Modelos de Proceso del Software

Instituto Tecnológico de Morelia

4. Modelos de Proceso del Software
El proceso es el conocimiento incorporado, y puesto que el conocimiento esta inicialmente disperso, el desarrollo de software implícito, latente e incompleto en gran medida es un proceso social de aprendizaje. El proceso es un dialogo en el que se reúne el conocimiento y se incluye en el software para convertirse en software. El proceso proporciona una iteración entre los usuarios y los diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramientas de desarrollo (tecnología). Es un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicación, con cada iteración del dialogo se obtiene mayor conocimiento.

Howard Baetjer

Desde un punto de vista técnico se puede decir que el proceso de software es un marco de trabajo de las tareas que se requieren para construir software de alta calidad.
Aun más importante es que la Ingeniería del Software la realizan personas creativas, con conocimiento, que deberían trabajar dentro de un proceso del software definido y avanzado que es apropiado para los productos que construyen y para las demandas de su mercado.
4.1 Modelo de cascada [4]
Modelo de Cascada (Bennington 1956, Modificado por Royce en 1970, Pressman lo presenta como ciclo de vida clásico). Se denomina modelo en cascada porque su característica principal es que no se comienza con un paso hasta que no se ha terminado el anterior. El modelo en Cascada establece que el software debe ser construido, rigurosamente, a través de una transformación sucesiva de documentos, siguiendo una estrategia lineal de desarrollo. Primero saber qué se quiere y después, cuando se conozca todo lo que se quiere, empezar a construirlo.

El modelo de cascada también conocido como modelo lineal secuencial sugiere un enfoque sistemático, secuencial para el desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

A grandes rasgos el primer paso es conseguir un documento con la especificación completa, exacta, no ambigua de los requisitos del sistema software que debe ser desarrollado. Este documento inicial es transformado en un documento de análisis, supuestamente alejado de la máquina. Después, a partir del análisis, se obtiene otro documento, el diseño. Y por último, del diseño se obtiene el documento final: el código. Para asegurar que no se introducen equivocaciones al transformar un documento (modelo) en otro, se hacen pruebas, al terminar cada uno. Las pruebas son planificadas desde el principio y se documentan como se vayan realizando. Antes de la entrega del sistema software, se valida que satisface los requisitos definidos en el documento inicial.
Está basado en el ciclo convencional de una ingeniería, tiene las siguientes actividades que se muestran en la figura 4.1 del modelo de cascada:



4.1.1 Actividades




Ingeniería y Análisis del Sistema
Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.
Análisis de los requisitos del software
Análisis: Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (Documento de Especificación de Requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos (debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas). [4]
Diseño
El diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. [4]
Codificación
Es la fase de programación. Aquí se desarrolla el código fuente, el diseño debe traducirse en una forma legible para la maquina, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente. [4]
Prueba
Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Se comprueba que funciona correctamente antes de ser puesto en explotación. [4]
Mantenimiento
El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán cuando se hayan encontrado errores, esto en lugar de que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. [4]
Desventajas

• 
  Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.
  
• 
  Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.
  
• 
  El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.
  

Se tiene un Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño. Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida

Este modelo, que se lleva a cabo de forma descendente, exige que para pasar a la siguiente fase hay que concluir correctamente la anterior, de manera que los posibles errores sean fácilmente detectables. Así, la salida de una fase es la entrada de la siguiente.
La Ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.
4.2 Modelo de espiral
El modelo espiral propuesto originalmente por Boehm en 1988, es un modelo de proceso de software evolutivo ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En este modelo el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. En las últimas iteraciones, se producen versiones cada vez mas completas del sistema diseñado.

El modelo representado mediante la espiral de la figura 4.2 define cuatro actividades principales, también llamadas regiones de tareas o sectores:

1. 
   Planificación. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente.[1]
   
2. 
   Análisis de riesgo. El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. [1]
   
3. 
   Ingeniería. En este sector se desarrolla y se valida. Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema.[1]
   
4. 
   Evaluación del cliente. El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir".[1]
   

Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completas y, al final, el propio sistema operacional.

De acuerdo con Sommerville Un ciclo en espiral inicia con la elaboración de objetivos, como el rendimiento y la funcionalidad. Después se enumeran formas alternativas de alcanzar estos objetivos y las restricciones impuestas en cada una de ellas. Cada alternativa se evalúa contra cada objetivo y se identifican las fuentes de riesgo del proyecto. Lo siguiente es resolver los riesgos mediante actividades de recopilación de información como la de detallar más el análisis, la construcción de prototipos y la simulación. Ya que se evaluaron los riesgos, se lleva a cabo cierto desarrollo, seguido de una actividad de planificación para la siguiente fase.
El paradigma del modelo en espiral para la Ingeniería de Software es actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.


4.3 Modelo incremental [2]

El modelo incremental aplica secuencias lineales de forma escalonada mientras avanza el tiempo. Corrige la necesidad de una secuencia no lineal de pasos de desarrollo. Cada secuencia lineal produce un incremento del software. Por ejemplo, el software de tratamiento de textos desarrollado con el paradigma incremental podría extraer funciones de gestión de archivos básicos y de producción de documentos en el primer incremento; funciones de edición mas sofisticadas y de producción de documentos en el segundo incremento; corrección ortográfica y gramatical en el tercero; y una función avanzada de esquema de pagina en el cuarto. Se debería tener en cuenta que el flujo del proceso de cualquier incremento pude incorporar el paradigma de construcción de prototipos.

El modelo incremental entrega el software en partes pequeñas, pero utilizables, llamadas “incrementos”. En general, cada incremento se construye sobre aquel que ya ha sido entregado. [2]
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión detalla). Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y características adicionales. Este proceso se repite siguiendo la entrega de cada incremento. Hasta que se elabore el producto completo.
El modelo de proceso incremental, como la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primero incrementos son versiones “incompletas” del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.
El desarrollo incremental es particularmente útil cuando el personal no esta disponible para una implementación completa en la fecha límite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas.
Este modelo constituyo un avance sobre el modelo en cascada pero también presenta problemas. Aunque permite el cambio continuo de requisitos, aun existe el problema de determinar si los requisitos propuestos son validos. Los errores en los requisitos se presentan tarde y su corrección resulta tan costosa como en el modelo en cascada.
4.4 Proceso de desarrollo unificado [18]

