Ingeniería Del Softare Orientado A Objetos PDF

Análisis Orientado a Objetos
Ingeniería del Software
M.C. José Martín Olguín Espinoza
M.C. Martín Olguín (C) 2004

Contenido del Curso
1.Introducción a la Ingeniería de Software
1.1. Definiciones de Ingeniería de Software
1.2. Características del Software
1.3. Aplicaciones del Software
1.4. Fases básicas del desarrollo del software
(definición, desarrollo, mantenimiento).

…Contenido del Curso
2.Modelos de Proceso del Software
2.1. Modelo en Cascada (ciclo de vida clásico)
2.2. Modelo en “V”
2.3. Modelo de Construcción de Prototipos
2.4. Modelos Evolutivos
2.4.1. Modelo Incremental
2.4.2. Modelo Espiral
2.4.3. Modelo Espiral WIN-WIN

...Contenido del Curso
3.El Proceso Unificado de Desarrollo (RUP)
3.1. Antecedentes
3.2. Dirigido por casos de uso
3.3. Centrado en la Arquitectura
3.4. Iterativo e Incremental

4.Administración de proyectos de software
4.1. Componentes de un proyecto de software
4.2. Personal
4.3. Producto
4.4. Proceso
4.5. Proyecto

5.Conceptos del Paradigma OO
5.1. El paradigma orientado a objetos
5.2. Clases y Objetos
5.3. Atributos
5.4. Operaciones, métodos y servicios
5.5. Mensajes
5.6. Encapsulamiento
5.7. Herencia
5.8. Polimorfismo
6.El UML
6.1. Vistas
6.1.1. Vista de Casos de Uso
6.1.2. Vista lógica
6.1.3. Vista de Componentes
6.1.4. Vista de la Implementación
6.1.5. Clasificadores y mecanismos de
extensión

6.2. Diagramas
6.2.1. Diagramas de caso de uso
6.2.2. Diagramas de clases
6.2.3. Diagramas de objetos
6.2.4. Diagramas de estado
6.2.5. Diagramas de secuencia
6.2.6. Diagramas de colaboración
6.2.7. Diagramas de actividad
6.2.8. Diagramas de componentes
6.2.9. Diagramas de implementación

7.Ingeniería de Requisitos y Análisis OO
7.1. Especificación de Requisitos
7.2. Modelo de Análisis
8.Diseño OO
8.1. Modelo de Diseño
8.2. Arquitectura del Software
8.3. Patrones de Diseño

9.Implementación
9.1. Programación Orientada a Objetos
9.2. Modelo de Implementación
10. Pruebas OO
10.1. Conceptos
10.2. Pruebas del modelo de análisis y el de diseño
10.3. Pruebas de unidad
10.4. Pruebas de integración
10.5. Pruebas de validación

11. Métricas OO
11.1. Conceptos
11.2. Métricas para el modelo de diseño OO
11.3. Métricas orientadas a clases
11.4. Métricas orientadas a operaciones

Bibliografía
1. Ingeniería del Software: un enfoque
práctico. 5ta edición.
Roger Pressman
McGraw-Hill
2. Ingeniería de Software Orientado a Objetos
Bernd Bruegge
Pearson Educación
3. The Rational Unified Process
Philippe Krutchen
Addison-Wesley

...Bibliografía
1. The Unified Modeling Language. User Guide
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison-Wesley
2. Design Patterns
Erich Gamma
Addison-Wesley
3. El Proceso Unificado de Desarrollo de Software
Ivar Jacobson, Grady Booch y James Rumbaugh
Addison-Wesley

Unidad 1
Introducción a la Ingeniería del
Software

Software
 Es el conjunto de programas de
cómputo, documentos asociados y
esquemas de configuración necesarios
para que estos programas operen.
[Sommerville, 2001]

 Definiciones del prólogo a la cuarta
edición en español de “Ingeniería del
Software: un enfoque práctico” de
Roger Pressman:
 Definición 1:
 Ingeniería del Software es el estudio de los
principios y metodologías para desarrollo y
mantenimiento de sistemas de software.
[Zelkovitz, 1978]
 Definición 2:
 Ingeniería del Software es la aplicación
