Procesos para la Ingeniería de Software. Facultad de Estadística e Informática

Transcripción

1 Procesos para la Ingeniería de Software PERIODO FEBRERO-JULIO 2018

2 Introducción Procesos para la Ingeniería de Software

3 Agenda I. Estructura del proceso de software Actividades estructurales Comunicación Planeación Modelado Construcción Despliegue II. Mejoramiento del Proceso de Software/Niveles de Madurez

4 COMUNICACIÓN PLANEACIÓN MODELADO CONSTRUCCIÓN DESPLIEGUE Estructura del proceso de software Actividades Sombrilla -Seguimiento y control -Administración del riesgo -Administración de la reutilización -Administración de la configuración del soft. Actividades Estructurales

5 Estructura del proceso de software Comunicación Es importante antes de cualquier trabajo técnico comunicarse y colaborar con el cliente y los demás participantes. Finalidad? Entender el objetivo del proyecto y reunir los requerimientos Para qué? Para definir las características y funciones del software.

6 Estructura del proceso de software Planeación. Mapa o guía de un equipo de trabajo llamado plan del proyecto de software. Define las tareas, riesgos probables, recursos, productos que se obtienen y establece la programación de las actividades.

7 Estructura del proceso de software Modelado. Bosquejo que se realiza para entender mejor el panorama del general de un proyecto, se puede ir refinando con más y más detalles con el propósito de comprender mejor el problema y cómo se resolverá. El modelado muestra: Cómo se verá arquitectónicamente el proyecto Cómo se ajustan o ubican las partes que lo constituyen Sus características En IS los modelos sirven para entender los requerimientos del software y elaborar el diseño del mismo

8 Estructura del proceso de software Construcción. Generar código y pruebas para descubrir posibles errores.

9 Estructura del proceso de software Despliegue. Entrega del producto al cliente para su evaluación y retroalimentación.

10 Mejoramiento del Proceso de Software

11 Mejoramiento del Proceso de Software (MPS) implica Primero, que los elementos de un proceso de software efectivo pueden definirse en forma efectiva; Segundo, que un enfoque organizacional existente sobre el desarrollo del software puede valorarse en contraste con dichos elementos; Tercero, que es posible definir una estrategia de mejoramiento significativa

12 La estrategia MPS transforma el enfoque existente sobre el desarrollo del software en algo que es más enfocado, más repetible y más confiable

13 Existen marcos conceptuales MPS que definen: 1) Un conjunto de características que deben presentarse si quiere lograrse un proceso de software efectivo, 2) Un método para valorar si dichas características están presentes, 3) Un mecanismo para resumir los resultados de cualquier valoración y 4) Una estrategia para auxiliar a una organización de software a implementar aquellas características del proceso que sean débiles o que hagan falta.

14 Beneficios del uso de una estrategia MPS: Reducción en los problemas del software que cuestan tiempo y dinero. Reducción del número de defectos que se entregan a los usuarios finales, Reducción de la cantidad de repetición de proceso debida a problemas de calidad Reducción de los costos asociados con el mantenimiento y el soporte del software Reducción de los costos indirectos que ocurren cuando el software se entrega tarde.

15 Un marco conceptual MPS valora la madurez del proceso de una organización y proporciona un indicio cualitativo de su nivel de madurez.

16 Elementos de un marco conceptual MPS Fuente: Pressman 2002

17 Marco conceptual MPS Modelo de Madurez Indicadores de calidad del proceso Proporcionar un indicio global de la madurez del proceso que muestra una organización de software, es decir, un indicio de la calidad del proceso de software, el grado en el que los profesionales entienden y aplican el proceso, y el estado general de la práctica de ingeniería del software. Medida global de la calidad del proceso Calidad del producto

18 Modelo de madurez Indicio global de la madurez del proceso que muestra una organización de software Un indicio de la calidad del proceso de software, el grado en el que los profesionales entienden y aplican el proceso, y el estado general de la práctica de ingeniería del software.

19 Esto se logra usando algún tipo de escala ordinal. Por ejemplo, el Modelo de madurez de capacidad del Software Engineering Institute sugiere cinco niveles de madurez [Sch96]:

20 Nivel 5, optimizado. La organización tiene sistemas de realimentación cuantitativa para identificar las debilidades del proceso y fortalecer esos puntos de manera proactiva. Los equipos de proyecto analizan defectos para determinar sus causas; los procesos de software se evalúan y actualizan para evitar que recurran tipos conocidos de defectos.

21 Nivel 4, gestionado. Métricas de proceso de software y de calidad de producto detalladas establecen el cimiento de evaluación cuantitativa. Las variaciones significativas en el desempeño del proceso pueden distinguirse del ruido aleatorio, y pueden predecirse las tendencias en las cualidades del proceso y el producto.

22 Nivel 3, definido. Los procesos para administración e ingeniería se documentan, estandarizan e integran en un proceso de software estándar para la organización. Todos los proyectos usan una versión aprobada y a la medida del proceso de software estándar de la organización para desarrollo de software.

23 Nivel 2, repetible. Se establecen procesos de administración de proyecto básicos para rastrear costo, calendario y funcionalidad. La planificación y administración de nuevos productos se basa en la experiencia con proyectos similares.

24 Nivel 1, inicial. Pocos procesos definidos, y el éxito depende más del esfuerzo heroico individual que de seguir un proceso y usar un esfuerzo sinérgico de equipo.

25 Muchas organizaciones muestran niveles de inmadurez de proceso. Schorsch [Sch06] sugiere cuatro niveles de inmadurez que se encuentran frecuentemente en el mundo real de las organizaciones de desarrollo del software:

26 Nivel 0, negligente. Fracaso para permitir que tenga éxito un proceso de desarrollo exitoso. Todos los problemas se perciben como problemas técnicos.

27 Nivel 1, obstructivo. Se imponen procesos contraproducentes. Los procesos se definen rígidamente y se adhieren a la forma que subrayan. Abundan las ceremonias rituales. La administración colectiva impide la asignación de responsabilidad.

28 Nivel 2, despreciador. No se preocupa por la buena ingeniería de software institucionalizada. Hay desunión completa entre actividades de desarrollo de software y actividades de mejoramiento del proceso de software y falta completa de programas de capacitación.

29 Nivel 3, socavación. Desprecio total por la propia organización, descrédito consciente de los esfuerzos de mejoramiento del proceso de software de los pares de la organización. Recompensa al fracaso y al pobre desempeño.

30 Bibliografía Pressman, R.S., Ingeniería del Software. Un enfoque práctico, quinta edición, 2002, España. Sommerville I., Ingeniería de Software, Addison-Wesley, 6ª. Edición, 2002, México. McConnell Steve, "Desarrollo y Gestión de proyectos informáticos", Ed. McGraw-Hill, 1997, España.

31 Gracias por su atención