Metodología para el Desarrollo del Proyecto SIACE

SISTEMA INTEGRAL ADMINISTRATIVO DE
CONTRALORÍAS DE ESTADO
(SIACE)
Página Elaboración
1/15 14/05/2015
PROYECTO PARA EL DESARROLLO DEL
SIACE
Versión
1.1
Actualización
01/07/2015
Proyecto para el Desarrollo del Sistema Integral Administrativo
de las Contralorías de Estado
SIACE
Versión 1.1
La información contenida en este documento es propiedad intelectual de las Contralorías de estados Orientales de Venezuela
Se prohíbe la reproducción total o parcial del mismo, sin consentimiento explícito de las mismas.
ENCUENTRO DE CONTRALORÍAS ORIENTALES-ENCOOVE – TODOS LOS DERECHOS RESERVADOS 2015.

(SIACE)
2/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
HISTORIAL DE REVISIÓN
FECHA VERSIÓN DESCRIPCIÓN AUTOR CARGO CONTRALORÍA
05/06/2015 1.0 Redacción Inicial del Documento Andy Vásquez Contralor Provisional SUCRE
01/07/2015 1.1 Incorporación del Concepto de Reingeniería
dentro de la metodología y actualización de
actores del proyecto.
Andy Vásquez Contralor Provisional SUCRE

(SIACE)
3/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
PLAN DE DESARROLLO DE SOFTWARE
Este Plan de Desarrollo del Software es una versión preparada para como respuesta al desarrollo del
Sistema Integral administrativo de Contralorías de estados; Este documento provee una visión global
del enfoque de desarrollo propuesto.
El proyecto ha sido concertado entre las Contralorías Orientales de Venezuela basado en La
metodología definida como el Proceso Unificado para el Desarrollo de Software (PUDS) en la que se
procederá a cumplir con todas las fases que marca la metodología, puesto que utilizaremos la
terminología (PUDS) en este documento. Debido a que este proyecto contempla la construcción en
versión mejorada de un sistema ya funcional, se explicará el concepto de reingeniería de software la
cual que se incorporará como actividad dentro de los flujos de trabajos en cada una de las fases del
proyecto. De igual forma se incluirá el detalle para las fases de Inicio y Elaboración y adicionalmente
se esbozarán las fases posteriores de Construcción y Transición para dar una visión global de todo
proceso.
El enfoque desarrollo propuesto constituye una configuración del proceso (PUDS) de acuerdo a las
características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los
artefactos (entregables) que serán generados. Este documento es a su vez uno de los artefactos de
(PUDS).
METODOLOGÍA DEL ÁREA DE APLICACIÓN
El Proceso Unificado para el Desarrollo de Software (PUDS), propuesta por Booch, Jacobson y
Rumbaugh en el año 1998 dentro de la corporación Rational Software.
El PUDS es un proceso de ingeniería de software. Provee un esquema disciplinado para asignar tareas y
responsabilidades en una organización de desarrollo. Su objetivo en el proyecto fue asegurar la
producción de software de alta calidad que reúna las necesidades de sus usuarios dentro de los límites
presupuestarios y de calendario. Ésta metodología constó de una serie de ciclos que se ejecutaron

(SIACE)
4/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
repetidamente. Cada ciclo o iteración estuvo dividido por de las fases de concepción, elaboración,
construcción y transición y culminó con una versión del producto de software (Figura 1). Estas
iteraciones estaban constituidas de la misma forma que un proyecto de software, como lo es la
planificación y el desarrollo de una serie de flujo de trabajos, los cuales se conformaron por captura de
requisitos, análisis, diseño, implementación y pruebas. El contenido de una iteración cambiaba para
acomodarse a los objetivos de cada fase.
Figura 1. Ciclo Iterativo de PUDS.
A continuación se describen cada uno de los flujos que contribuyen a la construcción del sistema:
Captura de requisitos: flujo de trabajo fundamental cuyo propósito esencial es orientar el desarrollo
hacia el sistema correcto. Esto se lleva a cabo mediante la descripción de los requisitos del sistema de

