Tema1 (INTRODUCCION A LA INGENEIRIA DE SW) PDF

1
INGENIERÍA del SOFTWARE

Curso 2004/05
Ingeniería en Informática
Facultad de Informática
UPV/EHU
Departamento de Lenguajes
y Sistemas Informáticos
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
Tema 1:
Introducción a la
Ingeniería del Software

A. Goñi, J.R. Zubizarreta, J. Iturrioz
Dpto. LSI. Facultad de Informática. UPV/EHU
2
Índice
• 1. Definición de Ingeniería del Software

• 2. Calidad del Software
• 3. Proceso de Ingeniería del Producto (Software)
• 4. Proceso de Mejora del Proceso de Ingeniería
del Producto
⇒ 5. CMM: un modelo para la mejora de
Procesos Software
⇒ 6. PSP: Proceso Software Personal
• A modo de conclusión y Bibliografía
Anexo: Proceso Unificado de Desarrollo de Software con UML
Motivación
A las 14:21 de un 15 de enero, hora punta en el tráfico telefónico, el conmutador 4ESS
de la red telefónica de Manhattan detectó un pequeño fallo en su hardware. El 4ESS se
desconectó de la red tras, amablemente, notificar a los conmutadores vecinos su
desconexión. En pocos segundos, el conmutador volvió a funcionar, lo que notificó
también a sus vecinos. Pero éstos estaban todavía procesando el primer mensaje cuando
recibieron el segundo. Esto les confundió, se dieron cuenta de este desconcierto y se
desconectaron de la red para realizar un auto-chequeo y reinicializarse, no sin antes
notificar a todos sus vecinos su desconexión. Como una epidemia de gripe, los
mensajes se distribuyeron por todo EEEUU. Tan pronto como un conmutador se
desconectaba y se recuperaba, recibía un aluvión de mensajes de sus compañeros que le
hacían volver a fallar. En el centro de operaciones, los técnicos veían cómo las líneas de
comunicaciones del mapa se ponían rojas por todo el país partiendo de Manhattan,
mientras que los ingenieros se veían negros siguiendo todos los procedimientos
estándar para la solución de problemas, los no estándar y los improvisados. Pero nada
funcionó. Un minúsculo error en la versión de diciembre del software del conmutador
4ESS causó el caos. AT&T volvió temporalmente a la versión anterior e instaló la
versión corregida cinco días después. Pero el daño ya estaba hecho.
[Arthur, L.J. Improving Software Quality: an Insider’s Guide to TQM. John Wiley & Sons, 1993

3
Motivación
El 4 de junio de 1996, la lanzadera europea Ariane 5 explotó tras 40 segundos de vuelo,
debido a un error de un fragmento de código innecesario. El software culpable
pertenecía al sistema de referencia inercial (SRI): antes del despegue, hay que hacer
ciertos cálculos para alinear el SRI, aunque estos cálculos pueden finalizar 9 segundos
antes del despegue. Pero como existe la posibilidad de que la cuenta atrás se detenga,
los ingenieros decidieron mantenerlo hasta 50 segundos después del despegue, puesto
que reiniciar el SRI llevaba varias horas. Una vez en vuelo, los cálculos del SRI son
inútiles, pero en el Ariane 5 causaron una excepción que no fue interceptada y…
¡boom! La excepción se debió a una conversión de un valor real de 64 bits (inclinación
horizontal) a un entero de 16 bits, pero, como no había un manejador por omisión de
excepciones, la excepción siguió el destino de todas las excepciones no capturadas, es
decir, abortar el software y por tanto los ordenadores de a bordo, y por tanto la misión.
¿Por qué no se controló la excepción? Los análisis habían demostrado que el overflow
no podía ocurrir nunca. Lo cual era completamente cierto para las trayectorias del
Ariane 4, para el cual había sido diseñado el SRI, no para las nuevas trayectorias del
Ariane 5, para el que se había reutilizado el código. Una reutilización que provocó que
un error trivial causara la explosión de un cohete de unos 500 millones de dólares.
[Jézéquel, Meyer:
A. Goñi, J.R. Zubizarreta, “Design
J. Iturrioz. by Contract: The Lessons of Ariane”. IEEE Computer 30 (1), 1997]
Dpto. LSI, UPV/EHU
6
1. Definición de Ingeniería del
Software
• Bauer 1972: IS 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.
• Bohem, 1976: IS 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.
• Zelkovitz 1978: IS es el estudio de los principios y
metodologías para desarrollo y mantenimiento de
sistemas de software.

4

Software
• Mills , 1980: la IS tiene como uno de sus principales
objetivos la producción de programas que cumplan las
especificaciones, y que se demuestren correctos,
producidos en el plazo y coste adecuados.
• Meyer 1988: la IS es la producción de software de calidad.
• Ford, 1990: IS es una forma de ingeniería que aplica los
principios de la ciencia de los computadores y
matemáticas para conseguir soluciones a los problemas
del software de forma efectiva y económica.
• IEEE 1993: IS es la aplicación de un enfoque sistemático,
disciplinado y cuantificable al desarrollo, operación y
mantenimiento del software; es decir, la aplicación de
ingeniería al software.
8
Software
Ingeniería del Software es la INGENIERÍA que trata de
construir software de ALTA CALIDAD a BAJO COSTO
– INGENIERÍA (IEEE): aplicación de un método sistemático, estructurado y
cuantificable a estructuras, máquinas, productos, sistemas o procesos.
– INGENIERÍA (DRAE): conjunto de conocimientos y técnicas que permiten aplicar
el saber científico a la utilización de la materia y fuentes de energía.
Sección
A) CALIDAD: definir qué es CALIDAD del SOFTWARE 2
B) INGENIERÍA, PRODUCTO de BAJO COSTO:
definir qué es un buen PROCESO SOFTWARE
• PROCESO de INGENIERÍA del PRODUCTO (SOFTWARE):
conjunto de actividades, métodos, prácticas y transformaciones
Sección 3
utilizados para desarrollar software y los productos asociados:
planes del proyecto, documentos de análisis/diseño, codificación,
casos de prueba, manuales de usuario
Secciones
• Todo es mejorable: MEJORA del PROCESO SOFTWARE
4, 5 y 6

