Proceso de software y ciclo de vida

8/7/2019 Proceso de software y ciclo de vida

1/72

Gonzalo MndezDpto. de Ingeniera de Software e Inteligencia Artificial

Facultad de Informtica

Universidad Complutense de Madrid

Curso 2008-2009

Proceso Software yCiclo de Vida

Presentacin de IS

Proyecto de IS

Introduccin a la IS

Proceso y Ciclo de Vida


2/72

Conceptos importantes

Personas

los que trabajanlos que trabajan Producto

lo que se obtienelo que se obtiene Proyecto

la pauta a seguir para desarrollar un productola pauta a seguir para desarrollar un producto Proceso

la pauta a seguir para desarrollar un proyectola pauta a seguir para desarrollar un proyecto


3/72

Un traje

Personas

El sastreEl sastre Producto

El trajeEl traje

Proyecto: el sastre, el traje, el presupuesto del traje, el traje en sel sastre, el traje, el presupuesto del traje, el traje en s, los, los

pasos a dar para hacer el traje...pasos a dar para hacer el traje...

Proceso La secuencia de acciones para hacer un traje concretoLa secuencia de acciones para hacer un traje concreto


4/72

Una cena

Personas

Empleados de una empresa de cateringEmpleados de una empresa de catering Producto

La cena que se sirveLa cena que se sirve

Proyecto El menEl men, el presupuesto, lo que hay que hacer para, el presupuesto, lo que hay que hacer para

conseguir el menconseguir el men, ..., ... Proceso

La secuencia de acciones de servir una cenaLa secuencia de acciones de servir una cena


5/72

Una gama de automviles

Personas

Empleados de la marcaEmpleados de la marca Producto

Los automLos automvilesviles

Proyecto Desarrollo de un modelo nuevoDesarrollo de un modelo nuevo

Proceso Las instrucciones de la empresa sobre cLas instrucciones de la empresa sobre cmomo

desarrollar un modelo nuevodesarrollar un modelo nuevo


6/72

Para vosotros

Personas

vuestro grupovuestro grupo Producto

la aplicacila aplicacin elegidan elegida

Proyecto parte prparte prctica ISctica IS

Proceso entregas mensuales + centregas mensuales + cmo vosotros decidmo vosotros decidisis

organizarosorganizaros


7/72

Capas de la IS

Capa de enfoque de calidad

Capa de proceso Capa de mtodos

Capa de herramientas


8/72

Capas de la IS

Capa de calidad

Base de cualquier proceso de ingenierBase de cualquier proceso de ingenieraa La IS se basa en calidadLa IS se basa en calidad

Mejores tcnicas de construccin de software

Capa de proceso Capa que une calidad y mCapa que une calidad y mtodostodos

Desarrollo racional de la IS

CConjuntoonjunto de actividades y resultados asociados quede actividades y resultados asociados que

sirven para construir un producto softwaresirven para construir un producto software


9/72

Capas de la IS

Capa de mtodos

Un mUn mtodo incluye:todo incluye: Anlisis de requisitos Diseo

Construccin de programas

Prueba

Mantenimiento

Suelen estar bastante ligados al procesoSuelen estar bastante ligados al proceso

Capa de herramientas Soporte automSoporte automtico o semiautomtico o semiautomtico para el proceso y lostico para el proceso y los

mmtodostodos Herramientas CASEHerramientas CASE


10/72

Visin general de la IS

Con independencia del modelo de proceso hay

tres fases genricas: Fase de definiciFase de definicinn

Fase de desarrolloFase de desarrollo Fase de mantenimientoFase de mantenimiento

Cada una de estas fases se descompone en unconjunto de tareas


11/72

Fase de definicin/especificacin

Se identifican requisitos de sistema y software:

InformaciInformacin a procesarn a procesar FunciFuncin y rendimiento deseadosn y rendimiento deseados

Comportamiento del sistemaComportamiento del sistema Interfaces establecidasInterfaces establecidas

Restricciones de diseRestricciones de diseoo

Tareas principales:Tareas principales: Planificacin del proyecto software

