FAQs: Preguntas frecuentes

sobre Ingeniería del Software

¿Qué es el Software? 1.1. El software y la
¿Cuál es la importancia y coste del Software?
¿Qué es la Ingeniería del Software? Ingeniería del software
¿Cuál es la diferencia entre Ingeniería del Software e
Ingeniería de Sistemas?
¿Qué es un sistema y un sistema de información?
¿Qué es un proceso software y un método de
desarrollo?
¿Cómo se gestiona el proceso?
¿Qué es CASE (Computer-Aided Software
Engineering)?
¿Cuáles son las responsabilidades de un Ingeniero
Software?
¿Qué es el Lenguaje Unificado de Modelado (UML)?7

¿Qué es el Software? Importancia del Software

Hace referencia a los programas y toda la información
asociada y materiales necesarios para soportar su Las economías de todos las paises son
instalación, operación, reparación y mejora. cada vez más y más dependientes del
Para construir un nuevo elemento software se necesita: software
Detallar las especificaciones Cada vez más y más sistemas están
Diseñar la solución
Codificar el algoritmo controlados por software
Probar el programa El gasto en desarrollo de software está
Documentar
Mantener aumentando su porcentaje en el PIB de
todos las paises
Es lo que se conoce como el ciclo de vida del software.
9 10

Crisis del Software Costes del Software

Crecimiento espectacular de los costes Los costes que representa el Software son a
menudo mayores que el hardware
del software.
Incumplimiento de los plazos de El mantenimiento
a e e o resulta
esu a más
ás caro
a o que e
el
entrega. desarrollo:
En sistemas de vida larga puede ser varias veces
Muchas dudas sobre la calidad del más caro
software construido.
La Ingeniería del Software tiene que ver con
el desarrollo de forma que sea
económicamente viable

11 12

2
 Gestión de la configuración del software
• identificación
1.5. Aspectos profesionales
HERRAMIENTAS • control de versiones
• control de cambios
y éticos de la Ingeniería del
Software
TECNICAS
• auditoría
PROCESO • informes
• construcción

Existen herramientas que ayudan al control de

las versiones a medida que avanzan (SourceForge)

Recomendaciones de IEEE-CS Responsabilidad del Ingeniero de

y ACM Software
Objetivos: La Ingeniería del Software implica una serie
Cuerpo de conocimientos de la disciplina, criterio de de responsabilidades más alla de las
acreditación de los titulados, mantener un código ético
habilidades técnicas
Software Engineering Body of Knowledge (SWEBOK)
E á d
Estándares de
d la
l Ingeniería
I i í del
d l Software
S f
Software Engineering Education Project Los Ingenieros de Software deben
Software Engineering Code of Ethics and Professional comportarse de modo honesto y ético si
Practice quieren lograr respeto como profesionales

En España: Colegios profesionales Es algo más que cumplir la ley

87 88

ACM/IEEE-CS: código ético ACM/IEEE-CS: código ético

Sociedad: Los ingenieros de software actuarán de
manera coherente con el interés general.
Cliente y empresario: Los ingenieros de software
deberán actuar de tal modo que se sirvan los
mejores intereses para sus clientes y empresarios,
Producto: Los ingenieros del software deberán
garantizar que sus productos y las modificaciones
relacionadas con ellos cumplen los estándares
profesionales de mayor nivel que sea posible.
Juicio: Los ingenieros del software deberán mantener
integridad e independencia en su valoración
profesional.
Gestión: Los gestores y líderes en Ingeniería del
Software suscribirán y promoverán un enfoque ético
a la gestión del desarrollo y el mantenimiento del
software.
Profesión: Los ingenieros del software deberán
progresar en la integridad y la reputación de la
profesión, de forma coherente con el interés público.
Compañeros: Los ingenieros del software serán
justos y apoyarán a sus compañeros.
Persona: Los ingenieros del software deberán
participar en el aprendizaje continuo de la práctica de
su profesión y promoverán un enfoque ético en ella.

89 90

15
 ¿Cuál es la diferencia entre Ingeniería del ¿Cuál es la diferencia entre Ingeniería del
Software y las Ciencias de la Computación? Software e Ingeniería de Sistemas?

Las Ciencias de la Computación tienen La Ingeniería de Sistemas tiene que ver

que ver con teorías y fundamentos con todos los aspectos del desarrollo de
sistemas basados en computadoras:
La Ingeniería del Software tiene que ver hardware, software e Ingeniería de
con los aspectos prácticos del desarrollo procesos.
del software
Ingeniería del Software es una parte de
este proceso
19 20

Disciplinas integradas en la
Ingeniería del Software SWEBOK Guía
Guía
SWEBOK
SWEBOK (I)
(I)

Software Engineering Body of Knowledge (SWEBOK) Requisitos

Requisitos del
del Diseño
Diseño Construcción
Construcción Prueba
Prueba del
del Mantenimiento
Mantenimiento
software del
del software
software del
del software software
software del
del software
Requisitos del software software software software

Diseño del software Proceso de Conceptos y principios Conceptos básicos Conceptos

Reducción de la
Construcción del software Ingeniería de básicos complejidad y definiciones básicos
Requisitos
P b del
Prueba d l Software
S ft Elementos clave en el Anticipación de la Niveles de Proceso de
Obtención de diseño del software diversidad pruebas mantenimiento
Mantenimiento del software requisitos
Estructura y arquitectura Estructuración para Técnicas de Principales
Análisis de del software la validación prueba problemas
Gestión de la configuración del software requisitos
Análisis y evaluación de Métricas
del mantenimiento
Uso de estándares
Gestión de la Ingeniería del Software Especificación la calidad del diseño externos relacionadas con Técnicas para
de requisitos las pruebas el mantenimiento
Proceso de Ingeniería del Software Notaciones
Validación de de diseño Gestión del proceso
Herramientas y métodos de la Ingeniería del Software requisitos de prueba
Estrategias y métodos
Calidad del software Gestión de de diseño
requisitos
(a) (b) (c) (d) (e)
21 22

