Metodologías
Tradicionales
ARCINIEGAS ROINER
GUARIN ERIKA
NAVARRO CHRISTIAN
PINEDA MAIRA A.
SOTO JOSE
Metodologías de Desarrollo de
Software.
Las Metodologías de Desarrollo de
Software surgen ante la necesidad de
utilizar una serie de procedimientos,
técnicas, herramientas y soporte
documental a la hora de desarrollar un
producto software.
METODOLOGÍAS TRACIONALES
(JDS) Desarrollo de Sistemas de Jackson
Ingeniería de la Información
(SSADM). Estructurado Análisis del Sistema y Método de
Diseño
Metodología Métrica
Otras metodologías tradicionales o pesadas podemos
citar:
RUP (Rational Unified Procces)
MSF (Microsoft Solution Framework)
Win-Win Spiral Model
Iconix
ESTUDIANTE:
ROINER ARCINIEGAS
Metodologías Pesadas.
Una de las metodologías pesadas más conocidas y
utilizadas es la Metodología 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 metodología estándar más utilizada para
los análisis, implementación y documentación de los
sistemas orientado a objeto.
Su objetivo es asegurar la producción de software de
alta calidad que satisfaga la necesidad del usuario final
dentro de un tiempo y presupuesto previsible. Es una
metodología 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 metodología
estándar y precisa, el rup varía de acuerdo a las
necesidades que se presenten o de acuerdo al contexto.
Este además incluye artefactos que van hacer los
productos tangibles del proceso, como por ejemplo el
modelo de caso de uso, el código fuente, entre otros y
además están los roles que van un papel que
desempeñan una persona en un determinado proceso.
Principios de desarrollo La metodología RUP tiene 6 principios clave:
Adaptación del proceso : El proceso debe
adaptarse a las características de la organización
para la que se esta desarrollando el software.
Balancear prioridades : Debe encontrarse un
balance que satisfaga a todos los inversores del
proyecto.
Colaboración entre equipos : Debe haber una
comunicación 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 iteración se evaluará la calidad y
estabilidad del producto y analizará la opinión y
sugerencias de los inversores.
Elevar el nivel de abstracción : Motivar el
uso de conceptos reutilizables.
Enfocarse en la calidad : La calidad del producto
debe verificarse en cada aspecto de la producción.
Principales características
Forma disciplinada de asignar tareas y
responsabilidades
Pretende implementar las mejores practicas en
ingeniería de software
Desarrollo iterativo
Administración de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual de software
Verificación 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 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.
Transmisión : Obtener el producto acabado y definido.
RUP
Inicio
Elaboración
Construcción
Transición
El RUP mejora la productividad del equipo ya que
permite que cada miembro del grupo sin importar su
responsabilidad específica acceda a la misma base
de datos de conocimiento. Esto hace que todos
compartan el mismo lenguaje, la misma visión y el
mismo proceso acerca de cómo desarrollar software.
¿Para que sirve?
DISCIPLINA DE DESARROLLO
DE RUP Determina las etapas a realizar durante el proyecto de
creación del software.
Ingeniería 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.
Análisis y diseño : Trasladar los requisitos analizados
anteriormente a un sistema automatizado y desarrollar
una arquitectura para el sistema.
Implementación: Crear software que se ajuste a la
arquitectura diseñada 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 Análisis
Diseño
Codificación
Integración y
Pruebas
Al terminar cada fase se realiza una
evaluación 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 reutilización del código teniendo en cuenta
que se realizan revisiones en las primeras
iteraciones lo cual además permite que se aprecien
oportunidades de mejoras en el diseño.
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 pequeños
Metodologías Msf
Microsoft Solutions Framework (MSF) es un conjunto
de ingeniería de software procesos.
Define un marco de trabajo de referencia para
construir e implantar sistemas empresariales
distribuidos basados en herramientas y tecnologías
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 brindándoles capacitación
Asignación 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 construcción 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 ingeniería de software concurrente y a la vez
con muchos usuarios.
EL MODELO ESPIRAL CAPTURA
ALGUNOS PRINCIPIOS BÁSICOS
Decidir que problema se quiere resolver antes de viajar
a resolverlo.
Examinar tus múltiples alternativas de acción y elegir
una de las mas convenientes.
Evaluar que tienes echo y que tienes que haber
aprendido después 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 tendrás
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 negociación al principio de cada paso
alrededor de la espiral. Más que una simple actividad de
comunicación con el cliente se definen las siguientes
actividades:
Identificación del sistema o subsistemas clave de los
directivos.
Determinación de las condiciones de victoria de los
directivos.
Negociación 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
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.
7. Revisión y comentarios.
Metodología ICONIX
Es un proceso simplificado en comparación con otros
procesos más tradicionales, que unifica un conjunto de
métodos de orientación 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).
Característica del ICONIX
Iterativo e incremental: varias iteraciones ocurren entre
el desarrollo del modelo del dominio y la Identificación de
los casos de uso. El modelo estático es incrementalmente
refinado por los modelos dinámicos.
Trazabilidad: cada paso está referenciado por algún
requisito. Se define trazabilidad como la capacidad de
seguir una relación entre los diferentes “artefactos de
software” producidos.
Dinámica del UML: La metodología ofrece un uso
“dinámico” del UML por que utiliza algunos diagramas del
UML, sin exigir la utilización de todos, como en el caso de
RUP.
Tareas del ICONIX
Análisis de Requisitos.
Modelo de Dominio.
Prototipación Rápida.
Modelo de Casos de Uso.
Análisis y Diseño Preliminar.
Descripción de Casos de Uso.
Diagrama de Robustez.
Diseño.
Diagrama de Secuencia.
Implementación.
Escribir /Generar el Código.
Análisis de Requisitos
Se realiza un relevamiento de todos los
requisitos que en principio deberían ser
parte del sistema.
Se debe capturar información 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 estático del sistema.
Prototipación Rápida
Se usa para simular el diseño del sistema. Se espera que los
usuarios lo evalúen 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 están de acuerdo
en que el sistema ha evolucionado lo suficiente como para incluir todas las
características necesarias o cuando es evidente que no se obtendrá mayor
beneficio con una iteración 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 querrían interactuar con el
sistema, a precisar qué informaciones quieren intercambiar y a describir
lo que debe hacerse para obtener el resultado esperado.
Analisis y Diseño Preliminar
Analisis y Diseño Preliminar
Análisis y Diseño Preliminar
Diagrama de Robustez
Ilustra gráficamente 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)
Implementación
Escribir /Generar el Código:
La importancia de la interactividad, accesibilidad y navegación en
el software harán que el usuario se sienta seguro y cómodo al poder
hacer uso de la aplicación sin inconvenientes.
Pero además 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: realización de sistemas descartando las
posibilidades de error.