Seminario de Diseño de Sistemas

1. Seminario de Diseño de Sistemas Mayo 2014

2. PROBLEMAS GENERALES DEL DISEÑO DE SISTEMAS

3. Diferentes Enfoques Para el Diseño de Sistemas Tema 1.3

4. Diferentes enfoques para el diseño de sistemas Enfoque = Perspectiva Prototipado. Cascada. RUP. Ágil. Iterativo. Espiral.

5. ¿Qué son los procesos del software?¿Metodologías? Un conjunto de actividades [especificaciones, diseño, implementación y pruebas de un sistema computarizado] y resultados asociados [especificaciones de requerimientos, documentos de diseño, etc.] que derivan en la obtención de un producto de software Paul Dunne, GMIT

6. ¿Qué son los procesos del software?¿Metodologías? El Proceso del Software Es un conjunto estructurado de actividades y de resultados asociados para desarrollar un sistema computacional: Especificaciones. Diseño. Validación. Evolución.

7. ¿Qué son los procesos del software?¿Metodologías? Usualmente las compañías tienen un proceso informal o una mezcla de diferentes tipos de procesos. Por lo que siempre es importante estandarizarlo ya que: Fomenta una mejor comunicación. Acorta el entrenamiento/capacitación de empleados. El soporte a los procesos mejora.

8. ¿Qué son los procesos del software?¿Metodologías? Un modelo de proceso de software o metodología es una representación abstracta de un proceso. Representa la descripción de un proceso desde un enfoque en particular. Cada modelo provee sólo parte de la información de un proceso.

9. Modelos Genéricos de Desarrollo de Software Modelo en Cascada Fases distintas y separadas para las especificaciones y el desarrollo. Desarrollo Evolucionario Especificaciones y desarrollo están intercalados. Desarrollo Formal de Sistemas Un modelo de sistemas matemáticos es formalmente transformado en una implementación. Desarrollo Basado en Reutilización El sistema es ensamblado a partir de componentes existentes.

10. Modelos Genéricos de Desarrollo de Software Cascada Este es un modelo simple de administración que separa el diseño de la implementación lo que puede derivar en sistemas más robustos que son más amigables al cambio.

11. Fases del Modelo en Cascada • Análisis de Requerimientos y Definición. Usadas para desarrollar las especificaciones. • Diseño del Sistema y Software. Donde se intenta cumplir los requerimientos con HW o SF • Implementación y Pruebas Unitarias Realizar el diseño como un conjunto de programas • Pruebas e Integración del Sistema Pegar los componentes y verificar si el sistema cumple con los requerimientos. • Mantenimiento y Operación Puede ser la fase más larga donde los problemas sean resueltos o se agreguen nuevas funcionalidades.

12. Problemas del Modelo en Cascada La desventaja del modelo en cascada es la dificultad para introducir cambios después de que el proceso ha sido encaminado. Inflexibilidad para dividir el proyecto en distintas facetas. Esto hace que sea difícil responder al cambio de los requerimientos por parte del cliente. Por lo tanto, este modelo sólo es apropiado cuando los requerimientos están bien entendidos. Este modelo es extremadamente popular debido a su relación estrecha con el “Modelo Tradicional de Ingeniería”.

13. Desarrollo Evolucionario Desarrollo de una implementación inicial, exponerlo al usuario y posteriormente refinar la implementación y repetir el proceso hasta que el sistema sea aceptable. Hay dos tipos de desarrollo evolucionario: Exploratorio: (y podría hacer…?) Prototipado Desechable (Es esta la manera en la que deseas…?)

14. Desarrollo Evolucionario Exploratorio: (y podría hacer…?) Objetivo: Trabajar con el cliente y evolucionar un sistema final desde el esquema inicial de las especificaciones. Debe comenzar con requerimientos bien comprendidos. El sistema evoluciona agregándole nuevas cualidades que propone el usuario. Prototipado: Objetivo: Entender los requerimientos del sistema. Debe comenzar con un entendimiento básico de los requerimientos. Se considera como un medio para obtener pistas acerca de lo que el usuario requeriere.

15. Desarrollo Evolucionario

16. Desarrollo Evolucionario Es bueno para producir sistemas que cumplan con necesidades inmediatas del usuario. Problemas: Falta de visibilidad de procesos. Es difícil documentar ya que los cambios son constantes. Estos sistemas están usualmente pobremente estructurados.

