Material de Clase Calidad de Software

Manual Aseguramiento Calidad de Software
UNIDAD I (ELEMENTOSY PRINCIPIOS DE LA CALIDAD)
1.1. LA CALIDAD REAL

Calidad es satisfacer al cliente cumpliendo con sus requisitos, requerimientos y/o
especificaciones.
“Calidad es respetar al pueblo” [La Habana, 2002].
Calidad es tener la oportunidad de mejorar y aportar valor a tu vida.
Calidad es vivir, compartir tus sentimientos, soñar, inventar proyectos lindos, bellos.
La ética, los valores, nuestra identidad de calidad.
Las personas, eje central de nuestras vidas, son los motores de la calidad.
Calidad es disfrutar de cada instante, de cada momento.
Calidad es una filosofía de la vida, el deseo de hacer las cosas bien desde el principio.
La adopción de un Sistema de la Calidad Total debe ser una decisión estratégica dentro
de la organización.
De igual forma que los proyectos de TI ya se consideran como una inversión, la calidad
no tiene coste, el costo real es de la NO CALIDAD, es decir, el coste de tener que
volver a hacer las cosas.
Para conseguir este objetivo es necesario desarrollar un plan de aseguramiento de
calidad específico que se aplicará en la planificación y gestión del proyecto.
1.2. DEFINICION DE CALIDAD
1. “La calidad es el conjunto de propiedades y características de un

producto, proceso o servicio que le confieren su aptitud para satisfacer
necesidades expresadas o implícitas.” (ISO).
2. “La calidad es la aptitud de un producto o de un servicio para satisfacer
las necesidades de los utilizadores.” (AENOR).
3. “La calidad es dar respuesta a las exigencias: conformidad.” (CROSBY).
1
• 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”.
• 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”.
• 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”.
• Sistema de gestión de la calidad: “Estructura de la organización, responsabilidades,
procedimientos, procesos y recursos que se establecen para llevar a término la gestión
de calidad”.
1.3. CALIDAD (OCHO PRINCIPIOS GENERALES)
Organización orientada al cliente.

Liderazgo.
Enfoque a procesos.
Enfoque a un sistema para la gestión.
Vocación de mejora continua.
Relaciones mutuamente provechosas con los proveedores.
Participación del personal.
Procesos de toma de decisiones basados en hechos.
2
1.4. LAS TRES ESCUELAS DE LA CALIDAD TOTAL
Crosby da una orientación práctica y sencilla al programa de implantación de la

Calidad Total.
Deming se centra más en aspectos relativos a las conductas y actitudes.
Juran focaliza en la alta dirección la responsabilidad de la aplicación y control de

los programas de calidad.
PHILIP CROSBY
Menciona que la calidad es gratis, definiéndola como “Conformidad con los requerimientos"
e indicando que el 100% de la conformidad es igual a cero defectos.
Establece que en las organizaciones que no se trabaja con un plan que contemple la calidad,
los retrabajos y desperdicios alcanzan del 20 al 40%.
Promueve sus 14 pasos para administrar la calidad en un libro denominado "Calidad sin
Lágrimas".
Autor del libro " La Calidad es Gratis ", se le conoce por su lema de Cero Defectos.
La aproximación de CROSBY
Compromiso de la dirección.
Equipo de mejora de la calidad.
Medición de la calidad.
Evaluación del coste de la calidad.
Conciencia de la calidad.
Acción correctora.
Planificación del cero defectos.
El día cero defectos.
Entrenamiento de los supervisores.
Fijación de metas.
3
Eliminación de metas.
Eliminación de causas de error.
Reconocimiento.
Consejos de calidad.
Hacerlo todo de nuevo.
WILLIAM EDWARD DEMING

Impulsor del desarrollo en calidad de Japón, fue invitado en 1950 por la Unión de Científicos
e Ingenieros del Japón (JUSE), logrando que implementaran el Control Total de Calidad
usando el ciclo PHVA (Planear, Hacer, Verificar y Actuar) de Shewhart y el Control
Estadístico de Procesos.
Se le considera el "Padre" de la Tercera Revolución Industrial o La Revolución de la Calidad,
con sus famosos 14 puntos.
Entre sus libros se puede citar "Calidad, Productividad y Competitividad", en donde hace ver
la necesidad del liderazgo en la calidad.
La aproximación de DEMING:
No se pueden tolerar los niveles aceptados de error.
Crear constancia en el propósito de mejorar el producto/servicio.
Dejar de depender de la inspección en masa.
Dejar hacer negocios sobre la base del precio.
Mejorar el sistema de producción y servicio.
Implantar la formación.
Erradicar el miedo.
Adoptar e implantar el liderazgo.
Derribar las barreras entre departamentos.
Eliminar los eslóganes exhortaciones y metas
Eliminar cuotas numéricas.
Fomentar el orgullo por el trabajo.
Estimular la educación y la auto mejora.
Lograr la transformación.
4
JOSEPH M. JURAN
Afirma que la Alta Administración es la responsable del cambio, abogando por crear el
cambio cuando el proceso necesita mejorarse y por prevenir el cambio cuando los problemas
son esporádicos.
Logró desarrollar la técnica de los Costos de Calidad, elaborando un Manual de Calidad, en
donde existe un fuerte contenido administrativo enfocado a la planeación, organización y
responsabilidad.
En 1954 fue invitado por el JUSE para dar conferencias en Japón, por lo que junto con
Deming e Ishikawa se les considera los principales promotores del éxito de Japón.
La aproximación de JURAN
Planificación de la calidad.
Identificar los clientes.
Establecer las necesidades de los clientes.
Desarrollo de productos/servicios según necesidades del cliente.
Desarrollo de procesos acorde con los productos anteriores.
Transferir los planes resultantes al personal.
Control de calidad.
Evaluar los resultados operativos.
Comparar los resultados con los objetivos.
Actuar en función de las diferencias corrigiendo las desviaciones.
Mejora de la calidad.
Establecer las infraestructuras necesarias para conseguirla.
Identificar las necesidades concretas para mejorar.
Establecer un equipo responsable.
Proporcionar los recursos, motivación y formación al equipo.
5
WALTER A. SHEWHART
La mayor parte de su carrera profesional la ejerció como ingeniero en Western Electric de
1918 a 1924, y en los laboratorios Bell Telephone como miembro del cuerpo técnico de 1925
hasta su retiro en 1956. También dio cátedras sobre control de calidad y estadísticas
aplicadas en la Universidad de Londres, el Instituto Stevens de Tecnología, la escuela de
graduados del Departamento de Agricultura de Estados Unidos y en la India. Fue miembro
del comité de visitas en el Departamento de Relaciones Sociales de Harvard, profesor
honorario en Rutgers y miembro del comité consultivo del departamento de matemáticas de
Princeton. Miembro fundador de la Sociedad Americana de Calidad (ASQ).
1.5. LA CALIDAD Y LOS DEFECTOS
Originalmente, la calidad de un programa o sistema se evaluaba de acuerdo al número de

defectos por cada mil líneas de código. En 1988, un estudio realizado en los EEUU, demostró
que se introducían cerca de sesenta defectos por cada mil líneas de código (60 def/KLOC),
Lograr un alto nivel de calidad de un producto o servicios es el objetivo de muchas
organizaciones. Ya no se acepta entregar productos de calidad pobre y luego arreglar los
problemas y deficiencias después de la entrega al cliente. A este respecto, el software tiene as
mismas características que cualquier otro producto manufacturado como los automóviles, los
televisores o las computadoras.
Sin embargo, la calidad del software es un concepto complejo que no se puede definir de una
forma simple. Clásicamente, la noción de calidad es que el producto desarrollado cumple sus
especificaciones (Crosby), 1979). En un mundo ideal, esta definición aplica a todos los
productos pero, para sistemas de software, existen problemas:
1. La especificación se orienta hacia las características del producto que el consumidor

quiere. Sin embargo, la organización desarrolladora también tiene requerimientos
(como los de mantenimiento) que no se incluyen en la especificación.
6
2. No se sabe como especificar ciertas características de calidad (por ejemplo,

mantenimiento) de una forma no ambigua.
Obviamente, se han hecho esfuerzos para mejorar las especificaciones, pero en la actualidad
se tiene que aceptar que son imperfectas. Se reconocen los problemas con las
especificaciones existentes y se diseñan procedimientos para mejorar la calidad dentro de las
restricciones impuestas por una especificación imperfecta. En particular, los atributos de
software, como la mantenibilidad, la portabilidad o la eficiencia, son atributos de calidad
críticos que no se especifican explícitamente pero que afectan la calidad percibida del
sistema.
La responsabilidad de los administradores de la calidad en una organización es asegurar que

se cumpla el nivel requerido de la calidad de un producto. En principio, la administración de
calidad comprende simplemente definir procedimientos y estándares a utilizar durante el
desarrollo de software y comprobar que todos los ingenieros los sigan. Pero en la práctica la
administración de la calidad es más que esto.
Los buenos administradores de la calidad tienen como propósito desarrollar una “cultura de
la calidad” donde cada persona responsable del desarrollo del producto es motivada para que
logre un alto nivel de la calidad del producto. Fomentan en los equipos a tomar
responsabilidad de la calidad de su trabajo y a desarrollar nuevos enfoques de mejora de la
calidad. Aunque los estándares y los procedimientos son la base de la administración de la
calidad, los administradores de la calidad experimentando reconocen que existen aspectos
intangible para la calidad del software (elegancia, transparencia, etc) que no están incluidas
en los estándares. Apoyan al personal interesado en estos aspectos inteligibles de la calidad y
fomentan el comportamiento profesional en todos los miembros del equipo.
7
UNIDAD II (ADMINISTRACION, ESTANDARES Y SEGURAMIENTO DE LA

CALIDAD)
2.1 LA ADMINISTRACIÓN DE LA CALIDAD DEL SOFTWARE SE ENCUENTRA

EN TRES ACTIVIDADES PRINCIPALES:
1. Aseguramiento de la calidad. El establecimiento de un marco de trabajo de

procedimiento y estándares organizacionales que conduce a software de alta calidad.
2. Planeación de la calidad. La selección de procedimientos y estándares adecuados a
partir de este marco de trabajo y la adaptación de estos para un proyecto de software
especifico.
3. Control de calidad. La definición y promulgación de los procesos que aseguran que
los procedimientos y estándares para la calidad del producto son seguidos por el
equipo de desarrollo de software.
La administración de la calidad provee una comprobación independiente de los procesos de

desarrollo de software. El producto resultante de los procesos del software se introduce en el
proceso de administración de la calidad, donde se comprueba para asegurar que es
consistente con los estándares y metas organizacionales (ver la figura 24.1).
Puesto que los miembros del equipo de aseguramiento y control de la calidad son
independientes, pueden tomar una visión objetiva del proceso y reportar problemas y
dificultades a los administradores principales de la organización.
La administración de la calidad esta separada de la administración de proyectos de manera

que no este comprometida con las responsabilidades de administración del presupuesto y de
la duración del proyecto. Un equipo independiente es responsable de administrar la calidad y
reporta con la administración superior del nivel de administración del proyecto. El equipo de
administración de la calidad no esta asociado con ningún grupo de desarrollo en particular
sino que tiene la responsabilidad de la administración de la calidad del software.
8
Una estándar internacional que se puede utilizar en el desarrollo de un sistema de

administración de calidad en todas las industrias es ISO 9000. Este es un conjunto de
estándares que se aplican a una gran variedad de organizaciones que van desde las de
manufactura hasta las de industria de servicios. ISO 9001 es el mas general de estos
estándares y se aplica a las organizaciones interesadas en el proceso de calidad del diseño,
desarrollo y mantenimiento de productos. Un documento de ayuda (ISO 9000-3) interpreta a
ISO 9000 para el desarrollo de software. Existen varios libros que se describen el estándar
ISO 9000 (Johnson, 1993; Oskarsson y Glass, 1995; Peach, 1996).
ISO 9001 es un modelo genérico de un proceso de calidad. Describe varios aspectos de ese
proceso y define que estándares y procedimientos deben existir dentro de una organización.
Puesto que no se refiere específicamente a una industria, no están definidos en detalle.
Dentro de una organización especifica, el conjunto de procesos de calidad apropiados se
define y documenta en un manual de calidad.
9
2.2 ASEGURAMIENTO Y ESTANDARES DE CALIDAD
Las actividades de aseguramiento de la calidad (QA) definen un marco de trabajo para lograr
la calidad del software. Los procesos QA comprenden definir o seleccionar estándares
aplicables al proceso de desarrollo de software o a los productos de software. Estos
estándares pueden estar incrustados en procedimientos o procesos aplicables durante el
desarrollo. Los procesos se pueden apoyar en herramientas que capturan el conocimiento de
los estándares de calidad.
Existen dos tipos de estándares que se establecen como parte del proceso de
aseguramiento de la calidad:
1. Estándares del producto. Estos son estándares que se aplican al producto de

software a desarrollar. Incluyen estándares de documentos, como la estructura del
documento de requerimientos a producir, estándares de documentación, como
encabezado estándar de comentarios para una definición de clases de objetos,
estándares de codificación, que definen como utilizar un lenguaje de programación.
2. Estándares del proceso. Estos son estándares que definen los procesos a seguir
durante el desarrollo del software. Incluyen definiciones de los procesos de
especificación, de diseño y de validación y una descripción de los documentos a
generar en el trascurso de estos procesos.
Existe una relación muy cercana entre los estándares del producto y del proceso. Los
estándares del producto se aplican a las salidas del proceso del software y, en muchos
casos, los estándares del proceso incluyen actividades específicas del proceso que
aseguran que se siguen los estándares del producto.
1. Proveen un conjunto compacto d las mejores practicas, o al menos de las mas

apropiadas. A menudo, este conocimiento solo se adquiere después de seguir un
proceso de prueba y error. Tenerlo constituido en un estándar evita la repetición
10
de errores anteriores. Los estándares capturan el conocimiento de valor para la

organización.
2. Proveen un marco de trabajo alrededor del cual se implementa el proceso de
aseguramiento de la calidad. Puesto que los estándares capturan las mejores
practicas, el control de la calidad sencillamente segura que los estándares se
siguen adecuándose.
Estándares del producto y del proceso (Figura 24,4)
ESTÁNDARES DEL PRODUCTO ESTÁNDARES DEL PROCESO

Formulación para revisión del diseño Conducto para la revisión del
diseño
Estructura del documento de Subministro de documento a CM
requerimientos
Formato del encabezado del Proceso de entregas de versiones
procedimiento
Estilo de programación en Java Proceso de aprobación del plan del
proyecto
Formato de petición de cambios Proceso de registro de las pruebas
Formato de plan de proyecto Proceso de control de cambio
Los standards aseguran que todos los ingenieros dentro de una organización adopten las
mismas prácticas. En consecuencia, se reduce el esfuerzo de aprendizaje cuando se comienza
un nuevo trabajo.
El desarrollo de los estándares de proyectos de ingeniería de software es un proceso difícil y

largo. Organizaciones nacionales e internacionales como el Departamento de Defensa de los
Estados Unidos. ANSI, BSI, OTAN y el IEEE han estado activamente en la producción de
estándares. Estos son estándares generales que se aplican a una gran variedad de proyectos.
Organizaciones, como la OTAN y otras organizaciones de defensa, requieren que sus propios
estándares se sigan en los contratos de software.
11
Se han desarrollado estándares nacionales e internacionales para cubrir la terminología de la

ingeniería de soltare, los lenguaje de programación como Ada y C++ las notaciones como
las de los símbolos de diagramas, los procedimientos para derivar y redactar requerimientos
de software, los procedimientos de aseguramiento de la calidad y los procesos de verificación
y validación del software (IEEE, 1994).
Los equipos de aseguramiento de la calidad que desarrollan los estándares se apoyan en

estándares organizacionales basados en estándares nacionales e internacionales. Utilizando
estos estándares como un punto de partida, el equipo de aseguramiento de la calidad debe
crear un manual de estándares. Este define los estándares que son apropiados para la
organización. La (Figura 24,4) muestra ejemplos de estándares que se pueden incluir en ese
manual.
Algunas veces los ingenieros de software consideran a los estándares como burocráticos e
irrelevantes para las actividades técnicas del desarrollo de software. Esto es así cuando los
estándares requieren llenar formularios tediosos y registrar el trabajo. Aunque por lo general
los ingenieros están de acuerdo en que los estándares son necesarios, a menudo tienen buenas
razones del porque dichos estándares no son necesariamente apropiados para su proyecto en
particular.
Para evitar estos problemas, los administradores de la calidad que fijan los estándares
requieren estar informando a tomar en consideración los siguientes pasos:
1. Involucrar a los ingenieros de software en el desarrollo de los estándares del

producto. Así comprenderán la motivación detrás del desarrollo de los estándares y se
comprometen con ellos. El documento de los estándares no debe establecer
simplemente que se sigan los estándares sino que deben incluir razones de por que se
tomaron decisiones particulares.
12
2. Revisar y modificar los estándares de forma regular con el fin de reflejar las
tecnologías cambiantes. Una vez que los estándares se desarrollan, tienden a
plasmarse en un manual de estándares de la organización y a menudo existe una
resistencia a cambiarlos. Un manual de estándares es esencial pero debe evolucionar
acorde a las circunstancias y la tecnología cambiantes.
3. Proveer herramientas de software para apoyar a los estándares donde sea necesario.
Los estándares clericales son la causa de muchas quejas debido al trabajo tedioso que
se requiere para implementarlos. Si se dispone de una herramienta de apoyo, no existe
la necesidad de esfuerzo adicional en el desarrollo de los estándares.
Los estándares del proceso provocan dificultades si se impone un proceso no práctico en el

equipo de desarrollo. A menudo, tales estándares simplemente dan lineamientos que deben
interpretarse por los administradores de los proyectos. No existe razón para prescribir una
forma particular de trabajo si esta es inapropiada para los proyectos o para el equipo del
proyecto. Por lo tanto, el administrador de cada proyecto tiene la autoridad de modificar los
estándares del proceso de acuerdo con las circunstancias individuales.
Sin embargo, los estándares relacionados con la calidad del producto y el proceso de post-
entrega solo deben cambiarse después de consideraciones cuidadosas.
El administrador del proyecto y el de la calidad pueden evitarse los problemas de los