Es un modelo complejo con mucha terminología propia, pensado principalmente para el desarrollo de grandes proyectos. Es un proceso que puede adaptarse y extenderse en función de las necesidades de cada empresa. Es el resultado de esfuerzo de las tres últimas décadas en desarrollo de software y de la experiencia de sus creadores Ivar Jacobson, Grady Booch y James Rumbaugh.

4.4.1 Orígenes
El antecedente más importante lo ubicamos en 1967 con la Metodología Ericsson

(Ericsson Approach), ésta es una aproximación de desarrollo basada en componentes, que introdujo el concepto de caso de uso; entre los años de 1987 a 1995 Jacobson funda la compañía “Objectory AB” y lanza el proceso de desarrollo Objectory (abreviación de Object Factory), posteriormente en 1995 “Rational Software Corporation” adquiere “Objectory AB” y es entre 1995 y 1997 que se desarrolla “Rational Objectory Process (ROP)” fruto del encuentro y evolución de Objectory 3.8 y la Metodología Rational (Rational Approach) que adopta por primera vez UML como lenguaje de modelamiento. [16]

A principios de los noventas, la guerra de los métodos hizo evidente la necesidad de unificar criterios, es así como Grady Booch autor del método Booch y James Rumbaugh (desarrollador para General Electric) se unieron en Rational en 1994, después en 1995 se une Jacobson y gracias al esfuerzo de varias compañías y metodologistas evolucionó UML hasta ser un estándar en 1997, el cual es adoptado en todos los modelos del ROP. Desde ese entonces y a la cabeza de Booch, Jacobson y Rumbaugh, Rational ha desarrollado e incorporado diversos elementos para expandir el ROP, destacándose especialmente el flujo de trabajo conocido como modelamiento del negocio, es así como en junio del 1998 se lanza Rational Unified Process 5.0. La evolución y orígenes de este proceso de desarrollo se puede visualizar mejor en la figura 2.1 [16]
4.4.2 Características del Proceso Unificado de Desarrollo
El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qué producto se debe producir, cómo desarrollar lo que vamos a entregar y también provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas.
El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes de software interconectados a través de interfaces bien definidas. Además, el Proceso Unificado utiliza el UML para expresar gráficamente todos los esquemas de un sistema de software. Pero, realmente, las características que definen este Proceso Unificado son tres: Iterativo e Incremental, Dirigido por casos de uso y Centrado en la Arquitectura.
4.4.2.1 Dirigido por casos de uso
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema. [17]
Basándose en los casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo. Además, estos modelos se validan para que sean conforme a los casos de uso. Finalmente, los casos de uso se usan para realizar los casos de pruebas sobre los componentes desarrollados. Los casos de uso no solo inician el proceso, sino que también proporcionan un hilo conductor en todo el ciclo de vida del desarrollo de software.
En conclusión los casos de uso son utilizados para:

• 
  Establecer el comportamiento deseado del sistema
  
• 
  Verificar y validar la arquitectura del sistema
  