5
2. Calidad de software
La Calidad de Software se entiende como la combinación de
una serie de factores:
– Factores Externos
⇒ Corrección ⇒ Eficiencia
⇒ Robustez ⇒ Portabilidad
⇒ Extensibilidad ⇒ Facilidad de Uso
⇒ Reusabilidad ⇒ Funcionalidad
⇒ Compatibilidad ⇒ Oportunidad
– Factores Internos: modularidad y legibilidad. Sólo

percibidos por los que tienen acceso al código fuente.
En principio sólo importan los externos, pero la clave
para conseguirlos radica en los factores internos
10
2. Corrección
• Software debe cumplir sus tareas

exactamente, debe cumplir su especificación.
• Necesidad de:
– realizar especificaciones precisas.
– uso de métodos de corrección condicional.
Sistema de Aplicación
Compilador
Se supone que estos
Sistema Operativo
niveles son correctos
Hardware

6
11
2. Robustez
– Capacidad de los sistemas software para

reaccionar apropiadamente ante condiciones
anormales
– Caracteriza el funcionamiento de un sistema
fuera de los límites de su especificación
• Caso normal: caso planificado durante el diseño
del software (puede ser una entrada errónea)
• Caso excepcional: no previsto en la especificación
12
2. Extensibilidad
• Facilidad de adaptación del software a cambios

de especificación, esto es, a nuevos requisitos.
• Las técnicas tradicionales de Ingeniería del
Software tendían, en el ciclo de vida del
software, a considerar que todos los requisitos
se obtenían al principio.
• Principios para conseguir la extensibilidad:
– simplicidad en el diseño; una arquitectura
simple es más fácil de adaptar a los cambios
– descentralización de módulos; los cambios
afectarán a menos módulos

7
13
2. Reutilización
• Capacidad de los elementos de software de

servir para la construcción de muchas
aplicaciones diferentes.
• Los sistemas software a menudo siguen
patrones similares. Evitar reinventar soluciones
a problemas que ya han sido encontrados.
– Uso de elementos de software reutilizables
– Uso de patrones de diseño
• Se requerirá un menor esfuerzo de
programación, que podrá dedicarse a otros
factores: corrección, robustez...
14
2. Compatibilidad
• Facilidad para combinar diferentes elementos
de software entre sí
• Un sistema software generalmente necesitar
interactuar con otros sistemas.
– Suelen encontrarse muchos problemas.
• Clave: homogeneidad en el diseño y acordar
convenciones estándares de comunicación
entre programas:
– Usar formatos de archivo estándares
– Usar estructuras de datos estándares
– Usar interfaces de usuario estándares

