TALLER

CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE

METODOLOGAS DE DESARROLLO DE SOFTWARE

MAURICIO ALEJANDRO GOMEZ RESTREPO

PROFESOR:
MANUEL IGNACIO CABRERA CUELLAR

UNIVERSIDAD INPAHU

INGENIERIA DE SOFTWARE

MODELAMIENTO DE SISTEMAS DE INFORMACIN

Contenido
INTRODUCCION_________________________________________________________3
OBJETIVO GENERAL_____________________________________________________4
OBJETIVOS ESPECIFICOS________________________________________________5
3. CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE____________________6
3.1. Ciclos de vida___________________________________________________________6
3.1.1. Tipos de modelo de ciclo de vida____________________________________________6
3.2. Modelos de ciclo de vida________________________________________________6
3.2.1. Modelo en cascada__________________________________________________________7
3.2.2. Modelo en V________________________________________________________________8
3.2.3. Modelo iterativo_____________________________________________________________9
3.2.4. Modelo de desarrollo incremental__________________________________________10
3.2.5. Modelo en espiral__________________________________________________________11
3.2.6. Modelo de Prototipos______________________________________________________12
3.3. ISO/IEC 12207_________________________________________________________14
4. METODOLOGAS DE DESARROLLO DE SOFTWARE____________________15
4.1. Definicin de metodologa_____________________________________________15
4.2. Ventajas del uso de una metodologa___________________________________16
4.3. Metodologas tradicionales y giles_____________________________________16
GLOSARIO_____________________________________________________________18
CONCLUSIONES_______________________________________________________19
BIBLIOGRAFIA_________________________________________________________20
 INTRODUCCION

En el presente trabajo abordamos temas tan importantes en el desarrollo de software,

tales como los ciclos de vida y las metodologas de desarrollo de software, los cuales nos
ayudan a mejorar nuestros procesos y a minimizar los riesgos de fracaso en el desarrollo
de un proyecto, abordando la organizacin y la planeacin y correcta ejecucin de un
proyecto, desde el nacimiento de una necesidad hasta la puesta en marcha de un
sistema.
 OBJETIVO GENERAL

Comprender a fondo en qu consisten los ciclos de vida y de desarrollo de software, as

como las metodologas que se utilizan en la optimizacin de los procesos y en el uso de
recursos, esto con el fin de aportarle a nuestra carrera profesional como ingenieros de
software un plus que har una gran diferencia en las probabilidades de xito y fracaso en
nuestros proyectos.
 OBJETIVOS ESPECIFICOS

1. Comprender de manera clara que es el ciclo de vida de desarrollo de software.

2. Aprender y diferenciar los principales modelos de ciclo de vida de desarrollo de
desarrollo de software diferenciando claramente, las ventajas y desventajas que
presentan para el desarrollo e implementacin de un proyecto de desarrollo de
software.
3. Conocer lo que significa para un ingeniero de software la norma ISO/IEC 12207 y
comprender como podra afectar positivamente el aplicar estos estndares en el
desarrollo de software.
4. Comprender que son y para que se usan las diferentes metodologas en el
desarrollo de software.
5. Conocer sobre las caractersticas y diferencias que conlleva en el ciclo de
desarrollo de software el aplicar una metodologa de trabajo tradicional o una de
trabajo gil, y lo que le aporta o le quita al proceso de desarrollo de software.
3. CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE
3.1. Ciclos de vida
El trmino ciclo de vida del software describe el proceso de desarrollo del software, desde
su fase de inicio hasta su fase final.
El propsito de este a veces llamado paradigma es definir las distintas fases intermedias
que se requieren para validar el desarrollo de la aplicacin y as poder garantizar que el
software cumpla los requisitos o requerimientos, en la aplicacin y verificacin de los
procedimientos de desarrollo, de esta manera, se asegura de que los mtodos utilizados
son apropiados.
Este paradigma se origina en el hecho de que es muy costoso rectificar los errores que se
detectan tarde dentro de la fase de implementacin. El ciclo de vida permite que los
errores se detecten lo antes posible y, por lo tanto, permite a los desarrolladores
concentrarse en la calidad del software, en los plazos de implementacin y en los costos
asociados.
Un ciclo de vida se compone de una sucesin de fases que es posible ampliarlas
conforme se avance en el desarrollo a travs de retroalimentacin de los procesos.
Una fase, est compuesta por mltiples tareas o actividades relacionadas entre s,
pueden ser realizadas al tiempo o no, la asignacin de las mismas y el tiempo de
ejecucin puede afectar la asignacin de los recursos disponibles para llevar a cabo el
desarrollo.
Los entregables, son el resultado de las fases, permiten evaluar fase a fase el avance del
proyecto.

