Proceso de desarrollo

Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de los usuarios en un producto final de software.

Versión 1.1

Modificado el 2 de septiembre de 2004

© 2004 solucion.biz. Todos los derechos reservados. Envienos su comentarios y sugerencias.


Objetivo

El propósito de este documento es describir el proceso de desarrollo de software que se utiliza en solucion.biz.

El proceso de desarrollo define quién esta haciendo qué, cuándo y cómo alcanzar un determinado objetivo. El proceso de desarrollo es una definición de un conjunto de actividades, no su ejecución.

Este documento sirve como guiá interna y como referencia a los clientes de que se hace en cada momento y porque.


Alcance

Al proceso de desarrollo utilizado en solucion.biz.


Convenciones en el documento

La siguiente tabla muestra las convenciones tipográficas utilizadas en este documento.

Convenio | Ejemplo | Descripción
Negrita | método Do | Identifica elementos predefinidos de programación, por ejemplo, clases, interfaces, métodos, funciones, macros, estructuras, enumerativos, campos, operadores, constructores, propiedades, eventos, tipo de datos, directivas, palabras claves, instrucciones, excepciones, atributos, llaves y valores del registro. También indica entradas de usuario tal y como tienen que ser escritas.
Itálica | Nombre | Indica textos a rellenar, por ejemplo parámetros de funciones o métodos, nombres de módulos y entradas que el usuario debe dar.
Letras mayúsculas | ENTER | Indica nombres de teclas o secuencia de teclas.
Signo más | ALT+F1 | Indica combinación de teclas.


Referencias

[1] Ivar Jacobson, Grady Booch y James Rumbaugh, El Proceso Unificado de desarrollo de software. Object Technology Series, Addison-Wesley, 2000.

[2] Roger S. Pressman, Ingenieria de Software, Un enfoque practico. Quinta edición. McGraw-Hill, 2002.

[3] Grady Booch. Análisis y diseño orientado a objetos con aplicaciones. Segunda edición. Addison-Wesley, 1998.


Guía rápida

Esta sección incluye una guiá rápida del proceso de desarrollo, otras secciones profundizan más en cada área en particular.

El proceso en una frase

El proceso de desarrollo esta dirigido por los casos de uso y centrado en la arquitectura, trata de mitigar los riesgos lo antes posible, y todo esto de una forma iterativa e incremental.

El proceso resumido

Fase de inicio: Tiene como objetivo desarrollar el análisis de negocio hasta el punto necesario para justificar la puesta en marcha del proyecto.

Se crea la visión que contiene los requisitos desde el punto de vista del usuario final.

Se obtiene una descripción de la funcionalidad del producto como casos de uso.

Se crea lista de riesgos con todos los problemas potenciales, que puede ocurrir o no.

Se hace un plan de proyecto con detalle sobre las iteraciones y su cronograma.

Fase de elaboración: Se especifican en detalle la mayoría de los casos de uso del producto y se diseña la línea base de la arquitectura del sistema.

Se crea la línea base de la arquitectura, que incluye el conjunto de decisiones significativas acerca de la organización de un sistema software.

Se obtiene un esqueleto ejecutable.

Se actualizan y completan los casos de uso.

Se actualiza la lista de riesgos.

Se actualiza el plan de proyecto.

Fase de construcción: La línea base de la arquitectura crece hasta convertirse en el sistema completo.

Una versión del sistema ejecutable con capacidad operativa inicial.

Se actualiza la lista de riesgos.

Se actualiza el plan de proyecto.

Fase de transición: Cubre el periodo durante el cual el producto se convierte en versión beta y pasa a la versión final.

Desde la versión beta a la entrega final del producto.

Se actualiza el plan de proyecto.


Principios

El proceso de desarrollo define el conjunto de actividades necesarias para convertir los requisitos de usuarios en un conjunto consistente de artefactos que conforman un producto software, y para convertir los cambios sobre esos requisitos en un nuevo conjunto consistente de artefactos. La palabra requisito se utiliza con un sentido general, refiriéndose a necesidades.

El producto software es más que código, son todos los artefactos que se necesitan para representarlo en una forma compresible por maquinas y hombres. Un artefacto es un término general para referirse a cualquier tipo de información creada, producida, cambiada o utilizada en el desarrollo del producto.

El proceso de desarrollo está dirigido por hitos externos e internos, que son puntos de comprobación que guían el proceso.