Ingeniera de sistemas o de informacin Anlisis de requisitos


12/72

Fase de desarrollo

Se define:

CCmo disemo disear las estructuras de datosar las estructuras de datos CCmo implementar las funcionesmo implementar las funciones

CCmo caracterizar las interfacesmo caracterizar las interfaces CCmo traducir el disemo traducir el diseo a programacio a programacinn

CCmo validar el producto (pruebas, verificacimo validar el producto (pruebas, verificacin)n)

Tareas principales:Tareas principales: Diseo del software

Generacin del cdigo Pruebas del software


13/72

Fase de mantenimiento

Centrada en cambios que se pueda necesitar realizar

sobre un producto Se vuelven a aplicar las fases de definicin y

desarrollo, pero sobre software ya existente

Pueden producirse cuatro tipos de cambio: CorrecciCorreccinn: Corregir los defectos: Corregir los defectos

AdaptaciAdaptaci

nn

: Modificaciones por cambio externo: Modificaciones por cambio externo

MejoraMejora: Ampliar los requisitos funcionales originales, a: Ampliar los requisitos funcionales originales, apeticipeticin del clienten del cliente

PrevenciPrevencinn: Cambio para facilitar el cambio: Cambio para facilitar el cambio


14/72


Estas fases se complementan con las

actividades de soporte No crean softwareNo crean software Mejoran suMejoran su calidadcalidad

Facilitan su desarrolloFacilitan su desarrollo Se aplican a lo largo de todo el proceso del

software


15/72


Ejemplos de actividades de soporte

DocumentaciDocumentacinn GestiGestin de configuracin de configuracinn Seguimiento y control del proyecto de softwareSeguimiento y control del proyecto de software Revisiones tRevisiones tcnicas formalescnicas formales GarantGaranta de la calidad del softwarea de la calidad del software

GestiGestin de reutilizacin de reutilizacinn MedicionesMediciones GestiGestin de riesgosn de riesgos


16/72

Proceso software

Conjunto estructurado de actividades y resultadosasociados requeridos para desarrollar un sistema desoftware EspecificaciEspecificacinn: establecer requisitos y restricciones: establecer requisitos y restricciones DiseDiseoo: Producir un modelo en papel del sistema: Producir un modelo en papel del sistema ImplementaciImplementacinn: construcci: construccin del sistema de softwaren del sistema de software ValidaciValidacinn:: verificar (por ejemplo mediante pruebas) que elverificar (por ejemplo mediante pruebas) que el

sistema cumple con las especificaciones requeridassistema cumple con las especificaciones requeridas

InstalaciInstalacinn: entregar el sistema al usuario: entregar el sistema al usuario EvoluciEvolucin y mantenimienton y mantenimiento:: cambiar/adaptar el softwarecambiar/adaptar el software

segsegn las demandas;n las demandas; reparar fallos en el sistemareparar fallos en el sistema


17/72

Modelos de proceso

Un modelo de proceso, o paradigma de IS, es

una plantilla, patrn o marco que define elproceso a travs del cual se crea software

Dicho de otra forma, los procesos soninstancias de un modelo de proceso

En esta asignatura los trminos proceso ymodelo de proceso se utilizan indistintamente


18/72

Modelos de proceso

Una organizacin podra variar su modelo de

proceso para cada proyecto, segn: La naturaleza del proyectoLa naturaleza del proyecto

La naturaleza de la aplicaciLa naturaleza de la aplicacinn Los mLos mtodos y herramientas a utilizartodos y herramientas a utilizar

Los controles y entregas requeridasLos controles y entregas requeridas


19/72

Caractersticas del proceso

Entendible

Visibilidad: Grado en que las actividades del procesoproporcionan resultados

Soportable por herramientas CASE

Aceptabilidad: Grado en que los desarrolladores aceptan yusan el proceso

Fiabilidad: Capacidad de evitar o detectar errores antes de que

sean defectos Robustez: Continuidad del proceso a pesar de los problemas

Mantenible: Capacidad de evolucin para adaptarse

Rapidez: Velocidad en que el proceso puede proporcionar unsistema a partir de una especificacin