3.1.1. Tipos de modelo de ciclo de vida

Existen mltiples tipos de ciclos de vida del software, pero sus principales diferencias son
las siguientes:
El alcance, depende directamente de hasta donde se vaya a desarrollar el proyecto.
Puede ser simplemente un estudio de viabilidad o puede llegar hasta el desarrollo e
implementacin del mismo.
Las caractersticas, son las actividades que componen cada ciclo, depende de cada caso
en particular, no existe un estndar para tal.
La estructura y la sucesin de fases, bsicamente consiste en si se permite la
retroalimentacin entre las fases, y de si tenemos la libertad de repetirlas.

3.2. Modelos de ciclo de vida

Ya definimos que es un modelo de ciclo de vida de software, ahondando ms en el tema,
vemos que el primer modelo de ciclo de vida que se gener es el de Royce, conocido
como cascada o lineal secuencial, este modelo indica bsicamente que el ciclo de
desarrollo es lineal en una sola direccin, ya que en si un modelo de ciclo de vida indica
en pocas palabras, las fases y el orden en el que se ejecutan esas fases en el desarrollo,
adems de diferencia cuales son las fases primarias en el modelo y ayuda a administrar el
proceso de desarrollo; en cada una de las fases se pueden establecer una serie de
objetivos, tareas y/o actividades a desarrollar, existen muchos modelos de ciclos de vida y
dependiendo del proyecto a desarrollar se debe tener en cuenta la eleccin de un modelo
adecuado para determinado proyecto.
A continuacin, mostramos algunos de los modelos de ciclo de vida ms utilizados.

3.2.1. Modelo en cascada

En este modelo lo primordial es que cada etapa debe esperar a que finalice la que la
antecede para empezar. Se trata de un proceso de desarrollo en secuencia, en el que el
flujo se visualiza hacia abajo (como una cascada).
Se cree que este modelo fue el primero que se mostr como tal, lo innovador realmente
fue mostrar el proceso de desarrollo de software dividido en fases separadas, as:
1. Especificacin de requisitos o tambin llamada requerimientos.
2. Diseo.
3. Construccin (Desarrollo, cdigo).
4. Integracin.
5. Pruebas.
6. Instalacin.
7. Mantenimiento.
Notamos que se avanza en el modelo de una manera secuencial.

A pesar de que es considerado como incorrecto por muchos, es el modelo que ms se

sigue actualmente.
Ventajas
Funciona muy bien para proyectos pequeos, en los que se conozcan las posibles fallas.
Todo est organizado y es fcil de seguir.
Debido a su rigidez es fcil de gestionar, cada fase tiene sus entregables y tienen su
proceso de revisin definidos.
Cada fase se procesa y se completa de una vez.
Inconvenientes
Un proyecto rara vez sigue una secuencia lineal, por lo que el modelo no sirve y se
implemente mal, pudiendo llevar al fracaso el proyecto.
Los clientes al principio muy rara vez definen todos los requerimientos o requisitos, para lo
cual este modelo no est adaptado, lo cual genera mltiples atrasos.
El producto se ve cuando se finaliza el proceso, y esto no es lo ms adecuado cuando el
cliente desea ver avances.
Es un modelo que se queda corto para proyectos grandes, genera una gran cantidad de
riesgos e incertidumbres ya que no se puede ver ni parcialmente el progreso del
desarrollo.
Variantes
Debido a los problemas percibidos en la prctica implementando este modelo, han
surgido muchos otros modelos de cascada modificados, para poder solventar las fallas
que este modelo tiene, uno de ellos es el Sashimi (Creado por Peter DeGrace), que
simplemente es superponer las fases, lo que quiere decir que se puede devolver a una
etapa anterior y ser modificada, solucionando muchos de los problemas del modelo
original.

