Qué tareas se llevan a cabo en cada etapa Qué salidas se producen y cuándo se deben producir Qué restricciones se aplican Qué herramientas

17 

Texto completo

(1)

Ing. Luis A. Otake

(2)

Conjunto de filosofías, fases, procedimientos, reglas, técnicas,

herramientas, documentación y aspectos de formación para los

desarrolladores de sistemas de información.

Es un conjunto de componentes que especifican:

Cómo se

debe dividir

un proyecto

en etapas

Qué tareas

se llevan a

cabo en cada

etapa

Qué salidas

se producen

y cuándo se

deben

producir

Qué

restricciones

se aplican

Qué

herramientas

se van a

utilizar

Cómo se

gestiona y

controla un

proyecto

3 Ing. Luis A. Otake

Es un conjunto de fases descompuestas en subfases

(módulos, etapas, pasos, etc.).

Guía a los desarrolladores en la elección de las técnicas que

debe elegir para cada estado del proyecto, y facilita la

planificación, gestión, control y evaluación de los proyectos.

(3)

Mejores aplicaciones

Un mejor proceso de

desarrollo, que

identifica las salidas (o

productos intermedios)

Un proceso estándar

Ing. Luis A. Otake 5

Registrar los requisitos de un SI de una forma acertada.

Proporcionar un método sistemático de desarrollo de forma que se pueda controlar su progreso.

Construir un SI dentro de un tiempo apropiado y unos costes aceptables.

Construir un sistema que esté bien documentado y que sea fácil de mantener.

(4)

Proceso

•Se descompone hasta el nivel de tareas o actividades elementales.

Tarea

•Para cada una se identifica un procedimiento.

Procedimiento

•Define la forma de ejecutar la tarea y es el vehículo de comunicación entre usuarios y desarrolladores. •Se pueden utilizar una o varias

técnicas para aplicarlo.

Producto

•Se obtiene como resultado de seguir un procedimiento

Sistema deseado

•Compuesto por un conjunto de productos finales.

Técnica

•Suelen ser gráficas con apoyos textuales formales, y determinan el formato de los productos resultantes de cada tarea.

Herramientas Software

•Sirven de apoyo para la realización de una técnica.

Ing. Luis A. Otake 7

Ejemplifique:

• Proceso

• Tarea

• Procedimiento

• Producto

• Sistema deseado

• Técnica

(5)

Una metodología puede seguir uno o varios modelos

de ciclo de vida.

El ciclo de vida indica qué es lo que hay que obtener

a lo largo del desarrollo pero no cómo hacerlo.

La metodología indica cómo hay que obtener los

distintos productos parciales y finales.

(6)

Los resultados finales

son impredecibles.

No hay forma de

controlar lo que está

sucediendo en el

proyecto.

Los cambios

organizativos afectan

negativamente al

proceso de desarrollo.

Ing. Luis A. Otake 11

Programación estructurada

Diseño estructurado

Análisis estructurado

Especificaciones funcionales:

• Gráficas

• Particionadas

(7)

Año Metodología

1968 Conceptos sobre la programación estructurada de DIJKSTRA 1974 Técnicas de programación estructurada de WARNIER y JACKSON 1975 Primeros conceptos sobre diseño estructurado de MYERS y YOURDON 1977 Primeros conceptos sobre análisis estructurado GANE y SARSON 1978 Análisis estructurado: DEMARCO y WEINBERG

1981 SSADM (versión inicial). Information Engineering (versión inicial)

1985 Análisis y diseño estructurado para sistemas de tiempo real de WARD y MELLOR 1986 SSADM versión 3

1987 Análisis y diseño estructurado para sistemas de tiempo real de HATLEY y PIRHBAY 1989 METRICA (versión inicial)

1990 SSADM versión 4 1993 METRICA versión 2 1995 METRICA versión 2.1

Ing. Luis A. Otake 13

Trata los procesos y datos de

forma conjunta, es decir,

modulariza tanto la

información como el

procesamiento.

Su esencia es la identificación

y organización de conceptos

del dominio de la aplicación y

no tanto su representación

final en un lenguaje de

(8)

Se eliminan fronteras entre fases debido a la naturaleza

iterativa del desarrollo OO.

Aparece una nueva forma de concebir los lenguajes de

programación y su uso al incorporarse bibliotecas de clases

y otros componentes reutilizables.

Hay un alto grado de iteración y solapamiento, lo que lleva a

una forma de trabajo muy dinámica.

Ing. Luis A. Otake 15

Son interactivas e

incrementales.

Fácil de dividir el

sistema en varios

subsistemas

independientes.

Se fomenta la

reutilización de

(9)

Existencia de reglas predefinidas

Cobertura total del ciclo de desarrollo

Verificaciones

intermedias Planificación y control

Comunicación efectiva

Utilización sobre un abanico amplio de

proyectos

Fácil formación por herramientas CASEDebe estar soportada

Debe contener actividades que mejoren el proceso de desarrollo

(calidad y coste)

Soporte al mantenimiento

Soporte a la reutilización de

software

Ing. Luis A. Otake 17

Enfoque

Tipo de Sistema

Formalidad

(10)

•los procesos, los flujos y la estructura de los datos de una manera descendente (top-down).

Proponen la creación de modelos de sistemas que representan