8
15
2. Eficiencia
• El software debe aprovechar al máximo los

recursos hardware: tiempo del procesador, espacio
ocupado de memoria…
Ù La eficiencia no es importante mientras el software no

sea correcto
Ù Hay que llevar un equilibrio entre eficiencia (necesaria) y
otros factores como extensibilidad y reutilización
Ù No se puede infravalorar la eficiencia. Hay que
implementar algoritmos eficientes donde merezca la pena
16
2. Portabilidad
• Facilidad de transportar los productos

software a distintos entornos hardware y
software
• La portabilidad tiene que ver con variaciones

de la máquina hardware-software
(plataforma= hardware + sistema operativo

+ sistema de ventanas (si se emplea)
+ otras herramientas fundamentales)

9
17
2. Facilidad de uso
• Facilidad con la cual otras personas con

diferentes formaciones pueden aprender a
usar los productos software.
– El sistema debe facilitar el manejo para todo tipo
de usuarios: desde usuarios novatos a los que
deben proporcionarse explicaciones hasta
usuarios expertos que quieren ir al grano.
• Los buenos diseñadores de interfaces siguen
la política de no hacer suposiciones sobre los
usuarios.
– “No suponga que conoce al usuario; realmente no
lo conoce”
18
2. Funcionalidad
• Es el conjunto de posibilidades ofrecidas por el

sistema.
• Se debe conocer cuánta funcionalidad es
suficiente, pero es difícil...
• Al añadir nueva funcionalidad no se debe perder la
consistencia del producto global.
• Al intentar añadir más funcionalidad cuanto antes
no hay que olvidar otros factores de calidad.

10
19
2. Oportunidad
• Es la capacidad de lanzar a tiempo un sistema
software
• Un sistema software debe estar desarrollado
para cuando los usuarios lo necesitan (o antes)
• Otros factores:
– Verificabilidad: facilidad para preparar
procedimientos de prueba
– Integridad : capacidad para protegerse contra
modificaciones y accesos no autorizados
– Reparabilidad: capacidad para facilitar reparación
de defectos
– Economía : capacidad de completarse dentro de
un presupuesto
20
2. Acerca de la documentación
• La documentación es una consecuencia de los

factores de calidad
• Tipos de documentación:
– documentación externa facilidad de uso
• Ayuda on-line
– documentación interna extensibilidad
• Uso de lenguajes que faciliten la documentación
interna.
– interfaces de los módulos
extensibilidad/reusabilidad
• Generación automática de documentación de interfaces.

11
21
2. Acerca del mantenimiento

• Etapa que cubre la vida de un sistema software
una vez que este ha sido implantado
• Representa el 70 % del coste de desarrollo de
software
• ¿Qué es mantenimiento? El software no se
estropea...
– Cambios en requerimientos del usuario (42%)
– Cambios en los formatos de datos (18 %)
– Resto (40%): mejoras eficiencia, documentación,
arreglos de rutinas, cambios hardware,...
La construcción de software extensible y la encapsulación de
datos (uso de TADs, clases OO) facilitará el problema del
mantenimiento (al menos en los casos “cambios reqs./formatos”)
22
3. Proceso de ingeniería del

producto (software)
• PROCESO DE INGENIERÍA DEL SOFTWARE:
– Es un conjunto de actividades junto con unas
restricciones de orden entre ellas que, si se ejecutan
apropiadamente, se obtiene como resultado software
de alta calidad a bajo costo.
– Un proceso de ingeniería de software es una definición
del conjunto completo de actividades necesarias para
transformar los requisitos de usuario en un producto.
Un proceso es una plantilla para crear proyectos.
• PROYECTO SOFTWARE: Es un elemento
organizativo (proyecto) a través del cual se
gestiona el desarrollo del software. Es un
proyecto de desarrollo donde se APLICA un
PROCESO DE INGENIERÍA DEL SOFTWARE

12
23

producto (software)
• PRODUCTO SOFTWARE: Es el RESULTADO de

un PROYECTO SOFTWARE. Incluye los modelos
de análisis y de diseño, código fuente, ejecutables y
documentación.
• PERSONAS: Todas las implicadas tanto en la

construcción como en la explotación del software:
desarrolladores, arquitectos, ingenieros de prueba,
usuarios, clientes...
• HERRAMIENTAS: software que se utiliza para