estándares inapropiados si planear cuidadosamente la calidad. Deben decidir cuales
estándares del manual utilizar sin cambios alguno, cuales se modifican y cuales se ignoran.
Tienen que crearse estándares nuevos como respuesta a un requerimiento particular del
proyecto. Por ejemplo, se pueden requerir. Estándares para las especificaciones formales si
están no se han utilizando en proyectos previos. Se deben seguir estos nuevos estándares para
evolucionar durante el proyecto.
13
2.3 ESTANDARES DE DOCUMENTACION
Los estándares de documentación en un proyecto de software son documentos muy

importantes ya que son la única forma tangible de representar al software y al proceso del
software. Los documentos estandarizados tienen una apariencia, estructura y calidad
consistentes, y por lo tanto son más fáciles de leer y de comprender.
Muchos estándares y procedimientos corporativos u organizacionales se concentran en las

descripciones que acompañan un conjunto de programas. Se considera como documentación
del programa al conjunto de descripciones escritas que explican al lector que hace el
programa y como lo hace. La documentación interna es el material descriptivo, escrito
directamente dentro del código, y cualquier otra documentación es documentación externa.
Documentación interna
La documentación interna contiene información dirigida a quienes leerán el código fuente del
programa. Se incluye información sumaria para identificar el programa y describir algoritmo,
estructuras de datos y flujo de control. Usualmente esta información se ubica al comienzo de
cada componente en un conjunto de comentarios que se denomina bloque de encabezado.
Encabezamiento: Así como un buen periodista incluye el por que, el cuando, el donde, y los
quienes de una historia, es necesario incluir al comienzo de los programas un
encabezamiento que contenga la siguiente información acerca de cada componente:
1. Que denominación tiene el componente

2. Quien ha escrito el componente
3. Donde va ubicado el componente en el diseño general del sistema
4. Cuando fue escrito, revisado o modificado
5. Por que existe el componente
6. Como utiliza sus estructuras de datos, algoritmos y control
14
Usualmente, los estándares organizacionales especifican el orden y contenido de estos

bloques de comentarios. A continuación se puede apreciar la apariencia típica de un
encabezamiento de esta clase.
Ejemplo:
PROGRAM SCAN: Programa para escanear líneas de texto carácter por carácter
PROGRAMADOR: Beatriz Clemente (809) 345-6765/ bc@power.com
VERSION 1: Escrito el 3 de noviembre 2001 por B. Clemente
DECLARACION DE VARIABLES Y CONTANTE
………
ESTRUCTURA DE DATOS
………..
ALGORITMO Y PROCEDIMIENTO
------------------
Documentación externa
Mientras la documentación interna es concisa y esta escrita en un nivel apropiado para un
programador, la documentación externa se prepara para ser leída incluso por quienes tal vez
nunca verán el código real. Por ejemplo, los diseñadotes pueden revisar la documentación
cuando consideran modificaciones o mejoras. Además, la documentación externa brinda una
oportunidad de explicar las cosas en forma mas amplia que lo que es razonable hacer en los
comentarios. Si se considera que el bloque de comentario del encabezamiento es una vista
global o resumen del programa, entonces, la documentación externa constituye un informe
totalmente desarrollado. Responde a las mismas cuestiones quien, que, por que, cuando,
donde y como desde la perspectiva del sistema, en lugar de la perspectiva de un componente.
Existen tres tipos de estándares de documentación:
1. Estándares del proceso de documentación. Estos definen el proceso a seguir para la

producción del documento.
2. Estándares del documento. Estos gobiernan la estructura y presentación de los
documentos.
15
3. Estándares para el intercambio de documentos. Estos aseguran que todas las copias
electrónicas de los documentos sean compatibles.
Los estándares del proceso definen el proceso utilizando para producir los documentos. Esto
implica definir los procedimientos involucrados en el desarrollo del documento y las
herramientas de software utilizadas para la producción del documento. También definen
procedimientos de comprobación y refinamiento que aseguren que se produzcan documentos
de alta calidad.
Los estándares de calidad del proceso de documentos deben se flexibles y les debe ser
posible ajustarse a todos los tipos de documentos. Para los documentos de trabajo o
memorando, no es necesario comprobar explícitamente la calidad. Sin embargo, si los
documentos son documentos formales utilizados para desarrollos posteriores o son
documentos a entregar a los clientes, se debe adoptar un proceso formal de calidad. La
(figura 24.5) muestra uno de los modelos.
16
Crear un borrador, comprobarlo, revisarlo y rehacerlo es un proceso interactivo. Este

continúa hasta que se produce un documento de calidad aceptable. El nivel de calidad
aceptable depende del tipo de documento y de los lectores potenciales de este.
Los estándares del documento aplican a todos documentos producidos en el transcurso del
desarrollo de software. Los documentos deben tener un estilo y una apariencia consistentes y
los documentos del mismo tipo deben tener una estructura consistente. Aunque los estándares
del documento se adaptan a las necesidades de un proyecto especifico, una buena práctica es
que se utilice el mismo estilo en todos documentos producidos por una organización.
Algunos ejemplos de estándares de documentos a desarrollar son:
1. Estándares de identificación de documentos. Puesto que los proyectos de sistemas

de software grandes producen cientos documentos, cada documento debe identificarse
de forma única. Para los documentos formales, este identificador es el identificador
formal definido por el administrador de la configuración. Para documentos
informales, el estilo del identificador del documento es definido por el administrador
del proyecto.
2. Estándares de la estructura del documento. Cada clase de documentos producido
durante un proyecto de software debe seguir alguna estructura estándar. Los
estándares de estructura deben definir las secciones a incluir y especificar las
convenciones utilizadas para numeración de páginas, el encabezado de las páginas y
la información de los pies de páginas, así como la numeración de secciones y
subsecciones.
3. Estándares de presentación del documento. Estos estándares definen un estilo
propio para los documentos y contribuyen de forma importante a la consistencia de
los mismos. Incluyen la definición de tipos de letra y estilo utilizados en el
documento, la utilización de logotipos y los nombres de la compañía, la utilización de
color para resaltar la estructura del documento, etc.
4. Estándar para actualizar los documentos. Conforme el documento evoluciona y

refleja los cambios en el sistema, se debe utilizar una forma consistente para indicar
17
los cambios en el documento. Se pueden utilizar diversos colores de la portada para

indicar una nueva versión del documento y cambiar las barras en el margen para
indicar párrafos modificados o agregados.
2.4 CALIDAD DEL PROCESO Y DEL PRODUCTO
Una suposición subyacente de la administración de la calidad es que la calidad del proceso de

desarrollo afecta directamente a la calidad de los productos a entregar. Esta suposición se
deriva de los sistemas de manufactura donde la calidad del producto esta íntimamente
relacionada a los procesos de producción. En efecto, en sistemas de información de
producción en masa, una vez que se ha asignado un nivel aceptable de la calidad del proceso,
se sigue naturalmente la calidad del producto. La figura 24.6 ilustra este caso.
La calidad del proceso es muy impotente en el desarrollo del software. La razón esto es que
es difícil medir los atributos de software, como la mantenibilidad, sin utilizar el software por
un periodo largo. El mejoramiento de la calidad se centra en identificar buenos productos de
calidad, examinar el proceso utilizado para desarrollar estos productos y después generalizar
estos procesos para que se apliquen a varios proyectos. Sin embargo, la relación entre el
proceso del software y la calidad del producto de software es compleja. Cambiar el proceso
no siempre conduce a mejorar la calidad del producto.
18
Existe un vínculo claro entre la calidad del proceso y la calidad del producto en la
manufactura debido a que el proceso es relativamente fácil de estandarizar y supervisar. Una
vez que se calibran los sistemas, se ejecutan una y otra vez para producir producto de
software de alta calidad. El software no se manufactura, se diseña. Puesto que el
desarrollo de software es un proceso creativo más que mecánico, la influencia de las
habilidades individuales y las experiencias es importante. Los factores externos, como la
novedad de la aplicación o la presión comercial para entregar un producto, también
afectan la calidad del producto con respecto al proceso utilizado.
Sin embargo, la calidad del proceso tiene una influencia importante en la calidad del
software. La administración de la calidad del proceso comprende:
1. Definir estándares de proceso como las versiones a realizar, cuando llevarlas a

cabo, etc.
2. Supervisar el proceso de desarrollo para asegurar que se sigan estándares.
3. Hacer informes del proceso para la administración del proyecto y para el
comprador del software.
Un peligro del aseguramiento de la calidad basada en procesos es que el proceso prescrito

puede se inapropiado para el tipo de software a desarrollar. Por ejemplo, los estándares de
calidad del proceso pueden indicar que una especificación debe estar completa y aprobada
antes que la implementación inicie. Sin embargo, algunos sistemas requieren la construcción
de prototipos, lo cual implica la implementación del programa.
El equipo de calidad puede indicar que ese prototipo no se puede llevar a cabo debido a que
su calidad no se puede supervisar. En tales situaciones, el administrador principal debe
intervenir para asegurar que el proceso de calidad ayude más que impida el desarrollo del
producto.
19
UNIDAD III (CONTROL Y PLANEACION DE LA CALIDAD)
3.1 PLANEACION DE LA CALIDAD
La planeación de la calidad inicia en las primeras etapas del proceso del software. Un plan de
calidad define la calidad del producto deseado. Define como valorar esta calidad. Por lo
tanto define lo que significa “software de alta calidad”. Sin tal definición, los diferentes
ingenieros pueden trabajar en direcciones opuestas de tal forma que optimicen distintos
atributos del producto. El resultado de un proceso de planeación de la calidad es un plan de
calidad del proyecto.
El plan de calidad selecciona aquellos estándares organizacionales apropiados para un

producto en particular y un proceso de desarrollo. Si el proyecto utiliza nuevos métodos y
herramientas, se tienen que definir nuevos estándares. Humphrey (1989), en su libro clásico
sobre administración del software, sugiere una estructura para un plan de calidad. Esta
estructura comprende:
1. Introducción del producto. Contiene la descripción del producto, el mercado al que

se dirige y las expectativas de calidad del producto.
2. Planes del producto. Contiene las fechas de terminación del producto y las
responsabilidades importantes junto con los planes para distribución y servicio.
3. Descripción del proceso. Contiene los procesos de desarrollo y de servicio a utilizar
para el desarrollo y administración del producto.
4. Metas de calidad. Contiene las metas y planes de calidad par el producto, incluye
una identificación y justificación de los atributos de calidad importantes del producto.
5. Riesgos administración de riesgos. Contiene los riesgos clave que podrían afectar la
calidad del producto y las acciones para abordar estos riesgos.
20
Atributos de calidad de software
Seguridad Compresión Portabilidad

Protección Experimentación Usabilidad
Fiabilidad Adaptabilidad Reutilización
Flexibilidad Modularidad Eficiencia
Robustez Complejidad Aprendizaje
3.2 CONTROL DE CALIDAD
El control de la calidad implica vigilar el proceso de desarrollo de software para asegurar que
se sigan los procedimientos de aseguramiento y estándares de calidad. Los productos
resultantes de un proceso de software se comprueban contra los estándares definidos del
proyecto en el proceso d control de calidad.
El proceso de control de calidad tiene su propio conjunto de procedimientos e informes a

utilizar durante el desarrollo de software. Estos procedimientos son directos y fácilmente
comprensibles por los ingenieros de desarrollo de software.
Existen dos enfoques complementarios para el control de la calidad:
1. Revisión de la calidad en las que el software, su documentación y los procesos

utilizados para producir ese software son revisados por un grupo de personas. Son
responsables de comprobar que se han seguido los estándares del proyecto y que el
software y los documentos están acordes a estos estándares. Toman las desviaciones
de los estándares y las ponen a consideración de la administración del proyecto.
21
2. Valoración automática del software en la que el software y los documentos

producidos se procesan por algún programa y se comparan con los estándares que
aplican a este proyecto de desarrollo en particular. Esta valoración automática
comprende una medida cuantitativa de algunos atributos del software.
3.3 REVISION DE LA CALIDAD

Las revisiones son el método más utilizado para validar la calidad de un proceso o producto.
Involucran a un grupo de personas que examinan parte o todo el proceso del software, los
sistemas o su documentación asociada para descubrir problemas potenciales. Las
conclusiones de la revisión se registran formalmente y se pasan al autor o a quien sea
responsable de corregir los problemas descubiertos.
El cometido del equipo de revisión es detectar los errores e inconsistencias y señalarlas al

diseñador o autor del documento. Las revisiones se basan en documentos pero no se limitan a
las especificaciones, diseño o código. Se revisan todos los documentos tales como los
modelos del proceso, los planes de prueba, los procedimientos de administración de la
configuración, los estándares del proceso y los manuales de usuario.
El equipo de revisión incluye aquellos miembros del proyecto que pueden hacer una
contribución efectiva. Por ejemplo, si se revisa el diseño de un subsistema, los diseñadores de
los subsistemas relacionados se incluyen en el equipo de revisión. Ellos proporcionan
aspectos importantes en las interfaces de subsistemas que podrían estar olvidadas si el
subsistema se considera de forma aislada.
El equipo de revisión tiene un cuerpo principal de tres a cuatros personas designadas como
revisores principales. Uno de los miembros es el diseñador principal que tiene
responsabilidad de tomar decisiones técnicas impotentes. Los revisores principales invitan a
otros miembros del proyecto para que contribuyan en la revisión. Ellos no se involucran en la
revisión de todo el documento. Más bien, se concentran en aquellas partes que afectan a su
trabajo. De forma alternativa, el equipo de revisión hace circular el documento a revisar y
solicita comentarios escritos de otros miembros del equipo del proyecto.
22
Los documentos a revisar se distribuyen con anterioridad a ka revisión para dar tiempo a los
revisores a que lo lean y comprendan. Aunque esto puede interrumpir el proceso de
desarrollo, la revisión no es efectiva si el equipo de revisión no comprende adecuadamente
los documentos antes de que tenga lugar la revisión.
La revisión misma es relativamente corta (dos horas a lo más). El autor del documento en
revisión debe seguir el documento junto con el equipo de revisión. Un miembro del equipo
preside la revisión y otro registra formalmente todas las decisiones de la revisión. Durante
esta, el presidente es responsable de asegurar que se consideren todos los comentarios
escritos. Al término de la revisión, se anotan las acciones y los formularios que registran los
cometarios y las acciones son firmados por el diseñador y el presidente de la revisión.
Después, estos pasan a formar parte de la documentación formal del proyecto. Si solo se
descubren problemas menores, no es necesaria una revisión adicional. El presidente es
responsable de asegurar que se hagan los cambios requeridos. Si se requiere cambios
importantes, se acuerda un seguimiento de la revisión.
3.4 TIPOS DE REVISIONES
Tipo de revisión Propósito principal

Inspecciones de diseño o programas Detectar errores finos en los
requerimientos, el diseño, o el código. La
revisión se conduce por una lista de
verificación de los posibles errores.
Revisión de progreso Proveer información para administrar el
progreso completo del proyecto. Esta es
una revisión tanto del proceso como del
producto y se refiere a los costos, planes y
calendarización.
Revisiones de calidad Llevar a cabo un análisis técnico de los
componentes del producto o
documentación para encontrar diferencias
entre la especificación y el diseño del
23
componente, código y documentación y

para asegurar que se siguen los estándares
de calidad definidos.
3.5 MEDICION Y METRICAS DE SOFTWARE
La medición del software se refiere a derivar un valor numérico para algún atributo de un
producto de software o un proceso del software. Comparando estos valores entre ellos y con
los estándares aplicados en la organización, es posible sacar conclusiones de la calidad del
software o de los procesos del software. Por ejemplo, suponga que una organización hace
planes para introducir una nueva herramienta de prueba de software. Antes de introducir la
herramienta, se registra el número de defectos descubiertos en el software en un tiempo dado;
después de introducir la herramienta, se repite este proceso. Si se descubren más defectos en
la misma cantidad de tiempo después de introducir la herramienta, entonces parecería que
provee ayuda útil para el proceso de validación del software.
Varias compañía grandes tales como Hewlett-Packerd (Grandy, 1993) y AT&T (Barnard y
Price, 1994) han introducido programas de métricas que utilizan métricas recolectadas en sus
procesos de administración de la calidad. El enfoque fue recolectar métricas sobre defectos
en los programas y en los procesos de verificación y validación. Offen y Jeffrey (1997) y
Hall y Fenton (1997) discuten la introducción de tales programas en la industria. El manual
ami (Pulford 1996) da consejos detallados sobre la medición y su utilización para la mejora
de procesos.
Sin embargo, aun es poco común la utilización de medidas y métricas sistemáticas de
software. Existe una reticencia para introducir medidas debido a que los beneficios no son
claros. Una razón de esto es que, en muchas compañías, los procesos del software utilizados
aun están pobremente organizados y no son suficientemente maduros como para utilizar las
medidas. Otra razón es que no existen estándares para las métricas y, por lo tanto, existe
ayuda limitada para la recolección y análisis de datos. Muchas compañías no estarán
preparadas para introducir mediciones hasta que estén disponibles tales estándares y
herramientas.
24
Una métrica de software es cualquier tipo de medida relacionada con un sistema, proceso o
documentación de software. Algunos ejemplos son las medidas que se utilizan para calcular
el tamaño de un producto en líneas de código, el índice de Fog (Gunning, 1962), que es una
medida de la claridad de un párrafo en un texto escrito, el numero de fallas reportadas en un
producto de software entregado y el numero de personas-día requeridas para desarrollar un
componente del sistema.
Las métricas son de control o de predicción. Las métricas de control por lo general se asocian
con los procesos del software; las métricas indicadoras se asocian con los productos de
software. Ejemplos de las métricas de control o de procesos son el esfuerzo y el tiempo
promedio requerido para reparar los defectos reportados. Ejemplos de métricas de predicción
son la complejidad ciclomatica de un modulo, la longitud promedio de los indicadores en un
programa y el numero de atributos y operaciones asociadas con los objetivos de un diseño.
Ambas métricas influyen en la toma de decisiones administrativas.
A menudo, es imposible medir los atributos de calidad del software de forma directa.
Los atributos como la mantenibilidad, la complejidad y la compresión se ven afectados por
diversos factores y no existen métricas directas para ellos. Más bien es necesario medir algún
atributo interno del software (como el tamaño) y suponer que existe una relación entre lo que
se puede medir y lo que se quiere saber. De forma ideal, existe una relación clara valida entre
los atributos de software internos y externos.
25
Figura 24.9
Metricas de prediccion
Y control
Proceso de Producto de
Desoftware software
Medidas de
Medidas de prediccion
control
Decisiones
administrativas
La figura 24.10 muestra algunos atributos de calidad externos de interés y los atributos que
pueden medirse y estar relacionados con los atributos externos. El diagrama sugiere que
existe una relación entre los atributos externos e internos pero no dice que relación es. Si la
medida del atributo interno es un indicador útil de la característica interna del software, se
deben cumplir tres condiciones (Kitchenham, 1990).
26
1. El atributo interno debe medirse de forma precisa.

