METODOLOGIAS

Unidad 1

29 DE AGOSTO DE 2017
MARCO ANTONIO HIGUERA VALDEZ GRUPO: 502
Profesor: M. Cs. Ral Loredo Medina
ndice
1 Metodologas clsicas.................................................................................. 2

1.1 Modelo de la cascada ........................................................................... 2

1.2 Modelos de proceso incremental .......................................................... 5

1.3 Modelos de proceso evolutivo ............................................................... 8

1.4 El modelo espiral. ................................................................................ 10

1.5 Mtodo de Prototipos .......................................................................... 13

1.6 Desarrollo basado en componentes .................................................... 16

2 Otras metodologas ................................................................................... 19

2.1 Metodologa de ganar-ganar ............................................................... 19

2.2 Proceso Unificado De Desarrollo De Software .................................... 21

2.3 Ingeniera Web .................................................................................... 24

2.4 Metodologias giles ............................................................................ 27

2.5 Metodologas emergentes ................................................................... 31

1 . -Metodologas clsicas

1.1 . -Modelo de la cascada

Hay veces en las que los requerimientos para cierto problema se comprenden
bien: cuando el trabajo desde la comunicacin hasta el despliegue fluye en forma
razonablemente lineal. Esta situacin se encuentra en ocasiones cuando deben
hacerse adaptaciones o mejoras bien definidas a un sistema ya existente (por
ejemplo, una adaptacin para software de contabilidad que es obligatorio hacer
debido a cambios en las regulaciones gubernamentales). Tambin ocurre en
cierto nmero limitado de nuevos esfuerzos de desarrollo, pero slo cuando los
requerimientos estn bien definidos y tienen una estabilidad razonable.

El modelo de la cascada, a veces llamado ciclo de vida clsico, sugiere un

enfoque sistemtico y secuencial6 para el desarrollo del software, que comienza
con la especificacin de los requerimientos por parte del cliente y avanza a travs
de planeacin, modelado, construccin y despliegue, para concluir con el apoyo
del software terminado (vase la figura 2.3). Una variante de la representacin
del modelo de la cascada se denomina modelo en V. En la figura 2.4 se ilustra
el modelo en V [Buc99], donde se aprecia la relacin entre las acciones para el
aseguramiento de la calidad y aquellas asociadas con la comunicacin,
modelado y construccin temprana. A medida que el equipo de software avanza
hacia abajo desde el lado izquierdo de la V, los requerimientos bsicos del
problema mejoran hacia representaciones tcnicas cada vez ms detalladas del
problema y de su solucin.

El aspecto ms importante del modelo de cascada es que ninguno de las etapas

se puede comenz con la fase anterior antes se ha completado. El ciclo de vida
del software tiene que seguir la secuencia. El modelo de cascada original
diseado por Royce consisti en las siguientes siete etapas:

Especificacin de Requisitos
Diseo
Construccin
Integracin
Probar y depurar
Instalacin
Mantenimiento

Diseo del programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento

de los requerimientos del usuario, as como tambin los anlisis necesarios para
saber qu herramientas usar en la etapa de Codificacin.

Codificacin

Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos

as como de pruebas y ensayos para corregir errores.

Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas

y componentes reutilizables dentro del mismo proyecto para hacer que la
programacin sea un proceso mucho ms rpido.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se

comprueba que funciona correctamente y que cumple con los requisitos, antes
de ser entregado al usuario final.
Verificacin

Es la fase en donde el usuario final ejecuta el sistema, para ello el o los

programadores ya realizaron exhaustivas pruebas para comprobar que el
sistema no falle.

Mantenimiento

Una de las etapas ms crticas, ya que se destina un 75 % de los recursos, es el

mantenimiento del software ya que al utilizarlo como usuario final puede ser que
no cumpla con todas nuestras expectativas.

Ventajas

Realiza un buen funcionamiento en equipos dbiles y productos maduros, por lo

que se requiere de menos capital y herramientas para hacerlo funcionar de
manera ptima.

Es un modelo fcil de implementar y entender.

Est orientado a documentos.

Es un modelo conocido y utilizado con frecuencia.

Promueve una metodologa de trabajo efectiva: Definir antes que disear,

disear antes que codificar.

Desventajas

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

El proceso de creacin del software tarda mucho tiempo ya que debe pasar por
el proceso de prueba y hasta que el software no est completo no se opera. Esto
es la base para que funcione bien.

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.

Una etapa determinada del proyecto no se puede llevar a cabo a menos de que
se haya culminado la etapa anterior.
1.2 Modelos de proceso incremental

Hay muchas situaciones en las que los requerimientos iniciales del software
estn razonablemente bien definidos, pero el alcance general del esfuerzo de
desarrollo imposibilita un proceso lineal. Adems, tal vez haya una necesidad
imperiosa de dar rpidamente cierta funcionalidad limitada de software a los
usuarios y aumentarla en las entregas posteriores de software. En tales casos,
se elige un modelo de proceso diseado para producir el software en
incrementos.

El modelo incremental combina elementos de los flujos de proceso lineal y

paralelo estudiados en la seccin 2.1. En relacin con la figura 2.5, el modelo
incremental aplica secuencias lineales en forma escalonada a medida que
avanza el calendario de actividades.

Cada secuencia lineal produce incrementos de software susceptibles de

entregarse de manera parecida a los incrementos producidos en un flujo de
proceso evolutivo (seccin 2.3.3).

