METODOLOGÍA TRADICIONAL

3. Estas metodologías tradicionales imponen una
disciplina de trabajo sobre el proceso de desarrollo del
software, con el fin de conseguir un software más
eficiente. Para ello, se hace énfasis en la planificación
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 definición de roles,
actividades, artefactos, herramientas y notaciones para
el modelado y documentación detallada.
Además, las metodologías tradicionales no se adaptan
adecuadamente a los cambios, por lo que no son
métodos adecuados cuando se trabaja en un entorno,
donde los requisitos no pueden predecirse o bien
pueden variar.

5. RUP
El Proceso Unificado de
Rational

6. +
Es un proceso de desarrollo de software Constituye la metodología
estándar más utilizada para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos.
El Proceso Racional Unificado es un proceso de desarrollo de
software desarrollado por la empresa Rational Software,
actualmente propiedad de IBM. Junto con el Lenguaje Unificado
de Modelado UML, constituye la metodología estándar más
utilizada para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos. El RUP no es un
sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada
organización.

7. Las cuatro fases del ciclo de vida son:
Ø CONCEPCIÓN: El objetivo es
determinar la visión del proyecto y definir
lo que se desea realizar.
Ø ELABORACIÓN: Etapa en la que se
determina la arquitectura óptima del
proyecto.
Ø CONSTRUCCIÓN: Se obtiene la
capacidad operacional inicial.
Ø TRANSICIÓN: Obtener el producto
acabado y definido.

8. Evaluación en cada fase que
permite cambios de objetivos.
Funciona bien en proyectos de
innovación.
Es sencillo, ya que sigue los pasos
intuitivos necesarios a la hora de
desarrollar el software.
Seguimiento detallado en cada
una de las fases.
La evaluación de riesgos es
compleja.
Excesiva flexibilidad para algunos
proyectos.
Estamos poniendo a nuestro
cliente en una situación que puede
ser muy incómoda para él.
Nuestro cliente deberá ser capaz
de describir y entender a un gran
nivel de detalle para poder acordar
un alcance del proyecto con él.

9. MICROSOFT SOLUTIONS FRAMEWORK
Proceso en MSF
ComponentesMSFPropuesta
ProblemaActual
Microsoft Solutions Framework (MSF) puede ser una herramienta
eficaz para las organizaciones que desean desarrollar de manera
rápida soluciones tecnológicas de alta calidad y relevantes para el
negocio. Su flexibilidad permite adaptarlo de manera sencilla a la
mayoría de proyectos tecnológicos, lo que ayuda a los equipos a
comunicarse y coordinar las actividades más importantes.

10. Microsoft® Solutions Framework es un marco
de trabajo de referencia para construir e
implantar sistemas empresariales distribuidos
basados en herramientas y tecnologías de
Microsoft. MSF

11. •Alinear los objetivos de negocio y de tecnología
•Establecer de manera clara los objetivos, los
roles y las responsabilidades
•Implementar un proceso iterativo controlado
por hitos o puntos de control
•Gestionar los riesgos de manera proactiva
•Responder con eficacia ante los cambios

12. DISCIPLINAS EN MSF
Identificar
prioridades
controlar
emergencias
y tomar la
mejor
decisión
Planificar entregas
cortas
Registrar y
hacer
evidentes
los cambios
Identificar
cambios
ajustados al
cronograma
Incorporar
nuevas
características
1
3
•GESTIÓN DE PROYECTOS
•CONTROL DE RIESGOS
•CONTROL DE CAMBIOS

13. Modelo del Proceso en MSF
VISIÓN
PLANEACIÓN
DESARROLLO
ESTABILIZACIÓN
IMPLANTACIÓN
Todo proyecto es separado en cinco principales fases:

14. MODELO DEL PROCESO
EN MSF
La fase de visión y alcances trata uno de los requisitos más
fundamentales para el éxito del proyecto, la unificación del
equipo detrás de una visión común. El equipo debe tener una
visión clara de lo que quisiera lograr para el cliente y ser capaz
de indicarlo en términos que motivarán a todo el equipo y al
cliente. Se definen los líderes y responsables del proyecto,
adicionalmente se identifican las metas y objetivos a alcanzar;
estas últimas se deben respetar durante la ejecución del
proyecto en su totalidad, y se realiza la evaluación inicial de
riesgos del proyecto.

15. Es en esta fase es cuando la mayor
parte de la planeación para el proyecto
es terminada. El equipo prepara las
especificaciones funcionales, realiza el
proceso de diseño de la solución, y
prepara los planes de trabajo,
estimaciones de costos y cronogramas
de los diferentes entregables del
proyecto.
MODELO DEL PROCESO
EN MSF
Durante esta fase el equipo realice la
mayor parte de la construcción de los
componentes (tanto documentación
como código), sin embargo, se puede
realizar algún trabajo de desarrollo
durante la tapa de estabilización en
respuesta a los resultados de las
pruebas. La infraestructura también es
desarrollada durante esta fase.

16. En esta fase se conducen
pruebas sobre la solución, las
pruebas de esta etapa
enfatizan el uso y operación
bajo condiciones realistas. El
equipo se enfoca en priorizar
y resolver errores y preparar
la solución para el
lanzamiento.
MODELO DEL PROCESO
EN MSF
Durante esta fase el equipo
implanta la tecnología base y los
componentes relacionados,
estabiliza la instalación, traspasa
el proyecto al personal soporte y
operaciones, y obtiene la
aprobación final del cliente.

17. 1.Fomente las comunicaciones abiertas.
2.Trabaje hacia una visión compartida.
3.Autorización para los miembros del equipo.
4.Establezca la responsabilidad clara y responsabilidad
compartida.
5.Entregue el valor incremental. La entrega de valor
incremental tiene dos facetas:
♣ Asegúrese de que lo que se entrega tiene un
valor óptimo para las partes interesadas.
♣ Determine los incrementos óptimos en los que
entregar valor o “frecuencia de entrega”.
6.Manténgase ágil, expectante y adáptese a los cambios.
7.Invierta en calidad
8.Aprenda de todas las experiencias.
9.Asóciese con clientes internos y externos.

18.  Crea una disciplina de análisis de riesgos
que ayuda y evoluciona con el proyecto.
Vinculación con el cliente como también
orientado al trabajo en equipo.
Tiene facilidad de soporte y
mantenimiento.
 Es adaptable, se puede utilizar para
proyectos de cualquier magnitud.
 El modelo tiene facilidad de manejo por
ser una empresa conocida.
 Aplica mucho e incentiva al trabajo en
equipo y a la colaboración.
 Al estar basado en tecnología Microsoft,
trata de obligar a usar herramientas de ellos
mismo.
 Solicita demasiada documentación en sus
fases.
 Si el análisis de riesgos se hace muy
exhaustivo puede retardar el proyecto.
 Los precios de licencias, capacitación y
soporte de Microsoft son caros.

19. El Modelo en Espiral fue
propuesto Originalmente por
“Boehm en 1988.” es un
modelo de proceso de
software evolutivo que
conjuga la naturaleza
iterativa de construcción de
prototipos con el modelo
lineal secuencial.

20. Modelo de cuatro regiones
modelo original de Boehm
El Modelo en Espiral, propuesto originalmente por Boehm en 1976