20/72

Modelos Genricos de Desarrollo de

Software Modelo de Cascada

Prototipado Desarrollo Evolutivo

En espiral Desarrollo basado en componentes

Mtodos Formales


21/72

Modelo en cascada (waterfall)

Modelo de proceso clsico (desde los 70)

Basado en la mentalidad de lnea deensamblaje (cartesiano)

Es sencillo y fcil de entender El proyecto pasa a travs de una serie de fases

Al final de cada fase se revisan las tareas deAl final de cada fase se revisan las tareas detrabajo y productostrabajo y productos Para poder pasar a la siguiente fase se tiene que haber

conseguido todos los objetivos de la fase anterior No hay apenas comunicaciNo hay apenas comunicacin entre las fasesn entre las fases


22/72


Definicin de

Requisitos

Diseo del Software

y del Sistema

Implementacin y

Pruebas Unitarias

Integracin y Prueba

del Sistema

Operacin y

Mantenimiento


23/72


Fases:

ConceptualizaciConceptualizaci

nn

: Se determina la arquitectura de la: Se determina la arquitectura de la

solucisolucin (divisin (divisin del sistema en subsistemas)n del sistema en subsistemas) AnAnlisis de requisitoslisis de requisitos: B: Bsicamente se definen lossicamente se definen los

requisitos funcionales y de rendimientorequisitos funcionales y de rendimiento

DiseDiseoo: Representaci: Representacin de la aplicacin de la aplicacin que sirve de gun que sirve de gua aa ala implementacila implementacinn

ImplementaciImplementacinn: Transforma el dise: Transforma el diseo en co en cdigodigo

PruebaPrueba: Validaci: Validacin e integracin e integracin de software y sistemasn de software y sistemas InstalaciInstalacin y comprobacin y comprobacinn: Se instala el software al: Se instala el software al

cliente, el cual comprueba la correccicliente, el cual comprueba la correccin de la aplicacin de la aplicacinn

Se supone que slo se baja en la cascada... perotambin se puede subir (aunque difcilmente)


24/72


Posibles ventajas:

Sencillo: Sirve cuando el personal estSencillo: Sirve cuando el personal est poco cualificadopoco cualificado Aplicable cuando el problema es estable y cuando seAplicable cuando el problema es estable y cuando se

trabaja con ttrabaja con tcnicas conocidascnicas conocidas

Crticas: No se ve un producto hasta muy tarde en el procesoNo se ve un producto hasta muy tarde en el proceso

Un error grave detectado en las ltimas fases puede ser letal

EspecificaciEspecificacin de requisitos establen de requisitos estable Impone una estructura de gestiImpone una estructura de gestin de proyectosn de proyectos

Fases muy rgidas

Las revisiones de proyectos de gran complejidad son muyLas revisiones de proyectos de gran complejidad son muydifdifcilesciles


25/72

Prototipado

Se usa un prototipo para dar al usuario una ideaconcreta de lo que va a hacer el sistema

Se aplica cada vez ms cuando la rapidez dedesarrollo es esencial

Prototipado evolutivo: el prototipo inicial se refinaprogresivamente hasta convertirse en versin final Prototipado desechable: de cada prototipo se extraen

ideas buenas que se usan para hacer el siguiente, perocada prototipo se tira entero


26/72

Prototipado

Escucharal cliente

El clienteevala elprototipo

Construir/

revisarprototipo


27/72

Prototipado

Comienza con la recoleccin de requisitos

Cliente y desarrolladores definen los objetivos globales delCliente y desarrolladores definen los objetivos globales delsoftware.software.

AdemAdems, identifican los requisitos conocidos y aquellos ques, identifican los requisitos conocidos y aquellos que

deben ser mdeben ser ms definidos.s definidos. Aparece un diseo rpido centrado en los aspectos

visibles para el cliente (e.g. informacin de E/S)

El diseEl diseo ro rpido lleva a la construccipido lleva a la construccin de un prototipon de un prototipo El prototipo lo evala el cliente y lo utiliza para

refinar los requisitos

