Unidad 5.

Estándares de Diseño
1. Métricas del diseño.
2. Análisis formal del diseño.
3. Técnicas de reingeniería e Ingeniería de reverso.
4. Estándares de calidad.
5. Herramientas Case

INTRODUCCIÓN

El objetivo primordial de la ingeniería del software es producir un sistema, aplicación o

producto de alta calidad. Para lograr este objetivo, los ingenieros de software deben
emplear métodos efectivos junto con herramientas modernas dentro del contexto de un
proceso maduro de desarrollo del software. Al mismo tiempo, un buen ingeniero del
software y buenos administradores de la ingeniería del software deben medir si la alta
calidad se va a llevar a cabo. A continuación se verá un conjunto de métricas del software
que pueden emplearse a la valoración cuantitativa de la calidad de software.

1.- Métricas de diseño.

Permiten medir de forma cuantitativa la calidad de los atributos internos del software.
Esto permite al ingeniero evaluar la calidad durante el desarrollo del sistema.
Generalidades.

Son varios los puntos de vista relacionados con la calidad del software. Las métricas de
diseño a nivel de componentes se concentran en las características internas de los
componentes del software con medidas que pueden ayudar al desarrollador a juzgar la
calidad de un diseño a nivel de componente.

Atributos de calidad Las métricas se centran en cuantificar tanto la complejidad, como la

funcionalidad y eficiencia inmersa en el desarrollo de software. Inclina sus objetivos a
mejorar la comprensión de la calidad del producto, a estimar la efectividad del proceso y
mejorar la calidad del trabajo. Las métricas empleadas están diseñadas para evaluar los
siguientes atributos de calidad:

 Responsabilidad. Consiste en la responsabilidad asignada a una clase en un marco de

modelado de un dominio o concepto, de la problemática propuesta.

 Complejidad de implementación. Consiste en el grado de dificultad que tiene

implementado un diseño de clases determinado.
 Reutilización. Consiste en el grado de reutilización presente en una clase o estructura
de clase, dentro de un diseño de software.

 Acoplamiento. Consiste en el grado de dependencia o interconexión de una clase o

estructura de clase, con otras, está muy ligada a la característica de Reutilización.

 Complejidad del mantenimiento. Consiste en el grado de esfuerzo necesario a realizar

para desarrollar un arreglo, una mejora o una rectificación de algún error de un diseño de
software. Puede influir indirecta, pero fuertemente en los costes y la planificación del
proyecto.

 Cantidad de pruebas. Consiste en el número o el grado de esfuerzo para realizar las

pruebas de calidad (Unidad) del producto (componente, módulo, clase, conjunto de
clases, etc.) diseñado.

TAMAÑO OPERACIONAL DE CLASE TOC

Está dado por el número de métodos asignados a una clase y evalúa los siguientes
atributos de calidad:

 Responsabilidad: Un aumento del TOC implica un aumento de la responsabilidad

asignada a la clase.

 Complejidad de implementación: Un aumento del TOC implica un aumento de la

complejidad de implementación de la clase.

 Reutilización: Un aumento del TOC implica una disminución del grado de reutilización
de la clase. Relaciones entre clases (RC) Está dado por el número de relaciones de uso de
una clase con otra y evalúa los siguientes atributos de calidad:

 Acoplamiento: Un aumento del RC implica un aumento del Acoplamiento de la clase. 

Complejidad de mantenimiento: Un aumento del RC implica un aumento de la
complejidad del mantenimiento de la clase.

 Reutilización: Un aumento del RC implica una disminución en el grado de reutilización

de la clase.

 Cantidad de pruebas: Un aumento del RC implica un aumento de la Cantidad de

pruebas de unidad necesarias para probar una clase.

Matriz de inferencia de indicadores de calidad

También llamada matriz de cubrimiento, es una representación estructurada de los
atributos de calidad y métricas utilizadas para evaluar la calidad del diseño propuesto.
Dicha matriz permite conocer si los resultados obtenidos de las relaciones
atributo/métrica es positivo o no, llevando estos resultados a una escalabilidad numérica
donde, si los resultados son positivos se le asigna el valor de 1, si son negativos toma valor
0 y si no existe relación es considerada como nula y es representada con un guion simple
(-). Luego se puede obtener un resultado general para cada atributo promediando todas
sus relaciones no nulas.

2.- Análisis formal del diseño.

La transición entre las fases de análisis y diseño en la orientación al objeto es mucho más
suave que en las metodologías estructuradas, no habiendo tanta diferencia entre las
etapas. Es difícil determinar dónde acaba el AOO y donde comienza el DOO, siendo la
frontera entre el AOO y DOO totalmente inconsistente, de forma que lo que algunos
autores incluyen en el AOO otros lo hacen en el DOO.

