NECESIDAD

METODOLOGIA

DE

UNA

El levantamiento de requerimientos no estaba estandarizado y los errores que

surgan tanto del cdigo como de los requerimientos que se les peda a los
clientes se iban arreglando en el camino.

DEFINICION
METODOLOGA

DE

UNA

La metodologa para el desarrollo de software es un modo sistemtico para

realizar, gestionar y administrar un proyecto para llevarlo a cabo con altas
posibilidades de xito.
La sistematizacin divide un gran proyecto en etapas. Cada una de las etapas
tiene especificada ciertas acciones. En cada etapa se definen sus entradas y
salidas.

OBJETIVO DE CADA ETAPA

Expresin de necesidades: Su objetivo es armar un documento donde estn
los requerimientos y funcionalidades que ofrecer el sistema (qu, y no cmo,
se va a implementar)
Especificaciones: Se formaliza el documento y se tomar como punto de
partida.
Anlisis: Tendremos una descripcin clara de que sistema construiremos, sus
funcionalidades y comportamiento.
Diseo: Sabiendo qu haremos, pasamos a cmo lo haremos. Cmo debe ser
construido el sistema en cuestin? Definimos en detalles entidades y relaciones
en la base de datos, seleccionamos en lenguaje que vamos a utilizar, el
Sistema Gestor de Base de Datos, etc.
Implementacin: Empezamos a codificar algoritmos y estructuras de datos
en el correspondiente lenguaje de programacin.
En muchos proyectos se pasa directamente a esta etapa, son proyectos
arriesgados que adoptan el ciclo de vida code & fix (codificar y corregir) donde
se eliminan las etapas de especificaciones, anlisis y diseo con la
consiguiente prdida de control sobre la gestin del proyecto.

Debugging: Su objetivo es garantizar que el programa no contiene errores. No

ve que la funciones del sistemas se realicen (le corresponde a implementacin)
sino que busca los errores. Todo los sistemas los tienen y esta etapa trata de
encontrar la mayor cantidad de ellos.
Validacin: Su objetivo es verificar que el programa cumpla con los
requerimientos definidos al principio.
Debugging y Validacin algunas veces se realizan en paralelo por su semejanza
pero aun asi no hay que confundirlos.
Evolucin: Tambin conocida como Mantenimiento. Agrega funcionalidades
(evolucin) o corrige errores (mantenimiento).

CLASIFICACIN
METODOLOGAS

DE

LAS

M. Estrucutrada: Las funciones del programa se descomponen en piezas ms

pequeas.
M. Orientada a Objetos: Arma mdulos basados en componentes, es decir,
cada componente es independiente del otro.
Permite que el cdigo sea reutilizable.
Modelo de desarrollo de software: es una representacin simplificada del
proceso para el desarrollo de software, presentada desde una perspectiva
especfica.
Metodologa de desarrollo de software: es un enfoque estructurado para
el desarrollo de software que incluye modelos de sistemas, notaciones, reglas,
sugerencias de diseo y guas de procesos.

Modelos para el desarrollo de software

stos modelos generales no son descripciones definitivas de los procesos del
software ms bien son abstracciones de los procesos que se pueden utilizar
para el desarrollo del software. Puede pensarse en ellos como marcos de
trabajo del proceso y que pueden ser adaptados para crear procesos ms
especficos.
-CASCADA
-SASHIMI
-CASCADA CON SUBPROYECTOS
-ITERATIVO
-PROTOTIPADO

-INCREMENTAL
-ESPIRAL

CASCADA
Modelo en cascada
Es un proceso secuencial, fcil de desarrollo en el que los pasos de desarrollo
son vistos hacia abajo (como en una cascada de agua) a travs de las fases de
anlisis de las necesidades, el diseo, implantacin, pruebas (validacin), la
integracin y mantenimiento.
Los principios bsicos del modelo de cascada son los siguientes:

El proyecto est dividido en fases secuenciales, con cierta superposicin

y splashback aceptable entre fases.

Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y

ejecucin de todo un sistema de una sola vez.

Un estricto control se mantiene durante la vida del proyecto a travs de

la utilizacin de una amplia documentacin escrita, as como a travs de
comentarios y aprobacin / signoff por el usuario y la tecnologa de la
informacin de gestin al final de la mayora de las fases antes de
comenzar la prxima fase.

Sus principales etapas se transforman en actividades fundamentales del

desarrollo:
1) Anlisis y definicin de requerimientos. Los servicios restricciones y metas
del sistema se definen a partir de las consultas con los usuarios. Entonces, se
definen en detalle y sirven de manera especfica al sistema.
2) Diseo del sistema y del software. El proceso de diseo del sistema divide
los requerimientos en sistemas ya sea hardware. Establece una arquitectura
completa del sistema, el diseo del software identifique describe los elementos
abstractos que son fundamentales para el software y sus relaciones.
3) Implementaciones prueba de unidades. Durante esta etapa el diseo del
software se lleva a cabo como un conjunto de unidades de programas, la
prueba de unidades implica verificar que cada una cumpla con su funcin
especfica.
4) Integracin y prueba del sistema. Los programas o las unidades individuales
de programas se integran y se prueban como un sistema completo para as
asegurar que se cumplan los requerimientos del software, despus se entrega
al
cliente.
5) Funcionamiento y mantenimiento. En esta fase el sistema se instala y se

