El Proceso para el Desarrollo de Software

Se define un proceso como una serie de acciones u operaciones para conseguir un fin. En general toda empresa u organización requiere de al menos un proceso para conseguir sus objetivos. En el caso de las empresas dedicadas al desarrollo de software, se requieren procesos que abarquen desde el diseño y concepción de un sistema de software hasta su mantenimiento. Es lo que conocemos como "ciclo de vida del software".

El Modelo de Proceso.

El modelo de proceso define un orden para realizar los distintos aspectos del proceso. El modelo se puede definir como un grupo de estrategias, actividades, métodos y tareas, que se organizan para lograr un conjunto de metas y objetivos.
Los modelos de proceso varían mucho entre sí y dependen de las diversas opiniones o máximas generales. Por ejemplo algunas creencias en el desarrollo de software son :

• Es mejor comprender el problema antes de desarrollar una solución.
• El proceso para resolver un problema debe dar un resultado predecible, sin importar del individuo que hace el trabajo.
• Debe ser posible planear y calcular el proceso con gran precisión.
• Evaluar y administrar el riesgo es importante para el éxito del proceso.
• Etapas bien definidas con entregas intermedias aumentan la confianza que se tiene en el resultado final.

Distintos tipos de Proyectos

Una creencia común pero equivocada en la industria del software es que hay un sólo modelo de proceso que sirve para todo tipo de proyectos. En general habrá un modelo de proceso mejor adaptado a cada tipo de proyecto, o un modelo de proceso que sea flexible y pueda dar solución particularizada a cada tipo de proyecto.
Podemos enumerar los tipos de proyectos más comunes:

• Primer proyecto de su tipo, donde se va a crear la mayoría del software desde cero, aunque se pueden aprovechar componentes genéricos para su desarrollo. Por ser la primera vez que se crea este tipo de proyecto, se requiere más tiempo para analizar el dominio del problema que para otros proyectos. Incluso aunque el dominio del problema sea familiar pudiera ser ésta la primera versión de un sistema de software de este tipo.

•  Variación de un proyecto, donde se extiende un sistema ya existente. Esto puede involucrar introducir componentes de software reutilizables como un marco (“framework”), crear nuevos componentes o simplemente extender la aplicación existente mediante nueva funcionalidad. Por lo general, el riesgo en este tipo de proyectos es mucho menor que en los primeros proyectos de su tipo. Lo que se debe hacer ya está definido por la naturaleza del software existente, sin embargo se debe comprender las nuevas extensiones en el software en especial si éstos involucran componentes reutilizables.

• Proyecto de reescritura de legado (“legacy”), donde se busca transformar o hacer una “reingeniería” de un sistema ya existente desarrollado bajo tecnologías anteriores, a un sistema desarrollado bajo nuevas tecnologías, tales como las orientadas a objetos.

• Proyecto de mejora de sistema o mantenimiento, donde se busca modificar los componentes básicos de un sistema para apoyar nueva funcionalidad. Tales proyectos a menudo son relativamente pequeños en alcance y no incluyen rescribir componentes o la aplicación completa. Se debe tener una buena comprensión de los componentes a ser mejorados y cómo estos cambios afectan el resto del sistema.

Modelo de Casacada

El modelo de cascada se define como una secuencia de actividades a ser seguidas en orden, donde la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de revisión bien definidos.

Las siguientes máximas sirven de base para el Modelo de Cascada :

• Las metas se logran de mejor manera teniendo como fin puntos de revisión bien definidas y documentadas, dividiendo el desarrollo en etapas secuenciales bien definidas.
• Documentos técnicos son comprensibles para usuarios y administradores no-técnicos, y estos participantes notécnicos pueden comunicarse de forma efectiva durante las diversas actividades. Cada detalle sobre los requisitos puede conocerse de antemano antes de desarrollarse el software, y estos detalles son estables a través del desarrollo.
• Pruebas y evaluaciones pueden llevarse a cabo eficientemente al final del desarrollo.

El modelo de cascada fue inicialmente bien recibido ya que identificaba etapas razonables y lógicas para las diversas actividades. Lamentablemente, el modelo no explicaba entre otras cosas cómo modificar un resultado. No existía una guía del por qué y cuándo se debía revisar un resultado previo para sus posibles cambios, en especial considerando que es extremadamente difícil definir todos los requisitos de un sistema al inicio y que estos se mantengan estables y sin cambios a lo largo del desarrollo.

