Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.

Transcripción

1 El proceso software Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software Especificación: Definir la funcionalidad y las restricciones en sus operaciones Diseño e implementación: Producir software que cumple la especificación Validación: Asegurar que hace lo que el cliente desea. Evolución: Seguir cumpliendo los cambios en las necesidades del usuario. Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.

2 Modelos de proceso genéricos No son descripciones exhaustivas de los procesos software. Son abstracciones útiles que explican diferentes enfoques utilizables a la hora de desarrollar software. Son marcos de trabajo del proceso, no detallan las actividades específicas. Se denominan paradigmas de proceso

3 Modelos de proceso genéricos El modelo de cascada Separa y distingue cada fases de especificación y desarrollo Desarrollo evolutivo Se interpolan la especificación y el desarrollo Desarrollo formal de sistemas Un modelo matemático del sistema se transforma formalmente a una implementación Desarrollo basado en reutilización El sistema se monta a partir de componentes existentes

4 Modelo en Cascada Definición de de Requisitos Diseño Diseño del del sistema sistema y del del software Implementación y prueba prueba de de unidades Integración y prueba prueba del del sistema sistema Operación y mantenimiento

5 Fases del modelo en cascada Análisis y definición de requisitos Diseño del sistema y del software Implementación y prueba de unidades Integración y prueba del sistema Operación y mantenimiento Una fase no comienza hasta que no hayan terminado las anteriores. Ladesventajaesladificultadde tener en cuenta los cambios cuando el proceso ya está en marcha

6 Problemas del Modelo en cascada Inflexibilidad al dividir el proyecto en estas etapas Es difícil responder a los cambios en los requisitos del cliente Por lo tanto, este modelo es apropiado sólo cuando los requisitos se comprenden muy bien.

7 Desarrollo evolutivo Desarrollar una implementación inicial e ir refinándola hasta conseguir el sistema adecuado. Las actividades se realizan concurrentemente. Desarrollo exploratorio El objetivo es trabajar con los clientes y desarrollar un sistema final con alguna especificación inicial. Se debe comenzar teniendo en cuenta los requisitos bien-entendidos. El sistema evoluciona según la nuevas propuestas del cliente. Prototipos desechables El objetivo es comprender los requisitps del cliente y desarrollar un prototipo para evaluar hasta qué punto se han entendido.

8 Desarrollo evolutivo Actividades concurrentes Especificación Especificación Versión Versión Inicial Inicial Bosquejo Bosquejo de de la la descripción descripción Desarrollo Desarrollo Validación Validación Versiones Versiones intermedias Versiones intermedias Versiones intermedias intermedias Versión Versión final final

9 Desarrollo evolutivo La ventaja es que la especificación se desarrolla de forma creciente. Problemas Hay que documentar cada versión del sistema Los sistemas tienen una estructura deficiente Se requieren herramientas y técnicas especiales (p.e. conocimientos en lenguajes para el prototipado rápido) Aplicabilidad Para sistemas interactivos pequeños o de tamaño mediano Para partes de sistemas grandes (e.g. el interfaz de usuario) Para sistemas con vida corta

10 Proceso mixto Desarrollar un prototipo desechable (con enfoque evolutivo) para resolver incertidumbres en la especificación inicial. Reimplementar con un enfoque más estructurado, con un proceso basado en el modelo en cascada.

11 Desarrollo formal de sistemas Se basa en la transformación de una especificación matemática a un programa ejecutable Las transformaciones preservan la corrección y el programa final es conforme con su especificación

12 Desarrollo formal de sistemas Definición Definición de de Requisitos Requisitos Especificación Especificación formal formal Transformación Transformación formal formal Integración Integración y y prueba prueba del del sistema sistema

13 Desarrollo formal de sistemas Problemas Se necesitan habilidades y el entrenamiento especializados para aplicar la técnica Es difícil especificar formalmente algunos aspectos del sistema tales como la interfaz de usuario Aplicabilidad Sistemas críticos donde la seguridad o la fiabilidad debe garantizarse antes de que el sistema se ponga en explotación

14 Desarrollo con/para reutilización Basado en la reutilización sistemática, los sistemas se integran con componentes existentes o con sistemas COTS (Commercial-off-the-shelf) Etapas del proceso Análisis de componentes Modificación de requisitos Diseño del sistema con reutilización Desarrollo e integración Este enfoque se está convirtiendo en el más importante pero todavía hay una experiencia limitada con él

15 Desarrollo con/para reutilización Especificación Especificación de de Requisitos Requisitos Análisis Análisis de de componentes componentes Modificación Modificación de de requisitos requisitos Diseño Diseño de de sistemas sistemas con con reutilización reutilización Desarrollo Desarrollo e e integración integración Validación Validación del del sistema sistema

16 Iteración del proceso En sistemas grandes, es conveniente utilizar diferentes enfoques en las distintas partes. Los requisitos del sistema SIEMPRE evolucionan en el transcurso de un proyecto. Siempre habrá una iteración en el proceso que obligue a rehacer las primeras fases del mismo. La necesidad de iterar aparece independientemente del modelo de proceso genérico utilizado Modelos de proceso que incluyen la iteración: Desarrollo incremental Desarrollo en espiral

