UCM _ Grado en Ingeniería a Informática _ Ingeniería del Software _ Temario_zi

Esta es una vista previa del archivo. Inicie sesión para ver el archivo original

Temario/Tema 01 - Introducción a la IS.pdf
Introducción a la Ingeniería del Software
Ingeniería del Software
Juan Pavón Mestras
Dep. Ingeniería del Software e Inteligencia Artificial
Facultad de Informática
Universidad Complutense Madrid
Ingeniería del Software
¿Qué es la Ingeniería del Software?
¿En qué se diferencia un Programador de un Ingeniero de 
Software?
¿Cuál es la diferencia entre un Ingeniero de Software y un 
Ingeniero de Sistemas?
¿Qué diferencia la Ingeniería del Software de la Ciencia de la 
Computación?
¿Qué es el software?
¿Qué es un proceso de software?
¿Qué es la arquitectura del software?
Juan Pavón - UCM 2011-12 Ingeniería del Software 2
Mitos del software
 Te explico un poco como va y ya concretaremos luego
 Es fácil modificar el software
 Como es complejo, el software puede fallar
 Una vez que el programa funciona, hemos terminado
 Hasta que empiece a funcionar no sabré si está bien
 Al cliente basta con darle un código que funcione
 El programa no falla, es el cliente que no sabe utilizarlo
 Con pruebas y verificación formal se pueden eliminar todos los 
errores
 Cuanto más voluminosa sea la documentación de un producto, 
mejor será
 Siempre podemos añadir más programadores
 Si una característica de la aplicación no es necesaria para el 
80% de los usuarios, al 20% restante realmente no le hará falta
 Si un error ha sobrevivido a dos revisiones, no es un error, sino 
comportamiento normal del sistema
Juan Pavón - UCM 2011-12 Ingeniería del Software 3
Desastres causados por fallos del software
 Explosión del Ariane 5, 1996
 Motivo: conversión de datos de un número demasiado grande
 Pérdida del Mars Climate Observer, 1999
 Motivo: mezcla de kilos y libras. El satélite acabó pegándosela en 
Marte
 Airbus 320 derribado por un misil lanzado desde el USS Vicennes
durante la guerra Irán-Irak, 1988
 Fallo en el software de reconocimiento de patrones, que confundió a 
un avión civil con un F-14 iraní: 290 pasajeros muertos
 Muertes de pacientes de cáncer por sobredosis de radiación del 
equipo Therac-25, 1986
 Fallo de control de condiciones de carrera
 Redondeo en la conversión del Euro a DM
 1 EURO = 1.95583 DM 
 0.01 DM = 0.01 Euro y 0.01 Euro = 0.02 DM
 Virus y gusanos
Juan Pavón - UCM 2011-12 Ingeniería del Software 4
¿Qué es el software?
 Pressman:
1. Instrucciones (programas de computadora) que cuando se 
ejecutan proporcionan la función y el rendimiento deseados
2. Estructuras de datos que permiten a los programas 
manipular adecuadamente la información, y
3. Documentos que describen la construcción y uso de 
programas
 Sommerville:
 Programas de ordenador y documentación asociada
 Los productos de software pueden ser
• Genéricos: desarrollados para clientes muy diversos
• Hecho a medida: para un cliente particular de acuerdo a 
su especificación
Juan Pavón - UCM 2011-12 Ingeniería del Software 5
¿Qué es la Ingeniería del Software?
 La Ingeniería de Software (IS) es 
 una disciplina de ingeniería 
• Aplicación de teorías, métodos, herramientas para hacer 
cosas que funcionen:
• Software que sea fiable y trabaje en máquinas reales
• Teniendo en cuenta restricciones financieras, 
organizacionales y técnicas
 que comprende todos los aspectos de la producción de 
software
• Desde la especificación inicial al mantenimiento del sistema
• Administración y gestión del proceso de producción
• Principios y metodologías para desarrollo y mantenimiento de 
sistemas de software
 IEEE 610-12 (Software Engineering)
 Aplicación de un enfoque sistemático, disciplinado y 
cuantificable al desarrollo, operación (funcionamiento) y 
mantenimiento del software
Juan Pavón - UCM 2011-12 Ingeniería del Software 6
¿Qué es la Ingeniería del Software?
 La IS es aplicar el sentido común al desarrollo de sistemas 
software [Navarro, UCM]
¿Qué es el sentido común?
• Planificar antes de desarrollar
• Diseñar antes de programar
• Reutilizar diseños que funcionan y son mantenibles
 ... utilizando las herramientas apropiadas [Pavón, UCM]
Juan Pavón - UCM 2011-12 Ingeniería del Software 7
Herramientas CASE
 Computer-Aided Software Engineering (CASE)
 Software que facilita la realización de actividades del proceso 
de desarrollo de software
• Edición de diagramas
• Comprobar la consistencia de los diagramas
• Generación de documentación
• Seguimiento de actividades del proyecto
 Upper-CASE
 Herramientas que ayudan en las actividades de captura de 
requisitos, análisis y diseño
 Lower-CASE
 Herramientas para la programación, depuración y pruebas
Juan Pavón - UCM 2011-12 Ingeniería del Software 8
Ingeniería del Software e Ingeniería de Sistemas 
 La Ingeniería de Sistemas se refiere a todos los 
aspectos del desarrollo de sistemas basados en 
computadora, tanto del hardware como del software y los 
procesos de diseño y distribución de sistemas
 La Ingeniería del Software es solo parte de este proceso
 Los ingenieros de sistemas se encargan de especificar el 
sistema, definir su arquitectura, integrar sus partes
• Están menos relacionados con la ingeniería de los 
componentes del sistema (HW y SW)
 Al ser el software muchas veces la parte más importante 
del sistema, las técnicas de ingeniería del software se 
aplican en el proceso de ingeniería de sistemas
Juan Pavón - UCM 2011-12 Ingeniería del Software 9
Ingeniería de Software y Ciencia de la Computación
 La Ciencia de la Computación se refiere a las teorías y los 
fundamentos subyacentes en los sistemas de computación
 La Ingeniería del Software trata los problemas prácticos 
del desarrollo de software
 Con las teorías de la ciencia de la computación no es 
suficiente para desarrollar software (al menos cuando el 
sistema tiene suficiente envergadura)
Juan Pavón - UCM 2011-12 Ingeniería del Software 10
Relevancia de la IS
 Las economías de TODOS los países desarrollados 
dependen en gran medida del software
 Cada vez más sistemas son controlados por software
 Comunicaciones
 Seguridad
 Administración
 Fábricas
 Comercio
 Agricultura
 Etc.
 El gasto en la Ingeniería de Software, representa un alto 
porcentaje del PIB de los países desarrollados
Juan Pavón - UCM 2011-12 Ingeniería del Software 11
Costes del software
 Los gastos del software dominan sobre los de sistema
 El HW es cada vez más barato
 Cuesta más el software que hay en un PC que el PC
 Cuesta más mantener el software que desarrollarlo
 En sistemas con una larga vida, los costes de mantenimiento 
llegan a multiplicar varias veces los costes de desarrollo
 Lo más caro en un proyecto son los desarrolladores
 La IS trata de mejorar el coste del desarrollo de software
Juan Pavón - UCM 2011-12 Ingeniería del Software 12
¿Cuáles son los costes de la IS?
 Coste del software
 Gastos de desarrollo
 Gastos de mantenimiento y evolución
 El coste varía dependiendo de:
 Tipo de sistema que se desarrolle y los requisitos de atributos 
del sistema como eficiencia y fiabilidad
 Modelo de desarrollo
 Generalmente, para el desarrollo del software
 60% en desarrollo 
 40% en pruebas
 En software hecho a medida los gastos de evolución 
suelen ser mayores que los de desarrollo
 En software genérico muchas veces no se considera la 
evolución sino que cada nueva versión se trata como un 
nuevo producto (razones mercantiles)
Juan Pavón - UCM 2011-12 Ingeniería del Software 13
Retos de la IS
 Sistemas heredados (legacy systems)
 Mantenimiento, actualización, integración
 Heterogeneidad (SW y HW) de sistemas distribuidos
 Integración y evolución
 Tiempos de desarrollo cada vez más cortos
 Y con menos recursos
 Proyectos web: 3 meses–3 personas–3 kilos 
 Modas
 Métodos, lenguajes, ...
 Cultura de ingeniería
 Formalidad
 Existe una gran demanda de que exista formalidad en el 
proceso de desarrollo de software
Juan Pavón - UCM 2011-12 Ingeniería del Software 14
IS: las 3 P
Personas
Producto
Proceso
Juan Pavón - UCM 2011-12 Ingeniería del Software 15
Producto: el software
 El software cada día es más caro, más grande, menos 
eficiente, menos robusto, …
 El hardware cada día es más barato, más pequeño, más 
eficiente, más robusto, …
 El software hoy:
 Distribuido: web, nube, …
 Multi-componente
 Multi-plataforma
 Ubicuidad
 Interfaces multi-modales
 Múltiples versiones
 Inteligente
Juan Pavón - UCM 2011-12 Ingeniería del Software 16
Características del software
 El software se desarrolla, no se fabrica 
 Los costes se centran en ingeniería, no en fabricación 
 Los proyectos software no se pueden gestionar como procesos 
de fabricación
 El software no se estropea
 Pero hay que mantenerlo
Juan Pavón - UCM 2011-12 Ingeniería del Software 17
Características del software
Curva de fallos del hardware
Juan Pavón - UCM 2011-12 Ingeniería del Software 18
Curva de fallos del software
Características del software
 Reparación del software
 El software deteriorado no se puede reparar 
• ¿revisar miles de líneas de código?
• ¿cambia una versión con el tiempo?
 Muchas veces las reparaciones dañan más al software
 El software debe estar bien diseñado para facilitar su 
evolución
Juan Pavón - UCM 2011-12 Ingeniería del Software 19
Software bien diseñado
 Atributos del software bien diseñado
 Mantenible
• Capaz de evolucionar según las necesidades de cambio de los clientes
 Seguro
• Robusto, que no produce daños incluso bajo un fallo del sistema
 Eficiente
• No desperdicia los recursos del sistema (memoria, procesador, disco)
 Amistoso
• Buena interfaz
 Bien documentado