Módelo de Espiral

El módelo en espiral es una modificación del modelo de cáscada ,  se basa en una estrategia para reducir el riesgo, al contrario del módelo de cascada que se basa en documentos. Introduce el uso de prototipos, El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo.

El modelo de espiral contempla que el desarrollo de sistemas es un proceso de cambios progresivos. Un sistema normalmente se desarrolla mediante cambios en la especificación de la versión anterior del sistema que son incorporados a nuevas versiones, donde un cambio se conoce como un delta en la especificación de requisitos o versión.

Las máximas del modelo de espiral :

• Una actividad comienza con un entendimiento de los objetivos y riesgos involucrados.
• Basado en la evaluación de soluciones alternas, se usa las herramientas que mejor reduzcan los riesgos.
• Todo el personal relacionado debe involucrarse en una revisión que determina cada actividad, planeando y comprometiéndose a las siguientes actividades.
• El desarrollo puede proceder en incrementos en cada etapa, permitiendo prototipos sucesivos del producto.

Modelo Win Win

El principal objetivo del modelo es establecer las reglas para la definición del proceso de desarrollo del proyecto tomando en cuenta a todos los implicados. Son cuatro los ciclos del modelo consistiendo de cuatro actividades principales cada uno:

• Definición de los objetivos del proceso y elaboración del sistema y subsistemas del producto.
• Evaluación de las alternativas con respecto a los objetivos del proyecto. Identificación y resolución de las fuentes principales de riesgo en el proceso de desarrollo de los productos.
• Elaboración de la definición de los productos y procesos.
• Planeación del siguiente ciclo. Calendarización del ciclo de vida del plan, incluyendo la partición del sistema en subsistemas para llevar el proceso en ciclos paralelos.

Las máximas o creencias del modelo son las siguientes:

1. Crear software basado en componentes para lograr mayor calidad en sistemas de mayor tamaño.
2. Escribir software reutilizable para eficientar el proceso de desarrollo.
3. Medir la calidad del sistema como aspecto clave del desarrollo del producto.
4. Lograr mayor calidad en el proceso de ensamblaje a partir de componentes menores.
5. Usar tecnología basadas objetos como aspecto básico para lograr la calidad.
6. Poder lograr sistemas más rápidamente, sencillos, confiables y de calidad a través de procesos bien definidos.
7. Utilizar el modelo de espiral como base del proceso.
8. Flexibilizar el proceso de desarrollo del software para lograr los objetivos generales de eficiencia.
9. Involucrar al cliente mediante el manejo de prototipos.
10. Analizar los riesgos en el proceso del desarrollo del software para asegurar la calidad final del sistema.

Calidad en el Software

Un proceso bien conocido y ampliamente utilizado, sustentado en medición y predicción de eventos, debe permitir controlar en buena medida la producción de software [De Marco, 1982] y consecuentemente la calidad de estos productos. Sin embargo, la producción de software sigue siendo compleja y difícil de obtener, aunque se están haciendo esfuerzos importantes para facilitar la producción y aumentar su calidad. Uno de los esfuerzos que han logrado mejores frutos es el desarrollo de modelos de madurez del proceso de producción de software que permite no sólo la estandarización de la producción a manera de cualquier otro producto sino el permitir una mejora continua.Por lo general, la calidad en los productos se da a través del control de los procesos de producción o procesos de desarrollo.Tomando en cuenta la definición y medición de los procesos de desarrollo como paso previo hacía una mejora, revisaremos a continuación los enfoques de los modelos más conocidos y sus implicaciones.

CMM (Capability Maturity Model)

El modelo "clásico" en el tratamiento de la capacidad de los procesos de desarrollo y su madurez es CMM (Capability Maturity Model) del SEI (Software Engineering Institute). CMM tiene como objetivo  evaluar los procesos en sus distintos niveles de madurez, identificar los niveles a través de los cuales una organización debe formarse para establecer una cultura de excelencia en la ingeniería de software. El modelo de madurez de procesos fue generado a través de la experiencia colectiva de los proyectos más exitosos de software, generando así un conjunto de prácticas  importantes que deben ser implantadas por cualquier entidad que desarrolla o mantiene software.
En particular, CMM es un marco de trabajo especificando guías para organizaciones de software que quieren incrementar su capacidad de procesos, considerando los siguientes puntos:

• Identificar fortalezas y debilidades en la organización.
• Identificar los riesgos de seleccionar entre diferentes contratos y monitorear los mismos.
• Entender las actividades necesarias para planear e implementar los procesos de software.
• Ayudar a definir e implementar procesos de software en la organización a través de una guía.

Los procesos son evaluados a través de distintos niveles de madurez, que van desde prácticas desordenas o ad-hoc,hasta lograr una mejora continua de procesos y por ende de producto, como se muestra en la siguiente figura:

En la siguiente tabla se da una descripción más detallada.

Otros modelos basados en la madurez de los procesos

Existen en la actualidad distintos modelos que al igual que CMM se basan en un análisis de la madurez de los procesos de desarrollo de software, entre los más conocidos se encuentran :

• ISO9000
• PSP/TCP Personal Process Software
• SPICE Software Process Improvement and Capability dEtermination
• PEMM (Performance Engineering Maturity Model)
• Tick It , desarrollado por el Departamento de Comercio e Industria del Reino Unido,

Estrategias

Existen múltiples estrategias que afectan el modelo del proceso de software. En esta sección analizaremos algunas de las más importantes como son los tipos de tecnología, arquitectura,desarrollo, prototipo y reutilización.

Tecnología

Uno de los factores más importantes es el tipo de tecnología que se utilizará. Este aspecto tiene grandes repercusiones en todo el proceso y debe escogerse con sumo cuidado. La selección del tipo tecnología tiene que ver con diversos aspectos del sistema como la robustez, extensibilidad, etc.

Arquitectura

La arquitectura de software se define como la estructura general del sistema incluyendo aspectos de como cambiarlo, verificarlo y mantenerlo. La arquitectura general se especializa a través de las distintas actividades del modelo de proceso hasta llegar a una arquitectura particular implementada por el código final. En el caso de desarrollo de sistemas orientados a objetos, la arquitectura general estará basada en clases y objetos.

Desarrollo

A nivel de actividades, existen dos estrategias básicas que vale la pena describir con más detalle: el desarrollo de actividades de forma iterativa y de manera incremental. Lamentablemente los términos “iterativo” e “incremental” a menudo se usan indistintamente, sin embargo, las dos son estrategias de desarrollo distintas e independientes, aunque pueden utilizarse de forma separada o en conjunto.

• Iterativo: Se conoce como desarrollo iterativo el acto de revisar un resultado previo para ser luego modificado. Desarrollo iterativo apoya rehacer porciones del sistema. La idea detrás del desarrollo iterativo es revisar parte del sistema de forma controlada para remover errores o hacer mejoras basadas en la retroalimentación del usuario. Después de cada iteración, se evalúa el resultado y se planea, en la iteración siguiente, mejorar el sistema y la calidad del diseño. Aunque lo ideal es no tener que hacer dos veces lo mismo, a veces esto se justifica cuando un problema es bastante nuevo o difícil.

• Incremental: Se conoce como desarrollo incremental el acto de incrementar o añadir desarrollo. Es necesario dividir los sistemas para desarrollarse en diferentes momentos para obtener progreso en pequeños pasos.El enfoque incremental requiere que un problema se convierta en varios subproblemas para que cada cual se desarrolle a su vez. Según se completa cada sección, se verifica e integra con las demás secciones ya completadas del sistema. En cada paso, el sistema parcialmente completado se puede evaluar en relación al desarrollo de secciones futuras.El sistema se agranda incrementalmente hasta llegar al nivel deseado, ofreciendo retroalimentación más frecuente durante el proceso de desarrollo. Esta es la idea detrás del modelo de espiral, donde cada ciclo significa un incremento en el sistema.Es la regla más que la excepción que los requisitos de los sistemas no son totalmente conocidos al iniciarse el proyecto.

En general, el desarrollo de software es un proceso incremental y muchas iteraciones ocurrirán antes de poder completar el sistema. Estas iteraciones ocurrirán y no tiene sentido impedirlas, sino encontrar la forma de manejarlas.

Protitopo