17 Desarrollo incremental Propuesto por Mills en En vez de entregar el sistema de una vez, tanto el desarrollo com las entregas se dividen en incrementos. Con cada incremento que entrega la parte de la funcionalidad que se hubiera determinado Los requisitos del usuario se priorizan y los requisitos de prioridad más alta se incluyen en los incrementos más tempranos Cuando el desarrollo de un incremento comienza, sus requisitos son inamovibles, aunque los requisitos de incrementos posteriores pueden continuar desarrollándose

18 Desarrollo incremental Definir Definir requisitos requisitos iniciales iniciales Asignar Asignar requisitos requisitos a a cada cada incremento incremento Diseñar Diseñar la la arquitectura arquitectura del del sistema sistema Desarrollar Desarrollar incremento incremento Validar Validar incremento incremento Integrar Integrar incrementos incrementos Validar Validar sistema sistema Sistema final Sistema incompleto

19 Ventajas del desarrollo incremental Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos más críticos. Los primero incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos. Existe un riesgo bajo de fallar en el proyecto total. Los servicios de sistema con la prioridad más alta tienden a ser los más probados. pero puede ser difícil ajustar los requisitos a los incrementos.

20 Programación extrema Propuesta por Beck en Nuevo enfoque basado en el desarrollo y la entrega de incrementos de funcionalidad muy limitada. Confía en la mejora constante del código, implicación del usuario en el equipo de desarrollo y la programación sin complejos.

21 Desarrollo en espiral Propuesto por Boehm en El proceso se representa como una espiral más que como una secuencia de actividades con vuelta hacia atrás. Cada vuelta en la espiral representa una fase del proceso. No hay fases fijas como la especificación o diseño. Cada vuelta en la espiral determina las actividades a realizar.

22 Modelo en espiral Deter mine ob jectives alternatives and cons traint s Plan next phase REVIEW Require ment s plan Life-cycle plan Develop ment plan Integration and test plan Risk analysis Risk analysis Risk analysis Prototype 2 Risk analysis Prototy pe 1 Concept of Operation Require ment validati on Desi gn V&V Serv ice S/W require ment s Acceptance test Prototype 3 Operati onal prot oype Simulati ons, models, bench marks Prod uct desi gn Integration test Evaluate alternatives iden tif y, resolve risk s Code Unit test Detailed desi gn Develop, v erif y next-level prod uct

23 Sectores del modelo en espiral Definición de objetivos Se identifican los objetivos de cada fase, las alternativas y las restricciones. Evaluación y reducción de riesgos Se determinan los riesgos de cada fase y se ponen en marcha las actividades que reduzcan estos riesgos. Desarrollo y validación Se elige el modelo de desarrollo más apropiado para el sistema de entre todos los modelos genéricos. Planificación Se revisa el proyecto y, si se continúa, se planifica la siguiente fase (nueva vuelta a la espiral).

24 Especificación del software Etapa en que se establece qué servicios se requieren del sistema y cuáles son las restricciones de operación y desarrollo del mismo. Se obtiene un documento de requisitos, con la especificación del sistema. Fases de la Ingeniería de Requisitos: Estudio de factibilidad Obtención y análisis de requisitos Especificación de requisitos: los del usuario y los del sistema Validación de requisitos

25 Diseño e implementación Etapa en la que se convierte la especificación del sistema en un sistema ejecutable Diseño del software Describir la estructura del software, los datos, las interfaces entre componentes, Implementación Transformar la estructura anterior en un programa ejecutable Las actividades de estas etapas están muy relacionadas y pueden interpolarse.

26 Actividades en el diseño Diseño arquitectónico. Qué subsistemas se necesitan? Especificación abstracta. Servicios y restricciones bajo las que opera. Diseño de la interfaz. Interacción con otros subsistemas. Diseño de componentes. Diseño de la estructura de datos. Diseño de algorítmos.

27 Programación y depuración Etapa en la que se traduce un diseño a un programa y se depuran los errores del mismo. Las pruebas que se realizan sobre un programa permiten descubrir los defectos del mismo. La depuración permite localizar y corregir esos defectos.

28 Validación del Software La verificación y la validación pretenden demostrar que un sistema es conforme con su especificación y que resuelve los requisitos del cliente La prueba del sistema implica ejecutar el sistema con los casos de prueba que se obtuvieron en la especificación.

29 Etapas en el proceso de pruebas Prueba de unidades Se comprueban los componentes individuales Prueba de módulos Se prueban colecciones de componentes dependientes Prueba de subsistemas Los módulos se integran en subsistemas y se prueban. Sobre todo se prueba el acoplamiento de las interfaces. Prueba del sistema Se prueban las interacciones entre los subsistemas y las propiedades emergentes. Prueba de aceptación Se prueba con datos reales para comprobar que el sistema es aceptable por el cliente.

30 Evolución del software El software es intrínsecamente flexible y puede cambiar. De la misma forma que los requisitos cambian según cambian las circunstancias del negocio, el software que da soporte al negocio debe también desarrollarse y cambiar. Aunque históricamente ha existido una demarcación entre el desarrollo y la evolución (mantenimiento) esto es cada vez más irrelevante, puesto que apenas hay sistemas completamente nuevos.

31 Ayuda automatizada al proceso (CASE) La Ingeniería de Software asistida por Ordenador (CASE) es el software que se utiliza para ayudar a las actividades de desarrollo y evolución del software. Automatización de actividades Editores gráficos para el desarrollo del modelo de sistema Diccionario de datos para gestionar las entidades del diseño Generadores de GUI para la construcción del interfaz de usuario Depuradores para encontrar los fallos de los programas Traductores automatizados para generar nuevas versiones de un programa