GESTION DE LA CONFIGURACION DEL SOFTWARE – GRUPO V

INTRODUCCION

La gestión de la configuración del software es uno de los procesos clave para toda
organización dedicada a la Ingeniería del Software, ya que posibilita una mejor
organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de
producción.

Durante el proceso de construcción de un software, los cambios son inevitables. Los

cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o
pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden
ocurrirle al software dentro de todo el proceso de ingeniería.

“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina

gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las
modificaciones que sufre el software…la meta es maximizar la productividad minimizando
errores.” Babich.

1. GESTION DE LA CONFIGURACION DEL SOFTWARE (GCS)

Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento por lo
tanto debemos estar preparados, las actividades de CGS sirven para:

• Identificar el cambio de nuestro software.

• Controlar ese cambio.
• Garantizar que el cambio quede bien implantado.
• Informar el cambio.

La gestión de configuración del software no es un mantenimiento del software, el

mantenimiento es la etapa final de la ingeniería hasta que se retire el producto del equipo, la
CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se
inicia el proyecto de desarrollo del software y termina sólo una vez que el software queda
fuera de circulación.

Desgraciadamente, en el proceso de ingeniería del software existe una variable

importantísima que entra en juego, el cambio.

La primera Ley de la ingeniería de sistemas establece: “Sin importar en que momento del
ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo
persistirá a lo largo de todo el ciclo de vida”.

Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar el sistema? ¿Que produce los
en el sistema cambios? La respuesta a estas interrogantes se puede encontrar en cuatro
aspectos fundamentales y a menudo muy tradicionales dentro del desarrollo del software:
 • Nuevos requisitos del negocio o condiciones que dictan los cambios en las
condiciones del producto o en las normas comerciales.
• Nuevas necesidades del los clientes que demandan la modificación de los datos
producidos por un sistema basado en computadora.
• Reorganización y/o reducción del volumen comercial que provoca cambios en las
prioridades del proyecto o en la estructura del equipo de ingeniería del software.
• Restricciones presupuestarias o de planificaciones que provocan una redefinición
del sistema o del producto.

La gestión de configuración del software realiza un conjunto de actividades desarrolladas

para gestionar y registrar los cambios a lo largo del ciclo de vida del software de
computadora.

La GCS es una actividad de garantía de calidad del software que se aplica en todas las fases
del proceso de ingeniería del software.

1.1. LINEAS BASE

Una línea base es un concepto de gestión de configuración del software que nos ayuda a
controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define una
línea base como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha

llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior
y que puede cambiarse solamente a través de procedimientos formales de control de
cambios.

Una forma de describir la línea base es mediante una analogía. Considere las puertas de la
cocina de un gran restaurante. Para evitar colisiones una puerta esta marcada como
SALIDA y la otra como ENTRADA las puertas tienen topes que hacen que solo se puedan
abrir en la dirección apropiada. Si un camarero recoge un pedido en la cocina lo coloca en
una bandeja y luego se da cuenta de que ha cogido un plato equivocado, puede cambiar el
plato correcto rápidamente informalmente antes de salir de la cocina.

Sin embargo, si abandona la cocina le da el plato al cliente y luego se le informa de su

error, debe seguir el siguiente proceso: 1) Mirar en la orden de pedido si ha cometido algún
error. 2) Disculparse insistentemente. 3) Volver a la cocina por la puerta de entrada. 4)
Explicar el problema etc.

Una línea base es análoga a un plato mientras pasa por las puertas de la cocina de un
restaurante antes de que un elemento de configuración del software se convierta en línea
base, el cambio se puede llevar a cabo rápida e informalmente. Sin embargo, una vez que se
establece una línea base, pasamos, de forma figurada, por una puerta de un solo sentido. Sé
pueden llevar a cabo los cambios, pero se debe aplicar un procedimiento formal para
evaluar y verificar cada cambio.

En el contexto de la ingeniería del software definimos una línea base como un punto de
referencia en el desarrollo del software y que queda marcado por el envío de uno o más
elementos de configuración del software (ECS) y la aprobación de ECS obtenido mediante
una revisión técnica formal. Por ejemplo, los elementos de una especificación de diseño se
documentan y se revisan. Se encuentran errores y se corrigen cuando todas las partes de las
especificaciones se han revisado corregido y aprobado, la especificación de diseño se
convierte en línea base. Solo se pueden realizar cambios futuros en la arquitectura del
software (contenidos en la especificación del diseño) tras haber sido evaluados y
aprobados. Aunque se puedan definir las líneas base con cualquier nivel de detalle las
líneas base más comunes son las que se muestran en la figura 1.0.

1.2. ELEMENTO DE CONFIGURACIÓN DE SOFTWARE

Un elemento de la configuración del software es la información creada como parte del

proceso de ingeniería un ECS (elemento de configuración de software) es un documento,
un conjunto completo de casos de prueba o un componente de un programa dado. Los
siguientes ECS son el objetivo de las técnicas de gestión de configuración y forman un
conjunto de líneas base:

1) Especificación del sistema

2) Plan de proyecto

3) a. Especificación de requisitos

