© élogos Conocimiento, S.L. Madrid 2007.

Todos los derechos de Propiedad Intelectual e Industrial de esta obra pertenecen a élogos Conocimiento, S.L.
1. Introducción a la la calidad del software

1.1 Introducción

El objetivo último de un desarrollo del software es, aparte de diseñar e implementar unos
programas que cumplan con la especificación de requisitos, el producir programas de calidad, es
decir, programas que cumplan unas expectativas de:

• Fiabilidad:

La fiabilidad es la cualidad del software que mide tasa de fallos. Cuanto más fiable es una
aplicación, menos fallos tiene y por supuesto menos fallos comente.

• Velocidad:

La velocidad, en el mundo de la informática, es un concepto que se aplica a todos los

aspectos del software, tanto en velocidad de procesamiento, como en velocidad de
comunicaciones de datos entre las diferentes partes del sistema software.

• Estabilidad:

Esta cualidad hace referencia al comportamiento del sistema. El comportamiento debe ser
estable, sin caídas o sin ralentizaciones sin explicación aparente.

Para producir aplicaciones de calidad, nos apoyamos en conceptos de desarrollo o áreas, que si se
tienen en cuenta durante el análisis y la implementación, nos permitirá elaborar programas con
calidad.

1.2 Áreas involucradas en la calidad del software

1.2.1 Metodologías de diseño: Diseño estructurado

Tras hacer un análisis del sistema que se quiere desarrollar, se va haciendo una estructuración de
los diferentes elementos que componen el sistema, análisis estructurado.

2 Programación
De esta forma, vamos identificando los elementos que intervienen en el sistema y definiendo su
funcionalidad.

Esta es una forma de garantizar calidad en el software, ya no se abordan los sistemas como
grandes proyectos monolíticos difíciles de implementar y más difíciles de mantener.

Dentro de estas metodologías hay una serie de elemento importantes que van a permitirnos medir
el progreso del desarrollo, como son las líneas de tiempo.

Estas líneas de tiempo sirven para marcar hitos o puntos importantes en un calendario, para que
los jefes de proyectos puedan verificar si el estado del desarrollo era el planificado o por el
contrario en algunas partes del proyecto se va con retraso o adelanto.

Esta línea de tiempo también marca las fases por las que va a pasar el desarrollo del proyecto, y
los recursos que se van a necesitar en cada momento, permitiendo administrar los recursos de
forma mucho más eficiente; por recurso entendemos tanto máquinas, personal, etc.

3 Programación
 1.2.2 Herramientas y métodos de codificación

Una de las fases críticas de un proyecto es la implementación. Esta fase está muy relacionada con
la fase de análisis. Cualquier problema no detectado en la fase de análisis puede causar estragos
en la fase de desarrollo.

Supongamos que el analista no ha tenido en cuenta la limitación de velocidad de transferencia de

datos de un sistema, y cuando estamos en la fase de implementación, vemos que esta velocidad es
insuficiente para que nuestros procesos sean capaces de funcionar correctamente, esto requiere
un rediseño del sistema, ya que el planteamiento del diseño actual no sirve para este tipo de
velocidades de transmisión.

Solución

Rediseñar parte del sistema para poder salvar el problema. Esto implica volver a la fase de
análisis, analizar el problema, proponer soluciones, estudiar las implicaciones de las
soluciones en el resto del sistema y una vez analizados todos los aspectos posibles, pasar al
desarrollo de esta parte del sistema con la nueva especificación.

4 Programación
 Parchear en codificación de alguna manera el sistema, para salvar la situación y así poder
seguir el desarrollo.

En cualquiera de los dos casos se va a producir un retraso considerable y además exige al

equipo de análisis y al equipo de desarrollo un esfuerzo extra. Todo esto se traduce en
pérdida de dinero.

En el segundo caso, un parche significa pérdida de calidad, ya que ese punto del sistema
será, posiblemente, un punto muy problemático del sistema, al haberse hecho para salvar
una situación y no como elemento natural del sistema.

Importante también es la elección de la metodología de programación que se va a emplear. Lo

primero es saber si se va a emplear un lenguaje procedural, como cualquier lenguaje que se
asemeje a todos los conceptos que hemos visto en el tema de Introducción a la Programación o por
el contrario vamos a utilizar la tecnología de Orientación a Objetos.

5 Programación
Esta elección suele estar tomada desde muy al principio del análisis estructurado, ya que hay una
fase donde se definen los objetos con sus atributos y sus métodos. Si este fuera el caso, ya queda
decido que la metodología de programación que se va a emplear es la de orientación a objetos.

Otro punto importante a tener en cuanta es el IDE de desarrollo.