automatizar las actividades definidas en el proceso.
24

producto (software)
PROCESO
Plantilla
Participan
PERSONAS PROYECTO
Resultado
AutomatizadoPor
PRODUCTO HERRAMIENTAS

13
25

producto (software)
• Objetivo del proceso de ingeniería del

producto:
conseguir el producto deseado
• Dentro del proceso de ingeniería del
producto, se distinguen 3 procesos:
– Proceso de desarrollo software
– Proceso de gestión del proyecto
– Proceso de control de configuraciones
26
3. Proceso de desarrollo software
• Es el responsable de producir el producto deseado

(software) y otros productos (manuales de usuario,
especificación de los requisitos, …)
– Conjunto de actividades que se necesitan para transformar los
requerimientos de un software en un sistema de software.
• Objetivo: desarrollar un producto que satisfaga al

cliente
Requisitos del Producto
PROCESO DE
usuario DESARROLLO o Sistema de Software
Actividades Captura de
a realizar requisitos Análisis Diseño Implementación Pruebas

14
27
3. Proceso de desarrollo software

• Ofrece un marco de trabajo genérico:
– Elementos para representar el diseño de los datos y la
arquitectura del sistema de información PARTE
ESTÁTICA
– Elementos para representar los procesos PARTE
DINÁMICA
– Elementos para representar la relación de los usuarios con
el sistema
INTERFAZ
– Modelo de referencia para conseguir construir de manera

eficiente el sistema CICLO DE
VIDA
• Ejemplos de procesos de desarrollo: Merise, SSADM,
Métrica, Proceso Unificado de Desarrollo de Software
28
3. Proceso de gestión del proyecto
• Lleva a cabo el control y la planificación

de las actividades de desarrollo para que
lleven hacia el objetivo del proyecto
Requisitos del PROCESO DE Producto
usuario DESARROLLO
Actividades Captura de
requisitos Análisis Diseño Implementación Pruebas
a realizar
Controla y
PROCESO DE Planifica
GESTIÓN DEL
PROYECTO

15
29
3. Proceso de gestión del proyecto
• Se trata de realizar una serie de

actividades de planificación y control:
– del alcance del proyecto
– del tiempo
– del costo
– de recursos humanos
– de calidad
– de riesgos
–…
30
3. Proceso de control de configuraciones

• PROBLEMAS:
– Los usuarios cambian los requisitos constantemente
– Los desarrolladores quieren cambiar el enfoque técnico
– Los gestores quieren modificar el alcance
– Los procesos de DESARROLLO de software no pueden
generalmente adaptarse a esos cambios arbitrariamente
• El proceso de control de configuraciones del
software trata con dichos cambios para que los
objetivos de calidad y costo del software se
mantengan, así como la integridad de los
productos
Requisitos del PROCESO DE Producto
usuario DESARROLLO
CAMBIOS CAMBIOS

16
31
• Objetivo: controlar los cambios, sin impedir

seriamente cambios justificados
• Elemento de Configuración (EC):
– programa, documento, etc. (artefacto) obtenido durante el proceso de
desarrollo y/o gestión, susceptible de sufrir algún cambio
• Línea Base (LB):
– Es una especificación o producto que se ha revisado formalmente y
sobre los que se ha llegado a un acuerdo, y que de ahí en adelante
sirve como base para un desarrollo posterior, y que puede cambiarse
solamente a través de procedimientos formales de control de
cambios. (Estándar IEEE 610.12-1990)
• Los EC pueden convertirse en LB
– Antes los cambios pueden realizarse de manera ágil
– Pero después, ya no… hay que seguir actividades del proceso de
control de configuraciones
32
• Se trata de realizar una serie de actividades de:

– Identificación de elementos de configuración que
probablemente cambien
– Control de versiones
• ¿Cómo se controlan los cambios antes y después de que el
software se distribuya al cliente?
– Control de cambios
• ¿Quién aprueba los cambios y establece prioridades entre ellos?
– Auditoría de la configuración
• ¿Cómo se garantiza que los cambios se han llevado a cabo de
manera adecuada?
– Informes de estado
• ¿Cómo se comunica a los demás los cambios realizados?

17
33
4. Proceso de Mejora del Proceso