• 
  Hacer Pruebas
  
• 
  Tener una comunicación entre los participantes del proyecto
  

4.4.2.2 Centrado en la arquitectura

La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción.

Arquitectura: 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, las interfaces entre ellos, su comportamiento, sus colaboraciones, y su composición. [17]
El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema.
La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado.
Los casos de uso y la arquitectura están profundamente relacionados. Los casos de uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y a futuro. El arquitecto desarrolla la forma o arquitectura a partir de la comprensión de un conjunto reducido de casos de uso fundamentales o críticos (usualmente no mas del 10 % del total). El arquitecto:

• 
  Crea un esquema en borrador de la arquitectura comenzando por la parte no específica de los casos de uso (por ejemplo la plataforma) pero con una comprensión general de los casos de uso fundamentales.
  
• 
  Enseguida, trabaja con un conjunto de casos de uso clave o fundamental. Cada caso de uso es especificado en detalle y realizado en términos de subsistemas, clases, y componentes.
  
• 
  A medida que los casos de uso se especifican y maduran, se descubre más de la arquitectura, y esto a su vez lleva a la maduración de más casos de uso.
  

Este proceso continúa hasta que se considere que la arquitectura es estable.

4.4.2.3 Iterativo e incremental

Todo sistema complejo supone un gran esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto en varias fases o mini proyectos.

Una iteración es un bucle de desarrollo completo, es una secuencia de actividades con un plan establecido y criterios de evaluación. Acaba en la edición de un producto ejecutable, subconjunto del producto final bajo desarrollo.
Se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido por las fases se denomina Iteración en el proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Cada iteración parte de la anterior incrementado (crece el producto) o revisando la funcionalidad implementada. Los desarrolladores basan la selección de lo que implementarán en cada iteración en dos cosas: el conjunto de casos de uso que amplían la funcionalidad, y en los riesgos más importantes que deben mitigarse. Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de una forma planificada.
Los beneficios de este enfoque iterativo son:

• 
  La iteración controlada reduce el riesgo a los costos de un solo incremento.
  
• 
  Reduce el riesgo de retrasos en el calendario atacando los riesgos más importantes primero.
  
• 
  Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener resultados a corto plazo.
  
• 
  Tiene un enfoque más realista al reconocer que los requisitos no pueden definirse completamente al principio.
  

4.4.2.4 Basado en componentes
La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta característica en un proceso de desarrollo, permite que el sistema se vaya creando a medida que se obtienen o que se desarrolla y maduran sus componentes.
Un componente, es una parte del sistema, física y reemplazable, que está sujeto á, y proporciona la implementación de un conjunto de interfaces.
El desarrollo basado en componentes consiste en la creación e implantación de sistemas de software complejos, ensamblados a partir de componentes, y que ponen a la vez nuevos componentes a disposición de otros sistemas. Puede automatizarse mediante herramientas y procesos, que permiten aumentar la productividad, calidad y tiempo de desarrollo.
4.4.3 Ciclo de vida

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versión del sistema.

4.4.3.1 Fases

Cada ciclo consta de cuatro fases: inicio, elaboración, construcción, y transición:

• 
  Inicio: Definición del proyecto.
  
• 
  Elaboración: Planificación del proyecto, especificación de características y elaborar arquitectura base.
  
• 
  Construcción: Construcción del sistema.
  
• 
  Transición: Transición a usuarios
  

Iteraciones dentro del ciclo de vida. Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.

4.4.3.2 Disciplinas

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área específica dentro del proyecto total. Las más importantes son: Requerimientos, Análisis, Diseño, Codificación, y Prueba.

El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visión tradicional en cascada.
Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos. Los artefactos más importantes son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseño, modelo de implementación, y modelo de prueba.
El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos desde el modelo de casos de uso hasta el modelo de pruebas.
4.4.3.3 Hitos
Cada fase finaliza con un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos (RUP llama artefactos a un subproducto), es decir un conjunto de modelos o documentos que han sido desarrollados hasta alcanzar un estado predefinido.
Los hitos tienen muchos objetivos. El más crítico es que los encargados del proyecto deben tomar ciertas decisiones antes de que el trabajo continúe con la siguiente fase. Los hitos también permiten controlar la dirección y progreso del trabajo. Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumidos en cada fase. Estos datos son útiles para la estimación en futuros proyectos.
4.4.3.4 Artefactos
Dentro del Proceso de Desarrollo Unificado se denomina artefacto a todo producto o subproducto resultante del proceso. Dentro de esto se encuentra desde el propio código fuente hasta la documentación aportada por el cliente y la entregada al completarse cada hito dentro del proyecto. Para su mejor comprensión hemos agrupado todos los artefactos posibles del proceso en tres grandes grupos: Artefactos entregados por el cliente, Artefactos internos del proceso y Artefactos entregables al cliente.
No siempre en todo proyecto se crean los mismos artefactos, esto dependerá de las características del proyecto y los requisitos del cliente, siendo tarea de la gestión de la configuración el definir qué artefactos específicos y con qué nivel de formalidad se crearán para el proyecto en cuestión.
4.4.3.4.1 Artefactos entregados por el cliente