¿Qué es un IDE?

Es el entorno de desarrollo. Este entorno es sobre el que se va a programar. En los últimos tiempos
ha tomado un papel protagonista dentro del ciclo de desarrollo de una aplicación, ya que muchos
IDEs incorporan multitud de herramientas que facilitan y aceleran la programación, permitiendo
realizar un desarrollo más rápido y fiable.

Entre esas herramientas podemos encontrar:

• Analizadores léxicos:

Estos analizadores nos van indicando mientras programamos si estamos introduciendo errores
al escribir las palabras claves del lenguaje.

• API online:

6 Programación
 Una de las características de los lenguajes de hoy en día es que hay muchas librerías que
podemos emplear para reutilizar código y así no tener que rehacer el código que otros ya
hicieron. Muchos IDEs nos permiten ver los contenidos de esas librerías según escribimos el
código, de esta manera no tenemos que memorizar miles de funciones y sus parámetros, sino
que se nos da esta información por pantalla.

• Debug integrado:

Debug es la acción de ejecutar el programa viendo los valores de las variables, las llamadas
que se hacen y así poder verificar el correcto funcionamiento del programa. También se
utiliza para detección y corrección de errores.

Cuando lo tenemos integrado en el IDE, se nos muestra mucha información y de forma muy
gráfica por pantalla, lo que facilita el entendimiento que lo que está ocurriendo en el
programa y la rápida detección de errores, cosa que con los debuggers antiguos era muy
difícil.

Debugger clásico

7 Programación
Debugger integrado en el IDE

1.2.3 Métodos y herramientas de pruebas

Otro de los puntos a tener en cuenta a la hora de producir un software de calidad es qué pruebas
vamos a realizar, con qué vamos a realizarlas.

Este punto es uno de los puntos que vamos a estudiar a lo largo de este texto.

1.2.4 Revisiones técnicas formales

Las revisiones formales son aquellas acciones que se realizan sobre el diseño y código para
verificar que se están siguiendo los estándares, que lo que se está diseñando y codificando es
exactamente lo que se quiere diseñar. Es decir, son seguimientos formales, programados en el

8 Programación
tiempo para poder saber si nos estamos desviando de nuestros objetivos y planificación a la hora
de construir un sistema.

1.2.5 Estrategia de pruebas

En este punto se analizarán las diferentes formas de abordar las pruebas, para que podamos
verificar el correcto funcionamiento de la implementación del sistema.

1.2.6 Control de documentación y cambios

En un proyecto, en cuanto es un poco grande, se hace necesario el manejo de una gran cantidad
de documentación, es por eso que se necesita tener mecanismos para tener esta documentación
controlada, así como los cambios que van sufriendo a medida que avanza el proyecto.

1.2.7 Procedimiento de ajuste a estándares

Los estándares son los que nos guían y nos dicen cómo hacer las cosas y ejecutar las diferentes
fases del proyecto para que podamos planificar y además medir la completitud de las fases. Es
decir, saber en qué punto del desarrollo estamos.

Los estándares también nos indican cómo gestionar la comunicación entre los diferentes
integrantes del proyecto, manejo de documentación, versiones, modo de codificación, etc.

1.2.8 Métricas

Nos permiten medir diferentes cosas de nuestro sistema, como podrían ser la complejidad de los
algoritmos.

Estos tipos de métrica sirven para dar una medida estimativa de diversos aspectos del sistema que
estamos creando.

1.3 ¿Qué es calidad del software?

En este punto vamos a profundizar más en el concepto de calidad del software.

9 Programación
A definición podría ser:

Concordancia con los requisitos funcionales y de rendimiento establecidos, con los

estándares de desarrollo explícitamente documentados y con las características implícitas
que se espera de todo software desarrollado profesionalmente.

Analicemos brevemente esta definición. Se define la calidad como una concordancia con los
requisitos funcionales. Es decir, todo desarrollo debe cumplir con la funcionalidad que viene
especificada en el documento de especificación de requisitos. Este documento recoge todo lo que
el sistema debe hacer y cómo lo debe hacer. Es el documento que describe la operatividad del
sistema, y es el documento en que los analistas se deben basar a la hora de diseñar el sistema.

Lógicamente si el sistema no tiene la funcionalidad que se detalla en este documento, la calidad

de ese sistema deja mucho que desear.

En la definición también se nombra el término rendimiento. Está claro que un sistema que cumple
con la especificación de requisitos pero que su funcionamiento es muy lento o consume
muchísimos recursos de la máquina donde está funcionando, o que el ancho de banda de la red
que lo soporta está totalmente saturada por sus comunicaciones, no es un sistema de gran calidad,
ya que aunque cumple con los requisitos, estamos consumiendo muchos más recursos de los que se
detallan en la documentación firmada con el cliente.

