Relais v1 n5 P 167 206

Aseguramiento de la Calidad en la Construccin de
Sistemas Basados en el Conocimiento: Un Enfoque

Prctico
Eduardo Diez
Laboratorio de Investigacin y Desarrollo en Aseguramiento de Calidad de Software
Grupo Investigacin en Sistemas de Informacin
Departamento Desarrollo Productivo y Tecnolgico. Universidad Nacional de Lans.
Remedios de Escalada, Buenos Aires, Argentina.
ediez@unla.edu.ar
ResumenLa funcin de aseguramiento de la calidad del
software (SQA) se debe basar en un planificado y sistemtico
diseo de acciones y mtodos, requeridos para garantizar la
calidad del mismo. En el presente trabajo, se presenta un diseo
de acciones y mtodos que constituyen un enfoque prctico para
el desempeo de la funcin de SQA en una organizacin,
adaptado especialmente a la metodologa IDEAL para el
desarrollo de sistemas basados en el conocimiento. Este enfoque
no pretende ser exclusivo y en ningn caso limita o inhibe la
aplicacin de otras acciones, mtodos o modelos, sino que podr
ser su complemento, adaptndolo convenientemente. El enfoque
o modelo de aseguramiento de la calidad del software que tiene
las siguientes caractersticas: el modelo de aseguramiento de
calidad de software sugerido es una interfaz a una metodologa,
ideal en este caso, de desarrollo de software, el modelo que aqu
se presenta no es una metodologa en s misma, sino que debe
acoplarse a una metodologa de desarrollo para poder
implementarse, esta interfaz est compuesta por mdulos
independientes, donde cada uno de ellos se asocia a ciertos
procesos de la metodologa ideal.
Palabras ClavesAseguramiento de la calidad del software,
sistemas basados en el conocimiento, metodologa ideal.
I. INTRODUCCION
La calidad es una cualidad esencial de cualquier producto,
generado por una organizacin, que va a ser usado por otros.
Antes del siglo veinte, las actividades relacionadas con el
aseguramiento de la calidad era responsabilidad nica de la
persona que construa el producto. La primera funcin de
control y de aseguramiento de la calidad formal fue introducida
por los laboratorios Bell en 1916 y se extendi rpidamente por
todo el mundo de las manufacturas. Hoy en da, cada empresa
tiene un mecanismo que asegura la calidad de sus productos, de
hecho, durante la pasada dcada se ha usado ampliamente
como tctica de mercado, la declaracin explcita de mensajes
que ponan de manifiesto la calidad ofrecida por las empresas.
La evolucin del aseguramiento de la calidad en el
desarrollo de software ha sido paralela a la evolucin de la
calidad en la fabricacin de hardware. Durante los primeros
aos de la informtica (los aos 50 y 60), la calidad era
responsabilidad nicamente del programador. Durante los aos
70 se introdujeron estndares de aseguramiento de la calidad
para el software en los contratos militares de desarrollo de
software y se extendieron rpidamente en los desarrollos de
software del mundo comercial.
La funcin de aseguramiento de la calidad del software

(SQA) se debe basar en un planificado y sistemtico diseo de
acciones y mtodos, requeridos para garantizar la calidad del
mismo. El alcance de la responsabilidad del aseguramiento de
la calidad, en el desarrollo de software, abarca a muchos
constituyentes de una organizacin, tales como ingenieros de
software, lderes de proyecto, clientes, comerciales y personas
que trabajan dentro del equipo de SQA (una conformacin del
mismo se presentar en captulos sucesivos).
El equipo de SQA debe analizar el software desde diversos
puntos de vista, respondiendo a algunas de estas preguntas:
Satisface el software, de forma adecuada los principales
factores de calidad?
Se ha realizado el desarrollo del software de acuerdo con
estndares preestablecidos?
Se han aplicado las tcnicas y mtodos apropiados para el
desarrollo del software?
Para responder a stas y otras cuestiones, en el presente
trabajo, se presenta un diseo de acciones y mtodos que
constituyen un enfoque prctico para el desempeo de la
funcin de SQA en una organizacin, adaptado especialmente
a la metodologa IDEAL para el desarrollo de sistemas basados
en el conocimiento. Este enfoque no pretende ser exclusivo y
en ningn caso limita o inhibe la aplicacin de otras acciones,
mtodos o modelos, sino que podr ser su complemento,
adaptndolo convenientemente.
En la seccin II se establecen los Conceptos Bsicos,
describiendo brevemente los conceptos de calidad, control y
aseguramiento de la misma y presentando el alcance de la
funcin de SQA en una organizacin. En la seccin III se
esboza el Modelo General, es decir, el diseo de acciones y
mtodos que constituyen un enfoque prctico para el
desempeo de la funcin de SQA en una organizacin.
Tambin de presenta el modelo de mejora continua del mismo.
En la seccin IV se describen los Mdulos del Modelo, se
presentan para cada uno de ellos las acciones a desempear, su
objetivo, sus entradas, salidas, lista de verificacin, mtricas y
participantes involucrados. En la seccin V se describe las
principales Tcnicas y Herramientas, a utilizar en los mdulos
del modelo descrito. En la seccin VI se describe el Nivel de
Servicio Esperado, a travs de un acuerdo de nivel de servicio
recomendado. En la seccin VII se detalla el Equipo de SQA
sugerido, indicando su estructura y responsabilidades. En la
seccin VIII se establecen las Conclusiones del presente
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico.
Revista Latinoamericana de Ingeniera de Software, 1(5): 167-206, ISSN 2314-2642
167
trabajo, sealando los beneficios y problemas esperados en la

aplicacin de la funcin de SQA en una organizacin. Tambin
se establecen las bases para un anlisis costo-beneficio. Por
ltimo se detalla la Bibliografa utilizada para la confeccin del
presente trabajo, ya sea referenciada o consultada.
II. CONCEPTOS BSICOS
En la presente seccin se establecen los Conceptos Bsicos,
describiendo brevemente los conceptos de calidad, control y
aseguramiento de la misma y presentando el alcance de la
funcin de SQA en una organizacin.
A. Paradigma de la calidad
El paradigma de la calidad es aplicable a todas las
actividades que se llevan a cabo en una organizacin. Se puede
definir en trminos generales a la calidad como:
La calidad es la suma de todos aquellos aspectos o
caractersticas de un producto o servicio, que influyen en su
capacidad para satisfacer las necesidades de los usuarios.
Por otro lado, con respecto a la satisfaccin del usuario, se
puede decir que:
La satisfaccin del usuario est determinada por la
diferencia entre la calidad percibida y la calidad esperada,
cuando ste hace uso de un producto o servicio.
Los principales elementos del paradigma de la calidad son
los siguientes:
La naturaleza de la calidad: Orientacin a los aspectos o
caractersticas de un producto o servicio que influyan en su
capacidad para satisfacer necesidades dadas, ms que a la
adecuacin a estndares o a especificaciones preestablecidas.
La perspectiva del proceso: Focalizacin en el proceso ms
que en el producto.
Orientado a datos: Basado en la recoleccin, anlisis y
comparacin de datos.
Focalizacin en el cliente o usuario: La obtencin de la
satisfaccin del cliente o usuario es el objetivo final de todo
proceso.
Eliminacin de defectos: Priorizacin de tcnicas de
prevencin de defectos sobre tcnicas de deteccin y
correccin.
Gestin para la calidad: La adopcin del paradigma requiere
del compromiso de la alta direccin.
En primer trmino, se debe diferenciar entre la calidad del
producto y la calidad del proceso que lo genera.
Las primeras aproximaciones a la calidad estaban basadas
solamente en el control de la calidad del producto terminado,
es decir en actividades que slo desataban acciones correctivas
para eliminar los defectos del producto. A estas actividades se
las suele catalogar como correctivas, tardas y relacionadas con
el producto.
Con el tiempo y tal cual se establece en uno de los
principios del paradigma de la calidad, las aproximaciones de
calidad se fueron trasladando al aseguramiento de la misma
sobre el proceso que genera el producto, es decir en actividades
preventivas, antes que el producto est terminado, y que
desatan acciones para evitar que el producto terminado tenga
defectos. A estas actividades se las suele catalogar como
preventivas, tempranas y relacionadas con el proceso.
Ahora bien, la realidad muestra que toda aproximacin
eficaz a la calidad, contiene una combinacin de actividades de
168
aseguramiento de la calidad y de actividades de control de la

misma y que estas se complementan fcilmente.
B. Calidad del Software
Particularmente, en el caso del software, existen muchas
definiciones distintas en la bibliografa, sin embargo, en lo que
a este trabajo respecta, tomaremos la definicin de R. Pressman
[1]:
La calidad del software se define como la concordancia con
los requisitos funcionales y de rendimiento explcitamente
establecidos, con los estndares y procesos de desarrollo
explcitamente documentados y con las caractersticas
implcitas que se espera de todo software desarrollado
profesionalmente.
No hay duda de que la anterior definicin puede ser
modificada o ampliada. De hecho, no tendra fin una discusin
sobre una definicin definitiva de la calidad del software. Para
los propsitos de este enfoque, la anterior definicin sirve para
hacer hincapi en tres puntos importantes:
1) Los requisitos del software son la base de las medidas de la
calidad. La falta de concordancia con los requisitos es una
falta de calidad.
2) Los estndares especificados definen un conjunto de
criterios de desarrollo que guan la forma en que se aplica
la ingeniera del software o del conocimiento. En caso de
no seguirse esos criterios, casi siempre habr falta de
calidad.
3) Existe un conjunto de requisitos implcitos que a menudo
no se mencionan (por ejemplo la necesidad de una interfaz
intuitiva). Si el software se ajusta a sus requisitos explcitos
pero falla en alcanzar los requisitos implcitos, la calidad
del software se debilita.
Queda claro a partir de la definicin de calidad del
software, que sta es siempre relativa a los requisitos o
necesidades que se desea satisfacer. Por eso la evaluacin de la
calidad del software siempre va a implicar la comparacin
entre los requisitos y el producto generado.
B.1. Puntos de vista de la calidad del software
En la ingeniera del software o del conocimiento, la visin
de la calidad no es nica, dependiendo del punto de vista desde
el cual se la analice, ver figura 1.
Punto de vista del
usuario
Punto de vista del

ingeniero
Punto de vista del

gerente de proyecto
Fig. 1. Puntos de vista de la calidad del software
Dependiendo del punto de vista, se priorizarn distintos

factores del software:
Punto de vista del usuario: El punto de vista del usuario, con
respecto a la calidad, estar basado en los factores externos
del producto, tales como funcionalidad y facilidad de
operacin.
Eduardo Diez. 2013. Aseguramiento de la Calidad en la Construccin de Sistemas Basados en el Conocimiento: Un Enfoque Prctico
Punto de vista del ingeniero de software: El punto de vista

del ingeniero del software, con respecto a la calidad, estar
basado en los factores internos del producto, tales como
modularidad y reusabilidad.
Punto de vista del gerente del proyecto: El punto de vista del
gerente del proyecto, con respecto a la calidad, estar basado
en los factores relacionados con la gestin del proyecto, tales
como costos y cronogramas acorde a lo planificado.
B.2. Factores que determinan la calidad del software
Existen muchos factores que afectan a la calidad del
software y se pueden clasificar de distintas formas (uno de
ellos es el punto de vista del apartado anterior). En este trabajo
se presentarn slo a modo descriptivo, algunos factores de
calidad que se han propuesto.
McCall y sus colegas [2] han propuesto los siguientes:
Correccin. El grado en que un programa satisface sus
especificaciones y consigue los objetivos de la misin
encomendada por el cliente. Responde a la pregunta: Hace
lo que quiero?
Fiabilidad. El grado en que se puede esperar que un programa
lleve a cabo sus funciones esperadas con la precisin
requerida (Hay que decir que se han propuesto otras
definiciones de fiabilidad ms completas). Responde a la
pregunta: Lo hace en forma fiable todo el tiempo?
Eficiencia. La cantidad de recursos de computadora y de
cdigo requeridos por un programa para llevar a cabo sus
funciones. Responde a la pregunta: Se ejecutar en mi
hardware lo mejor que se pueda?
Integridad. El grado en que puede controlarse el acceso al
software o a los datos, por personal no autorizado. Responde
a la pregunta: Es seguro?
Facilidad de uso. El esfuerzo requerido para aprender un
programa, trabajar con l, preparar su entrada e interpretar su
salida. Responde a la pregunta: Est diseado para ser
usado?
Facilidad de mantenimiento. El esfuerzo requerido para
localizar y arreglar un error en un programa (Se trata de una
definicin muy limitada). Responde a la pregunta: Permite
ser corregirlo con relativa facilidad?
Flexibilidad. El esfuerzo requerido para modificar un
programa operativo. Responde a la pregunta: Permite ser
cambiado con relativa facilidad?
Facilidad de prueba. El esfuerzo requerido para probar un
programa de forma que se asegure que realiza su funcin
requerida. Responde a la pregunta: Permite ser probado con
relativa facilidad?
Portabilidad. El esfuerzo requerido para transferir el
programa desde un hardware y/o un entorno de sistemas de
software a otro. Responde a la pregunta: Podr usarlo en
otra computadora?
Reusabilidad. El grado en que un programa (o partes de un
programa) se puede reusar en otras aplicaciones. Esto va
relacionado con el empaquetamiento y el alcance de las
funciones que realiza el programa. Responde a la pregunta:
Podr reusar alguna parte del software?
Facilidad de nter-operacin. El esfuerzo requerido para
acoplar un sistema a otro. Responde a la pregunta: Podr
hacerlo interactuar con otros sistemas?
Es difcil, y en algunos casos imposible, desarrollar

medidas directas de los anteriores factores de calidad. Por
tanto, cada factor se descompone en atributos o criterios, ms
fcilmente medibles. Cabe aclarar que cada uno de estos
atributos puede corresponder a ms de un factor de calidad.
Facilidad de auditora. La facilidad con que se puede
comprobar la conformidad con los estndares.
Exactitud. La precisin de los clculos y del control.
Normalizacin de las comunicaciones. El grado en que se
usan el ancho de banda, los protocolos y las interfaces
estndar.
Completitud. El grado en que se ha conseguido la total
implementacin de las funciones requeridas.
Concisin. Lo compacto que es el programa en trminos de
lneas de cdigo.
Consistencia. El uso de un diseo uniforme y de tcnicas de
documentacin a lo largo del proyecto de desarrollo del
software.
Estandarizacin en los datos. El uso de estructuras de datos y
de tipos estndar a lo largo de todo el programa.
Tolerancia de errores. El dao que se produce cuando el
programa encuentra un error.
Eficiencia en la ejecucin. El rendimiento en tiempo de
ejecucin de un programa.
Facilidad de expansin. El grado en que se puede ampliar el
diseo arquitectnico, de datos o procedimental.
Generalidad. La amplitud de aplicacin potencial de los
componentes del programa.
Independencia del hardware. El grado en que el software es
independiente del hardware sobre el que opera.
Instrumentacin. El grado en que el programa muestra su
propio funcionamiento e identifica errores que aparecen.
Modularidad. La independencia funcional de los
componentes del programa.
Facilidad de operacin. La facilidad de operacin de un
programa.
Seguridad. La disponibilidad de mecanismos que controlen o
protejan los programas o los datos.
Autodocumentacin. El grado en que el cdigo fuente
proporciona documentacin significativa.
Simplicidad. El grado en que un programa puede ser
entendido sin dificultad.
Independencia del sistema de software. El grado en que el
programa es independiente de caractersticas no estndar del
lenguaje de programacin, de las caractersticas del sistema
operativo y de otras restricciones del entorno.
Facilidad de traza. La posibilidad de seguir la pista a la
representacin del diseo o de los componentes reales del
programa hacia atrs, hacia los requisitos.
Formacin. El grado en que el software ayuda para permitir
que nuevos usuarios apliquen el sistema.
Otra lista de factores de calidad es la desarrollada por
Grady y sus colegas [3]. Los factores y sus atributos
correspondientes son los siguientes:
La funcionalidad se obtiene mediante la evaluacin del
conjunto de caractersticas y de posibilidades del programa,
la generalidad de las funciones que se entregan y la seguridad
de todo el sistema.
169
La facilidad de uso se calcula considerando los factores

humanos, la esttica global, la consistencia y la
documentacin.
La fiabilidad se calcula midiendo la frecuencia de fallos y su
importancia, la eficacia de los resultados de salida, el tiempo
medio entre fallos (MTBF), la posibilidad de recuperarse a
los fallos y la previsibilidad del programa.
El rendimiento se mide mediante la evaluacin de la
velocidad de proceso, el tiempo de respuesta, el consumo de
recursos, el rendimiento total de procesamiento y la
eficiencia.
La capacidad de soporte combina la posibilidad de ampliar el
programa (extensibilidad), la adaptabilidad y la utilidad
(estos tres atributos representan un trmino ms comn
facilidad de mantenimiento), adems de la facilidad de
prueba, la compatibilidad, la posibilidad de configuracin
(posibilidad de organizar y controlar elementos de la
configuracin & software)], la facilidad con la que se puede
instalar un sistema y la facilidad con la que se pueden
localizar los problemas.
Tanto el modelo de McCall como el de Grady, presentan
adems frmulas, matrices, pesos ponderados que permiten
cuantificar cada uno de los factores presentados. Ms all de
eso, los siguientes puntos deben quedar claros.
1) Los modelos aqu presentados son slo una muestra de los
disponibles, hay varios ms y se actualizan frecuentemente.
2) Al planificar la calidad de un producto de software se debe
seleccionar cuales de los factores de calidad van a ser
considerados requisitos, a su vez. Para realizar esta
seleccin, se debe tener en cuenta lo siguiente:
Las caractersticas particulares de la aplicacin a
desarrollar o de su entorno. As por ejemplo si la
aplicacin se desarrolla para un entorno en el que el
hardware evoluciona rpidamente, el factor portabilidad
es importante; si se espera que las especificaciones del
sistema cambien frecuentemente, la flexibilidad ser
esencial.
El costo de los factores de calidad frente al beneficio que
proporcionan. Es decir realizar un anlisis costobeneficio.
Las interrelaciones entre factores: Algunos factores
pueden ser conflictivos entre s. La eficiencia, por
ejemplo, est en conflicto con otros factores de calidad.
3) Es necesario medir cada uno de los factores y atributos
seleccionados. Algunos pueden ser medidos directamente y
otros slo pueden ser medidos indirectamente. En
cualquiera de los dos casos la cuantificacin es obligatoria.
Respondiendo a otro de los principio del paradigma de la
calidad (orientacin a datos), las comparaciones se deben
basar sobre datos y mediciones concretas y objetivas, no
sobre opiniones o subjetividades.
C. Alcance de la funcin de SQA
La calidad del software no es algo en lo que se empieza a
pensar una vez que se ha generado el cdigo. Segn R
Pressman [1] el aseguramiento de la calidad del software
(SQA) es una actividad de proteccin que se aplica a lo largo
de todo el proceso de ingeniera software y engloba:
1) Un enfoque de gestin de la calidad.
2) Tecnologa de ingeniera del software o del conocimiento
efectiva (mtodos y herramientas).
170
3) Revisiones tcnicas formales que se aplican durante cada

paso de la ingeniera del software o del conocimiento.
4) Una estrategia de prueba en mltiples niveles.
5) El control de la documentacin del software y de los
cambios realizados.
6) Un procedimiento que asegure un ajuste a los estndares de
desarrollo del software (cuando sea posible).
7) Mecanismos de medicin y de informacin.
Las anteriores involucran tanto a los ingenieros de software
como al equipo de SQA. Los ingenieros de software deben
aplicar mtodos tcnicos y mediciones slidas, conducir
revisiones tcnicas formales y ejecutar pruebas de software
bien planificadas. Por otro lado, de acuerdo al Software
Engineering Institute (SEI) [4], el equipo de SQA tiene como
propsito proveer a la gerencia la visibilidad apropiada del
proceso que est siendo usado y de los productos siendo
desarrollados. El propsito involucra:
Revisar y auditar los productos de software y actividades
para asegurar que obedecen a los procedimientos y estndares
aplicables.
Proveer al gerente del proyecto de software y a otras
gerencias, segn corresponda, los resultados de las revisiones
y auditorias. Las discrepancias son primero planteadas dentro
del proyecto de software y resueltas all, si es posible. Si no
se pueden resolver, se debe escalar a niveles superiores para
su resolucin.
Las actividades del equipo de SQA, acorde al SEI [4],
comprenden:
Preparar un plan de SQA para el proyecto: El plan es
desarrollado durante la planificacin del proyecto y es revisado
por todas las partes interesadas. Las actividades de
aseguramiento de la calidad a desempear por el equipo de
ingenieros de software y el equipo de SQA son regidas por este
plan. El plan identifica:
Evaluaciones a realizar.
Auditoras y revisiones a realizar.
Estndares aplicables al proyecto.
Procedimientos para reporte y seguimiento de errores.
Documentos a ser producidos por el equipo de SQA.
Retro-alimentacin a proveer al equipo del proyecto de
software.
Participar en el desarrollo de la descripcin del proceso de
software del proyecto: El equipo de software selecciona un
proceso de software para el proyecto, el equipo de SQA
revisa la descripcin del proceso, verificando que cumpla con
las polticas de la organizacin, estndares de software
internos y estndares impuestos externamente, entre otros.
Revisar las actividades de ingeniera del software o de
conocimiento para verificar que cumplan con el proceso de
software definido: El equipo de SQA identifica, documenta y
hace el seguimiento de cualquier desviacin del proceso y
verifica las correcciones realizadas.
Auditar productos de trabajo de software designados, para
verificar que cumplan con aquellos definidos como parte del
proceso de software: El equipo de SQA revisa productos
seleccionados; identifica, documenta y hace el seguimiento
de las desviaciones; verifica las correcciones realizadas y
peridicamente informa los resultados de su trabajo al
gerente del proyecto.
Asegurar que las desviaciones detectadas sean documentadas

y manejadas de acuerdo a procedimientos documentados: Las
desviaciones pueden encontrase en el plan de proyecto,
descripciones del proceso, estndares aplicables o productos
de trabajo tcnico.
Registrar cualquier incumplimiento y reportarlo a la alta
gerencia: A los incumplimientos se les debe hacer
seguimiento hasta que sean resueltos.
El equipo de SQA participa tambin en la tarea de
recolectar y analizar mtricas de software como as tambin en
establecer y revisar procedimientos, planes y estndares.
III. MODELO GENERAL
En la presente seccin se esboza el Modelo General, es
decir, el diseo de acciones y mtodos que constituyen un
enfoque prctico para el desempeo de la funcin de SQA en
una organizacin. Tambin se presenta el modelo de mejora
continua del mismo.
A. Modelo de aseguramiento de calidad sugerido
Una metodologa de desarrollo de software (ya sea para
software convencional o para sistemas basados en el
conocimiento) establece una forma consistente de ejecutar las
actividades relacionadas con el software dentro de una
organizacin. Toda metodologa describe:
Elementos: Cubren un conjunto de actividades bien
definidas, relacionadas y agrupadas.
Arquitectura: Establece el orden, las interfaces, las
interdependencias y otras relaciones entre los elementos.
Adicionalmente, la metodologa podra describir estndares,
mtodos y herramientas.
La metodologa de desarrollo es la que provee continuidad
en el proceso de software de una organizacin y es una
referencia para mtricas y mejoras de dicho proceso.
Sobre la base del concepto de metodologa y de los
conceptos bsicos ya definidos en el captulo anterior, se
propone un enfoque o modelo de aseguramiento de la calidad
del software que tiene las siguientes caractersticas:
El modelo de aseguramiento de calidad de software sugerido
es una interfaz a una metodologa de desarrollo de software.
En particular, para el presente trabajo, se utilizar la
metodologa IDEAL.
El modelo que aqu se presenta no es una metodologa en s
misma, sino que debe acoplarse a una metodologa de
desarrollo para poder implementarse.
Esta interfaz est compuesta por mdulos independientes,
donde cada uno de ellos se asocia a ciertos procesos de la
metodologa IDEAL.
La interfaz cuenta tambin con un mdulo de ejecucin
recurrente, en donde, para todas y cada uno de las entradas a
cada uno de los otros mdulos, se verifica la conformidad de
las mismas con la metodologa, estndares y normas aplicables
que estn vigentes en la organizacin.
El modelo de aseguramiento de la calidad del software
sugerido no es dependiente de la metodologa de desarrollo
utilizada en una organizacin, sino que se adapta a ella. Sobre
la base de los procesos de la metodologa de desarrollo, sus
precedencias, sus ciclos de ejecucin, y por supuesto de las
caractersticas del proyecto en curso, se seleccionan aquellas
porciones de la interfaz que resulten necesarias para obtener los
niveles de calidad deseados y el orden de ejecucin de las
mismas. En la figura 2 se muestra la relacin entre el modelo

