06 - CicloVidaProyectoSW

LS3148 - Calidad de Software3IM1Universidad Antonio de NebrijaJusto Hidalgo6. Componentes del Ciclo de Vida de un Proyecto SW

Calidad de Software - 6. Ciclo de Vida - Justo Hidalgo

ContenidosIntroduccin al ciclo de vida de un proyecto SWIntroduccin a Metodologas SWV&VDefectosPruebasMantenimiento SW


Introduccin (I)Actividades a realizar durante el desarrollo y mantenimiento de un producto SW.Dos pasos:Ciclo de Vida de DesarrolloMantenimiento y Operacin


Introduccin (II)Ciclo de Vida de Desarrollo:RevisionesPara cada artefacto generado:Reuniones formales de diseoPeer reviewsOpiniones de ExpertosPruebas SWLo veremos ms adelante en detalle.


Introduccin (III)Operacin y Mantenimiento:CorrectivoAdaptativoPerfectivoTambin lo veremos ms adelante.


Introduccin (y IV)SQA de los participantes externos:Subcontratas (outsourcing, body-shopping)COTS Commercial Off-The-Shelf- SW.


MetodologasAntes de ver cmo la calidad afecta al ciclo de vida de un proyecto SWhay que saber qu es el ciclo de vida de un proyecto SW!


ContenidosDefinicinUn hechoVentajas de la metodologaCiclo de vidaFunciones bsicas de una metodologaCiclos de vida clsicosCiclo de vida en cascadaCiclo de vida en cascada con refinamiento por mejorasPrototipado y maquetajeCiclo de vida en espiralProcesos clsicos:IEEEMtrica v3Proceso Unificado


DefinicinConjunto de mtodos que se utilizan para desarrollar una actividad con el objetivo de formalizarla y optimizarla.En ISW: optimizacin del proceso y producto SW.Elementos de una metodologa:Fases: jerarquizacin ordenada del desarrollo completo.Productos -intermedios y final-.Procedimientos y herramientas.Criterios de evaluacin.


Un hechoLa mayor parte de los proyectos SW FRACASAN:Mala evaluacin de objetivos.Mala planificacin de recursos/tiempos/costes.Participacin insuficiente de la direccin.Falta de acuerdos entre objetivos y planificacin.Rotacin del personal clave.Cambio de objetivos sin revisar la planificacin.Propsito no claro por/para los usuarios.Falta de hitos y metas.Poca comprensin del problema.Poca calidad del producto.Mala planificacin A PROPSITO.


Ventajas de la metodologa (I)Desde el punto de vista de gestinFacilita la planificacinFacilita el control y seguimiento de los proyectosMejora del ratio coste/beneficioOptimiza la gestin de recursosFacilita la comunicacin entre los participantesFacilita la evaluacin de los proyectos


Ventajas de la metodologa (II)Desde el punto de vista de los Ingenieros en el desarrolloComprensin del problemaOptimizacin del proceso, y dentro del proceso las fases a seguirFacilidad de mantenimientoAlgunos criterios sobre reusabilidad


Ventajas de la metodologa (y III)Desde el punto de vista del cliente/usuario finalGarantiza en la medida de lo posible la calidad del productoMayor confianza


Ciclo de vida o PARADIGMA: conjunto de fases por las que pasa el sistema que se est desarrollando desde que nace la idea hasta que el SW se retira o se reemplaza.


Funciones bsicas de una metodologaDefinicin del ciclo de vidaQue se adece a las condiciones y caractersticas del desarrollo.Determinacin de las fases dentro del ciclo de vida.Definicin de resultados intermedios y finales.Conjunto de mtodos, herramientas y tcnicas para facilitar la tarea del IS y aumentar su productividad.


Ciclos de vida clsicos (I)Ciclo de vida en cascadaCaractersticas:Visin del proceso de desarrollo como una sucesin de etapas que producen productos intermedios.Deben desarrollarse todas las fases.Limitaciones:No se permiten iteraciones.Los requisitos SE CONGELAN AL PRINCIPIO DEL PROYECTO.No existe un producto enseable hasta el final del proyecto.


Ciclos de vida clsicos (II)


Ciclos de vida clsicos (III)Ciclo de vida en cascada con refinamiento por mejorasAade la capacidad de retorno de cada fase a la fase anterior. Despus se permiti pasar a cualquier fase.


Ciclos de vida clsicos (IV)


Ciclos de vida clsicos (V)Prototipado y maquetajePara evitar la tercera limitacin del ciclo de vida en cascada se crean los siguientes modelos de desarrollo de productos SW:Desarrollo basado en prototipo:Valida la solucin informtica.Es ya parte del sistema.Da una visin de la dificultad del proyecto final.Desarrollo basado en maqueta:No valida la solucin informtica.Se usa si no se conoce bien el nivel de dificultad.Interfaz de usuario y mdulo de comunicaciones.


