IISSI I:
Bloque I: Introducción y Requisitos
Adrián Romero Flores
Ingeniería del Software - Universidad de Sevilla
Parte I
Introducción a la Ingeniería del Software
1. Características del software
El software es intangible. Se desarrolla, no se fabrica. No se estropea, se queda obsoleto.
Tipos de software:
1
Evolución del coste del software: (de menor a mayor complejidad)
Hardware: Válvulas de vacío, Transistores, Circuitos integrados, Microprocesador (PC).
Software: Interfaces gráficas de usuario, Internet, La nube.
(ver imagen evolución del software/hardware.)
2. Problemas de la industria del software
Therac-25 (1985-1987): máquina de radioterapia que mató a seis pacientes por radiación
excesiva a causa de un error de programación en el sistema operativo.
Ariane 5 (1996): cohete espacial de 370 millones de dólares que explotó 40 segundos des-
pués de su lanzamiento debido a un problema de overflow de una variable por reutilización
de un código de un modelo anterior.
Efecto 2000 (1999): miles de programas han de ser revisados para evitar que consideren
el año 2000 como 1900 a causa del formato de almacenamiento del año en dos dígitos.
Airbus Military (2015): un A400-M se estrella durante un vuelo de pruebas a 2 kilómetros
del aeropuerto de Sevilla. A causa de errores humanos y del software encargado de regular
la potencia de los motores en función de las señales que le enviaba el piloto.
Los Chaos Reports intentan identificar los principales problemas del desarrollo del software.
Están realizados por la consultadora Standish Group y clasifica miles de proyectos reales como
éxito (finalizado dentro del plazo y presupuesto y cumpliendo todos los requisitos), con proble-
mas (finalizado pero fuera de plazo, fuera de presupuesto y sin cumplir todos los requisitos) o
fracaso (cancelado durante el desarrollo).
(ver estadísticas Chaos Reports)
2
3. La necesidad de la ingeniería del software
¿Qué es una ingeniería?
Actividades propias de los Ingenieros: conciben, proyectan, construyen y gestionan la explotación
eficiente de: obras públicas, máquinas, sistemas de control, redes de comunicaciones, centrales
energéticas. . .
Científicos realizan actividad sistemática para adquirir nuevos conocimientos.
Pilares de una ingeniería
Vocabulario: conjunto de términos que se usan en un campo concreto.
Tecnología: instrumentos, procedimientos o recursos usados en un campo.
Herramientas: conjunto de instrumentos para desempeñar un trabajo concreto.
Buenas prácticas: conjunto de acciones que dan buenos resultados en un campo.
Metodologías: conjunto de procedimientos bien definidos para obtener buenos resultados.
Origen de la ingeniería del software
En el Software Engineering Conference (SEC) de la OTAN, Garmisch, Alemania (1968). Enfoque
ingenieril como la solución a la crisis del software. El término se atribuye a Fritz Bauer. Se definió
el concepto de ciclo de vida del software y se identificaron los principales problemas asociados
al software (Sobrecostes, retrasos, baja calidad, mantenimiento difícil).
Definición de ingeniería del software
Según el glosario de IEEE: la aplicación de un enfoque sistemático, disciplinado y cuantificable
para el desarrollo, operación y mantenimiento del software.
Según A. Davis: la aplicación inteligente de principios probados, técnicas, lenguajes y herramien-
tas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga
las necesidades de los usuarios.
Definición de proyecto
Es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.
Puede ser productivo, público, social, de vida, científico. . .
Un proyecto software es un esfuerzo temporal acometido para crear un único producto o servicio
software. Es realizado por personas. Debe ser limitado en tiempo y coste y debe ser planificado,
ejecutado y controlado.
Roles en un proyecto de software
Director de proyecto: responsable de la ejecución del proyecto con capacidad ejecutiva
para tomar decisiones sobre el mismo de acuerdo con el cliente.
Ingeniero de requisitos: también denominado analista. Responsable de interactuar con
clientes y usuarios para obtener sus necesidades y de desarrollar y gestionar los requisitos.
Equipo de desarrollo: conjunto de personas implicadas en el desarrollo del software.
Equipo de calidad: conjunto de personas responsables de la calidad de los productos ob-
tenidos, tanto documentación como software.
3
Cliente: responsable de la financiación del proyecto con capacidad ejecutiva para tomar
decisiones sobre el mismo.
Usuario: usuario potencial del software a desarrollar en el proyecto con una visión deta-
llada, aunque puede que parcial, del modelo de negocio.
Responsable TIC del cliente: responsable del entorno tecnológico del cliente, sobre el que
se debe integrar el sistema a desarrollar.
4. Normas y estándares
ISO/IEC/IEEE. Estándar relativo a los procesos del ciclo de vida del software:
Se aplica a la adquisición de sistemas de software, productos y servicios, al suministro, desarrollo,
operación, mantenimiento y eliminación de productos de software o componentes de cualquier
sistema, a sea que realice interna o externamente a una organización.
Se incluyen aquellos aspectos de la definición del sistema necesarios para proporcionar el con-
texto de los productos y servicios de software.
También proporciona procesos que pueden emplearse para definir, controlar y mejorar los pro-
cesos del ciclo de vida del software dentro de una organización o de un proyecto.
CMMI-DEV:
Modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación
de sistemas software.
Desarrollado por el Software Engineering Institute de la Universidad Carneige Mellon para el
Departamento de Defensa de EEUU.
Muchas administraciones públicas exigen un nivel mínimo de certificación CMMI para contratar.
Gracias al plan Avanza, España es el cuarto país en certificaciones CMMI.
4
5. Productos de la ingeniería del software
El conjunto de productos que deben desarrollarse y entregarse al cliente durante un proyecto se
denominan entregables.
Productos previos al comienzo: petición de propuestas, pliego de prescripciones técnicas, oferta,
contrato.
Deben dejar claro: las necesidades a satisfacer por el sistema, los entregables de requisitos, el
presupuesto y plazo de ejecución, restricciones técnicas, penalizaciones por retrasos.
Entregables habituales: plan de proyecto, informes de seguimiento, especificación de requisitos,
documento de diseño, plan de pruebas, código fuente, software ejecutable y manuales de usuario.
6. Mantenimiento del software
Una vez entregado se debe proporcionar un servicio de mantenimiento y gestión de incidencias.
Mantenimiento: se encarga de mejorar, adaptar o corregir el software en explotación. Su
coste es el más alto de todo el ciclo de vida.
Gestión de incidencias: restaurar cuanto antes la operativa normal del servicio minimizan-
do el impacto negativo en las operaciones de negocio. Detección, registro, categorización,
priorización, diagnóstico, escalado, resolución y cierre.
Tipos de mantenimiento:
Evolutivo (60 %): incorporar nuevos requisitos o cambios en los ya existentes.
Correctivo (17 %): corregir errores del producto software no detectados durante el desa-
rrollo.
Adaptativo (18 %): adaptar a cambios el entorno tecnológico.
Perfectivo (5 %): mejorar la calidad interna de los sistemas.
5
7. Calidad del software
Se encarga de asegurar un determinado nivel de calidad de software. Por calidad del software
se entiende:
Cumplir los requisitos establecidos explícitamente.
Cumplir con los estándares de desarrollo necesarios.
Tener las características implícitas que se espera de todo software desarrollado profesional-
mente.
Los costes de aseguramiento de la calidad se compensan con el ahorro en mantenimiento. El
equipo de SQA es responsable de:
Establecer el plan de SQA del proyecto.
Participar en la definición del plan de proyecto.
Auditar los productos del desarrollo.
Documentar e informar de las desviaciones o no conformidades que se vayan detectando
en las revisiones técnicas formales.
8. Gestión de la configuración
Se encarga de identificar, controlar e informar de los cambios en los productos del desarrollo de
software.
Dentro de sus actidades se identifican:
Determinar los productos bajo control de configuración.
Control de versiones.
Control de cambios.
Auditoria de la configuración.
Generación de informes del estado de la configuración.
Línea base (baseline): versión cerrada de algún elemento de configuración a partir de la cual es
necesario aplicar la política de control de cambios del proyecto antes de modificarlo.
CMS/CMDB: modelo lógico coherente de la infraestructura de la organización TI, típicamente
compuesto de varias Bases de Datos que operan como subsistemas físicos. Se usa para almacenar
información acerca de los elementos software bajo control de versiones.
6
Parte II
Ciclo de vida del Software
1. Concepto de ciclo de vida
El ciclo de vida es un marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, la operación y el mantenimiento de un producto software, abar-
cando la vida del sistema desde su definición hasta su retirada.
El ciclo de vida de un proyecto especifica el enfoque general del desarrollo, indicando los pro-
cesos, actividades y tareas que se van a realizar y en qué orden, y los productos que se van a
generar, los que se van a entregar al cliente y en qué orden se van a entregar.
2. Ciclo de vida clásico (en cascada)
Cada fase comienza cuando termina la anterior.
Asume que se conocen todos los requisitos.
Se tarda mucho en disponer del software.
Es mejor que no seguir ningún ciclo de vida.
Es el más fácil de planificar, es el ciclo ideal.
Cada fase finaliza con entregables.
Ventajas: tiene un lugar destacado en la IS, proporciona una plantilla para adecuar métodos, es
muy utilizado y es mejor que desarrollar sin guías.
Inconvenientes: su progresión secuencial o lineal no refleja la manera en que realmente se de-
sarrolla el software, es un modelo que adolece de rigidez, exige al usuario que exponga explíci-
tamente todos los requisitos al principio, se tarda mucho en pasar por todo el ciclo, es un modelo
monolítico, hasta llegar a las etapas finales del desarrollo no habrá una versión operativa del pro-
grama, lo que influye negativamente en el descubrimiento a tiempo de errores o incongruencias
en los requisitos, impone una estructura de gestión de proyecto al desarrollo del sistema y no
trata al software como un proceso de resolución de problemas.
3. Ciclos de vida evolutivos
Cuanto mayor es un proyecto, menor es la probabilidad de éxito (informes CHAOS). Obtener
todos los requisitos al comienzo de un proyecto es prácticamente imposible porque las necesi-
7
dades de los clientes y usuarios evolucionan durante el desarrollo. Ciclos requisitos-desarrollo-
evaluación: el resultado de la evaluación permite evolucionar hasta la siguiente versión.
Ciclo de vida incremental
Repetición de varios ciclos de vida en cascada.
Se suele aplicar a desarrollos de gran tamaño.
Al final de cada ciclo se entrega una versión parcial del software incrementada con cierta
funcionalidad nueva respecto a las anteriores.
Los ciclos se repiten hasta obtener un producto completo.
Aun que no completamente, los usuarios disponen antes del software y pueden sugerir
mejoras (nuevos requisitos).
Ciclo de vida iterativo
Repetición de varios ciclos de vida en cascada.
Se suele aplicar a desarrollos en los que los requisitos no están claros.
Al final de cada ciclo se entrega una versión completa del software mejorada respecto a la
anterior.
Las primeras versiones pueden ser prototipos que se desechan posteriormente.
Los ciclos se repiten hasta obtener un producto satisfactorio.
Los usuarios deben evaluar el producto en cada iteración y proponer mejoras.
Ciclos de vida basados en prototipos
Se pueden usar como una herramienta para obtener y validar los requisitos de clientes y
usuarios en cualquier ciclo de vida.
Lo habitual es usar prototipos de interfaz de usuario, que pueden reutilizarse o desecharse.
Siempre se debe evaluar si el esfuerzo de desarrollo del prototipo merece la pena.
Es fundamental la implicación de los usuarios.
Distintos enfoques de desarrollo:
- Desechable.
- Evolutivo.
- Mixto
Los prototipos funcionales, se utilizan para evaluar diferentes algoritmos antes de tomar
decisiones de diseño.
8
Inconvenientes: el sistema se puede llegar a deteriorar tendiendo hacia el modelo primi-
tivo, se suele refinar le prototipo hacia el sistema final en lugar de desecharlo y empezar
desde el principio, el cliente puede encontrar atractivo el prototipo y quedarse con el como
sistema final, relajación de los desarrolladores, no disminuye el tiempo entre la definición
de requisitos y la entrega del producto, al usuario le desagrada que se deseche código.
4. Ciclo de vida en los métodos ágiles
Son ciclos de vida de evolutivos con iteraciones de corta duración para favorecer la comu-
nicación con clientes y usuarios.
En cada iteración se incorporan nuevas peticiones de clientes y usuarios.
Iterativo e incremental a la vez.
El manifiesto ágil de 2001
Individuos e interacciones sobre procesos y herramientas:
- La gente es el principal factor de éxito de un proyecto.
- Es más importante construir un buen equipo que el entorno.
- Es mejor crear el equipo y que este configure su propio entorno de desarrollo en base
a sus necesidades.
Software que funcione sobre documentación detallada:
- No producir documentos a menos que sean necesarios de forma inmediata para tomar
una decisión importante.
- Estos documentos deben ser cortos y centrarse en lo fundamental.
Colaboración con el cliente sobre negociación de contratos:
- Interacción constante entre cliente y desarrollador.
Respuesta al cambio sobre seguimiento de un plan:
- Planificación flexible y abierta.
Los métodos ágiles no son escribir código desde el primer momento sin planificar ni documentar.
9
Técnicas de apoyo para los métodos ágiles
Refactorización: mejoras sobre el código fuente sin cambiar su funcionalidad.
Pruebas automáticas: pruebas programadas en lugar de realizarlas a mano.
Integración continua: automatización de la compilación y ejecución de pruebas automá-
ticas.
Gestión de configuración: especialmente diseñada para apoyar la interacción y la integra-
ción continua.
5. Metodología Scrum
Se trata de una metodología ágil más usada actualmente. Se basa en iteraciones de 30 días,
sprints. Durante un sprint:
Se produce código potencialmente entregable.
No se admiten cambios ni de requisitos ni de miembros del equipo de desarrollo.
Agile meeting: reuniones cortas y frecuentes donde cada miembro expone qué ha hecho desde
la última reunión y que va a desarrollar hasta la próxima.
Backlog: lista priorizada de tareas.
6. Ciclo de vida del proceso unificado
Proceso iterativo e incremental propuesto por los creadores de UML.
Define 6 fases: inicio, elaboración, construcción, transición, producción y retirada.
En cada fase se producen una o más iteraciones y se obtiene una versión evaluable del
software.
10
7. Ciclo de vida en Métrica 3
Metodología oficial de las administraciones públicas de España.
Métrica 3 permite aplicar diferentes ciclos de vida.
Sus procesos básicos son:
- Plan de Sistemas de Información (PSI).
- Desarrollo de Sistemas de Información.
◦ Estudio de Viabilidad del Sistema (EVS).
◦ Análisis del Sistema de Información (ASI).
◦ Diseño del Sistema de Información (DSI).
◦ Construcción del Sistema de Información (CSI).
◦ Implantación y Aceptación del Sistema (IAS).
- Mantenimiento de Sistemas de Información (MSI).
También incluye procesos de apoyo:
- Gestión de proyectos.
- Seguridad.
- Gestión de configuración.
- Aseguramiento de la calidad.
8. Pruebas en el ciclo de vida
El modelo en V asocia un tipo de pruebas a cada producto de cada fase según su nivel de abs-
tracción.
Pruebas Unitarias validan Implementación de Componentes.
Pruebas de Integración validan Diseño/Arquitectura.
Pruebas de Sistema validan Requisitos de Software.
Pruebas de Aceptación validan Requisitos de cliente.
9. Ingeniería inversa
A veces es necesario mantener sistemas heredados (legacy systems) de los que no se dispone
documentación.
Consiste en analizar el resultado de una fase del desarrollo de software para obtener el
resultado de la anterior, normalmente analizar el código para obtener el diseño.
10. Reingeniería
Utiliza la información obtenida por la ingeniería inversa para implicar cualquier tipo de
mantenimiento.
El mantenimiento preventivo del efecto 2000 ha sido el mayor esfuerzo de ingeniería in-
versa y reingeniería en la historia de la IS hasta la fecha.
11
Parte III
Introducción a los sistemas de información
1. Conceptos básicos
Un sistema es un conjunto de componentes que interactúan entre sí para lograr unos objetivos
comunes. Un sistema interactúa con un entorno, del que toma sus entradas y hacia el que genera
sus salidas.
Las entradas pueden ser datos, energía o materia.
Las salidas pueden ser información, energía o materia.
Los objetivos de un sistema controlan como se realiza la tranformación de las entradas en
salidas.
Casi todos los sistemas son realimentados, de forma que tienen en cuenta su efecto sobre
el entorno y actúan en consecuencia.
Datos: hechos o cifras que tienen existencia propia e independiente. Es necesario procesar-
los.
Información: conjunto de datos procesados con significado y dotados de relevancia y pro-
pósito.
Conocimiento: mezcla de experiencias concretas, valores, información de contexto y juicio
basado en la experiencia que proporciona un marco de referencia para evaluar e incorporar
nuevas experiencias e información.
Un sistema de información es un sistema diseñado para recoger, almacenar, procesar y distribuir
información sobre el estado de su entorno y soportar las operaciones, la gestión y la toma de
decisiones de la organización de la que forma parte y a la que da servicio.
Niveles de gestión de una organización
La eficiencia en el desarrollo de los procesos y el cumplimiento de las metas de una compañía
dependen de los niveles de gestión y planificación de su sistema logístico y de funcionamiento
interno. Un sistema de información ayuda a:
Tomar decisiones estratégicas de competividad.
Tomar decisiones tácticas de negocio.
Llevar a cabo los procesos de negocio y sus operaciones asociadas.
12
Un sistema informático es un sistema compuesto por hardware, software, personal encargado
de su operación, y por los procedimientos de operación y mantenimiento.
Un sistema de información suele incluir un sistema informático entre sus componentes,
excepto si es completamente natural.
Un sistema informático no tiene porque ser parte de un sistema de información.
2. Funciones de un sistema de información
Memoria: mantiene una representación interna del estado del entorno del sistema.
Informativa: proporciona información sobre el estado del entorno del sistema.
Activa: realiza acciones que modifican el estado del entorno del sistema.
Las tres funciones pueden realizarse bajo demanda o autónomamente.
3. Componentes de un sistema de información
4. Tipos de sistemas de información
Existen diferentes criterios, aunque el más habitual es en función del servicio que ofrecen: apoyo
a la gestión (DSS, MIS) o apoyo a la operación (TPS).
Procesamiento de transacciones TPS
Las transacciones son hechos o actidades que se llevan a cabo en una organización y que
aportan nueva información.
El objetivo de un TPS es capturar y procesar datos sobre las transacciones que se realizan
diariamente en su organización.
Una transacción es una interacción entre dos o más partes donde ocurre un intercambio de
información
Es importante cumplir con las características ACID para garantizar el correcto estado de la
Información:
- Atomicity: las operaciones son completadas y procesadas totalmente o son descarta-
das y no tienen efecto.
13
- Consistency: las operaciones no pueden violar la integridad de los datos.
- Isolation: cada operación debe ser independiente y ser llevada a cabo sin que afecte
al resultado de otra.
- Durability: el resultado de una operacion debe ser persistente en el tiempo.
Las transacciones suelen tener procedimientos definidos y rutinarios, lo que permite infor-
matizarlos con facilidad y trabajar con grandes cantidades de información.
Los TPS recogen la mayoría de los datos para los otros sistemas de información de la orga-
nización.
Un fallo grave en un TPS puede llegar a paralizar la organización y provocar un desastre.
Una base de datos sólo se encarga de almacenar los datos, un TPS además ofrece interfaz,
balanceador de peticiones, servidor de transacciones,. . .
Información de gestión MIS
Proporcionan información tanto para las necesidades de las operaciones como de la admi-
nistración en la empresa.
Transforman los datos e información en una variedad de formas para cumplir con los re-
quisitos.
Generan informes periódicos a partir de la información proporcionada por los TPS para
getentes de nivel medio. Los informes suelen tener una estructura fija.
Apoyo a toma de decisiones DSS
Usan información de los TPS, los MIS y de fuentes externas: la competencia, mercados,
clientes, etc.
Proporcionan informes, análisis y simulaciones de forma flexible, ya que deben ayudar a
resolver problemas no previstos.
Para no cargar los TPS, suelen usar un sistema de Data Warehousey, cada vez más, Big Data.
5. Sistemas integrales de gestión
ERP (Enterprise Resouce Planning)
- Sistemas integrales para la gestión de la empresa.
- Integran todo lo necesario para el funcionamiento de los procesos de negocio de la
empresa.
CRM (Customer Relationship Management)
- Modelo de gestión de la empresa enfocada principalmente a los clientes.
- Generan incentivos para satisfacer a los clientes ofreciendo soluciones que se ajusten
a sus expectativas.
SCM (Suplier Chain Management)
- Mejorar y automatizar el suministro a través de la reducción de las existencias y los
plazos de entrega.
- Trazabilidad
14
Parte IV
Requisitos para sistemas de información
1. Introducción
¿Qué es un requisito?
Glorario 610.12: una condición o capacidad que un usuario necesita para resolver un pro-
blema o lograr un objetivo.
Norma MIL-STD-498: una característica del sistema que es una condición para su acepta-
ción.
J.Goguen: propiedad que un sistema debería tener para tener exíto en el entorno en el que
se usará.
2. Historias de usuario
Son la propuesta de las metodologías ágiles para la especificación de los requisitos.
Se escriben desde el punto de vista del usuario del sistema y usando su vocabulario.
Se suele usar el formato propuesto por Mike Cohn: “como (tipo de usuario), quiero (servi-
cio), para (razón)”.
3. Requisitos generales (objetivos)
No todas las historias de usuario están al mismo nivel de detalle. En los objetivos, el nivel de de-
talle suele ser insuficiente como para que a partir de ellos pueda implementarse en una solución.
A veces las historias épicas(objetivos) sólon contienen el nombre y se utilizan para organizar
jerárquicamente el resto de historias. Se suelen colorear de forma diferente y se organizan vi-
sualmente como mapas de historias de usuario.
15
4. Requisitos de información
Describen qué información se debe almacenar sobre un concepto relevante para poder cum-
plir los objetivos.
También qué datos específicos del concepto son importantes para los usuarios.
5. Reglas de negocio
Definen reglas o políticas del negocio que son importantes para los usuarios y deben ser
respetadas.
También qué datos específicos del concepto son importantes para los usuarios.
Suelen ser requisitos inestables.
6. Requisitos funcionales
En general, definen los servicios que los usuarios desean que el sistema les ofrezca.
7. Requisitos no funcionales
Describen aspectos relacionados con la calidad que son importantes para los usuarios: usa-
bilidad, rendimiento, disponibilidad, fiabilidad, seguridad, compatibilidad. . .
8. Prubas de aceptación
No sólo describen cómo validar que el sistema desarrollado satisface los requisitos.
También añaden más detalle a las historias de usuario, sin complicar su descripción.
Lo ideal es que puedan programarse para que se ejecuten automáticamente.
Se asocian a uno o más requisitos (trazabilidad).
16