• 
  Glosario de Términos: Sólo existe uno para todo el sistema, que contiene un conjunto de definiciones concisas para favorecer la comunicación y evitar malos entendidos entre todos los involucrados. Los miembros del proyecto utilizarán el glosario inicialmente para comprender sus términos específicos.
  
• 
  Especificaciones de los casos de uso: Es una colección de documentos que recogen la especificación completa de cada caso de uso. Cada uno contiene los campos: nombre, descripción, actores, precondiciones, postcondiciones, flujo básico, flujos alternativos, puntos de extensión, entre otros que describen en detalle un caso de uso.
  
• 
  Modelo de casos de uso: Es un modelo de las funciones concebidas del sistema y su entorno. Es una entrada importante a actividades de análisis, diseño y prueba. Incluye todos los actores y casos de uso del sistema con sus descripciones. Puede ser entregado directamente en el formato que utilice la herramienta de modelación o gestión empleada, o mediante un informe de este modelo que contenga toda esta información que se complementará con las Especificaciones de los casos de uso.
  
• 
  Especificaciones suplementarias: Este artefacto captura los requerimientos del sistema que no fueron recogidos en el Modelo de casos de uso. Generalmente contiene los requerimientos no funcionales del sistema.
  
• 
  Especificación de requisitos del software: En los casos en que la empresa cliente no desee utilizar el enfoque de casos de uso para la gestión de requisitos, podrá entregar en lugar de los 3 artefactos descritos anteriormente un solo documento que recoja las características, requisitos funcionales y no funcionales del sistema, así como otra información útil como por ejemplo: restricciones en el diseño e implementación, componentes comprados a terceros, interfases de hardware o software, etc.
  
• 
  Documento de arquitectura del software: Este documento brinda un resumen de la arquitectura utilizando varias vistas diferentes que muestran distintos aspectos del sistema. Es un medio de comunicación entre el arquitecto de software y otros miembros del equipo del proyecto, acerca de las decisiones significativas que han sido tomadas para la arquitectura.
  
• 
  Modelo de diseño: Es una abstracción de la implementación del sistema que normalmente se utiliza para concebir y documentar su diseño. Es un artefacto compuesto que contiene todas las clases, subsistemas, paquetes, colaboraciones y las relaciones entre ellas. También contiene las realizaciones de los casos de uso.
  
• 
  Modelo de datos: Describe la representación física y lógica de los datos persistentes utilizados por la aplicación. Se utilizará siempre que se necesiten manejar datos persistentes. Usualmente describirá los diferentes elementos componentes de la estructura de una base de datos relacional.
  
• 
  Mapa de navegación: Expresa la estructura de los elementos de la interfaz de usuario del sistema, junto a los caminos de navegación principales. Existirá solamente uno de estos artefactos en el sistema y por lo general será empleado para aplicaciones Web.
  
• 
  Prototipo de la interfaz de usuario: Es un ejemplo de la interfaz de usuario que se construye para validar y/o explorar su diseño. El grado de formalidad y herramientas utilizadas para generarlo puede variar mucho de proyecto en proyecto, pudiendo ir desde solo unas cuantas imágenes de pantallas hasta un esqueleto de interfaz de usuario ejecutable producido en un ambiente de Desarrollo rápido de aplicaciones (RAD : Rapid Application Development) o un conjunto de páginas HTML interactivas. En aplicaciones Web pueden ser las imágenes de las diferentes pantallas creadas por el diseñador gráfico.
  

4.4.3.4.2 Artefactos Internos del Proceso

• 
  Plan de gestión de requisitos: Describe los artefactos de la disciplina, tipos de requisitos y sus respectivos atributos. Especifica la información que deberá ser obtenida y los mecanismos de control que deberán ser utilizados para reportar, medir, y controlar los cambios a los requisitos del producto.
  
• 
  Plan de pruebas: Contiene la definición de los objetivos de las pruebas, los elementos que deberán ser probados, los métodos que deberán utilizarse, los recursos necesarios y documentos a entregar. Usualmente se tiene uno de estos documentos con alcance global para todo el proyecto y uno por cada iteración del ciclo de vida del producto.
  