10 Programación
Hay una serie de características, que sin estar regidas en ningún documento, se deben cumplir en
todo sistema de calidad, eso es lo que significa la palabra implícita de la definición de calidad.

Entre estas características que se le exige a todo sistema podríamos citar:

• Ausencia de errores de código que produzcan una caída del sistema.

• Calidad en el código que facilite su mantenimiento una ve que se haya puesto el sistema en
producción.

• Documentación detallada y actualizada del sistema y del código.

• Etc.

11 Programación
Según podemos ver en el gráfico, son tres las grandes áreas donde podemos medir la calidad del
software:

1.3.1 Operaciones del producto

Esta área se concentra en la calidad desde el punto de vista de la operatividad del sistema.
Analiza puntos como lo sencillo o complicado que le es al usuario desenvolverse con el sistema.

Un sistema complicado de manejar, no será un sistema de calidad, ya que lo que se busca es

rendimiento por parte del sistema y del usuario, y si no conseguimos que el nuevo sistema facilite
las tareas del usuario, sino todo lo contrario, la calidad dejará mucho que desear.

La seguridad es otro de los puntos importantes, sobre todo hoy en día, donde las comunicaciones
han abierto muchísimas puertas de las máquinas al exterior. Todas esas puertas son susceptibles
de ser atacadas y abiertas, con lo que la información de nuestro sistema correría peligro.

Eficiencia: necesitamos sistemas eficientes, que sean capaces de hacer su labor de una manera
eficiente. Hay muchas maneras de llevar a cabo una tarea, como ya vimos en los algoritmos de

12 Programación
búsqueda, podemos buscar mecanismos que nos permitan desarrollar tareas de una forma
inteligente, por ejemplo la búsqueda binaria.

1.3.2 Revisión del producto

Hay una constante en todos los sistemas software que se han hecho, que se hacen y que se harán
en un futuro. Un sistema de este tipo no es una entidad estática, que cuando se termina su
desarrollo, se implanta y ya está, se deja a los usuarios que trabajen con él por los siglos de los
siglos.

Un sistema software es una entidad viva, que cambia debido a los cambios en las necesidades del
usuario. Una vez puesto en producción, el usuario va sugiriendo nuevas funcionalidades, cambios
en las funcionalidades actuales, etc., fruto de su experiencia trabajando con el sistema y de las
necesidades que tenga.

Esta evolución se traduce en cambios en el sistema, hay que añadir, quitar o alterar
funcionalidades al sistema. Es el mantenimiento, ya que habrá errores que sólo se detecten
cuando el sistema ya esté en producción.

Si no podemos realizar cambios en el código de una manera rápida, sencilla y segura, con segura
nos referimos a que si cambiamos una parte del sistema, las consecuencias colaterales sean las
menores posibles, tendremos un sistema de muy baja calidad, en el que cada cambio, por pequeño
que sea, supondrá un gran esfuerzo por parte de los analistas, desarrolladores y usuarios.

Los sistemas monolíticos son difíciles de mantener, mientras que los estructurados, al estar
compuestos de módulos más sencillos, el mantenimiento es bastante más sencillo.

13 Programación
Como se puede ver en la figura, los antiguos sistemas monolíticos, aquellos con un solo módulo
muy muy grande, son muy difíciles de mantener, ya que no se hicieron con la filosofía de diseño
actual, ni los lenguajes de programación permitían una modularización del sistema. En cambio,
sistemas modernos, compuestos de muchas piezas pequeñas funcionando de forma cooperante,
facilitan enormemente el mantenimiento. Podemos realizar cambios en un módulo sin tocar el
resto. Todo lo que sea manejar piezas de sistemas pequeños redunda en un mejor manejo del
código ya que será más simple.

Otro punto a tener en cuenta son las pruebas. El sistema debe permitir realizar pruebas de
diferentes tipos y aplicar una metodología de pruebas fácilmente, para así poder eliminar errores
del sistema, antes de que el sistema entre en producción.

1.3.3 Transición del producto

A muchos sistemas se les pide que puedan estar en un futuro corriendo en versiones más modernas
de las máquinas en las que actualmente funcionan, por eso hay que plantearse cómo sería una
transición del sistema de una plataforma a otra. Cuanto más sencilla es esta transición, mayor será
la calidad de nuestro software.

