Glosario Vision Plan de Desarrollo de Software
3.2.3 Plan
de Desarrollo de Software
3.2.3.1 Introducción
Este Plan de Desarrollo del Software es una versión preparada para ser incluida en la carrera de
informática. Este documento provee una visión global del enfoque de desarrollo
propuesto.
El proyecto ha sido propuesto por
estudiantes de la carrera de informática en la materia de Analisis y diseño
(Inf-162) del licenciado Msc. Miguel Cotaña en la que únicamente se procederá a
cumplir con las fases de metodología RUP en este documento. 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.
En esta propuesta se considera las utilidades de internet
para la gestión de procesos administrativos, una unidad de carácter académica
se advertirán rápidamente, al igual que los beneficios obtenidos, pues los
estudiantes requieren un servicio adecuado por la parte administrativa de dicha
unidad, ya sea en lo referente a su inscripción consulta sobre sus notas y
otros datos registrados en su historial.
3.2.3.2 Propósito
El propósito
de documento es proporcionar los detalles sobre los requerimientos y las
características necesarias para la elaboración de una plataforma web, encargada
de gestionar y automatizar el proceso de convocatorias (docentes) dentro de la
carrera de Informática.
3.2.3.3 Alcance
La
plataforma será utilizada con exclusividad dentro de la carrera de informática.
Ya que los estatutos utilizados para su desarrollo están orientados hacia esta
carrera. Se tratara de limitar las convocatorias a docentes, ya que las
convocatorias para estudiantes difieren de las de docentes.
3.2.3.4 Vista General del Proyecto
3.2.3.4.1 Propósito, Alcance y Objetivos
Lanzamiento de
convocatorias.El
sistema se limita solo a la carrera de informática.Elección de tribunalesLos tribunales serán extraídos del sistema de
seguimiento académico de la carrera.Recepción
de documentosNo todos los documentos presentados serán revisados en el
momento de la entrega, pero si se registraran los datos del postulante. Esto
con el fin de tomarlo en cuenta (docente o estudiante) en la siguiente
convocatoria.
Objetivos
Objetivo general
Ampliar la
credibilidad y la transparencia en los exámenes y minimizar la revisión de
documentos.
Objetivos específicos Almacenar en una base de datos los
documentos que anteriormente se presentaron. Crear una plataforma para
gestionar las notas del examen oral y el examen escrito Trabajando con el SIA
de la carrera para la verificación de algunos requisitos.
3.2.3.5 Entregables del proyecto 89
A continuación se indican y describen cada uno de los artefactos que
serán generados y utilizados por el proyecto y que constituyen los entregables.
Esta lista constituye la configuración de RUP desde la perspectiva de
artefactos, y que proponemos para este proyecto.
Es preciso destacar que de acuerdo a la filosofía de
RUP (y de todo proceso iterativo e incremental), todos los artefactos son
objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual,
sólo al término del proceso podríamos tener una versión definitiva y completa
de cada uno de ellos. Sin embargo, el resultado de cada iteración y los hitos
del proyecto están enfocados a conseguir un cierto grado de completitud y
estabilidad de los artefactos. Esto será indicado más adelante cuando se
presenten los objetivos de cada iteración.
3.2.3.6 Plan
de Desarrollo del Software
Es
el presente documento.
3.2.3.7 Modelo de Casos de Uso del Negocio
Es
un modelo de las funciones de negocio vistas desde la perspectiva de los
actores externos (Agentes de registro, solicitantes finales, otros sistemas
etc.). permite situar al sistema en el contexto organizacional haciendo énfasis
en los objetivos en este ámbito. Este modelo se representa con un Diagrama de
Casos de Uso usando estereotipos específicos para este modelo.
3.2.3.8 Modelo
de Objetos del Negocio
Es
un modelo que describe la realización de
cada caso de uso del negocio, estableciendo los actores internos, la
información que en términos generales manipulan y los flujos de trabajo (workflows)
asociados al caso de uso del negocio. Para la representación de este modelo se
utilizan Diagramas de Colaboración (para mostrar actores externos, internos y
las entidades (información) que manipulan, un Diagrama de Clases para mostrar
gráficamente las entidades del sistema y sus relaciones, y Diagramas de Actividad para mostrar los
flujos de trabajo.
3.2.3.9 Glosario 90
Es un documento que define los principales
términos usados en el proyecto. Permite
establecer una terminología consensuada. .
3.2.3.10 Modelo de Casos de Uso
El
modelo de Casos de Uso presenta las funciones del sistema y los actores que
hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso.
3.2.3.11 Visión
Este
documento define la visión del producto desde la perspectiva del cliente,
especificando las necesidades y características del producto. Constituye una
base de acuerdo en cuanto a los requisitos del sistema.
3.2.3.12 Especificaciones
de Casos de Uso
Para
los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no
baste con una simple descripción narrativa) se realiza una descripción
detallada utilizando una plantilla de documento, donde se incluyen:
precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales
asociados. También, para casos de uso cuyo flujo de eventos sea complejo podrá
adjuntarse una representación gráfica mediante un Diagrama de Actividad.
1)
Especificaciones Adicionales
Este documento capturará todos los requisitos que no
han sido incluidos como parte de los casos de uso y se refieren requisitos
no-funcionales globales. Dichos requisitos incluyen: requisitos legales o
normas, aplicación de estándares, requisitos de calidad del producto, tales
como: confiabilidad, desempeño, etc., u otros requisitos de ambiente, tales
como: sistema operativo, requisitos de compatibilidad, etc.
2)
Prototipos de Interfaces de Usuario
Se trata de prototipos que permiten al usuario hacerse
una idea más o menos precisa de las interfaces que proveerá el sistema y así,
conseguir retroalimentación de su parte respecto a los requisitos del sistema.
Estos prototipos se realizarán como: dibujos a mano en papel, dibujos con
alguna herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese
orden de acuerdo al avance del proyecto. Sólo los de este último tipo serán
entregados al final de la fase de Elaboración, los otros serán desechados.
Asimismo, este artefacto, será desechado en la fase de Construcción en la
medida que el resultado de las iteraciones vayan desarrollando el producto
final.
3)
Modelo de Análisis y Diseño
Este
modelo establece la realización de los casos de uso en clases y pasando desde
una representación en términos de análisis (sin incluir aspectos de
implementación) hacia una de diseño (incluyendo una orientación hacia el
entorno de implementación), de acuerdo al avance del proyecto.
4)
Modelo de Datos
Previendo
que la persistencia de la información del sistema será soportada por una base
de datos relacional, este modelo describe la representación lógica de los datos
persistentes, de acuerdo con el enfoque para modelado relacional de datos. Para
expresar este modelo se utiliza un Diagrama de Clases (donde se utiliza un
profile UML para Modelado de Datos, para conseguir la representación de tablas,
claves, etc.) .
5)
Modelo de Implementación
Este
modelo es una colección de componentes y los subsistemas que los contienen.
Estos componentes incluyen: ficheros ejecutables, ficheros de código fuente, y
todo otro tipo de ficheros necesarios para la implantación y despliegue del
sistema. (Este modelo es sólo una versión preliminar al final de la fase de
Elaboración, posteriormente tiene bastante refinamiento).
6)
Modelo de Despliegue
Este modelo muestra el despliegue la configuración de
tipos de nodos del sistema, en los cuales se hará el despliegue de los
componentes.
7)
Casos de Prueba
Cada
prueba es especificada mediante un documento que establece las condiciones de
ejecución, las entradas de la prueba, y los resultados esperados. Estos casos
de prueba son aplicados como pruebas de regresión en cada iteración. Cada caso
de prueba llevará asociado un procedimiento de prueba con las instrucciones
para realizar la prueba, y dependiendo del tipo de prueba dicho procedimiento
podrá ser automatizable mediante un script de prueba.
8) Solicitud de Cambio
Los
cambios propuestos para los artefactos se formalizan mediante este documento.
Mediante este documento se hace un seguimiento de los defectos detectados,
solicitud de mejoras o cambios en los requisitos del producto. Así se provee un
registro de decisiones de cambios, de su evaluación e impacto, y se asegura que
éstos sean conocidos por el equipo de desarrollo. Los cambios se establecen
respecto de la última baseline (el estado del conjunto de los artefactos en un
momento determinado del proyecto) establecida. En nuestro caso al final de cada
iteración se establecerá una baseline.
9) Plan de Iteración
Es
un conjunto de actividades y tareas ordenadas temporalmente, con recursos
asignados, dependencias entre ellas. Se realiza para cada iteración, y para
todas las fases.
10) Evaluación de Iteración
Este
documento incluye le evaluación de los resultados de cada iteración, el grado
en el cual se han conseguido los objetivos de la iteración, las lecciones
aprendidas y los cambios a ser realizados.
11) Lista de Riesgos
Este
documento incluye una lista de los riesgos conocidos y vigentes en el proyecto,
ordenados en orden decreciente de importancia y con acciones específicas de
contingencia o para su mitigación.
12) Manual de Instalación
Este
documento incluye las instrucciones para realizar la instalación del producto.
13) Material de Apoyo al Usuario Final
Corresponde a un conjunto de documentos y facilidades
de uso del sistema, incluyendo: Guías del Usuario, Guías de Operación, Guías de
Mantenimiento y Sistema de Ayuda en Línea
14) Producto
Los
ficheros del producto empaquetados y almacenadas en un CD con los mecanismos
apropiados para facilitar su instalación. El producto, a partir de la primera
iteración de la fase de Construcción es desarrollado incremental e
iterativamente, obteniéndose una nueva release al final de cada iteración.
Los
artefactos 19, 20 y 21 se generarán a partir de la fase de Construcción, con lo
cual se han incluido aquí sólo para dar una visión global de todos los
artefactos que se generarán en el proceso de desarrollo.
3.2.3.13 Evolución del Plan de Desarrollo del Software 92
El Plan de Desarrollo del Software se revisará
semanalmente y se refinará antes del comienzo de cada iteración.
3.2.3.14 Organización del Proyecto
3.2.3.14.1 Participantes en el Proyecto
De momento no se incluye el personal que designará
Deportes LSI 03 como Responsable del Proyecto, Comité de Control y Seguimiento,
otros participantes que se estimen convenientes para proporcionar los
requisitos y validar el sistema.
El resto del personal del proyecto (por la parte del la
empresa adjudicataria), considerando las fases de Inicio, Elaboración y dos
iteraciones de la fase de Construcción, estará formado por los siguientes
puestos de trabajo y personal asociado:
3.2.3.14.2 Interfaces Externas
Deportes LSI 03 definirá los participantes del proyecto
que proporcionarán los requisitos del sistema, y entre ellos quiénes serán los
encargados de evaluar los artefactos de acuerdo a cada subsistema y según el
plan establecido.
El equipo de desarrollo interactuará activamente con los
participantes de Deportes LSI 03 para especificación y validación de los
artefactos generados.
3.2.3.14.3 Roles y Responsabilidades 93
A
continuación se describen las principales responsabilidades de cada uno de los
puestos en el equipo de desarrollo durante las fases de Inicio y Elaboración,
de acuerdo con los roles que desempeñan en RUP.
3.2.3.15 Gestión del Proceso
3.2.3.15.1 Estimaciones del Proyecto
El
presupuesto estimado cuenta con el apoyo de la carrera de informatica
3.2.3.15.2 Plan del Proyecto
En esta sección se
presenta la organización en fases e iteraciones y el calendario del proyecto.
3.2.3.16 Plan de las Fases
El
desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada
una de ellas. La siguiente tabla muestra una la distribución de tiempos y el
número de iteraciones de cada fase (para las fases de Construcción y Transición
es sólo una aproximación muy preliminar)
Fase
|
Nro.
Iteraciones
|
Duración
|
Fase de Inicio
|
1
|
1 mes
|
Fase de Elaboración
|
1
|
1 mes
|
Fase de Construcción
|
2
|
2 meses
|
Fase de Transición
|
1
|
1 semana
|
Los hitos que marcan el final de cada
fase se describen en la siguiente tabla.
Descripción
|
Hito
|
Fase
de Inicio
|
En
esta fase desarrollará los requisitos del producto desde la perspectiva del
usuario, los cuales serán establecidos en el artefacto Visión. Los
principales casos de uso serán identificados y se hará un refinamiento del
Plan de Desarrollo del Proyecto. La aceptación del cliente / usuario del
artefacto Visión y el Plan de Desarrollo marcan el final de esta fase.
|
Fase de Elaboración
|
En
esta fase se analizan los requisitos y se desarrolla un prototipo de
arquitectura (incluyendo las partes más relevantes y / o críticas del
sistema). Al final de esta fase, todos los casos de uso correspondientes a
requisitos que serán implementados en la primera release de la fase de
Construcción deben estar analizados y diseñados (en el Modelo de Análisis /
Diseño). La revisión y aceptación del prototipo de la arquitectura del
sistema marca el final de esta fase. En nuestro caso particular, por no
incluirse las fases siguientes, la revisión y entrega de todos los artefactos
hasta este punto de desarrollo también se incluye como hito. La primera
iteración tendrá como objetivo la identificación y especificación de los
principales casos de uso, así como su realización preliminar en el Modelo de
Análisis / Diseño, también permitirá hacer una revisión general del estado de
los artefactos hasta este punto y ajustar si es necesario la planificación
para asegurar el cumplimiento de los objetivos. Ambas iteraciones tendrán una
duración de una semana.
|
Fase de Construcción
|
Durante la fase de
construcción se terminan de analizar y diseñar todos los casos de uso,
refinando el Modelo de Análisis / Diseño. El producto se construye en base a
2 iteraciones, cada una produciendo una release a la cual se le aplican las
pruebas y se valida con el cliente / usuario. Se comienza la elaboración de
material de apoyo al usuario. El hito que marca el fin de esta fase es la
versión de la release 3.0, con la capacidad operacional parcial del producto
que se haya considerado como crítica, lista para ser entregada a los usuarios
para pruebas beta.
|
Fase de Transición
|
En
esta fase se prepararán dos releases para distribución, asegurando una
implantación y cambio del sistema previo de manera adecuada, incluyendo el
entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye,
la entrega de toda la documentación del proyecto con los manuales de
instalación y todo el material de apoyo al usuario, la finalización del
entrenamiento de los usuarios y el empaquetamiento del producto.
|
3.2.3.17 Calendario del Proyecto 95
A
continuación se presenta un calendario de las principales tareas del proyecto
incluyendo sólo las fases de Inicio y Elaboración. Como se ha comentado, el
proceso iterativo e incremental de RUP está caracterizado por la realización en
paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo
cual la mayoría de los artefactos son generados muy tempranamente en el
proyecto pero van desarrollándose en mayor o menor grado de acuerdo a la fase e
iteración del proyecto. La siguiente figura ilustra este enfoque, en ella lo
ensombrecido marca el énfasis de cada disciplina (workflow) en un momento
determinado del desarrollo.
Para
este proyecto se ha establecido el siguiente calendario. La fecha de aprobación
indica cuándo el artefacto en cuestión tiene un estado de completitud
suficiente para someterse a revisión y aprobación, pero esto no quita la
posibilidad de su posterior refinamiento y cambios.
|
Fase de Elaboración
|
Aprobación
|
Modelado del Negocio
|
|
Modelo de Casos de Uso del Negocio y Modelo de
Objetos del Negocio
|
aprobado
|
Requisitos
|
|
Glosario
|
aprobado
|
Visión
|
aprobado
|
Modelo de Casos de Uso
|
-
|
Especificación de Casos de Uso
|
-
|
Especificaciones Adicionales
|
-
|
Análisis / Diseño
|
|
Modelo de Análisis / Diseño
|
Revisar en cada
iteración
|
Modelo de Datos
|
Revisar en cada
iteración
|
Gestión del proyecto
|
|
Plan de Desarrollo del Software en su versión 2.0 y
planes de las Iteraciones
|
Revisar en cada
iteración
|
No hay comentarios:
Publicar un comentario