SWEBOK
Guía
Guía
SWEBOK
SWEBOK (II)
(II)

Gestión
Gestión de
de la
configuración
configuración
la Gestión
Gestión
de
de la
la IS
IS
Proceso
Proceso de
IS
IS
de Herramientas
Herramientasyy
métodos
métodos
métodos de
de la
la IS
IS
Calidad
Calidad del
del
software
software 1.2. Sistemas de
Gestión del proceso de
gestión de la configuración
Gestión de
la organización
Conceptos del
proceso de IS
Herramientas
software
Conceptos sobre
calidad del software Información
Id tifi
Identificación
ió de
d lla G tió del
Gestión d l Infraestructura del Métodos
é Propósito
ó y planificación
f ó
configuración del software proceso/proyecto proceso software del SQA y de la V&V

Control de la configuración Medida de la Medida del Actividades y técnicas para

del software IS proceso SQA y V&V

Registro del estado de la Definición del Métricas aplicadas al SQA

configuración del software proceso y a la V&V

Auditoría de la gestión Análisis cualitativo

de la configuración del proceso

Gestión de la distribución Implementación y

del software cambio del proceso

23
(a) (b) (c) (d) (e)

4
 Diagramas para la gestión de proyectos
Calendario del proyecto
Partir el proyecto en tareas y estimar el tiempo y los Las notaciones gráficas ilustran la planificación del
recursos necesarios para terminar cada tarea proyecto
Organizar las tareas concurrentemente para hacer un Muestran la descomposición del proyecto en tareas.
uso óptimo de la mano de obra Las tareas no deben ser demasiado pequeñas.
Minimizar las dependencias entre tareas para evitar
retrasos producidos cuando una tarea espera a otra Los diagramas de redes de actividades muestran las
para terminar dependencias de las tareas y el camino crítico
Depende de la intuición y la experiencia de los
administradores del proyecto Los diagramas de barras muestran la planificación
sobre el calendario

Duración de las tareas y dependencias Red de actividades

14/7/99 15 days
Tarea Duración (días) Dependencias M1 T3
15 days
T1 8 8 days T9
T2 15 T1
25/7/99
5 days 4/8/99 25/8/99
T6 M4 M6
T3 15 T1 (M1) 4/7/99 M3
T4 10 start
15 days
20 days 7 days

T5 10 T2, T4 (M2) T2 T7 T11

T6 5 T1, T2 (M3) 25/7/99 11/8/99 5/9/99

10 days 10 days
T7 20 T1 (M1) M2 M7 M8
T4 T5 15 days
T8 25 T4 (M5) T10 10 days
T9 15 T3, T6 (M4) 18/7/99
T12
M5
T10 15 T5, T7 (M7)
25 days
T11 7 T9 (M6)
T8 Finish
T12 10 T11 (M8) 19/9/99

Actividades en el calendario
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Asignación de personal
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Start
T4
T1 Fred T4
T2
M1 T8 T11
T7 T12
T3
M5 Jane T1
T8
M3 T3
M2
T6
T9
T5 Anne T2
M4
T9 T6 T10
M7
T10
Jim T7
M6
T11
M8 Mary T5
T12
Finish

12
 Costes de los cambios El software se deteriora

60-100x
Tasa de Incremento de fallos
fallos

cambio
1.5-6x
1x
curva real
curva ideal
Definición Desarrollo Después de
entregado Tiempo
13 14

¿Qué es la Ingeniería del software? Ingeniería del software

Disciplina que se ocupa del desarrollo del
software.
Se enfrenta al software como un producto de
ingeniería que requiere: planificación, análisis,
diseño, implementación, pruebas y mantenimiento.
Trata de las teorías, métodos y herramientas que los
profesionales del desarrollo del software deben
utilizar.
No sólo comprende los procesos
técnicos del desarrollo.
También, los principios más relevantes
de dirección y control de este proceso.
También, el desarrollo de nuevas
teorías, métodos y herramientas de
apoyo a la producción del software.

15 16

Objetivos de la
Ingeniería del software Ingeniería del software
Mejorar la calidad del software Los ingenieros de software deben
Acortar los tiempos de desarrollo adoptar un enfoque sistemático y
Aumentar la productividad organizado en su trabajo y
Necesidad: utilizar las herramientas y técnicas más
Incrementar la reutilización del software apropiadas dependiendo
del problema a resolver,
las restricciones del desarrollo y
los recursos disponibles.
17 18

3

Ingeniería del Software I
3º I.T.I.Gestión
Miguel A. Laguna
Ingeniería del Software I
Introducción a la Ingeniería del Software
Producto y Proceso
Aspectos de Gestión
Elicitación, análisis y especificación de
Requisitos
Modelado de actividades y casos de uso
Modelado estático (diagramas de clases)
Modelado dinámico (diagramas de secuencia)
3
Objetivos
Presentar la disciplina de ingeniería del
software y explicar su importancia
Preguntas más frecuentes (FAQs) sobre
la ingeniería del software, proceso
software, UML y aspectos éticos de la
profesión
5 6
Objetivos del curso
Comprender los elementos característicos de la
ingeniería del software
Conocer de forma detallada los métodos y
herramientas de especificación de requisitos
Ser capaz de elaborar la especificación completa de
un sistema utilizando las herramientas, métodos y
procedimientos mostrados en el curso
1. Introducción
Ingeniería del Software I
3º I.T.I.Gestión
Miguel A. Laguna
Desarrollo del tema
1.1. El software y la Ingeniería del
software
1.2. Sistema de Información
1.3. Método y Proceso
1.4.Disciplinas de gestión de proyectos
1.5. Aspectos profesionales y éticos de
la Ingeniería del Software
1.6. Lenguaje Unificado de Modelado
(UML)
1
 ¿Qué es un sistema? Sistema y subsistemas
