Contenidos de la asignatura

Transcripción

1 Ingeniería a del software Departamento de Lenguajes y Sistemas Informáticos

2 Contenidos de la asignatura Introducción Definiciones La calidad del software Arquitecturas de varios niveles (JAVA) Evaluación y pruebas del software Reutilización 2

3 Introducción: n: Definiciones (I) Alcance del proyecto (PMBOK versión tres en castellano): Describe en detalle, los productos entregables del proyecto y el trabajo necesario para crear tales productos entregables. Autor del proyecto: Persona u organización que es responsable de realizar el proyecto. Calidad ( ) Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor Externos: Corrección, Robustez, Extensibilidad, Reusabilidad, Compatibilidad, Eficiencia, Portabilidad, Facilidad de Uso, Funcionalidad, Oportunidad Internos: Modularidad y legibilidad En principio sólo importan los externos, pero la clave para conseguirlos radica en los factores internos Cliente (norma ISO 9000: 2000 (2.3.5) y SE-CMM SEI) Persona u organización que recibe un producto o servicio. También uno de los que usa el producto o servicio. NOTA: Un cliente puede ser interno o externo a la organización del suministrador. 3

4 Introducción: n: Definiciones (II) Diseño (SE-CMM SEI): Proceso de definición de la arquitectura, componentes, interfaces, y otras características de un sistema o componente. Desarrollo (SE-CMM SEI): Proceso de transformación de un diseño en componentes hardware y/o software. Documento: Información registrada que puede considerarse como una unidad en un proceso de documentación. Especificación ( IEEE 729, IEEE , SE-CMM 1995, MIL-STD 499B ) Documento que establece, de una manera completa, precisa, verificable, los requisitos, comportamiento, u otras características de un sistema o componente y los procedimientos de verificación para determinar su grado de cumplimiento. Evaluación (SA-CMM: 1996) El uso de revisiones, inspecciones, y /o pruebas para determinar que un producto o servicio software, hardware, etc., satisface los criterios o especificaciones previamente establecidos. 4

5 Introducción: n: Definiciones (III) Ingeniería IEEE: aplicación de un método sistemático, estructurado y cuantificable a estructuras, máquinas, productos, sistemas o procesos. conjunto de conocimientos y técnicas que permiten aplicar el saber científico a la utilización de la materia y fuentes de energía. Ingeniería del software Ingeniería del Software es la ingeniería que trata de construir software de alta calidad a bajo costo Meyer 1988: la IS es la producción de software de calidad. Ford, 1990: IS es una forma de ingeniería que aplica los principios de la ciencia de los computadores y matemáticas para conseguir soluciones a los problemas del software de forma efectiva y económica. IEEE 1993: IS es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. 5

6 Introducción: n: Definiciones (IV) Proceso (ISO 9000: 2000 (2.4.1) y ISO 12207:1995) Conjunto de actividades interrelacionadas que usan recursos para transformar entradas en salidas. NOTAS: Las entradas a un proceso son típicamente salidas de otro proceso. Los procesos en una organización están típicamente planificados y llevados a cabo bajo condiciones controladas para añadir valor. Un proceso donde la conformidad del producto resultante no puede evidenciarse o verificarse económicamente es referido frecuentemente como un proceso especial Proceso de ingeniería del producto software: Conjunto de actividades, métodos, prácticas y transformaciones utilizados para desarrollar software y los productos asociados: planes del proyecto, documentos de análisis/diseño, codificación, casos de prueba, manuales de usuario. Los mayores niveles de calidad se consiguen paso a paso: mejora del proceso software Producto (ISO 9000: 2000 (2.4.2) Resultado de un proceso. NOTA: Cuatro categorías mencionables: hardware, software, comunicaciones, servicios. 6

7 Introducción: n: Definiciones (V) Proyecto: Conjunto de actividades planificadas y coordinadas, controladas, presupuestadas, y documentadas con fechas de comienzo y finalización, que se emprende para alcanzar unos objetivos conforme a requisitos específicos, por una organización temporal adaptada a sus necesidades Resultado (PMBOK-2004) Es la consecuencia de la ejecución de procesos y actividades de gestión de proyectos. Los resultados incluyen consecuencias (por ej., sistemas integrados, procesos revisados, organización reestructurada, pruebas, personal capacitado, etc.) y documentos (por ej., políticas, planes, estudios, procedimientos, especificaciones, informes, etc.). Requisito (ISO 9000:2000) Necesidad o expectativa que se establece de forma explícita o implícita. 7

8 Introducción: n: Definiciones (VI) Servicio (ISO 9000: 2000 (2.4.3)) Producto intangible que es el resultado de realizar al menos una actividad en la interfaz entre el suministrador y el cliente. Sistema (Norma ISO/IEC 15288:2002) Conjunto de elementos interrelacionados e interactuantes en uno o más de los procesos que proporcionan la capacidad de satisfacer una necesidad u objetivo definido. NOTA: Un sistema puede ser considerado como un producto o como el servicio que proporciona. Suministrador (Norma ISO 9000: 2000 (2.3.6)) Organización o persona que suministra un producto. NOTA: En una situación contractual a un suministrador puede denominársele también contratista. Usuario Una persona u organización que usa el sistema para realizar una función específica. Validación (ISO/IEC 12207: 1995) y SE-CMM:1995) Confirmación mediante examen y provisión de evidencia objetiva de que se cumplen los requisitos particulares para ser usado con un propósito específico y que satisface las necesidades del cliente. 8

9 Calidad del software Juan M. Pikatza Departamento de Lenguajes y Sistemas Informáticos

