Apuntes Teoria

Teoria.
pdf
infeps
Ingeniería del Software
3º Grado en Ingeniería Informática
Escuela Politécnica Superior

Universidad Autónoma de Madrid
Reservados todos los derechos.

No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Tema 01. Introducción a la Ingeniería del Software 4
Software 4
Crisis del Software 4
Proyecto, producto y proceso 5
Trabajo operativo vs Proyecto 5
Producto y proceso 5
Ingeniería del Software 6
Actividades de un ingeniero de software 6
Tema 02. Metodologías, ciclos de vida y proceso software 8

Proceso software 8

Metodologías y ciclos de vida 8
Metodologías tradicionales 9
Metodologías ágiles 12
Metodología métrica 15
Desarrollo de software centrado en el usuario 16
Tema 03. Actividades tempranas en el desarrollo de software 17

Actividades de predesarrollo 17
Definición del ciclo de vida 17
Definición de estándares, métodos, técnicas y herramientas 17
Definición de objetivos, entradas y salidas 17
Definición de criterios de calidad y validación 17
Definición de hitos 17
Creación del equipo de desarrollo final 17
Definición de mecanismos de seguimiento y control 18
Tema 04. Análisis y diseño 19

Análisis 19
Definición de requisitos 19
Tareas a realizar en el análisis 20
Educción de requisitos 20
Tipos de requisitos 20
Análisis de requisitos 21
Representación de requisitos 21
Documento final de análisis 22
Diseño 23
Niveles de diseño 23
Principios básicos 23
Diseño estructurado y diseño orientado a objetos 24
Métricas de diseño 24
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3170587
Principales errores en el diseño 25
Documento final de diseño 25
Tema 05. Codificación, pruebas, entrega y finalización 27

Codificación 27
Pruebas 27
Principios 27
Pruebas en todo el ciclo de vida 27
Pruebas basadas en ordenador: técnicas 28
Diseño de casos de prueba 30
Estrategia de pruebas 30
Pruebas de sistemas orientados a objetos 36
Depuración 36
Prevención de errores 36
Principales errores en la fase de pruebas 36
Unidad 06. Mantenimiento 38

Tipos de mantenimiento 38

Mantenimiento correctivo (20%) 38
Mantenimiento adaptativo (25%) 38
Mantenimiento perfectivo (50%) 39
Mantenimiento preventivo (5%) 39
Reingeniería 39
Ingeniería inversa 39
Estrategias de mantenimiento 40
Mantenimiento estructurado/planificado 40
Mantenimiento no estructurado 40
Mantenimiento combinado 40
Coste del mantenimiento 41
Costes intangibles 41
Documentos 41
Unidad 07. Gestión de la Configuración del Software 42

Elementos de configuración del software 42
Líneas base 42
Herramientas de gestión de configuración del software 43
SVN 43
Unidad 08. Aseguramiento de calidad 45

Factores que determinan la calidad del software 45
Medidas de aseguramiento de calidad del software (SQA) 45
Medidas constructivas 45
El mejor palacio para que no tiemble tu Vida de Rico, aquí.

Medidas analíticas 46
Sistemas software de alta calidad 46
Documentación 47

Tema 01. Introducción a la Ingeniería del Software
SOFTWARE
El software de un programa no solo es el código, sino que es el conjunto del código, los datos y la
documentación. Es un elemento lógico, el cual es desarrollado, no fabricado, y tiene una vida útil, es
decir, se deteriora. No existen “piezas de repuesto” para un software. Cada software que se construye es
construido a medida para el caso específico en el que se necesita.
Como mera curiosidad, se presenta en la siguiente imagen la evolución que ha ido teniendo el software
a lo largo de los años:

Imagen 1. Evolución del software
La ingeniería del software ha tenido una evolución similar al resto de ingenierías pero mucho más
rápidamente.
Crisis del Software
La crisis del Software surge cuando se ha establecido una mala planificación del producto desarrollado.
Las causas que pueden conllevar a esta crisis pueden ser:
1. La necesidad de un hardware más potente.
2. Una mayor demanda de lo previamente esperado.
3. La falta de metodologías y técnicas en el desarrollo del software.
4. El uso inadecuado de los recursos.
5. La implementación de sistemas más complejos.
6. La poca información de los desarrolladores.
Se puede decir que estamos entrando en una crisis de Software en el momento que notamos alguno de
estos síntomas:
Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

1. Una baja productividad de los desarrolladores en relación a la demanda.
2. Los sistemas no responden a las expectativas de los usuarios.
3. Los programas fallan a menudo (fiabilidad).
4. La calidad no es adecuada.
5. Los costes son difíciles de predecir, y a menudo sobrepasan lo esperado.
6. El mantenimiento del software es costoso y complejo.
7. Los plazos de entrega no se cumplen.
8. No hay un aprovechamiento óptimo de los recursos (eficiencia).
Esto conlleva una baja productividad y calidad de nuestro producto software. Para no llegar a este punto,
la solución más eficiente y óptima es aplicar la Ingeniería del Software en la construcción de estos
Sistemas Informáticos. La necesidad de meter un enfoque de ingeniería en el desarrollo del software de
productos fue propuesta en una conferencia de la OTAN en 1968.
PROYECTO, PRODUCTO Y PROCESO

Muchos de los proyectos que fracasan tienen como factor una imprecisa definición de requisito. Para
reducir el número de proyectos que tienen este factor negativo es importante que las estrategias
organizacionales se expresen claramente a través de los requisitos. Esta potencia tiene como objetivo
demostrar que todo proyecto crea y pone en operación un producto que será parte importante de un
proceso.
Trabajo operativo vs Proyecto
El trabajo operativo consiste en efectuar permanentemente actividades que generan un mismo

producto o que proveen un servicio repetitivo. Sin embargo, un proyecto es un esfuerzo temporal que
se lleva a cabo para crear un producto, servicio o resultado único.
Producto y proceso
Como hemos dicho ya, la producción de software antiguamente era realizada con un enfoque artístico,
a diferencia de hoy en día que tiene un enfoque industrial, más organizado. Ante la constante presencia
de proyectos fallidos, y con el objetivo de mejorar la calidad de sus productos, en los últimos años las
organizaciones han introducido los métodos de ingeniería del software para llevar a cabo este
desarrollo.
Definimos un proceso como una “serie de acciones que conducen a un final”. Un proceso de desarrollo
software es un conjunto de personas, estructuras de organización, reglas, componentes software,
metodologías y herramientas utilizadas o creadas específicamente para definir, desarrollar, ofrecer y
extender un producto software.
INGENIERÍA DEL SOFTWARE
La Ingeniería del Software tiene como propósito/desafío reducir el coste y mejorar la calidad del
software explotando y aprovechando al máximo el potencial proporcionado por el hardware. Con ella
se pretende un desarrollo y un mantenimiento que aseguren la calidad, la fiabilidad, una facilidad de uso
y una imposibilidad de mal uso del software, de tal manera que sea el ser humano el que dirija el
ordenador y no al revés.
El objetivo de la ingeniería del software es conseguir un producto fiable, de alta calidad y a bajo coste.
Para ello se tendrá que llevar a cabo un proceso de desarrollo y mantenimiento de manera eficiente y
exitosa. Ya empezamos a ver que realizar un proyecto software no solo es programar.
El principal objetivo de la ingeniería del software, el cual es común a todas las ingenierías, es construir
elementos (en este caso tanto hardware como software) que ayuden o faciliten al ser humano en la
realización de tareas.
La ingeniería del software está compuesta por cinco grandes disciplinas, las cuales podemos ver en la
siguiente imagen:

Imagen 2. Ramas necesarias en la IS
Como podemos observar, la gestión hace de “pegamento” entre todas estas diciplinas. Sin una buena
gestión no se puede llevar a cabo nada.
Actividades de un ingeniero de software
 Actividades de desarrollo.
- Decidir qué hacer (fase de análisis).
- Decidir cómo hacerlo (fase de diseño).
- Hacerlo (fase de codificación).
- Probar el producto (fase de pruebas).
- Usar el producto (fase de entrega /instalación).
- Mantener el producto (fase de mantenimiento).
 Actividades de control. Se ocupan de evaluar y asegurar la calidad del software.
- Métricas.
- Aseguramiento de la calidad.
- Gestión de configuraciones.
 Actividades de gestión.
- Planificación y estimación.
- Seguimiento de proyectos.

- Administración de proyectos.
- Dirección de proyectos.
 Actividades de operación.
- Entrega e instalación.
- Puesta en marcha.
- Formación a los usuarios.
Básicamente, con lo que nos tenemos que quedar de esta primera parte es que el proceso de construir
un software es una actividad en la que se resuelven problemas.

Tema 02. Metodologías, ciclos de vida y proceso software
PROCESO SOFTWARE
Antes de comenzar con el tema, vamos a ver en la siguiente imagen la importancia de la comunicación
durante el proceso software:
Imagen 3. Importancia de la comunicación en la IS
El proceso software es el proceso que transcurre desde que un cliente define lo que quiere hasta que al
final obtiene por lo que ha pagado.
METODOLOGÍAS Y CICLOS DE VIDA

Una metodología nos define el conjunto de métodos que se utilizan en una determinada actividad con
el fin de formalizarla. Determina los pasos a seguir y cómo realizarlos de una manera sistemática
(primero esto, luego lo otro…). Es por esto por lo que las metodologías optimizan el proceso y el
producto software, pues definen qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento
del proyecto.
Por su parte, el ciclo de vida es el conjunto de estados por los que va pasando el sistema que se está
desarrollando desde que nace la idea inicial hasta que el software es retirado o reemplazado. Un ciclo
de vida debe determinar el orden de las fases, establecer los criterios de transición de una fase a otra y
definir las entradas y salidas de cada una de las distintas fases por las que se pasa.
Estudiar sin publi es posible. Compra Coins.

Las metodologías definen las tareas a realizar en cada una de las fases, así como los productos necesarios
en cada una de ellas (ficheros de E/S, documentos…), los procedimientos y las herramientas necesarias
para llevarlas a cabo, y unos criterios de evaluación para determinar si se ha logrado el objetivo o no.
Las funciones básicas de una metodología son:
 Definir el ciclo de vida que más se adecúe a las condiciones y características del desarrollo.
 Determinar las fases dentro del ciclo de vida especificando su orden de ejecución.
 Definir los resultados intermedios y finales.
 Proporcionar un conjunto de métodos, herramientas y técnicas para facilitar la tarea del