Se emplea el Lenguaje Único de Modelado (UML) para preparar todos los esquemas y modelos del sistema en construcción.

El concepto de entrega de versiones es importante durante el ciclo de vida del proyecto porque afecta a la manera en que se establecen las expectativas, cómo se planean y administran.


Dirigidos por los casos de uso

Un producto software ve la luz para dar servicios a sus usuarios. Por tanto, para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean.

El término usuario no sólo hace referencia a usuarios humanos sino también a otros sistemas. En este sentido, el término usuario representa alguien o algo, como otro sistema, que interactúa con el sistema que estamos desarrollando. En repuesta a la interacción con un usuario el sistema lleva a cabo una secuencia de acciones que proporcionan al usuario un resultado importe.

Una interacción de este tipo es un caso de uso. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales del sistema. Un requisito funcional especifica una acción que debe ser capaz de realizar el sistema, sin considerar restricciones físicas; es un requisito que especifica el comportamiento de entrada/salida de un sistema.

De esta forma, definimos un caso de uso como una secuencia de acciones, incluyendo variantes, que el sistema puede llevar a cabo, y que producen un resultado observable de valor para un actor concreto.

En este contexto un actor es un conjunto coherente de roles que los usuarios de casos de uso desempeñan cuando interaccionan con estos casos de usos.

Los actores representan papeles que la gente o sistemas juegan como impulsores del sistema, un actor es algo que se comunica con el sistema o producto y que es externo al sistema en sí mismo.

El término rol se define como el comportamiento especifico de una entidad que participa en un contexto particular.

Es importante notar que un actor y un usuario no son la misma cosa. Un usuario normal puede jugar un número de papeles o roles diferentes cuando utiliza un sistema, por tanto un actor representa una clase de entidades externas, a veces, pero no siempre personas, que lleva a cabo un rol.

Una vez identificado los actores, se pueden desarrollar los casos de uso. Los casos de uso describen la manera en que los actores interactúan con el sistema. Cada caso de uso esta defino desde el punto de vista del actor que lo ejecuta.

Todos los casos de uso junto describen la funcionalidad total del sistema.

Puede decirse que una especificación funcional contesta a la pregunta: ¿Qué debe hacer le sistema? La estrategia de los casos de uso puede describirse añadiendo tres palabras al final de esta pregunta: ¿...para cada usuario? Estas tres palabras albergan una implicación importante. Nos fuerzan a pensar en términos de importancia para el usuario y no sólo en términos de funciones que sería bueno tener. Sin embargo, los casos de uno no son sólo una herramienta para especificar los requisitos del sistema. También guían el diseño, implementación, y prueba; esto es, guían el proceso de desarrollo. Basándose en el modelo de casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo los casos de uso. Los desarrolladores revisan cada uno de los sucesivos modelos para que sean conformes al modelo de casos de uso. Las prueban se centran en garantizar que los componentes implementados implementan correctamente los casos de uso.

Aunque es cierto que los casos de uso guían el proceso, no se desarrollan aisladamente. Se desarrollan junto con la arquitectura del sistema. Es decir, los casos de uso guían la arquitectura del sistema y la arquitectura del sistema influye en la selección de los casos de uso. Por tanto, la arquitectura y los casos de uso maduran según avanza el ciclo de desarrollo.


Centrado en la arquitectura

El papel de la arquitectura de software es parecido al papel que juega la arquitectura en la construcción de edificios. El edificio se contempla desde varios puntos de vista: estructura, servicios, calefacción, fontanería, electricidad, etc. Esto permite a un constructor ver una imagen completa antes de que comience la construcción. Análogamente, la arquitectura en un sistema de software se describe mediante diferentes vistas del sistema en construcción.

La arquitectura es el conjunto de decisiones significativas acerca de la organización de un sistema software, la selección de los elementos estructurales a partir de los cuales se compone el sistema, y las interfaces entre ellos, junto con su comportamiento, tal y como se especifica en las colaboraciones entre esos elementos, la composición de esos elementos estructurales y de comportamiento en subsistema progresivamente mayores, y el estilo arquitectónico que guía esta organización: estos elementos y sus interfaces, sus colaboraciones y su composición. La arquitectura del software se interesa no solo por la estructura y el comportamiento, sino también de las restricciones y compromisos de uso, funcionalidad, funcionamiento, flexibilidad al cambio, reutilización, compresión, economía y tecnología, así como de aspectos estéticos.