10 Objetivos Clarificar el significado del término calidad en el desarrollo del software Identificar los diferentes aspectos a considerar Conocer las ventajas de la producción industrial

11 Contenidos del curso A qué se le llama calidad en el software? Cómo podemos presentar bien un proyecto al cliente? Una norma utilizable y sus exigencias Cómo conseguir la certificación de capacidad y madurez exigida por el cliente? Modelos de calidad y certificaciones Procesos y herramientas de soporte Producción industrial y mejora continua 11

12 A A qué se le llama calidad en el software?

13 Hay quien piensa que.. Burocracia y retrasos en vez de escribir código Hacer un papeleo pesado, muchas reuniones para establecer un proceso,. Para conseguir un sello para nuestra publicidad: ISO 9000, FQM: Q de oro, plata, Producto mejor que el de la competencia Para hoy y el futuro (actualización) Gestión del proceso y el conocimiento Poder repetir el éxito plazos y costos conocidos (más cortos) Garantgías 13

14 Debe preocuparnos la calidad? Los clientes quieren un producto de calidad Evalúan las soluciones de los suministradores A menudo con ayuda de auditores profesionales Proyectos con diferentes objetivos y alcances Alcance: Definición de requisitos, análisis, diseño, Exigen normas de presentación de proyectos Conveniente seguir un proceso para conseguirlo Exigen altas cotas de fiabilidad y seguridad Se consigue con un proceso pensado para la seguridad Necesitan saber con qué proceso se desarrolló Exigen un nivel dentro de un modelo de calidad de proceso 14

15 Cómo se consigue la calidad? Producción industrial Entrega en plazo con precio competitivo y calidad Esto no es habitual en el desarrollo del software Existen industrias de referencia: automóvil Como hacerlo? Sistematización del desarrollo Proceso de desarrollo definido Requisitos, análisis, diseño, implementación, gestión, pruebas, documentación, Especialización: dominio y líneas de productos Dominio, menor coste y plazos de producción conocidos Ejemplos: Dominio = e-administración Línea de producto: relaciones ciudadano-ayuntamiento 15

16 Ingeniero en Informática Relación n proveedor-cliente PROBLEMA CLIENTE El escenario completo Insatisfecho Funciona Satisfecho Responsable Requerimientos Evaluación Proceso judicial Perito FRACASO Fidelidad del cliente Superar a la competencia EXITO Solución Plazo/presupuesto Auditor Proyecto Control de calidad No cumple Cumple Producto de calidad Plazo más m s corto Suministrador Aumento de la capacidad de negocio Mejorar proceso desarrollo 16

17 Igual que en otras ingenierías Optimización de Procesos Mejora de Procesos Procesos Métodos Piezas Producto Diseños Tecnología Herramientas Gestión n del Conocimiento Conocimiento Problema Cliente Requerimientos / Evaluación Solución Plazo/presupuesto Proyecto Control de calidad Gestión n del Conocimiento Conocimiento Suministrador Optimización de Procesos Mejora de Procesos Procesos Métodos Componentes Productos Patrones Tecnología Herramientas 17

18 Merece la pena.. Elaborar bien un proyecto y presentarlo bien Aceptación venta ( $ ) permanecer en el mercado Cumplir las normas exigidas por el cliente. Normas: ISO, ISO/IEC, IEEE, MIL-STD, Métrica v.3,une,.. Modelos de calidad: SA-CMM, SE-CMM, SE-CMM, CMMI Algunos clientes utilizan la Web para informar a los clientes University of British Columbia Supply Management: Risk Management of Treasury Board of Canada Secretariat: Para poder presentar según norma Más fácil si seguimos un proceso Definir un proceso de desarrollo Ayudarnos de herramientas de soporte Certificar nuestro nivel de calidad Modelos de calidad: SW-CMM, CMMI Mejorarlo constantemente Mejorar la tecnología: I+D+i 18

19 Contenidos del curso A qué se le llama calidad en el software? Cómo podemos presentar bien un proyecto al cliente? Una norma utilizable y sus exigencias Cómo conseguir la certificación de capacidad y madurez exigida por el cliente? Modelos de calidad y certificaciones Procesos y herramientas de soporte Producción industrial y mejora continua 19

20 Cómo podemos presentar bien un proyecto al cliente?

21 Relación n cliente-suministrador Incumplimientos de contrato habituales Falta de normas auditoria problemática conflictos Desconfianza en las empresas de software Clientes y suministradores pequeños Desconocimiento y baja calidad Clientes grandes exigen calidad Muchos exigen seguir un proceso y certificaciones Preocupación: calidad, plazos y presupuestos Saber hacer no garantiza hacer bien Capacidad para repetir haciendo bien y más rápido Capacidad y madurez para hacer mejor siguiendo un proceso de mejora continua 21

22 Relación n cliente-suministrador Normas El cliente, mediante normas, exige Formato de presentación de proyectos para una mejor evaluación Administraciones públicas: Normas: Métrica v3.0 (E), Merisse (F), SSADM (UK),.. Calidad de producto Robustez, usabilidad Calidad de servicio Mantenimiento, formación,.. Seguimiento de un proceso de producción Certificación de un nivel de calidad según algún modelo Imposible sin sistematización de la producción Proceso de producción industrial 22

23 Relación n cliente-suministrador Creación n de normas Quién: Comité técnico de expertos Nivel estatal (AENOR), internacional (ISO,..) Secretaría y edición: El Colegio de la profesión Vocales: colegios, asociaciones profesionales, empresas, Administración, universidades Para quién: la sociedad Para qué: mejorar las relaciones Definición de entregables, homogeneización Auditorias, peritajes, visados, evaluaciones, mejora procesos Qué: un documento Definciones Normas acumplir 23