Por ejemplo, un software para procesar textos que se elabore con el paradigma
incremental quiz entregue en el primer incremento las funciones bsicas de
administracin de archivos, edicin y produccin del documento; en el segundo
dar herramientas ms sofisticadas de edicin y produccin de documentos; en
el tercero habr separacin de palabras y revisin de la ortografa; y en el cuarto
se proporcionar la capacidad para dar formato avanzado a las pginas. Debe
observarse que el flujo de proceso para cualquier incremento puede incorporar
el paradigma del prototipo.

Cuando se utiliza un modelo incremental, es frecuente que el primer incremento

sea el producto fundamental. Es decir, se abordan los requerimientos bsicos,
pero no se proporcionan muchas caractersticas suplementarias (algunas
conocidas y otras no).

La arquitectura en pipeline (basada en filtros) consiste en ir transformando un

flujo de datos en un proceso comprendido por varias fases secuenciales, siendo
la entrada de cada una la salida de la anterior.
Esta arquitectura es muy comn en el desarrollo de programas para el intrprete
de comandos, ya que se pueden concatenar comandos fcilmente con tuberas
(pipe).

Tambin es una arquitectura muy natural en el paradigma de programacin

funcional, ya que equivale a la composicin de funciones matemticas.

Interprete de comandos

Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos

obtenidos del usuario por medio de una interfaz alfanumrica.

Caractersticas

Se evitan proyectos largos y se entrega algo de valor a los usuarios

con cierta frecuencia.
El usuario se involucre ms.
Difcil de evaluar el costo 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.
1.3 Modelos de proceso evolutivo

El software, como todos los sistemas complejos, evoluciona en el tiempo. Es

frecuente que los requerimientos del negocio y del producto cambien conforme
avanza el desarrollo, lo que hace que no sea realista trazar una trayectoria
rectilnea hacia el producto final; los plazos apretados del mercado hacen que
sea imposible la terminacin de un software perfecto, pero debe lanzarse una
versin limitada a fin de aliviar la presin de la competencia o del negocio; se
comprende bien el conjunto de requerimientos o el producto bsico, pero los
detalles del producto o extensiones del sistema an estn por definirse. En estas
situaciones y otras parecidas se necesita un modelo de proceso diseado
explcitamente para adaptarse a un producto que evoluciona con el tiempo. Los
modelos evolutivos son iterativos. Se caracterizan por la manera en la que
permiten desarrollar versiones cada vez ms completas del software. En los
prrafos que siguen se presentan dos modelos comunes de proceso evolutivo.

Hacer prototipos. Es frecuente que un cliente defina un conjunto de objetivos

generales para el software, pero que no identifique los requerimientos detallados
para las funciones y caractersticas. En otros casos, el desarrollador tal vez no
est seguro de la eficiencia de un algoritmo, de la adaptabilidad de un sistema
operativo o de la forma que debe adoptar la interaccin entre el humano y la
mquina. En estas situaciones, y muchas otras, el paradigma de hacer prototipos
tal vez ofrezca el mejor enfoque.

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez
ms completas y complejas, hasta llegar al objetivo final deseado; incluso
evolucionar ms all, durante la fase de operacin. Los modelos Iterativo
Incremental y Espiral (entre otros) son dos de los ms conocidos y utilizados
del tipo evolutivo.

La idea detrs de este modelo es el desarrollo de una implantacin del sistema

inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta
que se desarrolle el sistema adecuado. Una ventaja de este modelo es que se
obtiene una rpida realimentacin del usuario, ya que las actividades de
especificacin, desarrollo y pruebas se ejecutan en cada iteracin.
Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el

usuario los requisitos hasta llegar a un sistema final. El desarrollo
comienza con las partes que se tiene ms claras. El sistema
evoluciona conforme se aaden nuevas caractersticas propuestas por
el usuario.
Enfoque utilizando prototipos: El objetivo es entender los requisitos del
usuario y trabajar para mejorar la calidad de los requisitos. A diferencia
del desarrollo exploratorio, se comienza por definir los requisitos que
no estn claros para el usuario y se utiliza un prototipo para
experimentar con ellos. El prototipo ayuda a terminar de definir estos
requisitos.

VENTAJAS

La especificacin puede desarrollarse de forma creciente.

Los usuarios y desarrolladores logran un mejor entendimiento del sistema.
Esto se refleja en una mejora de la calidad del software.
Es ms efectivo que el modelo de cascada, ya que cumple con las
necesidades inmediatas del cliente.

DESVENTAJAS

Proceso no Visible: Los administradores necesitan entregas para medir el

progreso. Si el sistema se necesita desarrollar rpido, no es efectivo
producir documentos que reflejen cada versin del sistema.
Sistemas pobremente estructurados: Los cambios continuos pueden ser
perjudiciales para la estructura del software haciendo costoso el
mantenimiento.
Se requieren tcnicas y herramientas: Para el rpido desarrollo se
necesitan herramientas que pueden ser incompatibles con otras o que
poca gente sabe utilizar.
1.4 El modelo espiral.

Propuesto en primer lugar por Barry Boehm [Boe88], el modelo espiral es un

modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa
de hacer prototipos con los aspectos controlados y sistmicos del modelo de
cascada. Tiene el potencial para hacer un desarrollo rpido de versiones cada
vez ms completas. Boehm [Boe01a] describe el modelo del modo siguiente: El
modelo de desarrollo espiral es un generador de modelo de proceso impulsado
por el riesgo, que se usa para guiar la ingeniera concurrente con participantes
mltiples de sistemas intensivos en software. Tiene dos caractersticas
distintivas principales. La primera es el enfoque cclico para el crecimiento
incremental del grado de definicin de un sistema y su implementacin, mientras
que disminuye su grado de riesgo. La otra es un conjunto de puntos de referencia
de anclaje puntual para asegurar el compromiso del participante con soluciones
factibles y mutuamente satisfactorias. Con el empleo del modelo espiral, el
software se desarrolla en una serie de entregas evolutivas. Durante las primeras
iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones
posteriores se producen versiones cada vez ms completas del sistema cuya
ingeniera se est haciendo. Un modelo en espiral es dividido por el equipo de
software en un conjunto de actividades estructurales. Para fines ilustrativos, se
utilizan las actividades estructurales generales ya analizadas.9 Cada una de
ellas representa un segmento de la trayectoria espiral ilustrada en la figura 2.7.
Al comenzar el proceso evolutivo, el equipo de software realiza actividades
implcitas en un
circuito alrededor de la espiral en el sentido horario, partiendo del centro. El
riesgo se considera conforme se desarrolla cada revolucin (captulo 28). En
cada paso evolutivo se marcan puntos de referencia puntuales: combinacin de
productos del trabajo y condiciones que se encuentran a lo largo de la trayectoria
de la espiral. El primer circuito alrededor de la espiral da como resultado el
desarrollo de una especificacin del producto; las vueltas sucesivas se usan para
desarrollar un prototipo y, luego, versiones cada vez ms sofisticadas del
software. Cada paso por la regin de planeacin da como resultado ajustes en
el plan del proyecto.

Determinar o fijar objetivos

Fijar tambin los productos definidos a obtener: requisitos, especificacin,

manual de usuario.

Fijar las restricciones.

Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.

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

Desarrollar, verificar y validar (probar)

Tareas de la actividad propia y de prueba.

Anlisis de alternativas e identificacin resolucin de riesgos.

Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo
para el desarrollo, el que puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. As si por ejemplo si los riesgos en la interfaz de
usuario son dominantes, un modelo de desarrollo apropiado podra ser la
construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal
consideracin, un desarrollo basado en transformaciones formales podra ser el
ms apropiado.

Anlisis del riesgo

Se lleva a cabo el estudio de las causas de las posibles amenazas y probables

eventos no deseados y los daos y consecuencias que stas puedan producir.
Se evalan alternativas. Se debe tener un prototipo antes de comenzar a
desarrollar y probar.

En resumen, es para tener en cuenta los riesgos de cada uno de los mbitos.

Ventajas

El anlisis del riesgo se hace de forma explcita y clara. Une los mejores
elementos de los restantes modelos.
Reduce riesgos del proyecto
Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento, etc.

Desventajas

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso
Requiere experiencia en la identificacin de riesgos
1.5 Mtodo de Prototipos

Esta metodologa de la programacin todava sigue siendo la favorita de

muchos. Consiste bsicamente en que en base a los requerimientos y
necesidades que tiene el cliente, se realiza de forma rpida un prototipo, este no
vendr completo ni mucho menos terminado, pero si permitir contar con las
bases necesarias para que cualquier programador pueda seguir trabajando en
el hasta llegar al cdigo final.

Por si no lo sabes an, un prototipo es una versin no terminada del producto

que se le entregar al cliente o usuario final. Esto nos genera cierta ventaja en
el desarrollo de productos similares con funciones distintas, por ejemplo.
Supongamos que vas a desarrollar un proyecto para 3 clientes distintos, ambos
con una estructura idntica, pero con funcionalidades muy distintas, entonces lo
que hacemos es crear un prototipo base y entorno al mostrarlo a nuestros
clientes para que de ah se empiecen a desarrollar las dems funciones.

Mejor vamos a ver cules son las etapas de desarrollo de software por las cuales
tendrs que pasar, en caso de utilizar la metodologa de prototipos.

1. Planeacin. A diferencia de otras metodologas, la planeacin debe ser

muy rpida, en esta fase no puedes demorarte mucho, pues recuerda que
solamente ser un prototipo por el momento.
2. Modelado. Nuevamente, una fase que deber ser suficientemente rpida
como para que nos quite nada de tiempo. Hacer el modelado ser simple
y te sigo recordando que solamente es un prototipo, almenos por ahora.
3. Elaboracin del Prototipo. Ya que contamos con la planeacin de lo que
vamos a realizar y el modelado rpido, entonces es momento de elaborar
el prototipo. Para esta instancia, ya no te dir que lo debes hacer rpido,
puesto que te tomar el tiempo que tenga sea necesario elaborarlo,
recuerda que este ya se muestra al cliente, as que ya es una fase
importante.
4. Desarrollo. Posterior a contar con el prototipo elaborado y mostrado al
cliente, es momento de comenzar el desarrollo. Este te tomar una gran
cantidad de tiempo, dependiendo del tamao del proyecto y el lenguaje
de programacin que se vaya a utilizar.
 5. Entrega y Retroalimentacin. Una de las cosas con las que cuenta el
