Control de calidad del Software

Presentación del tema: "Control de calidad del Software"— Transcripción de la presentación:

1 Control de calidad del Software
Ingeniería del Software Lic.Marisa Gouget UCSA 2006

2 Mindmapping CALIDAD

3 Definiciones de Calidad
La totalidad de las características de un producto o servicio que le confieren aptitud para satisfacer necesidades establecidas e implícitas ISO Calidad de software es cumplir con los requerimientos del cliente más la formalidad del proceso con que fue desarrollado SEI SEI: Instituto de Ingeniería del Software. Creadores de CMM.

4 Definiciones de Calidad
Una definición de calidad de software es: El conjunto medible de atributos del producto y del proceso de producción, los cuales permiten determinar con claridad los costos, beneficios y riesgos potenciales de su desarrollo, utilización/comercialización y posterior evolución.

5 Atributos de Calidad de Productos y Procesos
Requerimientos Mantenibilidad Confiabilidad Seguridad Rendimiento Disponibilidad Definido Documentado Soportado Conocido Practicado Medido Mejorable Proceso Producto: ¿qué atributos de calidad debe tener el producto? Proceso Un proceso no definido no puede ser controlado (o medido) Un proceso no controlado no puede ser mejorado Intentar mejorar un proceso inestable puede producir mas inestabilidad

6 Problemas y costos de la No calidad
Requerimientos no cumplidos, mal interpretados Entregas tardías Diseños mal realizados Errores detectados por los clientes Errores de alto riesgo Malas políticas de testing Costos relacionados Altos costos de retrabajo Altos costos de soporte Costos de oportunidad Pérdida de mercados Defectos recurrentes

7 Costo de Calidad Costos asociados a la Calidad: Prevención Evaluación
Planificación de calidad RTF Equipos de Pruebas Formación Evaluación Inspección en el proceso y entre procesos Calibrado y mantenimiento del equipo Pruebas Fallos Internos (Retrabajo, Reparación, Análisis de fallos) Externos (Resolución de quejas, Sustitución de productos, Soporte) El costo de calidad incluye todos los costos acarreados en la búsqueda de la calidad o en las actividades relacionadas en la obtención de la misma. Los costos de calidad se pueden dividir en costos asociados con: Prevención  se incluyen: planificación de la calidad, revisiones técnicas, equipo de pruebas, formación, etc Evaluación  incluye actividades para tener una visión mas profunda de la condición del producto “la primera vez a través de”cada proceso. Por ej.: inspeccción en el proceso y entre procesos, calibrado y mantenimiento del equipo, pruebas Fallos  son costos que desarecerían si no surgieran defectos antes del envío de un producto al cliente. Fallos Internos: se producen cuando se detecta un error en el producto antes de su envío. Ej.: revisión, reparación, análisis de las modalidades de fallos. Fallos Externos: asociados a los defectos encontrados una vez enviado el producto al cliente. Ej.: resolución de quejas, devolución y sustitución de productos, soporte de línea de ayuda, trabajo de garantía. Los costos relativos para encontrar y reparar un defecto, aumentan dramáticamente a medida que se cambia de prevención a detección, y desde fallo interno al externo.

8 Procesos principales de la gestión de calidad
Planificación de la calidad: identificación de los estándares de calidad y de cómo satisfacerlos. Aseguramiento de la calidad: evaluación del desempeño completo del proyecto para brindar confianza en que el proyecto cumplirá con los estándares de calidad. Control de calidad: verificación del cumplimiento de los estándares de calidad y modo de eliminar causas de desempeño insatisfactorio.

9 Planificación de la calidad
Entradas: Políticas de calidad Enunciación del alcance Descripción del producto Estándares y regulaciones Otras salidas de procesos Salidas: Plan de gestión de la calidad Definiciones operativas Listas de verificación Entradas a otros procesos Técnicas y herramientas: Análisis costo/beneficio Estudios comparativos Diagramas de flujo Diseño de experimentos Costo de la calidad

10 Aseguramiento de la calidad
Entradas: Plan de gestión de la calidad Resultados de las mediciones de control de calidad Definiciones operativas Salidas: Mejora de la calidad Técnicas y herramientas: Técnicas y herramientas de la planificación de la calidad Auditorías de la calidad

