Fundamentos de Ingeniería del Software - Tercer

curso de Ingeniería Técnica Informática

Versión 0.4.8

23 de diciembre de 2006
Índice general
1. Introducción a la Ingeniería del Software 4
1.1. El software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Características del software . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Evolución del desarrollo del software . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Primera era (principio de los 50 a mediados de los 60) . . . . . . . 5
1.3.2. Segunda era (mediados de los 60 a nales de los 70) . . . . . . . . 6
1.3.3. Tercera era (nales de los 70 a principios de los 90) . . . . . . . . . 6
1.3.4. Cuarta era (de los 90 en adelante) . . . . . . . . . . . . . . . . . . 6
1.4. Problemas asociados al desarrollo de software . . . . . . . . . . . . . . . . 6
1.5. Las causas de los problemas en el desarrollo del software . . . . . . . . . . 7
1.6. Algunos mitos del desarrollo del software . . . . . . . . . . . . . . . . . . . 7
1.7. La Ingeniería del Software: deniciones, elementos y objetivos generales . 8
1.8. Visión general del proceso de la Ingeniería del Software . . . . . . . . . . . 9
1.8.1. Fase de planicación . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.8.2. Fase de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.8.3. Fase de mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9. Situación actual de la Ingeniería del Software . . . . . . . . . . . . . . . . 10

2. Introducción a los Sistemas de Información 11

2.1. Concepto de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Información y datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Enfoque sistémico u holístico para el estudio de sistemas . . . . . . . . . . 12
2.4. Sistema de Información (SI) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Denición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2. Elementos de un SI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3. Estructura de la información en un SI . . . . . . . . . . . . . . . . 14
2.5. Sistemas de Información Automatizados (SIA) . . . . . . . . . . . . . . . 15
2.6. Sistemas de Información básicos en las organizaciones . . . . . . . . . . . 16
2.7. La Ingeniería del Software en una organización . . . . . . . . . . . . . . . 16

3. El proceso software y modelos de proceso 17

3.1. El proceso software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Madurez del proceso software . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Estándares del proceso software . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1. Estándar IEEE 1074 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.2. Estándar ISO/IEC 12207-1 . . . . . . . . . . . . . . . . . . . . . . 21

1
 3.3.3. Estándar ISO/IEC 15505-2 . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Modelos de procesos del software . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1. Modelo en cascada o lineal secuencial . . . . . . . . . . . . . . . . 23
3.4.2. Modelo en cascada con prototipado desechable . . . . . . . . . . . 24
3.4.3. Modelos evolutivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.4. Modelo de desarrollo formal . . . . . . . . . . . . . . . . . . . . . . 28
3.4.5. Técnicas de 4a generación . . . . . . . . . . . . . . . . . . . . . . . 29

4. Métodos de desarrollo del software 30

4.1. Concepto de método . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2. Breve historia de los métodos . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3. Clasicación de los métodos . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4. Metodologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.1. Denición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.2. Estructura y componentes . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.3. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.5. Clasicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5. Metodologías ociales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.1. Merise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.2. SSADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.3. Métrica v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5. Ingeniería de Requisitos 38
5.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.1. Tipos de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.2. Problemas comunes . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2. Ingeniería de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3. El proceso de Ingeniería de Requisitos . . . . . . . . . . . . . . . . . . . . 39
5.4. Identicación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4.1. Técnicas o ayudas para la identicación de requisitos . . . . . . . . 40
5.5. Análisis y negociación de requisitos . . . . . . . . . . . . . . . . . . . . . . 42
5.6. Especicación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.6.1. Naturaleza de la especicación de requisitos . . . . . . . . . . . . . 43
5.6.2. Características de la especicación de requisitos . . . . . . . . . . . 43
5.6.3. Estructura de un documento de especicación de requisitos . . . . 44
5.6.4. Algunas técnicas de especicación de requisitos . . . . . . . . . . . 45
5.7. Validación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.8. El uso de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.8.1. Denición de prototipo . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8.2. Tipos de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8.3. Técnicas y herramientas . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8.4. Benecios de los prototipos . . . . . . . . . . . . . . . . . . . . . . 47

6. Modelado del análisis 48

7. Diseño del software 49

2
8. Técnicas y estrategias de prueba 50
8.1. Fundamentos de la prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.2. Principios de la prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.3. Técnicas de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.4. Diseño de casos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.4.1. Pruebas de caja blanca . . . . . . . . . . . . . . . . . . . . . . . . 53
8.4.2. Pruebas de caja negra . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.5. Estrategias de prueba del software . . . . . . . . . . . . . . . . . . . . . . 57
8.6. La depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.6.1. Enfoques para la depuración . . . . . . . . . . . . . . . . . . . . . 59

9. Ingeniería del Software Asistida por Ordenador 60

9.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1.1. Evolución histórica de las herramientas . . . . . . . . . . . . . . . 61
9.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.3. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.4. Elementos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.5. El repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.5.1. Funciones del repositorio . . . . . . . . . . . . . . . . . . . . . . . 62
9.5.2. Contenido del repositorio . . . . . . . . . . . . . . . . . . . . . . . 62
9.6. Taxonomías de herramientas . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.6.1. Clasicación por categorías . . . . . . . . . . . . . . . . . . . . . . 63
9.6.2. Clasicación por el nivel de integración . . . . . . . . . . . . . . . 63
9.6.3. Clasicación por su funcionalidad . . . . . . . . . . . . . . . . . . . 63
9.7. Plan para la adquisición e implantación de una herramienta . . . . . . . . 65
9.7.1. Planicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.7.2. Adquisición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.7.3. Introducción o implantación en un proyecto piloto . . . . . . . . . 66
9.7.4. Utilización o implantación en toda la organización . . . . . . . . . 66
9.8. Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3
Capítulo 1

Introducción a la Ingeniería del

Software
1.1. El software
El software no es sólo código, sino también las especicaciones del diseño, los datos
tratados y la documentación que permite el desarrollo, instalación y mantenimiento.
Estrictamente, se puede denir como:

Instrucciones que, cuando se ejecutan, proporcionan la funcionalidad deseada.

Estructuras de datos que facilitan a las instrucciones manipular adecuadamente la

información.

Documentos que describen el desarrollo, uso, instalación y mantenimiento de los

programas.

Se puede destacar, entre otras, la denición de software dada por el IEEE:

Aquellos programas de computador, procedimientos, reglas y documentación

posible asociada con la computación, así como los datos pertenecientes a las
operaciones de un sistemas de computación.

1.2. Características del software

El software presenta varias características.

Es un elemento lógico, no físico, en contraposición con el hardware.

Se desarrolla, no se fabrica. La fabricación consiste fundamentalmente en ensam-

blar componentes, punto al que no se ha llegado ni siquiera con la programación
orientada a objetos.

No se estropea, se deteriora. Con el tiempo, el hardware se va estropeando por la

presencia de componentes físicos. El software, al carecer de ellos, se deteriora, no

4
 estropea, aumentando el mantenimiento que necesita. Es el caso, por ejemplo, del
llamado código heredado.
El número de fallos sigue una curva teórica en la que, en la denominada fase ini-
cial, inmediatamente posterior a la implantación, se detectan muchos fallos que,
con el tiempo, se van corrigiendo, de forma que cada vez se detectan menos. Aún
así, sigue siendo necesario un mantenimiento para corregirlos, especialmente cuan-
do existe un gran volumen de cambios, como sucede en el software de gestión.
Pero en la realidad, cada vez que se resuelven un número determinado de errores
se publica una nueva versión sobre la que se detectan más, y, después de apare-
cer varias, la curva real supera bastante a la teórica, necesitando cada vez más
mantenimiento.

La mayoría se construye a medida en vez de ensamblar componentes existentes.

1.3. Evolución del desarrollo del software

Se puede dividir en varias eras que se detallan a continuación.

1.3.1. Primera era (principio de los 50 a mediados de los 60)

El hardware es muy caro y el software, en comparación, muy barato, por lo que se
le concede más importancia al primero y el segundo se considera un añadido. Además,
no existe la Ingeniería del Software, se aprende a través de cursos de programación, con
lo que el resultado termina siendo casi un método artesanal. El desarrollo se realiza a
medida y en lenguajes de muy bajo nivel (ensamblador), con los que se produce software
propietario.
El programador de la aplicación también la ejecuta y es el único que la conoce. El

5
tratamiento se realiza por lotes (procesos batch). En un proceso se ejecutan todos los
movimientos sin interactuar con el usuario.
A esta era la caracteriza la falta de documentación.

1.3.2. Segunda era (mediados de los 60 a nales de los 70)

Aparecen nuevos conceptos como la multiprogramación y el multiusuario, permitiendo
la interacción con éstos. Además, nacen las primeras empresas que desarrollan aplicacio-
nes para muchos usuarios en lugar de a medida, de forma que el software se convierte en
producto.
Nacen también los Sistemas de Gestión de Bases de Datos (SGBD), en contraposición
con el tratamiento de cheros que existía anteriormente, y que provocaba grandes incon-
sistencias debido a la existencia de información redundante.
Debido a la evolución del hardware, el rendimiento de éste ya podía inuir en el de las
aplicaciones, lo que permitió que surgieran las de tiempo real.
A esta era la caracteriza un incremento en el mantenimiento del software, en el que se
concentraban los recursos, en lugar de en el desarrollo. Este hecho se denomina crisis
del software.

1.3.3. Tercera era (nales de los 70 a principios de los 90)

Aparecen los primeros ordenadores personales y se abarata el coste del hardware.
Aparecen las redes de área local, los sistemas distribuidos, los primeros métodos estruc-
turados y la Ingeniería del Software, aunque el mantenimiento sigue siendo un problema.
A esta era la caracteriza que, con la popularización de los sistemas distribuidos y las
redes, antes citados, se complica el trabajo. Las aplicaciones poseen una complejidad de
la que carecían en eras anteriores (debido a las propias características de éstas).

1.3.4. Cuarta era (de los 90 en adelante)

Hasta la tercer era, la mayoría de procesos eran centralizados, pero en la cuarta, las
arquitecturas informáticas están cambiando de estos entornos de grandes computadoras
a entornos descentralizados cliente-servidor.
La tecnología orientada a objetos, surgida tiempo atrás con lenguajes como Smalltalk
y ahora popularizada por otros como C++ y Java, está desplazando rápidamente a
enfoques más tradicionales.
Nace Internet, que rápidamente se populariza.
La industria del software es una parte importante de la economía mundial. A esta era la
caracteriza la dependencia del software, por lo que se necesitan aplicaciones ables.

1.4. Problemas asociados al desarrollo de software

El desarrollo no satisface la demanda de software de la sociedad, sino que muchos
pedidos se atienden con retraso.
Además, se desarrollan aplicaciones cuyo mantenimiento consume demasiados recursos;
de media, un 75 % de los recursos de las organizaciones.

6
Existen dos razones fundamentales que provocan, con frecuencia, la insatisfacción del
cliente.

La baja productividad, que produce una acumulación de trabajo.

La calidad del software desarrollado es cuestionable.

En España se dan, además, otras situaciones:

Se desarrolla demasiado software a la medida y pocos paquetes.

No se desarrolla software de base: SSOO, SGBD, etc.

1.5. Las causas de los problemas en el desarrollo del

software
La primera de ellas es que los problemas están ligados a las propias características
del software, como que sea lógico en lugar de físico.
A esto se añade una corta experiencia (de unos 40 ó 50 años) y una industria que cambia
muy rápidamente y que provoca que los desarrolladores no tengan tiempo para adquirir
verdadera experiencia en una técnica, método o herramienta.
En contraposición, existe una resistencia al cambio por parte de los usuarios.
Por último, se podría citar también la existencia de una serie de mitos, armaciones con
cierta lógica o sentido intuitivo pero que son falsas. Estos mitos, ha menudo, han sido
expuestos o divulgados por los llamados gurús.

1.6. Algunos mitos del desarrollo del software

Muchas de las causas de la crisis del software se pueden encontrar en una mitología
que surge durante los primeros años del desarrollo del software.
A continuación se presentarán algunos de los mitos más destacables, con su enunciado y
a continuación la realidad:

Nuestra gente dispone de las herramientas de desarrollo de software más avanza-

das, después de todo, les compramos las computadoras más modernas.
Para producir software de calidad lo fundamental es aplicar la Ingeniería del Sof-
tware. Las herramientas CASE, por ejemplo, son más importantes que el último
modelo de computadora grande o de PC para conseguir buena calidad y producti-
vidad, aunque la mayoría de los desarrolladores del software todavía no las utilicen
ecazmente.

Si fallamos en la planicación, podemos añadir más programadores y adelantar el

tiempo perdido.
Cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el
equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo
productivo.

7
 Un conocimiento general de los requisitos es suciente para empezar a escribir los
programas.
Una mala denición inicial es la principal causa del trabajo baldío en software. Se
deben analizar de forma completa los requisitos.

Los cambios pueden acomodarse fácilmente, ya que el software es exible.

Los cambios aplicados sobre los resultados obtenidos en una fase más prematura
aumentan también el coste. Es decir, si se aplican sobre la implementación serán
más baratos que sobre el diseño, y en éste lo serán más que sobre el análisis.
Se ha de tener en cuenta, además, que el impacto del cambio varía según el momen-
to en que se introduzca. Si se pone cuidado al dar la denición inicial, los cambios
solicitados al principio pueden acomodarse fácilmente. Cuando los cambios se soli-
citan durante el diseño del software, el impacto en el coste crece rápidamente. Ya se
han acordado los recursos a utilizar y se ha establecido un marco de trabajo del di-
seño. Los cambios durante la implementación (codicación y prueba) pueden tener
un impacto importante sobre el coste. Cuando se solicitan al nal de un proyecto,
los cambios pueden producir un orden de magnitud más caro que el mismo cambio
pedido al principio.

No se puede comprobar la calidad hasta que los programas no estén ejecutándose.
Se deben ir realizando pruebas mientras se desarrolla. Además, desde el principio
del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar
la calidad del software: la revisión técnica formal.