El concepto de arquitectura de software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, también se ve influida por muchos otros factores, como la plataforma en la que tiene que funcionar el software, los bloques de construcción reutilizables de que se disponen, consideraciones de implantación y requisitos no funcionales. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalle a un lado.

La arquitectura facilita la compresión del sistema, y por consiguiente su primer requisito es que debe capacitar a los desarrolladores, directivos y clientes para comprender qué están haciendo con suficiente detalle como para facilitar su propia participación. También fomenta la reutilización al crear patrones arquitectónicos reutilizables.

La arquitectura se desarrolla mediante interacciones, y se trata de obtener una línea base de la arquitectura lo antes posible, un esqueleto del sistema.

Una línea base es un conjunto de artefactos revisados y aprobados que representan un punto de acuerdo para la posterior evolución y desarrollo, y solamente puede ser modificado a través de un procedimiento formal, como la gestión de cambios y configuraciones.

¿Cómo se relacionan los casos de uso y la arquitectura? Cada producto tiene tanto una función como una forma. Ninguna es suficiente por sí misma. Estas dos fuerzas deben equilibrase para obtener un producto con éxito. En esta situación, la función corresponde con los casos de uso y la forma con la arquitectura. Debe haber interacción entre los casos de uso y la arquitectura. Por un lado, los casos de uso deben encajar en la arquitectura cuando se llevan a cabo, y por otro lado, la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro.

Por tanto, los arquitectos moldean el sistema para darle forma. Esta forma, la arquitectura, debe diseñarse para permitir que el sistema evolucione, no sólo en su desarrollo inicial, sino también a lo largo de futuras generaciones. Para encontrar esta forma, los arquitectos deben trabajar sobre la comprensión general de las funciones claves, es decir, sobre los casos de uso claves del sistema. Estos casos de uso claves pueden suponer solamente entre el 5 y 10 por ciento de todos los casos de uso, pero son los significativos.


Iterativo e incremental

El desarrollo de un producto de software supone un gran esfuerzo que puede durar desde varios meses hasta posiblemente años. Es práctico dividir el trabajo en partes más pequeñas. Cada parte es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. Para una efectividad máxima, las iteraciones deben ser controladas; esto es, deben seleccionarse y ejecutarse de una forma planificada.

Los desarrolladores basan la selección de lo que se implementará en una iteración en dos factores. En primer lugar, la iteración tratara un grupo de casos de uso que juntos amplíen la utilidad del producto desarrollado hasta ahora. En segundo lugar, la iteración trata los riesgos más importante. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la ultima iteración. Cada iteración comienza con los casos de uso y continúan a través del trabajo de desarrollo de análisis, diseño, implementación y prueba, que terminan convirtiendo en código ejecutable los casos de uso que se desarrollan en la iteración.

En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño mediante componentes, y verifican que los componentes satisfacen los casos de uso. Cuando una iteración cumple sus objetivos el desarrollo sigue con la siguiente iteración. Si la iteración no cumple sus objetivos, los desarrolladores deben revisar sus decisiones previas y probar con un nuevo enfoque.

Un riesgo es una variable del proyecto que pone en peligro o impide el éxito del mismo. Es la probabilidad de que un proyecto experimente sucesos no deseados, como retrasos en las fechas, exceso de coste, o la cancelación directa.

Identificamos, priorizamos y llevamos a cabo las iteraciones sobre la base de los riesgos y su orden de importancia. Principalmente cuando se evalúan nuevas tecnologías y se trabaja por cumplir con las necesidades de los usuarios, sean funcionales o no, como características de rendimiento, fiabilidad, disponibilidad, integridad de las interfaces de usuario, adaptabilidad y portabilidad. Muchos de los riesgos no son visibles hasta que se implementa y prueba el software, y éste es el motivo por el cual se deben llevar a cabo iteraciones que examinen los riesgos lo antes posible.

Normalmente un riesgo se puede hacer corresponder con un caso de uso. Así un riesgo se atenúa si se desarrolla el caso de uso con el que corresponde teniendo en cuenta los requisitos funcionales y no funcionales del caso de uso.

