Metodologas

Tradicionales
ARCINIEGAS ROINER
GUARIN ERIKA
NAVARRO CHRISTIAN
PINEDA MAIRA A.
SOTO JOSE




Metodologas de Desarrollo de
Software.
Las Metodologas de Desarrollo de
Software surgen ante la necesidad de
utilizar una serie de procedimientos,
tcnicas, herramientas y soporte
documental a la hora de desarrollar un
producto software.
METODOLOGAS TRACIONALES

(JDS) Desarrollo de Sistemas de Jackson
Ingeniera de la Informacin
(SSADM). Estructurado Anlisis del Sistema y Mtodo de
Diseo
Metodologa Mtrica

Otras metodologas tradicionales o pesadas podemos
citar:
RUP (Rational Unified Procces)
MSF (Microsoft Solution Framework)
Win-Win Spiral Model
Iconix

ESTUDIANTE:
ROINER ARCINIEGAS
Metodologas Pesadas.
Una de las metodologas pesadas ms conocidas y
utilizadas es la Metodologa RUP (Rational Unified
Process).
El Rational Unified Process o Proceso Racional
Unificado. Es un proceso de desarrollo de software y
junto con el lenguaje unificado de modelado (UML),
constituye la metodologa estndar ms utilizada para
los anlisis, implementacin y documentacin de los
sistemas orientado a objeto.
Su objetivo es asegurar la produccin de software de
alta calidad que satisfaga la necesidad del usuario final
dentro de un tiempo y presupuesto previsible. Es una
metodologa de desarrollo iterativo enfocada hacia los
casos de uso, manejo de riesgos y el manejo de la
arquitectura.
RUP

Rup es un producto de racional software que pertenece
a IBM este se caracteriza por ser iterativo e
incremental est centrado en la arquitectura y guiado
por los casos de uso, el rup no tiene una metodologa
estndar y precisa, el rup vara de acuerdo a las
necesidades que se presenten o de acuerdo al contexto.

Este adems incluye artefactos que van hacer los
productos tangibles del proceso, como por ejemplo el
modelo de caso de uso, el cdigo fuente, entre otros y
adems estn los roles que van un papel que
desempean una persona en un determinado proceso.
Principios de desarrollo
La metodologa RUP tiene 6 principios clave:

Adaptacin del proceso : El proceso debe
adaptarse a las caractersticas de la organizacin
para la que se esta desarrollando el software.

Balancear prioridades : Debe encontrarse un
balance que satisfaga a todos los inversores del
proyecto.

Colaboracin entre equipos : Debe haber una
comunicacin fluida para coordinar requerimientos,
desarrollo, evaluaciones, planes, resultados, etc.,...
Demostrar valor iterativamente : Los proyectos se
entregan, aunque sea de una forma interna, en etapas
iteradas. En cada iteracin se evaluar la calidad y
estabilidad del producto y analizar la opinin y
sugerencias de los inversores.

Elevar el nivel de abstraccin : Motivar el
uso de conceptos reutilizables.

Enfocarse en la calidad : La calidad del producto
debe verificarse en cada aspecto de la produccin.
Principales caractersticas
Forma disciplinada de asignar tareas y
responsabilidades

Pretende implementar las mejores practicas en
ingeniera de software

Desarrollo iterativo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual de software

Verificacin de calidad de software


Ciclo de vida RUP

Divide el desarrollo en 4 fases que definen su ciclo de vida:

Inicio : El objetivo es determinar la visin del proyecto y
definir lo que se desea realizar.

Elaboracin : Etapa en la que se determina la
arquitectura ptima del proyecto.

Construccin : Se obtiene la capacidad operacional
inicial.

Transmisin : Obtener el producto acabado y definido.
RUP
Inicio
Elaboracin
Construccin
Transicin
El RUP mejora la productividad del equipo ya que
permite que cada miembro del grupo sin importar su
responsabilidad especfica acceda a la misma base
de datos de conocimiento. Esto hace que todos
compartan el mismo lenguaje, la misma visin y el
mismo proceso acerca de cmo desarrollar software.