El objetivo del AOO es modelar la semántica del problema en términos de objetos

distintos pero relacionados. Por su parte, el DOO conlleva reexaminar las clases del
dominio del problema, refinándolas, extendiéndolas y reorganizándolas, para mejorar su
reutilización y tomar ventaja de la herencia. El análisis casa con el dominio del problema y
el diseño con el dominio de la solución; por lo tanto el AOO enfoca el problema en los
objetos del dominio del problema y el DOO en los objetos del dominio de la solución.

Según Monarchi, los objetos del dominio del problema representan cosas o conceptos
utilizados para describir el problema, denominándose objetos semánticos porque ellos
tienen el significado del dominio del problema. El análisis se centra en la representación
del problema, la identificación de las abstracciones que tienen el significado de las
especificaciones y de los requisitos del sistema. El énfasis del diseño está en definir la
solución. Las clases semánticas pueden ser extendidas durante el análisis o el diseño. Los
objetos del dominio de la solución incluyen: objetos de interfaz, objetos de aplicación y
objetos base o de utilidad. Estos no forman parte directamente de los objetos del dominio
problema, pero representan la vista del usuario de los objetos semánticos.

Se puede definir AOO como el proceso que modela el dominio del problema identificando
y especificando un conjunto de objetos semánticos que interaccionan y se comportan de
acuerdo a los requisitos del sistema. Se puede definir DOO como el proceso que modela el
dominio de la solución, lo que incluye a las clases semánticas con posibles añadidos, y las
clases de interfaz, aplicación y utilidad identificadas durante el diseño.
El AOO y el DOO no deben separarse en fases muy separadas, siendo recomendable
llevarlas a cabo concurrentemente, así el modelo de análisis no puede completarse en
ausencia de un modelo de diseño, ni viceversa.

Uno de los aspectos más importantes de ADOO es la sinergia entre los dos conceptos.

3.- Técnicas de reingeniería e Ingeniería de reversos

Ejemplificando las técnicas de reingeniería e Ingeniería de reverso. Reingeniería del

software se puede definir como: “modificación de un producto software, o de ciertos
componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa
y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que
se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento,
reutilización, comprensión o evaluación.”

Entre las técnicas de Reingeniería tenemos:

Restructuración de Datos: Esto es reversar el modelo físico al modelo lógico para obtener
el modelo de E-R de la base de datos, recuperando el diccionario de datos, atributos,
entidades, dominios, cardinalidad, etc, la mayoría de las herramientas CASE del mercado
cumplen con esta función.

Restructuración de Código: Llevar a cabo esta actividad requiere analizar el código fuente
empleando una herramienta de restructuración, de no tener el código fuente disponible
puede aplicarse ingeniería inversa sobre el compilado para obtener el código fuente
original siempre y cuando la licencia del software lo permita, inmediatamente se indican
las violaciones de las estructuras de programación estructurada u orientada a objetos, y
entonces se restructurar el código (esto se puede hacer automáticamente). El código
restructurado resultante se revisa y se comprueba para asegurar que no se hayan
introducido anomalías. Se actualiza la documentación interna del código

4.- Estándares de Calidad

La obtención de un software con calidad implica la utilización de metodologías o

procedimientos estándares para el análisis, diseño, programación y prueba del software
que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad,
mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la
labor de desarrollo como para el control de la calidad del software.

Los requisitos del software son la base de las medidas de calidad. La falta de concordancia
con los requisitos es una falta de calidad. Los estándares o metodologías definen un
conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del
software. Si no se sigue ninguna metodología siempre habrá falta de calidad.

Existen algunos requisitos implícitos o expectativas que a menudo no se mencionan, o se

mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que
también pueden implicar una falta de calidad.

La política establecida debe estar sustentada sobre tres principios básicos: tecnológico,
administrativo y ergonómico.

El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del

software.

El principio administrativo contempla las funciones de planificación y control del

desarrollo del software, así como la organización del ambiente o centro de ingeniería de
software.

El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.

La adopción de una buena política contribuye en gran medida a lograr la calidad del
software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o
evaluación.

A partir del siguiente gráfico se observa la interrelación existente entre la Gestión de la

Calidad, el Aseguramiento de la Calidad y el Control de la Calidad.
La gestión de la calidad

Gestión de la calidad: “Aspectos de la función de gestión que determinan y aplican la

política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales
como la planificación de la calidad, el control de la calidad, la garantía de calidad y la
mejora de la calidad”.

Dentro de la gestión de la calidad se observa:

Gestión de la calidad de software (ISO 9000): Conjunto de actividades de la función