Lo único que se entrega al terminar el proyecto es el programa funcionando.

Un programa que funciona es sólo una parte de una conguración del software que
incluye muchos elementos. La documentación proporciona el fundamento para un
buen desarrollo y, lo que es más importante, proporciona guías para la tarea de
mantenimiento del software.

Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha
terminado.
Los grupos de desarrollo de software no se disuelven hasta que éste no está implan-
tado.

1.7. La Ingeniería del Software: deniciones, elementos

y objetivos generales
El término Ingeniería del Software nació a nales de los años 60 en un congreso en
Alemania. Los grupos de trabajo que se formaron llegaron a la conclusión de que se
deben aplicar métodos, metodologías, técnicas y herramientas en un marco de gestión
adecuado. La Ingeniería del Software estudia dicho métodos, ténicas, etc., para resolver
el problema del desarrollo del software, y se puede denir de la siguiente forma:

La Ingeniería del Software es una disciplina que integra métodos, técnicas y

herramientas para el desarrollo de software de computadora.
Sus elementos son:

8
 Métodos: Conjunto de tareas ordenadas para conseguir un n. Los métodos se desa-
rrollaron para cada una de las fases del desarrollo (análisis, diseño, implementación,
etc.), y un conjunto de varios con una losofía común componen una metodología.

Técnicas: Ayudan con las dicultades para llevar a cabo lo que se indica en los
métodos.

Herramientas: Programas que mecanizan los métodos y las técnicas.

Y sus objetivos fundamentales son desarrollar software de calidad y de forma

productiva.

1.8. Visión general del proceso de la Ingeniería del Sof-

tware
El ciclo de vida del software se divide en varias fases desde que nace hasta que muere:

Planicación: Se identica el proyecto, se le da nombre y se dene el alcance.

Desarrollo: Se desarrolla e implanta.

Mantenimiento: Desde que se implanta hasta que se abandona.

1.8.1. Fase de planicación

Se realiza un inventario de todas las actividades que se realizan en una empresa y se
agrupan por proyectos estableciendo una correspondencia entre éstos y las áreas organi-
zativas.
También se discute la arquitectura hardware, la topología de red, el lenguaje de progra-
mación, etc., y se da una prioridad a cada proyecto.
Se concluye con un documento denominado Plan de Sistemas de Información.
Como anotación, se puede comentar que no se encuentra entre las normas ISO debido
a que se realiza una vez cada períodos muy grandes de tiempo (una vez cada década o
incluso más).

1.8.2. Fase de desarrollo

Se llevan a cabo las tareas hasta tener el proyecto funcionando. Conlleva varias acti-
vidades: análisis, diseño, construcción, pruebas e implantación.

1.8.3. Fase de mantenimiento

Su objetivo es la obtención de una nueva versión de un sistema debido a peticiones de
cambio que los usuarios realizan por un problema detectado, o por la necesidad de una
mejora del mismo, para acomodarlo a los cambios de su entorno externo o para conseguir
una mayor adecuación a los requisitos, mayor eciencia, o simplemente recoger nuevas
funcionalidades no expresadas en la fase de denición del sistema.
Comprende el mantenimiento:

9
 Correctivo: Cambia el software para corregir los defectos.

Evolutivo: Introduce mejoras en el software.

Adaptativo: Modica el software para acomodarlo a los cambios de su entorno

externo.

Perfectivo: Lleva al software más allá de sus requisitos funcionales originales.

1.9. Situación actual de la Ingeniería del Software

A principios del siglo XXI, se plantean tres problemas esenciales:

El reto de lo heredado
Existe demasiado software antiguo que es fundamental para empresas de hoy y que,
al deteriorarse, posee un mayor índice de fallos y necesita un mantenimiento muy alto.

El reto de la heterogeneidad
El software debe correr en muchas arquitecturas y sobre sistemas operativos distintos.
Esto afecta a la abilidad del software, es más fácil que falle.

El reto de la entrega
Se necesitan aprender técnicas, herramientas, etc., para ser más productivos y entregar
los proyectos a tiempo. Sin embargo, este aprendizaje reduce el tiempo que se puede
dedicar al desarrollo.

10
Capítulo 2

Introducción a los Sistemas de

Información
2.1. Concepto de sistema
Un sistema es un conjunto de cosas que ordenadamente relacionadas entre sí contri-
buyen a un determinado objetivo.
Un sistema está compuesto de varios elementos:
Los componentes del sistema.
La estructura que viene determinada por las relaciones entre los componentes.
El objetivo u objetivos del sistema.
También se pueden considerar elementos de un sistema los siguientes:
El entorno del sistema: Aquello que lo rodea y dentro del cual está ubicado.
Los límites del sistema: La frontera entre lo que es el sistema y lo que constituye
el entorno.
Las entradas y salidas del sistema: Las relaciones con el exterior, representado por
el entorno. Los sistemas que se relacionan con el exterior se denominan sistemas
abiertos.

2.2. Información y datos

Los datos están constituidos por los registros de los hechos, acontecimientos, transac-
ciones, etc. Pueden ser series de números o de caracteres que por sí mismos no constituyen
información. Los datos se pueden considerar la materia prima para obtener la informa-
ción.
La información implica que los datos estén procesados de tal manera que resulten útiles
o signicativos para el receptor de los mismos, es el resultado de procesar dichos datos.
Por procesar entendemos la actividad de situar los datos en un contexto determinado o

11
completar su signicado si es incompleto.

Se han de tener en cuenta dos consideraciones relativas a la información: su cantidad

y su calidad, siendo esta última más importante que la primera. Según la teoría de la
comunicación de Claude Shannon la cantidad de información que se comunica se dene
en función del conjunto total de mensajes que se pueden enviar.
La comunicación más elemental consiste en el envío de dos posibles mensajes: verdadero
o falso, sí o no. La cantidad de información que se transmite al comunicar a alguien una
de estas dos alternativas, eliminación de la incertidumbre, la denominamos bit.
Cuando existe la posibilidad de enviar no dos, sino una cantidad n de diferentes men-
sajes equiprobables, cada uno por lo tanto con una probabilidad p = n1 , la cantidad de
información I medida en bits que se comunica cuando se envía uno de los n mensajes es:
I = log2 n.
La cantidad de información de un mensaje es equivalente al número de dígitos
binarios necesarios para codicar todos los posibles mensajes a enviar.
Por calidad de la información se entiende al conjunto de cualidades que además de
disminuir la incertidumbre ayudan al receptor a tomar la decisión más ventajosa. Las
propiedades que indican la calidad son:

Relevante para el problema considerado.

Precisa, es decir, exacta con la realidad y actualizada.

Completa. Lo ideal es disponer de toda la información relevante, pero esto nunca

ocurre, por lo tanto debemos de tener al menos la información sobre los elementos
clave.

Se comunica a la persona adecuada, es decir, a quien tiene que tomar la decisión.

A tiempo para que pueda ser útil.

Nivel de detalle adecuado.

Comprensible para el receptor.

2.3. Enfoque sistémico u holístico para el estudio de

sistemas
Consiste en, partiendo de un sistema con unas entradas y salidas, dividirlo en otros
subsistemas que se interconecten, de forma que las salidas de unos sean las entradas de
otros.

2.4. Sistema de Información (SI)

Los Sistemas de Información existen desde el mismo día que se creó la primera orga-
nización humana. Su historia se puede dividir en tres eras:

12
 A principios del siglo XIX, la Revolución Industrial cambió el concepto de trabajo
artesanal por la especialización y división del trabajo. Las personas se organiza-
ron en secciones o departamentos que se coordinaban mediante el intercambio de
información. Se empleaba el papel, el lápiz y los archivadores como sistemas de
información.
A principios del siglo XX, el tamaño y complejidad de las empresas hizo que la
gestión de la información empleara a multitud de ocinistas o administrativos que
manejaban ingentes cantidades de impresos, chas clasicadas en archivadores, etc.
Se empleaba la máquina de escribir, calculadoras mecánicas...
El nal del siglo XX y principios del siglo XXI se caracterizan por el empleo de
sosticadas tecnologías de la información para los actuales sistemas de información.
Los sistemas mecánicos se sustituyen por los informáticos.

2.4.1. Denición
Un Sistema de Información es un conjunto integrado de personas, procedi-
mientos, información y equipos diseñados, construídos, operados y manteni-
dos para recoger, registrar, procesar, almacenar, recuperar y visualizar infor-
mación.

2.4.2. Elementos de un SI
Un Sistema de Información posee los siguientes elementos:
Componentes:
• Los procedimientos y las prácticas habituales que se siguen al ejecutar toda
clase de actividades necesarias para el buen funcionamiento de la empresa.
Un procedimiento es la regularización de las acciones para llevar a cabo una
actividad de la empresa. No existen procedimientos para todas, y en tales
casos lo que existe son prácticas habituales.
• La información y que es el componente fundamental.
• Las personas o usuarios que introducen, manejan o usan la información para
realizar sus actividades.
• El equipo de soporte para la entrada, el procesamiento, el almacenamiento y
la comunicación de información.
Estructura: Un Sistema de Información indica:
• La información que necesita. También se debe tener en cuenta la información
de la que se dispone.
• Las personas a las que va dirigido.
• Los equipos (que pueden ser informáticos).
Objetivo u objetivos: Ayudar al desempeño de las actividades productivas y de
decisión en todos los niveles de la organización, mediante el suministro de la in-
formación adecuada, con la calidad suciente, a las personas apropiadas, en el
momento y lugar oportunos, y con el formato más útil para el receptor.

13
2.4.3. Estructura de la información en un SI
Sigue el modelo planteado en la siguiente imagen:

A continuación se describen las diferentes partes de la pirámide:

Operaciones y transacciones: Incluye el procesamiento de las actividades diarias

o transacciones, los acontecimientos rutinarios que afectan a la organización (fac-
turación, pagos, entrega de productos, etc.), cuyas características son que hay un
gran volumen de transacciones y pocas excepciones a los procedimientos normales.
Se emplean procesos interactivos.

Nivel operativo: Se trabaja con información del procesamiento de las actividades

diarias o transacciones, para tomar decisiones a corto plazo y de consecuencias
limitadas. Las características de esta información son:

• Es repetitiva, informes periódicos.

• Con datos originados internamente.
• Gran volumen de datos.
• Los datos cuentan con un formato bien estructurado, son detallados y precisos.
Se utilizan procesos batch.

Nivel táctico: Se ocupa de la asignación efectiva de los recursos a medio plazo para
mejorar el rendimiento de la empresa. Se basa en análisis de informes:

• Resúmenes con medidas estadísticas, con medias, desviaciones, etc.

• De excepciones, por ejemplo, centros con pérdidas.

14
 • Especícos, que no se han pedido antes, y que los directivos necesitan con
rapidez para resolver un problema muy concreto.

A nivel táctico no es necesario que los datos estén actualizados instantáneamente,

se pueden utilizar los de pocos días antes, lo cual permite realizar las operaciones
paralelamente a las de, por ejemplo, el nivel operativo.

Nivel estratégico: Trabaja con plazos largos para acometer la difícil tarea de de-
cidir las líneas maestras que debe seguir la empresa en el futuro. Se trabaja con
información del tipo:

• En formato muy resumido.

• En formatos muy variables y procedente de las fuentes externas más inespe-
radas.
• Las decisiones están poco formalizadas y con un fuerte componente subjetivo.
A nivel táctico y estratégico hace acto de presencia lo que se denomina un centro de
información, que desarrolla aplicaciones para obtener información, explotando las bases
de datos no actualizadas instantáneamente, y que se han citado en los párrafos superiores.

2.5. Sistemas de Información Automatizados (SIA)

Un Sistema de Información (SI) no necesita estar obligatoriamente basado en el uso
de ordenadores. El sistema de información existe siempre, esté mecanizado o no. Cuando
para recoger, registrar, procesar, almacenar, recuperar y visualizar información se utilizan
ordenadores estamos ante Sistemas de Información Basados en Computadora, Sistemas
Informáticos o Sistemas de Información Automatizados (SIA). Algunos conceptos rela-
cionadas con los sistemas de información son:

Sistemas de procesamiento de transacciones: Parte del Sistema de Información de-

dicado al tratamiento de las operaciones rutinarias diarias o transacciones.

MIS (Management Information System, Sistema de Información de Gestión): Parte

del Sistema de Información que se dedica únicamente a los niveles operativo, táctico
y estratégico. Se excluye el nivel transaccional.

DSS (Decision Support System, Sistema de Apoyo a las Decisiones): Parte del Sis-
tema de Información que da soporte a las decisiones poco estructuradas y en las
que de antemano no están claros los factores a considerar, mientras que el MIS
trata los procesos de ayuda a la toma de decisiones bien denidos y en los que se
conoce a priori qué información es necesaria.

EIS (Executive Information System, Sistemas de Información para Ejecutivos):

Concepto análogo al DSS pero dedicado a personal de alto nivel.

15
2.6. Sistemas de Información básicos en las organiza-
ciones
Un ERP (Enterprise Resource Planning) es un sistema automatizado de gestión em-
presarial que da soporte a las distintas áreas funcionales de una organización de una
forma integrada y coordinada.
En realidad es un conjunto de aplicaciones especializadas en cada área, alguna de las
cuales se considera básica y alrededor de ella se instalan las demás. La implantación de
un ERP exige una personalización a las características y circunstancias de cada empresa.
Algunas ventajas de los ERP son:

Creación de una visión unicada del negocio, lo que incrementa la cooperación y

coordinación interdepartamental.

Almacenamiento común e integrado de la información de gestión.

Interfaz común de usuario para todas las aplicaciones.

2.7. La Ingeniería del Software en una organización

Como anotación, indicar que la mayoría de empresas no tienen personal dedicado

exclusivamente a la Ingeniería del Software.

16
Capítulo 3

El proceso software y modelos de

proceso
En el software se pueden considerar tres clases de entidades:

Procesos: Conjunto de actividades y tareas para el desarrollo, mejora o manteni-

miento de proyectos.

