ingeniería del software - siul02.si.ehu.essiul02.si.ehu.es/~alfredo/iso/calidad del software...

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


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.


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.


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.


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.


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.


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


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?


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


¿¿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


¿¿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


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


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


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

¿¿CCóómo podemos mo podemos presentar bien un presentar bien un

proyecto al cliente?proyecto al cliente?


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


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


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


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


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


Motivación

• En otras ingenierías:

Solución

PeticiónPropuesta

DefiniciónConstrucción

Implantación• En nuestra ingeniería:

Cliente

Solución

PeticiónPropuesta


Implantación

Definición

Construcción

Cliente


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


Implantación

Definición

Construcción

Cliente


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


ImplantaciónCliente


Contenidos



Cliente

Solución

PeticiónPropuesta


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


Cliente

Solución

PeticiónPropuesta


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


Elaboracióncompleta

Evaluaciónvisado


Contenidos



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


Contenidos



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



• 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









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









propia








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









propia








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









propia








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









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









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









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









propia

• Implantación de seguridad

– Plan de seguridad– Metodologías– Herramientas

• Identificación de puntos críticos

– Por su importancia– Exigidos por leyes









propia

• Especificación detallada de requisitos

– Funcionales y no funcionales

– De producto y de proceso– Debe depender de la

metodología empleada









propia

• Determinar y justificar el costo económico del proyecto

– Desglosada en capítulos









propia

• Documentos requeridos por exigencias legales

– LOPD– LSSI– Firma electrónica– Etc.

¿¿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?


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


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


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


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


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


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


Modelo organizativo Modelo organizativo SWSW--CMMCMM


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



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



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


¿¿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


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


PMBOKPMBOK--2004 (2004 (www.pmi.orgwww.pmi.org) )


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)


RationalRational UnifiedUnified ProcessProcess (RUP)(RUP)


RationalRational UnifiedUnified ProcessProcess(RUP)(RUP)


Proyecto como instancia de Proceso Proyecto como instancia de Proceso


Herramientas de Herramientas de RationalRational


Otras herramientasOtras herramientas

ComputerAssociates(www.ca.com)

AllFusion

Aonix(www.aonix.com)

Sistemas de Tiempo-real


¿¿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


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)


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



GestorCustomer

SW QualityAssurance

SystemGroup

System TestGroup

SW EngineeringGroup

SW ConfigurationManager

XSS XS S0 2 5 15 0 2 5 15 50 50 personaspersonas


Proyecto


ProjectManager

CustomerSW QualityAssurance

SystemGroup

System TestGroup

SW EngineeringGroup


XSS XS S

SW QualityAssurance



ProyectoProyecto


XSS XS S

Proyecto

ProjectManager


SystemGroup

System TestGroup

SW EngineeringGroup


SW QualityAssurance



ProyectoProyecto


XSS XS S

Proyecto

ProjectManager


SystemGroup

System TestGroup

SW EngineeringGroup


SW QualityAssurance

SeniorManager



ProyectoProyecto


XSS XS S

Proyecto

ProjectManager


SystemGroup

System TestGroup

SW EngineeringGroup

Project Conf.Manager

SW QualityAssurance

SeniorManager

SoftwareConfiguration

Manager



Tipo proyectoTipo proyectoTipo proyecto

ProyectoProyecto


XSS XS S

Proyecto

ProjectManager


SystemGroup

System TestGroup

SW EngineeringGroup

Project Soft. Conf. Manager

SW QualityAssurance

SeniorManager


Manager




ProyectoProyecto


XSS XS S

Proyecto

ProjectManager


SystemGroup

System TestGroup

SW EngineeringGroup


Project Type SW Quality Assurance

Project Type

Manager

Project TypeSW Conf. Manager

SW QualityAssurance

SeniorManager


Manager


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


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



ProyectoProyecto

Procesos de desarrollo para PYMES: Procesos de desarrollo para PYMES: KeyKey ProcessProcess AreasAreas de CMMde CMM

Proyecto

ProjectManager


SystemGroup

System TestGroup

SW EngineeringGroup


Project Type SW Quality Assurance

Project Type

Manager

Project TypeSW Conf. Manager

SW QualityAssurance

SeniorManager


Manager

Plan

ifica

ción

de p

roye

ctos

Aseguramiento de la calidad

Gestión de la configuración

Gestión requisitosSeguimiento


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


¿¿QuQuéé proceso seguimos? proceso seguimos?


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)


Conjunto mConjunto míínimo de artefactosnimo de artefactos


RUP: MenRUP: Menúú en la Weben la Web


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


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


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


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

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


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

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



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

ingeniería del software - siul02.si.ehu.essiul02.si.ehu.es/~alfredo/iso/calidad del software...

Documents