3.2.2. Modelo en V
El modelo en V es una variacin del modelo en cascada que muestra cmo se relacionan
las actividades de prueba con el anlisis y el diseo, la codificacin forma el vrtice de la
V, con el anlisis y el diseo a la izquierda y las pruebas y el mantenimiento a la derecha.
La unin mediante lneas discontinuas entre las fases de la parte izquierda y las pruebas
de la derecha representa una doble informacin. Por un lado, sirve para indicar en qu
fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para
saber a qu fase de desarrollo hay que volver si se encuentran fallos en las pruebas
correspondientes.
Por lo tanto, el modelo en V hace ms explcita parte de las iteraciones y repeticiones de
trabajo que estn ocultas en el modelo en cascada. Mientras el foco del modelo en
cascada se sita en los documentos y productos desarrollados, el modelo en V se centra
en las actividades y la correccin.
Ventajas
La relacin entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la
localizacin de fallos.
Es un modelo sencillo y de fcil aprendizaje.
Hace explcito parte de la iteracin y trabajo que hay que revisar.
Especifica bien los roles de los distintos tipos de pruebas a realizar.
Involucra al usuario en las pruebas.
Inconvenientes
Es difcil que el cliente exponga explcitamente todos los requisitos.
El cliente debe tener paciencia pues obtendr el producto al final del ciclo de vida.
Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas.
El producto final obtenido puede que no refleje todos los requisitos del usuario.

3.2.3. Modelo iterativo

Este modelo, tambin conocido como Evolutivo, es una derivacin del ciclo de vida en
cascada puro, que busca reducir el riesgo que surge entre las necesidades del Usuario y
el Producto final por malos entendidos durante la etapa de solicitud de requerimientos.
En el ciclo de vida iterativo, en cada Iteracin se reproduce el ciclo de vida en cascada a
menor escala. Los objetivos de una Iteracin se establecen en funcin de la evaluacin de
las Iteraciones precedentes. Desde el principio, al final de cada Iteracin se le entrega al
Cliente una versin completa y mejorada del Producto. El Cliente es quien luego de cada
Iteracin evala el Producto y lo corrige o propone mejoras. Estas Iteraciones irn
Refinando el sistema y se repetirn hasta obtener un Producto que satisfaga al Cliente.
La especificacin de requisitos se realiza en forma creciente: a medida que los Usuarios
logran un mejor entendimiento del problema, ste es reflejado en el sistema software. Es
decir, el Producto de cada etapa de Especificacin de requisitos es un agregado o mejora
al Producto de la etapa de especificacin anterior.
Este modelo se basa en dos premisas:
1. Los Usuarios a menudo no saben bien lo que quieren o necesitan.
2. Por lo general, los requisitos en algn momento van a cambiar.
Para solucionar el primer punto, los requisitos se determinan en base a alguna forma
operacional del sistema (por ejemplo, un prototipo) para ser revisado por los usuarios.
Para atender el segundo punto, se realizan entregas parciales del sistema que permiten
incorporar nuevos requisitos o cambios en requisitos existentes en la siguiente entrega.
Es decir, cada versin es una mejora sobre la predecesora.
Este modelo se utiliza cuando no se puede especificar a priori todos los requisitos del
software, sino que el proceso ayudar a ir descubriendo paso a paso los requisitos a partir
de cada nueva Entrega.
Ventajas
No hace falta tener todos los requisitos al inicio del desarrollo, pero si se pueden ir
refinando o cambiando en el proceso.
Tiene las ventajas propias de realizar el desarrollo en pequeos ciclos, gestin de riesgos
ms exacto, y entregas.
Inconvenientes
Ya que al no requerirse los requisitos desde el principio se pueden presentar problemas
de infraestructura en el desarrollo.

3.2.4. Modelo de desarrollo incremental

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 puede aadir personal, de ser necesario. Por otro lado,
los incrementos se pueden planear para gestionar riesgos tcnicos.
Ventajas
Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
El usuario se involucra ms.
El resultado puede ser muy positivo.
Inconvenientes
Los errores en los requisitos se detectan tarde.
Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar
como un todo.
Requiere gestores experimentados.
Difcil de evaluar el coste total.

3.2.5. Modelo en espiral