práctica del conocimiento científico en el
diseño y construcción de programas de
computadora y la documentación asociada
requerida para desarrollar, operar y
mantenerlos. Se conoce también como
desarrollo de software o producción de
software. [Bohem, 1976]

 Definición 3:
 Ingeniería del software trata del
establecimiento de los principios y métodos
de la ingeniería a fin de obtener software
de modo rentable que sea fiable y trabaje
en máquinas reales. [Bauer, 1972]

 Definición 4:
 1. La aplicación de un enfoque sistemático,
disciplinado y cuantificable al desarrollo,
operación (funcionamiento) y
mantenimiento del software; es decir, la
aplicación de ingeniería al software. 2. El
estudio de enfoques como en (1) [IEEE,
1993]

 Definición 5:
 Es una disciplina que comprende todos los
aspectos de la producción de software
desde las etapas iniciales de la
especificación del sistema, hasta el
mantenimiento de éste después de que se
utiliza. [Sommerville, 2001]

Ingeniería de Software e
Ingeniería de Sistemas
Teoría de Sistemas
Ingeniería de
Sistemas
Ingeniería
de
Software

Sistema
 Un sistema es una colección de
componentes interrelacionados que trabajan
conjuntamente para cumplir algún objetivo.

Ingeniería de Sistemas
 La ingeniería de sistemas consiste en la
actividad de especificar, diseñar,
implementar, validar, distribuir y mantener
sistemas como un todo.
 Los ingenieros de sistemas no sólo están
relacionados con el software, sino también
con el hardware y las interacciones del
sistema con los usuarios y su entorno.

Características del Software
 El software se desarrolla, no se fabrica.
 El software no se descompone, se echa a
perder.
 Aunque la industria tiende a ensamblar
componentes, la mayoría del software es
hecho a la medida.

Atributos de un buen software
 Mantenibilidad
 El software debe poder evolucionar para cumplir con las
necesidades de cambio de los clientes.
 Confiabilidad
 El software debe ser fiable, seguro, no debe causar daños físicos o
económicos en el caso de una falla del sistema.
 Eficiencia
 El software debe aprovechar al máximo los recursos del sistema.
 Usabilidad
 El software debe ser fácil de utilizar.

Aplicaciones del Software
 Software de sistemas
 Software de tiempo real
 Software de gestión
 Software de ingeniería y científico
 Software empotrado
 Software de PC’s
 Software basado en Web
 Software de IA
Tarea
 Leer de Pressman la sección 1.4 Mitos del
Software y discutir en clase cada uno de los
mitos presentados.

Unidad 2
Modelos de Proceso del Software

Proceso de Software
 Es un conjunto de actividades y
resultados asociados, que generan un
producto de software, las cuales son
llevadas a cabo por los ingenieros de
software.

Actividades comunes a todo
Proceso de Software
 Especificación
 Diseño e implementación
 Validación
 Evolución
 Distintos procesos organizan estas
actividades de diferentes formas y las
describen a diferente nivel de detalle.
 Organizaciones diferentes utilizan procesos
diferentes
Modelos de Proceso del
software
 Es una descripción de un proceso del
software que se presenta desde una
perspectiva particular. Es una abstracción de
un proceso real.
 Existe una gran variedad de modelos o
paradigmas de desarrollo de software:
 Enfoque de Cascada
 Desarrollo Evolutivo
 Desarrollo Formal
 Desarrollo basado en la reutilización
Modelo de Cascada
Definición de Royce, 1970

requerimientos “Managing the development of
Large software systems: Concepts
And techniques”
IEEE Conference, Los Angeles
Diseño de sistemas
Adoptado por el DoD
y de software
Implementación y
Prueba de unidades
Integración y
prueba del sistema
Operación y
mantenimiento
Modelo en “V”
Operación y
mantenimiento
Definición de Pruebas de
requerimientos aceptación
Diseño de sistemas Pruebas de sistema
Diseño de Pruebas de unidad

programas Y de integración
Codificación
Desarrollo Evolutivo
 Modelo Construcción de prototipos
Especificación Versión inicial
Bosquejo de la Versiones
Versiones
Desarrollo Versiones
descripción intermedias
intermedias
intermedias
Validación Versión final