Un conjunto de elementos (hombres, Subsistemas:
máquinas, métodos, reglas) en interacción,
que transforman (mediante un proceso) Sistema físico: Transforma un flujo físico de
entradas en un flujo físico de salidas.
unos elementos (entradas) en otros nivel operativo de la organización.
(salidas).
Sistema de gestión: controla el sistema físico,
Los sistemas no son entidades independientes, decidiendo el comportamiento del mismo en
existen en un entorno: función de los objetivos marcados.
El entorno afecta al funcionamiento y rendimiento del
sistema.
El sistema puede estar diseñado para hacer cambios en
el entorno.
25 26

¿Qué es un sistema de
Sistema y subsistemas información?

Fijación de nuevos objetivos OBJETIVOS Sistema de Información: Está encargado de

almacenar y tratar informaciones sobre el sistema
físico para ponerlas a disposición del sistema de
SISTEMA DE Información de objetivos gestión
GESTIÓN
recibir decisiones sobre su propio control
interaccionar con el sistema físico
Información de
funcionamiento Decisión de comportamiento

Entrada Salida
SISTEMA FÍSICO

27 28

¿Qué es un sistema de Objetivos

¿Qué es un sistema de
información? información?
SIST. DE Una empresa típica cuenta con un SI compuesto por
GESTION los siguientes subsistemas:

Subsistema de Recursos Humanos: Se ocupa tanto de la

Decisión para gestión
tió del
d l personall como de
d la
l nómina.
ó i
Inf. del sist. su propio
físico
control
Subsistema de Gestión Contable: Tanto para el control
Decisión de interno de la empresa como para hacer frente a las
SIST. DE INFORMACION comportamiento obligaciones legales.

Interacción Información Subsistema de Gestión Comercial: Para el control de los

con el clientes y de las ventas.
sistema
físico
Entrada Salida Subsistema de Control de las Existencias: Del almacén y del
SIST. FISICO 29 inventario de bienes. 30

5
¿Qué es un sistema de
información automatizado? Propiedades emergentes
Si todas las transformaciones significativas La compleja relación entre los subsistemas de
son efectuadas por máquinas un sistema significa que éste es más
complejo que la suma de sus partes.
Las tareas fundamentales de un SIA son: L propiedades
Las i d d emergentes son
Memorización del modelo y de la base de información. consecuencia de las relaciones entre los
Tratamiento automático (control, actualización, búsquedas, componentes.
cálculos).
Captura de la información
Sólo pueden asegurarse y observarse cuándo
Salida de la información. el sistema se considera como un todo.

31 32

Ejemplos de prop. emergentes

El peso total del sistema
Se puede calcular a partir de las propiedades de
los componentes individuales.
1.3. Método y Proceso
La fiabilidad del sistema
Depende de la fiabilidad de los componentes y su
interrelación.
La usabilidad
Esta propiedad compleja no depende sólo del
hardware y del software sino que también
depende de los operadores y del entorno en que
se utilice.

33

¿Qué es un método? Componentes de un método

Together
Rose
Resulta necesario establecer un enfoque sistemático
y disciplinado para llevar a cabo un desarrollo HERRAMIENTAS
UML
software TECNICAS

Definiciones: PROCESO
Una metodología de ingeniería del software es un proceso
para producir software de forma organizada, empleando una
colección de técnicas y convenciones de notación
predefinidas Proceso: Define el marco de trabajo y permite un desarrollo UP
(James Rumbaugh et al.) racional de la IS

Conjunto de procedimientos, técnicas, herramientas y un Técnicas: Indican cómo construir técnicamente el software. Incluyen
soporte documental que ayuda a los desarrolladores a técnicas de modelado
realizar nuevo software
(Mario Piattini et al.) Herramientas: Proporcionan el soporte automático o
semiautomático para el proceso y para las técnicas
35 36

6
 Actividades complementarias
¿Qué es un proceso software? de gestión
Un conjunto estructurado de actividades y resultados Organizar, planificar y programar los
asociados que conducen a la creación de un producto
de software: proyectos de software:
Estimación del coste del pproyecto
y
Especificación de requisitos: Definir la funcio-
nalidad y las restricciones en sus operaciones Planificación y calendarización del proyecto
Diseño e implementación: Producir software que Gestión de la configuración del software
cumple la especificación
Calidad del software
Validación: Asegurar que hace lo que el cliente
desea. ....
Mantenimiento (o Evolución): Seguir cumpliendo
los cambios en las necesidades del usuario.
37 38

Especificación de requisitos
del software Especificación del software
Requirements
Etapa en que se establece qué servicios se requieren Feasibility
study elicitation and
del sistema y cuáles son las restricciones de analysis
operación y desarrollo del mismo. Requirements
specification
Se obtiene un documento de requisitos, con la Feasibility Requirements
especificación
ifi ió del
d l sistema.
i t report validation
System
models
Fases de la Ingeniería de Requisitos: User and system
Estudio de viabilidad requirements
Elicitación y análisis de requisitos
Especificación de requisitos: los del usuario y los del sistema Requirements
document
Validación de requisitos

39 40

Diseño e implementación Diseño e implementación

Etapa en la que se convierte la especificación Requirements
del sistema en un sistema ejecutable specification