14 Programación
Esto nos lleva al siguiente concepto, la reusabilidad. Si tenemos que migrar nuestro sistema a otra
plataforma, y eso significa que todo el sistema debe ser desechado, o que si en un futuro, se
quiere hacer evolucionar el sistema a un sistema mayor, y al ser el código muy cerrado no es
posible, denota que el sistema no tiene mucha calidad.

Por ejemplo:

Hemos hablado en capítulos anteriores de los sistemas heredados.

Cuando se implementaron todo este tipo de sistemas, no se pensaba en el software de la manera

que se hace hoy en día, sino que se desarrollaba el software, se le hacía funcionar y a partir de
ese momento el software evolucionaba sólo hacia donde las necesidades de la empresa le llevaba.

Con la revolución de Internet, se creó una necesidad por parte de las empresas de abrir sus
sistemas al mundo global a través de Internet, pero estos sistemas no fueron pensados para esta
posibilidad, e incluso la tecnología con que se desarrollaron no soportaba este tipo de
comunicaciones. Esto supuso un grave problema para las empresas actuales, cuya dependencia de
estos sistemas es total, ya que el negocio gira entorno a estos grandes sistemas, y el desarrollo de
un nuevo sistema es inviable.

Por otro lado, la necesidad de comunicar sus sistemas con Internet se hace obligatoria, ya que es
lo que demanda el mercado, y si no damos ese servicio, la empresa está abocada al fracaso.

Toda esta problemática viene dada por la necesidad de Transferir y Reusar e Interoperar nuestro
sistema con la tecnología puntera que es Internet.

Para poder salvar este escollo, se idearon soluciones como Webservices, SOAP, tecnologías basadas
en XML XSLT, etc.

15 Programación
Otro aspecto importante es:

Según el sistema que estemos implementando, puede ser que no tengamos en cuenta algún área,
ya que no tiene sentido para nuestro sistema, como podría ser la portabilidad, pero en áreas de
revisión u operación se debe cumplir con las expectativas del cliente.

Supongamos que estamos haciendo un sistema que va a manejar datos de aviónica de un modelo
de un avión. Este tipo de sistemas se suele llamar empotrado ya que se hace para un hardware
concreto y sólo funciona para dicho hardware, con lo que en este caso, la portabilidad es nula, y
no por ello podemos tachar al sistema como de baja calidad.

Es cierto que los sistemas actuales tienen tendencia a funcionar todos en máquinas parecidas,
permitiendo una mayor portabilidad, por no siempre es posible.

16 Programación
Para evaluar el grado de cumplimiento de los anteriores factores, se realizan medidas, algunas de
ellas subjetivas. Entre las listas de comprobación existentes, a modo de referencia, se podrían
medir:

• Facilidad de auditoría:

Facilidad con la que se puede comprobar la conformidad con los estándares (conjunto de
criterios de desarrollo que guían la forma en que se aplica la ingeniería del software).

• Exactitud:

Precisión de los cálculos y el control.

• Normalización de las comunicaciones:

El grado en que se usan el ancho de banda, el protocolo de comunicaciones y las interfases

estándar para comunicaciones.

• Completitud:

Grado en que se ha conseguido la total implementación de las funcionalidades requeridas.

• Concisión:

Lo compacto que es el programa en término de líneas de código.

• Consistencia:

Uso de un diseño uniforme y de técnicas de documentación a lo largo del proyecto de

desarrollo del software.

• Estandarización de los datos:

El uso de estructuras de datos y tipos estándar a lo largo de todo el programa.

Por ejemplo, el usar las plantillas de listas o árboles que traen las APIs de los lenguajes de
programación en vez de crear unas nuevas, a menos que sea estrictamente necesario.

17 Programación
• Tolerancia a Errores:

El daño que se produce en el sistema cuando se produce un error.

No es lo mismo que una aplicación se cuelgue y no se pueda reiniciar en menos de media

hora que únicamente comunique por pantalla el fallo, y pueda continuar trabajando el
sistema sin caídas o inconsistencia en los daros.

• Eficiencia en la ejecución:

El rendimiento en tiempo de ejecución de un programa.

Hay que implementar algoritmos que sean eficientes tantos en velocidad como en consumo
de recursos (memoria, ancho de banda de comunicaciones, etc.).

• Facilidad de expansión:

El grado en el que se puede ampliar el diseño arquitectónico de datos y/o procedimientos.

Es decir, partiendo de un sistema ya implementado e implantado, medimos la facilidad que

supondría añadir más funcionalidades, módulos o nuevos tipos de datos para que los maneje
el sistema.

• Generalidad:

La amplitud de aplicación potencial de los componentes del programa.

• Independencia del hardware:

El grado en que el sistema es independiente del hardware en el que opera.

Sistemas 100% JAVA, tienen una gran independencia del hardware, ya que estos sistemas
utilizan una máquina virtual software que se monta sobre las máquinas físicas hardware.
Esta máquina está disponible en casi todas las plataformas hardware, Windows, MacOs,
Linux, casi todos los Unís, etc. Luego cualquier máquina puede tener una máquina Java
corriendo y ésta a su vez, el programa JAVA, sin cambio alguno.

18 Programación
• Instrumentación:

El grado en que el propio programa muestra su propio funcionamiento e identifica los errores
que aparecen.

• Modularidad:

La independencia funcional de los diferentes componentes del sistema.

Es decir, el grado en que los cambios en uno de los módulos afecta al resto de los módulos.
Si un cambio afecta mucho al resto del módulo, el sistema tiene poca modularidad y mucho
acoplamiento.

• Seguridad:

La disponibilidad de mecanismos que controlen o protejan los programas y/o los datos.

Antivirus, Firewalls, usuarios/claves, sistemas de role para usuarios, etc.

• Auto documentación:

El grado en que el código fuente proporciona documentación efectiva.

Hay en entornos como en JAVA, que los comentarios que se van poniendo en el código, son
aprovechados por unos procesos para producir documentación estructurada en páginas web
de forma automática. El esfuerzo se hace mientras se escribe el código, cosa sencilla ya que
sabemos lo que estamos programando en ese momento. Luego la maquetación de esa
documentaciones automática, con lo que el esfuerzo en esta fase es mínimo.

• Simplicidad:

El grado en el que el programa puede ser entendido con facilidad.

• Independencia del sistema del software:

El grado en el que el programa es independiente de las características no estándar del

lenguaje de programación utilizado, de las características del sistema operativo y demás
componentes del entorno.

19 Programación
• Facilidad de traza:

La posibilidad de seguir la pista a la representación del diseño de los componentes reales del
sistema hacia atrás, hacia los requisitos.

• Formación:

El grado en que el sistema dispone de ayudas para que los nuevos usuarios puedan aprender
su funcionamiento.

1.4 Revisiones técnicas formales

En cada fase de la ingeniería del software deben de realizarse una serie de comprobaciones, con
el objetivo de garantizar la calidad del producto que se genera, antes de iniciar la siguiente fase.
De esta forma podremos detectar cualquier desviación en el desarrollo tanto en tiempo como en
las funcionalidades, puede ser detectado a tiempo y corregido antes de estar inmersos en la
siguiente fase, ya que como hemos visto, la detección de un error es mucho más problemático
cuanto más tarde se detecta.

Las comprobaciones afectan a las siguientes áreas:

• Ingeniería del hardware y software de sistema:

Este punto nos indica que las revisiones no deben ser únicamente del software que estamos
desarrollando, ya que nuestro sistema puede que esté compuesto de máquinas y otras
aplicaciones con las que tiene que comunicarse o cooperar nuestra aplicación.

Por ello es importante realizar comprobaciones de la compatibilidad con estas plataformas,

tanto de máquinas como de software del sistema, podría ser Sistemas Operativos, protocolos
de comunicaciones con otros módulos, por ejemplo Bases de Datos, Servidores de
Aplicaciones Web, etc.

20 Programación
• Planificación del proyecto de software (recursos, tiempos, costes):

No podemos dejar de revisar nuestro propio desarrollo, a nivel de recursos, de tiempos y de

costes.

A nivel de recursos tenemos que verificar que los recursos que en un primer momento se
asignaron a esta fase son los correctos o hemos fallado tanto por exceso como por defecto y
hay que asignarle más recursos o tenemos recursos disponibles para otros puntos del
desarrollo.

A nivel de tiempos, está claro, tenemos nuestros diagramas de GANT donde se nos muestra
las fases con sus fechas de comienzo y final, y hay que ir controlando la evolución del
proyecto con estos diagramas y ajustarlos según se vaya avanzado en el proyecto, ya que
siempre suele haber desviaciones por mucha causas:

• Retrasos del desarrollo.

21 Programación
 • Incompatibilidades no detectadas en fases anteriores.

• Retrasos de proveedores de máquinas y/o software.

• Etc.

• Análisis de requisitos:

No podemos olvidar el comprobar que se están cumpliendo los requisitos que vienen
especificados en la especificación de requisitos, ya que esos requisitos son los que definen la
funcionalidad del sistema, lo que tiene que ser capaz de hacer nuestro sistema.

22 Programación
 1.4.1 Revisión del diseño del software

Estas revisiones se centran el diseño de los datos, diseño arquitectónico y diseño procedimental.

Se realiza primero una revisión del diseño preliminar.

