Transcript Herramientas de Análisis Estructurado

El Ciclo de Vida del Proyecto
Ciclo de Vida de un Proyecto


Diversas fases por las que atraviesa un
proyecto antes de completarse.
Otros nombres del Ciclo de Vida
– Método de desarrollo
– Metodología de desarrollo
– Ciclo de vida de desarrollo de sistemas.
¿Para qué tener un ciclo de vida
de un proyecto?



Definir actividades a llevarse a cabo en
un proyecto de desarrollo de sistemas.
Lograr congruencia entre múltiples
proyectos.
Proporcionar puntos de control y
revisión administrativos.
El Ciclo de Vida del Proyecto
Relevamiento
Clásico
Requerimientos del usuario
Calendario, presupuesto
Análisis
Especificación funcional
Necesidades de rendimiento
Diseño
Preliminar
Especificación
del sistema
Diseño
Detallado
Pedido del hardware
Estudio
de Hardware
Configuración Final
Especificación del programa
Codificación
Módulos codificados
Prueba de
Unidad
Módulos probados
Prueba de
Sub-Sistema
Subsistemas probados
Prueba de
Sistema
Sistema probado
Características Ciclo de Vida
Clásico

Implementación ascendente (Bottom-Up)
– Ciclo de vida de cascada, basado en Diagrama de
Boehm.
– Es una de las mayores debilidades
– Nada está hecho hasta que todo esté terminado.
– Fallas más triviales se encuentran al comienzo,
más graves al final.
– Difícil la eliminación de fallas (debugging).
– Aumento de capacidad de computación al final del
Proyecto
Modelo de Cascada
Requerimientos
del Sistema
Requerimientos
de Software
Análisis
Diseño del Programa
Codificación
Pruebas
Operaciones
Características Ciclo de Vida
Clásico

Progresión Secuencial
-
Avance secuencial en orden de una fase a la otra
“Congelar” la especificación del sistema
Este enfoque NO es realista
Rara vez se hace algo complejo sin cometer
errores, la primera vez que se hace
- Cambios en el entorno del usuario o en su visión
del sistema suelen ocurrir durante los muchos
meses (o años) que toma desarrollar el sistema
completamente
- No utiliza técnicas de diseño o programación
estructuradas
El Ciclo de Vida Semiestructurado
Pedido del hw.
Requerimientos del usuario
4
ESTUDIO
DEL HW
1
RELEVAMIENTO
Documento de
factibilidad
Necesidades
de Rendimiento
2
ANÁLISIS
Presupuesto,
calendario
Requerimientos
del usuario
Datos de
configuración de hw.
Plan de pruebas
Especificación
3
narrativa
DISEÑO
funcional del
EST.
Sistema
Diseño por
paquetes
Sist.
5
IMPLEMENTACION
DESC.
Características Ciclo de Vida
Semiestructurado

Implementación de arriba hacia abajo (topdown).
– Módulos de alto nivel son codificados y testados
primero seguidos de módulos de bajo nivel
detallados
– Uso de Programación Estructurada para la
implementación de los módulos
– Codificación y Testeo se realizan en paralelo y
existe feedback entre estas actividades.

Diseño Estructurado
– Traducción de narrativa en un modelo construído
por DFD, DD, MER y Especificaciones de
Procesos
Detalles de la actividad de
DFD
Diseño
3.2
Derivar el
Diagrama de
Estructura
3.1
DFD, especificaciones
Codificar la de proceso, DD
Diagrama
Especificación
de Estructura
Funcional
3.3
Módulo de
Diseño
Especificación
Especificación
narrativa
Descripción de
de BD
funcional
módulos
Datos de configuración
Plan de prueba
3.4
Diseño de
Paquetes
Diagrama
de Estructura
Diseño en
paquetes
El Ciclo de Vida Estructurado
USUARIOS
Requerim. del sist.
Política del
usuario
Doc.
1
Relevamiento
ADM.
Restricciones
2
Análisis
5
Generación
de prueba
de aceptación
BD existente
Especif.
de diseño
Especif.
estructurada
Desc. de
Proc.
Manual de Usuario
Conj. de pruebas de ctrl. de calidad
Restricciones
operacionales
3
Diseño
Restricciones
Especif.
Inf. tentativo
CostoReporte estructurada
beneficio
de costobeneficio
7
ADM.
OPERACIONES
6
Ctrl. de
Calidad
Especif.
de diseño
8
Conversión
De BD
BD convertida
4
Implementación
Sist.
integrado
Sist.
aceptado
9
Instalación
Sist. instalado
Actividad 1: Relevamiento
Otros
nombres de esta actividad:
Pre-Análisis
Anteproyecto
Investigación
Estudio
Preliminar
de Factibilidad
Encuesta
(Survey)
Actividad 1: Relevamiento