24 Relación n cliente-suministrador Una propuesta de norma Desarrollada en AENOR Impulsada por todos los Colegios de Ingenieros en Informática Criterios generales para la elaboración de Sistemas Informáticos En fase de alegaciones Controversia en el uso de la palabra informática 24

25 Contenidos Motivación Objeto y campo de aplicación Definiciones Requisitos generales EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 25

26 Motivación Amplio uso de los Sistemas Informáticos Disciplina relativamente nueva Falta de normas de ámbito estatal Permanentes conflictos entre las partes Necesidad de definir una norma Siguiendo el modelo de otras ingenierías EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 26

27 Motivación Petición Propuesta En otras ingenierías: Cliente Petición Propuesta Definición Solución Construcción En nuestra ingeniería: Implantación Cliente Definición Solución Definición Construcción Construcción Implantación EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 27

28 Motivación Petición Propuesta Cliente Definición Definición Solución Construcción Construcción Implantación Tradición arraigada Consecuencias: Dificultad de planificación de la construcción Impacto negativo en la calidad de producto EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 28

29 Motivación La norma contempla: Petición Propuesta Cliente Definición Solución Construcción Implantación Tiene su origen en la norma UNE Norma general de proyectos de ingeniería Objetivo: Garantizar un mínimo de calidad EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 29

30 Contenidos Motivación Objeto y campo de aplicación Definiciones Requisitos generales EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 30

31 Objeto y campo de aplicación Según el alcance del proyecto: Cliente Petición Propuesta Definición Definición del problema Captura de requisitos Análisis de requisitos Solución Elaboración completa Construcción Evaluación visado Implantación Pudiendo incluir: Auditorias Revisiones independientes Visado Peritajes EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 31

32 Objeto y campo de aplicación Cliente Según el alcance del proyecto: Petición Propuesta Definición Definición Captura del Análisis de de problema requisitos requisitos Solución Elaboración completa Construcción Evaluación visado Implantación Características a cubrir en cada caso Estructura documental del proyecto Documentación completa a entregar Sin exigir ninguna metodología o proceso Pero recomendando seguir alguno EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 32

33 Contenidos Motivación Objeto y campo de aplicación Definiciones Requisitos generales EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 33

34 Definiciones Relación de normas para consulta Definiciones de conceptos ISO, UNE, ISO/IEC, CEN-CENELEC, IEEE, etc. Eurométodo Traducida al castellano Métrica versión 3 (MAP) PMBOK - A Guide to the Project Management Body of Knowledge version 3 (PMI) Traducida al castellano EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 34

35 Contenidos Motivación Objeto y campo de aplicación Definiciones Requisitos generales EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 35

36 Requisitos generales Título que identifica el producto o servicio Documentos Generados no necesariamente de forma secuencial Obligatorios, justificar omisiones Portada: Volumen, título, tipo documento, cliente, autores, y suministrador Cada página (número) o documento electrónico: Título, documento, identificativo, versión, y fechas Capítulos y apartados según UNE De calidad, interpretables por personas diferentes a los autores Orden de prioridad de los documentos EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 36

37 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO Toda la información relevante Justifica y describe la solución Referencia común entre suministrador y cliente Comprensible no sólo por profesionales Contenido Descripción de todos los entregables Reglas de identificación y gestión de cambios Elementos a utilizar en la ejecución Método Organización Validaciones Etc. Contenidos de mayor detalle en documentos aparte fuera de la memoria 37

38 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO M0.- M1.- M2.- M3.- M4.- M5.- Hojas de identificación Introducción Objeto Antecedentes Descripción de la situación actual Normas y referencias M5.1.- Disposiciones legales y normas aplicadas M5.2.- Bibliografía M5.3.- Métodos, Herramientas, Modelos, Métricas y Prototipos M5.4.- Plan de gestión de la calidad aplicado durante la redacción del Proyecto M5.5.- Otras referencias M6.- Definiciones y abreviaturas M7.- Requisitos iniciales M8.- Alcance M9.- Hipótesis y restricciones M10.- Estudio de alternativas y viabilidad M11.- Descripción del sistema propuesto M12.- Análisis de Riesgos M13.- Organización y gestión del proyecto M14.- Planificación temporal M15.- Presupuesto 38

39 Requisitos generales Título e identificador, cliente, suministrador, resumen, duración estimada, coste, y hoja índice de la memoria M0 Título Documentos Breve explicación Indice del General objetivo, contenido y estructura Memoria M1 Objetivo final del Anexos proyecto y de la finalidad que justifica su ejecución Análisis y diseño del M2 Sistema Elementos significativos Estimación del pasado de Tamaño que y tienen su influencia Esfuerzos en el proyecto M3 Planes de Gestión de la Punto de partida Ejecución del proyecto del Proyecto Seguridad Elementos que se ven afectados por el cambio propuesto Requisitos en el proyecto del sistema M4 Presupuesto y, Utilizados en la Estudios elaboración con y entidad necesarios para la ejecución propia M5 EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO M0.- M1.- M2.- M3.- M4.- M5.- Hojas de identificación Introducción Objeto Antecedentes Descripción de la situación actual Normas y referencias M5.1.- Disposiciones legales y normas aplicadas M5.2.- Bibliografía M5.3.- Métodos, Herramientas, Modelos, Métricas y Prototipos M5.4.- Plan de gestión de la calidad aplicado durante la redacción del Proyecto M5.5.- Otras referencias M6.- Definiciones y abreviaturas M7.- Requisitos iniciales M8.- Alcance M9.- Hipótesis y restricciones M10.- Estudio de alternativas y viabilidad M11.- Descripción del sistema propuesto M12.- Análisis de Riesgos M13.- Organización y gestión del proyecto M14.- Planificación temporal M15.- Presupuesto 39