• 
  Guión de pruebas: Son las instrucciones paso a paso que indican como llevar a cabo una prueba. Pueden ser documentos con información textual que describa cómo realizar la prueba manualmente o archivos de instrucciones legibles por las máquinas que posibiliten la ejecución automatizada de la prueba.
  
• 
  Informe resumen de las pruebas: Organiza y muestra un análisis resumido de los resultados de las pruebas que será entregado a los miembros del equipo de calidad para su revisión y evaluación. Adicionalmente puede contener un enunciado general de la calidad relativa y ofrecer recomendaciones para futuros esfuerzos de prueba.
  
• 
  Plan de gestión de configuración: Describe todas las actividades de Gestión de configuración y cambios que serán realizadas durante todo el ciclo de vida del proyecto. Brinda planificaciones detalladas de las actividades, responsabilidades asignadas, recursos necesarios que incluyen personal, herramientas y equipamiento.
  
• 
  Solicitud de cambio: Los cambios a los artefactos del proyecto se proponen mediante Solicitudes de cambio (Change Requests CR). Estos se utilizan para documentar y controlar defectos, solicitudes de mejoras o cualquier otra solicitud de cambios al proyecto. El beneficio de utilizarlos es que proporcionan un registro de las decisiones y, debido a su proceso evaluativo, se asegura que los impactos de los cambios sean entendidos por todos los miembros del equipo del proyecto.
  
• 
  Plan de desarrollo de software: Es un artefacto compuesto que recoge toda la información necesaria para llevar a cabo la dirección del proyecto. Contiene otros planes no menos importantes que, al igual que éste son desarrollados desde la fase de inicio y mantenidos durante todo el ciclo de vida (Aseguramiento de la calidad, Gestión de riesgos, Métricas, Aceptación del producto y Resolución de problemas).
  
• 
  Plan de la iteración: Es un plan más refinado que contiene un conjunto secuencial de actividades, tareas y recursos asignados a una iteración, por lo que existirá un artefacto de este tipo por cada iteración del ciclo de vida del producto. Incluye los objetivos de la iteración, que son utilizados como criterio de evaluación y miden diferentes aspectos deseables a su final, como grado de terminación de la funcionalidad planificada, niveles de calidad, rendimiento, etc.
  
• 
  Evaluación de la iteración: Se realiza al final de la iteración y captura el grado en que se cumplió el criterio de evaluación, las lecciones aprendidas y los cambios a realizar en la planificación de las subsiguientes iteraciones en función del nuevo conocimiento adquirido. Es un artefacto esencial del enfoque iterativo de desarrollo de software.
  
• 
  Proceso de desarrollo: También conocido como Proceso específico del proyecto, es una configuración del Proceso Unificado de Rational (RUP) para ajustarse a las necesidades del proyecto. Es un artefacto compuesto que contiene: el Caso de desarrollo, plantillas y normativas para el proyecto.
  

4.4.3.4.3 Artefactos entregables al cliente

• 
  Modelo de implementación: Representa la composición física de la implementación, está constituido por subsistemas y elementos de implementación (directorios y ficheros, incluyendo los de código fuente, datos y ejecutables).
  
• 
  Informe de entrega al cliente: Contendrá una descripción detallada de la estructura de directorios del paquete entregado, instrucciones para la instalación, errores conocidos y cambios realizados en la versión actual del sistema, subsistema o componente implementado. Adicionalmente incluirá cualquier otra información que sea considerada relevante referida al modelo de implementación o los artefactos contenidos en la entrega al cliente.
  
• 
  Documentación de soporte: En función de las características del proyecto, se entregará también la documentación técnica del sistema, subsistema o componente de software implementado, que podrá ser usada posteriormente para su mantenimiento o modificación por parte de otro equipo de desarrollo. Adicionalmente serán entregados los manuales necesarios para el soporte al usuario final.
  

4.4.3.5 Inicio

Su meta principal es lograr el consenso de todos los involucrados acerca de los objetivos del ciclo de vida del proyecto. Es muy importante especialmente en proyectos nuevos en que existen riesgos significativos en el negocio o la implementación de los requisitos, y deben ser solucionados para que el proyecto proceda.

Para los proyectos que se enfocan en mejorar sistemas existentes, esta fase es más breve, pero aún así centrada en asegurar que el proyecto vale la pena y se puede realizar.

Objetivos

• 
  Establecer el alcance y fronteras del software del proyecto, incluyendo la visión operacional, criterio de aceptación, qué se espera que esté en el producto y qué no.
  
• 
  Discriminar los casos de uso críticos del sistema, los escenarios primarios de operación que dirigirán las principales decisiones de diseño.
  
• 
  Mostrar al menos una arquitectura candidata para alguno de los escenarios primarios.
  
