Referencia: Sommerville, Software Engineering, 10 ed., Capítulo 2

Un proceso de software es un conjunto estructurado de actividades necesarias para desarrollar un sistema de software. Nótese que estamos hablando de un «proceso de software» — no de un «proceso de desarrollo de software.»

Hay muchos tipos diferentes de procesos de software, pero todos y cada uno de ellos implican estos cuatro tipos de actividades fundamentales:

• Especificación del software – definir lo que el sistema debe hacer;
• Diseño e implementación del software – definir la organización del sistema e implementar el sistema;
• Validación del software – comprobar que hace lo que el cliente quiere;
• Evolución del software – cambiar el sistema en respuesta a las necesidades cambiantes del cliente.

Un modelo de proceso de software es una representación abstracta de un proceso. Presenta una descripción de un proceso desde alguna perspectiva particular. Cuando describimos y discutimos los procesos de software, solemos hablar de las actividades de estos procesos, como la especificación de un modelo de datos, el diseño de una interfaz de usuario, etc. y el orden de estas actividades.Las descripciones de los procesos también pueden incluir:

• Los productos, que son los resultados de una actividad de proceso;
• Los roles, que reflejan las responsabilidades de las personas involucradas en el proceso;
• Las condiciones previas y posteriores, que son declaraciones que son verdaderas antes y después de que una actividad de proceso se ha promulgado o un producto producido.

Los procesos impulsados por un plan son procesos en los que todas las actividades del proceso se planifican por adelantado y el progreso se mide en función de este plan. En los procesos ágiles, la planificación es incremental y es más fácil cambiar el proceso para reflejar los requisitos cambiantes del cliente. En la práctica, la mayoría de los procesos prácticos incluyen elementos de ambos enfoques, el orientado a la planificación y el ágil.

El modelo en cascada Modelo impulsado por el plan. Fases separadas y distintas de especificación, diseño de software, implementación, pruebas y mantenimiento. Desarrollo incremental La especificación, el desarrollo y la validación se intercalan. El sistema se desarrolla como una serie de versiones (incrementos), y cada versión añade funcionalidad a la anterior. Puede ser planificado o ágil. Integración y configuración Se basa en la existencia de un número importante de componentes/sistemas reutilizables. El proceso de desarrollo del sistema se centra en la integración de estos componentes en un sistema en lugar de desarrollarlos desde cero. Puede estar dirigido por un plan o ser ágil.

En la práctica, la mayoría de los grandes sistemas se desarrollan utilizando un proceso que incorpora elementos de todos estos modelos.

Hay fases separadas identificadas en el modelo de cascada:

Análisis y definición de requisitos Los servicios, las restricciones y los objetivos del sistema se establecen mediante la consulta con los usuarios del sistema. A continuación, se definen en detalle y sirven como especificación del sistema. Diseño del sistema y del software El proceso de diseño de sistemas asigna los requisitos a los sistemas de hardware o de software estableciendo una arquitectura global del sistema. El diseño del software implica la identificación y descripción de las abstracciones fundamentales del sistema de software y sus relaciones. Implementación y pruebas unitarias Durante esta etapa, el diseño del software se realiza como un conjunto de programas o unidades de programa. Las pruebas unitarias consisten en verificar que cada unidad cumple su especificación. Integración y pruebas del sistema Las unidades de programa individuales o los programas se integran y se prueban como un sistema completo para garantizar que se han cumplido los requisitos del software. Tras las pruebas, el sistema de software se entrega al cliente. Operación y mantenimiento Normalmente (aunque no necesariamente), ésta es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento. El mantenimiento consiste en corregir los errores que no se descubrieron en las fases anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y mejorar los servicios del sistema a medida que se descubren nuevos requisitos.

El principal inconveniente del modelo de cascada es la dificultad de acomodar los cambios una vez que el proceso está en marcha. En principio, una fase tiene que estar completa antes de pasar a la siguiente. Los problemas del modelo de cascada incluyen:

Dificultad para abordar los cambios La división inflexible del proyecto en distintas fases dificulta la respuesta a los requisitos cambiantes del cliente.Por lo tanto, este modelo sólo es apropiado cuando los requisitos se comprenden bien y los cambios serán bastante limitados durante el proceso de diseño. Pocos sistemas empresariales tienen requisitos estables. Muy pocas aplicaciones en el mundo real El modelo de cascada se utiliza sobre todo en grandes proyectos de ingeniería de sistemas en los que un sistema se desarrolla en varios sitios.En esas circunstancias, la naturaleza del modelo de cascada, basada en la planificación, ayuda a coordinar el trabajo.

Beneficios del desarrollo incremental: Menor coste de los cambios El coste de acomodar los requisitos cambiantes del cliente se reduce. La cantidad de análisis y documentación que hay que rehacer es mucho menor que la requerida con el modelo en cascada. Retroalimentación frecuente Es más fácil obtener la retroalimentación del cliente sobre el trabajo de desarrollo que se ha realizado. Los clientes pueden comentar las demostraciones del software y ver cuánto se ha implementado. Entrega más rápida Es posible una entrega y un despliegue más rápidos del software útil para el cliente. Los clientes pueden utilizar y obtener valor del software antes de lo que es posible con un proceso en cascada.

Problemas con el desarrollo incremental (desde la perspectiva de la gestión):

El proceso no es visible Los gestores necesitan entregables regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema. La estructura del sistema tiende a degradarse a medida que se añaden nuevos incrementos A menos que se gaste tiempo y dinero en la refactorización para mejorar el software, el cambio regular tiende a corromper su estructura. La incorporación de nuevos cambios en el software se vuelve cada vez más difícil y costosa.

Este enfoque se basa en la reutilización sistemática en la que los sistemas se integran a partir de componentes existentes o sistemas COTS (Commercial-off-the-shelf).Las etapas del proceso incluyen:

• Análisis de componentes;
• Modificación de requisitos;
• Diseño del sistema con reutilización;
• Desarrollo e integración.

La reutilización es ahora el enfoque estándar para construir muchos tipos de sistemas empresariales.

Tipos de componentes de software:

• Servicios web que se desarrollan según estándares de servicio y que están disponibles para su invocación remota.
• Colecciones de objetos que se desarrollan como un paquete para integrarse con un marco de componentes como .NET o J2EE.
• Sistemas comerciales autónomos (COTS) que se configuran para su uso en un entorno concreto.

Actividades del proceso de software

Los procesos de software reales son secuencias intercaladas de actividades técnicas, de colaboración y de gestión con el objetivo general de especificar, diseñar, implementar y probar un sistema de software.

Las cuatro actividades básicas del proceso de especificación, desarrollo, validación y evolución se organizan de forma diferente en los distintos procesos de desarrollo. En el modelo de cascada, se organizan en secuencia, mientras que en el desarrollo incremental se intercalan.

Especificación del software El proceso de establecer qué servicios se requieren y las restricciones en el funcionamiento y desarrollo del sistema. Proceso de ingeniería de requisitos:

• Estudio de viabilidad: ¿es técnica y financieramente factible construir el sistema?
• Elicitación y análisis de requisitos: ¿qué requieren o esperan los interesados en el sistema?
• Especificación de requisitos: definir los requisitos en detalle
• Validación de requisitos: comprobar la validez de los requisitos

Diseño e implementación del software El proceso de convertir la especificación del sistema en un sistema ejecutable.

• Diseño de software: diseñar una estructura de software que realice la especificación;
• Implementación: traducir esta estructura en un programa ejecutable;

Las actividades de diseño e implementación están estrechamente relacionadas y pueden intercalarse. Las actividades de diseño incluyen:

• Diseño arquitectónico: identificar la estructura general del sistema, los componentes principales (a veces llamados subsistemas o módulos), sus relaciones y cómo se distribuyen.
• Diseño de interfaces: definir las interfaces entre los componentes del sistema.
• Diseño de componentes: tomar cada componente del sistema y diseñar cómo funcionará.
• Diseño de la base de datos: diseñar las estructuras de datos del sistema y cómo se van a representar en una base de datos.

