guia de ingenieria del software

5/26/2018 Guia de Ingenieria Del Software

1/83

INGENIERA DEL SOFTWARE:METODOLOGAS Y CICLOS

DE VIDA

Laboratorio Nacional de Calidad delSoftware

Marzo 2009


2/83

NOTA DE EDICINEsta gua ha sido desarrollada por el Laboratorio Nacional de Calidad del Software deINTECO. Esta primera versin ha sido editada en Marzo de 2009.

Ingeniera del software: Metodologas y ciclos de vida 2


3/83


AVISO LEGAL CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la

Universidad Carnegie Mellon

Las distintas normas ISO mencionadas han sido desarrolladas por la InternationalOrganization for Standardization.

Todas las dems marcas registradas que se mencionan, usan o citan en la presente guason propiedad de los respectivos titulares.

INTECO cita estas marcas porque se consideran referentes en los temas que se tratan,buscando nicamente fines puramente divulgativos. En ningn momento INTECO busca con

su mencin el uso interesado de estas marcas ni manifestar cualquier participacin y/oautora de las mismas.

Nada de lo contenido en este documento debe ser entendido como concesin, porimplicacin o de otra forma, y cualquier licencia o derecho para las Marcas Registradasdeben tener una autorizacin escrita de los terceros propietarios de la marca.

Por otro lado, INTECO renuncia expresamente a asumir cualquier responsabilidadrelacionada con la publicacin de las Marcas Registradas en este documento en cuanto aluso de ninguna en particular y se eximen de la responsabilidad de la utilizacin de dichasMarcas por terceros.

El carcter de todas las guas editadas por INTECO es nicamente formativo, buscando entodo momento facilitar a los lectores la comprensin, adaptacin y divulgacin de lasdisciplinas, metodologas, estndares y normas presentes en el mbito de la calidad delsoftware.


4/83

NDICE

1. DESCRIPCIN DE LA GUA 7

2. INTRODUCCIN A LA INGENIERA DEL SOFTWARE 8

2.1. Software 8

2.1.1. Componentes del software 8

2.1.2. Caractersticas del software 9

2.1.3. Tipos de software 11

2.1.4. Aplicaciones del software 11

2.2. Ingeniera del software 13

2.2.1. Historia 14

2.2.2. Etapas 15

2.2.3. Objetivo primario de la ingeniera del software 16

2.2.4. Relevancia de la ingeniera del software 17

2.2.5. Principios de la ingeniera del software 18

2.2.6. Capas 19

3. CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE 24

3.1. Ciclos de vida 24

3.1.1. Tipos de modelo de ciclo de vida 24

3.2. Modelos de ciclo de vida 25

3.2.1. Modelo en cascada 25

3.2.2. Modelo en V 28

3.2.3. Modelo iterativo 30

3.2.4. Modelo de desarrollo incremental 31

3.2.5. Modelo en espiral 32

3.2.6. Modelo de Prototipos 353.3. ISO/IEC 12207 37

4. METODOLOGAS DE DESARROLLO DE SOFTWARE 39

4.1. Definicin de metodologa 39

4.2. Ventajas del uso de una metodologa 41

4.3. Metodologas tradicionales y giles 41

5. DESARROLLO ITERATIVO E INCREMENTAL 44

5.1. La idea bsica 45



5/83

5.2. Debilidades en el modelo 46

5.3. Rapid Application Development (RAD) 46

5.4. Rational Unified Process (RUP) 49

5.4.1. Mdulos de RUP (building blocks) 49

5.4.2. Fases del ciclo de vida del proyecto 50

5.4.3. Certificacin 50

5.5. Desarrollo gil 51

6. DESARROLLO GIL 52

6.1.

Historia 53

6.2. Comparacin con otros mtodos 54

6.2.1. Comparacin con otros mtodos de desarrollo iterativos 54

6.2.2. Comparacin con el modelo en cascada 54

6.2.3. Comparacin con codificacin cowboy 55

6.3. Idoneidad de los mtodos giles 55

6.4. El manifiesto gil 56

6.4.1. Manifiesto para el desarrollo de software gil 57

6.4.2. Principios detrs del manifiesto gil 57

6.5. Mtodos giles 58

6.5.1. Gestin de proyectos 58

6.5.2. Extreme Programming (XP) 59

6.5.3. SCRUM 64

6.5.4. Dynamic Systems Development Method (DSDM) 67

6.5.5. Otros mtodos giles 70

6.6. Prcticas giles 72

6.6.1. Test Driven Development (TDD) 72

6.6.2. Integracin continua 746.6.3. Pair programming 77

6.7. Crticas al desarrollo gil 78

7. CONCLUSIONES 80

8. GLOSARIO 81

9. ACRNIMOS 82

10. 83REFERENCIAS



6/83

NDICE DE FIGURASFigura 1. Componentes del software .................................................................................... 8

Figura 2. Capas de la ingeniera del software .................................................................... 19

Figura 3. Modelo de ciclo de vida en cascada .................................................................... 26

Figura 4. Modelo de ciclo de vida en V ............................................................................... 29

Figura 5.

Modelo de ciclo de vida iterativo .......................................................................... 30

Figura 6. Modelo de ciclo de vida incremental .................................................................... 31

Figura 7. Ciclo de vida en espiral ........................................................................................ 34

Figura 8. Modelo de ciclo de vida de prototipos ................................................................. 36

Figura 9. Tabla comparativa entre metodologas tradicionales y desarrollo gil ................ 43

Figura 10. Desarrollo iterativo e incremental ........................................................................ 44

Figura 11. Flujo de proceso de RAD ..................................................................................... 47

Figura 12. Flujo de proceso de SCRUM ............................................................................... 66

Figura 13. Ciclo de desarrollo de DSDM .............................................................................. 67



7/83

1. DESCRIPCIN DE LA GUAEsta gua pretende ser una introduccin a la ingeniera del software y a las distintasmetodologas y ciclos de vida de desarrollo que existen, haciendo especial hincapi en eldesarrollo gil.

La primera parte de la gua se va a centrar en la contextualizacin de la ingeniera delsoftware. Va a permitir al lector entender las caractersticas, componentes y tipos desoftware, as como los objetivos y componentes de la ingeniera del software.

En la segunda parte de la gua nos centraremos en la definicin del concepto de ciclo devida y en la explicacin de distintos modelos de ciclo de vida existentes.

La tercera parte de la gua se centrar en la explicacin del concepto de metodologa, dondese hablar tanto de modelos tradicionales como de mtodos giles y se desarrollarnalgunas de las metodologas ms utilizadas.

La ltima parte se centrar en la explicacin del desarrollo gil, donde se tratarn tantomodelos como prcticas de desarrollo gil.



8/83

2. INTRODUCCIN A LA INGENIERA DEL SOFTWARECuando un software se desarrolla con xito, cuando satisface las necesidades de laspersonas que lo utilizan; cuando funciona de forma impecable durante mucho tiempo;cuando es fcil de modificar o incluso es ms fcil de utilizar, puede cambiar todas las cosasy de hecho cambiar para mejor. Ahora bien, cuando un software falla, cuando los usuariosno quedan satisfechos, cuando es propenso a errores, cuando es difcil de cambiar e inclusoms difcil de utilizar, pueden ocurrir y de hecho ocurren verdaderos desastres. Todosqueremos desarrollar un software que haga bien las cosas, evitando que esas cosas malasaparezcan. Para tener xito al disear y construir un software necesitaremos disciplina. Esdecir, necesitaremos un enfoque de ingeniera.

2.1. SOFTWARE

En primer lugar se va a tratar un concepto tan importante como es el software. Esimportante entender este concepto para poder pasar a definir a continuacin lo que es laingeniera del software.

Algunas definiciones de software:

IEEE Std. 610 define el software como programas, procedimientos y documentaciny datos asociados, relacionados con la operacin de un sistema informtico

Segn el Websters New Collegiate Dictionary (1975), software es un conjunto deprogramas, procedimientos y documentacin relacionada asociados con un sistema,especialmente un sistema informtico.

El software se puede definir como el conjunto de tres componentes:

Programas (instrucciones): este componente proporciona la funcionalidad deseada yel rendimiento cuando se ejecute.

Datos: este componente incluye los datos necesarios para manejar y probar losprogramas y las estructuras requeridas para mantener y manipular estos datos.

Documentos: este componente describe la operacin y uso del programa.

SOFTWARE PROGRAMAS DATOS DOCUMENTACIN

Figura 1. Componentes del software

2.1.1. Componentes del software

Es importante contar con una definicin exhaustiva del software ya que de otra manera sepodran olvidar algunos componentes. Una percepcin comn es que el software sloconsiste en programas. Sin embargo, los programas no son los nicos componentes del

software.



9/83

Programas

Los programas son conjuntos de instrucciones que proporcionan la funcionalidad deseadacuando son ejecutadas por el ordenador. Estn escritos usando lenguajes especficos quelos ordenadores pueden leer y ejecutar, tales como lenguaje ensamblador, Basic,FORTRAN, COBOL, C Los programas tambin pueden ser generados usandogeneradores de programas.

Datos

Los programas proporcionan la funcionalidad requerida manipulando datos. Usan datos paraejercer el control apropiado en lo que hacen. El mantenimiento y las pruebas de losprogramas tambin necesitan datos. El diseo del programa asume la disponibilidad de las