• 
  Estimar el costo global y planificación para el proyecto completo (estimaciones más precisas se obtendrán en la fase siguiente).
  
• 
  Estimar los riesgos potenciales.
  
• 
  Preparar el ambiente de soporte al proyecto
  

Actividades

• 
  Formular el alcance del proyecto.
  
• 
  Planificar y preparar el caso de negocio.
  
• 
  Sintetizar una arquitectura candidata.
  
• 
  Preparar el ambiente del proyecto: evaluar el proyecto y la organización, seleccionar las herramientas, decidir qué partes del proceso mejorar.
  

Hito
Establecer el ámbito del producto, la identificación de los principales riesgos y la viabilidad del proyecto.
4.4.3.6 Elaboración
El propósito de la etapa de Elaboración es crear la línea base de la arquitectura del software para así disponer de unos cimientos sólidos sobre los que se basará el grueso del esfuerzo de diseño e implementación durante la siguiente fase de Construcción. En la definición de la línea base de la arquitectura se incluyen los requisitos más significativos (aquéllos que tienen un mayor impacto sobre la arquitectura del sistema), y los componentes de mayor riesgo para el sistema. Para evaluar la estabilidad de la arquitectura se emplean prototipos evolutivos de la arquitectura.
Objetivos

• 
  Asegurar que la arquitectura, requisitos y planes son lo suficientemente estables y los riesgos han sido mitigados lo suficiente para poder determinar los costos y planificación necesarios para completar el desarrollo.
  
• 
  Solucionar todos los riesgos significativos para la arquitectura del proyecto.
  
• 
  Establecer la línea base de la arquitectura obtenida después de tratar los escenarios más significativos para la arquitectura, que por lo general muestra los mayores riesgos técnicos del proyecto.
  
• 
  Producir un prototipo progresivo de componentes con calidad para la producción, así como también algunos prototipos desechables exploratorios donde se mitigan riesgos específicos, como por ejemplo: Soluciones de compromiso en el diseño, reutilización de componentes, factibilidad del producto, o demostraciones a inversores, clientes y usuarios finales
  
• 
  Demostrar que la arquitectura incluida en la línea base respaldará los requisitos del sistema a un costo y tiempo razonables.
  
• 
  Establecer el ambiente de soporte para el proyecto. Esto incluye crear los planes de desarrollo, preparar las plantillas de los documentos, instrucciones, y herramientas
  

Actividades

• 
  Definir, validar y añadir la arquitectura a la línea base.
  
• 
  Refinar la Visión basándose en información nueva obtenida durante la fase.
  
• 
  Crear y añadir a la línea base planes de iteración detallados para la fase de construcción.
  
• 
  Refinar los planes de desarrollo y ponerlos en práctica en el ambiente de desarrollo.
  
• 
  Refinar la arquitectura y seleccionar componentes.
  

Hito
Obtener una línea base de la arquitectura del sistema, capturar la mayoría de los requisitos y reducir los riesgos principales así como permitir la escalabilidad del equipo del proyecto durante la fase de construcción.
4.4.3.7 Construcción
En esta fase se documentan los requisitos restantes y se completa el desarrollo del sistema basándose en la arquitectura que se ha sido añadida a la línea base. La Construcción es un proceso de fabricación donde se hace énfasis en la administración de los recursos y el control de operaciones para optimizar costos, el tiempo dedicado, y la calidad del producto. En este sentido la administración experimenta una transición del desarrollo de propiedad intelectual durante las fases de Inicio y Elaboración, al desarrollo de productos instalables durante la Construcción y Transición.
Objetivos

• 
  Minimizar los costos de desarrollo optimizando los recursos y evitando cambios innecesarios que resulten en desechar o modificar trabajo ya realizado.
  
• 
  Obtener una calidad apropiada tan rápido como sea posible.
  
• 
  Obtener versiones útiles (alfa, beta, y otras entregas de prueba) tan rápido como sea posible.
  
• 
  Completar el análisis, diseño, desarrollo y prueba de toda la funcionalidad requerida.
  
• 
  Desarrollar de forma iterativa e incremental un producto completo que esté listo para su transición hacia la comunidad de usuarios. Esto implica detallar los casos de uso restantes y otros requisitos así como completar el diseño, implementación y prueba del software.
  
• 
  Decidir si el software, sitio y usuarios están listos para la instalación de la aplicación.
  
• 
  Alcanzar algún grado de paralelismo en el trabajo de los equipos. Hasta en los proyectos más pequeños existen componentes que pueden ser desarrollados de forma independiente entre ellos, permitiendo un paralelismo natural entre los equipos. Este paralelismo puede acelerar significativamente el desarrollo de actividades.
  