de Ingeniería del Producto
• Los procesos de INGENIERÍA DEL
PRODUCTO serían suficientes si el
PROCESO DE SOFTWARE fuera algo
estático
• Pero no lo es ya que ...
– cada día se entiende mejor cómo hay que
desarrollar el software
– existen nuevas técnicas y herramientas
SE NECESITA UN PROCESO DE GESTIÓN
DEL PROCESO DE INGENIERÍA
34
4. Proceso de Mejora del Proceso
de Ingeniería del Producto
Proceso Software
Procesos de ingeniería
Proceso de
del producto gestión del proceso
CMM
SPICE
PSP
Proceso de Proceso de gestión Proceso de control

desarrollo del proyecto de configuraciones

18
35
4. Proceso de Mejora del Proceso de

Ingeniería del Producto
• El PROCESO DE GESTIÓN DEL
PROCESO SOFTWARE tiene como
objetivo mejorar dicho proceso, esto es,
la capacidad para producir software de
alta calidad a bajo costo
– Para ello hay que:
• Estudiar el proceso actual, analizando todos
los proyectos desarrollados bajo ese proceso.
• Mejorar, basándose en el análisis previo,
aquellos aspectos del desarrollo, del control
del proyecto y de las configuraciones.
36
5. CMM: un modelo para la

mejora de Procesos Software
• CMM (Capability Maturity Model)
• Desarrollado por el SEI (Software
Engineering Institute) a partir de 1986
• CMM describe una camino de mejora
para que organizaciones que desarrollan
software evolucionen desde un proceso
software inmaduro a uno más maduro y
disciplinado
• Existen otros modelos de mejora: SPICE,
BOOTSTRAP, ISO 9000, PSP

19
37
5. CMM: un modelo para la
mejora de Procesos Software
• OBJETIVO: mejorar la calidad de los procesos de

desarrollo, gestión y mantenimiento de software.
• Para conseguirlo se aplican las bases de la Gestión de la
Calidad Total (Total Quality Management) en la Ingeniería
del Software.
– Mejorar la gestión de la calidad es, en gran medida, responsabilidad
de la dirección.
– La mejora de la calidad debe basarse en mejorar los procesos y no
en las personas.
– Hay que medir la mejora de la calidad.
– Se necesitan incentivos para mantener un esfuerzo de mejora.
– La mejora de la calidad es un proceso continuo.
38
ORGANIZACIÓN
Proyecto 1 Proyecto 2 GESTIÓN

TOTAL DE
SISTEMA
CALIDAD
Proyecto N
(TQM)
Hardware
MEJORA DE
Software PROCESOS
SOFTWARE
(CMM)

20
39
5. Los 5 niveles de madurez del
proceso software
Efectividad del proceso Alto
(o Capacidad del proceso)
Proceso de 5.Optimizado
(o Madurez del proceso) mejora El objetivo principal es
continua la mejora del proceso.
Proceso 4. Gestionado
predecible Los procesos están Gestión de
Bajo
controlados y medidos cambios
Proceso
consistente y 3. Definido
estándar Los procesos están caracterizados, Calidad de
se entienden superficialmente. procesos y
2. Repetible productos
Proceso
disciplinado Se pueden repetir las tareas Proceso de
principales ya realizadas ingeniería
1. Inicial
Mal controlado y sin Gestión de
predicción proyectos básica
40
1. Nivel:
Los procesos se
realizan. da
“Just do it” Actividad Resultados
2. Nivel:
Los procesos se Planificar
piensan antes de
realizarlos. da
Actividad Resultados
Después de
realizarlos se entrada
verifican que
están bien. Evaluar
mejora

21
41
3. Nivel
entrada Planificar
produce
Estándares Actividad Resultados
entrada
entrada
Evaluar
mejora
Utilizar lecciones aprendidas
42
4. Nivel
entrada Planificar predice
produce
entrada
entrada
Evaluar
mejora
Después de predecir los resultados que se

esperan hay que crear el entorno para
conseguir los resultados deseados

22
43
5. Nivel
entrada Planificar predice
realiza
entrada
entrada
Evaluar
mejorar
Mejorar las lecciones aprendidas

y utilizar las lecciones aprendidas para crear nuevas lecciones aprendidas
y mejorar más las lecciones aprendidas
y utilizar las lecciones aprendidas para crear nuevas lecciones aprendidas
y..................
44
6. PSP
• PSP: Personal Software Process

