Professional Documents
Culture Documents
Capa de calidad
Base de cualquier proceso de ingeniería
La IS se basa en calidad
Mejores técnicas de construcción de software
Capa de proceso
Capa que une calidad y métodos
Desarrollo racional de la IS
Conjunto de actividades y resultados asociados que
sirvenpara construir un producto software
Capas de la IS
Capa de métodos
Un método incluye:
Análisis de requisitos
Diseño
Construcción de programas
Prueba
Mantenimiento
Suelen estar bastante ligados al proceso
Capa de herramientas
Soporte automático o semiautomático para el proceso y los
Métodos
Herramientas CASE: Computer Aided Software Engineering
Visión general de la IS
Fase de definición/especificación
Centrada en el QUÉ
Se identifican los requisitos del sistema y software:
Información a procesar
Función y rendimiento deseados
Comportamiento del sistema
Interfaces establecidas
Restricciones de diseño
Tareas principales:
Planificación del proyecto software
Ingeniería de sistemas o de información
Análisis de requisitos
Visión general de la IS
Fase de desarrollo
Centrada en el CÓMO
Se definen:
Cómo han de diseñarse las estructuras de datos
Cómo han de implementarse las funciones
Cómo han de caracterizarse las interfaces
Cómo debe traducirse el diseño a un lenguaje de
programación
Cómo ha de validarse el producto (pruebas, verificación)
Tareas principales:
Diseño del software
Generación del código
Pruebas del software
Visión general de la IS
Fase de mantenimiento
Centrada en cambios que se pueda necesitar realizar sobre un
producto
En esta fase se vuelven a aplicar las fases de definición y
desarrollo, pero sobre software ya existente
Pueden producirse cuatro tipos de cambio:
Corrección: Corregir los defectos
Adaptación: Modificaciones por cambio en el entorno externo
(CPU, SO, etc.)
Mejora: Ampliar los requisitos funcionales originales, a petición
del cliente
Prevención: Cambio para facilitar el cambio
Visión general de la IS
Entendible
Visibilidad
Grado en que las actividades del proceso proporcionan resultados
Soportable por herramientas CASE
Aceptabilidad
Grado en que los desarrolladores aceptan y usan el proceso
Fiabilidad
Capacidad de evitar o detectar errores antes de que sean defectos
Robustez
Continuidad del proceso a pesar de los problemas
Mantenible
Capacidad de evolución para adaptarse
Rapidez
Velocidad en que el proceso puede proporcionar un sistema a partirde una
especificación
Modelos de proceso que no son...
Modelo de Cascada
Separar en distintas fases de especificación y desarrollo que
se realizan en secuencia lineal.
Desarrollo Evolutivo
La especificación y el desarrollo están intercalados
Prototipado
Un modelo sirve de prototipo para la construcción del
sistemafinal
Transformación Formal
Un modelo matemático del sistema se transforma
formalmente en la implementación
Desarrollo basado en Reutilización
El sistema es ensamblado a partir de componentes
existentes
Modelo en cascada (waterfall)
Fases:
Conceptualización: Se determina la arquitectura de la
solución (i.e. división del sistema en subsistemas
+comunicación)
Análisis de requisitos: Básicamente se definen los
requisitos funcionales y de rendimiento
Diseño: Representación de la aplicación que sirve de guía a
la implementación
Implementación: Transforma el diseño en código
Prueba: Validación e integración del software y de los
sistemas
Instalación y comprobación: Se instala al cliente, el cual
comprueba la corrección de la aplicació
Modelo en cascada (waterfall)
Ingeniería de sistemas
Al ser el software parte de un sistema más grande el trabajo
comienza estableciendo requisitos de todos los elementos del
sistema y asignando al software una parte de estos requisitos
Modelo en cascada (waterfall)
Posibles ventajas:
Sencillo
Sirve cuando el personal está poco cualificado
Aplicable cuando el problema es estable y cuando se trabaja con
técnicas conocidas
Por ejemplo, será apropiado para la migración de una aplicación o
para generar una nueva versión de mantenimiento bien definida
Críticas:
No se ve un producto hasta muy tarde en el proceso
Un error grave en las últimas fases puede ser letal
Especificación de requisitos estable
Impone una estructura de gestión de proyectos
Fases muy rígidas
Las revisiones de proyectos de gran complejidad son muy difíciles
MODELO DE PROCESO INCREMENTAL
Modelo Incremental
35
Entre
Inc Análisi Diseño Codif. Prueba
ga 1er
1 s Inc.
Entreg
Inc Análisi Diseño Codif. Prueba
a 2do
2 s Inc.
Entreg
Inc Análisi Diseño Codif. Prueba
a 3er
3 s Inc.
Tiempo
MODELO INCREMENTAL
Ventajas
Rapidez
Válido para aplicaciones modularizables
Inconvenientes
Exige conocer bien los requisitos y delimitar el ámbito del
proyecto
Proyectos grandes => gran nro. de personas.
Alto compromiso en tiempo
Gestión riesgos técnicos altos
Uso de nueva tecnología
Alto grado de interoperabilidad con sistemas existentes
Modelos de proceso Evolutivos
41
43
Construcción de Prototipos
44
Modelo Espiral
Ingeniería,
Construcción Construir Extraer
y Entrega
Evaluació
Colocar en biblioteca
n del
Cliente
Construir iteración
Modelo de Métodos Formales
56
Fases de un ciclo
inicio
elaboración
construcción
transición
Ejemplos de iteraciones
Fase de inicio
Productos:
Productos:
Trabajador
• Un trabajador define el comportamiento y las
responsabilidades de un individuo.
• Es como un “sombrero” que la persona usa durante el
proyecto:
– Una persona puede tener varios sombreros
– Es el rol que desempeña en un momento dado
• Responsabilidades:
– Hacer una serie de actividades
– Ser el responsable de una serie de artefactos
Definiciones
Actividades
• Una actividad es una unidad de • Las actividades se consideran en la
trabajo que se asigna a un planificación y evaluación del progreso del
trabajador. Ej.: proyecto.
– Crear o modificar un artefacto • Ejemplos:
– Planificar una iteración - Administrador
• Una actividad lleva entre un par de de proyecto
horas y un par de días, involucra un – Encontrar actores y casos de uso -
solo trabajador y un número Analista
pequeño de artefactos.
– Revisar el diseño - Revisor de diseño
– Ejecutar pruebas de performance - Ing.
de pruebas de performance
Asignación de actividades
Flujos de Trabajo
de Apoyo
Flujos de trabajo
Imprimir Informe
• Los desarrolladores y
Reciclar Operador
clientes deben acordar qué Cliente
hacer:
– Relevar requerimientos • Los casos de uso describen
– Documentar funcionalidad y la funcionalidad.
restricciones • Los requerimientos no
– Documentar decisiones
– Identificar actores
funcionales se incluyen en
– Identificar casos de uso
una especificación
complementaria.
Análisis y diseño
• Propósito:
• Propósito:
• RUP propone probar las componentes
– Verificar la interacción entre los desde el principio:
objetos
– Confiabilidad, funcionalidad y
– Verificar la integración apropiada performance
de componentes
– Verificar que se satisfacen los • Las pruebas de regresión son importantes
requerimientos en desarrollos iterativos.
– Identificar los defectos y
corregirlos antes de la instalación • Rational tiene herramientas para
automatizar algunas pruebas.
• RUP describe como planear y ejecutar
estas pruebas.
Distribución
• RUP incluye:
– Un framework para manejo de proyectos de software
– Guías para planificación, provisión de personal, ejecución y monitoreo de
planes
– Un framework para manejar riesgos
Administración de configuración y cambios
Diagrama de casos de uso que muestra a los actores (otros usuarios del
sistema), los casos de uso (las situaciones que se producen cuando utilizan
el sistema) y sus relaciones.
Diagrama de clases que muestra las clases y la relaciones entre ellas.
Diagrama de secuencia muestra los objetos y sus múltiples relaciones entre
ellos.
Diagrama de colaboración que muestra objetos y sus relaciones,
destacando los objetos que participan en el intercambio de mensajes.
Diagrama de estado muestra estados, cambios de estado y eventos en un
objeto o en parte del sistema.
Diagrama de actividad que muestra actividades, así como los cambios de
una a otra actividad junto con los eventos que ocurren en ciertas partes del
sistema.
Diagrama de componentes que muestra los componentes de mayor nivel
de la programación (cosas como Kparts o Java Beans).
Diagrama de implementación que muestra las instancias de los
componentes y sus relaciones.
Diagrama de relaciones de entidad que muestra los datos y las relaciones y
restricciones entre ellos.