general de aseguramiento de la calidad del software y la
metodologa IDEAL.
Metodologa de Desarrollo
del Software de la
Organizacin
Identificacin de la
tarea
Desarrollo de
los
prototipos
Interfaz de Aseguramiento de
la Calidad del Software
Planificacin
Requerimientos
Anlisis
Ejecucin
de la
construccin
del sistema
integrado
Diseo
Actuacin
para
conseguir el
mantenimiento perfectivo
Lograr una
adecuada
transferencia
tecnolgica
Metodologa,
Estndares y
Normas de la
Codificacin
Organizacin
Verificacin
del Sistema
Validacin
del Sistema
Instalacin
Fig. 2. Relacin entre el modelo general y la metodologa de desarrollo
B. Aplicacin del Modelo

El modelo aqu presentado, es un modelo genrico cuya
flexibilidad permite su adaptacin a cada proyecto en
particular. De esta forma, se podrn seleccionar los segmentos
del mismo que cubran las necesidades de cada proyecto,
evitando la realizacin de actividades innecesarias.
El modelo general de aseguramiento de la calidad, se
documenta en un plan general de aseguramiento de la calidad.
La flexibilidad, que permite la adaptacin del modelo genrico
o plan general de aseguramiento de la calidad del software, a
todo tipo de proyectos, se formaliza a travs de los planes
especficos de aseguramiento de la calidad del software para
cada proyecto.
El plan especfico de aseguramiento de la calidad, para un
proyecto en particular, ser entonces, la adaptacin del plan
general a las caractersticas particulares de ese proyecto. En la
figura 3 se muestra la relacin entre el plan general de
aseguramiento de la calidad del software y cada uno de los
planes especficos.
C. Mdulos del modelo
En el captulo siguiente se describir cada uno de los
mdulos del modelo general de aseguramiento de la calidad
propuesto, indicando para cada uno de ellos los siguientes:
171
Objetivo: Descripcin del propsito del mdulo, para usar

como una regla contra la que medir el progreso del mismo.
permanentes mejoras y actualizaciones de acuerdo a la

experiencia y a las necesidades que surjan como consecuencia
de la aplicacin del mismo.
En la figura 4 se muestra el modelo de actualizacin y
mejora continua del plan general de aseguramiento de la
calidad del software y de los planes especficos de
aseguramiento de la calidad del software de cada proyecto, as
como la adaptacin del plan general, y la ejecucin y
verificacin de los planes especficos.
Plan General de
Aseguramiento de la
Calidad del Software
Fig. 3. Relacin entre el plan general y los planes especficos
Entrada: Documentos y/o informacin necesaria para

completar el mdulo. El nombre de los documentos es
genrico, sin embargo este nombre debe ser adaptado al
nombre del producto resultante, del proceso lgico
correspondiente, en la metodologa utilizada.
Proceso: Descripcin de las tareas y acciones que debe
ejecutar el integrante del equipo de SQA para dar por
cumplido el mdulo.
Salida: Productos que deben ser generados al final del
mdulo.
Lista de verificacin: Checklist que utilizan los integrantes
del equipo de SQA para verificar que ha cumplido el mdulo
correctamente. Las lista de verificacin se definen en tablas,
los campos de esas tablas se explican en la tabla I.
TABLA I.
EXPLICACIN DE LOS CAMPOS QUE FORMAN PARTE DE LAS

TABLAS QUE DEFINEN LAS LISTAS DE VERIFICACIN
CAMPOS
Nmero
tem
Respuesta
Comentarios
Plan Especfico de
Aseguramiento de la
Calidad del Software
Paso 3
Actualizacin del Plan
Especfico
Paso 2
Ejecucin del Plan
Especfico
EXPLICACIN
Un nmero que identifica secuencialmente
los tems de control de calidad, el resultado
positivo indicara que ese paso ha sido
realizado correctamente.
tem especfico de control de calidad que es
usado para medir la efectividad de ejecucin
de este paso.
El analista de calidad deber indicar en esta
columna si ha realizado el tem referenciado.
La respuesta puede ser: SI, NO o N/A si la
misma no es aplicable al proyecto en
cuestin.
Esta columna es utilizada para clarificar la
respuesta de SI, NO o N/A para los tems
indicados.
Generalmente la columna de comentarios
slo se completa en las respuestas por NO;
las respuestas por NO debern ser
investigadas y se deber tomar una
determinacin respecto a si este tem deber
ser completado antes de considerar este
paso completo.
D. Actualizacin del plan

D.1. Modelo de mejora continua del plan
El modelo o plan general de aseguramiento de la calidad
del software
aqu presentado no mantiene un estado
estacionario o esttico, sino que es dinmico y sujeto a
172
Paso 1
Adaptacin del Plan
General a cada Proyecto
particular
Paso 4
Actualizacin del Plan
General
Productos resultantes de la
Ejecucin
Fig. 4. Modelo de actualizacin y mejora continua
D.2. Detalle del modelo de mejora continua del plan

A continuacin se detalla el modelo de mejora continua del
plan general de aseguramiento de la calidad como as tambin
de los planes especficos correspondientes a cada proyecto
particular.
Adicionalmente, y slo para contextualizar los pasos
correspondientes a la mejora continua, se detallan brevemente
los pasos correspondientes a la adaptacin del plan general, y
la ejecucin y verificacin de los planes especficos:
Paso 1:
Entrada: Plan general de aseguramiento de la calidad de
software.
Accin: Adaptacin del plan general de aseguramiento
de la calidad de software a cada proyecto particular.
Salida: Plan especfico de aseguramiento de la calidad
de software para un proyecto particular
Paso 2:
Entrada: Plan especfico de aseguramiento de la calidad

de software, para un proyecto particular.
Accin: Ejecucin del plan especfico de aseguramiento
de la calidad de software.
Salida: Productos resultantes de la ejecucin del plan
especfico de aseguramiento de la calidad de software.
Paso 3:
Entrada: Productos resultantes de la ejecucin del plan
especfico de aseguramiento de la calidad de software.
Accin: Anlisis de la calidad de los productos
resultantes de la ejecucin del plan especfico.
Generacin de recomendaciones y acciones a realizar,
con su correspondiente justificacin, para mejorar el
plan especfico de aseguramiento de la calidad de
software.
Salida: Plan especfico de aseguramiento de la calidad
de software, para un proyecto particular, actualizado.
Paso 4:
Entrada: Actualizaciones realizadas al plan especfico
de aseguramiento de la calidad de software, para un
proyecto particular.
Accin: Anlisis de las actualizaciones realizadas al
plan especfico de aseguramiento de la calidad del
software, con sus correspondientes justificaciones.
Actualizacin del plan general de aseguramiento de la
calidad del software.
Salida: Plan general de aseguramiento de la calidad del
software actualizado.
IV. MDULOS DEL MODELO
En el presente captulo se describen los Mdulos del
Modelo, se presentan para cada uno de ellos las acciones a
desempear, su objetivo, sus entradas, salidas, lista de
verificacin, mtricas y participantes involucrados.
A. Planificacin
A.1. Objetivo
Determinar qu recursos estarn disponibles para producir y
mantener el software asociado al proyecto.
Determinar cundo y cmo se incurrir en costos de personal,
tiempo de procesamiento, etc.
Medir el avance del desarrollo del proyecto.
A.2. Entrada
Plan de desarrollo (de software) del proyecto.
Estimacin del proyecto y mtodo utilizado para realizarla.
Descripcin del proceso de desarrollo a utilizar en el
proyecto.
A.3. Proceso
En la figura 5 se detalla grficamente, el proceso a
desarrollar durante este mdulo:
A.3.1.Verificacin de la Estimacin del Proyecto
Muchos proyectos de software son esencialmente
innovadores, pero una ineficaz estimacin del sistema, puede
llevar a un exceso de costos. Estimar costos de software es un
proceso complicado porque el desarrollo del proyecto es
influenciado por un largo nmero de variables, muchas de ellas

son subjetivas, no cuantificables e interrelacionadas en forma
compleja.
Fig. 5. Proceso del mdulo de planificacin
Una estimacin inapropiada de costos puede daar ms a la

calidad del proyecto de software que a cualquier otro factor.
Si la estimacin es incorrecta, el equipo de proyecto har lo
imposible para coincidir con la estimacin. Todo esto provoca
un aumento de costos de mantenimiento, insatisfaccin del
cliente, esfuerzo adicional en el rea del cliente para compensar
la debilidad del sistema, y desanimar al personal del proyecto.
La verificacin puede aumentar la validez de la estimacin. La
estimacin del software es un proceso de tres partes como se
describe a continuacin:
Validar la sensatez del modelo de estimacin.
Validar que el modelo incluya todos los factores necesarios.
Verificar la efectividad del modelo estimado de costo.
El detalle de cada uno de estos puntos, se encuentra en el
captulo de Tcnicas y Herramientas.
A.3.2. Verificacin del Estado del Proyecto
Para conocer el estado del proyecto se sugiere un sistema
simple de acumulacin de puntos para medir el progreso.
Luego este sistema puede compararse con el reporte gerencial
del proyecto. Si hay una diferencia significativa entre ambos
sistemas de medicin del progreso, el analista de calidad puede
cuestionar la validez de los resultados producidos por la
gerencia de proyecto y/ o sistema de conteo.
El sistema de puntos para realizar la medicin durante el
desarrollo del software, provee un mtodo objetivo, preciso y
eficiente de recoleccin y reporte del rendimiento de la
informacin en el campo de la ingeniera que a menudo carece
de visibilidad. El mtodo utiliza informacin basada en tems
de entregables de software y es obtenida como parte del
proceso de desarrollo. Los resultados son fciles de interpretar
y pueden presentarse en una variedad de formatos. El esquema
es flexible y puede modificarse para proyectos grandes y
chicos. El detalle del mismo, se encuentra en el captulo de
Tcnicas y Herramientas.
173
A.4. Salidas
Informe de estimacin del proyecto
Informe de estado del proyecto
B. Requerimientos
A.5. Lista de Verificacin (Checklist)

En la tabla I se presenta la lista de verificacin:
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
La gerencia del proyecto, esta de acuerdo en tener un equipo

de aseguramiento de la calidad y evaluacin de la estimacin y
estado del plan de desarrollo?
El equipo de aseguramiento de la calidad conoce la
estimacin del progreso utilizada para el proyecto?
El equipo de aseguramiento de la calidad conoce el mtodo
para realizar los informes de estado del proyecto?
El equipo de aseguramiento de la calidad entiende el mtodo
utilizado para estimar y calcular?
El equipo de aseguramiento de la calidad ha realizado una
buena verificacin para determinar la validez de las
estimaciones realizadas?
Si el equipo de aseguramiento de la calidad est en
desacuerdo con la validez de las estimaciones realizadas.
Existe un procedimiento razonable para manejar tales
diferencias?
El equipo del proyecto posee un sistema de reportes
razonable para informar el estado del mismo?
El equipo de aseguramiento de la calidad ha establecido que
pueden utilizarse los informes de estado de proyecto como
gua para la toma de decisiones?
Existe algn procedimiento a seguir, si los informes de estado
indican que el proyecto est por encima o por debajo de las
estimaciones?
El equipo de aseguramiento de la calidad ha tenido en cuenta
los factores ms importantes en la evaluacin de la estimacin
realizada (Ejemplo: tamao del software, etc.)?
El equipo de proyecto ha recibido una copia del estado del
mismo?
El equipo de aseguramiento de la calidad tiene conocimiento
de cmo se efecta la planificacin?
El equipo de aseguramiento de la calidad tiene conocimiento
de cmo se efecta la estimacin del proyecto?
El equipo del proyecto tiene conocimiento del proceso de
desarrollo utilizado para construir el software especificado por
el proyecto?
El plan de proyecto est completo?
La estimacin del proyecto est totalmente documentada?
El proceso de desarrollo est totalmente documentado?
El mtodo de estimacin utilizado para el proyecto, es
razonable respecto de las caractersticas del mismo?
La estimacin efectuada es razonable como para completar el
proyecto segn lo especificado en el plan?
El equipo del proyecto tiene un mtodo definido para
determinar e informar el estado del mismo
El equipo de aseguramiento de la calidad, est de acuerdo
con que el estado informado coincide con el estado actual del
proyecto?
A.6. Mtricas
Eficacia de la estimacin
de la duracin:
N/A
Respuesta
SI
NO
#
1
Comentarios
LISTA DE VERIFICACIN DEL MDULO DE PLANIFICACIN
tem
TABLA II.
Eficacia de la estimacin
del esfuerzo
Duracin actual del proyecto

Duracin estimada del
proyecto
Esfuerzo actual del proyecto
Esfuerzo estimado del
proyecto
A.7. Involucrados
A.7.1. Equipo de Ingeniera
Gerente de proyecto.
A.7.2. Equipo de Aseguramiento de la Calidad del Software
Lder de aseguramiento de la calidad del software.
174
B.1. Objetivo
Determinar si los requerimientos expresan las necesidades
del usuario.
Verificar la separacin de los requerimientos entre
obligatorios y opcionales.
Verificar que cada requerimiento:
Est debidamente documentado, reflejando las necesidades
del usuario.
Se encuentre dentro del alcance definido del sistema en
cuestin.
Se encuentre dentro de los lmites del presupuesto para el
sistema en cuestin.
Se encuentre bien definido (en forma completa), de manera
de evitar cambios posteriores.
Determinar que los requerimientos documentados puedan ser
implementables (pasibles de ser analizados, diseados,
codificados) y verificables (pasibles de ser verificados y
validados) en fases posteriores.
B.2. Entradas
Minutas de reunin con el usuario.
Documento de especificacin de requerimientos del usuario.
B.3. Proceso
desarrollar durante este mdulo.
HACER
VERIFICAR
REHACER
1 Paso
Minutas de Reunin con el
Usuario
Preparar la Matriz de
Riesgo
NO
2 Paso
Realizar un Anlisis de
Factores a Verificar
Definicin de los
requerimientos del
Proyecto
Requerimiento
preciso y completo
SI
Reportes de la
Verificacin
3 Paso
Conducir un
"Walkthrough"
Fig. 6. Proceso del mdulo de requerimientos
B.3.1. Preparar la Matriz de Riesgo

La Matriz de Riesgo es una herramienta diseada para
evaluar el control en los sistemas de informacin.
Uno de los mayores beneficios de la matriz de riesgo es, no
slo la identificacin de los mismos, sino tambin qu es lo que
el sistema debe hacer para con cada uno de ellos. En
principio, la matriz de riesgo es una herramienta de diseo,
pero puede ser usada como herramienta de verificacin.
En forma ideal la matriz de riesgo comienza en la fase de
requerimientos, se desarrolla en la fase de anlisis y se termina
en la fase de diseo. La ejecucin de la matriz de riesgo es un

proceso de cinco pasos, los cuales se encuentran detallados en
el captulo de Tcnicas y Herramientas.
B.3.2. Realizar un Anlisis de Factores a Verificar
Debe llevarse a cabo un proceso para estimar las
incumbencias (concerns) asociadas a la fase de
requerimientos del desarrollo del sistema. Debe incluirse un
programa de verificacin para cada factor a considerar (son
15), cubriendo cada fase del proceso de desarrollo. Para cada
factor hay un programa de verificacin que tiene en cuenta
ciertas consideraciones las cuales se encuentran detalladas en el
captulo de Tcnicas y Herramientas.
El programa de verificacin enumera aquellos criterios, que
aseguran al equipo de aseguramiento de la calidad, que la
magnitud de esa preocupacin es mnima. A estos criterios
debe responder el equipo de aseguramiento de la calidad.
Tambin se debe realizar una verificacin suficiente para
evaluar si el equipo de proyecto ha manejado adecuadamente
cada criterio de verificacin.
Los factores a verificar en la etapa de requerimientos son:
Requerimientos compatibles con la metodologa (Factor de
prueba: Metodologa)
Funcionalidad de las especificaciones definidas (Factor de
prueba: Precisin)
Usabilidad de las especificaciones (Factor de prueba:
Facilidad de uso)
Mantenimiento de las especificaciones (Factor de prueba:
Mantenibilidad)
Necesidades de portabilidad (Factor de prueba: Portabilidad)
Interfaces del sistema (Factor de prueba: Acoplamiento)
Criterios de performance (Factor de prueba: Performance)
Necesidades operativas (Factor de prueba: Facilidad de
operacin)
Tolerancia (Factor de prueba: Fiabilidad)
Reglas de autorizacin (Factor de prueba: Autorizacin)
Requerimientos de integridad de archivos (Factor de prueba:
Integridad de archivos)
Recuperacin ante fallas en los requerimientos (Factor de
prueba: Auditora)
Impacto de fallas (Factor de prueba: Continuidad de
procesamiento)
Nivel de servicio deseado (Factor de prueba: Nivel de
Servicio)
Permisos y accesos (Factor de prueba: Seguridad)
B.3.3. Conducir un Walkthrough de Requerimientos
De los procesos de revisin, la inspeccin o recorrido
(walkthrough) de requerimientos es el menos estructurado y el
ms propenso a la creatividad. Por lo tanto ste se convierte en
un proceso de revisin que complementa los objetivos de la
fase de requerimientos. El objeto de este proceso de revisin es
crear una situacin en la cual un grupo de gente con las
habilidades adecuadas pueda ayudar al equipo en el desarrollo
de las soluciones del proyecto. El walkthrough intenta usar la
experiencia y juicio del equipo de revisin como un soporte en
el proceso de desarrollo.
Este mtodo se implementa como un proceso de cinco

pasos ejecutados en secuencia, los cuales se encuentran
detallados en el captulo de Tcnicas y Herramientas, que son:
Establecer reglas bsicas
Seleccionar el equipo / Notificar a los participantes
Presentacin del proyecto
Preguntas / recomendaciones
Reporte final
El tiempo destinado a cada paso depender del tamao de
la aplicacin que se est revisando y el grado de asistencia
deseado del equipo de walkthrough.
B.4. Salidas
Matriz de riesgo
Anlisis de factores de verificacin.
Informe de la inspeccin (walkthrough) confeccionado.
Resumen de la inspeccin (walkthrough) confeccionado.
B.5. Lista de Verificacin (Checklist)
En la tabla III se presenta la lista de verificacin.
TABLA III.
LISTA DE VERIFICACIN DEL MDULO DE REQUERIMIENTOS
Respuesta
tem
SI
1
2
3
4
5
6
7
8
NO
Comentarios
N/A
Los
requerimientos
definidos
son
verificables?
El usuario est de acuerdo con el
requerimiento definido?
Los desarrolladores entienden los
requerimientos?
El requerimiento definido coincide con los
objetivos del proyecto?
Se identificaron los riesgos del proyecto?
Se sigui un proceso razonable en la
definicin del requerimiento?
El proceso de control de requerimientos, es
adecuado para minimizar los riesgos del
proyecto?
Durante el proceso de control de
requerimientos, se ha llevado a cabo un
walktrough?
B.6. Mtricas
Estabilidad
de
requerimientos:
los
Cantidad de requerimientos
iniciales
Cantidad total de
requerimientos
Completitud
de
requerimientos:
los
Cantidad de nuevos
requerimientos agregados
Cantidad total de
requerimientos
Tasa de efectividad de la
verificacin:
Cantidad de tems cubiertos

Cantidad total de tems
B.7. Involucrados
B.7.1. Equipo de Ingeniera
Grupo de anlisis de requerimientos.
B.7.2. Equipo de Aseguramiento de la Calidad del Software
175
Analistas de aseguramiento de la calidad del software Senior

y/o Semi-senior.
C. Anlisis
C.1. Objetivo
Describir la funcionalidad del producto que va a ser
entregado.
Definir el ambiente en el que va a operar.
Definir la confiabilidad y el compromiso de mantenimiento.
Identificar las necesidades de soporte u operacin, como
hardware, software, etc.
Definir para cada requerimiento, qu prueba se va a ejecutar
para asegurar que se cumpla con el mismo.
C.2. Entradas
Documento de especificacin de requerimientos revisado
Documento de especificacin funcional.
C.3. Proceso
En la figura C se detalla grficamente, el proceso a
Fig. 7. Proceso del mdulo de anlisis
C.3.1. Analizar la Especificacin Funcional

La especificacin funcional, debe ser vista como un
proceso de representacin, a fin de poder llegar a una exitosa
implementacin de software. Algunos principios para
especificar, podran ser:
Separar requerimientos funcionales de implementacin.
Desarrollar un modelo del comportamiento deseado del
sistema, que comprenda datos y la respuesta funcional del
sistema a los estmulos del ambiente.
Establecer un contexto en el cual el software opera
especificando la forma en la cual otros componentes del
sistema interactan con el software.
Desarrollar un ambiente en el cual el sistema opere y
reaccione a los estmulos del mismo.
Crear un modelo cognitivo en lugar de un diseo o un
modelo de implementacin. El modelo cognitivo describe el
176
sistema como es percibido por los usuarios de esa

comunidad.
Reconocer que una especificacin tendr varios niveles de
detalle.
Se verificar que la especificacin funcional cumpla, con
al menos, los siguientes lineamientos:
El formato de la representacin y contenido debera ser
relevante para el problema. Debe llevarse a cabo, un
desarrollo general para los contenidos de las especificaciones.
La informacin contenida en la especificacin debe ir de lo
general a lo particular (estar anidada). Las representaciones
deberan revelar capas de informacin a fin de permitir al
lector que pueda moverse al nivel de detalle que sea
requerido. Se deben indicar esquemas de numeracin dentro
de los diagramas utilizados, indicando el nivel de detalle que
se presenta. Es importante presentar la misma informacin a
diferentes niveles de abstraccin para ayudar a su
entendimiento.
Los formatos diferentes de diagramas a utilizar y otras
formas de notacin, debern ser restringidas al mnimo en
nmero y consistentes en su uso. La informacin confusa e
inconsistente, sea tanto simblica o grfica, perjudica el
entendimiento y propicia errores.
La especificacin funcional, debe ser verificable.
Se verificar que la especificacin funcional cumpla, con al
menos, el siguiente contenido:
I. Introduccin
a. Resumen del Sistema
b. Descripcin del producto
c. Entregables
II. Ambiente
a. Usuarios
b. Servicios
c. Fsico
d. Seguridad
III. Descripcin de la informacin
a. Representacin del contenido de la informacin
b. Representacin del flujo de la informacin
i. Flujo de datos
ii. Flujo de control
IV. Descripcin funcional
a. Particin funcional
b. Descripcin funcional
i. Narrativa de proceso general
ii. Restricciones / Limitaciones
iii. Requerimientos de rendimiento
iv. Restricciones de diseo
v. Diagramas de soporte
c. Descripcin de control
i. Especificacin de control
ii. Restricciones de para el diseo
V. Descripcin de situacin
a. Estado del sistema
b. Eventos y acciones
VI. Validacin y criterios
a. Lmites y restricciones
b. Clases de pruebas requeridas
c. Respuesta esperada del software
d. Consideraciones especiales
VII. Cronograma
VIII. Apndices
C.3.2. Conducir una Inspeccin Formal