b. Prototipo ejecutable o “en papel”

4) Manual de usuario preliminar

5) Especificación de diseños

a. Descripción del diseño de datos

b. Descripción del diseño arquitectónico

c. Descripciones del diseño de los módulos

d. Descripciones del diseño de interfaces

e. Descripciones de los objetos (si se utilizan técnicas de P.O.O)

6) Listados del código fuente

7) a. Plan y procedimiento de pruebas

b. Casos de prueba y resultados registrados

8) Manuales de operación de y de instalación

9) Programas ejecutables

a. Módulos, código ejecutable

b. Módulos enlazados

10) Descripción de la base de datos

a. Esquema y estructura de archivos

b. contenido inicial

11) Manual del usuario final

12) Documentos de mantenimiento

a. Informes de problemas del software

b. Peticiones de mantenimiento

c. Ordenes de cambios e ingeniería

13) Estándares y procedimientos de ingeniería del software

Es importante considerar poner las herramientas de desarrollo de software bajo control de

configuración. Es decir congelar la versiones de editores, compiladores y otras
herramientas CASE utilizadas durantes el desarrollo, un cambio en las versiones utilizadas
puede que produzca resultados diferentes que la versión original.

Los ECS se organizan como objetos de configuración que deben ser catalogados por la base
de datos del proyecto con un nombre único. Un ECS tiene un nombre y atributos, y está
conectado a otros objetos mediante relaciones.

2. EL PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

La GCS es un elemento importante de garantía de calidad es responsable de controlar los

cambios. Sin embargo también se debe identificar los ECS individuales. El proceso se
puede definir en cinco tareas de CGS:

• Identificación
 • Control de versiones
• Control de cambios
• Auditorias de configuración
• Generación de informes

3. IDENTIFICACIÓN DE OBJETOS EN GCS

Se pueden identificar dos tipos de objetos los objetos básicos y los objetos compuestos.

Un objeto básico es una unidad de texto creada durante el análisis, diseño, codificación o
prueba. Un objeto compuesto es una colección de objetos básicos u objetos compuestos.
Cada objeto tiene un conjunto de características que los identifican como únicos. El nombre
del objeto es una cadena de caracteres que identifica al objeto sin ambigüedad. La
descripción del objeto es una lista de elementos de datos que identifican:

• El tipo de ECS (documento, programa, datos) que está representado por el objeto.
• Un identificador del proyecto; y la información de la versión y/o el cambio.

El esquema de identificación de los objetos de software debe tener en cuenta que los
objetos evolucionan a lo largo del proceso de ingeniería, por lo que se puede crear un grafo
de evolución.

En el grafo de evolución se describe la historia del objeto y sus cambios, las grandes
modificaciones hacen que un objeto cambie, por lo que cambia el número de versión
principal.

4. CONTROL DE VERSIONES

El control de versiones combina procedimientos y herramientas para gestionar las versiones

de los objetos de configuración creadas durante el proceso de ingeniería del software.

“La gestión de configuración permite a un usuario especificar configuraciones alternativas

del sistema de software mediante la selección de las versiones adecuadas. Esto se puede
gestionar asociando atributos a cada versión del software y permitiendo luego especificar y
construir una configuración describiendo el conjunto de atributos deseado.”

Los atributos pueden ser tan sencillos como un número específico de versión asociado a
cada objeto o tan complejos como una cadena de variables lógicas que especifiquen tipos
de cambios funcionales aplicados al sistema.

Para construir la variante adecuada de una determinada versión de un programa, a cada

componente se le asigna una tupla de atributos. A cada variante se le asigna uno o más
atributos. Otra forma de establecer los conceptos de la relación entre componentes,
variantes y versiones es representarlas como un fondo de objetos
La principal diferencia entre los distintos está en la sofisticación de los atributos que se
usan para construir versiones y variantes específicas de un sistema y en la mecánica del
proceso de construcción.

5. CONTROL DE CAMBIOS

En un gran proyecto de desarrollo de software, el cambio incontrolado lleva rápidamente al

caos. El control de cambios combina los procedimientos humanos y las herramientas
automáticas para proporcionar un mecanismo para el control de cambio.

Los resultados de la evaluación se presentan como un informe de cambios a la autoridad de

control de cambios (ACC). Para cada cambio aprobado se genera una orden de cambio de
ingeniería (OCI) La OCI describe el cambio a realizar, las restricciones que se deben
respetar y los criterios de revisión y de auditoria. El objeto a cambiar es “dado de baja” de
la base de datos del proyecto; se realiza el cambio y se aplican las adecuadas actividades de
SQA. Luego, el objeto es “dado de alta” en la base de datos y se usan los mecanismos de de
control de versiones apropiadas (sección 4) para crear la siguiente versión del software.

Los procedimientos de “alta” y “baja” implementan dos elementos importantes del control
de cambios: control de acceso y control de sincronización. El control de acceso gobierna
los derechos de los ingenieros de software a acceder y modificar objetos de configuración
concretos. El control de sincronización asegura que los cambios en paralelo, realizados por
personas diferentes, no se sobrescriben mutuamente.