2. Debe existir una relación entre lo que se puede medir y el atributo de comportamiento
externo.
3. Esta relación se comprende del todo, ha sido validada y se puede expresar en
términos de una formula o modelo.
3.6 PROCESO DE MESICION

En la figura 24.11 se muestra el proceso de medición del software que es parte de un
proceso de control de calidad. Cada uno de los componentes del sistema se analiza por
separado y los diversos valores de las métricas se comparan entre ellos y, quizás, con los
datos históricos de medición recolectados en los proyectos previos. Las medidas
anómalas se utilizan para centrar el esfuerzo de aseguramiento de la calidad de los
componentes que tienen problemas de calidad.
27
Los pasos clave para este proceso son:
1. Seleccionar las medidas a realizar. Se deben formular las preguntas que la

medición intenta responder y definir las medidas requeridas para resolver estas
preguntas. No se recolectan las mediciones que no sean relevantes de forma
directa a estas preguntas. El paradigma GQM (Goal-Question-Metric) de basili
(Basili y Rombach, 1988), es un buen enfoque a utilizar cuando se decide que
datos recolectar.
2. Seleccionar los componentes a evaluar. No es necesario o deseable estimar los

valores de las métricas de todos los componentes de un sistema de software. En
algunos casos, para la medición se elige un conjunto representativo de
componentes. En otros, se evalúan los componentes críticos como los
fundamentales que se utilizan de forma constante.
3. Medir las características de los componentes. Se miden los componentes

seleccionados y se calculan los valores de las métricas. Normalmente, esto
comprende procesar la representación del componentes (diseño, código, etc)
utilizando una herramienta de recolección de datos. Esta herramienta se puede
crear de forma especial o puede estar incorporada en las herramientas CASE
utilizadas en una organización.
4. Identificar las mediciones anómalas. Una vez que se obtienen las mediciones de
los componentes, se comparan entre ellas y con las mediciones previas
registradas en una base de datos de mediciones. Se deben observar los valores
más altos y más bajos de cada métrica puesto que estos sugieren que puede haber
problemas con los componentes que exhiben estos valores.
28
5. Analizar los componentes anómalos. Una vez identificados los componentes

con valores anómalos para las métricas particulares, se examinan estos
componentes para decidir si los valores de la métrica indican que la calidad del
componente esta en peligro. Los valores de la métrica anómalos para la
complejidad (por ejemplo) no necesariamente significa que el componente tenga
calidad deficiente. Puede existir alguna otra razón para el valor alto y no significa
que existan problemas con la calidad del componente.
Los datos recolectados se mantienen como un recurso organizacional, de igual forma los
registros históricos de todos los proyectos deben conservarse aun cuando los datos no se
hayan utilizado durante un proyecto particular. Una vez que se haya creado una base de
datos suficientemente grande de mediciones, se hace la comparación con los proyectos y
las métricas específicas se refinan de acuerdo con las necesidades organizacionales.
Figura 24.11
Proceso de medicion
Del producto
Analizar
Elegir medidas
Componentes
A realizar
anomalos
Seleccionar Identificar
Componenetes Medidas
A evaluar anomalas
Medir caracteristicas
De los componentes
29
3.7 METRICAS DEL PRODUCTO
La métrica del producto se refiere a las características del software mismo.

Desafortunadamente, las características del software que se miden fácilmente como el
tamaño y la complejidad ciclomatica, los atributos de calidad como la compresión y la
mantenibilidad no tienen una relación clara y universal. Las relaciones varían dependiendo
de los procesos y la tecnología de desarrollo y el tipo de sistemas a desarrollar. Las
organizaciones interesadas en la medición tienen que construir una base de datos históricos.
Después, esto se puede utilizar para descubrir como se relacionan los atributos del producto
de software con la calidad en la que esta interesada la organización.
Las métricas del producto se dividen en dos clases:
1. Las métricas dinámicas recolectadas por las mediciones hechas en un programa en

ejecución.
2. Las mediciones estáticas recolectadas por las mediciones hechas en las
representaciones del sistema como diseño, el programa o la documentación.
Estas diferentes métricas están relacionadas con diversos atributos de calidad. Las métricas
dinámicas ayudan a valorar la eficiencia y la fiabilidad de un programa mientras que las
estáticas ayudan a valorar la complejidad, la compresión y la mantenibilidad de un sistema de
software.
Las métricas dinámicas por lo general están relacionadas de forma cercana con los atributos
de calidad del software. Es relativamente fácil medir el tiempo de ejecución requerido por
funciones particulares y estimar el tiempo requerido para iniciar un sistema. Esto se relaciona
directamente con la eficiencia del sistema. De forma similar, se puede registrar el número y
el tipo de caídas del sistema y relacionarlos directamente la fiabilidad del software.
30
Métrica de software Descripción

Fan-in/Fan-out Fan-in es una medida del numero de funciones que llaman a
otra función (por ejemplo, x). Fan-out es el número de
funciones que son llamadas por una función X. Un valor alto de
fan-in significa que X esta fundamentalmente acoplada al resto
del diseño y que los cambios en X tendrán efectos extensivos
contundentes. Un valor alto de Fan-out sugiere que la
complejidad de X podría ser alta debido a la complejidad de la
lógica de control necesaria para coordinar los componentes
llamados.
Longitud del código Esta es una medida del tamaño del programa. Generalmente,
entre mas grande sea el tamaño del código de un componente
del programa, mas complejo y susceptible a errores sea el
componente.
Complejidad Esta es una medida de la complejidad del control de un
ciclomatica programa. Esta complejidad del control esta relacionada con la
compresión del programa.
Longitud de los Es una medida de la longitud promedio de los diferentes
identificadores identificadores en un programa. Entre mas grandes sea la
longitud de los identificadores, es mas probable que tengan
significado y, por lo tanto, el programa será mas comprensible.
Profundidad de la Esta es una medida de la profundidad de anidamiento de las
condicional anidada instrucciones if en un programa. Instrucciones if profundamente
anidadas son difíciles de comprender y son potencialmente
susceptibles a errores.
Indice de fog Esta es una medida de la longitud promedio de las palabras y
declaraciones en los documentos. Entre mas grande sea el valor
del índice de Fog, el documento será mas difícil de comprender.
31
Métricas orientadas a objetos
Métricas orientadas a objetos Descripción

Profundidad del árbol de Esta representa el número de niveles discretos en el
herencia árbol de herencia donde las subclases heredan
atributos y operaciones (métodos) de las superclases.
Entre mas profundo sea el árbol de herencia, mas
complejo será el diseño puesto que muchas clases de
objetos potencialmente distintas tienen que
comprenderse para conocer las clases de objetos en la
hoja del árbol.
Metodo fan-in/fan-out Esta directamente relacionada a fan-in y a fan-out,
como se describió antes, y significa esencialmente lo
mismo. Sin embargo, es conveniente hacer una
distinción entre las llamadas provenientes de otros
métodos dentro del objeto y las llamadas provenientes
de los métodos externos.
Metodos pasados por clase Este es el número de métodos incluidos en una clase
con peso dado por la complejidad de cada método. Por
lo tanto, un método sencillo tiene una complejidad de
1 y un método grande y complejo un valor mucho más
grande. Entre más grande sea el valor de esta métrica,
la clase será mas compleja. Los objetos complejos
tienden a ser más difíciles de comprender. No son
lógicamente cohesivos por lo que no se pueden
reutilizar efectivamente como superclases en un árbol
de herencia.
Numero de operaciones Este es el número de operaciones en una superclase
anuladas que se anulan en una subclase. Un valor alto para esta
métrica indica que la superclase utilizada no es una
madre adecuada para la subclase.
32
Métricas de la calidad de un producto software

• Es difícil, y en algunos casos imposibles, desarrollar medidas directas de los factores de
calidad del software
• Cada factor de calidad Fc se puede obtener como combinación de una o varias métricas:
Fc= c1 * m1 + c2 * m2 + … + cn *mn–ci factor de ponderación de la métrica i, que
dependerá de cada aplicación específica –mi métrica i
– Habitualmente se puntúan de 0 a 10 en las métricas y en los factores de calidad
• Métricas para determinar los factores de calidad

– Facilidad de auditoria
– Exactitud
– Normalización de las comunicaciones
– Completitud
– Concisión
– Consistencia
– Estandarización de los datos
– Tolerancia de errores
– Eficiencia de la ejecución
– Facilidad de expansión
– Generalidad
– Independencia del hardware
– Instrumentación
– Modularidad
– Facilidad de operación
– Seguridad
– Auto-documentación
– Simplicidad
– Independencia del sistema software
– Facilidad de traza
– Formación
33
UNIDAD IV (MODELO Y TECNICA DE LA CALIDAD)
4.1 MODELO DE CALIDAD
El CMM y la mejora continúa del proceso de software
Dentro de la competitividad actual, conseguir productos software excelentes a buen

precio en márgenes de tiempo estrechos es el sueño de miles de empresas. Ello se puede
conseguir concentrando esfuerzos en torno a dos pilares fundamentales: Las personas por un
lado, y los métodos y procedimientos por otro. El Modelo de Madurez de Capacidad del
Software (CMM) hace hincapié en la mejora del proceso de software en base a los
procedimientos internos y sin descuidar a las personas.
4.2 LA MEJORA DEL PROCESO DE GESTIÓN DEL SOFTWARE
Para conseguir tener un proceso de producción de software sin fallos, adecuado a las
necesidades estipuladas en un principio y entregado a tiempo, esta claro que la producción de
software debe convertirse en un proceso disciplinado y aceptado por todos.
Son varias las razones por las que puede fallar el proceso de software, mencionamos las
tres principales:
1. El personal no se involucra lo suficiente en el control de calidad del trabajo.

2. La alta dirección no ha adquirido conciencia de la importancia de un buen proceso de
software para su compañía, la principal consecuencia de esto es que el proceso de software
no tiene los recursos adecuados ya sea en forma de tiempo, dinero, tecnología, personal y
formación de este.
3. Las prácticas establecidas no son las adecuadas.
34
Hasta ahora hemos empleado el termino "proceso de software", pero ¿qué queremos decir
con este término?: "Un proceso es un conjunto de pasos definidos para lograr una
tarea", mientras que "un proceso definido es aquel que esta escrito a tal detalle que
permite que los ingenieros lo usen constantemente". Los procesos definidos ayudan a la
planificación y desarrollo de un trabajo. El proceso que establezcamos debe ser flexible y
debe facilitar el cambio y la innovación. Al mismo tiempo el proceso debe poder ser
aprendido.
Aquí es donde entra el CMM o "Modelo de Madurez de Capacidad del Software". El

CMM esta destinado a la evaluación y mejora de procesos. Se debe evaluar a la organización
para conocerla ya que sin conocerla no se puede mejorar. El propósito de CMM es guiar a
las organizaciones en la selección de estrategias de mejora determinando la madurez del
proceso actual e identificando los puntos importantes que se deben estudiar y trabajar
para mejorar tanto el proceso como la calidad del software. Dicho en palabras de Dymon
[Dymon 1997] ayudar a las personas a identificar aquellas actividades críticas que indican la
capacidad para realizar de la organización. Hay dos razones fundamentales para creer la
efectividad de este modelo:
1. El modelo CMM esta construido en base a prácticas reales.

2. Cada nueva (y correcta) implementación del CMM es un nuevo éxito.
El modelo de madurez de capacidad del software (cmm)
Acabamos de ver una pequeña introducción al significado del CMM. También consideramos
brevemente las ventajas de su empleo en una organización. Ahora bien, ¿tan bueno es el
CMM que no tiene ningún inconveniente? Por supuesto que el CMM tiene inconvenientes,
aunque mejor deberíamos llamarlo riesgos.
El CMM puede ser mal interpretado, para evitarlo es conveniente que las personas que lo
utilicen comprendan el modelo y sus implicaciones a la hora de aplicarlo a la organización.
Este modelo es fruto del trabajo de SEI (Software Engineering Institute), desde 1986
centra sus esfuerzos en mejorar la practica del proceso del Software. En 1991 consiguieron
35
estabilizar la primera versión del CMM. Desde entonces este modelo se ha empleado en
organizaciones tales como el Departamento de Defensa de los EEUU, sedes que necesitaban
controlar de manera exhaustiva el proceso de producción de software.
El CMM es una forma de comprender la propia gestión de procesos dentro de la

organización. Es cierto que el CMM evalúa a la organización ya que para mejorar es preciso,
antes, evaluar. Pero no podemos cometer el error de reducir el CMM a una mera lista de
comprobación, el CMM es mucho más que eso, es una "institucionalización" del proceso
para construir software con el objetivo de conseguir una mejora continua.
A la hora de aplicar el CMM debemos tener claro una serie de aspectos sobre la
organización, dichos aspectos son:
1. El tamaño de la organización.
2. Su nivel cultural.
3. Las tecnologías que emplea.
Conociendo estos tres puntos podemos acometer el conocimiento de los objetivos de la

organización. Posteriormente deberemos decidir como vamos a medir.
El CMM establece 5 posibles niveles de madurez en los que puede encontrarse una
organización:
a) Nivel 1: El más básico.

b) Nivel 2 (el proceso repetible).
c) Nivel 3 (el proceso definido).
d) Nivel 4 (el proceso gestionado).
e) Nivel 5 (el proceso de optimización).
36
Nadie puede obtener el significado exclusive del CMM. El CMM no aporta una medida
absoluta, no existe un nivel de 2'5, todos los resultados deben ser interpretados, mejor así ya
que el CMM es flexible para adaptarse en su utilización a las peculiaridades de cada
organización. Debido a este punto, el conocimiento del Modelo por parte de quien lo aplica
se hace aún más importante.
Nos queda ahora abordar en profundidad el proceso del CMM, para ello debemos tener en
cuenta las siguientes definiciones [Paulk 1994]:
a) Institucionalizar: Edificar una infraestructura y una cultura que soporte los métodos, las
prácticas y los procesos para que éstos sean la forma real de hacer negocios.
Será fundamental conocer cual es el grado de conocimientos de todos sus trabajadores, así
como el esquema cultural y social en que se ubica la empresa.
b) Proceso de Software: Conjunto de actividades, métodos, prácticas y transformaciones

para desarrollar y mantener software y productos asociados.
c) Capacidad de un proceso: Rango de resultados esperados que se pueden obtener tras

seguir un proceso.
d) Madurez de un proceso de software: Es el punto hasta el que un determinado proceso

está explícitamente definido, administrado, medido, controlado y ejecutado de manera
efectiva.
e) Nivel de madurez: Plataforma bien definida desde la que podemos obtener un proceso
maduro de software.
f) Procedimiento documentado: La actividad o procedimiento es un proceso rutinario y que

ha sido codificado.
37
4.3 CARACTERÍSTICAS DEL CMM
Comenzaremos este apartado dando una definición formal al CMM [Dymon1997]. “El
CMM es un modelo que describe cómo las prácticas de la ingeniería del software de una
organización evolucionan bajo ciertas condiciones:
1º.- El trabajo es organizado y visto como un proceso.

2º.- La evolución del proceso es gestionada sistemáticamente.”
El CMM guarda cierta relación con los estándares de calidad como ISO 9001, en palabras de
Dymon, “este estándar es efectivo para proporcionar una base de una buena práctica por
debajo de la cual una organización no debería descender”. Por el contrario, el CMM es un
estándar progresivo con una dimensión dinámica que conduce a una organización a mejorar
continuamente sus prácticas actuales de software.
Según los estudios realizados por el SEI una organización que se encuentre en un nivel
de madurez 3 podría obtener sin problemas la certificación ISO 9001. Pero una
organización que posea una certificación ISO 9001 podría quedar ubicada en un nivel
de madurez 2 o 3, dependiendo del caso. Para obtener mayores detalles en esta comparación
se puede consultar la obra [Paulk 1994].
CARACTERÍSTICAS DE LOS NIVELES DEL MODELO DE CMM
Nivel Características Transición al Siguiente Nivel

Inicial Poca formalización, junto Iniciar una administración rigurosa del
(Procesos con herramientas proyecto, y asegurar la cálida
Disciplinado) informalmente aplicadas al
proceso
Repetible Se logro un proceso Establecer un grupo de proceso y una
(Procesos estable con un nivel arquitectura de proceso de desarrollo de
Estandarizados) repetible de control software. Introducir métodos y tecnologías
estadístico de ingeniería de software
Definido Se logro una base para un Establecer un conjunto básico de
(Procesos progreso mayor continuo administraciones de proceso para
Predecibles) identificar la calidad y costo de los
parámetros y una base de datos del
38
proceso. Juntar y mantener datos del

proceso e informar a la administración
Administrado Mejoras sustanciales en Apoyar la recopilación automática de datos
(Procesos calidad junto con medidas del proceso.
Mejora comprensivas del proceso Usar datos para analizar y modificar el
Continua) proceso
Optimizado Mejorías en Base a mayor Continuar Mejorando y optimizando el
calidad y cantidad proceso.
Detallemos ahora un poco más los distintos niveles de madurez:
1) Nivel 1: Nivel inicial, el proceso de software es impredecible y poco controlado. Esto no

significa que una organización no produzca buen software, sino que el coste (financiero,
humano, temporal, etc.) es demasiado alto tanto para los productores como para los usuarios.
2) Nivel 2: Nivel repetible, en este nivel existe una disciplina básica en la gestión de procesos
basada en la repetición de tareas aprendidas previamente. Ya hay una planificación en
términos de coste, calendario y requisitos.
3) Nivel 3: Nivel definido, el proceso es estándar y consistente, se conoce lo que hace que el
proceso de software tenga éxito y se aplica a toda la organización.
4) Nivel 4: Nivel gestionado, el proceso del nivel 3 es medido y controlado

cuantitativamente, está implementado en toda la organización.
5) Nivel 5: Nivel optimizado, existe una evolución continua en la optimización del proceso.
El CMM se centra en los tres principales aspectos que influyen en una organización:
a) Las personas: Se trata por disciplinas como el desarrollo organizativo, gestión de los
RRHH y la Gestión de la Calidad Total (TQM).
39
b) La tecnología: La tecnología cambia a su propio ritmo a lo largo del tiempo, se puede