La revisin de una especificacin funcional es conducida
por el desarrollador y el cliente. Dado que las especificaciones
forman el punto fundamental y a partir del cual se realizar el
diseo y subsecuentemente las actividades de la ingeniera del
software o de conocimiento, se debern extremar los cuidados
para conducir esta revisin.
La revisin en una primera instancia es conducida en un
nivel macro. En este nivel, los inspectores intentan garantizar
que la especificacin est completa, consistente y exacta.
Se tendrn en cuenta los siguientes lineamientos para una
revisin detallada:
Detectar y remplazar trminos vagos.
En el caso de listas de elementos, asegurar que hayan sido
incluidos todos.
Cuando se especifiquen rangos (numricos, etc.) asegurarse
que no contengan valores asumidos sin ser definidos
expresamente
Estar alerta de verbos y pronombres ambiguos.
Identificar afirmaciones que no incluyan certeza.
Cuando una estructura es descripta en palabras, asegurar que
se realice un diagrama para ayudar a comprenderla.
Cuando sea necesario realizar un clculo especificado,
asegurar que se presente al menos dos ejemplos del mismo.
Con respecto a los cambios en los requerimientos, una vez
que los mismos han sido finalizados, el usuario deber notar
que cada uno de ellos es una ampliacin del alcance del
software y por ende, un cambio en la especificacin funcional.
Esto incrementar el costo del proyecto y/ o extender el
tiempo establecido para su finalizacin.
An cuando se realicen las mejores revisiones, cierto
nmero de problemas en la especificacin persiste. La
especificacin es difcil de verificar, por ende las
inconsistencias u omisiones pueden pasar desapercibidas.
Durante la revisin, pueden ser recomendados ms cambios en
la especificacin funcional. Puede ser extremadamente difcil
estimar el impacto global del cambio, esto es, cmo un cambio
en una funcin afecta a los requerimientos en otra funcin.
Esto ltimo deber ser tenido muy en cuenta a la hora de
impactar dicho cambio.
Correctitud de la
funcionalidad:
Cantidad de funciones
corregidas
Cantidad total de funciones
establecidas
Completitud de la
funcionalidad:
Cantidad de nuevas funciones

agregadas
establecidas
Eficiencia en la
deteccin de defectos:
Cantidad de defectos detectados

hasta anlisis
Cantidad total de defectos
Eficiencia en la
remocin de defectos:
Cantidad de defectos removidos

hasta anlisis
Tasa de efectividad de
la verificacin:

TABLA IV.
C.6. Mtricas
Estabilidad de los
requerimientos:
1
2
3
4
5
6
7
8
9
12
13
Estabilidad de la
funcionalidad:
Cantidad de requerimientos
modificados
Cantidad total de requerimientos
establecidos
Cantidad de funciones
modificadas
establecidas
Respuesta
SI
11
C.5. Lista de Verificacin (Checklist)

En la tabla IV se presenta la lista de verificacin.
tem
10
C.4. Salidas
Informe de la Inspeccin
Resumen de la Inspeccin
LISTA DE VERIFICACIN DEL MDULO DE ANLISIS
NO
Comentarios
N/A
Los objetivos y metas del sistema se mantienen

consistentes con las polticas de software de la
organizacin?
La estructura y el flujo de la informacin, est
adecuadamente definida por el rea a la cual
compete el problema?
Son claros los diagramas? Pueden ser
explcitos sin necesidad de ser descriptos o
narrados?
Las funciones principales del sistema, estn
dentro del alcance? Cada una de ellas ha sido
adecuadamente definida?
Es consistente el comportamiento del sistema
con la informacin que debe procesar y las
funciones que debe desarrollar?
Las limitaciones del sistema son realistas?
Ha sido considerado el riesgo tecnolgico del
desarrollo?
Se han considerado requerimientos alternativos
de software?
Ha sido detallado el criterio de verificacin y
validacin? Los mismos, son adecuados para
determinar el xito del sistema?
Existen
inconsistencias,
omisiones
o
redundancias en el modelo de informacin del
sistema?
El usuario final ha estado involucrado?
El usuario revis el prototipo y/o manual del
usuario?
Han sido debidamente planificadas las
estimaciones de esfuerzo?
C.7. Involucrados
C.7.1 .Equipo de Ingeniera
Grupo de anlisis de requerimientos.
Grupo de anlisis funcional.
C.7.2. Equipo de Aseguramiento de la Calidad del Software
y/o Semi-senior.
177
D. Diseo
D.1. Objetivo
Establecer los factores que conducen a un diseo correcto y
preciso
Conducir revisiones de diseo.
Conducir inspecciones de los entregables del diseo
D.2. Entradas
Comprensin del diseo por parte del equipo de
aseguramiento de la calidad
Entregables derivados del diseo:
Especificaciones de entrada
Especificaciones de procesamiento
Especificaciones de archivos
Especificaciones de salida
Especificaciones de control
Diagramas de flujo del sistema
Requerimientos de software y hardware.
Especificacin de los procedimientos de operacin manual.
Poltica de resguardo de la informacin.
Documento de diseo de alto nivel (Lgico)
Documento de diseo de detalle (Fsico y lgico)
D.3. Proceso
Fig. 8. Proceso del mdulo de diseo
D.3.1. Ranking de Factores de xito

El ranking (scoring) es una herramienta predictiva que
utiliza experiencias en proyectos anteriores. Los proyectos en
curso son analizados para determinar los atributos de los
mismos y su correlacin con el xito o el fracaso de proyectos
o sistemas en particular. Una vez que los atributos
correlacionados al xito o al fracaso pueden ser identificados,
tambin pueden ser usados para predecir el comportamiento
del sistema que est en desarrollo.
El concepto es el mismo que el usado para predecir el
resultado de las elecciones. La gente que hace las predicciones
178
procura identificar distritos electorales que muestran una

correlacin histrica alta en los resultados de elecciones
anteriores. El conocimiento del registro de votos de un distrito
en especial y los resultados de elecciones previas, nos provee la
base para hacer futuras predicciones. Esos distritos con un
registro de grandes ganadores pueden servir de muestra, para
luego basados en esas muestras, predecir el resultado de una
eleccin antes que los votos sean contados.
Estos tipos de predicciones en sistemas de computacin son
bien conocidos, pero no han sido bien utilizados hasta que el
concepto de ranking fue desarrollado. Por ejemplo, sabemos
que hay una correlacin positiva entre la participacin del
usuario y el sistema de computacin: cuanto ms involucrado
este el usuario, mayor probabilidad de que el sistema sea
exitoso. Tambin sabemos que habr problemas con el sistema
de computacin que empuja las actuales corrientes de
tecnologa. Por ejemplo, el primer sistema en usar la nueva
tecnologa puede ser identificada como un sistema de alto
riesgo, porque la mayora de los inconvenientes ocurrir
durante la implementacin.
Los criterios que se utilizan bajo el concepto de ranking, se
describen en el captulo de Tcnicas y Herramientas
Al concluir el ranking, el resultado puede ser usado en
cualquiera de las siguientes formas:
Estimar la extensin de la verificacin: A mayor riesgo, la
gerencia del proyecto puede requerir ms verificaciones.
Sabiendo que la aplicacin es de alto riesgo, se alertar al los
gerente del proyecto respecto de la necesidad de tomar las
medidas correspondientes para reducir el riesgo a un nivel
aceptable.
Identificar mdulos a verificar: Dependiendo de la
sofisticacin del instrumento con el que se obtuvo el ranking,
puede identificarse mdulos especficos para la verificacin.
Por ejemplo, si la lgica computacional se sabe que es de alto
riesgo, la verificacin debera evaluar exhaustivamente la
exactitud de este proceso.
Identificar la composicin del equipo de verificacin: Los
tipos de riesgos asociados con el sistema ayudan a determinar
la composicin del equipo de test. Por ejemplo, si los riesgos
tratan ms con la tecnologa que con la lgica, el equipo de
test debera incluir individuos con conocimientos profundos
en esa tecnologa.
Al ranking de riesgo se llega a travs de un desarrollo
matemtico, como se muestra en el captulo de Tcnicas y
Herramientas.
D.3.2. Anlisis de Factores
El encargado de dirigir la verificacin podr seleccionar
los factores de inters apropiados, para ajustar la verificacin,
teniendo en cuenta los siguientes objetivos generales para la
fase de diseo:
Desarrollar una solucin al problema de negocio planteado.
Determinar el rol de la tecnologa para resolver el problema.
Desarrollar especificaciones para los segmentos manuales y
automatizados del sistema.
Cumplir con el plan de accin, procedimientos, estndares y
regulaciones.
Definir los controles que reducirn riesgos de la aplicacin,
llevndolos a un nivel aceptable.
Completar el proyecto dentro de las restricciones del

presupuesto, personal y cronograma establecidos.
Los factores que deben analizarse durante la fase de diseo
se describen a continuacin, y puede encontrarse ms detalle en
el captulo de Tcnicas y Herramientas: Los factores a verificar
en la Fase de Diseo son:
Controles de integridad de datos.
Reglas de autorizacin.
Controles de integridad de archivos.
Pistas de auditoria.
Plan de contingencia.
Mtodo para alcanzar el nivel de servicio requerido.
Procedimientos de acceso.
Diseo acorde con la metodologa establecida.
Diseo acorde con los requerimientos establecidos.
Facilidad de uso.
Mantenibilidad del diseo.
Portabilidad del diseo.
Interfaces de diseo.
Diseo acorde con criterios establecidos.
Necesidades de operacin.
D.3.3. Conduccin de la Revisin del Diseo
La revisin de diseo ser estructurada usando la misma
informacin bsica que la utilizada para llevar a cabo el
ranking. El objetivo es identificar de antemano aquellos
atributos del diseo que se correlacionan con los problemas del
sistema. Entonces durante la revisin del diseo, se
investigarn dichos atributos para determinar si el equipo de
proyecto los ha tratado apropiadamente.
La revisin del diseo deber ser conducida por un grupo
de individuos con conocimientos en el proceso de diseo. El
grupo tendr la responsabilidad de revisar la integridad y
racionabilidad de la aplicacin. No es necesario que el grupo
conozca la aplicacin especficamente pero s debe conocer la
metodologa de la organizacin.
La revisin de diseo normalmente es formal y altamente
estructurada. Los miembros del equipo intentan determinar si
todas las tareas se han realizado apropiadamente. Al final de la
revisin de diseo, el equipo emite un reporte indicando sus
hallazgos y recomendaciones acerca del proyecto. El equipo de
revisin de diseo comprende los siguientes miembros:
Personal del proyecto.
Equipo de revisin independiente.
La siguiente es la lista con los pasos de una revisin de
diseo, la descripcin detallada est en el captulo de Tcnicas
y Herramientas:
Seleccionar el equipo de revisin.
Entrenar los miembros del equipo de revisin.
Notificar al equipo de proyecto.
Asignar tiempos adecuados.
Documentar los datos de la revisin.
Revisar los datos con el equipo de proyecto.
Desarrollar recomendaciones de revisin.
Revisar recomendaciones con el equipo de proyecto.
Preparar un reporte final.
Una o ms revisiones pueden llevarse a cabo durante la fase

de diseo. La cantidad de revisiones depender de la
importancia del proyecto y del lapso de tiempo en la fase de
diseo. As podrn llevarse a cabo revisiones del diseo de alto
nivel y del diseo detallado. Cada defecto descubierto durante
la revisin del diseo de alto nivel debe documentarse. Se
confeccionar un reporte de defectos. Los defectos deben
documentarse, categorizarse, registrarse, presentarse al equipo
de proyecto para corregir, y referenciarlo al documento
especfico en el cual el defecto fue notado. Un ejemplo del
formulario para registrar estos defectos, puede encontrarse en
el captulo de Tcnicas y Herramientas.
D.3.4. Conduccin de la Inspeccin de los Entregables de
Diseo
La Inspeccin es un proceso por el cual los productos
completos pero no verificados, son evaluados para saber si los
cambios especificados fueron implementados correctamente.
Para lograr esto, los inspectores examinan los productos
antes del cambio, las especificaciones de cambio, y los
productos luego del cambio para determinar los resultados.
Buscan tres tipos de defectos: Incorrectos (el cambio no se ha
hecho correctamente), faltantes (algo que debera haberse
cambiado, no se cambi), y adicionales (algo fue cambiado o
agregado sin la intencin de hacerlo).
D.4. Salidas
Informe de la inspeccin.
Resumen de la inspeccin.
D.5. Lista de Verificacin (Checklist)
En la tabla 4.4 se presenta la lista de verificacin.
D.6. Mtricas
Eficiencia en la

hasta diseo
Cantidad total de defectos hasta
diseo
Eficiencia en la

hasta diseo
diseo
la verificacin:

Estabilidad del diseo:
Cantidad de cambios introducidas

en el diseo
Cantidad total de cambios en el
proyecto
D.7. Involucrados
D.7.1. Equipo de Ingeniera
Grupo de diseo de alto nivel (o lgico).
Grupo de diseo de detalle (o fsico).
Grupo de administracin de base de datos.
Grupo de analistas desarrolladores.
179
D.7.2. Equipo de Aseguramiento de la Calidad del Software

Lder de Aseguramiento de la Calidad del Software
y/o Semi-senior.
SI
25
26
E. Codificacin
27
E.1. Objetivo
El principal objetivo de esta prueba es asegurar que las
especificaciones de diseo hayan sido correctamente
implementadas.
E.2. Entradas
Los entregables que funcionan como entrada al proceso de
verificacin de codificacin son los siguientes:
TABLA V.
#
LISTA DE VERIFICACIN DEL MDULO DE DISEO
SI
1
3
4
5
6
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
180
El equipo de aseguramiento de la calidad

tiene buenos conocimientos acerca del
proceso de diseo?
Si se han utilizado herramientas
automatizadas en la creacin del diseo, las
conocen los miembros del equipo de
aseguramiento de la calidad?
Han recibido los miembros del equipo de
aseguramiento de la calidad todos los
entregables de la fase necesarios para llevar
a cabo las verificaciones correspondientes?
Los usuarios estn de acuerdo con que el
diseo representa la realidad?
El equipo de proyecto cree que el diseo
representa la realidad?
Han identificado los miembros del equipo de
aseguramiento de la calidad los factores de
xito, tanto positivos como negativos, que
pudieran afectar el xito del diseo?
Han utilizado los miembros del equipo de
aseguramiento de la calidad, tales factores
en la puntuacin de las probabilidades de
xito?
Entienden los miembros del equipo de
aseguramiento de la calidad los factores
relacionados con el diseo?
Han analizado los miembros del equipo de
aseguramiento de la calidad los factores de
test del diseo para evaluar el potencial
impacto sobre el xito del mismo?
Ha sido instruido el equipo de Revisin
acerca de lo que representa el xito del
Diseo?
La Gerencia apoya el uso del proceso de
revisin del diseo?
El proceso de revisin del diseo fue
conducido en un momento apropiado?
Son razonables los tems identificados en el
proceso de revisin del diseo?
Estn de acuerdo los miembros del equipo
de aseguramiento de la calidad que los tems
identificados necesitan ser verificados?
La Gerencia apoya la ejecucin de
inspecciones en el proyecto?
Se ha provisto del tiempo suficiente en el
cronograma del proyecto para realizar
inspecciones?
Han sido instruidos los responsables del
proyecto acerca de la importancia de la
participacin en las inspecciones?
La Gerencia ve las inspecciones como una
parte integral del proceso, en lugar de
tomarlo como una auditora al desempeo de
los participantes?
Han sido planificados los procesos de
Inspeccin?
Han sido identificados los inspectores y
asignado sus roles especficos?
Han sido entrenados los inspectores para
cumplir con su rol?
Se les ha dado a los inspectores los
materiales necesarios para cumplir con la
inspeccin?
Se les ha dado a los inspectores tiempo
adecuado para realizar las tareas habituales
que le permitirn cumplir con la preparacin
y la reunin para el proceso de inspeccin?
Se han preparado adecuadamente los
inspectores para la inspeccin?
Comenta
rios
Respuesta
tem
NO
N/A
28
29
30
31
32
Comenta
rios
Respuesta
tem
NO
N/A
Han preparado los inspectores una lista de

defectos?
Se ha programado la inspeccin
convenientemente
para
todos
los
inspectores?
Han concurrido todos los inspectores a la
reunin de inspeccin?
Estuvieron de acuerdo todos los inspectores
con la lista de defectos?
Fueron identificados los defectos durante la
reunin de revisin registrados y entregados
al autor?
El autor estuvo de acuerdo acerca de
realizar las correcciones necesarias?
Se ha desarrollado un proceso razonable
para determinar si esos defectos han sido
corregidos satisfactoriamente?
La certificacin del moderador ha sido
tomada en cuenta para el producto /
entregable inspeccionado?
Especificaciones de programas.
Documentacin de programas.
Listado de cdigo.
Programas ejecutables.
Diagramas de flujo de los programas.
Instrucciones para el operador.
E.3. Proceso
Fig. 9. Proceso del mdulo de codificacin
E.3.1. Depuracin de Programas

Se utilizan tres metodologas para la deteccin y
eliminacin de los errores en la codificacin:
Depuracin de errores sintcticos.
Depuracin de errores estructurales.
Depuracin de errores funcionales.
El detalle de cada una de ellas est en el captulo de
Tcnicas y Herramientas.
E.3.2. Anlisis de Factores de Codificacin

A continuacin, se detallan los factores a analizar. El
detalle de cada uno de ellos est en el captulo de Tcnicas y
Herramientas:
Implementacin del control de integridad de informacin.
Implementacin de reglas de autorizacin.
Implementacin de control de integridad de archivos.
Implementacin de auditoras de rastreo.
Plan de contingencia escrito.
Consecucin del nivel de servicio deseado para el sistema.
Implementacin de procedimientos de seguridad.
Cumplimiento del programa con la metodologa a adoptar.
Programa acorde al diseo (Correctitud).
Programa acorde al diseo (Facilidad de uso).
Mantenimiento del programa.
Programa acorde al diseo (Portabilidad).
Programa acorde al diseo (Acoplamiento).
Desarrollo de procedimientos operativos.
Criterio de ejecucin del programa (Performance).
E.3.3. Conduccin de Revisiones de Pares
Se utiliza la revisin por pares, para evaluar la estructura y
funcionalidad del programa. La revisin por pares detecta
errores sintcticos, ms por observacin personal que por el
resultado directo del Walktrough.
E.4. Salidas
Dos son las salidas de este proceso
La eliminacin de todos los errores de codificacin utilizando
pruebas estticas.
Listado de errores encontrados.
E.5. Lista de Verificacin (Checklist)
En la tabla VI se presenta la lista de verificacin:
TABLA VI.
#
LISTA DE VERIFICACIN DEL MDULO DE CODIFICACIN

Respuesta
tem
SI
1
2
3
4
5
6
7
8
9
10
NO
N/A
Es considerada una responsabilidad del programador la

verificacin y la validacin de los programas?
El programador entiende la diferencia entre testing esttico y
dinmico?
El programa podra ser sometido a testing esttico como
medio primario para remover defectos?
El programador entiende el proceso que generar el cdigo
del programa?
El programador entiende y usa la tcnica de debugging?
El programador entiende los conceptos implicados, y los
tendr presentes en la verificacin de la programacin?
El programador es verificado usando revisin por pares o
inspeccin de cdigo?
El programa ser sometido a un test completo antes de
ingresar a un nivel superior de test?
Todos los defectos no cubiertos estn registrados en
detalle?
Todos los defectos no cubiertos fueron corregidos antes de
ingresar al siguiente nivel de verificacin?
E.6. Mtricas
Densidad de defectos
por componente:
Eficiencia en la
Comen
tarios
Eficiencia en la
Cantidad de defectos
removidos
la verificacin:

E.7. Involucrados
E.7.1. Equipo de Ingeniera
Grupo de programacin.
E.7.2 Equipo de Aseguramiento de la Calidad del Software
y/o Semi-senior.
F. Verificacin del Sistema
F.1. Objetivo
El objetivo es determinar si el software funcionar
correctamente cuando se ejecute. Para ello:
Se verificar que se haya probado la ejecucin del software
en un ambiente separado (test), siendo aproximadamente el
mismo entorno operacional en que ser ejecutado luego
(produccin).
Las pruebas sern verificadas, una vez terminada su
ejecucin y aprobacin interna.
Cualquier desviacin de los resultados esperados ser
reportada.
Dependiendo de la severidad y naturaleza de dichos
problemas, podran llegar a realizarse solicitudes de cambios al
sistema antes de su puesta en produccin.
F.2. Entradas
Planes de pruebas:
Pruebas en lnea (On-Line)
Pruebas por lotes (Batch)
Pruebas de interfaces.
Pruebas de regresin.
Pruebas de integracin.
Pruebas de stress.
Datos de prueba.
Resultados de las pruebas.
F.3. Proceso
Tamao del componente
detectados
181
Fig. 10. Proceso del mdulo de verificacin
F.3.1. Verificar la Construccin de Datos / Scripts de

Prueba
El concepto de construccin de datos de prueba es,
simplemente, la creacin de un proceso representativo de la
realidad usando transacciones ficticias. De dichos datos, se
tomar una muestra representativa para llevar a cabo una
verificacin de los mismos. La correcta seleccin de dicha
muestra es la clave para el xito de esta tarea. Dentro de esta
tarea debe abarcarse la verificacin de los siguientes:
Diseo de archivos de prueba
Estos archivos deben involucrar transacciones normales,
transacciones con datos invlidos, y transacciones que
puedan hacer incurrir al sistema en alguna situacin de
excepcin.
Ingreso de los datos de prueba
Despus que las transacciones de prueba estn definidas, se
deben introducir en el sistema todos los datos necesarios
para que las mismas puedan ser procesadas.
Anlisis de los resultados esperados
Antes de procesar alguna transaccin, el equipo de proyecto
debe establecer el resultado esperado para cada transaccin
a probar para poder compararla con el obtenido luego de
realizada la misma.
Prueba de transacciones
Para la prueba mencionada se recomiendan los siguientes 9
pasos:
Identificar los recursos de prueba.
Identificar las condiciones de prueba.
Priorizar las condiciones.
Seleccionar las condiciones.
Determinar los resultados esperados.
Crear transacciones de prueba.
Documentar las condiciones de prueba.
Ejecutar la prueba
182
Verificar y corregir.
Prueba de volumen
El objetivo de dicha prueba es verificar que el sistema
pueda realizar adecuadamente las transacciones cuando sus
programas internos o sus lmites se vean excedidos. Estas
pruebas suelen involucrar grandes volmenes de datos. Los
pasos que se recomiendan para esta prueba son:
Identificar las entradas del sistema.
Identificar las salidas del sistema.
Llevar cada dato a su mxima expresin tratando de
sobrepasar sus lmites.
Documentar las limitaciones.
Realizar la prueba de volumen.
Creacin de casos de prueba
Determinar el nivel de la prueba: Unitaria,
concurrencia, integracin, regresin o stress.
Desarrollar los casos de prueba: Un caso de prueba,
son todos los pasos que deben seguirse en el sistema
para probar dicho caso.
Ejecutar los casos de prueba: Usar el sistema con los
casos desarrollados en el punto anterior.
Analizar los resultados.
Mantener los casos de prueba.
F.3.2. Verificar la Ejecucin de la Prueba
Para lograr una prueba efectiva, se debe usar un plan de
pruebas creado previamente. Esta etapa es la culminacin de un
trabajo previo preparado para esta fase. Si esto no ocurre, la
prueba podra resultar poco efectiva y antieconmica.
Durante esta fase, el equipo de aseguramiento de la calidad,
llevar a cabo tanto la verificacin de los planes de prueba,
como la verificacin de la ejecucin de los mismos. Todo esto
se realizar, tomando muestras representativas de los planes y
sus respectivas ejecuciones.
Se verificar tambin, que los siguientes tipos de prueba
hayan sido llevados a cabo por el equipo de proyecto durante
esta fase:
Prueba manual, de regresin y funcional
La prueba manual asegura que las personas que interacten
con el sistema van a poder realizar las operaciones
propuestas; la prueba de regresin es la verificacin de que
lo que se est instalando no afecta a lo que ya estaba
instalado; y la prueba funcional apunta a que los
requerimientos del sistema puedan ser ejecutados
correctamente en diversas circunstancias.
Prueba de autorizacin
En esta prueba deben verificarse las reglas de
autorizaciones (permisos) para ejecutar las distintas
transacciones de la aplicacin.
Prueba de integridad
Debe ser verificada durante la prueba, los controles sobre la
integridad de los archivos de datos.
Prueba de pistas de auditoria
La funcin de pistas de auditoria, debe ser probada para
asegurarse que para cualquier transaccin, pueda
realizrsele un seguimiento desde su inicio hasta su fin,
para lograr una correcta reconstruccin de la misma cuando
sea necesario.
Prueba de recuperacin
Si el procesamiento debe continuar aunque el sistema no
est operativo, puede llegar a tener que provocarse fallas
intencionales en el sistema, para poder realizarse la prueba
de continuidad, la cual implica lo antedicho.
Prueba de stress
Es la prueba que asegura y cuantifica el nivel de servicio
del sistema ante grandes volmenes de datos.
Prueba de seguridad
En esta prueba lo que se intenta es violar todos los aspectos
de seguridad del sistema queriendo obtener como resultado
que ninguno de estos falle.
Prueba acorde a la metodologa
Todo tipo de prueba, deber ser llevado a cabo de acuerdo a
las polticas, estndares y procedimientos establecidos en la
metodologa de la organizacin. Esta ltima debera
especificar el plan de prueba requerido para cada tipo de
prueba, las tcnicas y herramientas de prueba
recomendadas, as como el tipo de documentacin
requerida a lo largo de la prueba misma. La metodologa
debera especificar el modo de determinar cundo una
prueba fue exitosa o no.
Prueba funcional
Esta prueba verifica el correcto cumplimiento de los
requerimientos del usuario.
Prueba de operacin
El xito de esta etapa depender fuertemente de la habilidad
de las personas que utilicen el sistema, adems es
importante que esta prueba se haga en un ambiente lo ms
parecido posible al de produccin.
Inspecciones
En esta prueba lo que se hace es evaluar el cdigo del
sistema para verificar ciertas reglas que lo harn fcil de
mantener ante supuestas modificaciones. Dichas reglas,
debern estar explicadas dentro de los estndares de la
organizacin.
Prueba de desastre
En esta prueba lo que se hace es provocar problemas en el
ambiente real de la aplicacin ya que es la nica manera de
ver realmente cmo se comporta el sistema ante situaciones
inesperadas.
Prueba funcional y de regresin
Esta fase de la prueba debe verificar la comunicacin con
los sistemas relacionados. Donde, la prueba funcional
verifica la interconexin de la nueva funcionalidad, y la
prueba de regresin verifica la continuidad del
funcionamiento del resto de los subsistemas asociados
preexistentes.
Prueba de performance
Los criterios de performance son establecidos durante la
fase de requerimientos e intentan ser medidos en la fase de
verificacin. De no poder realizarse porque el ambiente
necesario para llevarla a cabo sera muy costoso, se dejar
para ser medido en produccin.
Prueba de facilidad de operacin
Esta prueba generalmente es realizada por el equipo de
Operaciones que tratar normalmente con el sistema y se
intenta que el personal del grupo de proyecto no provea
ningn tipo de instrucciones a los usuarios, para que pueda

