PARADIGMAS DE DESARROLLO DE SOFTWARE
1. Ciclos de vida Clásico (cascada)
El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el más ampliamente seguido por las organizaciones se esti es tima ma !ue !ue el 90" 90" de los los sist sistem emas as #an #an sido sido desa desarrrolla ollado doss as así$ í$.. %rde %rdena na rigurosamente las etapas del ciclo de vida del software. &ara pasar de una fase a otra es necesario conseguir todos los o'(etivos de la etapa previa. 1.1 1.1
Rep Repes ese! e!"a "aci ci#! #! $á $á% %ca
)espu*s de cada etapa se realiza una revisi+n para compro'ar si se puede pasar a la siguiente. ra'a(a ra'a(a en 'ase a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento especí-co. dealmente, cada fase podría #acerla un e!uipo diferente gracias a la documentaci+n generada entre las fases. /as fases son oma como entrada una descripci+n en lengua(e natural de lo !ue A!álisis& oma !uiere el cliente. &roduce el .R.). oftware Re!uirements )ocument + )ocumento de Re Re!uisitos !uisitos del software$. software$. 2nálisis de Re!uisitos del istema. 2nálisis de Re Re!uisitos !uisitos del oftware. Dise'o& u entr entrad ada a es el .R .R.). &rod &roduc uce e el .). .).). ). of oftw twar are e )esi )esign gn )ocument + )ocumento de &lan del software$ )ise3o &reliminar. )ise3o )etallado. •
o o
•
o o
•
•
•
1.+ • • • •
•
Codi%caci#!& 2 partir del .).). produce m+dulos. En esta fase se #acen
tam'i*n prue'as de unidad. Peas& 2 partir de los m+dulos pro'ados se realiza la integraci+n y prue'as de todo el sistema. El resultado de las prue'as es el producto -nal listo para entregar. Ma!"e!i*ie!"o& e realizan constantemente al detectarse alguna falla en el sistema o para me(orarlo incluyendo alg4n nuevo modulo al mismo. ,e!"a-as
/a plani-caci+n es sencilla. /a calidad del producto resultante es alta. &ermite &ermite tra'a(ar con personal poco cali-cado. 2yuda a prevenir !ue se so'repasen las fec#as de entrega y los costes esperados. Es me(or !ue no seguir ning4n ciclo de vida.
1. Desve!"a-as •
•
•
• •
Es difícil o'tener todos los re!uisitos al comienzo. /o normal es !ue el cliente no tenga perfectamente de-nidas las especi-caciones del sistema, o puede ser !ue sur(an necesidades imprevistas. imprevistas. i se #an cometido errores en una fase es difícil volver atrás. 2l cam'iar alguna de las etapas se de'e revisar todas las etapas su'siguientes. Es co comp mpar arat ativ ivam amen ente te má máss lent lento o !ue !ue los los demá demáss y el co cost ste e es mayor ayor tam'i*n. e tarda muc#o en disponer del software. 5o se tiene el producto #asta el -nal, esto !uiere decir !ue i se comete un error en la fase de análisis no lo descu'rimos #asta la entrega, con el consiguiente gasto in4til de recursos. El clie client nte e no verá verá res esul ulta tado doss #ast #asta a el -nal -nal,, co con n lo !ue !ue pued puede e impacientarse. 5o se tienen indicadores -a'les del progreso del tra'a(o síndrome del 90"$. El mantenimiento se realiza en el c+digo fuente mpone una estructura de gesti+n de proyectos o
o
•
• •
1./ Aplicacio!es •
• •
2!uellos para los !ue se dispone de todas las especi-caciones desde el principio, por e(emplo, los de reingeniería. e está desarrollando un tipo de producto !ue no es novedoso. &royectos &royectos comple(os !ue se entienden 'ien desde el principio.
+. T0c!icas de /"a $e!eaci#!
6ac acil iliitan tan al ingen ngeniiero del del so sofftwar tware e la espe specici-ca caci ci+n +n de algu alguna nass cara ca ract cter erís ísti tica cass del del so sofftwar tware e a alto alto nive nivel. l. /uego uego,, la #er #errami ramien enta ta gene genera ra automáticamente el c+digo fuente 'asándose en la especi-caci+n del t*cnico.
ada vez parece más evidente !ue cuanto mayor sea el nivel en el !ue se especi-!ue el software, más rápido se podrá construir el programa. El paradigma 8 para la ingeniería del software se orienta #acia la posi'ilidad de especi-car el software usando formas de lengua(e especializado o notaciones grá-cas !ue descri'a el pro'lema !ue #ay !ue resolver en t*rminos !ue los entienda el cliente. 2ctualmente, un entorno para el desarrollo de software !ue soporte el paradigma 8 puede incluir todas o algunas de las siguientes #erramientas /engua(es no procedimentales de consulta a 'ases de datos, eneraci+n de informes, :ane(o de datos, nteracci+n y de-nici+n de pantallas, eneraci+n de c+digos, apacidades grá-cas de alto nivel, apacidades de #o(a de cálculo, eneraci+n automatizada de ;:/ y lengua(es similares utilizados para la creaci+n de sitios we' usando #erramientas de software avanzado. 2l igual !ue otros paradigmas, 8 comienza con el paso de reuni+n de re!uisitos. &or esta raz+n, el diálogo cliente
+.1 Desve!"a-as.
/as 8 están limitadas a las aplicaciones de sistema de informaci+n comercial, y de la o'tenci+n de informes en las grandes 'ases de datos. /as #erramientas actuales de 8 no son más fáciles de utilizar !ue los lengua(es de programaci+n. El c+digo fuente producido por tales #erramientas es ine-ciente= y el mantenimiento de grandes sistemas de software desarrollados mediante 8, es cuestiona'le +.+ Dise'o Ga%co
. Po"o"ipo
>n cliente, a menudo, de-ne un con(unto de o'(etivos generales para el software, pero no identi-ca los re!uisitos detallados de entrada, proceso o salida.
En otros casos, el responsa'le del desarrollo del software puede no estar seguro de la e-cacia de un algoritmo, de la capacidad de adaptaci+n de un sistema operativo, o de la forma en !ue de'ería tomarse la interacci+n #om're má!uina. En este caso el paradigma de construcci+n de prototipos puede ofrecer el me(or enfo!ue. Escca al Clie!"e& El paradigma de construcci+n de prototipos comienza con la recolecci+n de re!uisitos. El desarrollador y el cliente encuentran y de-nen los o'(etivos glo'ales para el software, identi-can los re!uisitos conocidos y las áreas del es!uema en donde es o'ligatoria más de-nici+n. •
•
Co!s"i2Revisa la *a3e"a& Entonces aparece un ?dise3o rápido@. El
dise3o rápido se centra en una representaci+n de esos aspectos del software !ue serán visi'les para el usuarioAcliente por e(emplo enfo!ues de entrada y formatos de salida$. El dise3o rápido lleva a la construcci+n de un prototipo. •
El Clie!"e Pea la *a3e"a& El prototipo lo eval4a el clienteAusuario y
se utiliza para re-nar los re!uisitos del software a desarrollar. /a iteraci+n ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo !ue el desarrollador comprenda me(or lo !ue se necesita #acer. .1 Repese!"aci#! $á%ca
+.1 ,e!"a-as •
2yuda a identi-car los re!uisitos del software.
• •
;ace el software amiga'le al usuario. El cliente estará seguro de !ue el producto -nal reBe(ara lo !ue *l desea.
. Desve!"a-as •
•
•
•
&rimera versi+n de un producto es construido con poca funcionalidad y poca -a'ilidad. El cliente ve lo !ue parece ser una versi+n de tra'a(o del software, y piensa !ue el tra'a(o esta #ec#o. &uede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez. 5o #ay otra alternativa !ue comenzar de nuevo, aun!ue nos duela pero es más inteligente, y construir una versi+n redise3ada en la !ue se resuelvan estos pro'lemas
./ Di4ee!cia e!"e Po"o"ipo 5 Podc"o Fi!al
/a diferencia entre prototipo y producto -nal es !ue el prototipo es e-ciente y el producto -nal de'e serlo y, !ue en el prototipo no están todos los detalles y, el producto -nal de'e contenerlos. lases de prototipos • •
Certical no recoge todas las funciones del sistema -nal. ;orizontal recoge todas las funciones, pero no las desarrolla por completo.
/. Desaollo de Aplicacio!es Rápidas (RAD)
El )esarrollo Rápido de 2plicaciones )R2$ es un modelo de proceso del desarrollo del software lineal secuencial !ue enfatiza un ciclo de desarrollo eDtremadamente corto. El modelo )R2 es una adaptaci+n a ?alta velocidad del modelo lineal secuencial en el !ue se logra el desarrollo rápido utilizando una construcci+n 'asada en componentes. i se comprenden 'ien los re!uisitos y se limita el ám'ito del proyecto, el proceso )R2 permite al e!uipo de desarrollo crear un ?sistema completamente funcional@ dentro de períodos cortos de tiempo. uando se utiliza principalmente para aplicaciones de sistemas de informaci+n, el enfo!ue )R2 comprende las siguientes fases Modelado de Ges"i#!. El Bu(o de informaci+n entre las funciones de gesti+n se
modela de forma !ue responda a las siguientes preguntas Fu* informaci+n conduce el proceso de gesti+nG Fu* informaci+n se generaGFui*n la generaG 2 d+nde va la informaci+nG Fui*n la procesaG
Modelado de da"os. El Bu(o de informaci+n de-nido como parte de la fase de
modelado de gesti+n se re-na como un con(unto de o'(etos de datos necesarios para apoyar la empresa. e de-nen las características llamadas atri'utos$ de cada uno de los o'(etos y las relaciones entre estos o'(etos Modelado del poceso. /os o'(etos de datos de-nidos en la fase de modelado
de datos !uedan transformados para lograr el Bu(o de informaci+n necesario para implementar una funci+n de gesti+n. /as descripciones del proceso se crean para a3adir, modi-car, suprimir, o recuperar un o'(eto de datos. Ge!eaci#! de aplicacio!es. El )R2 asume la utilizaci+n de t*cnicas de cuarta
generaci+n En lugar de crear software con lengua(es de programaci+n de tercera generaci+n, el proceso )R2 tra'a(a para volver a utilizar componentes de programas ya eDistentes cuando es posi'le$ o a crear componentes reutiliza'les cuando sea necesario$. En todos los casos se utilizan #erramientas para facilitar la construcci+n del software. /.1 Repese!"aci#! $á%ca
Peas 5 e!"e$a. omo el proceso DRA enfatiza la reutilizaci+n, ya se #an
compro'ado muc#os de los componentes de los programas. Esto reduce tiempo prue'as. in em'argo, se de'en pro'ar todos los componentes nuevos y se de'en e(ercitar todas las interfaces a fondo. /.+ ,e!"a-as
El )R2 #ace un fuerte uso de componentes reutiliza'les. %'viamente, las limitaciones de tiempo impuestas en un proyecto )R2 demandan ?ám'ito en escalas@. i una aplicaci+n de gesti+n puede modularse de forma !ue permita completarse cada una de las funciones principales en menos de tres meses utilizando el enfo!ue descrito anteriormente$, es un candidato del )R2. ada una de las funciones puede ser afrontada por un e!uipo )R2 separado y ser integradas en un solo con(unto. /. Desve!"a-as
&ara proyectos grandes aun!ue por escalas, re!uiere recursos #umanos su-cientes como para crear el n4mero correcto de e!uipos. Re!uiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo a'reviado. /./ Aplicacio!es !o apopiadas
i un sistema no se puede modularizar adecuadamente, la construcci+n de los componentes necesarios
i está en (uego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistemas 5o es adecuado cuando los riesgos t*cnicos son altos.
6. Poceso 7!i%cado Desaollado de So4"8ae (P7DS) Casos de so& /os casos de uso son las funciones !ue proporciona un sistema
para a3adir valor a sus usuarios es un medio para capturar re!uisitos funcionales. 6.1. Pi!cipales caac"e9s"icas •
•
•
Dii$ido po los casos de so& El proceso de tra'a(o sigue un #ilo de
tra'a(o !ue parte de los casos de uso. /os casos de uso guían el proceso y se desarrollan a la vez !ue la ar!uitectura del sistema y la ar!uitectura del sistema inBuye en la selecci+n de los casos de uso, la ar!uitectura del sistema y los casos de uso maduran seg4n avanza el ciclo de desarrollo. Ce!"ado e! la a3i"ec"a& /a ar!uitectura de'e permitir el desarrollo de todos los casos de uso re!ueridos, a#ora y en el futuro los casos de uso y la ar!uitectura de'en evolucionar en paralelo de'e dise3arse para permitir !ue el sistema evolucione I"ea"ivo e i!ce*e!"al& ada miniproyecto es una iteraci+n !ue resulta en un incremento. /as iteraciones #acen referencia a pasos en el Bu(o de tra'a(o, y los incrementos, al crecimiento del producto las iteraciones de'en estar controladas de'en seleccionarse y e(ecutarse de una forma plani-cada por lo !ue son miniproyectos.
6.+. Fases de!"o de ! ciclo •
•
•
Fase i!icio& Es una descripci+n del producto -nal a partir de una 'uena
idea y se presenta el análisis de negocio para el producto Fase de elaoaci#!& Especi-ca en detalle la mayoría de los casos de uso del producto y se dise3a la ar!uitectura del sistema. e crea la línea 'ase de la ar!uitectura. Fase de co!s"cci#!& e construye el producto. 2!uí la línea 'ase de la ar!uitectura crece #asta convertirse en el sistema completo y preparado para ser entregado a los usuarios.
•
Fase de "a!sici#!& u're el periodo durante el cual el producto se
convierte en versi+n 'eta. >n n4mero reducido de usuarios y con eDperiencia prue'a el producto e informa de defectos y de-ciencias.
6. Fl-os de "aa-o •
Modelo de casos de so& on todos los casos de uso y su relaci+n con los
usuarios. •
Modelo de a!álisis& on dos prop+sitos re-nar los casos de uso con más
detalle y esta'lecer la asignaci+n inicial de funcionalidad del sistema a un con(unto de o'(etos !ue proporcionan el comportamiento. •
Modelo de dise'o& )e-ne
a$ /a estructura estática del sistema en la forma de su'sistemas, clases e interfaces y '$ /os casos de uso reBe(ados como cola'oraciones entre los su'sistemas, clases, e interfaces. •
Modelo de i*ple*e!"aci#!& ncluye componentes y la correspondencia
de las clases con los componentes.
I!cl5e ! *odelo de desplie$e !ue de-ne los nodos físicos
ordenadores$ y la correspondencia de los componentes con esos nodos. •
Modelo de pea& Fue descri'e los casos de prue'a !ue veri-can los
casos de uso y por supuesto una representaci+n de la ar!uitectura. El sistema tam'i*n de'e tener un modelo del dominio o modelo del negocio !ue descri'a el conteDto del negocio en el !ue se #alla el sistema.
odos estos modelos están relacionados. Huntos representan al sistema como un todo.
6./ Las ca"o P:s •
Po5ec"o& Elemento organizativo a trav*s del cual se gestiona el desarrollo
de software. El resultado de un proyecto es una versi+n de un producto. con(unto de actividades necesarias para transformar los re!uisitos de usuario en un producto. >n proceso es una plantilla para crear proyectos.
•
Poceso&
•
Peso!a& /os principales autores de un proyecto software son los
ar!uitectos, desarrolladores, ingenieros de prue'a, y el personal !ue les da soporte, además de los usuarios, clientes, y otros interesados. /as personas son realmente seres #umanos a diferencia del t*rmino a'stracto tra'a(adores. •
Podc"o& 2rtefactos !ue se crean durante la vida del proyecto, como los
modelos, c+digo fuente, e(ecuta'les y documentaci+n. 6.6
Pa"icipa!"es. Co!vi"ie!do ecsos e! "aa-adoes&
>n tipo de tra'a(ador es un papel !ue un individuo puede desempe3ar en el desarrollo de software como puede ser un especi-cador de casos de uso, un ar!uitecto, un ingeniero de componentes, o un ingeniero de prue'as de integraci+n. El termino ol se emplea para #a'lar de los papeles !ue cumple un tra'a(ador. ada tra'a(ador tiene un con(unto de responsa'ilidades y lleva a ca'o un con(unto de actividades en el desarrollo de software.
6.;
Relacio!es e!"e *odelos&
>n sistema contiene todas las relaciones y restricciones entre elementos incluidos en diferentes modelos. &or tanto un sistema no es solo la colecci+n de sus modelos sino !ue contiene tam'i*n las restricciones entre ellos.
6.<
Las ac"ividades elacio!adas co!4o*a! =-os de "aa-o
>n Bu(o de tra'a(o es un con(unto de actividades. El proceso uni-cado se 'asa en una amplia eDperiencia para encontrar el con(unto facti'le de artefactos y tra'a(adores.
En t*rminos de >:/ un Bu(o de tra'a(o es un estereotipo de cola'oraci+n, en el cual los tra'a(adores y los artefactos son los participantes.
6.> ,e!"a-as • • • • • •
•
)e fácil comprensi+n para el e!uipo de desarrollo 6ácil control de cam'ios e o'tiene un modelado visual del software Ceri-caci+n de la calidad del software otalmente organizado. /os desarrolladores, los supervisores y directores pueden cam'iar de proyecto o de divisi+n sin tener !ue aprender un nuevo proceso El desarrollo del software es repeti'le puede plani-carse y estimarse en coste con su-ciente eDactitud como para cumplir las eDpectativas.
6.? Desve!"a-as
•
•
i el grupo !ue desarrolla el proyecto no llega a un estándar de codi-caci+n se produce entropía. i no se realiza la documentaci+n apropiada se produce entropía en el grupo !ue desarrolla el proyecto.
6.1@ EL MODELO R7P (Poceso 7!i%cado de Ra"io!al)
El ciclo de vida R>& es una implementaci+n del )esarrollo en espiral. 6ue creado ensam'lando los elementos en secuencias semi
& divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en n4mero varia'le seg4n el proyecto. En la 6igura muestra c+mo varía el esfuerzo asociado a las disciplinas seg4n la fase en la !ue se encuentre el proyecto R>&. /as primeras iteraciones en las fases de nicio y Ela'oraci+n$ se enfocan #acia la comprensi+n del pro'lema y la tecnología, la delimitaci+n del ám'ito del proyecto, la eliminaci+n de los riesgos críticos, y al esta'lecimiento de una 'aseline /ínea Iase$ de la ar!uitectura. En la fase de ela'oraci+n, las iteraciones se orientan al desarrollo de la 'aseline de la ar!uitectura, a'arcan más los Bu(os de tra'a(o de re!uisitos, modelo de negocios re-namiento$, análisis, dise3o y una parte de implementaci+n orientado a la 'aseline de la ar!uitectura. En la fase de construcci+n, se lleva a ca'o la construcci+n del producto por medio de una serie de iteraciones. &ara cada iteraci+n se selecciona algunos asos de >so, se re-na su análisis y dise3o y se procede a su implementaci+n y prue'as. e realiza una pe!ue3a cascada para cada ciclo. e realizan tantas iteraciones #asta !ue se termine la implementaci+n de la nueva versi+n del producto. En la fase de transici+n se pretende garantizar !ue se tiene un producto preparado para su entrega a la comunidad de usuarios.
;. El *odelo espial WIWI
El modelo en espiral sugiere una actividad del marco de tra'a(o !ue a'orda la comunicaci+n con el cliente. El o'(etivo de esta actividad es mostrar los re!uisitos del cliente. En un conteDto ideal, el desarrollador simplemente pregunta al cliente lo !ue se necesita y el cliente proporciona detalles su-cientes para continuar.
)esgraciadamente, esto raramente ocurre. En realidad el cliente y el desarrollador entran en un proceso de negociaci+n, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otros productos o características del sistema frente al coste y al tiempo de comercializaci+n. /a o'tenci+n de re!uisitos del software re!uiere una negociaci+n. iene *Dito cuando am'as partes ganan. Repese!"aci#! $á%ca
/as me(ores negociaciones se esfuerzan en o'tener victoria
El pi*e p!"o de %-aci#!, llamado o'(etivos del ciclo de vida %C$, de-ne un con(unto de o'(etivos para cada actividad principal de ingeniería del software.
•
El se$!do p!"o de %-aci#! , llamado ar!uitectura del ciclo de vida 2C$, esta'lece los o'(etivos !ue se de'en conocer mientras !ue se de-ne la ar!uitectura del software y el sistema.
/a capacidad operativa inicial %$ es el tercer punto de -(aci+n y representa un con(unto de o'(etivos asociados a la preparaci+n del software para la instalaci+nAdistri'uci+n, preparaci+n del lugar previamente a la instalaci+n, y la asistencia precisada de todas las partes !ue utilizará o mantendrá el software.
<. Recsivo paalelo (Oie!"ado a O-e"os B OO)
;oy en día el paradigma %% encierra una completa visi+n de la ingeniería del software. Edward Ierard declara /os 'ene-cios de la tecnología orientada a o'(etos se fortalecen si se usa antes y durante el proceso de ingeniería del software. <.1 Caac"e9s"icas
Esta tecnología orientada a o'(etos considerada de'e #acer sentir su impacto en todo el proceso de ingeniería del software. >n simple uso de programaci+n orientada a o'(etos &%%$ no 'rindará los me(ores resultados. /os ingenieros del software y sus directores de'en considerar tales elementos El análisis de re!uisitos orientado a o'(etos 2R%%$, El dise3o orientado a o'(etos )%%$, El análisis del dominio orientado a o'(etos 2)%%$, istemas de gesti+n de 'ases de datos orientadas a o'(etos I)%%$ y /a ingeniería del software orientada a o'(etos assistida por comutadora %%2$. • • • • •
<.+ Repese!"aci#! $á%ca
/os sistemas %% utilizan un modelo de ingeniería mediante proceso evolutivo. :ás adelante, en este mismo capítulo, nos referiremos a *l como el modelo recursivo paralelo. •
•
El proceso %% se mueve a trav*s de una espiral evolutiva !ue comienza con la comunicaci+n con el usuario. Es a!uí donde se de-ne el dominio del pro'lema y se identi-can las clases 'ásicas del pro'lema. /a plani-caci+n y el análisis de riesgos esta'lecen
•
una 'ase para el plan del proyecto %%. El tra'a(o t*cnico asociado con la ingeniería del software %% sigue el camino iterativo. /a ingeniería del software %% #ace #incapi* en la reutilizaci+n. &or lo tanto, las clases se 'uscan en una 'i'lioteca de clases %0 eDistentes$ antes de construirse. uando una clase no puede encontrarse en la 'i'lioteca, el desarrollador de software aplica análisis orientado a o'(etos 2%%$, dise3o orientado a o'(etos )%%$, programaci+n orientada a o'(etos &%%$ y prue'as orientadas a o'(etos &R%%$ para crear la clase y los o'(etos derivados de la clase. /a nueva clase se pone en la 'i'lioteca de tal manera !ue pueda ser reutilizada en el futuro.
<. ,e!"a-as •
6omenta el ensam'la(e reutilizaci+n$ de componentes es el me(or paradigma para ingeniería del software %%.
<./ Desve!"a-as •
•
erá eDtremadamente difícil de-nir las clases necesarias para un gran sistema o producto en una sola iteraci+n. /a visi+n orientada a o'(etos demanda un enfo!ue evolutivo de la ingeniería del software.
>. Ciclo de vida e! cascada I!ce*e!"al
En este caso se va creando el sistema a3adiendo pe!ue3as funcionalidades. ada uno de los pe!ue3os incrementos es parecido a lo !ue ocurre dentro de la fase de mantenimiento, en el sentido de aumentar m+dulos. om'ina elementos del modelo cascada aplicados repetidamente$ con la -losofía interactiva de construcci+n de prototipos. >.1 Repese!"aci#! $á%ca
&or un lado está el a!álisis 5 el dise'o $loal . &or otra parte están los pe!ue3os i!ce*e!"os, con las fases de dise3o detallado, codi-caci+n y mantenimiento. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. ada secuencia lineal produce un incremento del software. El modelo incremental entrega el software en partes pe!ue3as, pero utiliza'les, llamadas incrementos$. En general, cada incremento se construye so're a!u*l !ue ya #a sido entregado. •
•
•
El primer incremento a menudo es un producto esencial. Es decir, se afrontan re!uisitos 'ásicos, pero muc#as funciones suplementarias algunas conocidas, otras no$ !uedan sin eDtraer. El cliente utiliza el producto central o sufre la revisi+n detallada$. omo un resultado de utilizaci+n yAo de evaluaci+n, se desarrolla un plan para el incremento siguiente. El plan afronta la modi-caci+n del producto central a -n de cumplir me(or las necesidades del cliente y la entrega de funciones, y características adicionales.
Este proceso se repite siguiendo la entrega de cada incremento, #asta !ue se ela'ore el producto completo. El modelo de proceso incremental, como la construcci+n de prototipos y otros enfo!ues evolutivos, es iterativo por naturaleza.El modelo incremental se centra en la entrega de un producto operacional con cada incremento. /os primeros incrementos son versiones incompletas del producto -nal, pero proporcionan al usuario la funcionalidad !ue precisa y tam'i*n una plataforma para la evaluaci+n. •
>.+ ,e!"a-as • • •
•
5o es necesario tener todos los re!uisitos en un principio. Entrega un producto operacional con cada incremento. Ktil cuando la dotaci+n de personal no está disponi'le para una implementaci+n completa en la fec#a límite !ue se #aya esta'lecido para el proyecto /os primeros incrementos se pueden implementar con menos personas y proporcionan al usuario una plataforma para la evaluaci+n.
>. Desve!"a-as
/os errores en la detecci+n de re!uisitos se encuentran tarde. ada incremento no es el producto -nal, sino más 'ien un producto ! se acerca cada vez más a serlo, el incremento n será el producto -nal. •
?. Fa*e8o
En el desarrollo de software, un frameworL es una estructura de soporte de-nida en la cual otro proyecto de software puede ser organizado y desarrollado. ípicamente, un frameworL puede incluir soporte de programas, 'i'liotecas y un lengua(e interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto. ?.1 A3i"ec"a
)entro de este aspecto, podemos 'asarnos en el modelo :C ontrolador MN :odelo MN Cista$ ya !ue de'emos fragmentar nuestra programaci+n. enemos !ue contemplar estos aspectos 'ásicos en cuanto a la implementaci+n de nuestro sistema •
Co!"olado on este apartado podemos controlar el acceso incluso
todo$ a nuestra aplicaci+n, esto pueden ser arc#ivos, scripts... programasO cual!uier tipo de informaci+n !ue permita la interfaz. 2sí, podremos diversi-car nuestro contenido de forma dinámica, y estática a la vez$O
pues, solo de'emos controlar ciertos aspectos como se #a mencionado antes$. •
Modelo Este miem'ro del controlador mane(a las operaciones l+gicas, y
de mane(o de informaci+n previamente enviada por su ancestro$ para resultar de una forma eDplica'le, y sin titu'eos. ada miem'ro de'e ser meticulosamente llamado, en su correcto nom're y en principio, con su verdadera naturaleza el mane(o de informaci+n, su complementaci+n directa. •
,is"a& 2l -nal, a este miem'ro de la familia le corresponde di'u(ar, o
eDpresar la 4ltima forma de los datos la interfaz grá-ca !ue interact4a con el usuario -nal del programa >$. )espu*s de todo, a este miem'ro le toca evidenciar la informaci+n o'tenida #asta #acerla llegar con el controlador. olo e inicialmente$, nos espera demostrar la informaci+n.
1@. Modelo de ciclo de vida e! espial
&ropuesto originalmente por Ioe#m en 19PP, es un modelo de proceso de software evolutivo !ue con(uga la naturaleza iterativa de construcci+n de prototipos con los aspectos controlados y sistemáticos del modelo cascada
clásico$. &roporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. [email protected] Re$io!es de "aeas
El modelo en espiral se divide en un n4mero de actividades de marco de tra'a(o, tam'i*n llamadas regio!es de tareas. eneralmente, eDisten entre tres y seis regiones de tareas. /a 6igura anterior representa un modelo en espiral !ue contiene seis regiones de tareas más so-sticadas del software. ada paso por la regi+n de plani-caci+n produce a(ustes en el plan del proyecto. El coste y la plani-caci+n se a(ustan con la realimentaci+n ante la evaluaci+n del cliente. 2demás, el gestor del proyecto a(usta el n4mero plani-cado de iteraciones re!ueridas para completar el software. Co*!icaci#! co! el clie!"eB Esta'lecer comunicaci+n entre desarrollador y cliente. Pla!i%caci#!B )e-nir recursos, el tiempo y otra informaci+n relacionadas con el proyecto. A!álisis de ies$osB evaluar riesgos t*cnicos y de gesti+n. I!$e!ie9aB las tareas re!ueridas para construir una o más representaciones de la aplicaci+n. Co!s"cci#! 5 acci#!B construir, pro'ar, instalar y proporcionar soporte al usuario por e(emplo documentaci+n y práctica$ Evalaci#! del clie!"eB las tareas re!ueridas para o'tener la reacci+n del cliente seg4n la evaluaci+n de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalaci+n. •
•
• •
•
•
2l terminar una iteraci+n se comprue'a !ue lo !ue se #a #ec#o efectivamente cumple con los re!uisitos esta'lecidos, tam'i*n se veri-ca !ue funciona correctamente. El propio cliente eval4a el producto. 5o eDiste una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. uando #ay !ue #acer un cam'io, este puede consistir en un nuevo ciclo. 1@.+ ,e!"a-as •
•
•
•
5o necesita una de-nici+n completa de los re!uisitos para empezar a funcionar. 2l entregar productos desde el -nal de la primera iteraci+n es más fácil validar los re!uisitos. El riesgo en general es menor, por!ue si todo se #ace mal, solo se #a perdido el tiempo y recursos invertidos en una iteraci+n las anteriores iteraciones están 'ien$. El riesgo de sufrir retrasos es menor, ya !ue al identi-car los pro'lemas en etapas tempranas #ay tiempo de su'sanarlos.
1@.. Desve!"a-as •
Es difícil evaluar los riesgos.
• •
5ecesita de la participaci+n continua por parte del cliente. uando se su'contrata #ay !ue producir previamente una especi-caci+n completa de lo !ue se necesita, y esto lleva tiempo.
1@./ Aplicacio!es • • •
istemas de gran tama3o. &royectos donde sea importante el factor riesgo. uando no sea posi'le de-nir al principio todos los re!uisitos.
11. Ciclo de vida "ipo Sasi*i
En este caso sin em'argo, se permite un solapamiento entre fases. &or e(emplo, sin tener terminado del todo el dise3o se comienza a implementar. El nom're Qsas#imi deriva del modo del estilo de presentaci+n de roda(as de pescado crudo en Hap+n. /as fases de este ciclo de vida son oncepto.< consiste en de-nir los o'(etivos del proyecto, 'ene-cios, tipo de tecnología y el tipo de ciclo de vida. 2nálisis.< e analiza los re!uerimientos y se 'usca una soluci+n optima. El dise3o ar!uitect+nico.< es el de alto nivel. El dise3o detallado.< es el de 'a(o nivel. odi-caci+n.< e implementa el c+digo del proyecto &rue'as.< e prue'a si el proyecto funciona correctamente es decir sin entropía. •
• • • • •
11.1 Repese!"aci#! $á%ca
11.+ ,e!"a-as
•
>na venta(a de este modelo es !ue no necesita generar tanta documentaci+n como el ciclo de vida en cascada puro de'ido a la continuidad del mismo personal entre fases.
11. Desve!"a-as •
•
Es a4n más difícil controlar el progreso del proyecto de'ido a !ue los -nales de fase ya no son un punto de referencia claro. 2l #acer cosas en paralelo si #ay pro'lemas de comunicaci+n pueden surgir inconsistencias.