Un prototipo es una versión preliminar, intencionalmente incompleta o reducida de un sistema. El término prototipaje rapido (RAD – Rapid Application Development) se refiere al proceso de construir y evaluar uno o más prototipos rápidamente. Los prototipos son estrategias aplicadas a la mayoría de actividades del proceso de software, las cuales pueden estar relacionadas con aspectos técnicos, funcionales, eficiencia o interfaces de usuario. Los prototipos rápidos permiten el desarrollo sencillo con resultados inmediatos. Ya que un prototipo se concentra en las propiedades que requieren mayor investigación, aspectos adicionales pueden dejarse de lado, siendo mostrados únicamente de forma esquemática. El propósito de los prototipos es buscar de manera preliminar información necesaria para ayudar en la toma de decisiones.
Los prototipos complementan el desarrollo de sistemas incrementales y pueden ayudar a reducir el riesgo en la especificación de requisitos o en el diseño de la arquitectura del sistema. Una ventaja de los prototipos es que sirven como medio de comunicación entre el desarrollador y el cliente, ayudando a visualizar rápidamente la dinámica del sistema.

Reutilización

La reutilización del código se puede hacer dentro de un mismo proyecto o entre proyectos. Reutilización de código dentro de un mismo proyecto involucra simplemente descubrir secuencias de código redundantes en el diseño y usar las facilidades del lenguaje de programación, como procedimientos o herencia. Este tipo de reuso de código es siempre bueno, produciendo programas más pequeños y resultando en correcciones más rápidas.

El Ciclo de Vida del Software

La siguiente  muestra las actividades más importantes para el ciclo de vida del desarrollo de software. Estas actividades corresponden a las mostradas en el Modelo de Cascada y corresponden de manera similar a las actividades del Modelo de Espiral. La diferencia entre ellas radica en el proceso y orden para llevarlas a cabo junto con las estrategias y métodos utilizados para cada actividad.

Métodos y Metodologías

Los métodos definen las reglas para las distintas transformaciones dentro de las actividades. Las metodologías definen el conjunto de métodos. La selección de las metodologías a utilizarse es otra de las decisiones críticas en el proceso de software.
Los métodos deben proveer técnicas para crear modelos estáticos y dinámicos del sistema. El modelo estático incluye descripciones de los objetos que existen en el sistema, su relación mutua, y las operaciones que pueden ejecutarse en el sistema. El modelo dinámico incluye la secuencia aceptada de operaciones sobre el sistema, al igual que la secuencia de mensajes entre objetos necesaria para ejecutar las operaciones del sistema.

Notaciones

Una notación es usada para comunicar el resultado de aplicar un método, donde los elementos de la notación consisten de elementos gráficos, textuales, o alguna combinación de ambos. A menudo se confunde el concepto de actividad, método, y notación, los cuales están relacionados pero son diferentes.

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003).
Características del Proceso Unificado de Desarrollo de Software:

• Iterativo e incremental
• Dirigido por Casos de Uso
• Centrado en la Arquitectura
• Enfocado en los riesgos

El Proceso Unificado Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML , constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

• El Proceso Unificado es un proceso de desarrollo de software: conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software
• RUP es un marco genérico que puede especializarse para una variedad de tipos de sistemas, diferentes áreas de aplicación, tipos de organizaciones, niveles de aptitud y diferentes tamaños de proyectos.
• RUP está basado en componentes. El software esta formado por componentes de software interconectados a través de interfaces.
• RUP está dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental.

El ciclo de vida RUP es una implementación del desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

El Ciclo de Vida del Proceso Unificado

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.
Fases
Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición.






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

Un Modelo de Desarrollo de Software adaptado a una empresa X

Nuestra empresa X es una empresa, que por la naturaleza de su línea de negocio principal, realiza un extenso procesamiento de información, es por ello que tener aplicaciones de calidad que den soporte al negocio es de suma importancia.

La Dirección de Tecnología Aplicada a la Gestión(DTAG) es la encargada de desarrollar los sistemas informáticos que darán servicio a la distintas áreas de negocio de la empresa, es por ello que resulta importante establecer una metodología que facilite y formalice el proceso en que la empresa desarrolla su software. Tener una metodología predefinida y conocida por la organización, aumenta la calidad de las aplicaciones, ajusta el software resultante a las necesidades verdaderas de los usuarios finales y finalmente minimiza los riesgos y los esfuerzos de mantenimiento.