reproducirse el normal desarrollo de las transacciones, tal
como sera en el ambiente de produccin.
F.3.3. Verificar el Registro de los Resultados de la Prueba
Ya que documentar un problema, es el primer paso para la
correccin del mismo, es necesario llevar adelante una
verificacin del registro de los resultados de la prueba. Esto se
llevar a cabo, tomando muestras representativas de tales
resultados, para su anlisis posterior.
Se verificar que estn descriptos al menos, los siguientes
aspectos, para todos los problemas encontrados en las pruebas:
Declaracin del problema: Establecer cul es el problema.
Criterio: Establecer cmo debera comportarse el sistema.
Efecto: Es la diferencia entre el problema y el
comportamiento esperado.
Causa: Qu puede haber causado el problema?.
Para lograr una buena documentacin de los problemas, es
aconsejable seguir estos tres pasos:
Documentar el desvo: Esencialmente el usuario compara lo
que es con lo que debera ser, y cuando es identificada una
desviacin en este sentido, corresponde comenzar a
desarrollar la declaracin del problema.
Documentar el/ los efecto/s: Aqu debe evaluarse lo que el
problema significa para el sistema. La atencin que se le dar
al mismo, estar directamente relacionada con lo declarado
en el/ los efecto/s.
Documentar la o las causas: La o las causas son la o las
razones subyacentes para la condicin. En algunos casos la
causa puede ser obvia a travs de los hechos. Pero en otros,
puede ser necesaria una investigacin para encontrarla.
F.4. Salidas
Muestra de planes de prueba verificados.
Muestra de transacciones de prueba verificadas.
Muestra de resultados de la ejecucin de dichas transacciones
verificados.
Desvo de los resultados esperados documentados.
F.5. Lista de Verificacin (Checklist)
En la tabla VII se presenta la lista de verificacin:
TABLA VII.
#
LISTA DE VERIFICACIN DEL MDULO DE VERIFICACIN

Respuesta
tem
SI
1
2
3
4
5
6
7
8
9
10
11
12
NO
Comentarios
N/A
Todos los pasos fueron realizados como se

especificaron?
Si los pasos no fueron realizados como se especificaron.
Se afectaron recursos adicionales para resolver
defectos durante la etapa de ejecucin?
Se estableci un ambiente de prueba apropiado para
realizar la prueba del software?
Se entren analistas de calidad en las herramientas de
verificacin que sern utilizadas durante esta etapa?
Se fij un tiempo adecuado para esta etapa?
Se fijaron los recursos adecuados para esta etapa?
Los mtodos para crear datos de prueba son
apropiados para el sistema?
Fueron creados los datos de prueba necesarios para
probar adecuadamente el software?
Fueron programadas todas las tcnicas de verificacin
indicadas en el plan de prueba para ser ejecutadas
durante este paso? (Ej. Prueba de regresin)
Fueron determinados los resultados esperados de las
pruebas?
Se ha establecido el proceso por el cual se determina
el desvo entre los resultados esperados y los actuales?
Se han documentado los resultados esperados y los
actuales cuando existe una diferencia entre ellos?
183
Respuesta
tem
SI
13
14
NO
Comentarios
N/A
Se determin el potencial impacto de una desviacin?

(Ej. Problema en la verificacin)
Se ha establecido un procedimiento para asegurar las
acciones / resolucin apropiada de los defectos?
F.6. Mtricas
Eficiencia en la

hasta verificacin
verificacin
Eficiencia en la

hasta verificacin
verificacin
la verificacin:
Cantidad de tems
cubiertos
Antigedad media de
defectos pendientes:
Total de antigedad de defectos

pendientes al fin de un perodo
pendientes al fin de un perodo
Antigedad media de
defectos cerrados:
Total de antigedad de defectos

cerrados al fin de un perodo
cerrados al fin de un perodo
G.2. Entradas
Las entradas dependen del alcance asignado a la validacin
del sistema (prueba de aceptacin). Estas suelen ser:
Software probado: Una vez realizada la verificacin de las
piezas de software se comienza con la prueba de aceptacin.
Plan de Prueba de Aceptacin:
Pruebas en Lnea (On-Line).
Pruebas por Lotes (Batch).
Pruebas de Interfaces.
Pruebas de Integracin.
Pruebas de stress.
Pruebas de conectividad.
Pruebas de servidores.
Lista de defectos no resueltos: Quizs no sea prudente
esperar hasta que todos los defectos reportados sean
corregidos antes de empezar las pruebas de aceptacin. En
este caso, los encargados de efectuar las pruebas de
aceptacin reciben una lista no resuelta de defectos, la cual
les permitir conocer los procesos incorrectos y as enfocar la
atencin en los criterios principales de aceptacin antes de la
prueba.
G.3. Proceso
G.3.1. Verificar los Criterios de Aceptacin Definidos
El usuario deber definir el o los criterios que el software
deber cumplir para ser aceptado.
F.7. Involucrados
F.7.1. Equipo de Ingeniera
Representante del grupo de anlisis de requerimientos.
Representante del grupo de anlisis funcional.
Representante del grupo de diseo.
Representante del grupo de analistas desarrolladores.
Grupo de testeo.
F.7.2. Equipo de Aseguramiento de la Calidad del Software
y/o Semi-senior.
G. Validacin del Sistema
G.1. Objetivo
Describir los procedimientos para identificar los criterios de
aceptacin para el ciclo de vida de los productos y para
validarlos. La aceptacin final no solo tiene en cuenta que el
producto de software resuelva adecuadamente los
requerimientos de los usuarios, sino tambin, reconocer que el
proceso de desarrollo fue adecuado. Como parte del proceso de
ciclo de vida, la aceptacin del software permite:
Deteccin temprana de los problemas del software.
Preparacin apropiada de los medios para realizar la prueba.
Consideracin temprana de las necesidades del usuario
durante el desarrollo del software.
184
Fig. 11. Proceso del mdulo de validacin
Los requerimientos de aceptacin que el sistema debe

cumplir, pueden ser divididos en las siguientes cuatro
categoras:
Requerimientos Funcionales: Referido a las reglas de negocio
que el sistema debe ejecutar.
Requerimientos de Performance: Referido a los tiempos y

recursos de operacin.
Requerimientos de Interfaz: Referido a la relacin humano /
mquina, mquina / mdulo.
Requerimientos globales de Calidad del Software: Referidos
a la obtencin de los lmites para los factores o los atributos
tales como la fiabilidad, comprobabilidad, exactitud, y
usabilidad.
Estos criterios deberan estar enunciados y documentados
durante la fase de requerimientos, para ser refinados y
detallados en las fases siguientes. Se proceder a solicitar la
recopilacin de estos requerimientos, luego el equipo de
aseguramiento de la calidad, proceder a verificarlos.
Se debera determinar con el usuario, el grado de criticidad
de los requerimientos para los tems cuyas categoras se
presentan en la tabla VIII.
G.3.2. Verificar el Desarrollo del Plan de Aceptacin
El primer paso para completar la aceptacin del software es
el desarrollo simultneo de un plan de aceptacin, un plan de
proyecto y de los requerimientos del software que aseguran que
las necesidades del usuario estn representadas correcta y
completamente. Este desarrollo simultneo proveer una visin
general que asegurar que todo los recursos necesarios, estarn
incluidos en el plan de proyecto.
En la tabla IX se detallan los puntos a verificar dentro de un
plan de aceptacin tpico.
TABLA VIII.
Categora
TEMS DE REQUERIMIENTOS PARA DETERMINAR SU

CRITICIDAD
tems
Consistencia interna de documentos, cdigo, y entre
Funcionalidad
las fases.
Trazabilidad (posibilidad de seguimiento) de la

funcionalidad.
Verificacin adecuada de la lgica.

Preservacin de funcionalidad en el ambiente
productivo.
Anlisis de factibilidad de requerimientos de
Performance
performance.
Interfaz
Calidad global del

software
Herramientas de simulacin.
Anlisis de desempeo en el ambiente productivo.
Documentacin de la interfaz.
Complejidad de la interfaz.
Planes de prueba e integracin de la interfaz.
Ergonoma de la interfaz.
Prueba de la interfaz en el ambiente productivo.
Cuantificacin de medidas de calidad.
Criterios para la aceptacin de los productos de
software.
Suficiencia de documentacin y normas de desarrollo

de sistemas.
Criterios de Calidad para la Prueba Operacional.

TABLA IX.
Contenido
Descripcin del
proyecto
PUNTOS A VERIFICAR DENTRO DE UN PLAN DE ACEPTACIN

TPICO
Descripcin
Tipo de sistema.
Ciclo de vida definido por la metodologa de la
organizacin.
Usuarios del sistema.

Principales tareas que debe satisfacer el sistema.
Principales interfaces externas del sistema.
Contenido
Responsabilidades
del usuario
Descripcin
Uso normal esperado.

Potenciales usos indebidos.
Riesgos.
Restricciones.
Estndares y Normas.
Organizacin y responsabilidades para las actividades de
aceptacin del sistema.
Recursos y cronograma de requerimientos.

Requerimientos del recurso.
Requerimientos para soporte automatizado, datos
especiales, y entrenamiento.
Procedimientos
administrativos
Descripcin de
aceptacin
Normas, estndares y convenciones.

Actualizacin y revisin de los planes de aceptacin.
Informes de anomalas.
Control de cambios.
Resguardo de informacin.
Objetivos para el proyecto.
Resumen de criterios de aceptacin.
Principales actividades de aceptacin y revisiones.
Requerimientos de informacin.
Tipos de decisiones de aceptacin.
Responsabilidad de las decisiones de aceptacin.
G.3.3. Verificar la Ejecucin del Plan de Aceptacin

El objetivo de este paso es, verificar el cumplimiento de los
criterios de aceptacin, en el producto entregado. Esto se puede
llevar a cabo a travs de revisiones, que involucran verificar
productos provisorios y entregables desarrollados parcialmente,
a lo largo del proceso de desarrollo.
El criterio de aceptacin del sistema, debera estar
especificado formalmente en el plan del proyecto. El plan
identifica los productos a ser verificados, el criterio especfico
de aprobacin/rechazo, las revisiones,
y los tipos de
verificacin que se harn durante el ciclo de vida completo.
Las decisiones de aceptacin necesitan una estructura sobre
la cual operar, algunos componentes son: contratos, criterios de
aceptacin y mecanismos formales. La aceptacin del software
deber referirse a un criterio especfico que los productos
deben tener para ser aceptados. El principal medio para
alcanzar la aceptacin en el desarrollo de los sistemas de
software, es mantener una revisin peridica
de la
documentacin y productos de software.
Cuando la decisin de aceptacin requiere cambios, se hace
necesaria otra revisin para asegurarse de que los cambios
solicitados hayan sido configurados e implementados en forma
correcta, y que el efecto en cualquier otra parte sea aceptable.
Las actividades de aceptacin, pueden incluir la
verificacin de las piezas de software. La verificacin de
aceptacin del software, se vuelve formal, cuando durante el
ciclo de vida del desarrollo, el usuario acepta o rechaza el
mismo. Esto es como un requerimiento contractual entre el
usuario y el equipo del proyecto. El rechazo, generalmente,
significa que se deber realizar un trabajo adicional en el
sistema a fin de hacerlo aceptable para el usuario. La prueba de
aceptacin final, es la ltima oportunidad que tiene el usuario
para examinar la funcionalidad, interfaz, performance y
aspectos de calidad antes de la revisin final de aceptacin. En
ese momento, el sistema deber incluir el software a entregar,
toda la documentacin de usuario y las versiones finales de
otros entregables del sistema.
185
G.3.4. Revisar la Decisin de Aceptacin

La aceptacin de un sistema generalmente significa que el
proyecto se ha completado, con la excepcin de alguna
contingencia.
Las decisiones de aceptacin pueden involucrar alguna de
las siguientes situaciones:
Los cambios solicitados son aceptados antes de pasar a
desarrollar la prxima actividad.
Algunos cambios, deben ser aceptados y llevados a cabo
antes de continuar con el desarrollo del producto, y otros,
pueden ser postergados hasta la prxima revisin del
producto.
El desarrollo puede continuar y los cambios podrn ser
aceptados en la prxima revisin.
No hay cambios solicitados y el desarrollo puede continuar.
Cada una de estas situaciones, ser verificada por el equipo
de aseguramiento de la calidad, teniendo en cuenta los defectos
no resueltos, el cronograma del proyecto, el estado actual del
mismo, los recursos involucrados, etc.
G.4. Salidas
Informe de la decisin de Aceptacin.
LISTA DE VERIFICACIN DEL MDULO DE VALIDACIN

Respuesta
tem
SI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
186
Se incorpor la prueba de aceptacin al plan general de

pruebas?
La prueba de aceptacin est enfocada como un
proceso del proyecto en lugar de un paso aislado al final
del testing?
Fueron seleccionados los usuarios correctos para
determinar los criterios de aceptacin para el software y/o
componentes de hardware?
El grupo que define los criterios de aceptacin, es
representativo de los usos del sistema a ser probado?
Esos individuos aceptan la responsabilidad de identificar
los criterios de aceptacin?
Los criterios de aceptacin fueron identificados
tempranamente como para lograr influir en el planteo e
implementacin de la solucin?
Se ha desarrollado y escrito el plan de aceptacin?
El plan de aceptacin es consistente con los criterios de
aceptacin?
Se estn verificando los productos intermedios por parte
de los testeadores, antes de ser utilizados para la
siguiente tarea de implementacin?
Se han seleccionado las tcnicas de prueba apropiadas
para el test de aceptacin?
Los testeadores tienen el nivel de conocimiento
necesario para realizar dicha tarea?
Se afectaron los recursos necesarios para la realizacin
de la prueba de aceptacin?
Se destin el tiempo necesario para la realizacin de la
prueba de aceptacin?
Se han publicado las opiniones internas de la prueba de
aceptacin?
Fue buena la reaccin del equipo del proyecto en lo que
concierne a los testeadores en la prueba de aceptacin?
Se ha tomado la decisin final de aceptacin del
sistema?
Se han identificado los criterios de aceptacin crticos?
Los requerimientos fueron escritos con el detalle
suficiente, de forma tal de poder obtener a partir de ellos
las interfaces?
Estn los responsables de cada interfaz, descritos en el
diagrama?
Se ha definido un caso de prueba para cada uno de los
lmites que posee el sistema?
Los usuarios del sistema estn de acuerdo con los
casos definidos? Los consideran completos?
Se definieron tanto las condiciones normales como las
fallidas a probar?
Los usuarios estn de acuerdo con que los casos de
prueba cubren todos los probables escenarios?
Eficiencia en la

hasta validacin
validacin
Eficiencia en la

hasta validacin
validacin
la verificacin:

Estabilidad de las
criterios de aceptacin:
Cantidad de criterios iniciales

Cantidad total de criterios
Estabilidad de la
aceptacin:
Cantidad de cambios durante la

aceptacin
Cantidad total de cambios
G.7. Involucrados
G.5. Lista de Verificacin (Checklist)

En la tabla X se presenta la lista de verificacin.
TABLA X.
G.6. Mtricas
NO
N/A
Comentarios
G.7.1. Equipo de Ingeniera

Representante del grupo de anlisis de requerimientos.
Representante del grupo de anlisis funcional.
Representante del grupo de diseo.
Representante del grupo de analistas desarrolladores.
Grupo de testeo.
Usuario final.
G.7.2. Equipo de Aseguramiento de la Calidad del Software
y/o Semi-senior.
H. Instalacin
H.1. Objetivo
Realizar una verificacin completa de la fase de instalacin
para nuevos sistemas y/o cambio de versiones. La verificacin,
incluye, para cada criterio de instalacin identificado, una
evaluacin recomendada y las tcnicas y herramientas
sugeridas para llevarla a cabo.
H.2. Entradas
Plan de instalacin.
Diagrama de flujo de la Instalacin.
Documentos y listados de instalacin (slo si es requerida
una instalacin especial).
Resultados de la verificacin de instalaciones especiales.
Documentacin de pasaje del sistema a produccin.
Instrucciones para los nuevos operadores.
Instrucciones y procedimientos para los nuevos usuarios.
Resultado del proceso de instalacin.
H.3. Proceso
H.3.2. Verificacin de la Instalacin de Cambios de Software

El objetivo principal es instalar el cambio requerido en el
tiempo adecuado. A continuacin se detallan los objetivos
especficos de la instalacin de cambios:
Poner a la aplicacin modificada en produccin.
Evaluar la eficiencia de los cambios.
Monitorear la exactitud de los cambios.
Mantener actualizadas con las ltimas versiones disponibles,
los ambientes de prueba y produccin.
Son tres las sub-tareas a verificar en la instalacin de
cambios de software.
Fig. 12. Proceso del mdulo de instalacin
H.3.1. Verificacin de la Instalacin de Nuevo Software

La fase de instalacin posee dos dificultades para el
equipo de aseguramiento de la calidad. La primera es que la
instalacin es un proceso separado del resto del desarrollo de la
aplicacin. Estas funciones no estn relacionadas con las
necesidades del usuario, pero s con las de instalar en
produccin una aplicacin completa y verificada. La segunda
dificultad es que la instalacin ocurre en un lapso de tiempo
muy corto. Es comn que la instalacin dure unas horas. Por lo
tanto la verificacin debe ser bien planeada y ejecutada.
Es importante que los resultados de la verificacin estn
disponibles antes de la instalacin completa del sistema. El
objetivo de la verificacin es determinar si la instalacin fue
exitosa, por lo tanto los resultados deben estar disponibles lo
antes posible. Esto significa que los resultados a obtener de la
verificacin deben estar explicitados antes de que la
verificacin comience. Los 15 factores a tener en cuenta en la
verificacin de la instalacin son:
Integridad y exactitud de la instalacin.
Prohibicin de modificacin de datos durante la instalacin.
Integridad de archivos de produccin.
Registro de pistas de auditora de instalacin.
Integridad del sistema/versin anterior asegurado
(continuidad de procesamiento).
Recuperacin ante fallas de la instalacin.
Control de acceso durante la instalacin.
Instalacin acorde a la metodologa.
Instalacin en produccin de los programas indicados en la
fecha asignada.
Puesta a disposicin de instrucciones de instalacin.
Documentacin completa (Mantenibilidad).
Documentacin completa (Portabilidad).
Interfaces.
Monitoreo de la performance.
Procedimientos operativos.
a) Verificar si es adecuado el plan de recuperacin ante fallas

Existen varios aspectos de los cambios que impactan en el
proceso de recuperacin ante fallas:
Agregado de una nueva funcin.
Cambio en un JCL (Job Control Language).
Uso adicional de programas utilitarios.
Cambios en perodos de resguardo.
Cambios en los programas.
Introduccin de un formulario nuevo o revisado.
Los analistas de calidad deben evaluar el impacto en el
plan de recuperacin, cambio por cambio. Si determinan que el
cambio afecta a la recuperacin, se debe actualizar el plan.
b) Verificar que el cambio correcto, fue puesto en produccin
El pasaje de la modificacin, desde del ambiente de
prueba a produccin lo debe hacer el dueo del software,
previa aprobacin del usuario.
El ambiente de produccin debera ser capaz de controlar
los programas de acuerdo con la fecha de puesta en
produccin. Cada versin del programa en produccin debera
ser identificada (etiquetada) de acuerdo a si entra o sale de
produccin. Debe estar disponible para cada programa un
historial de los cambios, y as poder proveer pistas de auditora.
Para verificar que se introdujo el cambio correcto en
produccin se verificar lo siguiente:
Que los cambios en los programas hayan sido documentados:
El objetivo es contar con un historial, para proveer pistas de
auditora que indiquen cundo se ha realizado un cambio y
por otro impedir cambios no autorizados.
Que se cuente con un procedimiento para pasajes de
versiones del ambiente de prueba al ambiente de produccin.
El dueo del software decide cundo una versin va a ser
pasada a produccin. Esta aprobacin da la orden a
operaciones para dar aviso que el cambio va a ser instalado.
Que el procedimiento citado en el punto anterior se cumpla
c) Verificar que las versiones innecesarias hayan sido
eliminadas
Los programas con versiones innecesarias (viejas) deben
ser borrados. Esto solo puede hacerse con el debido nivel de
autorizacin. Se debe elaborar un formulario que autorice la
eliminacin de las versiones antiguas. Este formulario lo debe
completar el Gerente del proyecto de mantenimiento de
software y enviarlo al departamento de operaciones.
El departamento de Operaciones debe tener un proceso
para eliminar versiones innecesarias, despus de recibir la
debida autorizacin.
187
H.3.3. Seguimiento en Produccin

Los sistemas aplicativos son propensos a tener problemas
inmediatamente despus de introducir una nueva versin. Por
eso es necesario monitorear las salidas del aplicativo, una vez
instalada la nueva versin en produccin.
El personal asignado al mantenimiento de software y el
usuario debern proveer pistas, acerca de dnde ellos creen que
podran ocurrir problemas. El tipo de indicios incluye:
Investigacin de transacciones.
Clientes.
Reportes.
Archivos.
Performance.
Estos indicios deben ser documentados mediante el uso de
un formulario.
H.3.4. Documentar los Problemas
Los problemas detectados durante el monitoreo de los
cambios, deben ser documentados. Adems se debe evaluar el
riesgo asociado a ese problema.
El reporte de un problema causado por un cambio en el
sistema, permite asociar tal problema a lo especfico del
cambio. Este reporte debe ser enviado al analista de
mantenimiento de software para su anlisis y posterior
correccin.
H.4. Salidas
Reporte de recuperacin ante fallas.
Reporte de historia de cambios al software.
Reporte de puestas en produccin.
Reporte de autorizacin de eliminacin de versiones
innecesarias.
Reporte de notificacin de monitoreo de cambios de
software.
Reporte de problemas causados por cambios de Software.
H.5. Lista de Verificacin (Checklist)
En la tabla XI se presenta la lista de verificacin.
H.6. Mtricas
Eficiencia en la