EL Modelo Espiral, propuesto en 1988 por Barry Boehm, reconoce la naturaleza iterativa
del desarrollo y combina actividades de desarrollo con gestin de riesgo, para minimizar y
controlar el riesgo. Cada ciclo o iteracin de la espiral se divide en cuatro fases:
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 varias
alternativas propuestas para reducir o eliminar los riesgos
3. Desarrollar, verificar y validar (probar):
a) Tareas de la actividad propia y de prueba
b) Anlisis de alternativas e identificacin de resolucin de riesgos
c) Dependiendo del resultado de la evaluacin de riesgos, se elige un modelo
para el desarrollo, que puede ser cualquiera de los otros existentes, como
formal, evolutivo, cascada, etc. As, por ejemplo, si los riesgos de la interfaz de
usuario son dominantes, un modelo de desarrollo apropiado podra ser la
construccin 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.

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.
Adems, es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la
metodologa, ya que este ciclo de vida no es rgido ni esttico.
Inconvenientes
Genera mucho tiempo en el desarrollo del sistema.
Modelo costoso.
Requiere experiencia en la identificacin de riesgos.

3.2.6. 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.

Est dividido en varias etapas, las cuales listo a continuacin:

 1. Plan rpido.
2. Modelado, diseo rpido.
3. Construccin del Prototipo.
4. Desarrollo, entrega y retroalimentacin.
5. Comunicacin.
6. Entrega del desarrollo final.

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.
Se puede reutilizar el cdigo.
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.

3.3. ISO/IEC 12207

Que es, para que se cre y caractersticas.
La norma ISO 12207 fue creada con el propsito de establecer un marco comn para el
ciclo de vida del software para:

Adquirir, suministrar, desarrollar, operar y mantener software.

Gestionar, controlar y mejorar el marco de trabajo del software.
Como base para el comercio internacional de software.

Ya que el software es parte esencial de sistemas convencionales y de tecnologas de la

informacin, tales como sistemas de transporte, militares, mdico y financiero. Hay una
proliferacin de normas, procedimientos, mtodos, herramientas y entornos para
desarrollar y gestionar el software. Esta proliferacin ha creado dificultades en la gestin y
en la ingeniera del software, especialmente en la integracin de productos y servicios.
Este marco de referencia cubre el ciclo de vida del software desde la conceptualizacin de
ideas hasta su retirada, y consta de procesos para adquirir y suministrar productos y
servicios software. Cubre adems el control y la mejora de estos procesos. Los procesos
que hay en esta norma forman un conjunto completo. Una organizacin, dependiendo de
sus necesidades, puede seleccionar un subconjunto apropiado para satisfacer dichas
necesidades.
Como se aplica
Es la primera norma internacional que proporciona un conjunto completo de procesos
para la adquisicin y el suministro de productos y servicios de software. Abarca aspectos
tcnicos y comerciales, y se aplica a los compradores, proveedores, desarrolladores,
operadores y personal de mantenimiento.
La norma est destinada primordialmente a aplicarse en el contexto de un contrato de dos
partes; la estructura de la norma est concebida de manera flexible y modular de manera
que pueda ser adaptada a las necesidades de cualquiera que la use. Debido a que fue
concebida bajo dos preceptos que son su base los cuales son modularidad y
responsabilidad.
Ventajas
Se aplica a gran parte del medio de software.
Describe ampliamente la arquitectura de los procesos, as como los procesos de un ciclo
de vida del software.
Se puede aplicar mediante poltica interna de una organizacin para mejorar sus prcticas
y procesos de software.
Desventajas
Una limitacin potencialmente importante es que no pretende ser aplicable a la
adquisicin de productos de software.
Es un bastante divagante con respecto a las actividades o tareas de los procesos.
Como tal no permite ser implementada obligatoriamente a los procesos generales.

4. METODOLOGAS DE DESARROLLO DE SOFTWARE

