Ingeniería del Software de Gestión. Tema 1

tema 1 – introducción a la ingeniería
del software

enrique barreiro
departamento de informática
universidade de vigo

escuela superior de ingeniería informática
ingeniería del software de gestión

características y evolución del software
tema 1 – introducción a la ingeniería del software

un poco de historia
primeras décadas:
desarrollar el hardware
reducir costes de procesamiento y almacenamiento
década de los ochenta:
desarrollo de la microelectrónica
mayor potencia de cálculo y reducción de costes
objetivo actual: mejorar la calidad de las soluciones software.

1959 - 1965 1965 - 1975 1975 - 1989 1989 -
[ Sistemas distribuidos [ Potentes sistemas
[ Sistemas distribuidos [ Potentes sistemas
[ Multiusuario
[ Orientación [ Multiusuario [ Inteligencia Artificial
[ Orientación de sobremesa
[ Inteligencia Artificial
[ Tiempo real de sobremesa
[ Tiempo real
por lotes [ Hardware de bajo [ Tecnología de objetos
por lotes [ Hardware de bajo [ Tecnología de objetos
[ Bases de datos
[ Bases de datos
[ Distribución [ Sistemas expertos
coste
[ Distribución [ Sistemas expertos
[ Software como coste
[ Software como [ Impacto en el [ Redes neuronales
limitada [ Impacto en el [ Redes neuronales
limitada producto
[ Cliente/servidor
producto
[ Software aa consumo [ Cliente/servidor
[ Software [ Mayores gastos consumo
[ Mayores gastos [ Redes area local [ Tecnologías de
[ Redes area local [ Tecnologías de
medida de mantenimiento
medida de mantenimiento yyglobal Internet.
global Internet.
[ Gran demanda
[ Gran demanda

AUMENTAN los problemas del desarrollo de software:
è Subexplotación del potencial del hardware
è Incapacidad de atender a la demanda
è Incapacidad de mantener el software existente

© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 41


software
programas
archivos de configuración
documentación de la estructura del sistema
manuales de instalación y uso
sitios web con información y actualizaciones

tipos de software
productos genéricos
sistemas producidos por una organización y que se venden en el mercado
abierto
sistemas gestores de bases de datos, procesadores de texto, paquetes
gráficos,...
la organización controla la especificación
productos personalizados
desarrollados específicamente para un cliente
aplicaciones de negocio, sistemas de control de tráfico aéreo, control de
procesos de fabricación,...
el cliente controla la especificación de la aplicación



El software desde una perspectiva industrial
El valor del software: de “elemento añadido” a principal
elemento de coste

El desarrollo del software:

Algunas preguntas:
¿Por qué se tarda tanto? (y casi siempre más de lo previsto)
¿Por qué la productividad es tan baja?
¿Por qué cuesta tanto?
¿Por qué siempre quedan errores sin localizar?


naturaleza y problemas del desarrollo de software

El software como elemento lógico.
Se desarrolla, no se fabrica:
Calidad del diseño.
Costes más importantes en la ingeniería
Gestión especial de los proyectos
Se “deteriora” con el mantenimiento
Desarrollo a medida (ausencia de componentes)

La “crisis” del software: problemas que aparecen en el desarrollo del
software al desarrollar, mantener y atender la demanda de nuevas
aplicaciones.

Sin tiempo para recoger
datos históricos

Planificación y estimaciones
imprecisas
Dificultad de mantener
el software existente
Insatisfacción del cliente
Calidad Baja productividad


naturaleza y problemas del desarrollo de software

Causas de la crisis del software
Naturaleza lógica del software
Mala gestión de los proyectos ( ausencia de datos, deficiente
comunicación, ...)
Ausencia de entrenamiento formal en nuevas técnicas
(programadores vs. ingenieros de software)
MITOS DE GESTIÓN
Resistencia al cambio
Mitos del software: - Uso de estándares
- Uso de herramientas
- Mala planificación: aumento
de programadores

MITOS DE LOS DESARROLLADORES MITOS DEL CLIENTE
- Programa funcionando = fin del trabajo - Requisitos establecidos como
- Calidad = el programa se ejecuta una declaración general de
sin errores objetivos
- Entrega al cliente: programa - Flexibilidad del software ante
funcionando los cambios


la ingeniería del software

definiciones
establecimiento y uso de principios de ingeniería robustos,
orientados a obtener software económico, fiable, eficiente y
que satisfaga las necesidades del usuario
disciplina que comprende todos los aspectos de la
producción de software, desde las etapas iniciales hasta el
mantenimiento:
“disciplina de ingeniería”: aplicación de teorías, métodos y
herramientas para solucionar problemas, y teniendo en cuenta
restricciones financieras y organizativas
“todos los aspectos de producción”: comprende procesos
técnicos del desarrollo y actividades como la administración de
proyectos, desarrollo de herramientas, métodos y teorías
actividad de
modelado
solución de problemas
adquisición de conocimiento
dirigida por una fundamentación


la ingeniería del software

trata de ser la respuesta a la crisis del software
combinación de elementos:

métodos completos para
todas las fases

mejores técnicas de
control de calidad

mejores elementos
de programación

herramientas para automatizar
los métodos

filosofía de coordinación,
control
y buena gestión


modelado

modelado: método básico de la ciencia
modelo
representación abstracta de un sistema que da respuesta a preguntas
sobre el sistema
útiles cuando se manejan sistemas grandes, pequeños, complicados
o caros para tener una experiencia de primera mano
permiten visualizar y comprender sistemas que no existen o que sólo
se supone que existen
ejemplos:
biología: modelos de dinosaurios a partir de restos
física: modelos que representan cómo se reúnen materia y energía en los
niveles subatómicos más bajos
el sistema en el mundo real serían dinosaurios o partículas subatómicas

modelos


modelado

los ingenieros de software necesitan
comprender el ambiente de funcionamiento del sistema:
construyen modelos del dominio del problema (sistemas de
bolsa, control de tráfico aéreo,...)
comprender los distintos sistemas que podrían construir para
evaluar alternativas: construyen modelos del dominio de la
solución
SI ST EMA DE PAGOS Y

técnicas y herramientas para construir los modelos (por
FA CT URACIÓN

ejemplo, diagramas de UML)
Sol ici ta r b iene s o servicios

Co nfirm a r p edido
iniciador
iniciador

<<subsistema>>
Enviar factura al comprador
Sistema de
iniciador visión
Hojear fact uras
<<subsistema>>
iniciador
Pagar factura
Vendedor
<<subsistema>> <<subsistema>>
Comprador <<extend>> Controlador del Controlador del
iniciador
brazo asidero
<<subsistema>>
Sistema de identificación
Re al i za r t ransa cc ió n
Pagar recargo por saldo deudor de objetos

Planificar pago Rechazar
fact ura factura
Sistema de
cuentas bancarias

<<subsistema>>
<<subsistema>>
Pagar factura en día <<subsistema>>
Controlador de cinta
<<subsistema>>
Sistema de selección
vencimiento transportadora
Sistema de
En vi a r aviso
de embalajes
embalaje


solución de problemas

los ingenieros de software buscan una solución adecuada, en varios
pasos:
1. Formular el problema
2. Analizar el problema
3. Buscar soluciones
4. Decidir la solución más adecuada
5. Especificar la solución

actividades básicas del desarrollo
1. obtención de requerimientos
2. análisis
3. diseño del sistema
4. implementación

otras actividades del desarrollo para evaluar la adecuación de los modelos
revisiones del análisis: el modelo del dominio del problema se compara con la
realidad del cliente
revisiones del diseño: el modelo del dominio de la solución se compara con los
objetivos del proyecto
pruebas: el sistema se valida contra el modelo del dominio de la solución
administración del proyecto: se compara el modelo del proceso de desarrollo
(calendario y presupuesto) con la realidad (trabajos entregados y recursos
gastados)


participantes y papeles

participantes: todas las personas involucradas en el
proyecto
cliente: encarga y paga el sistema
desarrolladores: construyen el sistema (analistas,
diseñadores, programadores,...)
gerente o director del proyecto: planifica y calcula el
presupuesto, coordina a los desarrolladores y cliente
usuarios finales: los que van a utilizar el sistema

papel (rol)
conjunto de responsabilidades en el proyecto o en el sistema
asociado con un conjunto de tareas y se asigna a un
participante
un mismo participante puede cumplir varios papeles


otros conceptos de la ingeniería del software

sistemas y modelos
sistema: realidad subyacente
modelo: cualquier abstracción de la realidad

productos de trabajo
artefacto o elemento que se produce durante el desarrollo (documento,
fragmento de software,...)
dos tipos:
producto de trabajo interno: producto para el consumo interno del proyecto (por
ejemplo, una revisión de la estructura de la base de datos, resultados de pruebas para
el gerente,...)
entrega: producto de trabajo para un cliente (especificación de requisitos, manual de
usuario, producto final,...)

actividades, tareas y recursos
actividad (o fase): conjunto de tareas que se realiza con un propósito específico
(obtención de requisitos, entrega, administración,...) que pueden componerse de
otras actividades
tarea: unidad elemental de trabajo que puede ser administrada; consumen
recursos, dan como resultado productos de trabajo y dependen de productos de
trabajo producidos por otras tareas
recursos: bienes que se utilizan para realizar el trabajo:
tiempo, equipamiento y recursos humanos
al planificar, el gerente divide el trabajo en tareas y les asigna recursos



objetivos, requerimientos y restricciones
objetivos:
principios de alto nivel que se utilizan para guiar el proyecto
definen los atributos realmente importantes del sistema
(seguridad, fiabilidad,...)
a veces hay conflicto entre objetivos (por ejemplo, seguridad y
bajo coste) que aumentan la complejidad del proyecto
requerimientos
características que debe tener el sistema
requerimiento funcional: área de funcionalidad que debe
soportar el sistema (por ejemplo, proporcionar billetes de tren)
requerimiento no funcional: restricción que se establece sobre
el funcionamiento del sistema (por ejemplo, proporcionar
billetes de tren en menos de un segundo)
otras restricciones: por ejemplo, utilización de un
determinado lenguaje, de una determinada plataforma o de
un sistema antiguo que el cliente no quiere retirar



notaciones, métodos y metodologías
notación: conjunto de reglas gráficas o de texto para
representar un modelo (UML, Unified Modelling Language, es
una notación gráfica orientada a objetos para representar
modelos)
método: técnica repetible para resolver un problema
específico. Por ejemplo:
un algoritmo de ordenación es un método para ordenar
elementos en una lista
la administración de la configuración es un método para el
seguimiento de los cambios
metodología: colección de métodos para la resolución de una
clase de problemas (OMT, metodología de Booch, Catalysis,
Proceso Unificado de Desarrollo,...)


actividades de desarrollo

ingeniería de requerimientos
el cliente y los desarrolladores
ReservaBilletes

definen el propósito y objetivos
del sistema
resultado: descripción del
Com praBillet e
sistema en términos de
Viajero

participantes (actores) y
funciones (casos de uso)
actores: entidades externas
Anulación reserva
que interactúan con el
sistema (incluyen roles como
usuarios finales u otros
Nombre del caso de uso: CompraBillete
sistemas con los que
Nombre del caso de uso: CompraBillete
interactúa el sistema)
Actor participante: Iniciado por Viajero
Actor participante: Iniciado por Viajero
casos de uso: secuencias de
eventos que describen todas
Precondición:
Precondición:
1. El Viajero se para frente al distribuidor automático de billetes
las acciones posibles entre un
1. El Viajero se para frente al distribuidor automático de billetes
actor y el sistema para una
Flujo de eventos:
función específica.
Flujo de eventos:
2. El Viajero selecciona las estaciones de origen y destino
2. El Viajero selecciona las estaciones de origen y destino
se acuerdan requisitos no
3. El DistribuidorDeBilletes muestra el precio del billete
4. El Viajero inserta una cantidad de dinero que, albillete debe
3. El DistribuidorDeBilletes muestra el precio del menos,
funcionales. Por ejemplo:
ser igual que el precio del cantidad de dinero que, al menos, debe
4. El Viajero inserta una billete
5. El igual que el precio del emite el billete especificado al Viajero y
ser DistribuidorDeBilletes billete
el distribuidor de billetes debe
devuelve el cambio si es necesarioel billete especificado al Viajero y
5. El DistribuidorDeBilletes emite
estar disponible al menos un
devuelve el cambio si es necesario
95% del tiempo
Postcondición:
el distribuidor de billetes debe
Postcondición:
6. El Viajero coge el billete y el cambio
dar respuesta en menos de un
6. El Viajero coge el billete y el cambio
segundo después de
Requisitos especiales:
Requisitos especiales:
seleccionada la transacción
Si la transacción no ser termina después de un minuto de
inactividad, el DistribuidorDeBilletes devuelveun minuto de
Si la transacción no ser termina después de todo el dinero
inactividad, el DistribuidorDeBilletes devuelve todo el dinero
insertado
insertado



análisis
se produce un modelo correcto, completo, consistente, claro,
realista y verificable
transformación de los casos de uso en un modelo que
describe por completo el sistema y que se usará en el diseño
descubrimiento y resolución con el cliente de ambigüedades
e inconsistencias en el modelo de casos de uso

Transacción

da como resultado

cantidad pagada
BilleteTren
Saldo
válido para

Zona
Papel
Moneda



diseño
diseño del sistema
Gestión facturas
definición de los objetivos de diseño
comprador
descomposición del sistema en subsistemas
abordables por equipos
selección de estrategias para la construcción
(plataformas hardware y software,
almacenamiento de datos persistentes, control
de acceso,...)
resultado: descripción de las estrategias,
Gestión de planificación Gestión de
de pagos cuentas
descomposición en subsistema

diseño de objetos:
definición de objetos e interfaces de
subsistemas, reestructuración del modelo de
objetos para lograr los objetivos de diseño,
IU Solicitud
de pago
optimización del modelo para mejorar el
rendimiento,...
Co mprado r

resultado: modelo de objetos detallado
Procesamiento de
solicitudes de pago

actividades del diseño
diseño arquitectónico
Procesamiento
Planificador Gestor de de facturas
de pagos
especificación de los subsistemas
pedidos

diseño de interfaz
diseño de componentes
Confirmación Factura
Solicitud
de pedidos
de pago
diseño de la estructura de datos
diseño procedimental (algoritmos)



<<subsystem>> <<subsystem>>
<<s ubsyst em>>
Gestión Trabajos Gestión Sistema
Mantenimientos
Externos
de Gestión

<<subsystem>> <<subsystem>> <<subsystem>>
Gestión Mantenimiento Validación Gestión
Usuarios
Correctivo Instalaciones

<<subsystem>>
Gestión Mantenimiento <<subsystem>>
Preventivo Gestión
Subgrupos-Instalaciones
<<subsystem>>
Gestión Máquinas
Subgrupo



Alta Instalaciones
<<subsystem>> <<subsystem>> <<include>>
<<subsystem>>
Gestión Trabajos Gestión Sistema
Mant enimient os
Externos
de Gestión
<<include>>

Baja Instalaciones

<<include>>

Validar Usuario
<<subsystem>> <<subsystem>> <<subsystem>> Administrador
<<include>>
Gestión Mantenimiento Validación Gestión (from Validación Usuarios)
Usuarios (from Validación Usuarios)
Correcti vo Instalaciones Modificación Instalaciones

<<subsystem>>
Gestión Mantenimiento <<subsystem>>
Consult a Inst alaciones
Preventivo Gestión Operario
Subgrupos-Instalaciones
(from Validación Usuarios)
<<subsystem>>
Gestión Máquinas
Subgrupo

<<subsystem>>
Alta Características-Maq
Gestión <<include>>
Máquinas
<<include>>

Baja Características-Maq
<<include>>
Gestión Carac teríst icas Gestión Tareas Validar Usuario
Máquinas Administrador
Máquinas <<inc lude>> (f rom Validación Usuari os)
(f rom Vali dación Usuari os)

Modificación Características-Maq

Consulta Características-Maq
Operario
(from Validación Usuarios)



Nombre Alta Características Máquina
Prioridad Media
Actor Administrador
Extends Ninguno
Includes Validar Usuario
Pre-Condiciones 1. El usuario está identificado.
2. El usuario selecciona la opción de altas en el
formulario.
Post-Condiciones 1. Los datos de la nueva característica quedan Opciones Frm CTRL Alta Form_Alta Validar Datos Resultado Alta MENSAJES
: A dmi nistra dor
Cliente Instalación INSTALACION
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva característica no quedan Seleccionar
guardados si se produce algún error durante el
proceso. Cre a()
Descripción 1. El sistema muestra el formulario de altas.
Crea()
2. El usuario introduce los datos.
3. El sistema realiza la validación de los datos.
4. Si la característica ya existe [A].
Mostrar
5. Si los datos no son correctos [B].
6. El usuario selecciona la opción de Guardar.
7. El sistema guarda los datos.
8. Si se guarda correctamente se visualiza un mensaje, Introducir Datos()
si hay algún problema el sistema avisa con un
Comprobar()
mensaje de error.
Excepciones El proceso se puede cancelar en cualquier momento.
A. Si la característica ya existe se visualizan sus datos. Obtener Datos
...
B. Datos incorrectos, ir a punto 2.

Mostrar(Datos)

Cubrir_Datos()
Si no Existe

Comprobar()

Datos Correctos Crear_Alta()
Alta Características-Maq
<<include>>
Construir

<<include>>
Visualizar Resultado
<<include>>
Validar Usuario Construir
Datos no Correctos
Administrador
<<inc lude>> (f ro m V a li dación Usuari os)

Modificación Características-Maq Visualizar Mensaje

Fi n S i
Fi n S i

Operario
(from Valida ción Usuarios)



Nombre Alta Características Máquina
Prioridad Media
Actor Administrador
Extends Ninguno
Includes Validar Usuario
Pre-Condiciones 1. El usuario está identificado.
2. El usuario selecciona la opción de altas en el Sistema (from Validar Usuario) Admin istrador (from Al ta Máquinas)
formulario.
Administrador Validado
Post-Condiciones 1. Los datos de la nueva característica quedan
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva característica no quedan
guardados si se produce algún error durante el
proceso.
Descripción 1. El sistema muestra el formulario de altas.
Visualizar Seleccionar
2. El usuario introduce los datos.
Formulario Formulario
3. El sistema realiza la validación de los datos.
4. Si la característica ya existe [A].
5. Si los datos no son correctos [B].
6. El usuario selecciona la opción de Guardar.
Comprobar Introducir
7. El sistema guarda los datos.
Datos Datos
8. Si se guarda correctamente se visualiza un mensaje,
si hay algún problema el sistema avisa con un
mensaje de error. Datos Incorrectos Mensaje quot;Error
Excepciones El proceso se puede cancelar en cualquier momento.
Datosquot;
A. Si la característica ya existe se visualizan sus datos. Datos Correctos
B. Datos incorrectos, ir a punto 2.
Comprobar Existencia
de la Ins talación

Si Existe Visualizar Datos
Instalación

No Existe Seleccionar
Guardar

Alta Características-Maq Guardar Datos
<<include>>
Instalación

<<include>> Error al Guardar Mensaje
quot;Errorquot;
<<include>> In stalación Guardada

Validar Usuario
Administrador Mensaje quot;Instalación
<<inc lude>> (f ro m V a li dación Usuari os)
guardadaquot;

Modificación Características-Maq

Operario
(from Valida ción Usuarios)



Registra-venta-de
Descrita-por
1
n
Especificacion
0..1 CatalogoDe DelProducto
LineaDeVenta Contiene
Product os
descripción
cantidad
1 1..n precio
articuloID
1
1.. n Utilizado-por
n
Contenida-en
Tienda
Abastece
Articulo
direc ción
Registra-completas
nombre
1..n
1 n
1
1
1
Venta
Alberga
n
1..n
fecha
Iniciado-por
hora Registro 1 1 Encargado
1 Capturada-en
1
1
1 1
Pagada-mediante
Iniciada-por Registra-ventas-en
1 1
1
Pago
Cliente
cantidad Cajero



ODBC
Servidor SGBD

TCP/IP

Red Local Impresora
TCP/IP

Cliente

TCP/IP

Cliente



implementación
traducción del modelo de diseño (por ejemplo, del modelo de
objetos) en código fuente
incluye:
implementación de atributos y métodos de cada objeto
integración de todos los objetos para que funcionen como un solo
sistema

pruebas
pruebas de unidad: comparación del modelo de diseño con cada
objeto y subsistema
pruebas de integración: combinaciones de subsistemas y
comparación con el modelo de diseño del sistema
pruebas del sistema: ejecución de casos típicos y excepcionales, y
comparación con el modelo de requerimientos
objetivo: descubrir la mayor cantidad posible de errores que se
puedan reparar antes de entregar el sistema
mantenimiento
mejoras en el sistema (nuevas funciones, facilidad de uso,...)
corrección de errores
adaptación a cambios en el entorno (hardware, software,
legislación,...)
actividad más costosa del ciclo de vida de un producto software


actividades de administración del desarrollo
comunicación
actividad crítica y costosa en tiempo
intercambio de modelos y documentos, informes de evolución
y calidad, negociaciones, comunicación de decisiones,...
herramientas y notaciones
gestión de la configuración
proceso que supervisa y controla los cambios en los productos
de trabajo
cambios: requerimientos, plataformas hardware y software,
errores encontrados, mejoras del sistema,...
administración del proyecto
objetivo: asegurar la entrega de un sistema de alta calidad a
tiempo y dentro del presupuesto
planificación y presupuesto del proyecto
contratación de desarrolladores y coordinación de equipos
vigilancia de la evolución del proyecto
detección de desviaciones e intervención


el proceso de desarrollo


el proceso: modelos de desarrollo

proceso
conjunto ordenado de tareas, una serie de pasos que involucran actividades,
restricciones y recursos, que producen una salida determinada
proceso de software: conjunto de actividades necesarias para transformar los
requisitos de un usuario en un sistema software
características
tiene una serie de actividades principales
utiliza recursos, está sujeto a restricciones y genera productos intermedios y finales
compuesto por subprocesos que se encadenan de alguna forma
cada actividad tiene sus criterios de entrada y salida, que permiten conocer cuando
comienza y termina dicha actividad
existen principios orientadores que explican las metas de cada actividad
cuando implica la construcción de un producto, se suele llamar ciclo de vida
aportan consistencia y estructura sobre el conjunto de actividades, lo que
permite realizar la misma tarea correctamente de forma repetida
existen diferentes modelos de proceso

Requisitos
Sistema software
del usuario Proceso de desarrollo
Proceso de desarrollo
de Software
de Software


modelo en cascada

Requerimentos
y Análisis

Diseño

Implementación

Pruebas

Mantenimiento

resultado de cada fase: uno o más se retrasa la localización y corrección
documentos aprobados de errores
una fase comienza cuando la anterior pueden producir sistemas poco útiles
termina para usuarios o mal estructurados
en la práctica, las etapas se solapan inflexibilidad del modelo: dificultad
para responder a cambios en los
iteraciones de coste elevado y requerimientos
reelaboración del trabajo: tendencia a
la congelación de partes del desarrollo
(especificaciones,...)


desarrollo evolutivo

basado en: dos tipos:
desarrollo de una implementación prototipado evolutivo:
inicial
trabajo con cliente para explorar
exposición a comentarios y crítica del sus requerimientos y entregar un
sistema final
usuario
evolución continua del prototipo
refinamiento a través de diferentes mediante la agregación de
versiones hasta llegar a un sistema funciones y características
adecuado propuestas por el cliente
prototipos desechables
Recolección comprensión de las necesidades
y refinamiento de del cliente
requisitos desarrollo de una definición
mejorada de los requerimientos
del sistema
Producto prototipos centrados en la
Diseño experimentación de requisitos
poco claros o complejos
rápido
problemas
prisas del cliente (utilización del
prototipo como sistema final
Refinamiento Construcción pasar elecciones debidas al prototipo a
del prototipo del prototipo la implementación final (entorno,
sistema operativo,...)
estructura deficiente
Evaluación del evolución del proceso difícil de
prototipo por gestionar
el cliente herramientas y técnicas especiales
poco adecuado para grandes sistemas


prototipado con lenguajes visuales

Hypertext
display component
Date component

File Edit Views Layout Options Help
General
Index
12th January 2000
Range checking 3.876
script

User prompt
component +
Draw canvas script
component

Tree display
component

fuente: I. Sommerville, Software Engineering, 6th ed.,2000


desarrollo incremental

pasos
Definición general de
requerimientos
identificación y priorización de funciones y
servicios
Asignación de requerimientos
definición de varios requerimientos que
a incrementos
proporcionan parte de la funcionalidad, según la
prioridad (los más importantes se entregan
antes)
Diseño de la arquitectura del
definición detallada de requerimientos del
sistema
incremento y desarrollo con el proceso más
adecuado
congelación de requerimientos de incrementos
Desarrollo de incrementos
desarrollados
del sistema

puesta en explotación de los incrementos
completados y entregados
Validar
incrementos
ventajas
puesta en marcha temprana
Integrar
los incrementos iniciales permiten refinar
incrementos
requerimientos de incrementos posteriores
satisfacción del cliente (bajo riesgo de fallo)
Validar
sistema
sistema final muy probado y con pocos fallos
problemas
sistema incompleto
incrementos relativamente pequeños
sistema completo
adaptación de requerimientos a incrementos del
tamaño apropiado
identificación de recursos comunes a todos los
Sistema final
incrementos


Ingeniería del Software de Gestión. Tema 1

Ingeniería del Software de Gestión. Tema 1

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (20)

Similaire à Ingeniería del Software de Gestión. Tema 1

Similaire à Ingeniería del Software de Gestión. Tema 1 (20)

Plus de Enrique Barreiro

Plus de Enrique Barreiro (10)

Dernier

Dernier (15)

Ingeniería del Software de Gestión. Tema 1