Los problemas que a menudo tienen que resolver los ingenieros de software son extremadamente complejos. Comprender la naturaleza de los problemas puede ser muy difícil, especialmente si el sistema es nuevo.
En consecuencia, es difícil definir exactamente lo que el sistema debe hacer. Las descripciones de los servicios y restricciones son los requerimientos para el sistema, y el proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se llama ingeniería de requerimientos. Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema. Por supuesto, esto retrasa la entrega de este e incrementa los costos.
Los requerimientos del usuario para un sistema describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos.
Cuando los requerimientos del usuario incluyen demasiada información, restringen la libertad del desarrollador del sistema para proveer soluciones innovadoras a los problemas del usuario y hace que los requerimientos sean difíciles de comprender. Los requerimientos del usuario deben simplemente enfocarse a los recursos principales a proveer.
El proceso del software es un conjunto de actividades y resultados asociados que conducen a la creación de un producto de software. Esto puede consistir en el desarrollo de software desde cero, aunque cada vez más se desarrolla nuevo software ampliando y modificando los sistemas existentes. Una razón por la cual existe un enfoque limitado en el proceso de automatización es la inmensa diversidad de procesos del software. No existe un proceso ideal y diferentes organizaciones han desarrollado enfoques completamente diferentes para desarrollar software. Los procesos han evolucionado para explotar las capacidades de la gente de una organización, así como las características específicas de los sistemas que se están desarrollando. Por lo tanto, aun dentro de la misma organización pueden existir muchos procesos diferentes para desarrollar software.
La metodología del Proceso Unificado de Desarrollo (RUP) traza pautas muy concretas para el desarrollo de proyecto de software, define en un enfoque de alta colaboración, evolutivo y flexible para asimilar los cambios en los requerimientos del software en un ambiente de negocios dinámico. De igual forma define claramente los hitos donde son necesarias la revisiones formales del proyecto, las cuales incluyen la aprobación por parte del cliente. A continuación se puede apreciar en el diagrama el ciclo de vida de un proyecto de software basado en RUP:
Su enfoque evolutivo comprende un desarrollo iterativo e incremental. La naturaleza iterativa está presente en las actividades ubicadas en la parte izquierda del diagrama (requerimientos, análisis, diseño, etc.); mientras que el desarrollo incremental lo constituye la creación de prototipos en el tiempo, desarrollados a través del ciclo de vida, una vez para cada prototipo. Durante la Fase de Elaboración se desarrolla un prototipo con la arquitectura que involucra los casos de uso de mayor riesgo técnico. A su vez, también se produce software al final de cada iteración en la Fase de Construcción, de igual forma que en la Fase de Elaboración, el mismo puede ser utilizado con propósitos de pruebas o software demostrativo para el cliente. Cada vez que termina una iteración marca un hito donde es necesaria la revisión con el cliente, donde se analiza el cumplimiento de los requerimientos, el progreso del proyecto, el análisis de los costos reales y los planeados. En el caso de la última iteración correspondiente a cada fase del proyecto, se debe crear el acta de aprobación por el cliente, en la cual el mismo plantea su acuerdo con los desarrollos alcanzados por el proyecto, aceptando así el sentido financiero y técnico del software que se desarrolla.
En la etapa inicial de desarrollo (Concepción) se crean las bases del proyecto. Se define el alcance, el plan inicial, la visión del negocio con las metas y la justificación del proyecto, estos artefactos son perfeccionados a lo largo del desarrollo del proyecto. Los requerimientos iniciales son capturados a través de casos de uso.
Durante esta etapa se comienza a pensar en la arquitectura inicial del sistema, desde el punto de vista del negocio y desde el punto de visto técnico. Este proceso implica la creación de un modelo conceptual y un modelo de despliegue, ambos a un alto nivel en esta fase.
Se define un plan para el proyecto a alto nivel y después se refina en un plan más detallado en las siguientes iteraciones. El plan a alto nivel maneja las dependencias principales y la estrategia general, mientras que los planes más refinados (correspondientes a iteraciones más detalladas) manejan las tácticas propias de las situaciones en cuestión de cada iteración. En la planificación del proyecto se debe tener en cuenta acciones a largo plazo como son las operaciones, el soporte y la mejora continua.
Esta fase de concepción finaliza asegurando la existencia de un alcance definido, plan de desarrollo, análisis de riesgos donde los clientes concuerden con lo anterior y contar con una estrategia viable para la construcción del almacén de datos.
Existen algunos errores comunes que se incurre en esta etapa, se debe evitar:
- Pensar que es una fase de determinación de los requerimientos de forma tradicional.
- Pensar que se necesita contar con modelos y planes perfectos.
- Tratar de crear un modelo de datos completo al inicio del proyecto.
Artefactos Generados:
- Plan del Proyecto
- Visión
- Casos de Uso
- Diagrama Conceptual
- Diagrama de Despliegue
- Acta de aprobación por el Cliente
Las razones por las que las organizaciones utilizan RUP para el desarrollo de proyectos de software son:
- RUP controla el riesgo del alcance: RUP reconoce como un hecho que los requerimientos cambian en el desarrollo del proyecto y define un enfoque flexible para controlar estos requerimientos. Tratar de definir los requerimientos de forma total al inicio del proyecto es una decisión muy riesgosa.
- RUP busca más allá de los datos: una razón por la cual los proyectos de software fallan es no brindar el suficiente valor de negocio. Al identificar y centrarse en el valor de negocio mediante los casos de uso, RUP obtiene una vista de los requerimientos, método preferible al enfoque centrado en los datos.
- RUP controla de forma temprana el riesgo técnico: muchos proyectos de software fallan por la confianza que brindan modelos detallados creados de forma temprana. Si el modelo de datos es muy detallado, captura “la verdad única” y se han gastado meses trabajando en este, el problema radica en que cualquier arquitectura funciona bien en el papel, hasta que no se prueba la arquitectura con código no puede estar seguro de su funcionamiento correcto.
- RUP controla el riesgo financiero: el desarrollo iterativo e incremental que de forma temprana maneja los componentes críticos de un proyecto asegura que se garantice el mayor valor de funcionalidad primero, maximizando el retorno de la inversión todo el tiempo.
- RUP permite la agilidad de forma disciplinada: los proyectos de software son difíciles, se necesita flexibilidad pero al mismo tiempo mantener un nivel de control para lograr que el desarrollo sea efectivo.
Los cambios en los requerimientos demandan un enfoque de alta colaboración evolutivo y flexible el Proceso Unificado de Desarrollo (RUP) define tal enfoque.
Bibliografía
Ian Sommerville, “Ingeniería de Software”, 6ta Edición. Pearson Educación, 2002.
I. Archer Pupo, “Fases del Proceso Unificado de Desarrollo”. http://www.avatar.com.pe
