Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Proceso de desarrollo de software

Introduccin
Un sistema informtico est compuesto por hardware y software. n cuanto al hardware! su produccin se reali"a sistemticamente y la #ase de conocimiento para el desarrollo de dicha actividad est claramente definida. $a fia#ilidad del hardware es! en principio! e%uipara#le a la de cual%uier otra m%uina construida por el hom#re. Sin em#ar&o! respecto del software! su construccin y resultados han sido histricamente cuestionados de#ido a los pro#lemas asociados! entre ellos podemos destacar los si&uientes '()*

$os sistemas no responden a las e+pectativas de los usuarios. $os pro&ramas ,fallan- con cierta frecuencia. $os costes del software son dif.ciles de prever y normalmente superan las estimaciones. $a modificacin del software es una tarea dif.cil y costosa. l software se suele presentar fuera del pla"o esta#lecido y con menos prestaciones de las consideradas inicialmente. /ormalmente! es dif.cil cam#iar de entorno hardware usando el mismo software. l aprovechamiento ptimo de los recursos 0personas! tiempo! dinero! herramientas! etc.1 no suele cumplirse.

Se&2n el Centro +perimental de In&enier.a de Software 0C IS1 (! el estudio de mercado The Chaos Report reali"ado por Standish 3roup Internactional 4 en (556! concluy %ue slo un (67 de los proyectos de software son e+itosos 0terminan dentro de pla"os y costos y cumplen los re%uerimientos acordados1. 8tro 9:7 so#repasa costos y pla"os y cumple parcialmente los re%uerimientos. l resto ni si%uiera lle&a al trmino. ;l&unas deficiencias comunes en el desarrollo de software son*

scasa o tard.a validacin con el cliente. Inadecuada &estin de los re%uisitos. /o e+iste medicin del proceso ni re&istro de datos histricos. stimaciones imprevistas de pla"os y costos. +cesiva e irracional presin en los pla"os. scaso o deficiente control en el pro&reso del proceso de desarrollo. /o se hace &estin de ries&os formalmente. /o se reali"a un proceso formal de prue#as. /o se reali"an revisiones tcnicas formales e inspecciones de cdi&o.

l primer reconocimiento p2#lico de la e+istencia de pro#lemas en la produccin de software tuvo lu&ar en la conferencia or&ani"ada en (56< por la Comisin de Ciencias de la 8=;/ en 3armisch 0;lemania1! dicha situacin pro#lemtica se denomin crisis del software. n esta conferencia! as. como en la si&uiente reali"ada en >oma en (565! se estipul el inters hacia los aspectos tcnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretend.a acordar las #ases para una in&enier.a de construccin de software. Se&2n ?rit" @auer '4) lo %ue se necesita#a era , establecer y usar principios de ingeniera orientados a obtener software de manera econmica, que sea fiable y funcione eficientemente sobre mquinas reales-. sta definicin marca#a posi#les cuestiones tales como* ACules son los principios ro#ustos de la in&enier.a aplica#les al desarrollo de software de computadoraB ACmo construimos el software econmicamente para %ue sea fia#leB ACu se necesita para crear pro&ramas de computadora %ue funcionen eficientemente no en una m%uina sino en diferentes m%uinas realesB. Sin em#ar&o! dicho planteamiento adems de#.a incluir otros aspectos! tales como* meDora de la calidad del software! satisfaccin del cliente! mediciones y mtricas! etc.

( 4

http*EEwww.ceis.clE3estacionE3estacion.htm 09.:.4FF:1 http*EEstandish&roup.comE 09.:.4FF:1

(

G P.$etelier

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

l ,IEEE tandard !lossary of oftware Engineering Terminology - 0Stad. 6(F.(4H(55F1 ha desarrollado una definicin ms completa para in&enier.a del software '()* ,0(1 $a aplicacin de un enfo%ue sistemtico! disciplinado y cuantifica#le para el desarrollo! operacin y mantenimiento del softwareI es decir! la aplicacin de in&enier.a al software. 041 l estudio de enfo%ues en 0(1-. Pressman '() caracteri"a la In&enier.a de Software como ,una tecnolo&.a multicapa-! ilustrada en la ?i&ura (.

"igura #$ Capas de la Ingeniera de oftware% Dichas capas se descri#en a continuacin*

Cual%uier disciplina de in&enier.a 0incluida la in&enier.a del software1 de#e descansar so#re un esfuer"o de or&ani"acin de calidad. $a &estin total de la calidad y las filosof.as similares fomentan una cultura continua de meDoras de procesos %ue conduce al desarrollo de enfo%ues cada ve" ms ro#ustos para la in&enier.a del software. l fundamento de la in&enier.a de software es la capa proceso. l proceso define un marco de tra#aDo para un conDunto de reas clave! las cuales forman la #ase del control de &estin de proyectos de software y esta#lecen el conte+to en el cual* se aplican los mtodos tcnicos! se producen resultados de tra#aDo! se esta#lecen hitos! se ase&ura la calidad y el cam#io se &estiona adecuadamente. $os mtodos de la in&enier.a de software indican cmo construir tcnicamente el software. $os mtodos a#arcan una &ran &ama de tareas %ue incluyen anlisis de re%uisitos! diseJo! construccin de pro&ramas! prue#as y mantenimiento. stos mtodos dependen de un conDunto de principios #sicos %ue &o#iernan cada rea de la tecnolo&.a e incluyen actividades de modelado y otras tcnicas descriptivas. $as herramientas de la in&enier.a del software proporcionan un soporte automtico o semiHautomtico para el proceso y los mtodos! a estas herramientas se les llama herramientas C;S 0C omputer&'ided oftware Engineering1.

Dado lo anterior! el o#Detivo de la in&enier.a de software es lo&rar productos de software de calidad 0tanto en su forma final como durante su ela#oracin1! mediante un proceso apoyado por mtodos y herramientas. ; continuacin nos enfocaremos en el proceso necesario para ela#orar un producto de software.

El proceso de desarrollo del software

Un proceso de desarrollo de software tiene como propsito la produccin efica" y eficiente de un producto software %ue re2na los re%uisitos del cliente. Dicho proceso! en trminos &lo#ales se muestra en la ?i&ura 4 ':). ste proceso es intensamente intelectual! afectado por la creatividad y Duicio de las personas involucradas 'K). ;un%ue un proyecto de desarrollo de software es e%uipara#le en muchos aspectos a cual%uier otro proyecto de in&enier.a! en el desarrollo de software hay una serie de desaf.os adicionales! relativos esencialmente a la naturale"a del producto o#tenido. ; continuacin se e+plican al&unas particularidades asociadas al desarrollo de software y %ue influyen en su proceso de construccin. Un producto software en s. es compleDo! es prcticamente invia#le conse&uir un (FF7 de confia#ilidad de un pro&rama por pe%ueJo %ue sea. +iste una inmensa com#inacin de factores %ue impiden una verificacin e+haustiva de las todas posi#les situaciones de eDecucin %ue se puedan presentar 0entradas! valores de varia#les! datos almacenados! software del sistema! otras aplicaciones %ue intervienen! el hardware so#re el cual se eDecuta! etc.1. Un producto software es intan&i#le y por lo &eneral muy a#stracto! esto dificulta la definicin del producto y sus re%uisitos! so#re todo cuando no se tiene precedentes en productos software similares. sto hace %ue los re%uisitos sean dif.ciles de consolidar tempranamente. ;s.! los cam#ios en los re%uisitos son
G P.$etelier 4

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

inevita#les! no slo despus de entre&ado en producto sino tam#in durante el proceso de desarrollo. ;dems! de las dos anteriores! siempre puede seJalarse la inmadure" de la in&enier.a del software como disciplina! Dustificada por su corta vida comparada con otras disciplinas de la in&enier.a. Sin em#ar&o! esto no es ms %ue un in2til consuelo.

Requisitos nuevos o modificados

Proceso de Desarrollo de Software

Sistema nuevo o modificado

"igura ($ proceso de desarrollo de software% l proceso de desarrollo de software no es 2nico. /o e+iste un proceso de software universal %ue sea efectivo para todos los conte+tos de proyectos de desarrollo. De#ido a esta diversidad! es dif.cil automati"ar todo un proceso de desarrollo de software. ; pesar de la variedad de propuestas de proceso de software! e+iste un conDunto de actividades fundamentales %ue se encuentran presentes en todos ellos 'K)* (. Especificacin de software* Se de#e definir la funcionalidad y restricciones operacionales %ue de#e cumplir el software. 4. Diseo e Implementacin * Se diseJa y construye el software de acuerdo a la especificacin. :. Validacin * l software de#e validarse! para ase&urar %ue cumpla con lo %ue %uiere el cliente. K. Evolucin * l software de#e evolucionar! para adaptarse a las necesidades del cliente. ;dems de estas actividades fundamentales! Pressman '() menciona un conDunto de ,actividades protectoras-! %ue se aplican a lo lar&o de todo el proceso del software. llas se seJalan a continuacin*

Se&uimiento y control de proyecto de software. >evisiones tcnicas formales. 3arant.a de calidad del software. 3estin de confi&uracin del software. Preparacin y produccin de documentos. 3estin de reutili"acin. Lediciones. 3estin de ries&os.

Pressman '() caracteri"a un proceso de desarrollo de software como se muestra en la ?i&ura :. $os elementos involucrados se descri#en a continuacin*

Un marco comn del proceso! definiendo un pe%ueJo n2mero de actividades del marco de tra#aDo %ue son aplica#les a todos los proyectos de software! con independencia del tamaJo o compleDidad. Un conjunto de tareas! cada uno es una coleccin de tareas de in&enier.a del software! hitos de proyectos! entre&as y productos de tra#aDo del software! y puntos de &arant.a de calidad! %ue permiten %ue las actividades del marco de tra#aDo se adapten a las caracter.sticas del proyecto de software y los re%uisitos del e%uipo del proyecto. Las actividades de proteccin ! tales como &arant.a de calidad del software! &estin de confi&uracin del software y medicin! a#arcan el modelo del proceso. $as actividades de proteccin son independientes de cual%uier actividad del marco de tra#aDo y aparecen durante todo el proceso.

G P.$etelier

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

"igura )$ Elementos del proceso del software 8tra perspectiva utili"ada para determinar los elementos del proceso de desarrollo de software es esta#lecer las relaciones entre elementos %ue permitan responder uin de#e hacer u! !u"ndo y !mo de#e hacerlo '9).

"igura *$ Relacin entre elementos del proceso del software n la ?i&ura K se muestran los elementos de un proceso de desarrollo de software y sus relaciones. ;s. las interro&antes se responden de la si&uiente forma*

uin# $as Personas participantes en el proyecto de desarrollo desempeJando uno o ms >oles espec.ficos. u# Un ;rtefacto: es producido por un >ol en una de sus ;ctividades. $os ;rtefactos se especifican utili"ando /otaciones espec.ficas. $as Merramientas apoyan la ela#oracin de ;rtefactos soportando ciertas /otaciones. !mo $ !u"ndo# $as ;ctividades son una serie de pasos %ue lleva a ca#o un >ol durante el proceso de desarrollo. l avance del proyecto est controlado mediante hitos %ue esta#lecen un determinado estado de terminacin de ciertos ;rtefactos.

Un artefacto es una pie"a de informacin %ue 0(1 es producida! modificada o usada por el proceso! 041 define un rea de responsa#ilidad para un rol y 0:1 est suDeta a control de versiones. Un artefacto puede ser un modelo! un elemento de modelo o un documento. K

G P.$etelier

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

$a composicin y sincron.a de las actividades est #asada en un conDunto de Principios y Prcticas. $as Prcticas y Principios enfati"an ciertas actividades yEo la forma como de#en reali"arse! por eDemplo* desarrollar iterativamente! &estionar re%uisitos! desarrollo #asado en componentes! modelar visualmente! verificar continuamente la calidad! &estionar los cam#ios! etc.

%odelos de proceso software

Sommerville 'K) define modelo de proceso de software como ,Una representacin simplificada de un proceso de software! representada desde una perspectiva espec.fica. Por su naturale"a los modelos son simplificados! por lo tanto un modelo de procesos del software es una a#straccin de un proceso real.$os modelos &enricos no son descripciones definitivas de procesos de softwareI sin em#ar&o! son a#stracciones 2tiles %ue pueden ser utili"adas para e+plicar diferentes enfo%ues del desarrollo de software. Lodelos %ue se van a discutir a continuacin*

Codificar y corre&ir Lodelo en cascada Desarrollo evolutivo Desarrollo formal de sistemas Desarrollo #asado en reutili"acin Desarrollo incremental Desarrollo en espiral

!odificar $ corre&ir '!ode(and()i*+

ste es el modelo #sico utili"ado en los inicios del desarrollo de software. Contiene dos pasos*

scri#ir cdi&o. Corre&ir pro#lemas en el cdi&o.

Se trata de primero implementar al&o de cdi&o y lue&o pensar acerca de re%uisitos! diseJo! validacin! y mantenimiento. ste modelo tiene tres pro#lemas principales 'N)*

Despus de un n2mero de correcciones! el cdi&o puede tener una muy mala estructura! hace %ue los arre&los sean muy costosos. ?recuentemente! a2n el software #ien diseJado! no se aDusta a las necesidades del usuario! por lo %ue es recha"ado o su reconstruccin es muy cara. l cdi&o es dif.cil de reparar por su po#re preparacin para pro#ar y modificar.

%odelo en cascada
l primer modelo de desarrollo de software %ue se pu#lic se deriv de otros procesos de in&enier.a '<). Oste toma las actividades fundamentales del proceso de especificacin! desarrollo! validacin y evolucin y las representa como fases separadas del proceso. l modelo en cascada consta de las si&uientes fases* (. Definicin de los re%uisitos* $os servicios! restricciones y o#Detivos son esta#lecidos con los usuarios del sistema. Se #usca hacer esta definicin en detalle. 4. DiseJo de software* Se particiona el sistema en sistemas de software o hardware. Se esta#lece la ar%uitectura total del sistema. Se identifican y descri#en las a#stracciones y relaciones de los componentes del sistema. :. Implementacin y prue#as unitarias* Construccin de los mdulos y unidades de software. Se reali"an prue#as de cada unidad.

G P.$etelier

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

K. Inte&racin y prue#as del sistema* Se inte&ran todas las unidades. Se prue#an en conDunto. Se entre&a el conDunto pro#ado al cliente. 9. 8peracin y mantenimiento* 3eneralmente es la fase ms lar&a. l sistema es puesto en marcha y se reali"a la correccin de errores descu#iertos. Se reali"an meDoras de implementacin. Se identifican nuevos re%uisitos. $a interaccin entre fases puede o#servarse en la ?i&ura 9. Cada fase tiene como resultado documentos %ue de#en ser apro#ados por el usuario. Una fase no comien"a hasta %ue termine la fase anterior y &eneralmente se incluye la correccin de los pro#lemas encontrados en fases previas.

"igura +$ ,odelo de desarrollo en cascada% n la prctica! este modelo no es lineal! e involucra varias iteraciones e interaccin entre las distintas fases de desarrollo. ;l&unos pro#lemas %ue se o#servan en el modelo de cascada son*

$as iteraciones son costosas e implican rehacer tra#aDo de#ido a la produccin y apro#acin de documentos. ;un%ue son pocas iteraciones! es normal con&elar parte del desarrollo y continuar con las si&uientes fases. $os pro#lemas se deDan para su posterior resolucin! lo %ue lleva a %ue estos sean i&norados o corre&idos de una forma poco ele&ante. +iste una alta pro#a#ilidad de %ue el software no cumpla con los re%uisitos del usuario por el lar&o tiempo de entre&a del producto. s infle+i#le a la hora de evolucionar para incorporar nuevos re%uisitos. cam#ios en los re%uisitos. s dif.cil responder a

ste modelo slo de#e usarse si se entienden a plenitud los re%uisitos. ;2n se utili"a como parte de proyectos &randes.

Desarrollo evolutivo
$a idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial! e+ponerla a los comentarios del usuario! refinarla en / versiones hasta %ue se desarrolle el sistema adecuado. n la ?i&ura 6 se o#serva cmo las actividades concurrentes* especificacin! desarrollo y validacin! se reali"an durante el desarrollo de las versiones hasta lle&ar al producto final. Una ventaDa de este modelo es %ue se o#tiene una rpida realimentacin del usuario! ya %ue las actividades de especificacin! desarrollo y prue#as se eDecutan en cada iteracin.

G P.$etelier

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

"igura -$ ,odelo de desarrollo e.oluti.o% +isten dos tipos de desarrollo evolutivo*

Desarrollo +ploratorio* l o#Detivo de este enfo%ue es e+plorar con el usuario los re%uisitos hasta lle&ar a un sistema final. l desarrollo comien"a con las partes %ue se tiene ms claras. l sistema evoluciona conforme se aJaden nuevas caracter.sticas propuestas por el usuario. nfo%ue utili"ando prototipos* l o#Detivo es entender los re%uisitos del usuario y tra#aDar para meDorar la calidad de los re%uisitos. ; diferencia del desarrollo e+ploratorio! se comien"a por definir los re%uisitos %ue no estn claros para el usuario y se utili"a un prototipo para e+perimentar con ellos. l prototipo ayuda a terminar de definir estos re%uisitos. $a especificacin puede desarrollarse de forma creciente. $os usuarios y desarrolladores lo&ran un meDor entendimiento del sistema. meDora de la calidad del software. sto se refleDa en una

ntre los puntos favora#les de este modelo estn*

s ms efectivo %ue el modelo de cascada! ya %ue cumple con las necesidades inmediatas del cliente. Proceso no Visi#le* $os administradores necesitan entre&as para medir el pro&reso. Si el sistema se necesita desarrollar rpido! no es efectivo producir documentos %ue refleDen cada versin del sistema. Sistemas po#remente estructurados* $os cam#ios continuos pueden ser perDudiciales para la estructura del software haciendo costoso el mantenimiento. Se re%uieren tcnicas y herramientas* Para el rpido desarrollo se necesitan herramientas %ue pueden ser incompati#les con otras o %ue poca &ente sa#e utili"ar.

Desde una perspectiva de in&enier.a y administracin se identifican los si&uientes pro#lemas*

ste modelo es efectivo en proyectos pe%ueJos 0menos de (FF.FFF l.neas de cdi&o1 o medianos 0hasta 9FF.FFF l.neas de cdi&o1 con poco tiempo para su desarrollo y sin &enerar documentacin para cada versin. Para proyectos lar&os es meDor com#inar lo meDor del modelo de cascada y evolutivo* se puede hacer un prototipo &lo#al del sistema y posteriormente reimplementarlo con un acercamiento ms estructurado. $os su#sistemas con re%uisitos #ien definidos y esta#les se pueden pro&ramar utili"ando cascada y la interfa" de usuario se puede especificar utili"ando un enfo%ue e+ploratorio.

G P.$etelier

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

Desarrollo formal de sistemas

ste modelo se #asa en transformaciones formales de los re%uisitos hasta lle&ar a un pro&rama eDecuta#le.

"igura /$ 0aradigma de programacin automtica% $a ?i&ura N 0o#tenida desde '4F)1 ilustra un paradi&ma ideal de pro&ramacin automtica. Se distin&uen dos fases &lo#ales* especificacin 0incluyendo validacin1 y transformacin. $as caracter.sticas principales de este paradi&ma son* la especificacin es formal y eDecuta#le constituye el primer prototipo del sistema1! la especificacin es validada mediante prototipacin. Posteriormente! a travs de transformaciones formales la especificacin se convierte en la implementacin del sistema! en el 2ltimo paso de transformacin se o#tiene una implementacin en un len&uaDe de pro&ramacin determinado. ! el mantenimiento se reali"a so#re la especificacin 0no so#re el cdi&o fuente1! la documentacin es &enerada automticamente y el mantenimiento es reali"ado por repeticin del proceso 0no mediante parches so#re la implementacin1. 8#servaciones so#re el desarrollo formal de sistemas*

Permite demostrar la correccin del sistema durante el proceso de transformacin. ;s.! las prue#as %ue verifican la correspondencia con la especificacin no son necesarias. s atractivo so#re todo para sistemas donde hay re%uisitos de se&uridad y confia#ilidad importantes. >e%uiere desarrolladores especiali"ados y e+perimentados en este proceso para llevarse a ca#o.

Desarrollo ,asado en reutili-acin

Como su nom#re lo indica! es un modelo fuertemente orientado a la reutili"acin. fases ilustradas en la ?i&ura 5. ; continuacin se descri#e cada fase* ste modelo consta de K

(. ;nlisis de componentes* Se determina %u componentes pueden ser utili"ados para el sistema en cuestin. Casi siempre hay %ue hacer aDustes para adecuarlos. 4. Lodificacin de re%uisitos* Se adaptan 0en lo posi#le1 los re%uisitos para concordar con los componentes de la etapa anterior. Si no se puede reali"ar modificaciones en los re%uisitos! hay %ue se&uir #uscando componentes ms adecuados 0fase (1. :. DiseJo del sistema con reutili"acin* Se diseJa o reutili"a el marco de tra#aDo para el sistema. Se de#e tener en cuenta los componentes locali"ados en la fase 4 para diseJar o determinar este marco. K. Desarrollo e inte&racin* l software %ue no puede comprarse! se desarrolla. Se inte&ran los componentes y su#sistemas. $a inte&racin es parte del desarrollo en lu&ar de una actividad separada.

G P.$etelier

<

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

$as ventaDas de este modelo son*

Disminuye el costo y esfuer"o de desarrollo. >educe el tiempo de entre&a. Disminuye los ries&os durante el desarrollo.

"igura 1$ 2esarrollo basado en reutili3acin de componentes DesventaDas de este modelo*

$os ,compromisos- en los re%uisitos son inevita#les! por lo cual puede %ue el software no cumpla las e+pectativas del cliente. $as actuali"aciones de los componentes ad%uiridos no estn en manos de los desarrolladores del sistema.

Procesos iterativos
; continuacin se e+pondrn dos enfo%ues h.#ridos! especialmente diseJados para el soporte de las iteraciones*

Desarrollo Incremental. Desarrollo en spiral.

Desarrollo incremental
Lills '5) su&iri el enfo%ue incremental de desarrollo como una forma de reducir la repeticin del tra#aDo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los re%uisitos hasta ad%uirir e+periencia con el sistema 0ver ?i&ura (F1. s una com#inacin del Lodelo de Cascada y Lodelo volutivo. >educe el rehacer tra#aDo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener e+periencia en el sistema. Durante el desarrollo de cada incremento se puede utili"ar el modelo de cascada o evolutivo! dependiendo del conocimiento %ue se ten&a so#re los re%uisitos a implementar. Si se tiene un #uen conocimiento! se puede optar por cascada! si es dudoso! evolutivo.

"igura 4$ ,odelo de desarrollo iterati.o incremental%

G P.$etelier

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

ntre las ventaDas del modelo incremental se encuentran*

$os clientes no esperan hasta el fin del desarrollo para utili"ar el sistema. Pueden empe"ar a usarlo desde el primer incremento. $os clientes pueden aclarar los re%uisitos %ue no ten&an claros conforme ven las entre&as del sistema. Se disminuye el ries&o de fracaso de todo el proyecto! ya %ue se puede distri#uir en cada incremento. $as partes ms importantes del sistema son entre&adas primero! por lo cual se reali"an ms prue#as en estos mdulos y se disminuye el ries&o de fallos. Cada incremento de#e ser pe%ueJo para limitar el ries&o 0menos de 4F.FFF l.neas1. Cada incremento de#e aumentar la funcionalidad. s dif.cil esta#lecer las correspondencias de los re%uisitos contra los incrementos. s dif.cil detectar las unidades o servicios &enricos para todo el sistema.

;l&unas de las desventaDas identificadas para este modelo son*

Desarrollo en espiral
l modelo de desarrollo en espiral 0ver ?i&ura ((1 es actualmente uno de los ms conocidos y fue propuesto por @oehm 'N). l ciclo de desarrollo se representa como una espiral! en lu&ar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases* (. Definicin de o#Detivos* Se definen los o#Detivos. Se definen las restricciones del proceso y del producto. Se reali"a un diseJo detallado del plan administrativo. Se identifican los ries&os y se ela#oran estrate&ias alternativas dependiendo de estos. 4. valuacin y reduccin de ries&os* Se reali"a un anlisis detallado de cada ries&o identificado. Pueden desarrollarse prototipos para disminuir el ries&o de re%uisitos dudosos. Se llevan a ca#o los pasos para reducir los ries&os.

:. Desarrollo y validacin* Se esco&e el modelo de desarrollo despus de la evaluacin del ries&o. l modelo %ue se utili"ar 0cascada! sistemas formales! evolutivo! etc.1 depende del ries&o identificado para esa fase. K. Planificacin* Se determina si continuar con otro ciclo. Se planea la si&uiente fase del proyecto. ste modelo a diferencia de los otros toma en consideracin e+pl.citamente el ries&o! esta es una actividad importante en la administracin del proyecto. l ciclo de vida inicia con la definicin de los o#Detivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los ries&os al sopesar los o#Detivos contra las alternativas. Se eval2an los ries&os con actividades como anlisis detallado! simulacin! prototipos! etc. Se desarrolla un poco el sistema. Se planifica la si&uiente fase.

G P.$etelier

(F

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

"igura #5$ ,odelo de desarrollo en Espiral

.!u"l es el modelo de proceso m"s adecuado/

Cada proyecto de software re%uiere de una forma de particular de a#ordar el pro#lema. $as propuestas comerciales y acadmicas actuales promueven procesos iterativos! donde en cada iteracin puede utili"arse uno u otro modelo de proceso! considerando un conDunto de criterios 0Por eDemplo* &rado de definicin de re%uisitos! tamaJo del proyecto! ries&os identificados! entre otros1. n la =a#la ( se e+pone un cuadro comparativo de acuerdo con al&unos criterios #sicos para la seleccin de un modelo de proceso '(F)! la medida utili"ada indica el nivel de efectividad del modelo de proceso de acuerdo al criterio 0Por eDemplo* l modelo Cascada responde con un nivel de efectividad @aDo cuando los >e%uisitos y ar%uitectura no estn predefinidos 1*

G P.$etelier

((

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

%odelo de proceso

)unciona con re0uisitos $ ar0uitectura no predefinidos

Produce software altamente fia,le

1estin de ries&os

Permite correcciones so,re la marcha

Visin del pro&reso por el !liente $ el 2efe del pro$ecto

!odificar $ corre&ir !ascada Evolutivo e*ploratorio Evolutivo prototipado Desarrollo formal de sistemas Desarrollo orientado a reutili-acin Incremental Espiral

@aDo

@aDo

@aDo

;lto

Ledio

@aDo

;lto

@aDo

@aDo

@aDo

Ledio o ;lto

Ledio o ;lto

Ledio

Ledio o ;lto

Ledio o ;lto

;lto

Ledio

Ledio

;lto

;lto

@aDo

;lto

@aDo a Ledio

@aDo

@aDo

Ledio

@aDo a ;lto

@aDo a Ledio

;lto

;lto

@aDo ;lto

;lto ;lto

Ledio ;lto

@aDo Ledio

@aDo Ledio

Tabla #$ Comparacin entre modelos de proceso de software%

G P.$etelier

(4

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

%etodolo&3as para desarrollo de software

Un proceso de software detallado y completo suele denominarse ,Letodolo&.a-. $as metodolo&.as se #asan en una com#inacin de los modelos de proceso &enricos 0cascada! evolutivo! incremental! etc.1. ;dicionalmente una metodolo&.a de#er.a definir con precisin los artefactos! roles y actividades involucrados! Dunto con prcticas y tcnicas recomendadas! &u.as de adaptacin de la metodolo&.a al proyecto! &u.as para uso de herramientas de apoyo! etc. Ma#itualmente se utili"a el trmino ,mtodo- para referirse a tcnicas! notaciones y &u.as asociadas! %ue son aplica#les a una 0o al&unas1 actividades del proceso de desarrollo! por eDemplo! suele ha#larse de mtodos de anlisis yEo diseJo. $a comparacin yEo clasificacin de metodolo&.as no es una tarea sencilla de#ido a la diversidad de propuestas y diferencias en el &rado de detalle! informacin disponi#le y alcance de cada una de ellas. ; &randes ras&os! si tomamos como criterio las notaciones utili"adas para especificar artefactos producidos en actividades de anlisis y diseJo! podemos clasificar las metodolo&.as en dos &rupos* Letodolo&.as structuradas y Letodolo&.as 8rientadas a 8#Detos. Por otra parte! considerando su filosof.a de desarrollo! a%uellas metodolo&.as con mayor nfasis en la planificacin y control del proyecto! en especificacin precisa de re%uisitos y modelado! reci#en el apelativo de Letodolo&.as =radicionales 0o peyorativamente denominada Letodolo&.as Pesadas! o Peso Pesado1. 8tras metodolo&.as! denominadas Letodolo&.as P&iles! estn ms orientadas a la &eneracin de cdi&o con ciclos muy cortos de desarrollo! se diri&en a e%uipos de desarrollo pe%ueJos! hacen especial hincapi en aspectos humanos asociados al tra#aDo en e%uipo e involucran activamente al cliente en el proceso. ; continuacin se revisan #revemente cada una de estas cate&or.as de metodolo&.as.

%etodolo&3as estructuradas
$os mtodos estructurados comen"aron a desarrollarse a fines de los NFQs con la Pro&ramacin structurada! lue&o a mediados de los NFQs aparecieron tcnicas para el DiseJo 0por eDemplo* el dia&rama de structura1 primero y posteriormente para el ;nlisis 0por eDemplo* Dia&ramas de ?luDo de Datos1. stas metodolo&.as son particularmente apropiadas en proyectos %ue utili"an para la implementacin len&uaDes de :ra y Kta &eneracin. Demplos de metodolo&.as estructuradas de m#ito &u#ernamental* L >IS K 0?rancia1! LO=>IC; 9 0 spaJa1! SS;DL6 0>eino Unido1. Demplos de propuestas de mtodos estructurados en el m#ito acadmico* 3ane R SarsonN! Sard R Lellor<! Tourdon R DeLarco5 e Information n&ineerin&(F.

%etodolo&3as orientadas a o,jetos

Su historia va unida a la evolucin de los len&uaDes de pro&ramacin orientada a o#Deto! los ms representativos* a fines de los 6FQs SILU$;! a fines de los NFQs SmalltalUH<F! la primera versin de CVV por @Darne Stroustrup en (5<( y actualmente Wava (( o CX de Licrosoft. ; fines de los <FQs comen"aron a consolidarse al&unos mtodos 8rientadas a 8#Deto. n (559 @ooch y >um#au&h proponen el Ltodo Unificado con la am#iciosa idea de conse&uir una unificacin de sus mtodos y notaciones! %ue posteriormente se reorienta a un o#Detivo ms modesto! para dar lu&ar al Unified Lodelin& $an&ua&e 0UL$1 (4! la notacin 88 ms popular en la actualidad. ;l&unos mtodos 88 con notaciones predecesoras de UL$ son* 88;D 0@ooch1! 88S R Tourdon! Shaler R Lellor y 8L= 0>um#au&h1. 0Waco#son1! Coad

;l&unas metodolo&.as orientadas a o#Detos %ue utili"an la notacin UL$ son* >ational Unified Process 0>UP1(:! 8P /(K! LO=>IC; 0%ue tam#in soporta la notacin estructurada1.
K 9 6 N < 5 (F (( (4 (: (K

http*EEperso.clu#Hinternet.frE#rouardfES3@D>merise.htm 0N.9.4FF41 http*EEwww.map.esEcsiEmetrica:E 0N.9.4FF:1 http*EEwww.comp.&lam.ac.uUEpa&esEstaffEtdhutchin&sEchapterK.html 0N.9.4FF:1 http*EEportal.newman.wa.edu.auEtechnolo&yE(4infsysEhtmlEdfdnotes.doc 045.<.4FF:1 http*EEwww.yourdon.comE#ooUsEcool#ooUsEnotesEwardmellor.html 045.<.4FF:1 http*EEwom#at.doc.ic.ac.uUEfoldocEfoldoc.c&iBTourdon74?Demarco 045.<.4FF:1 http*EE&antthead.comE3anttheadEprocessEprocessLainE(!(4<5!4H(4FF5H4!FF.html 045.<.4FF:1 http*EEDava.sun.comE 0N.9.4FF:1 http*EEwww.uml.or&E 0N.9.4FF:1 http*EEwww.rational.comEproductsErupEinde+.Dsp 0N.9.4FF:1 http*EEwww.open.or&.auE 0(N.5.4FF:1
(:

G P.$etelier

Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de Valencia.

%etodolo&3as tradicionales 'no "&iles+

$as metodolo&.as no &iles son a%uellas %ue estn &uiadas por una fuerte planificacin durante todo el proceso de desarrolloI llamadas tam#in metodolo&.as tradicionales o clsicas! donde se reali"a una intensa etapa de anlisis y diseJo antes de la construccin del sistema. =odas las propuestas metodol&icas antes indicadas pueden considerarse como metodolo&.as tradicionales. ;un%ue en el caso particular de >UP! por el especial nfasis %ue presenta en cuanto a su adaptacin a las condiciones del proyecto 0mediante su confi&uracin previa a aplicarse1! reali"ando una confi&uracin adecuada! podr.a considerarse P&il.

%etodolo&3as "&iles
Un proceso es &il cuando el desarrollo de software es incremental 0entre&as pe%ueJas de software! con ciclos rpidos1! cooperativo 0cliente y desarrolladores tra#aDan Duntos constantemente con una cercana comunicacin1! sencillo 0el mtodo en s. mismo es fcil de aprender y modificar! #ien documentado1! y adapta,le 0permite reali"ar cam#ios de 2ltimo momento1 '((). ntre las metodolo&.as &iles identificadas en '(()*

+treme Pro&rammin& '6). Scrum 0'(4)! '(:)1. ?amilia de Letodolo&.as Crystal '(K). ?eature Driven Development '(9). Proceso Unificado >ational! una confi&uracin &il 0'(6)1. Dynamic Systems Development Lethod '(N). ;daptive Software Development '(<). 8pen Source Software Development '(5).

4eferencias
'4F) @al"er >. ' #+ 6ear 0erspecti.e on 'utomatic 0rogramming . I =ransactions on Software n&ineerin&! vol.((! n2m.((! p&inas (49NH(46<! /oviem#re (5<9.

G P.$etelier

(K