Antes de que un ECS se convierta en una línea base, sólo es necesario aplicar un control de
cambios informal. El que haya desarrollado el ECS en cuestión podrá hacer cualquier
cambio justificado por el proyecto y por los requisitos técnicos. Una vez que el objeto ha
pasado la revisión técnica formal y ha sido aprobada, se crea la línea base.

Una vez que el ECS se convierte en una línea base, aparece el control de cambios a nivel de
proyecto. Para hacer un cambio, el encargado del desarrollo debe recibir la aprobación del
gestor del proyecto (si el cambio es local), o de la ACC si el cambio impacta en otros ECS.
En algunos casos, se dispensa de generar formalmente las peticiones de cambio, los
informes de cambio y las OCI. Sin embargo, hay que hacer una evaluación de cada cambio
así como un seguimiento y revisión de los mismos.

Cuando se distribuye el producto de software a los clientes, se instituye el control de

cambios formal. La autoridad de control de cambios (ACC) desempeña un papel activo en
el segundo y tercer nivel de control. El papel de la ACC es el de tener una visión general, o
sea, evaluar el impacto del cambio fuera del ECS en cuestión. ¿Cómo impactará el cambio
en el hardware? ¿Cómo impactará en el rendimiento?¿Cómo alterará el cambio la
percepción del cliente sobre el producto?

6. AUDITORIA DE LA CONFIGURACION
¿Cómo podemos asegurar que el cambio se ha implementado correctamente? La respuesta
es doble: 1) revisiones técnicas formales y 2) auditorias de configuración del software.

Las revisiones técnicas formales se centran en la corrección técnica del elemento de

configuración que ha sido modificado. Los revisores evalúan el ECS para determinar la
consistencia con otros ECS, las omisiones o los posibles efectos secundarios.

Una auditoria de configuración del software complementa la revisión técnica formal al

comprobar características que generalmente no tiene en cuenta la revisión. La auditoria se
plantea y responde con las siguientes preguntas:

• ¿Se ha hecho el cambio especificado en la OCI? ¿Se han incorporado

modificaciones adicionales?
• ¿Se ha llevado a cabo una revisión técnica formal para evaluar la corrección
técnica?
• ¿Se han seguido adecuadamente los estándares de ingeniería de software?
• ¿Se han “recalcado” los cambios en el ECS?¿Se han especificado la fecha del
cambio y el autor?¿Reflejan los cambios los atributos del objeto de configuración?
• ¿Se han seguido procedimientos del GCS para señalar el cambio, registrarlo y
divulgarlo?
• ¿Se han actualizado adecuadamente todos los ECS relacionados?

7. GENERACION DE INFORMES

La generación de informes de estado de la configuración es una tarea de GCS que responde

a las siguientes preguntas:

• 1) ¿Qué pasó?
• 2) ¿Quién lo hizo?
• 3) ¿Cuándo pasó?
• 4) ¿Que más se vio afectado?

La generación de informes de estado de la configuración desempeña un papel vital en el

éxito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es
muy fácil que no exista una buena comunicación. Pueden darse errores entre las personas
desarrolladoras del software. El IEC ayuda a eliminar esos problemas, mejorando la
comunicación entre todas las personas involucradas
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE – GRUPO VI
La historia de la garantía de calidad en el desarrollo de software es paralela a la historia de
la calidad en la creación de hardware. Durante los primeros años de la informática (los años
cincuenta y sesenta), la calidad era responsabilidad únicamente del programador. Durante
los años setenta se introdujeron estándares de garantía de calidad para el software en los
contratos militares para desarrollo de software y se han extendido rápidamente a los
desarrollos de software en el mundo comercial.

CONCEPTO DE CALIDAD
La calidad se refiere a las características mensurables -cosas que se pueden comparar con
estándares conocidos como longitud, color, propiedades eléctricas, maleabilidad, etc.-. Sin
embargo, el software en su gran extensión, como entidad intelectual, es más difícil de
caracterizar que los objetos físicos. Cuando se examina un elemento según sus
características mensurables, se pueden encontrar dos tipos de calidad: calidad del diseño y
calidad de concordancia.

La calidad de diseño se refiere a las características que especifican los ingenieros de

software para un elemento. El grado de materiales, tolerancias y las especificaciones del
rendimiento contribuyen a la calidad del diseño.

La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseño

durante su realización. Una vez más, cuanto mayor sea el grado de cumplimento, más alto
será el nivel de calidad de concordancia.

Garantía de la calidad
La garantía de calidad consiste en la auditoría y las funciones de información de la gestión.
El objetivo de la garantía de calidad es proporcionar la gestión para informar de los datos
necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más
profunda y segura de que la calidad del producto está cumpliendo sus objetivos. Por
supuesto, si los datos proporcionados mediante la garantía de calidad identifican problemas,
es responsabilidad de la gestión afrontar los problemas y aplicar los recursos necesarios
para resolver aspectos de calidad.

El control de calidad es una serie de inspecciones, revisiones y pruebas utilizadas a lo

largo del proceso del software para asegurar que cada producto cumple con los requisitos
que le han sido asignados.

