Clase 5

Ingeniería de software
Ing. Fernando Ibarra

“La ingeniería de software es una disciplina que integra

métodos, herramientas y procedimientos para el
desarrollo de software de computadora.”
Modelos de la Ingeniería de
Software
MODELO DE CAPACIDAD DE
MADUREZ (CMM)
MADUREZ (CMM)
• CMM es un modelo para
determinara la madurez de los
procesos de software y de la
organización, y la identificación e
prácticas claves requeridas para el
mejoramiento e incremento de la
madurez de los procesos.
• Producción de software de calidad,
software que sea entregado, etc.
MADUREZ (CMM)
• Es un modelo de prácticas
fundamentales que deben ser
implementadas por toda
organización interesada en
desarrollar y mejorar la calidad
de sus productos.
MADUREZ (CMM)
• PROCESO INMADURO
No está documentado, es difícil de
compartirlo con otros miembros
del equipo, no es fácil reproducirlo
en nuevos proyectos, no hay
entrenamiento, no todo el mundo
conoce, no se mide, es
interpretado de manera distinta.
MADUREZ (CMM)
• PROCESO MADURO
✓ Está definido: el proceso es claro,
sistemático y suficientemente
detallado.
✓ Está documentado: está escrito en
un procedimiento publicado,
aprobado y fácilmente accesible.
Una de las mejores maneras es a
través de una intranet para apoyar
los proyectos de desarrollo
MODELO DE CAPACIDAD DE MADUREZ
(CMM)
• PROCESO MADURO
✓ El personal ha sido entrenado en el
proceso: los ingenieros de software y la
gerencia han recibido cursos y
entrenamiento en cada proceso que
aplica a su trabajo.
✓ Es practicado: el proceso definido debe
ser usado en las tareas habituales
llevadas a cabo por los proyectos. El
entrenamiento y la adaptación del
proceso a la realidad de la empresa
debieran garantizar su aplicación en la
vida real.
MADUREZ (CMM)
• PROCESO MADURO
✓ Es apoyado: la gerencia no solo
debe firmar y promover los
procesos definidos, sino que
además debe asignar
responsabilidad al personal y a
los jefes del proyecto por su
cumplimiento.
MADUREZ (CMM)
• PROCESO MADURO
✓ Es mantenido: el proceso es
revisado regularmente, para
asegurarse que está adaptado para
satisfacer las necesidades reales de
los proyectos.
✓ Está controlado: los cambios y
puestas al día del proceso son
revisados, aprobados y
comunicados oportunamente a
todos los usuarios.
MADUREZ (CMM)
• PROCESO MADURO
✓ Se verifica: la gerencia mantiene
mecanismos para asegurarse que
todos los proyectos siguen el
proceso vigente.
✓ Se valida: se asegura que el
proceso mantiene concordancia
con los requerimientos y
estándares aplicables.
MADUREZ (CMM)
• PROCESO MADURO
✓ Se mide: la utilización, los
beneficios y el rendimiento
resultante del proceso se miden
regularmente.
✓ Pueden mejorarse: existen
mecanismos y apoyo de la
gerencia para revisar e introducir
cambios en el proceso, de manera
de mejorar su eficacia e incorporar
nuevas metodologías.
MADUREZ (CMM)
• Niveles de Madurez
MADUREZ (CMM)
• Nivel 1: Inicial En este nivel la
capacidad del proceso es imprevisible,
no se cumplen los procedimientos
establecidos, la planificación de los
proyectos y los costos estimados.
• El desempeño del proyecto depende
de la capacidad del equipo de trabajo
y varía con sus habilidades natas,
conocimiento y motivaciones.
MADUREZ (CMM)
• Nivel 1: El proceso en este nivel es
clasificado como ad hoc o caótico, ya
que el proceso es improvisado: no existe
control de cambios y el proceso no es
controlado, ni medido.
• Típicamente los administradores se
abocan en resolver “crisis inmediatas”,
dejando de lado el proceso, centrándose
en las tareas de codificación y testing.
MADUREZ (CMM)
• Nivel 1: En este nivel existen pocos
procesos de software estables, y
el desempeño sólo puede predecirse
por la capacidad del grupo de trabajo,
en lugar de contar con un proceso
organizacional. Todas las
organizaciones por defecto se
encuentran en este nivel.
MADUREZ (CMM)
• Nivel 2: Repetible En este nivel, se
establecen políticas para administrar los
proyectos y procedimientos para
verificar que esas políticas son
implementadas y seguidas.
• Este nivel se define como repetible, por
el concepto de repetir el éxito logrado
en proyectos anteriores, en nuevos
proyectos de similares características.
MADUREZ (CMM)
• Nivel 2: Al implementar las prácticas
claves de este nivel la organización gana
en experiencia y además le permite
conocer sus procesos, con cual se
realizan planes y estimaciones más
realistas (basadas en la experiencia) que
le permiten lograr sus objetivos de
calidad, costo y planificación.
(CMM)
• Nivel 2: Los proyectos entonces,
implementan procesos efectivos, que están
bien definidos, documentados, practicados,
entrenados y medidos, pero que pueden ser
mejorados.
• Los plazos, costos y recursos estimados en los
proyectos son más reales.
• Para lograr esto, es necesario, llevar un
recuento en cada proyecto acerca de costos,
tiempo y funcionalidad (esto puede estar
sustentado por una base de datos del
proceso).
MADUREZ (CMM)
• Nivel 2: Si se presentara el caso, los
problemas para cumplir estos
compromisos son detectados en su
momento, ya que se cuenta con
prácticas de supervisión y control, tanto
del proyecto como del proceso.
• La capacidad del proceso de software de
este nivel puede resumirse como
“disciplinada”, porque planea y controla
si el proyecto se mantiene estable y
pueden repetirse los éxitos más
tempranamente.
(CMM)
• Nivel 2: Se puede decir que el proyecto de
software está bajo control por un sistema de
administración eficaz, siguiendo planes realistas,
basado en el desempeño de proyectos
anteriores.
• Las actividades necesarias para evolucionar al
siguiente nivel son:
– Establecer un grupo de proceso, que se
dedique por completo al mejoramiento
continuo del proceso.
– Definir una arquitectura para el proceso de
desarrollo de software.
– Introducir una familia de métodos y
tecnologías de ingeniería de software.
MADUREZ (CMM)
• Nivel 3: Definido
• La característica principal de este nivel
es que se cuenta con un proceso de
software estándar para desarrollar y
mantener el software.
• Este proceso se encuentra definido y
documentado y es implementado a lo
largo de toda la organización en
distintos proyectos.
(CMM)
• Algunos aspectos claves de este nivel son :
– Se hace uso de prácticas de ingeniería de
software para estandarizar el proceso de
software definido.
– Un grupo es responsable por las
actividades del proceso de software.
– Un programa de entrenamiento es
implementado para asegurar que el
equipo de trabajo, tengan el
conocimiento y las habilidades
requeridas para cumplir sus roles
asignados.
MODELO DE CAPACIDAD DE MADUREZ (CMM)
– El proceso de software estándar de la
organización se “organiza” para cada proyecto,
para así determinar el proceso de software
definido del proyecto.
– Este contendrá información sobre los productos
de trabajo en cada etapa de desarrollo, sus
entradas, estándares y procedimientos utilizados
para desarrollar el trabajo, mecanismos de
control y sus salidas.
– La capacidad del proceso de software de este
nivel puede resumirse como “consistente y
estándar” porque las actividades de ingeniería y
administración son estables y repetibles.
(CMM)
– Dentro de las líneas del producto son
verificadas y están bajo control: la
planificación, el costo y la calidad del
software.
• Esta capacidad del proceso está basada en un
entendimiento común de la organización, de
las actividades, roles, y responsabilidades del
proceso de software.
MADUREZ (CMM)
• Las actividades necesarias para
evolucionar al siguiente nivel son:
– Establecer un conjunto básico de
métricas de procesos, para
identificar parámetros de calidad y
costo de cada paso del proceso.
– Establecer una base de datos del
proceso de software y destinar los
recursos necesarios para
administrarla y mantenerla.
(CMM)
• Las actividades necesarias para evolucionar al
siguiente nivel son:
– Disponer de los recursos suficientes para
reunir y mantener los datos del proceso
y para asesorar a los miembros de los
proyectos para que los usen.
– Evaluar la calidad relativa de cada
producto e informar a la gerencia acerca
de los objetivos de calidad que no han
sido alcanzados.
MADUREZ (CMM)
• Nivel 4: Administrado
• En el nivel administrado, la organización
fija metas de calidad cuantitativas para
el proceso y los productos de software.
La productividad y la calidad son
medidas para las actividades
importantes del proceso en todos los
proyectos, como parte de un programa
de control organizacional.
(CMM)
• Una base de datos se utiliza para almacenar y
analizar los datos disponibles de los procesos
definidos de los proyectos.
• Los procesos de software son
instrumentados con medidas bien definidas y
consistentes.
• Estas medidas, establecen la base
cuantitativa para evaluar el proceso de
software de los proyectos y sus productos.
MADUREZ (CMM)
• Los proyectos logran el control sobre sus
productos y procesos estrechando el
margen de variación en su rendimiento,
para caer dentro de límites cuantitativos
aceptables.
• La capacidad del proceso de software de
este nivel puede resumirse
“cuantificable y predecible”, porque los
procesos y productos, son medidos y
operan dentro de límites cuantificables.
MADUREZ (CMM)
• Este nivel de capacidad, permite a una
organización predecir las tendencias
en el proceso y calidad del producto,
dentro de límites definidos.
• Cuando estos límites se exceden, se
toman las acciones necesarias para
corregir la situación.
MADUREZ (CMM)
• Las actividades necesarias para
evolucionar al siguiente nivel son:
– Soportar la obtención automática
de datos del proceso de software.
– Usar estos datos para analizar y
modificar el proceso para prevenir
problemas y mejorar la eficiencia.
MADUREZ (CMM)
• Nivel 5: Optimizando
• En el nivel optimizando, la organización
entera se enfoca en una continua
mejora del proceso.
• La organización tiene los medios para
identificar las debilidades y fortalezas
del proceso, con la meta de prevenir la
ocurrencia de fallas. Los equipos de
trabajo de Nivel 5 analizan los defectos
para determinar sus causas.
MADUREZ (CMM)
• Se evalúan los procesos de software
para prevenir que ocurran tipos de
errores conocidos, las lecciones
aprendidas son aplicadas en otros
proyectos.
• En este nivel, los gerentes son capaces
de estimar y después dar un
seguimiento cuantitativo al impacto y a
la efectividad del cambio.
(CMM)
• A partir de la eficiencia del proceso, es
posible generar reportes de costo - beneficio
de nuevas tecnologías o proponer cambios al
proceso estándar de la organización.
• La capacidad del proceso de software de este
nivel puede resumirse como un
“mejoramiento continuo”, porque las
organizaciones de Nivel 5 están
continuamente esforzándose para mejorar el
rango de su capacidad del proceso,
mejorando así, el rendimiento del proceso de
sus proyectos.
MADUREZ (CMM)
• La mejora ocurre por los avances
incrementales en el proceso existente
y las innovaciones al usar las nuevas
tecnologías y métodos.
MODELO DE CAPACIDAD DE MADUREZ (CMM)
• Beneficios
• Mejora del alineamiento del software con
la Estrategia de Negocio al integrar bajo
una visión los sistemas, los procesos, las
personas y la tecnología lo cual permite
tener las tecnologías alineadas lo cual
define los servicios y funciones de TIC
aportando el máximo valor exigido.
• Reducción en los costes y en las
desviaciones en plazo de los
“Proyectos software” al proveer un
conocimiento y administración de los
requerimientos.
MADUREZ (CMM)
• Beneficios
• Mayor eficacia en la detección de errores a lo largo
del ciclo de vida de los “Proyectos software“,
reduciendo drásticamente el número de errores
que afecta directamente a los clientes y usuarios, al
proveer un conocimiento y administración de los
riesgos y de exigencias de calidad.
• Resultados más predecibles en los proyectos al
proveer conocimiento y administración de la
información relevante al proyecto, del equipo y de
las exigencias de los clientes.
MODELO DE CAPACIDAD
DE MADUREZ (CMM)
• Beneficios
• Implementación de técnicas pro-
activas de gestión, mitigando los
riesgos que afectan a los proyectos.
• Liberación de tensiones,
malentendidos y vacíos de
responsabilidad en
“Proyectos software” al proveer
mecanismos de control de conflictos
de manera reactiva y proactiva.
MADUREZ (CMM)
• Beneficios
• Disposición de información de gestión útil
a la hora de tomar decisiones ya sean
éstas relacionadas con la Gestión de
“Proyectos software“, bien con la mejora
continua del “Proceso software“.
• Mejorar el posicionamiento frente al
mercado al tener información interna
alineada con los objetivos estratégicos y
por ende en consonancia con información
externa.
MADUREZ (CMM)
• Tipos
• PMMM (Project Management Maturity
Model), publicado en 1992, este modelo
analiza el nivel de a través de 5 niveles de
medición:
– i) Inicial
– ii) Repetición
– iii) definición
– iv) Dirección
– v) Optimización.
MADUREZ (CMM)
• Tipos
• Kezner, publicado en el año 2000, este
modelo consta de 183 preguntas
distribuidas en cinco niveles de medición:
– i) lenguaje común (80 preguntas)
– ii) Procesos comunes (20 preguntas)
– iii) Metodología común (42 preguntas)
– iv) Comparación (25 preguntas
– v) Mejoramiento continuo (16
preguntas).
MADUREZ (CMM)
• Tipos
• OPM3 (Organizational, Project Management
Maturity Model), desarrollado en el año 2003
y actualizado en el 2008 en una segunda
versión, este modelo describe la metodología de
medición de madurez organizacional en gerencia
de proyectos de acuerdo a los estándares.
• El OPM3 establece una rejilla de buenas prácticas
para los niveles de estandarización, medición,
control y mejora continua para proyectos,
programas y portafolio. Entre sus fortalezas
destacan:
– Se basa en normas organizacionales
MADUREZ (CMM)
• Tipos
• OPM3 (Organizational, Project
Management Maturity Model)
Entre sus fortalezas destacan:
– Permite identificar las buenas
prácticas requeridas para mejorar las
capacidades en dirección de proyectos
y sus vinculaciones entre sí a nivel de
procesos de dirección, áreas de
conocimiento, procesos de gestión,
procesos de estandarización,
medición, control y mejora continúa.
MADUREZ (CMM)
• Tipos
– Proporciona un medio objetivo para
evaluar la madurez en dirección de
proyectos con respecto a un conjunto
de mejores prácticas reconocidas a
nivel mundial y que prontamente se
encontrarán vinculadas con una
norma ISO.
MADUREZ (CMM)
• Tipos
– Incorpora la experiencia y
conocimientos de cientos de
profesionales en dirección de
proyectos de un amplio espectro de
industrias y área geográficas reflejadas
a través de buenas prácticas para la
gestión de portafolios.
MODELO EN CASCADA
MODELO EN CASCADA
También conocido como desarrollo
secuencia de software, ya que
permite representar un proyecto en
base a unas fases que suceden entre
sí.
MODELO EN CASCADA
¿Qué es el modelo en cascada?
Es un procedimiento lineal que se
caracteriza por dividir los procesos de
desarrollo en sucesivas fases de proyecto.
Al contrario que en los modelos iterativos,
cada una de estas fases se ejecuta tan solo
una vez.
Los resultados de cada una de las fases
sirven como hipótesis de partida para la
siguiente. El waterfall model se utiliza,
especialmente, en el desarrollo de software.
MODELO EN CASCADA
¿Cómo funciona el modelo en cascada?
• El modelo está compuesto por siete fases
que se ha de ejecutar en diversas vueltas
(iteraciones):
• Requisitos de sistema
• Requisitos de software
• Análisis
• Diseño
• Implementación
• Prueba
• Servicio
MODELO EN CASCADA
Procedimiento de la metodología
en cascada
MODELO EN CASCADA
Procedimiento de la metodología en cascada
Análisis
• Todo proyecto de software comienza
con una fase de análisis que incluye un
estudio de viabilidad y una definición
de los requisitos.
• En el estudio de viabilidad se evalúan
los costes, la rentabilidad y la
factibilidad del proyecto de software.
MODELO EN CASCADA
Procedimiento de la metodología en
cascada
Análisis
• El estudio de viabilidad da como
resultado un pliego de condiciones
(una descripción general de los
requisitos), un plan y una
estimación financiera del proyecto,
así como una propuesta para el
cliente, si fuera necesario.
MODELO EN CASCADA
Análisis
• A continuación, se realiza una definición
detallada de los requisitos, incluyendo un
análisis de la situación de salida y un
concepto.
• Mientras que los análisis de salida se
encargan de describir la problemática en
sí, el concepto ha de definir qué funciones
y características debe ofrecer el producto
de software para cumplir con las
correspondientes exigencias.
MODELO EN CASCADA
cascada
Análisis
• La definición de los requisitos da
como resultado un pliego de
condiciones, una descripción
detallada de cómo se han de
cumplir los requisitos del proyecto,
así como un plan para la prueba de
aceptación, entre otros.
MODELO EN CASCADA
cascada
Análisis
• Por último, la primera fase del
waterfall model incluye un análisis
de la definición de los
requisitos en el que los problemas
complejos se dividen en pequeñas
tareas secundarias y se elaboran
las correspondientes estrategias de
resolución.
MODELO EN CASCADA
Diseño
• La fase de diseño sirve para formular una
solución específica en base a las
exigencias, tareas y estrategias definidas
en la fase anterior.
• En esta fase, los desarrolladores de
software se encargan de diseñar
la arquitectura de software, así como
un plan de diseño detallado del mismo,
centrándose en componentes concretos,
como interfaces, entornos de trabajo o
bibliotecas.
MODELO EN CASCADA
cascada
Diseño
• La fase de diseño da como
resultado un borrador
preliminar con el plan de
diseño del software, así como
planes de prueba para los
diferentes componentes.
MODELO EN CASCADA
Implementación
• La arquitectura de software concebida
en la fase de diseño se ejecuta en
la fase de implementación, en la que
se incluye la programación del
software, la búsqueda de errores y
las pruebas unitarias.
• En la fase de implementación, el
proyecto de software se traduce al
correspondiente lenguaje de
programación.
MODELO EN CASCADA
Implementación
• Los diversos componentes se
desarrollan por separado, se
comprueban a través de las pruebas
unitarias y se integran poco a poco en
el producto final.
• La fase de implementación da como
resultado un producto de software
que se comprueba por primera vez
como producto final en la siguiente
fase (prueba alfa).
MODELO EN CASCADA
cascada
Pruebas
• La fase de prueba incluye la
integración del software en el
entorno seleccionado.
• Por norma general, los productos de
software se envían en primer lugar a
los usuarios finales seleccionados
en versión beta (pruebas beta).
MODELO EN CASCADA
cascada
Pruebas
• Las pruebas de aceptación desarrolladas
en la fase de análisis permiten
determinar si el software cumple con las
exigencias definidas con anterioridad.
• Aquellos productos de software que
superan con éxito las pruebas beta están
listos para su lanzamiento.
MODELO EN CASCADA
cascada
Servicio
• Una vez que la fase de prueba ha
concluido con éxito, se autoriza
la aplicación productiva del
software. La última fase del
modelo en cascada incluye
la entrega, el mantenimiento y
la mejora del software.
MODELO EN CASCADA - Ventajas y desventajas
MODELO EN CASCADA
Verificación
• Los resultados de cada una de las fases
de proyecto se deben comparar y
verificar inmediatamente con los
documentos elaborados previamente.
• Es decir, inmediatamente después de
desarrollar un módulo, por ejemplo, se
debería garantizar que este cumple con
las exigencias definidas con anterioridad
sin esperar a que concluya el proceso de
desarrollo.
Modelo de prototipos
Modelo de prototipos
• También conocida como desarrollo con
prototipación o modelo de desarrollo
evolutivo.
• Este modelo se utiliza para dar al usuario
una vista preliminar del software.
• Este modelo es básicamente prueba y
error ya que si al usuario no le gusta una
parte del prototipo significa que la
prueba fallo.
Modelo de prototipos - Etapas
• Recolección y refinamiento de requisitos
• Modelado, diseño rápido
• Construcción del prototipo
• Desarrollo, evaluación del prototipo por
el cliente
• Refinamiento del prototipo
• Producto de ingeniería.
Modelo de prototipos - Ventajas
• No modifica el flujo del ciclo de vida.
• Reduce el riesgo de construir productos
que no satisfagan las necesidades de los
usuarios.
• Reduce el costo y aumenta la
probabilidad de éxito.
• Exige disponer de las herramientas
adecuadas.
• Este modelo es útil si el cliente conoce los
alcances y objetos del software.
Modelo de prototipos -
Desventajas
• El usuario con un determinado prototipo
puede confundirse que el producto ya
está terminado.
• El desarrollador puede caer en el error de
ampliar mucho el prototipo y quedarse
sin tiempo para el desarrollo final del
producto.
Modelo de prototipos - Tipos
• Modelo de Prototipos rápido:
Metodología de diseño que
desarrolla rápidamente nuevos
diseños, los evalúa y prescinde
del prototipo cuando el
próximo diseño es desarrollado
mediante un nuevo prototipo.
• Modelo de Prototipos reutilizable:
También conocido como "Evolutionary
Prototyping"; no se pierde el esfuerzo
efectuado en la construcción del prototipo
pues sus partes o el conjunto pueden ser
utilizados para construir el producto real.
Mayormente es utilizado en el desarrollo
de software, si bien determinados productos
de hardware pueden hacer uso del prototipo
como la base del diseño de moldes en
la fabricación con plásticos o en el diseño de
carrocerías de automóviles.
• Modelo de Prototipos Modular: También
conocido como Prototipado Incremental
(Incremental prototyping); se añaden
nuevos elementos sobre el prototipo a
medida que el ciclo de diseño progresa.
• Modelo de Prototipos Horizontal: El
prototipo cubre un amplio número de
aspectos y funciones pero la mayoría no
son operativas. Resulta muy útil para
evaluar el alcance del producto, pero no
su uso real.
• Modelo de Prototipos Vertical: El
prototipo cubre sólo un pequeño número
de funciones operativas. Resulta muy útil
para evaluar el uso real sobre una
pequeña parte del producto.
• Modelo de Prototipos de Baja-fidelidad:
El prototipo se implementa con papel y
lápiz, emulando la función del producto
real sin mostrar el aspecto real del
mismo. Resulta muy útil para realizar
tests baratos.
• Modelo de Prototipos de Alta-
fidelidad: El prototipo se
implementa de la forma más
cercana posible al diseño real en
términos de aspecto, impresiones,
interacción y tiempo.
Modelo de prototipos – Tipos de
prototipos
Hay dos clases de prototipos el
desechable y el evolucionario.
• El desechable: nos sirve para
eliminar dudas sobre lo que
realmente quiere el cliente
además para desarrollar la
interfaz que más le convenga al
cliente.
Modelo de prototipos – Tipos de
prototipos
Hay dos clases de prototipos el
desechable y el evolucionario.
• El evolucionario: es un modelo
parcialmente construido que
puede pasar de ser prototipo a
ser software pero no tiene una
buena documentación y calidad.
Modelo RUP
Modelo RUP
• Es un proceso de ingeniería de
software, que hace una propuesta
orientada por disciplinas para lograr
las tareas y responsabilidades de una
organización que desarrolla software.
• Su meta principal es asegurar la
producción de software de alta
calidad que cumpla con las
necesidades de los usuarios, con una
planeación y presupuesto predecible.
Modelo RUP
• Provee un entorno de proceso de
desarrollo configurable, basado en
estándares.
• Permite tener claro y accesible el
proceso de desarrollo que se sigue.
• Permite ser configurado a las
necesidades de la organización y del
proyecto.
• Provee a cada participante con la
parte del proceso que le compete
directamente, filtrando el resto.
Modelo RUP - Fases
Inicio (Inception)
El objetivo general de esta fase es establecer un
acuerdo entre todos los interesados acerca de los
objetivos del proyecto.
Es significativamente importante para el
desarrollo de nuevo software, ya que se asegura
de identificar los riesgos relacionados con el
negocio y requerimientos.
Para proyectos de mejora de software existente,
esta fase es más breve y se centra en asegurar la
viabilidad de desarrollar el proyecto.
Modelo RUP - Fases
Elaboración
El objetivo en esta fase es establecer
la arquitectura base del sistema para
proveer bases estables para el
esfuerzo de diseño e implementación
en la siguiente fase.
La arquitectura debe abarcar todas
las consideraciones de mayor
importancia de los requerimientos y
una evaluación del riesgo.
Modelo RUP - Fases
Construcción
El objetivo de la fase de construcción
es clarificar los requerimientos faltantes
y completar el desarrollo del
sistema basados en la arquitectura base.
Vista de cierta forma esta fase es un
proceso de manufactura, en el cual el
énfasis se torna hacia la administración
de recursos y control de la operaciones
para optimizar costos, tiempo y calidad.
Modelo RUP - Fases
Transición
Esta fase se enfoca en asegurar que el
software esté disponible para sus usuarios.
Se puede subdividir en varias iteraciones,
además incluye pruebas del producto para
poder hacer el entregable del mismo, así
como realizar ajuste menores de acuerdo a
ajuste menores propuestos por el usuario.
En este punto, la retroalimentación de los
usuarios se centra en depurar el producto,
configuraciones, instalación y aspectos sobre
utilización.

Clase 5

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 5

Cargado por

Copyright:

Formatos disponibles

Ingeniería de software

Ing. Fernando Ibarra

“La ingeniería de software es una disciplina que integra

También podría gustarte