Ciclos de vida clsicos (VI)Ciclo de vida en espiralUtilizado cuando existen muchos riesgos y hay que buscar alternativas.Desventajas:Muy complicado.Consume muchos recursos.Las fases no estn claramente definidas.


Ciclos de vida clsicos (y VII)


Procesos ClsicosIntroducimos ahora brevemente un conjunto de procesos que se han utilizado y se utilizan a lo largo de la historia de la ingeniera de software:Proceso IEEE 12207 (ms adelante)Proceso Mtrica v3.Proceso Unificado.


Procesos Clsicos: Mtrica v3http://www.map.es/csi/metrica3Procesos Principales:Planificacin (PSI)DesarrolloEstudio de viabilidad (EVS)Anlisis (ASI)Diseo (DSI)Construccin (CSI)Implantacin y aceptacin (IAS)Mantenimiento (MSI)


Proceso Unificado


Qu es el Proceso Unificado (I)Contaremos poco del PU ahora, pues lo estudiaremos en detalle posteriormente.El proceso unificado proviene de otros exitosos procesos anteriores creados por:James Rumbaugh: OMT (Object Modeling Technique)Grady Booch: Chief Scientist.Ivar Jacobson:Concepto de Building Blocks.Diagramas de secuencia.SDL.Casos de uso.Objectory Process.


Qu es el Proceso Unificado (II)Proviene de:ObjectoryOMTRational Approach


Qu es el Proceso Unificado (y III)Unified Software Development ProcessDefinido por Ivar Jacobson, James Rumbaugh y Grady Booch.Un proceso define QUIN est haciendo QU, CUNDO y CMO para llegar a un objetivo.En la ingeniera de sw el objetivo es construir un producto sw o mejorar uno ya existente dentro de un esquema temporal, econmico y de calidad.Un proceso de desarrollo es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software.El proceso unificado no es un nico proceso, sino un framework genrico.


CaractersticasEs guiado por casos de uso (use-case driven)Se centra en la arquitectura (architecture-centric)Es iterativo (iterative)Es incremental (incremental)


Use-case drivenUn sistema sw existe para servir a sus usuarios.Por tanto, tiene sentido saber qu es lo que los usuarios quieren, no? Pues no siempre es as.Un usuario no slo es la persona que lo utiliza, sino cualquier sistema que haga uso de la aplicacin creada -sistema de gestin, otro componente externo, los diferentes tipos de usuarios humanos, etc.-Las interacciones entre los usuarios y el sistema se denominan casos de uso -use cases-.


Ejemplo de caso de uso


Architecture-centricEl proceso se basa en la arquitectura del sw.Su papel es parecido al de la arquitectura en la construccin de edificios.El concepto de arquitectura sw conlleva los aspectos tanto estticos como dinmicos del sistema. Estticos: diagrama de herencia, diagrama de paquetes.Dinmicos: diagrama de secuencia, de actividad, etc.Se ve influido por otros temas tales como el sistema operativo sobre el que corre el sistema, hw, comunicaciones.Todo producto tiene Forma y Funcin:Funcin: casos de uso.Forma: arquitectura del sistema.


Iterative & Incremental (I)El desarrollo de un producto comercial es un proceso largo, complicado y arriesgado.Se suele acometer a travs de mini-proyectos. Cada mini-proyecto es una iteracin del producto final.El final de cada mini-proyecto es un incremento del producto final.Un incremento no tiene por qu ser aditivo -sobre todo al principio, pueden ser reemplazos de implementacin de casos de uso-.Cada iteracin trata un conjunto de casos de uso, en cada momento los ms crticos que queden.


Iterative & Incremental (y II)Ventajas de las iteraciones controladas:Se reduce el riesgo de coste. Si hay que repetir la iteracin, slo se pierde ese tiempo.Antes exista el riesgo de tener que repetir el proyecto completo por un error del comienzo.Se reduce el riesgo de tiempo de salida al mercado.Los desarrolladores -y el equipo en general- mejoran sus tiempos al tener objetivos claros y cercanos en el tiempo.Y, repitiendo lo anterior: las necesidades del usuario no siempre pueden definirse al comienzo del proyecto -la famosa frase de el cliente no tiene ni idea de lo que quiere se repite tantas veces que no ser que estamos planteando mal el esquema de la solucin?-.


Vida del Proceso UnificadoEl proceso se repite sobre una serie de CICLOS, cada uno de los cules termina con una release: versin entregable del producto.Cada versin de una herramienta comercial que se vende en las tiendas es una release -entrega-.Cada ciclo consta de cuatro FASES:ConcepcinElaboracinConstruccinTransicinCada fase se puede subdividir en iteraciones, tal y como vimos anteriormente.