Propuesta de modelo de proceso de desarrollo de software

Como mejores práctica para Empresa X se recomienda aplicar un Proceso Unificado de Desarrollo de Software simplificado y flexible. Se recomienda un proceso iterativo e incremental con ciclos sucesivos conocidos y bien definidos formados de fases de Análisis -> Diseño -> Implementación -> Pruebas.

Recomendaciones

Dependiendo del tipo de proyecto, de su complejidad, alcance y holgura se recomienda realizar al menos un artefacto de la fase de Análisis y un artefacto de la fase de Diseño; se recomienda la utilización de patrones de diseño y se recomienda ajustarse a ellos en la fase de Implementación, para la fase de Pruebas se recomiendan pruebas extensivas tanto unitarias como integrales siguiendo Scrips de pruebas bien definidos y conocidos.

Caso Práctico Proyecto PORTAL DE FORMACIÓN

Se muestran los artefactos construidos para el proyecto "Portal de Formacion" en las distintas fases del proyecto.

FASE DE ANÁLISIS

En el caso del Portal de Formación se ha elaborado un documento de  Especificación de Requerimientos, Diagrama de Casos de uso y un Prototipo.

Especificación de Requerimientos de Software

Se muestra la Especificación del Requerimiento para la "Alta de Usuario"

En ciclos posteriores (segundo o tercero) se debe (opcional) detallar cada Caso de Uso , en este caso se utilizaron Diagramas de Flujo para detallar los Casos de Uso más complejos.
Diagrama de Flujo del Caso de Uso "Inscribir Alumno"

Diagramas de Caso de Uso

Adicionalmente puede elaborarse un Diagrama de Casos de Uso para identificar y agrupar las disferentes funcionalidades que debera llevar a cabo la aplicación.

Prototipo

También se recomienda realizar un protipo que presente las pantallas con las que interactuarán los usuarios y que reflejen las funciones que tendrá la aplicación.

Menú Principal

Página de Mis Datos con su funcionalidad

Página de Mi Formación y su funcionalidad

Página de Catálogo
                       
NOTA : En un primer ciclo se recomienda hacer un prototipo con el flujo de pantallas real y con todas las opciones que tendrá la aplicación. El prototipo debe hacerse en una tecnología sencilla y rápida de implementar , tiene un fin exclusivamente ilustrativo , y será un medio de comunicación con las áreas de negocio involucradas en el proyecto.

En ciclos posteriores (segundo o tercero) puede llevar un refinamiento, agregar el look and feel del protitipo.
Prototipo de Formación con Look and Feel
Pantalla de Búsqueda de trabajadores Imagen JPG

Pantalla de Documentos Recientes

NOTA: Dependiendo de la complejidad del proyecto y la holgura, se recomienda construir al menos 1 de los 3 artefactos de esta fase

FASE DE DISEÑO

En la fase de Diseño en caso de tratarse de una aplicación Orientada a Objetos se recomiendan 3 tipos de diagramas de Objectory con el fin de tener en cuenta tanto la vista estática (Diagrama de clases), la vista dinámica (Diagrama de Secuencia) y un Diagrama de Componentes para tener una visión de interrelación general del proyecto.
En el caso de programación estructurada se recomiendan  Diagramas de Flujo y de Diagrama  de Componentes.
En el caso del proyecto de Formación de han realizado Diagrama de componentes , Diagrama de clases, Diagrama de Secuencia.

Diagrama de componentes

Diagrama de Clases

Diagrama de clases Formación  Business Delegate

Diagrama Session Facade

Diagrama de Secuencia

Diagrama de Secuencia Caso de uso "Obtener Catágo de Cursos"

FASE DE IMPLENTACIÓN

Se ha realizado la Implementación en plataforma Java Enterprise Edition 5 soportado por Weblogic 10.3 y se ha desarrollado con MyEclipse 6.6

FASE DE PRUEBAS

La aplicación ha sido probada por el equipo de desarrollo (Pruebas unitarias) para la corrección de errores de validación y exactitud de resultados. Tambien se ha instalado un entorno de pruebas que simula el entorno productivo, en este entorno han podido probar los usuarios finales (Pruebas integrales.)

Probando la inscripción

Bibliografía

http://es.wikipedia.org/wiki/Proceso_Unificado
http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational