TEMA 1

¿Qué es la ingeniería?

Es la ciencia de la producción, el diseño y manufactura de

productos complejos.

La ingeniería como actividad humana es la aplicación del

conocimiento y los métodos científicos al diseño y la
producción de productos complejos.

Aunque difieren en el producto, todas las ingenierías tienen

en común:
- La ciencia de la ingeniería.
- Procesos de diseño.
- Aspectos de gestión y organización.
Aspectos de toda disciplina profesional (colegial, cognitivo y
moral).

¿Qué es el software?

El software es el conjunto complejo de programas,

procedimientos y documentación relacionada que se
asocia con un sistema, y especialmente con un sistema de
computadora.
- Tiene un sentido específico.
- Además el software evoluciona, es propenso al
cambio e invisible.
¿Qué es la ingeniería del software?

La aplicación de un enfoque sistemático, disciplinado y cuantificable al

desarrollo, la operación y el mantenimiento del software.
También es el estudio de enfoques como:
- Seguir un plan de manera metódica.
- Respetar estándares.
- Sus resultados y el propio proceso pueden medirse.

Historia de la ingeniería

1945-1965 -> Desarrollo de los principios de la disciplina.

1965-1985 -> Se identifican los problemas del desarrollo del software, y

se denomina la CRISIS DEL SOFTWARE.

1985 -> Con el artículo de Brooks comienza el desarrollo de la ingeniería

con la idea de que el software es algo complejo.

Conceptos básicos

Actividad: Proceso que tiene lugar en el tiempo y en el espacio, y en el

cual alguien actúa en función de unos objetivos.

Artefacto: Objeto creado con un propósito práctico.

Método: Secuencia de acciones con un propósito determinado.

Metodología: Conjunto de métodos con sentido y relacionados por unos

principios comunes.

Especificación: Descripción detallada y precisa de algo o de cierta

situación, presente o futura.
Ciclo de vida del software: Período de tiempo por el que el software es
creado hasta que deja de usarse, y se describe en función de las
actividades que se realizan en él.

Proceso software: Es el conjunto de herramientas, políticas, tecnologías

y procedimientos que se necesitan para crear, desarrollar implantar y
mantener un producto software.

Modelos de ciclo de vida en cascada

● Fases en secuencia, aunque evoluciona para que una fase pueda

ser corregida en la posterior.
● El sistema se entrega completo y de una sola vez al final del
proyecto.
● Es sencillo.
● Es la base conceptual de otros modelos más complejos.
● El estado del proyecto se hace visible en todo momento. Los
entregables se asocian a fases.
● Asume requisitos estables en todo el proyecto.
● Se propagan los errores hacia fases posteriores.

Es el modelo más antiguo, existen otros que se amoldan mejor a las

necesidades de cambios de requisitos.

El concepto de fase se mantiene en la actualidad.

En los modelos posteriores las actividades de desarrollo no se limitan a
una fase, si no que tienen lugar en varias de ellas.

Medición

La medición es fundamental para la estimación de recursos, costes y

esfuerzo, la evaluación del personal o de productividad.

Permite conocer el estado del mismo para realizar ajustes o mejoras en

los procesos.

La medición de los productos y sus características hace posible la

mejora de su calidad.

Con la ingeniería de software se puede medir:

- Artefactos.
- Procesos.
- Recursos.

Herramientas

Hay una necesidad de automatizar parte de las tareas.

Una herramienta de software es un programa que ayuda a realizar un

proceso y lo automatiza completamente.

Una herramienta CASE es una herramienta de software que se utiliza en

fases de desarrollo de un producto software para el apoyo de una tarea
específica.

Herramienta CASE

Sus objetivos más comunes:

- Desarrollar.
 - Probar.
- Analizar.
- Diseñar o mantener un software o su documentación.

Facilitan la realización de actividades de gestión y técnicas.

La Integración CASE es la capacidad que tiene esta herramienta para

compartir datos y cooperar con otras herramientas.

Ingeniería del software

Requisitos y análisis

Clave en el éxito el proyecto

- Proyecto de software donde se transforma el conjunto de

requisitos del sistema informático.
- El sistema fracasará si no satisface las expectativas.
● Descripción inadecuada.
● Se desvía de lo que desea el cliente.
- Establecer con exactitud los requisitos para el éxito del desarrollo
del software.

Factores que influyen en los requisitos

- Complejidad del problema a resolver.
- Factores relacionados con el cliente.
- Dificultades de comunicación.
- Existencia de requisitos ocultos.

Conceptos:

- Requisito software: propiedad que un software ha de tener para

resolver un cierto problema.
- Atributo: información complementaria que se incluye en la
especificación del requisito.
Actividades de requisitos:

Roles:

- Usuarios: operan con el software

- Clientes: tienen interés en adquirir el software
- Analistas de mercado: identifican requisitos a través de
potenciales clientes
- Reguladores: autoridades que establecen normativas específicas
o requisitos legales
- Ingenieros del software: tienen intereses en el software en sí.

Características de los requisitos

- Verificable: Especificarlos de manera cuantificable.

- Propiedades no esenciales (externas):
● Priorizable
● Que pueda hacerse un seguimiento del mismo
● Identificable de manera única
● Cuantificable

Tipos de requisitos
 - Funcionales: funciones, servicios o tareas a llevar a cabo.
- No funcionales: aspectos técnicos que debe incluir el sistema
desarrollado.

Clasificación de requisitos no funcionales

- Requisitos del producto: detallan limitaciones o comportamientos

exigidos al producto resultante del desarrollo.
- Requisitos de la organización: relacionados con las normativas de
funcionamiento de la organización que lleva a cabo el desarrollo
(y/o del cliente), sus procedimientos y políticas.
- Requisitos externos: cubren aspectos externos al sistema y a su
proceso de desarrollo.

Requisitos funcionales y no funcionales

- Se deben poder imprimir los contratos de alquiler.

- Deben almacenarse todas las facturas emitidas por el sistema
- El área de trabajo debe poder ampliarse o reducirse.
- El lenguaje de programación a utilizar será obligatoriamente Java.
- El sistema debe almacenar los datos de todos los clientes.
- El código debe ponerse a disposición de la comunidad.
- Además de operar desde la interfaz de ventanas, debe facilitarse
también una interfaz de comandos.
- El cliente podrá comenzar a utilizar los servicios contratados en
menos de 24 horas.
- Los datos se almacenarán según las directrices de la LOPD
española.
Actividades de requisitos: interrelaciones

Obtención
- Objetivo: conocer los requisitos del sistema a desarrollar y
establecer sus fronteras.
- Acciones a llevar a cabo:
1. Determinar las fuentes de información de las que se
obtendrán los requisitos.
2. Establecer las técnicas de obtención de requisitos a utilizar.
3. Glosario.

Análisis

- Objetivo: describir las tareas que deben llevarse a cabo para

examinar los requisitos, delimitarlos y definirlos con precisión
- Acciones a llevar a cabo:
1. Elaborar los requisitos del sistema para obtener los requisitos
del software a desarrollar.
2. Detectar requisitos ambiguos, duplicados o incoherentes.
3. Clasificar y priorizar los requisitos: categorías de requisitos.
4.Toma de decisiones de compromiso en los casos de conflictos
entre varios requisitos (negociación).
5. Establecer un modelo conceptual de los requisitos.
6. Situar los requisitos en la arquitectura del sistema.
Especificación

- Objetivo: describir completamente los requisitos del sistema a

desarrollar
- Implica con frecuencia la construcción de un modelo (o varios) del
sistema a construir desde el punto de vista de los usuarios del
sistema, que incluya los requisitos obtenidos.
- Los requisitos se plasman en un documento denominado
especificación de requisitos del software (SRS).
- En proyectos complejos, 3 documentos:
● Documento de definición del sistema.
● Documento de requisitos del sistema.
● Documento de Especificación de Requisitos del Software
(SRS).

Validación
- Objetivo:
● Examinar si los documentos de requisitos definen el software
que los usuarios esperan y no otro.
● Buscar errores y contradicciones en los requisitos,
descripciones poco claras y desviaciones de las prácticas
estándar.

Gestión del proceso de requisitos

Seguimiento + Métricas + Herramientas de gestión

- Seguimiento: más improbable que el sistema final tenga
inconsistencias por culpa de cambios realizados sin un control
exhaustivo.
- Los requisitos evolucionan iterativamente hasta alcanzar un nivel
de calidad y detalle suficiente.
- Para facilitar la comprensión completa de todos los aspectos
asociados con los requisitos han de definirse líneas base( conjunto
de requisitos que deberá contener una entrega del producto).
Seguimiento de los requisitos

Matriz de seguimiento: es una tabla donde se relacionan dos

documentos, los cuales pueden pertenecer a etapas distintas del
desarrollo.

Su uso más frecuente es seguir la pista de los requisitos a lo largo de

todo el desarrollo, principalmente en diseño, plan de pruebas y casos de
prueba.

Hace que se relacionen los componentes de software que los

implementarán y especialmente los casos de prueba.

¿Qué ocurre si hay un cambio de requisito?

Métricas de requisitos

- Es posible tomar medidas de los requisitos software que indiquen

el alcance del proyecto, su crecimiento potencial, su estabilidad y
progreso.
- Las medidas de requisitos son únicas: caracterizan el espacio del
problema.
● Otras medidas del desarrollo caracterizan el espacio de la
solución.
Herramientas de requisitos

El tamaño y la complejidad de los desarrollos hacen de las herramientas

algo esencial.
Las herramientas de gestión de requisitos:

- Facilitan un modo de seguimiento de los cambios que se producen

durante el ciclo de vida de un proyecto.
- Permiten automatizar algunas tareas.
- Mejoran la productividad y la calidad en el desarrollo.
- Permiten gestionar versiones y definir líneas base.
- Almacenan atributos de los requisitos y permiten agruparlos.
- Permiten estudiar el impacto de los cambios.
- Permiten enlazar requisitos con otros artefactos.
- Permiten generar informes automáticos.

TEMA 3

Principios de diseño según la guía SWEBOK:

● Abstracción.
● Descomposición y modularidad.
● Acoplamiento y cohesión.
● Encapsulamiento y ocultación de información.
● Separación de interfaz e implementación.
● Suficiencia, compleción y sencillez.
PRINCIPIOS DEL DISEÑO OO

● Principio abierto-cerrado. Un módulo debe ser abierto para la

extensión pero cerrado para la modificación.
● Principio de responsabilidad única. Una clase debe tener sólo una
razón para cambiar, lo que lleva a que cada clase tenga una única
responsabilidad.
● Principio de separación de la interfaz. Los clientes no deberían
verse forzados a depender de interfaces que no utilizan. En otras
palabras, es preferible tener muchas interfaces específicas que
una sola interfaz de propósito general.
● Principio de sustitución de Liskov. La herencia ha de garantizar
que cualquier propiedad que sea cierta para los objetos de la
clase, también lo sea para los objetos de sus subclases. En otras
palabras, las subclases deben poder sustituirse por la clase base.
● Ley de Demeter. Establece que cada unidad debería tener
solamente un conocimiento limitado sobre otras unidades (sólo
conocer las unidades con quienes tiene que relacionarse una
unidad). Esta ley busca mejorar el acoplamiento entre clases.
● Principio de inversión de dependencias. Establece (1) que los
módulos de alto nivel no deben depender de los módulos de bajo
 nivel, pues ambos deben depender de las abstracciones; y (2) las
abstracciones no deben depender de los detalles, sino los detalles
de las abstracciones.
● Principio de dependencias estables. Las dependencias entre
paquetes en un diseño deberían ir encaminadas a la estabilidad
de los paquetes, midiéndose la estabilidad por el número de
dependencias de entrada y salida de un paquete.

McCabe:

Aristas - Nodos + 2 = complejidad

nº secciones del grafo + 1 = complejidad

Métricas de Halstead:

n1 = nº total de operadores
n2 = nº total de operandos
N1 = cantidad total de operadores
N2 = cantidad total de operandos

Longitud = N = N1 + N2
Volumen = L = N * log2(n1 + n2)

TEMA 4

● Error: imperfección en el software, que se manifiesta como un

funcionamiento incorrecto.
● Fallo: efecto indeseado observado en las funciones o prestaciones
desempeñadas por un software.
● Probar: proceso por el que se muestra la presencia de fallos en el
software.
● Depurar: proceso de localizar errores y modificar el software para
eliminarlos.
● Trazabilidad: toda funcionalidad se debe relacionar con algún
requisito. Permite establecer un plan de pruebas consistente.
TEMA 5

El mantenimiento del software es la modificación de un producto

software después de la entrega para corregir fallos, para mejorar el
rendimiento u otros atributos, o para adaptar el producto a un entorno
modificado.

PROCESO DE MANTENIMIENTO DE SOFTWARE

Técnicas para el mantenimiento del software

La ingeniería inversa consiste en analizar un sistema para identificar sus

componentes y las relaciones entre ellos, así como para crear
representaciones del mismo en alguna forma que no exista,
generalmente en un nivel de abstracción más elevado.

La reingeniería es la modificación de un producto software, o de ciertos

componentes, usando para el análisis del sistema existente técnicas de
ingeniería inversa y, para la etapa de reconstrucción, herramientas de
ingeniería directa.
La reestructuración es la modificación del producto software dentro del
mismo nivel de abstracción.

INGENIERIA DE SOFTWARE
TEMA 6: PROCESOS

MODELOS DE CICLO DE VIDA

Son el marco de referencia de los procesos y actividades relacionadas

con la evolución del software y pueden dividirse en etapas.
Son definiciones generales que enumeran las fases por las que pasa el
software a lo largo de su vida, así como sus dependencias.
PROCESOS DE SOFTWARE

Hay que definir que hay que hacer en cada una de las fases:

- Definición general de proceso:

Conjunto de actividades interrelacionadas(que interactuan entre si), que

transforman entradas en salidas.

- Concretando en el software:

Conjunto coherente de políticas, estructuras organizativas, tecnologías,

procedimientos y artefactos que se necesitan para crear, desarrollar,
implantar y mantener un producto software.

- Objetivos:

Analizar los mejores modelos de organización de las tareas necesarias

para desarrollar software, mediante la definición del orden y de los
métodos con los que realizar las tareas se obtendrá un mejor software.

- Características generales:

No son únicos, se definen a nivel teórico, en cada organización se

adaptan en su implantación, para cualquier tipo de software.

- Definen las actividades a realizar y su orden.

- Una actividad es:

La unidad mínima de trabajo, tiene un tiempo definido, está relacionado

con otras actividades, consume recursos y tiene un coste dado.

- Se pueden agrupar en fases o dividirse en subactividades o

tareas.

- Una actividad define:

que se debe hacer, quien lo hace y que productos intervienen.

- Define un conjunto de procesos para el ciclo de vida del software.

- Hay dos categorias de procesos:

● Procesos de contexto de sistema:

No son propios del software, están relacionados con la

organización.
Subgrupos: contratación, gestión de proyectos, facilitadores de la
organización, técnicos.

● Procesos específicos del software:

Tres subgrupos:
- Implementación del software.
- Soporte para el desarrollo del software.
- Reutilización del software

- Nueva versión que simplifica el estándar.

- Cuatro grupos de procesos:

● Acuerdo.
● Organizativos habilitadores del proyecto.
● Gestión técnica.
● Técnicos.

METODOLOGÍAS DE INGENIERÍA DEL SW

- Definición: conjunto integrado de métodos y técnicas que permiten

llevar a cabo todas las actividades del ciclo de vida.

- Una metodología de IS establece:

● Cómo dividir un proyecto en etapas.

● Qué trabajos se llevan a cabo en cada etapa.
● Qué salida produce cada etapa y cuándo.
 ● Qué técnicas y herramientas se van a utilizar en cada etapa.
● Qué restricciones se aplican.
● Cómo se gestiona y controla un proyecto.

- Objetivos:
General: concebir el desarrollo como un proyecto de IS.
Específicos:
● Mejorar la calidad del SW, al estar mas controlado su
desarrollo.
● Facilitar el control de los proyectos.
● Facilitar la comunicación entre los participantes.
● Mejorar la productividad en el desarrollo del SW.
● Facilitar el mantenimiento del SW.
● Conseguir satisfacer a todas las personas afectadas por el
SW.

GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

Una aplicación software esta compuesta por muchos componentes

interrelacionados de una forma concreta.
La configuración de la disposición del sistema informático, definido por
el número, naturaleza e interconexiones de sus partes constituyentes.
Además, dichos componentes evolucionan a lo largo de su vida, se
conoce como versiones del sistema.

En lugar de componentes se denominan Elementos de configuración

como artefactos de IS que evolucionan durante el desarrollo de un
sistema de software.
La gestión de la configuración es la disciplina que aplica dirección y
control técnico de las características físicas y funcionales de los
elementos de configuración.
Constituye un conjunto de actividades de soporte a otras actividades de
IS.
Las actividades de la gestión de configuración del software son:
● Identificación de la configuración:
- Qué elementos se controlan
- Qué relaciones o dependencias entre elementos se
controlan.
- Para ver la evolución del elemento de configuración se
define con el concepto de versión.
- Las configuraciones fijas se denominan línea base.
● Control de los cambios en el software:
- Consiste en la definición de los procesos de inclusión de
cambios de una línea base.
- El panel de gestión de la configuración es un comité que
controla el proceso de cambio y ejerce de autoridad de
control.

● Informe y contabilidad del estado de los elementos:

- Proporcionar información precisa de los elementos de
configuración y la historia de sus cambios.
- Se debe diseñar una política de información.
● Auditoria de la configuración:
 - Su objetivo principal es la evaluación de la integridad de
cada elemento antes de que entre en la línea base.
- Para ello comprueban:
- Que se han cumplido los requisitos.
- Que el diseño de los elementos esté documentado de
manera apropiada.
● Herramientas y técnicas de GCS
- Se basan en repositorios de versiones, donde se almacenan
las diferentes versiones de cada elemento.
- Tienen la problemática de la actualización del mismo
elemento por distintos usuarios.

TEMA 7: CALIDAD

INTRODUCCIÓN

La calidad puede definirse como la característica que distingue el grado

de excelencia de un proceso, producto o servicio.

COSTES DE LA CALIDAD

- Costes de prevención:

Controlar que el proceso cumpla los criterios de calidad y prevenir

defectos.

- Costes de evaluación de calidad:

Asociados con actividades de verificación de la calidad.

- Costes fallos internos:

Producidos por tareas de detección y reparación de defectos internos

del software.

- Costes fallos externos:

Derivados de corregir fallos encontrados en el software después de la

entrega al cliente.
CALIDAD DEL PRODUCTO

MODELO MCCALL

Acercar visiones de calidad de desarrolladores y usuarios.

Está organizado por características de calidad:
- Factores de calidad: Especificar cómo ven el software los usuarios
desde el exterior.
- Criterios de calidad: Indican cómo debe construirse internamente
el software desde la perspectiva del desarrollador.
- Métricas de calidad: Indican cómo controlar y medir la calidad.

Define tres perspectivas desde las que estudiar once factores:

- Revisión del producto: Adaptación a los cambios
- Transición del producto: Capacidad del software para adaptarse a
distintos contextos de operación.
- Operación del producto: Forma en que el software lleva a cabo sus
funcionalidades y la medida en la cual cumple con sus
especificaciones.

Proceso medición factores:

- Especificar requisitos de calidad del producto a desarrollar,
seleccionando aquellos aspectos que tengan relación con la
calidad deseada.
- Establecer los factores de calidad (entre los once descritos) sobre
los que aplicar los requisitos de calidad establecidos para el
proyecto.
- Evaluar los factores seleccionados mediante los criterios que el
método proporciona para cada factor
MODELO BOËHM

Basado en la identificación de cierto número de características.

Concepto de ‘Utilidades principales’.
Modelo jerárquico. Primer nivel:
- Utilidad tal y como está. Es fácil de usar, fiable y eficiente.
- Facilidad de mantenimiento. Facilidad identificar qué es necesario
modificar, la facilidad de modificación o de ejecución de las
pruebas sobre el elemento modificado.
- Portabilidad. Facilidad para utilizar el software en un nuevo
entorno.

Modelo jerárquico. Segundo nivel:

- Portabilidad.
- Fiabilidad: ausencia de defectos.
- Eficiencia: mínimo uso d e recursos durante el correcto
funcionamiento del sistema.
- Usabilidad: facilidad de uso del software.
- Facilidad de evaluación: validación de que el software cumple con
los requisitos establecidos.
 - Comprensibilidad: facilidad para entender el propósito y estructura
del software.
- Flexibilidad: facilidad para modificar el software ante cambios en
los requisitos o aparición de otros nuevos.

Se descomponen a su vez en elementos primitivos.

MODELO ISO/IEC 9126

Su objetivo principal es proporcionar una especificación de la calidad de

los productos software y un modelo de evaluación, para ello define un
lenguaje común. Además, establece medidas objetivas de calidad y
evalúa la calidad reproducible y sistemática.

Modelo de calidad (ISO/IEC 9126-1:2001):

- Marco del modelo.
- Relaciones entre los diferentes enfoques.
- Identifica características d e calidad (funcionalidad, fiabilidad,
usabilidad, eficiencia, facilidad de mantenimiento y portabilidad,
subdivididas a su vez).
Métricas externas (ISO/IEC 9126-2:2003):
- Miden el comportamiento del sistema computacional en su
conjunto.
Métricas internas (ISO/IEC 9126 -3 2003) 3:2003):
- Miden el propio software.
Calidad en las métricas en uso(ISO/IEC TR 9126 -4:2004).
- Mide efectos del software en un contexto específico de utilización.
 - Características: efectividad, productividad, seguridad y
satisfacción.

CALIDAD DEL PROCESO

MODELO CMMI(MADUREZ)
MODELO SPICE
ISO 9000