Esta revisión se consigue en forma de respuestas a las siguientes preguntas:

¿Están reflejados los requisitos del software?

Con el diseño que se ha hecho por parte de los analistas y consultores, tenemos que repasar los
requisitos del sistema, para ver si todos ellos están cubiertos y son posibles con el diseño
propuesto.

¿Existe modularidad?

Como hemos visto antes, la modularidad es importante. En este punto debemos evaluar la
modularidad del sistema. Esto nos va a dar una idea del acoplamiento, y de la dificultad de
mantenimiento.

¿Depende de algunos factores la arquitectura del programa?

Hay que identificar si la arquitectura de nuestro sistema depende de algún factor externo como
podría ser que funcione en ciertas máquinas, o el no poder disponer de todo el ancho de banda
que necesitamos, y entonces haya que rehacer la arquitectura para poder salvar este problema,
etc.

¿Están definidas las interfases de los módulos?

Es importante que las interfases entre los diferentes módulos estén definidas, ya que es lo que
hace que las distintas piezas del sistema (los módulos) puedan comunicarse unos con otros, y así
realizar las distintas funcionalidades del sistema.

¿La estructura de datos es consistente con la información del problema?

23 Programación
Hay que revisar que las estructuras de datos, tanto en la aplicación como en las Bases de Datos
contemplan toda la información necesaria para poder llevar a cabo las funcionalidades del
sistema.

Por ejemplo, si estamos haciendo una aplicación de control de entrada de empleados a una
fábrica, la estructura de datos de personas debería ser: (ver figura)

¿La estructura de datos es consistente con los requisitos del software?

Las estructuras de datos, no sólo deben ser lo suficientemente completas como para almacenar
toda la información necesaria para el problema, también debe contener la información necesaria
para que el sistema la pueda manejar.

Por ejemplo: En el ejemplo anterior, para que el sistema pueda manejar los datos de una persona,
debe poder referenciarlos de forma única, y así leer, modificar, crear o borrar estos datos con la
seguridad de que no está borrando los datos de otro empleado. Para esto necesitamos añadir un
campo identificación. Puede que no sea necesario para el problema, pero sí para el sistema.

En la figura sería el campo número de empleado, ya que nuestro sistema no debe de permitir que
haya dos empleados con el mismo número.

¿Se ha considerado la facilidad de mantenimiento?

24 Programación
No sólo hay que plantear un diseño pensando en la funcionalidad del sistema, ya que seguramente
tengamos tanto o más trabajo cuando el sistema ya esté implantado que desarrollándolo.
Cambiaremos funcionalidades, añadiremos nuevas funcionalidades, arreglaremos errores, etc. Es
en fase de diseño un buen momento para sentarse y pensar en el mantenimiento. El sistema debe
facilitar lo máximo posible el mantenimiento.

Un sistema fácil de mantener es aquel que está bien documentado, los módulos son muy
independientes, las interfases entre módulos permiten añadir un módulo nuevo de forma sencilla,
etc.

¿Se han evaluado los factores de calidad?

Ya hemos hablado de ellos, en qué medida estamos cumpliendo con los diferentes factores de
calidad:

• Modularidad.

• Exactitud.

• Auditoría.

• Documentación.

• Etc.

Posterior mente se realiza una Inspección del diseño.

1.4.2 Inspección del diseño

En este punto, no miramos el sistema como un todo, sino que ahora nos concentramos en cada una
de las piezas del sistema (módulos), para comprobar que el diseño de cada pieza es correcto, y así
poder pasar a su implementación con la seguridad de que el diseño es correcto.

¿Realiza el algoritmo la función deseada?

25 Programación
A nivel de diseño, ya se habrán diseñado los diferentes algoritmos que se deberán implementar,
pero antes de proceder a la implementación debemos asegurarnos que los algoritmos cumplen con
la funcionalidad para la que se han diseñado.

Por ejemplo, si hemos diseñado el módulo de gestión de personal de una empresa, y en el

algoritmo hemos contemplado las operaciones de altas y bajas, nos puede parecer correcto, pero
en esta fase de revisión nos podemos dar cuenta de que el algoritmo debe también contemplar la
modificación de los datos del trabajador.

¿Es el algoritmo lógicamente correcto?

Con el concepto de lógicamente correcto queremos decir que si el algoritmo tiene algún problema
de lógica, como podría ser recorrer una lista sin verificar si hemos llegado al último elemento, ya
que en ese caso se podría producir un error al querer leer el siguiente elemento que no existe.

¿Se ha especificado el tratamiento de errores?