Una iteración es un recorrido completo por todos los flujos de trabajos fundamentales que obtiene como resultado una versión interna. Los cinco flujos de trabajo fundamentales en una iteración son requisitos, análisis, diseño, implementación y prueba. La importancia o peso que se le dedica a cada flujo de trabajo depende del tipo de iteración, una iteración al inicio del proyecto tendrá más peso en los requisitos, análisis y diseño que una iteración al final del proyecto que se centrara en la implementación y la prueba.

Al terminar una iteración se evalúan sus resultados. Uno de los objetivos es determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso.

Para alcanzar el mayor grado de economía en el desarrollo, el equipo intentará seleccionar sólo las iteraciones requeridas para lograr el objetivo del proyecto tratando de secuenciar las iteraciones en un orden lógico.


Programación dirigida por riesgos

La programación dirigida por riesgos, como su propio nombre indica, es la programación de tareas y componentes que representan los mayores factores de riesgo al inicio del proceso de desarrollo.

Un riesgo es un problema potencial, que puede ocurrir o no. Existen diferentes categorías de riesgos, riesgos del proyecto, riesgos técnicos y riesgos del negocio, cada una cubre un tipo de riesgo diferente. Los riesgos del proyecto identifican problemas potenciales de presupuesto, planificación temporal, personal, recursos, clientes y requisitos. Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir, si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, interfaz, verificación y mantenimiento. También las ambigüedades en la especificación, incertidumbre técnica, técnicas anticuada o tecnologías puntas son factores de riesgos importantes. Los riesgos del negocio amenazan la viabilidad del software a construir y la presencia de estos puede afectar el negocio de la empresa.

Hay que identificar los riesgos potenciales, asignar sus probabilidades, impactos, plan de contingencia y una prioridades según su importancia.

La siguiente lista describe pautas para la implementación de la programación dirigida por riesgos:

· La manera en que la función de programación se define mientras se crea la línea base de la arquitectura fomenta el uso de prototipos de implementación y de prueba de conceptos para explorar y mitigar los riesgos. Antes de que el equipo apruebe la línea base de la arquitectura, se tendrá que asegurar que entiende los riesgos que ésta implica. A continuación, el equipo se comprometerá a desarrollar y entregar la programación de tareas y dar prioridad a las versiones de desarrollo.

· La prioridad se genera en la definición de la especificación funcional. El equipo y los clientes acuerdan las prioridades, basadas en el riesgo técnico. Esto garantiza que las funciones potencialmente arriesgadas y las funciones de particular importancia para la empresa están disponibles en primer lugar.

· Los hitos principales no son puntos en los que las entregas se detienen, sino que son puntos en los que se ponen conjuntos de suposiciones bajo un control de cambios, de manera que los riesgos identificados tras ese punto se puedan planear y mitigar.

· A medida que la línea base de la arquitectura se consolida, los desarrolladores implementan las funcionalidades esenciales del sistema, que pueden ayudar a identificar nuevos riesgo.

· El concepto de entrega de versiones es parte del modelo de desarrollo. Esto permite que un equipo sea receptivo a los intercambios de funciones, programaciones de tareas y riesgos. También establece la etapa de mejora paulatina en la línea base de la primera versión.

La programación dirigida por riesgos anima a los programadores a trabajar con dinamismo hacia el primer hito en vez de ampliar el trabajo para solventar factores de riesgo.

Por otro lado, la ausencia del primer hito sirve como primer aviso a la administración del proyecto, llamando la atención del retraso de manera proactiva. El tiempo de retraso en los primeros hitos del proyecto sirve como medida de estimación de la calidad y proporciona información sobre las previsiones en el ajuste de los hitos que se tendrán que hacer más tarde en el proyecto.

Además, los clientes disponen de mayor visibilidad en las áreas de riesgo del proyecto y sus expectativas se administran de una manera más productiva.


Fases

El proceso de desarrollo de un producto se divide en cuatro fases. A través de una secuencia de modelos, los implicados visualizan lo que está sucediendo en esas fases. Dentro de cada fase se puede descomponer adicionalmente el trabajo, en iteraciones con sus incrementos. Cada fase termina con un hito principal, y por la disponibilidad de un conjunto de artefactos; es decir, ciertos modelos o documentos han sido desarrollados hasta alcanzar un estado predefinido.

Cada fase contiene una o más iteraciones en la que se realizan todos los flujos de trabajo.

