3.1.

Medidas de fiabilidad y de disponibilidad

No hay duda de que la fiabilidad de un programa de cmputo es un elemento importante de
su calidad general. Si un programa falla repetida y frecuentemente en su desempeo, importa
poco si otros factores de la calidad del software son aceptables.
La fiabilidad del software, a diferencia de muchos otros factores de la calidad, se mide y estima
directamente mediante el uso de datos histricos del desarrollo. La fiabilidad o confiabilidad
del software se define en trminos estadsticos como la probabilidad que tiene un programa
de cmputo de operar sin fallas en un ambiente especfico por un tiempo especfico. Para
ejemplificar esta situacin, digamos que se estima que el programa X tiene una confiabilidad
de 0.999 durante ocho horas de procesamiento continuo. En otras palabras, si el programa X
fuera a ejecutarse 1 000 veces y requiriera un total de ocho horas de tiempo de procesamiento
continuo (tiempo de procesamiento), es probable que operar correctamente (sin fallas) 999
veces. Como puede notarse, la fiabilidad del software se puede medir, dirigir y estimar
mediante datos histricos o de desarrollo, a diferencia de otros factores de calidad que no son
medibles.
Algo a puntualizar es el significado del trmino falla. En el contexto de cualquier anlisis de la
calidad y confiabilidad del software, la falla significa la falta de conformidad con los
requerimientos del software. Las fallas pueden ser leves o catastrficas. Una falla leve podra
corregirse en segundos, mientras que otra tal vez requiera de varias semanas o meses de
trabajo para ser corregida. Para complicar ms el asunto, la correccin de una falla quiz d
como resultado la introduccin de otros errores que a su vez originen otras fallas.
Todava se debate sobre la relacin entre los conceptos de la fiabilidad del hardware y su
aplicabilidad al software, pues la mayora de los modelos de fiabilidad relativos al hardware
estn ms orientados a fallas debido al uso que a fallas debidas a defectos de diseo, mientras
que todas las fallas de software se originan por problemas de diseo. Sin embargo existen
algunos conceptos que se aplican a ambos sistemas:
Considerando un sistema basado en computadora, una sencilla medida de la fiabilidad es el
tiempo medio entre fallas (TMEF), donde;
TMEF = TMDF + TMDR
Las siglas TMDF y TMDR corresponden a tiempo medio de fallo y tiempo medio de reparacin,
respectivamente.
Otra medida es la de Disponibilidad, que es la probabilidad de que un programa opere de
acuerdo con los requisitos en un momento dado, y se define como:
Disponibilidad = [TMDF/ (TMDF + TMDR)] x 100 %
La medicin del TMEF para la confiabilidad es igualmente sensible al TMPF y al TMPR. La
medicin de la disponibilidad es un poco ms sensible al TMPR, que es una medicin indirecta
de la facilidad que tiene el software para recibir mantenimiento.
Calidad en los Sistemas de Informacin Ingeniera Informtica


3.2. Seguridad de los sistemas de informacin
La seguridad del software es una actividad del aseguramiento del software que se centra en la
identificacin y evaluacin de los peligros potenciales que podran afectarlo negativamente y
que podran ocasionar que falle todo el sistema. Si los peligros se identifican al principio del
proceso del software, las caractersticas de su diseo se especifican de modo que los eliminen
o controlen.
Como parte de la seguridad del software, se lleva a cabo un proceso de modelado y anlisis.
Inicialmente se identifican los peligros y se clasifican segn su riesgo. Por ejemplo, algunos de
los peligros asociados con un control de crucero basado en computadora para un automvil
podran ser los siguientes: 1) ocasionar una aceleracin incontrolada que no pudiera
detenerse, 2) no responder a la presin en el pedal de frenado (porque se apague), 3) no
encender cuando se active el interruptor y 4) perder o ganar velocidad poco a poco. Una vez
identificados estos peligros en el nivel del sistema, se utilizan tcnicas de anlisis para asignar
severidad y probabilidad de ocurrencia a cada uno. Para ser eficaz, el software debe analizarse
en el contexto de todo el sistema. Por ejemplo, un error sutil en la entrada de un usuario (las
personas son componentes del sistema) podra ampliarse por una falla del software y producir
datos de control que situaran equivocadamente un dispositivo mecnico. Si y slo si se
encontrara un nico conjunto de condiciones ambientales externas, la posicin falsa del
dispositivo mecnico ocasionara una falla desastrosa. Podran usarse tcnicas de anlisis, tales
como rbol de fallas, lgica en tiempo real y modelos de red de Petri, para predecir la cadena
de eventos que ocasionaran los peligros, as como la probabilidad de ocurrir que tendra cada
uno de los eventos para generar la cadena.
Ejemplo de rbol de fallas
Una vez identificados y analizados los peligros, pueden especificarse requerimientos
relacionados con la seguridad para el software. Es decir, la especificacin contendra una lista
de eventos indeseables y las respuestas deseadas del sistema ante ellos. Despus se indicara
el papel del software en la administracin indeseable de los mismos.
Aunque la confiabilidad y la seguridad del software estn muy relacionadas, es importante
entender la sutil diferencia entre ellas. La primera utiliza tcnicas de anlisis estadstico para
determinar la probabilidad de que ocurra una falla del software. Sin embargo, la ocurrencia de
una falla no necesariamente da como resultado un peligro o riesgo. La seguridad del software
examina las formas en las que las fallas generan condiciones que llevan a un peligro. Es decir,
las fallas no se consideran en el vaco, sino que se evalan en el contexto de la totalidad del
sistema basado en computadora y de su ambiente.
Calidad en los Sistemas de Informacin Ingeniera Informtica