(SIACE)
5/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
forma tal que se pueda llegar a un acuerdo entre el cliente (incluyendo los usuarios) y los
desarrolladores, acerca de lo que debe y no debe hacer el sistema.
Modelado del negocio
En este flujo se entenderán los problemas que las contralorías desean solucionar y se identificaran las
mejoras potenciales, luego se medirá el impacto del cambio organizacional y la forma asegurar que los
usuarios finales y los otros participantes tuviesen un entendimiento compartido del problema.
Requerimientos
Aquí se establecerá y se mantendrá un acuerdo con los usuarios y los otros interesados acerca de que se
debe hacer con el sistema para proveerme a mi como desarrollador un mejor entendimiento de los
requerimientos del mismo, definiendo su alcance y un sustento para la planeación de los contenidos
técnicos de las iteraciones y la definición de una interfaz de usuario para el sistema enfocada en sus
necesidades y objetivos; Debido a que en este proyecto contempla la construcción en versión mejorada
de un sistema ya funcional, en este flujo de trabajo se efectuará una acción orientada a generar un
análisis para la reingeniería de los requerimientos y las interfaces sin perder la noción general del
sistema; al cual los usuarios finales ya están adaptados.
También se establecerá una base para la estimación de costo y tiempo necesarios para desarrollar el
sistema.
Análisis
En este flujo de trabajo se analizará las solicitudes descritas en la captura de requisitos, mediante su
refinamiento y estructuración.
Con esto se logrará una comprensión más precisa de los requerimientos, y se obtendrá una descripción
de las peticiones, lo que hará más fácil de mantener y esto ayudará a dar estructura al sistema en su
conjunto; incluyendo su arquitectura.

(SIACE)
6/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
Diseño
Se logrará formular los modelos que se centran en los requisitos no funcionales y el dominio de la
solución, y se prepararán para la implementación y pruebas del sistema; teniendo en cuenta el proceso
de reingenieria en los planos y pruebas.
Implementación
Flujo de trabajo fundamental donde se obtendrán los propósitos esenciales como lo es implementar el
sistema en términos de componentes, es decir, ficheros de código fuente, scripts, ficheros de módulos,
ejecutable y librerías. En este flujo de trabajo es donde se concentran con mayor fuerza, los cambios
planteados en el proceso de reingeniería de la estructura y del código del sistema
Prueba
Aquí se podrá comprobar el resultado de la implementación mediante las pruebas de cada construcción,
incluyendo tanto construcciones internas como intermedias, así como las versiones finales del sistema
que serán entregadas a terceros.
Administración y configuración de cambios
Este flujo permitirá controlar los cambios y mantener la integridad del producto desarrollado mediante
la identificación y restricción de los cambios en los elementos configurables, auditoría de los cambios
hechos a estos elementos y definición de los métodos, procesos y herramientas usadas para proveer la
administración y configuración.
Ambiente
Dentro del ambiente enfocamos las actividades necesarias para configurar el proceso al trabajo. Se
describirá las actividades requeridas para generar las líneas guías de apoyo al trabajo.
Todo esto con el fin de proveer a las contralorías, el ambiente necesario (herramientas y procesos) que

(SIACE)
7/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
me darán el soporte como equipo de desarrollo.
Evaluación
Sustenta un marco de trabajo, que permitirá administrar el proyecto de software. Proporcionándome
guías prácticas para la planeación, soporte, ejecución y monitoreo del trabajo, además de una base para
la administración del riesgo.
Además cada fase termina con un hito. Cada hito se determina por la disponibilidad de un conjunto
de artefactos; es decir, ciertos modelos o documentos que han sido desarrollados hasta alcanzar un
estado predefinido. Conjuntamente, el PUDS utiliza el Lenguaje Unificado de Modelado (LUM) para
preparar y describir todos los esquemas o modelos (artefactos) en cada una de las fases que lo
componen.
REINGENIERÍA DE SOFTWARE
Es una forma de modernización para mejorar las capacidades y/o mantenibilidad de los sistemas de
información heredados mediante la aplicación de tecnologías y practicas modernas. La Reingeniería de
Software ofrece una disciplina de preparación para migrar un sistema de información heredado hacia
un sistema evolucionable. El proceso aplica principios de ingeniería para un sistema existente para
encontrar nuevos requerimientos.
El propósito de la reingeniería es que los sistemas existentes tomen ventajas de las nuevas tecnologías y
habilitar el nuevo esfuerzo de desarrollo para que aproveche las ventajas de reutilizar sistemas
existentes. La reingeniería tiene el potencial de mejorar la productividad y calidad del software a través
de todo el ciclo de vida.
La reingeniería para el SIACE implicará cambiar la forma del programa y mejorar su documentación.
En este caso, la funcionabilidad del programa será cambiada; sólo su forma es modificada.