Al iniciar una fase se crea su planificación, incluyendo las metas a alcanzar y los artefactos a crear o actualizar. Al terminar la fase se hace una evaluación de la misma según la planificación realizada. La fase termina cuando se alcanza un determinado hito.

Los hitos tienen muchos objetivos. El más crítico es la toma de ciertas decisiones cruciales antes de que el trabajo pueda continuar con la siguiente fase. Los hitos también permiten controlar el progreso del trabajo según pasa por esos cuatro puntos claves. Al final, se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumido en cada fase. Estos datos son útiles en la estimación del tiempo y los recursos humanos para otros proyectos, en la asignación de recursos durante el tiempo que dura el proyecto, y en el control del progreso contrastado con las planificaciones.


Inicio

El objetivo de la fase de inicio es desarrollar el análisis de negocio hasta el punto necesario para justificar la puesta en marcha del proyecto.

Durante la fase de inicio, se desarrolla una descripción del producto final a partir de una buena idea y se presenta el análisis de negocio para el producto.

Esencialmente, esta fase responde 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 encuentra en un modelo de casos de uso simplificado que contenga los casos de uso más críticos. Cuando lo tengamos, la arquitectura es provisional, y consiste típicamente en un simple esbozo que muestra los subsistemas más importantes. En esta fase, se identifica y se da prioridad a los riesgos más importantes, se planifica en detalle la siguiente fase, y se estima el proyecto de manera aproximada.

En la fase de inicio el criterio esencial es determinar la viabilidad del proyecto, que llevamos a cabo mediante:

· La definición del ámbito del sistema:

o         ¿Está claro lo que va a formar parte del sistema?

o         ¿Se han identificado todos los actores?

o         ¿Se ha expuesto la naturaleza general de las interfaces con estos actores (interfaces de usuario y protocolos de comunicación)?

o         ¿Puede, lo que está incluido en el ámbito, constituir por sí mismo un sistema que funcione?

· Solución a las ambigüedades en los requisitos:

o         ¿Se han identificado y detallado los requisitos, tanto funcionales y no funcionales del limitado número de casos de uso necesarios para alcanzar los objetivos de la fase?

o         ¿Se han identificado y detallado los requisitos adicionales?

· La identificación y reducción de los riesgos críticos para la viabilidad del proyecto, y determinar si podemos mitigarlos.

o         ¿Se han identificado todos los riesgos?

o         ¿Se han mitigado todos los riesgos o existe un plan para mitigarlos?

· La creación de la arquitectura candidata a partir del desarrollo de un subconjunto clave de requisitos, basados en el modelado de casos de uso.

o         ¿Satisface la arquitectura candidata las necesidades de los usuarios?

o         ¿Es verosímil que funcione?

· La realización de una estimación inicial del coste, esfuerzo, calendario y calidad del producto con límites amplios.

· El inicio del análisis de negocio por el cual el proyecto parece merecer la pena económicamente, una vez más con límites amplios.

La fase de inicio termina con el hito aprobación de los objetivos del proyecto.


Documento de proyecto

El documento de proyecto debe incluir:

· Una visión del nuevo producto.

· Casos de uso, y detalle de los casos de uso más significativos.

· Lista de riesgos.

· Un plan de proyecto para la fase de elaboración.

Opcionalmente, dependiendo de la complejidad del producto se pueden incluir:

· Bosquejo inicial de la arquitectura candidata.

· Versión inicial de los modelos UML (caso de uso, análisis, diseño, despliegue e implementación).

· Lista de características que se desean incluir pero que no encajan en los casos de uso.

· Requisitos adicionales.

· Glosario.


Otros artefactos

Posiblemente, un prototipo exploratorio que muestra el uso del sistema.


Elaboración

Durante la fase de elaboración, se especifican en detalle la mayoría de los casos de uso del producto y se diseña la línea base de la arquitectura del sistema. La relación entre arquitectura del sistema y el propio sistema es primordial. Una manera simple de expresarlo es decir que la arquitectura es análoga al esqueleto cubierto por piel pero muy poco músculo entre los huesos y la piel, sólo el necesario para permitir que el esqueleto haga movimientos básicos. El sistema es el cuerpo entero: con el esqueleto, piel y músculo.