11 Control de la calidad Entradas: Técnicas y herramientas: Salidas:
Resultados de los trabajos Plan de gestión de la calidad Definiciones operativas Listas de verificación Salidas: Mejora de la calidad Decisiones de aceptación Reproceso Listas de verificación completadas Ajustes al proceso Técnicas y herramientas: Inspección Gráficos de control Diagramas de Pareto Muestreo estadístico Diagramas de flujo Análisis de tendencias

12 Herrramientas para la planificación de la calidad Diagramas causa-efecto
Tiempo Máquinas Método Material Energía Mediciones Personal Ambiente Defecto Causas potenciales Efecto Herramienta creada por Ishikawa para analizar por categorías los factores principales que influyen en un proceso, evitando prestar atención solamente a algunas causas.

13 Herrramientas para el control de la calidad Diagramas de pareto
Herramienta creada por Pareto, es un gráfico de barras que muestra en forma descendente y de izquierda a derecha la importancia de cada categoría de datos que permite armar la curva ABC conocida como 20-80

14 Control de calidad del software (SQA) Pressman
Para garantizar la calidad del software necesitamos: Enfoque a la gestión de calidad Tecnología (métodos y herramientas) de ingeniería de Software y un equipo de SQA Revisiones técnicas formales durante todo el proceso Una estrategia de pruebas Control de documentación del software y de los cambios realizados Procedimientos Mecanismos de medición y de generación de informes

15 Control de calidad del software (SQA)
De proceso De producto

16 Actividades del control de calidad del software (SQA)
Establecimiento de un plan de SQA para el proyecto con: Evaluaciones a realizar Auditorías y revisiones a realizar Estándares a aplicar en el proyecto Procedimientos para información y seguimiento de errores Documentos a producir Realimentación de información de desarrollo

17 Actividades del control de calidad del software (SQA)
Participación del grupo SQA en el desarrollo de la descripción del proceso de software (proceso vs políticas, procesos de negocios, etc) Revisión de las actividades de ingeniería de software para verificar su ajuste al proceso definido. Auditoría de los procesos de software. Aseguramiento de la documentación de los desvíos del producto y aplicación del procedimiento establecido. Registro de lo que no se ajuste e informe a los superiores. Coordinación del control y gestión de cambios Colaboración en la recopilación y el análisis de las métricas del software.

18 Revisiones técnicas formales
Objetivos: Descubrir errores en la función, la lógica o la implementación de cualquier representación del software. Verificar que el software bajo revisión alcanza sus requirimientos. Garantizar que el software ha sido representado de acuerdo a ciertos parámetros estándares predefinidos. Conseguir un software desarrollado de forma uniforme. Hacer que los proyectos sean más manejables.

19 Revisiones técnicas formales
Reunión de revisión para: Aceptar el producto Rechazar el producto Aceptar provisionalmente el producto Registro de la revisión: ¿Qué fue revisado? ¿Quién lo revisó? ¿Qué se descubrió y cuáles fueron las conclusiones?

20 Revisiones técnicas formales
Directrices para la revisión: Revisar el producto, no al productor Fijar una agenda y mantenerla Limitar el debate y las impugnaciones Enunciar áreas de problemas, pero no intentar resolver cualquier problema Tomar notas escritas Limitar el número de participantes e insistir en la preparación anticipada Desarrollar una lista de comprobación para cada producto que se vaya a revisar Disponer de recursos y tiempo para las RTFs, que se deben planificar junto con el proceso de ingeniería de software. Llevar a cabo un buen entrenamiento de todos los revisores en el proceso de revisión (técnica) y en psicología humana (ej. Trabajo en equipo). Revisar las revisiones anteriores.

21 Revisión Técnica Formal
Proceso de una RTF Se realiza la RTF. El productor le informa al líder que ha terminado su producto. Productor El líder evalúa si el producto está en condiciones de pasar a una RTF. Líder de Proyecto Distribuye las copias a los revisores. Agenda la RTF. Jefe de Revisión Los revisores realizan la revisión previa a la reunión. Revisores Toma las anotaciones correspondientes para generar: La lista de sucesos de revisión y el informe sumario de revisión. Le pasa los informes al productor para que realice las correcciones pertinentes. Archiva la documentación para futuros controles. Registrador Proceso de una Revisión Técnica Formal