Modelo Incremental
The management of software engineering
Mills et al., 1980
I BM Systems Journal
Bosquejo de
Definir Diseñar la
los
incrementos arquitectura
requisitos
Diseñar Validar Integar Validar

incremento incremento incremento sistema
Sistem
a
final
Origen del Extreme Programming (XP) Embracing change with extreme programming
Beck, K. 1999
IEEE Computer
Modelo en espiral
A spiral model of software development and enhancement

M.C. Martín Olguín (C) 2004 Bohem, 1988
I EEE Computer
Tarea
 Hacer un ensayo explicando las ventajas y
desventajas de los modelos de proceso de
software analizados en clase.

Tarea
 Preparar una exposición sobre los siguientes temas:

 Agile Methods
 Scrum
 XP
 Crystal
 Test-Driven Design
 Agile Modeling
Referencia inicial:
http://www.agilealliance.org/programs/roadmaps/Roadmap
Presentación el miércoles 25 de agosto

CMM (Capability Maturity
Model)
 Desarrollado por el SEI (Software Engineering
Institute)
 Es un modelo completo basado en un
conjunto de funciones de ingeniería del
software que deberían de estar presentes
conforme organizaciones alcanzan diferentes
niveles de madurez de su proceso.

...CMM
 El enfoque del SEI proporciona una medida

de la efectividad global de las prácticas de la
ingeniería del software de una compañía y
establece 5 niveles de madurez del proceso.
 Nivel 1: Inicial.
 Nivel 2: Repetible.
 Nivel 3: Definido.
 Nivel 4: Administrado.
 Nivel 5: Optimización.
Nivel 1: Inicial
 El proceso se define ad hoc.

 Es caótico.
 El éxito depende del esfuerzo individual.

Nivel 2: Repetible
 Se establecen los procesos de administración

del proyecto para dar seguimiento a los
costos, la planificación y la funcionalidad.
 Se toman en cuenta experiencias anteriores
para repetir las actividades necesarias en el
proceso.

Nivel 3: Definido
 Se documenta el proceso para las actividades

de administración y de ingeniería.
 Se estandariza e integra en un proceso para
toda la organización.
 Todos los proyectos utilizan una versión
documentada y aprobada del proceso.

Nivel 4: Administrado
 Se implementan métricas detalladas para los

proyectos.
 Se establecen estándares de calidad.
 Mediante la utilización de las métricas se
comprenden y se controlan cuantitativamente
tanto los productos como el proceso.

Nivel 5: Optimización
 El proceso se mejora continuamente mediante

la retroalimentación cuantitativa del proceso,
ideas y tecnologías innovadoras.

Auditores CMM
 Requisitos:
 Haber participado en una evaluación en los dos
años anteriores a su solicitud de cursos.
 Cursar las asignaturas.
 Ser líder en una evaluación CMM a una
organización dentro de los dos años siguientes a
los cursos, asesorado por un tutor certificado.
 Obtener la aprobación del tutor.

Tarea
 Investigar información sobre organizaciones

de software con certificación CMM.
 Tamaño
 Tiempo requerido para lograr la certificación
 Costo

Unidad 3
El Proceso Unificado de
Desarrollo (RUP)

El RUP
 Rational Unified Process

 El Proceso Unificado es un proceso de software
genérico que puede ser utilizado para una gran
cantidad de tipos de sistemas de software, para
diferentes áreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de competencia
y diferentes tamaños de proyectos.

Estructura del RUP

RUP y UML
 El Proceso Unificado usa el Lenguaje de

Modelado Unificado (UML) en la preparación
de todos los planos del sistema. De hecho,
UML es una parte integral del Proceso
Unificado, fueron desarrollados a la par.

Características clave del RUP
 Dirigido por casos de uso (use-case

driven).
 Centrado en la arquitectura
(architecture-centric).
 Iterativo e incremental.

Unidad 4
Administración de Proyectos

Exito en proyectos de software
en 1994
Resolution Type 1, or project success:
The project is completed on-time and
on-budget, with all features and
functions as initially specified.
Resolution Type 2, or project

challenged: The project is completed
and operational but over-budget, over
the time estimate, and offers fewer
features and functions than originally
specified.
Resolution Type 3, or project impaired:

The project is canceled at some point
during the development cycle. Fuente: www.standishgroup.com

Exito en Proyectos de Software en
1998
28% 26%
Fracaso Total
Excedido (tiempo y/o

costo)
Exitoso
46% Fuente: “Critical Succes Factors in Software Projects”

Reel, J.S. IEEE Software mayo de 1999

Administración de proyectos
de software
 Implica la planificación, supervisión y control
del personal, del proceso y de los eventos
que ocurren mientras evoluciona el software,
desde la fase preliminar hasta la
implementación operacional.

Características de los
proyectos de software
 El producto es intangible.
 No existen procesos de software estándar.
 Comúnmente los proyectos grandes son
“únicos”.

Las cuatro P's de la
administración de proyectos
 Personal
 El factor humano
 Producto
 Objetivos y el ámbito del producto
 Proceso
 Estructura de apoyo para la planeación
 Proyecto
 Administración de la complejidad

Personal
 Sin duda el elemento más valioso en la
 ¿Quiénes participan en un proyecto de
software?
 Programadores Líder de proyecto
 Arquitectos de software Usuarios
 Analistas/Diseñadores Clientes
 Ingenieros de requerimientos
 Ingenieros de proceso
 Ingenieros de pruebas
...Personal
 ¿Cuáles son las características deseables de

un líder de proyecto?
 Motivador
 Organizado
 Innovador
 Problem Solver

...Personal
 ¿Cómo se organiza el equipo de trabajo?

 Marilyn Mantei en “The effect of Programming
Team Structures on Programming Tasks”, 1981,
sugiere tres tipos genéricos de organización:
 Centralizado Controlado (CC): El jefe del equipo se
encarga de la resolución de problemas a alto nivel y la
coordinación interna del equipo. La comunicación entre
el jefe y los miembros del equipo es vertical.

...Personal
 Descentralizado Controlado (DC): Un jefe definido

que coordina tareas específicas y jefes secundarios
con responsabilidades sobre subtareas. La
resolución de problemas es una actividad del
grupo, la comunicación es horizontal y vertical.
 Descentralizado Democrático (DD) o “Egoless”: No
tiene un jefe permanente, se nombran de acuerdo a la
tarea. La solución de problemas se hacen por
consenso. La comunicación es horizontal.

...Personal
 ¿Qué factores se deben considerar cuando se

estructura un equipo de software?
 Complejidad del proyecto (dificultad del problema,
tamaño del software)
 Tiempo de desarrollo.
 Modularidad.
 Calidad.
 Comunicación requerida.

...Personal
 Discusión sobre ventajas y desventajas de

cada tipo de organización.

...Personal
 ¿Cómo creamos un equipo de alto

rendimiento?
 Según Constantine, L. en “Work Organization:
Paradigms for Project Management and
Organization, 1993:
 Confianza entre los miembros del equipo.
 Distribución de habilidades de acuerdo al problema.
 Los inconformistas deben ser excluidos.

...Personal
 ¿Qué factores pueden contaminar el

desempeño de un equipo?
 Según Jackman, M. en “Homeopathic Remedies
for Team Toxicity”, 1998:
 Atmósfera de trabajo frenética, malgastan energía y se
descentran de los objetivos
 Alta frustración causada por factores tecnológicos, del
negocio o personales que provocan fricción entre los
miembros del equipo.

...Personal
 Procedimientos coordinados pobremente o

fragmentados o una definición pobre o impropiamente
elegida del modelo de procesos que se convierte en un
obstáculo a saltar.
 Definición confusa de los papeles a desempeñar
produciendo una falta de responsabilidad y la
acusación correspondiente.
 Continua y repetida exposición al fallo que conduce a
una pérdida de confianza y una caída de la moral.

...Personal
 ¿Cómo evitamos las toxinas que afectan a los

equipos de software?
 ¿Cómo coordinar las acciones de los
miembros del equipo?

Tarea
 Leer el capítulo 3 del Pressman 5ta. edición

 Realizar los problemas 3.1, 3.4, 3.6 al 3.11