estructuras de datos tales como bases de datos y archivos que contienen datos.Documentos

Adems de los programas y los datos, los usuarios necesitan tambin una explicacin decmo usar el programa.

Documentos como manuales de usuario y de operacin son necesarios para permitir a losusuarios operar con el sistema.

Los documentos tambin son requeridos por las personas encargadas de mantener elsoftware para entender el interior del software y modificarlo, en el caso en que seanecesario.

2.1.2. Caractersticas del software

A lo largo de los aos, se han evolucionado muchas formas de producir bienes de mejorcalidad en el sector de las manufacturas. Este conocimiento puede extenderse a laconstruccin de productos software de mejor calidad si los profesionales del softwareentienden las caractersticas propias del software.

Para poder comprender lo que es el software (y consecuentemente la ingeniera delsoftware), es importante examinar las caractersticas del software que lo diferencian de otrascosas que el hombre puede construir.

El software es esencialmente un conjunto de instrucciones (programas) que proporcionan lafuncionalidad requerida, los datos relacionados y documentos. Por lo tanto, el software es unelemento lgico y se diferencia del hardware, un elemento fsico, en sus caractersticas.

El software se desarrolla, no se fabrica en el sentido clsico. Aunque existen similitudesentre el desarrollo del software y la construccin del hardware, ambas actividades sonfundamentalmente distintas.

Cada producto software es diferente porque se construye para cumplir los requisitos nicosde un cliente. Cada software necesita, por lo tanto, ser construido usando un enfoque deingeniera.

Construir un producto software implica entender qu es necesario, disear el producto paraque cumpla los requisitos, implementar el diseo usando un lenguaje de programacin y



10/83

comprobar que el producto cumple con los requisitos. Todas estas actividades se llevan a

cabo mediante la ejecucin de un proyecto software y requiere un equipo trabajando de unaforma coordinada.

El proceso usado para construir software es diferente de la fabricacin del hardware, dondelas mquinas se usan para producir partes y cada trabajador slo necesita realizar la tareaasignada o usar una mquina.

En el software, el recurso principal son las personas. No es siempre posible acelerar laconstruccin de software aadiendo personas porque la construccin de software requiereun esfuerzo en equipo. El equipo tiene que trabajar de forma coordinada y compartir unobjetivo de proyecto comn. Se necesita comunicacin efectiva dentro del equipo.

Un nuevo miembro del equipo no es inmediatamente productivo y necesita la iniciacinadecuada al equipo y la formacin para realizar el trabajo. Esto requiere una inversin detiempo y esfuerzo por parte de los miembros del equipo existentes y les puede distraer de supropio trabajo.

Otra caracterstica del software es que no se estropea. Los defectos no detectados harnque falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que secorrigen (suponiendo que no se introducen nuevos errores) los fallos disminuyen.

El software no se estropea, pero se deteriora. Durante su vida, el software sufre cambios(mantenimiento). Conforme se hacen los cambios, es bastante probable que se introduzcannuevos defectos, lo que hace que el software se vaya deteriorando debido a los cambios.

Otro aspecto del software es que, debido a que la industria del software es nueva, elsoftware se diferencia del hardware en el aspecto de uso de componentes. Aunque lamayora de la industria tiende a ensamblar componentes, la mayora del software seconstruye a medida.

Los componentes reutilizables se han creado para que el ingeniero pueda concentrarse enelementos verdaderamente innovadores de un diseo. En el mundo del software es algo queslo ha comenzado a lograrse en productos lanzados a gran escala.

El componente software debera disearse e implementarse para que pueda volver a serreutilizado en muchos programas diferentes. Hoy en da, se ha extendido la visin de lareutilizacin para abarcar tanto algoritmos como estructuras de datos, permitiendo alingeniero del software crear nuevas aplicaciones a partir de las partes reutilizables.

El hardware usa componentes estndar con funciones e interfaces bien definidas. El uso deestos componentes ayuda a evitar reinventar la rueda. La fase de diseo en el ciclo de vidade un producto hardware implica seleccionar los componentes disponibles ms adecuadosy decidir el enfoque para montarlos. Los componentes de hardware estndar son tilesporque conducen a:

Reducir el coste y el tiempo de lanzamiento al mercado

Buena calidad

Ingeniera rpida



11/83

Fcil mantenimiento

Fcil mejora

El software se crea normalmente desde cero. Con frecuencia se construye de acuerdo a losrequisitos especficos de un cliente y no se crea por la unin de componentes existentes.

Como la industria del hardware, la industria del software est intentando adoptar elmecanismo de reutilizar para hacer ms fcil y ms rpida la construccin. Las ventajas dela reutilizacin de software estn siendo entendidas y apreciadas. Existen algunoselementos reutilizables a travs de libreras de funciones y objetos reutilizables quecombinan funciones y datos.

Mientras que la reutilizacin y el montaje basado en componentes se estn incrementando,

la mayora del software continua siendo construido de forma personalizada, y los niveles dereutilizacin actuales estn lejos de los que deberan ser. Adems, la tarea de identificarcomponentes reutilizables potenciales es difcil porque cada producto software es nico ydistinto.

La industria del software tiene procesos bien definidos para la reutilizacin de componentes.Esto incluye procesos para la construccin de componentes, almacenamiento de los mismosen libreras de donde se pueden extraer para su reutilizacin y entonces incorporarlos.

A lo largo de los aos, la industria del software espera crear componentes reutilizablesespecficos a dominios de aplicacin particulares.

2.1.3. Tipos de sof tware

El software puede dividirse en dos grandes categoras:

Software de aplicaciones: se usan para proveer servicios a clientes y ejecutarnegocios de forma ms eficiente. El software de aplicaciones puede ser un sistemapequeo o uno grande integrado. Como ejemplos de este tipo de software estn: unsistema de cuentas, un sistema de planificacin de recursos

Software de sistemas: el software de sistemas se usa para operar y mantener unsistema informtico. Permite a los usuarios usar los recursos del ordenadordirectamente y a travs de otro software. Algunos ejemplos de este tipo de softwareson: sistemas operativos, compiladores y otras utilidades del sistema.

2.1.4. Apl icaciones del software

El software puede aplicarse en cualquier situacin en la que se haya definido previamenteun conjunto especfico de pasos procedimentales (es decir, un algoritmo) (excepcionesnotables a esta regla son el software de los sistemas expertos y de redes neuronales). Elcontenido y determinismo de la informacin son factores importantes a considerar paradeterminar la naturaleza de una aplicacin software. El contenido se refiere al significado y ala forma de la informacin de entrada y salida. Por ejemplo, muchas aplicaciones bancariasusan unos datos de entrada muy estructurados (una base de datos) y producen informescon determinados formatos. El software que controla una mquina automtica (por ejemplo:



12/83

un control numrico) acepta elementos discretos con una estructura limitada y produce

rdenes concretas para la mquina en rpida sucesin.El determinismo de la informacin se refiere a la predictibilidad del orden y del tiempo dellegada de los datos. Un programa de anlisis de ingeniera acepta datos que estn en unorden predefinido, ejecuta algoritmos de anlisis sin interrupcin y produce los datosresultantes en un informe o formato grfico. Un sistema operativo multiusuario, por otraparte, acepta entradas que tienen un contenido variado y que se producen en instantesarbitrarios, ejecuta algoritmos que pueden ser interrumpidos en condiciones externas yproduce una salida que depende de una funcin del entorno y del tiempo. Las aplicacionescon estas caractersticas se dice que son indeterminadas.

Algunas veces es difcil establecer categoras genricas para las aplicaciones del software

que sean significativas. Conforme aumenta la complejidad del software, es ms difcilestablecer compartimentos ntidamente separados. Las siguientes reas del softwareindican la amplitud de las aplicaciones potenciales:

Software de sistemas: el software de sistemas es un conjunto de programas quehan sido escritos para servir a otros programas. Algunos programas de sistemas (porejemplo: compiladores, editores y utilidades de gestin de archivos) procesanestructuras de informacin complejas pero determinadas. Otras aplicaciones desistemas (por ejemplo: ciertos componentes del sistema operativo, utilidades demanejo de perifricos, procesadores de telecomunicaciones) procesan datos en granmedida indeterminados. En cualquier caso, el rea del software de sistemas se

caracteriza por una fuerte interaccin con el hardware de la computadora; una granutilizacin por mltiples usuarios; una operacin concurrente que requiere unaplanificacin, una comparticin de recursos y una sofisticada gestin de procesos;unas estructuras de datos complejas y mltiples interfaces externas.

Software de tiempo real: el software que coordina/analiza/controla sucesos delmundo real conforme ocurren. Entre los elementos del software de tiempo real seincluyen: un componente de adquisicin de datos que recolecta y da formato a lainformacin recibida del entorno externo, un componente de anlisis que transformala informacin segn lo requiera la aplicacin, un componente de control/salida queresponda al entorno externo y un componente de monitorizacin que coordina todos

los dems componentes, de forma que pueda mantenerse el respuesta en tiemporeal.