Representaciones del Producto SW: dependencias


Visin global del ciclo de vida


Fases del Proceso Unificado (I)Como hemos dicho antes, cada ciclo se divide en cuatro fases: concepcin, elaboracin, construccin y transicin.Una fase acaba de un hito -milestone-:Un hito ocurre cuando se encuentran disponibles un conjunto de artefactos, es decir, modelos o documentos en un estado prescrito determinado.Por qu?Decisiones a tomar antes de pasar a la siguiente fase.Monitorizacin del trabajo por parte de desarrolladores y gestores.Categorizacin de los datos obtenidos: anlisis.


Fases del Proceso Unificado (II)Concepcin -inception-A partir de la idea se desarrolla la visin del producto final y se elabora el caso de negocio.Esta fase responde a las siguientes cuestiones:Qu va a realizar el sistema principalmente.Cmo sera un esqueleto de arquitectura del sistema.Cul es el plan de proyecto y cunto costara.


Fases del Proceso Unificado (III)Elaboracin -elaboration-Se disea la arquitectura del sistemadesde todos los puntos de vista -modelos del sistema-.Se definen todos los casos de uso.Los casos de uso ms crticos se desarrollan:ARCHITECTURE BASELINE: la lnea base de la arquitectura.Al final de esta fase, el gestor ya es capaz de planificar las actividades y recursos necesarios para completar el proyecto:Hemos logrado la estabilidad suficiente en casos de uso, arquitectura y planificacin como para asegurar el xito del proyecto?


Fases del Proceso Unificado (IV)Construccin -construction-El producto se construye.Ahora se aade el msculo al esqueleto.La lnea base crece hasta convertirse en el sw completo.Se supone que la arquitectura del sistema es estable, a pesar de que puede haber modificaciones menores.Al final de la fase el producto est terminado -todos los casos de uso implementados-, aunque todava nos podemos encontrar con bugs:Satisface el producto las necesidades del usuario?


Fases del Proceso Unificado (y V)Transicin -transition-Perodo durante el cul el SW est en beta release.Otras tareas:Manufactura.Formacin, ayuda en lnea, Correccin de defectos.


Relaciones de las Cuatro PsProcessProductProjectToolsPeopleParticipantesAutomatizacinPlantillaResultado


Otros procesosMtodo Shlaer/Mellorwww.projtech.comParticionamiento del sistema en dominios para su posterior anlisis.Verificacin del anlisis mediante ejecucin.Mtodo Coad/YourdonAproximacin orientada a prototipoAproximacin ligera


Fin Metodologas


V&VV&V: Verificacin & ValidacinUtilizar apuntes de ISW ICualificacin: se puede usar? Est centrado en mantenimiento.


Defectos (I)El Plan de Calidad ha de medir:La efectividad del plan en eliminar defectos de proyectoEl coste de eliminacin de defectos de proyecto


Defectos (II). Por qu?Fuente: Boehm (1981)


Defectos (y III). Distribucin


PruebasVitales en el Plan de Calidad.Lo veremos en detalle al final del cuatrimestre.


Mantenimiento (I). TiposMantenimiento correctivoMantenimiento adaptativoMantenimiento perfectivoM. perfectivo puroM. preventivo


Mantenimiento (II). CausasError de cdigoFallo de documentacin (textos, ayuda en lnea, )Documentacin imprecisa / vaga.Conocimiento insuficiente por parte del usuario (imputable?).


Mantenimiento (III). FundamentosCalidad del paquete SWFactores de operacinCorreccin de info de salida, de codificacin, -FiabilidadFactores de revisinCapacidad de mantenimientoFlexibilidadTestabilidadFactores de transicinPortabilidadInteroperabilidad


Mantenimiento (y IV). FundamentosPoltica de MantenimientoP. de desarrollo de versionesCuntas versiones operativas al mismo tiempo?Estructura SecuencialEstructura ArbreaP. de cambiosMtodo de examen de cada peticin de cambios.


BibliografaArtculos:Theory-W Software Project Management: principles and examples. B.Boehm, R. Ross, UCLA. IEEE Transactions on Software Engineering, 1989.The Shlaer-Mellor method. S. Shlaer, S. J. Mellor. Project Technology.Enlaces:Cetus Links sobre metodologas: http://www.cetus-links.org/oo_ooa_ood_methods.html


Ejemplo: hablar del proyecto de CECA, cmo CECA en ningn momento tiene en cuenta lo que sus usuarios pueden o no querer.

Gif: pgina 8 del UP (figure 1.2)Gif: pgina 9 del UP (figure 1.3)

Figure 1.4 en pgina 10.

Documents

06 - CicloVidaProyectoSW