El proceso se itera... desechando el prototipo?


28/72

Prototipado

Ventajas

Permite identificar los requisitos incrementalmentePermite identificar los requisitos incrementalmente Permite probar alternativas a los desarrolladoresPermite probar alternativas a los desarrolladores

Tiene una alta visibilidadTiene una alta visibilidad tanto clientes comotanto clientes como

desarrolladores ven resultados rdesarrolladores ven resultados rpidamentepidamente Inconvenientes

El cliente no entiende por quEl cliente no entiende por qu hay que desechar el prototipohay que desechar el prototipo

Si simplemente ha pedido unos ajustes...(?)

Riesgo de software de baja calidadRiesgo de software de baja calidad Compromisos de implementacin para que el prototipo funcione

rpidamente y que al final son parte integral del sistema Utilizar un SO o lenguaje de programacin inadecuado pero conocido


29/72

Modelos evolutivos

Caractersticas:

Gestionan bien la naturaleza evolutiva del softwareGestionan bien la naturaleza evolutiva del software Son iterativos: construyen versiones de softwareSon iterativos: construyen versiones de software

cada vez mcada vez ms completass completas

Se adaptan bien: Los cambios de requisitos del productoLos cambios de requisitos del producto

Fechas de entrega estrictas poco realistasFechas de entrega estrictas poco realistas Especificaciones parciales del productoEspecificaciones parciales del producto


30/72

Modelos evolutivos

Descripcindel sistema

VersinInicial

VersionesIntermedias

VersionesIntermedias

VersinFinal

Especificacin

Desarrollo

Validacin

ActividadesConcurrentes


31/72

Modelos evolutivos. Incremental

Fusiona el modelo lineal secuencial con el de

construccin de prototipos

A D C P 1er incremento

A D C P 2 incremento

..................... N-simo incremento


32/72


Cada secuencia lineal secuencial produce un

incremento del software Incremento: producto operacional de una parte del sistemaIncremento: producto operacional de una parte del sistema

El primer incremento suele ser el ncleo

Requisitos bRequisitos bsicossicos Muchas funciones suplementarias se dejan para despuMuchas funciones suplementarias se dejan para despuss

Se evala (p.ej., por el cliente) el producto entregado Como resultado se desarrolla un plan para el siguienteComo resultado se desarrolla un plan para el siguiente

Se itera

Hasta elaborar el producto completoHasta elaborar el producto completo


33/72


Ventajas

Es interactivoEs interactivo Con cada incremento se entrega al cliente un producto operacionalal cliente, que puede evaluarlo

PersonalPersonal Permite variar el personal asignado a cada iteracin

GestiGestin riesgos tn riesgos tcnicoscnicos Por ejemplo, disponibilidad de hardware especfico

Inconvenientes La primera iteraciLa primera iteracin puede plantear los mismos problemasn puede plantear los mismos problemas

que en un modelo lineal secuencialque en un modelo lineal secuencial


34/72

Modelo de Proceso en Espiral

Original: Boehm, 1988

IEEE Std. 1490-1998 Tratar primero las reas de mayor riesgo

Mltiples iteraciones sobre varias regiones de tareas Vuelta a la espiral: cicloVuelta a la espiral: ciclo

NNmero de iteraciones predeterminadas o calculadasmero de iteraciones predeterminadas o calculadasdindinmicamentemicamente

Se pueden variar las actividades de desarrollo: familiade modelos de procesos


35/72

Modelo de Proceso de Espiral

Determine objetivosalternativas yrestricciones

Evale alternativas,identifique y resuelva

riesgosAnlisis de

Riesgos

Anlisis deRiesgos

Anlisis deRiesgos

Anlisisde

Riesgos

Planea la

siguiente faseDesarrolla y verifica

el siguiente niveldel producto

PrototipoOperacionalPrototipo

3Prototipo2Proto

tipo1

Plan de requerimientosPlan del ciclo de vida

REVISIN

Plan deDesarrollo

Plan de Integraciny Prueba

Concepto deOperacin

Simulaciones, modelos y benchmarks

Requerimientos

de