– Desarrollado por Watts Humphrey creador a su vez
del CMM
– Presenta técnicas y métodos para definir y gestionar
un proceso personal de software
• El CMM suministra una infraestructura de
proceso para toda la organización pero no ayuda
al ingeniero del software a mejorar
individualmente.
• Una progresión desde el CMM Nivel 3 requiere
que los ingenieros apliquen principios de mejora
de proceso basados en un enfoque individual.
3

23
45
6. La medición en un Proceso
Definido
• Obtener datos históricos es imprescindible
para una planificación eficiente.
• Las mediciones señalan cuándo y cómo se
ejecutan las diferentes tareas del plan.
• Los datos históricos se utilizarán para
evaluar y mejorar el proceso del software.
• PSP utiliza tres tipos de medida:
– esfuerzo
– tamaño
– defectos
46
6. PSP Arquitectura Principal
Proceso PSP 3
Cíclico Desarrollo Cíclico
PSP 2 PSP 2.1

Calidad Diseño de Plantillas
Revisión de Código
Personal
Revisión de Diseño
PSP 1.1
PSP 1 Planificación de Tareas
Planificación Estimación de Tamaño Planificación de Tiempos
Personal Informe de Pruebas
PSP 0.1
PSP 0 Estandares de Codificación
Medición Medidas de los Tamaños
Proceso Actual
Personal Propuesta de Mejorade Proceso
Registro de Tiempos y Defectos
6

24
47
Registro deTiempos
• Registramos el
tiempo
utilizado en Student
Instructor
Date
Program #
cada fase del Date Start Stop Interruption Delta Phase Comments
PSP: Time Time
– Inicio
– Parada
– Tiempo de la
interrupción
– Fase
– Comentarios
48
Registro de Defectos
• Información de cada Defect Types

10 Documentation
20 Syntax
60 Checking
70 Data
30 Build, Package 80 Function
defecto encontrado 40 Assignment

50 Interface
90 System
100 Environment
en la revisión,
compilación y Student
Instructor
Kim Orihuela
Iraj
Date
Program #
10-3- 96
3A
prueba. Date
10- 3
Number
1
Type
40
Inject
CODE
Remove
CODE
Fix Time
11
Fix Defect
Description: Add variable to structure.

– Número
– Tipo Date Number Type Inject Remove Fix Time Fix Defect
10- 3 2 20 CODE CODE 1
– Fase en la que se Description: Misspelled variable.
introdujo (Inject) Date Number Type Inject Remove Fix Time Fix Defect
10- 3 3 20 CODE COMPILE 1
– Fase en la que se Description: Missing “ in print statement.
eliminó (Remove)
Date Number Type Inject Remove Fix Time Fix Defect
– Tiempo de 10- 3 4 10 CODE TEST 39
Description: Align/add print statements - beautify
búsqueda/fijación
– Descripción

25
49
Registro de Defectos (cont.)
• Información de
cada defecto
encontrado en
Defect Types
la revisión, 10 Documentation 60 Checking
20 Syntax 70 Data
compilación y 30 Build, Package 80 Function
prueba. 40 Assignment 90 System
50 Interface 100 Environment
– Número
– Tipo
– Fase en la que
se introdujo
50
Resumen del Plan
• El resumen del Student

Program
Kim Orihuela
Standard Deviation
Date
Program #
9-20-96
1A
Plan recoge: Instructor Iraj Hirmanpour Language C
Program Size (LOC): Plan Actual

– Fechas del Plan de Total New&Changed 50 33
Proyecto Time in Phase (min.)

Planning
Plan Actual
2
To Date
2
To Date %
1.6
Design 0 0 0
– Resultados Code
Compile
53
20
53
20
44.2
16.7
actuales Test
Postmortem
25
20
25
20
20.8
16.7
Total 240 120 120 100.0
• tamaño Defects Injected Actual To Date To Date %
• tiempos Planning
Design
0
0
0
0
0
0
Code 10 10 100
• defectos Compile 0 0 0
0
Test 0 0
detectados Total Development 10 10 100
To Date %
– Datos acumulados Defects Removed
Planning
Actual
0
To Date
0 0
Design 0 0 0
de los Proyectos Code
Compile
3
5
3
5
30
50
PSP Test
Total Development
2
10
2
10
20
100
After Development 0 0 0

26
51
No pasaremos del nivel
7. A modo de conclusión 1 de CMM. Hace falta
tener un Proceso de
Software maduro.
Proceso Software Llevaremos registros de
tiempos y defectos.
Procesos de ingeniería Proceso de

