Ingenier Ingenier í í a del a del software software Departamento de Lenguajes y Sistemas Informáticos http://siul02.si.ehu.es/~alfredo/
IngenierIngenieríía del a del softwaresoftware
Departamento de Lenguajes y Sistemas Informáticos
http://siul02.si.ehu.es/~alfredo/
2(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Contenidos de la asignaturaContenidos de la asignatura
IntroducciónDefiniciones
La calidad del software
Arquitecturas de varios niveles (JAVA)
Evaluación y pruebas del software
Reutilización
3(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
IntroducciIntroduccióón: Definiciones (I)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, OportunidadInternos: Modularidad y legibilidadEn 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.
4(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
IntroducciIntroduccióón: Definiciones (II)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.
5(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
IntroducciIntroduccióón: Definiciones (III)n: Definiciones (III)
IngenieríaIEEE: 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 softwareIngenierí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.
6(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
IntroducciIntroduccióón: Definiciones (IV)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 puedeevidenciarse 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 softwareProducto (ISO 9000: 2000 (2.4.2)Resultado de un proceso. NOTA: Cuatro categorías mencionables: hardware, software, comunicaciones, servicios.
7(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
IntroducciIntroduccióón: Definiciones (V)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 necesidadesResultado (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.
8(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
IntroducciIntroduccióón: Definiciones (VI)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”.UsuarioUna 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.
Calidad del softwareCalidad del software
Juan M. Pikatza
Departamento de Lenguajes y Sistemas Informáticos
ObjetivosObjetivos
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(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Contenidos del cursoContenidos 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
¿¿A quA quéé se le llama se le llama calidad en el software?calidad en el software?
13(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Hay quien piensa que..Hay quien piensa que..
Burocracia y retrasos en vez de escribir códigoHacer 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 competenciaPara hoy y el futuro (actualización)Gestión del proceso y el conocimiento
Poder repetir el éxitoplazos y costos conocidos (más cortos)Garantgías
14(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
¿¿Debe preocuparnos la calidad?Debe preocuparnos la calidad?
Los clientes quieren un producto de calidadEvalúan las soluciones de los suministradores
A menudo con ayuda de auditores profesionales
Proyectos con diferentes objetivos y alcancesAlcance: Definición de requisitos, análisis, diseño,…
Exigen normas de presentación de proyectosConveniente seguir un proceso para conseguirlo
Exigen altas cotas de fiabilidad y seguridadSe 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
15(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
¿¿CCóómo se consigue la calidad?mo se consigue la calidad?
Producción industrialEntrega en plazo con precio competitivo y calidad
Esto no es habitual en el desarrollo del softwareExisten industrias de referencia: automóvil
¿Como hacerlo?Sistematización del desarrollo
Proceso de desarrollo definidoRequisitos, análisis, diseño, implementación, gestión, pruebas, documentación, …
Especialización: dominio y líneas de productosDominio, menor coste y plazos de producción conocidosEjemplos:
Dominio = e-AdministraciónLínea de producto: relaciones ciudadano-ayuntamiento
16(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RelaciRelacióón proveedorn proveedor--clienteclienteEl escenario completoEl escenario completo
SuministradorSuministradorCLIENTECLIENTE
PROBLEMAPROBLEMA
Req
uer
imie
nto
sR
equ
erim
ien
tos
€€ €€ €€ €€ €€ €€ €€C
ontr
ol d
e ca
lidad
Con
trol
de
calid
adAuditorAuditor
SatisfechoSatisfecho
FuncionaFunciona
InsatisfechoInsatisfecho
Producto de calidadProducto de calidadPlazo mPlazo máás cortos corto
CumpleCumple
No cumpleNo cumple
ProyectoProyecto
SoluciSolucióónnPlazo/presupuestoPlazo/presupuesto
Eva
luac
iE
valu
aci óó
nn
Proceso Proceso judicialjudicial
FRACASOFRACASO
Fidelidad del Fidelidad del clientecliente
Superar a la Superar a la competenciacompetencia
EXITOEXITO
Mejorar Mejorar procesoproceso
desarrollodesarrollo
Aumento Aumento de la de la
capacidad capacidad de negociode negocio
Ingeniero enIngeniero enInformInformááticatica
PeritoPerito
ResponsableResponsable
17(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Igual que en otras ingenierIgual que en otras ingenierííasas
SuministradorSuministradorClienteCliente
ProblemaProblemaComponentesComponentes
ProyectoProyecto
SoluciSolucióónnPlazo/presupuestoPlazo/presupuesto
Req
uer
imie
nto
s /
Eva
luac
iR
equ
erim
ien
tos
/ E
valu
aci óó
nn
€€ €€ €€ €€ €€ €€ €€ Con
trol
de
calid
adC
ontr
ol d
e ca
lidad ProductosProductos
TecnologTecnologííaa
MMéétodostodos
ProcesosProcesos
HerramientasHerramientas
PatronesPatrones
PiezasPiezas
ProductoProducto
TecnologTecnologííaa
MMéétodostodos
ProcesosProcesos
HerramientasHerramientas
DiseDiseññosos
Mejora de Mejora de ProcesosProcesos
Mejora de Mejora de ProcesosProcesos
OptimizaciOptimizacióón n de Procesosde Procesos
OptimizaciOptimizacióón n de Procesosde ProcesosGestiGestióón del n del
ConocimientoConocimientoGestiGestióón del n del
ConocimientoConocimiento
ConocimientoConocimiento ConocimientoConocimiento
18(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Merece la pena..Merece la pena..Elaborar bien un proyecto y presentarlo bien
Aceptación → venta (€ $ £ ) → permanecer en el mercadoCumplir 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, CMMIAlgunos clientes utilizan la Web para informar a los clientes
University of British Columbia Supply Management:http://www.supplymanagement.ubc.caRisk 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 normaMás fácil si seguimos un proceso
Definir un proceso de desarrolloAyudarnos de herramientas de soporteCertificar nuestro nivel de calidad
Modelos de calidad: SW-CMM, CMMIMejorarlo constantementeMejorar la tecnología: I+D+i
19(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Contenidos del cursoContenidos 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
¿¿CCóómo podemos mo podemos presentar bien un presentar bien un
proyecto al cliente?proyecto al cliente?
21(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RelaciRelacióón clienten cliente--suministradorsuministrador
Incumplimientos de contrato habitualesFalta de normas → auditoria problemática → conflictosDesconfianza en las empresas de software
Clientes y suministradores “pequeños”Desconocimiento y baja calidad
Clientes “grandes” exigen calidadMuchos exigen seguir un proceso y certificaciones
Preocupación: calidad, plazos y presupuestosSaber hacer no garantiza hacer bien
Capacidad para repetir haciendo bien y más rápidoCapacidad y madurez para hacer mejor siguiendo un proceso de mejora continua
22(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RelaciRelacióón clienten cliente--suministradorsuministradorNormasNormas
El cliente, mediante normas, exigeFormato 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 productoRobustez, usabilidad
Calidad de servicioMantenimiento, formación,..
Seguimiento de un proceso de producciónCertificación de un nivel de calidad según algún modelo
Imposible sin sistematización de la producciónProceso de producción industrial
23(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RelaciRelacióón clienten cliente--suministradorsuministradorCreaciCreacióón de normasn de normas
Quién: Comité técnico de expertosNivel estatal (AENOR), internacional (ISO,..)
Secretaría y edición: El Colegio de la profesiónVocales: colegios, asociaciones profesionales, empresas, Administración, universidades
Para quién: la sociedadPara qué: mejorar las relaciones
Definición de entregables, homogeneizaciónAuditorias, peritajes, visados, evaluaciones, mejora procesos
Qué: un documentoDefincionesNormas acumplir
24(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RelaciRelacióón clienten cliente--suministradorsuministradorUna propuesta de normaUna 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 alegacionesControversia en el uso de la palabra “informática”
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 25COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Contenidos
• Motivación • Objeto y campo de aplicación• Definiciones• Requisitos generales
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 26COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 27COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Motivación
• En otras ingenierías:
Solución
PeticiónPropuesta
DefiniciónConstrucción
Implantación• En nuestra ingeniería:
Cliente
Solución
PeticiónPropuesta
DefiniciónConstrucción
Implantación
Definición
Construcción
Cliente
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 28COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Motivación
• Tradición arraigada• Consecuencias:
– Dificultad de planificación de la construcción– Impacto negativo en la calidad de producto
Solución
PeticiónPropuesta
DefiniciónConstrucción
Implantación
Definición
Construcción
Cliente
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 29COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Motivación
• La norma contempla:
• Tiene su origen en la norma UNE 157001 – Norma general de proyectos de ingeniería
• Objetivo: Garantizar un mínimo de calidad
Solución
PeticiónPropuesta
DefiniciónConstrucción
ImplantaciónCliente
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 30COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Contenidos
• Motivación • Objeto y campo de aplicación• Definiciones• Requisitos generales
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 31COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Cliente
Solución
PeticiónPropuesta
DefiniciónConstrucción
Implantación
Objeto y campo de aplicación
• Según el alcance del proyecto:
– Pudiendo incluir:• Auditorias• Revisiones
independientes• Visado• Peritajes
Definición delproblema
Captura de requisitos
Análisis de requisitos
Elaboracióncompleta
Evaluaciónvisado
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 32COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Cliente
Solución
PeticiónPropuesta
DefiniciónConstrucción
Implantación
Objeto y campo de aplicación
• Según el alcance del proyecto:
– 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
Definición delproblema
Captura de requisitos
Análisis de requisitos
Elaboracióncompleta
Evaluaciónvisado
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 33COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Contenidos
• Motivación • Objeto y campo de aplicación• Definiciones• Requisitos generales
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 34COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 35COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
Contenidos
• Motivación • Objeto y campo de aplicación• Definiciones• Requisitos generales
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 36COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 37COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
• 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 38COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
M0.- Hojas de identificaciónM1.- IntroducciónM2.- ObjetoM3.- AntecedentesM4.- Descripción de la situación actualM5.- Normas y referencias
M6.- Definiciones y abreviaturasM7.- Requisitos inicialesM8.- Alcance M9.- Hipótesis y restriccionesM10.- Estudio de alternativas y viabilidadM11.- Descripción del sistema propuestoM12.- Análisis de RiesgosM13.- Organización y gestión del proyecto M14.- Planificación temporalM15.- Presupuesto
M5.1.- Disposiciones legales y normas aplicadas
M5.2.- BibliografíaM5.3.- Métodos, Herramientas, Modelos,
Métricas y PrototiposM5.4.- Plan de gestión de la calidad
aplicado durante la redacción del Proyecto
M5.5.- Otras referencias
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 39COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
M0.- Hojas de identificaciónM1.- IntroducciónM2.- ObjetoM3.- AntecedentesM4.- Descripción de la situación actualM5.- Normas y referencias
M6.- Definiciones y abreviaturasM7.- Requisitos inicialesM8.- Alcance M9.- Hipótesis y restriccionesM10.- Estudio de alternativas y viabilidadM11.- Descripción del sistema propuestoM12.- Análisis de RiesgosM13.- Organización y gestión del proyecto M14.- Planificación temporalM15.- Presupuesto
M5.1.- Disposiciones legales y normas aplicadas
M5.2.- BibliografíaM5.3.- Métodos, Herramientas, Modelos,
Métricas y PrototiposM5.4.- Plan de gestión de la calidad
aplicado durante la redacción del Proyecto
M5.5.- Otras referencias
Título e identificador, cliente, suministrador, resumen, duración estimada, coste, y hoja índice de la memoria
Breve explicación del objetivo, contenido y estructura
Objetivo final del proyecto y de la finalidad que justifica su ejecución
Elementos significativos del pasado que tienen su influencia en el proyecto
Punto de partida del proyecto
Elementos que se ven afectados por el cambio propuesto en el proyecto
M0M0
M1M1
M2M2
M3M3
M4M4
Utilizados en la elaboración y necesarios para la ejecución M5M5
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 40COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
M0.- Hojas de identificaciónM1.- IntroducciónM2.- ObjetoM3.- AntecedentesM4.- Descripción de la situación actualM5.- Normas y referencias
M6.- Definiciones y abreviaturasM7.- Requisitos inicialesM8.- Alcance M9.- Hipótesis y restriccionesM10.- Estudio de alternativas y viabilidadM11.- Descripción del sistema propuestoM12.- Análisis de RiesgosM13.- Organización y gestión del proyecto M14.- Planificación temporalM15.- Presupuesto
M5.1.- Disposiciones legales y normas aplicadas
M5.2.- BibliografíaM5.3.- Métodos, Herramientas, Modelos,
Métricas y PrototiposM5.4.- Plan de gestión de la calidad
aplicado durante la redacción del Proyecto
M5.5.- Otras referencias
Características funcionales y no funcionales que deba cumplir una vez construido
Establecimiento de lo que está incluido en el proyecto y todo lo que no forma parte del mismo
M7M7
M8M8
Hipótesis de partidaRestricciones que se han utilizado para la elaboración del proyecto Restricciones para la ejecución M9M9
Alternativas tenidas en cuenta Justificación de la alternativa elegida Razones de los descartes M10M10
Visión global del proyecto comprensiblepor especialistas Enumeración de características significativas M11M11
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 41COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
M0.- Hojas de identificaciónM1.- IntroducciónM2.- ObjetoM3.- AntecedentesM4.- Descripción de la situación actualM5.- Normas y referencias
M6.- Definiciones y abreviaturasM7.- Requisitos inicialesM8.- Alcance M9.- Hipótesis y restriccionesM10.- Estudio de alternativas y viabilidadM11.- Descripción del sistema propuestoM12.- Análisis de RiesgosM13.- Organización y gestión del proyecto M14.- Planificación temporalM15.- Presupuesto
M5.1.- Disposiciones legales y normas aplicadas
M5.2.- BibliografíaM5.3.- Métodos, Herramientas, Modelos,
Métricas y PrototiposM5.4.- Plan de gestión de la calidad
aplicado durante la redacción del Proyecto
M5.5.- Otras referencias
Identificación de los riesgos de la fase de elaboración y de la fase de construcción
Matriz de responsabilidadesDirectrices para la gestión de cambiosDirectrices para el seguimiento Directrices control de la informaciónComunicación cliente-suministradorDirectrices aprobación de entregablesLugar de trabajoEtc.
M12M12
Cronograma de entregas parciales, hitos intermedios y fecha final del proyecto
M13M13
M14M14
Coste total de la ejecución con costes parciales M15M15
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 42COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
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 43COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 44COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
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 45COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
• 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 46COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
• 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 47COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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
• Determinar y justificar el costo económico del proyecto
– Desglosada en capítulos
(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005 48COLEGIO OFICIAL DE INGENIEROS EN INFORMÁTICA DEL PAÍS VASCOEUSKADIKO INFORMATIKAKO INGENIARIEN ELKARGO OFIZIALA
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.
49(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Contenidos del cursoContenidos 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
¿¿CCóómo conseguir la mo conseguir la certificacicertificacióón de n de
capacidad y madurez capacidad y madurez exigida por el cliente?exigida por el cliente?
51(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
El cliente quiere saber cEl cliente quiere saber cóómo mo desarrollamosdesarrollamos
La calidad es resultado de un proceso repetibleSoluciones mantenibles, adaptables a problemas similares y evolucionables. Plazo y costo limitado No una obra genial única no repetible
El cliente exige certificaciones de procesosExisten modelos de calidad para evaluar procesos:
SW-CMM, CMMI, SPICE,..
No se pueden alcanzar sin seguir un proceso de desarrollo definidoProceso definido y en mejora continua (suministrador)
Aumento del rendimiento y capacidad de negocio
52(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
El cliente exige certificacionesEl cliente exige certificaciones
Para definir un proceso que lleve a la calidadTenemos 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-15504 (SPICE )
Software Process Improvement and Capability DeterminationBOOTSTRAP ..
El más solicitado es el CMM (SW-CMM / CMMI)El problema
Demasiados roles para una organización pequeña => FRACASODemasiado cambio para una organización grande => FRACASO
La solución: adaptar el proceso al proyecto, se puede
53(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
SWSW--CMM / CMMICMM / CMMI
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
¡Del caos a la disciplina!Certificación costosa
EsfuerzoDinero
SW-CMM certificación por niveles completadosCMMI por niveles completados o por áreas clave completadas
procesos caóticos
Capability Maturity Model(CMM)
Inicial(1)
Definido(3)
Repetible(2)
Gestionado(4)
Optimizado(5)
ISO 9001ISO 9004
54(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
SWSW--CMM / CMMI y CMM / CMMI y ááreas clavereas clave
Ad hoc, procesos caóticos
Inicial(1)
Definido(3)
Repetible(2)
Gestionado(4)
Optimizado(5)
proceso disciplinado
proceso consistente
con estándares
procesos predecibles
procesos que mejoran
continuamente
Gestión de requisitosPlanificación de proyectoMonitorización y control de proyectoGestión de suministradoresMediciones y análisisAseguramiento de calidad de proceso y productoGestión de configuración
Enfoque del proceso organizativoDefinición del proceso organizativoGestión de formaciónGestión integrada de proyectoGestión de riesgos
Gestión cuantitativa de calidad y procesoRealización del proceso organizativo
Análisis causal y resoluciónInnovación tecnológica proc. organiz.Implantación innovación del proceso
55(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
SWSW--CMM / CMMI y CMM / CMMI y ááreas clavereas clave
Ad hoc, procesos caóticos
Inicial(1)
Definido(3)
Repetible(2)
Gestionado(4)
Optimizado(5)
proceso disciplinado
proceso consistente
con estándares
procesos predecibles
procesos que mejoran
continuamente
Gestión de requisitosPlanificación de proyectoMonitorización y control de proyectoGestión de suministradoresMediciones y análisisAseguramiento de calidad de proceso y productoGestión de configuración
Enfoque del proceso organizativoDefinición del proceso organizativoGestión de formaciónGestión integrada de proyectoGestión de riesgos
Gestión cuantitativa de calidad y procesoRealización del proceso organizativo
Análisis causal y resoluciónInnovación tecnológica proc. organiz.Implantación innovación del proceso
Entrega en plazo y con cero defectos
56(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
El modelo de calidad SWEl modelo de calidad SW--CMMCMM
Key Areas de SW-CMM por
Nivel Ámbito
GestiónOrganizaciónIngeniería
“Buenas prácticas” que debemos cumplirExigentes para individuos
57(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Modelo organizativo Modelo organizativo SWSW--CMMCMM
58(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
CMM CMM –– TSP TSP -- PSPPSP
CMMI es un modelo mejorado de SW-CMM
TSP(Team Software
Process) es un vehículo efectivo para implementar mejoras basadas en CMM
59(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
CMM CMM –– TSP TSP -- PSPPSP
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
60(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
CMM CMM –– TSP TSP -- PSPPSP
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
61(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
¿¿AlgAlgúún proceso que nos lleve a CMM?n proceso que nos lleve a CMM?
Recomendaciones de consenso para ingenieríasPMBOK-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
62(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Procesos muy extendidosProcesos muy extendidos RUP PMBOK
Inicio Elaboración Construcción Transición
Inicialización Entorno Planificación Gestión de proyecto
Ejecución Modelado de
negocio Requisitos
Requisitos Análisis y
Diseño Implementación
Test Despliegue
Control Gestión de proyecto Gestión de configuración y cambio
Cierre RUP RUP –– 2005 : 2005 : www.rational.com/universitywww.rational.com/university => inscribirse y bajar productos=> inscribirse y bajar productosPMI: PMI: www.pmi.orgwww.pmi.orgPMBOK PMBOK GuideGuide -- 2000 2000 EditionEdition ExcerptsExcerpts WelcomeWelcome: : => versi=> versióón 2000 gratis,n 2000 gratis, versiversióón 2004 non 2004 no
httphttp://://www.pmi.orgwww.pmi.org//prodprod//groupsgroups//publicpublic//documentsdocuments//infoinfo//pp_pmbok2kpp_pmbok2k__conf.aspconf.asp
63(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
PMBOKPMBOK--2004 (2004 (www.pmi.orgwww.pmi.org) )
64(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
La evoluciLa evolucióón de las metodologn de las metodologííasas
Enfoque Ericsson
Objectory Rational SoftwareUnified Process
Select SoftwarePerspective Process
Sterling SoftwareSpex methodology
Enfoque Catalysis Tecnología
Platinum
ComputerAssociates
Aonix
KnowledgeWare
TI SoftwareSynon
Bachman
CadreCayenne
ProtosoftAion
Interactive Development EnvironmentsThomson Software Products
Paul AllenQSSCBOT
65(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005www.rational.com
RationalRational UnifiedUnified ProcessProcess (RUP)(RUP)
66(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RationalRational UnifiedUnified ProcessProcess (RUP)(RUP)
67(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RationalRational UnifiedUnified ProcessProcess(RUP)(RUP)
68(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RationalRational UnifiedUnified ProcessProcess(RUP)(RUP)
69(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Proyecto como instancia de Proceso Proyecto como instancia de Proceso
70(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Herramientas de Herramientas de RationalRational
71(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Herramientas de Herramientas de RationalRational
72(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Otras herramientasOtras herramientas
ComputerAssociates(www.ca.com)
AllFusion
Aonix(www.aonix.com)
Sistemas de Tiempo-real
73(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
¿¿CCóómo implantarlo en PYMES?mo implantarlo en PYMES?
Excusas para no incorporar un procesoDemasiados roles para una organización pequeña => FracasoDemasiado cambio para una organización grande => Fracaso
Una soluciónCreació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 trabajoImplantando, en la medida de lo posible, en equipos pequeños
Menor cambio cuando la organización es grande!
Es un tema candente y existen antecedentesLos procesos caóticos habituales llevan a la desaparición de la empresa por pérdida de clientes
74(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: AntecedentesAntecedentes
Intentos de adaptar CMM a PYMESDynamic 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. 133--149, (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). http://mabwww.gsfc.nasa.gov/papers/DOCS/AMApproach.pdf
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-09, (2001)
75(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ModeloModelo
XSS XS S
Desarrollador
GestorCustomer
SW QualityAssurance
0 2 5 15 0 2 5 15 50 50 personaspersonas
76(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ModeloModelo
GestorCustomer
SW QualityAssurance
SystemGroup
System TestGroup
SW EngineeringGroup
SW ConfigurationManager
XSS XS S0 2 5 15 0 2 5 15 50 50 personaspersonas
77(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Proyecto
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ModeloModelo
ProjectManager
CustomerSW QualityAssurance
SystemGroup
System TestGroup
SW EngineeringGroup
SW ConfigurationManager
XSS XS S
SW QualityAssurance
0 2 5 15 0 2 5 15 50 50 personaspersonas
78(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
ProyectoProyecto
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ModeloModelo
XSS XS S
Proyecto
ProjectManager
CustomerSW QualityAssurance
SystemGroup
System TestGroup
SW EngineeringGroup
SW ConfigurationManager
SW QualityAssurance
0 2 5 15 0 2 5 15 50 50 personaspersonas
79(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
ProyectoProyecto
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ModeloModelo
XSS XS S
Proyecto
ProjectManager
CustomerSW QualityAssurance
SystemGroup
System TestGroup
SW EngineeringGroup
SW ConfigurationManager
SW QualityAssurance
SeniorManager
0 2 5 15 0 2 5 15 50 50 personaspersonas
80(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
ProyectoProyecto
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ModeloModelo
XSS XS S
Proyecto
ProjectManager
CustomerSW QualityAssurance
SystemGroup
System TestGroup
SW EngineeringGroup
Project Conf.Manager
SW QualityAssurance
SeniorManager
SoftwareConfiguration
Manager
0 2 5 15 0 2 5 15 50 50 personaspersonas
81(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Tipo proyectoTipo proyectoTipo proyecto
ProyectoProyecto
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ModeloModelo
XSS XS S
Proyecto
ProjectManager
CustomerSW QualityAssurance
SystemGroup
System TestGroup
SW EngineeringGroup
Project Soft. Conf. Manager
SW QualityAssurance
SeniorManager
SoftwareConfiguration
Manager
0 2 5 15 0 2 5 15 50 50 personaspersonas
82(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Tipo proyectoTipo proyectoTipo proyecto
ProyectoProyecto
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ModeloModelo
XSS XS S
Proyecto
ProjectManager
CustomerSW QualityAssurance
SystemGroup
System TestGroup
SW EngineeringGroup
Project Soft. Conf. Manager
Project Type SW Quality Assurance
Project Type
Manager
Project TypeSW Conf. Manager
SW QualityAssurance
SeniorManager
SoftwareConfiguration
Manager
83(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ÁÁreas de trabajoreas de trabajo
Proceso Proyecto(Abstracto) (Concreto)
1
n1
nk
XXS
XS
S
Nivel deproceso
Nivel deproyecto
84(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: ÁÁreas de trabajoreas de trabajo
Proceso Proyecto(Abstracto) (Concreto)
1
n1
nk
XXS
XS
S
Nivel deproceso
Nivel deproyecto
m
Nivel deTipo proyecto
85(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Tipo proyectoTipo proyectoTipo proyecto
ProyectoProyecto
Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: KeyKey ProcessProcess AreasAreas de CMMde CMM
Proyecto
ProjectManager
CustomerSW QualityAssurance
SystemGroup
System TestGroup
SW EngineeringGroup
Project Soft. Conf. Manager
Project Type SW Quality Assurance
Project Type
Manager
Project TypeSW Conf. Manager
SW QualityAssurance
SeniorManager
SoftwareConfiguration
Manager
Plan
ifica
ción
de p
roye
ctos
Aseguramiento de la calidad
Gestión de la configuración
Gestión requisitosSeguimiento
86(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
UnifiedUnified ProcessProcess y la reutilizaciy la reutilizacióónn
Sólo cubre las fases de desarrollo (ni mantenimiento ni soporte)No existe un soporte explícito para infraestructura de desarrollo multiproyectoNo hay separación entre desarrollo de componentes y desarrollo de aplicacionesLa reutilización se menciona sólo cuando se desarrolla la arquitectura y el modelo del dominio
Sin indicar cómo se alcanza
87(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
¿¿QuQuéé proceso seguimos? proceso seguimos?
88(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RUPRUP
RUP: el más extendido¿Cómo presentaremos la solución?
Siguiendo la norma anteriorMemoria y anexos para el clienteMemoria de la elaboración del proyecto para el suministrador
Usar alguna otra normaSi usamos RUP
¿Qué artefactos desarrollaremos? Hay un conjunto mínimo para proyectos pequeños
Usar el sitio Web definido en RUPUtil para compartir y presentar el proyecto
Veremos unos proyectos pequeños (PFC)
89(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Conjunto mConjunto míínimo de artefactosnimo de artefactos
90(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
RUP: MenRUP: Menúú en la Weben la Web
91(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
ConclusionesConclusiones
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íasEntregar 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 excelenciaEs necesario disponer de herramientas de soporte poderosas existentes pero carasTodo ello es escalable a proyectos pequeños
Los procesos de Los procesos de desarrollo tambidesarrollo tambiéén n afectan al clienteafectan al cliente
93(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
ObjetivosObjetivos
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
94(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Solicitud de propuestas (cliente)Solicitud de propuestas (cliente)
Definición del problema a resolverEstudios a realizar, posiblemente, por terceros
Petición de soluciones de calidad y evaluaciónNormas de presentación obligatorias para suministradoresEvaluación:
Auditorias realizadas por terceros durante el desarrollo del proyectoProcesos de evaluación especiales:
Sector público (concurso), farmacia, medicina, aviónica, ferrocarriles, espacio,..Varios meses, retraso en la resolución, venta y cobro
95(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
GestiGestióón del proyecto en marchan del proyecto en marcha
Proyecto evaluado y aprobadoGestión del proceso de desarrollo del proyecto
Establecimiento de un proceso Carencia habitual => FRACASOS
El afectado principal es le cliente
Responsabilidades e interlocuciónEjemplos en la Web
Texas: http://www.dir.state.tx.us/eod/qa/index.htmhttp://www.cio-dpi.gc.ca/emf-cag/pmg-ggp/corp-min-process/risk-risq/risk-risq06_e.aspDIS, 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 clienteGestión del conocimiento del cliente
96(C) J.M. Pikatza Dep. L.S.I. (UPV/EHU), 2005
Contenidos del cursoContenidos 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
97
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Aspectos a considerarAspectos a considerar
Identificación de oportunidades de reutilización
Dominios y familias de productos
Ingeniería basada en componentes
IdentificaciIdentificacióón de n de oportunidades de oportunidades de
reutilizacireutilizacióónn
ObjetivosObjetivos
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 quPor quéé reutilizar?reutilizar?
La reutilización no es un fin en sí mismo
La motivación final es económicaEs 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 nuevoEsto no es nuevo
Lo hemos practicado siempre de alguna manera
Algunas formas ad-hoc de hacerloCopiar 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
ReutilizaciReutilizacióón sistemn sistemááticatica
El uso sistemático de activos (assets) reutilizablesen el desarrollo de nuevos sistemas para alcanzar beneficios sustanciales en la capacidad de negocioy rendimiento en un área de negocio o dominioExige:
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
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
La reutilizaciLa reutilizacióón se da entre n se da entre proyectosproyectos
Proyecto AProyecto BProyecto C
Activos reutilizados
104
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Aspectos bAspectos báásicos de la mejora sicos de la mejora basada en la reutilizacibasada en la reutilizacióónn
Requiere del compromiso de la direcciónRequiere cambios en los procesos y la organizaciónDebe ser introducido sistemática e incrementalmenteEl alcance del ciclo de mejora basada en la reutilización es un dominio de aplicación
105
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Roles en la mejora basada en la Roles en la mejora basada en la reutilizacireutilizacióónn
Patrocinador: Da soporte al compromiso y se compromete en la mejora basada en la reutilización
Monitoriza el rendimientoAsegura los recursos
Director de reutilización: Define objetivos de reutilizaciónIdentifica acciones de mejora basada en la reutilización
Ingeniero de reutilización: Implementa las acciones del programa de reutilización
Por Por dominiodominio
Incluso Incluso la la
misma misma personapersona
Beneficios de la reutilizaciBeneficios de la reutilizacióónn
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
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
ResumenResumen
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
Dominios y familias Dominios y familias de productosde productos
109
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
¿¿QuQuéé desarrollamos?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
110
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Las familias segLas familias segúún n ParnasParnas
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 1979
111
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Las familias segLas familias segúún n DijkstraDijkstra
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
DominiosDominios
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 dominiosEjemplos de dominios
Control de tráfico aéreoControl de tráfico aéreo en Hondarribia
Control de tráfico aéreo en Frankfurt
Interfaces de usuarioSistema con pantalla táctil
Sistema con ratón
Acceso a bases de datosRutina de acceso a bases de datos Oracle
Rutina de acceso a ficheros indexados
114
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Familias de productos yFamilias de productos yLLííneas de productosneas de productos
Familias de productosUn 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 productosUna colección de productos que comparten un conjunto común de características que atacan las necesidades específicas de un área de negocio dadoPerspectiva de negocio: generalmente asociado con un dominio de negocio
115
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Cambios en el ciclo de vidaCambios en el ciclo de vidaEstudio de factibilidad
Análisis de requisitos
Diseño
Codificación y prueba
Integración y prueba
Mantenimiento
Ingeniería del
dominio
Ingeniería de la
aplicación
Ingeniería de la
aplicación
Ingeniería de la
aplicación
116
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Esquema del proceso de Esquema del proceso de reutilizacireutilizacióónn
Objetivos de negocio
DominioNecesidades
producto
Ingeniería del dominio
Ingeniería de aplicaciones
Uso del productoNecesidades
usuario
ProductoaplicaciónProductoaplicaciónProducto aplicación
Infraestructura común
Conocimiento del dominio
117
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
Proceso de reutilizaciProceso de reutilizacióónn
Dos ciclos de vida con objetivos diferentes pero complementarios
Ingeniería del dominioEstablece 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 aplicacionesMecánicamente deriva aplicaciones y los instancia para necesidades especiales de los clientes
118
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
AnAnáálisis del dominiolisis del dominio
Establece una visión compartida del dominioDefine su alcance y el modo en el que los miembros del dominio son similares a los demásHace comprender lo que tienen en común los miembros del dominio y sus diferencias
El análisis del dominio generaLa definición del dominio (incluye nombre, sinopsis, productos, glosario, tecnología, clientes, aspectos organizativos, etc.)Comunalidades y variabilidadesModelo de decisión
Serie de preguntas que permiten caracterizar un miembro del dominio del resto de miembros
119
(C)
J.M
. Pik
atza
D
ep. L
.S.I.
(UP
V/E
HU
), 20
05
AnAnáálisis del dominiolisis del dominio
K. K. KangKang, S. Cohen, J. , S. Cohen, J. HessHess, W. , W. NovakNovak, , andand S. S. PetersonPeterson. . FeatureFeature--OrientedOriented DomainDomainAn~ysisAn~ysis (FODA). (FODA). FeasibilityFeasibility StudyStudy. . TechnicalTechnical ReportReport CMU/SE[CMU/SE[--9090--TRTR--21, Software 21, Software EngineeringEngineering InstituteInstitute, , PittsburghPittsburgh, PA 15213, Nov. 1990, PA 15213, Nov. 1990
DefiniciDefinicióón del dominion del dominio2. Nombre, para hacer referencia al
dominio3. 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
DefiniciDefinicióón n de de
dominiodominio
EjemploEjemplo
DefiniciDefinicióón n de de
dominiodominio
EjemploEjemplo
Consejos para la definiciConsejos para la definicióón de n de dominiosdominios
Debe representar una visión común y de consensode 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 iterativoNo sale perfecta la primera vez
ComunalidadComunalidad y variabilidady 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 Ejemplos de comunalidadcomunalidad
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 empleadaSólo se usan páginas .jsp
Modelo “thin client” (cliente ligero)
Ejemplos de variabilidadEjemplos 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 utilizadoPor 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 Consejos para la comunalidadcomunalidad y y variabilidadvariabilidad
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ónpor parte de los usuarios
Limitar la explosión de combinaciones de variabilidad
El consenso simplifica enormemente el dominio
Modelo de decisiModelo de decisióón (MD)n (MD)
Un modelo de decisión recoge todas las decisiones abiertas que caracterizan un dominio
Con los rangos de sus posibles valores de decisión
Una formalización de las variabilidades
Cada decisión puede ser representada como:Una pregunta (una variable) y Un rango de respuestas válidas (valores de la variable)
Puede ser representado como:Una tablaUna declaración de tipo (p. ej. esquema de BD)Un árbol (p. ej. FODA)
RepresentaciRepresentacióón tabular de un MDn tabular de un MD
Decisiones con sus posibles valores:
……………….…………….…………………
Mensajes en la pantalla del móvil
En/fr/esIdioma de intereacción
Habilidad para mantener una llamada entrante
Si/No
Sólo si el llamante habla otro idioma
Llamada esperando
Habilidad para llamar
Habilidad para responder
Si
Si/No
Si/No
Características llamada
Hacer llamada
Responder llamada
SignificadoValoresDecisiones
Esquema de representaciEsquema de representacióón de un n de un MDMD
TiposTipos 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 adicionalesOpcional o obligatorio
Valor por defecto
Modelo de decisiModelo de decisióón para el n para el ejemplo eejemplo e--ComercioComercio
SectorDeAplicación: {libros|consumibles}NumModulos: [4-12]Modulo:
IdentifModulo: StringVersión
Numversion: realCaracterísticas: String
ModulosInstalados: conjunto no vacioTecnología: (ASP, Java)IdiomaDocumentación: (EU|EN|ES)Restricción:
SectorDeAplicación = libros
Puntos de variación
RepresentaciRepresentacióón arborescente de n arborescente de un MD: Modelo de caracterun MD: Modelo de caracteríísticassticas
Metodología aplicable:FODA (Feature Oriented Decision Analisis), SEI
http://www.sei.cmu.edu/domain-engineering/FODA.html
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
RepresentaciRepresentacióón arborescente de n arborescente de un MD: Modelo de caracterun MD: Modelo de caracteríísticassticas
Las decisiones impactan en Las decisiones impactan en todos los productos del procesotodos 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
Código fuente
Arquitectura /diseño
Documentos de requisitos
IngenierIngenieríía basada en a basada en componentescomponentes
IngenierIngenieríía basada en a basada en componentes (CBE)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 IngenierFases principales en Ingenieríía a basada en componentes (CBE)basada en componentes (CBE)
DesarrolloDesarrollo
AplicaciAplicacióón 1n 1 AplicaciAplicacióón 2n 2 AplicaciAplicacióón nn n
Base de Base de activosactivos
EspecializaciEspecializacióón n y ensambladoy ensamblado
RetroalimentaciRetroalimentacióónn
Ingeniería del dominio
Ingeniería de la aplicación
Ingeniería de la aplicación
Ingeniería de la aplicación
ComponentesComponentes
Un componente es un activo software reutilizable, que puede formar parte de un sistema softwareLos componentes son reutilizados en tiempo de producción cuando se ensambla el sistemaLos componentes reutilizables son:
Empaquetados: Tienen existencia independientemente de la aplicación en la que se usan. Nombre propioEvolucionables: 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
Compatible hacia atrás
Flexibles: Adaptable a contextos específicos
Desarrollo del softwareDesarrollo 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 componentesArquitectura 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 Componentes comerciales (COTS)(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 COTSRoles en el mercado de COTS
El vendedor de COTS El desarrollador de software
Desarrollo de software basado en COTSConsultor/Evaluador de COTS/Asistente legalBroker:
Corredor o agente que relaciona clientes con vendedores
EscrowEl 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 COTSRoles en el mercado de COTS
Vendedor
de COTSDesarrollador de software
Consultor/ Evaluador de COTS/
Asistente legal
Broker
Escrow
CBE con COTSCBE con COTS
El uso de componentes construidos por terceros es lo normal en otras industriasEL uso de COTS cambia el énfasis
De desarrollo de aplicaciones a ensamblado de aplicaciones
Requiere conocimiento y gestión de proveedoresRequiere flexibilidad en los requisitos de los usuarios
Beneficios del uso de COTSBeneficios del uso de COTS
Es más baratoPlazos de entrega más cortosPermite hacer uso de las últimas tecnologíasCalidad creciente:
Los COTS se prueban en el mercado
Riesgos del uso de COTS (I)Riesgos del uso de COTS (I)
Problemas de integración no previstosImprecisión en las estimaciones de proyectosProblemas de compatibilidad e interoperabilidad
El mantenimiento puede ser costosoAparición de nuevos problemas de integraciónNecesidad de adquirir “upgrades” no deseadasDependencia del vendedor
El uso de estándares de propietario lleva a:Problemas de portabilidad e integraciónDependencia del vendedor
La integración de COTS de distintos vendedores aumenta los problemas
Riesgos del uso de COTS (II)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 construirlosRazones para construirlos
No hay COTS adecuados en el mercadoLos 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 necesarioLos recursos y habilidades necesarios para desarrollar un componente están altamente disponibles en la compañíaLa compañía no puede confiar completamente en el proveedorLa compañía acepta el tiempo previsto de puesta en el mercado
Razones para comprarRazones para comprar
Hay COTS adecuados en el mercadoSe espera una pequeña y predecible evolución de los componentesSe puede disponer de código de calidad y documentaciónLos recursos y habilidades de la compañía son escasosLa compañía confía en el proveedorLa compañía necesita reducir el tiempo de puesta en el mercado
ResumenResumen
Los componentes son activos empaquetados, evolucionables y flexiblesLa Ingeniería Basada en Componentes pretende la derivación de aplicaciones software a partir de componentes reutilizables de una base de activosHay un cambio importante en el paso del desarrollo de aplicaciones al ensamblado de aplicacionesLos componentes de software comerciales (COTS) son usados crecientemente en la construcción de sistemas
Pero es necesario gestionar algunos riesgos