CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez

Transcripción

1 CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS USB Ing. De Software. Prof. I. C. Martínez

2 Ing. De Software

3 Ingeniería de Software La Ingeniería de Software es la ciencia y el arte de construir sistemas de software significativos, que sean: 1) Desarrollados a tiempo 2) Desarrollados dentro del presupuesto 3) Con un desempeño aceptable 4) Con operación correcta.

4 Ingeniería de Software La Ingeniería de Software se ocupa de las teorías, métodos y herramientas para el desarrollo profesional de software.

5 El Proceso de Software Conjunto estructurado de actividades y resultados que se requieren para desarrollar un sistema de software. Existen 4 acividades fundamentales: Especificación Desarrollo Validación Evolución Estas actividades se organizan de forma diferente y presentan diferentes niveles de detalle, dependiendo del tipo de sistema que se desarrolla.

6 Modelo del Proceso de Ingeniería Especificación: Precisar los requerimientos y las restricciones del sistema. Diseño: Producir un modelo del sistema. Manofactura: Construcción del sistema. Pruebas: Chequeo de que el sistema cumple con las especificaciones. Instalación: Entregar el sistema a los clientes y asegurarse que está operativo. Mantenimiento:Reparar las fallas en el sistema a medida que son encontradas.

7 Diferencias de la Ingeniería de Software Normalmente, las especificaciones son incompletas. La separación entre la especificación, el diseño y la construcción es muy difusa. No hay una manifestación física del sistema para probar. El software no de desgasta con el uso - su mantenimiento no significa reemplazar componentes.

8 Modelos de Procesos de Desarrollo

9 Modelos del proceso de software Cascada Separa y distingue las diferentes fases de especificación y desarrollo Evolutivo La especificación y el desarrollo son alternados. Transformaciones Formales Un modelo matemático del sistema se trasforma formalmente en una implementación Basados en Reusabilidad El sistema se ensamble a partir de componentes existentes

10 Modelo de Cascada

11 Modelo Evolutivo Concurrent activities Specification Initial version Outline description Development Intermediate versions Validation Final version

12 Transformaciones Formales Requirements definition Formal specification Formal transformation Integration and system testing

13 Desarrollo Basado en Re-usabilidad Requirements specification Component analysis Requirements modification System design with reuse Development and integration System validation

14 Problemas de los Modelos del Proceso Cascada Alto riesgo para sistemas nuevos debido a problemas de especificación y diseño. Bajo riesdo para desarrollos bien-conocidos usando tecnologías familiares. Prototipos Bajo riesgo para nuevas aplicaciones debido a especificaciones y programas por pasos Alto riesgo debido a la falta de visibilidad del proceso.

15 Problemas de los Modelos del Proceso Transformacional Alto riesgo debido a la necesidad de tecnologías avanzadas y conocimiento altamente especializado del personal. Basado en Reusabilidad Desorganización en el diseño e implementación. Poca experiencia.

16 Modelos de Proceso Híbridos Los sistemas grandes usualmente están conformados por varios subsistemas. El mismo modelo de proceso no necesariamente debe ser usado para todos los subsistemas. Prototipos para especificaciones de alto riesgo. Cascada para desarrollos bien conocidos.

17 Iteración de Procesos Los sistemas SIEMPRE evolucionan en el transcurso del proyecto, luego la iteración del proceso donde las etapas tempranas son re-trabajadas es parte del proceso para grandes sistemas. Las iteraciones pueden ser aplicadas a cualquier modelo de proceso. Dos aproximaciones relacionadas: Desarrollo incremental Desarrollo en espiral

18 Desarrollo Incremental En lugar de liberar el sistema como un todo, el desarrollo y entrega se subdivide en incrementos. Cada incremento entrega parte de la funcionalidad requerida. Los requerimientos de los usuarios se prioritizan y los de mayor prioridad se incluyen en los incrementos tempranos. Una vez que se da inicio al desarrollo de un incremento, los requerimientos para el mismo se congelan aunque los requerimientos para futuros incrementos pueden seguir evolucionando.

19 Desarrollo Incremental Define outline requirements Assign requirements to increments Design system architecture Develop system increment Validate increment System incomplete Integrate increment Validate system Final system