El coste de calidad incluye todos los costes acarreados en la búsqueda de la calidad o en

las actividades relacionadas en la obtención de la calidad. Se realizan estudios sobre el
coste de calidad para proporcionar una línea base del coste actual de calidad, para
identificar oportunidades de reducir este coste, y para proporcionar una base normalizada
de comparación.

Los costes de calidad se pueden dividir en costes asociados con la prevención, la

evaluación y los fallos.
Entre los costes de prevención se incluyen:
• planificación de la calidad
• revisiones técnicas formales
• equipo de pruebas
• formación

Entre los costes de evaluación se incluyen actividades para tener una visión más profunda
de la condición del producto «la primera vez a través de» cada proceso. A continuación se
incluyen algunos ejemplos de costes de evaluación:

• inspección en el proceso y entre procesos.

• calibrado y mantenimiento del equipo.
• pruebas.

Los costes de fallos son los costes que desaparecerían si no surgieran defectos antes del
envío de un producto a los clientes. Estos costes se pueden subdividir en costes de fallos
internos y costes de fallos externos.

Los costos de fallos internos se producen cuando se detecta un error en el producto antes
de su envío. Entre estos se incluyen:

• retrabajo (revisión).
• reparación.
• análisis de las modalidades de fallos.

Los costes de fallos externos son los que se asocian a los defectos encontrados una vez
enviado el producto al cliente. A continuación se incluyen algunos ejemplos de costes de
fallos externos:

• resolución de quejas.
• devolución y sustitución de productos.
• soporte de línea de ayuda.
• trabajo de garantía.

Calidad del software

Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos,
con los estándares de desarrollo explícitamente documentados, y con las características
implícitas que se espera de todo software desarrollado profesionalmente.

La anterior definición 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 estándares especificados definen un conjunto de criterios de desarrollo que guían la
forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi
siempre habrá falta de calidad.

3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo:

el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus
requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del Software
queda en entredicho.

Actividades de SQA
La garantía de calidad del software comprende una gran variedad de tareas, asociadas con
dos constitutivos diferentes -los ingenieros de software que realizan trabajo técnico y un
grupo de SQA que tiene la responsabilidad de la Planificación de garantía de calidad,
supervisión, mantenimiento de registros, análisis e informes-. Los ingenieros de software
afrontan la calidad (y realizan garantía de calidad) aplicando métodos técnicos sólidos y
medidas, realizando revisiones técnicas formales y llevando a cabo pruebas de software
bien planificadas. Éstas son las actividades que realizan (o facilitan) un grupo
independiente de SQA:

Establecimiento de un plan de SQA para un proyecto. El plan se desarrolla durante la

planificación del proyecto y es revisado por todas las partes interesadas. Las actividades de
garantía de calidad realizadas por el equipo de ingeniería del software y el grupo SQA son
gobernadas por el plan. El plan identifica:

• evaluaciones a realizar.
• auditorías y revisiones a realizar.
• estándares que se pueden aplicar al proyecto.
• procedimientos para información y seguimiento de errores.
• documentos producidos por el grupo SQA.
• realimentación de información proporcionada al equipo de proyecto del software.

Participación en el desarrollo de la descripción del proceso de software del proyecto.

El equipo de ingeniería del software selecciona un proceso para el trabajo que se va a
realizar. El grupo de SQA revisa la descripción del proceso para ajustarse a la política de la
empresa, los estándares internos del software, los estándares impuestos externamente (por
ejemplo: 1SO 9001), y a otras partes del plan de proyecto del software.

Revisión de las actividades de ingeniería del software para verificar su ajuste al

proceso de software definido. El grupo de SQA identifica, documenta y sigue la pista de
las desviaciones desde el proceso y verifica que se han hecho las correcciones.

Auditoría de los productos de software designados para verificar el ajuste con los
definidos como parte del proceso del software. El grupo de SQA revisa los productos
seleccionados; identifica, documenta y sigue la pista de las desviaciones; verifica que se
han hecho las correcciones, e informa periódicamente de los resultados de su trabajo al
gestor del proyecto.
Asegurar que las desviaciones del trabajo y los productos del software se documentan
y se manejan de acuerdo con un procedimiento establecido. Las desviaciones se pueden
encontrar en el plan del proyecto, en la descripción del proceso, en los estándares aplicables
o en los productos técnicos.

Registrar lo que no se ajuste a los requisitos e informar a sus superiores. Los

elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se resuelven.

Además de estas actividades, el grupo de SQA coordina el control y la gestión de cambios

y ayuda a recopilar y a analizar las métricas del software.

Las revisiones del software

Son un «filtro» para el proceso de ingeniería del software. Esto es, las revisiones Se aplican
en varios momentos del desarrollo del software y sirven para detectar errores y defectos que
pudieran así ser eliminados. Las revisiones del software sirven para «purificar» las
actividades de ingeniería del software que suceden como resultado del análisis, el diseño y
la codificación.

El objetivo primario de las revisiones técnicas formales es encontrar errores durante el

proceso, de forma que se conviertan en defectos después de la entrega del software. El
beneficio obvio de estas revisiones técnicas formales es el descubrimiento de errores al
principio para que no se propaguen al paso siguiente del proceso del software.