22 Estándares de calidad Otros aspectos de calidad:
Fiabilidad del software (Probabilidad de operación libre de fallos, en un entorno y tiempo determinado): TMEF = TMDF + TMDR (tiempo medio entre fallos = tiempo medio de fallo + tiempo promedio de reparación) Disponibilidad del software (Probabilidad de que un prg funcione de acuerdo con los req en un momento dado): Disponibilidad= TMDF/(TMDF+TMR) *100

23 Estándares de calidad - Normas ISO
ISO 9001: es un estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño. ISO : es un documento específico que interpreta ISO 9001 para el desarrollador de SW. ISO : soporta las directrices para el servicio de soporte a usuarios.

24 Factores de Calidad según ISO 9126
· Funcionalidad : Adaptación, Exactitud, Interoperación, Seguridad. · Confiabilidad: Madurez, Tolerancia a Defectos, Facilidad de Recuperación. · Eficiencia: Comportamiento en el Tiempo, de los Recursos. · Facilidad de Uso: Facilidad de Comprensión, de Aprendizaje, de Operación. · Facilidad de Mantenimiento: Facilidad de Análisis, de Cambios, de Pruebas, Estabilidad. · Portabilidad: Adaptabilidad, Facilidad de Instalación, de Reemplazo.

25 Árbol de las características de calidad del software. IEEE 1976
Independiente del HW Autocontenido Seguro Portabilidad Compelto Integro/Robusto Confiabilidad Consistente Utilidades Generales Para el uso Eficiencia Trazable Eficiente con el HW Ingeniería Humana Accesible Comunicativo Testeable Auto descriptivo Para el Mantenimiento Estructurado Comprensible Conciso Legible Modificable Escalable

26 Calidad del Software Ingeniería del Software UCSA
CMM Calidad del Software Ingeniería del Software UCSA

27 Qué es un modelo de procesos?
Un modelo es una colección estructurada de elementos que describen las caractéristicas de un proceso eficiente y eficaz. Un buen modelo de procesos contiene un gran cantidad de experiencia de campo dentro de su estructura.

28 Qué es CMM Una aplicación del sentido común para el gerenciamiento de procesos y conceptos de mejora de la calidad del desarrollo y mantenimiento del software Una guía desarrollada por y para la comunidad profesional del software Un modelo para la mejora organizacional Una estructura confiable y consistente para evaluar y mejorar las capacidades de una organización En que consiste el CMM El Modelo de Madurez de Capacidades (conocido en inglés como "Capability Maturity Model" o por su sigla CMM) es un modelo de prácticas fundamentales que deben ser implementadas por toda organización interesada en desarrollar y mejorar la calidad de sus productos y su productividad. Este modelo está basado en conceptos de calidad total y de mejoramiento continuo; ha sido elaborado por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon y ha sido ampliamente aceptado por la comunidad de ingeniería de software. Se ha convertido en el estándar para evaluar la madurez de los procesos dentro de las diferentes organizaciones que producen software en todo el mundo. El SEI ha desarrollado algunos métodos de evaluación basados en este modelo. Uno de estos métodos es la evaluación basada en CMM para el mejoramiento interno de procesos, generalmente conocido como CBA IPI ("CMM -Based Appraisal for Internal Process Improvement"); aunque su principal objetivo es permitir a la empresa la determinación de sus fortalezas y necesidades de mejoramiento, también permite revisar las prácticas de los proveedores externos, a objeto de que puedan derivar un plan de mejoramiento adecuado a su organización. La creciente necesidad, sumada a décadas de promesas incumplidas en cuanto a calidad, costos y cumplimiento en el desarrollo de software, condujo al Instituto de Ingeniería de Software de los Estados Unidos a desarrollar el modelo CMM (Capability Maturity Model - Modelo de Madurez de Capacidad). En principio creado para evaluar y mejorar la capacidad de los contratistas de software del Departamento de Defensa de los Estados Unidos, el modelo CMM se convirtió a través de los años en el más alto estándar de ingeniería en el mundo para todo tipo de compañías. Está fundamentado en prácticas reales de las compañías mas avanzadas del planeta, y refleja el estado del arte en procesos de desarrollo de software.