hasta instalacin
instalacin
Eficiencia en la

hasta instalacin
instalacin
la verificacin:

H.7. Involucrados
H.7.1. Equipo de Ingeniera
Grupo de mantenimiento de software.
Grupo de instalacin de software.
188
Grupo de operaciones.
H.7.2. Equipo de Aseguramiento de la Calidad del Software
TABLA XI.
#
LISTA DE VERIFICACIN DEL MDULO DE INSTALACIN

Respuesta
tem
SI
18
Cada cambio es revisado para cada impacto sobre el plan de

reinicio/recuperacin?
Si el cambio impacta a la recuperacin, es calculado nuevamente el
tiempo de no servicio?
Si el cambio impacta a la recuperacin, es estimado nuevamente el
riesgo del tiempo de no servicio?
Los cambios necesarios para el proceso de recuperacin son
documentados?
La notificacin de los cambios de la versin de produccin fueron
documentados?
Los cambios de los sistemas de aplicacin de control de cambio de
aplicacin son controlados por una numeracin?
Existen procedimientos para eliminar versiones antiguas de las
bibliotecas de objetos?
Existen solicitudes de eliminacin para que produccin sea autorizado
para eliminar programas?
Estn establecidos procedimientos para asegurar que la versin de los
programas sea pasada al ambiente de produccin en la fecha correcta?
Si esto afecta a procedimientos de operacin, Estn notificados los
operadores del da en que la nueva versin se pase a produccin?
Estn establecidos los procedimientos para monitorear los cambios de
los sistemas de aplicacin?
Las personas que monitorean reciben notificacin de que el sistema de
aplicacin fue cambiado?
Las personas que monitorean los cambios reciben indicios de las reas
consideradas impactadas por el probable problema?
Las personas que monitorean el cambio del sistema de aplicacin
reciben una gua de que acciones tomar si el problema ocurre?
Los problemas detectados, inmediatamente despus de que el cambio
del sistema ocurri, son documentados en un formulario especial para
poder vincularlos a un cambio en particular?
Se solicita, a las personas que documentan problemas, que documenten
el impacto a nivel organizacional que puede implicar el problema?
La informacin acerca de la instalacin de cambios de software es
recopilada y documentada?
El servicio de la direccin realiza revisiones y utiliza la retroalimentacin
de los datos?
19
El servicio de la direccin peridicamente revisa la efectividad de la

instalacin de cambios de software?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
NO
Comentarios
N/A

y/o Semi-senior.
I. Metodologa, Estndares y Procedimientos
I.1. Objetivo
La verificacin de productos, deber ajustarse a la
organizacin. Esto incluye ajustar el vocabulario y los trminos
utilizados en la verificacin para que sean los mismos que los
utilizados en la organizacin para describir los componentes
del sistema, documentos y productos.
I.2 Entradas
Metodologa de desarrollo de la organizacin.
Estndares de la organizacin.
Procedimientos de la organizacin.
Productos que ingresan a cada una de las fases definidas en el
presente modelo.
I.3 Proceso
I.3.1. Verificar el Cumplimiento de los Estndares de

Documentacin
La formalidad, extensin y nivel de detalle de la
documentacin a preparar dependern de las prcticas de la
organizacin y del tamao, complejidad y riesgo del proyecto.
Fig. 13. Proceso del mdulo de metodologa, estndares y procedimientos
Lo que es adecuado para un proyecto puede ser inadecuado

para otro. Para verificar la documentacin, se proceder a
comprobar si est completa, es adecuada y cumple con las
normas y estndares corporativos.
Esta tarea intenta evaluar el apego a los procedimientos y
estndares definidos por la metodologa de la organizacin,
evaluando los criterios as establecidos y determinando si el
nivel y el alcance de la documentacin cumplen con lo
requerido.
En el caso que la metodologa de la organizacin,
establezca pautadamente la documentacin necesaria para cada
tipo de proyecto segn su criticidad, se proceder a verificar si
la documentacin cumple con cada una de esas pautas.
I.3.2. Verificar la Integridad de la Documentacin
Para evaluar la integridad de la documentacin, se usarn
los criterios definidos al respecto, en la metodologa de la
organizacin. El equipo de aseguramiento de la calidad de
software deber determinar si cada documento cumple con
esos criterios. Si la documentacin no alcanza a cubrir un
criterio, deber identificarse la deficiencia y documentarse.
Otros criterios adicionales, que pueden ser utilizados para
evaluar la integridad de cada documento, son discutidos en el
captulo de Tcnicas y Herramientas, nombrndose a
continuacin cada uno de ellos:
Contenido de la documentacin.
Usuarios del documento.
Redundancia.
Flexibilidad.
Tamao del documento.
Combinacin de diferentes tipos de documentos.
Formato.
Secuencia de contenido.
Ttulos de secciones/prrafos.
Expansin de los prrafos.
Diagramas de flujo y tablas de decisin.
Formularios.
Es aconsejable llevar a cabo una o ms verificaciones de
adecuacin de la documentacin a los estndares de la
organizacin. Tales verificaciones requieren que una persona
capaz, no asociada al proyecto, haga una simulacin de cambio
al sistema basado en la documentacin actual y el
requerimiento de cambio (no deben cambiarse ni la
documentacin real ni los programas). Despus que la persona
haga el cambio, alguien familiarizado con el proyecto debe
evaluar si se ha hecho correctamente. Esta verificacin revelar
si:
La documentacin es entendible para las personas ajenas al
proyecto
Una persona ajena puede utilizar la documentacin para
hacer un cambio correctamente, y lo puede hacer de manera
eficiente y efectiva.
I.3.3. Verificar el grado de actualizacin de la
Documentacin
La documentacin que no est actualizada no ser til. Si
la metodologa de la organizacin ya establece algn mtodo
para verificar el grado de actualizacin de la documentacin,
dicho mtodo ser usado por el grupo de verificacin durante la
misma. Caso contrario, se propone que el equipo de
verificacin de la documentacin utilice cualesquiera de las
siguientes cuatro tcnicas de verificacin (que se detallarn se
detallan en el captulo de Tcnicas y Herramientas) para
validar la actualizacin de la documentacin:
Utilizar la documentacin existente para llevar a cabo un
cambio en la aplicacin
Comparar el cdigo fuente de los programas con la
documentacin
Verificar que la documentacin est vigente
Verificar la actualizacin de los documentos con el usuario
final
Las anteriores tcnicas podrn aplicarse sobre los
documentos completos o sobre partes de los mismos o sobre
una muestra de la documentacin del proyecto.
I.4. Salidas
Reporte de documentacin verificada
I.5 Lista de Verificacin (Checklist)
En la tabla XII se presenta la lista de verificacin.
I.6. Mtricas
Documentacin
vigente:
Revisin de
documentos:
Cantidad de documentacin
vigente no actualizada
Cantidad total de documentacin
vigente
Cantidad de documentos
revisados
Cantidad de documentos a
revisar
189
I.7. Involucrados
Verificar la efectividad del modelo de estimacin de costos.
I.7.1. Equipo de Ingeniera

Gerente de proyecto
Responsables de elaboracin de documentos
Grupo de Metodologa, Estndares y Procedimientos
A.1.1. Validar el Modelo de Estimacin

La organizacin necesita usar un modelo para realizar las
estimaciones. El objetivo de este punto es validar la sensatez
del modelo de estimacin. Esta verificacin deber desafiar el
modelo usando las siguientes 14 caractersticas deseables para
la estimacin de costos.
Estas caractersticas buscan determinar los puntos dbiles
del modelo:
El alcance del modelo debe estar bien definido.
El modelo debera ser ampliamente aplicado.
El modelo debe ser fcil de usar.
El modelo debe ser capaz de usar informacin actual, cuando
est disponible.
El modelo debe permitir el uso de datos histricos y
ajustarlos para una organizacin en particular y un tipo de
software.
El modelo debe ser verificado contra un nmero histrico
razonable de proyectos.
El modelo debe requerir slo entradas basadas en las
propiedades del proyecto, las cuales estn bien definidas y
pueden ser establecidas con un grado de certeza razonable al
momento en que la estimacin es llevada a cabo.
El modelo debe proveer entradas basadas en criterios
objetivos.
El modelo no debe ser hipersensible para criterios de entrada
subjetivos.
El modelo debe ser sensible a todos los parmetros del
proyecto que fueron establecidos teniendo un marcado efecto
en el costo y no debe requerir entrada de parmetros no
correlacionados con costos.
El modelo debe incluir estimaciones de cmo y cundo van a
ser necesarios los recursos.
El modelo debe producir un rango de valores por la cantidad
que ha sido estimada.
El modelo debe incluir la posibilidad de realizar anlisis de
sensibilidad, para que el responsable de la estimacin pueda
ver la variacin de los parmetros seleccionados.
El modelo debe incluir alguna estimacin del riesgo para
completar las estimaciones de tiempo o costo.
TABLA XII.
LISTA DE VERIFICACIN DEL MDULO DE METODOLOGA,

ESTNDARES Y PROCEDIMIENTOS
Respuesta
tem
SI
1
2
3
4
5
6
7
8
9
Comentarios
N/A
Existen estndares para la documentacin del sistema?

Los miembros del equipo de prueba estn informados sobre las
intenciones y contenidos de esos estndares?
Los estndares son adaptables a sistemas de varios tamaos, de
manera que el tamao del proyecto no sea directamente proporcional con
al tamao del documento?
Se les entreg al equipo de aseguramiento de la calidad una copia
completa de la documentacin del sistema correspondiente a esta
verificacin?
El equipo de aseguramiento de la Calidad ha medido las necesidades de
la documentacin de acuerdo a los criterios establecidos por la
metodologa de la organizacin?
El equipo de aseguramiento de la calidad ha determinado qu
documentos deben revisarse?
Las personas del proyecto estn de acuerdo con las sugerencias del
equipo de aseguramiento de la calidad en cuanto a las revisiones de la
documentacin?
El equipo de aseguramiento de la calidad determin la completitud de los
documentos usando los criterios detallados en la metodologa de la
organizacin?
El equipo de aseguramiento de la calidad ha utilizado el proceso de
Inspeccin para determinar la completitud de la documentacin del
sistema?
11
El equipo de Aseguramiento de la Calidad de Software ha determinado

el grado de actualizacin de la documentacin del proyecto?
El equipo de aseguramiento de la calidad ha desarrollado un documento
detallando las deficiencias de la documentacin respecto de los
estndares de la organizacin?
12
Se ha asegurado el equipo de aseguramiento de la calidad de que las

deficiencias descritas estn documentadas?
10
NO
I.7.2. Equipo de Aseguramiento de la Calidad del Software

y/o Semi-senior.
V. TCNICAS Y HERRAMIENTAS
En el presente captulo se presentan y describen
brevemente las principales Tcnicas y Herramientas
identificadas en los mdulos del modelo general de
aseguramiento de la calidad.
Tambin se presenta, slo a modo de ejemplo, un conjunto
de productos entregables que se obtienen al aplicar stas
tcnicas y herramientas. Lo que se pretende mostrar con estos
productos, son los datos que se deberan registrar, ms all del
formato, el soporte electrnico o detalles de implementacin.
A. Estimacin del Proyecto
A.1. Verificar la Validez de la Estimacin de los Costos de
Software
Una estimacin inapropiada de costos puede daar ms a la
calidad del Proyecto de Software que a cualquier otro factor,
por eso, la verificacin puede aumentar la validez de la
estimacin. La estimacin del software es un proceso de tres
partes como se describe a continuacin:
Validar el modelo de estimacin.
Validar que el modelo incluya todos los factores necesarios.
190
A.1.2. Validar que el Modelo Incluya Todos los Factores

Necesarios
Los factores que influencian al costo del proyecto de
software deben estar divididos en los que contribuyen en el
desarrollo y mantenimiento de la organizacin y en aquellos
inherentes al proyecto de software.
Es importante que los modelos sean usados correctamente y
que todos los factores que influencian los costos de software
sean imputados correctamente. Los modelos pueden producir
resultados incorrectos basados en esa influencia de factores. En
primer lugar el factor puede ser excluido del modelo como
resultado de una incorrecta estimacin. En segundo lugar se
puede introducir un factor incorrecto o incompleto al modelo,
causando estimaciones incorrectas de costos de software.
Si un factor no fue incluido, el analista de calidad debe
determinar dnde afecta el factor significativamente en el costo
actual de construir el software. A continuacin se describen los
factores influyentes en el costo del software:
Tamao del software.

Porcentaje de diseo y/o cdigo nuevo.
Complejidad del sistema de software.
Dificultad de diseo y codificacin.
Calidad.
Lenguajes a usar.
Clasificacin de nivel de seguridad del proyecto.
Tipo de mquina a utilizar (tecnologa).
Utilizacin de hardware.
Volatilidad del requerimiento
A continuacin se describen los factores influyentes, que
dependen de la organizacin:
Cronograma del proyecto.
Personal.
Ambiente de desarrollo.
Recursos no atribuibles directamente a aspectos tcnicos del
proyecto.
Recursos de computacin.
Honorarios.
Inflacin.
A.1.3. Verificar la Exactitud del Modelo de Estimacin de
Costos
Se proponen las siguientes cuatro verificaciones para
validar las estimaciones producidas por el modelo de
estimacin de costos de software:
1) Recalcular lo estimado: El analista de calidad puede
validar el proceso de estimacin ejecutando el modelo de
estimacin. El propsito de esto es:
Validar que los datos de entrada fueron ingresados
correctamente.
Validar que los datos de entrada fueron razonables.
Validar que la ecuacin matemtica fue calculada
correctamente.
2) Comparar estimaciones realizadas con proyectos
tpicos: El analista de calidad puede determinar cunto tiempo
lleva desarrollar proyectos del mismo tamao y complejidad.
El clculo realizado por el sistema de estimacin, es luego
comparado con costos actuales de proyectos tpicos. Si
existiera una diferencia el analista de calidad puede evaluar
ms en detalle, la validacin de la estimacin.
3) Razonabilidad de la estimacin: Esta verificacin es
similar a la del punto anterior, se utiliza la experiencia pasada.
El analista de calidad documenta los factores que influyen
sobre la estimacin de costos, documenta el clculo producido
por el sistema de estimacin y luego valida la razonabilidad de
esa estimacin teniendo en cuenta experiencias anteriores. Es
recomendable un mnimo de tres experiencias consultadas a los
Gerentes de proyecto. En caso en que uno o ms no sienta que
es razonable la estimacin, la misma deber ser rechazada.
4) Redundancia en estimaciones de costo de software: El
Analista de calidad debe recalcular la estimacin usando otro
modelo de estimacin de costo. Si la diferencia es pequea, la
estimacin ser confiable. Caso contrario se tendra que
realizar una investigacin adicional.
A continuacin, se detallan las fuentes de los modelos de
estimacin de software:
Desarrollos internos (propios) de la organizacin.
Modelos de estimacin incluidos en metodologas de

desarrollo de sistemas.
Paquetes de software para desarrollo de estimaciones de
software.
Uso de puntos de funcin para la estimacin de costos de
software
B. Estado del Proyecto: Sistema de Acumulacin de Puntos
La creciente complejidad de los sistemas, combinado con los
requerimientos para diseos estructurados y modulares, ha
aumentado la cantidad de elementos de software desarrollados
y entregados. El aumento de elementos, ms los tradicionales
hitos usados para medir el progreso han hecho subjetivo y a
menudo poco confiable el seguimiento del desarrollo del
software y la prediccin del consumo progresivo del tiempo.
Se ha utilizado exitosamente un sistema para seguir el
progreso del desarrollo de software a travs de un esquema de
puntos ganados. Los puntos estn asignados en cada paso en el
ciclo de desarrollo del software de la organizacin. Los pasos
son hitos en los cuales un producto generado es aceptado. Al
aceptar los productos se ganan los puntos que poseen
asociados. La proporcin de puntos ganados sobre el total de
puntos posibles se recopila y as se determina el progreso
logrado. Luego, se generan informes, tabulando la
informacin en una variedad de reportes gerenciales.
El sistema as implementado es flexible y altamente
automatizado. Los puntos acumulados son rpidamente
verificados, objetivos, y basados en el estado actual del
desarrollo del proyecto. Clculos simples o comparaciones de
los puntos acumulados proveen una medida precisa del
progreso, del desvo en el cronograma y la prediccin de
progresos futuros.
B.1. Cmo Utilizar el Sistema de Puntos
El sistema de acumulacin de puntos, propuesto por W. Perry
[5], es una extensin del sistema de "hitos". En su forma ms
simple se asume que cada tem o componente del software
pasa por procesos de desarrollo similares y hay una cantidad
de hitos claramente identificables dentro del proceso.
A modo de ilustracin, se desarrollarn 5 componentes y 4
hitos definirn el proceso de desarrollo. Los hitos pueden
representar diseos revisados y aceptados, cdigo revisado y
completo, resultados de prueba verificados, y componentes
liberados. En un caso simple, cada hito para cada tem de
software vale 1 punto. En este caso, pueden ganarse 20
puntos. Como parte de cada revisin de diseo, inspeccin de
cdigo, prueba de verificacin, o entrega, se cumple el hito y
se ganan los puntos correspondientes. Al poner en un archivo
una lista con los componentes e hitos logrados (puntos
ganados) y crear simples generadores de reportes, puede
adquirirse una medida objetiva, precisa y oportuna de los
resultados. En la tabla XIII se muestra cmo es un reporte
simple de estado.
Este esquema simplificado funciona bien para un conjunto
homogneo de componentes donde todos tienen similar
complejidad y cada hito representa una cantidad de trabajo
similar. A travs de la introduccin de "pesos" en los factores,
pueden manejarse fcilmente, los componentes de
complejidad diversa o los hitos que representan esfuerzos
dismiles para completarlos.
191
TABLA XIII. REPORTE SIMPLE DE ESTADO
hacer ambas estimaciones es proveer al Gerente del proyecto y

a la alta gerencia de mayor seguridad respecto de la validez de
los resultados del reporte de progreso.
REPORTE DEL ESTADO DEL SISTEMA

TEM
DISEO
CODIFICACIN
VERIFICACIN
ENTREGA
PUNTOS GANADOS
Componente A
Componente B
Componente C
Componente D
Componente E
TOTALES
3
2
PORCENTAJE 9/20 = 45= %
El motor del sistema es un archivo de datos y algunos reportes

simples. El archivo de datos es simplemente una coleccin de
registros, uno por cada tem que debe seguirse, que contiene
campos para indicar si se ha alcanzado algn hito. Usualmente
es ventajoso incluir campos para la descripcin de los tems,
analista responsable, identificacin del trabajo, entre otros.
El mantenimiento o actualizacin del archivo puede ser tan
efectivo como modificar registros con un editor de lnea o tan
complejo como crear un programa interactivo para ese
propsito. Deben usarse algunos medios de acceso limitado
para restringir modificaciones no autorizadas al archivo. Una
vez actualizado el mismo, para incluir una entrada de datos al
componente en desarrollo se actualizan los campos de estado
de los hitos a medida que se van alcanzando tales hitos. En
algunos casos, esto puede ser un proceso manual; una vez que
el evento ocurri y se alcanz el hito, una persona (autorizada)
actualiza el estado en el archivo. En otras circunstancias, en
sistemas ms sofisticados, un programa puede determinar que
ha ocurrido un hito (compilacin sin errores o prueba exitosa)
y automticamente actualiza el estado del hito.
Una vez armado el archivo, se escriben los programas
generadores de reportes para imprimir el estado. Para
proyectos menores, puede ser suficiente un programa que
simplemente imprime cada registro, suma los puntos ganados
y definidos, y calcula el porcentaje de puntos ganados. Los
proyectos ms grandes pueden necesitar varios reportes para
subsistemas diferentes o reportes resumen que enfaticen los
cambios ocurridos.
B.2. Utilizacin del Sistema de Puntos como Mtodo de
Prueba
El mtodo de puntos para seguir el progreso del software
puede ser utilizado por el Analista de calidad en alguna de las
tres formas siguientes:
B.2.1. Validar el Progreso Informado.
El uso del sistema de puntos por el equipo de aseguramiento
de la calidad, elabora una evaluacin del progreso que puede
compararse con los reportes de progreso del Gerente del
proyecto. Si el seguimiento del progreso es aproximadamente
el mismo utilizando los dos resultados, el examinador puede
validar el sentido de los reportes del proyecto producidos por
el equipo del proyecto. Esto es un anexo de lo que la prueba
normalmente hace, pero puede ser muy valiosa desde la
perspectiva de la alta gerencia. Ntese que si hay una
diferencia significativa en la estimacin del progreso del
proyecto, la diferencia puede estar en el sistema de puntos o
en el sistema que usa el Gerente del proyecto. El objetivo de
192
B.2.2. Planeamiento de la Prueba

El mtodo de puntos para el seguimiento del progreso indica
cundo ocurrir la prueba. Al tener un sistema que permita al
equipo de proyecto, seguir el progreso, puede asistirlo para
planificar el uso de los recursos de prueba. El sistema de
puntos no requiere muchos recursos; no obstante est
destinado a asistir al equipo de proyecto, indicndole cuando
los programas/subsistemas estarn disponibles para verificar.
B.2.3. Reportar el Estado de la Prueba
El sistema de puntos tambin indica cundo est hecha la
prueba y cuando se liberan los mdulos a produccin. La
informacin contenida en el sistema de puntos es la misma
que necesitar el equipo de proyecto para reportar los
resultados de la prueba.
C. Matriz de Riesgos
La matriz de riesgos es una herramienta diseada para
identificar y evaluar riesgos y determinar qu es lo que el
sistema debe hacer con cada uno de ellos.
A continuacin se describe como usar la matriz de riesgos. En
forma ideal la matriz de riesgos comienza en la fase de
requerimientos y se desarrolla y termina en la fase de diseo.
La implementacin de esta herramienta es un proceso de cinco
pasos. Los pasos deben ser ejecutados en la siguiente
secuencia:
C.1 Identificacin del Equipo de Evaluacin de Riesgos
La clave para el xito de la matriz de riesgos es establecer un
equipo evaluador de riesgos, cuya responsabilidad ser
completar la matriz. El objetivo de completar la matriz, es
llevar a cabo un control adecuado de requerimientos y diseo
para reducir los riesgos a un nivel mnimo aceptable.
El grupo de riesgo, puede ser parte del equipo que realiza la
toma de requerimientos o parte del grupo de test, o puede ser
un equipo seleccionado especficamente con el propsito de
confeccionar la matriz de riesgo. El grupo debera contar con
entre 3 y 6 miembros, y al menos poseer las siguientes
habilidades:
Conocimiento sobre el uso de la aplicacin.
Entender el concepto de riesgo.
Habilidad para identificar controles.
Estar familiarizado con ambos, riesgos de la aplicacin y de
los servicios de informacin.
Entender el concepto de servicio de informacin y sistema de
diseo.
Los candidatos en el grupo de riesgo debern al menos incluir
a alguien del rea usuaria, y alguno o todos de las siguientes
reas:
Auditor interno.
Consultor de riesgo.
Representante del rea de procesamiento de datos.
Representante del rea de seguridad.
Representante del rea de operaciones.
C.2. Identificacin de Riesgos
El primer objetivo del grupo evaluador de riesgos, es
identificar los riesgos enfocndose en la aplicacin, pero no en
los riesgos ambientales. El equipo evaluador de riesgo, puede