Productos: Resultado obtenido de las actividades del proceso.

Recursos: Bienes que se usan para realizar las actividades y tareas y son requeridos
por éstas.

Cada actividad del proceso está en relación con recursos y productos.

3.1. El proceso software

El proceso software es el conjunto de actividades que conducen a la creación
de un producto software.
Una actividad es un conjunto de tareas que se realizan con un propósito es-
pecíco.
Existen un conjunto de actividades genéricas comunes para todos los procesos de software
independientes del tamaño o complejidad del proyecto. Estas actividades son:

Planicación (plan de sistemas o especicación inicial).

Desarrollo.

Mantenimiento.

Algunas de las actividades del desarrollo son:

Denición de requisitos (Ingeniería de requisitos): La primera actividad del desa-

rrollo del software es denir los requisitos, que incluyen:

17
 • El contexto del problema a resolver (límites del problema).
• Las funcionalidades que se espera que resuelva el sistema.
• Las restricciones y condiciones de uso.
Especicación de requerimientos: Un analista intenta comprender los requisitos y
dene las especicaciones que los satisfacen y que describen la conducta externa
del sistema, lo qué se supone que debe hacer, no cómo lo hace. Hay que asegurarse
de que concuerdan con los requisitos, puesto que son el punto de partida para el
diseño.
Diseño: Sa nalidad fundamental es describir cómo va a desarrollar las especica-
ciones el sistema a construir. El resultado nal es una especicación precisa de la
estructura del software que satisfaga los requerimientos con la calidad necesaria.
Comprende:
• Estructura de los datos a implementar.
• Arquitectura del software.
• Representaciones de interfaz.
• Determinar los algoritmos.
Construcción: Cada unidad nal es codicada y se incluye en esta fase la prueba
individual para vericar su correcto funcionamiento. Para la construcción, el en-
cargado recibe un cuaderno de carga con la descripción del programa. En función
de su contenido, se pasa a realizar una de las siguientes actividades:
• Programar: Se reciben sólo las unidades de programación, y se deben realizar
los diagramas, organigramas, etc.
• Codicar: Generar código propiamente dicho.
Pruebas: Se comprueba que se está construyendo el producto correcto, y que se
está construyendo correctamente el producto. Incluye las pruebas de integración
(comprobar que todas las partes del sistema funcionan correctamente en conjunto),
de aceptación y del sistema.
Implantación: Se elabora la documentación necesaria para la operación y uso del
sistema, se imparte la formación precisa, se realiza la carga inicial de datos y se
pone el sistema en funcionamiento.

3.2. Madurez del proceso software

La madurez del proceso software de una organización indica el punto en el
que se encuentra de una trayectoria evolutiva partiendo de un proceso ad hoc
e inmaduro hasta llegar a un proceso maduro y disciplinado, con el objetivo
de mejorar dicho proceso.
El SEI (Software Engineering Institute) ha desarrollado el CMM (Modelo de Capacidad
de Madurez del proceso software, Capability Maturity Model), un modelo para evaluar
las capacidades de las organizaciones que desarrollan software y mejorarlas. Este modelo
establece 5 niveles de madurez.

18
Nivel 1: Inicial
El proceso software se realiza en cada caso de una manera e incluso de forma caótica.
El éxito depende de esfuerzos personales más que de procesos adecuadamente denidos.
No hay un proceso denido implícita o explícitamente.

Nivel 2: Repetible
Se establecen unos procesos básicos de gestión del proyecto para hacer un seguimiento
del coste y calendario. Se establecen ciertas actividades para llevar a cabo un proyecto
necesarias para repetir éxitos anteriores en proyectos similares. Una función de calidad
asegura que se realizan dichas actividades.
Se obtienen niveles de calidad parecidos a proyectos anteriores.

Nivel 3: Denido
El proceso software está documentado y constituye el proceso estándar de la orga-
nización. La organización tiene denidos sus procesos y existe un procedimiento formal
que asegura que el proceso se sigue en todos los proyectos.
Existen pocas organizaciones que superan este nivel, debido al coste que supone alcanzar
el siguiente.

Nivel 4: Gestionado
Se recopilan medidas del proceso software y de la calidad del producto. Se gestiona
la calidad del proceso y del producto. Se pueden usar dichas medidas (métricas del
software) para detectar situaciones excepcionales y corregirlas.

Nivel 5: Optimizado
Es posible una mejora, una optimización continua del proceso, cuanticando el efecto
que un proceso nuevo o herramienta tienen sobre un proyecto y comparándolo con pro-
yectos anteriores que no utilizaron ese proceso o herramienta.
Este nivel representa una cierta analogía en la supervisión y control de la calidad del sof-
tware con los mecanismos de control que existen en otras industrias con mayor madurez.

3.3. Estándares del proceso software

Los estándares del proceso software proporcionan el conjunto de actividades
que constituyen los procesos obligatorios para el desarrollo y mantenimiento
del software, con el n de que una organización pueda indicar que cumple con
determinado estándar.
A continuación se detallan los estándares IEEE 1074, ISO/IEC 12207 e ISO/IEC TR
15505-2.

19
3.3.1. Estándar IEEE 1074
Dene las actividades que constituyen los procesos necesarios para el desarrollo y el
mantenimiento del software, así como las de los procesos de gestión y soporte a lo largo
de todo el ciclo de vida. Las actividades pueden ser obligatorias u opcionales.
Los procesos se agrupan en 4 secciones, 17 procesos y 65 actividades. A continuación se
detallan las primeras.

Proceso de selección del modelo del ciclo de vida del software

Aunque el estándar no establece ni dene un modelo ciclo de vida especíco o sus
metodologías subyacentes, sí requiere que se seleccione y utilice un modelo de ciclo de
vida. Es posible que el mismo modelo de ciclo de vida se utilice en diferentes proyectos,
sin embargo, para cada proyecto deberemos jar el conjunto de actividades concretas que
se van a realizar.

Procesos de gestión del proyecto

Son los procesos que inician y gestionan el progreso del proyecto a lo largo de su
ciclo de vida. También planica y gestiona el programa de aseguramiento de calidad
del software. El progreso se revisa y mide en los hitos establecidos en el proceso de
planicación del proyecto.

Procesos orientados al desarrollo y mantenimiento del proyecto

Comprende los procesos que se realizan antes, durante y después del desarrollo como
los de mantenimiento y retirada. Los procesos propios del desarrollo son los de requisitos
y requerimientos, diseño...

Procesos integrales
Son los procesos que se necesitan para completar con éxito las actividades del desa-
rrollo de un proyecto. Comprende los procesos de:
Vericación y validación.
Gestión de la conguración del software.
Desarrollo de la documentación.
Entrenamiento.
El estándar requiere la selección de un modelo de ciclo de vida pero no implica ninguno
determinado (ninguno de los estándares lo hace). Cada organización debe seleccionar y
asociar las actividades denidas en el estándar al modelo del ciclo de vida del software
seleccionado.
El seguimiento del estándar no implica el uso de ningún método especíco, ni la creación
de determinados documentos. Prescribe los procesos del ciclo de vida, no los productos
del mismo.
El requisito de conformidad con el estándar es la realización de todas las actividades
obligatorias.

20
3.3.2. Estándar ISO/IEC 12207-1
Muestra los procesos (conjuntos de actividades), actividades (conjuntos de tareas) y
tareas (acciones que transforman entradas en salidas) que se necesitan durante:

La adquisición de un producto o un servicio software.

El suministro.

El desarrollo.

La explotación.

El mantenimiento.

Los procesos pueden ser: principales (5), de soporte (8) o generales (4), así como un
proceso que permite adaptar el ciclo de vida a cada caso concreto.

Procesos principales
Útiles a las personas que inician o realizan el desarrollo, la explotación o el manteni-
miento del software: compradores, suministradores, personal de desarrollo, operadores y
personal de mantenimiento del software. Ejemplo de procesos de desarrollo son el análisis
de requisitos, el diseño software, la construcción y las pruebas.

Procesos de soporte
Sirven de apoyo al resto y contribuyen al éxito y calidad del proyecto software. Los
procesos que pertenecen a esta categoría son la documentación, la gestión de congura-
ción, el aseguramiento de calidad, la vericación y la validación.

21
Procesos generales
Pueden establecerse dos niveles:

A nivel organización: Sirven para establecer, implementar y mejorar la organiza-

ción (gestión, formación del personal, mejora del proceso, etc.). Estos procesos se
realizan fuera de proyectos especícos, a nivel organizativo.

A nivel proyecto: También considera los procesos de gestión del proyecto, gestión
de la calidad y gestión del riesgo. Se realizan para cada proyecto.

ISO/IEC 12207-1 no implica un modelo de ciclo de vida determinado, o un método de

desarrollo de software. La organización que aplique el estándar es responsable de seleccio-
nar un modelo de ciclo de vida y relacionar los procesos, actividades y tareas del estándar
en ese modelo. A esto se denomina proceso de adaptación.
El seguimiento del estándar no implica el uso de ningún método especíco, ni la creación
de determinados documentos. Prescribe los procesos del ciclo de vida, no los productos
del mismo.
El requisito de conformidad con el estándar es la realización de todos los procesos, ac-
tividades y tareas seleccionados en el proceso de adaptación para un proyecto concreto.
Cualquier organización que quiera imponer el estándar debe especicar y hacer públicos
los procesos, actividades y tareas que constituyen la conformidad con el estándar.

3.3.3. Estándar ISO/IEC 15505-2

Este estándar describe los procesos que una organización puede realizar a la hora de
adquirir, suministrar, desarrollar, explotar, evolucionar y soportar software. Los procesos
están fuertemente alineados con el estándar ISO/IEC 12207.

3.4. Modelos de procesos del software

Los estándares establecen los diferentes procesos implicados a la hora de desarrollar
y mantener un sistema desde que surge la idea o necesidad de desarrollar las aplicaciones
hasta que éstas se retiran de explotación. Sin embargo, ninguno impone un modelo de
procesos concreto (modelo de ciclo de vida) ni cómo realizar las diferentes actividades
incluidas en cada proceso, por lo que cada empresa deberá utilizar los métodos, técnicas
y herramientas que considere oportuno.
Por su naturaleza, los modelos son simplicaciones; por lo tanto, un modelo de procesos
del software es una simplicación o abstracción de un proceso real.

Podemos denir un modelo de procesos del software como una representación

abstracta de alto nivel de un proceso software.
Cada modelo es una descripción de un proceso software que se presenta desde una pers-
pectiva particular. Alternativamente, a veces se usan los términos ciclo de vida y Mo-
delo de ciclo de vida.
Cada modelo describe una sucesión de fases y un encadenamiento entre ellas. Según las
fases y el modo en que se produzca este encadenamiento, tenemos diferences modelos de
proceso.Un modelo es más adecuado que otro para desarrollar un proyecto dependiendo

22
de un conjunto de características de éste.
Existe una gran variedad de modelos diferentes entre los que tenemos los que se describ-
cen a continuación.

3.4.1. Modelo en cascada o lineal secuencial

Características del modelo:
Primer modelo empleado (Royce, 1970), también denominado ciclo de vida clásico
y modelo lineal secuencial.
Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da
nombre al modelo.
Cada fase genera documentación para la siguiente. Esta documentación debe ser
aprobada.
Una fase no comienza hasta que la anterior ha terminado.
Requiere disponer de unos requisitos completos y precisos al principio del desarrollo.
Presenta una serie de ventajas:
Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor
que ninguno.
Facilita la gestión del desarrollo.
Así como una serie de inconvenientes:
En general, establecer todos los requisitos al principio del proceso de desarrollo es
un mito inalcanzable: Los usuarios no pueden imaginarse lo que quieren hasta que
no ven un sistema funcionando.
Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cam-
bia, todo cambia.
El usuario debe esperar mucho tiempo hasta ver los resultados: Se tarda mucho
tiempo en pasar por todo el ciclo (hasta que no termina una fase no empieza la
siguiente) y el sistema en funcionamiento no estará disponible hasta el nal del
proceso, eso sí, será el sistema completo.
Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases
siguientes con un efecto conocido como bola de nieve.
Se genera mucho mantenimiento inicial debido al período de congelación de requi-
sitos y éste recae, en su mayor parte, sobre el código fuente, que en consecuencia
se va deteriorando y resultando cada vez más difícil de mantener.
Las características del proyecto que hacen adecuado el uso de este modelo son que:
Se disponga de unos requisitos completos y consistentes al principio del desarrollo.
Sea un proyectos pequeño, en el que el período de congelación de los requisitos es
corto, o un proyecto con unos requisitos bastante estables.

23
3.4.2. Modelo en cascada con prototipado desechable
Trata de resolver algunos de los inconvenientes que presenta el modelo en cascada,
fundamentalmente el problema que representa disponer de unos requisitos completos y
consistentes al principio del desarrollo y la detección de errores en la fase de integración
provenientes de la fase de análisis.
Características del modelo: Divide el ciclo de vida en dos partes.
En la parte A, se construye un prototipo rápido o desechable, que ayudará a renar
y validar los requerimientos.
En la parte B, el desarrollo posterior prosigue en cascada.
Presenta una serie de ventajas:
Se dispone desde muy temprano de unos requerimientos completos y consistentes.
Facilita el desarrollo en lo que respecta a la interfaz de usuario.
Ayuda a mitigar el efecto bola de nieve al reducir el mantenimiento como conse-
cuencia de disponer de unas especicaciones completas y correctas, aunque no lo
elimina al continuar el desarrollo en cascada.
Así como de inconvenientes:
Es frecuente arrastrar malas decisiones (de diseño, de planicación, etc.) que sólo
eran apropiadas para la obtención rápida del prototipo y cuya implementación real
puede ser muy costosa.
El prototipo sólo puede ser aprovechado en su aspecto externo. Los aspectos fun-
cionales son muy reducidos.
El tiempo invertido en la construcción del prototipo y el coste adicional de la
inversión que supone la creación de un producto desechable.
Las características del proyecto que hacen adecuado el uso de este modelo son que:
El usuario no tenga un buen conocimiento del dominio.
Sea un proyecto corto.
Haya pocos cambios en los requisitos.

3.4.3. Modelos evolutivos

Tratan de resolver el largo período de congelación de requisitos del modelo en cascada,
puesto que todos los sistemas evolucionan con el tiempo y los requisitos cambian conforme
se avanza en el proceso de desarrollo. Además, existe una fuerte presión para nalizar un
producto completo ejecutable.
Los modelos evolutivos son iterativos. En cada iteración se alcanza una versión ejecutable
que iremos renando y completando hasta alcanzar una que satisfaga plenamente los
requisitos del usuario.
Entre los modelos evolutivos tenemos:

24
Modelo incremental
Este modelo entrega el software en partes pequeñas, pero utilizables, llamadas incre-
mentos. En general, cada incremento se construye sobre aquél que ya ha sido entregado.
Características del modelo:
Combina elementos del modelo lineal secuencial con la losofía iterativa propia de
los modelos evolutivos. Se realizan una serie de iteraciones sobre el propio modelo
en cascada.
Cada iteración produce un incremento, una versión más renada del sistema,
hasta alcanzar una que satisfaga plenamente los requisitos del usuario .
Cada incremento es un producto totalmente operativo que se entrega al usuario (se
pone en explotación).
Una vez establecida la arquitectura global el sistema se desarrolla incremento a
incremento.

Sus ventajas son que:

Permite obtener un producto ejecutable lo antes posible.
Disminuye el período de congelación de requisitos.
Y sus inconvenientes, que los sistemas están a menudo pobremente estructurados: al
introducir cambios el software queda muy parcheado.
Las características del proyecto que hacen adecuado el uso de este modelo son que:
Debemos ser capaces de diseñar una arquitectura de incrementos para el proyecto
a desarrollar.
La ventaja que reporta el adelantar la puesta en explotación de parte del proyecto
justique lo pobremente estructurado que queda el código.

25
 Si existen alternativas (por ejemplo desarrollar cada subsistema por separado) es
mejor utilizar otros modelos.

Modelo en espiral
Propuesto por Boehm y actualmente muy conocido, es un modelo evolutivo que con-
juga aspectos sistemáticos del modelo lineal secuencial con la naturaleza iterativa propia
de este tipo de modelos. En el modelo en espiral, el software se desarrolla en una serie
de versiones incrementales. Durante las últimas iteraciones, se producen versiones cada
vez más completas del sistema.

Características del modelo:

Boehm lo describe como:

Un modelo de procesos guiado por el riesgo que se emplea para desarrollar

sistemas. Tiene dos características principales:
• Un enfoque cíclico para el crecimiento incremental del grado de de-
nición e implementación de un sistema mientras disminuye su grado
de riesgo.
• Fija un conjunto de puntos para asegurar el compromiso del usuario
con soluciones que sean factibles y mutuamente satisfactorias.
La secuencia de actividades del proceso software se representa como una espiral y
cada bucle representa una fase del proceso.

Cada bucle se divide en cuatro sectores.

Se comienza por el bucle más interior y se avanza hacia el exterior.

26
 No hay fases jadas de antemano en este modelo. Se pueden usar fases del modelo
de prototipos para resolver un problema con los requisitos y disminuir el riesgo,
seguido de fases del modelo en cascada u otro.

Presenta como ventajas:

La consideración explicita del riesgo.

Hacer uso de los mejores elementos de los restantes modelos.

Y como inconvenientes que:

Depende en exceso de la habilidad personal para identicar riesgos.

Implica bastante trabajo adicional.

Las características del proyecto que hacen adecuado el uso de este modelo son que:

Se quiera disminuir el riesgo.

Se sea capaz de evaluar el riesgo y se tenga la capacidad suciente para resolverlo.

Se asuma el trabajo adicional que genera.

Desarrollo basado en componentes

Es evolutivo y en consecuencia exige un enfoque iterativo. La tecnología de objetos
proporciona el marco de trabajo adecuado para este tipo de modelo que promueve la
reutilización del código. Si se diseñan adecuadamente las clases éstas serán reutilizables
por diferentes aplicaciones.
Características del modelo:

Ligado a la OO.

Promueve la reutilización del código.

Congura las aplicaciones desde componentes preparados de software denominados

clases.

Proporciona ventajas notables, en función de la biblioteca de componentes, como la

reutilización del código y consecuentemente en la reducción del tiempo y el coste de
programación (entorno a un 70 % aunque lógicamente varía de una organización a otra).
Pero también presenta el inconveniente de que los resultados anteriores están en función
de la robustez de la biblioteca de componentes. La característica del proyecto que hace
adecuado el uso de este modelo es que el enfoque de desarrollo sea orientado a objetos,
por la ventaja importante derivada de la reutilización del código y, consecuentemente,
de la reducción del tiempo y el coste de programación que supone.

27
3.4.4. Modelo de desarrollo formal
Los métodos formales permiten especicar, implementar y vericar un sistema sof-
tware aplicando una notación matemática rigurosa con lo que se eliminan los problemas
de ambigüedad. Se precisa de un proceso de transformación que convierta fácilmente los
requerimientos en código.
Características del modelo:

Se realiza una especicación formal de los requerimientos.

Se realiza una transformación automática o asistida de las especicaciones a código.

Se realizan una serie de iteraciones sobre el código obtenido con objeto de mejorarlo.

Se realizan las pruebas.

Una ventaja es que es adecuado para construir software de mucha seguridad.

Sus inconvenientes son:

La dicultad para transformar de forma adecuada requerimientos en código.

El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiem-

po.

Pocos desarrolladores tienen los conocimientos necesarios para aplicar estos mode-
los.

La característica del proyecto que hace adecuado el uso de este modelo es que se deba
construir software muy conable y se disponga de equipos de desarrollo con los conoci-
mientos necesarios.

28
3.4.5. Técnicas de 4a generación
Especicación usando formas de un lenguaje especializado o notaciones grácas que
describan el problema a resolver en términos que los entienda el usuario y posteriormente
generar automáticamente el código.
Características del modelo:

Incluye lenguajes no procedimentales de consulta a bases de datos (SQL), gene-

radores de informes (Easytrieve) y generadores automáticos de HTML utilizados
para la creación de sitios web.

En aplicaciones pequeñas, se realiza análisis, implementación, pruebas e implanta-

ción. En aplicaciones grandes, se añade el diseño entre el análisis y la implementa-
ción.

Como ventajas, presenta:

Una reducción del tiempo de desarrollo.

Mayor productividad.

Y como inconvenientes:

Código ineciente.

El mantenimiento no tiene sentido, porque es más fácil rehacer la aplicación

Las características del proyecto que hacen adecuado el uso de este modelo son que:

El número de ejecuciones en explotación sea muy reducido y el mantenimiento vaya

a ser bajo por serlo también el número de cambios.

Se disponga de lenguajes no procedimentales, herramientas...

29
Capítulo 4

Métodos de desarrollo del

software
4.1. Concepto de método
Existe confusión entre los términos método, metodología y modelo de ciclo de
vida. Algunos autores como Yourdon los consideran sinónimos, pero hay diferencias:

Un modelo de ciclo de vida indica qué actividades hay que hacer y cómo se enca-
denan, pero no cómo hacerlas. Esto sí lo deberían indicar los métodos.

Una metodología es un concepto más amplio que el de método. Podemos conside-

rarla como un conjunto de métodos.

Inicialmente, los métodos se centraban en una fase del ciclo de vida.

Un método de desarrollo de software es un enfoque sistemático y disciplinado

para desarrollar software de calidad y de forma productiva.
Los métodos son importantes por varias razones:

Inculcan una disciplina en el proceso de desarrollo.

Denen los productos a generar.

Promueven el uso de determinadas técnicas.

Denen los hitos necesarios para medir el progreso y gestionar el riesgo.

4.2. Breve historia de los métodos

Los métodos han evolucionado como respuesta a la complejidad creciente de los sis-
temas de software.
Antes de 1960, los métodos no existían. Tampoco eran necesarios, debido a la sencillez de
las aplicaciones. Se llevaba a cabo lo que ahora se denomina un desarrollo convencional.

30
De la década de los 60 a los 70, el descenso de los precios del hardware y el aumento de
potencia de los ordenadores propició un aumento en la complejidad de las aplicaciones.
Se propusieron muchos métodos para enfrentarse a ella, y los más inuyentes fueron los
métodos estructurados orientados al ujo de los datos (Yourdon y Constantine).
De la década de los 70 al 85, surgieron los métodos orientados a la estructura de los datos
(Jackson, Warnier-Orr) que, junto a los métodos estructurados orientados al ujo de los
datos, se han aplicado con éxito a una serie de dominios complejos, particularmente a
los sistemas de gestión de la información.
De 1985 a 1990, se llevan a cabo ampliaciones, como por parte de Ward y Mellor, para el
desarrollo de aplicaciones de tiempo real, donde los métodos estructuras no se mostraban
como una solución óptima.
De 1990 en adelante se han extendido los métodos orientados a objetos, métodos formales,
etc.

4.3. Clasicación de los métodos

Los métodos se pueden clasicar en las siguientes categorías:

Desarrollo convencional: Se realizan prácticas artesanales y no existen los métodos,

dando lugar a ciertos problemas.

• No se sabe realmente cuándo puede acabar el proyecto, y los resultados pueden

ser muy distintos a proyectos similares.
• Al no existir fases establecidas ni productos concretos a obtener sobre los que
realizar vericaciones, no se pueden establecer puntos de control.
• No es fácil integrar nuevos recursos.
Métodos estructurados: Aparecen a nales de los 70, y representan tanto los pro-
cesos como las estructuras de datos, de una manera jerárquica descendente. Ven el
sistema como entradas-proceso-salidas.
Son métodos sencillos, fáciles de entender y aprender, y tienen una amplia difu-
sión: están presentes en muchas metodologías (Métrica, SSADM, Merise), existen
muchas herramientas CASE disponibles y la mayor parte del software existente se
ha desarrollado con ellos.
Se pueden señalar los siguientes tipos:

• Orientados al ujo de los datos/a procesos: Se centran en el ujo de informa-

ción. Ésta puede representarse como un ujo continuo que sufre una serie de
transformaciones (procesos) conforme va de la entrada a la salida. Estos mé-
todos denen un conjunto de pasos que transforman el ujo de información en
una estructura de programa, y son especialmente útiles cuando la información
se procesa secuencialmente y no existe una estructura de datos jerárquica. Por
ejemplo, en software cientíco y de gestión.
Las notaciones que utilizan son: DFD (Diagramas de Flujo de Datos), E-R
(Entidad-Relación) y DTE (Diagramas de Transición de Estados).
Ejemplos de estos métodos son: De Marco,Gane & Sarson y Yourdon.

31
 • Orientados a la estructura de los datos/a datos: Se centran en la estructura de
los datos en vez de en el ujo de éstos. Se utilizan para desarrollar software de
base como sistemas operativos y aplicaciones de gestión cuando utilizan bases
de datos jerárquicas. Aunque cada método tiene un enfoque y una notación
distinta, todos poseen características comunes:
◦ Asumen que la estructura de la información es jerárquica.
◦ Requieren que se represente la estructura de los datos usando las estruc-
turas básicas iterativa, selectiva y secuencial.
◦ Proporcionan un conjunto de pasos para transformar una estructura je-
rárquica de datos en una estructura de programa.
Las notaciones que utilizan dependen del método, para el DSED (Desarrollo
de Sistemas Estructurados de Datos) se utilizan diagramas de Warnier y de
entidades (muy parecidos a los DFD), y para el DSJ (Desarrollo de Sistemas
de Jackson), diagramas de Jackson y de especicación del sistema.
• Aplicaciones de tiempo real: A mediados de los 80 comenzaron a hacerse evi-
dentes las deciencias de los métodos estructurados cuando se intentaban uti-
lizar en aplicaciones de tiempo real). Las ampliaciones derivaron en el método
de Ward y Mellor en 1985, y más tarde en el de Hatley y Pirbhai en 1987.
En cuanto a notaciones, la de Ward & Mellor incorpora a los DFDs ujos de
control que se representan mediante echas de trazo discontinuo y procesos
de control. Sólo manejan ujos de control, que también se representan con
burbujas de trazo discontinuo.
Orientados a objetos: A diferencia de los métodos estructurados, que consideran los
sistemas de información como entradas-proceso-salidas, en la POO se identican
los objetos, que son objetos del mundo real, y que encapsulan datos y procesos. En
el análisis se trata de construir un modelo abstracto de objetos, que se traducen
a objetos del sistema durante el diseño, y que a su vez son traducidos a objetos
software (rutinas) durante la construcción.
La correspondencia más directa entre el programa que funciona y los requisitos
originales facilita el mantenimiento. Estos métodos son muy adecuados para el
desarrollo de sistemas interactivos.
No existe una notación estándar, sino que es especíca para cada método. Con
UML (Unied Modeling Language) tenemos, entre otros, diagramas de clases, de
objetos, de secuencia, de casos de uso...
Ejemplos de estos métodos son: Booch, OMT, Objectory/OOSE, FUSION, OOram,
Proceso Unicado, Rational Unied Process...
Métodos formales: Utilizan técnicas de base matemática para describir las propie-
dades del sistema. Estos métodos permiten especicar, desarrollar y vericar los
sistemas de manera sistemática en vez de hacerlo ad hoc. Se dice que un método es
formal si posee una base matemática estable, que normalmente vendrá dada por un
lenguaje de especicación formal. Pocos desarrolladores tienen los conocimientos
necesarios para aplicarlos, y se utilizan para desarrollar software muy seguro.
Como ejemplos de algunos lenguajes de especicación formal se encuentran: PSL/PSA
(Problem Statement Language/ Problem Statement Analyzer), OBJECT Z y CSP
(Communicating Sequential Processes).

32
4.4. Metodologías
4.4.1. Denición
Una metodología es un conjunto de métodos aplicados a lo largo del ciclo de vida del
desarrollo de software, unicados por alguna aproximación general o losóca.

4.4.2. Estructura y componentes

Una metodología presenta la siguiente estructura:

Por ejemplo, para cada proceso principal, Métrica v3 especica una descripción del pro-
ceso y un diagrama de actividades. Para cada actividad especica:
Descripción de la actividad.
Tareas de que consta.
Productos generados por la actividad.
Técnicas utilizadas.
Participantes.
Las tres últimas se especican a nivel de tarea, pero no de actividad.
Para cada tarea especica:
Descripción de la tarea.
Productos.

33
 De entrada.

De salida.

Técnicas.

Participantes.

4.4.3. Características
Las metodologías dan una cobertura total del ciclo de vida del desarrollo, son exibles
con relación al tamaño del proyecto a desarrollar, permiten una fácil formación y están
soportadas por herramientas automatizadas. Ademaás, son personalizables: se precisa un
proceso de personalización para adaptar una metodología foránea a una organización.
No es razonable pensar que dos organizaciones utilicen la misma metodología sin realizar
cambios sobre ella.
Por último, presentan enlaces (interfaces) con procesos de gestión, aseguramiento de la
calidad, gestión de la conguración...

4.4.4. Objetivos
Los objetivos generales de las metodologías son:

Desarrollar mejores aplicaciones, es decir, de más calidad, aunque una metodología

no basta para asegurar la calidad, ya que hay otros factores que pueden inuir.

Mejorar la productividad: Las aplicaciones se desarrollan más rápidamente y con

los recursos apropiados.

Y los objetivos especícos:

Posibilitar una gestión (estimación, planicación y control) adecuada del desarrollo.

Construir un sistema bien documentado.

Disponer de un medio consistente de comunicación.

Posibilitar la utilización óptima de todos los recursos.

Facilitar la incorporación de nuevas personas.

4.4.5. Clasicación
Las metodologías se pueden clasicar en:

Estructuradas.

Orientadas a procesos.

Orientadas a datos.

Para el desarrollo de sistemas de tiempo real.

34
 Orientadas a objetos.

Formales.

Mixtas.

4.5. Metodologías ociales

Entre ellas, podemos destacar Merise, SSADM y Métrica v3, que se presentarán de-
talladamente a continuación.

4.5.1. Merise
Es la metodología ocial francesa. Sas bases fueron creadas por un pequeño grupo
universitario de ingenieros hacia nales de 1976, pero el proyecto de desarrollar una
metodología parte del Centre Technique Informatique (CTI) del Ministerio de Industria
francés y su lanzamiento se realiza en 1979.
Como aportaciones, considera un ciclo de vida más largo que los existentes, incorporando
una nueva actividad de planicación previa al desarrollo, que denomina esquema direc-
tor.
Además, considera tres niveles de abstracción:

1. Nivel conceptual: Se ocupa de denir el qué.

2. Nivel organizativo: Dene la organización a implantar para alcanzar los objetivos

asignados al sistema.

3. Nivel físico: Se ocupa de los medios técnicos necesarios para el proyecto.

Para cada nivel dene dos modelos, un modelo de datos y un modelo de tratamientos.
Tuvo alguna difusión en España y ha inuido en Métrica.

4.5.2. SSADM
Nació a principios de la década de los 80, promovida por el gobierno británico. Se
desarrolló de forma conjunta por la Central Computing and Telecomunications Agency y
Learmonth and Burchett Management Systems. Desde su nacimiento ha ido evolucionan-
do para adaptarse, de forma muy abierta, a los cambios tecnológicos; así, la v3 incorporó
la técnica diseño del diálogo para diseñar la interfaz de usuario y afrontar el crecimiento
del interactivo.
Sólo cubre el análisis y el diseño, considerando las fases de:

Estudio de viabilidad.

Estudio completo: Análisis de requisitos, especicación de requisitos y especicación

lógica del sistema.

Diseño físico.

35
Deja fuera la construcción, pruebas e implantación, y por supuesto las actividades de
planicación y mantenimiento.
Como aspectos clave presenta el énfasis en la participación de los usuarios, y la libre
disposición tanto en entornos industriales como académicos, lo que ha sido benecioso
para la aparición de numerosas herramientas que soportan la metodología.
Al igual que Merise, ha inuido en Métrica.

4.5.3. Métrica v3
Puesto que Métrica es la metodología ocial española, será la que se trate en mayor
profundidad.

Objetivos
Comparte los objetivos de todas las metodologías, que se pueden consultar en el
apartado 4.4.3. Además, los objetivos especícos de Métrica v3 son:

Mantener la sencillez, exibilidad y adaptabilidad de la versión 2.1.

Incorporar nuevas técnicas y métodos presentes en los desarrollos actuales: Cliente-

servidor, orientación a objetos...

Hacer énfasis en el uso de estándares.

Interfaces
Incorpora interfaces con gestión de proyectos, calidad (PGGC, Plan General de Ga-
rantía de Calidad), gestión de la conguración del software y seguridad (MAGERIT).

Ámbito de aplicación
Promovido por el Consejo Superior de Informática del Ministerio para las Admi-
nistraciones Públicas (órgano interministerial responsable de la política informática del
Gobierno).
En orden descendente, se aplica en:

Administración Central del Estado.

Administración Autonómica.

Administración Local.

Resto de empresas e instituciones.

Alcance de la metodología
Métrica ha sido concebida para abarcar el desarrollo completo de sistemas de in-
formación sea cual sea su complejidad y magnitud, por lo cual su estructura responde
a desarrollos máximos y deberá adaptarse a las dimensiones y características de cada
proyecto en particular y al modelo de procesos escogido.

36
Versiones
1. Data de 1989.
2. Data de 1993. La versión 2.1 fue publicada en 1995.
3. Data de 2000.

Inuencias
De los métodos SSADM v4 y Merise.
De los estándares ISO 12207, IEEE Std. 1074-1998, ISO/IEC TR 15.504 (SPICE), ISO
9000-3, IEEE Std. 610.12-1998 y el estándar UML de OMG.
En cuanto a referencias especícas, PGGC y MAGERIT.

Aportaciones
Es una metodología mixta, cubre los enfoques estructurado y OO), al contrario que
Merise y SSADM, que son estructuradas.
Contempla la arquitectura cliente-servidor y las GUI (Graphical User Interface).
Desarrolla los procesos principales de planicación, desarrollo y mantenimiento.

Estructura
Se compone de procesos principales que a su vez se dividen en procesos, éstos en
actividades (comunes, estructuradas u orientadas a objetos), y estas últimas en tareas.
A continuación se detallará la información que suministra de cada uno.
Proceso principal: Descripción general.
Proceso: Descripción general y productos generados.
Actividad: Descripción y tareas de que consta. Productos generados por la activi-
dad, técnicas utilizadas y participantes (estos tres últimos datos se indican a nivel
de tarea, no de actividad).
Tarea: Descripción, productos de entrada y de salida, técnicas y participantes.

Procesos
Planicación de Sistemas de Información (PSI).
Desarrollo de Sistemas de Información:
• Estudio de Viabilidad del Sistema (EVS).
• Análisis del Sistema de Información (ASI).
• Diseño del Sistema de Información (DSI).
• Construcción del Sistema de Información (CSI).
• Implantación y Aceptación del Sistema (IAS).
Mantenimiento de Sistemas de Información (MSI).

37
Capítulo 5

Ingeniería de Requisitos
5.1. Requisitos
Cuando se realiza un proyecto, el primer paso es la obtención de requisitos, pregun-
tando al usuario qué servicios quiere que lleve a cabo, y las condiciones en que se va
a ejecutar, lo que se denominan condiciones de uso. La primera de las actividades en
muchos modelos del ciclo de vida es la obtención de los requisitos.
Los requisitos denen: los servicios que el sistema debe proporcionar a los usuarios, y las
restricciones y condiciones de uso.
La denición de los requisitos debe ser el fruto del trabajo conjunto de las partes invo-
lucradas como son los desarrolladores y usuarios. Los usuarios son los únicos que tienen
poder para modicar, añadir, quitar, etc., un requisito. El desarrollador sólo actúa como
notario.
Un usuario es el conocedor del dominio de aplicación, del área del proyecto. Por ejemplo,
si se desarrolla un proyecto de contabilidad, el usuario debe conocerla. Si el dominio es
abordable desde diferentes puntos de vista, cada uno que lo conoce es un usuario.
Por otra parte, los encargados de elaborar los requisitos son los analistas funcionales,
que no necesitan ser informáticos ni conocedores del dominio porque el análisis no forma
parte de las actividades técnicas informáticas, que comienzan en la fase de diseño.

5.1.1. Tipos de requisitos

Los funcionales describen la funcionalidad o los servicios que se espera que el sistema
provea, sus entradas y salidas, excepciones, etc. Describen lo que el sistema debería hacer.
Los no funcionales se reeren a las propiedades del sistema, como el tiempo de respuesta,
etc. Describen las restricciones de cómo serán implementados los requisitos funcionales.

5.1.2. Problemas comunes

Muchos de los problemas que aparecen en los sistemas software una vez en utilización
(aproximadamente el 37 %) se derivan de problemas aparecidos, o no detectados, en la
identicación de los requisitos. Estos problemas son que:

38
 Los requisitos no reejan las necesidades reales de los usuarios del sistema software.

Los requisitos son inconsistentes y/o incompletos.

Es difícil introducir cambios en los requisitos una vez estos han sido consensuados
entre usuarios y desarrolladores.

La causa de estos problemas es una falta de entendimiento entre los usuarios y aquéllos
que desarrollan el sistema software.

5.2. Ingeniería de Requisitos

La Ingeniería de Requisitos es el proceso sistemático de denición, comprensión, aná-
lisis y documentación de los requisitos.
Con esta denominación de Ingeniería de Requisitos se pretende cubrir todas las activida-
des implicadas en relación con los requisitos. El uso del término ingeniería implica que se
emplea el conocimiento cientíco y técnicas sistemáticas y repetibles para asegurar que
los requisitos sean completos y consistentes.
Muy pocas organizaciones tienen estandarizado y bien denido el proceso de obtención
de los requisitos, dejando, generalmente, a la responsabilidad de los técnicos implicados
la denición de decidir qué hacer y cómo, qué información y qué útiles se usaran, etc.
Se trata, por tanto, de una fase del ciclo de vida que está muy poco tecnicada, a pesar
que los estudios existentes estiman que el coste de esta fase llega a suponer en torno al
15 % del presupuesto total de desarrollo de un nuevo sistema software.

5.3. El proceso de Ingeniería de Requisitos

39
5.4. Identicación de requisitos
La identicación de requisitos es la actividad mediante la cual los usuarios y desarro-
lladores describen los requisitos que desean que satisfaga el sistema software a desarrollar.
Los problemas más comunes en la identicación de requisitos son:

Fijar el alcance o límites del sistema: Si cambian los objetivos, el proyecto también
cambia en gran medida.

Comprensión y comunicación: El lenguaje natural es poco apto para la comunica-

ción. A esto se añade la sobrevaloración de sus capacidades por parte del usuario,
que omite algunas funciones o las expone desde su punto de vista, que él considera
casi de informático.

Volatilidad: Existencia de cambios inevitables.

Para solucionar estos problemas, Sommerville sugiere una serie de actuaciones:

Identicar a los usuarios y contrastar su papel en la organización.

Utilizar técnicas adecuadas tales como entrevistas.

Utilizar prototipos en el caso de requisitos ambiguos.

5.4.1. Técnicas o ayudas para la identicación de requisitos

Observación
Debemos estar alerta y observar todo cuanto ocurre a nuestro alrededor jándonos
en cualquier acontecimiento o actividad que pueda estar relacionado con el sistema de
información, entre otros:

Cargas de trabajo (cuellos de botella, ritmo, métodos...)

Tiempos desperdiciados, interrupciones...

Movimiento de personas, de documentos...

Examen de archivos
Técnica básica para obtener información cuantitativa: volúmenes, frecuencias, ten-
dencias, ratios, etc.
También proporciona ayuda para medir el nivel de conanza que se puede depositar en
las estimaciones cuantitativas dadas por el usuario.

Muestreos
Es útil cuando se pide información relativa a un gran volumen de documentos o
actividades que se repiten con mucha frecuencia. En este caso es aceptable examinar
documentos o actividades escogidas al azar.
Por lo menos, debería realizar un muestreo aleatorio simple con un tamaño de muestra
de 30 individuos.

40
Cuestionarios
Son difíciles de diseñar y de interpretar, por lo que su uso debe restringirse a los casos
de localidades remotas o cuando la información deba proporcionarla un número elevado
de personas.

Entrevistas
Es la técnica principal y la que más se usa. En ellas, una o varias personas, desarro-
lladores y usuarios, se reúnen para que estos últimos indiquen los servicios que quieren y
las condiciones de uso en las que se desarrollarán. El analista debería tomar una copia de
cualquier documento que le pueda proporcionar el usuario. Con sus apuntes, documentos,
etc., debe elaborar un acta que después será aprobada por ambas partes.
Un analista debe contar con las siguientes características:
Imparcial.
Ponderado.
Buen oyente.
Habilidad en el trato.
Cordialidad y accesibilidad.
Paciencia.
Las entrevistas requieren de un método que podemos establecer en los siguientes pasos:
Planicación de la entrevista (antes de realizar la entrevista): Fijar a quién se debe
entrevistar, contando con la aprobación previa. Se informa al entrevistado con
antelación del contenido de la entrevista, y se reúne toda la información existente
sobre el contenido antes de realizar la entrevista. Finalmente, convenir día, hora y
lugar.
Realización de la entrevista: Deberá llevarse a cabo en un ambiente apropiado y lo
más exento posible de interrupciones. Conviene ser puntual, identicarse y explicar
el objetivo de la entrevista.
En el desarrollo, se debe ir de lo general a aspectos más detallados, empezando por:
• Funciones - entradas - salidas (lo que hace)
• Salidas - funciones - entradas (los documentos que maneja)
Se debe utilizar un estilo apropiado y evitar la tentación de argumentar, dar con-
sejos o envolver emocionalmente al entrevistado (esto último modicará su actitud
de cara a próximas entrevistas).
Finalización de la entrevista: Vericaremos las notas con la persona entrevistada,
le expresaremos nuestro agradecimiento y dejaremos el camino abierto para nuevos
contactos.
Consolidación (después de la entrevista): Se debe organizar y completar si fuera
preciso las notas recogidas, elaborar un acta que debe ser entregada a todos los par-
ticipantes, recabar cuantas consideraciones sean precisas en relación a su contenido
y conseguir que el usuario lo apruebe.