Atributos en tensión: su importancia depende del sistema y del 
entorno en el que será utilizado
El coste tiende a ser alto si se exige un alto nivel de alguna característica
Juan Pavón - UCM 2011-12 Ingeniería del Software 20
Características del software
 Coste de la eficiencia del software
Juan Pavón - UCM 2011-12 Ingeniería del Software 21
Coste
Eficiencia
Software bien diseñado
 Componentes software
 Ingeniería: creación y mantenimiento de una serie de 
componentes estándar con el fin de no reinventar la rueda
 Software bien diseñado debe favorecer la reutilización de 
código
 Las tecnologías OO y de componentes software reutilizables 
favorecen dicha reutilización
Juan Pavón - UCM 2011-12 Ingeniería del Software 22
Distintos tipos de software
 Software de sistemas
 Programas escritos para servir a 
otros programas
• Compiladores, Sistemas 
Operativos (SSOO), etc.
 Software de gestión
 Proceso de información comercial, 
accediendo a bases de datos que 
contienen dicha información
• Gestión de nóminas, control de 
almacén, etc.
 Software de PC
 Procesadores de texto, hojas de 
cálculo, navegadores, etc.
 Software de ingeniería y 
científico
 Algoritmos numéricos
• Programas CAD, simuladores, etc.
 Software empotrado (embedded
systems)
 Controla productos y sistemas de 
mercados industriales y de consumo
 Reside en ROM
 Relacionado con el tiempo real
 Software de inteligencia 
artificial
 Problemas complejos
• Sistemas expertos
• Reconocimiento de patrones (voz, 
imágenes, etc.)
• Agentes software
 Software en móviles
 Recursos limitados
Juan Pavón - UCM 2011-12 Ingeniería del Software 23
De vuelta con los mitos del software
 Mitos del gestor
 Mito: Tenemos un manual de desarrollo de software, ¿qué 
más necesitamos?
• Realidad: ¿Se entiende? ¿Se utiliza? ¿El personal tiene 
práctica en su aplicación?
 Mito: Disponemos de las herramientas de desarrollo más 
avanzadas, ya que compramos siempre los mejores equipos
• Realidad: ¿Se invierte en herramientas CASE? ¿Y en 
entornos de desarrollo? ¿Se forma al personal en el uso de 
estas herramientas?
 Mito: Si fallamos en la planificación, podemos añadir más 
personal y adelantar el tiempo perdido
• Realidad: En el proceso de software añadir gente puede 
retrasar más el proyecto. La gente debe añadirse de forma 
planificada y ordenada. Además si sacamos a gente de otros 
proyectos, en último término retrasaremos otros proyectos
Juan Pavón - UCM 2011-12 Ingeniería del Software 24
De vuelta con los mitos del software
 Mitos del cliente
 Mito: Una declaración general de objetivos es suficiente para 
comenzar a escribir los programas, y podemos dar los detalles 
más adelante
• Realidad: Una mala definición inicial conlleva trabajo inútil
 Mito: Los requisitos del proyecto cambian continuamente, 
pero los cambios pueden acomodarse fácilmente porque el 
software es flexible
• Realidad: Es cierto que los requisitos cambian, pero el 
impacto del cambio varía en función del momento en que se 
introduzcan los cambios
Juan Pavón - UCM 2011-12 Ingeniería del Software 25
De vuelta con los mitos del software
Juan Pavón - UCM 2011-12 Ingeniería del Software 26
Impacto del cambio
Momento Coste del cambio
Definición 1x
Desarrollo 1,5-6x
Después entrega 60-100x
De vuelta con los mitos del software
 Mitos de los desarrolladores
 Mito: Una vez que escribamos el programa y hagamos que 
funcione, nuestro trabajo ha terminado
• Realidad: Entre el 50% y el 70% de todo el esfuerzo 
dedicado a un programa se realiza después de que se 
entregue al cliente por primera vez
 Mito: Hasta que no tenga el programa ejecutándose, no tengo 
forma de medir su calidad
• Realidad: Revisiones Técnicas Formales durante el desarrollo 
de software.
 Mito: Lo último que se entrega al terminar el proyecto es el 
programa funcionando
• Realidad: Software = programas + datos + documentos
Juan Pavón - UCM 2011-12 Ingeniería del Software 27
Responsabilidad y ética profesional
 Confidencialidad
 De los demás empleados y de los clientes
 Competencia
 Reconocer los límites y capacidades para aceptar un trabajo
 Derechos de propiedad intelectual
 Patentes, copyright
 Trabajo de otros colegas
 Mal uso de los sistemas
 Juegos, virus, pirateo
Juan Pavón - UCM 2011-12 Ingeniería del Software 28
Responsabilidad y ética profesional
 Código ético de ACM/IEEE
 Principios que deben guiar el comportamiento y decisiones 
de ingenieros software profesionales (incluyendo gestores, 
estudiantes y profesores)
1.Actuar en bien del interés público
2.Actuar en el mejor interés del cliente y el empleador, 
siendo consistente con el interés público
3.Asegurar que los productos y modificaciones reúnen los 
mejores estándares profesionales posibles
4.Mantener la integridad e independencia en el juicio 
profesional
5.Suscribir y promocionar un comportamiento ético en la 
gestión y mantenimiento del desarrollo de software
6.Colaborar en el avance de la integridad y la reputación de 
la profesión siendo consistente con el interés público
7.Ser justo y ayudar a los colegas
8.A lo largo de la vida, reciclarse en la práctica de la 
profesión y promocionar un comportamiento ético en la 
práctica de la profesión
Juan Pavón - UCM 2011-12 Ingeniería del Software 29
Responsabilidad y ética profesional
 Dilemas en el ejercicio de la profesión
 Desacuerdo con los principios y política de los superiores
 El empleador actúa de manera no ética y libera un sistema 
crítico de seguridad sin haber acabado las pruebas del 
sistema
 Participación en el desarrollo de sistemas con fines contrarios 
a la propia moral
Juan Pavón - UCM 2011-12 Ingeniería del Software 30
Conclusiones
 El desarrollo y mantenimiento de software: 
Personas, Producto, Proceso
 El software siempre evoluciona
 La IS trata de abordar estas cuestiones de forma rigurosa
¡ Cuidado con los mitos !
Juan Pavón - UCM 2011-12 Ingeniería del Software 31
Bibliografía
 R. Pressman: Ingeniería del Software - Un enfoque práctico, 7ª 
edición. McGraw-Hill, 2010
 I. Sommerville: Ingeniería
del Software, 7ª edición. Addison 
Wesley, 2006
 Frederick P. Brooks, Jr., The Mythical Man-Month, Addison 
Wesley, 1975 (Anniversary edition 1995)
Juan Pavón - UCM 2011-12 Ingeniería del Software 32
Temario/Tema 02 - Proceso de Desarrollo de Software.pdf
Tema 02 –
Proceso de desarrollo de software
Ingeniería del Software
Rubén Fuentes Fernández
Dep. Ingeniería del Software e Inteligencia Artificial
Facultad de Informática
Universidad Complutense Madrid
Trabajando con Antonio Navarro, Juan Pavón y Pablo Gervás
Contenidos
• El proceso de desarrollo de software
– Introducción
– Modelos de proceso
• Modelo de madurez de capacidades del software
Rubén Fuentes Fernández Ingeniería del Software 2
Objetivos
• Entender qué es el proceso de desarrollo de software
• Cuáles son los componentes que debe considerar un proceso 
de desarrollo de software
• Modelos de proceso de desarrollo de software
• Calidad del proceso de desarrollo de software
Ingeniería del Software 3Rubén Fuentes Fernández
INTRODUCCIÓN
Rubén Fuentes Fernández Ingeniería del Software 4
El producto como base del proceso
• La Ingeniería es el análisis, diseño, construcción y verificación 
de entidades técnicas (o sociales).
• La entidad sobre la que trabaja caracteriza a la ingeniería:
– Caminos, canales y puertos
– Aeronaves
– Buques
– …
Ingeniería del Software 5Rubén Fuentes Fernández
Ingeniería del Software 6
Conceptos clave del proceso
• Personas: los que trabajan
• Producto: lo que se obtiene
• Proyecto: la pauta a seguir para desarrollar un producto
• Proceso: la pauta a seguir para desarrollar un proyecto
Rubén Fuentes Fernández
Ingeniería del Software 7
Una cena
• Personas: Empleados de una empresa de catering
• Producto: La cena que se sirve
• Proyecto: La secuencia de acciones de servir una cena 
concreta
• Proceso: Las instrucciones                                                               
de la empresa sobre                                                                    
cómo se sirve una cena
Rubén Fuentes Fernández
Ingeniería del Software 8
Una gama de automóviles
• Personas: Empleados de la marca
• Producto: Los automóviles
• Proyecto: Desarrollo de un modelo nuevo
• Proceso: Las instrucciones de la empresa sobre cómo 
desarrollar un                                                                           
modelo nuevo
Rubén Fuentes Fernández
Ingeniería del Software 9
Software
• Personas: Vosotros
• Producto: ???
• Proyecto: ???
• Proceso: Asignatura de IS
Rubén Fuentes Fernández
Aspectos a considerar en la Ingeniería
• Con independencia de la entidad debemos identificar y 
solucionar:
– Problema a resolver
– Características de la entidad
– Forma de construir la entidad
– Enfoque para resolver los errores cometidos durante el diseño y 
construcción de la entidad
– Mantenimiento de la entidad frente a su evolución
Rubén Fuentes Fernández Ingeniería del Software 10
Tecnología estratificada
• La IS es una tecnología multicapa:
– Capa de enfoque de calidad
• Base de cualquier proceso de ingeniería
• Mejores técnicas o buenas prácticas
– Capa de proceso
• Conjunto de actividades y resultados asociados que sirven para construir 
un producto software.
– Capa de métodos
• Un método ofrece pautas para:                                                                
análisis de requisitos, diseño,                                                          
construcción de programas,                                                                     
prueba, instalación y                                                                     
mantenimiento
– Capa de herramientas
Rubén Fuentes Fernández Ingeniería del Software 11
Objetivos de un proceso del software
• Desarrollar, operar y mantener software de forma que:
– Se apliquen principios y metodologías de ingeniería
– Se construya software que satisfaga las necesidades del cliente
• No sólo funcionales
• También coste, fiabilidad y eficiencia
– Se pueda sistematizar, disciplinar y cuantificar
• Establecer pautas sobre las que orientar, reflexionar, aprender y mejorar
Ingeniería del Software 12Rubén Fuentes Fernández
Producto y fases genéricas
• En IS, entidad = software
• Soporte para el desarrollo de la entidad/soporte para la IS: 
modelo de proceso
• Con independencia del modelo de proceso hay tres fases 
genéricas:
– Fase de definición
– Fase de desarrollo
– Fase de mantenimiento
Ingeniería del Software 13Rubén Fuentes Fernández
Fase de definición
• Centrada en el qué
• Se identifican los requisitos del sistema y software:
– Información a procesar
– Función y rendimiento deseados
– Comportamiento del sistema
– Interfaces establecidas
– Restricciones de diseño
• Tareas principales:
– Planificación del proyecto software
– Ingeniería de sistemas o de información
– Análisis de requisitos
Ingeniería del Software 14Rubén Fuentes Fernández
Fase de desarrollo
• Centrada en el cómo
• Se define cómo han de plasmarse los requisitos en el sistema:
– Diseño de las estructuras de datos
– Implementación de las funciones
– Caracterización de las interfaces
– Traducción del diseño a un lenguaje de programación
– Pruebas
• Tareas principales:
– Diseño del software
– Generación del código
– Pruebas del software
Rubén Fuentes Fernández Ingeniería del Software 15
Fase de mantenimiento
• Centrada en el cambio.
• Pueden producirse 4 tipos de cambio:
– Corrección. Corregir los defectos
– Adaptación. Modificaciones por cambio en el entorno externo
– Mejora. Ampliar los requisitos originales, a petición del cliente
– Prevención. Cambio para facilitar el cambio
• En esta fase se vuelven a aplicar las fases de definición y 
desarrollo, pero sobre software ya existente.
Ingeniería del Software 16Rubén Fuentes Fernández
Fases, actividades y tareas
• Las fases de un proceso del software se realizan mediante una 
serie de actividades.
– Las actividades se pueden extender a lo largo de varias fases.
– Ej. comunicación con el cliente, planificación, diseño e 
implementación del software
• Las actividades a su vez se articulan mediante acciones.
– Una acción es un conjunto de tareas relacionadas que produce un 
producto del trabajo o artefacto.
– Ej. la actividad diseño e implementación puede incluir una acción de 
análisis, que puede descomponerse en las tareas realizar diagramas 
casos de uso, realizar diagramas actividades, realizar diagramas clases 
análisis…
Ingeniería del Software 17Rubén Fuentes Fernández
Actividades de protección
• Las actividades de creación de artefactos se complementan con las 
actividades de soporte o protección.
– No crean software
– Mejoran su calidad
– Facilitan su desarrollo
• Se aplican a lo largo de todo el proceso del software.
• Ejemplos de actividades de soporte:
– Documentación
– Gestión de configuración
– Seguimiento y control del proyecto de software
– Revisiones técnicas formales
– Garantía de la calidad del software
– Gestión de reutilización
– Mediciones
– Gestión de riesgos
Rubén Fuentes Fernández Ingeniería del Software 18
Proceso del software
• Conjunto estructurado de actividades y resultados asociados 
requeridos para desarrollar un sistema de software
– Especificación: establecer los requisitos y restricciones del sistema
– Diseño: producir un modelo del sistema
– Implementación: construcción del sistema de software
– Validación: verificar que el sistema cumple con las especificaciones 
requeridas
– Instalación: entregar el sistema al usuario y asegurar su operacionalidad
– Evolución y mantenimiento: cambiar/adaptar el software según las 
demandas; reparar fallos en el sistema cuando sean descubiertos
• Debe estar explícitamente modelado si va a ser bien administrado.
Rubén Fuentes Fernández Ingeniería del Software 19
Modelos de proceso
• Un modelo de proceso del software (o paradigma de IS) es 
una representación abstracta de un proceso del software.
– Plantilla, patrón o marco que define el proceso a través del cual se 
crea software
• Los modelos de proceso tienen en cuenta, en mayor o menor 
medida, las actividades estructurales comunes a todos los 
procesos de construcción de software.
• Un modelo de proceso ha de definir sus actividades 
estructurales así como su flujo de realización.
Ingeniería del Software 20Rubén Fuentes Fernández
Adaptación de los modelos de proceso
• Los modelos de proceso no son fijos para una organización o 
tipo de proyecto.
• Una organización puede variar su modelo de proceso para 
cada proyecto según:
– La naturaleza del proyecto
– La naturaleza de la aplicación
– Los métodos y herramientas a utilizar
– Los controles y entregas requeridos
• Los modelos de proceso se ajustan a los proyectos concretos 
variando el conjunto de tareas en que se dividen las 
actividades estructurales.
Ingeniería del Software 21Rubén Fuentes Fernández
Características para seleccionar el proceso
• Entendible
• Visibilidad
– Grado en que las actividades del proceso proporcionan resultados
• Soportable por herramientas CASE
• Aceptabilidad
– Grado en que los desarrolladores aceptan y usan el proceso
• Fiabilidad
– Capacidad de evitar o detectar errores antes de que sean defectos
• Robustez
– Continuidad del proceso a pesar de los problemas
• Mantenible
– Capacidad de evolución para adaptarse
• Rapidez
– Velocidad con que el proceso proporciona un sistema a partir de una especificación
Rubén Fuentes Fernández Ingeniería del Software 22
MODELOS DE PROCESO QUE SÍ 
SON…
Rubén Fuentes Fernández Ingeniería del Software 23
Principales modelos de proceso del software
• Modelo en cascada
– Separa en distintas fases de especificación y desarrollo que se realizan 
en secuencia lineal.
• Prototipado
– Un prototipo sirve de modelo para la construcción del sistema final.
• Desarrollo evolutivo
– La especificación y el desarrollo están intercalados.
• Transformación formal
– Un modelo matemático del sistema se transforma formalmente en la 
implementación.
• Desarrollo basado en reutilización
– El sistema es ensamblado a partir de componentes existentes.
Rubén Fuentes Fernández Ingeniería del Software 24
MODELOS EN CASCADA
Modelos de proceso que sí son…
Rubén Fuentes Fernández Ingeniería del Software 25
Modelo en cascada (waterfall) (1/2)
Rubén Fuentes Fernández Ingeniería del Software 26
Análisis
Diseño
Implementación
Pruebas e 
integración
Instalación
Conceptualización
Modelo en cascada (2/2)
• Es el modelo de proceso clásico (desde los 1970s)
• Es sencillo y fácil de entender
– Basado en la mentalidad de línea de ensamblaje
• El proyecto pasa a través de una serie de fases
– Al final de cada fase se revisan las tareas de trabajo y productos
• Para poder pasar a la siguiente fase se tienen que haber conseguido todos 
los objetivos de la fase anterior.
– No hay apenas comunicación entre las fases
• Se supone que sólo se baja en la cascada...
– ... pero también se puede subir (aunque difícilmente)
Rubén Fuentes Fernández Ingeniería del Software 27
Modelo en cascada: fases
• Conceptualización
– Se determina la arquitectura de la solución
– Arquitectura = división del sistema en subsistemas + comunicación
• Análisis de requisitos
– Básicamente se definen los requisitos funcionales y de rendimiento
• Diseño
– Representación de la aplicación que sirve de guía a la implementación
• Implementación
– Transforma el diseño en código
• Prueba
– Validación e integración del software y de los sistemas
• Instalación y comprobación
– Se instala al cliente, el cual comprueba la corrección de la aplicación
Rubén Fuentes Fernández Ingeniería del Software 28
Modelo en cascada: documentos
Actividad Documentos producidos
Análisis de Requisitos Documento de Requisitos
Definición de Requisitos Documento de Requisitos
Especificación del Sistema Especificación Funcional y Plan de Pruebas de Aceptación
Diseño Arquitectural Especificación de la Arquitectura y Plan de Pruebas del Sistema
Diseño de Interfaces Especificación de Interfaces y Plan de Pruebas de Integración
Diseño detallado Especificación del Diseño y Plan de Pruebas de Unidades
Codificación Código de Programa
Prueba de Unidades Informe de Prueba de Unidades
Prueba de Módulos Informe de Prueba de Módulos
Prueba de Integración Informe de Prueba de Integración y Manual de Usuario Final
Prueba del Sistema Informe de Prueba del Sistema
Prueba de Aceptación Sistema Final y Documentación
Rubén Fuentes Fernández Ingeniería del Software 29
Variantes del modelo en cascada
• Modelo Sashimi
– Solapamientos de fases
• Sommerville
• Pressman (lineal secuencial)
• Modelo en V
• Cascada con subproyectos
Rubén Fuentes Fernández Ingeniería del Software 30
Modelo en cascada: evaluación
• Ventajas:
– Muy probado
– Sencillo
• Sirve cuando el personal está poco cualificado
– Aplicable cuando el problema es estable y cuando se trabaja con técnicas 
conocidas
• Inconvenientes:
– Poco realista
– Supone una especificación de requisitos estable
– Baja visibilidad
• No se ve un producto hasta muy tarde en el proceso
– Un error grave en las últimas fases puede ser letal
– Si no hay solapamientos entre fases puede haber bloqueos
– Las revisiones de proyectos de gran complejidad son muy difíciles
Ingeniería del Software 31Rubén Fuentes Fernández
PROTOTIPADO
Modelos de proceso que sí son…
Rubén Fuentes Fernández Ingeniería del Software 32
Modelo de construcción de prototipos
Rubén Fuentes Fernández Ingeniería del Software 33
Escuchar 
al cliente
El cliente 
evalúa el 
prototipo
Construir/
revisar 
prototipo
Modelo de construcción de prototipos
• Comienza con la recolección de requisitos
– Clientes y desarrolladores definen los objetivos globales del software.
– Además, identifican los requisitos conocidos y aquellos que deben ser 
más definidos.
• Aparece un diseño rápido centrado en los aspectos visibles 
para el cliente (ej. información de E/S)
– El diseño rápido lleva a la construcción de un prototipo.
• El prototipo lo evalúa el cliente y lo utiliza para refinar los 
requisitos
• El proceso se itera...
... desechando el primer prototipo
Rubén Fuentes Fernández Ingeniería del Software 34
Rubén Fuentes Fernández Ingeniería del Software 35
Modelo de construcción de prototipos
• Ventajas:
– Permite identificar los requisitos incrementalmente
– Permite probar alternativas a los desarrolladores
– Tiene una alta visibilidad  tanto clientes como desarrolladores ven 
resultados rápidamente
• Inconvenientes:
– El cliente no entiende porque hay que desechar el primer prototipo
• Si simplemente ha pedido unos ajustes...(¿?)
– Riesgo de software de baja calidad
• Compromisos de implementación para que el prototipo funcione 
rápidamente y que al final son parte integral del sistema
• Ej. utilizar un sistema operativo o lenguaje de programación inadecuado 
pero que ya es conocido
DESARROLLO EVOLUTIVO
Modelos de proceso que sí son…
Rubén Fuentes Fernández Ingeniería del Software 36
Modelos evolutivos
• Características:
– Gestionan bien la naturaleza evolutiva del software
– Son iterativos  construyen versiones del software cada vez más 
completas
• Se adaptan bien a:
– Los cambios de requisitos del producto
– Fechas de entrega estrictas poco realistas
– Especificaciones parciales del producto
Rubén Fuentes Fernández Ingeniería del Software 37
Modelos evolutivos
Rubén Fuentes Fernández Ingeniería del Software 38
Descripción
del sistema
Versión
Inicial
Versiones
Intermedias
Versión
Final
Especificación
Desarrollo
Validación
Actividades
Concurrentes
Modelos evolutivos  incremental
• Fusiona el modelo lineal secuencial con el de construcción
de 
prototipos
– El modelo lineal secuencial es una variante del modelo en cascada
Rubén Fuentes Fernández Ingeniería del Software 39
A D C P 1er incremento
A D C P 2º incremento
..................... N-ésimo incremento
Rubén Fuentes Fernández Ingeniería del Software 40
Modelos evolutivos  incremental
• Cada secuencia lineal produce un incremento del software.
– Un incremento es un producto operacional de una parte del sistema.
• El primer incremento suele ser un producto esencial o núcleo.
– Requisitos básicos
– Muchas funciones suplementarias se dejan para después
• Se evalúa (ej. por el cliente) el producto entregado.
– Como resultado se desarrolla un plan para el incremento siguiente
• Se itera.
– Hasta elaborar el producto completo
Rubén Fuentes Fernández Ingeniería del Software 41
Modelos evolutivos  incremental
• Ventajas
– Es interactivo
• Con cada incremento se entrega al cliente un producto operacional que 
puede evaluar
– Personal
• Permite variar el personal asignado a cada iteración
– Gestión riesgos técnicos
• Ej. disponibilidad de hardware específico
• Inconvenientes
– La primera iteración puede plantear los mismos problemas que en un 
modelo lineal secuencial
Modelo evolutivo incremental vs Prototipos
• Discusión: aparte de las fases de desarrollo concretas, ¿qué 
diferencia esencial hay entre el modelo de construcción de 
prototipos y el incremental?
Rubén Fuentes Fernández Ingeniería del Software 42
Modelos evolutivos  espiral
• Original: Boehm, 1988
– Revisado en el IEEE Std. 1490‐1998
• Se centra en tratar las áreas de mayor riesgo en un proyecto.
– Ej. requisitos y arquitectura
• El proyecto se compone de varios mini‐proyectos que tratan 
una o varias áreas de riesgo.
• Múltiples iteraciones sobre varias regiones de tareas
– Vuelta a la espiral  ciclo
– Número de iteraciones predeterminadas o calculadas dinámicamente
• Se pueden variar las actividades de desarrollo  familia de 
modelos de procesos
Rubén Fuentes Fernández Ingeniería del Software 43
Modelos evolutivos  espiral de Boehm
Rubén Fuentes Fernández Ingeniería del Software 44
Desarrollar 
entregas de la 
iteración y verificar 
que son correctas
Determinar objetivos,
alternativas y
restricciones
Identificar y 
resolver riesgos
Análisis de
Riesgos
Análisis de
Riesgos
Análisis de
Riesgos
Análisis de
Riesgos
Planificar la 
siguiente iteración
Prototipo
OperacionalPrototipo
3Prototipo
2Proto
tipo 1
Plan de requisitos
Plan del ciclo de vida
REVISIÓN
Plan de 
Desarrollo
Plan de Integración
y Prueba
Concepto de
Operación
Simulaciones, modelos y benchmarks
Requisitos
SW
Validación de
Requisitos
Diseño
V &V
Servicio
Pruebas de
Aceptación
Pruebas
Integración
Pruebas
unitarias
Codificación
Diseño
Detallado
Diseño
del
Producto
Evaluar 
alternativas
Entrega
Rubén Fuentes Fernández Ingeniería del Software 45
Modelos evolutivos  espiral
• El IEEE Std. 1490 especifica cuatro ciclos prototípicos:
– Prueba de concepto
• Requisitos generales
– Primer desarrollo
• Requisitos del sistema
– Segundo desarrollo
• Requisitos de los subsistemas
– Ciclo final
• Requisitos de unidades
• Realización de pruebas de aceptación
• Las regiones de tareas son asimilables a las fases del modelo 
en cascada.
Modelos evolutivos – espiral IEEE Std. 1490: 
regiones (1/2)
• Identificar requisitos
– En función del ciclo:
• Requisitos de negocio
• Requisitos del sistema
• Requisitos de subsistemas
• Requisitos de unidad
• Diseñar
– En función del ciclo:
• Diseño conceptual
• Diseño lógico
• Diseño físico
• Diseño final
Rubén Fuentes Fernández Ingeniería del Software 46
Rubén Fuentes Fernández Ingeniería del Software 47
Modelos evolutivos – espiral IEEE Std. 1490: 
regiones (2/2)
• Construir
– En función del ciclo:
• Prueba de concepto (prototipo)
• Primer desarrollo
• Segundo desarrollo
• Desarrollo final
• Evaluar
– En función del ciclo se hace:
• Análisis de riesgo
• Prueba del concepto
• Evaluación de los primeros desarrollos
• Prueba del desarrollo final
Rubén Fuentes Fernández Ingeniería del Software 48
Modelos evolutivos  espiral: evaluación
• Ventajas
– Enfoque realista
– Gestión explícita de riesgos
– Centra su atención en la reutilización de componentes y la eliminación 
de errores en información descubiertos en las fases iniciales
– Los objetivos de calidad son el primer objetivo
– Integra desarrollo con mantenimiento
• Inconvenientes
– Convencer cliente enfoque controlable
– Requiere de experiencia en la identificación de riesgos
– Requiere refinamiento para uso generalizado
Ejemplos de procesos evolutivos modernos
• 3 modelos de proceso concretos
– Modelos pesados
• Proceso Unificado
– Modelos ágiles
• eXtreme Programming
• Scrum
Rubén Fuentes Fernández Ingeniería del Software 49
PROCESO UNIFICADO DE 
DESARROLLO
Rubén Fuentes Fernández Ingeniería del Software 50
Proceso unificado de desarrollo
• El Proceso Unificado (Unified Process, UP) es creado por los 
autores de UML.
– Booch: método Booch
– Rumbaugh: OMT
– Jacobson: proceso Objectory
• También es conocido como RUP (Rational Unified Process) en 
su versión comercial. 
Rubén Fuentes Fernández Ingeniería del Software 51
Proceso unificado de desarrollo: claves
• Es un proceso de desarrollo de software:
– Dirigido por casos de uso
– Centrado en la arquitectura
– Iterativo e incremental
• Utiliza UML para definir los modelos del sistema software.
• El sistema software en construcción está formado por:
– componentes software 
– interconectados a través de interfaces
Rubén Fuentes Fernández Ingeniería del Software 52
Proceso de 
desarrollo de SW
Requisitos
de usuario Sistema SW
Los requisitos cambian y el sistema SW evoluciona
Proceso unificado de desarrollo
• Discusión: ¿todo modelo iterativo es incremental? ¿Y todo 
incremental es iterativo?
Rubén Fuentes Fernández Ingeniería del Software 53
Proceso unificado de desarrollo: mapa
Rubén Fuentes Fernández Ingeniería del Software 54
Gestión
Entorno
Modelo de negocio
Implementación
Pruebas
Análisis & Diseño
Iteración(es)
preliminares
Iter.
#1
Fases
Flujos de trabajo de proceso
Iteraciones
Flujos de trabajo de soporte
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Implantación
Gestión de configuración
Requisitos
Elaboración TransiciónConcepción Construcción
Proceso unificado de desarrollo: iteración
Rubén Fuentes Fernández Ingeniería del Software 55
Análisis
Requisitos
Implementación
Diseño
Prueba
Proceso unificado de desarrollo: fase
• Cada vuelta en la espiral se denomina iteración
• La agrupación de iteraciones se denomina fase
– Inicio
– Elaboración
– Construcción
– Transición
Rubén Fuentes Fernández Ingeniería del Software 56
Proceso unificado de desarrollo: fases
• Fase de inicio
– Se desarrolla una descripción del producto final
• Fase de elaboración:
– Se especifican los casos de uso
– Se diseña la arquitectura del sistema
• Fase de construcción
– Se crea el producto
• Fase de transición
– Periodo durante el cual el producto se entrega a clientes
• No todos los flujos de trabajo tienen el mismo peso dentro de 
cada fase
Rubén Fuentes Fernández Ingeniería del Software 57
Proceso unificado de desarrollo
• Actividad en el tiempo
Rubén Fuentes Fernández Ingeniería del Software 58
Descubrimiento Invención
Foco
Implementación
Proceso unificado de desarrollo: ciclo
• Las agrupaciones de fases se denominan ciclo.
• Cada ciclo concluye con una versión del producto.
• Discusión: 
¿es lo mismo un ciclo UP que un ciclo del modelo en espiral?
Rubén Fuentes Fernández Ingeniería del Software 59
Proceso unificado de desarrollo: evaluación
• Ventajas
– Modelo de proceso racional
– Tecnologías de componentes
• Inconvenientes
– Muy ligado al método
Rubén Fuentes Fernández Ingeniería del Software 60
DESARROLLO ÁGIL
Rubén Fuentes Fernández Ingeniería del Software 61
Modelos de proceso ágil: supuestos
• Los procesos ágiles parten de 3 supuestos clave:
– Es difícil predecir qué requisitos software persistirán y cuáles 
cambiarán.
• También es difícil predecir las prioridades del cliente.
– El diseño y el desarrollo de software están intercalados.
• Por tanto, se deben realizar de manera conjunta, de forma que el diseño 
se pruebe según se crea.
• Es difícil predecir cuanto diseño es necesario antes de construir el código 
que lo implementa.
– El análisis, el diseño y la construcción no son predecibles desde el 
punto de vista de la planificación, lo que sería deseable.
Ingeniería del Software 62Rubén Fuentes Fernández
Modelos de proceso ágil: características
• Un proceso ágil tiene 3 características clave:
– Es adaptable de forma incremental.
– Necesita retroalimentación del cliente.
– Se basa en la entrega continua de incrementos.
• Teóricamente, la agilidad se puede aplicar a cualquier proceso 
de software.
– En cualquier caso, surgen modelos de proceso propios del desarrollo 
ágil.
Ingeniería del Software 63Rubén Fuentes Fernández
Rubén Fuentes Fernández Ingeniería del Software 64
eXtreme Programming
• El eXtreme Programming (XP) es un modelo de proceso 
propuesto por K. Beck:
“Un modo ligero, eficiente, de bajo riesgo, flexible, predecible, 
científico y divertido de producir software”
• Características:
– Alta visibilidad debido a ciclos muy cortos
– Planificación incremental
– Se adapta a cambios de negocio
eXtreme Programming: claves
• Basado en pruebas automatizadas escritas por 
desarrolladores y clientes
• Alta comunicación
• Diseño evolutivo
• Colaboración entre programadores
• Busca equilibrio entre las necesidades a corto plazo de los 
programadores y las de largo plazo del proyecto
Rubén Fuentes Fernández Ingeniería del Software 65
eXtreme Programming: estructura
• La estructura del proceso, si se puede considerar que la hay, 
es un poco atípica
Rubén Fuentes Fernández Ingeniería del Software 66
Actividades en XP
Prueba Evaluación DiseñoCodificación
Rubén Fuentes Fernández Ingeniería del Software 67
eXtreme Programming: prácticas
• Las 4 actividades de XP están soportadas por 12 prácticas:
– El juego de planificación
– Pequeñas entregas
– Metáfora
– Diseño simple
– Prueba
– Refactorización
– Programación en pareja
– Propiedad colectiva
– Integración continua
– Semana de cuarenta horas
– Cliente en el lugar de desarrollo
– Codificación estándar
Rubén Fuentes Fernández Ingeniería del Software 68
eXtreme Programming: evaluación
• Ventajas:
– Bueno para especificaciones cambiantes
– Fundamentación práctica
• Inconvenientes:
– Poco probado
– Poco compatible con especificaciones/diseños totales
– Solo funciona con equipos pequeños (hasta 10 personas)
• Esta evaluación es extensible al resto de procesos ágiles.
SCRUM
• SCRUM (melé) es un modelo de proceso desarrollado por J. 
Sutherland a principios de los 90, y revisado posteriormente 
por Schwaber y Beedle.
• Se basa en:
– Equipos de trabajo organizados para maximizar la comunicación y 
minimizar los gastos
– Proceso adaptable a cambios técnicos y de negocio para asegurar el 
mejor producto
– Incrementos frecuentes de software
– Trabajo y equipo divididos en paquetes de bajo acoplamiento
– Capacidad de construir un producto cuando se requiera
Ingeniería del Software 69Rubén Fuentes Fernández
SCRUM: actividades
• El proceso incluye actividades clásicas:
– Requisitos
– Análisis
– Diseño
– Evolución
– Entrega
• Dentro de cada actividad las tareas se ajustan a patrones de 
proceso.
– Un patrón de proceso es un conjunto de tareas.
• En general, SCRUM se basa en cuatro patrones de proceso 
para organizar las actividades.
Rubén Fuentes Fernández Ingeniería del Software 70
SCRUM: patrones de proceso
Ingeniería del Software 71Rubén Fuentes Fernández
SCRUM: patrones de proceso (1/2)
• Product backlog (trabajo acumulado)
– Lista de requisitos priorizados que puede actualizarse en cualquier 
momento, salvo en el propio sprint
• Sprint
– Trabajo requerido para satisfacer un requisito definido
– 30 días normalmente
Ingeniería del Software 72Rubén Fuentes Fernández
SCRUM: patrones de proceso (2/2)
• SCRUM
– Reunión diaria corta (15”) centrada en:
• ¿Qué hiciste desde la última reunión?
• ¿Tienes algún obstáculo?
• ¿Qué harás antes de la próxima reunión?
– Un maestro de SCRUM preside la reunión y evalúa las respuestas de 
cada persona.
• Demostración
– Se entrega el incremento al cliente.
Ingeniería del Software 73Rubén Fuentes Fernández
TRANSFORMACIONES FORMALES
Modelos de proceso que sí son…
Rubén Fuentes Fernández Ingeniería del Software 74
Desarrollo formal de sistemas
• Se basa en la transformación de una especificación formal a lo 
largo de varias representaciones hasta llegar a un programa 
ejecutable.
• Las transformaciones preservan la corrección.
– Permiten comprobar fácilmente que el programa es conforme a la 
especificación.
Rubén Fuentes Fernández Ingeniería del Software 75
Rubén Fuentes Fernández Ingeniería del Software 76
Desarrollo formal de sistemas
• Transformación formal
T1 T2 T3 T4
Especificación 
formal R1 R2 R3
Programa 
ejecutable
Pruebas de corrección de la transformación
P1 P2 P3 P4
Transformaciones
Desarrollo formal de sistemas: evaluación
• Problemas
– Hace falta una formación especializada para aplicar la técnica.
– Muchos aspectos de los sistemas reales son difíciles de especificar 
formalmente.
• Interfaz de usuario
• Requisitos no funcionales
• Aplicabilidad
– Sistemas críticos en los que la seguridad y fiabilidad deben poder 
asegurarse antes de poner el sistema en operación.
Rubén Fuentes Fernández Ingeniería del Software 77
DESARROLLO BASADO EN 
REUTILIZACIÓN
Modelos de proceso que sí son…
Rubén Fuentes Fernández Ingeniería del Software 78
Componentes
• Una interfaz es una colección de operaciones que son 
utilizadas para especificar un servicio de una clase o de un 
componente.
• Un componente es una parte física y reemplazable de un 
sistema que se ajusta a, y proporciona la realización de, un 
conjunto de interfaces.
• Un sistema software basado en componentes se modela y 
construye en base a componentes software interconectados a 
través de interfaces bien definidas.
Ingeniería del Software 79Rubén Fuentes Fernández
Rubén Fuentes Fernández Ingeniería del Software 80
Modelos evolutivos  ensamblaje de 
componentes
Planificación Análisis de
riesgos
Evaluación
por parte del cliente 
Ingeniería, 
construcción y entrega
Comunicación 
con el cliente
Identificar
componentes
candidatos
Buscar 
componentes
en biblioteca
Extraer
componentes
disponibles
Construir
componentes
que falten
Añadir
componentes
a biblioteca
Construir
iteración N
del sistema
Es un ejemplo de este tipo de modelos
Rubén Fuentes Fernández Ingeniería del Software 81
Modelos evolutivos  ensamblaje de 
componentes
• El modelo de ensamblaje de componentes es un espiral de 
Boston adaptado al uso de componentes software 
reutilizables.
• Ventajas
– Componentes
• Inconvenientes
– Tamaño biblioteca
• Cómo encontrar los componentes adecuados
• Realmente todos los procesos vistos pueden hacer uso de 
componentes.
SELECCIÓN DE PROCESOS
Rubén Fuentes Fernández Ingeniería del Software 82
Rubén Fuentes Fernández
Visibilidad de Procesos
• Los sistemas de software son intangibles por lo que los 
administradores necesitan documentación para identificar el 
progreso en el desarrollo.
• Esto puede causar problemas:
– El tiempo planeado para entrega de resultados puede no coincidir con 
el tiempo necesario para completar una actividad.
– La necesidad
de producir documentos restringe la iteración entre 
procesos.
– El tiempo para revisar y aprobar documentos es significativo.
• El modelo de cascada es aún el modelo basado en resultados 
más utilizado.
Ingeniería del Software 83
Rubén Fuentes Fernández
Visibilidad de Procesos
Modelo de Proceso Visibilidad del Proceso
Modelo de Cascada Buena visibilidad, cada actividad 
produce un documento o 
resultado
Desarrollo Evolutivo Visibilidad pobre, muy caro al 
producir documentos en cada 
iteración
Modelos Formales Buena visibilidad, en cada fase 
deben producirse documentos
Desarrollo orientado a la 
reutilización
Visibilidad moderada. Importante 
contar con documentación de 
componentes reutilizables
Modelo de Espiral Buena visibilidad, cada segmento 
y cada anillo del espiral debe 
producir un documento
Ingeniería del Software 84
¿Qué modelo utilizar?
• Para sistemas bien conocidos se puede utilizar el modelo en 
cascada.
– La fase de análisis de riesgos debe ser relativamente fácil.
• Con requisitos estables y sistemas de seguridad críticos, se 
recomienda utilizar modelos formales.
• Con especificaciones incompletas, el modelo de prototipado
ayuda a identificarlos y va produciendo un sistema funcional.
• Pueden utilizarse modelos híbridos en distintas partes del 
desarrollo.
Rubén Fuentes Fernández Ingeniería del Software 85
MADUREZ DEL PROCESO 
SOFTWARE DE UNA ORGANIZACIÓN
Rubén Fuentes Fernández Ingeniería del Software 86
Rubén Fuentes Fernández Ingeniería del Software 87
Madurez del proceso software
• La madurez del proceso software es la corrección en la 
aplicación de un proceso de software.
• El Instituto de Ingeniería del Software (SEI) ha desarrollado el 
Modelo de Madurez del Software (SW CMM) para identificar 
este nivel.
• El CMM identifica una serie de Áreas Clave del Proceso (ACPs).
– Una ACP es básicamente una actividad de IS.
– Las ACPs han de aparecer en la aplicación del proceso.
• Dependiendo de la ejecución del proceso, las ACPs se 
encuentran en distintos niveles.
• El nivel de las ACPs determina el nivel de madurez de la 
organización.
Rubén Fuentes Fernández Ingeniería del Software 88
CMM
• Áreas clave del proceso P r o ce s s c h a n g e m a n a g em e n t
T e c h n o l o g y c h a n g e m a n a g em e n t
D e f e c t p r e v e n t io n
S o f tw a re q u a l it y m a n a g em e n t
Q u a nt it a t iv e p r o ce s s m a n a g em e n t
P e e r r e v ie w s
I n t e r g ro u p c o o r d in at io n
S o f tw a r e p r o d u ct e n g i n e e r i n g
I n t e g r a t e d s o f tw ar e m a n a g e m e n t
T r a i n i n g p r o g r a m m e
O r g a n i z a ti o n p r oc e s s d e f in it io n
O r g a n i z a ti o n p r oc e s s f o c u s
S o f tw a r e c o n f i g u ra t io n m a n a g em e n t
S o f tw a r e q u a l it y a s s u r a n c e
S o f tw a r e s u b c o n tr a c t m a n a g em e n t
S o f tw a r e p ro je c t tr a c k i n g a n d o v e r s ig h t
S o f tw a r e p ro je c t p l a n n in g
R e q u ir e m e n ts m a n a g e m e n t
I n it i a l
R e p e a t a b l e
D e f i n e d
M a n a g ed
O p t i m i zi n g
CMM: niveles (1/3)
• Nivel 1: Inicial
– El proceso de software se caracteriza según el caso.
– Se definen poco los procesos.
– El éxito depende del esfuerzo individual.
• Nivel 2: Repetible
– Nivel 1
– Se incluye seguimiento del coste, de la planificación y de la funcionalidad.
– Se repiten técnicas de proyectos anteriores con buenos resultados.
– Las ACPs son:
• Planificación del proyecto de software
• Seguimiento y supervisión del proyecto de software
• Gestión de requisitos
• Gestión de la configuración software (GCS)
• Garantía de calidad del software (SQA)
• Gestión de la subcontratación
Rubén Fuentes Fernández Ingeniería del Software 89
Rubén Fuentes Fernández Ingeniería del Software 90
CMM: niveles (2/3)
• Nivel 3: Definido
– Nivel 2
– Las actividades se documentan, estandarizan e integran en un proceso 
a nivel organización.
– Existe un proceso documentado.
– Las ACPs son:
• Definición y enfoque del proceso de la organización
• Programa de formación
• Revisiones periódicas
• Coordinación entre grupos
• Ingeniería de productos software
• Gestión de integración del software
Rubén Fuentes Fernández Ingeniería del Software 91
CMM: niveles (3/3)
• Nivel 4: Gestionado
– Nivel 3
– Se recopilan medidas del proceso del software y de la calidad del 
producto.
– Estas medidas sirven para gestionar el proceso.
– Las ACPs son:
• Gestión de la calidad del software
• Gestión cuantitativa del software
• Nivel 5: Optimización
– Nivel 4
– En base a la experiencia y métricas se optimiza el proceso.
– Las ACPs son:
• Gestión de cambios del proceso
• Gestión de cambios de tecnología
• Prevención de defectos
Rubén Fuentes Fernández Ingeniería del Software 92
CMM: niveles
• Un nivel razonable es el definido (nivel 3).
• Un nivel deseable es optimización (nivel 5).
• Con independencia del CMM, ACPs mínimas:
– Planificación del proyecto
– Seguimiento y supervisión del proyecto
– Gestión de requisitos
– GCS
– SQA
– Definición del proceso
– Revisiones periódicas
– Coordinación entre grupos
CMM
• Datos Agosto 2000
– Inicial  34,9%
– Repetible 38,2%
– Definido 18,5%
– Gestionado 5,5%
– Optimizado 2,9%
• Resultados de 901 empresas desde 1996
Rubén Fuentes Fernández Ingeniería del Software 93
CONCLUSIONES
Rubén Fuentes Fernández Ingeniería del Software 94
Rubén Fuentes Fernández Ingeniería del Software 95
Conclusiones
• La IS es una tecnología multicapa.
• La IS es una ingeniería.
• El proceso del software es un conjunto estructurado de 
actividades requeridas para desarrollar un sistema de 
software.
– Varían dependiendo de la organización y el tipo de sistema a 
desarrollar.
• El proceso debe estar explícitamente modelado si va a ser 
bien administrado.
• En IS hay tres fases genéricas.
– Estas tres fases están presentes en todos los modelos de proceso.
Glosario
• ACP = Área Clave de Proceso
• CASE = Computer‐Aided Software Engineering
• GCS = Gestión de Configuración Software
• IS = Ingeniería del Software
• RUP = Rational Unified Process
• SEI = Software Engineering Institute
• SQA = Software Quality Assurance
• SW CMM = Software Capability Maturity Model
• UML = Unified Modelling Language
• UP = Unified Process
• XP = eXtreme Programming
Ingeniería del Software 96Rubén Fuentes Fernández
Referencias
• R. Pressman: Ingeniería del Software. Un enfoque práctico, 7ª 
edición. McGraw‐Hill, 2010.
– Modelos de proceso  pp. 17‐46
– SW CMM  pp. 21‐25
• I. Sommerville: Ingeniería del Software, 7ª edición. Addison 
Wesley, 2007.
– Modelos de proceso  pp. 42‐67
– SW CMM  pp. 557‐575
• Proceso unificado de Rational
– Jacobson, Krutchen
• SW CMM
– http://www.sei.cmu.edu/cmm/obtain.cmm.html
Ingeniería del Software 97Rubén Fuentes Fernández
Temario/Tema 03 - Ingeniería de Requisitos.pdf
Tema 03 –
Ingeniería de requisitos
Ingeniería del Software
Rubén Fuentes Fernández
Dep. Ingeniería del Software e Inteligencia Artificial
Facultad de Informática
Universidad Complutense Madrid
Trabajando con Antonio Navarro, Juan Pavón y Pablo Gervás
Contenidos
• Introducción
• Tipología de requisitos
• El proceso de Ingeniería de Requisitos
– Casos de uso
– FAST
• IEEE Std. 830‐1998
Rubén Fuentes Fernández Ingeniería del Software 2
Objetivos
• Entender las dificultades de capturar las necesidades del 
cliente
• Determinar qué aspectos clave hay que capturar en los 
requisitos
• Proporcionar pautas para el proceso de captura
• Examinar guías de documentación de requisitos
Ingeniería del Software 3Rubén Fuentes Fernández
INTRODUCCIÓN
Rubén Fuentes Fernández Ingeniería del Software 4
El contexto del sistema
• Entender la naturaleza de un problema es por lo general algo 
difícil.
– Implica una interacción entre
el grupo desarrollador y el contratante.
– Estos grupos tienen diferentes perspectivas, y una idea imprecisa de 
qué información es relevante y cómo transmitirla.
• Un interesado (stakeholder) es cualquier persona que puede 
tener influencia directa o indirecta sobre los requisitos:
– Clientes  quien contrata o representa a la organización
– Usuarios  quien utilizará el sistema
– Otros  ej. expertos externos
Rubén Fuentes Fernández Ingeniería del Software 5
Dificultades en la captura de requisitos
• Un sistema tiene muchos usuarios y ninguno tiene una visión de 
conjunto.
• Distintos interesados pueden tener distintos requisitos.
• Influencia de factores políticos.
• Entorno de negocio dinámico del sistema informático. 
• Los clientes no saben qué partes del trabajo pueden transformarse 
en software.
• Los interesados pueden desconocer lo que esperan del sistema 
informático.
• Los interesados no saben cómo hacer más eficiente la operación en 
su conjunto.
• Los interesados no saben detallar lo que saben de forma precisa.
• Es posible que los ingenieros de requisitos no conozcan el dominio 
del sistema, familiar para los interesados.
Rubén Fuentes Fernández Ingeniería del Software 6
Requisitos
• Los requisitos son una descripción de los servicios y 
restricciones del sistema a construir.
• La Ingeniería de Requisitos es el proceso que permite 
identificar dichos requisitos.
– Sistemáticamente
– De una forma apropiada para el proceso de desarrollo
• Discusión con el cliente
• Punto de partida del resto de fases
Ingeniería del Software 7Rubén Fuentes Fernández
Tipos de requisitos
• Requisitos de usuario
– Describen los servicios que el sistema debe proporcionar y las 
restricciones bajo las que debe operar.
– Ej. el sistema debe hacer préstamos
• Requisitos de sistema
– Determinan los servicios del sistema y las restricciones en detalle.
– Sirven como contrato.
– Pueden ser funcionales, no funcionales y de dominio.
– Ej. función préstamo; entrada: código socio, código ejemplar; salida: 
fecha devolución; ...
• Son los mismos, pero a distinto nivel de detalle.
– Ambos se describen con lenguaje natural, diagramas y otros recursos.
Rubén Fuentes Fernández Ingeniería del Software 8
Requisitos funcionales vs no funcionales
• Los requisitos funcionales describen:
– Los servicios que proporciona el sistema (funciones).
– La respuesta del sistema ante determinadas entradas.
– El comportamiento del sistema en situaciones particulares.
– En algunos casos, también determinan lo que no debería hacer el 
sistema.
• Los requisitos no funcionales describen:
– Restricciones de los servicios o funciones que ofrece el sistema.
Rubén Fuentes Fernández Ingeniería del Software 9
Requisitos – función préstamo
• Requisitos funcionales
– prioridad: alta – estabilidad: alta
– descripción: presta un ejemplar a un socio de la biblioteca
– entrada: código socio, código ejemplar – salida: fecha devolución
– origen: operador, consola – destino: sistema
– necesita: base de datos de socios y ejemplares
– acción: prestar ejemplar
– precondición: usuario y ejemplar dados de alta, usuario sin préstamos pendientes, 
usuario sin límite de préstamos alcanzado
– postcondición: ejemplar prestado al usuario
– efectos laterales: retirada del carné durante 7 días si el usuario tiene préstamos 
pendientes de devolución
• Requisitos no funcionales
– El tiempo de proceso de una petición será siempre inferior a 1 segundo.
– El sistema de biblioteca debe ser capaz de atender simultáneamente a todas las 
bibliotecas de la universidad, estimadas en picos de 50 peticiones/minuto
Rubén Fuentes Fernández Ingeniería del Software 10
Requisitos no funcionales: tipos
• Requisitos del producto
– Especifican el comportamiento del producto.
– Ej. prestaciones, memoria o tasa de fallos
• Requisitos organizativos
– Se derivan de las políticas y procedimientos de las organizaciones de 
los clientes y desarrolladores.
– Ej. estándares de proceso o lenguajes de programación
• Requisitos externos
– Se derivan de factores externos al sistema y al proceso de desarrollo.
– Ej. requisitos legislativos o éticos
Rubén Fuentes Fernández Ingeniería del Software 11
Requisitos del dominio
• Se derivan del dominio de la aplicación y reflejan 
características de dicho dominio.
– Pueden ser funcionales o no funcionales.
– Ej. el sistema de biblioteca de la universidad debe ser capaz de 
exportar datos mediante el Lenguaje de Intercomunicación de 
Bibliotecas de España (LIBE)
– Ej. el sistema de biblioteca no podrá acceder a bibliotecas con material 
censurado
Rubén Fuentes Fernández Ingeniería del Software 12
PROCESO
Rubén Fuentes Fernández Ingeniería del Software 13
El proceso de Ingeniería de Requisitos
• La Ingeniería de Requisitos debe centrarse en lo que hay que 
hacer, no en el cómo.
• Para obtener los requisitos es necesario realizar varias tareas.
• También hay que tener en cuenta que los requisitos 
evolucionan.
– Es necesario gestionar su cambio.
• Las actividades anteriores se organizan siguiendo modelos de 
proceso.
– De la misma manera que el proceso de desarrollo de software global.
– Aunque existen variantes de este modelo, vienen a cubrir las mismas 
actividades.
Ingeniería del Software 14Rubén Fuentes Fernández
Proceso estilo cascada
Ingeniería del Software 15
Estudio de 
viabilidad
Obtención y análisis 
de requisitos
Especificación de
requisitos
Validación de
requisitos
Informe de
viabilidad
Requisitos 
Requisitos 
especificados Requisitos validados
Rubén Fuentes Fernández
Proceso estilo evolutivo
Ingeniería del Software 16
Pese a las figuras, 
se debe usar 
“requisitos” en 
vez de 
“requerimientos”.
Rubén Fuentes Fernández
Fases: estudio de viabilidad
• Se trata de una estimación sobre si se puede resolver el 
problema cumpliendo las restricciones establecidas:
– Usando las tecnologías software y hardware disponibles.
– Integrándose en el entorno tecnológico y organizativo.
– Cumpliendo las restricciones económicas del desarrollo.
– Creando un sistema rentable en cuanto a operación y mantenimiento.
• Se origina tras una especificación preliminar de los requisitos.
• El estudio debe responder a las preguntas:
– ¿Contribuye el sistema a los objetivos generales de la organización?
– ¿Se puede implementar el sistema utilizando la tecnología actual y 
dentro de las restricciones de coste y tiempo?
– ¿Puede integrarse el sistema con otros sistemas existentes en la 
organización?
Rubén Fuentes Fernández Ingeniería del Software 17
Fases: análisis de requisitos
• Proceso en el que se interactúa con los interesados para 
determinar:
– El dominio de la aplicación
– Los requisitos funcionales
– Los requisitos no funcionales
Rubén Fuentes Fernández Ingeniería del Software 18
Análisis de requisitos: proceso
Ingeniería del Software 19
1º
2º 3º
4º
Rubén Fuentes Fernández
Fases: especificación de requisitos
• Se fija una descripción detallada y precisa de los requisitos.
– Debe servir de base para un contrato entre los clientes y los 
desarrolladores de software.
• En función del ciclo, los requisitos serán preliminares del 
negocio, de usuario o de sistema.
– Dentro de un proceso evolutivo o incremental
• El objetivo es realizar la Especificación de Requisitos Software 
(SRS).
Ingeniería del Software 20Rubén Fuentes Fernández
Lenguajes de especificación de requisitos
• Pueden utilizarse distintos lenguajes para especificar los 
requisitos:
– Lenguaje natural
– Lenguaje natural estructurado
– Lenguaje de descripción de diseño
– Lenguaje de especificación de requisitos
– Notaciones gráficas
– Especificaciones matemáticas
– Especificaciones lógicas
Rubén Fuentes Fernández Ingeniería del Software 21
Fases: validación de requisitos
• Se encarga de comprobar si los requisitos se ajustan a los 
deseos
y necesidades de los interesados.
• Si la validación es inadecuada, se propagarán errores al diseño 
e implementación.
• Evidentemente, tiene una fuerte repercusión sobre el coste.
Ingeniería del Software 22Rubén Fuentes Fernández
Verificaciones en la validación de requisitos 
(1/2)
• Corrección
– Cada requisito identificado es un requisito del sistema.
• No ambigüedad
– Cada requisito identificado tiene una única interpretación.
• Realismo
– Comprobar que se pueden implementar los requisitos con las tecnologías 
y plantilla disponibles.
• Completitud
– La SRS debe incluir:
• Todos los requisitos relativos a funcionalidad, prestaciones, restricciones de 
diseño, atributos o interfaces externas.
• Definición de las respuestas del sistema a todos los tipos posibles de datos de 
entrada en todas las posibles situaciones.
• Todas las etiquetas y referencias a todas las figuras, tablas y diagramas en la 
SRS, así como definiciones de todos los términos y unidades de medida.
Ingeniería del Software 23Rubén Fuentes Fernández
Verificaciones en la validación de requisitos 
(2/2)
• Consistencia
– Consistencia interna con todos los requisitos en todos los documentos (ej. 
requisitos de usuario vs requisitos de sistema).
• Priorizada
– La SRS debe priorizar la importancia y/o la estabilidad de cada requisito mediante 
un identificador de importancia y/o estabilidad para cada requisito.
• Verificable
– Cada requisito identificado es verificable.
• Es decir, se puede comprobar que el sistema implementa el requisito.
• Modificable
– La estructura y estilo permiten cambios en los requisitos de forma fácil, completa y 
consistente manteniendo la estructura y estilo.
• Trazable
– El origen de cada requisito está claro.
– Facilita la referencia de cada requisito en desarrollos futuros o en mejoras de la 
documentación.
Ingeniería del Software 24Rubén Fuentes Fernández
Técnicas de validación
• Hay distintas técnicas para validar los requisitos, que pueden 
utilizarse conjunta o individualmente:
– Revisión de requisitos
• Análisis sistemático de los requisitos por parte de un equipo de revisores.
– Prototipado
• Creación de un modelo ejecutable del sistema.
– Generación de casos de prueba
• Si no se puede diseñar un caso de prueba para un requisito, 
probablemente el requisito sea problemático.
– Análisis automático de la consistencia
• Supuesto que se haya utilizado una herramienta formal de especificación 
de requisitos.
Ingeniería del Software 25Rubén Fuentes Fernández
Gestión de requisitos software
• Los requisitos pueden cambiar y evolucionar.
– Puede haber requisitos variables en función del usuario.
– El cliente no suele ser el usuario.
– El producto y/o el entorno evolucionan.
• La gestión de requisitos es el proceso de entender y controlar 
los cambios en los requisitos del sistema.
– Tiene en cuenta aspectos técnicos no contemplados por la Gestión de 
la Configuración Software (GCS).
Ingeniería del Software 26Rubén Fuentes Fernández
Objetivos de la gestión de requisitos software
• En la gestión de requisitos debemos ser capaces de:
– Identificar los requisitos
– Tener un proceso de gestión del cambio
– Disponer de políticas de traza
– Disponer de soporte CASE
Ingeniería del Software 27Rubén Fuentes Fernández
Gestión de requisitos software
• La identificación de cada requisito se supone realizada cuando 
se dispone de una SRS.
• El proceso de gestión de cambio es común al de cualquier 
Elemento de Configuración Software (ECS).
• Las políticas de traza deben llevar cuenta de diversa 
información de traza:
– De origen  liga el requisito al interesado
– De requisitos  determina las dependencias entre requisitos
– De diseño  liga los requisitos a los módulos de diseño
Ingeniería del Software 28Rubén Fuentes Fernández
Matriz de traza
• La información de traza de requisitos puede representarse 
mediante una matriz de traza.
Ingeniería del Software 29
D: depende de R: relacionado con
Rubén Fuentes Fernández
Tipología de requisitos según su evolución
• Estables
– Se derivan de la actividad principal del sistema y están directamente 
relacionados con el dominio.
• Volátiles
– Probablemente cambiarán durante el desarrollo del sistema o después 
de su entrega.
– Se clasifican en:
• Mutables  Cambian debido a cambios en el entorno en el que la 
organización opera.
• Emergentes  Aparecen durante el desarrollo del sistema por el mayor 
entendimiento por parte del cliente.
• De consecuencia  Aparecen por la introducción del sistema.
• De compatibilidad  Dependen de los procesos de negocio de la 
organización.
Rubén Fuentes Fernández Ingeniería del Software 30
Herramientas CASE
• Las herramientas CASE facilitan:
– El almacenamiento de requisitos
– La gestión del cambio
– La gestión de la traza
• Pueden ser herramientas específicas o gestionar el cambio de 
la SRS como el de cualquier otro ECS.
Ingeniería del Software 31Rubén Fuentes Fernández
CASOS DE USO
Técnicas de especificación de requisitos
Rubén Fuentes Fernández Ingeniería del Software 32
Modelo de casos de uso
• Visión del sistema tal como se muestra a sus usuarios 
externos.
– Lo desarrollan tanto los analistas como los expertos del dominio (los 
interesados).
• Para entenderlo mejor se puede fragmentar en distintos 
puntos de vista y con diferentes propósitos.
• Representa el acuerdo alcanzado entre clientes y 
desarrolladores.
– Sirve como entrada al análisis, diseño y pruebas.
Rubén Fuentes Fernández Ingeniería del Software 33
Casos de uso
• Un caso de uso describe una forma en que los actores usan el 
sistema.
– Es un fragmento de funcionalidad que el sistema ofrece para aportar 
un resultado de valor para sus actores.
– Es una transacción (caso de uso) que tiene significado para los 
usuarios (actores).
• Un actor es cada tipo de usuario o sistema externo que 
interactúa con el sistema.
– Terceros fuera del sistema que colaboran con el sistema.
Rubén Fuentes Fernández Ingeniería del Software 34
Especificación del modelo de casos de uso
• El estándar de UML [OMG, 2010] especifica estos modelos 
con:
– Diagramas de casos de uso
– Descripción de los casos de uso
• Mediante plantillas de texto
• Acompañados de diagramas de interacción
Rubén Fuentes Fernández Ingeniería del Software 35
Diagrama de casos de uso: entidades
• Caso de uso
– Secuencia de acciones, incluyendo variantes, 
que puede realizar el sistema interaccionando 
con los actores del sistema
• Actor
– Un conjunto coherente de roles que juegan los                                   
usuarios cuando interaccionan con los casos de 
uso
• Límite del sistema
– Representa el límite entre el sistema físico y 
los actores que interaccionan con el sistema
Rubén Fuentes Fernández Ingeniería del Software 36
nombre de 
caso de uso
nombre de actor
Diagrama de casos de uso: relaciones
• Asociación
– La participación de un actor en un caso de uso
– La instancia de un actor se comunica con instancias                                     
de un caso de uso
• Generalización
– Relación taxonómica entre un caso de uso más general 
y otro más específico
• Dependencia
– <<extend>> el comportamiento de un caso de uso
origen extiende el de un caso de uso destino
– <<include>> el comportamiento de un caso de uso
origen incluye el de un caso de uso destino
Rubén Fuentes Fernández Ingeniería del Software 37
<<extend>>
<<include>>
Ejemplo: asociaciones de dependencia y 
generalización
Rubén Fuentes Fernández Ingeniería del Software 38
Proporcionar Datos 
Cliente
Pedir Producto Realizar Pago
Pago con tarjeta de 
crédito
Pago en metálico
Solicitar catálogo Realizar pedido
<<include>>
<<include>>
<<include>>
<<extend>>
el vendedor solicita
el catálogo
Adaptado de Fig. 3-54, UML Notation Guide
Ejemplo: límite del sistema
Rubén Fuentes Fernández
Ingeniería del Software 39
Customer
Supervisor
SalespersonPlace
Establish
credit
Check
Telephone Catalog
Fill orders
Shipping Clerk
status
order
Rubén Fuentes Fernández Ingeniería del Software 40
 