SWValidacin deRequerimientos

DiseoV &V

Servicio

Prueba de

Aceptacin

Prueba deIntegracin

Prueba deUnidades

Codificacin

Diseo

Detallado

Diseo

delProducto


36/72

Modelo de Proceso en Espiral

El modelo en espiral es bastante adecuado para

la gestin de riesgos Se puede aadir una actividad de gestin de

riesgos De hecho, el modelo original de Boehm:

Fijar objetivosFijar objetivos

Gestionar y reducir riesgosGestionar y reducir riesgos

Desarrollo y validaciDesarrollo y validacinn

Planificar siguiente cicloPlanificar siguiente ciclo


37/72

Modelos Evolutivos. Espiral Boehm

Fijar objetivos

Definir objetivos del cicloDefinir objetivos del ciclo Identificar restricciones del proceso y productoIdentificar restricciones del proceso y producto Desarrollar plan de gestiDesarrollar plan de gestinn

Identificar riesgosIdentificar riesgos Identificar estrategias alternativasIdentificar estrategias alternativas

Gestionar y reducir el riesgo RSGR para cada riesgo identificadoRSGR para cada riesgo identificado


38/72

Modelos Evolutivos. Espiral Boehm

Desarrollo y validacin

Elegir modelo de desarrolloElegir modelo de desarrollo Algunos autores lo denominan metamodeloAlgunos autores lo denominan metamodelo Yo prefiero llamarlo modeloYo prefiero llamarlo modelo paramparamtricotrico

Planificacin RevisiRevisin del proyecton del proyecto

DecisiDecisin de una nueva vueltan de una nueva vuelta


39/72

Modelos de Proceso en Espiral

Ventajas

Enfoque realistaEnfoque realista GestiGestin expln explcita de riesgoscita de riesgos

Centra su atenciCentra su atenci

n en la reutilizacin en la reutilizaci

n den de

componentes y eliminacicomponentes y eliminacin de errores enn de errores eninformaciinformacin descubierta en fases inicialesn descubierta en fases iniciales

Los objetivos de calidad son el primer objetivoLos objetivos de calidad son el primer objetivo Integra desarrollo con mantenimientoIntegra desarrollo con mantenimiento


40/72

Modelos de Proceso en Espiral

Inconvenientes

Convencer cliente enfoque controlableConvencer cliente enfoque controlable Requiere de experiencia en la identificaciRequiere de experiencia en la identificacin den de

riesgosriesgos

Requiere refinamiento para uso generalizadoRequiere refinamiento para uso generalizado


41/72

Desarrollo Basado en Componentes

Desarrollo de sistemas en poco tiempo

Adaptacin a alta velocidad de la cascada Equipos trabajando en paraleloEquipos trabajando en paralelo

Aplicando tecnologAplicando tecnologa de componentesa de componentes

A

D

C

P

Equipo 1

A

D

C

P

Equipo 2

A

D

C

P

Equipo n

............

60-90 das


42/72


Ventajas

RapidezRapidez VVlido para aplicacioneslido para aplicaciones modularizablesmodularizables

Inconvenientes

Exige conocer bien los requisitos y delimitar elExige conocer bien los requisitos y delimitar el mbito delmbito delproyectoproyecto

NNmero de personasmero de personas

Clientes y desarrolladores comprometidosClientes y desarrolladores comprometidos GestiGestin riesgos tn riesgos tcnicos altoscnicos altos

Uso de nueva tecnologa

Alto grado de interoperabilidad con sistemas existentes


43/72

Identificar

componentescandidatos

Buscar

componentesen biblioteca

Extraer

componentesdisponibles

Construir

componentesque falten

Aadir

componentesa biblioteca

Construir

iteracin Ndel sistema



44/72

Desarrollo con mtodos formales

Se basa en la transformacin de una

especificacin formal a lo largo de variasrepresentaciones hasta llegar a un programaejecutable

Las transformaciones preservan la correccin PermitenPermiten comprobarcomprobar ffcilmentecilmente queque elel programaprograma eses

conformeconforme a laa la especificaciespecificacinn


45/72