41
Reuniones
Cuando los diferentes aspectos en relación a un tema son conocidos por distintas per-
sonas es preciso reunirlas para obtener una información lo más completa posible sobre
dicho tema. El responsable de la reunión suele ser el desarrollador.
Existen una serie de problemas especícos para la aplicación de esta técnica, fundamen-
talmente los derivados de la dinámica de grupos.

JAD (Joined Application Development, Desarrollo Conjunto de Aplicaciones)

Surgen con fuerza para resolver dos de los problemas que presentan las entrevistas:
Los conictos entre requisitos al entrevistar por separado a distintos usuarios y el alar-
gamiento en el tiempo debido a las numerosas entrevistas.
Un JAD es una alternativa a las entrevistas, que consiste en un proceso acelerado de reu-
niones en el cual todos los usuarios y analistas se reúnen de forma intensiva (puede durar
desde un día a una semana) para documentar los requisitos. Normalmente un especialista
supervisa las reuniones y actúa como mediador para promover una mejor comunicación
entre analistas y usuarios.
La idea del JAD es:
Aprovechar la dinámica de grupos.
Aprovechar toda clase de ayudas visuales, de comunicación y comprensión de solu-
ciones.
Realizar un trabajo sistemático y organizado.
El método utilizado se divide en:
Preparación: Seleccionar los participantes, recabar información sobre el sistema a
construir y organizar la reunión (lugar, fecha, ayudas audiovisuales, redacción de
un documento de trabajo...).
Sesión JAD: Consiste en diversas reuniones bien estructuradas y organizadas donde
se parte de un documento de trabajo que hay que analizar para completar los
requisitos del sistema, documento que deberá ser aprobado por los presentes. El
jefe del JAD es el responsable de conseguir que las reuniones sean productivas y de
mantener el orden.
Documentación: Aunque el documento nal debería estar terminado al nal de las
sesiones JAD, lo cierto es que es preciso completarlo, organizarlo, etc., para tener
el documento es su forma nal.
El JAD es difícil de llevar a la práctica al tener que disponer de numerosos usuarios
simultáneamente, lo que puede provocar un parón en la producción.

5.5. Análisis y negociación de requisitos

Es la actividad de estudio sobre los requisitos obtenidos detectando y resolviendo
posibles inconsistencias o conictos y, si existen problemas presupuestarios, jar qué
requisitos contemplará nalmente el proyecto a desarrollar.
Se deben plantear, entre otras cuestiones:

42
 Si el requisito es necesario.
Si algún requisito tiene un nivel de detalle inapropiado.
Si el requisito está bien delimitado y sin ambigüedad.
Si existen requisitos incompatibles con otros.
Si se puede probar el requisito una vez implantado.
Si cada requisito tiene un origen conocido.

5.6. Especicación de requisitos

Es la actividad de redacción o registro de los requisitos utilizando el lenguaje natural,
lenguajes formales, modelos, grácos, etc.

5.6.1. Naturaleza de la especicación de requisitos

Una especicación de requisitos debe incluir información coherente con las necesi-
dades del usuario y comunicarla de forma ecaz, es decir, que se pueda comprender
perfectamente.
La especicación debe describir qué hay que desarrollar, no cómo, cuándo, etc.
La Especicación de Requisitos del Sistema (ERS) denota también el documento que
describe de forma completa, precisa y vericable los requisitos o los componentes de un
sistema.

5.6.2. Características de la especicación de requisitos

Según el estándar 610.12 de IEEE de 1990, las ERS deben ser:
Correctas: Una ERS es correcta si y sólo si cada requisito denido debe ser satisfecho
por el sistema software. Se trata de determinar si las ERS reejan correctamente
las necesidades reales. Como es lógico no hay ningún útil o herramienta que asegure
la corrección de las ERS.
No ambiguas: Una ERS es no ambigua si y sólo si cada requisito denido en la
misma tiene una sola interpretación. Como mínimo, exige que cada característica
del sistema a desarrollar se describa utilizando un único término. En los casos en
que el término usado en un contexto particular pueda tener múltiples signicados,
debe ser incluido en un glosario donde se aclare su signicado especíco.
Dado que las ERS van a ser utilizadas en las fases siguientes del desarrollo deben
ser no ambiguas tanto para quien las crea como para quien las utiliza. Las ERS
se escriben normalmente en lenguaje natural, y éste, aún correctamente utilizado,
puede ser ambiguo. Una vía para resolver esta ambigüedad es escribir las ERS en
un lenguaje formal de especicación de requisitos.
Completas: Una ERS es completa si y sólo si incluye todos los requisitos signicati-
vos, sean relativos a funcionalidad, rendimiento, restricciones de diseño o interfaces
externas; y una denición de la respuesta del sistema software a todas las clases

43
 y tipos de entradas de datos en cualquier situación que pueda presentarse. Hay
que tener presente que esto supone que deben especicarse tanto las respuestas a
entradas válidas como a las que no lo son.

Consistentes: La consistencia se reere a la conformidad de la ERS con documentos

de más alto nivel o de algunos apartados de la ERS con otros.

Clasicadas por su importancia.

Vericables: Una especicación de requisitos es vericable si y sólo si cada uno de

los requisitos denidos es vericable. A su vez, un requisito es vericable si y sólo
si existe algún procedimiento por el que una persona o máquina pueda comprobar
posteriormente que el sistema software cumple el requisito.
En general, un requisito ambiguo es no vericable. Así, aquellos que incluyen ex-
presiones del tipo: trabaja bien, buena interfaz, ocurre usualmente, etc., no
pueden ser vericados porque es imposible denir términos como bueno, bien,
usualmente.

Modicables: Una ERS es modicable si y sólo si su estructura y estilo es tal

que puedan hacerse numerosos cambios de los requisitos de forma fácil, completa
y consistentemente, manteniendo la misma estructura y estilo. Esto requiere que
la ERS esté organizada de manera coherente y fácil de usar, con una tabla de
contenidos, un índice, referencias cruzadas, etc.; que no sea redundante, es decir,
el mismo requisito no debe aparecer más de una vez, y cada requisito debe estar
descrito de forma separada.

Trazables: Una ERS es trazable si el origen de cada requisito es claro y si facilita la

referencia del mismo para futuros desarrollos o modicaciones. Son recomendables
dos tipos de trazabilidad:

• Hacia atrás: Cuando cada requisito referencia explícitamente su fuente u origen

en documentos anteriores.
• Hacia delante: Implica que cada requisito tiene un único nombre o número de
referencia.

5.6.3. Estructura de un documento de especicación de requisi-

tos
La estructura que establece el estándar IEEE / ANSI 830-1998 para el documento de
especicación de requisitos, es:

1. Introducción

2. Descripción general.

3. Requisitos especícos.

4. Apéndices.

5. Glosario.

44
5.6.4. Algunas técnicas de especicación de requisitos
Se pueden utilizar lenguajes grácos: DFD
s, E/R
s, Diccionario de datos, etc. Tam-
bién existen técnicas de especicación formal:

Notaciones relacionales: Ecuaciones implícitas, relaciones recurrentes, axiomas al-

gebraicos...

Notaciones de estado: Tablas de decisión,tablas de transición, tablas de sucesos...

5.7. Validación de requisitos

Actividad de conrmación por parte de los usuarios y desarrolladores de que los
requisitos se han especicado sin ambigüedad ni inconsistencias y de que son completos.
También se valida que no se incumplen ninguno de los estándares establecidos ni ninguna
restricción denida.
Para la validación de requisitos, se pueden presentar las siguientes cuestiones, entre otras:

¾El requisito está claramente denido o puede interpretarse mal?

¾Está identicado el origen del requisito (persona, norma, documento)?

Si un requisito está relacionado con otros, ¾están claramente identicadas las rela-
ciones por medio de una matriz de referencias cruzadas?

¾El requisito se puede probar?

5.8. El uso de prototipos

Además de los problemas citados para la obtención de los requisitos existen otros
problemas con relación a los requisitos:

Es casi imposible predecir cómo un nuevo sistema afectará a sus prácticas de tra-
bajo.

No es posible anticipar las necesidades de información que le van surgiendo a medida

que adquiere experiencia con el nuevo sistema.

En consecuencia, cuando un nuevo sistema de información es entregado a los usuarios es

frecuente que después de un período corto de utilización se tengan que realizar un gran
número de cambios, lo que lleva a un incremento del mantenimiento. Se ha observado que
entre un 60-80 % de los costes de mantenimiento son consecuencia directa de los errores
y ambigüedades en la denición de los requisitos.
El estudio cuidadoso de los requisitos y revisiones sistemáticas de los mismos, dedican-
do tiempo y esfuerzo al proceso de obtención de requisitos aplicando la ingeniería de
requisitos y acortando lo más posible el periodo de congelación de requisitos durante
el desarrollo, reduce la incertidumbre de lo que debe hacer el sistema pero no anticipa
sucientemente la evolución de las necesidades de información. Esto sólo es posible
con el uso de prototipos.

45
5.8.1. Denición de prototipo
Un prototipo es una versión inicial de un sistema software o de parte de él que se
construye de forma rápida y barata y que se utiliza para demostrar conceptos, probar op-
ciones y, de forma general, enterarse más del problema a resolver y sus posibles soluciones.
Así, se consigue anticiparse a la evolución de los requisitos.

5.8.2. Tipos de prototipos

Existen muchos tipos de prototipos o de prototipado, dependiendo del aspecto o
aspectos que se consideren para su clasicación.

Por los objetivos

Prototipado de interfaz de usuario: Fundamentalmente son modelos de pantallas
que sirven para mostrar la interfaz de usuario.
Prototipado operacional: Implementa algunas funciones, y a medida que se com-
prueba que son las apropiadas, se corrigen, renan, y se añaden otras.
Modelos de rendimiento: Evalúan el rendimiento de una aplicación crítica.

Por la robustez
Prototipo funcional (Keep-it): El prototipo es sucientemente robusto y eciente
para que se pueda traspasar a producción directamente. Estos prototipos permiten
al usuario almacenar datos y realizar operaciones con esos datos.
Prototipado desechable (Throw-away): El prototipo se usa sólo para captar y validar
los requisitos del sistema.

Por las funcionalidades que cubre

Global.
Local.

Por el grado de desarrollo

Vertical: Prototipa profundamenta una parte del sistema.
Horizontal: Prototipa parcialmente varias partes.

5.8.3. Técnicas y herramientas

Para poder crear prototipos rápidamente se dispone de diferentes clases de técni-
cas y herramientas.Entre las técnicas, todas aquellas que nos permitan generar código
rápidamente son muy adecuadas, como por ejemplo:
Técnicas de cuarta generación.
Componentes de software reutilizables.

46
 Lenguajes formales de especicación y herramientas.

5.8.4. Benecios de los prototipos

El benecio principal es mejorar la calidad de los requisitos, o lo que es lo mismo,
disminuir la incertidumbre acerca de lo que el sistema debe hacer. Pero también se
mejora la actitud (comunicación, participación y menor conictividad) de los usuarios,
su satisfacción (utilidad, amigabilidad...) con el sistema de información, y se le entrena
antes de que el sistema nal sea entregado.

47
Capítulo 6

Modelado del análisis

SUPRIMIDO

48
Capítulo 7

Diseño del software

SUPRIMIDO

49
Capítulo 8

Técnicas y estrategias de prueba

8.1. Fundamentos de la prueba
La prueba del software es fundamental para garantizar la calidad de éste (aunque la
calidad del software hace referencia también a procesos y recursos). La importancia de
los costes asociados a un fallo del software están motivando la realización de pruebas
cada vez más minuciosas y bien planicadas.
La prueba de software es el proceso que se realiza sobre un producto software
con la intención de descubrir errores.
Los errores pueden empezar desde el primer momento del proceso software.

Cuando hablamos de la prueba del software hablamos de la prueba de las especica-

ciones, del diseño, del código...
No es una actividad secundaria, sino que suele suponer un 30-40 % del esfuerzo de desa-
rrollo, y en aplicaciones críticas (control de vuelo, reactores nucleares...), de 3 a 5 veces
más que el resto de procesos juntos.
La prueba no puede asegurar la ausencia de defectos: sólo puede demostrar que existen
defectos en el software. Una prueba tiene éxito si descubre un error no detectado

50
hasta entonces.
En las pruebas se deben distinguir dos términos importantes:
Vericación: Se corresponde con actividades para comprobar si un producto sof-
tware está técnicamente bien construido, es decir, si funciona.
Validación: En general, se trata de comprobar si el software construido satisface los
requisitos del usuario.

8.2. Principios de la prueba

Antes de diseñar casos de prueba, un desarrollador debe entender los principios básicos
que guían las pruebas del software. Algunos de ellos son:
A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos
de usuario (trazabilidad).
Las pruebas deberían planicarse y realizarse desde el principio y mucho antes de
generar ningún código.
El principio de Pareto es aplicable a la prueba del software (20 % - 80 %).
No son posibles las pruebas exhaustivas o, al menos, no aconsejables en muchos
casos.
Para ser más efectivas, las pruebas deberían ser realizadas por un equipo indepen-
diente.
No deben realizarse planes de prueba suponiendo que prácticamente no hay defectos
y, por tanto, dedicando pocos recursos a las pruebas.
Las pruebas del código deberían empezar por lo pequeño, los módulos individua-
les, y progresar hacia lo grande, el sistema entero.

8.3. Técnicas de pruebas