Revisión Técnica Formal (RTF)

Una revisión técnica formal (RTF) es una actividad de garantía de calidad del software
llevada a cabo por los ingenieros del software (y otros). Los objetivos de la RTF son:
(1) descubrir errores en la función, la lógica o la implementación de cualquier
representación del software.
(2) verificar que el software bajo revisión alcanza sus requisitos.
(3) garantizar que el software ha sido representado de acuerdo con ciertos estándares
predefinidos.
(4) conseguir un software desarrollado de forma uniforme.
(5) hacer que los proyectos sean más manejables.

La reunión de revisión Independientemente del formato que se elija para la RTF,

cualquier reunión de revisión debe acogerse a las siguientes restricciones:

• Deben convocarse para la revisión (normalmente) entre tres y cinco personas.

• Se debe preparar por adelantado, pero sin que requiera más de dos horas de trabajo a
cada persona.
• La duración de la reunión de revisión debe ser menor de dos horas.

Al final de la revisión, todos los participantes en la RTF deben decidir si

(1) aceptan el producto sin posteriores modificaciones;
(2) rechazan el producto debido a los serios errores encontrados (una vez corregidos, ha
de hacerse otra revisión)
(3) aceptan el producto provisionalmente (se han encontrado errores menores que deben ser
corregidos, pero sin necesidad de otra posterior revisión). Una vez tomada la decisión,
todos los participantes terminan firmando, indicando así que han participado en la revisión
y que están de acuerdo con las conclusiones del equipo de revisión.

La garantía de calidad estadística refleja una tendencia, creciente en toda la industria, a

establecer la calidad más cuantitativamente. Para el software, la garantía de calidad
estadística implica los siguientes pasos:
1. Se agrupa y se clasifica la información sobre los defectos del software.

2. Se intenta encontrar la causa subyacente de cada defecto (por ejemplo, no concordancia

con la especificación, error de diseño, incumplimiento de los estándares, pobre
comunicación con el cliente).

3. Mediante el principio de Pareto (el 80 por 100 de los defectos se pueden encontrar en el
20 por 100 de todas las posibles causas), se aísla el 20 por 100 (los «POCOS vitales»).

4. Una vez que se han identificado los defectos vitales, se actúa para corregir los problemas
que han producido los defectos.

La fiabilidad del software se define en términos estadísticos como «la probabilidad de

operación libre de fallos de un programa de computadora en un entorno determinado y
durante un tiempo específico».

La seguridad del software es una actividad de garantía de calidad del software que se
centra en la identificación y evaluación de los riesgos potenciales que pueden producir un
impacto negativo en el software y hacer que falle el sistema completo. Si se pueden
identificar pronto los riesgos en el proceso de ingeniería del software podrán especificarse
las características del diseño del software que permitan eliminar o controlar los riesgos
potenciales.

El plan de SQA proporciona un mapa para institucionalizar la garantía de calidad del

software. El plan, desarrollado por un grupo de SQA, sirve como plantilla para actividades
de SQA instituidas para cada proyecto de software.

El IEEE ha recomendado un estándar para los planes de SQA. Las secciones iníciales
describen el propósito y el alcance del documento e indican aquellas actividades del
proceso del software cubiertas por la garantía de calidad. Se listan todos los documentos
señalados en el plan de SQA y se destacan todos los estándares aplicables. La sección de
Gestión del plan describe la situación de la SQA dentro de la estructura organizativa; las
tareas y las actividades de SQA y su emplazamiento a lo largo del proceso del software; así
como los papeles y responsabilidades organizativas relativas a la calidad del producto.

La sección de Documentación describe (por referencia) cada uno de los productos de

trabajo producidos como parte del proceso de software. Entre estos se incluyen:
 • Documentos del proyecto (por ejemplo: plan del proyecto).
• Modelos (por ejemplo: DERs, jerarquías de clases),
• Documentos técnicos (por ejemplo: especificaciones, planes de prueba),

Los estándares, prácticas y convenciones muestran todos los estándares/prácticas que se

aplican durante el proceso de software (por ejemplo: estándares de documentos, estándares
de codificación y directrices de revisión). Además, se listan todos los proyectos, procesos y
(en algunos casos) métricas de producto que se van a recoger como parte del trabajo de
ingeniería del software.

La sección Revisiones y Auditorías del plan identifica las revisiones y auditorías que se
van a llevar a cabo por el equipo de ingeniería del software, el grupo de SQA y el cliente.
Proporciona una visión general del enfoque de cada revisión y auditoría.

La sección Prueba hace referencia al Plan y Procedimiento de Pruebas del Software).

También define requisitos de mantenimiento de registros de pruebas.

La Información sobre problemas y acción correctiva define procedimientos para

informar, hacer seguimiento y resolver errores y defectos, e identifica las responsabilidades
organizativas para estas actividades.

