METODOLOGIAS DE

DESARROLLO DE SOFTWARE
TRADICIONALES

INTRODUCCION
Desarrollar software implica muchas
cosas, desde su planificacin hasta la
puesta en marcha se deben de seguir un
sinnmero de pasos o actividades. Hoy
en da existen diversas metodologas para
hacerlo, sin embargo es necesario definir
primero la naturaleza del software antes
de elegir un determinado ciclo de vida.
Al inicio el desarrollo de software era
artesanal en su totalidad, la fuerte
necesidad de mejorar el proceso y llevar
los proyectos a la meta deseada,
tuvieron que importarse la concepcin y
fundamentos de metodologas existentes
en otras reas y adaptarlas al desarrollo
de software. Esta nueva etapa de
adaptacin contena el desarrollo
dividido en etapas de manera secuencial
que de algo mejoraba la necesidad
latente en el campo del software.
Las metodologas tradicionales (formales)
se focalizan en documentacin,
planificacin y procesos. (Plantillas,
tcnicas de administracin, revisiones,
etc.),
Metodologas tradicionales
Metodologas tradicionales
RUP
Es un proceso formal:
Provee un
acercamiento
disciplinado para
asignar tareas y
responsabilidades
dentro de una
organizacin de
desarrollo.
MSF
Es un compendio de las
mejores prcticas en
cuanto a administracin
de proyectos se refiere.
Ms que una metodologa
rgida de administracin
de proyectos, MSF es una
serie de modelos que
puede adaptarse a
cualquier proyecto de
tecnologa de
informacin.
RUP
(RATIONAL UNIFIED PROCESS)
Fases
Las cuatro fases
del ciclo de vida
son:
Concepcin
Elaboracin
Construccin
Transicin

RUP
Concepcin
Su objetivo es la comunicacin con
el cliente y las actividades de
planeacin. Se establece
el caso del negocio para el sistema,
as como la identificacin de todas
las entidades externas que
interactan con el sistema y sus
respectivas iteraciones.
Elaboracin
Tiene como fin desarrollar un
entendimiento del dominio del
problema,
crear un marco de trabajo
arquitectnico
para el sistema, desarrollar el plan
del proyecto e identificar los riesgos
claves. Al finalizar esta fase se debe
tener el modelo de requerimientos
del sistema (UML), una arquitectura
y un plan de desarrollo.






Construccin
Su objetivo es el diseo
del sistema, la programacin, las
pruebas y
la integracin de todas las partes
del sistema
software. Al final de esta fase se
debe tener
un software operativo con su
respectiva documentacin.
Transicin
En esta fase el sistema software
se entrega a los usuarios finales para
sus respectivas
pruebas en un entorno real. Al
terminar esta
fase se debe tener un software
documentado y
funcionando correctamente.
RUP
(El ciclo de vida)
se puede apreciar que el
ciclo de vida de RUP est
comprendido por varios
ciclos. Las versiones y
ciclos le aaden
funcionalidad al sistema
hasta el punto donde ya
termine su ciclo de vida
con la muerte o
cumplimiento total del
objetivo para el cual fue
diseado el software.

RUP
VENTAJAS
Evaluacin en cada
fase que permite
cambios de objetivos
Funciona bien en
proyectos de
innovacin.
Es sencillo, ya que sigue
los pasos intuitivos
necesarios a la hora de
desarrollar el software.
Seguimiento detallado
en cada una de las
fases.
DESVENTAJAS
La evaluacin de
riesgos es compleja
Excesiva flexibilidad
para algunos
proyectos
Nuestro cliente deber
ser capaz de describir
y entender a un gran
nivel de detalle para
poder acordar un
alcance del proyecto
con l.


MSF
(MICROSOFT SOLUTION FRAMEWORK)
Es un compendio de las mejores prcticas
en cuanto a administracin de proyectos se
refiere. Ms que una metodologa rgida de
administracin de proyectos, MSF es una
serie de modelos que puede adaptarse a
cualquier proyecto de tecnologa de
informacin.
MSF
(MICROSOFT SOLUTION FRAMEWORK)
Caractersticas de MSF
ste Framework est basado en los modelos espiral
y cascada, lo cual indica que toma elementos de
los mtodos tradicionales que an son referentes
importantes para procesos de software. Es adaptable,
flexible y escalable, e independiente de tecnologas,
lo cual significa que no se cierra a un slo modelo de
programacin sino ms bien queda abierto segn la
naturaleza del proyecto. Usa como referente el DSL
(Domain-Specific Language) para realizar el
modelado,
as como RUP se apoya en UML para hacer el
modelado (Microsoft).
MSF
Todo proyecto es
separado en cinco
principales fases:

Visin y Alcances.
Planificacin.
Desarrollo.
Estabilizacin.
Implantacin.

MSF
Visin y alcances
Se debe tener el objetivo y
limitaciones del proyecto, el
anlisis de los problemas de
negocios,
el mbito de la aplicacin, la
evaluacin del
riesgo y panificacin del
producto.
Planificacin
Se debe tener la ingeniera de
requerimientos, planificacin y
gestin de riesgos.







Desarrollo
En esta fase se codifica y se
realizan
las respectivas pruebas,
tambin se identifican y
mitigan los riesgos existentes.
Estabilizacin
Se realizan pruebas beta, se
crea un plan de gestin de
incidencias, se revisa la
documentacin final de la
arquitectura y se elabora
un plan de despliegue.
MSF
Implantacin
Se libera la solucin software,
se crea un registro de mejoras y
sugerencias, se revisan
las guas y manuales de usuario
y se entrega el
proyecto final.

El proceso del MSF se
puede llevar a cabo de
forma iterativa, de tal
forma que al liberar una
solucin, se puede iniciar
nuevamente la
metodologa para darle
ms funcionalidad al
producto




MOF
(Microsoft Operation Framework)
El modelo de
proceso MOF est
formado por
cuadrantes,
revisiones de la
administracin de
las operaciones y
revisiones de la
administracin de
los servicios
DIFERENCIAS ENTRE LAS METODOLOGIAS
TRADICIONALES VS AGILES
TRADICIONALES
Basadas en normas provenientes de
estndares seguidos por el entorno de
desarrollo
Cierta resistencia a los cambios
Impuestas externamente
Proceso mucho ms controlado, con
numerosas polticas/normas
El cliente interacta con el equipo de
desarrollo mediante reuniones
Grupos grandes y posiblemente
distribuidos
La arquitectura del software es
esencial y se
expresa mediante modelos

AGILES
Basadas en heursticas provenientes
de prcticas de produccin de
cdigo
Especialmente preparados para
cambios durante el proyecto
Impuestas internamente (por el
equipo)
Proceso menos controlado, con pocos
principios.
El cliente es parte del equipo de
desarrollo
Grupos pequeos (<10 integrantes) y
trabajando en el mismo sitio
Menos nfasis en la arquitectura del
software