3.3. Relacin de la ingeniera de sistemas de informacin con SQA (Software Quality
Assurance)
En los aos 50, el software comenz a encontrar su camino dentro de los sistemas del DoD
(Department of Defense of USA). Usualmente estos proyectos estaban muy alejados de la
planificacin, se pasaban del presupuesto y tenan muchos problemas tcnicos.
Frecuentemente no funcionaban como se esperaba y muchos proyectos eran cancelados antes
de ser entregados. Durante este periodo los contratistas para el desarrollo de software a
menudo hacan estimaciones muy optimistas sobre el estado del desarrollo del software. El
DoD normalmente no era notificado de los problemas en la planificacin, en la gestin del
presupuesto y de problemas tcnicos hasta muy avanzado el proyecto, cuando ya no eran
capaces de entender los problemas ni de evaluar el impacto de stos.
Para intentar resolver este problema se estableci la Verificacin y Validacin Independientes
(IV&V - Independent Verification and Validation), un proceso de ingeniera que empleaba
metodologas rigurosas para evaluar la correctitud y calidad del software a lo largo de su ciclo
de vida.
El primer software en usar IV&V fue el programa del misil atlas a finales de los aos 50. Desde
el proyecto atlas se ha recolectado mucha informacin que indica que los proyectos con IV&V
se realizan o ejecutan mucho mejor que los proyectos sin IV&V. Con el tiempo el rol del IV&V
se convirti critico.
La actividad de SQA evoluciona directamente de la Verificacin y Validacin Independientes
(IV&V), muchas de las tareas que se incluyen con SQA son originarias de IV&V.
Luego durante los aos 70 la actividad de desarrollo de software comenz a expandirse y las
compaas de desarrollo de software fueron experimentando los mismos pobres resultados
que las agencias gubernamentales (DoD, NASA etc.) en las dcadas tempranas. Las compaas
tenan dificultad para entregar el software dentro de los plazos, presupuesto y calidad
planificados. Varios proyectos desarrollados entre 1980 y 1990 fueron desastrosos, muchos
excedan ampliamente el presupuesto y la planificacin o entregaban software de baja calidad
que no se poda usar.
Durante los 80 esta experiencia se convirti en lo que se conoce como crisis del software, el
tiempo consumido en el mantenimiento exceda el tiempo insumido en la construccin de
nuevos productos de software.
Luego de la crisis del Software en los aos 80, SQA evolucion hacia una herramienta que las
compaas de desarrollo de software utilizaban para identificar de forma temprana los
problemas de calidad en el proceso de desarrollo. Mientras SQA era visto como un pequeo
paso dentro del proceso del desarrollo del software, muchos jefes de proyectos vieron
beneficios cuantificables a partir de integrar SQA dentro del proceso de desarrollo de software.
En los 90 varias compaas de software ya tenan funciones de SQA dentro de sus
organizaciones.
Calidad en los Sistemas de Informacin Ingeniera Informtica