29 Qué puedo hacer con CMM ? Ayudar a la comunicación, al establecer un lenguaje común en el ámbito organizacional Facilitar poner el foco de atención en cuestiones críticas Proveer recomendaciones generales Ayudar a priorizar acciones de mejora Alcance de CMM: Excluye todas las disciplinas de implementación (desarrollo de hard, firmeware y soft) Excluye disciplinas especiales de ingenieria (petroleo, electrica, comunicaciones) Pero se extiende hasta tocar sus limites

30 Niveles de Madurez Se define al nivel de madurez como la capacidad de los procesos de ingeniería de software y de administración de proyectos usados en una organización de desarrollo de software.

31 Estructura del CMM Nivel de Madurez Areas claves Objetivos
Actividades a ejecutar Compromiso Para ejecutar Habilidades necesarias Medición y Análisis Contiene Debe alcanzar Facilidades comunes para la implantación Verificación de Implantación Los niveles constituyen la estructura de más alto nivel del CMM. Deben ser interpretados como estadios evolutivos, los cuales se sustentan en la implementación de los niveles más bajos. Con excepción del Nivel 1, cada uno de estos Niveles de Madurez está compuesto por un cierto número de Áreas Claves de Proceso, conocidas a través de la documentación del CMM por su sigla inglesa: KPA. Cada KPA identifica una agrupación de actividades y prácticas relacionadas, las cuales cuando son realizadas en forma colectiva permiten lograr alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: ·         Gestión, ·         Organizacional e ·         Ingeniería. Las prácticas que deben ser realizadas por cada Área Clave de Proceso están organizadas en 5 Características Comunes, las cuales constituyen atributos que indican si la implementación y la institucionalización de un proceso clave es efectivo, repetible y duradero.

32 CMM Nivel 1: Inicial Ambiente inestable que carece de prácticas de management Los compromisos no están bajo control Los éxitos se basan en el talento individual y el esfuerzo de los héroes Las buenas prácticas y estándares son frecuentemente sacrificadas por otras prioridades del management Usualmente se cuenta con cronogramas La capacidad del proceso es impredecible Los objetivos de cronograma, costos y calidad no se hallan definidos (Andá y hacelo!) El nivel 1 o inicial es el estado primario en la evolución de las organizaciones que desarrollan software. Una definición amplia es que en este nivel se encuentran todas las empresas que no han logrado implementar las prácticas básicas de gestión de proyectos e ingeniería de software definidas a partir del nivel 2 o superiores. Una empresa está en el nivel caótico cuando sus gerentes y personal afirmen que los proyectos no se pueden planear, que los requerimientos no se pueden tener bajo control, que no esté siempre en condiciones de controlar las versiones de producto, donde la calidad sea percibida como una burocracia innecesaria, cuando se acepte que los procesos son una cosa personal, cuando no se pueda verificar ni validar el producto, y sobre todo, cuando sus gerentes y personal vivan bajo condiciones de stress y frustración permanentes Se lo llama “nivel de heroísmo”, ya que en este tipo de empresas, el software es virtualmente producto del arte más que de la ingeniería. Cada "artista" crea su proceso propio independientemente del de los demás integrantes de la empresa dando a la gerencia un gran trabajo al tener que dedicar una parte significativa de su tiempo a enfrentar problemas y clientes insatisfechos. Ante una situación de crisis permanente, se les hace difícil destinar recursos para definir o documentar procesos, lo que lleva a un círculo sin salida, normalmente concluyendo en el fin de la empresa.