Software de gestin: el proceso de la informacin comercial constituye la mayor delas reas de aplicacin del software. Los sistemas discretos (por ejemplo: nminas,cuentas de haberes-dbitos, inventarios, etc.) han evolucionado hacia el software desistemas de informacin de gestin (SIG) que accede a una o ms bases de datosque contienen informacin comercial. Las aplicaciones en esta rea reestructuran losdatos existentes para facilitar las operaciones comerciales o gestionar la toma dedecisiones. Adems de las tareas convencionales de procesamiento de datos, lasaplicaciones de software de gestin tambin realizan clculo interactivo (por ejemplo:

el procesamiento de transacciones en puntos de venta).



13/83

Software de ingeniera y cientfico : este tipo de software est caracterizado por los

algoritmos de manejo de nmeros. Las aplicaciones van desde la astronoma a lavulcanologa, desde el anlisis de la presin de los automotores a la dinmica orbitalde las lanzaderas espaciales y desde la biologa molecular a la fabricacinautomtica. Sin embargo las nuevas aplicaciones del rea de ingeniera/ciencia sehan alejado de los algoritmos convencionales numricos. El diseo asistido porcomputadora (CAD), la simulacin de sistemas y otras aplicaciones interactivas, hancomenzado a coger caractersticas del software de tiempo real e incluso de softwarede sistemas.

Software empotrado: los productos inteligentes se han convertido en algo comn encasi todos los mercados de consumo e industriales. El software empotrado reside en

memoria de slo lectura y se utiliza para controlar productos y sistemas de losmercados industriales y de consumo. El software empotrado puede ejecutarfunciones muy limitadas y curiosas (por ejemplo: el control de las teclas de un hornomicroondas) o suministrar una funcin significativa y con capacidad de control (porejemplo: funciones digitales en un automvil, tales como control de la gasolina,indicadores en el salpicadero, sistemas de frenado, etc.)

Software de computadoras personales: el mercado del software de computadoraspersonales ha germinado en las pasadas dcadas. El procesamiento de textos, lashojas de clculo, los grficos por computadora, multimedia, entretenimiento, gestinde bases de datos, aplicaciones financieras, de negocios y personales y redes o

acceso a bases de datos externas son algunas de los cientos de aplicaciones. Software basado en web: las pginas web buscadas por un explorador son

software que incorpora instrucciones ejecutables y datos.

Software de inteligencia artificial: el software de inteligencia artificial hace uso dealgoritmos no numricos para resolver problemas complejos para los que no sonadecuados el clculo o el anlisis directo. Los sistemas expertos, tambin llamadossistemas basados en el conocimiento, reconocimiento de patrones (imgenes y voz),redes neuronales artificiales, prueba de teoremas y los juegos son representativos delas aplicaciones de esta categora.

2.2. INGENIERA DEL SOFTWAREEl trmino ingeniera de software se define en el DRAE (Diccionario de la Real AcademiaEspaola) como:

1. Conjunto de conocimientos y tcnicas que permiten aplicar el saber cientfico a lautilizacin de la materia y de las fuentes de energa.

2. Profesin y ejercicio del ingeniero

Y el trmino ingeniero se define como:

1. Persona que profesa o ejerce la ingeniera.



14/83

De igual modo, la Real Academia de Ciencias Exactas, Fsicas y Naturales de Espaa

define el trmino Ingeniera como: conjunto de conocimientos y tcnicas cuya aplicacinpermite la utilizacin racional de los materiales y de los recursos naturales, medianteinvenciones, construcciones u otras realizaciones provechosas para el hombre.

Otras definic iones:

1. Ingeniera del Software es el estudio de los principios y metodologas para eldesarrollo y mantenimiento de sistemas de software (Zelkovitz, 1978)

2. Ingeniera del Software es la aplicacin prctica del conocimiento cientfico al diseoy construccin de programas de computadora y a la documentacin asociadarequerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce tambin

como desarrollo de software o produccin de software (Bohem, 1976)3. Ingeniera del Software trata del establecimiento de los principios y mtodos de la

ingeniera a fin de obtener software de modo rentable que sea fiable y trabaje enmquinas reales (Bauer, 1972)

4. La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo,operacin (funcionamiento) y mantenimiento del software; es decir, la aplicacin deingeniera al software. (IEEE, 1993)

La definicin de IEEE describe la ingeniera del software como un enfoque sistemticocubriendo los aspectos del desarrollo, operacin y mantenimiento. Este enfoque esdisciplinado y cuantificable.

2.2.1. Historia

El trmino ingeniera del software apareci por primera vez en la conferencia de ingenierade software de la OTAN en 1968 y fue mencionado para provocar el pensamiento sobre lacrisis de software del momento. Desde entonces, ha continuado como una profesin ycampo de estudio dedicado a la creacin de software de alta calidad, barato, con capacidadde mantenimiento y rpido de construir. Debido a que el campo es todava relativamentejoven comparado con otros campos de la ingeniera, hay todava mucho trabajo y debatesobre qu es realmente la ingeniera del software, y si se merece el ttulo de ingeniera. Hacrecido orgnicamente fuera de las limitaciones de ver el software slo como programacin.

Mientras que el trmino ingeniera del software fue acuado en una conferencia en 1968, losproblemas que intentaba tratar empezaron mucho antes. La historia de la ingeniera delsoftware est entrelazada con las historias contrapuestas de hardware y software.

Cuando el ordenador digital moderno apareci por primera vez en 1941, las instruccionespara hacerlo funcionar estaban conectadas dentro de la maquina. Las personasrelacionadas con la ingeniera rpidamente se dieron cuenta de que este diseo no eraflexible e idearon la arquitectura de programa almacenado o arquitectura von Neumann. Deesta forma la primera divisin entre hardware y software empez con la abstraccinusada para tratar la complejidad de la computacin.



15/83

Los lenguajes de programacin empezaron a aparecer en la dcada de 1950 y este fue otro

paso importante en la abstraccin. Los lenguajes principales como Fortran, Algol y Cobol selanzaron a finales de los 50s para tratar con problemas cientficos, algortmicos y de negociorespectivamente. Dijsktra escribi Go to Statement Considered Harmful en 1968 y DavidParnas introdujo el concepto clave de la modularidad y encapsulacin en 1972 para ayudara los programadores a tratar con la complejidad de los sistemas de software. Un sistemasoftware para gestionar el hardware, denominado sistema operativo tambin se introdujo,ms notablemente por Unix en 1969. En 1967, el lenguaje Simula introdujo el paradigma dela programacin orientada a objetos.

Estos avances en software se encontraron con ms avances en el hardware. A mediados delos 70s, la microcomputadora fue introducida, haciendo econmico a los aficionados a

obtener una computadora y escribir software para l. Esto sucesivamente condujo al famosoordenador personal o PC y Microsoft Windows. El ciclo de vida de desarrollo de software oSDLC tambin empez a aparecer como un consenso para la construccin centralizada desoftware a mediados de los 80s. A finales de los 70s y principios de los 80 se vieron varioslenguajes de programacin orientados a objetos inspirados en Simula, incluyendo C++,Smalltalk y Objective C.

El software open source empez a aparecer a principios de los 90s en la forma de Linux yotros software introduciendo el bazaar o el estilo descentralizado de construccin desoftware. Despus aparecieron Internet y la World Wide Web a mediados de los 90scambiando de nuevo la ingeniera del software. Los sistemas distribuidos ganaron dominiocomo forma de disear sistemas y el lenguaje de programacin Java se introdujo como otropaso en la abstraccin, teniendo su propia mquina virtual. Varios programadorescolaboraron y escribieron el manifiesto gil que favoreci procesos ms ligeros para crearsoftware ms barato y en menos tiempo.

2.2.2. Etapas

La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas comolas siguientes:

Anlisis de requisi tos

Extraer los requisitos de un producto software es la primera etapa para crearlo. Mientras quelos clientes piensan que ellos saben lo que el software tiene que hacer, se requiere habilidady experiencia en la ingeniera del software para reconocer requisitos incompletos, ambiguoso contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en eldocumento Especificacin de Requisitos. Asimismo, se define un diagrama deentidad/relacin, en el que se plasman las principales entidades que participarn en eldesarrollo de software.

La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una partecrucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se hanideado modelos y diversos procesos de trabajo para estos fines. Aunque an no estformalizada, se habla de la Ingeniera de Requisitos.



16/83

La IEEE Std. 830-1998 normaliza la creacin de las especificaciones de requisitos software.

Especificacin

Es la tarea de escribir detalladamente el software a ser desarrollado, en una formamatemticamente rigurosa. En la realidad, la mayora de las buenas especificaciones hansido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Lasespecificaciones son ms importantes para las interfaces externas, que deben permanecerestables.

Diseo y arquitectura

Se refiere a determinar cmo funcionar el software de forma general sin entrar en detalles.Consisten en incorporar consideraciones de la implementacin tecnolgica, como el

hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizar elsistema, y se transformarn las entidades definidas en el anlisis de requisitos en clases dediseo, obteniendo un modelo cercano a la programacin orientada a objetos.

Programacin

Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera delsoftware, pero no necesariamente es la que demanda mayor trabajo ni la ms complicada.La complejidad y la duracin de esta etapa est ntimamente relacionada al o a loslenguajes de programacin utilizados, as como al diseo previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en laespecificacin del problema. Una tcnica de prueba es probar por separado cada mdulodel software y luego probarlo de forma integral, para as llegar al objetivo. Se considera unabuena prctica que las pruebas sean efectuadas por alguien distinto al desarrollador que laprogram.