El resto del plan de SQA identifica las herramientas y métodos que soportan actividades y
tareas de SQA; hace referencia a los procedimientos de gestión de configuración del
software para controlar el cambio; define un enfoque de gestión de contratos; establece
métodos para reunir, salvaguardar y mantener todos los registros; identifica la formación
que se requiere para cumplir las necesidades del plan y define métodos para identificar,
evaluar, supervisar y controlar riesgos.

ANALISIS Y GESTION DE RIESGOS – GRUPO VII

¿Qué es?
El análisis y la gestión del riesgo son una serie de pasos que ayudan al equipo del software
a comprender y a gestionar la incertidumbre.
Un proyecto de software puede estar lleno de problemas. Un riesgo es un problema
potencial –puede ocurrir o no. Pero sin tener en cuenta el resultado, realmente es una buena
idea identificarlo, evaluar su probabilidad de aparición, estimar su impacto, y establecer un
plan de contingencia por si ocurre el problema.
¿Quién lo hace?
Todos los que estén involucrados en el proceso del software -gestores, ingenieros de
software y
Clientes participan en el análisis y la gestión del riesgo.
¿Por qué es importante?
Pensemos en el lema de los boys scout: «estar preparados ». El software es una empresa
difícil.
Muchas cosas pueden ir mal, y francamente, a menudo van mal. Esta es la razón para estar
preparados –comprendiendo los riesgos y tomando las medidas proactivas para evitarlo o
gestionarles un elemento clave de una buena gestión de proyectos de software.
¿Cuáles son los pasos?
El reconocimiento de que algo puede ir mal es el primer puso, llamado identificación del
riesgo. A continuación, cada riesgo es analizado para determinar la probabilidad de que
pueda ocurrir y el daño que puede causar si ocurre. Una vez establecida esta información,
se priorizan los riesgos, en función de la probabilidad y del impacto. Por último, se
desarrolla un plan para gestionar aquellos riesgos con gran probabilidad e impacto.
¿Cuál es el producto obtenido?
Se realiza un Plan de Reducción, Supervisión y Gestión del Riesgo (RSGR) o un informe
de riesgos.
;Cómo puedo estar seguro de que lo he hecho correctamente?
Los riesgos analizados y gestionados deberían derivarse del estudio del personal, del
producto, del proceso y del proyecto.
El RSGR debe ser revisado mientras el proyecto se realiza para asegurar que los riesgos
están siendo controlados hasta la fecha. Los planes de contingencia para la gestión del
riesgo deben ser realistas.

ESTRATEGIA DE PROYECTOS PROACTIVA VS REACTIVA

la mayoría de los equipos de software confían solamente en las estrategias de riesgo

reactivas. En el mejor de los casos, la estrategia reactiva supervisa el proyecto en previsión
de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en
problemas reales. Pero lo más frecuente es que el equipo de software no haga nada respecto
a los riesgos hasta que algo va mal. Después el equipo vuela para corregir el problema
rápidamente. Este es el método denominado a menudo «de bomberos». Cuando falla, «la
gestión de crisis» entra en acción y el proyecto se encuentra en peligro real.
Una estrategia considerablemente más inteligente para el control del riesgo es ser proactivo.
La estrategia proactiva empieza mucho antes de que comiencen los trabajos técnicos. Se
identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece
una prioridad según su importancia. Después, el equipo de Software establece un plan para
controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden evitar
todos los riesgos, el equipo trabaja para desarrollar un plan de contingencia que le permita
responder de una manera eficaz y controlada.

RIESGO DEL SOFTWARE

El riesgo siempre implica dos características:

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por

ejemplo, no hay riesgos de un 100 por 100 de probabilidad.

Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o

pérdidas.
Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el
grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes
categorías de riesgos.

Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del
proyecto se hacen realidad, es probable que la planificación temporal del proyecto se
retrase y que los costes aumenten. Los riesgos del proyecto identifican los problemas
potenciales de presupuesto, planificación temporal, personal (asignación y organización),
recursos, cliente y requisitos y su impacto en un proyecto de software.

Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay
que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar
a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño,
implementación, de interfaz, verificación y de mantenimiento. Además, las ambigüedades
de especificaciones, incertidumbre técnica, técnicas anticuadas y las «tecnologías punta»
son también factores de riesgo.
Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que
pensábamos.
Los riesgos del negocio amenazan la viabilidad del software a construir.

Los riesgos del negocio a menudo ponen en peligro el proyecto o el producto. Los
candidatos para los cinco principales riesgos del negocio son:

(1) construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de
mercado)
(2) construir un producto que no encaja en la estrategia comercial general de la compañía
(riesgo estratégico)
(3) construir un producto que el departamento de ventas no sabe cómo vender;
(4) perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de
personal (riesgo de dirección);
(5) perder presupuesto o personal asignado (riesgos de presupuesto). Es extremadamente
importante recalcar que no siempre funciona una categorización tan sencilla. Algunos
riesgos son simplemente imposibles de predecir.

Otra categorización general de los riesgos ha sido pre puesta por Charette.
Los riesgos conocidos son todos aquellos que se pueden descubrir después de una
cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial en el que se
desarrolla el proyecto y otras fuentes de información fiables (por ejemplo: fechas de
entrega poco realistas, falta de especificación de requisitos o de ámbito del software, o un
entorno pobre de desarrollo).