26 Programación
Un punto muy importante es cómo se van a tratar los errores que se produzcan en nuestra
aplicación. Tendremos que definir los diferentes tipos de errores:

• Errores de completitud de datos: cuando rellenamos un formulario, debemos ver si están

todos los datos.

• Errores fatales: Errores que suponen que el sistema no pueda continuar trabajando.

• Errores transitorios: como puede ser la caída de la red, en cuanto la red de comunicaciones
vuelva a estar operativa, el sistema podrá continuar su trabajo.

Una vez definidos los errores que se pueden dar en nuestro sistema, debemos saber cómo actuar
en cada caso.

¿Se han definido adecuadamente las estructuras de datos locales?

¿Se ha utilizado la construcción de programación estructurada?

¿Es adecuado el nivel de detalle del diseño para el lenguaje de implementación?

La fase que viene después del diseño es la implementación (codificación), es importante que al
finalizar el diseño, éste sea lo suficiente mente simple para que un desarrollador sólo se preocupe
de desarrollar el diseño sin tener que inventar o intentar entender lo que el analista quiere en el
diseño.

27 Programación
¿Se han utilizado características dependientes del sistema operativo o del lenguaje de
programación?

Puede que en el diseño de los módulos y/o de los algoritmos se hayan utilizado características
propias del SO o del lenguaje en el que se va a desarrollar. Esto, sin ser un desastre, es una
debilidad, ya que cualquier cambio en el SO o lenguaje de programación podría afectar al
desarrollo del módulo, e incluso imposibilitar su desarrollo. Estos puntos deberían estar
localizados y evitarlos en la medida de lo posible.

¿Se ha tenido en cuenta la facilidad de mantenimiento?

Al igual que en el tipo de revisión anterior, la facilidad de mantenimiento debe estar siempre
presente en todas las fases del sistema. Cuando se realiza cualquier cambio en el diseño del
sistema, se debe evaluar el impacto que tiene este cambio sobre el mantenimiento del sistema.

Una vez revisado el diseño, pasamos a la siguiente fase, la codificación (desarrollo,

implementación).

1.4.3 Revisión de la codificación

Ya tenemos el diseño realizado y verificado, hemos pasado a la fase de codificación y según vamos
terminando los módulos, éstos deben de ser revisados, para asegurarnos que cumplen con todos los
requisitos que se le piden.

Es esta revisión la que verificará que el diseño ha sido correctamente implementado. Si el diseño
era correcto, la implementación debería serlo.

¿Se ha traducido adecuadamente el diseño al código?

Este es el punto principal, ya que si hemos hecho una implementación que no cumple con el
diseño, ese módulo no es correcto, y el sistema nunca podrá funcionar como debe.

¿Se han seguido los estándares de codificación, los comentarios, etc.?

Como ya hemos visto, la implementación debe seguir unos estándares. Este punto también se debe
verificar, ya que si desarrollamos sin seguir el estándar, la corrección de errores y el
mantenimiento se podrían complicar mucho.

28 Programación
Además el seguimiento de estándares permite unificar la forma de desarrollo de los distintos
desarrolladores y así minimizar la dependencia del sistema de cada desarrollador, ya que su
trabajo podría ser retomado por otro desarrollador que conozca el estándar de desarrollo y
entender en muy poco tiempo el código heredado.

¿Hay comentarios incorrectos o ambiguos?

Los comentarios deben se explicativos y concisos, referentes al código que se está desarrollando, y
por supuesto deben ser correctos.

Por ejemplo, en un código de alta de usuarios no se ponen comentarios de modificación de

usuarios, ya que eso no es lo que se está haciendo y dificulta la revisión del código.

¿Son apropiadas las declaraciones de tipos y datos?

Puede ocurrir que un algoritmo utilice una lista para hacer operaciones. El desarrollador por su
parte podría decidir utilizar un vector, que en cierto modo es lo mismo, pero con algunas
diferencias.

Puede que ese cambio de una lista por un vector sea correcto, pero puede haber casos en que se
necesite una lista, porque no sabemos la cantidad de elementos que vamos a manejar, y en un
vector deberíamos darle la dimensión en un principio, en estos casos, esa declaración de tipo no es
correcta.

¿Se han aplicado las recomendaciones de la Inspección de Diseño?

De la revisión del diseño, pueden haberse generado recomendaciones para la fase de desarrollo,
estas recomendaciones se deberían tener en cuenta para la codificación de los algoritmos.

1.4.4 Prueba del software

Una vez que hemos revisado el código, entramos en la fase de pruebas. Es en esta fase donde el
objetivo a conseguir es el de un software de calidad.

Para poder probar un software, debemos tener un Plan de Pruebas.