desarrollador y aumentar su productividad.
Los tres tipos de metodologías que existen en la actualidad son:
1. Metodologías pesadas o tradicionales.
- Las fases están bien definidas.

- Las entregas se realizan al finalizar el desarrollo.
- Los requisitos y la planificación están bien definidos.
2. Metodologías ágiles.
- Se utilizan cuando se necesita una interacción continua con el cliente.
- Se realizan muchas entregas parciales.
- Los ciclos iterativos son cortos.
3. Modelos centrados en el usuario.
- Se centran en el usuario y se interacciona mucho con él.
- Las características de calidad prioritarias son la usabilidad y la accesibilidad.
Metodologías tradicionales
Modelo de ciclo de vida en cascada

El modelo en cascada es un proceso de desarrollo secuencial en el que el desarrollo de software se
concibe como un conjunto de etapas bien definidas que se ejecutan una tras otra. Se denomina en
cascada por las posiciones que ocupan las diferentes fases que componen el proyecto, siguiendo un flujo
de ejecución de arriba hacia abajo, como una cascada.
Imagen 4. Modelo de ciclo de vida en cascada
Este modelo de desarrollo en cascada se originó en la industria y la construcción, donde los cambios a
posteriori son caros y difíciles de implementar. En el mundo del software, como no se habían implantado
otras metodologías de desarrollo, se adaptó el modelo en cascada que se utilizaba en estos sectores.
Para que el proyecto con esta metodología tenga éxito deben desarrollarse todas las fases, que no
terminan hasta que se han cumplido en su totalidad.
1. Análisis de requisitos. En esta fase se hace un análisis de las necesidades del cliente para
determinar las características software a desarrollar, y se especifica todo lo que debe hacer el
sistema sin entrar en detalles técnicos. Hay que tener cuidado en esta primera fase, ya que en
este modelo no se van a poder añadir nuevos requisitos en mitad del proceso de desarrollo.
2. Diseño. En esta etapa se describe la estructura interna del software y las relaciones entre las
entidades que lo componen. El sistema se descompone y se organiza en elementos que puedan
elaborarse por separado, aprovechando las ventajas del desarrollo en equipo.
Como resultado de esta etapa surge el SDD (Documento de Diseño del Software), que contiene
la descripción de la estructura del sistema y la especificación de lo que debe hacer cada una de
las partes.
3. Codificación. En esta fase se programan los requisitos especificados haciendo uso de las
estructuras de datos diseñadas en la fase anterior.
4. Pruebas e integración. Una vez se termina la fase de implementación, se verifica que todos los
componentes del sistema funcionen correctamente y cumplan con los requisitos. El objetivo de

estas pruebas es obtener información de la calidad del software y sirven para encontrar bugs,
mejorar la calidad del software, refinar el código…
5. Operación y mantenimiento. Una vez se han desarrollado todas las funcionalidades del
software y se ha comprobado que funcionan correctamente, se inicia la fase de instalación y
mantenimiento. Se instala la aplicación en el sistema y se comprueba que funcione
correctamente en el entorno en el que se va a utilizar.
Es a partir de ahora cuando hay que asegurarse de que el software funcione y hay que destinar
recursos para mantenerlo.
Ventajas
 El tiempo que se pasa en diseñar el producto puede evitar problemas que serían más costosos
cuando el proyecto ya estuviese en su fase de desarrollo.
 La documentación es muy exhaustiva.
 Es una metodología muy estructurada con fases muy bien definidas.
 Es ideal para proyectos donde los requisitos son claros y no van a cambiar a lo largo del proceso.
Inconvenientes
 En muchas ocasiones los clientes no saben bien los requisitos que necesitarán antes de ver una
primera versión del software en funcionamiento, por lo que este modelo no es adecuado, ya que
una vez acabas una fase no puedes cambiarla.
 No se muestra al cliente el producto a medida que se va desarrollando, sino que el resultado se
ve cuando el proceso ha terminado.
 No es adecuado para proyectos largos, pues las necesidades del usuario pueden cambiar.
Modelo de ciclo de vida en cascada con refinamiento
En el modelo de ciclo de vida en cascada, algún cambio en cualquiera de las etapas en el modelo
secuencial en cascada implicaría reiniciar desde el principio todo el ciclo completo, lo cual incrementaría
considerablemente el tiempo de desarrollo. Por esto surge el modelo de ciclo de vida en cascada con

refinamiento. Hay veces que surge la necesidad de realizar algunas pequeñas correcciones en fases
anteriores, y este modelo permite tener esas incertezas o pequeños cambios durante el ciclo de vida.
Imagen 5. Modelo de ciclo de vida en cascada con refinamiento
Modelo de ciclo de vida incremental

En este modelo se analiza primero el problema, el cual se divide en subproblemas que se van

desarrollando en cada iteración. Como vemos, se va aumentando poco a poco la funcionalidad. Se
empieza con un pequeña parte y, a medida que se va haciendo y comprobando que esta funcionalidad
es correcta, se añade al proyecto y se genera más funcionalidad, así hasta terminar con todo.
Un ejemplo de un desarrollo puramente incremental puede ser la agregación de módulos en diferentes
fases.
Imagen 6. Modelo de ciclo de vida incremental
Modelo de ciclo de vida iterativo

Este modelo es como el refinamiento por pasos, pero normalmente se iteran todas las fases a la vez. En
cada ciclo se revisa lo que ya se ha hecho y se mejora en caso de ser necesario.
Compra Coins y descarga sin publicidad.

Imagen 7. Modelo de ciclo de vida iterativo
Estos dos modelos (incremental e iterativo) permiten construir una implementación parcial del sistema
global para posteriormente ir aumentando la funcionalidad. Tienen la ventaja de que lo que ya tenemos
hecho se le puede enseñar al cliente, por lo que habrá un feedback.
Modelo de ciclo de vida iterativo incremental
En este modelo de ciclo de vida se juntan el iterativo con el incremental. Del iterativo sacamos que en

las iteraciones se pasan por todas las fases, y del incremental sacamos que cada iteración que vamos
haciendo le vamos metiendo más funcionalidad.
Se empieza por iteraciones con una funcionalidad pequeña para cada subsistema y se va agrandando
(incrementando) a medida que vamos haciendo más iteraciones.
Imagen 8. Ejemplo modelos de ciclos de vida iterativo e incremental
Metodologías ágiles
El problema del ciclo de vida clásico es que no tiene flexibilidad. Una vez se tienen los requisitos, se
congelan y no se pueden cambiar. Es por esto por lo que surgieron las metodologías ágiles.
En el año 2001 un grupo de desarrolladores que no se sentían cómodos con el método tradicional de
desarrollo de software, se reunieron y firmaron el Manifiesto1 por el desarrollo Ágil de Software.
1 http://agilemanifesto.org/iso/es/manifesto.html

En este Manifiesto se resumen los principios sobre los que se basan estos métodos.
1. Anteponer los individuos e interacciones sobre procesos y herramientas.
La clave de un proyecto son las personas. Las herramientas y los procesos no pueden sustituir el
conocimiento, experiencia y trabajo de las personas.
2. Anteponer el software en funcionamiento sobre la documentación exhaustiva.
Es fundamental que se empiece a desarrollar el software lo antes posible. Con la base de un
programa se pueden obtener ideas importantes que ayuden a mejorarlo y adaptarlo a las
necesidades del usuario.
3. Anteponer la colaboración con el cliente sobre la negociación contractual.
Durante el desarrollo el cliente es uno más del equipo y aporta sus comentarios e ideas que
retroalimentan continuamente el proyecto.
4. Anteponer la respuesta ante el cambio sobre seguir un plan.
Es fundamental tener una pronta capacidad de respuesta a las novedades. Por ello, los planes

preestablecidos a largo plazo pueden no ser lo suficientemente flexibles para los proyectos de
desarrollo.
La mayor ventaja de las metodologías ágiles es que están pensadas para satisfacer a los clientes, pues se
generan entregas continuas de evaluables y, en caso de que el cliente desee cambiar los requisitos, no
hay problema en incluirlos en el desarrollo. Las entregas de software son frecuentes, dando preferencia
a los plazos más cortos que a los largos.
Las metodologías ágiles más utilizadas actualmente son XP (eXtreme Programming), KANBAN y SCRUM.
Vamos a enfocarnos en esta última.
SCRUM
Scrum es una metodología ágil de desarrollo iterativa y de pequeños incrementos. El proyecto se
ejecuta en partes pequeñas conocidas como iteraciones o sprints, que son periodos cortos de tiempo
cuya duración varía entre 2 y 4 semanas. En cada una de estas iteraciones o sprints el equipo trabaja en
todas las fases: planeamiento, análisis, diseño, implementación y pruebas. Al final de cada iteración se
muestra al cliente el producto con las nuevas funcionalidades.
Roles en Scrum
En la metodología Scrum hay tres roles principales que representan al equipo: el dueño del producto
(product owner), el scrum master y el equipo de desarrollo scrum.
Product Owner
El dueño del producto representa al cliente y a los usuarios del software, solicitando que se desarrollen
las características que el cliente necesite. Se encarga de escribir las historias de usuario, priorizarlas y
situarlas en la lista de tareas (backlog).
Scrum Master
Es el facilitador, el que se encarga de retirar obstáculos que el equipo pueda encontrar en el camino. No
es el líder del equipo ni el jefe de proyecto, sino que tiene el papel de eliminar los impedimentos que el
grupo encuentra a lo largo del proyecto, facilitando su trabajo. El scrum master se asegura también de
que la metodología se aplique correctamente.
Equipo de desarrollo scrum (scrum team)
El equipo de desarrollo es el responsable de entregar las nuevas funcionalidades al final de cada sprint.
El conjunto de miembros del equipo posee todas las habilidades necesarias para desarrollar estos
avances de software.
El proceso de trabajo Scrum
Todos los sprints comienzan con la planificación de la iteración, que define la lista de tareas (backlog)
para esa iteración, y se estima la cantidad de trabajo para ese sprint. Cada día del sprint se realizan
reuniones cortas llamadas “stand-up meetings” o “daily meetings”. La iteración termina con una
revisión del sprint, en la que se verifica el progreso realizado para mostrar el resultado al cliente, y se
identifican posibles mejoras para futuros sprints. Una vez terminado, se comienza un nuevo sprint en el
que se implementarán nuevas funcionalidades. Veamos en detalle cada una de estas fases.
Planificación del sprint
Al comienzo de un sprint se mantiene una reunión que durará como máximo una hora por cada semana
de duración del sprint, fijándose un límite de 8 horas.
El cliente presenta al resto del equipo la lista de requisitos y la prioridad de cada elemento de la lista. Se
prepara la lista de tareas o requisitos del sprint y se analiza, con todo el equipo, el tiempo y el esfuerzo
que llevará hacer cada funcionalidad elegida.
Una vez el equipo ha preparado la lista de tareas, se estima y se vota qué tareas serán entregadas al final
del sprint. El equipo de desarrollo se asegura de entender bien todos los detalles de cada uno de los