adquirir.
c) El proceso. Pero, ¿cómo se gestiona el proceso y cómo se mejora?, ¿se puede comprar? La
gestión del proceso se puede aprender e institucionalizar, aquí es donde entra el CMM.
La complejidad aparente del CMM se simplifica en cuatro conceptos base:
- La evolución es posible pero lleva tiempo.

- Hay etapas distinguibles en la madurez del proceso.
- La evolución implica que algunas cosas deben ser aplicadas antes que otras.
- La madurez disminuirá al menos que se mantenga. “Los cambios duraderos
requieren un esfuerzo constante” [Dymon 1997]. Para cambiar el proceso del software
debemos:
- Gestionar las influencias.
- Gestionar las mejoras sistemáticas.
El cambio puede empezar a aplicarse a través del ciclo de Deming: Planificar, Hacer,
Verificar y Actuar [Deming 1982]. Adaptado a nuestra situación, Iniciar es acordar el motivo
y la estrategia para el cambio. Diagnosticar es acordar qué cambiar, posteriormente debemos
Establecer la infraestructura (equipos y planes), Actuar (llevar a cabo los planes) e
Institucionalizar (capturar y reutilizar las lecciones aprendidas).
Volvemos aquí a insistir en algo de crucial importancia, la aplicación del modelo requiere el
compromiso de la alta dirección ya que está claro que durante un tiempo ciertos recursos
deberían desviarse de las actividades de generar ingresos y dedicarse a la mejora del proceso.
40
4.4 MODELO ISO 9000
Historia
Se denomina ISO 9000 a una serie de estándares que pueden ser usados por diferentes
empresas para establecer la gestión de un sistema de calidad. Pero hay que aclarar que ISO
9000 no tiene nada que ver con la calidad absoluta del producto; sólo se refiere a la forma de
establecer guías para un sistema de gestión de la calidad.
Los estándares fueron publicados por primera vez en 1987, por la International Organization
for Standardization (ISO), cuya sede central está en Ginebra, Suiza.
Hasta cierto punto, los estándares británicos BS 5750 sirvieron de base para las series ISO
9000. Y más lejos aún, otra referencia clara para ISO 9000 son los estándares generados
durante la Segunda Guerra Mundial en los Estados Unidos, con especificaciones militares
muy precisas, que tenían por objetivo evitar la falta de coordinación entre distintos
fabricantes o suministradores de armas y otros productos. Estas especificaciones pasarían
posteriormente a la OTAN bajo la denominación AQAP.
La serie ISO 9000 se compone de cinco documentos independientes aunque relacionados. El
estándar ISO 9000 es una guía para la selección y uso de los estándares reales, ISO 9001,
ISO 9002 e ISO 9003. ISO 9000 incluye las siguientes definiciones para el resto de la serie:
- Política de Calidad
- Gestión de Calidad
- Sistema de Calidad
- Control de Calidad
- Aseguramiento de la Calidad
Impacto de ISO 9000

Desde su introducción, ISO 9000 ha tenido un impacto creciente en el comercio internacional
y es considerado el lenguaje común sobre la calidad. Los estándares han sido redactados
intencionadamente de manera muy amplia, así que pueden ser aplicados a empresas de muy
diverso tamaño en todos los sectores de actividad económica.
41
La mayor fuerza de empuje para ISO 9000 en los últimos años ha sido el Acta Única
Europea, ya que la Unión Europea necesitaba un sistema de harmonización para todos sus
miembros, que han desarrollado sus respectivas industrias de manera independiente y con
hábitos comerciales muy diferentes. ISO 9000 ha proporcionado una buena herramienta de
puesta en común.
Objetivos
El propósito de ISO 9000 es incrementar la confianza de los clientes y consumidores en el
sistema de calidad de sus suministradores. Un dato que es particularmente importante cuando
se amplían las distancias entre las partes, o se usan diferentes idiomas y términos. ISO 9000
proporciona el marco común necesario, con requerimientos generales específicos para ambas
partes.
El objetivo, pues, no es determinar que un producto es superior a otro, sino más consistente y
fiable en su producción. Es decir, ISO asegura que la producción genera productos de una
calidad homogénea (sea ésta alta o baja) a lo largo del tiempo. Es decir, un producto de hoy
ha de ser igual que un producto de ayer y lo mismo que uno de mañana.
Qué es Calidad y Sistema de Calidad

El término Calidad designa muchas cosas distintas para distintas personas. Es una idea muy
subjetiva. Además, el producto de mayor calidad no es necesariamente el mejor para realizar
un trabajo concreto, que tal vez necesite gastar su presupuesto en otras necesidades más
importantes. En términos generales, pues, ISO se refiere a Calidad como "apropiado para el
uso". Y un Sistema de Calidad es "la planificación y sistematización de todas las actividades
necesarias para llegar a un adecuado nivel de confianza". En palabras sencillas: "decir lo que
se hace, hacer lo que se dice, archivar lo que se hizo, comprobar los resultados y actuar
sobre las diferencias que se encuentren en ellos".
42
Dos tipos de estándares en ISO 9000

En la serie 9000 hay dos tipos de estándares. Unos son Estándares Guía, como ISO 9000 y
9004; su misión es describir los parámetros principales y ayudar a elegir los estándares
apropiados.
El segundo tipo son los Estándares de Conformidad, ISO 9001, 9002 y 9003. Las empresas
u organizaciones sólo pueden ser certificadas para uno de estos tres estándares de la serie.
Qué diferencias existen entre los Estándares de Conformidad
Debe quedar claro que los tres estándares de conformidad NO son ni representan niveles de
calidad, sino que varían en el grado de amplitud de la estandarización.
• ISO 9003 : Es un modelo para la Conformidad de Calidad en la Inspección Final.

• ISO 9002 : Es un modelo para la Conformidad de Calidad en Producción, Instalación
y Servicios.
• ISO 9001 : Es un modelo para la Conformidad de Calidad en el Diseño, Desarrollo,
Producción, Instalación y Servicios.
Dudas y preguntas sobre ISO 9000
¿Cuánto dura el proceso de certificación?: Alrededor de dos años.
Decir realmente lo que se hace: cuando se describen los procedimientos

productivos, no hay que tratar de que suenen bien; hay que hacerlos reales.
Una vez puestos sobre el papel, hay que cumplirlos.
ISO no es igual a Gestión de Calidad Total: ISO es un sistema para

asegurar la consistencia en la producción; la Gestión de Calidad Total busca
generar un proceso empresarial de continua mejora.
Revisiones periódicas: Una vez que una empresa consigue el certificado de

estandarización no termina el papel de ISO; un auditor independiente puede
ser requerido para realizar comprobaciones, incluso cada seis meses. Además,
los estándares ISO 9000 tienen una duración de cinco años, después de los
cuales deben ser revisados.
43
Beneficios de ISO 9000
• 1: Ayuda a centrar la empresa sobre el problema de producir con calidad.

• 2: Puede contribuir a superar una situación anterior de desorganización productiva.
• 3: Determina las responsabilidades de cada uno en la cadena productiva y registra
todo el proceso para verificar dónde se producen los fallos.
• 4: Mejora la competitividad en el mercado y la fiabilidad de los clientes
• 5: Puede disminuir el conjunto de los gastos productivos, al aumentar la eficacia.
4.5 FACTORES QUE DETERMINAN LA CALIDAD DE UN PRODUCTO DE

SOFTWARE
Se clasifican en tres grupos:

Operaciones del producto: características operativas
– Corrección (¿Hace lo que se le pide?)
• El grado en que una aplicación satisface sus especificaciones y consigue los objetivos
encomendados por el cliente
– Fiabilidad (¿Lo hace de forma fiable todo el tiempo?)
• El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificadas
y con la precisión requerida
– Eficiencia (¿Qué recursos hardware y software necesito?)
• La cantidad de recursos hardware y software que necesita una aplicación para realizar las
operaciones con los tiempos de respuesta adecuados
– Integridad (¿Puedo controlar su uso?)
• El grado con que puede controlarse el acceso al software o a los datos a personal no
autorizado
– Facilidad de uso (¿Es fácil y cómodo de manejar?)
• El esfuerzo requerido para aprender el manejo de una aplicación, trabajar con ella,
introducir datos y conseguir resultados.
• Revisión del producto: capacidad para soportar cambios
– Facilidad de mantenimiento (¿Puedo localizar los fallos?)
44
• El esfuerzo requerido para localizar y reparar errores

– Flexibilidad (¿Puedo añadir nuevas opciones?)
• El esfuerzo requerido para modificar una aplicación en funcionamiento
– Facilidad de prueba (¿Puedo probar todas las opciones?)
• El esfuerzo requerido para probar una aplicación de forma que cumpla con lo especificado
en los requisitos.
• Transición del producto: adaptabilidad a nuevos entornos

– Portabilidad (¿Podré usarlo en otra máquina?)
• El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo
– Reusabilidad (¿Podré utilizar alguna parte del software en otra aplicación?)
• Grado en que partes de una aplicación pueden utilizarse en otras aplicaciones
– Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o sistemas informáticos?
• El esfuerzo necesario para comunicar la aplicación con otras aplicaciones o sistemas
informáticos.
4.6 CERTIFICACIÓN DE LA CALIDAD (QUALITY CERTIFICATION)
• Un sistema de certificación de calidad permite una valoración independiente que debe

demostrar que la organización es capaz de desarrollar productos y servicios de calidad
• Los pilares básicos de la certificación de calidad son tres [Sanders 1994, p. 44] :
– Una metodología adecuada
– Un medio de valoración de la metodología
– La metodología utilizada y el medio de valoración de la metodología deben estar
reconocidos ampliamente por la industria
45
4.7 NORMAS DE LA SERIE ISO 9000:2000
El sistema de gestión de calidad propuesto por la norma ISO 9000:2000 se basa en 8

principios:
1. Enfoque al cliente: las organizaciones dependen de sus clientes y por lo tanto

deberían comprender las necesidades actuales y futuras de los clientes, satisfacer los
requisitos de los clientes y esforzarse en exceder las expectativas de los clientes.
2. Liderazgo: los líderes establecen la unidad de propósito y la orientación de la

organización. Ellos deberían crear y mantener un ambiente interno, en el cual el
personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la
organización
3. Participación del personal: El personal, a todos los niveles, es la esencia de una

organización y su total compromiso posibilita que sus habilidades sean usadas para el
beneficio de la organización.
4. Enfoque basado en procesos: Un resultado deseado se alcanza más eficientemente

cuando las actividades de los recursos relacionados se gestionan como un proceso.
5. Enfoque de sistema para la gestión: identificar, entender y gestionar los procesos

interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una
organización en el logro de sus objetivos.
6. Mejora continua: la mejora continua del desempeño global de la organización

debería ser un objetivo permanente de ésta.
7. Enfoque basado en hechos para la toma de decisión: las decisiones eficaces se

basan en el análisis de los datos y la información.
46
8. Relaciones mutuamente beneficiosas con el proveedor: una organización y sus

proveedores son interdependientes, y una relación mutuamente beneficiosa aumenta
la capacidad de ambos para crear valor.
La figura ilustra el sistema de gestión de calidad basado en procesos descrito en la familia de

normas ISO 9000. Esta ilustración muestra que las partes interesadas juegan un papel
significativo para proporcionar elementos de entrada a la organización. El seguimiento de la
satisfacción de las partes interesadas requiera la evaluación de la información relativa a su
percepción de hasta que punto se han cumplido sus necesidades y expectativas.
47
Sistema de Gestión de Calidad

Mejora continua
Responsabili-
dad de la
dirección
Satisfacción
C Medición, C
Gestión de
l análisis, l
Requisitos
recursos
mejora
i i
e e
n Resultado
n
Entrada Realización del
t Producto/ t
producto y/o servicio Servicio
e e
Sistema de Gestión de Calidad
Actividades que aportan Flujo de información

valor
Se distinguen cuatro grupo de procesos.
1) Responsabilidad de la dirección
a) Compromiso de la dirección
b) Enfoque al cliente
c) Política de calidad
d) Planificación
e) Responsabilidad, autoridad y comunicación
f) Revisión de la dirección
2) Gestión de los recursos

a) Recursos humanos
b) Infraestructura
c) Ambiente de trabajo
3) Realización del producto

a) Planificación de la realización del producto.
b) Procesos relacionados con el cliente.
c) Diseño y desarrollo.
d) Compras.
e) Producción y prestación del servicio.
f) Control de los dispositivos de seguimiento y medición.
4) Medición, análisis y mejora

a) Seguimiento y medición
48
b) Control del producto no conforme

c) Análisis de datos
d) Mejora
4.8 ESTRUCTURA DE ISO 9000:2000
La serie ISO 9000:2000 está compuesta por tres normas:
ISO 9000:2000- Sistemas de gestión de la calidad: Fundamentos y vocabulario

ISO 9001:2000- Sistemas de gestión de la calidad: Requisitos
ISO 9004:2000- Sistemas de gestión de la calidad: Directrices para la mejora del
desempeño.
La Norma ISO 9000:2000 constituye una norma explicativa del enfoque de procesos y de los
principales elementos de un sistema de calidad. Contiene también una relación completa del
vocabulario utilizado en Gestión de Calidad.
Las Normas ISO 9001:2000 e ISO 9004:2000 constituyen un par consistente. Esto es, tiene la
misma estructura organizativa.
La ISO 9001:2000 indica los requisitos que una organización debe cumplir, con relación a su
Sistema de Gestión de la Calidad, cuando este sistema es evaluado por una organización
independiente, con relación a su proceso de certificación.
La ISO 9004:2000, con la misma estructura de la 9001, constituye una guía para la mejora
del desempeño de las organizaciones. O sea, ISO 9001 e ISO 9004 han sido diseñadas para
complementarse entre sí.
ISO 9004 proporciona orientación sobre un rango más amplio de objetivos de un sistema de
gestión de la calidad que ISO 9001, especialmente para la mejora continua y la eficiencia
global de la organización, así como su eficacia. Sin embargo la Norma ISO 9004:2000 no
está elaborada con propósitos de certificación.
49
4.9 MODELOS DE EXCELENCIA
CRITERIOS PARA LA EXCELENCIA ACADÉMICA - MALCOLM BALDRIGE
ESTRATEGIAS, DESAFÍOS, RELACIONES, PLANES DE ACCION
2 5
PLANEAMIENTO GESTION DE
ESTRATÉGICO LAS
PERSONAS 7
RESULTADOS
DEL
1 DESEMPEÑO DE
LIDERAZGO 3 LA
FOCO EN LA ORGANIZACIÓN
6
SATISFACCION DEL GESTION DE
ALUMNO, PARTES LOS
INVOLUCRADAS, Y PROCESOS
MERCADO
4 INFORMACIÓN Y ANALISIS
1.- Liderazgo:
Liderazgo organizacional.
Responsabilidad Pública y Ciudadana.
2.- Planeamiento estratégico:
Proceso de planeamiento estratégico.
Planeamiento operativo.
3.- Enfoque en el alumno y en las otras partes involucradas:
Conocimiento de las necesidades y expectativas del alumno (actual y potencial).
Gestión de la relación y satisfacción del alumno y otras partes involucradas
4.- Información y Análisis:
Medición del desempeño de la organización.
Análisis del desempeño de la organización
5.- Desarrollo del cuerpo docente, de gestión y apoyo:
Sistema de trabajo.
Educación, entrenamiento y desarrollo del personal académico y de apoyo.
Bienestar y satisfacción del cuerpo docente y personal de apoyo.
6.- Gestión de los procesos educativos y de apoyo:
Diseño y gestión del proyecto pedagógico-educativo.
Gestión de procesos de apoyo.
Gestión del las relaciones con etapas anteriores y posteriores
7.- Resultados de desempeño de la organización:
Resultados del desempeño de los alumnos.
50
Resultados de la satisfacción de los alumnos y otras partes involucradas..

Resultados de los docentes y personal de apoyo.
Resultados financieros y presupuéstales.
Resultados del desempeño y efectividad general de la organización.
Las dimensiones de evaluación que normalmente se utilizan, en los modelos de

excelencia, son tres:
• Enfoque: se refiere a la filosofía de diseño de los sistemas, los métodos, principios y

conceptos que son empleados para alcanzar el propósito de calidad en cada uno de los
temas de evaluación. Al analizar este aspecto, la evaluación se hará tomado en
cuenta:
o El grado en que se esté orientado hacia la prevención más que la corrección
o El grado en que se tiende hacia la mejora de los procesos, más que a la
corrección de los productos.
o El grado en que se fomenta la toma de decisiones basadas en información y
datos, más que en opiniones.
o El grado en que se busca estimular la autoevaluación por parte del personal,
más que la inspección o supervisión.
o El grado en que los procesos se orientan primordialmente a lograr la
satisfacción del cliente (procesos eficaces).
o El grado en que se trabaja en la mejora de la eficiencia de los procesos.
o El grado en que se tiende hacia contar con procesos sistemáticos e integrales,
buscando propiciar la mejora continua.
• Implantación: se refiere al nivel de aplicación del enfoque e incluye:

o El alcance con que se han introducido apropiada y efectivamente los
principios de calidad en todas las áreas, funciones y actividades de la
organización.
o La práctica sistemática y rutinaria de los principios de calidad, en todas las
actividades e interacciones “clientes – proveedor”, tanto al interior como al
entorno de la organización (clientes, proveedores y la sociedad en general)
51
• Resultados: son los logros derivados de la Implantación y el Enfoque de los sistemas

en la organización. Incluyen información cuantitativa, cualitativa, comparación de
parámetros e impactos de los logros. Se toma en cuenta la calidad de los resultados, o
sea los niveles alcanzados, como también la duración de los resultados, o sea la
tendencia. Se consideran los siguientes aspectos:
o Nivel de calidad alcanzada, comparándolos con los competidores líderes,
tanto nacionales como mundiales.
o Tendencias de mejora continua y rapidez de dichas mejoras
o Impacto que dichos logros han tenido en la posición competitiva,
participación en los mercados, retención de los clientes y rentabilidad de la
organización.
o Mejora de calidad de la vida de sus empleados y trabajadores.
o Mejora y desarrollo de sus proveedores
o Mejora del bienestar de los consumidores.
o Mejora en el entorno social y en el medio ambiente.
4.10 EL MODELO DE McCALL.
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el
usuario puede contemplar la calidad de un producto, basándose en once factores de calidad
organizados en torno a los tres ejes y a su vez cada factor se desglosa en otros criterios:
Puntos De Factor Criterios

