calidad del software
Anuncio
Ingeniería del
software
Departamento de Lenguajes y Sistemas Informáticos
http://siul02.si.ehu.es/~alfredo/
Contenidos de la asignatura
Introducción
¾ Definiciones
¾ La
calidad del software
Arquitecturas de varios niveles (JAVA)
Evaluación y pruebas del software
Reutilización
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
2
Introducció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 (www.rae.es )
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 1995 - 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.
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
3
Introducción: Definiciones (II)
Diseño (SE-CMM 1995 - SEI):
Proceso de definición de la arquitectura, componentes, interfaces, y otras
características de un sistema o componente.
Desarrollo (SE-CMM 1995 - 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 610.12, 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.
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
4
Introducció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.
¾ www.rae.es: 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.
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
5
Introducció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.
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
6
Introducció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.
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
7
Introducció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.
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
8
Calidad del software
Juan M. Pikatza
Departamento de Lenguajes y Sistemas Informáticos
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
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
11
¿A qué se le llama
calidad en el software?
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
¾
¾
plazos y costos conocidos (más cortos)
Garantgías
Poder repetir el éxito
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
13
¿Debe preocuparnos la calidad?
Los clientes quieren un producto de calidad
¾
Evalúan las soluciones de los suministradores
9A
menudo con ayuda de auditores profesionales
9 Proyectos con diferentes objetivos y alcances
Alcance: Definición de requisitos, análisis, diseño,…
9 Exigen
¾
normas de presentación de proyectos
Conveniente seguir un proceso para conseguirlo
Exigen altas cotas de fiabilidad y seguridad
9 Se
consigue con un proceso pensado para la seguridad
9 Necesitan saber con qué proceso se desarrolló
Exigen un nivel dentro de un modelo de calidad de proceso
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
14
¿Cómo se consigue la calidad?
Producción industrial
¾
Entrega en plazo con precio competitivo y calidad
9
9
Esto no es habitual en el desarrollo del software
Existen industrias de referencia: automóvil
¿Como hacerlo?
¾
Sistematización del desarrollo
9
Proceso de desarrollo definido
¾
Requisitos, análisis, diseño, implementación, gestión, pruebas,
documentación, …
Especialización: dominio y líneas de productos
9
9
Dominio, menor coste y plazos de producción conocidos
Ejemplos:
Dominio = e-Administración
Línea de producto: relaciones ciudadano-ayuntamiento
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
15
Ingeniero en
Informática
Relación proveedor-cliente
El escenario completo
Proceso
judicial
Perito
FRACASO
Insatisfecho
No cumple
Requerimientos
(C) J.M. Pikatza
Control de calidad
Cumple
Fidelidad del
cliente
Superar a la
Producto de calidad
Satisfecho
competencia
Plazo más corto
EXITO
Solución
Plazo/presupuesto
PROBLEMA
Aumento
de la
Responsable
Proyecto
capacidad
de negocio
Auditor
CLIENTE
Suministrador
€€€€€€€
Evaluacióón
Evaluaci
Funciona
Mejorar
proceso
desarrollo
Dep. L.S.I. (UPV/EHU), 2005
16
Igual que en otras ingenierías
Optimización
de Procesos
Gestión del
Mejora de Conocimiento
Procesos
Conocimiento
Optimización
Gestión del de Procesos
Conocimiento Mejora de
Procesos
Conocimiento
Procesos
Métodos
Métodos
Producto
Diseños
Tecnología
Herramientas
Problema
Cliente
Componentes
Solución
Plazo/presupuesto
Proyecto
€€€€€€€
(C) J.M. Pikatza
Control de calidad
Piezas
Evaluacióón
Requerimientos / Evaluaci
Procesos
Productos
Patrones
Tecnología
Suministrador Herramientas
Dep. L.S.I. (UPV/EHU), 2005
17
Merece la pena..
Elaborar bien un proyecto y presentarlo bien
¾
Aceptación → venta (€ $ £ ) → permanecer en el mercado
9 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
http://www.supplymanagement.ubc.ca
Risk Management of Treasury Board of Canada Secretariat:
http://www.cio-dpi.gc.ca/emf-cag/pmg-ggp/corp-min-process/risk-risq/risk-risq06_e.asp
Para poder presentar según norma
¾
University of British Columbia Supply Management:
Más fácil si seguimos un proceso
Definir un proceso de desarrollo
¾
¾
Ayudarnos de herramientas de soporte
Certificar nuestro nivel de calidad
9
¾
¾
Modelos de calidad: SW-CMM, CMMI
Mejorarlo constantemente
Mejorar la tecnología: I+D+i
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
18
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
19
¿Cómo podemos
presentar bien un
proyecto al cliente?
Relación cliente-suministrador
Incumplimientos de contrato habituales
¾
¾
Clientes y suministradores “pequeños”
¾
Desconocimiento y baja calidad
Clientes “grandes” exigen calidad
¾
Falta de normas → auditoria problemática → conflictos
Desconfianza en las empresas de software
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
9
Capacidad y madurez para hacer mejor siguiendo un proceso de
mejora continua
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
21
Relación cliente-suministrador
Normas
El cliente, mediante normas, exige
¾
Formato de presentación de proyectos para una mejor
evaluación
9
Administraciones públicas:
¾
Calidad de producto
9
¾
Robustez, usabilidad
Calidad de servicio
9
¾
Normas: Métrica v3.0 (E), Merisse (F), SSADM (UK),..
Mantenimiento, formación,..
Seguimiento de un proceso de producción
9
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
22
Relación cliente-suministrador
Creación de normas
Quién: Comité técnico de expertos
¾
Nivel estatal (AENOR), internacional (ISO,..)
9
9
Para quién: la sociedad
Para qué: mejorar las relaciones
¾
Definición de entregables, homogeneización
9
Secretaría y edición: El Colegio de la profesión
Vocales: colegios, asociaciones profesionales, empresas,
Administración, universidades
Auditorias, peritajes, visados, evaluaciones, mejora procesos
Qué: un documento
¾
¾
Definciones
Normas acumplir
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
23
Relació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”
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
24
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
25
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
26
Motivación
• En otras ingenierías:
Petición
Propuesta
Definición
Solución
Construcción
Cliente
• En nuestra ingeniería:
Implantación
Petición
Propuesta
Definición
Solución
Definición
ConstrucciónConstrucción
Implantación
Cliente
EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
27
Motivación
Petición
Propuesta
Definición
Solución
Definición
ConstrucciónConstrucción
Implantación
Cliente
• 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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
28
Motivación
• La norma contempla:
Petición
Propuesta
Definición
Solución
Construcción
Implantación
Cliente
• Tiene su origen en la norma UNE 157001
– 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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
29
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
30
Objeto y campo de aplicación
• Según el alcance del proyecto:
Petición
Propuesta
Definición
Solución
Construcción
Cliente
Definición del
problema
– Pudiendo incluir:
Captura de
requisitos
Análisis de
requisitos
Implantación
Elaboración
completa
Evaluación
visado
EUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCO
(C) J.M. Pikatza
• Auditorias
• Revisiones
independientes
• Visado
• Peritajes
Dep. L.S.I. (UPV/EHU), 2005
31
Objeto y campo de aplicación
• Según el alcance del proyecto:
Petición
Propuesta
Definición
Solución
Construcción
Cliente
Definición
Captura
del Análisis
de
de
problema
requisitos
requisitos
Implantación
Elaboración Evaluación
completa
visado
– 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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
32
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
33
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
34
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
35
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 50-132
– 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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
36
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
38
Requisitos generales
Título e identificador, cliente, suministrador,
resumen,
• duración
Títuloestimada, coste, y hoja
índice de la memoria
M0
• Documentos
Breve explicación
del General
objetivo, contenido y
– Indice
estructura – Memoria
M1
– del
Anexos
Objetivo final
proyecto y de la finalidad
•
Análisis y diseño del M2
que justifica su ejecución
Sistema
• Estimación
de Tamaño
Elementos significativos
del pasado
que y
Esfuerzos
tienen su influencia
en el proyecto
M3
• Planes de Gestión de la
del Proyecto
Punto de partidaEjecución
del proyecto
• Seguridad
Elementos que se ven afectados por el
– Requisitos
del sistema M4
cambio propuesto
en el proyecto
– Presupuesto y,
Utilizados en
elaboración
necesarios
– la
Estudios
cony entidad
M5
propia
para la ejecución
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
39
Requisitos generales
Características funcionales y no funcionales
que deba
• cumplir
Títulouna vez construido M7
• Documentos
Establecimiento
de lo que está incluido en el
proyecto y todo
lo queGeneral
no forma parte del
– Indice
mismo
M8
– Memoria
Hipótesis–deAnexos
partida
• Análisis
diseño del
Restricciones que
se han yutilizado
para la
Sistema
elaboración del proyecto
• Estimación de Tamaño y
Restricciones para la ejecución
M9
Esfuerzos
• Planes
Gestión de la
Alternativas tenidas
en de
cuenta
Ejecución
del
Proyecto
Justificación de la alternativa elegida
• Seguridad
Razones de los descartes
M10
– Requisitos del sistema
Visión global
del proyecto comprensible
– Presupuesto
y,
por especialistas
– Estudios con entidad
Enumeración
de características
propia
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
40
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
– Indice General
Directrices para el seguimiento
Directrices
de la información
– control
Memoria
Comunicación cliente-suministrador
– Anexos
Directrices aprobación de entregables
• Análisis y diseño del
Lugar de trabajo
Sistema
Etc.
M13
• Estimación de Tamaño y
Esfuerzos
Cronograma de entregas
parciales, hitos
• Planes
deproyecto
Gestión deM14
la
intermedios y fecha
final del
Ejecución del Proyecto
Coste total de la•ejecución
con costes
Seguridad
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
41
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
• Base para la elaboración
del presupuesto
– Selección de métricas
– Valoración de métricas
• Según datos del proyecto
• Criterios normalizados
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
• Implantación de
seguridad
– Plan de seguridad
– Metodologías
– Herramientas
• Identificación de puntos
críticos
– Por su importancia
– Exigidos por leyes
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
• Especificación detallada
de requisitos
– Funcionales y no
funcionales
– De producto y de proceso
– Debe depender de la
metodología empleada
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
• Determinar y justificar el
costo económico del
proyecto
– Desglosada en capítulos
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
• Documentos requeridos
por exigencias legales
–
–
–
–
LOPD
LSSI
Firma electrónica
Etc.
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
48
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
49
¿Cómo conseguir la
certificación de
capacidad y madurez
exigida por el cliente?
El cliente quiere saber cómo
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:
9
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
51
El cliente exige certificaciones
Para definir un proceso que lleve a la calidad
¾
¾
Modelos de calidad más conocidos
¾
¾
¾
¾
Tenemos que ver qué exigen los modelos de calidad de procesos
La calidad hay que perseguirla en todo el proceso de desarrollo
Capability Maturity Model Integration (CMMI)
Capability Maturity Model (SW-CMM)
ISO-15504 (SPICE )
9 Software Process Improvement and Capability Determination
BOOTSTRAP ..
El más solicitado es el CMM (SW-CMM / CMMI)
¾
El problema
9
9
¾
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
52
SW-CMM / CMMI
Optimizado
Creado por el SEI (Univ.
Carnegie- Mellon).
www.sei.cmu.edu/cmm
Los grandes clientes exigen
niveles de evaluación de 2 y 3
(CMM) a los suministradores
¾
¾
9
Gestionado
(4)
(3)
Esfuerzo
Dinero
SW-CMM
certificación
por
niveles completados
CMMI por niveles completados o
por áreas clave completadas
(C) J.M. Pikatza
(5)
Definido
¡Del caos a la disciplina!
Certificación costosa
9
Capability
Maturity
Model
(CMM)
Repetible
(2)
Inicial
ISO 9001
ISO 9004
procesos caóticos
(1)
Dep. L.S.I. (UPV/EHU), 2005
53
SW-CMM / CMMI y áreas clave
procesos que
mejoran
continuamente
procesos
predecibles
Análisis causal y resolución
Optimizado Innovación tecnológica proc. organiz.
(5)
Implantación innovación del proceso
Gestionado
(4)
Gestión cuantitativa de calidad y proceso
Realización del proceso organizativo
Enfoque del proceso organizativo
Definición del proceso organizativo
Definido Gestión de formación
proceso
Gestión integrada de proyecto
(3)
Gestión de riesgos
consistente
Gestión de requisitos
con estándares
Repetible Planificación de proyecto
Monitorización y control de proyecto
proceso
(2)
Gestión de suministradores
disciplinado
Mediciones y análisis
Aseguramiento de calidad de proceso y producto
Inicial
Gestión de configuración
(1)
Ad hoc, procesos caóticos
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
54
Entregaclave
en plazo
SW-CMM / CMMI y áreas
y con cero defectos
procesos que
mejoran
continuamente
procesos
predecibles
Análisis causal y resolución
Optimizado Innovación tecnológica proc. organiz.
(5)
Implantación innovación del proceso
Gestionado
(4)
Gestión cuantitativa de calidad y proceso
Realización del proceso organizativo
Enfoque del proceso organizativo
Definición del proceso organizativo
Definido Gestión de formación
proceso
Gestión integrada de proyecto
(3)
Gestión de riesgos
consistente
Gestión de requisitos
con estándares
Repetible Planificación de proyecto
Monitorización y control de proyecto
proceso
(2)
Gestión de suministradores
disciplinado
Mediciones y análisis
Aseguramiento de calidad de proceso y producto
Inicial
Gestión de configuración
(1)
Ad hoc, procesos caóticos
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
55
El modelo de calidad SW-CMM
Key Areas de
SW-CMM por
¾
¾
Nivel
Ámbito
9
9
9
Gestión
Organización
Ingeniería
“Buenas
prácticas” que
debemos
cumplir
Exigentes para
individuos (C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
56
Modelo organizativo
SW-CMM
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
57
CMM – TSP - PSP
CMMI es un modelo
mejorado de SWCMM
TSP(Team Software
Process)
es
un
vehículo efectivo para
implementar mejoras
basadas en CMM
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
58
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
59
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
60
¿Algú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):
9
9
9
9
9
IBM Rational Software (Rational Unified Process – RUP)
Computer Associates/Sterling Software
Select Software Tools
Aonix
Computer Associates/Platinum Technology
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
61
Procesos muy extendidos
RUP
Inicio
Elaboración Construcción Transición
PMBOK
Inicialización
Entorno
Planificación
Gestión de proyecto
Ejecución Modelado
Requisitos
Implementación
de
Despliegue
Análisis y
Test
negocio
Diseño
Requisitos
Control
Gestión de proyecto
Gestión de configuración y cambio
Cierre
RUP – 2005 : www.rational.com/university
=> inscribirse y bajar productos
PMI: www.pmi.org
PMBOK Guide - 2000 Edition Excerpts Welcome: => versión 2000 gratis, versión 2004 no
http://www.pmi.org/prod/groups/public/documents/info/pp_pmbok2k_conf.asp
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
62
PMBOK-2004 (www.pmi.org)
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
63
La evolución de las metodologías
Enfoque
Ericsson
Rational Software
Objectory
Unified Process
Select Software
KnowledgeWare
TI Software
Synon
Bachman
Cayenne
Cadre
Paul Allen
Perspective Process
Enfoque
Catalysis
Protosoft
Aion
Interactive Development Environments
Thomson Software Products
(C) J.M. Pikatza
QSS
CBOT
Sterling Software
Spex methodology
Tecnología
Platinum
Computer
Associates
Aonix
Dep. L.S.I. (UPV/EHU), 2005
64
Rational Unified Process (RUP)
www.rational.com
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
65
Rational Unified Process (RUP)
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
66
Rational Unified Process
(RUP)
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
67
Rational Unified Process
(RUP)
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
68
Proyecto como instancia de Proceso
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
69
Herramientas de Rational
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
70
Herramientas de Rational
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
71
Otras herramientas
Computer
Associates
(www.ca.com)
¾
AllFusion
Aonix
(www.aonix.com)
¾
Sistemas de
Tiempo-real
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
72
¿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
9
9
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
73
Procesos de desarrollo para PYMES:
Antecedentes
Intentos de adaptar CMM a PYMES
¾
Dynamic CMM (Laryd 00)
9
¾
People Capability Maturity Model (Curtis, 95)
9
¾
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)
9
¾
Laryd A. and Terttu Orci T. Dynamic CMM for Small Organizations, Proceedings
ASSE 2000, the First Argentine Symposium on Software Engineering, Tandil,
Argentina, pp. 133--149, (2000)
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).
http://mabwww.gsfc.nasa.gov/papers/DOCS/AMApproach.pdf
CMM nivel 2 para e-Comercio (Antón, 01)
9
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 TR2001-09, (2001)
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
74
Procesos de desarrollo para PYMES:
Modelo
0
2
XSS
XS
S
5
15
50
personas
Customer
SW Quality
Assurance
Gestor
Desarrollador
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
75
Procesos de desarrollo para PYMES:
Modelo
0
2
XSS
XS
S
5
15
50
Customer
SW Quality
Assurance
Gestor
SW Engineering
Group
System
Group
personas
System Test
Group
(C) J.M. Pikatza
SW Configuration
Manager
Dep. L.S.I. (UPV/EHU), 2005
76
Procesos de desarrollo para PYMES:
Modelo
0
2
XSS
XS
S
5
15
50
personas
Proyecto
Project
Manager
SW Engineering
Group
System
Group
SW Quality
Assurance
System Test
Group
(C) J.M. Pikatza
Customer
SW Quality
Assurance
SW Configuration
Manager
Dep. L.S.I. (UPV/EHU), 2005
77
Procesos de desarrollo para PYMES:
Modelo
0
2
XSS
XS
S
5
15
50
personas
Proyecto
Proyecto
Proyecto
Project
Manager
SW Engineering
Group
System
Group
SW Quality
Assurance
System Test
Group
(C) J.M. Pikatza
Customer
SW Quality
Assurance
SW Configuration
Manager
Dep. L.S.I. (UPV/EHU), 2005
78
Procesos de desarrollo para PYMES:
Modelo
0
2
XSS
XS
S
5
15
50
Senior
Manager
personas
SW Quality
Assurance
Proyecto
Proyecto
Proyecto
Customer
SW Quality
Assurance
Project
Manager
SW Engineering
Group
System
Group
System Test
Group
(C) J.M. Pikatza
SW Configuration
Manager
Dep. L.S.I. (UPV/EHU), 2005
79
Procesos de desarrollo para PYMES:
Modelo
0
2
XSS
XS
S
5
15
50
Senior
Manager
personas
SW Quality
Assurance
Proyecto
Proyecto
Proyecto
Customer
SW Quality
Assurance
Project
Manager
SW Engineering
Group
System
Group
System Test
Group
(C) J.M. Pikatza
Project Conf.
Manager
Dep. L.S.I. (UPV/EHU), 2005
Software
Configuration
Manager
80
Procesos de desarrollo para PYMES:
Modelo
0
2
XSS
XS
S
5
15
50
personas
Tipo proyecto
Tipo
Tipo proyecto
proyecto
Senior
Manager
SW Quality
Assurance
Proyecto
Proyecto
Proyecto
Customer
SW Quality
Assurance
Project
Manager
SW Engineering
Group
System
Group
System Test
Group
(C) J.M. Pikatza
Project Soft.
Conf. Manager
Dep. L.S.I. (UPV/EHU), 2005
Software
Configuration
Manager
81
Procesos de desarrollo para PYMES:
Modelo
XSS
XS
S
Senior
Manager
SW Quality
Assurance
Tipo proyecto
Tipo
Tipo proyecto
proyecto
Project
Type
Project Type SW
Quality Assurance
Manager
Proyecto
Proyecto
Proyecto
Customer
SW Quality
Assurance
Project
Manager
SW Engineering
Group
System
Group
System Test
Group
(C) J.M. Pikatza
Project Soft.
Conf. Manager
Dep. L.S.I. (UPV/EHU), 2005
Project Type
SW Conf.
Manager
Software
Configuration
Manager
82
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
83
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
84
Procesos de desarrollo para PYMES:
Key Process Areas de CMM
Tipo proyecto
Tipo
Tipo proyecto
proyecto
Project
Type
Manager
Proyecto
Proyecto
Proyecto
Seguimiento
SW Engineering
Group
Project
Manager
System
Group
Planificación de proyectos
Senior
Manager
ad
d
i
al
c
la
e
od
A
itos
s
i
u
req
n
ó
i
t
Ges
System Test
Group
(C) J.M. Pikatza
SW Quality
Assurance
t
en
i
ram
u
g
Project Type SW
se
Quality Assurance
Customer
SW Quality
Assurance
Project Type
SW Conf.
Manager
Project Soft.
Conf. Manager
Software
Configuration
Manager
Gestión de la configuración
Dep. L.S.I. (UPV/EHU), 2005
85
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
86
¿Qué proceso seguimos?
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
87
RUP
RUP: el más extendido
¿Cómo presentaremos la solución?
¾
Siguiendo la norma anterior
9
9
¾
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?
9
¾
Usar el sitio Web definido en RUP
9
¾
Hay un conjunto mínimo para proyectos pequeños
Util para compartir y presentar el proyecto
Veremos unos proyectos pequeños (PFC)
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
88
Conjunto mínimo de artefactos
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
89
RUP: Menú en la Web
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
90
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
91
Los procesos de
desarrollo también
afectan al cliente
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
93
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:
¾
9 Auditorias
realizadas por terceros durante el desarrollo
del proyecto
9 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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
94
Gestión del proyecto en marcha
Proyecto evaluado y aprobado
Gestión del proceso de desarrollo del proyecto
¾
Establecimiento de un proceso
9 Carencia
habitual => FRACASOS
El afectado principal es le cliente
9 Responsabilidades
e interlocución
9 Ejemplos en la Web
Texas: http://www.dir.state.tx.us/eod/qa/index.htm
http://www.cio-dpi.gc.ca/emf-cag/pmg-ggp/corp-min-process/risk-risq/risk-risq06_e.asp
DIS, Washington: www.dis.wa.gov/portfolio/302G.doc
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
¾
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
95
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
96
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
Aspectos a considerar
Identificación de oportunidades de
reutilización
Dominios y familias de productos
Ingeniería basada en componentes
97
Identificación de
oportunidades de
reutilización
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
¿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
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
Reutilización sistemá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:
9
9
¾
¾
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
La reutilización se da entre
proyectos
Proyecto A
Proyecto B
Proyecto C
Activos reutilizados
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
103
Aspectos básicos 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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
104
Roles en la mejora basada en la
reutilización
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
Patrocinador: Da soporte al
compromiso y se compromete en la
mejora basada en la reutilización
¾
¾
Director de reutilización:
¾
¾
Monitoriza el rendimiento
Asegura los recursos
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
Beneficios de la reutilización
¾
Debería ser medida con respecto a los objetivos
de negocio establecidos
9 Beneficios
en rendimiento (resultados)
Reducción de costos
Mejora de la calidad
Reducción del tiempo de puesta en el mercado
9 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
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
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
Resumen
107
Dominios y familias
de productos
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
¿Qué desarrollamos?
¿Productos independientes o familias de
productos software?
¾ Una familia de productos puede ser:
¾
9 Un
conjunto de sistemas de aplicación para
diferentes clientes con similares necesidades
9 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
Definición práctica y económica
¾
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
Las familias según Parnas
“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 1979
110
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
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
¾
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
¾
Familias de productos y
Líneas de productos
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
Cambios en el ciclo de vida
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
Estudio de
factibilidad
Análisis de
requisitos
Diseño
Codificación
y prueba
Integración y
prueba
Ingeniería
del
dominio
Mantenimiento
Ingeniería
Ingeniería
de
la
Ingeniería
de la
aplicación
de la
aplicación
aplicación
115
Esquema del proceso de
reutilización
Conocimiento
Objetivos de
negocio
Ingeniería del
dominio
Dominio
Infraestructura común
Necesidades
producto
Ingeniería de
aplicaciones
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
del dominio
Producto
Producto
Producto
aplicación
aplicación
aplicación
Necesidades
usuario
Uso del producto
116
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
Proceso de reutilización
Dos ciclos de vida con objetivos diferentes
pero complementarios
¾
Ingeniería del dominio
9 Establece
un concepto compartido y estandarizado
dentro de un dominio en la organización
9 Desarrolla y mantiene la infraestructura para el
desarrollo de aplicaciones en un dominio
¾
Ingeniería de aplicaciones
9 Mecánicamente
deriva aplicaciones y los instancia
para necesidades especiales de los clientes
117
Análisis del dominio
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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
9
Serie de preguntas que permiten caracterizar un miembro
del dominio del resto de miembros
118
(C) J.M. Pikatza
Dep. L.S.I. (UPV/EHU), 2005
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[-90-TR-21, Software
Engineering Institute, Pittsburgh, PA 15213, Nov. 1990
119
2.
3.
4.
5.
6.
7.
8.
9.
Definición del dominio
Nombre, para hacer referencia al
dominio
Descripción, sentencia informal
breve que indica el alcance del
dominio
Productos, lista representativa de
productos existentes (legado) y
futuros
Glosario, definiciones de
terminología relevante usada por
los expertos del dominio
Clientes, identificación de
clientes internos o externos del
dominio (los que usarán los
activos)
Organización implicada,
departamentos internos o grupos
que tienen alguna interacción con
el dominio
Tecnología, en la que se basa el
dominio
Componentes aplicables, propios
y de terceros disponibles
aplicables
Definición
de
dominio
Ejemplo
Definición
de
dominio
Ejemplo
Consejos para la definició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
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
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)
Ejemplos de variabilidad
De una aplicación a otra varía:
¾
¾
La funcionalidad
La estructura de la base de datos
9
9
¾
¾
Algunos aspectos legales
El idioma utilizado
9
Por el número de variables a tener en cuenta
Por los tipos de datos de las variables
Por los usuarios
Las variaciones en el idioma a usar por los
desarrolladores en sus artefactos será más difícil de
solucionar
Consejos para la comunalidad y
variabilidad
Para la comunalidad:
¾
¾
Para la variabilidad:
¾
¾
¾
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
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
Modelo de decisión (MD)
Un modelo de decisión recoge todas las
decisiones abiertas que caracterizan un dominio
¾
Una formalización de las variabilidades
Cada decisión puede ser representada como:
¾
¾
Con los rangos de sus posibles valores de decisión
Una pregunta (una variable) y
Un rango de respuestas válidas (valores de la variable)
Puede ser representado como:
¾
¾
¾
Una tabla
Una declaración de tipo (p. ej. esquema de BD)
Un árbol (p. ej. FODA)
Representación tabular de un MD
Decisiones con sus posibles valores:
Decisiones
Valores
Significado
Características llamada
Hacer llamada
Responder llamada
Si
Si/No
Si/No
Llamada esperando
Si/No
Habilidad para mantener una
Sólo si el llamante llamada entrante
habla otro idioma
Idioma de intereacción
En/fr/es
Mensajes en la pantalla del
móvil
…………………
…………….
……………….
Habilidad para llamar
Habilidad para responder
Esquema de representación de un
MD
Tipos
¾
¾
¾
¾
¾
¾
Tipos básicos: integer, real, Boolean
Intervalos: [1-10]
Tipos enumerados: (x|y|z)
Tipos agregación: x: tipo, y: tipo, z: tipo
Conjunto de tipos: conjunto {x, y, z}
Tipos colección: colección (x|y|z)
Restricciones adicionales
¾
¾
Opcional o obligatorio
Valor por defecto
Modelo de decisión para el
ejemplo e-Comercio
SectorDeAplicación: {libros|consumibles}
NumModulos: [4-12]
Modulo:
¾
¾
IdentifModulo: String
Versión
9
9
Numversion: real
Características: String
ModulosInstalados: conjunto no vacio Puntos de
variación
Tecnología: (ASP, Java)
IdiomaDocumentación: (EU|EN|ES)
Restricción:
¾
SectorDeAplicación = libros
Representación arborescente de
un MD: Modelo de características
Metodología aplicable:
¾
FODA (Feature Oriented Decision Analisis), SEI
http://www.sei.cmu.edu/domain-engineering/FODA.html
9 Inconvenientes:
¾
¾
Con muchas características la representación gráfica se satura
Mezcla decisiones con el orden en el que deben tomarse. Mejor
separarlos
Las decisiones están determinadas por la variabilidad
contemplada, no son muchas
Las decisiones que no se reflejan están fuera del
dominio
Representación arborescente de
un MD: Modelo de características
Las decisiones impactan en
todos los productos del proceso
El modelo de
decisiones recoge
todas las decisiones
Diferentes valores
en las decisiones
llevan a variaciones
en los productos del
proceso
Decisión del modelo
de decisión
Documentos
de requisitos
Arquitectura
/diseño
Código
fuente
Ingeniería basada en
componentes
Ingeniería basada en
componentes (CBE)
Definición:
¾
La creación y
desarrollo de
sistemas software a
base de ensamblar
componentes
reutilizables
Concepto de factoría
de software
Fases principales en Ingeniería
basada en componentes (CBE)
Desarrollo
Base de
activos
Especialización
y ensamblado
Aplicación 1
Aplicación 2
Ingeniería
del dominio
Retroalimentación
Aplicación n
Ingeniería de
de
laIngeniería
aplicación
laIngeniería
aplicaciónde
la aplicación
Componentes
Un componente es un activo software reutilizable,
que puede formar parte de un sistema software
Los componentes son reutilizados en tiempo de
producción cuando se ensambla el sistema
Los componentes reutilizables son:
¾
¾
Empaquetados: Tienen existencia independientemente
de la aplicación en la que se usan. Nombre propio
Evolucionables: Existe un mecanismo claro que
determina el impacto del cambio en un componente de
forma que el sistema pueda evolucionar fácilmente para
adaptarse a las cambiantes tecnologías y necesidades
9
¾
Compatible hacia atrás
Flexibles: Adaptable a contextos específicos
Desarrollo del software
En la Ingeniería Basada en Componentes, el
proceso de desarrollo se parece más a una línea
de montaje
La parte creativa del desarrollo se concentra en
las partes innovadoras del software
Lo repetitivo se realiza de forma automática o
mecanizada
La aplicación software resultante se “deriva” de
la infraestructura de la base de activos existente
Arquitectura y componentes
En general, la arquitectura del dominio captura
los aspectos de la solución que son comunes a
todos los miembros
La arquitectura del dominio define el esqueleto
general del sistema y identifica los puntos en los
que se integran los componentes
Componentes comerciales
(COTS)
Componentes COTS
¾
Commercial-Off-The-Shelf
A priori existen y pueden ser comprados y
licenciados por un vendedor comercial
Disponibles para público en general
La implementación física se oculta
Mantenidos por el vendedor de COTS
Roles en el mercado de COTS
El vendedor de COTS
El desarrollador de software
¾
Consultor/Evaluador de COTS/Asistente legal
Broker:
¾
Desarrollo de software basado en COTS
Corredor o agente que relaciona clientes con
vendedores
Escrow
¾
El código fuente puede quedar en una institución
bancaria o similar para evitar el desastre que supone
la desaparición del vendedor
Roles en el mercado de COTS
Vendedor
Desarrollador
de software
de COTS
Broker
Escrow
Consultor/
Evaluador de COTS/
Asistente legal
CBE con COTS
El uso de componentes construidos por terceros
es lo normal en otras industrias
EL uso de COTS cambia el énfasis
¾
De desarrollo de aplicaciones a ensamblado de
aplicaciones
Requiere conocimiento y gestión de proveedores
Requiere flexibilidad en los requisitos de los
usuarios
Beneficios del uso de COTS
Es más barato
Plazos de entrega más cortos
Permite hacer uso de las últimas tecnologías
Calidad creciente:
¾
Los COTS se prueban en el mercado
Riesgos del uso de COTS (I)
Problemas de integración no previstos
¾
¾
El mantenimiento puede ser costoso
¾
¾
¾
Aparición de nuevos problemas de integración
Necesidad de adquirir “upgrades” no deseadas
Dependencia del vendedor
El uso de estándares de propietario lleva a:
¾
¾
Imprecisión en las estimaciones de proyectos
Problemas de compatibilidad e interoperabilidad
Problemas de portabilidad e integración
Dependencia del vendedor
La integración de COTS de distintos vendedores
aumenta los problemas
Riesgos del uso de COTS (II)
Los COTS son cajas negras que dificultan su
prueba
¾
Dificultades para asegurar la calidad y seguridad
La documentación incompleta o imprecisa lleva
a dificultades de integración (problemas
imprevistos)
Razones para construirlos
No hay COTS adecuados en el mercado
Los COTS implican demasiadas restricciones de
desarrollo (costos, licencias, etc.)
Se espera una impredecible evolución de
componentes o los COTS no ofrecen posibilidades
cuando es necesario
Los recursos y habilidades necesarios para
desarrollar un componente están altamente
disponibles en la compañía
La compañía no puede confiar completamente en
el proveedor
La compañía acepta el tiempo previsto de puesta
en el mercado
Razones para comprar
Hay COTS adecuados en el mercado
Se espera una pequeña y predecible evolución de
los componentes
Se puede disponer de código de calidad y
documentación
Los recursos y habilidades de la compañía son
escasos
La compañía confía en el proveedor
La compañía necesita reducir el tiempo de
puesta en el mercado
Resumen
Los componentes son activos empaquetados,
evolucionables y flexibles
La Ingeniería Basada en Componentes pretende
la derivación de aplicaciones software a partir de
componentes reutilizables de una base de
activos
Hay un cambio importante en el paso del
desarrollo de aplicaciones al ensamblado de
aplicaciones
Los componentes de software comerciales
(COTS) son usados crecientemente en la
construcción de sistemas
¾
Pero es necesario gestionar algunos riesgos