modelo de prototipos, es que una vez entregado el proyecto, debemos
darle al cliente cierta retroalimentacin sobre como utilizarlo y ciertamente
es una fase que se encuentra dentro de las etapas de desarrollo de
software esta metodologa.
6. Comunicacin con el Cliente. Es importante que una ves entregado el
proyecto, tengamos cierta comunicacin con el cliente, bsicamente para
que nos indique si el proyecto es correcto o si desea agregarle ciertas
funciones, nuestra metodologa lo permite. Si fuera en modo cascada,
entonces seria algo realmente imposible de hacer.
7. Entrega del Producto Final. Por ltimo, solamente quedar entregar el
sistema elaborado mediante esta metodologa. Aqu tendrs la ventaja de
que el cdigo es reutilizable, para que as con el prototipo ya puedas
simplemente empezar de nuevo y con una buena base de cdigo que te
acelerar el proceso.

Cules son los Principios Bsicos del mtodo de prototipos?

Por supuesto, te habrs dado cuenta de que el modelo de prototipos puede llegar
a ser un poco ms tedioso, aunque todo depender del mbito en que lo utilices.
Sin embargo, uno de sus principios bsicos que seguramente habrs notado, es
que con el mtodo de prototipos el proyecto se va dividiendo en partes cada vez
ms pequeas, para evitar el peligro ante los riesgos frente a los que estamos
expuestos.

Adems, otros de sus principios bsicos fundamentales, es que, con la

metodologa de prototipos, el cliente final se involucra mucho ms en el proyecto
que con otras metodologas, haciendo de esta forma que el producto final llegue
rpidamente, aunque con un poco ms de presin en el proceso. La ventaja es
que conforme se van haciendo prototipos pequeos, poco a poco se va llegando
al producto final. Incluso en algn determinado momento podrs llegar a crear
un prototipo que, con solo ajustar ciertos detalles, se podra convertir en el
producto que el usuario quiere.
Algunas Ventajas del uso de prototipos

1. Permiten el desarrollo de un sistema a partir de requisitos poco claros o

cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.
2. Como informacin complementaria a los requisitos constituyen un gran apoyo a
las estimaciones de esfuerzo de todas las reas, incluyendo proveedores.
3. Son ms fciles de abordar con los usuarios finales.
4. El usuario participa ms activamente en la construccin del producto de software
(La Solucin), ya que lo puede ver y, dependiendo del tipo de prototipo, utilizar
desde el primer momento.
5. Se reduce el riesgo o la incertidumbre sobre la implementacin del software.
6. Su uso redunda en una mayor satisfaccin del usuario con el producto final, ya
que l o ella han participado activamente de su diseo.
7. Proporciona al usuario un mayor conocimiento del sistema con una curva menor
de aprendizaje.
8. Permite a todos los involucrados entender bien y mejor el problema antes de la
implementacin final.

Algunas Desventajas del uso de prototipos

1. 1.El usuario quiere empezar a trabajar desde el primer momento con el

prototipo para solucionar su problema particular, cuando el prototipo es
solo un modelo de lo que ser el producto.
2. 2.Los prototipos generan o pueden generar otro tipo de problemas si su
presentacin y discusin con los usuarios no es controlada: puesto que
son modelos inconclusos, los usuarios suelen enfocarse en aspectos
superficiales del prototipo que los pueden dejar inconformes luego de
verlos por primera vez. Tambin es posible que se pierda mucho tiempo,
innecesariamente, tratando de hacer entender al usuario la finalidad real
de los prototipos.
3. 3.Requiere participacin activa del usuario, al menos, para evaluar el
prototipo. Y mucho ms involucramiento si queremos que participe en su
creacin.
4. 4.Una desventaja importante a tener en cuenta es la falta de experiencia
que tienen muchos Analistas Funcionales en programacin y en
actividades de diseo de interfaces de usuario.
1.6 Desarrollo basado en componentes

comerciales de software general (COTS, por sus siglas en ingls), desarrollados

por vendedores que los ofrecen como productos, brindan una funcionalidad que
se persigue con interfaces bien definidas que permiten que el componente se
integre en el software que se va a construir. El modelo de desarrollo basado en
componentes incorpora muchas de las caractersticas del modelo espiral. Es de
naturaleza evolutiva y demanda un enfoque iterativo para la creacin de
software. Sin embargo, el modelo de desarrollo basado en componentes
construye aplicaciones a partir de fragmentos de software prefabricados. Las
actividades de modelado y construccin comienzan con la identificacin de
candidatos de componentes.

stos pueden disearse como mdulos de software convencional o clases

orientadas a objetos o paquetes16 de clases. Sin importar la tecnologa usada
para crear los componentes, el modelo de desarrollo basado en componentes
incorpora las etapas siguientes (se implementan con el uso de un enfoque
evolutivo):

1. Se investigan y evalan, para el tipo de aplicacin de que se trate,

productos disponibles basados en componentes.
2. Se consideran los aspectos de integracin de los componentes.
3. Se disea una arquitectura del software para que reciba los componentes.
4. Se integran los componentes en la arquitectura.
5. Se efectan pruebas exhaustivas para asegurar la funcionalidad
apropiada.

El modelo del desarrollo basado en componentes lleva a la reutilizacin del

software, y eso da a los ingenieros de software varios beneficios en cuanto a la
mensurabilidad. Si la reutilizacin de componentes se vuelve parte de la cultura,
el equipo de ingeniera de software tiene la posibilidad tanto de reducir el ciclo
de tiempo del desarrollo como el costo del proyecto. En el captulo 10 se analiza
con ms detalle el desarrollo basado en componentes.