del producto gestión del proceso
Proceso de Proceso de control

Proceso de gestión de configuraciones
desarrollo del proyecto PyGPI
•Requisitos
•Análisis ADSI Para ello, nos apoyaremos en el
•Diseño desarrollo de una práctica. Se entregarán
los requisitos, el análisis y el diseño.
•Implementación Habrá que terminar el diseño y realizar la
•Pruebas ISO implementación y las pruebas.
52
8. Bibliografía
• Libro general sobre Ingeniería del Software:

– Ingeniería del Software. Un enfoque práctico.
5ª Edición. Roger S. Pressman. MacGraw-Hill, 2001.
• Para la sección 2
– Construcción de Software Orientado a Objetos.
2ª Edición. Bertrand Meyer. Prentice-Hall, 1999.
Capítulo 1.
• Para la secciones 5, 6 y 7
– The Capability Maturity Model: Guidelines for Improving
the Software Process. M.C.Paulk, C.V.Weber, B.Curtis
y M.B.Chrissis. Addison-Wesley
– Introducción al Proceso Software Personal (PSP)
Watts S. Humphrey. Addison-Wesley, 2001.

27
53
Proceso unificado de desarrollo
• Basado en componentes Orientados a Objetos
• Utiliza el lenguaje unificado de modelado (UML)
• El proceso es:
• Guiado por casos de uso
• Centrado en la arquitectura
• Con un ciclo de vida iterativo e incremental
PARTE
DINÁMICA
CICLO Debe ofrecer un

marco de trabajo INTERFAZ
DE VIDA
genérico
PARTE
ESTÁTICA
54
1.- CASO DE USO Desarrollo guiado por

Tomar Préstamo CASOS DE USO
Persona
2.- ANÁLISIS DEL

CASO DE USO
: IU -1 : GestorLibro : Libro elLibro:Libro
1: Introducir Signatura yNumeroDeSocio

Se repite hasta que se
2: Aceptar encuentre un libro
con la signatura que
3.- DISEÑO DEL 3: obtenerLibro(signaturaLibro:String) estamos buscando
CASO DE USO
4: getSignatura()
elLibro
5: getCopias()
6: isCopiaPrestada()
4.- IMPLEMENTACIÓN DEL CASO DE USO

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU 5.- PRUEBA DEL CASO DE USO

28
55
Centrado en la
ARQUITECTURA
1
VISTA DEL MODELO DE CASOS DE USO VISTA DEL MODELO DEL DOMINIO /
VISTA DEL DIAGRAMA DE CLASES
: IU -1 : : : : :
1:
2:
3: G 4 2: 1:
3: G 4
r r
() ()
o o
VISTA DEL MODELO DEL ANÁLISIS
VISTA DEL MODELO DEL DISEÑO
+ VISTAS DEL MODELO DE IMPLEMENTACIÓN Y PRUEBAS
SON VISTAS DE LOS MODELOS (NO MODELOS COMPLETOS). SÓLO

APARECEN LOS QUE CORRESPONDEN A CASOS DE USOS CRÍTICOS
DA UNA IDEA DE LA “FORMA” QUE TIENE EL “SISTEMA COMPLETO”
56
CICLO
Flujos de
Fases DE VIDA
trabajo:
Actividades
Inicio Elaboración Construcción Transición
Requisitos
Análisis
Diseño
Implementación
Prueba
iter. iter. iter. iter. ite r. iter. ite r.

Iteraciones: #1 #2 #n # n +1 # n +2 #m # m +1

29
57

Como se puede ver, el Proceso
Unificado de Desarrollo
incluye actividades
ITERACIÓN correspondientes a un Proceso
de Gestión de Proyectos
PLANIFICACIÓN DE EVALUACIÓN DE LA
LA ITERACIÓN ITERACIÓN
REQUISITOS ANÁLISIS DISEÑO IMPLEMENTACIÓN PRUEBAS
ACTIVIDADES DE LOS FLUJOS DE TRABAJO FUNDAMENTALES

58
FASES:
• INICIACIÓN: se desarrolla una descripción del producto
final y se presenta el análisis del negocio; se identifican y
priorizan los riesgos más importantes, se planifica la
siguiente fase y se estima el proyecto de manera
aproximada
• ELABORACIÓN: se especifican en detalle la mayoría de
los casos de uso y se diseña la arquitectura del sistema;
se planifican las actividades y estiman los recursos para
terminar el proyecto
• CONSTRUCCIÓN: se desarrolla/construye el producto
• TRANSICION: se proporciona el sistema a los usuarios
finales