utilizar uno de los dos mtodos siguientes para la
identificacin del riesgo:
C.2.1. Anlisis de Escenarios de Riesgos
En este mtodo el equipo de riesgo delibera sobre los riegos
potenciales de la aplicacin usando sus experiencias, juicio y
conocimiento del rea de aplicacin. Es importante tener
sinergia, as los miembros del grupo pueden cuestionarse uno
a otro para desarrollar una lista completa de riesgos que son
compatibles a la aplicacin.
C.2.2. Lista de Verificacin de Riesgos
Se provee al equipo de riesgo de una lista con los riesgos ms
comunes que ocurren en aplicaciones automticas. El equipo
selecciona de la lista aquellos riesgos aplicables a la
aplicacin. En este mtodo, el equipo necesita pocas
habilidades porque la lista de riesgos provee el estmulo para
el proceso, y el objetivo del equipo es determinar cuales de los
riesgos de la lista son aplicables a la aplicacin. He aqu una
lista de riesgos para su identificacin:
Acceso no controlado al sistema.
Prcticas de seguridad no eficaces para la aplicacin.
Errores de procedimiento en los servicios de informacin:
Procedimientos y controles.
Manipulacin de medios de almacenamiento.
Errores del programa.
Defectos del sistema operativo.
Fallas en el Sistema de Comunicacin:
Fallas accidentales.
Actas accidentales.
C.3. Establecer Objetivos de Control
Durante la fase de requerimientos, deben establecerse los
objetivos de control para cada riesgo. Estos objetivos definen
el nivel de aceptacin del perjuicio de cada riesgo
identificado. Otra forma de manifestar el nivel de dao
aceptable, es el objetivo mensurable de control.
La adecuacin del control no puede chequearse hasta que no
est definido el nivel de perjuicio de cada riesgo. Por lo tanto,
mientras que la definicin de los objetivos de control es
responsabilidad del usuario y del proyecto, puede llevar a la
formacin de un grupo de riesgos para definirlos. Una vez
definidos los objetivos de control, se pueden chequear los
requerimientos para determinar si son factibles.
En la tabla XIV se muestra un ejemplo de matriz de riesgo al
final de la fase de requerimientos para un tpico sistema de
Facturacin y Distribucin. Esta matriz muestra cuatro riesgos
para el sistema de Facturacin y Distribucin, y objetivos de
control para cada uno de aquellos riesgos. Por ejemplo, uno de
los riesgos es que el producto sea enviado pero no facturado.
En esta instancia, el objetivo de control es asegurar que todos
los envos sean facturados. En otras palabras, el nivel de
perjuicio aceptable de este riesgo es cero, y el equipo del
proyecto debe instalar un sistema que asegure que para cada
envo que se despacha se prepara una factura. Sin embargo,
ntese que el siguiente riesgo es que el producto se facturar
con un precio o cantidad errnea y que los controles tienen
establecido un nivel de defecto mayor a cero, como los otros
dos riesgos.
C.4. Identificar Controles en Cada Sistema

Durante la fase de diseo, el equipo de riesgo identificar los
controles en cada fase del sistema de aplicacin para cada
riesgo identificado. Los segmentos de sistemas ms comunes
son:
Origen: La creacin del documento fuente ms la
autorizacin asociada con aquella transaccin original.
TABLA XIV. EJEMPLO DE MATRIZ DE RIESGO AL FINAL DE LA
FASE DE REQUERIMIENTOS
RIESGO
OBJETIVOS DE CONTROL
Despachado pero no facturado
Asegurar que todos los envos estn facturados
Facturado con precio o cantidad

errnea
Facturar al precio actual el 99% de los tems bsicos y error permitido

menor al 10%
Facturado al cliente equivocado
Reducir facturas perdidas a menos del 1%
Despacho del producto o cantidad

equivocada
Despachar los productos y cantidades correctas al 99% de los tems de

base
Ingreso de Datos: Transferencia de informacin a un medio

legible por la mquina.
Comunicacin: El movimiento de datos desde un punto del
sistema a otro. El movimiento puede ser manual o
electrnico.
Procesamiento: Aplicacin del sistema lgico a los datos.
Almacenamiento: La retencin de datos, por largos o cortos
perodos de tiempo.
Salida: La traduccin de la informacin de computadora a los
medios entendibles y utilizables.
Uso: Satisfaccin de la necesidad del negocio a travs de los
resultados del sistema de procesamiento.
El equipo de evaluacin de riesgos, determinar qu controles
son aplicables a qu riesgos y los registrar en el segmento
correcto del sistema. Al trmino del desarrollo de la matriz de
riesgo, el equipo de riesgo har una estimacin para verificar
si los controles son los adecuados para reducir el riesgo hasta
el nivel de aceptacin identificado en el objetivo de control.
Esto verificar la efectividad de los controles al finalizar el
proceso de diseo. En la tabla XV se muestra un ejemplo de
matriz de riesgo para sistemas de facturacin y distribucin al
final de la fase de diseo.
Los mismos cuatro riesgos identificados durante la fase de
Requerimientos (tabla XIV) tambin se muestran en esta
matriz, por lo que los controles estn asociados a cada riesgo.
En este ejemplo, el riesgo de despachar sin facturar muestra
que los controles 1, 2 y 3 ayudarn a disminuir ese riesgo
(para una matriz real estos controles deben describirse). La
matriz muestra en qu segmento del sistema de aplicacin
residen aquellos controles.
Despus de identificar y registrar los controles, el equipo de
riesgo debe determinar si aquellos tres controles y los
segmentos a los cuales pertenecen son los adecuados para
reducir el riesgo de despachar sin facturar.
C.5. Determinar si los Controles son adecuados
La verificacin termina cuando el equipo de riesgo determina
si los controles son los adecuados para reducir cada uno de los
riesgos identificados al nivel aceptable.
193
TABLA XV. EJEMPLO DE MATRIZ DE RIESGO AL FINAL DE LA

FASE DE DISEO
RIESGO DEL SEGMENTO
DEL SISTEMA
Despacho sin facturacin
ORIGEN
INGRESO
DATOS
#1
Facturado con precio o

calidad errnea
#6
#17
PROCES.
ALMAC.
SALIDA
#2
Facturado al cliente
equivocado
Despacho de producto o
cantidad errnea
COMUNIC.
#18
USO
#6
#7
#8
#9
#10
#11
#12
#3
#14
#15
#16
#21
#22
#19
#20
D. Anlisis de Factores (Mdulo de Requerimientos)

Se llevar a cabo un proceso para estimar las incumbencias
asociadas a la fase de requerimientos del desarrollo del
sistema. Debe incluirse un programa de verificacin para cada
tem. Hay 15 tems a considerar, cubriendo cada fase del
proceso de desarrollo. Para cada tem hay un programa de
verificacin que tiene en cuenta ciertas consideraciones las
cuales se encuentran detalladas ms abajo. El programa de
verificacin enumera aquellos criterios, que aseguran al
equipo de aseguramiento de la calidad, que la magnitud de esa
preocupacin es mnima. A estos criterios debe responder el
equipo de aseguramiento de la calidad. Tambin se debe
realizar una verificacin suficiente para evaluar si el equipo de
proyecto ha manejado adecuadamente cada factor de
verificacin.
A continuacin, se detallarn brevemente cada uno de los
factores a tener en cuenta:
D.1. Requerimientos Compatibles con la Metodologa
(Factor: Metodologa)
El procedimiento utilizado para definir y documentar
requerimientos, debe estar presente durante la fase de
requerimientos. Cuanto ms formales sean estos
procedimientos, se facilita el proceso de su verificacin. El
proceso de requerimientos es un proceso de, anlisis, toma de
decisiones y registro de requerimientos en una forma
predefinida para poder utilizarse luego en el diseo.
D.2. Funcionalidad de las Especificaciones (Factor:
Precisin)
La satisfaccin del usuario solo puede asegurarse, cuando se
han cumplido los objetivos del sistema. El cumplimiento de
estos objetivos solo pueden medirse cuando stos sean
mensurables. Por ejemplo, los objetivos cualitativos, como la
mejora de servicio, no son mensurables, mientras que s lo es
el pedido de procesamiento en cuatro horas de usuario.
especificaciones determinarn los mtodos de mantenimiento

(Ej.: cambio de parmetros introducido por el usuario) y el
intervalo de tiempo en el cual se necesitan implementar dichos
cambios.
D.5. Necesidades de Portabilidad (Factor: Portabilidad)
La capacidad para operar el sistema en diferentes tipos de
hardware, o migrarlo a otra versin, deber enunciarse como
parte del requerimiento. La necesidad de tener la aplicacin
desarrollada como portable, puede afectar significativamente
la implementacin de requerimientos.
D.6. Interfaces del Sistema (Factor: Acoplamiento)
Se debe definir en forma precisa, la informacin esperada
como entrada desde otros sistemas computadorizados y las
salidas a entregar a otros sistemas. Esta definicin no solo
incluye los tipos de informacin intercambiada, sino tambin,
el momento en el cual debe estar disponible cada interfaz y el
procesamiento que se espera como resultado de cada una de
ellas. Otros factores a tener en cuenta al definir las interfaces
son: privacidad, seguridad y resguardo de la informacin.
D.7. Criterios de Performance (Factor: Performance)
Debe quedar establecido: la eficacia, economa y eficiencia
esperadas del sistema. Estos objetivos son una parte integral
del proceso de diseo. Cuando no son alcanzados, la
insatisfaccin del usuario est garantizada. Como producto
final de la fase de requerimientos, se realizar el anlisis del
costo-beneficio del factor performance, calculado para la
aplicacin.
D.8. Necesidades operativas (Factor: Facilidad de
Operacin)
Las consideraciones operativas deben definirse durante la fase
de requerimientos. Esto es especialmente importante en
sistemas de aplicacin manejados por el usuario. Los procesos
a seguir para operar el sistema, en otras palabras, los
procedimientos necesarios para procesar transacciones, deben
ser lo ms simple posible. Tambin deben considerarse
procedimientos de operacin por excepcin y monitoreo
centralizado.
D.3. Usabilidad de las Especificaciones (Factor: Facilidad de

Uso)
La cantidad de esfuerzo requerido para usar el sistema y la
habilidad necesaria, deben definirse durante la fase de
requerimientos. La experiencia muestra que las aplicaciones
difciles de usar finalmente no se utilizan, en cambio los
sistemas funcionales fciles de usar son altamente utilizados.
Entonces los desarrolladores, debern crear especificaciones
fciles de usar, incrementando as la facilidad del uso del
sistema en s mismo.
D.9. Tolerancia (Factor: Fiabilidad)

Debe definirse la confiabilidad esperada de los controles del
sistema. Por ejemplo, la fase de requerimientos determinar
los requerimientos de control para la precisin de la
facturacin, el porcentaje de rdenes que necesitan procesarse
dentro de las 24 horas, etc.
La tolerancia de facturacin puede afirmar que se procesarn
las facturas con tolerancia 1% de los precios de los
productos actuales.
Si no se establecen estas tolerancias, no hay base para asignar
y medir la confiabilidad del sistema por perodo de tiempo. Si
no se define el nivel de defectos esperados, normalmente se
espera cero defectos. Los controles para lograr cero defectos
son antieconmicos.
Usualmente es ms econmico, que surja una cantidad mnima
de defectos en el proceso pero que sean detectados y
mensurables.
D.4. Mantenimiento de las Especificaciones (Factor:

Mantenibilidad)
Debe definirse el grado de mantenimiento esperado, as como
tambin las reas donde los cambios son muy probables. Las
D.10. Reglas de Autorizacin Definidas (Factor:

Autorizacin)
Deben especificarse los mtodos de autorizacin (niveles de
seguridad) para asegurar que las transacciones se procesen de
194
acuerdo con la intencin que tiene la organizacin, respecto

del sistema.
D.11. Requerimientos de Integridad de Archivos (Factor:
Integridad de Archivos)
Se necesita especificar los mtodos para asegurar la integridad
de los archivos. Esto normalmente incluye el conjunto de
controles que deben mantenerse dentro del archivo e
independientemente de la aplicacin. Los controles deben
asegurar que los registros de detalle sean consistentes con los
totales de control para cada archivo.
D.12. Recuperacin ante Fallas (Factor: Auditoria)
La recuperacin abarca los procedimientos de recomposicin
ante la identificacin de un problema. Se debe definir para
cada aplicacin, las necesidades de recomposicin de procesos
e informacin. Si la recomposicin es necesaria, se necesita
enunciar el momento para su ejecucin. Este momento, puede
variar segn la hora del da y el da de la semana.
Estos requerimientos de recomposicin afectan el tipo y
disponibilidad de los datos.
D.13. Impacto de Fallas (Factor: Continuidad de
Procesamiento)
La necesidad para asegurar la continuidad de procesamiento
depende del impacto de las fallas. Si la falla causa solo
problemas mnimos, puede ser innecesario asegurarse el
procesamiento continuo. Por el contrario, cuando la
continuidad de la operacin es esencial, es necesario duplicar
los equipos y centros de cmputos, para que se pueda
continuar procesando.
D.14. Nivel de Servicio Deseado (Factor: Nivel de Servicio)
El nivel de servicio implica tiempo de respuesta basado en los
requerimientos. El nivel de servicio requerido variar sobre la
base de los requerimientos. Cada nivel de servicio deseado
necesita estar enunciado; por ejemplo, hay un nivel de servicio
para corregir un error de programacin, otro para instalar un
cambio y otro para responder a una consulta, etc.
D.15. Permisos y Accesos (Factor: Seguridad)
Los requerimientos de seguridad deben desarrollarse
mostrando la relacin entre recursos de sistema y humanos.
Los requerimientos deben enunciar todos los recursos del
sistema disponibles sujetos a control, y luego indicar quin
debe tener acceso a aquellos recursos y con qu propsitos. Al
final del mdulo, el equipo de aseguramiento de la calidad,
puede emitir juicio acerca de la adecuacin de cada criterio. El
equipo debe emitir uno de los siguientes cuatro juicios acerca
de cada criterio:
Muy adecuado: El equipo de proyecto ha hecho ms de lo
normalmente esperado para el criterio.
Evaluacin adecuada: El equipo de proyecto ha hecho el
trabajo suficiente para asegurar el control por encima del
criterio.
Evaluacin inadecuada: El equipo de proyecto no ha hecho el
trabajo suficiente, y deben trabajar ms en este criterio.
No aplicable (N/A): Debido al tipo de aplicacin o diseo
filosfico del sistema por parte de la organizacin, la
implementacin de este criterio no es aplicable al sistema que
se est revisando.
E. Inspecciones
Las inspecciones y las recorridas walkthrough apuntan a
asistir a los productores para mejorar su trabajo.
Las inspecciones intentan examinar tcnicamente el trabajo y
proveer a los productores, una evaluacin independiente de
aquellas reas productivas en donde las mejoras son
necesarias. Las recorridas son generalmente menos formales y
estn conducidos en un formato ms educacional. Las
inspecciones, por el contrario, generalmente tienen un formato
formal, la asistencia es especfica, y la informacin se refleja
en los resultados.
Hay tantos tipos de inspecciones como tipos de productos. Es
de mucha ayuda inspeccionar los requerimientos antes de
comenzar el diseo de alto nivel, el diseo de alto nivel antes
de comenzar el diseo detallado, el diseo detallado antes de
comenzar la implementacin, y la implementacin antes de
comenzar la verificacin. Esto no significa que todos los
diseos de alto nivel deben ser inspeccionados antes del
comienzo de cualquier diseo detallado, pero el diseo
especfico a realizar debe basarse en el trabajo que ha sido
inspeccionado. Tambin es de ayuda inspeccionar los casos
verificados y la documentacin.
Se recomiendan las inspecciones para diseo, codificacin,
casos de prueba, y documentacin. Caso contrario, es
adecuado un proceso de recorrida menos formal.
E.1. Proceso
El proceso de inspeccin sigue ciertos principios bsicos:
La inspeccin es un proceso formal, estructurado a travs de
un sistema de listas de verificacin (checklists) y roles
definidos para los participantes. Provee un instrumento
ordenado para implementar un estndar de excelencia de
ingeniera del software o de conocimiento en toda la
organizacin.
Los estndares y listas de verificacin genricas son
desarrollados para cada tipo de inspeccin y, cuando sea
apropiado, se ajustan a las necesidades de un proyecto
especfico. Estas listas cubren el planeamiento de la
inspeccin, la preparacin, la conduccin, la salida y reportes
de normas.
Los inspectores estn preparados de antemano y tienen
identificados sus tareas y cuestiones antes de que comiencen
la inspeccin.
El foco de la inspeccin estar en identificar problemas, no
en resolverlos. Este foco, junto a lo mencionado en el punto
anterior, asegura que la inspeccin pueda manejarse con una
mnima prdida de tiempo.
Una inspeccin es conducida por tcnicos para tcnicos. Los
directivos no se involucrarn, aunque sern informados de los
hallazgos y las fechas en las cuales se resolvern los
problemas identificados.
La informacin de la inspeccin deber ser ingresada a una
base de datos y se la utilizar para monitorear la efectividad
de la inspeccin, seguimiento y conduccin de la calidad del
producto.
Mientras mucha gente pueda estar interesada en los resultados
de la inspeccin, el propsito de la inspeccin es asistir a los
productores para mejorar su trabajo. Esto puede hacerse mejor
limitndose a cinco o seis los inspectores. El punto clave de
esta limitacin es la atencin tcnica.
195
El moderador no es el director del trabajo que se est

inspeccionando, ni tampoco ninguno de los otros
participantes. Los moderadores necesitan una base completa
de los principios y mtodos de inspeccin antes de que puedan
hacer un trabajo competente. Esto les dar las herramientas
bsicas y los ayudar a tener mayor confianza en s mismos,
necesaria para liderar tal actividad.
Como las inspecciones bien realizadas requieren de una
intensa concentracin de todos los participantes, stos pueden
quedar exhaustos. Por esto, las sesiones de inspeccin
generalmente no deben exceder las dos horas.
Tambin es de gran ayuda asignar algunos inspectores en
reas productivas especficas durante el proyecto.
E.2. Participantes
Los participantes de la inspeccin, se detallan a continuacin:
El moderador (lder de inspeccin): Persona responsable para
liderar la inspeccin pronta y eficientemente a una conclusin
satisfactoria.
Los productores: Persona/s responsable/s de hacer que se
inspeccione el trabajo.
Los examinadores (inspectores): Generalmente es la gente
directamente involucrada y conocedora del trabajo que est
siendo inspeccionado.
El registrador (quien anota): Alguien que registra los
resultados significativos de la inspeccin.
E.3. Salidas
Las salidas a obtener luego de realizarse una inspeccin, se
detallan a continuacin:
Informe de Inspeccin (Figura 14)
Resumen de la Inspeccin (Figura 15)
Fig. 15.
Resumen de la inspeccin
Muestreo: Los atributos que se utilizarn correspondern a

una muestra de todos los atributos abarcados en la
implementacin de un sistema.
Alta correlacin positiva. Los atributos elegidos tendrn que
mostrar una alta correlacin positiva en el pasado con
cualquier xito o fracaso durante la automatizacin de una
aplicacin. Estos atributos no deberan ser intuitivos sino, que
debern ser atributos para los cuales pueda demostrarse que
la ausencia o presencia de los mismos muestre una alta
correlacin con respecto al resultado final del proyecto.
Facilidad de uso. Para ser efectivo, el proceso de ranking
debe ser lo ms simple posible.
Desarrollar el ranking de riesgo. El ranking para cada atributo
debe determinarse en un formato mensurable de modo que el
ranking de riesgo total pueda ser desarrollado para cada
aplicacin. Esto indicara el grado de riesgo, el rea de riesgo,
y tambin una comparacin de riesgos entre las diferentes
aplicaciones.
Al ranking de riesgo se llega a travs de un desarrollo
matemtico, como se muestra a continuacin.
TABLA XVI. DESARROLLO MATEMTICO PARA OBTENER UN
RANKING DE RIESGO
RIESGO DE LA
CARACTERSTICA
Fig. 14.
Informe de inspeccin
# DE CARACTERSTICAS
EVALUADAS
FACTOR DE
MULTIPLICACIN
FACTOR PARA
EL RANKING
Alta
Media
18
Baja
12
12
Total
F. Ranking de Factores de xito (Mdulo de Diseo)

El ranking (scoring) es una herramienta predictiva que
utiliza experiencias en sistemas anteriores. Se analizan los
sistemas existentes para determinar los atributos o
caractersticas de los mismos y su correlacin con el xito o el
fracaso de cada aplicacin en particular. Una vez que los
atributos correlacionados al xito o al fracaso pueden ser
identificados, tambin pueden ser usados para predecir el
comportamiento del sistema que est en desarrollo.
Los lineamientos que se utilizan bajo el concepto de ranking,
se describen a continuacin:
196
39
Para usar esta tabla, el nmero de atributos o caractersticas

calificadas con alto, medio y bajo, deber ser totalizado, y los
totales colocados en la columna # (cantidad) de
Caractersticas Evaluadas.
Luego a cada nmero se lo multiplica por el factor de
multiplicacin y as obtener el ranking de riesgo. Por ejemplo,
el nmero total de caractersticas definidas con alto riesgo
debe multiplicarse por tres. Luego los tres nmeros se suman
para llegar a totalizar el riesgo total, el cual puede utilizarse
para comparar entre los diferentes sistemas, o bien, respecto
de un estndar definido por la organizacin. cuanto ms alto
es el puntaje, mayor ser el riesgo, y a menor puntaje menor
riesgo.
G. Anlisis de Factores (Mdulo de Diseo)

Los factores que deben analizarse durante el mdulo de diseo
G.1. Controles de Integridad de Datos
La integridad de datos va desde la identificacin de riesgos,
hasta la decisin gerencial de aceptar esos riesgos, establecida
en trminos de la cantidad de prdidas aceptables. Los
controles de integridad de datos se disean a partir de la
tolerancia a tales riesgos, los cuales se encuentran
especificados.
G.2. Reglas de Autorizacin
Las autorizaciones en los sistemas pueden ser manuales y/o
automticas. Los procedimientos para autorizacin manual
deben especificarse durante la fase de diseo. Los mtodos de
autorizacin
automtica
deben
especificarse
ms
detalladamente que los manuales, por el hecho de que no se
pueden dejar librados a criterios personales segn la situacin
que se presente.
G.3. Controles de Integridad de Archivos
La integridad de los archivos estar asegurada por los mtodos
de identificacin de archivos, controles automticos y
controles
de
integridad
de
archivos
mantenidos
independientemente. Las especificaciones para este proceso
integrador de tres partes debe determinarse durante la fase de
diseo.
G.4. Pistas de Auditoria
Estas pistas proveen la capacidad para rastrear transacciones
desde su origen hasta los controles. Adems, las pistas de
auditoria se usan para consolidar el procesamiento de
transacciones individuales y recuperar la integridad de
operaciones luego de su prdida.
Frecuentemente los entes gubernamentales especifican las
pistas de auditoria que necesitan retener para cada tipo de
informacin que manipulan. Estas necesidades de
informacin, deben definirse durante la fase de diseo.
G.5. Plan de Contingencias
El plan de contingencias esquematiza las acciones a tomar
ante la aparicin de problemas.
Este plan deber incluir los mtodos manuales a seguir cuando
las aplicaciones automatizadas no estuvieran en operacin, as
como tambin, las consideraciones de lugar fsico. Las
especificaciones del plan de contingencia deben llevarse a
cabo durante la fase de diseo.
G.6. Mtodo para Alcanzar el Nivel de Servicio Requerido
La fase de requerimientos define el nivel de servicio a obtener
durante la operacin de la aplicacin. El mtodo para alcanzar
ese nivel de servicio es desarrollado durante la fase de diseo.
Esto involucra el desempeo del sistema y su habilidad para
satisfacer las necesidades de los usuarios a lo largo del tiempo.
G.7. Procedimientos de Acceso
La seguridad en los sistemas automatizados es llevada a cabo
predefiniendo quin puede tener acceso a qu recursos y para
hacer qu. Esto estar indicado por los perfiles de seguridad
definidos. Durante la fase de diseo, debern desarrollarse los
procedimientos, las herramientas y las tcnicas necesarias para
crear e implementar los perfiles de seguridad necesarios.
G.8. Diseo Acorde con la Metodologa