Diseño del software Design activities

Describir la estructura del software

software, los datos
datos, las Architectural Abstract Interface Component Data
structure
Algorithm

interfaces entre componentes, …

design specification design design design
design

Implementación
Transformar la estructura anterior en un programa System Software Interface Component
Data
structure
Algorithm
ejecutable architecture specification specification specification specification
specification

Las actividades de estas etapas están muy Design products

relacionadas y pueden interpolarse.

41 42

7
 Técnicas de diseño Validación del Software
Formas sistemáticas de diseñar el La verificación y la validación pretenden
sistema demostrar que un sistema es conforme
Generalmente se documenta con con su especificación y que resuelve los
modelos gráficos: requisitos del cliente
Diagramas de flujo de datos (DFDs) La prueba del sistema implica ejecutar
Diagramas Entidad-Relación el sistema con los casos de prueba que
Diagramas de estructura se obtuvieron en la especificación.
Modelos orientados a objetos

43 44

Etapas en el proceso de Etapas en el proceso de

pruebas pruebas

Prueba de unidades Requirements

specification
System
specification
System
design
Detailed
design
Se comprueban los componentes individuales
Prueba de módulos
Se prueban colecciones de componentes dependientes Acceptance
System Sub-system Module and
Prueba de subsistemas test plan
integration
test plan
integration
test plan
unit code
and tess
Los módulos se integran en subsistemas y se prueban. Sobre
todo se prueba el acoplamiento de las interfaces.
Prueba del sistema Acceptance System Sub-system
Service
Se prueban las interacciones entre los subsistemas y las test integration test integration test
propiedades emergentes.
Prueba de aceptación
Se prueba con datos reales para comprobar que el sistema
es aceptable por el cliente.
45 46

Mantenimiento del software Mantenimiento del software

El software es intrínsecamente flexible y puede
cambiar.

De la misma forma que los requisitos cambian según Define system Assess existing Propose system Modify
cambian las circunstancias del negocio,
negocio el software requirements systems changes systems
que da soporte al negocio debe también desarrollarse
y cambiar.
Existing New
systems
Aunque históricamente ha existido una separación system
entre el desarrollo y la mantenimiento (o evolución)
esto es cada vez más irrelevante, puesto que apenas
hay sistemas completamente nuevos.

47 48

8
 Ayuda automatizada al proceso
(CASE) Tipos de herramientas CASE
Tool type
La Ingeniería de Software asistida por Ordenador Planning tools
(CASE) es el software que se utiliza para ayudar a las Editing tools
actividades de desarrollo y evolución del software.
Change management tools
Automatización de actividades Configuration management tools
Editores gráficos para el desarrollo del modelo de sistema Prototyping tools
Diccionario de datos para gestionar las entidades del diseño
Method-support tools
Generadores de GUI para la construcción del interfaz de
usuario Language-processing tools
Depuradores para encontrar los fallos de los programas Program analysis tools
Traductores automatizados para generar nuevas versiones
Testing tools
de un programa Debugging tools
Documentation tools
Re-engineering tools
49
Examples
PERT tools, estimation tools,
spreadsheets
Text editors, diagram editors, word
processors
Requirements traceability tools, change
control systems
Version management systems, system
building tools
Very high-level languages,
user interface generators
Design editors, data dictionaries, code
generators
Compilers, interpreters
Cross reference generators, static
analysers, dynamic analysers
Test data generators, file comparators
Interactive debugging systems
Page layout programs, image editors
Cross-reference systems, program re-
50
structuring systems

Reengineering tools

Tipos de herramientas CASE

Testing tools

Debugging tools

Program analysis tools

CASE
technology Language-processing
tools

Method support tools

Tools Workbenches Environments Prototyping tools

Configuration
management tools
File Integrated Process-centred
Editors Compilers Change management tools
comparators environments environments
Documentation tools

Editing tools
Analysis and
Programming Testing
design Planning tools

Specification Design Implementation Verification

Multi-method Single-method General-purpose Language-specific
and
workbenches workbenches workbenches workbenches
Validation
51 52

Objetivos de la gestión de
1.4. proyectos
Disciplinas de gestión de Organizar, planificar y programar los
proyectos proyectos de software
Disciplinas y técnicas:
Planificación y estimación de costes
Garantía de calidad
Gestión de la Configuración
Gestión de personal
…

9
 Tareas de gestión de proyectos
(competencias de un jefe de proyecto) 1.4.1
Planificación del proyecto Planificación del proyecto
• Tareas a realizar y plan de trabajo
Estimación
ó del
d l coste del
d l proyecto
Supervisión y revisión del proyecto Medición
• Para comparar los progresos y costes Estimación
reales con los planeados y hacer ajustes El plan de proyecto
Herramientas gráficas
Selección y evaluación del personal
Redacción y presentación de informes

Estimación del coste del

Planificación del proyecto software
Es la actividad que más tiempo Predecir los recursos necesarios para un
consume en la administración de un determinado proceso de desarrollo de
software
proyecto
Es un proceso iterativo que se completa
Preguntas:
cuando el proyecto mismo termina.
¿Cuánto esfuerzo se requiere para
El plan del proyecto debe ser revisado completar una actividad?
regularmente
Es imposible a la vistasin
planificar deestimar
la evolución
o ¿Cuánto tiempo de calendario se necesita
del mismo para terminar una actividad?
estimar sin medir… ¿Cuál es el coste total de una actividad?

Medición de la Productividad Métricas de la productividad