17. Desarrollo de Sistemas Formales Comienza con una especificación de requerimientos de software. Las especificaciones de los requerimientos del software son refinados a una especificación forma y matemática. (Ej. Expresados en una Notación Matemática.) Las especificaciones matemáticas son pasadas por una serie de transformaciones (resultando en un número diferente de representaciones) para finalmente aparecer como un programa ejecutable. Las transformaciones son “enfocadas en la exactitud” por lo que es bastante sencillo hacer que un programa se ajuste a estas especificaciones. Encarnada en el enfoque de “IBM Cleanroom” (Enfoque dedicado a producir software certificable en su confiabilidad).

18. Desarrollo de Sistemas Formales

19. Desarrollo de Sistemas Formales • Problemas: • Necesidad de habilidades especializadas para probar y aplicar la técnica. • Dificultad para especificar formalmente algunos aspectos del sistema como puede ser la interfaz de usuario. La cual es una parte muy importante del proceso de desarrollo de la mayoría de sistemas. • Uso: • Fuera de áreas especializadas, este proceso no es muy utilizado: • Química • Simuladores de procesos físicos. • Viajes Espaciales.

20. Desarrollo Orientado a la Reutilización • Basado en la reutilización sistemática donde sistemas son integrados de compontes existentes. • Etapas del Proceso • Análisis de componente. • Requerimientos de modificación. • Diseño de sistema con reutilización. • Desarrollo e integración.

21. Desarrollo Orientado a la Reutilización

22. Modelos Híbridos de Desarrollo de Software Han sido desarrollados para subsanar los problemas del mundo real en lo referente al análisis y diseño de sistemas. Genéricos  Híbridos.

23. Iteración de Procesos • Los requerimientos del sistema tienen que evolucionar SIEMPRE a lo largo de un proyecto. • La iteración puede ser aplicada a cualquiera de los modelos genéricos de desarrollo. • Dos enfoques relacionados: • Desarrollo incremental. • Desarrollo en espiral. • La esencia de los procesos iterativos es que la especificación sea desarrollada en conjunto con el software. • Los procesos de iteración pueden causar problemas dentro de las organizaciones que están casadas con un modelo tradicional donde las especificaciones se plasman en el contrato antes de que el trabajo empiece.

24. Desarrollo Incremental El desarrollo incremental espera combinar lo mejor del desarrollo en cascada y el proceso evolucionario. En lugar de entregar el sistema de una vez, el desarrollo y entrega es partido en “incrementos”. Con cada incremento se entregan nuevas partes de la funcionalidad requerida. Los requerimientos de los usuarios son priorizados y las prioridades más altas se incluyen en los primeros incrementos. Una vez que el desarrollo de un incremento es iniciado, lo requerimientos se congelan para que puedan continuar evolucionando en incrementos posteriores.

25. Desarrollo Incremental

26. Desarrollo Incremental Ventajas: El “valor al cliente” puede ser entregado con cada incremento, de este modo las funcionalidades del sistema están disponibles anticipadamente. Los primeros incrementos actúan como prototipos para ayudar a los requerimientos de incrementos posteriores. Bajo riesgo de que el proyecto falle porque los problemas son identificados en etapas tempranas. Problemas: Los incrementos tienen que ser pequeños (<20 LOCs) Mapeo de los requerimientos para incrementos de la magnitud correcta.

27. Desarrollo en Espiral Originalmente Propuesto por Boehm (1988) EL proceso es representado como una espiral en lugar de hacer como una secuencia de actividades. Cada ciclo en la espiral representa una fase en el proceso. (Ej. La más interior puede enfocarse en la factibilidad del sistema, la siguiente con la definición de los requerimientos, la siguiente el diseño, etc.).

28. Desarrollo en Espiral Donde a cada ciclo no se le asigna un nombre: No ha fases o etapas definidas. Los riesgos son definidos y resueltos a lo largo del proceso. (Muy distinto a otros modelos) El modelo en espiral es compatible con otros modelos. (Ej. La fase uno puede ser el prototipado)

29. Sectores del Modelo en Espiral Fijación de Objetivos Deben ser definidos objetivos específicos para esa fase. Se identifican los riesgos y se hace el plan con estrategias alternativas. Identificación y reducción de Riesgos Los riesgos deben ser mitigados y las actividades deben ser definidas. Desarrollo y Validación El modelo de desarrollo para el sistema es elegido. El cual puede ser de los modelos genéricos. Planeación El proyecto debe ser reanalizado y decidor si continuar con otro ciclo de la espiral. El próxima fase de la espiral debe ser planeada.

30. Desarrollo en Espiral