(SIACE)
8/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
A continuación se describirán las fases de la metodología a utilizar:
FASE DE CONCEPCIÓN
Se desarrollará una descripción del producto final a partir de una buena idea y se presentará el análisis
del negocio para el producto. Esencialmente, esta fase responderá a las siguientes preguntas:
¿Cuáles son las principales funciones del sistema para sus usuarios más importantes? ¿Cómo podría ser
la arquitectura del sistema? ¿Cuál es el plan de proyecto y cuánto costará desarrollar el producto?
La respuesta a la primera pregunta se encontrará en un modelo de casos de uso simplificado que
contenga los casos de uso más críticos. Cuando se tengan, la arquitectura es provisional, y consiste
típicamente en un simple esbozo que muestra los subsistemas más importantes, se planificará en detalle
la fase de elaboración, y se estimará el proyecto de manera aproximada.
FASE DE ELABORACIÓN
Aquí se especificarán en detalle la mayoría de los casos de uso del producto y se diseñará la
arquitectura del sistema. La relación entre la arquitectura del sistema y el propio sistema será
primordial. Una manera simple de expresarlo, es decir, que la arquitectura será análoga al esqueleto
cubierto por la piel pero con muy poco músculo (el software) entre los huesos y la piel, sólo lo
necesario para permitir que el esqueleto haga movimientos básicos. El sistema será el cuerpo entero
con esqueleto, piel y músculos.
Por tanto, la arquitectura se expresará en forma de vistas de todos los modelos del sistema, los cuales
juntos representarán al sistema entero. Esto implica que habrá vistas arquitectónicas de los modelos de
casos de uso, análisis, diseño, implementación y despliegue. La vista del modelo de implementación
incluirá componentes para probar que la arquitectura será ejecutable. Durante esta fase del desarrollo,
se realizarán los casos de uso más críticos identificados en la fase de inicio. El resultado de esta fase

(SIACE)
9/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
será una línea base de la arquitectura.
Al final de la fase de elaboración, el director de proyecto estará en disposición de planificar las
actividades y estimar los recursos necesarios para terminar el proyecto. Aquí la cuestión fundamental
es: ¿serán suficientemente estables los casos de uso, la arquitectura y el plan, y estarán los riesgos
suficientemente como para ser capaces de comprometerse al desarrollo entero mediante un contrato?.
FASE DE CONSTRUCCIÓN
Se creará el producto; añadiendo los músculos (software terminado) al esqueleto (la arquitectura). En
esta fase, la línea de la arquitectura crecerá hasta convertirse en el sistema completo. La descripción
evolucionará hasta convertirse en un producto preparado que será entregado a la comunidad de
usuarios. El grueso de los recursos requeridos se empleará durante esta fase del desarrollo. Sin
embargo, la arquitectura del sistema será estable, aunque los desarrolladores podrán descubrir formas
mejores de estructurar el sistema, ya que los arquitectos recibirán sugerencias de cambios
arquitectónicos de menor importancia. Al final de esta fase, el producto contendrá todos los casos de
uso que la dirección y el cliente habrán acordado para el desarrollo de esa versión. Sin embargo, puede
que no esté completamente libre de defectos. Muchos de estos defectos se descubrirán y solucionarán
durante la fase de transición. La pregunta decisiva será: ¿cubrirá el producto las necesidades de algunos
usuarios de manera suficiente como para hacer una primera entrega?.
FASE DE TRANSICIÓN
Cubrirá el periodo durante el cual el producto se convertirá en versión beta. En está, un número
reducido de usuarios con experiencia probará el producto e informará de defectos y deficiencias. Los
desarrolladores corregirán los problemas e incorporarán algunas de las mejoras sugeridas en una

(SIACE)
10/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
versión general que será dirigida a la totalidad de la comunidad de usuarios. La fase de transición
conllevará actividades como la fabricación, formación del cliente, proporcionará una línea de ayuda y
asistencia, y la corrección de los defectos que se encontrarán tras la entrega. El equipo de
mantenimiento suele dividir esos defectos en dos categorías: los que tendrán suficiente impacto en la
operación para justificar una versión incrementada (versión delta) y los que podrán corregirse en la
siguiente versión normal.
Tabla 1. Relación de hitos por fases.
Fase Hitos
Inicio Objetivos y ámbitos
Elaboración Arquitectura
Construcción Capacidad operacional
inicial( Reingeniería )
Transición Liberación del producto

(SIACE)
11/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
Figura 2. Representación gráfica del PUDS.