40 Requisitos generales Características funcionales y no funcionales que deba cumplir una vez construido M7 Título Documentos Establecimiento de lo que está incluido en el proyecto y todo Indice lo que General no forma parte del mismo Memoria M8 Hipótesis de Anexos partida Restricciones que Análisis se han y utilizado diseño del para la elaboración del proyecto Sistema Estimación de Tamaño y Restricciones para la ejecución Esfuerzos M9 Alternativas tenidas Planes en de cuenta Gestión de la Ejecución del Proyecto Justificación de la alternativa elegida Seguridad Razones de los descartes M10 Requisitos del sistema Visión global Presupuesto del proyecto comprensible y, por especialistas Estudios con entidad Enumeración propia de características significativas M11 EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO M0.- M1.- M2.- M3.- M4.- M5.- Hojas de identificación Introducción Objeto Antecedentes Descripción de la situación actual Normas y referencias M5.1.- Disposiciones legales y normas aplicadas M5.2.- Bibliografía M5.3.- Métodos, Herramientas, Modelos, Métricas y Prototipos M5.4.- Plan de gestión de la calidad aplicado durante la redacción del Proyecto M5.5.- Otras referencias M6.- Definiciones y abreviaturas M7.- Requisitos iniciales M8.- Alcance M9.- Hipótesis y restricciones M10.- Estudio de alternativas y viabilidad M11.- Descripción del sistema propuesto M12.- Análisis de Riesgos M13.- Organización y gestión del proyecto M14.- Planificación temporal M15.- Presupuesto 40

41 Requisitos generales Identificación de los riesgos de la fase de elaboración y de la fase de construcción M12 Título Documentos Matriz de responsabilidades Directrices para la gestión de cambios Directrices para Indice el seguimiento General Directrices control Memoria de la información Comunicación Anexos cliente-suministrador Directrices aprobación de entregables Lugar de trabajo Análisis y diseño del Sistema M13 Etc. Estimación de Tamaño y Cronograma de entregas Esfuerzos parciales, hitos intermedios y fecha Planes final del proyecto Gestión de M14 la Ejecución del Proyecto Coste total de la ejecución Seguridad con costes parciales Requisitos del sistemam15 Presupuesto y, Estudios con entidad propia EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO M0.- M1.- M2.- M3.- M4.- M5.- Hojas de identificación Introducción Objeto Antecedentes Descripción de la situación actual Normas y referencias M5.1.- Disposiciones legales y normas aplicadas M5.2.- Bibliografía M5.3.- Métodos, Herramientas, Modelos, Métricas y Prototipos M5.4.- Plan de gestión de la calidad aplicado durante la redacción del Proyecto M5.5.- Otras referencias M6.- Definiciones y abreviaturas M7.- Requisitos iniciales M8.- Alcance M9.- Hipótesis y restricciones M10.- Estudio de alternativas y viabilidad M11.- Descripción del sistema propuesto M12.- Análisis de Riesgos M13.- Organización y gestión del proyecto M14.- Planificación temporal M15.- Presupuesto 41

42 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO En función del alcance: Análisis: Modelo de análisis del sistema a construir Diseño: Arquitectura del sistema propuesto Modelos de diseño: Funcionalidad Interfaces Datos 42

43 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia Base para la elaboración del presupuesto Selección de métricas Valoración de métricas Según datos del proyecto Criterios normalizados EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 43

44 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO Forma en la que se realiza la dirección del proyecto: Gestión del alcance Gestión de plazos Gestión de costes del proyecto Gestión de la calidad Gestión de recursos humanos Gestión de comunicaciones Gestión de riesgos Gestión de adquisiciones 44

45 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO Implantación de seguridad Plan de seguridad Metodologías Herramientas Identificación de puntos críticos Por su importancia Exigidos por leyes 45

46 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO Especificación detallada de requisitos Funcionales y no funcionales De producto y de proceso Debe depender de la metodología empleada 46

47 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO Determinar y justificar el costo económico del proyecto Desglosada en capítulos 47

48 Requisitos generales Título Documentos Indice General Memoria Anexos Análisis y diseño del Sistema Estimación de Tamaño y Esfuerzos Planes de Gestión de la Ejecución del Proyecto Seguridad Requisitos del sistema Presupuesto y, Estudios con entidad propia Documentos requeridos por exigencias legales LOPD LSSI Firma electrónica Etc. EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO 48

49 Contenidos del curso A qué se le llama calidad en el software? Cómo podemos presentar bien un proyecto al cliente? Una norma utilizable y sus exigencias Cómo conseguir la certificación de capacidad y madurez exigida por el cliente? Modelos de calidad y certificaciones Procesos y herramientas de soporte Producción industrial y mejora continua 49

50 Cómo conseguir la certificación n de capacidad y madurez exigida por el cliente?

51 El cliente quiere saber cómo c desarrollamos La calidad es resultado de un proceso repetible Soluciones mantenibles, adaptables a problemas similares y evolucionables. Plazo y costo limitado No una obra genial única no repetible El cliente exige certificaciones de procesos Existen modelos de calidad para evaluar procesos: SW-CMM, CMMI, SPICE,.. No se pueden alcanzar sin seguir un proceso de desarrollo definido Proceso definido y en mejora continua (suministrador) Aumento del rendimiento y capacidad de negocio 51