21. NÚMERO DE ACTIVIDADES DE MARCO DE
TRABAJO TAMBIEN LLAMADO REGIONES
TAREAS:
•COMUNICACIÓN CON EL CLIENTE: Las
tareas requeridas para establecer
“Comunicación” entre el “Desarrollador” y el
“Cliente”.
•PLANIFICACIÓN: Las Tareas Requeridas
para definir “Recursos” , el “Tiempo” y otra
“Información” relacionadas con el Proyecto.
•ANÁLISIS DE RIESGO: Las Tareas
Requeridas para evaluar “Riesgos Técnicos” y
de “Gestión”.
•INGENIERÍA: Las Tareas Requeridas para
“Construir” una o mas representaciones de la
Aplicación.
•CONSTRUCCIÓN Y ACCIÓN: Las
Tareas Requeridas para “Construir”,
“Probar”, “Instalar” y “proporcionar”
soporte al Usuario
( por ejemplo: Documentación y
Práctica).
• EVALUACIÓN DEL CLIENTE: Las
Tareas Requeridas para obtener la
Reacción del Cliente según la Evaluación
de las representaciones del software
creadas durante la etapa de “ingeniería”
e “implementada” durante la etapa de
“instalación”.
.

22. Modelo en espiral de seis regiones
Planificación
Análisis de
riesgos
Ingeniería
Construcción y
adaptación
Evaluación del
cliente
Comunicación
con el cliente
Producto
Final

23. Define un Conjunto de Actividades de Negociación
al principio de cada paso alrededor de la
Espiral.
Mas que una simple actividad de comunicación con
el cliente, se definen las siguientes
actividades:

24. Modelo en espiral WINWIN
2. Identificar las
condiciones de
victoria de los
directivos
3a. Reunir las
condiciones de victoria.
3b. Establecer los
objetivos, restricciones
y alternativas del
siguiente nivel.
4. Evaluar las
alternativas del
producto y del proceso
y resolución de
riesgos.
5. Definir el siguiente
nivel del producto y del
proceso incluyendo
particiones.
6. Validar las
definiciones del
producto y del proceso
1. Identificar el
siguiente nivel para
los directivos
7. Revisión y
comentarios.

25. •El modelo en espiral puede adaptarse y
aplicarse a lo largo de la vida del software de
computadora.
•Como el software evoluciona a medida que
progresa el proceso, el desarrollador y el cliente
comprenden y reaccionan mejor ante riesgos
en cada uno de los niveles evolutivos.
•El modelo en espiral permite a quien lo
desarrolla aplicar el enfoque de construcción de
prototipos en cualquier etapa de evolución del
producto.
•El modelo en espiral demanda una
consideración directa de los riesgos técnicos en
todas las etapas del proyecto y si se aplica
adecuadamente debe reducir los riesgos antes
de que se conviertan en problemas.
•Resulta difícil convencer a grandes
clientes de que el enfoque evolutivo
es controlable.
•Debido a su elevada complejidad
no se aconseja utilizarlo en
pequeños sistemas.
•Genera mucho tiempo en el
desarrollo de sistemas.

26. ICONIX es la
metodología que
está de moda por
su fácil aplicación y
rápida producción
de software de
calidad.
1. Análisis de requisitos
• Elaboración rápida de prototipos
• Modelo del dominio
• Modelo de casos de usos
2. Análisis y diseño preliminar
•Descripción de los casos de uso
•Diagramas de robustez
3. Diseño
• Diagrama de secuencia
4. Implementación
•Código y pruebas

27. La metodología ICONIX, es una combinación entre la RUP y XP;
está basada en el desarrollo de sistemas a partir del análisis y la
documentación.
Esta metodología se busca tener una retroactividad con el
cliente, en la mitad de los procedimientos, comenzando con un
prototipo en donde el analista y el cliente definirán pantallas,
funcionalidades, en si lo que se espera obtener del programa.
Se definirán los modelos de casos de uso, de secuencia y de
robustez, con la finalidad de conseguir un buen sistema.

28. esquema del método ICONIX:
Prototipo de interfaz
de usuario
Diagrama de robustez
Modelo de casos de uso
Diagrama de
secuencia
DINÁMICA
Código
Modelo de dominio Diagrama de clases
ESTÁTICA
Plan de
Prueba
------
------
ICONIX