Proyecto para el Desarrollo del Sistema Integral ...cgesucre.gob.ve/ces_web/encoove/METODOLOGIA_SIACE.pdf · El PUDS es un proceso de ingeniería de software. Provee un esquema disciplinado

SISTEMA INTEGRAL ADMINISTRATIVO DECONTRALORÍAS DE ESTADO

(SIACE)

Página Elaboración

1/15 14/05/2015

PROYECTO PARA EL DESARROLLO DELSIACE

Versión

1.1

Actualización

01/07/2015

Proyecto para el Desarrollo del Sistema Integral Administrativode las Contralorías de Estado

SIACEVersión 1.1

La información contenida en este documento es propiedad intelectual de las Contralorías de estados Orientales de VenezuelaSe 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


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íadentro de la metodología y actualización de

actores del proyecto.

Andy Vásquez Contralor Provisional SUCRE




(SIACE)


3/15 14/05/2015


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


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


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


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


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


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


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


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


Versión

1.1

Actualización

01/07/2015

Figura 2. Representación gráfica del PUDS.




(SIACE)


13/15 14/05/2015


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


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 yMetodología

El jefe de proyecto asignará los recursos, gestionará las prioridades, coordinará las interaccionescon los usuarios, y mantendrá al equipo del proyecto enfocado en los objetivos. El jefe de proyectotambién establecerá un conjunto de prácticas que aseguran la integridad y calidad de losartefactos del proyecto. Además, el jefe de proyecto se encargará de supervisar el establecimientode 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 secumplan el estándar de programación, así como del buen funcionamiento y prueba de lacodificación en general. Debe también asegurarse que la programación sea fiel a los diagramas decaso de uso, clases y Secuencia. Responde e Informa al Jefe de Proyecto y Coordinará con losotros actores del sistema.




(SIACE)


15/15 14/05/2015


Versión

1.1

Actualización

01/07/2015

PUESTO RESPONSABILIDAD

Administrador de base deDatos (DBA)

El administrador de Base de Datos se encargara de general y mantener un modelo general debase de datos del SIACE, de igual forma construir un solo archivo .sql con la BD, un solo modelorelacional en el software de modelado;en la forma normal más óptima, también es quien seencargara de hacer cumplir el estándar para base de datos del SIACE, Responde e Informa alJefe 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 losusuarios mediante entrevistas. Elaboración del Modelo de Análisis y Diseño. Colaboración en laelaboración de las pruebas funcionales, modelo de datos y Manuales del sistema. Responde eInforma 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 deprototipos. Colaboración en la elaboración de las pruebas funcionales, modelo de datos y en lasvalidaciones 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 losprogramadores; el administrador de base de datos y los analistas. El resultado de su trabajo es laversión concertada del SIACE, tanto en programación, como en planos y Base de dato. Respondee Informa al Jefe de Proyecto y Coordinará con los otros actores del sistema.



Documents

Proyecto para el Desarrollo del Sistema Integral ...cgesucre.gob.ve/ces_web/encoove/METODOLOGIA_SIACE.pdf · El PUDS es un proceso de ingeniería de software. Provee un esquema disciplinado