33 CMM Nivel 2: Repetible La necesidad es establecer una administración efectiva del proyecto de software Los procesos de Administración de Proyectos están definidos e implementados Las políticas organizacionales guían los proyectos Las prácticas exitosas usadas en proyectos previos, puede ser repetidas. El nivel 2 o Repetible hace posible la implementación de prácticas mínimas de administración de proyecto, de control de requerimientos, versiones de producto y de proyectos realizados por subcontratistas. El grupo o equipo humano que realizó el proyecto puede aprovechar su experiencia e inversión en procesos para aplicarla en un nuevo proyecto. Este nivel no garantiza que todos los proyectos dentro de la empresa estén necesariamente al mismo nivel de madurez. Algunos pueden estar todavía en el nivel inicial. El mayor beneficio obtenido de la implementación del nivel 2, es el planeamiento realista de los proyectos. Dentro de esta planificación se incluyen cronogramas que se hacen día a día más confiables, mejorando a medida que se acumula más información en las bases de datos de los proyectos pasados. El uso generalizado de métodos de estimación permite al personal del proyecto de justificar plazos y recursos. Aún el "olfato profesional" y la experiencia personal juegan un papel importante en la generación de planes de proyecto, pero ahora son decisiones informadas en vez de simples adivinanzas como ocurre en empresas que no llegan a este nivel. Como desventaja de este nivel se puede observar que mas allá de que se comparta información y experiencias sobre la administración de los proyectos, estos todavía difieren en la metodología en la cual se realizan, es decir, aun existe la incomunicación entre proyectos y grupos, y entre el personal y la gerencia.

34 CMM Nivel 3: Definido Los procesos de software están definidos, documentados, y son aplicados a través de toda la organización. Comprensión compartida de como funciona el proceso y roles establecidos La capacidad de los procesos satisface objetivos de cronograma, costos, y funcionalidad Dentro de este nivel se puede observar un nivel de maduración de la empresa. Toda la empresa operara en torno a un conjunto de procesos, metodologías y herramientas comunes que se aplicaran a todos los proyectos iniciados por la corporación. Este proceso común está suficientemente documentado y es accesible a todos los desarrolladores, todo el personal debe recibir el entrenamiento necesario para entenderlo. Existen pautas y criterios definidos para adaptar dicho proceso a las necesidades y características propias de cada proyecto. El nivel de definición es detallado y completo. La dependencia (o el riesgo de depender) en individuos irreemplazables es baja. Igual que en el nivel anterior se utiliza una base de datos, esta vez mas completa, que reúne estadísticas de los proyectos pasados y en curso, que es de mucha ayuda a la hora de planificar y comparar el rendimiento. Se realizan revisiones regulares, mejorando notablemente la calidad de los productos y minimizando las reiteraciones innecesarias. Se incorporan además, mecanismos de comunicación entre proyectos y departamentos, lo que garantiza una visión común del producto y una rápida acción para enfrentar los problemas. Este nivel se caracteriza por lograr satisfacción del personal. En este punto los gerentes pueden realizar su verdadera función, administrar.

35 CMM Nivel 4: Administrado
La efectividad del proceso es medida. El control estadístico del proceso es iniciado. Se sigue un proceso que apunta a las causas de desviaciones en el producto. Antes de comenzar a detallar las características de este nivel cabe destacar que son muy raras las empresas que han decido implementar este nivel. No son muchos especialistas de procesos que realmente tengan experiencia práctica, o incluso que entiendan bien las áreas claves de proceso del nivel 4. Son solamente 2 prácticas, pero imposibles de alcanzar si no se ha implementado firmemente los 2 niveles de madures anteriores. En este nivel la corporación mide la calidad del producto y del proceso de software. Ambos, producto y proceso, son seguidos en forma cuantitativa y se controlan mediante métricas detalladas. La capacidad de rendimiento del proceso es previsible. Las mediciones permiten detectar cuando las variaciones del rendimiento se salen de los rangos aceptables, de manera de poder tomar medidas correctivas para asegurar la calidad. La empresa es capaz de proponerse metas cuantitativas para la calidad de los productos y de los procesos de software. Es posible medir la productividad y calidad de los procesos de software a través de todo el proyecto. Los proyectos pueden controlar la variación del rendimiento de sus productos y procesos para mantenerla dentro de fronteras cuantitativas aceptables.