Objetivos:
- Identificar usuarios responsables
- Identificar deficiencias en el entorno del
usuario
- Definir Alcance inicial del Sistema
- Establecer Objetivos del Sistema
- Sugerir Alternativas de Solución
- Determinar Factibilidad del Sistema
- Preparar un esquema para guiar el resto
del proyecto
Actividad 2: El Análisis de
Sistemas

Propósito: Transformar políticas de
usuario y esquema del proyecto en una
especificación estructurada

Modelar el entorno del usuario con
DFDs, MERs, DTEs, y otras
herramientas del Análisis Estructurado
Actividad 2: El Análisis de
Sistemas

Modelo esencial: representa una descripción
formal de lo que el nuevo sistema debe
hacer, independientemente de las TI
– Modelo esencial= Modelo ambiental + Modelo de
comportamiento


Modelos del sistema describen los
requerimientos del usuario
Análisis Costo/Beneficio detallado
Actividad 3: El Diseño




Asignación de porciones de la especificación
a procesadores adecuados (máquinas o
humanos) y a tareas adecuadas dentro de
cada procesador
Desarrollo de una jerarquía apropiada de
módulos de programas e interfases
Transformación de MER en un diseño de BD
Modelo de Implementación del Usuario:
definición de la frontera del sistema y de la
interfase hombre-máquina
Actividad 4: Implementación

Codificación e integración
progresiva de módulos en una
versión mas completa del sistema.

Incluye programación estructurada
e implantación descendente.
Actividad 5: Generación de
Pruebas de Aceptación

Definir un sistema aceptable desde el
punto de vista del usuario

Conjunto de casos de prueba de
aceptación generados a partir de la
especificación estructurada

Puede realizarse en paralelo con las
actividades de diseño e implementación
Actividad 6: Garantía de Calidad
Prueba final, de aceptación
 Verificación de que el sistema tiene
un nivel apropiado de calidad
 Requiere casos de prueba
generados en la actividad 5, y
sistema implementado e integrado a
través de la actividad 4
 SQA se realiza sobre todas las
actividades

Actividad 7: Descripción de
Procedimientos


Generación de una descripción
formal de la parte manual del
sistema y de cómo los usuarios van
a interactuar con la parte
automatizada del mismo
Manual de Usuario
Actividad 8: Conversión de Base
de Datos

Migración de la BD actual del usuario,
si es que existe una
Actividad 9: Instalación



Entradas: Manual de usuario, BD
convertida y Sistema aceptado.
Implantación o Puesta en Marcha
Puesta en marcha en paralelo
En Resumen:
 Actividades
paralelas.
 Actividad < > Fase.
 Retroalimentación
entre actividades
El Ciclo de Vida de Prototipos
Factibilidad
Lineamientos
Especificación
rigurosa
NO
¿Es buen
candidato?
SI
Diseño
Preliminar
Identificar necesidades
básicas
Desarrollar un modelo
funcional
Demostración dentro del
contexto, obtener refinamientos, etc.
Hacer correcciones
SI
¿Impacto
sobre el
Prototipo?
Afinar
prototipo
y doc.
NO
¿Está SI ¿Se necesitan
hecho el componentes
NO
Prototipo? de detalle?
NO
Componentes de la
Especif. rigurosa
SI
Características Ciclo de Vida de
Prototipos


Colección de programas de comp. que
simularán algunas o todas las funciones que
el usuario desea.
Herramientas:
- DD integrado
- Generador de pantallas
- Generador de reportes
- Lenguajes de programación de cuarta generación
- Lenguaje de consultas
- Medios poderosos de adm. de BD
Cuándo usar prototipos?




Usuario no puede o no quiere examinar
modelos abstractos.
Usuario no puede o no quiere pre- especificar
requerimientos => tanteo, ensayo y error.
Sistema en línea y operación por pantalla.
Sist. donde es más importante formato que
algoritmos.