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.