Por tanto, la arquitectura se expresa en forma de vistas de todos los modelos del sistema, los cuales juntos representan al sistema entero. Esto implica que hay casos de uso, análisis, diseño, implementación y despliegue. La implementación incluye componentes para probar que la arquitectura es ejecutable. Durante esta fase, se realizan los casos de uso más críticos que se identificaron en la fase de inicio. El resultado de esta fase es una línea base de la arquitectura.

Al final de esta fase se debe estar en disposición de planificar las actividades y estimar los recursos necesarios para terminar el proyecto. Aquí la cuestión fundamental es:

· ¿Son suficientemente estable los casos de uso, la arquitectura y el plan del proyecto, y están los riesgos suficientemente controlados como para que seamos capaces de comprometernos al desarrollo entero?

En la fase de elaboración, el criterio esencial es la capacidad de construir el sistema dentro de un marco de trabajo económico, que llevamos a cabo mediante:

· La identificación y la reducción de los riesgos que afectan de manera significativa la construcción del sistema.

o         ¿Se han identificados los riesgos significativos?

o         ¿Se han mitigado de forma adecuada los riegos críticos, ya se han eliminado o preparado un plan de emergencia?

o         ¿Son los riesgos que aún permanecen en la lista de riesgos susceptibles de ser eliminados de forma rutinaria en la fase de construcción?

· La especificación de la mayoría de los casos de uso que representan la funcionalidad a desarrollarse.

o         ¿Se han identificados los requisitos, actores y casos de uso necesarios para llegar a la línea base de la arquitectura?

· La extensión de la arquitectura candidata hasta las proporciones de una línea base.

o         ¿Satisface la línea base de la arquitectura no sólo los requisitos recopilados formalmente hasta ahora, sino también las necesidades de todos los usuarios?

o         ¿Parece la línea base de la arquitectura lo suficientemente robusta como para resistir la fase de construcción y la adicción de características que puedan ser necesarias en posteriores versiones del producto?

· La preparación del plan de proyecto con suficiente detalle como para guiar la fase de construcción.

o         ¿Se ha desarrollado lo suficiente como para lograr los objetivos de esta fase?

o         ¿Está el plan del proyecto lo suficientemente definido como para apostar por un precio, agenda y calidad?

· La realización de una estimación con unos límites suficientemente ajustados como para justificar la inversión.

· La terminación del análisis del negocio.

La fase de elaboración termina con el hito aprobación de la línea base de la arquitectura.


Documento de proyecto

El documento de proyecto debe incluir:

· Línea base de la arquitectura y su descripción.

· Especificación de casos de uso actualizada.

· Detalle de la mayoría de los casos de uso.

· Lista de riesgos actualizada.

· Un plan de proyecto para la fase de elaboración.

Opcionalmente, dependiendo de la complejidad del producto se pueden incluir:

· Una revisión de los modelos UML (caso de uso, análisis, diseño, despliegue e implementación).

· Requisitos adicionales actualizado.

· Lista de características actualizada.


Otros artefactos

Debe existir un esqueleto ejecutable de la línea base de la arquitectura.

Opcionalmente, una versión preliminar del manual de usuario.


Construcción

Durante la fase de construcción se crea el producto, se le añade músculo al esqueleto. En esta fase, la línea base de la arquitectura crece hasta convertirse en el sistema completo. La descripción evoluciona hasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios. El grueso de los recursos requeridos para el proyecto se emplea en esta fase. Sin embargo, la arquitectura del sistema es estable, aunque los desarrolladores pueden descubrir formas mejores de estructurar el sistema, ya que los arquitectos recibirán sugerencias de cambios arquitectónicos de menos importancia.

Al final de esta fase, el producto contiene todos los casos de uso que se han acordado con el cliente, pero puede que no este libre de defectos. Muchos de estos defectos se descubrirán y solucionarán durante la siguiente fase. La pregunta decisiva en esta fase es:

· ¿Cubre el producto las necesidades de los usuarios de manera suficiente como para hacer una primera entrega?

En la fase de construcción, el criterio esencial es un sistema capas de una operatividad inicial en el entorno del usuario, y lo llevamos a cabo mediante:

· Una serie de iteraciones, que llevan a incrementos y entregas periódicas, de forma que a lo largo de esta fase, la viabilidad del sistema siempre es evidente en la forma de ejecutables.

· Se preparan una primera versión de los materiales escritos de ayuda y cursos a los usuarios finales, tales como guías de usuario, textos de ayuda, notas de versión, manual de usuario, etc.