Existen diversas técnicas de prueba, y unas son más adecuadas que otras dependiendo
del producto a probar. Por ejemplo, los recorridos e inspecciones se utilizan para validar
y vericar las especicaciones de requisitos, las especicaciones funcionales, las especi-
caciones técnicas, cuadernos de carga, los manuales de usuario y explotación, etc.
Para el código se utilizarán fundamentalmente las técnicas de análisis estático, ejecución
simbólica y vericación formal.
A continuación se detallan algunas técnicas de prueba.

Recorridos
Un equipo de recorrido consta de una persona revisada y de tres a cinco revisores. La
persona revisada recorre el producto y los revisores preguntan sobre aspectos relacio-
nados con él. Los revisores pueden ser el jefe del proyecto, otros miembros del equipo de
desarrollo, del grupo de control de calidad, personal técnico, el usuario... El objetivo es

51
descubrir errores que no se resuelven durante la sesión de recorrido.
Como principios generales se debe tener en cuenta:
Planicar las sesiones de recorrido.
Una sesión de recorrido es para detectar errores, no para corregirlos.
Se deben atender aspectos principales.
Una sesión no debe durar más de dos horas.
El éxito depende mucho del establecimiento de una atmósfera agradable.
No deben usarse para evaluar al revisado.

Inspecciones
Según IEEE...
Una inspección es una técnica de evaluación o prueba en la cual las especi-
caciones de requisitos, las especicaciones funcionales, las especicaciones
técnicas, cuadernos de carga, los manuales de usuario y explotación, etc.,
se examinan en detalle, por una persona o grupo distintos del autor, para
detectar defectos, disconformidades con las normas de desarrollo y otros pro-
blemas.
Los grupos de inspección constan de uno a cuatro miembros, inspectores, preparados para
realizar esta labor. Las inspecciones deben ser dirigidas por moderadores preparados y
entrenados para tal n. Cada inspector, si son varios, tiene una tarea concreta para
incrementar la efectividad, y trabajan a partir de listas preparadas para su tarea con el
n de incrementar el descubrimiento de defectos.

Comparativa de recorridos e inspecciones

Los recorridos mejoran la comunicación, y dan lugar a una mayor involucración en el
proceso de prueba.
Las inspecciones permiten la retroalimentación, los inspectores representan papeles de-
nidos y se utilizan listas para la detección de errores.
Se recomienda el uso balanceado de inspecciones y recorridos. De los experimentos rea-
lizados se desprende que un alto porcentaje de errores (superior al 80 %) se encuentran
utilizando estas técnicas y antes de llegar a la prueba de unidad. Pero a pesar de estos
resultados, las inspecciones y recorridos no se efectúan de manera rutinaria.

Análisis estático
Sirve para valorar las características estructurales de cualquier representación que si-
ga unas reglas sintácticas bien denidas. En el código fuente es una técnica para valorar
sus características estructurales. Se examina la estructura del código, pero éste no se
ejecuta.
El objetivo es detectar prácticas de codicación cuestionables y el no cumplimiento de
estándares, así como variables no inicializadas, código aislado, etc.
Normalmente se utilizan herramientas automatizadas denominadas analizadores estáti-
cos.

52
Ejecución simbólica
Es una técnica de validación en la que a las variables de entrada a un programa se
les asignan valores simbólicos en vez de valores literales.
Un programa se analiza propagando los valores simbólicos de las entradas a través de los
cálculos, y las expresiones simbólicas resultantes se simplican a cada paso del cálculo,
de manera que los resultados se expresan siempre en términos de las entradas simbólicas.

Vericación formal
La vericación formal implica el uso de técnicas matemáticas rigurosas para demos-
trar que los programas tienen ciertas propiedades deseables. Dentro de las técnicas de
vericación formal las más empleadas son:

Armaciones de E/S: Se asocian predicados (armaciones) con un punto de entra-

da, de salida y varios puntos intermedios en el código fuente de un programa. La
notación (P )S(R) signica que si el predicado (armación) P es verdadero antes de
ejecutar el segmento de código S , entonces el predicado R será verdadero después
de la ejecución de S si las condiciones de vericación intermedias son verdaderas a
lo largo de la ruta de ejecución S .
La regla de composición dice que, si las condiciones de vericación intermedias son
verdaderas a lo largo de una ruta de ejecución, entonces una condición de entrada
verdadera implicará la verdad de la condición de salida.

Inducción estructural: Se apoya en el principio general de la inducción matemática,

que consiste en demostrar que una condición es verdadera para valores mínimos.
Suponiendo que la condición es verdadera para n, demostrar que es verdadera para
n + 1.

8.4. Diseño de casos de prueba

Dado que la prueba exhaustiva no es aconsejable, se trata de diseñar casos de prueba
que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima
cantidad de esfuerzo y tiempo posible.
Se plantea que cualquier producto software puede probarse de dos maneras, dando lugar
a dos enfoques principales:

1. Conociendo la función especíca para la que fue diseñado el producto, comprobar

que dicha función está completamente operativa.

2. Conociendo el funcionamiento, comprobar que todos los componentes internos del

producto funcionan de forma adecuada.

Al primer enfoque se denomina de la caja negra y al segundo de la caja blanca.

8.4.1. Pruebas de caja blanca

Se centra en la estructura interna de los programas para elegir los casos de prueba.
Todo lo que tenemos que hacer es denir todos los caminos lógicos y desarrollar casos de

53
prueba que los ejecuten, o sea, generar casos de prueba que ejecuten exhaustivamente la
lógica del programa.
Desgraciadamente, incluso para programas pequeños el número de caminos lógicos puede
ser enorme, sin embargo, no se debe desechar la prueba de la caja blanca como imprac-
ticable. Lo que tenemos que hacer es elegir una serie de caminos lógicos importantes
que:

Garanticen que se ejecute al menos una vez cada sentencia.

Que se ejecuten todas las decisiones lógicas en sus vertientes verdadera y falsa.

Que se ejecuten todos los bucles en sus límites.

Entre las pruebas de la caja blanca vamos a considerar las que se detallan a continuación.

Prueba del camino básico

Propuesta por Tom McCabe, se centra en la prueba del conjunto de caminos básicos,
con lo que garantizamos que en la prueba se ejecuta por lo menos una vez cada sentencia
del programa (cobertura de sentencias). El número de pruebas que hay que realizar viene
dado por la complejidad ciclomática.
Como conceptos destacan:

Camino: Secuencia de sentencias encadenadas desde la sentencia inicial del progra-

ma hasta su sentencia nal.

Camino lógico: Conjunto de caminos que durante la prueba garantizan que se eje-
cuta exhaustivamente la lógica del programa.

Camino básico: Conjunto de caminos que durante la prueba garantizan que se

ejecuta al menos una vez cada sentencia del programa.

Camino linealmente independiente de otros: Introduce por lo menos un nuevo con-

junto de sentencias de proceso o una nueva condición.

Complejidad ciclomática: Es una métrica del software que proporciona una medi-
ción cuantitativa de la complejidad lógica de un programa. En el contexto de la
prueba del camino básico dene el límite superior del número de pruebas que se
deben realizar para asegurar que se ejecuta al menos una vez cada sentencia.

Grafo de ujo: Sencilla notación para representar el ujo de control lógico de un

programa. En un grafo de ujo, cada círculo, denominado nodo del grafo de u-
jo, representa una o más sentencias procedimentales. Las echas, denominadas
aristas o enlaces, representan el ujo de control y son análogas a las echas de
un diagrama de ujo. Toda arista debe terminar en un nodo, aunque el nodo no
represente ninguna sentencia procedimental.

Para la obtención de casos de prueba se realiza el siguiente proceso:

1. Usando el diseño o el código como base, dibujamos el correspondiente grafo de ujo.

2. Determinamos la complejidad ciclomática del grafo de ujo resultante, V(G).

54
 3. Determinamos un conjunto básico de hasta V(G) caminos linealmente independien-
tes.
4. Preparamos los casos de prueba que forzarán la ejecución de cada camino del con-
junto básico.

Prueba de condiciones
Se centra en la prueba de cada una de las condiciones de un programa. Si una condición
es incorrecta, al menos un componente de la condición lo es.
Como conceptos, son dignos de destacar:
Condición simple: es una variable lógica o una expresión relacional que toma la
forma de dos expresiones aritméticas, y un operador relacional entre ellas, es decir,
E1 < operadorrelacional > E2. <, >, =, etc., son operadores relacionales.
Condición compuesta: Formada por dos o más condiciones simples, operadores ló-
gicos y paréntesis. OR, AND, NOT, etc., son operadores lógicos.
Los componentes de una condición son:
Operador lógico.
Paréntesis.
Operador relacional.
Expresión aritmética.
Un error en una condición puede ser por un error en cualquier de dichos componentes.
Para una condición simple, se deben generar casos de prueba que ejecuten al menos una
vez las ramas verdadera y falsa de la condición.
Para una condición compuesta, se deben generar casos de prueba que ejecuten al menos
una vez las ramas verdadera y falsa de la condición compuesta y las ramas verdadera y
falsa de cada condición simple.

Prueba de bucles
La prueba de bucles se centra exclusivamente en la validez de la construcción de
bucles. Los bucles aparecen en la mayoría de los algoritmos implementados en el software
y es por ello que debemos prestarles atención cuando llevamos a cabo la prueba del
software. Podemos considerar cuatro tipos de bucles: simples, anidados, concatenados y
no estructurados. Para cada uno de ellos se deben obtener unos casos de prueba.
Bucles simples: Si n es el número máximo de iteraciones del bucle, generar casos
de prueba que permitan:
• Pasar por alto totalmente el bucle.
• Pasar una sola vez por el bucle.
• Pasar dos veces por el bucle.
• Hacer m pasos por el bucle, con m < n.

55
 • Hacer n − 1, n y n + 1 pasos por el bucle.
Bucles anidados: Si aplicáramos el enfoque de los bucles simples el número de prue-
bas aumentaría geométricamente a medida que aumentara el nivel de anidamiento.
Para evitarlo, Beizer propone:

1. Llevar a cabo las pruebas de bucles simples con el bucle más interior. Con-
gurar el resto de bucles con sus valores mínimos.
2. Progresar hacia afuera, llevando a cabo pruebas para el siguiente bucle, mante-
niendo los bucles externos en sus valores mínimos y los internos en sus valores
típicos.
3. Continuar hasta probar todos los bucles.

Bucles concatenados: La prueba depende de que los bucles concatenados sean inde-
pendientes o no. Dos bucles concatenados no son independientes si se usa el contador
del primero como valor inicial del contador del segundo. Si son independientes, se
debe probarlos como los bucles simples, y si no, como los bucles anidados.

Bucles no estructurados: Rediseñar para que se ajusten a alguna de las construc-

ciones anteriores.

8.4.2. Pruebas de caja negra

Se trata de generar casos de prueba que ejecuten completamente todos los requeri-
mientos funcionales de un programa. Se comprueba que la entrada se produce de forma
adecuada y que se genera el resultado esperado, sin tener en cuenta la estructura lógica
interna del software.
La prueba de la caja negra no es una alternativa a la prueba de caja blanca sino un
enfoque complementario. Busca tipos de errores diferentes a las pruebas de caja blanca:
funciones incorrectas o ausentes, errores de interfaz y errores de rendimiento.
Entre las pruebas de la caja negra vamos a considerar dos.

Partición equivalente
Se divide el dominio de valores de entrada en un número limitado de clases de equiva-
lencia. La prueba de un valor representativo de la clase permite suponer razonablemente
que el resultado obtenido será el mismo que probando cualquier otro valor de la clase.
Entre los conceptos, destaca el de clase de equivalencia, un conjunto de estados válidos
o de estados inválidos para una condición de entrada. Típicamente, una condición de
entrada puede ser: un valor numérico especíco, un rango de valores, un conjunto de
valores o una condición lógica. Las clases de equivalencia que se pueden denir son las
siguientes:

Si una condición de entrada es un valor se dene una clase de equivalencia válida

(dicho valor) y dos inválidas (los valores menores y los mayores).

Si una condición de entrada especica un rango de valores, se especica una clase

válida (dicho rango) y dos no válidas (rango inferior y rango superior).

56
 Si una condición de entrada especica un miembro de un conjunto se dene una
clase válida (elementos del conjunto) y una inválida (elementos que no pertenecen
al conjunto).

Si una condición de entrada especica una condición lógica se dene una clase
válida (valores que dan lugar a verdadero) y una inválida (valores que dan lugar a
falso).

Para obtener los casos de prueba se deben identicar las clases de equivalencia y después
crear los casos de prueba correspondientes.

Análisis de Valores Límite (AVL)

Los errores tienden a darse más en los límites del campo de entrada que en el centro,
por esta razón se ha desarrollado el análisis de los valores límite. El AVL nos lleva a la
elección de casos de prueba que ejerciten los valores límite. El AVL es complementario
a la partición equivalente puesto que, en lugar de seleccionar cualquier elemento de una
clase de equivalencia, se seleccionan casos de prueba en los bordes de la clase.
Para obtener los casos de prueba:

Si una condición de entrada especica un rango delimitado por los valores a y b,

se deben generar casos para a y b y casos no válidos justo por debajo y justo por
encima de a y b, respectivamente.

Si una condición de entrada especica un conjunto de valores, se deben desarrollar

casos de prueba que ejerciten los valores máximo y mínimo, uno más el máximo y
uno menos el mínimo.

La mayoría de desarrolladores llevan a cabo de forma intuitiva alguna forma de AVL.

8.5. Estrategias de prueba del software

Una estrategia de prueba del software puede verse como una espiral. La prueba se
realiza en varias fases:

1. Prueba de unidad: En la parte más interior de la espiral se encuentra la prueba

de cada módulo, que normalmente realiza el propio personal de desarrollo en su
entorno en la fase de construcción.

2. Prueba de integración: Avanzando hacia el exterior de la espiral, con el esquema del

diseño del software los módulos probados se integran para comprobar sus interfaces.

3. Prueba de validación: Dando otra vuelta se comprueba si el software satisface to-

dos los requerimientos funcionales y de rendimiento, facilidad de mantenimiento,
recuperación de errores, etc.