Mantenimiento

Mantener y mejorar el software para solventar errores descubiertos y tratar con nuevosrequisitos. El mantenimiento puede ser de cuatro tipos: perfectivo (mejorar la calidad internade los sistemas), evolutivo (incorporaciones, modificaciones y eliminaciones necesarias enun producto software para cubrir la expansin o cambio en las necesidades del usuario),adaptativo (modificaciones que afectan a los entornos en los que el sistema opera, porejemplo, cambios de configuracin del hardware, software de base, gestores de base dedatos, comunicaciones) y correctivo (correccin de errores).

2.2.3. Objetivo primario de la ingeniera del software

Hemos visto que todas las definiciones de la ingeniera del software se centran en el uso deun enfoque sistemtico para la construccin de software.

El objetivo primario de la ingeniera del software es construir un producto de alta calidad deuna manera oportuna. Trata de conseguir este objetivo primario usando un enfoque de

ingeniera.



17/83

La ingeniera implica un conjunto de principios fundamentales que deberan seguirse

siempre. Incluyen actividades explcitas para el entendimiento del problema y lacomunicacin con el cliente, mtodos definidos para representar un diseo, mejoresprcticas para la implementacin de la solucin y estrategias y tcticas slidas para laspruebas. Si se siguen los principios bsicos, esto resulta en productos de alta calidad.

Para conseguir el objetivo de construir productos de alta calidad dentro de la planificacin, laingeniera del software emplea una serie de prcticas para:

Entender el problema

Disear una solucin

Implementar la solucin correctamente

Probar la solucin

Gestionar las actividades anteriores para conseguir alta calidad

La ingeniera del software representa un proceso formal que incorpora una serie de mtodosbien definidos para el anlisis, diseo, implementacin y pruebas del software y sistemas.Adems, abarca una amplia coleccin de mtodos y tcnicas de gestin de proyectos parael aseguramiento de la calidad y la gestin de la configuracin del software.

2.2.4. Relevancia de la ingeniera del sof tware

Hoy en da, los productos software se construyen con un nivel de urgencia que no se veaen aos anteriores. La prioridad ms alta de las compaas es reducir el tiempo de salida almercado, que es la base del desarrollo rpido.

La ingeniera de software es percibida por algunos como demasiado formal, que consumedemasiado tiempo y demasiado estructurada para la flexibilidad necesaria durante eldesarrollo de hoy en da. Las personas que hacen estas crticas exponen que no se puedenpermitir la formalidad de un enfoque de ingeniera para construir software porque necesitandesarrollar productos de forma rpida. Las personas que lanzan tales objeciones ven laingeniera como una disciplina esttica y piensan que no se puede adaptar a lasnecesidades cambiantes del negocio y la industria. La verdad es, sin embargo, que laingeniera del software es adaptativa y por lo tanto, relevante para cualquiera que construyaun producto software.

La ingeniera del software es adaptativay no una metodologa rgida. Es una filosofa quepuede ser adaptada y aplicada a todas las actividades y dominios de aplicacin deldesarrollo de software.

La ingeniera del software proporciona una amplia coleccin de opciones que losprofesionales pueden elegir para construir productos de alta calidad. Sin embargo, no hayun enfoque de ingeniera individual o un conjunto de procesos, mtodos o herramientas deingeniera del software para construir un producto software.



18/83

El enfoque de ingeniera del software, incluyendo los procesos, mtodos y herramientas

puede y debera ser adaptada al producto, la gente que lo construye y el entorno delnegocio.

Los profesionales del software, por lo tanto, no deberan ser dogmticos sobre la ingenieradel software. No es una religin y no hay verdades absolutas.

2.2.5. Principios de la ingeniera del software

Entre los principios ms destacados de la ingeniera del software, podemos sealar lossiguientes:

Haz de la calidad la razn de trabajar.

Una buena gestin es ms importante que una buena tecnologa.

Las personas y el tiempo no son intercambiables.

Seleccionar el modelo de ciclo de vida adecuado.

Entregar productos al usuario lo ms pronto posible.

Determinar y acotar el problema antes de escribir los requisitos.

Realizar un diseo.

Minimizar la distancia intelectual.

Documentar. Las tcnicas son anteriores a las herramientas.

Primero hazlo correcto, luego hazlo rpido.

Probar, probar y probar.

Introducir las mejoras y modificaciones con cuidado.

Asuncin de responsabilidades.

La entropa del software es creciente.

La gente es la clave del xito.

Nunca dejes que tu jefe o cliente te convenza para hacer un mal trabajo.

La gente necesita sentir que su trabajo es apreciado.

La educacin continua es responsabilidad de cada miembro del equipo.

El compromiso del cliente es el factor ms crtico en la calidad del software.

Tu mayor desafo es compartir la visin del producto final con el cliente.

La mejora continua de tu proceso de desarrollo de software es posible y esencial.

Tener procedimientos escritos de desarrollo de software puede ayudar a crear una

cultura compartida de buenas prcticas.



19/83

La calidad es el principal objetivo; la productividad a largo plazo es una consecuencia

de una alta calidad. Haz que los errores los encuentre un colaborador, no un cliente.

Una clave en la calidad en el desarrollo de software es realizar iteraciones en todaslas fases del desarrollo excepto en la codificacin.

La gestin de errores y solicitud de cambios es esencial para controlar la calidad y elmantenimiento.

Si mides lo que haces puedes aprender a hacerlo mejor.

Haz lo que tenga sentido; no recurras a los dogmas.

No puedes cambiar todo de una vez. Identifica los cambios que se traduzcan en losmayores beneficios, y comienza a implementarlos.

2.2.6. Capas

El enfoque de ingeniera del software cuenta con un compromiso organizacional con lacalidad porque no es posible incorporar la ingeniera del software en una organizacin queno est centrada en conseguir calidad.

La ingeniera del software es una tecnologa multicapa. Se puede ver como un conjunto decomponentes estratificados, que reposan sobre ese enfoque de calidad.

Un enfoque de calidadProcesos

Mtodos

Herramientas

Figura 2. Capas de la ingeniera del software

Estos componentesque forman parte de la ingeniera del software son:

Procesos: un marco de trabajo que ayuda al jefe de proyecto a controlar la gestindel proyecto y las actividades de ingeniera.

Mtodos: las actividades tcnicas requeridas para la creacin de productos detrabajo.

Herramientas: la ayuda automatizada para los procesos y mtodos.

2.2.6.1. Procesos

El fundamento de la ingeniera del software es la capa de proceso. El proceso define unmarco de trabajo para un conjunto de reas clave de proceso que se deben establecer para

la entrega efectiva de la tecnologa de la ingeniera del software.



20/83

La capa de proceso define el proceso que se usar para construir el software y las

actividades y tareas que un jefe de proyecto tiene que gestionar. Por lo tanto, las reasclaves del proceso forman la base del control de gestin de proyectos del software yestablecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos detrabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, seasegura la calidad y el cambio se gestiona adecuadamente. El proceso de la ingeniera delsoftware es la unin que mantiene juntas las capas de tecnologas y que permite undesarrollo racional y oportuno de la ingeniera del software.

La capa de proceso:

Permite al jefe de proyecto planificar una ejecucin exitosa del proyecto. La capa deproceso proporciona una hoja de ruta del trabajo de ingeniera del software. Ayuda al

jefe de proyecto en la creacin de un plan de trabajo viable que asle tareas detrabajo, responsabilidades, los productos de trabajo producidos, y los mecanismosusados para asegurar calidad en dichos productos de trabajos. Permite la ejecucinde proyectos software dentro de un marco de tiempo razonable.

Proporciona a las personas involucradas el contexto de su trabajo. La capa deproceso gua a las personas involucradas proporcionando el marco de trabajo en elque entienden el contexto de las tareas a realizar.

Se pueden ver todas las actividades, incluyendo las actividades tcnicas, como parte delproceso. Adems, cualquier recurso, incluyendo herramientas usadas para construir el

software tambin encajan en el proceso. La capa de proceso es, por lo tanto, el fundamentode la ingeniera del software y da soporte a las capas de mtodos y herramientas.

Importancia de un proceso

Un proceso es til porque proporciona claridad en cmo ha de realizarse el trabajo.Cualquier conjunto de actividades humanas complejas se puede convertir en catico si nohay guas para que las personas puedan realizar las actividades. Un proceso definidoresponde a las siguientes cuestiones:

Quin se comunica con quin?

Cmo se coordinan las actividades interdependientes?

Quin es responsable de qu trabajo?

Quin produce qu productos de trabajo, y cmo se evalan?

Un proceso:

Identifica todas las actividades y tareas de la ingeniera del software

Define el flujo de trabajo entre las actividades y tareas

Identifica los productos de trabajo que se producen

Especifica los puntos de control de calidad requeridos



21/83

Algunas personas ven el desarrollo de software con una perspectiva que requiere

habilidades artsticas y de artesana y que es inherentemente catico. Se resisten a la ideade usar un proceso definido porque lo ven como incmodo y burocrtico y por lo tantodificulta la creatividad.

Aunque no hay duda de que el desarrollo de software requiere creatividad, la mayora delsoftware de calidad en la industria se desarrolla por el esfuerzo coordinado de ms de unapersona. Para cualquier esfuerzo de equipo, el control coordinado es mejor alternativa quela anarqua. La hoja de ruta proporcionada por un proceso es til para las personas queconstruyen productos software o que gestionan proyectos.