Tareas de la Administración de
Proyectos
 Estimación del tamaño del proyecto
 LDC
 PF
 COCOMOII
 Planificación temporal
 Barras de Actividad
 Red de actividades
 Administración del Riesgo
 Supervisión y Control
Métricas para Estimación
 Se clasifican en dos:
 Medidas relacionadas al tamaño
 Se relacionan con el tamaño de la salida de alguna
actividad.
 La métrica más común es Líneas de Código (LDC)
 Dependen del lenguaje de programación y en general
no es una buena medida para POO.
 Medidas relacionadas a la función

Medidas Relacionadas a la
Función
 Son medidas que se relacionan con la
funcionalidad del software.
 Las más comunes son:
 Puntos de Función (PF)
 Puntos de Objeto (PO)

Puntos de Función
 Es una medida de la funcionalidad entregada
por la aplicación.
 Es una medida indirecta, a diferencia de
LDC.
 Propuesta por primera vez en:
 Albretch, A.J., “Measuring Application
Development Productivity”, Proceedings IBM
Application Development Symposium, Octubre
1979.
 Consultar en www.ifpug.org versión 4.1
Cálculo de PF
Factor de ponderación
Parámetros de Cuenta Simple Medio Complejo

medición
Número de entradas de [ ]x3 [ ]x4 [ ]x6 =
usuario
Número de salidas de [ ]x4 [ ]x5 [ ]x7 =
usuario
Número de peticiones de [ ]x3 [ ]x4 [ ]x6 =
usuario
Número de archivos [ ]x7 [ ]x10 [ ]x15 =
Número de interfaces [ ]x5 [ ]x7 [ ]x10 =
externas
Conteo Total (UFP)

...Cálculo de PF
 El UFP (Unadjusted Function Point count) se
multiplica por factores de complejidad del
proyecto para obtener el PF final:

PF = UFP x [0.65 + 0.01 x  (F )]
i

Fi
1. ¿Requiere el sistema copias de seguridad y de recuperación fiables? 0-5
2. ¿Se requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico el rendimiento?
5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?
6. ¿Requiere el sistema entradas de datos interactivas?

7. ¿Las entradas interactivas se harán en múltiples pantallas y operaciones?
8. ¿Se actualizan los archivos maestros de forma interactiva?
9. ¿Son complejas las entradas, salidas, archivos y peticiones?
10. ¿Es complejo el procesamiento interno?
11. ¿El diseño del código es reutilizable?
12. ¿El diseño incluye conversión e instalación?
13. ¿El diseño incluye soporte para múltiples instalaciones en diferentes orgs.
14. ¿El diseño facilita los cambios y la usabilidad?
Relación entre LDC y PF
Lenguaje de Programación LDC/PF (media)
Ensamblador 320
C 128
COBOL 106
FORTRAN 106
Pascal 90
C++ 64
Visual Basic 32
PowerBuilder 16
SQL 12
Jones, C. Estimating Software Costs, McGraw-Hill, 1998

Puntos de Objeto
 También es una medida indirecta del
software.
 NO es una medida de las clases necesarias
para construir la aplicación.
 Los elementos que toma en cuenta son:
 Pantallas
 Informes (reportes)
 Componentes (o código en 3GL)

Cálculo de Puntos Objeto
Peso de la complejidad
Tipo de Objeto Simple Medio Complejo
Pantallas [ ]x1 [ ]x2 [ ]x3 =
Informes [ ]x2 [ ]x5 [ ]x8 =
Componente 3GL [ ]x10 =
Puntos Objeto
Bohem, B., “Anchoring de software process”, IEEE Software, julio 1996

Técnicas de Estimación de
Costos
Modelado del Utiliza un modelo con información histórica de
costos, relaciona una métrica con el costo del
algoritmo de proyecto. Se estima la métrica y se predice el
esfuerzo.
costos
Opinión de Se consultan expertos en las técnicas de desarrollo
propuestas y el dominio de la aplicación. Cada uno
expertos estima el costo y se consensa después de varias
iteraciones.
Estimación por Cuando se han completado proyectos del mismo

dominio de la aplicación se estima en base a la
analogía experiencia.
Ley de Parkinson Establece que el trabajo se expande para llenar el

tiempo disponible. El costo se determina más por los
recursos disponibles que por los objetivos logrados.