Para que sirve?
DISCIPLINA DE DESARROLLO
DE RUP
Determina las etapas a realizar durante el proyecto de
creacin del software.

Ingeniera o modelado del negocio: Analizar y
entender las necesidades del negocio para el cual se
est desarrollando el software.

Requisitos: Proveer una base para estimar los costos y
tiempo de desarrollo del sistema.

Anlisis y diseo : Trasladar los requisitos analizados
anteriormente a un sistema automatizado y desarrollar
una arquitectura para el sistema.
Implementacin: Crear software que se ajuste a la
arquitectura diseada y que tenga el comportamiento
deseado.

Pruebas : Asegurarse de que el comportamiento
requerido es correcto y que todo lo solicitado est
presente.

Despliegue: Producir distribuciones del producto y
distribuirlo a los usuarios.
Trabajo de
procesos
Trabajo de
soporte
N veces
Anlisis
Diseo
Codificacin
Integracin y
Pruebas
Al terminar cada fase se realiza una
evaluacin para determinar si se ha cumplido
o no con los objetivos de la misma.
VENTAJAS
Requiere conocimientos del proceso y de UML.

Reduce los riesgos del proyecto

Integra el desarrollo de mantenimiento.

Progreso visible en las etapas tempranas.

Facilita la reutilizacin del cdigo teniendo en cuenta
que se realizan revisiones en las primeras
iteraciones lo cual adems permite que se aprecien
oportunidades de mejoras en el diseo.

DESVENTAJAS
Pretende prever y tener todo el control en el
mantenimiento.

Este modelo genera muchos gastos.

Este modelo genera mucho trabajo adicional.

No es recomendable para el desarrollo de
proyectos pequeos



Metodologas Msf
Microsoft Solutions Framework (MSF) es un conjunto
de ingeniera de software procesos.
Define un marco de trabajo de referencia para
construir e implantar sistemas empresariales
distribuidos basados en herramientas y tecnologas
de Microsoft para cualquier plataforma (Linux, Citrix,
Microsoft, Unix).
MSF 1.0: 1993
MSF 3.0: 2002
MSF 4.0: 2005




COMPONENTES DE
MSF

Fortalecer el equipo brindndoles capacitacin
Asignacin de responsabilidades y autoridad
Comunicaciones abiertas
Agregar valor
Calidad
Aprender experiencias

DISCIPLINAS


MODELO DE EQUIPO DE
TRABAJO


MODELO DE PROCESO


MODELO EN ESPIRAL
Este es un modelo de proceso de software evolutivo, el
cual enlaza la naturaleza iterativa de la construccin de
prototipos, pero conservado aquellas propiedades del
modelo en cascada.
Boehm lo describe como un generador de modelo de
proceso por el riesgo que se emplea para conducir sistemas
intensivos de ingeniera de software concurrente y a la vez
con muchos usuarios.

EL MODELO ESPIRAL CAPTURA
ALGUNOS PRINCIPIOS BSICOS
Decidir que problema se quiere resolver antes de viajar
a resolverlo.
Examinar tus mltiples alternativas de accin y elegir
una de las mas convenientes.
Evaluar que tienes echo y que tienes que haber
aprendido despus de hacer algo.
No ser tan ingenuo para pensar que el sistema que estas
construyendo ser el sistema que el cliente necesita.
Conocer o comprender los niveles de riesgo, que tendrs
que tolerar.

FUNCIONAMIENTO DEL
MODELO ESPIRAL

EL MODELO EN ESPIRAL WIN -
WIN
El modelo en espiral WINWIN de Boehm, define un conjunto
de acciones de negociacin al principio de cada paso
alrededor de la espiral. Ms que una simple actividad de
comunicacin con el cliente se definen las siguientes
actividades:
Identificacin del sistema o subsistemas clave de los
directivos.
Determinacin de las condiciones de victoria de los
directivos.
Negociacin de las condiciones de victoria de los
directivos para reunirlas en un conjunto de condiciones
para todos los afectados (incluyendo el equipo del
proyecto de software).