Todos los enfoques de la construccin de software tienen un proceso, pero en muchoscasos, son ad hoc, invisibles y caticos. Una buena ingeniera de software hace que el

proceso de software sea ms visible, predecible y ms til para aquellos que construyensoftware.

La capa de proceso abarca las siguientes cuestiones:

El marco de trabajo de proceso comn (CPF)

Actividades y tareas de la ingeniera de software

Puntos de control de calidad

Definiciones de productos de trabajo

Gestin de proyectos

Aseguramiento de la calidad del software

Gestin de la configuracin del software

Monitorizacin de proyectos

Medidas y mtricas

2.2.6.2. Mtodos

La capa de proceso identifica las tareas de ingeniera que se deben realizar para construirsoftware de alta calidad.

La siguiente capa, la capa de mtodos se centra en las actividades tcnicas que se debenrealizar para conseguir las tareas de ingeniera. Proporciona el cmo y cubre lasactividades de ingeniera fundamentales.

Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo,construccin de programas, pruebas y mantenimiento. Los mtodos de la ingeniera delsoftware dependen de un conjunto de principios bsicos que gobiernan cada una de lasreas de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas.

La construccin de software implica una amplia coleccin de actividades tcnicas. La capade mtodos contiene los mtodos definidos para realizar esas actividades de forma

eficiente. Se centra en cmo se han de realizar las actividades tcnicas. Los personas



22/83

involucradas usan los mtodos para realizar las actividades de ingeniera fundamentales

necesarias para construir el software.Las actividades tcnicas fundamentales para construir software son:

Anlisis: el anlisis es el fundamento de todos los trabajos de ingeniera que siguen.Durante el anlisis, se crea el modelo de lo que es requerido por el software.

Diseo: las actividades de diseo siguen el anlisis y traducen el modelo del anlisisen cmo el producto proporciona estas funciones por medio del software.

Codificacin: una vez que el diseo es completo, la codificacin traduce el modelo dediseo en una forma ejecutable.

Pruebas: el proceso de pruebas ayuda a destapar errores en el cdigo y el diseosubyacente.

Tambin se realizan actividades de soporte: revisiones tcnicas y soporte de mtricas.

Para varias actividades de proceso, la capa de mtodos contiene el correspondienteconjunto de mtodos tcnicos para usar. Esto abarca un conjunto de reglas, los modos derepresentacin grficos o basados en texto, y las guas relacionadas para la evaluacin dela calidad de la informacin representada.

Para definir la capa de mtodos, es necesario seleccionar un mtodo adecuado de unamplio rango de mtodos disponibles.

Consideramos las actividades de anlisis y diseo. Hay una amplia variedad de mtodosdisponibles. El equipo de proyecto debera seleccionar el mtodo que es ms apropiadopara el problema, el entorno de desarrollo y el conocimiento y experiencia de los miembrosdel equipo.

2.2.6.3. Herramientas

La capa de herramientas proporciona soporte a las capas de proceso y mtodoscentrndose en el significado de la automatizacin de algunas de las actividades manuales.Las herramientas se pueden utilizar para automatizar las siguientes actividades:

Actividades de gestin de proyectos Mtodos tcnicos usados en la ingeniera del software

Soporte de sistemas general

Marcos de trabajo para otras herramientas

La automatizacin ayuda a eliminar el tedio del trabajo, reduce las posibilidades de errores,y hace ms fcil usar buenas prcticas de ingeniera del software. Cuando se usanherramientas, la documentacin se convierte en una parte integral del trabajo hecho, en vezde ser una actividad adicional. De ah que la documentacin no se tenga que realizar comoactividad adicional. Las herramientas se pueden utilizar para realizar actividades de gestin

de proyecto as como para actividades tcnicas.



23/83

Existen una gran variedad de herramientas para mltiples actividades. Entre ellas se pueden

destacar las siguientes: Herramientas de gestin de proyectos

Herramientas de control de cambios

Herramientas de anlisis y diseo

Herramientas de generacin de cdigo

Herramientas de pruebas

Herramientas de reingeniera

Herramientas de documentacin

Herramientas de prototipos

Estas herramientas soportan las capas de proceso y de mtodos en varias actividades.



24/83

3. CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE

3.1. CICLOS DE VIDA

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se estdesarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado(muere). Tambin se denomina a veces paradigma.

Entre las funciones que debe tener un ciclo de vida se pueden destacar:

Determinar el orden de las fases del proceso de software

Establecer los criterios de transicin para pasar de una fase a la siguiente

Definir las entradas y salidas de cada fase

Describir los estados por los que pasa el producto

Describir las actividades a realizar para transformar el producto

Definir un esquema que sirve como base para planificar, organizar, coordinar,desarrollar

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareasque se pueden planificar. Segn el modelo de ciclo de vida, la sucesin de fases puedeampliarse con bucles de realimentacin, de manera que lo que conceptualmente se

considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto,recibiendo en cada pasada de ejecucin aportaciones a los resultados intermedios que sevan produciendo (realimentacin).

Fases: una fase es un conjunto de actividades relacionadas con un objetivo en eldesarrollo del proyecto. Se construye agrupando tareas (actividades elementales)que pueden compartir un tramo determinado del tiempo de vida de un proyecto. Laagrupacin temporal de tareas impone requisitos temporales correspondientes a laasignacin de recursos (humanos, financieros o materiales).

Entregables: son los productos intermedios que generan las fases. Pueden sermateriales o inmateriales (documentos, software). Los entregables permiten evaluar

la marcha del proyecto mediante comprobaciones de su adecuacin o no a losrequisitos funcionales y de condiciones de realizacin previamente establecidos.

3.1.1. Tipos de modelo de cic lo de vida

Las principales diferencias entre distintos modelos de ciclo de vida estn en:

El alcance del ciclo dependiendo de hasta dnde llegue el proyecto correspondiente.Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de unproducto, o su desarrollo completo o en el extremo, toda la historia del producto consu desarrollo, fabricacin y modificaciones posteriores hasta su retirada del mercado.



25/83

Las caractersticas (contenidos) de las fases en que dividen el ciclo. Esto puede

depender del propio tema al que se refiere el proyecto, o de la organizacin. La estructura y la sucesin de las etapas, si hay realimentacin entre ellas, y si

tenemos libertad de repetirlas (iterar).

3.2. MODELOS DE CICLO DE VIDA

La ingeniera del software establece y se vale de una serie de modelos que establecen ymuestran las distintas etapas y estados por los que pasa un producto software, desde suconcepcin inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento,hasta la retirada del producto. A estos modelos se les denomina Modelos de ciclo de vida

del software. El primer modelo concebido fue el de Royce, ms comnmente conocidocomo Cascada o Lineal Secuencial. Este modelo establece que las diversas actividadesque se van realizando al desarrollar un producto software, se suceden de forma lineal.

Los modelos de ciclo de vida del software describen las fases del ciclo de software y elorden en que se ejecutan las fases.

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren duranteel desarrollo de software, intenta determinar el orden de las etapas involucradas y loscriterios de transicin asociados entre estas etapas.

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software Define las fases primarias esperadas de ser ejecutadas durante esas fases

Ayuda a administrar el progreso del desarrollo

Provee un espacio de trabajo para la definicin de un proceso detallado de desarrollode software

En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una seriede objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo devida, y la eleccin de un modelo para un determinado tipo de proyecto es realmenteimportante; el orden es uno de estos puntos importantes.

Existen varias alternativas de modelos de ciclo de vida. A continuacin se muestran algunosde los modelos tradicionales y ms utilizados.

3.2.1. Modelo en cascada

Es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida delsoftware, de forma que el inicio de cada etapa debe esperar a la finalizacin de lainmediatamente anterior.

El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se vefluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida.



26/83

Se cree que el modelo en cascada fue el primer modelo de proceso introducido y seguido

ampliamente en la ingeniera el software. La innovacin estuvo en la primera vez que laingeniera del software fue dividida en fases separadas.

La primera descripcin formal del modelo en cascada se cree que fue en un artculopublicado en 1970 por Winston W. Royce, aunque Royce no us el trmino cascada en esteartculo. Irnicamente, Royce estaba presentando este modelo como un ejemplo de modeloque no funcionaba, defectuoso.

En el modelo original de Royce, existan las siguientes fases:

1. Especificacin de requisitos

2. Diseo

3. Construccin (Implementacin o codificacin)

4. Integracin

5. Pruebas

6. Instalacin

7. Mantenimiento

Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una formapuramente secuencial.

REQUISITOS

DISEO

IMPLEMENTACIN

PRUEBAS

MANTENIMIENTO

Figura 3. Modelo de ciclo de vida en cascada

Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendoel paradigma ms seguido a da de hoy.



27/83

3.2.1.1. Ventajas

El modelo en cascada puede ser apropiado, en general, para proyectos estables(especialmente los proyectos con requisitos no cambiantes) y donde es posible y probableque los diseadores predigan totalmente reas de problema del sistema y produzcan undiseo correcto antes de que empiece la implementacin. Funciona bien para proyectospequeos donde los requisitos estn bien entendidos.