o         ¿Son suficientes los materiales de ayuda para dar soporte a los usuarios en la fase de transición?

La fase de construcción termina con el hito finalización del código.


Documento de proyecto

El documento de proyecto debe incluir:

· Una descripción de la arquitectura mínimamente modificada y actualizada.

· Otras actualizaciones y revisiones.

· Un plan de proyecto para la fase de transición.


Otros artefactos

Una versión del sistema ejecutable con capacidad operativa inicial.

Información sobre el despliegue e implantación del producto.

Opcionalmente, una versión preliminar del manual de usuario, lo suficientemente detallado como para guiar a los usuarios betas.


Transición

La fase de transición cubre el periodo durante el cual el producto se convierte en versión beta. En la versión beta un número reducido de usuarios con experiencia prueba el producto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan algunas de las mejoras sugeridas en una nueva versión general dirigida a la totalidad de la comunidad de usuarios.

La fase de transición conlleva actividades como la formación del cliente, el proporcionar una ayuda en línea, asistencia, y la corrección de defectos que se encuentren tras la entrega del producto. El equipo suele dividir esos defectos en dos categorías: los que tienen suficiente impacto en la operación para justificar una versión incrementada y los que pueden corregirse en la siguiente versión del producto.

En la fase de transición, el criterio esencial es un sistema que alcanza una operatividad final, llevado a cabo mediante:

· La corrección de defectos.

o         ¿Han cubierto los usuarios beta las funciones claves, por ejemplo las representadas por todos los casos de uso, relativas a la operación con éxito del producto en el campo de aplicación?

o         ¿Ha superado el producto las pruebas de aceptación realizadas por el cliente?

o         ¿Tiene el material de usuario una calidad aceptable?

o         ¿Esta listo el material de cursos necesarios?

o         ¿Parecen los usuarios y clientes satisfechos con el producto?

La fase de transición termina con el hito versión final del producto.


Documento de proyecto

El documento de proyecto debe incluir:

· Descripción completa y actualizada de la arquitectura.

· Otras actualizaciones y revisiones.


Otros artefactos

El propio software ejecutable, incluyendo el software de instalación.

Documentos legales, como contractos, licencias, renuncias de derechos y garantías.

Manuales y material de formación del usuario final, y si es aplicable de los operadores y de los administradores del sistema.


Documento de proyecto

El documento de proyecto contiene toda la información relevante a un proyecto. Aunque pueden existir otros documentos o artefactos relacionados al proyecto, el documento de proyecto es el único obligatorio a mantener.

Esto documento puede ser tan corto como una simple hoja o tan extenso como sea necesario. Esto lo determina el tipo y alcance de cada proyecto.

Esta sección incluye una descripción de las secciones recomendadas de un documento de proyecto.

También se puede incluir una sección con los términos específicos del proyecto (Glosario) .


Visión

La sección de visión contiene los requisitos desde el punto de vista del usuario final. Incluye una descripción de los usuarios y las características esperadas del producto.

Cuando se tiene una línea base del documento de visión, se ha llegado a un acuerdo con el cliente sobre las principales características del producto.


Casos de uso

La sección de casos de uso contiene una descripción de cada de caso de uso. Se incluye su flujo fundamental, flujos alternativos, el actor que lo ejecuta.


Lista de riesgos

La sección de lista de riesgo contiene una lista de todos los riesgos detectados e información adicional sobre los mismos.


Arquitectura

La sección de arquitectura describe desde el punto de vista arquitectónico el producto.

Para la descripción de la arquitectura se puede utilizar en lo posible modelos UML.

Si no se utilizan modelos UML, se describirán los módulos principales, las interfaces y la interrelación entre los módulos. Se puede incluirá una sección de referencia con la especificación de las interfaces.


Plan de proyecto

La sección de plan de proyecto describe el cronograma total de ejecución, y contiene secciones para cada una de las iteraciones.

Cada iteración tiene una sección en el documento de proyecto que describir los objetivos esperados, el tiempo estimado, casos de uso que implementa, riesgos que mitigan y una evaluación final.


Control de calidad

Para el control de calidad del software desarrollado se utilizara un enfoque basado en unidades de prueba.

La creación unidades de prueba tiene beneficios, entre otros:

1. Las unidades de prueba documentan el código. Al ver el código fuente de las unidades de prueba se tiene ejemplo de utilización del código y como este funciona. Normalmente las unidades de prueba incluyen casos típicos de la utilización con componente que se prueba.

2. Las unidades de prueba indican los fallos. Al realizar cualquier cambio en un componente, por muy trivial que sea, se pueden introducir errores. Al ejecutar las unidades de prueba se detectan los fallos lo antes posible, y no en fases posteriores.

Se utilizara la herramienta NUnit, actualmente la versión 2.1, para crear las unidades de prueba de cada componente de código desarrollado.


Proyecto de prueba

Para cada proyecto desarrollado debe existir un proyecto de prueba con todas las unidades de prueba, para crear el proyecto de prueba siga los siguientes pasos:

1. Agregue un nuevo proyecto a la solución.

a. Seleccione un proyecto Biblioteca de clases, la ubicación debe ser la carpeta del proyecto original y su nombre coincidir con el nombre del proyecto origina agregando el sufijo Tests.

b. Por ejemplo, para el proyecto Bizion.Base que se encuentra en la carpeta C:\Projects\Bizion\Bizion.Base, la ubicación del proyecto de prueba es C:\Projects\Bizion\Bizion.Base, y su nombre Bizion.Base.Tests.

2. Agregue una referencia al proyecto original y una referencia al marco de trabajo de NUnit.

a. La referencia al proyecto original se agrega seleccionado en la ficha Proyectos del cuadro de diálogo Agregar referencia el proyecto original.

b. La referencia al marco de trabajo de NUnit se agrega en la ficha .NET del cuadro de diálogo Agregar referencia, haciendo clic en el botón Examinar..., y seleccionado el archivo nunit.framework.dll que se encuentra en la carpeta bin dentro de la carpeta en la que instalo NUnit.

3. Especifique la aplicación de inicio del proyecto de prueba.

a. En las propiedades del proyecto de prueba, en la configuración Debug, seleccione Propiedades de configuración, luego Depuración y en Aplicación de inicio especifique el camino completo a la interfaz de usuario de NUnit, archivo nunit-gui.exe. Por defecto este archivo se encuentra en la carpeta bin dentro de la carpeta en la que instalo NUnit.


Unidad de prueba

Una unidad de prueba en una clase que utiliza el marco de trabajo de NUnit en la implementación de la prueba, para crear una unidad de prueba siga los siguientes pasos:

1. Agregue una clase al proyecto de prueba.

a. El nombre de la case debe comenzar con el nombre del componente que se prueba con el sufijo Tests, por ejemplo, la unidad de prueba de Workspace se debe llamar WorkspaceTests.

2. Incluya el espacio de nombres NUnit.Framework en el archivo de la clase.

3. Marque la clase como una unidad de prueba agregando el atributo TestFixture.

4. Agregue un constructor publico por defecto (constructor publico sin parámetro).

5. Agregue los métodos específicos de la infraestructura de prueba, estos métodos se marcan con los siguientes atributos:

a. Test: Método que implementa una prueba (caso de prueba). La prueba debe ser atómica y no depender de otras pruebas.

b. SetUp, TearDown: Métodos inicialización y terminación de las pruebas (caso de prueba). Se ejecutan antes (SetUp) y después (TearDown) de cada prueba.

c. TestFixtureSetUp, TestFixtureTearDown: Métodos para inicialización y terminación de la unidad de prueba. Se ejecutan antes (TestFixtureSetUp) de la primera prueba (caso de prueba) y después (TestFixtureTearDown) de la ultima prueba (caso de prueba).

6. Escribir las pruebas (casos de prueba).

a. Utilizar los métodos del objeto Assert de NUint para controlar las aserciones.

b. Iniciar excepciones con información especifica en caso de detectar un error.


Glosario

Artefacto

Un artefacto es un término general para referirse a cualquier tipo de información creada, producida, cambiada o utilizada en el desarrollo del producto de software.

Lista de características

Lista de ideas sugeridas por clientes, usuarios y desarrolladores que podrían convertirse en requisitos. Esta lista puede contener requisitos que no se implementan en la versión actual del producto, pero sirve como referencia para versiones futuras.

Requisitos adicionales

Lista de requisitos adicionales, normalmente requisitos no funcionales que no pueden asociarse a ningún caso de uso en particular.