Se intenta determinar una medida de la
Métricas relacionadas con el tamaño.
cantidad de software y de documentación
asociada que produce un programador número de líneas del código fuente
individual número de instrucciones del código
g objeto
j
Hay que tener en cuenta que existen
número de páginas de la documentación...
muchas soluciones software con distintas
características: más eficiente, más Métricas relacionadas con la función.
mantenible, …
Basadas en una estimación de la
Hay varias propuestas de métricas para
funcionalidad del software entregado: los
medir diversos aspectos del software
puntos de función.

10
 Métricas de Puntos de función Calidad y productividad
measurement parameter count
weighting factor
simple avg. complex
Las métricas basadas en volumen/unidad de
tiempo (líneas/programador-mes) son
number of user inputs X 3 4 6 =
imperfectas
number of user outputs X 4 5 7 =
no tienen
ti en cuenta
t factores
f t como la
l fiabilidad,
fi bilid d ell
number of user inquiries X 3 4 6 = mantenimiento, …
number of files X 7 10 15 =
number of ext.interfaces X 5 7 10 = La productividad se puede aumentar
count-total generalmente a costa de la calidad
complexity multiplier
function points

Técnicas de estimación Técnicas de estimación

No hay una forma simple de hacer una Modelado algorítmico de costes.
estimación exacta del esfuerzo requerido para Se analizan los costes de otros proyectos realizados. Se
utiliza una fórmula matemática para predecir los costes del
desarrollar un sistema de software proyecto actual
Las estimaciones iniciales se basan en información Opinión de expertos.
poco precisa que aportan los usuarios
S consulta
Se l a varios
i expertos y entre ellos
ll acuerdan
d una
El software puede tener que ejecutarse en estimación.
ordenadores no conocidos o utilizar tecnología nueva
Estimación por analogía.
El personal del proyecto es desconocido
Se estima por analogía con otros proyectos completados
sobre el mismo dominio de aplicación.
Ley de Parkinson.
Las estimaciones de los costes del proyecto El trabajo se extiende para llenar el tiempo disponible.
tienden a “autorealizarse” El coste se determina según los recursos disponibles.
La estimación determina el presupuesto y el producto Precio para ganar.
se ajusta para cumplir el presupuesto Se acuerda la funcionalidad aceptable para el sistema
teniendo en cuenta el coste acordado.

Estructura de un plan de Estructura de un plan de

proyecto proyecto
Se fijan los recursos disponibles, se divide 4. Requisitos de recursos de hardware y de software.
el trabajo y se crea un calendario de Precios de lo que hay que comprar y fechas de entrega

trabajo. 5. División del trabajo.

División del proyecto en actividades, marca hitos y
productos a entregar
1. Introducción. 6. Calendario del proyecto.
Objetivos del proyecto y restricciones económicas y Dependencias entre actividades, tiempo estimado
temporales requerido y asignación de personal
2. Organización del proyecto. 7. Mecanismos de supervisión e informe.
Organización del equipo, personas involucradas y sus tareas
Cuándo y qué tipo de informe debe producirse
3. Análisis de riesgos.
Posibles riesgos con su probabilidad y estrategias de reducción
de riesgos propuestas

11
 Problemas en la planificación
Estimar la dificultad de los problemas, y por 1.4.2
lo tanto el coste de desarrollar una solución, Otras actividades de gestión
es difícil
L productividad
La d i id d no es proporcional
i l all
número de personas que trabajan en una
tarea Gestión de riesgos
Añadir personal al final del proyecto produce Garantía de calidad
más retraso por la sobrecarga en la Gestión de la configuración
comunicación
Lo inesperado siempre ocurre

Gestión del riesgo Tabla de riesgos

El análisis de riesgos consiste en evaluar el Probabilidad Impacto Gestión y

Riesgo
proyecto, la tecnología y los recursos con el Mitigación del
fin determinar y comprender la naturaleza y Riesgo

el origen de los riesgos Escala 1..5

1=impacto
bajo
5=catástrofe
Posibles riesgos: Ejemplo:
Software
Comerciales (competencia, etc.) empotrado
Financieros (económicos, etc.) depende de Ajustar pruebas a la
hardware no disponiblilidad del
Técnicos (¿base tecnológica sólida y probada?) disponible 60% 4(crítico) HW
De desarrollo (¿equipo experimentado?) Utilizar simulación

Garantía de calidad
Conceptos de calidad
Coste de los fallos encontrados en distintas etapas ¿Cómo se aplica al software?
100 60.00-100.00 Control de calidad: inspecciones, revisiones,
pruebas
Aseguramiento de la calidad: análisis, auditoría e
10 10.00 informes
3.00
1.50
1 0.75
1.00 Estándares de calidad: ISO 90003
guía para la aplicación de la ISO 9001:2000 para la
Diseño Pruebas En uso adquisición, suministro, desarrollo, instalación y
Req. Prog. Prueba mantenimiento de SOFTWARE y servicios de soporte.
del sistema

13
 MODELO DE MADUREZ DE LA CAPACIDAD
Garantía de calidad Nivel Características Resultados
- Ausencia de gestión de proyectos.
- El proceso de software es cambiante e irregular:
- Los planes, estimaciones y calidad son
Proceso y impredecibles. Productividad y
Revisiones Inicial - El rendimiento depende de la capacidad calidad escasa.
Estandares formales individual de los miembros del grupo. Riesgo máximo
- Se
S establecen
t bl programas de
d formación
f ió del
d l
personal de desarrollo y mantenimiento.

Análisis
& Planifica- - Los procesos de software son estables y
Informes ción de las repetibles.
pruebas - La organización establece políticas de gerencia
Productividad y
Métricas de proyectos y procesos.
Repetible calidad baja.
- La planificación se basa en proyectos similares.
Riesgo alto.
- Existen estándares definidos y exigidos.
- El proceso se enmarca en un sistema de gestión
de proyectos basado en experiencias pasadas.