Vista O Ejes
OPERACIÓN Facilidad de uso - Facilidad de operación: Atributos del software que
DEL determinan la facilidad de operación del software.
PRODUCTO
- Facilidad de comunicación: Atributos del software que
proporcionan entradas y salidas fácilmente asimilables.
- Facilidad de aprendizaje: Atributos del software que

facilitan la familiarización inicial del usuario con el
software y la transición del modo actual de operación.
- Formación: El grado en que el software ayuda para
52
permitir que nuevos usuarios apliquen el sistema.
Integridad - Control de accesos. Atributos del software que

proporcionan control de acceso al software y los datos que
maneja.
- Facilidad de auditoría: Atributos del software que facilitan

la auditoría de los accesos al software.
- Seguridad: La disponibilidad de mecanismos que

controlen o protejan los programas o los datos.
Corrección - Completitud: Atributos del software que proporcionan la
implementación completa de todas las funciones requeridas.
- Consistencia: Atributos del software que proporcionan

uniformidad en las técnicas y notaciones de diseño e
implementación.
- Trazabilidad o rastreabilidad: Atributos del software que

proporcionan una traza desde los requisitos a la
implementación con respecto a un entorno operativo
concreto.
OPERACIÓN Fiabilidad - Precisión: Atributos del software que proporcionan el
DEL grado de precisión requerido en los cálculos y los
PRODUCTO resultados.
- Consistencia.
- Tolerancia a fallos: Atributos del software que posibilitan

la continuidad del funcionamiento bajo condiciones no
usuales.
- Modularidad: Atributos del software que proporcionan

una estructura de módulos altamente independientes.
- Simplicidad: Atributos del software que posibilitan la

implementación de funciones de la forma más comprensible
posible.
- Exactitud: La precisión de los cálculos y del control.
53
Eficiencia - Eficiencia en ejecución: Atributos del software que

minimizan el tiempo de procesamiento.
- Eficiencia en almacenamiento: Atributos del software que

minimizan el espacio de almacenamiento necesario.
REVISION Facilidad de - Modularidad.
DEL mantenimiento
PRODUCTO - Simplicidad.
- Consistencia.
- Concisión: Atributos del software que posibilitan la

implementación de una función con la menor cantidad de
códigos posible.
- Auto descripción: Atributos del software que

proporcionan explicaciones sobre la implementación de las
funciones.
Facilidad de - Modularidad.
prueba
- Simplicidad.
- Auto descripción.
- Instrumentación: Atributos del software que posibilitan la

observación del comportamiento del software durante su
ejecución para facilitar las mediciones del uso o la
identificación de errores.
Flexibilidad - Auto descripción.
- Capacidad de expansión: Atributos del software que

posibilitan la expansión del software en cuanto a
capacidades funcionales y datos.
- Generalidad: Atributos del software que proporcionan

amplitud a las funciones implementadas.
- Modularidad.
Reusabilidad - Auto descripción.
- Generalidad.
54
- Modularidad.
-Independencia entre sistema y software: Atributos del

software que determinan su dependencia del entorno
operativo.
- Independencia del hardware: Atributos del software que

determinan su dependencia del hardware.
Interoperabilidad - Modularidad.
- Compatibilidad de comunicaciones: Atributos del

software que posibilitan el uso de protocolos de
comunicación e interfaces estándar.
- Compatibilidad de datos: Atributos del software que

posibilitan el uso representaciones de datos estándar.
- Estandarización en los datos: El uso de estructuras de

datos y de tipos estándar a lo largo de todo el programa.
Portabilidad - Auto descripción.
- Modularidad.
-Independencia entre sistema y software.
- Independencia del hardware.
4.11 CÓMO EMPLEAR EL MODELO DE McCall.
Antes de comenzar a utilizar el modelo de McCall hay que seguir las siguientes pautas:
1. Se aceptan los factores, criterios y métricas que propone el modelo.

2. Se aceptan las relaciones entre factores y criterios, y entre criterios y métricas.
3. Se selecciona un subconjunto de factores de calidad sobre los que aplicar los
requisitos de calidad establecidos para el proyecto.
Al comienzo del proyecto habrá que especificar los requisitos de calidad del producto
software, para lo cual se seleccionarán los aspectos inherentes a la calidad deseada del
producto, teniendo que considerarse para ello:
55
• Las características particulares del propio producto que se está diseñando: por
ejemplo, su ciclo de vida que si se espera que sea largo implicará un mayor énfasis en
la facilidad de mantenimiento y la flexibilidad, o bien si el sistema en desarrollo está
destinado a un entorno donde el hardware evoluciona rápidamente implicará como
requisito su portabilidad.
• La relación calidad-precio, que puede evaluarse a través del coste de cada factor de
calidad frente al beneficio que proporciona. La siguiente tabla muestra la relación
calidad-precio para cada factor considerado:
Factor Beneficio / coste

Corrección alto
Fiabilidad alto
Eficiencia bajo
Integridad bajo
Facilidad de uso medio
Facilidad de mantenimiento alto
Facilidad de prueba alto
Flexibilidad medio
Portabilidad medio
Reusabilidad medio
Interoperabilidad bajo
• La determinación de las etapas del ciclo de vida donde es necesario evaluar cada
factor de calidad para conocer en cuales se dejan sentir más los efectos de una calidad
pobre con respecto a cada uno de los factores.
• Las propias interrelaciones entre los factores debido a que algunos factores pueden
entrar en conflicto entre sí: por ejemplo, la eficiencia plantea conflictos prácticamente
con todos los demás factores de calidad. La interacción entre los diversos factores a
evaluar queda reflejada en la tabla I que indica la dependencia entre los factores de
McCall.
56
También habrá que establecer valores deseables para los criterios, para lo cual se emplearán
datos históricos, el promedio en la industria, y con ellos se concretarán los valores finales y
otros intermedios o predictivos en cada período de medición durante el desarrollo, así como
unos valores mínimos aceptables. La explicación para cualquier selección o decisión deberá
ser adecuadamente documentada.
En la fase de desarrollo será necesario implementar las métricas elegidas, analizar sus
resultados y tomar medidas correctivas cuando los valores obtenidos estén por debajo de los
mínimos aceptables.
Una vez finalizado el proyecto será necesario contrastar las medidas predictivas utilizadas y
comprobar si, en efecto, se pueden tomar como indicadores de los valores finales.
57
4.12 Proceso Unificado de Rational)
RUP es un proceso para el desarrollo de un proyecto de software que define claramente

quien, cómo, cuándo y qué debe hacerse en el proyecto, con 3 características esenciales, está
dirigido por los Casos de Uso: que orientan el proyecto a la importancia para el usuario y lo
que este quiere , está centrado en la arquitectura: que Relaciona la toma de decisiones que
indican cómo tiene que ser construido el sistema y en qué orden, y es iterativo e
incremental: dividiéndose el proyecto en mini proyectos donde los casos de uso y la
arquitectura cumplen sus objetivos de manera más depurada.
58
También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de
IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las
diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la
personalización de acuerdo a necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y
una especificación más detallada, el Rational Unified Process, que luego se vendiera como
producto independiente.
Este maneja 6 principios clave:
1. Adaptación del proceso

El proceso deberá adaptarse a las características propias de la organización. El tamaño del
mismo, así como las regulaciones que lo condicionen, influirán en su diseño específico.
También se deberá tener en cuenta el alcance del proyecto.
2. Balancear prioridades
Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o
disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.
3. Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples equipos.
Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones,
planes, resultados, etc.
4. Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.
En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del
producto, y se refina la dirección del proyecto así como también los riesgos involucrados.
5. Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del
software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Éstos se pueden
acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.
59
6. Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos
de la producción.
Historia
El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson

Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en
componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995
Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory
(abreviación de Object Factory).
Posteriormente en 1995 Rational Software Corporation adquiere Objectory Aby entre 1995 y
1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque
Rational (Rational Approach) adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh,
Rational Software desarrolló e incorporó diversos elementos para expandir ROP,
destacándose especialmente el flujo de trabajo conocido como modelado del negocio. En
junio del 1998 se lanza Rational Unified Process.
Ciclo de vida de RUP

RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en los
distintas actividades.
Fase de inicio
Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.
Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso más
esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan de
negocio para determinar que recursos deben ser asignados al proyecto.
60
Los objetivos de esta fase son:

Establecer el ámbito del proyecto y sus límites.
Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que definen la
funcionalidad.
Mostrar al menos una arquitectura candidata para los escenarios principales.
Estimar el coste en recursos y tiempo de todo el proyecto.
Estimar los riesgos, las fuentes de incertidumbre.
Los resultados de la fase de inicio deben ser:

Un documento de visión: Una visión general de los requerimientos del proyecto,
características clave y restricciones principales.
Modelo inicial de Casos de Uso (10-20% completado).
Un glosario inicial: Terminología clave del dominio.
El caso de negocio.
Lista de riesgos y plan de contingencia.
Plan del proyecto, mostrando fases e iteraciones.
Modelo de negocio, si es necesario
Prototipos exploratorios para probar conceptos o la arquitectura candidata.
Al terminar la fase de inicio se deben comprobar los criterios de evaluación para
continuar:
Todos los interesados en el proyecto coinciden en la definición del ámbito del sistema
y las estimaciones de agenda.
Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos de Uso
principales.
Las estimaciones de tiempo, coste y riesgo son creíbles.
Comprensión total de cualquier prototipo de la arquitectura desarrollado.
Los gastos hasta el momento se asemejan a los planeados.
Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo
profundamente
61
Fase de elaboración
El propósito de la fase de elaboración es analizar el dominio del problema, establecer los

cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones
sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos de Uso
críticos identificados en la fase de inicio. También debe demostrarse que se han evitado los
riesgos más graves.
Los objetivos de esta fase son:

Definir, validar y cimentar la arquitectura.
Completar la visión.
Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en
sucesivas iteraciones. Debe incluir los costes si procede.
Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y
en un tiempo razonable.
Al terminar deben obtenerse los siguientes resultados:

Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos
actores identificados, la mayoría de los casos desarrollados.
Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito
no asociado con un Caso de Uso específico.
Descripción de la arquitectura software.
Un prototipo ejecutable de la arquitectura.
Lista de riesgos y caso de negocio revisados.
Plan de desarrollo para el proyecto.
Un caso de desarrollo actualizado que especifica el proceso a seguir.
Un manual de usuario preliminar (opcional).
En esta fase se debe tratar de abarcar todo el proyecto con la profundidad mínima.
Sólo se profundiza en los puntos críticos de la arquitectura o riesgos importantes.
En la fase de elaboración se actualizan todos los productos de la fase de inicio.
62
Los criterios de evaluación de esta fase son los siguientes:

La visión del producto es estable.
La arquitectura es estable.
Se ha demostrado mediante la ejecución del prototipo que los principales elementos
de riesgo han sido abordados y resueltos.
El plan para la fase de construcción es detallado y preciso. Las estimaciones son
creíbles.
Todos los interesados coinciden en que la visión actual será alcanzada si se siguen los
planes actuales en el contexto de la arquitectura actual.
Los gastos hasta ahora son aceptables, comparados con los previstos.
Si no se superan los criterios de evaluación quizá sea necesario abandonar el proyecto
o replanteárselo considerablemente.
Fase de construcción
La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma
incremental a través de las sucesivas iteraciones. Durante esta fase todos los componentes,
características y requisitos deben ser implementados, integrados y probados en su totalidad,
obteniendo una versión aceptable del producto.
Los objetivos concretos según [KRU00] incluyen:

Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el
tener que rehacer un trabajo o incluso desecharlo.
Conseguir una calidad adecuada tan rápido como sea práctico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido
como sea práctico.
Los resultados de la fase de construcción deben ser [RSC98]:
Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación)
Arquitectura íntegra (mantenida y mínimamente actualizada)
Riesgos Presentados Mitigados
Plan del Proyecto para la fase de Transición.
Manual Inicial de Usuario (con suficiente detalle)
63
Prototipo Operacional – beta

Caso del Negocio Actualizado

El producto es estable y maduro como para ser entregado a la comunidad de usuario
para ser probado.
Todos los usuarios expertos están listos para la transición en la comunidad de
usuarios.
Son aceptables los gastos actuales versus los gastos planeados.
Fase de transición
La finalidad de la fase de transición es poner el producto en manos de los usuarios finales,

para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la
documentación, entrenar al usuario en el manejo del producto, y en general tareas
relacionadas con el ajuste, configuración, instalación y facilidad de uso del producto.
Algunas de las cosas que puede incluir esta fase:

Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas de
los usuarios.
Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por
nuestro proyecto.
Conversión de las bases de datos operacionales.
Entrenamiento de los usuarios y técnicos de mantenimiento.
Traspaso del producto a los equipos de marketing, distribución y venta.
Los principales objetivos de esta fase son:
Conseguir que el usuario se valga por si mismo.
Un producto final que cumpla los requisitos esperados, que funcione y satisfaga
suficientemente al usuario.
64
Los resultados de la fase de transición son:

Prototipo Operacional
Documentos Legales
Caso del Negocio Completo
Línea de Base del Producto completa y corregida que incluye todos los modelos del
sistema
Descripción de la Arquitectura completa y corregida
Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva
versión.

El usuario se encuentra satisfecho.
Son aceptables los gastos actuales versus los gastos planificados.
Roles, actividades, artefactos y flujos de trabajo

Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP define
cuatro elementos los roles, que responden a la pregunta ¿Quién?, las actividades que
responden a la pregunta ¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los
flujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo?
Roles
Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de
individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles,
así como un mismo rol puede ser representado por varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el
ser el dueño de un conjunto de artefactos.
Analistas:
Analista de procesos de negocio.
Diseñador del negocio.
Analista de sistema.
Especificador de requisitos.
65
Desarrolladores:
Arquitecto de software.
Diseñador
Diseñador de interfaz de usuario
Diseñador de cápsulas.
Diseñador de base de datos.
Implementador.
Integrador.
Gestores:
Jefe de proyecto
Jefe de control de cambios.
Jefe de configuración.
Jefe de pruebas
Jefe de despliegue
Ingeniero de procesos
Revisor de gestión del proyecto
Gestor de pruebas.
Apoyo:
Documentador técnico
Administrador de sistema
Especialista en herramientas
Desarrollador de cursos
Artista gráfico
Especialista en pruebas:
Especialista en Pruebas (tester)
Analista de pruebas
Diseñador de pruebas
66
Otros roles:
Stakeholders.
Revisor
Coordinación de revisiones
Revisor técnico
Cualquier rol
Actividades
Una actividad en concreto es una unidad de trabajo que una persona que desempeñe un rol
puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente
expresado en términos de crear o actualizar algún producto.
Artefactos
Un producto o artefacto es un trozo de información que es producido, modificado o usado
durante el proceso de desarrollo de software. Los productos son los resultados tangibles del
proyecto, las cosas que va creando y usando hasta obtener el producto final.
Un artefacto puede ser cualquiera de los siguientes:

Un documento, como el documento de la arquitectura del software.
Un modelo, como el modelo de Casos de Uso o el modelo de diseño.
Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un
Caso de Uso o un subsistema.
Flujos de trabajo
Con la enumeración de roles, actividades y artefactos no se define un proceso, necesitamos
contar con una secuencia de actividades realizadas por los diferentes roles, así como la
relación entre los mismos. Un flujo de trabajo es una relación de actividades que nos
producen unos resultados observables. A continuación se dará una explicación de cada flujo
de trabajo.
Ejemplo: Configuración RUP para proyecto pequeño

A continuación se describen brevemente cada uno de los artefactos que se generarán y usarán
durante el proyecto.
67
1. Flujos de Trabajo
Se utilizarán Diagramas de Actividad para modelar los Flujos de Trabajo (workflows) del
área problema, tanto los actuales (previos a la implantación de nuevo sistema) como los
propuestos, que serán soportados por el sistema desarrollado.
2. Características del Producto Software

Es una lista de las características principales del producto, deseables desde una perspectiva
de las necesidades del cliente.
3. Glosario
Es un documento que define los principales términos usados en el proyecto.
Permite establecer una terminología consensuada.
4. Modelo de Casos de Uso

El modelo de Casos de Uso presenta la funcionalidad del sistema y los actores que hacen uso
de ella. Se representa mediante Diagramas de Casos de Uso.
5. Especificaciones de Casos de Uso

Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste
con una simple descripción narrativa) se realiza una descripción detallada utilizando una
plantilla de documento, donde se incluyen: precondiciones, postcondiciones, flujo de
eventos, requisitos no-funcionales asociados.
6. Modelo de Análisis y Diseño

Este modelo establece la realización de los casos de uso en clases y pasando desde una
representación en términos de análisis (sin incluir aspectos de implementación) hacia una de
diseño (incluyendo una orientación hacia el entorno de implementación). Está constituido
esencialmente por un Diagrama de Clases y algunos Diagramas de Estados para las clases
que lo requieran.
7. Modelo Lógico Relacional

Previendo que la persistencia de la información del sistema será soportada por una base de
datos relacional, este modelo describe la representación lógica de los datos persistentes, de
68
acuerdo con el enfoque para modelado relacional de datos. Para expresar este modelo se
utiliza un Diagrama de Tablas donde se muestran las tablas, claves, etc.
8. Modelo de Implementación
Este modelo es una colección de componentes y los subsistemas que los contienen. Estos
componentes incluyen: ficheros ejecutables, ficheros de código fuente, y todo otro tipo de
ficheros necesarios para la implantación y despliegue del sistema.
9. Modelo de Pruebas
Para cada Caso de Uso se establecen pruebas de Aceptación que validarán la correcta
implementación del Caso de Uso. Cada prueba es especificada mediante un documento que
establece las condiciones de ejecución, las entradas de la prueba, y los resultados esperados.
10. Manual de Instalación

Este documento incluye las instrucciones para realizar la instalación del producto.
11. Material de Usuario

Corresponde a un conjunto de documentos y facilidades de uso del sistema.
12. Producto
Todos los ficheros fuente y ejecutable del producto.
69
4.13 EL PROCESO UNIFICADO: DIRIGIDO POR CASOS DE USO, CENTRADO

EN LA ARQUITECTURA, ITERATIVO E INCREMENTAL (UML)
La atención actual en el software lleva a la construcción de sistemas más grandes y más