Actividades

• 
  Administración de recursos, control y optimización del proceso.
  
• 
  Desarrollo y prueba completa de los componentes utilizando el criterio de evaluación definido.
  
• 
  Evaluación de las entregas del producto utilizando los criterios de aceptación de la Visión.
  

Hito
Podemos decir que se alcanza el hito principal de la fase cuando hemos conseguido desarrollar el sistema con calidad de producción, y puede entonces prepararse para la entrega al equipo de transición. En esta fase, toda la funcionalidad ha sido implementada, y completadas las pruebas para el estado alfa de la aplicación.

4.4.3.8 Transición
En esta fase la atención se enfoca en asegurar que el software está disponible para los usuarios finales. Puede extenderse a varias iteraciones, e incluye las pruebas del producto como parte de su preparación para ser entregado, y la realización de ajustes menores en respuesta a la retroalimentación recibida de los usuarios. En este punto del ciclo de vida la retroalimentación de los usuarios debe enfocarse fundamentalmente a ajustes específicos y de corto alcance al producto, junto a otros temas como configuración, instalación, y usabilidad. Referencias a otros ajustes estructurales mayores habrán sido solucionadas anteriormente en el ciclo de vida y serán documentadas para futuras generaciones del software.
Al final de la fase de Transición los objetivos del ciclo de vida se han cumplido, y el proyecto está listo para cerrarse. En algunos casos el final de este ciclo coincide con el inicio de otro ciclo en el mismo proyecto, encaminándose a la siguiente generación o versión del producto. Para otros proyectos el final de esta fase puede coincidir con la entrega completa de los productos (aplicaciones) y subproductos (documentación) a terceros que pudieran ser responsables de la operación, mantenimientos, y mejoras al sistema entregado. Esta fase de transición puede variar de muy sencilla a extremadamente compleja, dependiendo del tipo de producto.
Esta etapa comienza cuando la línea base está lo suficientemente madura como para realizar una entrega al dominio de los usuarios finales. Esto por lo general requiere que se haya completado un subconjunto usable del sistema con un nivel de calidad aceptable y documentación de usuario de modo que la transición produzca resultados positivos para todas las partes.
Objetivos

• 
  Realizar pruebas de estadio beta para validar el nuevo sistema con las expectativas de los usuarios.
  
• 
  Realizar pruebas de estadio beta y la operación en paralelo al sistema anterior que se está reemplazando.
  
• 
  Entrenamiento de usuarios y encargados del mantenimiento.
  
• 
  Salida a comerciales, distribución y ventas.
  
• 
  Ingeniería específica de instalación: comercialización y producción de los paquetes, etc.
  
• 
  Actividades de corrección de errores, mejoras en el funcionamiento y rendimiento y usabilidad.
  
• 
  Evaluación de la línea base de la instalación con la visión completa y criterios de la aceptación del producto.
  
• 
  Lograr el consenso de los involucrados en que la línea base está completa.
  
• 
  Lograr el consenso de los involucrados en que la línea base es consistente con el criterio de evaluación de la visión.
  

Actividades

• 
  Ejecutar los planes de instalación.
  
• 
  Completar el material de soporte de los usuarios finales.
  
• 
  Pruebas del producto en el sitio de desarrollo.
  
• 
  Preparar la entrega de esta versión del producto.
  
• 
  Recoger la retroalimentación de los usuarios.
  
• 
  Hacer ajustes finos al producto basándose en la retroalimentación de los usuarios.
  
• 
  Hacer disponible el producto para los usuarios finales.
  

Hito
Al finalizar esta fase se decide si los objetivos se cumplieron y si debe comenzarse otro ciclo de desarrollo. Es el resultado de la revisión y aceptación por parte del cliente de los productos y subproductos que le han sido entregados.

4.5 Proceso Software Personal.
El Proceso Personal del Software (PSP) es un sistema estructurado de descripciones, de medidas, y de los métodos de proceso que pueden ayudar a ingenieros a mejorar su actividad personal.
El PSP fue definido por Watts S. Humphrey del Software Engineering Institute (SEI) en la Carnegie Mellon University.
4.5.1 Principios del Proceso de Software Personal [15]

• 
  Cada ingeniero es diferente; para ser más eficiente, debe planificar su trabajo basándose en datos tomados de su propia trayectoria profesional.
  
• 
  Para mejorar auténticamente su trabajo, los ingenieros deben usar procesos personales bien definidos y cuantificados.
  
• 
  Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos. Los buenos productos no se obtienen por azar, sino como son secuencia de un esfuerzo positivo para hacer un trabajo de calidad.
  
• 
  Cuanto antes se detecten y corrijan los defectos menos esfuerzo será necesario.
  