36 CMM Nivel 5: Optimizado Los factores que imposibilitan la realización, son identificados y eliminados. La mejora continua está institucionalizada La transición a nuevas tecnologías es practicada rutinariamente Este nivel, también conocido como el Nivel Optimizado. Además es se puede considerar que este nivel es un estado IDEAL. El nivel 5 tiene como característica principal el mejoramiento continuo del proceso, en base a la realimentación cuantitativa y al ensayo de ideas y tecnologías innovadoras. La organización entera se aboca al mejoramiento continuo del proceso. La corporación cuenta con los medios para identificar las debilidades y reforzar en forma proactiva el proceso, con objeto de prevenir la ocurrencia de defectos. Los datos relativos a la eficacia del proceso de software se usan para analizar el costo y el beneficio de usar nuevas tecnologías y de implementar cambios al proceso de software. Los proyectos de software analizan los defectos para determinar sus causas. Los proceso de software se evalúan para prevenir que los defectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidas son difundidas a otros proyectos.

37 Conclusiones El CMM codifica buenas prácticas existentes
Es independiente de la tecnología y del área Es difícil salir del nivel 1 Se puede ser exitoso en el nivel 1 Se puede ser un fracaso en el nivel 3 Es aplicable a todo tipo y tamaño de organizaciones de software

38 Los problemas de CMM y la solución
Las disciplinas de Software y Sistemas nuncan han sido bien integradas La Importancia e influencia del software en los sistemas se ha incrementado dramáticamente La solución: CMMI Integrar las disciplinas de software y sistemas en un marco de mejoras a los procesos. Proveer un marco de trabajo para introducir nuevas disciplinas según necesidades. Depende de la disciplina que quiera modelar: Ingenieria de Software Ingenieria de Sistemas Adquisición de Software Seguridad de Sistemas Infraestructura tecnológica etc Muchos modelos y poco tiempo: Diferentes estructuras, formatos, términos y maneras de medir la madurez Estas son causa de confusiones, especialmente cuando se usa más de un modelo Duros para integrarlos en un único programa de SPI Es muy complejo usar múltiples modelos para la selección de proveedores

39 Mejoras de CMMI sobre CMM
Enfasis en mejoras medibles para lograr objetivos del negocio Han sido agregadas Areas de Procesos para poner más enfasís en algunas prácticas importantes Gestión de Requerimientos Ingeniería de Procesos Análisis de las decisiones CMMI es significativamente más grande que el CMM: Más objetivos y prácticas Más áreas de proceso Más detalles Algunas conclusiones – Método de evaluación : El método de evaluación para CMMI es el SCAMPI Es similar al CBA-IPI de CMM Ajustable a la organización y/o alcance del modelo Demanda más tiempo y esfuerzo que una avaluación del SW-CMM

40 Ventajas del CMMI Arquitectura del modelo más robusta y con mayor nivel de detalle Aplicable a más de una disciplina Mejor atención a las áreas de ingeniería La representación continua permite focalizar mejoras de acuerdo a los objetivos del negocio

41 Desventajas del CMMI Tamaño y complejidad mucho mayor que modelos vigentes El proceso de avaluación es más costoso en tiempo y esfuerzo La complejidad de la evaluación continua puede atentar contra la definición de objetivos concretos de madurez

42 Conclusiones Si usted viene del mundo del CMM trabaje con el modelo por niveles Si usted tiene bien claros los objetivos de su negocio y las debilidades de sus procesos, y además entiende las relaciones entre las áreas de proceso, la representación continua puede ser una buena alternativa Para ambos casos, defina un plan de migración sobre la base de su madurez actual y una buena comprensión de su negocio/productos

43 Gestión de configuración del software
Ingeniería del Software Lic.Marisa Gouget UCSA 2006

44 Gestión de Configuración de Software Definición
“La gestión de configuración es una actividad de auto protección que se aplica a lo largo del proceso de la Ingeniería de Software y que tiene como objetivo identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo.” Babich y Pressman

45 Gestión de Configuración de Software Definición
NO ES Mantenimiento del Software

46 Actividades de la GCS Identificar el cambio Controlar el cambio
Garantizar que el cambio se implementa adecuadamente Informar del cambio a los interesados.

47 Elementos de Configuración
La Ingeniería del software produce: Programas Datos Documentos Todos ellos se transforman en elementos de configuración del software.

48 Los cambios “Sin importar en qué momento del ciclo de vida nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida”. Los cambios se producen por: Nuevos requerimientos del negocio Nuevas necesidades del usuario Reorganización comercial Restricciones de presupuestos o planificaciones