En esencia, un componente es una pieza de cdigo reelaborado que encapsula

alguna funcionalidad expuesta a travs de interfaces estndar
 (1) . Los componentes son los "ingredientes de las aplicaciones", que se
juntan y combinan para llevar a cabo una tarea
(2) (2) . Es algo muy similar a lo que podemos observar en el equipo de
msica que tenemos en nuestra sala. Cada componente de aquel aparato
ha sido diseado para acoplarse perfectamente con sus pares, las
conexiones son estndar y el protocolo de comunicacin est ya
preestablecido. Al unirse las partes, obtenemos msica para nuestros
odos.

El paradigma de ensamblar componentes y escribir cdigo para hacer que estos

componentes funcionen se conoce como Desarrollo de Software Basado en
Componentes. El uso de este paradigma posee algunas ventajas:

Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin

de software.

Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando
cada uno de los componentes antes de probar el conjunto completo de
componentes ensamblados.

Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento

entre componentes, el desarrollador es libre de actualizar y/o agregar
componentes segn sea necesario, sin afectar otras partes del sistema.

Mayor calidad. Dado que un componente puede ser construido y luego

mejorado continuamente por un experto u organizacin, la calidad de una
aplicacin basada en componentes mejorar con el paso del tiempo.

De la misma manera, el optar por comprar componentes de terceros en lugar de

desarrollarlos, posee algunas ventajas:

Ciclos de desarrollo ms cortos. La adicin de una pieza dada de

funcionalidad tomar das en lugar de meses aos.

Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la inversin

puede ser ms favorable que desarrollando los componentes uno mismo.

Funcionalidad mejorada. Para usar un componente que contenga una pieza de

funcionalidad, solo se necesita entender su naturaleza, ms no sus detalles
internos. As, una funcionalidad que sera imprctica de implementar en la
empresa, se vuelve ahora completamente asequible.

Ventajas:

Funcionalidad mejorada.
reduce los costes y tiempos
Reutilizacin del software.
Simplifica las pruebas.
Simplifica el mantenimiento del sistema.
Mayor calidad.
Ciclos de desarrollo ms cortos.

Desventajas:

Genera mucho tiempo.

Genera mucho trabajo adicional
Confiabilidad de los componentes.
Los componentes son cajas negras de unidades de programas,
y el cdigo de los componentes puede no estar disponible para
los usuarios de dichos componentes.
2 Otras metodologas
2.1 Metodologa de ganar-ganar

En los modelos clsicos surge en la comunicacin con los clientes para

determinar los requisitos, en este modelo se basa en la negociacin entre el
cliente y el desarrollador, se negocia coste frente a funcionalidades, rendimiento,
calidad, o simplemente el gestor del proyecto le pregunta al cliente qu necesita
y l proporciona la informacin para continuar.

Esto se refiere que a la obtencin de requisitos requieren de una negociacin,

que tiene xito cuando ambas partes ganan.

Es decir que el cliente gane obteniendo el producto que lo satisfaga, y el

desarrollador tambin gane consiguiendo presupuesto y fecha de entrega
realista. Evidentemente, este modelo requiere fuertes habilidades de
negociacin.

Grupo de aplicacin: Se determina la viabilidad de un grupo apropiado de

aplicaciones. En este ciclo se refiri principalmente en la determinacin que debe
tener dicho proyecto.

Objetivos del ciclo de vida de la aplicacin: Se desarrollan objetivos del ciclo de

vida, incluyendo prototipos, planes y especificaciones de aplicaciones
individuales, y se verifica la existencia de al menos una arquitectura viable para
cada aplicacin.

Arquitectura del ciclo de vida de la aplicacin: Se establece una arquitectura del

ciclo de vida detallado, se verifica la viabilidad y determina que no existen riesgos
mayores en satisfacer los planes y especificaciones.

Capacidad de operacin inicial: Alcanzar una capacidad operacional inicial para

cada etapa crtica del proyecto en el ciclo de vida del software.

ACTIVIDADES

1. Identificacin del sistema o subsistemas

2. Determinacin de los directivos
Modelo de desarrollo evolutivo WinWin

El modelo de desarrollo evolutivo, Es visto como una variacin o una evolucin

del modelo en espiral Que utiliza una aproximacin cclica para el desarrollo
incremental De sistemas software.

WinWin literalmente significa Ganar-Ganar y hace referencia a que el Desarrollo

del proceso software se basa en una constante negociacin Entre el cliente y el
desarrollador en busca del beneficio mutuo y Constante, o sea, el cliente quiere
ganar y el desarrollador tambin Quiere ganar, por lo que el centro de la
negociacin entre ambos Adquiere una especial relevancia en la fase de los
requisitos del Sistema.

Cada ciclo envuelve cuatro actividades principales:

Elaboracin del sistema o subsistemas y los objetivos,

Restricciones y alternativas del proceso.
Evaluar las alternativas respecto a los objetivos y restricciones.
Identificar y resolver el mayor nmero de fuentes de producto y Riesgos
posibles.
Elaboracin de la definicin del producto y del proceso.
Planificacin del prximo ciclo y actualizacin de la planificacin
Del ciclo de vida. Ello incluye, si es necesario, el Particionamiento
del sistema en subsistemas a desplegarse en Paralelo. Puede
incluir, adems, la definicin de un plan para Finalizar el proyecto
si ste es de riesgo demasiado alto o no es Factible.