complejos. Esto es debido en parte al hecho de que los computadores son mas potentes cada
año, y los usuarios, por tanto, esperan mas de ellos. Esta tendencia también se ha visto
afectada por el uso creciente de Internet para el intercambio de todo tipo de información de
texto sin formato a texto con formato, fotos, diagramas y multimedia. Nuestro apetito de
software aun más sofisticado crece a medida que vemos como pueden mejorarse los
productos de una versión a otra. Queremos un software que este mejor adaptado a nuestras
necesidades, pero esto, a su vez, simplemente hace el software más complejo. En breve
queremos más.
También los queremos as rápido. El tiempo de salida al mercado es otro conductor
importante.
70
Conseguirlo, sin embargo, es difícil. Nuestra demanda de software potente y complejo no e

corresponde con como se desarrolla el software. Hoy, la mayoría de la gente desarrolla
software mediante los mismos métodos que llevan utilizando desde hace 25 años. Esto es un
problema. A menos que renovemos nuestros métodos, no podremos cumplir con el objetivo
de desarrollar el software complejo que se necesita actualmente.
El problema del software se reduce a la dificultad que afrontan los desarrolladores para
coordinar las múltiples cadenas de trabajo de un gran proyecto de software. La comunidad de
desarrolladores necesita una forma coordinada de trabajar. Necesita un proceso que integre
las múltiples facetas del desarrollo. Necesita un método común, un proceso que:
1. Proporcione una guía para ordenar las actividades de un equipo.
2. Dirija las tareas de cada desarrollador por separado y del equipo como un todo.
3. Especifique los artefactos que deben desarrollarse.
4. Ofrezca criterios para el control y la medición de los productos y actividades del
proyecto.
El proceso unificado en pocas palabras (UML)
En primer lugar, Proceso Unificado es un proceso de desarrollo de software. Un proceso de

desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos
de un usuario en un sistema software (ver figura 1.1). Sin embargo, el Proceso Unificado es
mas que un simple proceso, es un marcho de trabajo genérico que puede especializarse para
una gran variedad de sistemas software, para diferentes áreas de aplicación, diferente tipos de
organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto.
El Proceso Unificado esta basado en componentes, lo cual quiere decir que el sistema
software en construcción esta formado por componentes software, interconectados a través
de interfaces.
Los Proceso Unificado utilizan el lenguaje Unificado de Modelado (Unified Modeling
Language, UML) para preparar todos los esquemas de un sistema de software. De hecho,
UML es una parte esencial del Proceso Unificado sus desarrollos fueron paralelos.
71
No obstante, los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres
frases clave dirigido por casos de uso, centrado en la arquitectura e iterativo e incremental.
Esto es lo que hace único el Proceso Unificado.
Los tipos de diagramas disponible

Diagram Type
Description Descripción
Diagrama de Tipo
Class Diagram is a visual expression of various static relations of
class-related elements. Diagrama de clases es una expresión visual
de diferentes relaciones estáticas de la clase de elementos
Class Diagram relacionados. Class Diagram can contain not only classes but also
Diagrama de clases interfaces, enumerations, packages, various relations, instances, and
their links. Diagrama de clases pueden contener no sólo las clases,
sino también las interfaces, enumeraciones, paquetes, relaciones
diferentes, de los casos, y sus enlaces.
Use Case Diagram is an expression of relations between the use
cases in a specific system or object and the external actors.
Diagrama de casos de uso es una expresión de las relaciones entre
Use Case Diagram los casos de uso en un sistema específico o el objeto y los actores
Diagrama de Casos de externos. Use Case expresses the functions of the system and how
Uso the system functions interact with the external actors. Casos de Uso
expresa las funciones del sistema y cómo funciona el sistema de
interactuar con los actores externos.
Sequence Diagram expresses the interactions of instances.
Diagrama de Secuencia expresa las interacciones de los casos. It is
a direct expression of the InteractionInstanceSet, which is a set of
the stimuli exchanged between the instances within a
CollaborationInstanceSet. Se trata de una expresión directa de la
Sequence Diagram InteractionInstanceSet, que es un conjunto de estímulos
Diagrama de Secuencia intercambiados entre las instancias dentro de un
CollaborationInstanceSet. While Sequence Role Diagram is a
ClassifierRole-oriented expression, Sequence Diagram is an
Instance-oriented expression. Mientras Secuencia Papel diagrama
es una expresión orientada ClassifierRole, diagrama de secuencia
72
es una instancia de expresión orientado.

Sequence Role Diagram expresses the interactions of the role
concepts. It is a direct expression of the Interaction, which is a set
of the messages exchanged between the ClassifierRoles within a
Collaboration. While Sequence Diagram is an Instance-oriented
expression, Sequence Role Diagram is a ClassifierRole-oriented
Sequence Diagram expression. Diagrama de Secuencia de Papel expresa la interacción
(Role) Diagrama de de los conceptos de función. Se trata de una expresión directa de la
Secuencia (Papel) interacción, que es un conjunto de los mensajes intercambiados
entre el ClassifierRoles dentro de una colaboración. Mientras
diagrama de secuencia es una instancia de expresión orientada,
Secuencia Papel diagrama es una ClassifierRole expresión
orientada.
Collaboration Diagram expresses the collaboration between
instances. Diagrama de colaboración expresa la colaboración entre
las instancias. It is a direct expression of the collaboration model of
the instances within a CollaborationInstanceSet. Se trata de una
Collaboration expresión directa del modelo de colaboración de las instancias
Diagram Diagrama de dentro de un CollaborationInstanceSet. While Collaboration Role
colaboración Diagram is a ClassifierRole-oriented expression, Collaboration
Diagram is an Instance-oriented expression. Mientras Colaboración
Papel diagrama es una expresión orientada ClassifierRole,
Diagrama de colaboración es una instancia de expresión orientada.
Collaboration Role Diagram expresses the collaboration between
the role concepts. Colaboración Papel Diagrama expresa la
colaboración entre los conceptos de función. It is a direct
expression of the collaboration model of the ClassifierRoles within
Collaboration a Collaboration. Se trata de una expresión directa del modelo de
Diagram (Role) colaboración de la ClassifierRoles dentro de una colaboración.
Diagrama de While Collaboration Diagram is an Instance-oriented expression,
colaboración (Papel) Collaboration Role Diagram is a ClassifierRole-oriented
expression. Mientras que la colaboración Diagrama es una instancia
de expresión orientado a la colaboración Papel diagrama es una
expresión de ClassifierRole orientada.
Statechart Diagram expresses the static behaviors of a specific
object through states and their transitions. Diagrama de estados
expresa el comportamiento estático de un objeto específico a través
de los estados y sus transiciones. Although Statechart Diagram is
Statechart Diagram generally used to express the behaviors for instances of classes, it
Diagrama de estados can also be used to express behaviors of other elements. Aunque
Statechart diagrama se utiliza generalmente para expresar el
comportamiento de las instancias de las clases, también puede ser
utilizado para expresar el comportamiento de otros elementos.
Activity Diagram is a special form of Statechart Diagram that is
Activity Diagram suitable for expressing the activity execution flow. Diagrama de
73
Diagrama de actividad actividad es una forma especial de Statechart Diagrama que es

adecuado para expresar el flujo de ejecución de actividades.
Activity Diagram is commonly used for expressing workflow, and
it is frequently used for objects like classes, packages, and
operations. Diagrama de actividad se utiliza comúnmente para
expresar el flujo de trabajo, y es frecuentemente utilizado para
objetos como clases, paquetes, y las operaciones.
Component Diagram expresses the dependency between the
software components. Diagrama de componentes expresa la
dependencia entre los componentes de software. The elements that
Component constitute software components and the elements that implement
Diagram Diagrama de those components can all be expressed by Component Diagram.
componentes Los elementos que constituyen los componentes de software y los
elementos que poner en práctica esos componentes pueden ser
expresadas por los componentes de diagrama.
Deployment Diagram expresses the hardware elements of the
physical computer and devices and the software components,
Deployment processes and objects that are assigned to them. Diagrama de
Diagram Diagrama de implementación expresa los elementos de hardware del equipo
implementación físico y los dispositivos y los componentes de software, procesos y
objetos que les son asignadas.
Composite Structure Diagram is a diagram to express internal
Composite structure of Classifier. Diagrama de estructura compuesta es un
Structure Diagram diagrama de expresar la estructura interna de clasificador. It is
Diagrama de estructura included in interaction point with other parts of system. Se incluye
compuesta Diagrama en el punto de interacción con otras partes del sistema.
74
ANEXOS
75
CONSULTA A EXPERTOS (Caso I)
EXP- EXP- EXP- EXP- EXP-

DESCRIPCION 1 2 3 4 5 TOTAL
Compromiso de la dirección
Medición de la Calidad
Evaluación del Costo de la Calidad
Conciencia de la Calidad
Acción correcta
Planificación del cero defectos
El día cero defectos
Entrenamiento de los supervisores
Fijación de Metas
Eliminación de Metas
Eliminación de causas de error
Reconocimiento
Consejos de Calidad
Hacer todo de nuevo
No se puede tolerar los niveles aceptados de error
Crear constancia en el propósito de mejorar el
producto y servicios
Dejar de depender de la inspección en masa
Dejar de hacer negocios sobre la base del precio
Mejorar el Sistema de Producción y Servicios
Implantar la formación
Erradicar el miedo
Adoptar e implantar el liderazgo
Derribar las barreras entre Depto.
Eliminar cuotas numéricas
Fomentar el orgullo por el trabajo
Estimular la educación, Auto mejoras
Lograr la transformación
Identificar los Clientes
Establecer las Necesidades de los Clientes
Desarrollo de productos servicios según
necesidades del Cliente
Desarrollo de Procesos acorde con los productos
anteriores
Transferir los planebs Resultantes al Personal
Evaluar los resultados operativos
Comparar los resultados con los objetivos
Actuar en función de las diferencias corrigiendo las
desviaciones
Establecer las Infraestructuras necesarias para
76
conseguirlo
Identificar las necesidades concretas para mejorar
Establecer un equipo responsable
Proporcionar los recursos, motivación y formación
al equipo
Total General
Total Promedio por Experto

Exp-1 Exp-2 Exp-3 Exp-4 Exp-5 TOTAL%
Leyenda:
Debe marcar la casilla correspondiente con un valor de 1 si es afirmativo o un valor 0 si no

aplica.
Exp-1= Juan Pérez
TOTAL= Exp-1+ Exp-2+ Exp-3+ Exp-4+ Exp-5
TPxE= Total Promedio por Experto

TPxE= (Total General Exp_1 x 100)/ Sumatoria TOTAL
Nota: Hacer esta operación para los 5 expertos.
GESTION DE CONFIGURACION (Caso II)

Si No No se
¿Conoce que es la GCS?
¿Existen procedimientos definidos para la GCS?
¿Se controlan las versiones?
¿Las solicitudes de cambio son recibidas, analizadas,

ejecutadas, revisadas y almacenadas?
GCS= Gestión Configuración Software
77
EVALUACIÓN DE LAS TRES ESCUELAS DE LOS PRINCIPIOS DE CALIDAD

REALIZADA POR EXPERTOS EN DESARROLLO DE SOFTWARE
NOMBRE:_____________________________________________________
EMPRESA:____________________________________________________
DESCRIPCIÓN APLICA
SI/NO
Compromiso de la dirección
Equipo de mejora de la Calidad
Medición de la Calidad
Evaluación del Costo de la Calidad
Conciencia de la Calidad
Acción correcta
Planificación del cero defectos
El día cero defectos
Entrenamiento de los supervisores
Fijación de Metas
Eliminación de Metas
Eliminación de causas de error
Reconocimiento
Consejos de Calidad
Hacer todo de nuevo
No se puede tolerar los niveles aceptados de error
Crear constancia en el propósito de mejorar el producto y servicios
Dejar de depender de la inspección en masa
Dejar de hacer negocios sobre la base del precio
Mejorar el Sistema de Producción y Servicios
Implantar la formación
Erradicar el miedo
Adoptar e implantar el liderazgo
Derribar las barreras entre Depto.
Eliminar cuotas numéricas
Fomentar el orgullo por el trabajo
Estimular la educación, Auto mejoras
Lograr la transformación
Identificar los Clientes
Establecer las Necesidades de los Clientes
Desarrollo de productos servicios según necesidades del Cliente
Desarrollo de Procesos acorde con los productos anteriores
Transferir los planes Resultantes al Personal
Evaluar los resultados operativos
78
Comparar los resultados con los objetivos

Actuar en función de las diferencias corrigiendo las desviaciones
Establecer las Infraestructuras necesarias para conseguirlo
Identificar las necesidades concretas para mejorar
Establecer un equipo responsable
Proporcionar los recursos, motivación y formación al equipo
SISTEMA DE COMPRAS
NARRATIVA DEL SISTEMA
El sistema de Compras comprende tres grandes procesos: Solicitud de Requerimiento,
Cotizaciones y Generación de Orden, todos estos procesos interactúen entre si generando
información los cuales la salida en la culminación de cada uno de los procesos representa la
entrada de información necesaria para que los demás procesos se desarrollen con normalidad.
Además de estos tres grandes procesos el sistema de Compras también se relaciona con el
sistema administrativo financiero, almacén, planificación y recursos humanos.
Dentro de las actividades que realiza cada proceso están las siguientes:
Proceso Solicitud de Servicios. Un empleado de las áreas o departamento de la empresa u

organización solicita un servicio o requerimiento de Compras la cual esta compuesta por los
diferentes producto así como la medida o empaque en el cual estas definido el producto. Esta
solicitud debe estar certificada o validada por el jefe inmediato de la persona que realiza la
petición del servicio.
Proceso de Cotización. Una vez realizado el registro de petición del servicio, el

departamento de Compras verifica y validad dicha información y pasa a desarrollar el
proceso de cotización el cual consiste en seleccionar todos los productos de la solicitud de
servicio y agruparlos por tipo y enviarlos a los proveedores activos disponibles que se
encuentran en su base de datos, este proceso debe ser simultáneamente a tres proveedores
diferentes por razones de controles institucionales. Una vez concluido pasa a la recepción de
la confirmación enviada por los proveedores sobre los productos cotizados el depto, de
Compras hace una evaluación de los precios escogiendo los que mas se ajusten a la escala de
precio según las políticas de la organización.
Proceso Orden de Compras: El depto de Compras toma la cotización seleccionada y

realiza el proceso de generación de la orden validando el presupuesto que tiene asignado cada
departamento que realiza una solicitud una vez concluido este proceso le envía un original y
una copia al suplidor para que haga la entrega en el tiempo establecido de la orden de
Compras, archiva una copia y envía otra al departamento financiero para que realice el
proceso de pago de dicha orden.
79
CASO PRACTICO
USO HERRAMIENTA UML
Modelo sistema de Compras
80
81
Causas de defectos durante el desarrollo

Requermientos incorrectos, perdidos o no claros
Analisis de requerimientos Traduccion incorrecta o no clara
Diseño del sistema Especificacion de diseño incorrecta o no clara
Especificacion de diseño incorrecta o no clara

Diseño del
programa Mala interpretacion del diseño del sistema
Mala interpretacion del diseño del programa

Implementacion Documentacion incorrecta
Del programa Sintaxis o semantica incorrecta
Prueba unitarias Procedimientos de prueba incompletos

Y de integracion Nuevos defectos introducidos al corregir los viejos
Prueba del sistema Procedimientos de prueba incompletos
Documentacion incorrecta de usuario

Carencias de factores humanos
Mantenimiento
Nuevos defectos introducidos al corregir los viejos
Cambios en los requerimientos
82
TABLA 8.1
CLASIFICACIÓN ORTOGONAL DE DEFECTOS DE IBM
Tipos de defectos Significado
Función Defecto que afecta la capacidad, interfaces de

usuario final, interfaces de producto,
interfaces con la arquitectura hardware o la
estructura global de datos.
Interfaz Defecto en la interacción con otros

componentes o controladores por vía de
llamadas, macros, bloques de control o listas de
parámetros.
Comprobación Defecto en la lógica del programa, que falla al

validar valores y datos correctamente antes que
sean utilizados.
Asignación Defecto en la estructura de datos o en la

inicialización de un bloque de código.
Sincronización /Serialización Defecto que involucra sincronización de

recursos compartidos y de tiempo real.
Construcción/Empaquetado/Combinación Defecto que ocurre debido a problemas en

repositorios, gestión de cambios o control de
versiones.
Documentación Defecto que afecta publicaciones y notas de

mantenimiento.
Algoritmo Defecto que involucra la eficiencia o exactitud

de un algoritmo o estructura de datos, pero el
diseño.
83
CUADRO DESTACADO 9.4

DIFERENCIAS ENTRE CONFIABILIDAD DE HARDWARE Y DE SOFTWARE
Mellor (1992) explica por qué las fallas del hardware son sustancialmente diferentes de las
fallas del software.
El hardware complejo falla cuando un componente se rompe y deja de funcionar de
acuerdo con lo especificado. Por ejemplo una compuerta lógica puede quedar retenida en
O o en 1 y una resistencia se puede poner en corto circuito. La causa es física (por ejemplo,
oxidación, corrosión, sobretensión) y el defecto se produce en un instante particular. Para
arreglar el problema, se repara o reemplaza la parte afectada y el sistema puede restaurarse
a su estado previo.
Sin embargo, los defectos del software pueden existir en un producto por un tiempo muy
largo y activarse solamente cuando existen ciertas condiciones que transforman el defecto
en una falla. Esto significa que, el defecto está latente y el sistema seguirá fallando (bajo las
mismas condiciones) a menos que se modifique el software para corregir el problema
subyacente.
Debido a esta diferencia en los efectos de los defectos, la confiabilidad del software se debe
definir de una manera distinta a la del hardware. Cuando se repara hardware, retorna a su
nivel de confiabilidad previo a la falla, es decir se mantiene la confiabilidad. Pero cuando se
repara software, la confiabilidad puede incrementar o disminuir. Por lo tanto, la meta de
confiabilidad en ingeniería de hardware es la estabilidad; la meta correspondiente en la
ingeniería del software es el aumento de la confiabilidad.
84