•Orientadas a procesos •Orientadas a datos

•Orientadas a estructuras de datos jerárquicas •Orientadas a estructuras de datos no jerárquicas •Mixtas

Tipos de metodologías

Ing. Luis A. Otake 19

• Entrada • Proceso • Salida.

Fundada sobre el enfoque

básico:

• De Marco • Gane y Sarson • Yourdon

Ejemplos:

Se basan en la utilización de un modelo descendente de descomposición

funcional para definir los requisitos del sistema.

•Diagrama de flujo de datos (DFD)

• Diccionario de datos (que aparecen en el DFD) • Especificaciones de procesos

Se apoyan en técnicas

gráficas (especificación

(11)

MERISE

SSADM

METRICA

Ing. Luis A. Otake 21

Programación extrema (Kent Beck)

Desarrollo adaptativo de software (Jim Highsmith)

Método de desarrollo de sistemas dinámicos

Melé (Jefff Sutherland)

Cristal (Alistair Cockburn y Jim Highsmith)

(12)

Utiliza desarrollo

orientado a objetos

Conjunto de reglas y

prácticas bajo cuatro

actividades: planeación,

diseño, codificación y

pruebas.

Ing. Luis A. Otake 23

Planeación

•Historias de usuario (escritas por el cliente): describen las características y la funcionalidad requeridas para el software

Diseño

•Principio MS (mantenerlo simple)

•Tarjetas CRC

•Prototipo de diseño (solución pico), solamente cuando se encuentra un problema difícil de diseño

•Refabricación (mejorar el diseño del código después de que se ha escrito) •El diseño puede y debe

modificarse de manera continua

Codificación

•Una vez que el código está completo, la unidad puede probarse de inmediato •Programación en pareja (dos

cabezas piensan mejor que una)

Pruebas

•Las pruebas de integración y validación del sistema pueden realizarse a diario •“Arreglar problemas pequeños

(13)

planeación

diseño

codificación

prueba

Ing. Luis A. Otake 25

Historias del usuario Valores Criterios de las pruebas de iteración

Plan de iteración

Diseño simple Cartas CRC Soluciones

pico prototipos

refabricación

Programación en pareja Integración

continua Prueba de unidad

Pruebas de aceptación Lanzamiento

Incremento de software Velocidad calculada del proyecto

Proporciona un medio simple para identificar y organizar las clases

relevantes para los requisitos del sistema o producto.

Es una colección de tarjetas índice estándar que representan clases.

Las tarjetas se dividen en tres secciones.

•A lo largo del borde superior de la tarjeta se escribe el nombre de la clase.

(14)

El UML proporciona la tecnología necesaria para apoyar la práctica de la

ingeniería de software OO, pero no provee un marco de trabajo del proceso.

El Proceso Unificado es un marco de trabajo para la ingeniería de software

OO, mediante la utilización de UML.

Proceso de software guiado por los casos de uso, de arquitectura céntrica,

iterativo e incremental.

Llamado también Rational Unified Process (RUP)

Ing. Luis A. Otake 27

•Comunicación con el cliente y actividades de planeación •Requisitos del negocio

•Arquitectura aproximada del sistema •Plan iterativo e incremental Inicio

•Comunicación con el cliente y actividades de modelado del modelo genérico del proceso •Se refina y expande los CU

•Se expande la representación arquitectónica •Línea de base arquitectónica

•Se revisa el plan: ámbito, riesgos, datos entregados Elaboración

•Actividad genérica de construcción •Implementación del código fuente •Pruebas de unidad

•Integración (ensamblaje de componentes) •Pruebas de aceptación

(15)

•Últimas etapas de la actividad genérica de construcción

•Primera parte de la actividad genérica de despliegue

•Pruebas beta con usuarios finales

•Reporte de defectos y cambios

•Información (documentación) de soporte para el lanzamiento

Transición

•Actividad genérica de despliegue

•Se monitorea el uso subsiguiente del software

•Soporte para el ambiente operativo (infraestructura)

•Se reciben y evalúan informes de defectos y requerimientos de cambios

Producción

Ing. Luis A. Otake 29

Fase de inicio

Documento de la visión Modelo inicial de caso de uso

Glosario inicial del proyecto Caso inicial del negocio Evaluación inicial del riesgo Plan del proyecto, fases e iteraciones

Modelo de negocio si es necesario

Uno o más prototipos

Fase de elaboración

Modelo de casos de uso Requisitos suplementarios, se incluyen las no funcionalidades Modelos de análisis Descripción de la arquitectura del software Prototipo arquitectónico ejecutable

Modelo de diseño preliminar Lista revisada de riesgos Plan de proyecto que incluye:

•plan de iteración •flujos de trabajo

Fase de construcción

Modelo del diseño Componentes del software Incremento integrado del software

Plan y procedimiento de pruebas

Casos de prueba Documentación del soporte •manuales de usuario •manuales de instalación •descripción del incremento actual

Fase de transición

Incremento de software integrado

Reportes de las pruebas beta

(16)
(17)

Piattini, Mario G.; Calvo-Manzano, José A.;

Cervera, Joaquín y Fernández, Luis. 2000.

Análisis y diseño detallado de Aplicaciones

Informáticas de Gestión. Alfaomega. México.

http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.pdf

Figure

Actualización...

Descargar ahora (17 página)