29 Programación
El Plan de Pruebas es un documento que se ha elaborado en las fases anteriores y que detalla las
pruebas que deben hacerse a los módulos por separado y al sistema completo para poder depurar
errores y medir la calidad del sistema.

Una posible lista de comprobaciones que debería estar recogidas en el plan de pruebas sería:

¿Se han identificado las principales fases de prueba?

Como se ha visto, el desarrollo de un software no se hace de forma continuada en un único y largo

paso, sino que se divide en varias fases.

Lo mismo ocurre con las pruebas. No se espera al final del desarrollo para hacer pruebas y ver si
todo ha ido bien, las pruebas se deben estructurar en fases, para probar primeramente los módulo,
después el sistema completo.

¿Se han establecido los requisitos de validación de los requerimientos?

Para poder decidir si el sistema cumple o no cumple todos los requisitos acordados con el cliente,
es importante que en la fase de pruebas se recojan todas las validaciones que se deben hacer para
verificar que efectivamente cada uno de los requisitos del sistema son cumplidos por la
implementación realizada.

Ejemplo: Sistema control de entrada-salida de trabajadores a un fábrica.

Un requisito puede ser:

Se controlará la hora de entrada y salida de los trabajadores mediante un sistema de

fichar con tarjeta personal de cada trabajador.

En pruebas, según el diseño del sistema, se deberá comprobar que después de fichar un
empleado, queda registrada en la base de datos la hora.

Además deberá comprobarse que el módulo de análisis de horas-empleado, lee bien estas
horas y realiza el cálculo correcto de horas trabajadas.

30 Programación
¿Se han comprobado pronto las funciones importantes?

Cuando definimos un sistema de manera somera, lo que hacemos es sintetizar todas las
funcionalidades del sistema completo, en las funcionalidades más importantes del sistema.

Son estas funcionalidades las que deben ser comprobadas lo antes posible, ya que de ellas
dependen el resto de funcionalidades.

Por ejemplo: Sistema de control de entrada-salida de personal a una fábrica.

Una de las funcionalidades claves es el cálculo de horas trabajadas por los trabajadores, ya
que el sistema de facturación depende totalmente de estas horas.

En cambio, la comunicación desde el terminal lector de fichas a la base de datos es

secundario, ya que el sistema sólo necesita de estos terminales la hora de fichar, y no es
clave, aunque sí importante, par el resto del sistema. Bien podemos probar el resto del
sistema, simulando los datos de entrada de los empleados, para ver que el cálculo de horas
es correcto.

31 Programación
¿Es consistente el plan de prueba con el plan de poyecto?

¿Se han definido los tiempos en el plan de prueba?

Nos podemos hacer una idea de lo importante que es ir controlando los tiempos de las distintas
fases del proyecto. Los retrasos son mal vistos ante el cliente y además afectan al desarrollo de la
fase siguiente.

El plan de pruebas debe considerarse como una fase más del proyecto, tan importante o más que
el resto, ya que es en esta fase donde se depurarán errores y además el cliente se basará en
pruebas para verificar que el sistema cumple con todos los requisitos para hacer la aceptación del
sistema.

Es por todo esto que se tiene que planificar cuidadosamente cuánto tiempo nos va a llevar hacer
las pruebas.

¿Están disponibles los recursos necesarios para las pruebas?

Ya hemos hablado de planificar cuidadosamente los tiempos para hacer el plan de pruebas, ahora
lo siguiente a tener en consideración son los recursos que vamos a necesitar para poder realizar
ese plan de pruebas.

32 Programación
Puede ocurrir que cuando estemos en este punto, veamos que los recursos no estarán disponibles
para las fechas de plan de pruebas, en ese caso deberemos rehacer la planificación para las
pruebas.

¿Se ha establecido un mecanismo para registrar los resultados de las pruebas?

Como toda prueba tendremos unos resultados, que pueden ser de muchos tipos.

Satisfactorios, negativos, parcialmente satisfactorio, grado de satisfacción; además se deberán

registrar observaciones y todos los datos que puedan ser útiles a los analistas para corregir errores.

Puede haber un control de versiones de los datos para ver como evolucionan los distintos errores
encontrados y en qué medida aparecen nuevos errores.

Para este tipo de trabajo hay muchas herramientas, que además facilitan la comunicación entre
los diferentes grupos de trabajo dentro de un proyecto, analistas, consultores, jefes de proyecto,
equipo desarrolladores 1, equipo desarrolladores 2, etc.

¿Se han identificado los conductores y los resguardos y se han planificado para desarrollarlos?

¿Se ha especificado la prueba de resistencia del software?

33 Programación