Desarrollo con mtodos formales

Requirements

definition

Formal

specification

Formal

transformation

Integration andsystem testing


46/72

Transformaciones formales

R2Formalspecification R3 Executableprogram

P2 P3P4

T1 T2 T3 T4

Proofs of transformation correctness

Formal transformations

R1

P1


47/72

Desarrollo formal de sistemas

Problemas

HaceHace faltafalta unauna formaciformacinn especializadaespecializada parapara aplicaraplicar lalattcnicacnica

MuchosMuchos aspectosaspectos de losde los sistemassistemas realesreales sonson difdifcilesciles dede

especificarespecificar

formalmenteformalmente

Interfaz de usuario

Requisitos no funcionales

Aplicabilidad SistemasSistemas crcrticosticos en losen los queque lala seguridadseguridad yy fiabilidadfiabilidad debedebepoderpoder asegurarseasegurarse antes deantes de ponerponer elel sistemasistema enen operacioperacinn


48/72

Visibilidad de Procesos

Los sistemas de software son intangibles por lo que

los administradores necesitan documentacin paraidentificar el progreso en el desarrollo

Esto puede causar problemas

El tiempo planeado para entregar resultados puede noEl tiempo planeado para entregar resultados puede nocoincidir con el necesario para completar una actividadcoincidir con el necesario para completar una actividad

La necesidad de producir documentos restringe la iteraciLa necesidad de producir documentos restringe la iteracinn

entre procesosentre procesos Tiempo para revisar y aprobar documentos significativoTiempo para revisar y aprobar documentos significativo

El modelo de cascada es an el modelo basado enresultados mas utilizado


49/72

Visibilidad de Procesos

Modelo de Proceso Visibilidad del Proceso

Modelo de Cascada Buena visibilidad, cada actividad

produce un documento oresultado

Desarrollo Evolutivo Visibilidad pobre, muy caro alproducir documentos en cadaiteracin

Modelos Formales Buena visibilidad, en cada fasedeben producirse documentos

Desarrollo orientado a lareutilizacin

Visibilidad moderada. Importantecontar con documentacin de

componentes reutilizables

Modelo de Espiral Buena visibilidad, cada segmentoy cada anillo del espiral debeproducir un documento


50/72

Qu modelo utilizar?

Para sistemas bien conocidos se puede utilizar el

Modelo de Cascada. La fase de anlisis de riesgos esrelativamente fcil

Con requisitos estables y sistemas de seguridad

crticos, se recomienda utilizar modelos formales Con especificaciones incompletas, el modelo de

prototipado ayuda a identificarlos y va produciendoun sistema funcional

Pueden utilizarse modelos hbridos en distintas partes

del desarrollo


51/72

Ejemplos

Dos modelos de proceso concretos:

Proceso Unificado deProceso Unificado de RationalRational (pesado)(pesado) ExtremeExtreme ProgrammingProgramming ((gil)gil)


52/72

Proceso Unificado

Los autores de UML

BoochBooch: m: mtodotodo BoochBooch RumbaughRumbaugh: OMT: OMT

Jacobson: procesoJacobson: proceso ObjectoryObjectory

Tambin conocido como RUP: RationalUnified Process


53/72

Proceso Unificado

Es un proceso de desarrollo de software Dirigido por casos de usoDirigido por casos de uso

Centrado en la arquitecturaCentrado en la arquitectura Iterativo e incrementalIterativo e incremental

Utiliza UML para definir los modelos del sistema software

El sistema software en construccin est formado por componentescomponentes softwaresoftware

interconectados a travinterconectados a travs des de interfacesinterfaces

Proceso dedesarrollo de

software

Requisitosde usuario

Sistemasoftware

Los requisitos cambiany el sistema software evoluciona


54/72

Proceso Unificado

Elaboration Construction TransitionInception

Phases

Requirements Capture

Analysis & Design

Implementation

Test

Management

EnvironmentDeployment

ProcessComponents

SupportingComponents

Iterations

preliminary

iteration(s)

iter.

#1

iter.

#2

iter.

#n

iter.

#n+1