requisitos. Algunas tareas pueden devolverse a la lista de tareas pendientes si se cree que no pueden
completarse en ese sprint.
Desarrollo de la iteración
Todos los días del sprint el equipo de desarrollo se reúne para ponerse al día de cómo va el trabajo de
los demás compañeros. Se trata de una reunión corta (de unos 15 minutos) y se suele hacer de pie.
La reunión se realiza todos los días a la misma hora y las intervenciones deben ser cortas, y responder
a estas tres preguntas:
 ¿Qué hice ayer?
 ¿En qué tengo pensado trabajar hoy?
 ¿Qué impedimentos he encontrado o creo que puedo encontrar?
El scrum master se encargará de eliminar los impedimentos identificados, o se pondrá de acuerdo con
una persona que trabaje para solventar estos problemas.
Revisión retrospectiva del Sprint
Al final del sprint se llevan a cabo dos actividades: la revisión y la retrospectiva del sprint.
Durante la revisión el equipo revisa el trabajo que se ha desarrollado y presenta el resultado al cliente.
En función de la opinión del cliente, éste puede solicitar realizar algunos cambios en el proyecto.
En la retrospectiva el equipo analiza cómo ha sido su manera de trabajar e identifica acciones de mejora
para futuros sprints. Esta actividad será guiada por el scrum master.
Lista de tareas (backlog)
La lista de tareas es el conjunto de todos los requisitos que debe cumplir el proyecto. Los elementos
añadidos a la lista de tareas pendientes (backlog) se suelen escribir en forma de historias de usuario.

La lista de tareas del sprint actual contiene las funcionalidades que el equipo de desarrollo
implementará durante el sprint. Estas tareas han sido previamente seleccionadas del backlog, tomando
las más prioritarias.
Una vez que el sprint actual se ha terminado, el backlog se analiza de nuevo y se vuelven a asignar
prioridades si es necesario. Además, un nuevo conjunto de tareas es seleccionado para el nuevo sprint.
Imagen 9. Metodología Scrum
Ventajas

- Flexibilidad a cambios.
- Reducción del Time To Market.
- Optimiza el proceso.
- Alcance viable.
- Mayor productividad del equipo.
- Maximiza el retorno de la inversión (ROI).
- Incremental.
- Reducción de riesgos.
Inconvenientes
- Equipo autoorganizado. Puede ser una ventaja, pero también conlleva riesgos.
- Depende de un fuerte compromiso tanto por parte del equipo como por parte del cliente.
- Restricciones en el tamaño de los proyectos. Están más orientados a proyectos pequeños.
- Posible falta de documentación.
Metodología métrica
Es una metodología promovida por el Ministerio de Hacienda y Función Pública para la sistematización
de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas.
Este modelo ofrece un marco de trabajo que define una división del proyecto en fases, junto a las
relaciones de estas fases. También ofrece responsabilidades y funciones de los miembros del equipo.
Esta metodología surge para paliar el problema de los Departamentos de Tecnología de la Información
que no utilizan ninguna metodología de desarrollo, que suelen tener escasa o nula documentación, un
mantenimiento difícil, una falta de comunicación con el cliente y productos no entregados a tiempo.

Desarrollo de software centrado en el usuario
El Diseño Centrado en el Usuario (DCU) es una metodología o filosofía de diseño que se centra en crear
productos o plantearlos para que den solución a necesidades específicas de los usuarios. Se preocupa
por determinar soluciones concretas siempre, exigiendo un mayor esfuerzo y atención, pero obteniendo
un alto grado de satisfacción por parte de los consumidores.
El usuario juega un papel fundamental antes, durante y después de la construcción del software. El
objetivo principal de esta metodología es el aseguramiento de la usabilidad del sistema final. Existen
tres fases principales por las que hay que pasar para hacer un buen desarrollo de software centrado en
el usuario:
1. Conocer a fondo a los usuarios finales.
2. Diseñar un producto que resuelva sus necesidades y se ajuste a sus capacidades,
expectativas y motivaciones.
3. Poner a prueba lo diseñado, normalmente utilizando tests de usuario.
Usabilidad
El término usabilidad se refiere a la facilidad con que las personas pueden utilizar una herramienta
particular o cualquier otro objeto fabricado por humanos con el fin de alcanzar un objetivo concreto.
Para saber si un producto es usable o no, generalmente se utilizan las métricas de la Usabilidad:

 Exactitud. Número de errores cometidos por sujetos de prueba y si estos errores son
recuperables o no al usar los datos o procedimientos adecuados.
 Tiempo requerido para concluir la actividad.
 Recuerdo. Qué recuerda el usuario después de un periodo sin utilizar la aplicación.
 Respuesta emocional. Cómo se siente el usuario al terminar la tarea (en tensión, satisfecho,
molesto…).

Tema 03. Actividades tempranas en el desarrollo de software
ACTIVIDADES DE PREDESARROLLO
Definición del ciclo de vida
Para definir el ciclo de vida hace falta definir las fases por las que va a pasar, el orden de estas fases y las
entradas y salidas que tendrá cada una de estas fases. Recordemos que no se puede pasar a otra fase sin
haber terminado previamente la anterior.
Todo esto se realiza de acuerdo a las características del proyecto en específico que se va a realizar.
Definición de estándares, métodos, técnicas y herramientas
El siguiente paso a realizar en el desarrollo de un proyecto es la definición de estándares, las

herramientas que se van a utilizar, los métodos y las técnicas.
Definición de objetivos, entradas y salidas
En esta parte se definirá el proyecto, así como las entradas y salidas que debe tener, y las funciones
básicas también se definirán aquí.
Definición de criterios de calidad y validación
Estos criterios se deben especificar de acuerdo con la especificación de requisitos, los resultados
esperados, el plan de validación, el plan de aseguramiento de calidad y los atributos de calidad.
Estos criterios de calidad y validación deben ser acordados por todos los participantes en el proyecto.
Definición de hitos
Se deben definir productos correspondientes a cada hito, es decir, productos intermedios que sean
“enseñables” a los clientes. Se debe definir qué, quién, cuándo y cómo se va a evaluar este hito. Se
conseguirá el hito cuando se haya revisado la calidad de uno o más productos y se hayan aceptado.
Tras cada hito, se debería generar un informe de progreso del proyecto, coincidiendo este informe con
el final de una fase (como mínimo).
Creación del equipo de desarrollo final
El personal es el factor más importante en el éxito de un proyecto software. Lo podemos observar en la

siguiente imagen, que nos enseña la distribución del tiempo de trabajo de un ingeniero software en un
proyecto:
En este punto se debe definir un jefe de proyecto, así como los miembros que conformarán el equipo y
el papel que desarrollará cada uno de estos miembros.
Definición de mecanismos de seguimiento y control
En todo proyecto software se tiene que especificar un seguimiento y control del mismo para ver su
desarrollo a lo largo del tiempo. Para ello, se definen varias tareas a realizar:
Se debe controlar un cumplimiento de tiempos en cuanto a entregas, además de evaluar objetivos por
parte del equipo y, sobre todo tiene que haber una coordinación del equipo para poder llevar a cabo el
proyecto. Además, también debe haber revisiones rutinarias para seguir el desarrollo.

Tema 04. Análisis y diseño
ANÁLISIS
En esta primera parte se hará un análisis del problema y una especificación completa del
comportamiento externo que se espera del sistema software que se va a construir, así como de los flujos
de información y control.
Definición de requisitos
Los requisitos especifican lo que el sistema debe hacer (junto a sus funciones) y las propiedades
esenciales y deseables que debe tener. La captura de requisitos tiene como objetivo la comprensión de
lo que los clientes y usuarios espera que haga el sistema. Un requisito expresa el propósito del sistema
sin considerar cómo se va a implantar. En otras palabras, los requisitos especifican el qué del sistema,
sin saber el cómo, de lo que se encargará el diseño.
La captura y análisis de requisitos es una de las fases más importantes para que un proyecto tenga éxito.
Tenemos que diferenciar entre lo que son los requisitos para el usuario y lo que son los requisitos para
el equipo de desarrollo. Para el usuario los requisitos son las condiciones o capacidades necesarias para
que un usuario pueda resolver un problema o alcanzar un objetivo, mientras que para el equipo de
desarrollo los requisitos son las condiciones o capacidades que debe reunir un sistema para satisfacer

un contrato, estándar o cualquier otro documento impuesto formalmente.
Requisitos de usuario y requisitos software
Los requisitos de usuario son declaraciones en lenguaje natural de las funciones o acciones que los
distintos usuarios pueden realizar con la aplicación y bajo qué restricciones. Estos requisitos forman el
Documento de Requisitos de Usuario (DRU/ERU).
Por otra parte, los requisitos software especifican de una manera completa, consistente y detallada qué
debe hacer y cómo debe comportarse el software para cumplir con los objetivos de la aplicación. Estos
son los requisitos que sirven a los desarrolladores para diseñar el sistema. Se recogen en la
Especificación de Requisitos Software (ERS) y deben responder a la pregunta “¿qué características
necesita cumplir el sistema software para permitir alcanzar los requisitos expuestos en el DRU?”.
Cuando el cliente ya ha planteado su problema y el resultado que espera obtener junto con las
condiciones expuestas, el equipo de desarrollo debe hacer un análisis de este problema y con ello
formular el conjunto de requisitos, para que después estos sean implementados.
Para tener toda la información posible, el equipo de desarrollo hace un análisis del contexto del
problema y realiza entrevistas con el cliente para tener una mayor comprensión de las necesidades de
los usuarios. Con todo esto, el equipo ya tiene las necesidades, las cuales transformará en requisitos.

Tareas a realizar en el análisis
Lo primero que se debe de hacer en la fase de análisis es comprender el problema que se propone. Los
requisitos han de determinarse siguiendo una aproximación descendente: primero se analiza el
problema globalmente para después pasar al detalle.
Las tareas a realizar son entonces las siguientes:
1. Educción de requisitos. En esta etapa se deben identificar los requisitos que se obtienen de los
usuarios y clientes.
2. Análisis de Usuarios y de las tareas. Se deben identificar potenciales usuarios del sistema, su
jerarquía y las tareas a realizar.
3. Análisis del problema y de los requisitos. Razonar sobre los requisitos educidos, combinar
requisitos relacionados, establecer prioridades entre ellos, determinar su viabilidad…
4. Representación (modelización). Registrar los requisitos de alguna forma, incluyendo lenguaje
natural, lenguajes formales, modelos, prototipos, maquetas, UML…
5. Validación. Examinar inconsistencias entre requisitos, determinar la corrección, ambigüedad…
Establecer criterios para asegurar que el software reúna los requisitos cuando se haya
producido. El cliente, usuario y desarrollador se deben poner de acuerdo.
Educción de requisitos

La educción de requisitos es un proceso a través del cual los clientes, compradores o usuarios de un
sistema software exponen, formulan, articulan y comprenden sus requisitos. Este paso se realiza
mediante reuniones, entrevistas, análisis de tareas, lectura de documentos…
Tipos de requisitos
Requisitos funcionales
Son las acciones fundamentales que deben tener lugar en la ejecución del software. Son las acciones que
son necesarias para el correcto funcionamiento y comportamiento de nuestro sistema. Ejemplo: “El
usuario podrá dar de alta un elemento”.
Requisitos no funcionales
Representan las características o cualidades generales que se esperan del software para conseguir su
propósito. Existen requisitos funcionales de muchos tipos:
 Requisitos de interfaz y usabilidad. Menús, ventanas, mensajes de error, formatos de
pantalla…
 Requisitos operacionales. Modos de operación, back-ups, funciones de recuperación…
 Requisitos de documentación. Idiomas, tipos de usuario, ayuda online, web, tutoriales…
 Requisitos de seguridad. Diferentes niveles de acceso al sistema, protección, mantenimiento
de históricos, claves…
 Requisitos de mantenibilidad y portabilidad. Grado en que debe de ser fácil cambiar el
software o portarlo.
 Requisitos de recursos. Limitaciones de memoria, almacenamiento…
 Requisitos de rendimiento. Tiempo de respuesta, número de usuarios, terminales soportadas,
consumo de memoria…
 Requisitos de comportamiento.

 Requisitos de disponibilidad. Especialmente para aquellos sistemas informáticos que
necesitan estar conectados a la red.
 Requisitos de soporte. Incluyen la facilidad de instalación, facilidad de mantenimiento,
facilidad de actualización y facilidad de portabilidad.
 Requisitos de verificación y fiabilidad. Recuperaciones ante situaciones anómalas o de error.
 Requisitos legales. Características que debe cumplir el sistema para cumplir con la legislación
vigente.
Análisis de requisitos
El análisis de requisitos es el proceso a través del cual se determinan qué requisitos son aceptables y se
definen cuáles van a formar parte del producto. Este análisis se realiza mediante una evaluación de
viabilidad técnica y económica, además de realizar una valoración de riesgos. Los riesgos que
analicemos se podrán clasificar en categorías como obligatorios, deseables, accesorios…

Representación de requisitos
La representación de requisitos sirve para registrar los requisitos de una o más formas y para especificar
aquellos requisitos que todavía no estén educidos. ¿Cómo podemos realizar esto? Hay varias formas de
hacerlo: mediante lenguaje natural, mediante lenguaje formal, o con modelos, diagramas, maquetas…
El cliente a veces puede no tener una idea clara de lo que quiere o no saber explicarlo bien. Por ello, el
responsable de desarrollo puede no estar seguro de la eficacia de un algoritmo o del enfoque que tiene
que tomar en la interacción hombre-máquina. Para ayudar a comprender y validar estos requisitos que
aún no están claros podemos desarrollar maquetas y/o prototipos.
Las maquetas se pueden realizar en varios casos. Cuando los requisitos no están claros, cuando el
alcance del proyecto no está bien definido, cuando los usuarios no se muestran colaboradores o cuando
las comunicaciones resultan difíciles. Una maqueta nos permite adaptar el modelo mental del usuario
con el del ingeniero del software. Nos ayuda a validar los requisitos del usuario, a comprobar su
aceptación y la integración que podría tener con el entorno.
Los prototipos se realizan cuando no se conoce la complejidad total del desarrollo. Son diferentes a las
maquetas. Un prototipo lo realiza un ingeniero de software cuando no tiene muy clara la solución
informática más adecuada.
El prototipado permite educir y verificar los requisitos principales del usuario, verificar la viabilidad del
diseño informático del sistema y facilitar el diseño de la interacción Persona-Ordenador y de las
interfaces de usuario.
Para resumir, la diferencia entre las maquetas y los prototipos es que las maquetas solamente tienen
una interfaz, no tienen ningún tipo de lógica. Sin embargo, un prototipo, además de presentar una
interfaz, también tiene un mínimo de funcionalidad. La ventaja que tienen los prototipos es que se puede
hacer un uso (aunque sea mínimo) del producto, mientras que en una maqueta solo se ve la parte gráfica,
sin ninguna funcionalidad.
Documento final de análisis
El propósito del documento final de análisis de un proyecto software es el de proporcionar los medios
de comunicación entre todas las partes, tanto clientes como usuarios, analistas y diseñadores. Este
documento debe ser comprensible por todas las partes y debe servir como base para las actividades de
diseño, pruebas y verificación. A continuación vemos la estructura que más o menos debería quedar en
un documento ERS.

1. Introducción
1.1. Propósito
1.2. Definiciones, acrónimos y abreviaturas
1.3. Referencias
1.4. Estructura
2. Descripción general
2.1. Alcance
2.2. Funciones del producto
2.3. Restricciones generales
2.4. Dependencias
2.5. Características de usuario
3. Requisitos específicos
3.1. Requisitos de interfaz
3.2. Requisitos de rendimiento
3.3. Requisitos operacionales
3.4. Requisitos de recursos
3.5. Atributos del sistema software (fiabilidad, disponibilidad, seguridad…)
4. Descripción de la información
4.1. Flujo de control
4.2. Flujo de datos
5. Descripción funcional
5.1. Partición funcional
5.2. Diagramas de soporte
6. Descripción del comportamiento
7. Criterios de validación
7.1. Límites de rendimiento

7.2. Clases de pruebas
7.3. Respuesta esperada del producto
7.4. Consideraciones especiales
DISEÑO
En esta etapa del desarrollo del software, vamos a analizar cómo podemos hacer la transición del
análisis al diseño, es decir, cómo pasar del qué al cómo. El diseño es el proceso de definición de la
arquitectura, componentes, módulos, interfaces, procedimientos de prueba y datos de un sistema
software para satisfacer los requisitos especificados en la fase de análisis.
Niveles de diseño
Existen dos niveles de diseño diferentes, que se diferencian en el grado de exactitud en que se
implementan.
Por un lado tenemos el diseño de la arquitectura (diseño de alto nivel), que es el proceso de
definición de la colección de componentes del sistema y sus interfaces. Su objetivo es determinar el
marco de referencia que guiará a la construcción del sistema. En este tipo de diseño se llevan a cabo las
siguientes tareas:
- Definir los criterios de descomposición del proyecto.

- Descomponer el sistema en diferentes módulos.
- Determinar las estructuras de datos a utilizar.
- Diseñar las interfaces.
- Definir los flujos de control.
Por el otro lado nos encontramos con el diseño detallado. Este tipo de diseño consta de una descripción
más detallada de la lógica de cada uno de los módulos, así como de las estructuras de datos que se
utilizan y de los flujos de control. Su objetivo es describir el sistema con el grado de detalle suficiente y
necesario para su posterior implementación. En el diseño detallado las tareas que se realizan son más
exhaustivas:
- Descripción detallada de los módulos: estructuras y algoritmos a utilizar.
- Descripción detallada de las estructuras físicas de datos.
- Descripción de los procedimientos de acceso a las estructuras físicas de datos.
- Descripción detallada de las interfaces.
Principios básicos
Se deben tener en cuenta algunos aspectos básicos a la hora de llevar a cabo la implementación del
diseño. El primero de ellos es que se debe procurar tener un nivel de abstracción bastante alto, de
manera que se manejen conceptos generales y no de instancias particulares. Otra característica que se
pide es seguir una estrategia de diseño descendente (refinamiento), es decir, empezar con el diseño de
las cosas más grandes e ir detallando poco a poco cada una de ellas. Además, la modularidad es muy
importante, pues dividir el software en diferentes unidades con entidad propia lo hace mucho más fácil
de utilizar. Esto nos lleva a la ocultación de información. Los detalles internos de cada módulo han de
ser transparentes a los demás módulos, de manera que cada módulo sea independiente de los demás.
Esta ocultación de información ayuda a reducir la complejidad, pues el problema se descompone en
piezas más pequeñas unas independientes de otras.

Sin embargo, a pesar de intentar reducir esta complejidad mediante la descomposición del problema en
piezas independientes cada vez más pequeñas, a partir de un momento dado la complejidad empieza a
aumentar de nuevo a causa de las interdependencias que tienen unas piezas con otras. Entonces la
pregunta que nos surge es: “¿hasta dónde debe llegar la descomposición de un sistema en piezas más
pequeñas?”.
Diseño estructurado y diseño orientado a objetos
En el diseño estructurado se considera que el sistema es un conjunto de módulos o unidades, cada uno
con una función bien definida, que están organizados de forma jerárquica, mientras que en el diseño

orientado a objetos se considera al sistema como una colección de objetos que interactúan entre ellos
a través de mensajes. Cada objeto tiene su propio estado y conjunto de operaciones asociadas.
Es por ello por lo que los diagramas que se realizan para ambos tipos de diseño son diferentes:
Diagramas estructurales Diagramas de comportamiento

Diagrama de clases Diagrama de casos de uso
Diagrama de objetos Diagrama de secuencia
Diagrama de componentes Diagrama de comunicación
Diagrama de despliegue Diagrama de estados
Diagrama de paquetes Diagrama de actividad
Veamos en qué etapa se desarrolla cada uno de estos diagramas
Etapa de análisis Etapa de diseño

Diagrama de casos de uso Diagrama de clases
Casos de uso detallados Diagrama de objetos
Otros diagramas conceptuales y del sistema Diagrama de componentes
Diagrama de comunicación
Diagrama de secuencia
Diagrama de estados
Diagrama de actividad
Métricas de diseño
Cohesión y acoplamiento
Podríamos definir la cohesión como el grado en que los elementos de un módulo permanecen juntos.
Es decir, lo estrecha que es la relación entre esos elementos. Si hablamos de clases, una clase tendrá una
cohesión alta si sus métodos están relacionados entre sí, es decir, tienen una “temática” común, trabajan

con tipos similares… Es mejor tener un alto grado de cohesión, pues ello implica un menor coste de
programación y una mayor calidad del producto. Un módulo con un alto grado de cohesión idealmente
se dedica a hacer una única tarea.
El acoplamiento es la manera en que se relacionan los componentes entre ellos. Si existen muchas
relaciones entre los componentes, con muchas dependencias unos con otros, tendremos un
acoplamiento alto. Si por el contrario los componentes son independientes unos de otros, el
acoplamiento será bajo. En este caso, es mejor tener un grado de acoplamiento bajo, pues minimiza el
efecto de onda (la propagación de errores), además de también minimizar el riesgo al cambiar de un
módulo por otro y facilitar el entendimiento.

Principales errores en el diseño
A continuación vamos a ver una lista de los errores que se suelen cometer en la fase de diseño.
1. Se tiende a tener mucha prisa por empezar a programar. Sin embargo, está demostrado que
cuanto antes se empiece a escribir código, más tarde se acabará el programa.
2. Se tiende también a no detallar de forma exhaustiva las especificaciones del diseño.
3. A veces también falta documentación de la etapa de diseño. Aunque se crea que no, la
documentación siempre es tanto o más importante que lo que se implementa.
4. No tener en cuenta el entorno físico. El equipo de desarrollo debe saber dónde va a montar el
software que esta desarrollando. Por ejemplo, no es lo mismo montarlo en una arquitectura
RISC, con un tamaño de memoria grande o pequeño… Todas esas cosas hay que estudiarlas
también.
Documento final de diseño
Vemos a continuación cuáles son los puntos que debe tener un documento de diseño bien realizado:
1. Introducción
1.1. Propósito del documento
1.2. Entorno hardware y software
1.3. Principales funciones del software
1.4. Bases de datos externas
1.5. Restricciones y limitaciones
1.6. Referencias
2. Descripción del diseño
2.1. Diagramas
2.2. Descripción de datos
2.3. Descripción de interfaces
2.4. Descripción de comunicaciones
3. Descripción de los módulos (para cada módulo)
3.1. Descripción
3.2. Descripción de la interfaz
3.3. Módulos relacionados
3.4. Organización de los datos
4. Descripción de archivos externos y datos globales
4.1. Descripción
4.2. Métodos de acceso

Tema 05. Codificación, pruebas, entrega y finalización
CODIFICACIÓN
El objetivo de esta etapa es traducir las especificaciones del diseño en un lenguaje de programación. Las
salidas esperadas de esta fase de codificación son los programas, el documento de diseño modificado, el
manual técnico y el manual para el usuario.
PRUEBAS
Un error de software se produce cuando el software no hace lo que el usuario espera que haga, acordado
previamente en la especificación de requisitos. Una prueba es el proceso de ejecutar un software con el
fin de encontrar errores. A veces se tiene una idea incorrecta de lo que es probar un sistema, como vemos
en las siguientes citas:
 “Probar es demostrar que no hay errores en el programa”.
 “Probar es demostrar que el programa funciona correctamente”.
El objetivo de las pruebas es descubrir errores cometidos durante las fases anteriores de desarrollo del
producto, no demostrar que el programa funciona. Los mejores casos de prueba son aquellos que tienen
una alta probabilidad de mostrar un error que no ha sido descubierto hasta entonces.

Tenemos que diferenciar entre lo que es verificación y lo que es validación. En la verificación se estudia
si el software que hemos construido se ha construido de forma correcta. Responde a la pregunta “¿se ha
construido el sistema correctamente?”. Mientras que en la validación se comprueba que lo que se ha
construido es realmente lo que se tenía especificado en los requisitos de usuario. Es decir, en la
validación, por mucho que funcione perfectamente el sistema, si no hace lo que yo le pido, no es correcto.
Eso es lo que se quiere evaluar. Responde a la pregunta “¿se ha construido el sistema correcto?”.
Principios
Cuando se realizan pruebas a un determinado software, se deben seguir una serie de pautas.
- Cada uno de los resultados de estas pruebas debe ser inspeccionado cuidadosamente.
- Todos los casos de prueba deben ser escritos tanto para entradas válidas y esperadas como para
entradas no válidas e inesperadas.
- El programador del software no debe ser el único que pruebe su propio programa, pues se suele
tender a no encontrar errores en el propio código de alguien. Es por esto por lo que es bueno
que las pruebas las realice un equipo distinto al que realizó la codificación.
- Además de que con las pruebas hay que verificar si un programa hace o no hace lo que debería
hacer, también hay que verificar que hace o no hace lo que no debería de hacer.
- Es importante documentar los casos de prueba. Esto permite reejecutarlos en el futuro (pruebas
de regresión).
- Hay que evitar las pruebas no reproducibles o “sobre la marcha”.
Pruebas en todo el ciclo de vida
Las pruebas no solo se realizan sobre el código una vez implementado. Las pruebas se van realizando a
lo largo de todo el ciclo de vida de un proyecto software, tanto en el análisis de requisitos como en la
etapa de diseño.

En el análisis de requisitos se comprueba que no haya requisitos no identificados o requisitos
redundantes o contradictorios. En la etapa de diseño se comprueba que el diseño abarque todos los
requisitos descritos anteriormente, y que la solución elegida para implementarlo sea la más simple
posible.
Por su parte, las pruebas realizadas sobre la etapa de codificación son bastante exhaustivas. En ellas se
realizan inspecciones de código. Este tipo de pruebas, como hemos comentado antes, suelen realizarse
por un equipo que incluye personas ajenas al proyecto, participantes en otras fases del proyecto y
personal del grupo de calidad.
Pruebas basadas en ordenador: técnicas
Pruebas de caja negra

Las pruebas de caja negra son pruebas de software en las cuales se verifica la funcionalidad sin tener en
cuenta la estructura interna del código, detalles de implementación o escenarios de ejecución internos
en el software.
En este tipo de pruebas nos enfocamos solamente en las entradas y salidas del sistema, sin preocuparnos
en tener conocimiento de la estructura interna del programa de software. Para obtener el detalle de
cuáles deben ser esas entradas y salidas, nos basamos en los requisitos de software y especificaciones
funcionales.

En las pruebas de caja negra se intentan buscar situaciones donde el programa no se ajusta a su
especificación. Para ello tenemos los casos de prueba. Los casos de prueba son un conjunto de datos de
entrada que deben generar una salida en concordancia con la especificación.
Para llevar a cabo las pruebas de caja negra primero se realiza una partición de equivalencia. Esto es, se
divide el dominio de entrada de un programa en un número finito de clases de equivalencia de las que
puedan derivar casos de prueba con el objetivo de reducirlos. Se hacen en dos pasos:
1. Identificar las clases de equivalencia. Conjunto de datos que definen las entradas validas y no
validas al sistema.
2. Identificar los casos de prueba.
En estas pruebas se deben hacer un Análisis de Valores Límite (AVL), en el cual se seleccionan casos de
prueba que ejerciten valores límite de cada clase de equivalencia.
Pruebas de caja blanca
Las pruebas de caja blanca se centran en probar el comportamiento interno y la estructura del programa
examinando la lógica interna de los módulos. Para ello es necesario ejecutar todas las sentencias al
menos una vez, recorrer todos los caminos independientes de cada módulo, comprobar todas las
decisiones lógicas y comprobar todos los bucles. Recordemos que el objetivo de las pruebas es encontrar
errores, por lo que se intenta provocar situaciones extremas que nos digan cómo de bien se comporta
el programa.
Idealmente, para examinar completamente la lógica de cada módulo habría que ejecutar todos los
posibles caminos, bucles, secuencias… Pero como esto es imposible, entonces hay que intentar, con el

menor número de casos, ser lo más eficiente posible y probar los caminos que nos pueden llevar antes
a encontrar errores.
Hay diversas técnicas de caja blanca, entre ellas:
• Pruebas de interfaz. Este tipo de pruebas analizan el flujo de datos que pasa a través de la
interfaz (tanto interna como externa) del módulo.
Para las interfaces internas se comprueban los argumentos que se pasan entre funciones, así
como la consistencia de las definiciones de variables globales entre los módulos. Debemos tener
en cuenta que lo deseable de un buen código es que tenga el menor número de variables globales
compartidas.
Por otra parte, en el caso de las interfaces externas lo que se comprueba es cómo se gestionan
los ficheros, si se declaran correctamente los atributos, si se abren correctamente los ficheros, si
se manejan correctamente las condiciones de fin de fichero y si se manejan correctamente las
condiciones de E/S.

• Pruebas de estructuras de datos locales. Estas pruebas comprueban la integridad de los datos
durante la ejecución del módulo. Para ello se fijan en que el acceso sea correcto, es decir, que se
utilizan variables inicializadas, no se salen del límite de matrices o vectores… Con respecto a la
declaración de datos, comprueban que todas las declaraciones son correctas (en longitud,
tipo…). Además, también se calculan errores como el overflow, underflow, división por cero… y
se comprueba también que no se hacen comparaciones entre variables de distinto tipo.
• Pruebas del camino básico. Este tipo de pruebas permiten obtener una medida de la
complejidad de la lógica del diseño detallado, y se usa esa medida para definir un conjunto básico
de caminos de ejecución usando la complejidad ciclomática (medida calculada a partir de la
complejidad del módulo). Para realizar estas pruebas se siguen los siguientes pasos:
1. Dibujar el grafo de flujo.
2. Determinar la complejidad ciclomática del grafo.
3. Determinar el conjunto base de caminos linealmente independientes.
4. Preparar los casos de prueba que forzarán la ejecución de cada camino.
Para determinar el conjunto base, es decir, los caminos independientes, es necesario:
1. Asegurarnos de que hay solo un nodo inicial y un nodo final.
2. Hay que seleccionar un camino funcional, que pudiera ser el más importante a ojos del
probador, y agregarlo al conjunto base.
3. Fijar el num_caminos en 1.
4. Mientras existan nodos de decisión con salidas no utilizadas y num_caminos sea menor
que v(G): seguir un camino básico hasta uno de tales nodos, seguir la salida no utilizada
y buscar regresar al camino básico tan pronto como sea posible, y agregar el camino al
conjunto base e incrementar num_caminos en 1.
Un módulo con complejidad ciclomática mayor de 10 debe ser examinado para posibles
simplificaciones o partirlo en varias subrutinas.
• Pruebas de condiciones límite o pruebas de bucles. Son pruebas centradas en validar la
construcción de los bucles. Hay que diferenciar cuatro distintos tipos de estas pruebas: bucles
de condición simple (condiciones booleanas), condiciones compuestas o bucles anidados, bucles
concatenados y bucles no estructurados. A cada bucle se le debería aplicar un número de
pruebas que los ejecutará exhaustivamente.
En los bucles simples, si 𝑛 es el número de pasos, primero no ejecutaremos el bucle. En la
siguiente prueba lo ejecutaremos solo una vez, luego dos veces... Y así hasta hacer 𝑚 pasos,
siendo 𝑚 un número menor que 𝑛. Y por último nos centraremos en hacer el paso n-1 y el n+1.
En el caso de los bucles anidados extenderemos el enfoque de pruebas de los bucles simples a los
anidados. El número posible de pruebas aumentaría geométricamente a medida que crece el
nivel de alineamiento. Esto llevaría a un número impracticable de pruebas. Por ello, primero
comenzaremos con el bucle más interno, poniendo el resto a los valores mínimos. Llevaremos a
cabo las pruebas para bucles simples para el bucle más interno.
En el caso de bucles concatenados, se prueban empleando el enfoque definido para los bucles
simples si cada uno de los bucles fuera independiente. Sin embargo, si los bucles están
concatenados y el contador del bucle 1 se emplea como valor inicial para el bucle 2, entonces los
bucles no son independientes. Si sucede esto, se recomienda el enfoque aplicado a los bucles
anidados.
Los bucles no estructurados, siempre que sea posible, deben diseñarse de nuevo para soportar el
uso de estructuras de programación estructurada.
Diseño de casos de prueba
El objetivo del diseño de los casos de prueba es crear el subconjunto de todos los posibles casos de
prueba que tiene la mayor probabilidad de detectar el mayor número posible de errores. Esto se realiza
mediante técnicas de caja negra, y después se completa creando casos suplementarios que examinen la
lógica del programa (caja blanca).
Estrategia de pruebas

La estrategia es realizar las pruebas desde dentro hacia fuera, comenzando por los módulos unitarios y
acabando con el sistema completo.
Pruebas unitarias
Estas pruebas comprueban la lógica, la funcionalidad y si es correcta la especificación de cada módulo.
Se corresponden con la prueba de cada módulo del programa y las realiza el programador en su entorno
de trabajo. El objetivo es probar los bloques más pequeños del programa. Tiene la ventaja de que, si se
encuentra un error, éste estará más localizado, y además se pueden probar simultáneamente varios
módulos.
Estas pruebas tienen el enfoque de pruebas de caja blanca. Se examinan las interfaces y su funcionalidad.
La prueba de unidad se simplifica cuando se ha diseñado un módulo con alto grado de cohesión.
Para realizar estas pruebas se crea un módulo conductor, que es un módulo específicamente creado para
la prueba que llama al módulo a probar. Además, también se crean módulos de resguardo (o auxiliares),
que son creados específicamente para la prueba y son llamados por el módulo a probar.

Pruebas de integración
Estas pruebas consisten en integrar los módulos centrándose en probar sus interfaces. Tienen un
enfoque más parecido a la caja negra. En este tipo de pruebas hay que determinar la manera en la que
se combinan los distintos módulos. Esto se realiza mediante pruebas no incrementales (big bang) o
mediante pruebas incrementales (descendentes, ascendentes, sándwich).
Pruebas de integración ascendentes
Este tipo de pruebas comienzan con los módulos terminales y se integra de abajo hacia arriba. Para ello
se utilizan módulos conductores. Las fases por las que se pasa son las siguientes:
1. Se combinan módulos del nivel más bajo en grupos.
2. Se construye un conductor para coordinar la entrada y la salida de los casos de prueba.
3. Se prueba el grupo.
4. Se eliminan los conductores y se combinan los grupos moviéndose hacia arriba por la estructura
del programa.
Veamos un ejemplo:

En este esquema el primer paso a realizar sería el siguiente:
El siguiente paso sería continuar en sentido ascendente:

Por último, el siguiente paso sería llegar hasta el nivel más arriba:

Pruebas de integración descendentes
Estas pruebas son contrarias a las ascendentes. Comienzan por el módulo superior y continúan hacia
abajo por la jerarquía de control (ya sea en profundidad o en anchura). Para ello se utilizan módulos de
resguardo. Las fases por las que se pasa son las siguientes:
1. Se usa el módulo de control principal como conductor de pruebas, construyendo resguardos
para los módulos inmediatamente subordinados.
2. Se sustituyen uno a uno los resguardos por los módulos reales.
3. Se prueba cada vez que se integra un módulo.
4. Al acabar las pruebas, se reemplaza otro resguardo por el módulo real.
5. Se hacen pruebas de regresión, es decir, se repiten ciertos casos de prueba para asegurar que no
se introducen nuevos errores,
En el mismo ejemplo de antes, veamos ahora los pasos:

Pruebas de integración sándwich

Este tipo de pruebas combina las aproximaciones ascendentes y descendentes. Se aplica a la integración
ascendente en los niveles inferiores de la jerarquía de módulos y, paralelamente, se aplica la integración
descendente en los niveles superiores de la jerarquía de módulos. La integración termina cuando ambas
aproximaciones se encuentran en un punto intermedio de la jerarquía de módulos.
Elección del módulo crítico
¿Cómo sabemos qué modulo integrar en cada momento? Para ello, nos tenemos que fijar en los módulos
críticos. Un módulo crítico es aquel que cumple alguna de estas características:
• Está dirigido a varios requisitos del software.
• Tiene un nivel de control alto.
• Es complejo o contiene un algoritmo nuevo.
• Es propenso a errores.
• Tiene unos requisitos de rendimiento muy definidos o estrictos.
Pruebas de validación
En estas pruebas se comprueba que se cumplen los requisitos. Los requisitos de validación se han
acordado antes de la fase de definición de requisitos. La técnica utilizada para este tipo de pruebas es la
de caja negra. Consta de dos partes:
1. La validación por parte del usuario para comprobar si los resultados producidos son correctos.

2. La utilidad, facilidad de uso y ergonomía de la interfaz de usuario.
Existen dos tipos de pruebas de validación: las pruebas alfa y las pruebas beta.
1. Pruebas alfa. Las lleva a cabo el cliente en el lugar de desarrollo.
2. Pruebas beta. Las lleva a cabo el cliente en su entorno. El desarrollador no está presente
normalmente.
Pruebas del sistema
En este tipo de pruebas se prueba el sistema integrado en su entorno, tanto hardware como software,
para verificar que cumple con los requisitos especificados.
Estas pruebas constan de:
• Pruebas de interfaces externas.
• Pruebas de volumen.
• Pruebas de funcionamiento.
• Pruebas de recuperación.
• Pruebas de seguridad.
• Pruebas de resistencia (en condiciones de sobrecarga o límites).
• Pruebas de rendimiento/comportamiento (en condiciones normales).
• Pruebas de fiabilidad.
• Pruebas de documentación (adecuación de la documentación de usuario).
Pruebas de aceptación
Son el último paso antes de la entrega formal del software al cliente y se realiza normalmente en el
entorno del usuario. Consisten en la aceptación por parte del cliente del software desarrollado.
Comprueban que el sistema está listo para su uso operativo.
Veamos un resumen de los entornos en los que se realiza cada una de las pruebas que acabamos de
explicar:

Pruebas de sistemas orientados a objetos
Para probar los sistemas orientados a objetos basta con que sigamos los siguientes pasos:

1. Probar los métodos de las clases.
2. Probar las clases individuales.
3. Probar agrupaciones de objetos.
4. Probar el sistema entero.
Depuración
La depuración es el proceso de eliminación de errores software mediante la detección de las causas a

partir de los síntomas. Los pasos que se siguen en la depuración son:
1. Especificación de desviación (¿qué, cuándo y en qué condiciones?).
2. Determinar la ubicación y la causa.
• Trazar.
• Volcados de memoria.
• Vuelta atrás.
• Uso de herramientas automáticas.
3. Corregir.
Prevención de errores
Para prevenir errores, se puede introducir precisión en el proceso de desarrollo software, establecer
una verificación al final de cada fase antes de comenzar la siguiente o establecer diferentes procesos de
pruebas.
Principales errores en la fase de pruebas
Los principales errores que podemos encontrar en la fase de pruebas son:

• Suponer que no se van a encontrar errores.
• Efectuar pruebas solo por el programador que ha realizado el programa.
• No especificar el resultado esperado.

• No probar para condiciones inválidas.
Para evitar estos errores, se establecen unas recomendaciones.
• Documentar los casos de prueba, de forma que se puedan ejecutar de igual forma en el futuro y
así evitar tener que reinventarlos.
• Enfocarse en el riesgo, de manera que se centre en los módulos más complejos y en los que
podrían hacer el mayor daño si fallan.
• Minimizar la complejidad de los módulos
• Diseñar las pruebas de unidad de forma sistemática.
• Hay que recordar que también se pueden cometer errores en las pruebas.
Unidad 06. Mantenimiento
El mantenimiento de un producto software comprende la modificación de dicho producto después de
haber sido entregado a los clientes con el fin de corregir defectos, mejorar el rendimiento u otros
atributos, añadir funcionalidades o adaptarlo a un cambio en su entorno.
Es el conjunto de actividades que se realizan sobre el software una vez que éste está operativo, es decir,
después de la entrega. Cubre la vida de un sistema software desde que se instala hasta que se reemplaza
o se da de baja.
El mantenimiento tiene una serie de problemas que el desarrollo no tiene, y que dificultan su realización
y aumentan su coste. En un producto software hay que preocuparse por la “mantenibilidad” (facilidad
de mantenimiento) durante el proceso de desarrollo de software. Es decir, siempre hay que tener en
cuenta la claridad, la modularidad, la extensibilidad y flexibilidad del diseño y realizar una buena
documentación tanto interna como externa. El llevar a cabo el mantenimiento de forma planificada
facilita y reduce su coste.
Muchas veces damos poca importancia al mantenimiento. Sin embargo, también los costes intangibles
derivados de una inadecuada estrategia de mantenimiento nos pueden perjudicar mucho. Por ejemplo,
la disminución de la calidad global del software o de la satisfacción del cliente. Cuanto más nos hayamos
preocupado por la mantenibilidad durante el proceso de desarrollo, más fácil será hacer el