Los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (por

ejemplo: cambio de personal, mala comunicación con el cliente, disminución del esfuerzo
del personal a medida que atienden peticiones de mantenimiento).

Los riesgos impredecibles son el comodín de la baraja. Pueden ocurrir, pero son
extremadamente difíciles de identificar por adelantado.

LA IDENTIFICACIÓN DEL RIESGO

Es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones,
planificación temporal, carga de recursos, etc.). Identificando los riesgos conocidos y
predecibles,
el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos
cuando sea necesario.

Existen dos tipos diferenciados de riesgos para cada categoría: riesgos genéricos y riesgos
específicos del producto.

Los riesgos genéricos son una amenaza potencial para todos los proyectos de software.
Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara
visión de la tecnología, el personal y el entorno específico del proyecto en cuestión. Para
identificar los riesgos específicos del producto, se examinan el plan del proyecto y la
declaración del ámbito del software y se desarrolla una respuesta a la siguiente pregunta:
«¿Qué características especiales de este producto pueden estar amenazadas por nuestro plan
del proyecto?» Un método para identificar riesgos es crear una lista de comprobación de
elementos de riesgo.
La lista de comprobación se puede utilizar para identificar riesgos y se centra en un
subconjunto de riesgos conocidos y predecibles en las siguientes sub-categorías genéricas:

Tamaño del producto: riesgos asociados con el tamaño general del software a construir o
a modificar.

Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o
por el mercado.

Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad
del desarrollador para comunicarse con el cliente en los momentos oportunos.

Definición del proceso: riesgos asociados con el grado de definición del proceso del
software y su
Seguimiento por la organización de desarrollo.

Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las

herramientas que se van a emplear en la construcción del producto.

Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la

tecnología punta que contiene el sistema.

Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de

proyectos de los ingenieros del software que van a realizar el trabajo.

Evaluación Global del Riesgo del Proyecto

Las siguientes preguntas provienen de los datos del riesgo obtenidos mediante las encuestas
realizadas a gestores de proyectos de software expertos de diferentes partes del mundo. Las
preguntas están ordenadas por su importancia relativa para el éxito de un proyecto.

1. ¿Se han entregado los gestores del software y clientes formalmente para dar soporte al
proyecto?

2. ¿Están completamente entusiasmados los usuarios finales con el proyecto y con el

sistema/producto a construir?

3. ¿Han comprendido el equipo de ingenieros de software y los clientes todos los

requisitos?

4. ¿Han estado los clientes involucrados por completo en la definición de los requisitos?

5. ¿Tienen los usuarios finales expectativas realistas?

6. ¿Es estable el ámbito del proyecto?

7. ¿Tiene el ingeniero de software el conjunto adecuado de habilidades?

8. ¿Son estables los requisitos del proyecto?

9. ¿Tiene experiencia el equipo del proyecto con la tecnología a implementar?

10. ¿Es adecuado el número de personas del equipo del proyecto para realizar el trabajo?

11. ¿Están de acuerdo todos los clientes/usuarios en la importancia del proyecto y en los
requisitos del sistema/producto a construir?

COMPONENTES Y CONTROLADORES DEL RIESGO

Las Fuerzas Aéreas de Estados Unidos han redactado un documento que contiene
excelentes directrices para identificar riesgos del software y evitarlos. El enfoque de las
Fuerzas Aéreas requiere que el gestor del proyecto identifique los controladores del riesgo
que afectan a los componentes de riesgo del software -rendimiento, coste, soporte y
planificación temporal-.
En el contexto de este estudio, los componentes de riesgo se definen de la siguiente manera:

Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus

requisitos y se adecue para su empleo pretendido.

Riesgo de coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto.

Riesgo de soporte: el grado de incertidumbre de la facilidad del software para corregirse,

adaptarse y ser mejorado.

Riesgo de la planificación temporal: el grado de incertidumbre con que se podrá

mantener la planificación temporal y de que el producto se entregue a tiempo.

El impacto de cada controlador del riesgo en el componente de riesgo se divide en cuatro

categorías de impacto -despreciable, marginal, crítico y catastrófico-.

LA PROYECCIÓN DEL RIESGO

También denominada estimación del riesgo, intenta medir cada riesgo de dos maneras -la
probabilidad de que el riesgo sea real y las consecuencias de los problemas asociados con el
riesgo, si ocurriera-. El jefe del proyecto, junto con otros gestores y personal técnico,
realiza cuatro actividades de una de riesgo de proyección del riesgo:

(1) establecer una escala que refleje la probabilidad percibida del riesgo.
(2) definir las consecuencias del riesgo.
(3) estimar el impacto del riesgo en el proyecto y en el producto.
(4) apuntar la exactitud general de la proyección del riesgo de manera que no haya
confusiones.

REFINAMIENTO DEL RIESGO

Durante las primeras etapas de la planificación del proyecto, un riesgo puede ser declarado
de un modo muy general. Con el paso del tiempo y con el aprendizaje sobre el proyecto y
sobre el riesgo, es posible refinar el riesgo en un conjunto de riesgos más detallados, cada
uno algo más fácil de reducir, supervisar y gestionar.