Validación del software La verificación y validación (V & V) tiene por objeto demostrar que un sistema se ajusta a su especificación y cumple los requisitos del cliente del sistema.

• Validación: ¿estamos construyendo el producto correcto (lo que quiere el cliente)?
• Verificación: ¿estamos construyendo el producto correcto?

V & V implica procesos de comprobación y revisión y pruebas del sistema. Las pruebas del sistema implican la ejecución del sistema con casos de prueba que se derivan de la especificación de los datos reales que va a procesar el sistema. Las pruebas son la actividad V & V más utilizada e incluyen las siguientes etapas:

• Pruebas de desarrollo o de componentes: los componentes individuales se prueban de forma independiente; los componentes pueden ser funciones u objetos o agrupaciones coherentes de estas entidades.
• Pruebas del sistema: pruebas del sistema en su conjunto, las pruebas de las propiedades emergentes son especialmente importantes.
• Pruebas de aceptación: pruebas con datos del cliente para comprobar que el sistema satisface las necesidades del cliente.

Evolución del software El software es inherentemente flexible y puede cambiar. A medida que los requisitos cambian a través de las circunstancias cambiantes del negocio, el software que apoya el negocio también debe evolucionar y cambiar.Aunque ha habido una demarcación entre el desarrollo y la evolución (mantenimiento) esto es cada vez más irrelevante ya que cada vez menos sistemas son completamente nuevos.

El cambio es inevitable en todos los grandes proyectos de software.Los cambios en el negocio conducen a nuevos y cambiados requisitos del sistemaLas nuevas tecnologías abren nuevas posibilidades para mejorar las implementaciones.Las plataformas cambiantes requieren cambios en las aplicaciones.El cambio conduce a la reelaboración por lo que los costes del cambio incluyen tanto la reelaboración (e.p. ej., volver a analizar los requisitos) como los costes de implementación de la nueva funcionalidad.

Dos estrategias para reducir los costes de retrabajo:

Evitar el cambio El proceso de software incluye actividades que pueden anticipar posibles cambios antes de que se requiera un retrabajo significativo. Por ejemplo, se puede desarrollar un sistema prototipo para mostrar algunas características clave del sistema a los clientes. Tolerancia al cambio El proceso se diseña de forma que los cambios se puedan acomodar a un coste relativamente bajo, lo que normalmente implica alguna forma de desarrollo incremental. Los cambios propuestos pueden aplicarse en incrementos que aún no se han desarrollado. Si esto es imposible, es posible que sólo haya que modificar un único incremento (una pequeña parte del sistema) para incorporar el cambio.

Un prototipo es una versión inicial de un sistema utilizado para demostrar conceptos y probar opciones de diseño. Un prototipo se puede utilizar en:

• El proceso de ingeniería de requisitos para ayudar a la obtención y validación de requisitos;
• En los procesos de diseño para explorar opciones y desarrollar un diseño de interfaz de usuario;
• En el proceso de pruebas para ejecutar pruebas consecutivas.

Beneficios de la creación de prototipos:

• Mejora de la usabilidad del sistema.
• Una mayor coincidencia con las necesidades reales de los usuarios.
• Mejora de la calidad del diseño.
• Mejora de la capacidad de mantenimiento.
• Reducción del esfuerzo de desarrollo.

Los prototipos pueden basarse en lenguajes o herramientas de creación rápida de prototipos. Pueden implicar la omisión de funcionalidad:

• El prototipo debe centrarse en las áreas del producto que no se conocen bien;
• La comprobación y recuperación de errores puede no incluirse en el prototipo;
• Centrarse en los requisitos funcionales más que en los no funcionales, como la fiabilidad y la seguridad.

Los prototipos deben descartarse después del desarrollo, ya que no son una buena base para un sistema de producción:

• Puede ser imposible ajustar el sistema para cumplir con los requisitos no funcionales;
• Los prototipos normalmente no están documentados;
• La estructura del prototipo suele degradarse debido a los rápidos cambios;
• El prototipo probablemente no cumplirá con los estándares de calidad normales de la organización.

En lugar de entregar el sistema como una sola entrega, el desarrollo y la entrega se dividen en incrementos con cada uno de ellos entregando parte de la funcionalidad requerida.Una vez que se inicia el desarrollo de un incremento, los requisitos se congelan, aunque los requisitos para los incrementos posteriores pueden seguir evolucionando.

Ventajas de la entrega incremental:

• El valor para el cliente se puede entregar con cada incremento, por lo que la funcionalidad del sistema está disponible antes.
• Los primeros incrementos actúan como un prototipo para ayudar a obtener los requisitos para los incrementos posteriores.
• Menos riesgo de fracaso global del proyecto.
• Los servicios del sistema de mayor prioridad tienden a recibir la mayor cantidad de pruebas.

Problemas de la entrega incremental:

• La mayoría de los sistemas requieren un conjunto de instalaciones básicas que son utilizadas por diferentes partes del sistema. Como los requisitos no se definen en detalle hasta que se va a implementar un incremento, puede ser difícil identificar las instalaciones comunes que son necesarias para todos los incrementos.
• La esencia de los procesos iterativos es que la especificación se desarrolla junto con el software. Sin embargo, esto entra en conflicto con el modelo de adquisición de muchas organizaciones, donde la especificación completa del sistema es parte del contrato de desarrollo del sistema.

Mejora de procesos

Muchas empresas de software han recurrido a la mejora de los procesos de software como forma de mejorar la calidad de su software, reducir los costes o acelerar sus procesos de desarrollo. La mejora de procesos significa comprender los procesos existentes y cambiarlos para aumentar la calidad del producto y/o reducir los costes y el tiempo de desarrollo.

Enfoque de madurez de procesos Se centra en la mejora de la gestión de procesos y proyectos y en la introducción de buenas prácticas de ingeniería de software. El nivel de madurez del proceso refleja el grado de adopción de buenas prácticas técnicas y de gestión en los procesos de desarrollo de software de la organización. Enfoque ágil Se centra en el desarrollo iterativo y la reducción de los gastos generales en el proceso de software. Las características principales de los métodos ágiles son la entrega rápida de la funcionalidad y la capacidad de respuesta a los requisitos cambiantes del cliente.

Las actividades de mejora del proceso forman un ciclo continuo con un bucle de retroalimentación:

• Medir uno o más atributos del proceso o producto de software. Estas mediciones forman una línea de base que ayuda a decidir si las mejoras del proceso han sido efectivas.
• Analizar el proceso actual e identificar los cuellos de botella.
• Cambiar el proceso para abordar algunos de los puntos débiles del proceso identificados. Estos se introducen y el ciclo se reanuda para recoger datos sobre la eficacia de los cambios.

Medición del proceso

• Siempre que sea posible, deben recogerse datos cuantitativos del proceso.
• Las mediciones del proceso deben utilizarse para evaluar las mejoras del proceso.
• Las métricas pueden incluir:
  • Tiempo que tardan en completarse las actividades del proceso, p.p. ej. tiempo de calendario o esfuerzo para completar una actividad o proceso.
  • Recursos necesarios para los procesos o actividades, p. ej. esfuerzo total en días-persona.
  • Número de ocurrencias de un evento particular, p. ej. número de defectos descubiertos.

El modelo de madurez de la capacidad del SEI

• Inicial: Esencialmente no controlado
• Repetible: Procedimientos de gestión de productos definidos y utilizados
• Definidos: Procedimientos y estrategias de gestión de procesos definidos y utilizados
• Gestionados: Estrategias de gestión de la calidad definidas y utilizadas
• Optimizando: Estrategias de mejora de procesos definidas y utilizadas