mantenimiento ahora.
La “mantenibilidad” es la facilidad de corregir, adaptar o mejorar el software, y es uno de los atributos
de la calidad del software, por lo que nos tenemos que preocupar de ella durante todo el ciclo de vida
del proyecto. Esto implica principalmente ir realizando las distintas fases del ciclo de vida siguiendo los
principios de ingeniería del software y revisando los resultados al final de cada etapa. Por ejemplo, en
análisis hay que asegurarse de que el conjunto de requisitos es completo. En diseño hay que cumplir los
principios básicos: modularidad, abstracción, ocultamiento de datos, y cumplir las métricas de bajo
acoplamiento y alta cohesión, de tal forma que tengamos un diseño claro y fiable. En la codificación
debemos hacer y seguir una guía de estilo que nos proporcione un código legible y estructurado, así
como documentar el código. Y, en general, generar una buena documentación, que nos va a servir de
mucha ayuda durante el mantenimiento. En resumen, debemos hacer de la mantenibilidad uno de los
objetivos del proceso de desarrollo.
TIPOS DE MANTENIMIENTO
Mantenimiento correctivo (20%)
Se basa en modificar el sistema tras haber detectado algún defecto, ambigüedades o errores. Incluye el
diagnóstico y la corrección de errores. Puede ser de dos tipos: de emergencia o planificado.
Mantenimiento adaptativo (25%)
En este tipo de mantenimiento se trata de modificar el sistema para acomodarlo a cambios físicos del
entorno. Incluye:
• Actividades para ajustar el software a un entorno nuevo.
• Actividades para añadir nuevos periféricos.
• Actividades para ajustar el software a cambios en fuentes externas.

Mantenimiento perfectivo (50%)
En este tipo de mantenimiento se intenta mejorar el sistema para que cumpla con las nuevas
necesidades o requerimientos de los usuarios o del negocio. Incluye:
• Mejoras en el software para aumentar la eficiencia, el rendimiento…
• Las actividades necesarias para cumplir nuevos requisitos relativos a fuentes externas (como
por ejemplo un nuevo formato de informes).
Mantenimiento preventivo (5%)
Con el mantenimiento preventivo se trata de modificar el sistema con los cambios necesarios para que
se mantenga la eficiencia y fiabilidad del software. Incluye:
• Revisión periódica de equipos, periféricos y protocolos asociados.
• Pruebas y revisiones periódicas del software.
• Aumentar el tamaño previsto de los ficheros o bases de datos.
Mantenimiento estructural (reingeniería)
El mantenimiento estructural es un tipo de mantenimiento preventivo. Se basa en modificar la
arquitectura interna del sistema con el objetivo de mejorar su mantenibilidad. Incluye:
• Mejorar la documentación existente.

• Reestructurar el código para mejorar la legibilidad.
• Efectuar reingeniería software para incrementar la modularidad.
¿Por qué hay que hacer mantenimiento estructural? Es necesario porque el software no se rompe, sino
que se deteriora y su mantenimiento es mucho más costoso con el tiempo.
REINGENIERÍA
Es el proceso de examinar un sistema software existente y modificarlo (reconstruirlo) con la ayuda de
herramientas automáticas para mejorar su mantenibilidad, incrementar su calidad y aumentar su vida.
Normalmente se cambia la forma del software, no la funcionalidad. Es decir, se suele, por ejemplo, hacer
el código más estructurado o un diseño más completo.
Los tipos de reingeniería son la reestructuración, la ingeniería inversa y la migración.
Ingeniería inversa
Es un proceso que incluye analizar un código o descripción física (análisis, diseño…) de un sistema
software, además de recuperar el nivel de abstracción anterior con la ayuda de herramientas
automáticas. La ingeniería inversa no cambia lo que hace el software sino que transforma la
representación de este software a una forma más fácil de entender, más clara y completa.

¿Cuándo podemos aplicar la reingeniería? Hay algunos sistemas candidatos en los que se puede aplicar:
• Cuando hay una importancia crítica para la empresa.
• Cuando los fallos son frecuentes y difíciles de encontrar.
• Cuando surgen problemas de eficiencia o rendimiento.
• Cuando es difícil de modificar.
• Cuando es difícil de probar.
• Cuando hay un mantenimiento frecuente.

• Cuando el sistema es caro de mantener.
• Cuando solo es mantenible por un número pequeño de personas.
• Cuando los problemas van en aumento.
ESTRATEGIAS DE MANTENIMIENTO
Existen diversas estrategias de mantenimiento, entre las que podemos encontrar:
Mantenimiento estructurado/planificado
En este tipo de estrategia de mantenimiento se acumulan las peticiones de cambio aceptadas y se

realizan todas a la vez cada cierto tiempo en fechas planificadas.
Mantenimiento no estructurado
Este tipo de estrategia de mantenimiento es bajo demanda. Cada vez que llega una petición, se resuelve
y se implementa.
Mantenimiento combinado
En este tipo de estrategia de mantenimiento, el mantenimiento es estructurado, y no estructurado

cuando hay emergencias. Suele ser el tipo de estrategia más beneficiosa para la empresa desarrolladora.
Lo primero que se hace es evaluar la petición de cambio. Si es viable, se analiza su severidad, es decir,
cómo de grave es para el sistema informático y su entorno. Si no es muy severa, se encola y se realizará
en las fechas de mantenimiento ya planificadas. Si es muy grave, se atenderá inmediatamente
resolviendo la incidencia. En este caso, normalmente las peticiones que se tratan bajo demanda son las
de tipo correctivo y cuando el error es grave. Los demás tipos de mantenimiento habitualmente pueden
esperar a cuando esté planificada su realización.

COSTE DEL MANTENIMIENTO
Alrededor del 80%-90% del presupuesto de las empresas se gasta en mantenimiento. El mantenimiento
de una aplicación grande consume entre 2 y 4 veces más recursos que el desarrollo de la misma. Los
costes de mantenimiento, sin embargo, son difíciles de estimar.
Costes intangibles
Estos costes son derivados de una mala planificación o estrategia de mantenimiento. Se pueden generar
por la pérdida de una oportunidad de un nuevo proyecto, por la insatisfacción del cliente o por una
disminución de la calidad global del software.
DOCUMENTOS
En el proceso de mantenimiento se han de realizar varios documentos. Antes de realizar cualquier

actividad, debemos firmar con el cliente el contrato de mantenimiento, donde se recogen todas las
condiciones bajo las que se realizará el servicio. Justo al inicio, se debe llevar a cabo el plan de
mantenimiento, donde se establece qué vamos a hacer, quién, cuándo y cómo. Al igual que el plan de
desarrollo, debe irse actualizando a lo largo del proyecto.
Por otra parte, se ha de crear un formulario de petición de mantenimiento, de tal forma que el cliente
solicite su petición siempre a través de este formulario y del medio que se haya acordado.
Finalmente, el informe de cambios recoge los detalles del cambio ya realizado, incluyendo objetivos,
fecha, esfuerzo, persona encargada del cambio…
Tampoco hay que olvidarse de documentar todos los programas que se cambian, para que queden
registradas todas las modificaciones que se vayan realizando
Unidad 07. Gestión de la Configuración del Software
La configuración del software es el estado actual del sistema software y las interrelaciones que existen
entre sus componentes constitutivos, es decir, entre el código fuente, los datos y la documentación.
La gestión de configuración del software (GCS) es una disciplina cuya misión es identificar, controlar
y organizar la evolución de un sistema software. Permite controlar formalmente la evolución y los
cambios del software, garantizando la visibilidad en el desarrollo y en el producto, y la trazabilidad en
el producto durante todo su ciclo de vida.
Los sistemas software tienen una “vida larga”, y todos ellos cambian a lo largo de esta vida. Pasan por
diferentes versiones, plataformas… Se tiene que asegurar que los cambios producidos ocasionen el
mínimo coste. La gestión de configuración del software asegura:
• La coherencia entre versiones.
• Seguridad ante pérdidas de software o de personal.
• Reutilización de software.
• Poder recuperar cualquier versión realizada por cualquier desarrollador en cualquier momento.
• Calidad, pues únicamente se aceptan los elementos formalmente revisados y aprobados.
El objetivo de la gestión de configuración del software es establecer y mantener la integridad de los
productos generados durante un proyecto de desarrollo de software y a lo largo de todo el ciclo de vida.

ELEMENTOS DE CONFIGURACIÓN DEL SOFTWARE
La GCS actúa sobre programas, documentos y datos. Un elemento de configuración del software
(ECS) es cada uno de los componentes básicos de un producto software sobre los que se realiza un
control. Tiene un nombre y puede evolucionar.
Los elementos de configuración del software cumplen dos condiciones: evolucionan en el tiempo y nos
interesa controlar esa evolución.
Líneas base
Una línea base es un punto de referencia en el proceso de desarrollo del software a partir del cual las
revisiones de los elementos de configuración del software se han de realizar de manera formal. Su
objetivo es controlar los cambios en el software sin impedir llevar a cabo aquellos que sean justificados.
Las líneas base se definen al comienzo del proyecto, y suelen coincidir con los hitos marcados.
Generalmente se corresponden con los resultados de las fases.
Los tipos de líneas base son:
• Línea base funcional. Después de la fase de análisis.
• Línea base de diseño. Después de la fase de diseño.
• Línea base de producto. Después de las pruebas, cuando tengamos un producto final estable.
• Línea base operativa. Después de entregar el sistema final.
Estas son las líneas base más habituales, pero pueden variar.
Las líneas base tienen como objetivo secundario:
• Identificar los resultados de las tareas realizadas en cada fase.
• Asegurar que se ha completado la fase.

• Servir como punto de partida para los desarrollos posteriores.
• Servir como punto de partida para las peticiones de cambio.
Una vez que se ha desarrollado y revisado un elemento de configuración, pasa a formar parte de la
siguiente línea base planificada del proyecto. Esto es lo mismo que decir que el elemento se convierte
en línea base.
Cuando un ECS se convierte en una línea base se introduce en una Base de Datos del proyecto. A partir
de aquí el elemento se debe modificar siguiendo un procedimiento establecido. El objetivo es que se
puedan hacer los cambios necesarios pero de manera controlada y con previa autorización.
Los cambios de un elemento de una línea base producen la creación de una nueva versión del elemento.
Estos son los pasos que hay que seguir cuando un elemento de configuración del software se convierte
en una línea base y se quieren controlar sus cambios:
1. Petición de cambio.
2. Evaluación del esfuerzo, efectos secundarios, alcance… del cambio.
3. Generación de un informe de cambios.
4. Autorización.
5. Emisión de una orden de cambio.
6. Baja en la Base de Datos de proyectos del elemento a cambiar.
7. Realización del cambio.