52 El cliente exige certificaciones Para definir un proceso que lleve a la calidad Tenemos que ver qué exigen los modelos de calidad de procesos La calidad hay que perseguirla en todo el proceso de desarrollo Modelos de calidad más conocidos Capability Maturity Model Integration (CMMI) Capability Maturity Model (SW-CMM) ISO (SPICE ) Software Process Improvement and Capability Determination BOOTSTRAP.. El más solicitado es el CMM (SW-CMM / CMMI) El problema Demasiados roles para una organización pequeña => FRACASO Demasiado cambio para una organización grande => FRACASO La solución: adaptar el proceso al proyecto, se puede 52

53 SW-CMM / CMMI Creado por el SEI (Univ. Carnegie- Mellon). Los grandes clientes exigen niveles de evaluación de 2 y 3 (CMM) a los suministradores Del caos a la disciplina! Certificación costosa Esfuerzo Dinero SW-CMM certificación por niveles completados CMMI por niveles completados o por áreas clave completadas Capability Maturity Model (CMM) Repetible (2) Inicial (1) Definido (3) Optimizado (5) Gestionado (4) ISO 9001 ISO 9004 procesos caóticos 53

54 SW-CMM / CMMI y áreas clave proceso consistente con estándares proceso disciplinado procesos que mejoran continuamente procesos predecibles Repetible (2) Inicial (1) Definido (3) Optimizado (5) Gestionado (4) Análisis causal y resolución Innovación tecnológica proc. organiz. Implantación innovación del proceso Gestión cuantitativa de calidad y proceso Realización del proceso organizativo Enfoque del proceso organizativo Definición del proceso organizativo Gestión de formación Gestión integrada de proyecto Gestión de riesgos Gestión de requisitos Planificación de proyecto Monitorización y control de proyecto Gestión de suministradores Mediciones y análisis Aseguramiento de calidad de proceso y producto Gestión de configuración Ad hoc, procesos caóticos 54

55 SW-CMM / CMMI y áreas Entrega clave en plazo proceso consistente con estándares proceso disciplinado procesos que mejoran continuamente procesos predecibles Repetible (2) Inicial (1) Definido (3) Optimizado (5) Gestionado (4) y con cero defectos Análisis causal y resolución Innovación tecnológica proc. organiz. Implantación innovación del proceso Gestión cuantitativa de calidad y proceso Realización del proceso organizativo Enfoque del proceso organizativo Definición del proceso organizativo Gestión de formación Gestión integrada de proyecto Gestión de riesgos Gestión de requisitos Planificación de proyecto Monitorización y control de proyecto Gestión de suministradores Mediciones y análisis Aseguramiento de calidad de proceso y producto Gestión de configuración Ad hoc, procesos caóticos 55

56 El modelo de calidad SW-CMM Key Areas de SW-CMM por Nivel Ámbito Gestión Organización Ingeniería Buenas prácticas que debemos cumplir Exigentes para individuos 56

57 Modelo organizativo SW-CMM 57

58 CMM TSP - PSP CMMI es un modelo mejorado de SW- CMM TSP(Team Software Process) es un vehículo efectivo para implementar mejoras basadas en CMM 58

59 CMM TSP - PSP CMMI marco conceptual basado en las mejores prácticas de ingeniería del software para ayudar a la organización en la: Caracterización de la madurez de sus procesos Establecimiento de objetivos de mejora de procesos Establecimiento de prioridades de acción inmediata Introducción de una cultura de ingeniería del software de excelencia 59

60 CMM TSP - PSP TSP (Team Software Process) TSP añade un nivel de gestión de proyectos a PSP Enfoca en el desarrollo y mantenimiento del software con equipos multidisciplinares de alto rendimiento Nivel 5 en el manejo de equipos de 5-10 ingenieros Puede ser extendido a grandes proyectos con TSP multi-team PSP (Personal Software Process) Uso individual para ajustar costos Aplica las tareas personales más estructuradas PSP extendido con TSP puede dar soporte al desarrollo de grandes sistemas software Utilizable para acelerar el paso del nivel 2 al 5 60

61 Algún n proceso que nos lleve a CMM? Recomendaciones de consenso para ingenierías PMBOK-2004 (Project Management Institute PMI) Metodologías y herramientas CASE Las metodologías, habitualmente, están asociadas con herramientas comerciales Los principales suministradores son (por importancia): IBM Rational Software (Rational Unified Process RUP) Computer Associates/Sterling Software Select Software Tools Aonix Computer Associates/Platinum Technology 61

62 RUP PMBOK Inicialización Planificación Ejecución Control Cierre Procesos muy extendidos Inicio Elaboración Construcción Transición Modelado de negocio Requisitos Entorno Gestión de proyecto Requisitos Análisis y Diseño Implementación Test Gestión de proyecto Gestión de configuración y cambio Despliegue RUP 2005 : => inscribirse y bajar productos PMI: PMBOK Guide Edition Excerpts Welcome: => versión n 2000 gratis, versión n 2004 no :// 62