3.4. Definicin y propsito del SQA
El aseguramiento de la calidad del software (con frecuencia llamado administracin de la
calidad) es una actividad que se aplica en todo el proceso del software. Al igual que con la
definicin de calidad hay varios puntos de vista desde donde se puede definir el
aseguramiento de la calidad del software. La definicin ms completa a mi parecer es la que
propone el IEEE, la cual dice que es una gua planificada y sistemtica de todas las acciones
necesarias para proveer la evidencia adecuada de que un producto cumple los requerimientos
tcnicos establecidos. Un conjunto de actividades diseadas para evaluar el proceso por el cual
un producto es desarrollado o construido.
Por tanto, el grupo de SQA es nicamente el facilitador de los procesos de calidad y el
responsable por aplicar los principios de calidad a lo largo de la organizacin. La
responsabilidad por la implantacin de la calidad recae en la administracin superior y en los
grupos de desarrollo.
La existencia de un grupo de SQA dedicado no garantiza por s solo que los procesos sean
seguidos y que la calidad se introduzca mgicamente en el producto. Debe existir un
compromiso de toda la organizacin por orientar hacia una cultura de la calidad.
El concepto de SQA se basa en la premisa de que la calidad de un producto de software est
fundamentalmente determinada por los procesos utilizados en su desarrollo y mantencin. Es
decir, a travs de la incorporacin de prcticas de ingeniera de software y del monitoreo de la
adherencia a ellas, se lograr perfeccionar el proceso de desarrollo y, por consecuencia,
mejorar la calidad del producto.
Sin embargo, es necesario comprender que la calidad no puede ser una funcin exclusiva de
una persona o de un grupo dentro de una organizacin. Muy por el contrario es
responsabilidad de cada persona involucrada en el desarrollo del producto.
La labor de SQA se limita a difundir y motivar a los miembros de la organizacin en el
mejoramiento de la calidad, participar en la evaluacin del producto y en el monitoreo de
procesos para garantizar su adherencia a los estndares y procedimientos establecidos y guiar
a la administracin en la innovacin, integracin y optimizacin del proceso de desarrollo.
SQA es, por lo tanto, un staff de apoyo en la toma de decisiones para el nivel de gestin, un
fiscalizador durante todo el ciclo de vida de un proyecto y el principal promotor de las
prcticas de calidad dentro de todos los niveles organizacionales.
Basndose en lo anterior, los objetivos principales de SQA son:
1. Planificar las actividades de SQA.
2. Verificar la adherencia de los productos de trabajo y de las actividades a los
estndares, procedimientos y requerimientos establecidos.
3. Informar a los grupos e individuos afectados sobre las actividades de SQA y sus
resultados.
4. Comunicar a la administracin superior sobre desviaciones no resueltas dentro del
proyecto.
Calidad en los Sistemas de Informacin Ingeniera Informtica
Para alcanzar estos objetivos se requiere comprender la necesidad de un grupo responsable de
SQA (Software Quality Group), las actividades del proceso de SQA, sus tareas a lo largo del
ciclo de vida de un proyecto y su relacin con otras reas de prcticas del desarrollo de
software.
3.4.1. Actividades del SQA
El objetivo del grupo de SQA es auxiliar al equipo del software para lograr un producto final de
alta calidad. El Instituto de Ingeniera de Software recomienda un conjunto de acciones de SQA
que se dirigen a la planeacin, supervisin, registro, anlisis y elaboracin de reportes para el
aseguramiento de la calidad. Estas acciones son realizadas (o facilitadas) por un grupo
independiente de SQA que hace lo siguiente:
Prepara el plan de SQA para un proyecto. El plan se desarrolla como parte de la preparacin
del proyecto y es revisado por todos los participantes. Las acciones de aseguramiento de la
calidad efectuadas por el equipo de ingeniera de software y por el grupo de SQA son dirigidas
por el plan. ste identifica las evaluaciones que se van a realizar, las auditoras y revisiones por
efectuar, los estndares aplicables al proyecto, los procedimientos para reportar y dar
seguimiento a los errores, los productos del trabajo que genera el grupo de ACS y la
retroalimentacin que se dar al equipo del software.
Participa en el desarrollo de la descripcin del software del proyecto. El equipo de software
selecciona un proceso para el trabajo que se va a realizar. El grupo de ACS revisa la descripcin
del proceso a fin de cumplir con la poltica organizacional, los estndares internos para el
software, los estndares impuestos desde el exterior (como la norma ISO-9001) y otras partes
del plan del proyecto de software.
Revisa las actividades de la ingeniera de software a fin de verificar el cumplimiento mediante
el proceso definido para el software. El grupo de ACS identifica, documenta y da seguimiento a
las desviaciones del proceso y verifica que se hayan hecho las correcciones pertinentes.
Audita los productos del trabajo de software designados para verificar que se cumpla con
aquellos definidos como parte del proceso de software. El grupo de ACS revisa productos del
trabajo seleccionados; identifica, documenta y da seguimiento a las desviaciones; verifica que
se hayan hecho las correcciones necesarias y reporta peridicamente los resultados de su
trabajo al gerente del proyecto.
Asegura que las desviaciones en el trabajo de software y sus productos se documenten y
manejen de acuerdo con un procedimiento documentado. Las desviaciones pueden
encontrarse en el plan del proyecto, la descripcin del proceso, los estndares aplicables o los
productos del trabajo de la ingeniera de software.
Registra toda falta de cumplimiento y la reporta a la alta direccin. Se da seguimiento a los
incumplimientos hasta que son resueltos.
Adems de estas acciones, el grupo de ACS coordina el control y administracin del cambio y
ayuda a recabar y analizar mtricas para el software.
Calidad en los Sistemas de Informacin Ingeniera Informtica
Estas actividades se pueden clasificar segn las etapas de desarrollo del software as como
sigue:
Planificacin. Durante la etapa de planificacin, SQA debe participar de la elaboracin del plan
de proyecto.
Es su responsabilidad producir el Plan de SQA y verificar que los procesos, procedimientos y
estndares identificados en el plan de proyecto son apropiados, claros, especficos y
auditables.
El contenido del plan de SQA debe identificar: evaluaciones, auditoras y revisiones,
estndares, procedimientos de seguimiento y reporte de errores, y la documentacin por
producir.
Especificacin de requerimientos. SQA debe corroborar que en la especificacin estn
expresados todos los requerimientos funcionales, tcnicos, operacionales y de interfaz, de
manera tal que puedan ser verificados en el producto final.
Diseo. En la fase de diseo, dentro de las actividades de SQA se incluyen asegurar:
La adherencia del diseo y su documentacin a los estndares definidos en el plan
del proyecto.
La presencia de todo mdulo en el diseo.
La incorporacin de los resultados de las inspecciones en el diseo.
El ingreso del diseo a la configuracin del software, tras su aprobacin.
Implementacin. A SQA le corresponde auditar:
Los resultados de las actividades de diseo y codificacin.
El estado de todos los entregables.
Las actividades de gestin de configuracin y de la biblioteca del software.
Los informes sobre desviaciones y las acciones correctivas.
Integracin y prueba. Con relacin a la integracin y a la prueba, a SQA le corresponde
garantizar la concordancia de las pruebas con el plan y los procedimientos definidos, as como
tambin que toda desviacin haya sido informada y corregida. Adems, debe certificar que las
actividades de prueba se han completado satisfactoriamente y que el software y su
documentacin se encuentran listos para la entrega del producto final.
Aceptacin y entrega. En la fase de aceptacin, SQA es responsable de realizar la ltima
auditora de configuracin del software, con el objetivo de determinar que los deliberables
estn listos para la entrega.
Mantenimiento. Durante la operacin pueden presentarse correcciones o mejoras que
originen pequeos ciclos de desarrollo. En tal caso, se repetirn las actividades de SQA
descritas con anterioridad.
Calidad en los Sistemas de Informacin Ingeniera Informtica

