análisis y diseño de sistemas iii ciclo - eti ing. marlon jara · organización del trabajo...

Análisis y Diseño de Sistemas

Sesión 1-3

III CICLO - ETI

Ing. Marlon Jara

INDICE

• INGENIERIA DE SOFTWARE

• MODELO DE PROCESOS DE DESARROLLO DE SOFTWARE

• METODOLOGÍAS DE DESARROLLO DE SOFTWARE

• INTRODUCCIÓN A UML

• RATIONAL ROSE

• DIAGRAMAS DE CASO DE USO

• DIAGRAMA DE CLASES Y OBJETOS

• DIAGRAMA DE SECUENCIA

UNIDAD 1: METODOLOGÍAS USADAS EN EL DESARROLLO DE SOFTWARE

INGENIERIA DE SOFTWARE

• Características del software (lo contrario para el hardware):

• No se desgasta ni envejece, y por este motivo no requiere reparaciones ocasionales

• Su duplicación es poco costosa, lo caro es el desarrollo

• Puede ser modificado fácilmente, tanto que es necesario un control de versiones

• La Ingeniería del Software comprende las técnicas y procedimientos ingenieriles para el desarrollo del software.

INGENIERIA DE SOFTWARE

• La IS no se plantea solo una actividad de programación, previamente sonnecesarias las fases de análisis y diseño y posteriormente la integración y laverificación, incluso el manteniendo cuando el producto ya está en explotación.(CICLO DE VIDA).

• Inicialmente la tarea de desarrollo era realizada individualmente por hábilescreativos, de forma poco disciplinada. El trabajo en equipo supone la división yorganización del trabajo utilizando metodologías de desarrollo.

• En los 70 y los 80 empiezan a usarse herramientas CASE (Computer AidedSoftware Engineering). En los 90 IPSE e ICASE.

INSTITUTO SISE ANALISIS Y DISEÑO DE SISTEMAS 5

Modelos de desarrollo de software

• Modelo en cascada• Enfoque sistemático y secuencial

del desarrollo• Problemas

• Toma una visión estática de los requerimientos ignorando la volatilidad

• Poca participación de usuario una vez que la especificación es obtenida

• Separación poco realista de la especificación contra el diseño

• No hay lugar para prototipos, reuso, etc

• El sistema está listo muy al final.

percepción de

una necesidad

integración

testeo

codificación

diseño

requerimientos

6


• Prototipación• Beneficios

• Entiende los requerimientos para la interfaz de usuario

• Examina la veracidad del diseño propuesto

• Explora características de performance del sistema

• Problemas• Los usuarios ven al prototipo

como solución• Los prototipos solo obtienen

especificación parcial• Tipos de prototipos

• Evolucionables• desechables

requeri-

miento

testeo de

prototipo

construc

ción de

prototipo

diseño

de

prototipo

documento de

requeriementostesteocodificacióndiseño integración

INSTITUTO SISE ANALISIS Y DISEÑO DE SISTEMAS

7


• Modelo en espiral• Dos versiones

Determinar metas,

alternativas y

limitaciones

Evaluar alternativas

de riesgo

Desarrollo y testPlan

Planificación

Comunicación

con el

cliente

Análisis de

riesgo

Ingeniería

configuración

y adaptación

Evaluación del

cliente

Cuatro ciclos


8

• Modelo en espiral modelo orientado al análisis de riesgo

• Cuatro ciclos básicos

• Proyecto de desarrollo de conceptos

• Proyecto de desarrollo de producto nuevo

• Proyecto de mejora de producto

• Proyecto de mantenimiento de productos

• En cada iteración o ciclo:

• Se planea la siguiente fase

• Se determinan objetivos y limitaciones

• Se evalúan alternativas

• Se resuelven casos de riesgo

• Se desarrolla el producto

• Qué diferencias encuentra entre las dos alternativas?

• Qué incluye