MODELO DE MADUREZ DE LA CAPACIDAD

Nivel Características Resultados

SITUACIÓN DE CMM EN ESPAÑA. 5/2006
-Los procesos son definidos:
estandarizados, documentados e institucionalizados.
- Los procesos de ingeniería y gerencia son estables y se
integran en uno sólo. Productividad y
Definido - Existe un entendimiento común de los procesos, calidad media.
funciones y responsabilidades. Riesgo medio.
- La organización mantiene un grupo dedicado a la
definición, mejora y difusión del proceso
- Los procesos son medibles o cuantificables
- La productividad y la calidad se miden y registran para
cada proyecto de la organización. Productividad y
Gestionado - Se fijan metas cuantitativas de la calidad del software. calidad alta.
-Mediante el uso de métricas de software, se crea una Riesgo mínimo.
base cuantitativa para la evaluación y estimación en
proyectos futuros.
- Los procesos se mejoran continuamente.
- La organización busca lograr el nivel máximo de Productividad y
Optimizado capacidad. calidad total.
- Se incorporan nuevas tecnologías y métodos para Riesgo nulo.
mejorar los procesos.

Gestión de la configuración del

software Gestión de la configuración del software
Cambios en
Requisitos de negocio
Cambios en
Requisitos técnicos
C bi en
Cambios
otros programas
Requisitos de usuario documentación

modelos de software

Hay cambios
Plan datos
datos en muchas
Pruebas piezas
código

14
 ¿Por qué se necesita un
lenguaje de modelado?
1.6.Lenguaje Unificado de Los sistemas complejos son difíciles de
entender si no se cuenta con un modelo que
Modelado (UML) los describa

Disponer de un lenguaje capaz de modelar

cualquier sistema software es esencial
1.6.1 ¿Qué es UML?
1.6.2 Arquitectura El lenguaje de modelado tiene un valor
1.6.3 Elementos de Modelado añadido si dicho lenguaje es estándar.
1.6.4 Mecanismos de extensión
92

¿Qué es UML? UML- Objetivos

“Unified Modeling Language” Establecer un lenguaje visual de modelado, expresivo y sencillo
UML no es un método OO (?) en su uso
UML propone una notación y una semántica universal. Mantener una independencia (?) de los métodos y de los
Inicialmente: lenguajes de programación
“Un lenguaje
“U l j para especificar,
ifi construir
t i yd documentar
t Establecer bases formales (?)
artefactos software, que pretende cubrir los conceptos de Imponer un estándar mundial
Booch, OMT y OOSE con un lenguaje simple, común y
ampliamente utilizable por usuarios de otras metodologías”
Integrar las mejores prácticas
UML es un un lenguaje para representar los modelos de Modelar sistemas, y no únicamente software
cualquier método OO. Establecer las relaciones entre modelos conceptuales y
ejecutables
UML no fuerza a utilizar un método concreto (distintos tipos Crear un lenguaje de modelado utilizable tanto por máquinas
de problemas conducen a diferentes métodos de análisis y como por hombres
diseño) 93 94

Participantes en UML
UML aglutina múltiples enfoques
Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)
Rumbaugh Digital Equipment
Booch Jacobson Hewlett-Packard
Odell i-Logix (David Harel)
Meyer IBM
Pre- y
Pre
Shlaer-Mellor ICON Computing (Desmond
( d D’Souza)
’ )
Ciclo de vida de los objetos
UML Post-condiciones
Intellicorp and James Martin & co. (James Odell)
Harel
MCI Systemhouse
Gamma et. al. State Charts
Frameworks, patrones Microsoft
Embly Wirfs-Brock ObjecTime
Singleton
Fusion Responsabilidades Oracle
Descripciones de operaciones, Platinium Technology
Numeración de mensajes Sterling Software
Taskon
Texas Instruments
95 Unisys 96

16
 UML 2.x (08/2005) Aspectos Novedosos
UML: Evolución UML 1.5 (2003)

septiembre de 2001 UML 1.4

Abril 1999: UML 1.3 Definición semi-formal del Meta-Modelo
s públicos

asociado
Publicación de UML 1.1 Estandarización
Septiembre 1997
UML 1.1
Incluye “stereotypes”
stereotypes como mecanismo de
Documentos

Publicación de UML 1.0

UML 1.0
Enero 1997 extensibilidad (usos particulares)
Unificación
Junio 96 y Octubre 1996 UML 0.9 & 0.91
Colaboradores y
OOPSLA’95 Método Unificado 0.8 expertos Incluye un lenguaje para expresar
restricciones, OCL (Object Constraint
Booch’93 OMT-2 Language) desarrollado por IBM
Fragmentación
Otros métodos Booch’91 OMT-1 OOSE
97 98

Modelado con UML

Perspectivas de UML

UML ya es el lenguaje de modelado predominante State

State de
Participación de importantes empresas Use
UseCase
Case de
Diagramas
Diagrams
Diagrams State
Use Diagramas
Diagrams Clases State de
Aceptación como notación estándar OMG UseCase
Case de
Diagramas
Diagrams
Casos de Uso
Diagramas
Diagrams
Diagrams
Diagrams
Diagrams Objetos
Secuencia
Evidencias:
Herramientas UML, libros, Congresos, cursos, camisetas, Scenario State
Scenario de
Diagramas State de
Diagramas
Diagrams
Diagrams Diagrams
Diagrams
Colaboración Modelo Componentes
Inconvenientes:
Definición separada del proceso de desarrollo Scenario
Scenario de
Component
Component
Diagramas
Diagrams Diagramas
Diagrams
Diagrams
de
Falta integración con otras técnicas tales como patrones de Diagrams
Estados Distribución
Diagramas de
diseño, interfaces de usuario, etc. Actividad
Monopolio de conceptos, técnicas y métodos en torno a UML
“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”
99 100