3.4.2. Roles y responsabilidades de los equipos de SQA
A continuacin se describen los diferentes roles que puede jugar el equipo de SQA y las
funciones que puede llevar a cabo en una organizacin.
Como polica del proceso: el trabajo del equipo de SQA es asegurar que el desarrollo sigue el
proceso establecido. Entre sus funciones en este rol se encuentran:
Auditar los productos del trabajo para identificar deficiencias.
Determinar el cumplimiento del plan de desarrollo del proyecto y del proceso de
desarrollo de software.
Juzgar el proceso y no el producto.

Como abogado del cliente: el trabajo del equipo de SQA es representar al cliente. Entre sus
funciones en este rol se encuentran:
Identificar la funcionalidad que al cliente le gustara encontrar.
Ayudar a la organizacin a sensibilizarse con las necesidades del cliente.
Actuar como un cliente de prueba para obtener una alta satisfaccin del cliente.

Como analista el trabajo del equipo de SQA es recabar informacin. Entre sus funciones en
este rol se encuentran:
Reunir una cantidad considerable de datos sobre todos los aspectos del producto y
del proceso.
Con esta informacin ayudar a mejorar los procesos y los productos.

Como proveedor de informacin el trabajo del equipo de SQA es revisar qu es lo que est
hecho y decir cules objetivos tcnicos realmente estn cumplidos para que la gerencia pueda
tomar mejores decisiones de negocios. Entre sus funciones en este rol se encuentran:
Proveer informacin tcnica objetiva para que la gerencia pueda usarla para tomar
mejores decisiones.
Proveer informacin apropiada de las clases de productos y de los riesgos asociados
con estos.
Concentrarse ms en la reduccin de los riesgos que en el cumplimiento del proceso.

Como responsable de la elaboracin del proceso. El trabajo del equipo de SQA es participar
en la definicin de los planes, procesos, estndares y procedimientos para asegurar que se
ajustan a las necesidades del proyecto y que pueden ser usados para realizar las evaluaciones
de QA y cumplir los requerimientos del proyecto y las polticas de la organizacin. Para cumplir
este rol el aseguramiento de la calidad debera comenzar en las fases tempranas del proyecto.
Aqu conviene aclarar que no necesariamente las personas que definen la metodologa a seguir
pertenecen al equipo de QA. Definir la metodologa puede llegar a ser o no una actividad del
equipo de QA. Una estructura posible en el proceso de mejora del software puede ser contar
con un SEPG (Software Engineering Process Group) totalmente
Calidad en los Sistemas de Informacin Ingeniera Informtica
independiente del equipo de QA, encargado de definir la metodologa mientras que el equipo
de QA se limita a verificar que se cumpla dicha metodologa.