4. Prueba del sistema: Finalmente, el software ya validado se prueba junto con el

hardware y el software de base, es decir, con el resto de elementos del sistema.

57
La prueba de unidad hace uso intensivo del enfoque de caja blanca.
La prueba de integración utiliza pruebas de la caja blanca y de la caja negra.
La prueba de validación usa exclusivamente pruebas de la caja negra. La prueba del
sistema queda fuera de los límites de la Ingeniería del Software, entrando en el contexto
de la Ingeniería de Sistemas.

8.6. La depuración
La depuración aparece como una consecuencia de una prueba efectiva. Cuando un
caso de prueba descubre un error, la depuración es el proceso resultante para la elimina-
ción de dicho error.
El desarrollador, al evaluar los resultados de una prueba se encuentra con una indica-
ción sintomática de un problema en el software. El síntoma es la manifestación del error.
Conectar un síntoma con una causa es la tarea fundamental de la depuración. La ma-
nifestación externa de un error y la causa interna del error pueden no estar
relacionados de forma obvia.
El proceso de depuración siempre tiene uno de los dos resultados siguientes:

Se encuentra la causa, se corrige y se elimina.

No se encuentra la causa, en cuyo caso se sospecha una, se diseñan casos de prue-

ba que ayuden a conrmar la sospecha y el trabajo vuelve hacia atrás de forma
iterativa.

La depuración es difícil debido a dos causas.

Características de los errores

El síntoma y la causa pueden estar muy alejados.

El síntoma puede desaparecer temporalmente al corregir otro error.

El síntoma puede ser producido por algo que no es un error.

El síntoma puede ser el resultado de problemas de temporización no de proceso.

El síntoma puede aparecer de forma intermitente.

El síntoma puede ser debido a causas que se distribuyen por una serie de tareas
ejecutándose en diferentes procesadores.

El síntoma puede ser causado por un error humano que no sea fácilmente detectable.

Aspectos humanos
Todo parece indicar que la habilidad en la depuración es un rasgo innato en algunas
personas.

58
8.6.1. Enfoques para la depuración
Fuerza bruta
El más común y menos eciente. Dejamos que el ordenador encuentre el error haciendo
volcados de memoria, trazas de ejecución, etc., y esperamos que entre la gran cantidad
de información generada encontremos alguna pista que nos lleve a la causa del error.

Vuelta atrás
Partiendo del lugar donde se descubre el síntoma se recorre manualmente hacia atrás
el código fuente hasta llegar a la posición de error. Si en la vuelta atrás el número de
caminos crece mucho esta técnica se hace impracticable.

Eliminación de causas
Se hace una lista de posibles causas, se llevan a cabo pruebas para eliminar cada una,
y si alguna prueba indica que alguna causa en particular parece prometedora se renan
los datos con el n de aislar el error.

59
Capítulo 9

Ingeniería del Software Asistida

por Ordenador
9.1. Introducción
Las herramientas CASE e I-CASE suponen la informatización de la informática, es
decir, la automatización de parte del desarrollo del software, contribuyendo a elevar la
productividad y la calidad. Por tanto, se denen como:

Un conjunto de herramientas que proporcionan asistencia automatizada a las

diferentes actividades del proceso software.
CASE es el acrónimo de Computer-Aided Software Engineering, e I-CASE de Integrated
CASE.
Las herramientas CASE abarcan algunas actividades del proceso software por separado,
sin embargo, la verdadera potencia de CASE solamente se puede lograr mediante la in-
tegración.
Las I-CASE contemplan las actividades de todo el ciclo de desarrollo. El término inte-
gración implica una combinación de una gama de herramientas e información que haga
posible la comunicación entre éstas, las personas y los procesos software. Para que una
herramienta sea I-CASE debe:

Compartir la información entre todas las herramientas.

Hacer posible que un cambio en un elemento de información se siga a los elementos

relacionados.

Permitir acceso directo a cualquier herramienta.

Permitir que los usuarios de cada herramienta tengan una visión consistente de
la interfaz persona-máquina: Representaciones consistentes de la información, in-
terfaces estandarizadas entre herramientas y un mecanismo homogéneo para la
comunicación.

60
9.1.1. Evolución histórica de las herramientas
Surgen a mediados de los setenta cuando empiezan a aparecer las primeras metodolo-
gías estructuradas y se popularizan a nales de los ochenta, pero las falsas expectativas y
la incorrecta utilización llevan al desencanto a muchas organizaciones. A mediados de los
noventa entran en una nueva fase de madurez, surge una nueva generación y las nuevas
herramientas superan un buen número de limitaciones de las existentes, a la vez que los
usuarios conocen mejor sus posibilidades.

9.2. Objetivos
Mejorar la productividad y la calidad del software a través de:

Simplicar el uso de técnicas.

Liberar a los desarrolladores de tareas rutinarias.

Facilitar la generación de documentación, la realización de prototipos, el uso de

estándares, la gestión del desarrollo del proyecto...

9.3. Características
Soporte multiusuario, personalización y apoyo automatizado a las tareas de la meto-
dología en uso.

9.4. Elementos básicos

Los elementos básicos de una de estas herramientas son:

Metamodelo: Marco para la denición de la metodología y técnicas asociadas. Ló-

gicamente, estas técnicas deben estar soportadas por la herramienta.

Repositorio: Almacén de datos de los elementos creados por la herramienta o prove-

nientes de otros sistemas y cuya gestión se realiza mediante un SGBD. Es el núcleo
de la herramienta.

Facilidades de personalización, validación y compartición de datos, que permitan:

adaptar la herramienta a una organización en particular, llevar a cabo un análisis
de la exactitud, integridad y consistencia de los distintos elementos generados por
la herramienta, y compartir datos de forma controlada en un entorno multiusuario.

Interfaces que posibiliten cargar el repositorio con datos de otros sistemas o enviar
datos a otros sistemasm proporcionando así un medio de comunicación con otras
herramientas.

Opciones de grácos, pantallas, informes, etc., que permitan dar soporte automa-
tizado a las técnicas precisas.

61
9.5. El repositorio
El repositorio es una base de datos que actúa como centro para el almacenamiento
de información. Es el núcleo o corazón de la herramienta.
El papel del desarrollador es interactuar con el repositorio empleando herramientas inte-
gradas con él.

9.5.1. Funciones del repositorio

Se pueden enumerar las siguientes:

Mantener la integridad de datos

Incluye funciones para validar las entradas, para asegurar la consistencia entre objetos
relacionados, y realiza automáticamente modicaciones en cascada cuando los cambios
en un objeto exigen cambios en otros relacionados.

Compartir información
Proporciona mecanismos para compartir información entre múltiples herramientas, y
controla el acceso multiusuario bloqueando y desbloqueando objetos.

Facilitar la integración datos-herramientas

Establece un modelo de datos al que se puede acceder con todas las herramientas.

Estandarización de documentos
La adopción de estándares para los distintos soportes da lugar directamente a un
enfoque estándar para la creación de documentos.

9.5.2. Contenido del repositorio

El repositorio tiene los siguientes contenidos:
Información de la organización: estructura organizativa, funciones de negocio...
Usuarios de la organización y de cada sistema.
Aplicaciones: Subsistemas que integran cada sistema, elementos que integran cada
subsistema, deniciones, diagramas y representaciones, reglas y estándares, algo-
ritmos y reglas de transformación, estructuras de datos como cheros y bases de
datos...
Construcción: Sódigo fuente, código objeto...
Validación y vericación: Casos de prueba, resultados de las pruebas, métricas...
Información de gestión de proyectos tal como estimaciones, planicaciones, etc.,
además informes de tiempos y de progreso...
Documentación: Manuales y soportes normalizados...

62
9.6. Taxonomías de herramientas
9.6.1. Clasicación por categorías
Herramientas de gestión: Estimación, planicación y seguimiento.
Herramientas técnicas: De análisis, diseño, etc., de mantenimiento, L4G's...
Herramientas de soporte: Repositorio, de control de conguración, de seguridad...

9.6.2. Clasicación por el nivel de integración

Upper Case: Primeras fases de análisis y diseño.
Lower CASE: Últimas fases del desarrollo.
I-CASE: Engloban a las anteriores, contemplando todo el ciclo de vida del desarrollo.
IPSE (Entorno de Soporte de Proyectos Integrado): Además de cubrir todo el ciclo de
vida, incluye componentes para la gestión de proyectos y la gestión de conguración.

9.6.3. Clasicación por su funcionalidad

Herramientas de gestión de proyectos
De estimación de costos y esfuerzos: Calculan el esfuerzo estimado, la duración del
proyecto y el número de personas recomendado para el proyecto.
Planicación de proyectos: Hacen posible que el gestor dena todas las tareas del
proyecto, que cree una red de tareas, que represente las interdependencias entre
ellas y que modele la cantidad de paralelismo que sea posible para ese proyecto.
Seguimiento y control: Su objetivo es proporcionar un enfoque sistemático para el
aislamiento de los requisitos, comenzando por el RFP del cliente o por la especi-
cación.
Métricas del software: Las métricas o herramientas de medidas actuales se centran
en características de procesos y productos. Las herramientas orientadas a la gestión
se sirven de métricas especícas del proyecto que proporcionan una indicación global
de productividad o de calidad. Las herramientas con orientación técnica determinan
las métricas técnicas que proporcionan una mejor visión de la calidad del diseño o
del código.

Herramientas grácas
Símbolos, estructuras y formas.

Herramientas omáticas
Tratamiento de textos, correo electrónico, calculadoras de sobremesa...

Herramientas de documentación
Son herramientas de producción de documentos. Es frecuente que se invierta hasta
un 20 %-30 % del esfuerzo global del desarrollo en el proceso de documentación, por lo
que estas herramientas suponen una importante mejora de la productividad.

63
Herramientas de construcción de prototipos
Generadores de pantallas y disposición entre ellas para aplicaciones interactivas.
Creación de un diseño de datos acompañado por diseños de informes y pantallas.
Herramientas PRO/SIM para predecir el comportamiento de un sistema antes de
llegar a construirlo. Además, le capacitan para desarrollar simulaciones del sistema
de tiempo real.
Herramientas de cuarta generación.

Herramientas de programación
Compiladores, editores y depuradores para apoyar a la mayoría de los lenguajes de
programación convencionales.
L4G.
Lenguajes de consulta a bases de datos SQL.
Generadores de código: A partir de estructuras básicas o de pseudocódigo.

Herramientas de interfaz persona-máquina

Prototipos de interfaz que permiten una rápida creación en pantalla de interfaces
de usuario sosticadas.
Interfaces programables: String-sets, lenguajes de procedimientos, diseño de tecla-
dos seleccionables...

Herramientas de reingeniería
Las herramientas para el software heredado abarca un conjunto de actividades de
mantenimiento que actualmente absorben un porcentaje signicativo de todo el esfuerzo
relacionado con el software. Las herramientas de reingeniería se pueden subdividir en las
funciones siguientes:
H. de ingeniería inversa: Se toma el código fuente como entrada y se generan mode-
los grácos de análisis y diseño estructurados, listas de utilización y más información
sobre el diseño.
H. de reestructuración: Se analiza la sintaxis del programa, se genera una gráca
de control de ujo y se genera automáticamente un programa estructurado.
H. de ingeniería directa.

Herramientas de gestión de conguración

Control de versiones: Para el paso a explotación.
Control de cambios: Para conocer el estado de las modicaciones.
Auditoría.

64
Herramientas de gestión de la información
Acceso rápido a documentos.
C.B.T.: Recopilan información y la suministran al usuario.

Herramientas de prueba
Adquisición de datos: Adquieren los datos que se utilizarán durante la prueba.

Medidas estáticas: Analizan el código fuente sin ejecutar casos de prueba.

Medidas dinámicas: Analizan el código fuente durante la ejecución.

Gestión de pruebas: Prestan su asistencia en la planicación, desarrollo y control

de las pruebas.

Herramientas de análisis de riesgos

Herramientas de control de calidad
La mayoría son en realidad herramientas de métricas que hacen una auditoría del
código fuente para determinar si se ajusta o no a ciertos estándares del lenguaje. Otras
herramientas extraen métricas técnicas para extrapolar la calidad del software que se
está construyendo.

Herramientas de desarrollo de webs

Entre estas herramientas se incluyen las que prestan ayuda en la generación de texto,
grácos, formularios, guiones, applets y otros elementos de una página Web.

9.7. Plan para la adquisición e implantación de una

herramienta
El proceso se divide en varias fases:

9.7.1. Planicación
Se debe valorar el nivel de madurez de la organización haciendo especial énfasis en
la metodología y técnicas que se aplican en el desarrollo, realizar un plan de gestión de
riesgos y seleccionar el grupo de personas para llevar a cabo la implantación.

9.7.2. Adquisición
Depende en gran medida de la situación en la que se encuentre la empresa, pero en
general se tendrán en cuenta varios criterios:

Metodología y técnicas soportadas por la herramienta.

Tipo de computador (mainframe, PC, ...).

65
 Posibilidades de integración con otras plataformas (presentes y futuras).

Criterios habituales en la selección de software: precio, asistencia técnica, formación,

etc.

Tener en cuenta que el coste de adopción de la herramienta puede llegar a ser hasta
ocho veces el coste de adquisición.

9.7.3. Introducción o implantación en un proyecto piloto

Incluye las actividades de:

Instalación de la herramienta y su adaptación.

Formación y entrenamiento en la herramienta del grupo de personas inicialmente

seleccionado.

La formación en el uso de herramientas CASE se estima en 1/3 de la formación

necesaria para el uso de la metodología subyacente.

Aplicación al desarrollo de un proyecto piloto.

Evaluación.

9.7.4. Utilización o implantación en toda la organización

Consiste en extender la utilización de la herramienta a todas las áreas de desarrollo,
lo que conlleva:

Formación y entrenamiento en la herramienta de todo el personal.

Aplicación al desarrollo del resto de los proyectos.

Posible migración de aplicaciones anteriores.

Evaluación.

9.8. Situación actual

66