8. Pruebas.
9. Alta del elemento en la Base de Datos de proyectos.
10. Uso de mecanismos apropiados de cambio de versiones.
HERRAMIENTAS DE GESTIÓN DE CONFIGURACIÓN DEL SOFTWARE

La gestión de configuración del software siempre se realiza con herramientas automáticas. Las dos más
conocidas son SVN y Git. Ninguna es mejor que otra, sino que cada una es más adecuada dependiendo
de las características del proyecto.
SVN
Es un software libre de código abierto desarrollado para la gestión de configuraciones. Sustituye a CVS.
Este software compara versiones anteriores, caza errores regresivos, mantiene ramas compatibles con
las versiones anteriores, produce registros de cambios…
Un repositorio Subversion se comporta como un sistema de ficheros que recuerda conjuntos de cambios
que se le han hecho. Esto lo hace almacenando ficheros en forma de árbol, llevando un control de su
evolución a lo largo del tiempo.
La diferencia entre SVN y Git es que Git modela sus datos más como un conjunto de instantáneas de un
mini sistema de archivos. Cada vez que se confirma un cambio, Git básicamente hace una foto del aspecto
de todos los archivos en ese momento, y guarda une referencia a esa instantánea. Para ser eficiente, si
los archivos no se han modificado, Git no almacena el archivo de nuevo, solo un enlace al archivo anterior
idéntico que ya tiene almacenado.
En la siguiente imagen vemos en la parte de arriba cómo SVN almacena los datos, mientras que en la
parte de abajo vemos cómo lo hace Git.

Unidad 08. Aseguramiento de calidad
Antes de comenzar el tema tenemos que saber cuál es la diferencia entre Quality Assurance (o calidad
del software) (QA) y Verificación-Validación (V&V). V&V trata las actividades técnicas, es decir los
errores técnicos del software, los errores humanos. QA, sin embargo, trata las actividades de gestión.
Trata fallos y defectos de calidad del software. Los defectos pueden venir por la falta de información en
la parte de requisitos, diseño o código, y los fallos pueden generarse por la manifestación de una falta
en el Sistema.
¿Cuándo podemos decir que un proyecto software es de calidad? La calidad de un proyecto software
depende tanto de que el producto como el proceso sean de calidad, aun teniendo presente que es
imposible asegurar esto al 100%. Cuando hablamos de la calidad de un producto, hacemos referencia a
que un producto cumpla con los requisitos definidos (requisitos funcionales, requisitos no funcionales
y requisitos implícitos). Por su parte, un proceso será de calidad cuando sea eficiente, productivo y

cumpla con las estimaciones previstas. Según el estándar IEEE, “la calidad del software es el grado en
que un sistema, componente o proceso cumple los requisitos especificados y las necesidades o expectativas
del cliente o usuario”. En general, un proceso será de calidad si satisface tanto al cliente como a todos los
participantes involucrados en ese proyecto. Si alguna de las partes no está satisfecha, el proyecto no se
puede considerar de calidad. Por lo tanto, se tiende a que en un proyecto todos salgan ganadores, lo que
se conoce como Win-Win.
FACTORES QUE DETERMINAN LA CALIDAD DEL SOFTWARE

Hay factores que determinan la calidad del software. Algunos se pueden medir directamente, y otros no.
Entre los factores medibles encontramos:
• Los errores reportados.
• El número de documentos generados.
• El número de peticiones de cambio.
• El número de test de pruebas satisfactorias.
• Algunos más.
Entre los que no pueden ser medidos directamente nos encontramos:
• La facilidad de uso.
• La facilidad de pruebas.
• La facilidad de mantenimiento.
• Algunos más.
MEDIDAS DE ASEGURAMIENTO DE CALIDAD DEL SOFTWARE (SQA)

Las medidas de aseguramiento de la calidad del software son las medidas que podemos aplicar en
nuestro proyecto para asegurar su calidad. O, si nuestro proyecto ha finalizado mal, cómo podemos
saber qué ha ocurrido y qué medidas aplicar para que lo sucedido no vuelva a pasar y los siguientes
proyectos no tengan estos problemas.
Las medidas SQA se pueden dividir en medidas constructivas y medidas analíticas.
Medidas constructivas
Los tipos de medidas constructivas son:
• Las medidas constructivas técnicas. Se basan en aplicar técnicas de ingeniería del software
para mejorar la calidad de los productos.
• Las medidas constructivas organizativas. Engloban la realización y el seguimiento de planes
para proporcionar una mejor calidad a los procesos software.
• Las medidas constructivas humanas. Establecen la formación que necesitan los
desarrolladores para realizar su trabajo con mayor calidad.
Medidas analíticas
Estas medidas se dividen en dinámicas y estáticas.
Medidas dinámicas
Las medidas dinámicas requieren la ejecución del objeto que está siendo medido o probado. Es decir,
hace referencia a las pruebas de software. Aplicar medidas dinámicas significa hacer pruebas del código.
Medidas estáticas
Las medidas estáticas analizan el objeto sin necesidad de ejecutarlo, y principalmente son revisiones
y auditorías.
Las revisiones son reuniones formales donde se analizan de forma estructurada los resultados,
parciales o totales, de un proyecto software. Sirven para detectar acciones del producto o proceso
respecto a las especificaciones iniciales, y se pueden realizar en todas las fases del ciclo de vida, aunque

son especialmente relevantes en las primeras para poder detectar desviaciones o errores cuanto antes,
y solventarlos. Los revisores deben ser externos al proyecto, aunque hay que decir que en el proceso de
revisión no siempre hay reuniones. Por ejemplo, si revisamos un documento, se trata de leer el
documento y extraer todo lo que pensemos que está mal y afecta a la calidad de ese producto. Lo normal
es: si se revisa entre varios, reunirse a continuación con el equipo de desarrollo para comunicarles los
resultados; pero si hay un único revisor, en ocasiones no es necesaria esta reunión.
Las auditorías tienen como objeto realizar una investigación, también externa al proyecto, para
determinar, por una parte, el lado de cumplimiento de estándares, requisitos, procedimientos y métodos
definidos; y por otra, la efectividad del proceso llevado a cabo. Pueden ser:
• De producto, cuando se cuantifica el grado de conformidad de un producto con los requisitos y
especificaciones definidas.
• De proceso, donde se evalúa el proceso de desarrollo o de gestión para determinar qué se puede
mejorar.
En ambos casos, revisiones y auditorías, se finaliza con un informe donde se describe el producto o
proceso revisado o auditado, y los resultados obtenidos. En cuanto a los resultados, es importante,
además decir los defectos encontrados en las áreas problemáticas y emitir recomendaciones sobre
posibles mejoras. En este sentido, los informes de revisión y de auditoría deben ser constructivos, donde
no solo digamos los problemas, sino cómo se pueden solucionar.
SISTEMAS SOFTWARE DE ALTA CALIDAD

Un sistema software de alta calidad debería:
1. Cumplir con un conjunto de requisitos funcionales claramente especificados.
2. Cumplir con un conjunto de factores de calidad del software medibles acordados previamente
entre el usuario y el desarrollador.
3. Cumplir plazos y presupuesto.

4. Mantenerse rentable durante el desarrollo y mantenimiento.
5. Ser útil para el usuario, mantenible y adaptable durante todo su ciclo de vida.
DOCUMENTACIÓN
El plan de aseguramiento de la calidad es una planificación de cómo se va a construir la calidad en el
software y cómo se va a evaluar. Este documento se debe producir en una fase muy temprana del
proceso de desarrollo. El contenido de este documento es:
• Un propósito.
• Documentos de referencia.
• Gestión.
• Documentación.
• Estándares, prácticas y convenciones.
• Revisiones y auditorías.
• Gestión de configuraciones.
• Gestión de errores.
• Herramientas, técnicas y metodologías.
• Control del código.
• Control del almacenamiento.
• Control de proveedores.

• Recogida, mantenimiento y retención de información.


Apuntes Teoria

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Apuntes Teoria

Cargado por

Copyright:

Formatos disponibles

Teoria.

Ingeniería del Software

3º Grado en Ingeniería Informática

Escuela Politécnica Superior

Reservados todos los derechos.

Tema 02. Metodologías, ciclos de vida y proceso software 8

Reservados todos los derechos.

Tema 03. Actividades tempranas en el desarrollo de software 17

Tema 04. Análisis y diseño 19

Tema 05. Codificación, pruebas, entrega y finalización 27

Unidad 06. Mantenimiento 38

Reservados todos los derechos.

Unidad 07. Gestión de la Configuración del Software 42

Unidad 08. Aseguramiento de calidad 45

El mejor palacio para que no tiemble tu Vida de Rico, aquí.

El mejor palacio para que no tiemble tu Vida de Rico, aquí.

Reservados todos los derechos.

Crisis del Software

Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

PROYECTO, PRODUCTO Y PROCESO

Reservados todos los derechos.

Trabajo operativo vs Proyecto

El trabajo operativo consiste en efectuar permanentemente actividades que generan un mismo

Reservados todos los derechos.

Actividades de un ingeniero de software

Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

METODOLOGÍAS Y CICLOS DE VIDA

Estudiar sin publi es posible. Compra Coins.

Reservados todos los derechos.

Modelo de ciclo de vida en cascada

Imagen 4. Modelo de ciclo de vida en cascada

Reservados todos los derechos.

Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

Modelo de ciclo de vida incremental

Reservados todos los derechos.

Imagen 6. Modelo de ciclo de vida incremental

Modelo de ciclo de vida iterativo

Compra Coins y descarga sin publicidad.

Reservados todos los derechos.

Imagen 8. Ejemplo modelos de ciclos de vida iterativo e incremental

El mejor palacio para que no tiemble tu Vida de Rico, aquí.

Reservados todos los derechos.

Reservados todos los derechos.

El mejor palacio para que no tiemble tu Vida de Rico, aquí.

Reservados todos los derechos.

Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

Reservados todos los derechos.

Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

Definición del ciclo de vida

Definición de estándares, métodos, técnicas y herramientas

El siguiente paso a realizar en el desarrollo de un proyecto es la definición de estándares, las

Reservados todos los derechos.

Definición de objetivos, entradas y salidas

Definición de criterios de calidad y validación

Creación del equipo de desarrollo final

El personal es el factor más importante en el éxito de un proyecto software. Lo podemos observar en la

Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

Reservados todos los derechos.

Estudiar sin publi es posible. Compra Coins.

Reservados todos los derechos.

Sólo por participar te llevas 10 WUOLAH COINS pinchando aquí!

Reservados todos los derechos.

Documento final de análisis