• Análisis de riesgo de requerimientos (usando prototipos y simulación

• Planificación de diseño

• Problemas

• Convencer que el enfoque evolutivo es controlable

• Si se escapa del análisis un riesgo puede traer problemas



9


• Modelo VRequerimientos

del sistema

Test e

integración

Análisis y

diseño

integración del

sistema

preuba de

aceptación

Integración del

software

prueba de

componentes

prueba de

unidad

Codificación y

verificación

Diseño

Detallado

Diseño

preliminar

Requerimientos

del software

Niv

el d

e a

bstr

acció

n

TiempoINSTITUTO SISE ANALISIS Y DISEÑO DE SISTEMAS

Metodologías orientadas al Flujo de información

• Contemplan los sistemas software como procesadores de flujo de información.

• La información entra, se transforma a su paso por las distintas unidades (hardware, software y elementos humanos) y sale procesada.

• Entrada: señales eléctricas, voz, pulsaciones de teclado, sensores, etc.

• Transformación: comparaciones sencillas, algoritmos complejos, inferencia lógica, etc.

• Salida: listados, actuadores, dispositivos multimedia, etc.

• Metodología Análisis Estructurado

• Metodología de diseño estructurado de Yourdon

METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Análisis & Diseño estructurado

• Autores: Análisis estructurado de Tom DeMarco 1979 & Diseño estructurado de Yourdon

• Modelo de proceso: en cascada.

• Lenguaje de Modelado:

• Diagramas de flujos de datos (DFDs).

• Diagramas de flujos de control (DFCs).

• Diagramas de Transición de estados (DTEs).

• Diagramas de E-R.

• Alcance

• Actividades Técnicas cubiertas:

• Análisis: DFDs, DFCs, CSPEC, PSPEC, Diccionario de requisitos.

• Diseño: Método de transformación de Yourdon


Metodologías Orientadas a Objetos

• Concebidas para el desarrollo de sistemas basados en el paradigma de la orientación a objetos.

• Se desarrollan alrededor del concepto de clase.

• Conciben el diseño como una evolución o refinamiento del análisis, eliminando el salto existente hasta entonces.

• Emplean lenguajes de modelado OO.

• Rápido desarrollo y proliferación:

• Objectory, Booch, OMT, RUP, …

• Método Unificado de Rational (RUP –Rational UnifiedProcess)


Metodología RUP (Rational Unified Process)

• Autores: Booch, Rumbaugh & Jacobson

• De la mano de Rational junto con UML y Rose

• Modelo de proceso: Iterativo e incremental (híbrido). En cuatro fases: inicio, elaboración, construcción y transición.

• Lenguaje de Modelado: UML

• Alcance:

• Obtención de req.

• Análisis

• Diseño

• Implementación

• Pruebas


Metodologías Orientadas Basadas en Roles

• Evolución de las OO.

• No por desarrollar con objetos, hay que diseñar con objetos

• No se basan en la abstracción de clase, sino de la del rol que juega cada clase.

• La clase no es un elemento atómico, sino la implementación de un rol.

• OORAM (Object Oriented Role Analysis and Modelling)

Role Clase Código

Implementa Implementa

Líneas de Investigación


Metodologías Ágiles de Desarrollo

• Se basan en la creencia de que las metodologías ingenieriles no son válidas para el desarrollo de software.

• Las metodologías clásicas se basan en la planificación.

• No es posible planificar cuando el desarrollo de software no es predecible.

• Centran su filosofía en la adaptabilidad al cambio en los requisitos.

• Orientadas a la gente.

• Ciclos de vida muy cortos.

• eXtreme Programming (XP).



eXtreme Programming

• Autores: Kent Beck y Ward Cunningham

• Modelo de proceso: iterativo, con ciclos muy cortos


Análisis

Diseño

Implementación

Pruebas

En cascada

Iterativo XP

Alcance

Tiemp

o

• Lenguaje de modelado: No determinado, recomendado UML

• Prácticas propuestas:

1. Planificación

2. Versiones pequeñas

3. Metáfora

4. Diseño simple

5. Prueba continua

6. Refactoring

7. Pair Programming

8. Propiedad colectiva del código

9. Integración continua

10. 40 horas semanales

11. Cliente en el sitio

12. Estándares de codificación


GRACIAS

análisis y diseño de sistemas iii ciclo - eti ing. marlon jara · organización del trabajo...

Documents