REDUCCION, SUPERVISION Y GESTION DEL RIESGO

Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo
-ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos-. Una
estrategia eficaz debe considerar tres aspectos:
 • Evitar el riesgo
• Supervisar el riesgo, y
• Gestionar el riesgo y planes de contingencia.

Para reducir el riesgo, la gestión del proyecto debe desarrollar una estrategia para reducir la
movilidad. Entre los pasos que se pueden tomar:

• Reunirse con la plantilla actual y determinar las causas de la movilidad (por

ejemplo: malas condiciones de trabajo, salarios bajos, mercado laboral competitivo).

• Actuar para reducir esas causas que estén al alcance de nuestro control antes de que
comience el proyecto.

• Una vez que comienza el proyecto, asumir que habrá movilidad y desarrollar
técnicas que aseguren la continuidad cuando se vaya la gente.

• Organizar los equipos del proyecto de manera que la información sobre cada
actividad de desarrollo esté ampliamente dispersa.

• Definir estándares de documentación y establecer mecanismos para estar seguro de

que los documentos se cumplimentan puntualmente.

A medida que progresa el proyecto, comienzan las actividades de supervisión del riesgo. El
jefe del proyecto supervisa factores que pueden proporcionar una indicación sobre si el
riesgo se está haciendo más o menos probable. En el caso de gran movilidad del personal,se
pueden supervisar los siguientes factores:

• Actitud general de los miembros del equipo basándose en las presiones del
proyecto;
• Grado de compenetración del equipo;
• Relaciones interpersonales entre los miembros del equipo;
• Problemas potenciales con compensaciones y beneficios;
• Disponibilidad de empleo dentro y fuera de la compañía.

RIESGO Y PELIGROS PARA LA SEGURIDAD

El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos después

de haber desarrollado con éxito el software y de haberlo entregado al cliente. Estos riesgos
están típicamente asociados con las consecuencias del fallo del software una vez en el
mercado.

La seguridad del software y el análisis del peligro son actividades para garantizar la calidad
del software (Capítulo 8) que se centra en la identificación y evaluación de peligros
potenciales que pueden impactar al software negativamente y provocar que falle el sistema
entero. Si se pueden identificar los peligros al principio del proceso de ingeniería del
software, se pueden especificar características de diseño software que eliminen o controlen
esos peligros potenciales.

EL PLAN RSGR

Se puede incluir una estrategia de gestión de riesgo en el plan del proyecto de software o se
podrían organizar los pasos de gestión del riesgo en un Plan diferente de reducción,
supervisión y gestión del riesgo (Plan RSGR). Todos los documentos del plan RSGR se
llevan a cabo como parte del análisis de riesgo y son empleados por el jefe del proyecto
como parte del Plan del Proyecto general. Algunos equipos de software no desarrollan un
documento RSGR formal. Más bien, cada riesgo se documenta utilizando una hoja de
información de riesgo.

La reducción del riesgo es una actividad para evitar problemas. La supervisión del riesgo es
una actividad de seguimiento del proyecto con tres objetivos principales:

(1) evaluar cuando un riesgo previsto ocurre de hecho;

(2) asegurarse de que los procedimientos para reducir el riesgo definidos para el riesgo en
cuestión se están aplicando apropiadamente;
(3) recoger información que pueda emplearse en el futuro para analizar riesgos.

TECNICAS DE PRUEBA DEL SOFTWARE – GRUPO VIII

Una vez generado el código fuente, el software debe ser probado para descubrir y corregir
errores el máximo de errores posible antes de su entrega al cliente. Aquí es donde se
aplican las técnicas de prueba de software. Estas técnicas facilitan una guía sistemática para
diseñar pruebas que:

• Comprueben la lógica interna de los componentes de software.

• Verifiquen los dominios de entrada y salida del programa para descubrir errores en
la funcionalidad, el comportamiento y el rendimiento.

DISENO DE CASOS DE PRUEBA

Cualquier producto de ingeniería (y de muchos otros campos) puede probarse de una de
estas dos formas:

(1) conociendo la función específica para la que fue diseñado el producto, se pueden llevar
a cabo pruebas que demuestren que cada función es completamente operativa y, al mismo,
tiempo buscando errores en cada función;

(2) conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren
que «todas las piezas encajan», o sea, que la operación interna se ajusta a las
especificaciones y que todos los componentes internos se han comprobado de forma
adecuada.
El primer enfoque de prueba se denomina prueba de caja negra y el segundo, prueba de
caja blanca.

La prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del
software. O sea, los casos de prueba pretenden demostrar que las funciones del software
son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado
correcto, así como que la integridad de la información externa (por ejemplo, archivos de
datos) se mantiene. Una prueba de caja negra examina algunos aspectos del modelo
fundamental del sistema sin tener mucho en cuenta la estructura lógica interna del software.

La prueba de caja blanca del software se basa en el minucioso examen de los detalles
procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de
prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el
«estado del programa» en varios puntos para determinar si el estado real coincide con el
esperado o mencionado.