(SIACE)
13/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
FORMATO DE CONTROL DE ITERACIÓN CON SUS FLUJOS DE TRABAJO
Fase: Construcción SEMANA 1 SEMANA 2
1 Flujo de Trabajo Lunes Martes Miércoles Jueves Viernes Lunes Martes Miércoles Jueves Viernes
2 Modelado de Negocio
3 Entrevistas Minutas
4 Video Conferencias
5 Requerimientos
6 Jerarquía de Actores.
7 Reingeniería de
Requerimientos/Interfaces
8 Casos de Uso
9 Análisis/ Diseño
10 Diag. Clases
11 Modelo de Datos
12 Reingeniería en Planos.
13 Diag. Secuencia.
14 Implantación
15 Análisis de Esquema Proy./
16 Mapeo de Clases/ Tablas
17 Ringeniería de Códigos
18 Programación
19 Pruebas
20 Pruebas de Funcionamiento
21 Integridad Base Datos
22 Pruebas de Plataforma
23 Integración
24 Ajustar Cambios en Clases y
Tablas Generales
25 Migrar a Versión Integrada
26 Prueba Post Integración.

(SIACE)
14/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
ORGANIZACIÓN DEL PROYECTO
Participantes en el Proyecto
Hasta el momento y como acuerdos previos se cuenta con:
TIPO DE PERSONAL SUCRE MONAGAS DELTA AMACURO BOLIVAR TOTALES
Analistas Programadores 3 3 2 2 10
Analista de Sistema. 1 5 0 0 6
Jefe Informática (Gerencia). 0 1 0 0 1
Director(a) Técnica (Gerencia). 1 1 1 1 4
Contralor (a) (Gerencia). 1 1 1 1 4
Roles y Responsabilidades
A continuación se describen las principales responsabilidades de cada uno de los puestos en el equipo
de desarrollo durante las fases del PUDS, para la construcción del SIACE.
PUESTO RESPONSABILIDAD
Jefe de Proyecto Gerencia y
Metodología
El jefe de proyecto asignará los recursos, gestionará las prioridades, coordinará las interacciones
con los usuarios, y mantendrá al equipo del proyecto enfocado en los objetivos. El jefe de proyecto
también establecerá un conjunto de prácticas que aseguran la integridad y calidad de los
artefactos del proyecto. Además, el jefe de proyecto se encargará de supervisar el establecimiento
de la arquitectura del sistema. Gestión de riesgos. Planificación y control del proyecto.
Jefe de Programación
El jefe de programación se encargará de verificar y ejecutar las acciones necesarias para que se
cumplan el estándar de programación, así como del buen funcionamiento y prueba de la
codificación en general. Debe también asegurarse que la programación sea fiel a los diagramas de
caso de uso, clases y Secuencia. Responde e Informa al Jefe de Proyecto y Coordinará con los
otros actores del sistema.

(SIACE)
15/15 14/05/2015
SIACE
Versión
1.1
Actualización
01/07/2015
PUESTO RESPONSABILIDAD
Administrador de base de
Datos (DBA)
El administrador de Base de Datos se encargara de general y mantener un modelo general de
base de datos del SIACE, de igual forma construir un solo archivo .sql con la BD, un solo modelo
relacional en el software de modelado;en la forma normal más óptima, también es quien se
encargara de hacer cumplir el estándar para base de datos del SIACE, Responde e Informa al
Jefe de Proyecto y Coordinará con los otros actores del sistema.
Analista de Sistemas
Le corresponderá la captura, especificación y validación de requisitos, interactuando con los
usuarios mediante entrevistas. Elaboración del Modelo de Análisis y Diseño. Colaboración en la
elaboración de las pruebas funcionales, modelo de datos y Manuales del sistema. Responde e
Informa al Jefe de Proyecto y Coordinará con los otros actores del sistema.
Analista/ Programador
Además de hacer todas las funciones del Analista de Sistema, le corresponde: la construcción de
prototipos. Colaboración en la elaboración de las pruebas funcionales, modelo de datos y en las
validaciones con el usuario. Responde e Informa al Jefe de y Programación y el de Proyecto,
Coordinará con los otros actores del sistema.
Integrador
Se encargara de unir todas las funcionalidades adelantadas en cada iteración, por parte de los
programadores; el administrador de base de datos y los analistas. El resultado de su trabajo es la
versión concertada del SIACE, tanto en programación, como en planos y Base de dato. Responde
e Informa al Jefe de Proyecto y Coordinará con los otros actores del sistema.

Metodología para el Desarrollo del Proyecto SIACE

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Metodología para el Desarrollo del Proyecto SIACE

Semelhante a Metodología para el Desarrollo del Proyecto SIACE (20)

Metodología para el Desarrollo del Proyecto SIACE