pone en funcionamiento prctico el mantenimiento implica corregir errores no

descubiertos en las etapas anteriores del ciclo de vida, mejorar la
implementacin de las unidades del sistema y resaltar los servicios del sistema
una vez que se descubren en nuevos requerimientos.

Es un ciclo de vida que admite iteraciones, contrariamente a la creencia de que

es un ciclo de vida secuencial como el lineal.
Despus de cada etapa se realiza una o varias revisiones para comprobar si se
puede pasar a la siguiente. Es un modelo rgido, poco flexible, y con muchas
restricciones.
Ventaja: Adems de su planificacin sencilla, es la de proveer un producto con
un elevado grado de calidad sin necesidad de un personal altamente calificado.
Adecuado para proyectos en que los requerimientos estn al comienzo.
Desventajas: la necesidad de contar con todos los requerimientos (o la
mayora) al comienzo del proyecto, y, si se han cometido errores y no se
detectan en la etapa inmediata siguiente, es costoso y difcil volver atrs para
realizar la correccin posterior.
Al final del ciclo veremos el proyecto terminado, cualquier error nos puede
retrasar.
Es ms terico porque raramente un usuario mantiene sus requerimientos igual
que al principio.

Tipo Sashimi
-Parecido al cascada puro pero con las etapas solapadas.
-Su nombre viene de la presentacin del pescado crudo cortado, en que sus
partes se solapan entre s.
Ventajas: Mejora la calidad. No hace falta una documentacin detallada (por el
solapado de las etapas).
Desventajas: Por ser solapado, es difcil gestionar el comienzo y fin de cada
etapa.

Cascada con subproyectos

- Las cascadas se realizan en paralelos.

Ventajas: Varias personas trabajando

Desventajas: Pueden surgir dependencias en los proyectos que puedan
detener su desarrollo si no se gestiona correctamente.

Iterativo

Derivado del cascada

requerimientos.

puro.

Intenta

reducir

el

desacuerdo

de

los

Es repetir el ciclo de vida varias veces (iterativo). En cada iteracin se entrega

al cliente una versin mejorada o con mayores funcionalidades (por lo tanto no
completa).
Al final de cada iteracin el cliente propone mejoras o corrige.
Se repiten hasta que el cliente este satisfecho.
Utilizado cuando los requerimientos no estn claros por parte del usuario. Por
eso es necesaria la construccin de varios prototipos para presentarlos y
obtener la conformidad con el cliente.
Proyecto ideal
Cuando se hacen migraciones a otras estructuras. Para aplicaciones medianas
a grandes. Y que no se necesitan todas las funcionalidades al mismo tiempo.

Prototipado

El prototipado permite desarrollar modelos de aplicaciones de software que

permiten ver la funcionalidad bsica de la misma, sin necesariamente incluir
toda la lgica o caractersticas del modelo terminado. El prototipado permite al
cliente evaluar en forma temprana el producto, e interactuar con los
diseadores y desarrolladores para saber si se est cumpliendo con las
expectativas y las funcionalidades acordadas. Los Prototipos no poseen la
funcionalidad total del sistema pero si condensa la idea principal del mismo,
Paso a Paso crece su funcionalidad, y maneja un alto grado de participacin del
usuario.
**************

El uso de programas prototipo no es exclusivo del ciclo de vida iterativo.

En la prctica los prototipos se utilizan para validar los requerimientos de los
usuarios en cualquier ciclo de vida.
Es necesario evaluar si el esfuerzo por hacer prototipos vale la pena.
Ventaja: Unico apto para las ocasiones en que no se conoce las
especificaciones o la tecnologa a utilizar.
Desventaja: Por este desconocimiento, es costoso y difcil de administrar
temporalmente.

Proyecto ideal
Productos con innovaciones importantes
En tecnologas nuevas o poco probadas, en que la incertidumbre del resultado
impide un desarrollo secuencial.
Migrar aplicaciones a otras tecnologas

Incremental

Provee una estrategia para controlar la complejidad y los riesgos, desarrollando

una parte del producto software reservando el resto de aspectos para el futuro.
Los principios bsicos son:

Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la

cascada modelo de desarrollo se han completado para una pequea
parte de los sistemas, antes de proceder a la prxima incremental.

Se definen los requisitos antes de proceder con lo evolutivo, se realiza

una mini-Cascada de desarrollo de cada uno de los incrementos del
sistema.

El concepto inicial de software, anlisis de las necesidades, y el diseo

de la arquitectura y colectiva bsicas se definen utilizando el enfoque de
cascada, seguida por iterativo de prototipos, que culmina en la
instalacin del prototipo final.

*************************************
Objetivos:
-Construir aumentando las funcionalidades del sistema (crear una por una)
-Construccin de mdulos que cumplen cada funcin. (cada miembro del
equipo construye uno)
-Se diferencia del iterativo en que: Se van aadiendo las partes (cada funcin)
a la anterior. Al final de cada ciclo se entrega una nueva funcionalidad.