El modelo COCOMO
 Constructive Cost Model
 Es un modelo de estimación empírico desarrollado
por Bohem.
 Se obtuvo recolectando datos de varios proyectos
de software grandes.
 Como resultado del análisis de los datos se
obtuvieron fórmulas y tablas que se ajustan a las
observaciones.
 Es muy utilizado y ha tenido seguimiento desde su
aparición en 1981.

COCOMO II
 Es el modelo más reciente
 Consta de estimación en tres niveles:
 Construcción de propotipo inicial
 Se usa al inicio del proyecto
 Diseño inicial
 Se aplica cuando se tienen la mayoría de los
requisitos y diseño preliminar
 Postarquitectónico
 Se aplica cuando ya se tiene la arquitectura

COCOMO II Nivel Inicial
PM = (PO x (1 - Reutilización))/PROD
Donde:
PM = Esfuerzo Persona-Mes
PO = Puntos Objeto
Reutilización = %reutilización/100
PROD = 4, 7, 13, 25, 50 dependiendo de la experiencia y
capacidad de los desarrolladores y/o Madurez del proceso
(Muy baja, baja, normal, alta, muy alta) dada en PO/mes

...COCOMO II
 Estimación de calendario
TC = 3 x PM(0.33+0.2*(B-1.01))
Para el nivel inicial: B=1
TC = 3 x PM(0.328)
TC está dada en meses.

Planificación Temporal
 Es la actividad que distribuye el esfuerzo
estimado a lo largo de la duración prevista
del proyecto.
 Evoluciona con el tiempo.
 “El proyecto se ha completado en un 90%”

Gráficas de Barras de Actividad

Red de Actividades

Administración del Riesgo
 Etapas
 Identificación de riesgos
 Análisis de riesgos
 Valorar las probabilidades y consecuencias
 Planeación de riesgos
 Planes para evitar o minimizar el impacto
 Supervisión de riesgos
 Valoración constante, revisión de planes de
mitigación conforme se vaya presentando información
del riesgo.
Ejemplos de Riesgos
Riesgo Tipo
Rotación de personal Proyecto
Cambio de administración Proyecto
No disponibilidad del hardware Proyecto
Cambio de requerimientos Proyecto y producto
Retrasos en la especificación Proyecto y producto
Subestimación del tamaño Proyecto y producto
Bajo desempeño de la herramienta CASE Producto
Cambio de tecnología Negocio

Proceso de Administración del
Riesgo
Identificación de Análisis de Planeación de Supervisión de

Riesgos Riesgos Riesgos Riesgos
Anulación de
Listado de Riesgos Listado de prioriza- Valoración de
Riesgos y planes de
potenciales ción de riesgos Riesgos
contingencia

Ingeniería Del Softare Orientado A Objetos PDF

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

Ingeniería Del Softare Orientado A Objetos PDF

Cargado por

Copyright:

Formatos disponibles

Análisis Orientado a Objetos

Ingeniería del Software

M.C. José Martín Olguín Espinoza

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

Definición de Royce, 1970

Diseño de sistemas Pruebas de sistema

Diseño de Pruebas de unidad

Especificación Versión inicial

Validación Versión final

M.C. Martín Olguín (C) 2004

Diseñar Validar Integar Validar

A spiral model of software development and enhancement

M.C. Martín Olguín (C) 2004

 Preparar una exposición sobre los siguientes temas:

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

 El enfoque del SEI proporciona una medida

 El proceso se define ad hoc.

M.C. Martín Olguín (C) 2004

 Se establecen los procesos de administración

M.C. Martín Olguín (C) 2004

 Se documenta el proceso para las actividades

M.C. Martín Olguín (C) 2004

 Se implementan métricas detalladas para los

M.C. Martín Olguín (C) 2004

 El proceso se mejora continuamente mediante

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

 Investigar información sobre organizaciones

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

 Rational Unified Process

M.C. Martín Olguín (C) 2004

M.C. Martín Olguín (C) 2004

 El Proceso Unificado usa el Lenguaje de

M.C. Martín Olguín (C) 2004

 Dirigido por casos de uso (use-case

M.C. Martín Olguín (C) 2004