VENTAJAS

Minimiza riesgos del proyecto

Agrega objetivos de calidad

DESVENTAJAS

Genera mucho tiempo en el desarrollo del sistema

Resulta como un modelo muy costoso

Requiere de mucha experiencia en la identificacin de los riesgos

2.2 Proceso Unificado De Desarrollo De Software

La metodologa de UP, es un mtodo iterativo de diseo de software que

describe cmo desarrollar software de forma eficaz, utilizando tcnicas probadas
en la industria.

El Proceso Unificado de Desarrollo de 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, enfocado en el riesgo, y
por ser iterativo e incremental.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo

extensible que puede ser adaptado a organizaciones o proyectos especficos.

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. Es una metodologa orientada a conducir el proceso de desarrollo de
software en sus aspectos tcnicos; los flujos y productos de trabajo de UP no
incluyen la administracin del proyecto.

UP Divide El Trabajo De Desarrollo De Software En Cuatro Fases

Fase de Inicio en UP

En esta fase corresponde definir el negocio. Es la etapa donde se define la

factibilidad del proyecto a realizar, se representa el modelo de negocio, visin y
metas del proyecto, se identifican actores, conceptos de dominio y deseos de
usuario. Adicionalmente se complementa con la definicin de la arquitectura
preliminar, y estimaciones (imprecisas, preliminares) de plazos y costos.
Tambin se define la viabilidad del proyecto.

Fase de Elaboracin en UP

En la fase de elaboracin se obtiene la visin refinada del proyecto a realizar, la

implementacin iterativa del ncleo central de la aplicacin, la resolucin de los
riesgos ms altos, la identificacin de nuevos requisitos y nuevos alcances, y
estimaciones ms ajustadas. A esta altura existe la posibilidad de detener el
proyecto por complejidad tcnica.
Fase de Construccin en UP

La fase de construccin es la implementacin iterativa del resto de los requisitos

de menor riesgo y elementos ms sencillos. Es la evolucin hasta convertirse en
un producto listo, incluyendo todos los requisitos (100%), para entregarse al
Cliente. Al final de esta fase el sistema contiene todos los casos de uso que el
cliente y la direccin del proyecto han acordado. La mayora de los casos de uso
que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en
grupos de requisitos o casos de uso durante esta fase.

1. Interactivo e Incremental

El desarrollo de software interactivo e incremental corresponde a mantener

permanentemente un enfoque de cambio en los proyectos de desarrollo. Los
llamados ciclos por fases intentan poner en manos del usuario un sistema con
prestaciones parciales, que se va completando con nuevas prestaciones en
fases sucesivas. As, el usuario tiene en produccin algunas funcionalidades
mientras se van desarrollando las otras. Por lo tanto, existen entonces al menos
dos sistemas funcionando en paralelo:

1) El sistema operacional o sistema en produccin, en uso por el cliente.

Puede ser una implementacin parcial, una implementacin anterior con
funcionalidades nuevas o sustituidas, una implementacin nueva con
partes de la anterior u otra variante coherente.
2) El sistema en desarrollo (la siguiente versin) que est siendo preparada
para reemplazar la versin en produccin, que puede an conservar
partes de implementaciones anteriores o faltarle funcionalidades.

La representacin de un proceso iterativo e incremental se realiza en la siguiente

ilustracin.

La metodologa RUP como se pudo observar es la mejor al momento de obtener

software de calidad. Tambin la complejidad que lleva el desarrollar un software
ya sea grande o chico como su base fundamental que son las iteraciones y la
reutilizacin de recursos, los roles que tiene la metodologa cada uno tiene
impartido las prioridades que conlleva el desarrollar software por este medio, y
concluimos que al momento de elegir cualquier metodologa es la que mejor se
adapte a los requerimientos de las empresas y que cumpla con un software de
calidad.

Ventajas:

-Requiere de conocimientos del proceso y de UML

-Progreso visible en las etapas tempranas
-El uso de iteraciones
-Evaluacin de riesgos en lugar de descubrir en la integracin final del
sistema
-Facilita la reutilizacin del cdigo

Desventajas:

-Por el grado de complejidad puede no resultar no muy adecuado

-Mal aplicado en el estilo cascada.
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 Word Wide Web.

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 la informacin 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.

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.
Los principales aspectos de la ingeniera de la Web incluyen, entre otros,
los siguientes temas:

Diseo de procesos de negocio para aplicaciones web.

Herramientas CASE para aplicaciones web.
Generacin de cdigo para aplicaciones web.
Desarrollo web colaborativo.
Modelado conceptual de aplicaciones web.
Diseo de Modelos de datos para sistemas de informacin web.
Ingeniera web emprica.
Entornos de desarrollo de aplicaciones web integrados.
Herramientas de autor para contenido multimedia.
Pruebas de rendimiento de aplicaciones basadas en web.
Personalizacin y adaptacin de aplicaciones web.
Herramientas y mtodos de prototipado.
Control de calidad y pruebas de sistemas.
Ingeniera de requisitos para aplicaciones web.
Aplicaciones para la Web Semntica.
Factoras de software para la web.
Mtodos, herramientas y automatizacin de pruebas para aplicaciones web.
Aplicaciones web mviles y ubicuas.
Usabilidad de aplicaciones web.
Accesibilidad para la web.
Metodologas de diseo web.
Formacin en ingeniera de la web.
Diseo de interfaces de usuario.
Mtricas para la web, estimacin de costes y medicin.
Gestin de proyectos web y gestin de riesgos.
Desarrollo y despliegue de servicios web.
Aplicacin de software basada en la Web este sitio puede tener todas las
caractersticas antes mencionadas, pero logrando un parecido con una
implementacin cliente/servidor comnmente conocido que a un sitio web
esttico.
Ventajas