63 PMBOK-2004 ( 63

64 La evolución n de las metodologías Enfoque Ericsson Objectory Rational Software Unified Process KnowledgeWare TI Software Synon Bachman Cayenne Cadre Select Software Perspective Process Paul Allen Sterling Software Spex methodology QSS CBOT Enfoque Catalysis Protosoft Aion Interactive Development Environments Thomson Software Products Tecnología Platinum Aonix Computer Associates 64

65 Rational Unified Process (RUP) 65

66 Rational Unified Process (RUP) 66

67 Rational Unified Process (RUP) 67

68 Rational Unified Process (RUP) 68

69 Proyecto como instancia de Proceso 69

70 Herramientas de Rational 70

71 Herramientas de Rational 71

72 Otras herramientas Computer Associates ( AllFusion Aonix ( Sistemas de Tiempo-real 72

73 Cómo implantarlo en PYMES? Excusas para no incorporar un proceso Demasiados roles para una organización pequeña => Fracaso Demasiado cambio para una organización grande => Fracaso Una solución Creación de un modelo para las pequeñas organizaciones, capaz de evolucionar a medida que la empresa crece Tarea compleja, hay que introducir una disciplina de trabajo Implantando, en la medida de lo posible, en equipos pequeños Menor cambio cuando la organización es grande! Es un tema candente y existen antecedentes Los procesos caóticos habituales llevan a la desaparición de la empresa por pérdida de clientes 73

74 Procesos de desarrollo para PYMES: Antecedentes Intentos de adaptar CMM a PYMES Dynamic CMM (Laryd 00) Laryd A. and Terttu Orci T. Dynamic CMM for Small Organizations, Proceedings ASSE 2000, the First Argentine Symposium on Software Engineering, Tandil, Argentina, pp , (2000) People Capability Maturity Model (Curtis, 95) Curtis B., Hefley W.E. and Millar S. Overview of the People Capability Maturity Model, CMU/SEI-95-MM-01, Carnegie Mellon University, (1995) Aproximación matricial (Schultz, 01) Schultz D., Bachman J., Landis L., Stark M., Godfrey S. and Morisio M. A Matrix Approach to Software Process Definition. Software Engineering Workshop Greenbelt, MD, (2001). CMM nivel 2 para e-comercio (Antón, 01) Antón A.I, Carter R.A., Srikanth H., Sureka A., Williams L.A., Yang K. and Yang L. Tailored CMM for a Small e-commerce Company Level 2: Repeatable. North Carolina State University Department of Computer Science Technical Report TR , (2001) 74

75 Procesos de desarrollo para PYMES: Modelo XSS XS S personas Gestor Customer SW Quality Assurance Desarrollador 75

76 Procesos de desarrollo para PYMES: Modelo XSS XS S personas Gestor Customer SW Quality Assurance SW Engineering Group System Group System Test Group SW Configuration Manager 76

77 Procesos de desarrollo para PYMES: Modelo XSS XS S personas Proyecto Project Manager SW Quality Assurance Customer SW Quality Assurance SW Engineering Group System Group System Test Group SW Configuration Manager 77

78 Procesos de desarrollo para PYMES: Modelo XSS XS S personas Proyecto Proyecto Proyecto Project Manager SW Quality Assurance Customer SW Quality Assurance SW Engineering Group System Group System Test Group SW Configuration Manager 78

79 Procesos de desarrollo para PYMES: Modelo XSS XS S personas Senior Manager SW Quality Assurance Proyecto Proyecto Proyecto Project Manager Customer SW Quality Assurance SW Engineering Group System Group System Test Group SW Configuration Manager 79

80 Procesos de desarrollo para PYMES: Modelo XSS XS S personas Proyecto Proyecto Proyecto Senior Manager Project Manager Customer SW Quality Assurance SW Quality Assurance SW Engineering Group System Group System Test Group Project Conf. Manager Software Configuration Manager 80

81 Procesos de desarrollo para PYMES: Modelo XSS XS S personas Tipo proyecto Tipo proyecto Tipo proyecto Proyecto Proyecto Proyecto Senior Manager Project Manager Customer SW Quality Assurance SW Quality Assurance SW Engineering Group System Group System Test Group Project Soft. Conf. Manager Software Configuration Manager 81

82 Procesos de desarrollo para PYMES: Modelo XSS XS S Senior Manager SW Quality Assurance Tipo proyecto Tipo proyecto Tipo proyecto Proyecto Proyecto Proyecto Project Type Manager Project Manager Customer SW Quality Assurance Project Type SW Quality Assurance SW Engineering Group System Group System Test Group Project Soft. Conf. Manager Project Type SW Conf. Manager Software Configuration Manager 82

83 Procesos de desarrollo para PYMES: Áreas de trabajo Proceso (Abstracto) Proyecto (Concreto) XXS 1 XS 1 n S k n Nivel de proceso Nivel de proyecto 83

84 Procesos de desarrollo para PYMES: Áreas de trabajo Proceso (Abstracto) Proyecto (Concreto) XXS 1 XS 1 n S k m n Nivel de proceso Nivel de Tipo proyecto Nivel de proyecto 84

85 Procesos de desarrollo para PYMES: Key Process Areas de CMM Tipo proyecto Tipo proyecto Tipo proyecto Proyecto Proyecto Proyecto Seguimiento SW Engineering Group Project Type Manager Project Manager System Group Senior Manager Planificación de proyectos Gestión requisitos System Test Group Project Soft. Conf. Manager Customer SW Quality Assurance Project Type SW Quality Assurance Aseguramiento de la calidad Project Type SW Conf. Manager Gestión de la configuración SW Quality Assurance Software Configuration Manager 85

86 Unified Process y la reutilización Sólo cubre las fases de desarrollo (ni mantenimiento ni soporte) No existe un soporte explícito para infraestructura de desarrollo multiproyecto No hay separación entre desarrollo de componentes y desarrollo de aplicaciones La reutilización se menciona sólo cuando se desarrolla la arquitectura y el modelo del dominio Sin indicar cómo se alcanza 86

87 Qué proceso seguimos? 87

88 RUP RUP: el más extendido Cómo presentaremos la solución? Siguiendo la norma anterior Memoria y anexos para el cliente Memoria de la elaboración del proyecto para el suministrador Usar alguna otra norma Si usamos RUP Qué artefactos desarrollaremos? Hay un conjunto mínimo para proyectos pequeños Usar el sitio Web definido en RUP Util para compartir y presentar el proyecto Veremos unos proyectos pequeños (PFC) 88

89 Conjunto mínimo m de artefactos 89

90 RUP: Menú en la Web 90

91 Conclusiones Una ingeniería aplica un proceso sistemático para construir soluciones repetidamente Necesidad de un proceso que se vaya mejorando siguiendo el modelo de otras ingenierías Entregar un código que funciona mal documentado y sin diseño de partida => FRACASO Las exigencias de los clientes requieren un trabajo de ingeniería de excelencia Es necesario disponer de herramientas de soporte poderosas existentes pero caras Todo ello es escalable a proyectos pequeños 91

92 Los procesos de desarrollo también afectan al cliente

93 Objetivos Comprender los problemas del cliente Entender sus exigencias de calidad Valorar el enorme impacto que producen en el suministrador Ver la necesidad de construir herramientas de soporte a la gestión de procesos y proyectos 93

94 Solicitud de propuestas (cliente) Definición del problema a resolver Estudios a realizar, posiblemente, por terceros Petición de soluciones de calidad y evaluación Normas de presentación obligatorias para suministradores Evaluación: Auditorias realizadas por terceros durante el desarrollo del proyecto Procesos de evaluación especiales: Sector público (concurso), farmacia, medicina, aviónica, ferrocarriles, espacio,.. Varios meses, retraso en la resolución, venta y cobro 94

95 Gestión n del proyecto en marcha Proyecto evaluado y aprobado Gestión del proceso de desarrollo del proyecto Establecimiento de un proceso Carencia habitual => FRACASOS El afectado principal es le cliente Responsabilidades e interlocución Ejemplos en la Web Texas: DIS, Washington: Certificación en un nivel de calidad de proceso en el cliente Todo lo dicho del suminstrador vale pare el cliente Gestión del conocimiento del cliente 95

96 Contenidos del curso A qué se le llama calidad en el software? Cómo podemos presentar bien un proyecto al cliente? Una norma utilizable y sus exigencias Cómo conseguir la certificación de capacidad y madurez exigida por el cliente? Modelos de calidad y certificaciones Procesos y herramientas de soporte Producción industrial y mejora continua 96

97 Aspectos a considerar Identificación de oportunidades de reutilización Dominios y familias de productos Ingeniería basada en componentes 97

98 Identificación n de oportunidades de reutilización

99 Objetivos Entender los conceptos básicos de la reutilización sistemática Identificar factores de reutilización críticos y barreras para su adopción

100 Por qué reutilizar? La reutilización no es un fin en sí mismo La motivación final es económica Es una inversión Incrementa la predictibilidad en el proceso de desarrollo del software Barreras para la adopción de la reutilización

101 Esto no es nuevo Lo hemos practicado siempre de alguna manera Algunas formas ad-hoc de hacerlo Copiar y pegar código Librerías de funciones Componentes genéricos Componentes tal cual Reutilizar personal Poca aplicabilidad Demasiadas versiones Demasiadas funciones Demasiado genéricos Demasiado concretos No escalable

102 Reutilización n sistemática tica El uso sistemático de activos (assets) reutilizables en el desarrollo de nuevos sistemas para alcanzar beneficios sustanciales en la capacidad de negocio y rendimiento en un área de negocio o dominio Exige: Gestión (igual que una inversión) de activos de: Producto: código, documentos, modelos, requisitos, diseño, Proceso: procesos, datos de rendimiento de procesos, planes de proyecto, guías, plantillas, generadores de código, Personal, herramientas, Medir los avances, tener algún nivel CMM Factoría del software: especialización en dominio

103 La reutilización n se da entre proyectos Proyecto A Proyecto B Proyecto C Activos reutilizados 103

104 Aspectos básicos b de la mejora basada en la reutilización Requiere del compromiso de la dirección Requiere cambios en los procesos y la organización Debe ser introducido sistemática e incrementalmente El alcance del ciclo de mejora basada en la reutilización es un dominio de aplicación 104

105 Roles en la mejora basada en la reutilización Patrocinador: Da soporte al compromiso y se compromete en la mejora basada en la reutilización Monitoriza el rendimiento Asegura los recursos Director de reutilización: Define objetivos de reutilización Identifica acciones de mejora basada en la reutilización Ingeniero de reutilización: Implementa las acciones del programa de reutilización Por dominio Incluso la misma persona 105

106 Beneficios de la reutilización Debería ser medida con respecto a los objetivos de negocio establecidos Beneficios en rendimiento (resultados) Reducción de costos Mejora de la calidad Reducción del tiempo de puesta en el mercado Beneficios en capacidad de negocio Incremento de la madurez del proceso Incremento de la capacidad de producción Mejor conciencia de la capacidad existente Estimaciones más precisas

107 Resumen La estrategia de reutilización conlleva la necesidad de reutilizar procesos específicos La introducción de la reutilización requiere de la creación de nuevas fases en un ciclo sistemático de desarrollo del software 107

108 Dominios y familias de productos

109 Qué desarrollamos? Productos independientes o familias de productos software? Una familia de productos puede ser: Un conjunto de sistemas de aplicación para diferentes clientes con similares necesidades Un conjunto de variantes del mismo sistema adaptados para las necesidades cambiantes de un cliente Los productos pueden ser vistos como familias de productos 109

110 Las familias según Parnas Definición práctica y económica Consederamos que un conjunto de programas constituyen una familia si es útil estudiar primero programas del conjunto, para el primer estudio de las propiedades comunes del conjunto, y después determinar las especiales propiedades de los miembros individuales de la familia David L. Parnas. Extension and Contraction of Software. IEEE Transactions on Software Engineering, Vol. Se-s, No. 2, March

111 Las familias según Dijkstra Diseño de guías para familias la estructura del programa, debería ser tal que anticipase sus adaptaciones y modificaciones. Nuestro programa debería no sólo reflejar (por estructura) nuestro comprensión sobre el, sino que debería también ser claro, desde su estructura, qué clase de adaptaciones pueden ser llevadas a cabo sencillamente Edsger Dijkstra (1968) Sobre familias de programas 111

112 Dominios Dominio es un área conceptual o campo definido por un conjunto de características que son compartidas por sus miembros Dominio del problema: requisitos comunes Dominio de la solución: diseño/código común Desde el punto de vista de la reutilización, se ve más conveniente dar una solución global al dominio que a individualidades El dominio establece el alcance de reutilización

113 Ejemplos de dominios Control de tráfico aéreo Control de tráfico aéreo en Hondarribia Control de tráfico aéreo en Frankfurt Interfaces de usuario Sistema con pantalla táctil Sistema con ratón Acceso a bases de datos Rutina de acceso a bases de datos Oracle Rutina de acceso a ficheros indexados

114 Familias de productos y Líneas de productos Familias de productos Un grupo de sistemas construido mediante un conjunto común de activos (assets) Perspectiva de la construcción: generalmente asociado con un dominio técnico Línea de productos Una colección de productos que comparten un conjunto común de características que atacan las necesidades específicas de un área de negocio dado Perspectiva de negocio: generalmente asociado con un dominio de negocio 114

115 Cambios en el ciclo de vida Estudio de factibilidad Ingeniería del dominio Análisis de requisitos Diseño Ingeniería Ingeniería de Ingeniería la aplicación de la aplicación de la aplicación Codificación y prueba Integración y prueba Mantenimiento 115

116 Conocimiento del dominio Esquema del proceso de Objetivos de negocio reutilización Ingeniería del dominio Dominio Infraestructura común Ingeniería de aplicaciones Producto Producto aplicación aplicación Necesidades producto Necesidades usuario Uso del producto 116

117 Proceso de reutilización Dos ciclos de vida con objetivos diferentes pero complementarios Ingeniería del dominio Establece un concepto compartido y estandarizado dentro de un dominio en la organización Desarrolla y mantiene la infraestructura para el desarrollo de aplicaciones en un dominio Ingeniería de aplicaciones Mecánicamente deriva aplicaciones y los instancia para necesidades especiales de los clientes 117

118 Análisis del dominio Establece una visión compartida del dominio Define su alcance y el modo en el que los miembros del dominio son similares a los demás Hace comprender lo que tienen en común los miembros del dominio y sus diferencias El análisis del dominio genera La definición del dominio (incluye nombre, sinopsis, productos, glosario, tecnología, clientes, aspectos organizativos, etc.) Comunalidades y variabilidades Modelo de decisión Serie de preguntas que permiten caracterizar un miembro del dominio del resto de miembros 118

119 Análisis del dominio K. Kang,, S. Cohen, J. Hess,, W. Novak, and S. Peterson. Feature-Oriented Domain An~ysis (FODA). Feasibility Study. Technical Report CMU/SE[ TR-21, Software Engineering Institute, Pittsburgh,, PA 15213, Nov

120 Definición n del dominio 2. Nombre, para hacer referencia al dominio 3. Descripción, sentencia informal breve que indica el alcance del dominio 4. Productos, lista representativa de productos existentes (legado) y futuros 5. Glosario, definiciones de terminología relevante usada por los expertos del dominio 6. Clientes, identificación de clientes internos o externos del dominio (los que usarán los activos) 7. Organización implicada, departamentos internos o grupos que tienen alguna interacción con el dominio 8. Tecnología, en la que se basa el dominio 9. Componentes aplicables, propios y de terceros disponibles aplicables

121 Definición de dominio Ejemplo

122 Definición de dominio Ejemplo

123 Consejos para la definición n de dominios Debe representar una visión común y de consenso de todas las personas y organizaciones implicadas Debe incluir criterios para determinar pertenencia Los productos legados puede ayudar a determinar las características y hacer ingeniería inversa Pero no es la única fuente de información Es necesario mirar hacia el futuro y hacer previsiones La definición del dominio es un proceso iterativo No sale perfecta la primera vez

124 Comunalidad y variabilidad Comunalidad: Características comunes que estan presentes en todos los miembros del dominio Caracteriza al dominio frente a otros dominios Variabilidad: Características que pueden ser diferentes para diferentes miembros del dominio Recomendable identificar el rango de variabilidad

125 Ejemplos de comunalidad Sistema: Existe un catálogo de productos Determinar exactamente un producto Hacer varias compras Conocer el valor del contenido del carro Hacer el pago Tecnología empleada Sólo se usan páginas.jsp Modelo thin client (cliente ligero)

126 Ejemplos de variabilidad De una aplicación a otra varía: La funcionalidad La estructura de la base de datos Por el número de variables a tener en cuenta Por los tipos de datos de las variables Algunos aspectos legales El idioma utilizado Por los usuarios Las variaciones en el idioma a usar por los desarrolladores en sus artefactos será más difícil de solucionar

127 Consejos para la comunalidad y variabilidad Para la comunalidad: Comparar sistemas del legado y mirar las características esenciales. Desarrollar una lista por cada sistema No entrar en mucho detalle. Preguntarse si representan necesidades esenciales de los clientes afectados Para la variabilidad: Derivar variabilidades de las comunalidades Preguntarse si representan características de selección por parte de los usuarios Limitar la explosión de combinaciones de variabilidad El consenso simplifica enormemente el dominio