UNIDAD 2 METODOLOGAS

DE DESARROLLO DE
SOFTWARE
2.1 METODOLOGA DE DESARROLLO DE SOFTWARE
Metodologa de desarrollo de software en ingeniera de software es un marco
de trabajo usado para estructurar, planificar y controlar el proceso de
desarrollo en sistemas de informacin.
Una metodologa de desarrollo de software se refiere a un framework que es
usado para estructurar, planear y controlar el proceso de desarrollo en sistemas
de informacin.
A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados
diferencindose por su fortaleza y debilidad.
El framework para metodologa de desarrollo de software consiste en:
Una filosofa de desarrollo de programas de computacion con el enfoque
del proceso de desarrollo de software
Herramientas, modelos y mtodos para asistir al proceso de desarrollo de
software
Estos frameworks son a menudo vinculados a algn tipo de organizacin, que
adems desarrolla, apoya el uso y promueve la metodologa. La metodologa
es a menudo documentada en algn tipo de documentacin formal.
2.1.1 MODELO DE CASCADA

En Ingeniera de software el desarrollo en cascada, tambin llamado modelo
en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas
del proceso para el desarrollo de software, de tal forma que el inicio de cada
etapa debe esperar a la finalizacin de la etapa anterior.
Llamado tambin Lineal secuencial. Proporciona una simple visin del
desarrollo del Software. A los procesos los representa como fases separadas y
secuenciales en tiempo.
Antes de codificar debemos disear el software, adems probarlo antes de
construirlo y ponerlo en operacin.
Un ejemplo de una metodologa de desarrollo en cascada es:
1. Anlisis de requisitos.
2. Diseo del Sistema.
3. Diseo del Programa.
4. Codificacin.
5. Pruebas.
6. Implantacin.
7. Mantenimiento.
De esta forma, cualquier error de diseo detectado en la etapa de prueba
conduce necesariamente al rediseo y nueva programacin del cdigo
afectado, aumentando los costos del desarrollo. La palabra cascada sugiere,
mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para
introducir un cambio en las fases ms avanzadas de un proyecto.
Si bien ha sido ampliamente criticado desde el mbito acadmico y la
industria, sigue siendo el paradigma ms seguido al da de hoy.
VENTAJAS DEL MODELO CASCADA
1. Modelo y planificacin fcil y sencilla.
2. Sus fases son conocidas por los desarrolladores.
3. Los usuarios lo pueden comprender fcilmente.
DESVENTAJAS DEL MODELO CASCADA
1. Alto riesgo en sistemas nuevos debido a problemas en las especificaciones
y en el diseo.
2. Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa
conocida.
2.1.2 MODELO INCREMENTAL

El Modelo Incremental combina elementos del MLS con la filosofa interactiva
de construccin de prototipos.
En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo
y Prueba. Sin embargo, para la produccin del Software, se usa el principio de
trabajo en cadena o Pipeline, utilizado en muchas otras formas de
programacin. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada
incremento a fin de que el software se adapte mejor a sus necesidades reales.
El proceso se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros mtodos de modelado, el Modelo Incremental es de
naturaleza interactiva pero se diferencia de aquellos en que al final de cada
incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente til cuando no se cuenta con una
dotacin de personal suficiente. Los primeros pasos los pueden realizar un
grupo reducido de personas y en cada incremento se aadir personal, de ser
necesario. Por otro lado los incrementos se pueden planear para gestionar
riesgos tcnicos.
El Modelo Incremental se puede ver aqu en forma grfica:
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia.
- El usuario se involucra ms.
- Difcil de evaluar el coste total.
- Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y
a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya
que se implementa la funcionalidad parcial.
- Tambin provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del Software.
- El modelo proporciona todas las ventajas del modelo en cascada
realimentado, reduciendo sus desventajas slo al mbito de cada incremento.
- Permite entregar al cliente un producto ms rpido en comparacin del
modelo de cascada.
- Resulta ms sencillo acomodar cambios al acotar el tamao de los
incrementos.
- Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel
administrativo como tcnico.
Desventajas:
- El modelo Incremental no es recomendable para casos de sistemas de tiempo
real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto
ndice de riesgos.
- Requiere de mucha planeacin, tanto administrativa como tcnica.
- Requiere de metas claras para conocer el estado del proyecto.
2.1.3 MODELO EVOLUTIVO

Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificacin,
desarrollo y validacin. Un sistema inicial se desarrolla rpidamente a partir de
especificaciones abstractas. ste se refina basndose en las peticiones del
cliente para producir un sistema que satisfaga sus necesidades.
El desarrollo evolutivo consta del desarrollo de una versin inicial que luego de
exponerse se va refinando de acuerdo de los comentarios o nuevos
requerimientos por parte del cliente o del usuario final. Las fases de
especificacin, desarrollo y validacin se entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el
cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo
empieza con las partes del sistema que se comprenden mejor. El sistema
evoluciona agregando nuevos atributos propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo
es comprender los requerimientos del cliente y entonces desarrollar una
definicin mejorada de los requerimientos para el sistema. El prototipo se centra
en experimentar con los requerimientos del cliente que no se comprenden del
todo.
2.1.4 MODELO DE ESPIRAL
El desarrollo en espiral es un modelo de ciclo de vida del software definido por
primera vez por Barry Boehm en 1986,