iter.

#n+2

iter.

#m

iter.

#m+1

Organizationalongcontent

Organization alongtime


55/72

Extreme Programming (XP)

Modelo de proceso de Kent Beck

Un modo ligero, eficiente, de bajo riesgo, flexible,Un modo ligero, eficiente, de bajo riesgo, flexible,predecible, cientpredecible, cientfico y divertido de producir softwarefico y divertido de producir software

Caractersticas Alta visibilidad debido a ciclos muy cortosAlta visibilidad debido a ciclos muy cortos

PlanificaciPlanificacin incrementaln incremental

Se adapta a cambios de negocioSe adapta a cambios de negocio


56/72


Basado en pruebas automatizadas escritas por

desarrolladores y clientes (test-driven) Alta comunicacin

Diseo evolutivo

Colaboracin entre programadores

Busca equilibrio entre las necesidades a cortoplazo de los programadores y las de largoplazo del proyecto


57/72


La estructura del proceso, si la hay, es un poco

atpica

Actividades en XP

Prueba Evaluacin DiseoCodificacin


58/72


Las cuatro actividades estn soportadas por doce prcticas: El juego de planificaciEl juego de planificacinn

PequePequeas entregasas entregas MetMetforafora

DiseDiseo simpleo simple

PruebaPrueba RefactoringRefactoring

ProgramaciProgramacin en parejan en pareja

Propiedad colectivaPropiedad colectiva IntegraciIntegracin continuan continua

Semana de cuarenta horasSemana de cuarenta horas

Cliente en el lugar de desarrolloCliente en el lugar de desarrollo

CodificaciCodificacin estn estndarndar


59/72


Ventajas:

Bueno para especificaciones cambiantesBueno para especificaciones cambiantes FundamentaciFundamentacin prn prcticactica

Inconvenientes: Poco probadoPoco probado Poco compatible con especificaciones/disePoco compatible con especificaciones/diseosos

totalestotales SSlo funciona con equipos pequelo funciona con equipos pequeos (hasta diezos (hasta diez

personas)personas)

E P i (XP)


60/72


Diferencias fundamentales (hay ms que ya se

vern) No hay requisitos explNo hay requisitos explcitos sino que el clientecitos sino que el clienteparticipa en el desarrolloparticipa en el desarrollo

Se empieza por automatizar las pruebasSe empieza por automatizar las pruebas Se desarrolla siempre la versiSe desarrolla siempre la versin mn ms simple posibles simple posible

que resuelva el problemaque resuelva el problema

Se ejecutan todas las pruebas todos los dSe ejecutan todas las pruebas todos los dasas Se cambia el diseSe cambia el diseo (aunque sea radicalmente)o (aunque sea radicalmente)

siempre que haga faltasiempre que haga falta


61/72

Calidad del proceso de software

Cmo medir la calidad del

proceso de software de unaempresa ?


62/72

La empresa ideal

El Dpto. de la Defensa de los US fund el SoftwareEngineering Institute (SEI) asociado con laUniversidad de Carnegie Mellon (CMU).

Desarrollan el Software Capability Maturity Model

(SW CMM) a mediados de 1980s, refinado en losinicios de l990s.

Este modelo define una serie de reas clave de

proceso (ACP) UnUn rea clave de proceso es, brea clave de proceso es, bsicamente, una actividad desicamente, una actividad de

ISIS

S f C bili M i M d l


63/72

Software Capability Maturity Model

Level 3Defined

Level 2Repeatable

Level 1

Initial

Level 4Managed

Level 5Optimizing

l d l


64/72

reas clave del proceso

P r o c e s s c h a n g e m a n a g em e n tT e c h n o l o g y c h a n g e m a n a g em e n tD e f e c t p r e v e n t io n

S o f tw a re q u a l it y m a n a g em e n tQ u a nt it a t iv e p r o c e s s m a n a g e m e n t

P e e r r e v ie w sI n t e r g ro u p c o o r d in at io nS o f tw a r e p r o d u c t e n g i n e e r i n g