• 
  Es mas efectivo evitar los defectos que detectarlos y corregirlos.
  
• 
  Trabajar bien es siempre la forma más rápida y económica de trabajar.
  

El PSP Cubre los siguientes aspectos como:

• 
  Definición de procesos
  
• 
  Medida de la calidad
  
• 
  Medida de la productividad.
  

Es un acercamiento general que se puede utilizar en casi cualquier parte del proceso del software.

El costo personal de un PSP, es el tiempo que se requiere para aprender y para usarlo, el costo emocional de tener una disciplina necesaria y el riesgo potencial a su ego.
Los beneficios del PSP:

• 
  Habilidades y talentos obtenidos
  
• 
  El estímulo de una corriente casi ilimitada de ideas
  
• 
  El marco que proporciona para la mejora personal
  
• 
  El grado de control se gana sobre el trabajo
  
• 
  La sensación del orgullo y de la realización
  
• 
  Una base mejorada para el trabajo en equipo eficaz
  
• 
  La seguridad para hacer el trabajo la manera que usted sabe que usted debe.
  

4.5.2 PSP0 Línea Base [15]

Establece una línea de medida del progreso y para definir un fundamento para mejorar.

EL PSP0 provee una estructura muy conveniente para hacer tareas a pequeña escala, un marco de trabajo para medir las tareas y un fundamento de mejora del proceso
Las tareas incluyen lo siguiente:

• 
  Definición del proceso actual (PSP0).
  
• 
  Tiempo de registro (PSP0).
  
• 
  Registro de falla (PSP0).
  
• 
  Registro de falla estándar (PSP0).
  
• 
  Codificación estándar (PSP0.1).
  
• 
  Medida del tamaño (PSP0.1).
  
• 
  Mejora del proceso (PSP0.1).
  

4.5.2.1 PSP0 Proceso Actual [15]

Se debe identificar el proceso actual del desarrollo de software. En caso de que no se tenga un proceso regular se puede utilizar el siguiente:

• 
  Diseño, Codificación, Compilación, Prueba
  

El proceso incluye las siguientes tareas:

• 
  Planeación (Produce un Plan de trabajo).
  
• 
  Desarrollo (Desarrollo del software actual).
  
• 
  Post ejecución (Comparación del funcionamiento actual con el plan de trabajo).
  

4.5.2.2 PSP0 Tiempo de Registro [15]

• 
  El tiempo de registro se usa para medir el tiempo que se lleva en cada parte del proceso PSP.
  
• 
  El objetivo es determinar donde se invierte más tiempo.
  
• 
  Ser bastante minucioso con los datos (probablemente hasta minutos)
  

El tiempo de registro incluye:

• 
  Fecha de entrada
  
• 
  Hora de Inicio
  
• 
  Hora de fin
  
• 
  Estimación de tiempo de interrupción para esta entrada
  
• 
  Tiempo delta (el tiempo en el que se trabaja para esta entrada)
  
• 
  Fase en la que se esta trabajando
  
• 
  Comentarios pertinentes
  

4.5.2.3 PSP0 Registro de fallas [15]

El registro de una falla se usa para tener los defectos encontrados y corregidos. El objetivo de esto es determinar donde se pierde mucho tiempo y ser lo mas minucioso posible con los datos.

El registro de fallas debe incluir lo siguiente:

• 
  Fecha de la falla encontrada
  
• 
  Numero de falla
  
• 
  Tipo de falla (Documentación, sintaxis, asignación, interfase, etc.…)
  
• 
  Fase donde se inicio la falla
  
• 
  Fase donde la falla se elimino
  
• 
  Tiempo que se llevo para reparar la falla
  
• 
  Descripción del porque de la falla
  

4.5.2.4 PSP0 Estándar de fallas [15]

Estos pueden se algunas de las fallas que se registran y que se pueden tomar como un estándar:

No	Nombre o descripción
10	Comentario de documentación, mensajes
20	Deletreo de sintaxis, puntuación, formato
30	Construcción, Manejo de cambio de paquete, librería, control de versión
40	Declaración de asignación, duplicado de nombres, alcance, limitaciones
50	Procedimiento de la Interfaz, llamadas, referencias, I/O, formato de usuario
60	Chequeo de mensajes de error
70	Estructura de datos, contenido
80	Función de conexión, enlace, recursividad,
90	Configuración de sistema, sincronización, memoria
1 Tabla 4.1 Estanda de fallas Mike Grasso, University of Maryland, “The Personal Software Process” [En línea], Maryland EUA [Consulta: Mayo de 2006] 00	Diseño del entorno, compilación, prueba, otro sistema de soporte de problemas