USO INCORRECTO DE UNA VERSIÓN BETA
En julio de 1997, la NASA tuvo algunos problemas con el dispositivo de aterrizaje del
Pathfinder que colocó al dispositivo de exploración Sojourner sobre el planeta Marte. El
software del Pathfinder le permitía posarse obre la superficie de Marte, liberar al
explorador Sojourner y gestionar la comunicación entre Tierra y el aterrizador. Sin
embargo, debido a fallas relacionadas con la administración de pilas y punteros durante los
procesos de conmutación, el Pathfinder se reinicializó a sí mismo, interrumpiendo su
trabajo por algunos períodos de tiempo.
El Sojourner estaba equipado con un controlador serial de tareas simple 80C85, que
trabajaba muy bien. Pero la NASA necesitó un software mucho más complejo para
gestionar las funciones más complejas del Pathfinder. Durante el diseño, la NASA
seleccionó en primer lugar un procesador objetivo (target) y luego encontró el software
apropiado para ejecutar en él. En consecuencia, la NASA seleccionó un procesador de IBM
muy resistente a la radiación, una versión nueva de su R6000, similar al procesador
utilizado en PowerPC. El chip de 32 bits resultaba atractivo porque utilizando un sistema
operativo de tiempo real comercial para él se evitaba el costo de construir un software
específico. Por lo tanto, el próximo paso de la NASA fue encontrar un sistema operativo
para el Pathfinder.
Había varios sistemas operativos disponibles y la NASA seleccionó VxWorks de Wind

River Systems (Alameda, California). Cuando se hizo la selección, el VxWorks estaba
probado y disponible comercialmente para PowerPC, Sin embargo, la versión diferenciada
para el R6000 todavía no estaba lista. En consecuencia, Wind River Systems convirtió la
versión para PowerPC del sistema operativo VxWorks al R6000, sacando ventaja de la
portabilidad del lenguaje C. El producto convertido fue entregado a la NASA en 1994.
Cuando llegó la versión para R6000 del sistema VxWorks, la NASA congeló la
configuración del Pathfinder en la versión 5.1.1, aunque algunos problemas significativos
con el sistema operativo todavía no habían sido resueltos. Por lo tanto, el software del
Pathfinder estaba construido en realidad alrededor de una versión de prueba beta de su
sistema operativo, en lugar de estar montado sobre un sistema operativo robusto y
completamente probado (Coffee 1997).
85

MEDIDA DE LA EFECTIVIDAD Y LA EFICIENCIA DE LA PRUEBA
La medida de la efectividad de la prueba es un aspecto relevante de la planificación y la

generación de informes de resultados. Graham (1996b) señala que la efectividad de prueba
puede medirse dividiendo el número de defectos localizados por una prueba dada por el
número total de defectos encontrados (incluidos aquellos que se descubren después de la
prueba). Supóngase, por ejemplo, que durante una prueba de integración se descubren 56
defectos y que durante el proceso de prueba completo se encuentran 70 defectos en total.
Entonce, la medida de Graham de la efectividad de prueba indica para la prueba de
integración una efectividad del 80%. Sin embargo, supóngase que el sistema se entrega
después de localizar y subsanar esos 70 defectos, pero que durante los primeros seis meses
de operación del sistema se encuentran 70 defectos más. Por lo tanto, la prueba de
integración es responsable de la localización de 56 de los 140 defectos, lo que da una
efectividad de sólo un 40%.
Este enfoque para la evaluación del impacto de una fase o técnica particular de prueba puede
ser ajustado de varias maneras. Es posible categorizar las fallas por niveles de severidad y se
puede calcular la efectividad de prueba por niveles. Con este criterio, la prueba de
integración podría tener una efectividad del 50% para la localización de defectos que
provocan fallas críticas, pero ser un 80% efectiva para descubrir defectos que causan fallas
menores. Como alternativa, la efectividad de prueba puede combinarse con el análisis de
causa raíz, de modo que se puede describir la efectividad para encontrar defectos tan pronto
como sea posible en el proceso de desarrollo. Por ejemplo, la prueba de integración puede
localizar el 80% de los defectos, pero la mitad de ellos podría haber sido descubierta más
temprano, durante la revisión del diseño, ya que se trata de problemas de diseño.
La eficiencia de prueba se calcula dividiendo el número de defectos encontrados

durante las pruebas por el esfuerzo necesario para realizarlas, lo que da un valor mensurable
en defectos por hora-plantel. La medida de la eficiencia ayuda a comprender el costo que
conlleva encontrar los defectos así como los costos relativos de localizarlos en diferentes
fases del proceso de prueba.
Ambas medidas, efectividad y eficiencia, pueden ser útiles en la planificación de la
prueba; se pretende maximizar efectividad y eficiencia basándose en el historial de pruebas.
Por lo tanto, la documentación de las pruebas actuales puede incluir medidas que permitan
calcular la efectividad y la eficiencia.
86

POR QUÉ LOS ESFUERZOS DE SIX-SIGMA NO SE APLICAN AL SOFTWARE
Cuando se piensa en sistemas de alta calidad, se suelen utilizar analogías del hardware para
justificar la aplicación de técnicas exitosas del hardware al software. Pero Binder (1997)
explica por qué algunas de las técnicas del hardware son inapropiadas para el software. En
particular se considera la noción de construir software para alcanzar lo que se conoce como
las "seis-sigma" restricciones de calidad. Las piezas de fabricación, por lo general, tienen
rango de tolerancias, dentro de los cuales se considera que satisfacen sus metas de diseño.
Por ejemplo, si una pieza debe pesar 45 mg, de hecho se aceptan piezas que pesen entre
44,9998 mg y 50,0002 mg; si el peso de una pieza no está dentro del rango, se dice que es
defectuosa. Una restricción de calidad de tipo seis-sigma establece que en mil millones de
partes se deben esperar solamente 3,4 fuera del rango aceptable (es decir, no más de 3,4
partes por cada mil millones son defectuosas). A medida que se incrementa el número de
partes de un producto caen significativamente los chances de encontrar productos libres de
defectos, por lo que la posibilidad de un producto de 100 partes libres de defecto (donde las
partes se han diseñado conforme a las restricciones seis-sigma) es de 0,9997. Se puede
mejorar este índice de calidad reduciendo el número de partes, reduciendo el número de
restricciones críticas por parte y simplificando el proceso que integra las partes separadas.
Sin embargo, Binder señala que esta analogía del hardware es inadecuada para el software por
tres razones: el proceso, las características y la singularidad. Primero, porque las personas
son variables, el proceso del software contiene inherentemente un elevado grado de
variaciones incontrolables de una "parte" a la otra. Segundo, el software conforma o no lo
hace. No existen grados de conformidad como en la clásica consulta "no conforma,
conforma algo, conforma bastante, conforma totalmente". La conformidad es binaria y
no puede .1.0- ciarse a un único defecto, a veces son muchos los defectos que contribuyen
a una sola falla y usualmente no se sabe cuántos defectos contiene un sistema. Es más, la
causa de una falla puede depender de una aplicación diferente relacionada a través de una
interfaz (como cuando un sistema externo envía un mensaje incorrecto al sistema que se
prueba). Tercero, el software no es el resultado de un proceso de producción masiva. “Es
inconcebible que cualquiera intentara construir miles de componentes de software idénticos
en un proceso de desarrollo idéntico, muestrear unos pocos para obtener la conformidad y
después, dependiendo del resultado, intentar corregir el proceso si produce demasiados
sistema que no satisfacen los requerimientos. Se pueden producir millones de copias
mediante un proceso mecánico, pero esto es irrelevante con respecto a los defectos del
software. Utilizado como eslogan (lema) seis-sigma simplemente significa (en forma
subjetiva) un muy bajo nivel de defectos. El sentido estadístico preciso se pierde"
(Binder 1997).
87

BENEFICIOS E INCONVENIENTES DEL MANTENIMIENTO DE SISTEMAS ORIENTADOS A
OBJETOS
Wilde, Matthews y Huitt (1993) han investigado las diferencias entre el mantenimiento de
los sistemas orientados a objetos y los procedimentales. Destacan algunos beneficios en lo
referente a la orientación a objetos:
• Los cambios por mantenimiento a una sola clase de objeto en general no afectan al resto
del programa.
• El personal de mantenimiento puede reutilizar objetos fácilmente, escribiendo solamente
una pequeña cantidad de código nuevo.
Sin embargo, también existen varios inconvenientes:
• Las técnicas orientadas a objetos pueden hacer que los programas sean más difíciles de
comprender, debido a la profusión de partes del programa. Resulta difícil discernir la
intención original del diseñador a causa de la dificultad de localización: los planos del
programa se encuentran dispersos a través de numerosos segmentos de programa no
contiguos.
• Por la misma razón, la existencia de múltiples partes puede dificultar la comprensión del
comportamiento global del sistema.
• La herencia puede contribuir a que las dependencias sean difíciles de rastrear.
• El enlace dinámico hace que sea imposible determinar cuál de los varios métodos se va a
ejecutar, por lo que quienes realizan el mantenimiento deben considerar todas las
alternativas.
• Por ocultar los detalles de la estructura de datos, la función del programa puede estar
distribuida entre varias clases. Esto hace que resulte difícil detectar y descifrar la
interacción de las clases.
88

LINEAS DE CÓDIGO Y NÚMERO CICLOMÁTICO
Es muy fácil mostrar que el número de líneas de código constituye una medida válida del
tamaño de un programa. Sin embargo, no es una medida válida de la complejidad, ni forma
parte de un sistema exacto de predicción de la complejidad. Fenton y Pfleeger (1997)
explican que la falencia no está vinculada con la medida de líneas de código sino con la
definición imprecisa de complejidad. Aunque la complejidad se describe generalmente co-
mo un atributo que puede afectar la confiabilidad, la aptitud para el mantenimiento, el costo
y demás, la imprecisión que rodea su definición representa un problema en el campo de la
investigación de la complejidad.
Pero los problemas asociados con la complejidad no impiden que el número de
líneas de código sea útil para medir otros atributos, además del tamaño. Por ejemplo,
suponer que existe una asociación estocástica entre un gran número de líneas de código y un
gran número de defectos de la prueba unitaria. Esta relación puede ayudar para seleccionar
una estrategia de prueba y reducir el riesgo.
Por otra parte, hay numerosos estudios que exhiben una significativa correlación
entre líneas de código y número ciclomático. ¿Prueba esta correlación que el número
ciclomático se incrementa con el tamaño? Si el número ciclomático fuera una medida de
tamaño, el código más largo sería siempre código el más complejo. Es fácil construir un
contraejemplo a esta hipótesis. Si se examinan cuidadosamente los datos que muestran la
relación entre número ciclomático y líneas de código, lo que se observa es que el número de
decisiones en un componente usualmente se incrementa con la longitud del código.
89

MEDICIÓN DE LA FACILIDAD DE
REUTILIZACIÓN
¿Cómo examinar un componente candidato y decidir si conviene incorporarlo a un

repositorio de reutilización?
A muchos gerentes les gustaría contar con un conjunto de métricas simples, que,
cuando se aplican a un componente, distingan si es reutilizable o no. Sin embargo, el
hallazgo del conjunto correcto de mediciones no es tan fácil como parece. Las medidas
deben tener una meta, habitualmente relacionada con la calidad, la productividad o el
tiempo para comercializar. Y también deben tener en cuenta la perspectiva de la persona
que formula la consulta; los desarrolladores tienen una perspectiva diferente de la que
tienen los niveles ejecutivos. Pfleeger (1996) describe cómo una simple pregunta, qué
medir, conduce a la generación de más de 1.000 mediciones posibles, claramente una
cantidad inaceptable de mediciones a realizar.
Pero, aun cuando se posea una buena lista de mediciones, ¿cómo se sabe qué límites
poner a cada una? ¿Un componente pequeño es más reutilizable que uno grande? ¿Es
mejor reutilizar código complejo que código simple? Estas cuestiones son tema de
investigación y están siendo estudiadas de varias maneras diferentes. Algunas
organizaciones buscan en la historia pasada para determinar las características de los
componentes más reutilizados. Otras están seleccionando mediciones basadas en un
"criterio de ingeniería". Los enfoques más promisorios han sido usados en el Contel
Technology Center, donde un repositorio automatizado fue organizado usando la
clasificación facetada. El repositorio rastreó información sobre las consultas, tales como
cuáles fueron los descriptores usados con mayor frecuencia. También registraba cuando
un componente era seleccionado para utilizarlo, cuando se lo examinaba pero no era
seleccionado y cuando satisfacía el criterio de la consulta pero no era examinado.
Después el administrador del repositorio establecía un diálogo personal con los usuarios
para comprender por qué ciertos componentes no se estaban utilizando en tanto otros se
usaban muchísimo. Las medidas, combinadas con la interacción personal, le permitieron
al administrador incorporar nuevos sinónimo a la clasificación facetada, modificar
componentes para hacerlos más reutilizables, eliminar componente que no eran usados
por los desarrolladores (y, en consecuencia, reducir el tiempo de búsqueda) encontrar
nuevos componentes que eran deseables pero no estaban incorporados al repositorio.
90

ESTÁNDARES DE PROGRAMACIÓN EN
MICROSOFT
Cusumano y Selby (1995, 1997) han estudiado el desarrollo de software en

Microsoft. Puntualizan que la compañía intenta incorporar algunos aspectos de
práctica de la ingeniería software en sus ciclos de desarrollo de software,
preservando al mismo tiempo las características de creatividad e individualidad que
usualmente exhiben los hackers. Entonces, Microsoft debe encontrar vías "que
estructuren y coordinen lo que los miembros individuales de la compañía hacen,
dándoles al mismo tiempo suficiente flexibilidad para ser creativos y desarrollar por
etapas los detalles del producto". Debido a las presiones de mercado y necesidades
cambiantes, los grupos de desarrollo de Microsoft alternan sus actividades entre el
diseño, la construcción y prueba de componentes. Por ejemplo, los integrantes de un
equipo revisan los tipos de prestaciones y sus detalles así como aprenden más acerca
de lo que el producto debe hacer.
Sin embargo la flexibilidad no excluye los estándares. Casi todos los equipos de
desarrollo de Microsoft trabajan en un único lugar físico, utilizando lenguajes
comunes de desarrollo (generalmente C o C++), estilos comunes de codificación y
herramientas estándar de desarrollo. Estos estándares ayudan a los equipos a comu-
nicarse, a discutir los pro y los contra de diferentes alternativas de diseño y resolver
problemas.
Microsoft también exige que sus equipos tomen un reducido conjunto de mediciones,
incluyendo información específica cuando se producen fallas y cuando se detectan y
reparan defectos subyacentes. Estas mediciones orientan las decisiones acerca de
cuándo continuar el desarrollo y cuándo despachar un producto al mercado.
91

SELECCIÓN DE COMPONENTES REUTILIZABLES EN LUCENT
Lucent Technologies inició un programa corporativo para favorecer la reutilización de

componentes de software (McClure, 1997). Como consecuencia, el departamento de
desarrollo correspondiente -Workstation Software Development Department- formó una
junta para delinear la estrategia de selección de componentes candidatos a integrar un
repositorio de reutilizables. La junta estaba integrada por siete personas en representación de
todos los grupos del departamento. Esta junta creó un inventario de componentes y
conformó una matriz con las prestaciones de todos proyectos pasados y planeados. Después,
cada prestación se ponderó en términos de cuando fue implementada siendo todavía
necesaria, o si fue implementada no siendo ya necesaria, o bien no está implementada pero
continúa siendo necesaria. Aquellas prestaciones que resultaron necesarias y además
comunes a más de un proyecto quedaron marcadas para su reutilización. De hecho, algunos
de estos componentes fueron rediseñados para hacerlos todavía más reutilizables.
La junta se reúne todas las semanas durante dos horas para seleccionar componentes,
inspeccionar la documentación de diseño de los componentes que ya integran el repositorio y
para monitorear los niveles de reutilización en los proyectos del departamento.
92

CONSTRUCCIONES EN
MICROSOFT
La estrategia de integración de Microsoft ha sido indicada por las presiones del

mercado, y se basa en la necesidad de tener productos en funcionamiento tan
rápido como sea posible (Cusumano y Selby 1995, 1997).
Allí se utilizan muchos equipos pequeños que operan en paralelo (cada uno tiene
entre tres y ocho integrante) que implementan un enfoque conocido como 11 synch-
and-stabilize" (sincronizar y estabilizar). El proceso es iterativo, entre el diseño, la
construcción y la prueba de componentes, mientras se involucra al cliente en el
proceso de prueba. Todas las partes de un producto son integradas frecuentemente
para determinar cuáles trabajan correctamente y cuáles no lo hacen.
El enfoque de Microsoft permite que el equipo cambie la especificación de
características a medida que lo desarrolladores aprenden más acerca de lo que el
producto puede y debe hacer. A veces el conjunto de características cambia hasta un
30% o más. El producto y el proyecto están divididos en partes que están basadas en
las características, y los diferentes equipos son responsables de las diferentes
características.
Los hitos se definen a través del particionamiento de las características en muy
críticas, deseable y poco críticas. Los equipos sincronizan su trabajo construyendo el
producto y localizando y corrigiendo defectos sobre una base diaria, como muestra la
Figura 8.15. Por lo tanto, las características más importantes se desarrollan e integran
primero y cada hito incluye un buffer de tiempo para el manejo de complicaciones y
demoras inesperadas. Si el cronograma se tiene que acortar, se suprimen las
características menos importantes del producto.
93

LAS CONSECUENCIAS DE OMITIR LAS PRUEBAS DE REGRESION
El no realizar correctamente las pruebas de regresión puede tener

severas consecuencias. Por ejemplo, Seligman (1997) y Trager (1997)
informan que a 167.000 californianos les fueron facturados $667.000
por llamadas telefónicas no confirmadas, debido a un problema del
software adquirido por la Nothern Telecom. Un problema similar
experimentaron los clientes en la ciudad de Nueva York.
El problema provino de un defecto en una actualización del software

para la unidad de conmutación telefónica DMS-100. El defecto hizo
que la interfaz de facturación utilizara un código de área incorrecto en
centrales que utilizan más de un código de área. Como resultado, las
llamadas locales fueron facturadas como llamadas de larga distancia
con cargo. Cuando los clientes reclamaron, las compañías de teléfono
locales respondieron que el problema correspondía al prestador de
servicio de larga distancia; después al reclamar al prestador del servicio
de larga distancia ¡fueron derivados nuevamente a la compañía local! A
las compañías locales les llevó cerca de un mes encontrar y subsanar la
causa del problema. De haberse realizado las pruebas de regresión
completas sobre la actualización del software, incluyendo un chequeo
para ver si los códigos de área se informaban correctamente, el
problema de facturación de la Nothern Telecom nunca se habría
producido.
94