Es un modelo en el que todo est bien organizado y no se mezclan las fases. Es simple yfcil de usar.

Debido a la rigidez del modelo es fcil de gestionar ya que cada fase tiene entregablesespecficos y un proceso de revisin. Las fases son procesadas y completadas de una vez.

3.2.1.2. Inconvenientes

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una malaimplementacin del modelo, lo cual hace que lo lleve al fracaso.

Difcilmente un cliente va a establecer al principio todos los requisitos necesarios, por lo queprovoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y nopermite movilizarse entre fases.

Los resultados y/o mejoras no son visibles progresivamente, el producto se ve cuando yaest finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir

viendo los avances en el producto. Esto tambin implica el tener que tratar con requisitosque no se haban tomado en cuenta desde el principio, y que surgieron al momento de laimplementacin, lo cual provocar que haya que volver de nuevo a la fase de requisitos.

Hay muchas personas que argumentan que es una mala idea en la prctica, principalmentea causa de su creencia de que es imposible, para un proyecto no trivial, conseguir tener unafase del ciclo de vida del producto software perfecta antes de moverse a las siguientesfases. Por ejemplo, los clientes pueden no ser conscientes exactamente de los requisitosque quieren antes de ver un prototipo del trabajo; pueden cambiar los requisitosconstantemente, y los diseadores e implementadores pueden tener poco control sobreesto. Si los clientes cambian sus requisitos despus de que el diseo est terminado, estediseo deber ser modificado para acomodarse a los nuevos requisitos, invalidando unabuena parte del esfuerzo.

Muchas veces se considera un modelo pobre para proyectos complejos, largos, orientados aobjetos y por supuesto en aquellos en los que los requisitos tengan un riesgo de moderado aalto de cambiar. Genera altas cantidades de riesgos e incertidumbres.

3.2.1.3. Variantes

Existen muchas variantes de este modelo. En respuesta a los problemas percibidos con elmodelo en cascada puro, se introdujeron muchos modelos de cascada modificados. Estosmodelos pueden solventar algunas o todas las crticas del modelo en cascada puro.

De hecho muchos de los modelos utilizados tienen su base en el modelo en cascada.



28/83

Uno de estos modelos modificados es el modelo Sashimi.

El modelo sashimi (llamado as porque tiene fases solapadas, como el pescado japonssashimi) fue creado originalmente por Peter DeGrace. A veces se hace referencia a l comoel modelo en cascada con fases superpuestas o el modelo en cascada conretroalimentacin. Ya que las fases en el modelo sashimi se superponen, lo que implica quese puede actuar durante las etapas anteriores. Por ejemplo, ya que las fases de diseo eimplementacin se superpondrn en el modelo sashimi, los problemas de implementacinse pueden descubrir durante las fases de diseo e implementacin del proceso dedesarrollo. Esto ayuda a aliviar muchos de los problemas asociadas con la filosofa delmodelo en cascada.

3.2.2. Modelo en VEl modelo en v se desarroll para terminar con algunos de los problemas que se vieronutilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontradosdemasiado tarde en el ciclo de vida, ya que las pruebas no se introducan hasta el final delproyecto. El modelo en v dice que las pruebas necesitan empezarse lo ms pronto posibleen el ciclo de vida. Tambin muestra que las pruebas no son slo una actividad basada enla ejecucin. Hay una variedad de actividades que se han de realizar antes del fin de la fasede codificacin. Estas actividades deberan ser llevadas a cabo en paralelo con lasactividades de desarrollo, y los tcnicos de pruebas necesitan trabajar con losdesarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y

tareas y producir una serie de entregables de pruebas. Los productos de trabajo generadospor los desarrolladores y analistas de negocio durante el desarrollo son las bases de laspruebas en uno o ms niveles. El modelo en v es un modelo que ilustra cmo lasactividades de prueba (verificacin y validacin) se pueden integrar en cada fase del ciclo devida. Dentro del modelo en v, las pruebas de validacin tienen lugar especialmente durantelas etapas tempranas, por ejemplo, revisando los requisitos de usuario y despus porejemplo, durante las pruebas de aceptacin de usuario.

El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo delciclo de vida de un proyecto. Describe las actividades y resultados que han de serproducidos durante el desarrollo del producto. La parte izquierda de la v representa la

descomposicin de los requisitos y la creacin de las especificaciones del sistema. El ladoderecho de la v representa la integracin de partes y su verificacin. V significa Validacin yVerificacin.



29/83

INGENIERADE

REQUISITOS

DISEO DELSISTEMA

DISEO DEL

SOFTWARE

CODIFICACIN

VERIFICACIN

DELSOFTWARE

VERIFICACINDEL SISTEMA

VALIDACINDEL SISTEMA

Validar requisito s

Verificardiseo

Figura 4. Modelo de ciclo de vida en V

Realmente las etapas individuales del proceso pueden ser casi las mismas que las delmodelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de unaforma lineal las fases del proceso vuelven hacia arriba tras la fase de codificacin, formando

una v. La razn de esto es que para cada una de las fases de diseo se ha encontrado quehay un homlogo en las fases de pruebas que se correlacionan.

3.2.2.1. Ventajas

Las ventajas que se pueden destacar de este modelo son las siguientes:

Es un modelo simple y fcil de utilizar.

En cada una de las fases hay entregables especficos.

Tiene una alta oportunidad de xito sobre el modelo en cascada debido al desarrollode planes de prueba en etapas tempranas del ciclo de vida.

Es un modelo que suele funcionar bien para proyectos pequeos donde losrequisitos son entendidos fcilmente.


Entre los inconvenientes y las crticas que se le hacen a este modelo estn las siguientes:

Es un modelo muy rgido, como el modelo en cascada.

Tiene poca flexibilidad y ajustar el alcance es difcil y caro.

El software se desarrolla durante la fase de implementacin, por lo que no se

producen prototipos del software.



30/83

El modelo no proporciona caminos claros para problemas encontrados durante las

fases de pruebas

3.2.3. Modelo iterativo

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgoque surge entre las necesidades del usuario y el producto final por malos entendidosdurante la etapa de recogida de requisitos.

Consiste en la iteracinde varios ciclos de vida en cascada. Al final de cada iteracin se leentrega al cliente una versin mejorada o con mayores funcionalidades del producto. Elcliente es quien despus de cada iteracin evala el producto y lo corrige o propone

mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga lasnecesidades del cliente.

ANL ISIS

DISEO

CODIFICACIN

PRUEBAS

ANLISIS

DISEO

CODIFICACIN

PRUEBAS

AN LISIS

DISEO

CODIFICACIN

PRUEBAS

Versin 1 Versin 3Versin 2

Figura 5. Modelo de ciclo de vida iterativo

Este modelo se suele utilizar en proyectos en los que los requisitos no estn claros por partedel usuario, por lo que se hace necesaria la creacin de distintos prototipos parapresentarlos y conseguir la conformidad del cliente.

3.2.3.1. Ventajas

Una de las principales ventajas que ofrece este modelo es que no hace falta que losrequisitos estn totalmente definidos al inicio del desarrollo, sino que se pueden ir refinandoen cada una de las iteraciones.

Igual que otros modelos similares tiene las ventajas propias de realizar el desarrollo enpequeos ciclos, lo que permite gestionar mejor los riesgos, gestionar mejor las entregas



31/83


La primera de las ventajas que ofrece este modelo, el no ser necesario tener los requisitosdefinidos desde el principio, puede verse tambin como un inconveniente ya que puedensurgir problemas relacionados con la arquitectura.

3.2.4. Modelo de desarrollo incremental

El modelo incremental combina elementos del modelo en cascada con la filosofa interactivade construccin de prototipos. Se basa en la filosofa de construir incrementando lasfuncionalidades del programa. Este modelo aplica secuencias lineales de forma escalonadamientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento

del software.

ANL ISIS

DISEO

CODIFICACIN

PRUEBAS

ANLISIS

DISEO

CODIFICACIN

PRUEBAS

AN LISIS

DISEO

CODIFICACIN

PRUEBAS

1 1 2 1 2 3

Figura 6. Modelo de ciclo de vida incremental

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un productoesencial, slo con los requisitos bsicos. Este modelo se centra en la entrega de unproducto operativo con cada incremento. Los primeros incrementos son versiones

incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa ytambin una plataforma para la evaluacin.

3.2.4.1. Ventajas

Entre las ventajas que puede proporcionar un modelo de este tipo encontramos lassiguientes:

Mediante este modelo se genera software operativo de forma rpida y en etapastempranas del ciclo de vida del software.

Es un modelo ms flexible, por lo que se reduce el coste en el cambio de alcance y

requisitos.



32/83

Es ms fcil probar y depurar en una iteracin ms pequea.

Es ms fcil gestionar riesgos.

Cada iteracin es un hito gestionado fcilmente


Para el uso de este modelo se requiere una experiencia importante para definir losincrementos y distribuir en ellos las tareas de forma proporcionada.

Entre los inconvenientes que aparecen en el uso de este modelo podemos destacar lossiguientes:

Cada fase de una iteracin es rgida y no se superponen con otras. Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los

requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio.

3.2.5. Modelo en espiral