El proceso de diseo de sistemas debe ejecutarse y
documentarse de acuerdo con la metodologa establecida por
la organizacin. Los procedimientos estndares de diseo
aseguran la facilidad de comprensin por todos los miembros
del equipo capacitados y entrenados en esa metodologa y al
mismo tiempo ayuda a asegurar que se cumpla en forma
completa el proceso de diseo.
G.9. Diseo Acorde con los Requerimientos
El diseo del sistema es una transformacin de los
requerimientos de los usuarios en especificaciones ms
detalladas. Durante cualquier transformacin, pueden ocurrir
malos entendidos o malas interpretaciones. Entonces, deben
tomarse las medidas necesarias para asegurar que el diseo
cumpla sus objetivos y est focalizado a cumplir con los
requerimientos definidos.
G.10. Facilidad de Uso
Cuanto el producto final sea ms fcil de usar, habr mayor
probabilidad que el usuario lo utilice y que las transacciones
sean procesadas correctamente. Deben considerarse las
habilidades necesarias para cada puesto de trabajo y la
motivacin en el mismo, de todas las personas usuarias del
sistema.
G.11. Mantenibilidad del Diseo
El costo de mantener una aplicacin normalmente excede el
costo de desarrollo. Identificar aquellos aspectos del sistema
que son los ms factibles de cambiar y construir aquellas
partes del sistema para facilidad del mantenimiento es un
aspecto importante del proceso de diseo. La mantenibilidad
del diseo puede cambiar significativamente dependiendo de
la frecuencia esperada de los cambios introducidos.
G.12. Portabilidad del Diseo
Si los requerimientos indican que el sistema debe poder ser
transferido desde un ambiente de hardware a otro, o una
versin de software de base a otra, el diseo debe tener en
cuenta e incorporar estos aspectos de portabilidad. Cuando el
hardware y software futuros son inciertos, el diseo debe ser
lo ms general posible y no intentar sacar ventaja de los
aspectos o facilidades que brindan el hardware y software
existentes.
G.13. Interfaces de Diseo
Deben ser identificadas y especificadas y documentadas las
interfaces con otras aplicaciones. Las especificaciones de las
interfaces deben tambin considerar usos alternativos de la
informacin de la aplicacin.
G.14. Diseo Acorde con Criterios Establecidos
El estudio de costo/beneficio realizado durante la fase de
requerimientos no provee una estimacin de gran precisin.
La estimacin de la fase de requerimientos puede estar
afectada en ms o menos el 50%. Durante la fase de diseo, la
estimacin del desempeo puede ser definida mejor por lo que
se puede hacer una mejor prediccin y as lograr el
cumplimiento del criterio de desempeo establecido. Una gua
til a ser utilizada, es que la precisin de la estimacin del
criterio de desempeo al final de la fase de diseo puede
variar en 10%.
197
G.15. Necesidades Operacionales

El sector de operaciones deber identificar los requerimientos
de procesamientos futuros para preparar el manejo de tales
requerimientos cuando el sistema se implemente. Cuanto ms
grandes sean los requerimientos de procesamiento, mayor ser
la necesidad de involucrar al sector de operaciones en la
consideracin de las alternativas de diseo.
H. Revisin del Diseo
El objetivo es identificar aquellos atributos del diseo que se
correlacionan con los problemas del sistema. Entonces durante
la revisin de diseo, se investigarn dichos atributos para
determinar si el equipo de proyecto los ha tratado
apropiadamente.
El equipo de revisin de diseo comprende los siguientes
miembros:
Personal del proyecto: El personal del proyecto puede
conducir su propia revisin del diseo. Normalmente la
persona asignada con la responsabilidad de la revisin del
proyecto no es la misma que realmente dise el sistema; sin
embargo el que revisa puede tener responsabilidad parcial en
el diseo. Esto requiere que las personas durante el proceso
de revisin acepten roles y responsabilidades diferentes a los
que han tenido en el proceso de diseo. Debido a probables
vnculos con el diseo real del sistema, tener una lista de
verificacin de revisin de diseo como herramienta
evaluadora, normalmente cumple una valiosa funcin para
el/los que revisan.
Equipo de revisin independiente: Los miembros de este
equipo de revisin no son miembros del proyecto que est
siendo revisado. Pueden ser de otros proyectos o del equipo
de aseguramiento de la calidad. Esta manera de operar provee
un mayor grado de independencia para conducir la revisin
ya que no habr conflicto de intereses entre los roles de
diseador y del que revisa. Por otro lado es frecuentemente
difcil para los inspectores ser crticos unos con otros,
especialmente en situaciones donde el que revisa pueda
eventualmente trabajar para la persona que est siendo
revisada.
La siguiente es una gua en la conduccin de una revisin de
diseo:
Seleccionar el equipo de revisin: Los miembros del equipo
de revisin deben seleccionarse antes del proceso de revisin
propiamente dicho.
Entrenar los miembros del equipo de revisin: Las personas
que conducirn la revisin deben estar entrenadas sobre cmo
dirigir la revisin. Mnimamente significa revisar el checklist
y explicar el objetivo e intencin de cada asunto. Tambin es
aconsejable entrenar a las personas involucradas en
relaciones interpersonales y as realizar la revisin en un
ambiente armonioso.
Notificar al equipo del proyecto: El equipo del proyecto debe
estar notificado de la revisin con varios das de antelacin
cuando comienza la revisin y su responsabilidad durante la
misma. Es importante organizar formalmente la revisin para
que estn todos presentes.
Asignar tiempos adecuados: La revisin debe conducirse
formalmente y tan eficientemente como sea posible. An
cuando la misma gente que dise la revisin, la dirija, las
relaciones interpersonales y los efectos de la sinergia de la
revisin pueden producir muchos efectos positivos si se
198
asigna el tiempo suficiente para permitir una interaccin

apropiada.
Documentar los datos de la revisin: Deben registrarse todos
los hallazgos realizados en la revisin. Normalmente esto
puede llevarse a cabo en el checklist, a menos que los
comentarios sean muy extensos. En cualquier caso, los datos
deben hacer referencia a preguntas especficas del checklist
que cubran.
Revisar los datos con el equipo de proyecto: La precisin de
los datos debe ser comprobada por todas las personas
involucradas, y la revisin no debe continuar si esto no est
hecho. Es mejor hacerlo al final de la revisin que durante el
proceso mismo.
Desarrollar recomendaciones de revisin: Basndose en los
datos, el equipo de revisin har sus recomendaciones para
corregir cualquier situacin de conflicto. Estas
recomendaciones son parte importante del proceso de
revisin.
Revisar recomendaciones con el equipo de proyecto: El
equipo de proyecto debe ser el primero en recibir las
recomendaciones y tener la oportunidad de aceptar, modificar
o rechazar las recomendaciones.
Preparar un reporte: Se debe preparar un reporte para
documentar los hallazgos, y las acciones tomadas o a tomar
acerca de las recomendaciones. Este reporte puede o no
enviarse a altos niveles gerenciales, dependiendo de las
reglas establecidas en la revisin por la organizacin. Sin
embargo es importante tener un registro formal del proceso
de revisin, qu se encontr y las acciones tomadas respecto
de las recomendaciones.
La cantidad de revisiones depender de la importancia del
proyecto y del lapso de tiempo en la fase de diseo. As
podrn llevarse a cabo revisiones del diseo de alto nivel y del
diseo detallado.
H.1. Revisin del Diseo de Alto Nivel
Cada defecto descubierto durante la revisin del diseo lgico
o de alto nivel debe documentarse. Se confecciona un reporte
de defectos para llevar registro de los mismos, incluyendo tipo
y categora de los defectos. La descripcin de cada defecto se
registra bajo una columna de Faltante, Errneo o Adicional.
Al final de la revisin del diseo lgico, los defectos se
resumen y totalizan. En la figura 16 se muestra un formulario
de registro de defectos en la fase de diseo de alto nivel:
Fig. 16.
Formulario de registro de defectos en la fase de diseo

de alto nivel
H.2. Revisin del Diseo Detallado

Cada defecto descubierto durante la revisin del diseo fsico
o detallado debe documentarse. Se confecciona un reporte de
defectos para llevar registro de los mismos, incluyendo tipo y
categora de los defectos. La descripcin de cada defecto se
registra bajo una columna de Faltante, Errneo o Adicional.
Al final de la revisin del diseo fsico, los defectos se
resumen y totalizan. En la figura 17 se muestra un formulario
de registro de defectos en la fase de diseo detallado:
Fig. 17.
Formulario de registro de defectos en la fase de diseo

detallado
I. Depuracin de Programas
La depuracin (debugging) permite al programador evaluar
la integridad y precisin del programa previo a la conduccin
de revisiones y verificaciones menos econmicas. La
depuracin, incluye el diseo detallado y la codificacin.
Esta operacin puede ser tan extensa o tan reducida como se
quiera. La cantidad de depuraciones a realizar depender de:
El tiempo de espera hasta que se reciba el siguiente
programa.
Cronograma de implementacin.
Recursos de prueba
Eficiencia de herramientas de test.
Polticas del rea.
La depuracin puede ser sintctica, estructural, o funcional.
I.1. Depuracin Sintctica
Las especificaciones y expresiones del programa deben
desarrollarse de acuerdo con la metodologa definida por la
organizacin y los requerimientos recopilados. El
programador puede chequear las expresiones y sintaxis para
asegurarse que ha escrito el programa de acuerdo con las
reglas establecidas. Al chequear la sintaxis se hacen preguntas
como:
La funcin a realizar, est claramente identificada?
Las sentencias del programa estn identificadas
correctamente?
Las sentencias del programa estn construidas utilizando la
estructura apropiada?
Los elementos de datos estn apropiadamente identificados?
Las estructuras de datos son las adecuadas para colocar los

valores que sern utilizados en dichas estructuras?
I.2. Depuracin Estructural
Los problemas de estructura crean un significante nmero de
defectos en la mayora de las aplicaciones. Estos defectos
ocultan defectos funcionales por lo que su deteccin se torna
difcil. Las preguntas tpicas durante la depuracin estructural
son:
Se colocaron todas las sentencias necesarias?
Se utilizan todas las definiciones de datos en las sentencias
definidas?
Se utilizan todos los elementos de datos definidos?
Las tablas internas y valores lmite estn usados de manera
que cuando se excede el lmite se puede continuar
procesando?
5.9.3 Depuracin Funcional
Las funciones son los requerimientos que el programa
ejecutar. Las preguntas cuando se depura la funcionalidad
son:
El programa ejecutar la funcin especfica en la forma
indicada?
Algunas de las funciones son mutuamente excluyentes?
El sistema detectar datos incorrectos o ilgicos?
Se acumular apropiadamente la informacin entre
diferentes ejecuciones del programa?
J. Anlisis de Factores (Mdulo de Codificacin)
La profundidad de la verificacin en el mdulo de
codificacin, depende de cmo se adecua el sistema a las
necesidades del usuario, al final del mdulo de diseo. A
mayor confianza del equipo de verificacin en la adecuacin
de la aplicacin al final del mdulo de diseo, tendrn menos
inquietudes durante el mdulo de codificacin.
En el mdulo de codificacin, el equipo de aseguramiento de
la calidad debe identificar las inquietudes que sean de mayor
inters, y luego desarrollar el proceso de verificacin para
hacer frente a dichas inquietudes. Al identificarlas, el equipo
de aseguramiento de la calidad, debe tener en cuenta los
cambios que han ocurrido en las especificaciones del sistema
desde que se produjo la ltima verificacin. Los objetivos que
los miembros del equipo de aseguramiento de la calidad deben
considerar en el mdulo de codificacin, son:
Los sistemas son mantenibles?
Se han implementado correctamente las especificaciones del
sistema?
Los programas son compatibles con los estndares y
procedimientos?
Existe un plan de verificacin capaz de evaluar los
ejecutables?
Los programas estn adecuadamente documentados?
Las inquietudes (concerns) a considerar durante esta tarea
Implementacin del control de integridad de informacin: Es
necesario tener implementados controles especficos de
manera de lograr la precisin en el procesamiento deseado.
Los controles implementados en forma impropia, no
alcanzarn el nivel de tolerancia aceptado, y por la mala
comprensin del propsito de los controles, sern
implementadas soluciones simplistas cuando en realidad se
199
requieren controles complejos para alcanzar los objetivos de

control establecidos previamente.
Implementacin de reglas de autorizacin: Es necesario
verificar la implementacin de reglas de autorizacin de
manera de dificultar su evasin. Adems, las reglas de
autorizacin no deben slo considerar la ejecucin de las
reglas si no tambin tener en cuenta los mtodos ms
comunes de evadirlas.
Implementacin de controles de integridad de archivos: Los
controles de integridad de archivos deben implementarse de
manera que minimicen la probabilidad de prdida la
integridad, debiendo adems prevenirla y detectarla
oportunamente.
Implementacin de auditoras de rastreo: Es necesario
implementar una verificacin de las auditorias para facilitar
la recuperacin de informacin de las mismas (rastreo). Si la
verificacin de la auditoria contiene informacin costosa o
demanda
mucho
tiempo,
su
valor
disminuye
significativamente.
Las
consideraciones
de
la
implementacin incluyen la cantidad de informacin a
recuperar seguida de la facilidad de recuperacin, referencias
cruzadas de informacin para la recuperacin y el tiempo que
la informacin de la auditoria necesita ser almacenada.
Plan de contingencia escrito: El plan de contingencia (serie
procedimientos detallados perfilando aquellas tareas a
ejecutar ante la ocurrencia de problemas) debe describir las
tareas preparatorias para que los datos necesarios y otros
recursos estn disponibles cuando sea necesario activarse.
Abordar el diseo de la contingencia es de poco valor si no se
documenta o no estar en manos de la gente que lo utilizar.
Consecucin del nivel de servicio deseado para el sistema: El
nivel de servicio deseado puede solo hacerse realidad cuando
los procedimientos y mtodos estn implementados. Uno de
los procedimientos que debe establecerse, es el monitoreo del
nivel de servicio para asegurarse que cumple con las
especificaciones. La inclusin de la rutina de monitoreo
provee seguridad en el logro del nivel de servicio a largo
plazo, caso contrario, se detectar a tiempo para tomar
medidas correctivas.
Implementacin de procedimientos de seguridad: La
seguridad es la combinacin de previsin y entrenamiento,
ms herramientas y tcnicas de seguridad. Los
procedimientos que aseguran que tanto las herramientas
como las tcnicas de seguridad estn disponibles y que
trabajen juntas, deben desarrollarse durante la fase de
codificacin.
Cumplimiento del programa con la metodologa a adoptar:
Los procedimientos a implementar deben asegurar
conformidad con estndares, polticas, procedimientos y
mtodos definidos por la organizacin. Si se detecta la no
conformidad, se deberan tomar las medidas necesarias para
modificar el diseo y as lograr la conformidad.
Programas acordes al diseo (Correctitud): El cambio
continuo de condiciones puede provocar que varios
miembros del personal del proyecto, ignoren los objetivos del
mismo durante la fase de codificacin. El argumento es que
siempre hay cambios, de manera que el ajuste a los objetivos
del sistema ya definidos, ahora ya no es muy significativa. El
equipo de aseguramiento de la calidad, debe desalentar esta
forma de pensar y continuamente monitorear la
implementacin de dichos objetivos. Si no se han alcanzado
200
los mismos, o deben cambiarse, o bien, debe cambiarse el

sistema para tratar de ajustarlos a las especificaciones
funcionales ya realizadas de la aplicacin.
Programas acordes al diseo (Facilidad de uso): La
implementacin de especificaciones del sistema puede
invalidar algunas de los aspectos del diseo respecto de la
facilidad de uso, a menos que los mismos se encuentren
definidos especficamente. La programacin es la traduccin
de especificaciones de diseo a lenguaje ejecutable por la
mquina. Esto puede entorpecer el logro de la facilidad de
uso. La codificacin debe lograr la facilidad de uso, de igual
forma en que se intenta cumplir con el resto de las
especificaciones funcionales.
Mantenibilidad de los programas: El mtodo de codificacin
puede significar ms para el mantenimiento que las
especificaciones de diseo mismas. Las reglas de
mantenimiento deben definirse en parte por los estndares y
en parte por las especificaciones del sistema. Adems, el
programador debe utilizar su juicio y experiencia para
desarrollar cdigo altamente mantenible.
Programas acordes al diseo (Portabilidad): La portabilidad
de los programas depende del lenguaje seleccionado y de
cmo se usa ese lenguaje. Las especificaciones deben indicar
lo que se hace y no se hace en la programacin para lograr su
portabilidad, y la codificacin debe apegarse a esas
especificaciones de diseo. Si la portabilidad es una
preocupacin importante y las especificaciones del programa
fallan al definir adecuadamente la portabilidad de la
codificacin, la misma quedar en manos del programador.
Programas acordes al diseo (Acoplamiento): Las
especificaciones de diseo deben indicar parmetros a pasar
desde y hacia otros mdulos y aplicaciones del sistema.
Normalmente es una buena prctica del programador,
verificar que las especificaciones del sistema estn
actualizadas antes que las funciones sean codificadas. Esto no
solo asegura que el programa se ajusta al diseo, sino
tambin, que las especificaciones de interconexin entre
aplicaciones no se han modificado desde que se document el
diseo.
Desarrollo de procedimientos operativos: Los procedimientos
deben desarrollarse durante la fase de programacin, de
forma de poder operar la aplicacin. Durante la fase
siguiente, los programas ejecutables sern operados. Los
procedimientos operativos deben ser consistentes con los
requerimientos operacionales definidos para la aplicacin.
Alcance de los criterios de performance por parte de los
programas: La creacin del programa provee la primer
oportunidad para los usuarios de evaluar si el sistema puede
lograr el nivel rendimiento deseado. Una evaluacin
temprana del rendimiento, brindar una buena oportunidad
para hacer ajustes si es necesario.
K. Revisiones por Pares
La revisin por pares contribuye a construir el cdigo de un
programa a travs de revisiones informales, pero sin embargo
efectivas, acerca de la funcionalidad del programa.
Este tipo de revisin provee un anlisis esttico que evala la
estructura y funcionalidad del programa. Puede detectar
errores sintcticos en mayor medida que una simple
observacin visual, como resultado de un recorrido
(walktrhough) de requerimientos.
La revisin por pares tambin puede ser formal. Las formales

son tareas integrales en el proceso de programacin, mientras
que las informales son solicitadas a discrecin del lder de
programacin. Adems puede aplicarse a otros productos, no
slo al cdigo de un programa.
El equipo de revisin por pares debe tener entre tres y seis
miembros. Es importante tener por lo menos tres miembros
para obtener variedad de opiniones. Las personas a considerar
para este equipo sern:
Programadores (por lo menos dos).
Especialistas en JCL (Job Control Language) o similar.
Operadores.
Lderes de programacin.
El programa de revisiones por pares se realiza ejecutando las
siguientes tareas:
K.1. Establecer Reglas Bsicas para la Revisin
Esto no es necesario para cada revisin pero es importante
tener buenas reglas de base. Entre dichas reglas, estn:
reas incluidas y excluidas de la revisin por pares. Por
ejemplo: Ver si la eficiencia de los programas ser incluida.
Cundo se usarn reportes.
Mtodo para seleccionar el lder de la revisin por pares.
Ubicacin de la conduccin de la revisin.
Mtodo para seleccionar productos a ser revisados por pares.
K.2. Seleccionar al Equipo de Revisin
Los integrantes del equipo deben ser seleccionados con la
suficiente antelacin, de manera que puedan organizar su
tiempo y estar entrenados para la revisin.
K.3. Entrenar a los Miembros del Equipo
Si una persona del equipo no ha participado previamente en el
programa de revisin por pares, se la debe entrenar en el
proceso. El entrenamiento incluye el entendimiento de las
reglas bsicas de esta revisin, preferentemente algn
entrenamiento en relaciones interpersonales acerca de cmo
entrevistar y trabajar con gente en el proceso de la revisin, y
entrenamiento en los estndares y metodologa de
programacin.
K.4. Seleccionar el Mtodo de Revisin
El lder del equipo debe seleccionar el mtodo de revisin. La
revisin en s misma consiste en dos partes. La primera es una
explicacin general de los objetivos y funcionamiento del
programa. La segunda parte es la revisin de los programas
utilizando el mtodo seleccionado. Los mtodos que pueden
ser utilizados para conducir la revisin por pares son cuatro:
Diagrama de flujo: El programa se explica desde un diagrama
de flujo. Esto es ms efectivo cuando el diagrama de flujo es
producido directamente desde el cdigo fuente.
Cdigo fuente: La revisin examina cada lnea del cdigo
fuente para entender el programa.
Muestra de transacciones: El lder de programacin explica
los programas exponiendo los procesamientos tpicos que
ocurren a partir de una muestra representativa de
transacciones.
Especificaciones de programas: Las especificaciones de
programas se revisan como un medio para entender el
programa.
K.5. Conducir la Revisin

El lder de programacin del proyecto normalmente
inspecciona la revisin por pares. La revisin comienza
habiendo hecho el lder de programacin, una revisin rpida
de las reglas bsicas, explicado los objetivos, y luego conduce
al equipo a revisar el procesamiento del programa. El equipo
de revisin ser libre de preguntar y comentar sobre cualquier
aspecto de la explicacin del programador y de hacer
recomendaciones y sugerencias acerca del programa.
Generalmente, la revisin por pares es dirigida en forma
democrtica.
El rol del lder del equipo es asegurar que las preguntas y
comentarios del equipo sean ordenados, asegurar los derechos
de hacer preguntas, recomendaciones o parar en un punto
especfico si, en la opinin del lder de inspeccin, no tiene
sentido continuar discutiendo.
K.6. Conclusiones
Al final de la revisin por pares, el lder de programacin
indicar cundo no tiene ms comentarios que hacer y lo deja
en manos del lder del equipo de revisin por pares. El lder
del equipo de revisin por pares, toma el control y resume la
informacin bosquejada de la revisin y presenta las
recomendaciones del equipo de revisin. Idealmente, esto se
hace como actividad grupal, pero algunos equipos de revisin
por pares, especialmente cuando el proceso se formaliza,
puede querer algn tiempo a solas para discutir entre ellos lo
que han escuchado y lo que van a recomendar. Las
conclusiones y recomendaciones luego se presentan al equipo
del proyecto para su consideracin.
K.7. Reportes
En el proceso de la revisin por pares, se prepara el reporte
documentando los resultados. Sin embargo, esto es opcional y
no es una parte esencial del proceso de revisin por pares.
El formato de los informes tpicos ser similar al que ya se han
detallado con anterioridad:
Informe de Inspeccin
Resumen de la Inspeccin
L. Verificacin de Documentacin
L.1. Integridad de la Documentacin
Los criterios principales para la verificacin de la integridad
de la documentacin, surgirn de la metodologa y estndares
de la organizacin. A continuacin, se detallan criterios
adicionales para verificar la integridad de la documentacin:
Contenido de la documentacin: Al ndice de cada
documento le debera seguir una breve descripcin de cada
elemento dentro del documento. Cada documento debe tener
un ndice de contenidos mnimos obligatorios, para poder
determinar si los documentos contienen toda la informacin
necesaria. Si faltan elementos, hay un defecto potencial en la
integridad de la documentacin, la cual debera ser
notificada.
Usuarios del documento: Cada tipo de documento estar
escrito dirigido a un usuario en particular, el cual podr ser
una persona o grupo, los cuales usarn el documento para
ejecutar una funcin. (Por ejemplo, operacin,
mantenimiento, diseo y programacin).
201
La informacin deber ser presentada con la terminologa y