general de la dirección que determina la calidad, los objetivos y las responsabilidades y se
implanta por medios tales como la planificación de la calidad, el control de la calidad, el
aseguramiento (garantía) de la calidad y la mejora de la calidad, en el marco del sistema
de calidad

Política de calidad (ISO 9000): Directrices y objetivos generales de una organización,

relativos a la calidad, tal como se expresan formalmente por la alta dirección.

La gestión de la calidad se aplica normalmente a nivel de empresa. También puede haber

una gestión de calidad dentro de la gestión de cada proyecto. El aseguramiento de la
calidad Ante todo se debe conocer:

Aseguramiento de la calidad:

“Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la

confianza adecuada de que un producto o servicio satisfará los requerimientos dados
sobre calidad”.

Aseguramiento de la calidad de software: Conjunto de actividades planificadas y

sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará
los requisitos dados de calidad.

El aseguramiento de calidad del software se diseña para cada aplicación antes de

comenzar a desarrollarla. Hay quienes prefieren decir garantía de calidad en vez de
aseguramiento.

La garantía, puede confundir con garantía de productos, mientras que el aseguramiento

pretende dar confianza en que el producto tiene calidad.

El aseguramiento de calidad del software está presente en:

 Métodos y herramientas de análisis, diseño, programación y prueba.

  Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del
software.
 Estrategias de prueba multiescala.
 Control de la documentación del software y de los cambios realizados.
 Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera
de ellos).
 Mecanismos de medida (métricas).
 Registro de auditorias y realización de informes.

Las actividades para el aseguramiento de calidad del software se detallan en:

 Métricas de software para el control del proyecto.

 Verificación y validación del software a lo largo del ciclo de vida (Incluye
las pruebas y los procesos de revisión e inspección).
 La gestión de la configuración del software.

Algunos métodos del aseguramiento:

 Revisiones técnicas y de gestión (su objetivo es la evaluación).

 Inspección (su objetivo es la verificación). ¿Estamos construyendo el producto
correcto?.
 Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto
correctamente?.
 Auditorias (su objetivo es la confirmación del cumplimiento).

El control de la calidad

Se debe conocer:

 Control de calidad: "Conjunto de técnicas y actividades de carácter operativo,

utilizadas para verificar los requerimientos relativos a la calidad del producto o
servicio".
 Control de la calidad del software: Técnicas y actividades de carácter operativo,
utilizadas para verificar los requisitos relativos a la calidad, centradas en mantener
bajo control el proceso de desarrollo y eliminar las causas de los defectos en las
diferentes fases del ciclo de vida.

El control de la calidad del software está centrado en dos objetivos fundamentales:

 Mantener bajo control un proceso.

 Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

En general, se puede decir que el control de de la calidad del software son las actividades
para evaluar la calidad de los productos desarrollados.
Las estrategias de trabajo se representan como sigue:

Cultura de calidad evitar errores y otros problemas que afectan la calidad

El Estándar de Calidad ISO 9001

El estándar, que ha sido adoptado por más de 130 países para su uso, se está
convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de
un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está en que
no es específico de la industria: está expresado en términos generales, y puede ser
interpretado por los desarrolladores de diversos productos como cojinetes de bolas,
secadores de pelo, automóviles, equipamiento deportivo, televisores, así como por los
desarrolladores de software. Se han realzado muchos documentos que relacionan el
estándar con la industria del software, pero no entran en una gran cantidad de detalles.

Para la industria del software los estándares relevantes son:

• ISO 9001: este es un estándar que describe el sistema de calidad utilizado para
mantener el desarrollo de un producto que implique diseño.

• ISO 9000-3: este es un documento específico que interpreta el ISO 9001 para el
desarrollador de software.
• ISO 9004-2: este documento proporciona las directrices para el servicio de facilidades
del software como soporte de usuarios.

Los requisitos se agrupan bajo 20 títulos:

• Responsabilidad de la gestión

• Inspección, medición y equipo de pruebas

• Sistema de calidad

• Inspección y estado de pruebas

• Revisión de contrato

• Acción correctiva

• Control de diseño

• Control de producto no aceptado

• Control de documento

• Tratamiento, almacenamiento, empaquetamiento y entrega

• Compras

• Producto proporcionado al comprador

• Registros de calidad

• Identificación y posibilidad de seguimiento del producto

• Auditorias internas de calidad

• Formación

• Control del proceso

• Servicios

• Inspección y estado de pruebas

• Técnicas estadísticas.
Factores de calidad ISO 9126

El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos clave
de calidad para el software. El estándar identifica 6 atributos clave de calidad:

• Funcionalidad: el grado en que el software satisface las necesidades indicadas por los
siguientes subatributos: idoneidad, corrección, interoperatividad, conformidad y
seguridad.

• Confiabilidad: cantidad de tiempo que el software está disponible para su uso. Está
referido por los siguientes subatributos: madurez, tolerancia a fallos y facilidad de
recuperación.

• Usabilidad: grado en que el software es fácil de usar. Viene reflejado por los siguientes
subatributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.

• Eficiencia: grado en que el software hace óptimo el uso de los recursos del sistema. Está
indicado por los siguientes subatributos: tiempo de uso y recursos utilizados.

• Facilidad de mantenimiento: la facilidad con que una modificación puede ser realizada.
Está indicada por los siguientes subatributos: facilidad de análisis, facilidad de cambio,
estabilidad y facilidad de prueba.

• Portabilidad: la facilidad con que el software puede ser llevado de un entorno a otro.
Está referido por los siguientes subatributos: facilidad de instalación, facilidad de ajuste,
facilidad de adaptación al cambio.

Estándares de la calidad del proceso de pruebas

• ISO 9001: este es un estándar que describe el sistema de calidad utilizado para
mantener el desarrollo de un producto que implique diseño.

• ISO 9000-3: este es un documento específico que interpreta el ISO 9001 para el
desarrollador de software.

• ISO 9004-2: este documento proporciona las directrices para el servicio de facilidades
del software como soporte de usuarios
Certificación del desarrollo de Software

CMMI (Capability Maturity Model Integration) e s el Modelo para la mejora de los

procesos de desarrollo y mantenimiento de sistemas y productos de software. Fue
desarrollado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon
(SEI) y publicado en su primera versión en enero de 2002 como una evolución del modelo
CMM publicado en 1993.

Esta norma tiene como objetivo la mejora de la gestión de los proyectos en una
organización. Para ello, define una serie de prácticas técnicas y de gestión que deben
adoptarse en los proyectos informáticos para asegurar el cumplimiento de los plazos, los
presupuestos y las exigencias de calidad de los clientes.

En la actualidad, este Modelo CMMI (Capability Maturity Model Integration) es

adoptado por organizaciones de todo el mundo para avanzar en los procesos de mejora
continua de sus proyectos, actividades de desarrollo de software y mantenimiento de
sistemas informáticos.

5.- Herramienta CASE

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por
Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el
desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero.

Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del
software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos,
implementación de parte del código automáticamente con el diseño dado, compilación
automática, documentación o detección de errores entre otras.

Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que
analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos
generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la
aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement
Analyzer). Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos
proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año
1984 y trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM
había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus
mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de
vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y
actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de
diversas herramientas más específicas para cada fase del ciclo de vida del software.

Objetivos
1. Mejorar la productividad en el desarrollo y mantenimiento del software.

2. Aumentar la calidad del software.

3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas

informáticos.

4. Mejorar la planificación de un proyecto

5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a
la búsqueda de soluciones para los requisitos.

6. Automatizar el desarrollo del software, la documentación, la generación de

código, las pruebas de errores y la gestión del proyecto.

7. Ayuda a la reutilización del software, portabilidad y estandarización de la

documentación

8. Gestión global en todas las fases de desarrollo de software con una misma
herramienta.

9. Facilitar el uso de las distintas metodologías propias de la ingeniería del

software.

Clasificación
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas
CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

1. Las plataformas que soportan.

2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.

3. La arquitectura de las aplicaciones que producen.

4. Su funcionalidad.

La siguiente clasificación es la más habitual basada en las fases del ciclo de

desarrollo que cubren:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación,

análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas
UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y

diseño de la aplicación.
Lower CASE (L-CASE), herramientas que semi-automatizan la generación de
código, crean programas de detección de errores, soportan la depuración de
programas y pruebas. Además automatizan la documentación completa de la
aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de
aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una
clasificación excluyente entre sí, ni con la anterior:

Integrated CASE (I-CASE), herramientas que engloban todo el proceso de

desarrollo software, desde análisis hasta implementación.

MetaCASE, herramientas que permiten la definición de nuestra propia técnica de

modelado, los elementos permitidos del metamodelo generado se guardan en un
repositorio y pueden ser usados por otros analistas, es decir, es como si
definiéramos nuestro propio UML, con nuestros elementos, restricciones y
relaciones posibles.

CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de

software.

IPSE (Integrated Programming Support Environment), herramientas que soportan

todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión
de la configuración activa.

Por funcionalidad podríamos diferenciar algunas como:

Herramientas de generación semiautomática de código.

Editores UML.

Herramientas de Refactorización de código.

Herramientas de mantenimiento como los sistemas de control de versiones