El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en1985, utilizado de forma generalizada en la ingeniera del software. Las actividades de estemodelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Lasactividades no estn fijadas a priori, sino que las siguientes se eligen en funcin del anlisisde riesgos, comenzando por el bucle anterior.

Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin deesfuerzos y tiempo que se consume en hacer productos software; y modelos de ciclo devida, ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: elModelo Evolutivo Espiral. Su modelo de ciclo de vida en espiral tiene en cuenta fuertementeel riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando lasposibles alternativas de desarrollo, se opta por la de riesgos ms asumibles y se hace unciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelven aevaluar las nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta quellegue un momento en el que el producto software desarrollado sea aceptado y no necesiteseguir mejorndose con otro nuevo ciclo.

Este modelo de desarrollo combina las caractersticas del modelo de prototipos y el modeloen cascada. El modelo en espiral est pensado para proyectos largos, caros y complicados.

Esto modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer modelo enexplicar las iteraciones.

Este modelo fue propuesto por Boehm en 1988 en su artculo A Spiral Model of SoftwareDevelopment and Enhancement. Bsicamente consiste en una serie de ciclos que serepiten en forma de espiral, comenzando desde el centro. Se suele interpretar como quedentro de cada ciclo de la espiral se sigue un modelo en cascada, pero no necesariamenteha de ser as.



33/83

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por

ejemplo, la creacin de un sistema operativo.Al ser un modelo de ciclo de vida orientado a la gestin de riesgos se dice que uno de losaspectos fundamentales de su xito radica en que el equipo que lo aplique tenga lanecesaria experiencia y habilidad para detectar y catalogar correctamente riesgos.

Tareas:

Para cada ciclo habr cuatro actividades:

1. Determinar o fijar objetivos:

a. Fijar tambin los productos definidos a obtener: requerimientos,especificacin, manual de usuario.

b. Fijar las restricciones

c. Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos

d. Hay una cosa que solo se hace una vez: planificacin inicial o previa

2. Anlisis del riesgo:

a. Se estudian todos los riesgos potenciales y se seleccionan una o variasalternativas propuestas para reducir o eliminar los riesgos

3. Desarrollar, verificar y validar (probar):

a. Tareas de la actividad propia y de pruebab. Anlisis de alternativas e identificacin de resolucin de riesgos

c. Dependiendo del resultado de la evaluacin de riesgos, se elige un modelopara el desarrollo, que puede ser cualquiera de los otros existentes, comoformal, evolutivo, cascada, etc. As, por ejemplo, si los riesgos de la interfazde usuario son dominantes, un modelo de desarrollo apropiado podra ser laconstruccin de prototipos evolutivos.

4. Planificar:

a. Revisamos todo lo que hemos hecho, evalundolo y con ello decidimos si

continuamos con las fases siguientes y planificamos la prxima actividad.El proceso empieza en la posicin central. Desde all se mueve en el sentido de las agujasdel reloj.



34/83

DETERMINAROBJETIVOS EVALUARRIESGOS

PLANIFICARDESARROLLAR

Y PROBAR

Figura 7. Ciclo de vida en espiral

Las cuatro regiones del grfico son:

La tarea de planificacin: para definir recursos, responsabilidades, hitos yplanificaciones

La tarea de determinacin de objetivos: para definir los requisitos y las restriccionespara el producto y definir las posibles alternativas

La tarea de anlisis de riesgos: para evaluar riesgos tanto tcnicos como de gestin

La tarea de ingeniera: para disear e implementar uno o ms prototipos o ejemplosde la aplicacin

3.2.5.1. Ventajas

El anlisis de riesgos se hace de forma explcita y clara. Une los mejores elementos de losrestantes modelos. Entre ellos:

Reduce riesgos del proyecto

Incorpora objetivos de calidad

Integra el desarrollo con el mantenimiento

Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con elmodelo, ya que el ciclo de vida no es rgido ni esttico.

Mediante este modelo se produce software en etapas tempranas del ciclo de vida y sueleser adecuado para proyectos largos de misin crtica.


Es un modelo que genera mucho trabajo adicional. Al ser el anlisis de riesgos una de lastareas principales exige un alto nivel de experiencia y cierta habilidad en los analistas deriesgos (es bastante difcil).



35/83

Esto puede llevar a que sea un modelo costoso. Adems, no es un modelo que funcione

bien para proyectos pequeos.

3.2.5.3. Comparacin con otros modelos

La distincin ms destacada entre el modelo en espiral y otros modelos de software es latarea explcita de evaluacin de riesgos. Aunque la gestin de riesgos es parte de otrosprocesos tambin, no tiene una representacin propia en el modelo de proceso. Para otrosmodelos la evaluacin de riesgos es una subtarea, por ejemplo, de la planificacin y gestinglobal. Adems no hay fases fijadas para la especificacin de requisitos, diseo y pruebasen el modelo en espiral. Se puede usar prototipado para encontrar y definir los requisitos.

La diferencia entre este modelo y el modelo de ciclo incremental es que en el incremental separte de que no hay incertidumbre en los requisitos iniciales; en este, en cambio, se esconsciente de que se comienza con un alto grado de incertidumbre. En el incrementalsuponemos que conocemos el problema y lo dividimos. Este modelo gestiona laincertidumbre.

3.2.6. Modelo de Protot ipos

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero noidentifica los requisitos detallados de entrada, proceso o salida. En otros casos, elresponsable del desarrollo del software puede no estar seguro de la eficiencia de un

algoritmo, de la calidad de adaptacin de un sistema operativo, o de la forma en que deberatomarse la interaccin hombre-mquina. En estas y en otras muchas situaciones, unparadigma de construccin de prototipos puede ofrecer el mejor enfoque.

El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. Eldesarrollador y el cliente encuentran y definen los objetivos globales para el software,identifican los requisitos conocidos y las reas del esquema en donde es obligatoria msdefinicin. Entonces aparece un diseo rpido. El diseo rpido se centra en unarepresentacin de esos aspectos del software que sern visibles para el usuario/cliente. Eldiseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el cliente/usuarioy se utiliza para refinar los requisitos del software a desarrollar. La iteracin ocurre cuando elprototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismotiempo que el desarrollador comprenda mejor lo que se necesita hacer.



36/83

ESCUCHAR ALCLIENTE

CONSTRUIR/REVISAR LAMAQUETA

EL CLIENTEPRUEBA LAMAQUETA

Figura 8. Modelo de ciclo de vida de prototipos

3.2.6.1. Ventajas

Entre las ventajas que ofrece este modelo se pueden destacar las siguientes:

Ofrece visibilidad del producto desde el inicio del ciclo de vida con el primer prototipo. Estopuede ayudar al cliente a definir mejor los requisitos y a ver las necesidades reales delproducto. Permite introducir cambios en las iteraciones siguientes del ciclo. Permite larealimentacin continua del cliente.

El prototipo es un documento vivo de buen funcionamiento del producto final. El clientereacciona mucho mejor ante el prototipo, sobre el que puede experimentar, que no sobreuna especificacin escrita.

Este modelo reduce el riesgo de construir productos que no satisfagan las necesidades delos usuarios.

3.2.6.2. InconvenientesEntre los inconvenientes que se han observado con este modelo est el hecho de quepuede ser un desarrollo lento. Adems se hacen fuertes inversiones en un productodesechable ya que los prototipos se descartan. Esto puede hacer que aumente el coste dedesarrollo del producto.

Con este modelo pueden surgir problemas con el cliente que ve funcionando versiones delprototipo pero puede desilusionarse porque el producto final an no ha sido construido. Eldesarrollador puede caer en la tentacin de ampliar el prototipo para construir el sistemafinal sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con elcliente.



37/83

3.3. ISO/IEC 12207

Esta norma establece un marco de referencia comn para los procesos del ciclo de vida delsoftware, con una terminologa bien definida a la que puede hacer referencia la industria delsoftware. Contiene procesos, actividades y tareas para aplicar durante la adquisicin de unsistema que contiene software, un producto software puro o un servicio software, y duranteel suministro, desarrollo, operacin y mantenimiento de productos software. El softwareincluye la parte software del firmware.

Esta norma incluye tambin un proceso que puede emplearse para definir, controlar ymejorar los procesos del ciclo de vida del software.

La ISO 12207 define un modelo de ciclo de vida como un marco de referencia que

contiene los procesos, actividades y tareas involucradas en el desarrollo, operacin ymantenimiento de un producto software, y que abarca toda la vida del sistema, desde ladefinicin de sus requisitos hasta el final del uso.

Esta norma agrupa las actividades que pueden llevarse a cabo durante el ciclo de vida delsoftware en cinco procesos principales, ocho procesos de apoyo y cuatro procesosorganizativos. Cada proceso del ciclo de vida est dividido en un conjunto de actividades;cada actividad se subdivide a su vez en un conjunto de tareas.

Procesos principales del ciclo de vida: son cinco procesos que dan servicio a laspartes principales durante el ciclo de vida del software. Una parte principal es la queinicia o lleva a cabo el desarrollo, operacin y mantenimiento de productos software.

Los procesos principales son:

o Proceso de adquisicin

o Proceso de suministro

o Proceso de desarrollo

o Proceso de operacin

o Proceso de mantenimiento

Procesos de apoyo al ciclo de vida: son procesos que apoyan a otros procesoscomo parte esencial de los mismos, con un propsito bien definido, y contribuyen al