¿Qué debe aportar un lenguaje de

modelado?

Elementos de modelado Conceptos + Semántica

Notación Representación visual de los elementos 1.6.2. Arquitectura de UML
Recomendaciones Cómo usarlo

Principales elementos de UML:

Un metamodelo y una semántica
Una notación gráfica

Un conjunto de recomendaciones
101

17
Arquitectura Jerarquía de modelos
Arquitectura de cuatro capas, definida en la
especificación Meta Object Facility del OMG:

•Meta-metamodelo: define el lenguaje para

especificar
p metamodelos

• Metamodelo: define el lenguaje para especificar

modelos

• Modelo: define el lenguaje para describir un

dominio de información

• Objetos de usuario: define un dominio de

información específico
103 104

Modelado de objetos ...Modelado de objetos

Una situación parecida ocurre con las relaciones:
Los objetos se relacionan con las clases de las que
son creados por la relación “SerInstanciaDe”
(“IsInstanceOf”)

105 106

Metamodelado... Metamodelado... Pop

Type = Real

Se basa en la idea de modelar los tipos de

Attribute Area

UML
type Type = Real

HasAttribute

entidades (clases y relaciones) con que forman los

HasAttribute HasAttribute

Class City Houston

modelos
NoOfInstances NoOfInstances = 1 Pop = 2M
Area = 40 SM

HasRelationship HasRelationship
IsIn

Relationship IsIn.Country USA

SourceCardinality SourceCardinality = 0 Pop = 250M
TargetCardinality TargetCardinality = 1 Area = 200 SM

Cuando
d se ve la
l clase
l como un objeto,
b la
l clase
l es Pop

una instancia de otra clase (o meta-clase)

Type = Real

Attribute Area
type Type = Real

HasAttribute

HasAttribute HasAttribute

Class City Houston

NoOfInstances NoOfInstances = 1 Pop = 2M
Area = 40 SM

HasRelationship HasRelationship
IsIn

Relationship IsIn.Country USA

SourceCardinality SourceCardinality = 0 Pop = 250M
TargetCardinality TargetCardinality = 1 Area = 200 SM

107 108

18
 ...Metamodelado Terminología de metamodelado...

La idea fundamental en el metamodelado es que La idea de ver las clases como objetos puede ser
aplicada repetidamente para crear una jerarquía
las entidades del modelo (ej: clases) juegan dos
de instanciación del clases y objetos
papeles:
ell papell de
d plantilla
l till (cuando
( d se ve como una clase)
l )
el papel de instancia (cuando se ve como instancia de la
En principio está jerarquía podría continuar hasta
meta-clase) cualquier profundidad arbitraria, pero en la
práctica no se extiende más allá de cuatro niveles
de profundidad

109 110

Terminología de metamodelado... ...Terminología de metamodelado

UML se define en cuatro niveles (la guía semántica

de UML representa justamente el nivel meta-
modelo)

111 112

UML: Notación
1.6.3 Bloques
Elementos
Elementos de modelado en UML Estructurales
De comportamiento
De Agrupación
De anotación
Elementos y Relaciones Relaciones
Diagramas UML Diagramas

Vistas Mecanismos
Mecanismos de Especificación
Divisiones
Adornos
Mecanismos de extensibilidad 114

19
 Bloques y relaciones Paquetes en UML
Clase Objeto
Son elementos auxiliares de organización y pueden contener
cualquier elemento de modelado.
Atributos Atributos
Estado
Métodos Métodos

Pueden anidarse a su vez.

Caso de N d
Nodo
Uso Interfaz
Actor Su utilidad final es ganar claridad

Nota Componente
Paquete

Nombre

Dependencia Generalización Nombre Nombre Nombre

Asociación Realización

115 116

Notas UML- Diagramas

Una nota es un comentario en el diagrama, que irá
unida a él o a uno de sus elementos..

Ejemplo de una

nota asociada a una clase

Clase
Atributos
Métodos

117 118

Diagramas de estructura Diagramas de comportamiento

119 120

20
 UML- Diagramas UML- Casos de uso
Elicitación de requisitos de usuario
Casos de Uso Introducido formalmente por Ivar Jacobson

Modelado de la estructura estática/análisis y diseño De empleo en la etapa de elicitación para captar los
Diagrama de Clases requisitos de los usuarios
Model do de la
Modelado l estructura
e t t e
estática/implementación
táti /implement ión
Diagrama de Componentes
Diagrama de Distribución De fácil comprensión por parte de los usuarios de los
sistemas
Modelado de interacción
Diagrama de secuencia Precisa otras técnicas complementarias para ser
Diagrama de comunicación
utilizada en procesos de modelado OO
Modelado dinámico
Diagrama de Estados
Diagrama de Actividades 121 122

UML- Casos de uso caso de uso

UML- Diagrama de Clases
Proviene de los diagramas de entidad-relación de Chen (‘70s)
incorporar
libros
«include» Fueron extendidos con conceptos de AOO, como generalización
«extend»
y agregación (‘80s)
consultar crear nuevo
libro código Bibliotecario Aunque también fueron empleados por Booch, conservan el
actor aspecto de la notación propuesta por Rumbaugh en OMT
«include»
Permiten modelar la estructura estática de los sistemas
realizar
Alumno préstamo

123 124

UML- Diagrama de Clases UML- Diagrama de Secuencia