Ya que el desarrollo de software es una labor tan cambiante y complicada, se han
desarrollado cantidad de propuestas para que se facilite el proceso, que inciden en
distintas dimensiones del proceso de desarrollo, por un lado, tenemos propuestas
tradicionales que se centran especialmente en el control del proceso, estableciendo
rigurosamente las actividades involucradas, los artefactos que se deben producir, y las
herramientas y notaciones que se usarn, las cuales han demostrado ser efectivas y
adems necesarias, para mltiples proyectos, pero tambin han presentado problemas en
muchos otros, se han introducido mejoras tales como, incluir en los procesos de
desarrollo ms actividades, ms artefactos y ms restricciones, basndose en los puntos
dbiles detectados, pero el resultado final sera un proceso de desarrollo ms complejo
que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto.
Otra solucin es centrarse en el factor humano o el producto software, nombradas como
metodologas giles, las cuales dan mayor protagonismo al individuo, a la colaboracin
con el cliente y al desarrollo incremental del software con iteraciones muy cortas, esta
forma de ver las cosas tambin ha demostrado su efectividad en proyectos con requisitos
muy cambiantes y cuando se exige reducir los tiempos de desarrollo, pero al tiempo
manteniendo una alta calidad.
Las metodologas giles estn revolucionando la manera de producir software, y a la vez
generando un amplio debate entre sus seguidores y quienes por escepticismo o
convencimiento no las ven como alternativa para las metodologas tradicionales, por lo
tanto, un objetivo trazado ha sido el de encontrar procesos y metodologas, que sean
sistemticas, predecibles y repetibles, esto con el objetivo de mejorar tanto en
productividad en el desarrollo, como en la calidad del producto software.
El avance de la ingeniera del software ha generado propuestas diferentes para mejorar
los resultados del proceso de construccin, por su lado las metodologas tradicionales
hacen expreso inters y foco en la planificacin y las metodologas giles en la
adaptabilidad del proceso.

4.1. Definicin de metodologa

La metodologa para el desarrollo de software se define como un conjunto de mtodos y
tcnicas orientadas a manejar las actividades del ciclo de vida del software de manera
homognea y abierta.
Lo que quiero decir con esto es que, se busca adquirir la capacidad para poder realizar,
gestionar y administrar un proyecto de desarrollo y generar altas posibilidades de
culminarlo con xito.
Comprende los procesos a seguir de manera sistemtica para el desarrollo de un
software, desde su inicio hasta que se cumple el objetivo con el cual es creado en primera
instancia, de esta manera podemos decir que una metodologa de desarrollo de software
optimiza el proceso y el producto final (software), genera los mtodos que guan la
planificacin y el desarrollo y define el que, como, cuando durante el desarrollo del
producto. Dentro de las tareas que vale la pena destacar se encuentra, la definicin de las
fases, los productos de cada fase, los procedimientos y herramientas que se deben
utilizar, y los criterios de evaluacin y de calidad que se deben revisar en el proceso y en
el producto.
Una metodologa de desarrollo tambin est compuesta por un marco de trabajo, y
consiste en los siguientes aspectos, una filosofa de desarrollo, enfocada al proceso de
desarrollo del software, y las mltiples herramientas, modelos y mtodos de trabajo que
ayudan en el proceso de desarrollo de software, llamados marcos de trabajo, los cuales
por lo general estn asociados a algunos tipos de organizaciones, que se encargan del
desarrollo, soporte, uso y promocin de la metodologa, con frecuencia es documentada
de manera formal.

4.2. Ventajas del uso de una metodologa

Son muchsimas las ventajas que se pueden obtener con el uso de una metodologa de
desarrollo de software, veremos algunas brevemente desde diferentes puntos de vista.
Desde el punto de vista de la gestin,
Facilitan la tarea de planificacin, control y seguimiento, mejoran la relacin
coste/beneficio, optimiza las gestin y uso de los recursos, facilita la evaluacin de los
resultados y el cumplimiento de los objetivos, y facilita la comunicacin entre usuarios y
desarrolladores.
Desde el punto de vista de un ingeniero de software,
Ayudan a la compresin del problema, optimizan las fases del proyecto individualmente y
en conjunto, facilitan el mantenimiento, permite la reutilizacin de cdigo.
Desde el punto de vista del cliente,
Garanta de un buen nivel de calidad (previamente determinado), confianza en la
planeacin del proyecto, tiempos, etc., y define el ciclo de vida idneo para el desarrollo
del proyecto.

4.3. Metodologas tradicionales y giles