30
59
FLUJOS DE TRABAJO:
• REQUISITOS: desarrollar un modelo del sistema que se
va a construir; identificar los requisitos de dicho sistema.
Se obtiene el Modelo de Casos de Uso (MCU) y el
Modelo del Dominio (o del Negocio)
• ANÁLISIS: tener una especificación más precisa de los
requisitos obtenidos en REQUISITOS y recogidos en el
MCU. Se obtiene el Modelo del Análisis (diagramas de
colaboración y paquetes/subpaquetes de análisis)
• DISEÑO: encontrar la forma del sistema que cumpla con
todos los requisitos (encontrar la solución). Se obtiene el
Modelo del Diseño (diagramas de secuencia, diagrama
de clases y sistemas/subsistemas de diseño)
60

FLUJOS DE TRABAJO:
• IMPLEMENTACIÓN: realizar la codificación

correspondiente al diseño. Se obtiene el Modelo de
la Implementación (componentes: clases y
subsistemas implementados)
• PRUEBAS: realizar la verificación de la

implementación; diseñar, implementar casos de
prueba y ejecutarlos. Hay que obtener los casos y
procedimientos de prueba.

31
61
Unified Modelling Language (UML)
PARTE PARTE
INTERFAZ
ESTÁTICA DINÁMICA
• Para que tenga éxito, un proceso de desarrollo de
software no sólo debe ser bueno, sino que debe utilizar
además una buena notación y ofrecer herramientas
CASE (Computer Assisted Software Engineering)
• El Proceso Unificado de Desarrollo utiliza UML para
representar la parte estática y dinámica del sistema.
UML Notación
Herramientas Proceso
RATIONAL ROSE
PROCESO UNIFICADO DE
VISIO
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU DESARROLLO DE RATIONAL


Tema1 (INTRODUCCION A LA INGENEIRIA DE SW) 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

Tema1 (INTRODUCCION A LA INGENEIRIA DE SW) PDF

Cargado por

Copyright:

Formatos disponibles

1

INGENIERÍA del SOFTWARE

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU

Ingeniería del Software

• 1. Definición de Ingeniería del Software

Ingeniería del Software

Ingeniería del Software

1. Definición de Ingeniería del

Ingeniería del Software

– Factores Internos: modularidad y legibilidad. Sólo

• Software debe cumplir sus tareas

Ingeniería del Software

– Capacidad de los sistemas software para

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU

• Facilidad de adaptación del software a cambios

Ingeniería del Software

• Capacidad de los elementos de software de

Ingeniería del Software

• El software debe aprovechar al máximo los

Ù La eficiencia no es importante mientras el software no

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU

• Facilidad de transportar los productos

• La portabilidad tiene que ver con variaciones

(plataforma= hardware + sistema operativo

Ingeniería del Software

• Facilidad con la cual otras personas con

• Es el conjunto de posibilidades ofrecidas por el

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU

Ingeniería del Software

• La documentación es una consecuencia de los

Ingeniería del Software

2. Acerca del mantenimiento

3. Proceso de ingeniería del

Ingeniería del Software

3. Proceso de ingeniería del

• PRODUCTO SOFTWARE: Es el RESULTADO de

• PERSONAS: Todas las implicadas tanto en la

• HERRAMIENTAS: software que se utiliza para

3. Proceso de ingeniería del

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU

Ingeniería del Software

3. Proceso de ingeniería del

• Objetivo del proceso de ingeniería del

3. Proceso de desarrollo software

• Es el responsable de producir el producto deseado

• Objetivo: desarrollar un producto que satisfaga al

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU

Ingeniería del Software

3. Proceso de desarrollo software

– Modelo de referencia para conseguir construir de manera

3. Proceso de gestión del proyecto

• Lleva a cabo el control y la planificación

Ingeniería del Software

3. Proceso de gestión del proyecto

• Se trata de realizar una serie de

3. Proceso de control de configuraciones

Ingeniería del Software

3. Proceso de control de configuraciones

• Objetivo: controlar los cambios, sin impedir

3. Proceso de control de configuraciones

• Se trata de realizar una serie de actividades de:

Ingeniería del Software