Ing. Luis A. Otake
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.
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.
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
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.
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
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
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
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
•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
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)
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
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.
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
•Ú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