20 Ventajas del Desarrollo Incremental Elementos de valor al cliente pueden ser entregados en cada incremento, luego la funcionalidad del sistema está disponible más temprano. Los incrementos tempranos actúan como prototipos para ayudas a elicitar requerimientos para futuros incrementos. Baja el riesgo de falla del proyecto Los servicios del sistema de mayor prioridad son probados más.

21 Modelo Espiral El proceso se representa como una espiral, en lugar de una secuencia de actividades con backtracking. Cada ciclo en el espiral representa una fase en el proceso. No hay fases fijas, tales como especificación o diseño, los ciclos en la espiral se escogen de acuerdo a lo que se requiere. Los riesgos se determinan explícitamente y se resuelven a través del proceso.

22 Modelo Espiral Determine objectives alternatives and constraints Plan next phase REVIEW Requirements plan Life-cycle plan Development plan Integration and test plan Risk analysis Risk analysis Risk analysis Prototype 2 Risk analysis Prototype 1 Concept of Operation S/W requirements Requirement validation Design V&V Service Acceptance test Prototype 3 Operational protoype Simulations, models, benchmarks Product design Integration test Evaluate alternatives identify, resolve risks Code Unit test Detailed design Develop, verify next-level product

23 Ventajas del Modelo Espiral Enfoca la atención en la reusabilidad. Se enfoca en la eliminación temprana de los errores, Coloca los objetivos de calidad en primer plano Integra desarrollo y mantenimiento. Proporciona un marco de trabajo para el desarrollo de hardware y software.

24 Problemas del Modelo Espiral El desarrollo por contrato usualmente especifica el modelo del proceso y los entregables por adelantado. Requiere experticia en la evaluación de riesgos.

25 Mejores Prácticas

26 Desarrollo iterativo del software Manejo de requerimientos Uso de arquitecturas basadas en componentes Modelaje visual del software Verificación de la calidad del software Control de cambios del software

27 Facilita el entendimiento incremental del problema a través de Refinamientos sucesivos Produce la solución efectiva en Múltiple iteraciones Reduce el Perfil de riesgos del proyecto en c/etapa del desarrollo Provee Progreso demostrable con la participación efectiva del usuario

28 Cada iteración culmina con una Versión ejecutable Concentración del equipo en la producción de resultados Chequeos frecuentes del estado aseguran seguimiento al plan de trabajo Ajuste de cambios tácticos en los requerimientos, lineamientos o plan Enfoque de Cascada presenta limitaciones en el proceso de desarrollo total del SW Desde los Requerimientos hasta las Pruebas finales

29 RUP describe cómo: Obtener los requerimientos Organizarlos Documentar requerimientos de funcionalidad y restricciones Rastrear y documentar decisiones Captar y comunicar requerimientos del negocio Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseño, la implementación y las pruebas.

30 El proceso construye al inicio una Arquitectura ejecutable robusta antes de comprometer recursos de gran escala. Los componentes son módulos y subsistemas con una función Define arquitecturas ensamblando componentes existentes y nuevos

31 La arquitectura debe ser: Flexible Fácil de modificar Intuitivamente comprensible Promueve la reutilización de componentes RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

32 Modelado visual de la estructura y el comportamiento de la arquitectura y los componentes. Esconde los detalles y el código usando bloques gráficos de construcción La abstracción visual asiste en la comunicación de varios aspectos del SW: Apreciar como los elementos de relacionan entre sí Asegurar la consistencia de su código con los bloques de construcción Mantener la consistencia entre el diseño y su implementación Promover la comunicación sin ambigüedades UML es la base del modelamiento visual de RUP.

33 No sólo la funcionalidad es esencial, también el rendimiento y la confiabilidad. Evita el pobre desempeño y la ocurrencia de fallas de las aplicaciones resultantes. La calidad es revisada con relación a los requerimientos: No ocurrencia de fallas Funcionalidad esperada Desempeño de la aplicación y del sistema.

34 La evaluación de la calidad está construida en el proceso, no es opcional: En todas las actividades Involucra a todos los participantes Usa medidas y criterios objetivos de forma natural

35 Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto. Habilidad para el manejo del cambio en ambientes de cambio Factor Crítico de Éxito al Desarrollo Iterativo Demanda control, seguimiento y monitoreo de los cambios a implementar Mantiene Áreas de Trabajo seguras para cada desarrollador: Aísla los cambios hechos en otras áreas de trabajo Controla los cambios de todos los artefactos de SW : Modelos, Código, Documentos, etc