Segn las filosofas del desarrollo, podemos definir las metodologas de desarrollo en dos
grupos, el primero es la de la metodologa tradicional y el segundo es la de la metodologa
gil.
Metodologas tradicionales,
Las metodologas tradicionales imponen una disciplina de trabajo sobre el proceso de
desarrollo del software, con el fin de conseguir un software ms eficiente. Para ello, se
hace nfasis en la planificacin total de todo el trabajo a realizar y una vez que est todo
detallado, comienza el ciclo de desarrollo del producto software. Se centran
especialmente en el control del proceso, mediante una rigurosa definicin de roles,
actividades, artefactos, herramientas y notaciones para el modelado y documentacin
detallada. Adems, las metodologas tradicionales no se adaptan adecuadamente a los
cambios, por lo que no son mtodos adecuados cuando se trabaja en un entorno, donde
los requisitos no pueden predecirse o bien pueden variar.
Metodologas agiles,
Un modelo de desarrollo gil, generalmente es un proceso Incremental, (pequeos y
frecuentes releases o entregas con ciclos rpidos), tambin Cooperativo (Clientes y
desarrolladores trabajan constantemente con una comunicacin muy fina y constante),
sencillo (El mtodo es fcil de aprender y modificar para el equipo, es bien documentado
por medio de libros o la Web) y finalmente adaptativo (capaz de permitir cambios de
ltimo momento).
Las metodologas giles proporcionan una serie de pautas y principios junto a tcnicas
pragmticas que puede que no curen todos los males, pero harn la entrega del proyecto
menos complicada y ms satisfactoria tanto para los clientes como para los equipos de
entrega.

TRADICIONAL AGIL
El cliente delega su responsabilidad Individuos e interacciones
Castigo y penalizacin Colaboracin: Beneficio comn
Competicin: Beneficio individual Trabajo en equipo
Evaluacin individual Flujo de valor continuo
Puntas de trabajo desequilibradas Retencin de talento
Baja motivacin del equipo El cliente se involucra en el proceso
Responsabilidad asignada Comunicacin directa
Especialidad Responsabilidad adquirida por
compromiso
Equipos grandes Multifuncionalidad
Equipos pequeos
 GLOSARIO

1. Paradigma:
Un paradigma de programacin es una propuesta tecnolgica adoptada por una
comunidad de programadores y desarrolladores cuyo ncleo central es
incuestionable en cuanto que nicamente trata de resolver uno o varios problemas
claramente delimitados; la resolucin de estos problemas debe suponer
consecuentemente un avance significativo en al menos un parmetro que afecte a
la ingeniera de software.
2. Iteracin:
Iteracin significa el acto de repetir un proceso con la intencin de alcanzar una
meta deseada, objetivo o resultado. Cada repeticin del proceso tambin se le
denomina una "iteracin", y los resultados de una iteracin se utilizan como punto
de partida para la siguiente iteracin.
3. Prototipo:

Los prototipos son una representacin limitada de un producto, permite a las

partes probarlo en situaciones reales o explorar su uso, creando as un proceso de
diseo de iteracin que genera calidad. Un prototipo puede ser cualquier cosa,
desde un trozo de papel con sencillos dibujos a un complejo software.

4. Modularidad:
Es la capacidad que tiene un sistema de ser estudiado, visto o entendido como la
unin de varias partes que interactan entre s y que trabajan solidariamente para
alcanzar un objetivo comn, realizando cada una de ellas una tarea necesaria para
la consecucin de dicho objetivo.
 CONCLUSIONES

1. En el mundo del desarrollo de software, tenemos mltiples herramientas

que con el tiempo se han desarrollado para poder realizar mejor nuestro
trabajo y brindarles a nuestros proyectos una amplia posibilidad de xito.
2. La mayora de metodologas usadas como modelo en el ciclo de desarrollo
de software tienen una gran capacidad de brindarnos las herramientas que
necesitamos para casi garantizar el xito de un proyecto, pero usadas
indebidamente y sin responsabilidad seguro nos pueden llevar al fracaso
tambin.
3. En el mundo del desarrollo de software no existe una frmula mgica para
llevar con xito a cabo un proyecto, pero las herramientas que elegimos y el
cmo las usamos nos dan un plus para poder hacerlo, claro si son usadas
correctamente.
 BIBLIOGRAFIA

Ivar Jacobson, Grady Booch y James Rumbaugh, The Unified Software Development
Process (1999)

Mitchel H. Levine, Analyzing the Deliverables Produced in the Software Development Life
Cycle (2000)

SELECTING A DEVELOPMENT APPROACH. Revalidated: March 27, 2008. Retrieved 27

Oct 2008.

Sitios Web

Metodologas giles para el desarrollo de software: eXtreme Programming

http://www.cyta.com.ar/ta0502/v5n2a1.htm

Metodologa de desarrollo de software

https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software

Conceptos de programacin en el mbito de la integracin de Common Language

Runtime (CLR)

https://msdn.microsoft.com/es-es/library/ms131102.aspx