xito y calidad del proyecto software. Un proceso de apoyo se emplea y ejecuta porotro proceso segn sus necesidades.

Los procesos de apoyo son:

o Proceso de documentacin

o Proceso de gestin de la configuracin

o Proceso de verificacin

o Proceso de validacin

o Proceso de revisiones conjuntas

o Proceso de auditora



38/83

o Proceso de solucin de problemas

Procesos organizativos del ciclo de vida: se emplean por una organizacin paraestablecer e implementar una infraestructura construida por procesos y personalasociado al ciclo de vida, y para mejorar continuamente esta estructura y procesos.

o Proceso de gestin

o Proceso de infraestructura

o Proceso de mejora

o Proceso de formacin



39/83

4. METODOLOGAS DE DESARROLLO DE SOFTWAREEl desarrollo de software no es una tarea fcil. Prueba de ello es que existen numerosaspropuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo.Por una parte tenemos aquellas propuestas ms tradicionales que se centran especialmenteen el control del proceso, estableciendo rigurosamente las actividades involucradas, losartefactos que se deben producir, y las herramientas y notaciones que se usarn. Estaspropuestas han demostrado ser efectivas y necesarias en un gran nmero de proyectos,pero tambin han presentado problemas en muchos otros. Una posible mejora es incluir enlos procesos de desarrollo ms actividades, ms artefactos y ms restricciones, basndoseen los puntos dbiles detectados. Sin embargo, el resultado final sera un proceso de

desarrollo ms complejo que puede incluso limitar la propia habilidad del equipo para llevara cabo el proyecto. Otra aproximacin es centrarse en otras dimensiones, como por ejemploel factor humano o el producto software. Esta es la filosofa de las metodologas giles, lascuales dan mayor valor al individuo, a la colaboracin con el cliente y al desarrolloincremental del software con iteraciones muy cortas. Este enfoque est mostrando suefectividad en proyectos con requisitos muy cambiantes y cuando se exige reducirdrsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Lasmetodologas giles estn revolucionando la manera de producir software, y a la vezgenerando un amplio debate entre sus seguidores y quienes por escepticismo oconvencimiento no las ven como alternativa para las metodologas tradicionales.

Un objetivo de dcadas ha sido encontrar procesos y metodologas, que sean sistemticas,predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad delproducto software.

La evolucin de la disciplina de ingeniera del software ha trado consigo propuestasdiferentes para mejorar los resultados del proceso de construccin. Las metodologastradicionales haciendo nfasis en la planificacin y las metodologas giles haciendo nfasisen la adaptabilidad del proceso, delinean las principales propuestas presentes.

4.1. DEFINICIN DE METODOLOGA

Una metodologa es un conjunto integrado de tcnicas y mtodos que permite abordar deforma homognea y abierta cada una de las actividades del ciclo de vida de un proyecto dedesarrollo. Es un proceso de software detallado y completo.

Las metodologas se basan en una combinacin de los modelos de proceso genricos(cascada, incremental). Definen artefactos, roles y actividades, junto con prcticas ytcnicas recomendadas.

La metodologa para el desarrollo de software en un modo sistemtico de realizar, gestionary administrar un proyecto para llevarlo a cabo con altas posibilidades de xito. Unametodologa para el desarrollo de software comprende los procesos a seguirsistemticamente para idear, implementar y mantener un producto software desde que

surge la necesidad del producto hasta que cumplimos el objetivo por el cual fue creado.



40/83

Una definicin estndar de metodologa puede ser el conjunto de mtodos que se utilizan en

una determinada actividad con el fin de formalizarla y optimizarla. Determina los pasos aseguir y cmo realizarlos para finalizar una tarea.

Si esto se aplica a la ingeniera del software, podemos destacar que una metodologa:

Optimiza el proceso y el producto software.

Mtodos que guan en la planificacin y en el desarrollo del software.

Define qu hacer, cmo y cundo durante todo el desarrollo y mantenimiento de unproyecto.

Una metodologa define una estrategia global para enfrentarse con el proyecto. Entre los

elementos que forman parte de una metodologa se pueden destacar:

Fases: tareas a realizar en cada fase.

Productos: E/S de cada fase, documentos.

Procedimientos y herramientas: apoyo a la realizacin de cada tarea.

Criterios de evaluacin: del proceso y del producto. Saber si se han logrado losobjetivos.

Una metodologa de desarrollo de software es un marco de trabajo que se usa paraestructurar, planificar y controlar el proceso de desarrollo de sistemas de informacin. Una

gran variedad de estos marcos de trabajo han evolucionado durante los aos, cada uno consus propias fortalezas y debilidades. Una metodologa de desarrollo de sistemas no tieneque ser necesariamente adecuada para usarla en todos los proyectos. Cada una de lasmetodologas disponibles es ms adecuada para tipos especficos de proyectos, basados enconsideraciones tcnicas, organizacionales, de proyecto y de equipo.

Una metodologa de desarrollo de software o metodologa de desarrollo de sistemas eningeniera de software es un marco de trabajo que se usa para estructurar, planificar ycontrolar el proceso de desarrollo de un sistema de informacin.

El marco de trabajode una metodologa de desarrollo de software consiste en:

Una filosofa de desarrollo de software, con el enfoque o enfoques del proceso dedesarrollo de software.

Mltiples herramientas, modelos y mtodos para ayudar en el proceso de desarrollode software.

Estos marcos de trabajo estn con frecuencia vinculados a algunos tipos de organizaciones,que se encargan del desarrollo, soporte de uso y promocin de la metodologa. Lametodologa con frecuencia se documenta de alguna manera formal.



41/83

4.2. VENTAJAS DEL USO DE UNA METODOLOGA

Son muchas las ventajas que puede aportar el uso de una metodologa. A continuacin sevan a exponer algunas de ellas, clasificadas desde distintos puntos de vista.

Desde el punto de vista de gestin:

Facilitar la tarea de planificacin

Facilitar la tarea del control y seguimiento de un proyecto

Mejorar la relacin coste/beneficio

Optimizar el uso de recursos disponibles

Facilitar la evaluacin de resultados y cumplimiento de los objetivos Facilitar la comunicacin efectiva entre usuarios y desarrolladores

Desde el punto de vista de los ingenieros del software:

Ayudar a la comprensin del problema

Optimizar el conjunto y cada una de las fases del proceso de desarrollo

Facilitar el mantenimiento del producto final

Permitir la reutilizacin de partes del producto

Desde el punto de vista del cliente o usuario:

Garanta de un determinado nivel de calidad en el producto final

Confianza en los plazos de tiempo fijados en la definicin del proyecto

Definir el ciclo de vida que ms se adecue a las condiciones y caractersticas deldesarrollo

4.3. METODOLOGAS TRADICIONALES Y GILES

Desarrollar un buen software depende de un gran nmero de actividades y etapas, donde elimpacto de elegir la metodologa para un equipo en un determinado proyecto es

trascendental para el xito del producto.Segn la filosofa de desarrollo se pueden clasificar las metodologas en dos grupos. Lasmetodologas tradicionales, que se basan en una fuerte planificacin durante todo eldesarrollo, y las metodologas giles, en las que el desarrollo de software es incremental,cooperativo, sencillo y adaptado.

Metodologas tradicionales

Las metodologas tradicionales son denominadas, a veces, de forma peyorativa, comometodologas pesadas.



42/83

Centran su atencin en llevar una documentacin exhaustiva de todo el proyecto y en

cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo delproyecto.

Otra de las caractersticas importantes dentro de este enfoque, son los altos costes alimplementar un cambio y la falta de flexibilidad en proyectos donde el entorno es voltil.

Las metodologas tradicionales (formales) se focalizan en la documentacin, planificacin yprocesos (plantillas, tcnicas de administracin, revisiones, etc.)

Metodologas giles

Este enfoque nace como respuesta a los problemas que puedan ocasionar las metodologastradicionales y se basa en dos aspectos fundamentales, retrasar las decisiones y laplanificacin adaptativa. Basan su fundamento en la adaptabilidad de los procesos dedesarrollo.

Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio es msimportante que el seguimiento estricto de un plan.

Metodologas giles o metodologas tradicionales?

En las metodologas tradicionales el principal problema es que nunca se logra planificar bienel esfuerzo requerido para seguir la metodologa. Pero entonces, si logramos definirmtricas que apoyen la estimacin de las actividades de desarrollo, muchas prcticas demetodologas tradicionales podran ser apropiadas. El no poder predecir siempre los

resultados de cada proceso no significa que estemos frente a una disciplina de azar. Lo quesignifica es que estamos frente a la necesidad de adaptacin de los procesos de desarrolloque son llevados por parte de los equipos que desarrollan software.

Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se desarrolleresulta una idea interesante. Estas metodologas pueden involucrar prcticas tanto demetodologas giles como de metodologas tradicionales. De esta manera podramos teneruna metodologa por cada proyecto, la problemtica sera definir cada una de las prcticas,y en el momento preciso definir parmetros para saber cul usar.

Es importante tener en cuenta que el uso de un mtodo gil no vale para cualquier proyecto.Sin embargo, una de las principales ventajas de los mtodo

guia de ingenieria del software

Documents

tipos de software

software deinteco

software 483ndice1

ciclos de vida

metodologas de desarrollo

tipos de modelo

modelo iterativo

ciclo de vida