Proyecto para la Corrección de Errores en Listas de Ceros y Unos

Plan de Desarrollo de
Software

Versión 0.5

Historial de Revisiones

Plan de Desarrollo del
Software

Introducción

La relación entre las computadoras como medio o
herramienta de transmisión de información produce
continuamente un movimiento de datos, generalmente por canales no
diseñados para este propósito (línea
telefónica), y que introducen un ruido externo que produce
errores en la transmisión.

En consecuencia, debemos asegurarnos que este
fenómeno que causa errores, pueda ser detectado al momento
de generarse y/o al ser transmitido para posteriormente
corregirlo.

El método para detectar y corregir errores es
incluir en los bloques de datos transmitidos bits adicionales
denominados redundancia.

En la investigación realizada, se han
desarrollado dos estrategias básicas para manejar los
errores:

• Incluir suficiente información redundante en
  cada bloque de datos para que se puedan detectar y corregir
  los bits erróneos. Se utilizan códigos de
  corrección de errores.

• Incluir sólo la información redundante
  necesaria en cada bloque de datos para detectar los errores.
  En este caso el número de bits de redundancia es
  menor. Se utilizan códigos de detección de
  errores.

Si consideramos un bloque de datos formado
por m bits de datos y r de redundancia, la longitud final del
bloque será n, donde n = m + r.

Propósito

El propósito del Plan de Desarrollo de Software
es proporcionar la información necesaria para controlar el
proyecto. En él se describe el enfoque de desarrollo del
software.

Los usuarios del Plan de Desarrollo del Software
son:

• El jefe del proyecto lo utiliza para organizar la
  agenda y necesidades de recursos, y para realizar su
  seguimiento.

• Los miembros del equipo de desarrollo lo usan para
  entender lo qué deben hacer, cuándo deben
  hacerlo y qué otras actividades dependen de
  ello.

Alcance

[Una breve descripción del alcance de este
Plan de Desarrollo Software]

Resumen

Después de esta introducción, el resto del
documento está organizado en las siguientes
secciones:

Vista General del Proyecto — proporciona una
descripción del propósito, alcance y objetivos del
proyecto, estableciendo los artefactos que serán
producidos y utilizados durante el proyecto.

Organización del Proyecto — describe
la estructura organizacional del equipo de desarrollo.

Gestión del Proceso — explica los
costos y planificación estimada, define las fases e hitos
del proyecto y describe cómo se realizará su
seguimiento.

Planes y Guías de aplicación —
proporciona una vista global del proceso de desarrollo de
software, incluyendo métodos, herramientas y
técnicas que serán utilizadas.

Vista General del
Proyecto

Propósito, Alcance y
Objetivos

La información que a continuación se
incluye ha sido extraída de las diferentes reuniones que
se han celebrado con el stakeholder de la empresa desde el inicio
del proyecto, Patricio Letelier Torres.

Suposiciones y Restricciones

[Describe todas aquellas suposiciones que se
realizan sobre el proyecto y se declaran las restricciones
impuestas tales como restricciones temporales, de hardware, de
personal, etc.]

Entregables del
proyecto

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.

• 1) Plan de Desarrollo del
  Software

Es el presente documento.

• 2) 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) 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.

• 4) Glosario

Es un documento que define los principales
términos usados en el proyecto. Permite establecer una
terminología consensuada. .

• 5) 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.

• 6) 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.

• 7) 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.

• 8) 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.

• 9) 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.

• 10) 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.

• 11) 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.) .

• 12) 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).

• 13) 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.

• 14) 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.

• 15) 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.

• 16) 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.

• 17) 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.

• 18) 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.

• 19) Manual de
  Instalación

Este documento incluye las instrucciones para realizar
la instalación del producto.

• 20) 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

• 21) 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.

Evolución del
Plan de Desarrollo del Software

El Plan de Desarrollo del Software se revisará
semanalmente y se refinará antes del comienzo de cada
iteración.

Organización del Proyecto

Participantes en el Proyecto

Jefe de Proyecto.

[Aquí se declara el perfil del candidato a
este puesto, así como su nombre y
apellidos]

Analista de Sistemas.

[Aquí se declara el perfil del candidato a
este puesto, así como su nombre y
apellidos]

Analistas – Programadores.

[Aquí se declara el perfil de los candidatos
a estos puestos, así como sus nombres y
apellidos]

Ingeniero de Software.

[Aquí se declara el perfil del candidato a
este puesto, así como su nombre y
apellidos]

Interfaces Externas

[Breve descripción de las interfaces y
funcionalidad que ofrecerá el producto]

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 de Inicio y Elaboración, de
acuerdo con los roles que desempeñan en RUP.

Gestión del
Proceso

Estimaciones del Proyecto

El presupuesto del proyecto y los recursos involucrados
se adjuntan en un documento separado.

Plan del Proyecto

En esta sección se presenta la
organización en fases e iteraciones y el calendario del
proyecto.

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)

Los hitos que marcan el final de cada
fase se describen en la siguiente tabla.

Calendario del
Proyecto

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.

Seguimiento y Control
del Proyecto

Gestión de Requisitos

[Breve descripción de los requisitos que a
los que se irá haciendo un seguimiento a lo largo de todo
el proyecto]

Control de Plazos

[Figuran aquí los plazos de entrega de cada
una de las fases planificadas]

Control de Calidad

[Descripción de los
parámetros a tener en cuenta para llevar un control de
calidad]

Gestión de Riesgos

[Definidos por el
cliente]

Gestión de Configuración

[Resumen de los requisitos de
configuración del producto generado en el
proyecto]

Referencias

Autor:

Carlos Oblitas