Ventajas:
Construir un sistema pequeo siempre es menos riesgoso que construir un
sistema grande.

 Como desarrollamos independientemente las funcionalidades, es ms fcil

relevar los requerimientos del usuario.
Si se detecta un error grave, slo desechamos la ltima iteracin.
No es necesario disponer de los requerimientos de todas las funcionalidades
en el comienzo del proyecto
Proyecto ideal
-Cualquiera, especialmente para proyectos que se deban entregar rpido
aunque sean parciales.

Espiral (?)
Ventajas: Se puede comenzar un proyecto con algo grado de incertidumbre.
Bajo riesgo de retraso en caso de deteccin de errores (se pueden resolver en
la prxima rama de la espiral)
Desventajas: Cada vuelta en la espiral suma tiempo.
Dificultad para evaluar los riesgos
Comunicacin continua con el cliente o usuario
Proyecto ideal
-Grandes proyectos internos en los que los requerimientos no estn disponibles
al principio y el usuario est en nuestro entorno laboral.
******************************

Planificacin: Relevamiento de requerimientos iniciales o luego de una

iteracin.
Anlisis de riesgo: De acuerdo con el relevamiento de requerimientos
decidimos si continuamos con el desarrollo.
Implementacin: desarrollamos un prototipo basado en los requerimientos.
Evaluacin: El cliente evala el prototipo, si da su conformidad, termina el
proyecto. En caso contrario, incluimos los nuevos requerimientos solicitados
por el cliente en la siguiente iteracin.

El modelo en espiral es un modelo de proceso de software evolutivo que

conjuga la naturaleza iterativa de la construccin de prototipos con los
aspectos controlados y sistemticos del modelo en cascada. Cuando se aplica
este modelo en espiral, el software se desarrolla en una serie de entregas
evolutivas. Cada una de las actividades del marco de trabajo representan un
segmento
de
la
ruta
en
espiral.
Este modelo se basa en la idea de desarrollar una implementacin inicial,
exponindola a los comentarios del usuario y refinndola a travs de las
diferentes versiones que se generan hasta que se desarrolle un sistema
adecuado.
Las actividades de especificacin, desarrollo y validacin se entrelazan en vez
de separarse, con una rpida retroalimentacin entre estas. Existen dos tipos
de
desarrollo
evolutivo:
1) Desarrollo exploratorio, en este caso 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, el objetivo de este proceso de desarrollo evolutivo
es comprender los requerimientos del cliente para as desarrollar una definicin
mejorada de los requerimientos para el sistema. El prototipo se centra en
experimentar los requerimientos del cliente que no se comprenden del todo.
Haciendo referencia a la produccin del software, un enfoque evolutivo suele
ser ms efectivo que el enfoque en cascada, ya que satisface las necesidades
inmediatas de los clientes. La ventaja de un software que se basa en un
enfoque evolutivo es que las especificaciones se pueden desarrollar de forma
creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de
su problema, esto se puede reflejar en el software. Sin embargo, desde la
perspectiva de ingeniera y de gestin, el enfoque evolutivo tiene dos

problemas:
1) El proceso no es visible. Esto significa que los administradores tienen
que hacer entregas regulares para medir el progreso del producto. Si los
sistemas se desarrollan rpidamente, no es rentable producir documentos
que
reflejen
cada
versin
del
sistema.
2) A menudo los sistemas tienen una estructura deficiente. Esto hace
referencia que los cambios continuos tienden a corromper la estructura del
software. Incorporar cambios en l se convierte cada vez ms en una tarea
difcil y costosa.
Para sistemas pequeos y de tamao medio (hasta 500,000 lneas de
cdigo), el enfoque evolutivo de desarrollo es el mejor. Los problemas del
desarrollo evolutivo se hacen particularmente agudos para sistemas
grandes y complejos con un perodo de vida largo, donde diferentes
equipos desarrollan distintas partes del sistema. Es difcil establecer una
arquitectura del sistema usando este enfoque, ya que hace difcil integrar
las contribuciones de los equipos. Para sistemas grandes se recomienda un
proceso mixto es decir que incorpore las mejores caractersticas del
modelo en cascada y del desarrollo evolutivo. Esto implica desarrollar un
prototipo desechable, utilizando un enfoque evolutivo para resolver
incertidumbres en la especificacin del sistema. Puede entonces no
implementarse utilizando un enfoque ms estructurado.

Las principales metodologas giles

- SCRUM. Es un marco de trabajo que nos proporciona una serie de
herramientas y roles para, de una forma iterativa, poder ver el progreso y los
resultados de un proyecto.
- KANBAN. Se basa en una idea muy simple. sta es que el trabajo en curso
(Work In Progress, WIP) debera limitarse y slo deberamos empezar con algo
nuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a
otra funcin posterior de la cadena.
- XP: Es una metodologa gil centrada en potenciar las relaciones
interpersonales como clave para el xito en desarrollo de software,
promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los
desarrolladores y propiciando un buen clima de trabajo.