I n t e g r a t e d s o f tw ar e m a n a g e m e n tT r a i n i n g p r o g r a m m eO r g a n i z a ti o n p r oc e s s d e f in it io nO r g a n i z a ti o n p r oc e s s f o c u s

S o f tw a r e c o n f i g u ra t io n m a n a g e m e n tS o f tw a r e q u a l it y a s su r a n c eS o f tw a r e s u b c o n t r a c t m a n a g em e n tS o f tw a r e p ro je c t tr a c k i n g a n d o v e r s ig h tS o f tw a r e p ro je c t p l a n n i n gR e q u i r e m e n t s m a n a g e m e n t

I n it i a l

R e p e a t a b l e

D e f i n e d

M a n a g ed

O p t i m i zi n g

Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31.


65/72

CMM

Los niveles son acumulativos

Nivel 1: Inicial El proceso de software se caracteriza segEl proceso de software se caracteriza segn el cason el caso

Se definen poco procesosSe definen poco procesos ElEl xito depende del esfuerzo individualxito depende del esfuerzo individual


66/72

CMM

Nivel 2: Repetible

Se incluye seguimiento del coste, la planificaciSe incluye seguimiento del coste, la planificacin y lan y lafuncionalidadfuncionalidad

Se repiten tSe repiten tcnicas de proyectos anteriores con buenoscnicas de proyectos anteriores con buenosresultadosresultados

Las ACP son:Las ACP son: Planificacin del proyecto de software

Seguimiento y supervisin del proyecto de software

Gestin de requisitos

Gestin de la configuracin software (GCS)

Garanta de calidad del software (SQA)

Gestin de la subcontratacin


67/72

CMM

Nivel 3: Definido

Nivel 2Nivel 2

Las actividades se documentan, estandarizan e integran enLas actividades se documentan, estandarizan e integran enun proceso a nivel organizaciun proceso a nivel organizacinn

Existe un proceso documentadoExiste un proceso documentado Las ACP son:Las ACP son: Definicin y enfoque del proceso de la organizacin

Programa de formacin

Revisiones peridicas

Coordinacin entre grupos

Ingeniera de productos software

Gestin de integracin del software


68/72

CMM

Nivel 4: Gestionado

Nivel 3Nivel 3 Se recopilan medidas del proceso del software y deSe recopilan medidas del proceso del software y de

la calidad del productola calidad del producto

Estas medidas sirven para gestionar el procesoEstas medidas sirven para gestionar el proceso

Las ACP son:Las ACP son:

Gestin de la calidad del software Gestin cuantitativa del software


69/72

CMM

Nivel 5: Optimizacin

Nivel 4Nivel 4 En base a la experiencia y mEn base a la experiencia y mtricas se optimiza eltricas se optimiza el

procesoproceso

Las ACP son:Las ACP son: Gestin de cambios del proceso

Gestin de cambios de tecnologa Prevencin de defectos


70/72

CMM

Un nivel razonable es el definido (nivel 3)

Un nivel deseable es optimizacin (nivel 5) Con independencia del CMM, ACPs mnimas:

PlanificaciPlanificacin del proyecton del proyecto

Seguimiento y supervisiSeguimiento y supervisin del proyecton del proyecto GestiGestin de requisitosn de requisitos

GCSGCS

SQASQA

DefiniciDefinicin del proceson del proceso

Revisiones periRevisiones peridicasdicas CoordinaciCoordinacin entre gruposn entre grupos


71/72

Datos Agosto 2000

Inicial 34,9%

Repetible 38,2% Definido 18,5%

Gestionado 5,5% Optimizado 2,9%

Resultados de 901 empresas desde 1996.


72/72

Referencias

Modelos de procesoModelos de proceso Pressman 17-46, Sommerville 42-67

Proceso UnificadoProceso Unificado Jacobson, Krutchen

SW CMMSW CMM Pressman Cap. 2, Sommerville Cap. 25 http://www.sei.cmu.edu/cmm/obtain.cmm.html

MaterialMaterial

Pablo Gervs Juan Pavn y Jorge Gmez

Natalia Juristo

Documents

Proceso de software y ciclo de vida