HITOS O PUNTOS DE FIJACION
Objetivos del ciclo de vida (OCV).
Arquitectura del ciclo de vida (ACV).
La capacidad operativa inicial (COI).

UNA VISTA GENERAL SOBRE
LOS PASOS A SEGUIR.
1. Identificar el siguiente nivel para los directivos.
2. Identificar las condiciones de victoria de los directivos.
3. Reunir las condiciones de victoria, establecer los
objetivos, restricciones y alternativas del segundo
nivel.
4. Evaluar las alternativas del producto y del proceso
resolucin de riesgos.
5. Definir el siguiente nivel del producto y del proceso,
incluyendo particiones.
6. Validar las definiciones del producto y del proceso.
7. Revisin y comentarios.

Metodologa ICONIX
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.
Presenta claramente las actividades de cada etapa y
exhibe una secuencia de pasos que deben ser seguidos.

Est entre la complejidad del RUP (Rational Unified
Processes) y la simplicidad de XP (Extreme
Programming).
Caracterstica del ICONIX
Iterativo e incremental: varias iteraciones ocurren entre
el desarrollo del 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 trazabilidad como la capacidad de
seguir una relacin entre los diferentes artefactos de
software producidos.

Dinmica del UML: La metodologa ofrece un uso
dinmico del UML por que utiliza algunos diagramas del
UML, sin exigir la utilizacin de todos, como en el caso de
RUP.


Tareas del ICONIX
Anlisis de Requisitos.
Modelo de Dominio.
Prototipacin Rpida.
Modelo de Casos de Uso.
Anlisis y Diseo Preliminar.
Descripcin de Casos de Uso.
Diagrama de Robustez.
Diseo.
Diagrama de Secuencia.
Implementacin.
Escribir /Generar el Cdigo.

Anlisis de Requisitos
Se realiza un relevamiento de todos los
requisitos que en principio deberan ser
parte del sistema.

Se debe capturar informacin sobre lo
que les gusta y lo que les desagrada a los
usuarios.

Modelo de Dominio
Con los requisitos se construye el diagrama de clases,
que representa el modelo esttico del sistema.
Prototipacin Rpida
Se usa para simular el diseo del sistema. Se espera que los
usuarios lo evalen como si fuera el sistema final. Los cambios al
prototipo son planificados con los usuarios antes de llevarlos a
cabo.

El proceso se repite y finaliza cuando los usuarios y analistas estn de acuerdo
en que el sistema ha evolucionado lo suficiente como para incluir todas las
caractersticas necesarias o cuando es evidente que no se obtendr mayor
beneficio con una iteracin adicional.
Modelo de Casos de Usos
Los casos de uso permiten a los usuarios estructurar y articular sus
deseos; les obligan a definir la manera como querran interactuar con el
sistema, a precisar qu informaciones quieren intercambiar y a describir
lo que debe hacerse para obtener el resultado esperado.

Analisis y Diseo Preliminar
Analisis y Diseo Preliminar
Anlisis y Diseo Preliminar
Diagrama de Robustez
Ilustra grficamente las interacciones entre los objetos
participantes de un caso de uso. Los que pueden ser:
Objetos de interfaz. (Pantallas)
Objetos entidad. (Almacenamientos)
Objetos de control. (Gestores)

Implementacin
Escribir /Generar el Cdigo:
La importancia de la interactividad, accesibilidad y navegacin en
el software harn que el usuario se sienta seguro y cmodo al poder
hacer uso de la aplicacin sin inconvenientes.
Pero adems debemos tener en cuenta factores como:
La Reusabilidad: que es la posibilidad de hacer uso de los
componentes en diferentes aplicaciones.
La Extensibilidad: que consiste en modificar con facilidad el
software.
La Confiabilidad: realizacin de sistemas descartando las
posibilidades de error.