DELTAS Y ARCHIVOS SEPARADOS
El Sistema de Control de Código Fuente (sccs, por su sigla en inglés) distribuido con la
mayoría de las versiones de un IX de AT&T está pensado para controlar la línea de base
del software de un proyecto. También puede utilizarse para otros documentos
relacionados a proyectos, siempre que tengan formato de texto. Utilizando un enfoque
delta, sccs permite múltiples versiones y emisiones y un programador puede solicitar
cualquier versión o emisión del sistema a un tiempo dado. El sistema básico se guarda
junto con las transformaciones. Esto es, para un componente dado, sccs almacena en un
archivo el código básico para la versión 1.0 de dicho componente, el delta para
transformarlo en la versión 2.0 y el delta para pasar de la versión 2.0 a la 3.0. De manera
similar, sccs puede almacenar diferentes ediciones o una combinación de versión y
edición. Por lo tanto, cualquier edición o versión siempre está disponible para su uso o
modificación; sccs sólo aplica los deltas apropiados para derivarla desde la básica. Sin
embargo, hacer cambios en versiones o ediciones intermedias puede dar lugar a
problemas, dado que el delta para la próxima versión o edición está basado en el texto de
la versión previa. Por otra parte, la flexibilidad de sccs en el manejo de múltiples
versiones y ediciones significa que un vendedor puede utilizar sccs para soportar
simultáneamente numerosas versiones y ediciones de los productos.
Un programador solicita que sccs elabore una versión o edición utilizando el comando
"get", Cuando se incluye la llave l/-e", que indica que el componente debe ser editado, sccs
bloquea el acceso al componente a todos los demás usuarios, hasta que se comprueba la
devolución del componente modificado.
El Sistema de Lenguaje Ada (ALS) es un ambiente de programación diseñado con una
gestión de configuración como factor clave de diseño (Babich 1986). No aplica una
estrategia de gestión de configuración particular. De hecho incorpora comandos de tipo
UNIX que soportan las herramientas de configuración. A diferencia de sccs, ALS almacena
las revisiones por separado, como archivos distintos. Además congela todas las versiones
y ediciones excepto la actual. Es decir, las versiones y ediciones antiguas no pueden ser
modificadas a menos que se genere una réplica nueva que esté disponible para los
usuarios.
ALS permite agrupar colecciones de versiones y ediciones relacionadas en conjuntos de
variantes. Los conjuntos de variantes pueden estar basados en una versión de producción
más unas cuantas versiones de desarrollo, o en una versión con varias ediciones
subsiguientes. También le adjunta a cada archivo información de atributos tales como
fecha de creación, nombres de quienes lo han utilizado, fecha de la última prueba o el
propósito del archivo. El sistema también rastrea las asociaciones de manera que todos los
archivos en un sistema o todos los archivos en un conjunto de variantes puedan ser
rotulados.
El esquema de control para ALS involucra bloqueos para los nombres de las personas
autorizadas para leer, sobre escribir, agregar o ejecutar datos en el archivo. El sistema
95
también asigna permisos para que ciertas herramientas accedan o interactúen con un
archivo.

EL CONTROL DE CONSTRUCCIÓN DE MICROSOFT
Cusumano y Selby (1997) informan que los desarrolladores de Microsoft deben ingresar su
código en una base de datos de producto en un horario particular por la tarde. Después, el
equipo de proyecto recompila el código fuente crea una nueva “construcción” del producto
en evolución. Cualquier código que sea lo bastante defectuoso como para impedir que la
“construcción” se compile y ejecute debe corregirse de inmediato.

El proceso mismo de la construcción nene varios pasos. En primer lugar, el desarrollador
obtiene una copia privada de un archivo de código fuente, de un puesto central donde se
mantienen versiones maestras de los productos. Después modifica la copia privada para
Implementar o modificar características. Una vez realizados los cambios, se prueba esa
copia privada con las modificaciones introducidas. Cuando se completan exitosamente las
pruebas, el nuevo código se incorpora a la versión maestra. Por último, se hacen las pruebas
de regresión que garantizan que los cambios realizados por el desarrollador no hayan
afectado inadvertidamente otras funcionalidades.
Los desarrolladores individuales pueden combinar sus cambios según lo necesiten (a veces a
diario, o semanalmente, dependiendo de las necesidades), pero una "construcción maestra"
genera diariamente una versión completa del producto, utilizando la versión maestra de cada
archivo de código fuente para el día. Estas construcciones diarias se hacen para cada
producto y cada mercado.
96

CANTIDAD DE DEFECTO DE LOS REQUERIMIENTOS
¿Cuántos problemas de desarrollo se originan durante el proceso de captación de los

requerimientos? Hay opiniones variadas. Boehm y Papaccio (1988), en un estudio que
analizaba el software en IBM y TRW, dicen que la mayoría de los errores se producen
durante el diseño, y que usualmente existen tres defectos de diseño por cada dos
defectos de codificación. Puntualizan que el alto número de defectos atribuido a la
etapa de diseño podría derivar de errores en los requerimientos. En su libro sobre
economía en la ingeniería del software Boehm (1981) cita estudios de Iones. Thayer y
otros que atribuyen:
• 35% de los defectos a las actividades de diseño para proyectos de 30-35 mil
instrucciones fuente entregadas
• 10% de los defectos a las actividades de requerimientos y un 55% de los defectos
al diseño en proyectos de 40-80 mil instrucciones fuente entregadas
• 8-10% de los defectos a las actividades de requerimientos y 40-55% de los
defectos al diseño en proyectos de 65-85 mil instrucciones fuente entregadas
Basili y Perricone (1984), en una investigación empírica sobre errores del software,
informan que el 48% de los defectos observados en proyectos de software de mediana
escala eran "atribuidos a especificaciones funcionales o requerimientos incorrectos o mal
interpretados".
Beizer (1990) atribuye un 8,12% de los defectos en estas muestras a problemas en los
requerimientos funcionales. El investigador incluye en su cuenta los problemas que resultan
de la forma en que están especificados o implementados los requerimientos así como los
requerimientos incorrectos, requerimientos ilógicos o no razonables, ambiguos, completos o
sobre especificados, requerimientos no comprobables o imposibles de probar,
requerimientos mal presentados y requerimientos cambiados. Sin embargo, la taxonomía de
Beizer incluye actividades que no son de diseño. Dice "los requerimientos, especialmente
expresado en una especificación (o a menudo no expresados porque no existe la
especificación), son la mayor fuente de costosos bugs. El rango va desde un pequeño
porcentaje hasta más del 50% dependiendo de la aplicación y el ambiente. Lo que más hiere
es que estos defectos son los que más temprano invaden el sistema y también son lo último
en salir. No es raro que un requerimiento defectuoso pase todas las pruebas de desarrollo, la
prueba beta, y el uso inicial en campo, sólo para ser descubierto después de que se han
instalado en centenares de sitios.
Abundan otras estadísticas. Por ejemplo. Perry y Stieg (1993) concluyen que el 79,6% de los
defectos de las interfaces y el 20,4% de los defectos de implementación se deben a
requerimientos omitidos o incompletos. De manera similar, en Computer Weekly Report
(1994) se discutía un estudio que mostraba que el 44,1% de todos los defectos de los
sistemas se producen en la etapa de especificación. ¿Cuál es el número correcto para cada
ambiente de desarrollo? Sólo puede decirlo un registro cuidadosamente mantenido. Esto
registros pueden utilizarse como base para medir la mejora a medida que se incorporan
nuevas práctica y utilizan nuevas herramientas.
97
CUADRO DE TACADO 9.7

COMPROBACIÓN AUTOMATIZADA DE UN SISTEMA DE COTIZACIÓN DE
SEGUROS PARA AUTOMOTORES
Mills (1997) describe la forma en que su compañía utiliza la automatización para probar un si
tema de cotización de seguros de automóviles. Cada sistema contiene los perfiles de riesgo
de aproximadamente 90 aseguradoras y productos, lo que le permite al agente de seguros
suministrar información acerca de un automóvil y a su conductor recibir una cotización para
los seguros premium. La entrada Incluye 50 campos, tales como edad, experiencia en
conducción, área de circulación, tipo de uso, tamaño del motor y numero de personas que
utilizan el automóvil. Esta información ayuda a ubicar al candidato en una de 20 áreas, uno
de más de 20 grupos de vehículos, cinco clases de uso, tres tipos de cobertura de seguro y 15
grupos de edades. El sistema de cotización rastrea 14 productos en 10 sistemas de
aseguramiento, donde cada sistema se actualiza por lo menos mensualmente.
Por lo tanto, el número de casos de prueba que se necesita para probar a fondo el sistema de
cotización es muy grande, y una gran parte del proceso de prueba está en decidir cuántos
casos de prueba son suficientes. Bate (1997) presenta los cálculos para mostrar que la
comprobación de 5.000 condiciones para un sistema en el National Westminster Bank
requiere 21.000 guiones; dado que cada guión toma 3 minutos para el chequeo manual, la
prueba demandaría unos 7,5 meses de trabajo de una persona en una plataforma. Esta
situación es claramente inaceptable para el sistema de seguros descrito por Milis, que
involucra numerosas condiciones y guiones de prueba. Los desarrolladores estimaron que
podrían probar entre 100 Y 200 casos en modo loteado (batch) y los aseguradores les dieron
directivas para ejecutar 100 pruebas aleatorias. Pero, utilizando comprobación automatizada,
un tercer participante ejecuta 30.000 cotizaciones de prueba planeadas por cliente obre cada
sistema de cotización todos los meses. ¡Y el proceso de prueba tarda menos de una semana
para completar el Milis informa que la diferencia mayor entre la prueba automatizada y la
manual, aparte de la velocidad, es que la mayoría de los defectos se descubren temprano en el
proceso de comprobación dejando mas tiempo disponible para corregirlos antes que se emita
la próxima versión del sistema.
98
Ejercicios Prácticos
Calidad del Software
Ejercicio 1 Encontrar ejemplos concretos de dependencias de aplicaciones para con

el sistema operativo o con el hardware. ¿Por qué razón estas dependencias pueden
afectar la calidad del software?
Ejercicio 2 Uno de los sistemas operativos más utilizados en el mundo es Microsoft

Windows_. Evaluar el cumplimiento de los distintos factores externos de calidad de
software para este sistema operativo, indicando qué versión del mismo se está
evaluando. Analizar si las sucesivas versiones introducidas mejoraron el
cumplimiento de alguno de los factores identificados.
Ejercicio
Ejercicio 3 En el contexto del tema gestión de riesgos, suponga que usted es el dueño
de una pequeña empresa de desarrollo de software, por ejemplo formada por cinco
programadores.
Considere el riesgo asociado a la pérdida de todos los archivos de datos y código
fuente y conteste las siguientes preguntas:
a) ¿Cuáles son los riesgos asociados?

b) ¿Cuál es la probabilidad de pérdida asociada a esos riesgos?
c) ¿Cuál sería el costo monetario de recuperarse de los riesgos si éstos ocurrieran?
d) ¿Cuál sería el costo si ocurriera el peor escenario? ¿Cómo se puede hacer para
disminuir o eliminar el costo si ocurriera el peor escenario?
e) ¿Cuáles son las alternativas para atenuar los riesgos? ¿Cómo se controla que las
alternativas son efectivas y se están llevando a cabo correctamente?
f) ¿Las alternativas producen otros riesgos?
Ejercicio 4 Un error común en ciencias de la computación es pensar que la

codificación consume la mayor parte del tiempo de desarrollo del software.
Apelando a la experiencia individual, establecer qué porcentaje de tiempo requieren
aproximadamente las fases de especificación de requerimientos, diseño, codificación,
testeo y mantenimiento en el desarrollo de un programa.
Ejercicio 5 Definir el concepto de riesgo en el desarrollo de software. Enumerar

algunos de los riesgos que deberían tenerse en cuenta a lo largo de la producción de
software.
99
Ejercicio 6 Explicar brevemente cómo funciona el modelo en espiral del ciclo de

vida del software. Los modelos en espiral o en cascada (con feedback), ¿se pueden
usar indistintamente?. Justificar la respuesta suministrada.
Ejercicio 7 Explicar por qué está mal pensar que la Ingeniería de Software consume
mucho tiempo e interfiere con la productividad del programador. Repasar la
respuesta dada en el ejercicio 4. Con todo esto en mente, ¿cuál sería la mejor
estrategia para reducir los tiempos de codificación?.
Ejercicio 8 ¿Es suficiente con que un lenguaje de programación soporte el concepto

de módulo, o en realidad hacen falta herramientas meta-lingüísticas (esto es,
herramientas fuera del lenguaje) adicionales para asegurar la calidad del software?.
Ejercicio 9 En el contexto del tema Factores de calidad externos del software, considere
la métrica para medir la portabilidad de un sistema que ya está operando en un
ambiente e1 y se desea migrar a un ambiente e2:
e2
Portabilidad = 1 – ET / ER
Donde ET es una medida de la cantidad de recursos necesarios para migrar el

sistema del ambiente e1 al ambiente destino e2, y ER es una medida de la cantidad
de recursos necesarios para crear el sistema para el ambiente destino e2. Suponga
que tenemos dos sistemas S1 y S2 que se desean migrar del sistema operativo
Windows XP al sistema operativo Windows Mobile Edition.
Si adaptar a S1 cuesta RD$250,000.00 en sueldos de programadores mientras que
desarrollarlo desde cero cuesta RD$500,000.00 En cambio, adaptar a S2 cuesta
RD$180,000.00 pero desarrollarlo desde cero cuesta RD$450,000.00. Conteste,
justificando adecuadamente, cuál de los dos sistemas es más portable. Desde su
punto de vista, explique cuál sería el problema de utilizar esta métrica en la práctica.
Ejercicio 10 Se denominó “problema Y2K” a la incapacidad de un sistema de

software de representar fechas usando cuatro dígitos para codificar los años. A fines
del año 1999 mucho dinero fue invertido en la actualización de los sistemas que no
estaban preparados para el cambio de siglo. ¿Qué factor o factores de calidad de
software no cumplían los sistemas alcanzados por el problema Y2K?
Ejercicio 11 El modelo en cascada completamente lineal del ciclo de vida del

software es usualmente impracticable. En este contexto, indicar cuál o cuáles son los
inconvenientes de este modelo.
100

Material de Clase Calidad de Software

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Material de Clase Calidad de Software

Загружено:

Авторское право:

Доступные форматы

Manual Aseguramiento Calidad de Software

UNIDAD I (ELEMENTOSY PRINCIPIOS DE LA CALIDAD)

1.1. LA CALIDAD REAL

1.2. DEFINICION DE CALIDAD

1. “La calidad es el conjunto de propiedades y características de un

• Control de calidad: “Conjunto de técnicas y actividades de carácter operativo,

1.3. CALIDAD (OCHO PRINCIPIOS GENERALES)

Organización orientada al cliente.

1.4. LAS TRES ESCUELAS DE LA CALIDAD TOTAL

Crosby da una orientación práctica y sencilla al programa de implantación de la

Deming se centra más en aspectos relativos a las conductas y actitudes.

Juran focaliza en la alta dirección la responsabilidad de la aplicación y control de

WILLIAM EDWARD DEMING

1.5. LA CALIDAD Y LOS DEFECTOS

Originalmente, la calidad de un programa o sistema se evaluaba de acuerdo al número de

1. La especificación se orienta hacia las características del producto que el consumidor

2. No se sabe como especificar ciertas características de calidad (por ejemplo,

La responsabilidad de los administradores de la calidad en una organización es asegurar que

UNIDAD II (ADMINISTRACION, ESTANDARES Y SEGURAMIENTO DE LA

2.1 LA ADMINISTRACIÓN DE LA CALIDAD DEL SOFTWARE SE ENCUENTRA

1. Aseguramiento de la calidad. El establecimiento de un marco de trabajo de

La administración de la calidad provee una comprobación independiente de los procesos de

La administración de la calidad esta separada de la administración de proyectos de manera

Una estándar internacional que se puede utilizar en el desarrollo de un sistema de

2.2 ASEGURAMIENTO Y ESTANDARES DE CALIDAD

1. Estándares del producto. Estos son estándares que se aplican al producto de

1. Proveen un conjunto compacto d las mejores practicas, o al menos de las mas

de errores anteriores. Los estándares capturan el conocimiento de valor para la

Estándares del producto y del proceso (Figura 24,4)

ESTÁNDARES DEL PRODUCTO ESTÁNDARES DEL PROCESO

El desarrollo de los estándares de proyectos de ingeniería de software es un proceso difícil y

Se han desarrollado estándares nacionales e internacionales para cubrir la terminología de la

Los equipos de aseguramiento de la calidad que desarrollan los estándares se apoyan en

1. Involucrar a los ingenieros de software en el desarrollo de los estándares del

Los estándares del proceso provocan dificultades si se impone un proceso no práctico en el

El administrador del proyecto y el de la calidad pueden evitarse los problemas de los

2.3 ESTANDARES DE DOCUMENTACION

Los estándares de documentación en un proyecto de software son documentos muy

Muchos estándares y procedimientos corporativos u organizacionales se concentran en las

1. Que denominación tiene el componente

Usualmente, los estándares organizacionales especifican el orden y contenido de estos

Existen tres tipos de estándares de documentación:

1. Estándares del proceso de documentación. Estos definen el proceso a seguir para la

Crear un borrador, comprobarlo, revisarlo y rehacerlo es un proceso interactivo. Este

Algunos ejemplos de estándares de documentos a desarrollar son:

1. Estándares de identificación de documentos. Puesto que los proyectos de sistemas

4. Estándar para actualizar los documentos. Conforme el documento evoluciona y

los cambios en el documento. Se pueden utilizar diversos colores de la portada para

2.4 CALIDAD DEL PROCESO Y DEL PRODUCTO

Una suposición subyacente de la administración de la calidad es que la calidad del proceso de

1. Definir estándares de proceso como las versiones a realizar, cuando llevarlas a

Un peligro del aseguramiento de la calidad basada en procesos es que el proceso prescrito

UNIDAD III (CONTROL Y PLANEACION DE LA CALIDAD)

3.1 PLANEACION DE LA CALIDAD

El plan de calidad selecciona aquellos estándares organizacionales apropiados para un

1. Introducción del producto. Contiene la descripción del producto, el mercado al que

Atributos de calidad de software

Seguridad Compresión Portabilidad

3.2 CONTROL DE CALIDAD

El proceso de control de calidad tiene su propio conjunto de procedimientos e informes a

Existen dos enfoques complementarios para el control de la calidad:

1. Revisión de la calidad en las que el software, su documentación y los procesos

2. Valoración automática del software en la que el software y los documentos

3.3 REVISION DE LA CALIDAD