Es de Fcil uso
Permite la comunicacin rpida y directa con una o varias personas que
se encuentre en cualquier parte del mundo, ayudando de esta manera en
las Tics
Desarrollo de diferentes proyectos y propuestas para dar a conocer dichos
proyectos a travs de la red
Ayuda en el proceso de globalizacin de las empresas, ya que permite
contactar diferentes entidades y personas en el mundo sin altos costos
Crear publicidad para que los clientes puedan acceder a productos y
servicios y tengan informacin actualizada de ellos.
Creacin de ventaja competitiva, ya que la empresa o entidad se
encontrara a la vanguardia de la tecnologa.

Desventajas

No posee muchas funcionalidades para la empresa. solo suple

necesidades de comunicacin.
No ofrece diversidad de opciones.
2.4 METODOLOGAS GILES

En una reunin celebrada en febrero de 2001 en Utah-EEUU, nace el trmino

"gil" aplicado al desarrollo de software. En esta reunin participan un grupo de
17 expertos de la industria del software, incluyendo algunos de los creadores o
impulsores de metodologas de software. Su objetivo fue esbozar los valores y
principios que deberan permitir a los equipos desarrollar software rpidamente
y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se
pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que
se genera en cada una de las actividades desarrolladas. Varias de las
denominadas metodologas giles ya estaban siendo utilizadas con xito en
proyectos reales, pero les faltaba una mayor difusin y reconocimiento.

resumen gran parte del espritu gil. Son:

I. La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor. Un proceso es gil si a
las pocas semanas de empezar ya entrega software que funcione,
aunque sea rudimentario. El cliente decide si pone en marcha dicho
software con la funcionalidad que ahora le proporciona o simplemente
lo revisa e informa de posibles cambios a realizar.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el
cliente tenga una ventaja competitiva. Este principio es una actitud que
deben adoptar los miembros del equipo de desarrollo. Los cambios en
los requisitos deben verse como algo positivo. Les va a permitir
aprender ms, a la vez que logran una mayor satisfaccin del cliente.
Este principio implica adems que la estructura del software debe ser
flexible para poder incorporar los cambios sin demasiado coste
aadido. El paradigma orientado a objetos puede ayudar a conseguir
esta flexibilidad.

Luego existen una serie de principios que tienen que ver directamente con el
proceso de desarrollo de software a seguir.
III. Entregar frecuentemente software que funcione desde un par de
semanas a un par de meses, con el menor intervalo de tiempo posible
entre entregas. La entrega al cliente se insiste en que sean software,
no planificaciones, ni documentacin de anlisis o de diseo.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo
largo del proyecto. El proceso de desarrollo necesita ser guiado por el
cliente, por lo que la interaccin con el equipo es muy frecuente.
V. Construir el proyecto en torno a individuos motivados. Darles el
entorno y el apoyo que necesitan y confiar en ellos para conseguir
finalizar el trabajo. La gente es el principal factor de xito, todo los
dems (proceso, entorno, gestin, etc.) queda en segundo plano. Si
cualquiera de ellos tiene un efecto negativo sobre los individuos debe
ser cambiado.
VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para
comunicar informacin dentro de un equipo de desarrollo. Los
miembros de equipo deben hablar entre ellos, ste es el principal modo
de comunicacin. Se pueden crear documentos, pero no todo estar
en ellos, no es lo que el equipo espera.
VII. El software que funciona es la medida principal de progreso. El estado
de un proyecto no viene dado por la documentacin generada o la fase
en la que se encuentre, sino por el cdigo generado y en
funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el
50% de los requisitos ya estn en funcionamiento.
VIII. Los procesos giles promueven un desarrollo sostenible. Los
promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante. No se trata de desarrollar lo ms rpido
posible, sino de mantener el ritmo de desarrollo durante toda la
duracin del proyecto, asegurando en todo momento que la calidad de
lo producido es mxima.
I. Finalmente, los ltimos principios estn ms directamente
relacionados con el equipo de desarrollo, en cuanto metas a seguir y
organizacin del mismo.
 IX. La atencin continua a la calidad tcnica y al buen diseo mejora la
agilidad. Producir cdigo claro y robusto es la clave para avanzar ms
rpidamente en el proyecto.
X. La simplicidad es esencial. Tomar los caminos ms simples que sean
consistentes con los objetivos perseguidos. Si el cdigo producido es
simple y de alta calidad ser ms sencillo adaptarlo a los cambios que
puedan surgir.
XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos
organizados por s mismos. Todo el equipo es informado de las
responsabilidades y stas recaen sobre todos sus miembros. Es el
propio equipo el que decide la mejor forma de organizarse, de acuerdo
a los objetivos que se persigan.
XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a
ser ms efectivo, y segn esto ajusta su comportamiento. Puesto que
el entorno est cambiando continuamente, el equipo tambin debe
ajustarse al nuevo escenario de forma continua. Puede cambiar su
organizacin, sus reglas, sus convenciones, sus relaciones, etc., para
seguir siendo gil.