CASO DE 
USO #1 
ArranqueSistema 
Objetivo en contexto Se encarga de crear los objetos que componen el sistema e 
inicializarlos adecuadamente, leyendo archivos de 
configuración y cargando los casos de una base de datos 
Entradas 
Precondiciones Los archivos de configuración deben existir y ser válidos 
Debe ser posible establecer la conexión con la base de 
datos, y en ésta se han definido los esquemas adecuados 
Salidas 
Postcondición si éxito Es posible empezar a interactuar con el sistema 
Postcondición si fallo El sistema no se ha podido inicializar adecuadamente y la 
aplicación acaba 
Actores El usuario y la base de datos 
Secuencia normal Paso Acción 
 1 Leer los archivos de configuración. Si error S-1 
 2 Construir la función de similitud 
 3 Construir el conector a la base de datos. Si error S-2 
 4 Construir la base de casos, a partir de la función de 
similitud y el conector a la base de datos. Si error S-3 
Secuencias alternativas Paso Acción 
 S-1 Error al leer los archivos de configuración. Se informa 
del error y termina la aplicación. 
 S-2 Error al establecer la conexión con la base de datos. Se 
informa del error y termina la aplicación. 
 S-3 Error al leer los casos de la base de datos. Se cierra la 
base de datos, se informa del error y termina la 
aplicación. 
 
¿Hay algún 
problema en 
esta 
descripción?
Flujo de sucesos
• El flujo de sucesos es una especificación textual de la 
secuencia de acciones que el sistema puede llevar a cabo 
interactuando con sus actores.
– Incluye las alternativas dentro de la secuencia.
• Estas secuencias de acciones deben poder ser modificadas, 
revisadas, diseñadas, implementadas y probadas como un 
conjunto significativo.
– Pueden ser descritas como una sección del manual del usuario.
Rubén Fuentes Fernández Ingeniería del Software 41
Prototipo de interfaz de usuario
• Los casos de uso se centran en los aspectos funcionales.
– No son los únicos requisitos
• Los prototipos de interfaz de usuario ayudan a comprender y 
especificar las interacciones entre actores humanos y el 
sistema.
• Pueden usarse modelos de interfaz gráfica y esquemas de 
pantallas.
Ingeniería del Software 42Rubén Fuentes Fernández
Rubén Fuentes Fernández Ingeniería del Software 43
Requisitos especiales
• Aquellos que no pueden asociarse a ningún caso de uso
– Requisitos no funcionales
• Se capturan como lista de requisitos.
– De interfaz  interacción con un elemento externo que impone 
restricciones en formatos, tiempos u otros factores
– Legales (normativas)
– Físico  característica física que debe poseer un sistema (material, 
forma, tamaño, peso)
– Restricción de diseño  limita el diseño (extensibilidad, 
mantenibilidad, reutilización de sistemas heredados)
– Restricción de implementación  especifica o limita la codificación o 
construcción del sistema (estándares, lenguajes, políticas para la 
integridad de base de datos...)
Rubén Fuentes Fernández Ingeniería del Software 44
Glosario
• Define términos comunes importantes que los analistas 
utilizan para describir el sistema.
• Centrado en el sistema que se va a construir, en lugar de su 
contexto.
Rubén Fuentes Fernández Ingeniería del Software 45
Captura de los requisitos
1. Identificar actores
2. Identificar casos de uso
3. Describir brevemente cada caso de uso
4. Priorizar los casos de uso 
5. Detallar los caso de uso 
6. Prototipar la interfaz de usuario 
7. Identificar los requisitos adicionales
8. Describir y estructurar el modelo de casos de uso completo
– Incluye la elaboración del glosario
• El proceso no es necesariamente secuencial.
Rubén Fuentes Fernández Ingeniería del Software 46
Cómo identificar casos de uso
• A partir de los actores
– Identificar los actores relacionados con el sistema o la organización.
– Para cada actor, identificar los procesos que inicia o en los que 
participa.
• A partir de los eventos
– Identificar los eventos externos a los que puede responder el sistema.
– Relacionar los eventos con actores y casos de uso.
• Criterios para identificar los actores relevantes:
– Al menos un usuario que pueda representar al actor candidato.
– Coincidencia mínima entre distintos actores.
Rubén Fuentes Fernández Ingeniería del Software 47
Pautas de elaboración
• Asegurarse que cada caso de uso describe una parte 
significativa del funcionamiento del sistema.
• Evitar un número excesivo de casos de uso.
– Un caso de uso no es un paso, operación o actividad individual en un 
proceso.
– Un caso de uso describe un proceso completo que incluye varios 
pasos.
• Los casos de uso tienen que ser entendibles tanto por 
desarrolladores como por expertos del dominio.
– Es una descripción de alto nivel del sistema.
– Evitar conceptos de diseño.
Rubén Fuentes Fernández Ingeniería del Software 48
Cuándo definir un modelo de casos de uso
• Para identificar los requisitos funcionales del sistema
– y para identificar escenarios de prueba
• Normalmente en las primeras etapas de desarrollo
– En metodologías dirigidas por casos de uso:
• Empezar por los casos de uso y derivar de ellos los modelos estructural y 
de comportamiento
– y si no:
• Asegurarse que el modelo de casos de uso es consistente con los modelos 
estructural y de comportamiento
Rubén Fuentes Fernández Ingeniería del Software 49
FAST
Técnicas de especificación de requisitos
Rubén Fuentes Fernández Ingeniería del Software 50
Técnica de facilitación de la especificación de 
aplicaciones
• La técnica de facilitación de la especificación de aplicaciones 
(FAST) es un método específico para gestionar entrevistas.
– Múltiples versiones
• Está diseñado para poner a clientes y desarrolladores a 
trabajar en equipo.
Ingeniería del Software 51Rubén Fuentes Fernández
Proceso fundamental
• Se realiza una reunión previa con el cliente.
– Establecer el alcance y la descripción básica. 
• Se redacta una petición de producto breve.
– 1 o 2 páginas
• Se convoca una reunión FAST.
– Se elige un moderador.
– Se reparte la petición de producto a todos los asistentes.
– Se realiza la reunión.
Rubén Fuentes Fernández Ingeniería del Software 52
Reunión: entorno
• Se celebra en sitio neutral.
• Asisten clientes y desarrolladores
• Hay reglas claras para la preparación y la participación.
• Hay un orden del día.
– Suficientemente formal para que se cubra todo.
– Suficientemente informal para que haya flexibilidad.
• Hay un moderador.
– Cliente o desarrollador
• Hay un mecanismo de definición.
– Ej. pizarra, proyector o fichas.
• El objetivo es identificar el problema y especificar los requisitos 
básicos de la solución.
53Ingeniería del SoftwareRubén Fuentes Fernández
Deberes para la reunión
• Cada asistente tiene que traer preparadas a la reunión las 
siguientes listas:
– Objetos  elementos que forman parte del entorno del sistema, 
produce el sistema o utiliza el sistema
– Servicios
– Restricciones  coste, tamaño, reglas de negocio…
– Criterios de rendimiento
• Las listas no tienen que ser exhaustivas pero deben reflejar la 
visión que cada participante tiene del sistema.
54Ingeniería del SoftwareRubén Fuentes Fernández
Reunión: fases
• Primera fase  exposición
– Se exponen las listas para un área concreta.
– En este punto no se admiten críticas ni discusión.
– Se elabora una lista combinada.
– Cuando están las listas combinadas para todas las áreas, se acuerda una 
versión negociada de cada una.
• Segunda fase  elaboración
– Se separan los asistentes por equipos.
– Cada grupo se encarga de hacer una mini especificación de unas cuantas 
propuestas de la lista.
– Cada equipo presenta su mini especificación a