49 Los cambios La GCS es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software. La GCS es una actividad de garantía de calidad que se aplica en todas las fases del proceso de la ingeniería del software.

50 Líneas de Base Una línea de base es una especificación o producto que se ha revisado formalmente, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

51 Líneas de Base La Línea de base es un punto de referencia en el desarrollo del software que queda marcado con la aprobación de uno o más elementos de configuración del soft. Se pueden establecer por ejemplo al terminar cada fase del ciclo de vida que se esté utilizando.

52 Líneas de Base Ingeniería del Sistema Análisis de Requisitos
Diseño del Software Codificación Prueba Entrega Especificación Del sistema de requisitos Del diseño Planes, procedimientos, datos de pruebas Código fuente Sistema en funcionamiento

53 Elementos de configuración Ejemplos
Especificación del sistema Plan del Proyecto de Software Especificación de requisitos del software: Modelo del análisis Especificaciones de Procesos Prototipos Manual de usuario Especificación del diseño Listados de códigos fuentes Especificación de las pruebas Manuales de operación y ejecución Programas ejecutables Descripción de la base de datos Etc....

54 Líneas de Base y Elementos de Configuración Relación
Una línea de base Varios elementos De configuración

55 El proceso de la GCS Identificación los elementos de configuración
Control de versiones Control de cambios Auditorías de Configuración: Revisiones formales Auditorías de configuración Generación de informes

56 El proceso de la GCS 1.- Identificación los elementos de configuración
Identificar y organizar los objetos como básicos y compuestos (colección de básicos y compuestos) Identificar al objeto con un nombre que lo identifique unívocamante. Identificar las relaciones entre los objetos. Documentarlos con gráficos o notaciones.

57 El proceso de la GCS 2.- Control de versiones
Combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creados durante el proceso de ingeniería de software. Cada versión del software es un colección de ECS y cada versión puede estar compuesta de diferentes variantes. A cada componente se le asigna una tupla de atributos, lista de características que definen si se ha de utilizar el componente cuando se va a construir una determinada versión del software.

58 El proceso de la GCS 3.- El proceso del Control de cambios
Combina procedimientos humanos y herramientas. Elementos del control de cambios: Petición del cambio Autoridad de control de cambios (ACC) Orden de Ingeniería de cambios (OCI) Procesos de alta y baja de objetos (control de acceso y sincronización) Nivel del cambio: informal (antes de la línea de base), a nivel del proyecto (cambio local) o formal (cuando el software está en los clientes).

59 El Proceso Formal del Control de Cambios
El usuario reconoce la necesidad del cambio El usuario pide el cambio El desarrollador lo evalúa Se genera un informe de cambios La autoridad de control de cambios decide Se genera la orden Se rechaza de cambio el cambio Se informa al usuario

60 El Proceso Formal del Control de Cambios
Se genera la orden de cambio Se identifican los elementos de configuración afectados Se dan de baja los ECS (sincronización) Se realiza el cambio Se audita el cambio Se aprueba el cambio Se dan de alta los ECS afectados Se incluyen cambios en producción Se revisan los cambios en todos los ECS Se distribuye una nueva versión con los cambios

61 El proceso de la GCS 4.- Auditorías de Configuración
Revisiones técnicas formales: es una reunión con determinadas premisas que se centra en la corrección técnica del ECS que ha sido modificado, evaluando su consistencia con otros ECS, las omisiones o efectos secundarios. Auditorías de configuración: es una actividad independiente que es llevada a cabo por el grupo de garantía de calidad y tiene como objetivo asegurar que se ha hecho, revisado, implementado y comunicado correctamente el cambio, de acuerdo a los estándares.

62 Es una actividad que documenta (contabiliza):
El proceso de la GCS 5.- Generación de informes de estado de configuración (IEC) Es una actividad que documenta (contabiliza): ¿Qué pasó? ¿Quién lo hizo? ¿Cuándo pasó? ¿Qué más se vio afectado? en cada paso del proceso formal del control de cambios. Su objetivo es el de mejorar la comunicación entre todas las personas involucradas en el proyecto.