Ventajas/Desventajas de las metodologas agiles

Bueno, tras analizar las metodologas agiles y la crtica realizada en la entrada

anterior a la metodologa scrum, voy a enumerar y analizar las
ventajas que tienen las metologas agiles y, como no, tambin sus
inconvenientes.

La primera y la que, a mi parecer es la ms importante, es que estas

metodologas ofrecen una rpida respuesta a cambios de requisitos a lo largo
del desarrollo del proyecto gracias a su proceso iterativo, es tan importante
realizar una buena recolecta de requisitos, como
despuespoder modificarlos evitando grandes prdidas en cuanto a costes,
motivacin, tiempo.
El cliente, si quiere colaborar, puede observar cmo va avanzando el
proyecto, y por supuesto, opinar sobre su evolucin gracias a las numerosas
reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.

Uniendo las dos anteriores, se puede deducir que, al utilizar estas

metodologas, los cambios que quiera realizar el cliente van a tener un menor
impacto, ya que se va a entregar en un pequeo intervalo de tiempo un pequeo
trozo del proyecto al cliente, y si ste quiere cambiarlo, solo se habr perdido
unas semanas de trabajo. Con las metodologas tradicionales las entregas al
cliente se realizaban tras la realizacin de una gran parte del proyecto, eso quiere
decir que el equipo ha estado trabajando meses para que luego un mnimo
cambio que quiera realizar el cliente, conlleve la prdida de todo ese trabajo.

Importancia de la simplicidad al eliminar trabajo innecesario pero claro, aunque

las ventajas sean muy apetecibles, estas metodologas tambin presentan
inconvenientes que hay que asumir cuando se decide trabajar con ellas. Estos
son:

Falta de documentacin del diseo. Al no haber documentacin es el cdigo

(junto con sus comentarios) lo que se toma como documentacin.

Problemas derivados de la comunicacin oral. Bo hace falta decir que algo que
est escrito a no se puede borrar, en cambio, algo dicho es muy fcil crear
ambigedad.

Fuerte dependencia de las personas.

Falta de reusabilidad derivada de la falta de documentacin

Destrucciones en cuanto a tamao de los proyectos

2.5 Metodologas emergentes

Una metodologa es emergente si permite adaptar la forma de trabajo a las

condiciones del proyecto. El tipo de sistemas es el uso del modelo orientado a
objetos que ayuda a explorar el poder expresivo de todos los lenguajes de
programacin basados en objetos y orientados a objetos, como Smalltalk,
objectpascal, C++, CLOS, Ada y java. Su incertidumbre es la direccin que indica
la necesidad estratgica que se desea cubrir, ofreciendo mxima libertad al
equipo de trabajo. La difusin y la transferencia del conocimiento es la alta
rotacin de los miembros de los equipos entre diferentes proyectos. Por otra
parte, es potenciar el acceso libre a la informacin y documentacin. La
metodologa emergente se utiliza mayor mente en el desarrollo de productos con
innovaciones importantes y para sistemas de informacin empresarial.

Ventajas:

las metodologas emergentes motivan ms a los equipos de trabajo.

El principal benecito del diseo orientado a objetos es que proporciona un
mecanismo para formalizar modelos de la realidad
Evita malos entendidos de requerimientos entre el cliente y el equipo.
El uso del modelo orientado a objetos alienta la reutilizacin, no solo del
software, sino de diseos completos.
Proporciona mejores resultados en los proyectos de alto riesgo.

Desventajas:

Problemas derivados de la comunicacin oral.

Falta de calidad

ICONIX es una metodologa pesada2ligera de desarrollo del Software que se

halla a medio camino entre un RPU (Rational unified process) y un XP (Extreme
Programming).

El proceso ICONIX se define como un proceso de desarrollo de software

practico. Este entre la complejidad de RPU y la simplicidad y pragmatismo de
XP, sin eliminar las tareas de anlisis y diseo lo que XP no contempla.
Es un proceso simplificado en comparacin con otros procesos ms
tradicionales, que unifica un conjunto de mtodos de orientacin a objetos con el
objetivo de abarcar todo el ciclo de vida de un proyecto. ICONIX presenta
claramente las actividades de cada fase y exhibe una secuencia de pasos que
deben ser seguidos. dems, est adaptado a patrones y ofrece el soporte ULM,
dirigido por pasos de Usos es un proceso iterativo e incremental.

Las tres caractersticas fundamentales de ICONIX son:

iterativo e incremental varias interacciones ocurren entre el modelo del dominio

y la identificacin de los casos de uso. El modelo esttico es incrementalmente
refinado por los modelos dinmicos.

trazabilidad cada paso est referenciado por algn requisito. Se define la

trazabilidad como la capacidad de seguir una relacin entre los diferentes
artefactos producidos

Dinmica del UML: la metodologa ofrece un uso dinmico del UML como los
diagramas del caso de uso, diagramas de secuencia y de colaboracin.

Las tareas que se realizan en la metodologa ICONIX son:

1-ANALISIS DE REQUERIMIENTO:

Modelo del dominio (diagrama de clases)

Prototipado rpido
Modelo de casos de Uso

2-ANALISIS Y DISEO PRELIMINAR:

Descripcin de casos de Uso

Diagrama de Robustez

3-DISEO

Diagrama de Secuencia

4-IMPLEMENTACION

Escribir y generar el cdigo