utilizado generalmente en la Ingeniera de
software. Las actividades de este modelo se conforman en una espiral, en la
que cada bucle o iteracin representa un conjunto de actividades. Las
actividades no estn fijadas a ninguna prioridad, sino que las siguientes se
eligen en funcin del anlisis de riesgo, comenzando por el bucle interior.
Este es un modelo de proceso de software evolutivo, el cual enlaza la
naturaleza iterativa de la construccin de prototipos, pero conservado aquellas
propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe as:
El modelo de desarrollo en espiral es un generador de modelo de proceso
guiado por el riesgo que se emplea para conducir sistemas intensivos de
ingeniera de software concurrente y a la vez con muchos usuarios.
Se caracteriza principalmente por:
- Un enfoque cclico para el crecimiento incremental del grado de definicin
e implementacin de un sistema, mientras que disminuye su grado de riesgo.
- Un conjunto de puntos de fijacin para asegurar el compromiso del usuario
con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral captura algunos principios bsicos:
Decidir qu problema se quiere resolver antes de viajar a resolverlo.
Examinar tus mltiples alternativas de accin y elegir una de las ms
convenientes.
Evaluar qu tienes hecho y qu tienes que haber aprendido despus de
hacer algo.
No ser tan ingenuo para pensar que el sistema que ests construyendo
ser "EL" sistema que el cliente necesita, y
Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son
completamente compatibles.
2.1.5 MODELO DE PROTOTIPOS
El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de
desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando
los programas adecuados y no se debe utilizar muchos recursos.
El diseo rpido se centra en una representacin de aquellos aspectos del
software que sern visibles para el cliente o el usuario final. Este diseo conduce
a la construccin de un prototipo, el cual es evaluado por el cliente para una
retroalimentacin; gracias a sta se refinan los requisitos del software que se
desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer
las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador
entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
Etapas:
Plan rpido
Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, entrega y retroalimentacin
Comunicacin
Ventajas
Este modelo es til cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento
o salida.
Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del
software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de
un sistema operativo o de la forma que debera tomar la interaccin humano-
mquina.
La construccin de prototipos se puede utilizar como un modelo del proceso
independiente, se emplea ms comnmente como una tcnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos del proceso
expuestos. Sin importar la forma en que ste se aplique, el paradigma de
construccin de prototipos ayuda al desarrollador de software y al cliente a
entender de mejor manera cul ser el resultado de la construccin cuando los
requisitos estn satisfechos. De esta manera, este ciclo de vida en particular,
involucra al cliente ms profundamente para adquirir el producto.
Desventajas
El usuario tiende a crearse unas expectativas cuando ve el prototipo de
cara al sistema final. A causa de la intencin de crear un prototipo de forma
rpida, se suelen desatender aspectos importantes, tales como la calidad y el
mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a
reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente que
el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya
el sistema final, lo que lo convertira en un prototipo evolutivo, pero partiendo
de un estado poco recomendado.
En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar
algunas decisiones de implementacin poco convenientes (por ejemplo, elegir
un lenguaje de programacin incorrecto porque proporcione un desarrollo ms
rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn
que le llev a tomar tales decisiones, con lo que se corre el riesgo de que
dichas elecciones pasen a formar parte del sistema final.
2.1.6 DESARROLLO BASADO EN COMPONENTES

La ingeniera de software basada en componentes (CBSE) (tambin conocida
como desarrollo basado en componentes (CBD)) es una rama de la ingeniera
de software que enfatiza la separacin de asuntos (separation of concerns
(SoC)) por lo que se refiere a la funcionalidad de mplio rango disponible a
travs de un sistema de software dado. Es un acercamiento basado en la
reutilizacin para definir, implementar, y componer, componentes dbilmente
acoplados en sistemas. Esta prctica apunta traer igualmente un mplio grado
de beneficios tanto en el corto como el largo plazo, para el software en s
mismo, y para las organizaciones que patrocinan tal software.
Los ingenieros de software consideran los componentes como parte de la
plataforma inicial para la orientacin a servicios. Los componentes juegan este
rol, por ejemplo, en servicios de web, y ms recientemente, en las arquitecturas
orientadas a servicios (SOA), por el que un componente es convertido por el
servicio web en un servicio y subsecuentemente hereda otras caractersticas
ms all de las de un componente ordinario.
Los componentes pueden producir o consumir eventos y pueden ser usados
para las arquitecturas dirigida por eventos (EDA).
Un componente de software individual es un paquete de software, un servicio
web, o un mdulo que encapsula un conjunto de funciones relacionadas (o de
datos).
Todos los procesos del sistema son colocados en componentes separados de
tal manera que todos los datos y funciones dentro de cada componente
estn semnticamente relacionados (justo como con el consentimiento
de clases). Debido a este principio, con frecuencia se dice que los
componentes son modulares y cohesivos.
Con respecto a la coordinacin a lo largo del sistema, los componentes se
comunican uno con el otro por medio de interfaces. Cuando un componente
ofrece servicios al resto del sistema, ste adopta una interface proporcionada
que especifica los servicios que otros componentes pueden utilizar, y cmo
pueden hacerlo. Esta interface puede ser vista como una firma del
componente - el cliente no necesita saber sobre los funcionamientos internos
del componente (su implementacin) para hacer uso de ella. Este principio
resulta en componentes referidos como encapsulados. Las ilustraciones UML de
este artculo representan a las interfaces proporcionadas, con un smbolo
lollipop unido al borde externo del componente.
2.2 OTRAS METODOLOGAS DE DESARROLLO DE SOFTWARE
2.2.1 MODELO GANAR-GANAR
En este tipo de modelo se crea una estrecha relacin cliente-desarrollador,
donde ambos van buscan cual es lo ms conveniente para ambos y de
manera individual, el cliente busca la satisfaccin, reduccin de
costos, acortar los tiempos de entrega y mejoras del sistemas. En cada giro de
esta espiral hay tres puntos claves.
Objetivo del ciclo de Vida (OCV).- se definen los objetivos a alcanzarse
en cada segmento de la espiral.
Arquitectura del ciclo de Vida (ACV).- Una vez definido los objetivos se
establece la manera en cmo se actuara para llevarse a cabo cada uno de
ellos.
La Capacidad operativa Inicial (COI).- Una vez establecidos objetivos y
la forma de atacar cada uno de ellos se lleva la fase de aplicacin y
evaluacin de resultados.
2.2.2 PROCESO UNIFICADO

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es
un marco de desarrollo de software que se caracteriza por estar dirigido
por casos de uso, centrado en la arquitectura y por ser iterativo e incremental.
El refinamiento ms conocido y documentado del Proceso Unificado es
el Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos especficos.
De la misma forma, el Proceso Unificado de Rational, tambin es un marco de
trabajo extensible, por lo que muchas veces resulta imposible decir si un
refinamiento particular del proceso ha sido derivado del Proceso Unificado o
del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un
mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genrico que
incluye aquellos elementos que son comunes a la mayora de los refinamientos
existentes. Tambin permite evitar problemas legales ya que Proceso Unificado
de Rational o RUP son marcas registradas por IBM (desde su compra
de Rational Software Corporationen 2003). El primer libro sobre el tema se
denomin, en su versin espaola, El Proceso Unificado de Desarrollo de
Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady
Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del
UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que
publican libros sobre el tema y que no estn afiliados a Rational utilizan el
trmino Proceso Unificado, mientras que los autores que pertenecen a Rational
favorecen el nombre de Proceso Unificado de Rational.
2.2.3 INGENIERA WEB
La ingeniera web es la aplicacin de metodologas sistemticas, disciplinadas y
cuantificables al desarrollo eficiente, operacin y evolucin de aplicaciones de
alta calidad en la World Wide Web.
1

La ingeniera web se debe al crecimiento desenfrenado que est teniendo la
Web est ocasionando un impacto en la sociedad y el nuevo manejo que se le
est dando a lainformacin en las diferentes reas en que se presenta ha
hecho que las personas tiendan a realizar todas sus actividades por esta va.
Desde que esto empez a suceder el Internet se volvi ms que una diversin y
empez a ser tomado ms en serio, ya que el aumento de publicaciones y de
informaciones hizo que la Web se volviera como un desafo para los (Ingeniera
del software) ingenieros del software, a raz de esto se crearon enfoques
disciplinados, sistemticos y metodologas donde tuvieron en cuenta aspectos
especficos de este nuevo medio.
Uno de los aspectos ms tenidos en cuenta, en el desarrollo de sitios web es sin
duda alguna el diseo grfico y la organizacin estructural del contenido. En la
actualidad la web est sufriendo grandes cambios, que han obligado a
expertos en el tema a utilizar herramientas y tcnicas basadas en la ingeniera
del software, para poder garantizar el buen funcionamiento y administracin
de los sitios web.
Para garantizar el buen funcionamiento y mantenimiento de los sitios web, este
debe contar con ciertos atributos y caractersticas que en conjunto forman un
concepto muy importante, para alcanzar el xito en cualquier organizacin,
herramienta, y todo aquello que se pueda considerar como servicio. Dicho
concepto es la calidad, que con atributos como, usabilidad, navegabilidad,
seguridad, mantenibilidad, entre otros, hace posible por un lado la eficiencia
del artefacto web y por ende la satisfaccin del usuario final.
Pero para tener artefactos de calidad, a esa misma se le debe planificar,
programar y controlar, es decir la calidad no podr ser agregada a un
artefacto web o a cualquier otro producto, al final del proceso de desarrollo, si
no que se deber implementar durante todo el ciclo de vida del desarrollo.
Para finalizar el resultado de un proceso de calidad, podra arrojar
recomendaciones para introducir mejoras, y la decisin final podra consistir en
lanzar una nueva versin del sitio web o en modificar algunos atributos ausentes
o pobremente diseados. Cabe destacar que la ingeniera de la web hace
una diferencia entre un webSite y una aplicacin, ya que la ingeniera de la
web no se dedica a la construccin de sitios web si no a la construccin de
aplicaciones web la principal caracterstica que los distingue (aplicaciones de
sitios web) es que los sitios web son sitios en la web en donde se publica
contenido generalmente esttico o un muy bajo nivel de interactividad con
el usuario, mientras que las aplicaciones son lugares con alto contenido de
interactividad y funcionalidades que bien podran ser de
un software convencional, la aplicacin web ms sencillo seria uno que
contenga formularios y subiendo de nivel encontramos los que realizas
conexin con bases de datos remotas, y administradores de contenidos entre
otras.
Entonces la ingeniera de la Web es la aplicacin de metodologas sistemticas,
disciplinadas y cuantificables al desarrollo eficiente, operacin y evolucin de
aplicaciones de alta calidad en la World Wide Web. En este sentido, la
ingeniera de la Web hace referencia a las metodologas, tcnicas y
herramientas que se utilizan en el desarrollo deaplicaciones Web complejas y
de gran dimensin en las que se apoya la evaluacin, diseo, desarrollo,
implementacin y evolucin de dichas aplicaciones.
2.2.4 METODOLOGAS GILES

El desarrollo gil de software son mtodos de ingeniera del software basados
en el desarrollo iterativo e incremental, donde los requerimientos y soluciones
evolucionan mediante la colaboracin de grupos auto organizados y
multidisciplinarios. Existen muchos mtodos de desarrollo gil; la mayora
minimiza riesgos desarrollando software en lapsos cortos. El software
desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe
durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye:
planificacin, anlisis de requerimientos, diseo, codificacin, revisin y
documentacin. Una iteracin no debe agregar demasiada funcionalidad
para justificar el lanzamiento del producto al mercado, pero la meta es tener
una demo (sin errores) al final de cada iteracin. Al final de cada iteracin el
equipo vuelve a evaluar las prioridades del proyecto.
Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la
documentacin. La mayora de los equipos giles estn localizados en una
simple oficina abierta, a veces llamadas "plataformas de lanzamiento"
(bullpen en ingls). La oficina debe incluir revisores, escritores de
documentacin y ayuda, diseadores de iteracin y directores de proyecto.
Los mtodos giles tambin enfatizan que el software funcional es la primera
medida del progreso. Combinado con la preferencia por las comunicaciones
cara a cara, generalmente los mtodos giles son criticados y tratados como
"indisciplinados" por la falta de documentacin tcnica.