Describe la forma en la que colaboran entre sí los objetos para
Persona llevar a cabo sus respectivas responsabilidades
asociación Autor
1 Cada diagrama representa la funcionalidad (parcial) de un único
navegabilidad caso de uso
generalización 1..*
solicita
Alumno Libro
0..* 0..* Permite ver cómo se suceden cronológicamente los mensajes
entre los objetos

clase Proviene de los diagramas POSA de Buschmann

Préstamo
nota
clase asociación Fueron utilizados por los tres autores del UML en sus
respectivos métodos previos
multiplicidad

125 126

21
 UML- Diagrama de Secuencia UML- Diagrama de Comunicación
Es otro de los diagramas de interacción que se
objeto 1 objeto 2 objeto 3

incluye en el UML
inicio de un método

auto-delegación
No permite observar gráficamente la cronología de
los mensajes

activación Facilita la organización de los objetos en paquetes

retorno Destaca la conexión estática entre los objetos

destrucción de un
objeto 127 128

UML- Diagrama de Comunicación UML- Diagrama de estados

1: maximo_alcanzado ( ) Describe cómo cambian de estado los objetos a medida que
: Usuario ocurren eventos

Cada diagrama se utiliza para representar el ciclo de vida de los

objetos de una única clase (estados posibles en la vida de los
: bibliotecario objetos)
2: ejemplares disponibles ( )

Provienen de los diagramas de estado de David Harel

: Libro

Los emplearon Rumbaugh en OMT, Booch en su libro de 1994 y

: Ejemplar
2.1: prestado ( ) Jacobson con la incorporación de una notación amplia

129 130

UML- Diagrama de estados UML- Diagrama de Actividad

Sin antecedentes claros

Permite destacar y sincronizar las operaciones

concurrentes y establecer caminos alternativos

Muestra el comportamiento combinado de varias

clases

Se emplea para describir comportamientos complejos

131 132

22
 UML- Diagrama de Actividad 1.6.4
Buscar
transporte Mecanismos generales de
extensión de UML
Se va en
S Toma un
T
su auto taxi

Estereotipos.
Cambia de Mira por el
Restricciones.
marcha espejo
Valores etiquetados.

Entra a su
trabajo

133

Mecanismos de extensión:

Mecanismos de UML Estereotipos

Tipos de mecanismos Un estereotipo es un nuevo tipo de elemento de
Mecanismos de Especificación modelado.
Completa el aspecto gráfico Los estereotipos se representan encerrados en los
Divisiones (dicotomías) símbolos « » o mediante iconos
Ej: clase y objeto,
objeto operación y método.
método
Adornos
Se pueden añadir detalles como la multiplicidad de una
relación
Mecanismos de extensibilidad
Estereotipos
Valores etiquetados
Restricciones (OCL)

135 136

Mecanismos de extensión: Mecanismos de extensión:

Valores etiquetados: Restricciones:

Se pueden añadir propiedades a los elementos de Una restricción es una relación semántica entre
UML. Consisten en parejas de etiqueta + valor elementos del modelo que especifican condiciones y
proposiciones que deben de ser respetadas o
mantenidas como ciertas.

Ventana
{abstract,
autor=José Z.,
Todas las restricciones irán siempre encerradas entre
estado=comprobada} llaves ( { } ).

En particular se puede utilizar OCL (Object Constraint

Language)

137 138

23
 Mecanismos de extensión:
Mecanismos de extensión:
Restricciones: Restricciones: OCL
UML propone un lenguaje para expresar la
* Miembro de * navegación a través de caminos de clases en
Persona {Subconjunto} Comité el modelo.
1 Preside *
Estas expresiones se pueden encadenar, de
trabajador Empleado Empleador tal forma que el elemento más a la izquierda
*
Persona * 0..1 Empresa sea un objeto o un conjunto de objetos.
jefe
0..1

vuelo.piloto.horas_de_entrenamiento > horas.avión.horas_min

{Persona.empleador= empresa.empleado[cargo=“Gerente” and Count(Subordinados)>10].

Persona.jefe.empleador}

139 140

Caso de estudio: Punto de venta

Bibliografía general
Sommerville, I. "Ingeniería del software" Pearson, 2005 (7ª ed.)
Pressman, Roger S. "Ingeniería del software : un enfoque práctico
MacGraw-Hill", 2005 (6ª ed)
Booch, G., Jacobson, I., Rumbaugh, J. “El Lenguaje Unificado de
Modelado. Guía del usuario”. Addison-Wesley/Diaz de Santos, 1999.

Lecturas complementarias

OMG, “OMG Unified Modeling Language Specification. Version 1.5”.

Object Management Group Inc., 2003.
SWEBOK: http://www.swebok.org
Código etico: http://seeri.etsu.edu/SpanishVersionSECode.htm
Colegio profesional de ingenieros en informatica de Castilla y
León: http://www.cpiicyl.org/index.html

141
Referencia: libro de Larman 142

Las ventas se registran a través Enfoque: Se pretende

de un terminal punto-de-venta (TPDV) independizar las capas del sistema:
Registrar las ventas, incluyendo el detalle de los productos y su
cantidad.
Capa de Interfaz
Manejar un catálogo con todos los productos.
Registrar los productos a través
é del código
ó de barras o tecleando su
identificación. Se debe mostrar el nombre y el precio del producto.
Calcular el total de la venta ¿y los descuentos? Capa de objetos Venta Pago Foco
Si se paga en efectivo, calcular las vueltas
del dominio
principal

Si se paga con tarjeta, capturar los datos del cliente/tarjeta y autorizar

el pago... Capa de servicios Registro Persistencia

Actualizar automáticamente el stock de cada producto

El cajero debe identificarse (nombre y contraseña) para utilizar un
terminal 143 144

24