el nivel de detalles apropiados para el tipo de usuario al cual
est dirigido el documento.
Redundancia: Los documentos tpicos dentro del proyecto
(Ej. Especificacin de Requerimientos, Anlisis de
Factibilidad, etc.) tendrn alguna redundancia. Se deber
incluir material introductorio en cada tipo de documento para
proveer al lector de un marco de referencia, facilitando la
interpretacin del documento con la menor cantidad de
referencias cruzadas hacia otros documentos. La informacin
que debera ser incluida en cada tipo de documento diferir
en su contexto y a veces en la terminologa y nivel de detalle,
porque intenta ser ledo por diferentes usuarios en diferentes
puntos del ciclo de vida del software
Flexibilidad. La flexibilidad en el uso de los documentos
depende de los lineamientos vigentes en la organizacin.
Tamao del documento: Cada tipo de documento puede tener
un tamao que va de unas pocas a varias decenas de hojas. La
longitud depende del tamao y complejidad del proyecto y
del juicio del Gerente de proyecto as como el nivel de
detalles necesario para el ambiente en el cual el software
deber desarrollarse y ejecutarse.
Combinacin de diferentes tipos de documentos: En
ocasiones, es necesario combinar algunos tipos de
documentos bajo una sola portada o producir algunos
volmenes con los mismos tipos de documentos. Los tipos de
documentos que pueden ser combinados son manuales para
el usuario, operaciones, y mantenimiento del programa. Para
sistemas de gran envergadura, puede ser preparado un
documento para cada mdulo. Algunas veces el tamao del
documento puede requerir ser repartido en varios volmenes
para hacer ms fcil su uso. En esos casos, debern estar
separados por secciones, sub-secciones, etc.
Formato: El formato obligatorio debe ser verificado, y debe
recomendarse el uso del mismo.
Secuencia de contenido: En general, el orden de las secciones
y prrafos de un tipo de documento debe ser el mismo que el
que se muestra en el ndice de contenidos obligatorios. El
orden puede cambiarse si enriquece la presentacin, caso
contrario, debera ajustarse a los estndares ya definidos por
la organizacin.
Ttulos de secciones/prrafos. Estos ttulos generalmente son
los mismos que los mostrados en la ndice de contenidos.
Pueden modificarse para reflejar la terminologa del software
a documentar si el significado le agrega valor a la
presentacin. Se pueden agregar o eliminar secciones o
prrafos segn sea necesario.
Expansin de los prrafos: La mayora de los tipos de
documentos definidos por la metodologa, estndares o
lineamientos de la organizacin tienen prrafos con un ttulo
general y una lista de puntos que pueden discutirse dentro de
ese prrafo. La intencin de esa lista no es establecer la
discusin de cada uno de estos puntos, sino sugerir la
consideracin de los mismos al escribir el prrafo. Este y
todos los otros prrafos pueden expandirse y subdividirse
para llevar a cabo una mejor presentacin de la informacin.
Diagramas de flujo y tablas de decisin: Los grficos de las
soluciones a problemas en forma de diagramas de flujo o
tablas de decisin, pueden estar incluidos o ser un apndice
del documento.
202
Formularios: El uso de formularios especficos depende de

las prcticas de la organizacin. Parte de la informacin
especificada en los prrafos del ndice de contenidos puede
registrarse en tales formularios. Si es as, el formulario puede
referenciarse desde el prrafo apropiado. Se requiere usar los
formularios que conforman los estndares de la organizacin.
L.2. Grado de actualizacin de la Documentacin
El equipo de verificacin de la documentacin puede usar
cualquiera de las siguientes cuatro verificaciones propuestas
para validar la actualizacin de la documentacin. Los tipos de
verificacin posibles se enumeran a continuacin:
L.2.1. Utilizar la Documentacin Vigente
La actualizacin puede validarse utilizando la documentacin
vigente para realizar algn cambio en la aplicacin. Esto
permite al analista de calidad buscar y confirmar la
consistencia entre varios documentos (por ejemplo, que las
especificaciones en el documento de diseo del programa,
sean las mismas que estn en el cdigo actual) y determinar si
la documentacin respalda el funcionamiento del sistema.
L.2.2. Comparar el Cdigo Fuente con la Documentacin
Esta verificacin usa la versin actual del cdigo fuente de
uno o ms programas como base de la documentacin. Esta
verificacin es realizada sobre la base de una muestra elegida
al azar de los programas o parte de los mismos y se las
verifica contra la documentacin. El objetivo es determinar si
el cdigo es representativo de la documentacin que se posee
del mismo.
L.2.3. Verificar la Vigencia de la Documentacin
Las personas que elaboran la documentacin deben verificar
que est vigente. Deben hacerse preguntas especficas, como
stas:
La documentacin es 100% representativa de la aplicacin
en operacin?
La documentacin cambia cada vez que se hace un cambio
en el sistema?
Los individuos que cambian el sistema confan en que la
documentacin es la correcta?
L.2.4. Verificar la Actualizacin de la Documentacin con el
Usuario
Los usuarios finales deben preguntarse si la documentacin
para el sistema est actualizada. Si los usuarios finales no
estn familiarizados con la documentacin, necesitarn que se
seleccione una muestra pidiendo piezas especficas de la
documentacin. La documentacin seleccionada debe ser
familiar para el usuario final de manera que se les pueda dar
partes representativas del documento y pedir que validen si
estn actualizadas o no.
VI. NIVEL DE SERVICIO ESPERADO
En el presente captulo se describe el Nivel de Servicio
Esperado, a travs de la cuantificacin de los resultados
esperados.
A. Generalidades
A.1. Necesidad de cuantificacin
Toda aplicacin de un modelo o servicio, requiere de ciertos
niveles de servicio o indicadores que permitan obtener una
cuantificacin de los resultados de la aplicacin del mismo y/o

establecer las expectativas para aplicaciones futuras. Para ello,
se describen cuatro indicadores.
Los indicadores aqu presentados, tanto su definicin como el
valor objetivo sugerido, constituyen slo una muestra no
esttica del tipo de indicadores que habra que considerar; es
decir se pueden agregar nuevos y/o modificar los aqu
presentados, conforme a la capacidad de la organizacin y a la
experiencia en la aplicacin del modelo.
A.2. Definicin de trminos
Con el objeto de clarificar diferentes trminos que se suelen
confundir o usar indistintamente y para precisar los acuerdos
de nivel de servicio, se presenta a continuacin las siguientes
definiciones, propuesta en [6]:
Errores: Estos son equivocaciones humanas como los errores
tipogrficos o sintcticos.
Defectos: Estos son condiciones impropias de un programa
que generalmente son el resultado de un error. No todos los
errores producen defectos en el programa, como comentarios
incorrectos o algunos errores de documentacin. Por el
contrario, un defecto puede producirse por causas ajenas al
programador, como problemas con las herramientas.
Bugs: Son defectos del programa que se encuentran operando
el mismo, ya sea durante la prueba o durante su uso. Los bugs
provienen de los defectos, pero no todos los defectos causan
bugs (algunas estn latentes pero nunca se encuentran). Los
defectos pueden encontrarse muchas veces, dando como
resultado mltiples bugs por defecto.
Fallas: Es un mal funcionamiento en una instalacin de
usuario. Puede ser provocado por un bug, una instalacin
incorrecta, una falla del hardware, etc.
Problemas: Son dificultades encontradas por los usuarios.
Pueden provenir de fallas, mal uso o mal entendimiento. Los
problemas son eventos relacionados con los humanos,
contrariamente a las fallas que son eventos relacionados con
el sistema.
Entradas Unitarias: Corresponde a cada uno de los elementos
del conjunto que componen la entrada a cada uno de los
mdulos del modelo de Aseguramiento de Calidad de
Software propuesto. Ejemplos de estos elementos o entradas
unitarias son documentos, especificaciones, planes,
diagramas, etc.
En la tabla XVII se resumen algunas de las definiciones
establecidas:
Comenzando con el problema se pueden rastrear las posibles

causas.
B. Indicadores
B.1. Indicador A
El indicador A establece el nivel tiempo promedio en que debe
poder adaptarse el plan general de aseguramiento de la calidad
a un proyecto en particular. El esquema correspondiente al
indicador A se muestra en la figura 19.
Fig. 18.
Proceso del mdulo de metodologa, estndares y

procedimientos
Descripcin: Tiempo promedio insumido en la generacin

del plan especfico de aseguramiento de la calidad para un
proyecto dado.
Valor objetivo sugerido: Menor o igual a 1 semana.
TABLA XVII. DEFINICIN DE TRMINOS

Categora
tems medidos
Causas
Errores
Acciones humanas
Equivocaciones del programador
Defectos
Propiedades del programa
Errores
Bugs
Mal funcionamiento del programa
Defectos del programa
Fallas
Mal funcionamiento del sistema
Bugs y otros mal funcionamientos
Problemas
Percepciones humanas
Fallas, errores humanos, incomprensin humana
En la figura 18 se muestran las relaciones entre las categoras

de la tabla anterior. Este diagrama tiene una doble utilidad:
Fig. 19.
Tiempo promedio en que se debe adaptar el plan

general al proyecto en particular
B.2. Indicador B
El indicador B establece el nivel de la capacidad de trabajo
concurrente del equipo de SQA en su conjunto. El esquema
correspondiente al indicador B se muestra en la figura 20.
Descripcin: Capacidad mxima de entradas unitarias en
proceso de verificacin concurrente.
Valor objetivo sugerido: Hasta 10 entradas unitarias.
Comenzando con el error del programador, se puede rastrear

en el diagrama hasta llegar al problema.
203
Fig. 20.
Nivel de capacidad de trabajo concurrente de SQA
B.3. Indicador C
El indicador C establece el nivel de la rapidez de trabajo del
equipo de SQA. El esquema correspondiente al indicador C se
muestra en la figura 21.
Descripcin: Tiempo mximo promedio de verificacin para
una entrada unitaria.
Valor objetivo sugerido: Menor o igual a 1 semana.
Fig. 23.
Estructura en tres niveles del equipo de aseguramiento

de la calidad
Cada sub-equipo, confirmado por un analista de SQA Senior y

sus Analistas de SQA Semisenior, podra ser asignado a un
proyecto en particular, mientras que, el Lder de SQA de la
organizacin, tiene el control sobre los sub-equipos y
mantiene una visin general que comprende a todos los
proyectos de dicha organizacin.
B. Responsabilidades del equipo
A continuacin de describe, slo a modo de ilustrativo, las
principales responsabilidades de cada uno de los perfiles
establecidos en la estructura de la figura 23.
Fig. 21.
Rapidez de trabajo de SQA
B.4. Indicador D
El indicador D establece el nivel de eficacia del trabajo del
equipo de SQA. El esquema correspondiente al indicador D se
muestra en la figura 22.
Descripcin: Porcentaje de defectos detectados en el proceso
de aseguramiento de la calidad del software (Considerando el
total de defectos de un sistema desde el inicio del proyecto
hasta 6 meses despus de su puesta en produccin).
Valor objetivo sugerido: 75% de los defectos
Fig. 22.
Nivel de eficacia del trabajo de SQA

VII. EQUIPO DE SQA
En el presente captulo se detalla el Equipo de SQA sugerido,

indicando su estructura y responsabilidades.
A. Estructura del equipo aseguramiento de la calidad
El equipo de trabajo de SQA puede tener variadas estructuras
y depender de la propia realidad y caractersticas particulares
de la organizacin en la cual el equipo se desempea.
En el presente trabajo se presentar una estructura en tres
niveles, muy comn en varias organizaciones. En la figura 23
se esquematiza esta estructura:
204
B.1. Lder de SQA

Mantenimiento del dialogo primario con los referentes del
rea de desarrollo.
Administracin del presupuesto de los proyectos para la
funcin de SQA.
Responsable de asegurar al equipo de trabajo los elementos
que ste o cualquiera de sus integrantes necesite.
Coordinacin de las necesidades polticas de los proyectos
con las capacidades operativas disponibles.
Coordinacin de responsabilidades entre los analistas de
SQA de los distintos proyectos.
Mantenimiento de la conduccin de todo el equipo de SQA.
Determinacin de los objetivos de SQA, para etapa de un
proyecto y control de su cumplimiento.
Elaboracin peridica de informes de avance y seguimiento.
Participacin en reuniones tcnicas, siempre que resulte
necesario.
Participacin en los mdulos que se indica en el modelo de
aseguramiento de la calidad propuesto.
Supervisin (directa o indirecta) de los analistas de SQA.
Evaluacin de cada integrante del equipo.
Responsable de la disciplina y cumplimiento del equipo.
B.2. Analista de SQA Senior
Aseguramiento del cumplimiento de su presupuesto
asignado.
Aplicacin de la metodologa de aseguramiento de la calidad
para los proyectos asignados.
Aseguramiento del cumplimiento de los objetivos fijados por
el lder de SQA.
Aseguramiento del cumplimiento de la metodologa de
trabajo fijada.
Participacin en los mdulos que se indica en el modelo de

Conduccin y administracin del equipo asignado a su cargo.
Asignacin de tareas a los analistas de SQA Semi-senior.
Supervisin de las tareas de los analistas de SQA Semi-senior
que le correspondan en cada proyecto.
Elaboracin peridica de informes de gestin de su equipo.
Elaboracin de informes por excepcin cada vez que resulte
necesario.
Comunicacin inmediata en situaciones que excedan su
capacidad de control o decisin.
Responsable primario de la disciplina y cumplimiento de su
equipo.
Colaboracin tcnica con el Lder de SQA en las reuniones o
consultas que ste requiera.
Asesoramiento al Lder de SQA en toda cuestin tcnica
vinculada a su rea de influencia.
B.3. Analista de SQA Semi-senior
Participa en los mdulos que se indica en el modelo de
Cumplimiento detallado con la metodologa de trabajo
impuesta y con las pautas que le fijen sus supervisores.
Elaboracin de informes detallados de cada unidad de
anlisis.
Elaboracin de informes por excepcin cada vez que resulte
necesario.
Comunicacin inmediata en situaciones que excedan su
capacidad de control o decisin.
Colaboracin tcnica con el Analista de SQA Senior en las
reuniones o consultas que ste requiera.
VIII. CONCLUSIONES
En el presente captulo se establecen las Conclusiones
obtenidas al concluir el presente trabajo, sealando los
beneficios y problemas esperados en la aplicacin de la
funcin de SQA en una organizacin. Tambin se establecen
las bases para un anlisis costo-beneficio.
A. Beneficios y problemas
Aunque pocos profesionales pondran en duda la necesidad de
calidad en el software, muchos no estn interesados en
establecer funciones de SQA formales. Las principales
razones de esta aparente contradiccin son las siguientes:
Los responsables del desarrollo se resisten a hacer frente a los
costos extras inmediatos y les cuesta ver los beneficios a
largo plazo.
Por desconocimiento, muchos profesionales creen que ya
estn haciendo todo lo que hay que hacer con respecto al
aseguramiento de la calidad.
Pocos saben dnde situar esa funcin dentro de la
organizacin.
Todos quieren evitar cierto nivel de burocracia que la funcin
de SQA tiende a introducir en el proceso de ingeniera del
software o de conocimiento.
En el presente trabajo, se ha presentado un enfoque prctico
para la aplicacin de la funcin de aseguramiento de la calidad
del software en una organizacin, que intenta echar luz sobre
las razones ya enunciadas que impiden la aplicacin de la

dicha funcin.
Aunque instanciada en la metodologa IDEAL, este enfoque
es independiente de la metodologa de desarrollo que esa
organizacin utilice. La independencia del enfoque con
respecto a metodologa utilizada por la organizacin, se debe a
qu el enfoque presentado es general, aplicable a fases
comunes de cualquier metodologa y a que no obliga a su
aplicacin rgida, sino que permite su adaptacin a esa
metodologa y a la propia realidad de la organizacin.
Asimismo, el enfoque presentado constituye un complemento
no disruptivo de la metodologa de desarrollo que ya utiliza
una organizacin y no obliga a profundos cambios en la
misma. Por el contrario, si la organizacin no utiliza una
metodologa, incentiva la utilizacin de una.
Algunos de los principales beneficios esperados de la
aplicacin constante y rigurosa de la funcin de SQA,
mediante el enfoque presentado, son los siguientes:
El software tendr menos defectos latentes, como
consecuencia, se reducir el esfuerzo y el tiempo durante las
etapas de prueba y mantenimiento.
Se dar una mayor fiabilidad y, por tanto, una mayor
satisfaccin del cliente.
Se podrn reducir los costos de mantenimiento (un porcentaje
sustancial de los costos totales del software).
El tiempo y el costo total del ciclo de vida del software
disminuir.
Por el lado negativo, la funcin de SQA podra resultar
problemtica por las siguientes razones:
Es difcil institucionalizar en organizaciones pequeas, en las
que no estn disponibles los recursos necesarios para llevar a
cabo esas actividades.
Representa un cambio cultural, y el cambio nunca es fcil.
Requiere un gasto que, de otro modo, nunca se hubiera
destinado explcitamente a la ingeniera del software o de
conocimiento o al aseguramiento de la calidad.
B. Evaluacin costo-beneficio
A la hora de establecer la funcin de aseguramiento de la
calidad del software en una organizacin, es razonable
preguntarse si valdr la pena, si el costo de su establecimiento
y aplicacin continua se ver justificado por los beneficios
alcanzados.
En el marco de un anlisis bsico de costo-beneficio, se puede
afirmar que la funcin de SQA en una organizacin ser
efectiva si se cumple con la siguiente: A > B + C siendo:
A: Costo de las fallas que aparecen sin la aplicacin de la
funcin de SQA. Esto incluye, entre otros, las actividades de
reparacin y re-trabajo, resolucin de quejas del cliente,
retorno y reemplazo del producto, soporte y ayuda al cliente, y
el pago de penalidades contractuales.
B: Costo de la propia aplicacin de la funcin de SQA. Esto
incluye, entre otros, los salarios del equipo de SQA y las
actividades de planificacin, revisiones y auditorias.
C: Costo de las fallas que no se encuentran con la aplicacin
de la funcin de SQA. Esto incluye los mismos puntos que A,
pero deberan ser dramticamente inferiores.
Sin embargo, es importante resaltar que en un anlisis ms
minucioso habra que considerar tambin otros aspectos, tales
como:
Reducciones en los costos de las pruebas y de la integracin.
205
Reduccin del nmero de cambios en las primeras versiones.

Reduccin en los costos de mantenimiento.
y otros de no tan fcil cuantificacin, tales como:
Mejora en satisfaccin del cliente.
Mejora en la imagen de la imagen externa de la organizacin.
Mejora en la imagen interna del equipo de ingeniera del
software o de conocimiento.
Finalmente, tambin es necesario tener en cuenta al momento
de hacer un anlisis costo-beneficio, que la funcin de SQA
no necesariamente est circunscripta al mbito de la ingeniera
del software o de conocimiento, sino que evoluciona como
parte de un esfuerzo general de gestin en la organizacin,
dirigido a mejorar la calidad. A ese esfuerzo general de
gestin dentro de la organizacin se lo suele denominar
gestin de la calidad total.
IX. BIBLIOGRAFA
[1] Roger S. Pressman (2001). Software Engineering: A
Practitioner's Approach. McGraw-Hill.
[2] J. Mc Call, P. Richards y G. Walters (1977). Factors in Software
Quality. Rome Air Development Center, United States Air
Force.
[3] R. Grady y D. Caswell (1987). Software Metrics: Establishing a
Company-Wide Program. Prentice Hall.
[4] Carnegie Mellon University - Software Engineering Institute
(1994) The Capability Maturity Model: Guidelines for
Improving the Software Process. Addison Wesley.
[5] William E. Perry (2000). Effective Methods for Software
Testing. Wiley Computer Publishing.
[6] Watts S. Humphrey (1989). Managing the Software Process.
X. FINANCIAMIENTO
Las investigaciones cuyos resultados se presentan en este
trabajo fueron parcialmente financiados por subsidio del
proyecto UNLa 33B102.
Eduardo Diez. Es Profesor Asociado del Area de
Ingeniera de Software en la Licenciatura en
Sistemas (Res. CONEAU 1089/12) del
Departamento de Desarrollo Productivo y
Tecnolgico de la Universidad Nacional de Lans
y Profesor Adjunto Regular del rea de Ingeniera
de Software en la Carrera de Ingeniera
Informtica de la Facultad de Ingeniera de la Universidad de Buenos
Aires. Es Profesor de la Maestra en Ingeniera de Software
(Acreditada por Resolucin CONEAU nro 239/04) en el marco del
Convenio Universidad Politcnica de Madrid - ITBA y Profesor de
Posgrado en la Maestra en Ingenieria de Sistemas de Informacin en
la Escuela de Posgrado de la Facultad Regional Buenos Aires de la
Universidad Tecnolgica Nacional. Es Investigador del Grupo de
Investigacin en Sistemas de Informacin y dirige del Laboratorio de
Investigacin y Desarrollo en Aseguramiento de Calidad de Software
de la Licenciatura en Sistemas y de la Maestria en Sistemas de
Informacin del Departamento de Desarrollo Productivo y
Tecnolgico de la Universidad Nacional de Lans. Su areas de
interes en investigacin son Calidad de Software y Modelos de
Madurez de Procesos de Software. Es Director del Proyecto UNLa
33B102 Aseguramiento de la Calidad para Proyectos de Explotacin
de Informacin. Es Analista de Sistemas y Licenciado en Sistemas
por la Universidad de Belgrano. Es Especialista en Ingeniera de
Sistemas Expertos y Magister en Ingeniera de Software por el
Instituto Tecnolgico de Buenos Aires y por la Facultad de
Informtica de la Universidad Politcnica de Madrid.
Addison Wesley.
206

Relais v1 n5 P 167 206

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Relais v1 n5 P 167 206

Uploaded by

Copyright:

Available Formats

Aseguramiento de la Calidad en la Construccin de

Sistemas Basados en el Conocimiento: Un Enfoque

La funcin de aseguramiento de la calidad del software

trabajo, sealando los beneficios y problemas esperados en la

aseguramiento de la calidad y de actividades de control de la

Punto de vista del

Punto de vista del

Fig. 1. Puntos de vista de la calidad del software

Dependiendo del punto de vista, se priorizarn distintos

Punto de vista del ingeniero de software: El punto de vista

Es difcil, y en algunos casos imposible, desarrollar

La facilidad de uso se calcula considerando los factores

3) Revisiones tcnicas formales que se aplican durante cada

Asegurar que las desviaciones detectadas sean documentadas

mismas. En la figura 2 se muestra la relacin entre el modelo

Fig. 2. Relacin entre el modelo general y la metodologa de desarrollo

B. Aplicacin del Modelo

Objetivo: Descripcin del propsito del mdulo, para usar

permanentes mejoras y actualizaciones de acuerdo a la

Fig. 3. Relacin entre el plan general y los planes especficos

Entrada: Documentos y/o informacin necesaria para

EXPLICACIN DE LOS CAMPOS QUE FORMAN PARTE DE LAS

D. Actualizacin del plan

Fig. 4. Modelo de actualizacin y mejora continua

D.2. Detalle del modelo de mejora continua del plan

Entrada: Plan especfico de aseguramiento de la calidad

influenciado por un largo nmero de variables, muchas de ellas

Fig. 5. Proceso del mdulo de planificacin

Una estimacin inapropiada de costos puede daar ms a la

A.5. Lista de Verificacin (Checklist)

La gerencia del proyecto, esta de acuerdo en tener un equipo

LISTA DE VERIFICACIN DEL MDULO DE PLANIFICACIN

Duracin actual del proyecto

Fig. 6. Proceso del mdulo de requerimientos

B.3.1. Preparar la Matriz de Riesgo

en la fase de diseo. La ejecucin de la matriz de riesgo es un

Este mtodo se implementa como un proceso de cinco

LISTA DE VERIFICACIN DEL MDULO DE REQUERIMIENTOS

Cantidad de tems cubiertos

Analistas de aseguramiento de la calidad del software Senior

Fig. 7. Proceso del mdulo de anlisis

C.3.1. Analizar la Especificacin Funcional

sistema como es percibido por los usuarios de esa

C.3.2. Conducir una Inspeccin Formal

Cantidad de nuevas funciones

Cantidad de defectos detectados

Cantidad de defectos removidos

Cantidad de tems cubiertos

C.5. Lista de Verificacin (Checklist)

LISTA DE VERIFICACIN DEL MDULO DE ANLISIS

Los objetivos y metas del sistema se mantienen

Fig. 8. Proceso del mdulo de diseo

D.3.1. Ranking de Factores de xito

procura identificar distritos electorales que muestran una

Completar el proyecto dentro de las restricciones del

Una o ms revisiones pueden llevarse a cabo durante la fase

Cantidad de defectos detectados

Cantidad de defectos removidos

Cantidad de tems cubiertos

Estabilidad del diseo:

Cantidad de cambios introducidas

D.7.2. Equipo de Aseguramiento de la Calidad del Software

LISTA DE VERIFICACIN DEL MDULO DE DISEO