Este capítulo discute la ingeniería de software y los procesos de desarrollo de software. Explica que el desarrollo de software es una tarea difícil que involucra aspectos funcionales, ergonómicos y educativos. También introduce el concepto de proceso de software y discute los modelos y estándares internacionales de procesos de desarrollo de software. Finalmente, define la ingeniería de software y explica su importancia para el desarrollo de software de calidad.

1. Cap´
ıtulo 5
Ingenier´ de software
ıa
El desarrollo de sistemas de informaci´n se caracteriza por ser una dif´
o ıcil
empresa. El grado de dificultad se incrementa cuando el software producido
tiene caracter´
ısticas educativas. Ante esto, se verifica que el desarrollo de
software educativo integra tanto los aspectos ergon´micos (i.e. aquellos estu-
o
diados en la ingenier´ de usabilidad) y los aspectos educativos (i.e. aquellos
ıa
estudiados por las teor´ educativas), como los aspectos funcionales (i.e.
ıas
aquellos estudiados por la ingenier´ de software).
ıa
De esta manera, se a˜ade a la presente tesis la ingenier´ de software
n ıa
en donde se investigan, desde el enfoque basado en procesos1 , los siguientes
aspectos:
• El an´lisis y dise˜o de modelos conceptuales de flujos de trabajo.
a n
• Su estructura de organizaci´n.
o
1
De acuerdo con Hammer y Champy (1993), la mayor´ de las personas de negocios no
ıa
usan el enfoque de an´lisis y dise˜o basado en proceso, sino que usan enfoques orientado
a n
a tareas, a trabajo, a personas y a estructuras.
130

2. 131
• La gesti´n y control de calidad.
o
En este cap´
ıtulo, se presentan los conceptos fundamentales para el en-
tendimiento de los v´
ınculos existentes entre la ingenier´ de software y el
ıa
modelo de test propuesto (v´ase Cap´
e ıtulo 7). El panorama presentado parte
de la definici´n de software y sus caracter´
o ısticas, pasando por los modelos
y est´ndares internacionales de proceso de software, hasta la definici´n de
a o
modelos de proceso de test.

3. 132
5.1 El software y su ingenier´
ıa
El software es un sistema inform´tico compuesto por un conjunto de ins-
a
trucciones que, cu´ndo se ejecutan en un dispositivo f´
a ısico (i.e. el hardware)
produce resultados de acuerdo con los objetivos y funci´n principal prede-
o
terminada. Dicho conjunto de instrucciones est´ organizado en estructuras
a
de datos2 que permiten la manipulaci´n de la informaci´n. Seg´n Pressman
o o u
(1995), el ingenio del “desarrollador” (o del equipo de desarrollo) es el unico
´
aspecto que limita el dise˜o (i.e. organizaci´n y complejidad) de una es-
n o
tructura de datos, aunque existen algunas estructuras de datos cl´sicas (e.g.
a
escalar, vector secuencial, listas encadenadas y ´rbol jer´rquica) que pueden
a a
ser usadas para la construcci´n de estructuras m´s complejas.
o a
La estructura de datos asociada al tipo de hardware usado influye de-
cisivamente en el desempe˜o del software. As´ pues, durante el dise˜o y
n ı n
programaci´n de un software es importante seleccionar el tipo de estructura
o
de datos m´s adecuado respecto al tipo de procesamiento previsto.
a
Usando el concepto abstracto del software (i.e. parte l´gica del sis-
o
tema “computacional”3 ) como punto de partida, se presentan algunas car-
acter´
ısticas que distinguen el software del hardware y ofrecen una buena
2
De acuerdo con Pressman (1995, p. 432-433),
“la estructura de datos es una representaci´n de la relaci´n l´gica entre e-
o o o
lementos de datos individuales. (...) La estructura de datos determina la
organizaci´n, los m´todos de acceso, el grado de asociatividad y las alterna-
o e
tivas de procesamiento de informaciones”.
3
Se define un sistema “computacional” como un entorno de trabajo, estudio, entrete-
nimiento u otra actividad, el cual est´ compuesto por tres elementos interrelacionados: el
a
software (i.e. la parte l´gica), el hardware (i.e. la parte f´
o ısica) y el peopleware (i.e. la
parte humana).

4. 133
compresi´n de su significado (Pressman, 1995):
o
• Su desarrollo o proyecto no se basa en manufactura cl´sica sino que en
a
la ingenier´
ıa.
• Considerando que un determinado software est´ implantado, ´ste no
a e
se deteriora con el tiempo, la suciedad, las temperatura altas y la vi-
braci´n, como es el caso del hardware. Por otra parte, la evoluci´n
o o
del hardware impone cambios de paradigmas en la filosof´ de dise˜o
ıa n
del software, de manera que se identifica la implementaci´n de nuevas
o
versiones con el prop´sito de adaptarlas a las nuevas tecnolog´
o ıas.
• La mayor´ de los sistemas inform´ticos son desarrollados a medida
ıa a
(i.e. se concibe el software como una unidad completa). Sin embar-
go, actualmente se observa una tendencia que consiste en dise˜ar y
n
implementar componentes de software que puedan ser usados seg´n la
u
necesidad. En la literatura, se pueden encontrar diversos estudios sobre
el tema (e.g. Veryard (1997) y Garc´ y Fuente (2000)).
ıa
En este sentido, se desarrolla un software con el objetivo de facilitar
todas aquellas tareas en d´nde se verifica la necesidad de procesamiento de
o
grandes cantidades de informaciones. Esto implica la determinaci´n de ´reas
o a
de aplicaci´n de software (e.g. software b´sico, de tiempo real, comercial,
o a
cient´
ıfico y de ingenier´ educativo, etc.), lo que, seg´n Pressman (1995), es
ıa, u
una tarea dif´
ıcil. Dentro el contexto de la presente investigaci´n, se trata
o
con el software educativo representado las aplicaciones multimedia usadas en
educaci´n y formaci´n a distancia.
o o

5. 134
Zahran (1998) argumenta que el desarrollo de software, m´s que un in-
a
tento, es una empresa caracterizada por un proceso continuado de desaf´
ıo.
Adem´s, la influencia del software dentro del mundo de los negocios y de la
a
vida cotidiana de las personas se vuelve cr´
ıtica debido no s´lo a los problemas
o
conceptuales y de dise˜o, sino tambi´n a los problemas t´cnicos y econ´micos
n e e o
generados durante el proyecto de software.
Las propuestas acad´micas y de la industria para reducci´n de estos pro-
e o
blemas como por ejemplo las herramientas CASE4 y las metodolog´ de
ıas
desarrollo, han permitido que el software evolucionara provocando, a partir
de las necesidades creadas, la aparici´n de una nueva disciplina: la ingenier´
o ıa
de software.
Dicha disciplina, incluyendo la ingenier´ de usabilidad (v´ase Cap´
ıa e ıtulo
4), define est´ndares para el desarrollo de software de calidad basados en
a
diversos indicadores como, por ejemplo, la correcci´n, la eficacia, la eficiencia,
o
la fiabilidad, la facilidad de comprensi´n, de uso y de mantenimiento, la
o
interoperabilidad, la portabilidad, la reusabilidad y la robustez.
De acuerdo con Naur y Randall (1968), la ingenier´ de software es
ıa
“el establecimiento y uso de s´lidos principios de ingenier´a con
o ı
el prop´sito de obtener econ´micamente un software que sea fiable
o o
y que funcione eficientemente en m´quina reales”.
a
Humphrey (1989) presenta una definici´n similar resaltando, de manera
o
4
La sigla CASE es acr´nimo de Computer-Aided Software Engineering. Esta herramien-
o
ta consiste en un sistema compuesto por software, hardware y una base de datos que ofrece
soporte a la ingenier´ de software, permitiendo el an´lisis estructurado, la implementaci´n
ıa a o
y test de sistemas inform´ticos.
a

6. 135
general, la calidad del software. Usando la definici´n citada anteriormente
o
como punto de partida, Totland y Conradi (1995) comentan que el area
´
de modelado del proceso de software (software process modeling) puede ser
considerado como un subdominio de la ingenier´ de software.
ıa
El desarrollo formal de software se caracteriza por la definici´n de los
o
requerimientos de la aplicaci´n, la especificaci´n de los objetivos, el dise˜o
o o n
iterativo, los procesos continuados de test y la implementaci´n del software.
o
Para cada una de estas actividades se dise˜an procesos (y subprocesos) que
n
ser´n implementados a trav´s de un lenguaje de programaci´n.
a e o
Considerando la perspectiva del dise˜o centrado en el usuario (v´ase Sec-
n e
ciones 4.4 y 4.6, p´ginas 101 y 122 respectivamente), el estudio y la evoluci´n
a o
de los m´todos y t´cnicas de control y gesti´n de la calidad han sido deter-
e e o
minantes para la creaci´n de la ingenier´ de usabilidad.
o ıa
´
Esta se caracteriza por ser uno de los macro-procesos de la ingenier´
ıa
de software. En este sentido, Sulaiman (1996) presenta una propuesta de
integrar la usabilidad al ciclo de vida de producci´n de software a trav´s de
o e
la inserci´n de m´todos de medici´n de calidad de software y en las fases
o e o
iniciales de proyecto.
Se realiza la integraci´n a partir de la definici´n de los procesos de soft-
o o
ware. Por lo tanto, se presentan en las pr´ximas secciones la contextuali-
o
zaci´n y conceptualizaci´n necesaria del enfoque de dise˜o y desarrollo de
o o n
software orientado a procesos. De esta manera, se concentra el estudio en las
actividades de mejora de procesos de software y procesos de test.

7. 136
5.1.1 Proceso de software
Para lograr el entendimiento de proceso de software, es necesario, en primer
lugar, presentar una definici´n de proceso. En la literatura, se puede en-
o
contrar una amplia variedad de definiciones de la palabra “proceso”. Por
consiguiente, se observa que dentro de esta variedad existen distintas inter-
pretaciones, sean por extensi´n, cobertura o orientaci´n (Zahran, 1998).
o o
Hammer y Champy (1993, p. 35) presentan una definici´n adecuada para
o
el ´mbito de la presente tesis debido a su car´cter general. Seg´n los autores,
a a u
un proceso es
“una colecci´n de actividades que toman uno o m´s tipos de en-
o a
tradas y crea una salida que es de valor para cliente”.
En el contexto de la presente investigaci´n, la colecci´n de actividades
o o
se caracteriza por todos los procedimientos que componen el ciclo de vida
de software (i.e. procesos de concepci´n, dise˜o, desarrollo, mantenimiento,
o n
documentaci´n, control de calidad, test, gesti´n, entrenamiento, etc.) desde
o o
las fases iniciales hasta su uso por el cliente (i.e. el usuario final). Cabe re-
saltar que un software se caracteriza por tres grandes actividades: la entrada
de datos, su procesamiento y la salida de las informaciones procesadas.
De acuerdo con Zahran (1998), un proceso est´ compuesto por tres as-
a
pectos. El primer aspecto es la definici´n del proceso que generalmente est´
o a
representado por un documento que especifica las actividades y procedimien-
tos para el proceso. El segundo aspecto se refiere a la transferencia del
conocimiento del proceso para aquellos que lo van a ejecutar. Finalmente, el

8. 137
tercer aspecto son los resultados obtenidos del proceso despu´s de su ejecu-
e
ci´n. Seg´n el autor, el enfoque orientado a proceso permite:
o u
• La sincronizaci´n y armon´ entre las actividades desempe˜adas por
o ıa n
cada individuo y los objetivos comunes del equipo.
• La garant´ de la consistencia de las actividades y sus resultados.
ıa
• El uso de t´cnicas objetivas de medici´n del desempe˜o de cada indi-
e o n
viduo respecto a las actividades asignadas.
• Debido a la reducci´n de la dependencia en cada individuo, se consigue
o
que el equipo pueda repetir un determinado proceso, aunque individuos
ajenos sean asignados a la actividad.
Por otra parte, seg´n Curtis, Kellner y Over (1992), las perspectivas
u
en la representaci´n del proceso son la funcional, la de conducta, la de la
o
organizaci´n y la de la informaci´n. Usando la definici´n de proceso y sus
o o o
consideraciones como punto de partida, Boehm (1988, p. 61) argumenta que
“las funciones primarias de un modelo de proceso de software son
determinar el orden de las fases involucradas en el desarrollo y
evoluci´n de software y establecer los criterios de transici´n para
o o
avanzar de una fase a la pr´xima”.
o
La ingenier´ del software comprende un conjunto estructurado de pa-
ıa
sos que representan los “paradigmas de la ingenier´ del software”. Estos
ıa
paradigmas se basan en la naturaleza del proyecto y de la aplicaci´n, en los
o
m´todos y las herramientas que ser´n usados en el proyecto, los controles y
e a
los productos o servicios desarrollados (Pressman, 1995).

9. 138
5.2 Ciclo vida de software
En la literatura, se pueden encontrar varios modelos de ciclo de vida de
desarrollo de software. Todos ellos se basan en diversos aspectos tales como
la planificaci´n, el an´lisis, el dise˜o e implementaci´n de software. Cada uno
o a n o
de estos m´todos est´n asociados a los marcos y paradigmas tecnol´gicos de
e a o
su entorno y ´poca.
e
A continuaci´n, se presenta una revisi´n de los modelos de ciclo de vida
o o
de desarrollo de software.
5.2.1 Modelo codificar-y-fijar
Boehm (1988) comenta que en la ´poca inicial del desarrollo de software, se
e
´
ha usado el modelo codificar-y-fijar (code-and-fix). Este contiene dos pasos:
• Escribir alg´n c´digo.
u o
• Fijar los problemas en el c´digo.
o
De esta manera, inicialmente se implementaba alg´n c´digo y, a continua-
u o
ci´n, se pensaba sobre los requerimientos, el dise˜o, los test y el mantenimien-
o n
to. Las principales dificultades del modelo consisten en la estructuraci´n in-
o
suficiente de c´digo, la carencia de correspondencia con las necesidades del
o
usuario y el coste excesivo debido a la deficiente preparaci´n de los test y
o
modificaciones.
Ante esto, se observa la necesidad de reorganizaci´n del modelo en etapas,
o
incorporando elementos de planificaci´n, coordinaci´n y control.
o o

10. 139
5.2.2 Modelo de etapas
A partir de la necesidad de construir grandes sistemas de software (e.g. Semi-
Automated Ground Environment - SAGE), el modelo de etapas ha sido desa-
rrollado con el prop´sito de facilitar la mejora de los problemas involucrados
o
en los proyectos de software (Benington, 1956). El modelo determina que el
software ser´ desarrollado en etapas consecutivas:
a
• Plan operativo.
• Especificaci´n operativa.
o
• Especificaci´n de codificaci´n.
o o
• Codificaci´n o implementaci´n.
o o
• Test de par´metros.
a
• Test de integraci´n o montaje.
o
• Registro (shakedown).
• Evaluaci´n del sistema.
o
Adem´s, el modelo enfatiza la documentaci´n resultante de cada una de
a o
las etapas, de manera que formaliza los procedimientos de planificaci´n y
o
de control. No obstante, se identifica no s´lo una laguna entre el equipo
o
de desarrollo, caracterizado b´sicamente por la figura del programador, y el
a
usuario del software, sino tambi´n la necesidad de rehacer todo el sistema
e
cuando se detectan problemas en su instalaci´n.
o

11. 140
5.2.3 Modelo en cascada
Este modelo, tambi´n conocido como ciclo de vida cl´sico (Pressman, 1995)
e a
ha sido inicialmente presentado por Royce (1970) y se caracteriza por un
refinamiento del modelo de etapas, en el cual se realza los ciclos de retroali-
mentaci´n entre las etapas con el objetivo de minimizar el coste de retrabajo
o
del proyecto. El modelo incorpora el “prototipaje” al ciclo de vida de desa-
rrollo de software. En la Figura 5.1, se presentan la etapas del modelo.
Viabilidad del
sistema
Validación
Planes y requerimien-
tos de software
Validación
Diseño del producto
Verificación
Diseño detallado
Verificación
Código
Test de unidad
Integración
Verificación
del producto
Implementación
Test del sistema
Operaciones y
mantenimiento
Revalidación
Figura 5.1: El modelo en cascada del proceso de software. Fuente: Boehm
(1988)

12. 141
Aunque los ciclos de retroalimentaci´n permitan realizar extensas revi-
o
siones y refinamientos, se identifican algunas dificultades causadas por el
´nfasis en la elaboraci´n de documentos completos como criterios de fina-
e o
lizaci´n para las etapas de requerimientos y dise˜o.
o n Por otra parte, se
observa la problem´tica de su aplicaci´n a sistemas interactivos, debido,
a o
una vez m´s, al distanciamiento entre los usuarios y el equipo de desarrollo
a
(Boehm, 1988; Sommerville, 1996).
5.2.4 Modelo de desarrollo orientado a prototipos
Este modelo consiste en un procedimiento que permite al equipo de desarrollo
dise˜ar y analizar una aplicaci´n que representa el sistema que ser´ imple-
n o a
mentado (McCracken y Jackson, 1982). Dicha aplicaci´n, llamada prototipo,
o
est´ compuesta por los componentes que se desean evaluar (i.e. las funciones
a
principales). Las etapas del modelo son:
• Investigaci´n preliminar.
o
• Colecta y refinamiento de los requerimientos y proyecto r´pido:
a
– An´lisis y especificaci´n del prototipo.
a o
– Dise˜o y construcci´n del prototipo.
n o
– Evaluaci´n del prototipo por el cliente.
o
– Refinamiento del prototipo.
• Dise˜o t´cnico.
n e
• Programaci´n y test.
o

13. 142
• Operaci´n y mantenimiento.
o
De acuerdo con Pressman (1995), los problemas identificados en el modelo
de desarrollo orientado a prototipos consisten, por una parte, en que “se ve
lo que parece ser” (i.e. lo que el usuario examina es una representaci´n
o
del sistema con funcionalidades restringidas), por tanto, no se considera la
calidad global del software, ni sus aspectos de mantenimiento. Por otra parte,
el equipo de desarrollo hace concesiones de implementaci´n basadas en el uso
o
de sistemas operativos y lenguajes de programaci´n impropios, sin importar
o
la inadecuaci´n posterior del producto.
o
5.2.5 Modelo de desarrollo evolutivo
De acuerdo con Boehm (1988), las etapas del modelo de desarrollo evolutivo
“consisten en expandir los incrementos de un producto de software
operativo, siendo las direcciones de evoluci´n determinadas por la
o
experiencia operativa”.
Se identifica, por tanto, la importancia en la obtenci´n de un sistema de
o
producci´n flexible y expansible, permitiendo la adaptaci´n de los cambios
o o
de requerimientos que no han sido planeados. Se asocia este modelo a un
lenguaje de cuarta generaci´n. En este sentido, Sommerville (1996) comenta
o
que este modelo es el m´s apropiado para el desarrollo de sistemas interactivos
a
y de sistemas de inteligencia artificial. Las etapas b´sicas del modelo son:
a
• Especificaci´n inicial.
o
• Desarrollo del producto o servicio.

14. 143
• Implementaci´n.
o
• Uso.
• Evaluaci´n.
o
• Nuevas versiones.
• Re-especificaci´n.
o
Sin embargo, se observan algunas dificultades t´cnicas como, por ejemplo,
e
la problem´tica de la integraci´n de aplicaciones independientes, los casos de
a o
“esclerosis de informaci´n” debido a los trabajos temporales alrededor de
o
algunas deficiencias del software y el reemplazo de un nuevo software en un
gran sistema existente (Boehm, 1988).
5.2.6 Modelo de transformaci´n
o
El modelo de transformaci´n ha sido propuesto como una soluci´n a las difi-
o o
cultades de c´digo del modelo de desarrollo evolutivo y del modelo codificar-
o
y-fijar analizado dentro del modelo en cascada. Desde la optica de Boehm
´
(1988, p. 63) el modelo
“asume la existencia de una capacidad de convertir autom´ticamente
a
una especificaci´n formal de un producto de software en un pro-
o
grama que satisfaga la especificaci´n”.
o
Seg´n el autor, los pasos de este modelo son:
u
• Especificaci´n formal del mejor entendimiento inicial del producto de-
o
seado.

15. 144
• Transformaci´n autom´tica de la especificaci´n en c´digo.
o a o o
• Un ciclo iterativo, si necesario, para mejorar el desempe˜o del c´digo
n o
resultante, lo que ofrece una gu´ de optimizaci´n al sistema de trans-
ıa o
formaci´n.
o
• Ejercicio o evaluaci´n del producto resultante.
o
• Un ciclo interactivo externo para ajustar las especificaciones basadas en
el resultado de la experiencia operativa, y para rederivar, reoptimizar,
y ejercitar o evaluar el producto de software ajustado.
Las dificultades del modelo se caracterizaban por la carencia generali-
zada de capacidades de transformaci´n autom´ticas s´lo disponibles para
o a o
peque˜os productos, la posibilidad de evoluci´n no planeada y los problemas
n o
de mantenimiento de base de conocimiento.
5.2.7 Modelo espiral
Boehm (1988) presenta el modelo espiral del proceso de software (v´ase Figu-
e
ra 5.2), el cual ha evolucionado bas´ndose en los diversos refinamientos del
a
modelo en cascada y del desarrollo orientado a prototipos. El modelo espiral
se caracteriza por un conjunto de ciclos progresivos, en los cuales se identi-
fican los objetivos de cada parte del producto que est´ siendo desarrollado,
a
las propuestas alternativas de implementaci´n y las restricciones impuestas
o
por dichas alternativas al software.

16. 145
Planeamiento Coste acumulado Análisis de riegos
Determinar Progreso a través
de las fases Evaluar
objetivos, alternativas,
alternativas, identificar y
restricciones resolver riegos
Análisis de
riesgos (AR)
AR
AR
Prototipo Prototipo
AR Prototipo
3
Revisión
Comprometimiento Prototipo 1 2 operativo
Partición Plan de Simulaciones,
Modelos, Está
requisitos, Concepto de ndares
operación os
it re o- e
Plan de ciclo is r
l p ar
qu wa de ftw
de vida Re soft
ño o
Plan de ación de se e s Diseño detallado
Valid sitos Di to d
desarro qui du
c
de re
Test de unidad
llo ión y
Plan de
test e ficac diseño
Veri del
Código
Planificar las
Integración y
integrac ción
ión a
siguientes fases valid
aceptación
Desarrollar y
Implemen-
test
Test de
tación
verificar el
producto en el
siguiente nivel
Evaluación del cliente Ingeniería
Figura 5.2: El modelo espiral del proceso de software. Fuente: Boehm (1988)
El modelo se divide en cuatro cuadrantes que representan las actividades
principales para el ciclo de vida de desarrollo de software, resumidos por
Pressman (1995) en:
• Planeamiento.
• An´lisis de riegos.
a
• Ingenier´
ıa.
• Evaluaci´n del cliente.
o

17. 146
De acuerdo con Boehm (1988, p. 65) el ciclo de vida propuesto por el
modelo se basa en cuatro preguntas fundamentales:
1. “¿C´mo empieza la espiral?”
o
2. “¿C´mo uno rompe los ciclos de la espiral cuando es apropiado termi-
o
nar un proyecto apenas iniciado?”
3. “¿Por qu´ la espiral se acaba bruscamente?”
e
4. “¿Qu´ pasa con la mejora (o el mantenimiento) del software?”
e
Debido a la reducci´n de riesgos determinada por el m´todo evolutivo
o e
del modelo, ´ste representa un enfoque m´s apropiado para el desarrollo de
e a
grandes, complejos y ambiciosos sistemas de informaci´n. Adem´s, el modelo
o a
espiral posee un nivel alto de capacidades de entorno de soporte de software y
es flexible, lo que permite acomodar diversas alternativas t´cnicas y objetivos
e
de usuario.
5.3 Modelos y est´ndares internacionales de
a
proceso de software
Como se ha comentado, la presente investigaci´n se basa en el an´lisis de las
o a
interrelaciones entre los aspectos ergon´micos y el aprendizaje del usuario de
o
aplicaciones multimedia en entornos de formaci´n a distancia. Para ello, se
o
definen en las Seccione 5.1 y 5.2 de este cap´
ıtulo, los fundamentos te´ricos
o
sobre la ingenier´ de software.
ıa

18. 147
En consecuencia, se puede decir que a trav´s de los modelos y est´ndares
e a
de evaluaci´n de proceso de software se podr´ establecer estrategias para la
o a
definici´n de criterios de evaluaci´n de usabilidad de sistemas interactivos
o o
multimedia.
5.3.1 Capability Maturity Model for Software
Paulk, Curtis, Chrissis y Weber (1993) definen el modelo de madurez de
capacidad (Capability Maturity Model - CMM) como un modelo que establece
los niveles por los cuales las organizaciones de software hacen evolucionar
sus definiciones, implementaciones, mediciones, controles y mejor´ de sus
ıas
procesos de software.
Adem´s, el CMM permite la definici´n del grado de madurez de las
a o
pr´cticas de gesti´n y de ingenier´ de software de dichas organizaciones.
a o ıa
De esta manera, se puede determinar c´mo madura una determinada orga-
o
nizaci´n y cuales son las acciones de mejora prioritarias para sus procesos de
o
software.
El enfoque inicial del CMM ha sido el proceso de software. Sin embargo,
se puede encontrar aplicaciones del modelo en otros campos como por ejem-
plo CMM para personas (People CMM), CMM para ingenier´ de sistemas
ıa
(Systems Engineering CMM), CMM para la gesti´n de productos integrados
o
(Integrated Product Management CMM) y otros (Zahran, 1998).

19. 148
5.3.1.1 Estructura del CMM
El esquema del modelo CMM est´ compuesto por cinco niveles de madurez de
a
acuerdo con la capacidad del proceso de software y definidos por los objetivos
de los procesos que, cuando satisfechos, permiten evolucionar al pr´ximo nivel
o
ya que uno o m´s componentes importantes del proceso de software han sido
a
estabilizados (Paulk, Curtis, Chrissis y Weber, 1993). De esta manera, los
niveles de madurez ayudan a las organizaciones a definir prioridades para
sus esfuerzos de mejora. En la Figura 5.3, se presenta los cinco niveles de
madurez del proceso de software.
• Nivel 1 - Inicial: se caracteriza como ad hoc o ca´tico. Pocos procesos
o
son definidos.
• Nivel 2 - “Repetible” o repetici´n: se caracteriza como disciplinado. Se
o
establecen procesos b´sicos de gesti´n.
a o
• Nivel 3 - Definido: se caracteriza como est´ndar y consistente.
a
• Nivel 4 - Gestionado: se caracteriza como predicable. Hay un preocu-
paci´n en la medici´n detallada de la calidad del proceso de software y
o o
del producto.
• Nivel 5 - Optimizaci´n: se caracteriza como mejora continua a partir
o
de la realimentaci´n (feedback) cuantitativa.
o
Cada nivel de madurez tiene una estructura interna (v´ase Figura 5.4)
e
compuesta por los siguientes componentes:

20. 149
Mejora
Optimización
continuada
(5)
de proceso
Proceso Gestionado
predicable (4)
Estándar,
Definido
proceso
(3)
consistente
Proceso "Repetible"
disciplinado (2)
Inicial
(1)
Figura 5.3: Los niveles de madurez del proceso de software del CMM. Fuente:
Paulk, Curtis, Chrissis y Weber (1993)

21. 150
• Nivel de madurez: Representa un indicador evolutivo que permite al-
canzar la madurez del proceso de software.
´
• Areas de proceso clave (Key Process Areas - KPA): Son las subestruc-
turas de cada nivel que indican las areas a las que una organizaci´n
´ o
deber´ dirigir su atenci´n con el prop´sito de mejorar su proceso de
ıa o o
software. Se asigna cada conjunto de KPA a un nivel de madurez (ex-
cepto al nivel uno), como se muestra en la Figura 5.5. Zahran (1998)
comenta que el CMM no detalla todas las areas de proceso involu-
´
cradas en el desarrollo y mantenimiento de software, sino que se enfoca
en las ´reas clave que contribuyen en la mayor´ de las capacidades de
a ıa
proceso.
• Objetivos: Este componente delimita las KPA a trav´s de la definici´n
e o
de su alcance, l´
ımites y intenciones. Los objetivos, por lo tanto, de-
terminan las restricciones que deben ser superadas por la organizaci´n
o
para que ´sta pueda alcanzar mejores niveles de madurez.
e
• Caracter´
ısticas comunes: Son atributos que indican si la implementaci´n
o
e institucionalizaci´n de una KPA son eficaces, repetidas y duraderas.
o
Paulk, Curtis, Chrissis y Weber (1993) presentan cinco caracter´
ısticas
comunes:
– El compromiso en desempe˜ar las acciones que garantizan el es-
n
tablecimiento del proceso.
– La habilidad en desempe˜ar dichas acciones.
n
– Las actividades desempe˜adas para implementar las KPA.
n

22. 151
– La medici´n y el an´lisis del estado y eficacia de las actividades
o a
desempe˜adas.
n
– La implementaci´n para la verificaci´n de las actividades desem-
o o
pe˜adas respecto a los procesos establecidos.
n
´
• Pr´cticas clave: Estas describen la infraestructura y actividades que
a
contribuyen para la implementaci´n e institucionalizaci´n efectiva de
o o
la KPA.
Niveles de madurez
indican contienen
Capacidad del Áreas de proceso clave
proceso
alcanzan organizadas por
Objetivos Características comunes
direccionan contienen
Implementación o Prácticas clave
Institucionalización
describen
Infraestructura o
Actividades
Figura 5.4: Estructura interna del CMM. Fuente: Paulk, Curtis, Chrissis y
Weber (1993)

23. 152
Optimización (5)
Gestión de cambio de proceso
Gestión de cambio de tecnología
Prevención de defecto
Gestionado (4)
Gestión de calidad de software
Gestión de proceso cuantitativo
Definido (3)
Revisión de pares
Coordinación intergrupo
Ingeniería de producto de software
Gestión de software integrado
Programa de entrenamiento
Definición de proceso de organización
Enfoque de proceso de organización
Repetición (2)
Gestión de configuración de software
Garantía de calidad de software
Gestión de subcontratación de software
Supervisión y dirección del proyecto de software
Planeamiento de proyecto de software
Gestión de requerimientos
Inicial (1)
Figura 5.5: Las KPA representadas en cada uno de los cinco niveles de
madurez del proceso de software del CMM. Fuente: Paulk, Curtis, Chris-
sis y Weber (1993)

24. 153
De acuerdo con Zahran (1998), el CMM es un mapa para la definici´n de
o
pasos (i.e. un esquema de evaluaci´n) que una organizaci´n necesita realizar
o o
para moverse desde procesos ca´ticos a procesos de mejora continua. Las eva-
o
luaciones basadas en CMM utilizan el cuestionario del Software Engineering
Institute (SEI) como un instrumento de evaluaci´n. Su enfoque se dirige a
o
temas relacionados con procesos y sus cuestiones se basan en los objetivos
de las KPA del CMM.
5.3.2 Est´ndar ISO/IEC 15504
a
La Organizaci´n Internacional para Estandarizaci´n (International Organi-
o o
zation for Standardization) y la Comisi´n Electrot´cnica Internacional (Inter-
o e
national Electrotechnical Commission) han presentado el est´ndar ISO/IEC
a
15504 (1998), el cual se manifiesta a partir del consenso internacional en la
definici´n de un est´ndar de dominio p´blico para la evaluaci´n de procesos
o a u o
de software.
El desarrollo del est´ndar ISO/IEC 15504 se establece a partir del proyeto
a
SPICE5 que tiene como objetivo garantizar una ruta de desarrollo r´pida y
a
solicitar las opiniones de los expertos m´s importantes del mundo (Zahran,
a
1998).
5.3.2.1 Estructura del ISO/IEC 15504
El est´ndar ISO/IEC 15504 consiste en dos dimensiones: la dimensi´n de
a o
proceso y la dimensi´n de capacidad.
o
5
Software Process Improvement and Capability dEtermination.

25. 154
• Dimensi´n de proceso: se caracteriza por los prop´sitos de proceso (i.e.
o o
objetivos de medici´n esenciales de un proceso) y el resultado esperado
o
del proceso (i.e. la indicaci´n de su finalizaci´n exitosa) (Zahran, 1998).
o o
Para esta dimensi´n son atribuidas cinco categor´
o ıas:
– Categor´ de proceso cliente-proveedor.
ıa
– Categor´ de proceso de ingenier´
ıa ıa.
– Categor´ de proceso de soporte.
ıa
– Categor´ de proceso de gesti´n.
ıa o
– Categor´ de proceso de organizaci´n.
ıa o
• Dimensi´n de capacidad: Esta dimensi´n consiste en un conjunto de
o o
atributos interrelacionados que ofrecen los indicadores de medici´n nece-
o
saria para gestionar un proceso y mejorar la capacidad de desempe˜ar
n
un proceso. Esta dimensi´n compuesta de seis niveles tiene carac-
o
ter´
ısticas evolutivas similares a las del CMM (v´ase Figura 5.6):
e
– Nivel 0 - Incompleto: se caracteriza por un incumplimiento general
para lograr el prop´sito del proceso;
o
– Nivel 1 - Proceso desempe˜ado: se caracteriza por el logro de
n
manera general del prop´sito del proceso;
o
– Nivel 2 - Proceso gestionado: se caracteriza por la identificaci´n
o
de la calidad aceptable con definici´n de tiempos y recursos. Los
o
productos del trabajo est´n de acuerdo con los est´ndares especi-
a a
ficados y los requerimientos;

26. 155
– Nivel 3 - Proceso consolidado: se caracteriza por la gesti´n y el
o
desempe˜o del proceso usando el proceso est´ndar basado en prin-
n a
cipios estables de ingenier´ de software;
ıa
– Nivel 4 - Proceso predecible: se caracteriza por la consistencia de
su desempe˜o en la pr´ctica con l´
n a ımites de control definidos para
alcanzar sus objetivos de proceso definido;
– Nivel 5 - Proceso optimizado: se caracteriza por la optimizaci´n
o
del desempe˜o del proceso para encontrar las necesidades de nego-
n
cio actuales y futuras, y por el grado de repetici´n que el proceso
o
alcanza encontrando sus objetivos de negocio definidos.
Nivel 5
Nivel 5 Proceso
optimizado
Nivel 4 Proceso predecible
Nivel 3 Proceso consolidado
Nivel 2 Proceso gestionado
Nivel 1 Proceso desempeñado
Nivel 0 Incompleto
Figura 5.6: Los niveles de capacidad de proceso seg´n ISO/IEC 15504.
u
Fuente: Zahran (1998)
Como se ha comenta, el ISO/IEC 15504 (1998) es un est´ndar interna-
a
cional para la evaluaci´n de proceso de software que ofrece beneficios a los
o
desarrolladores, proveedores y clientes (i.e. las organizaciones que adquieren

27. 156
el software). En este sentido, se observa la necesidad de dise˜ar un modelo
n
de test para aplicaciones multimedia que tambi´n ofrezca beneficios similares
e
al ambito educativo.
´
5.3.3 Bootstrap
El Bootstrap es una metodolog´ de evaluaci´n que mejora la capacidad de
ıa o
los procesos de desarrollo de software. Adem´s, el modelo Bootstrap describe
a
el proceso de evaluaci´n, determina donde se encuentra una organizaci´n res-
o o
pecto a los niveles de madurez, identifica los puntos fuertes y debilidades de
la organizaci´n, y ofrece un gu´ para el proceso de mejora (Kuvaja, Bicego,
o ıa
Haase, Koch, Krzanik, Cacchia, Lancelotti, Maiocchi, Messnarz, Saukkonen,
Schynoll y Simil¨, 1993).
a
Este m´todo es uno de los resultados del proyecto ESPRIT 5441 apoyado
e
por la Comunidad Europea. El Bootstrap ha considerado como punto de
partida varios est´ndares y metodolog´ como por ejemplo CMM, ISO/IEC
a ıas
15504 y los est´ndares de ingenier´ de software (Software Engineering Stan-
a ıa
dards - SES) de la Agencia Espacial Europea (European Space Agency - ESA).
El modelo Bootstrap se basa en la tr´
ıada Organizaci´n, Metodolog´ y Tec-
o ıa
nolog´ (OMT) presentada en la Figura 5.7.
ıa
Organización
Metodología
Tecnología
Figura 5.7: La tr´
ıada Bootstrap. Fuente: Zahran (1998)

28. 157
5.3.3.1 Arquitectura del modelo de proceso Bootstrap
Usando la tr´
ıada presentada en la Figura 5.7 como punto de partida, se define
una arquitectura en forma de arbol que identifica, seg´n Zahran (1998),
´ u
las categor´ de proceso, las areas de proceso, los procesos y las mejores
ıas ´
pr´cticas.
a
Boostrap 3.2
Organización Tecnología
ORG. 1 Ingeniería de negocios TEC. 1 Innovación tecnológica
ORG. 2 Gestión de recursos TEC. 2 Soporte tecnológico para
humanos Metodología los procesos del ciclo de vida
ORG. 3 Gestión de infraestructura TEC. 3 Soporte tecnológico para
los procesos independiente del ciclo de vida
TEC. 4 Herramienta de integración
Ciclo de vida dependiente
ENG. 0 Definición de desarrollo Relacionado a proceso
ENG. 1 Análisis de requerimientos
de sistema Ciclo de vida independiente PRO. 1 Definición de proceso
ENG. 2 Diseño de la arquitectura PRO. 2 Mejora de proceso
del sistema PRO. 3 Evaluación de proceso
ENG. 3 Análisis de requerimientos PRO. 4 Medición
de software
ENG. 4 Diseño de la arquitectura
de software
ENG. 5 Diseño detallado de
software
Gestión Soporte Cliente Proveedor
ENG. 6 Implementación y test de MAN. 0 Gestión SUP. 1 Documentación CUS. 1 Adquisición
software MAN. 1 Gestión de proyecto SUP. 2 Gestión de CUS. 2 Gestión de la necesidad
ENG. 7 Integración y test de MAN. 2 Gestión de calidad configuración del cliente
software MAN. 3 Gestión de riesgos SUP. 3 Garantía de calidad CUS. 3 Garantía Suministro
ENG. 8 Integración y test de MAN. 4 Gestión de SUP. 4 Verificación CUS. 4 Operación de software
sistema subcontrato SUP. 5 Validación CUS. 5 Atención al cliente
ENG. 9 Mantenimiento MAN. 5 Gestión de reuso SUP. 6 Revisión completa
ENG. 10 Migración SUP. 7 Auditoría
ENG. 11 Retiro SUP. 8 Resolución de
problemas
Figura 5.8: Arquitectura de proceso Bootstrap versi´n 3.2.
o Fuente:
http://www.bootstrap-institute.com
En general, se utiliza el proceso de evaluaci´n del m´todo Bootstrap para
o e
medir el estado actual de la pr´ctica de desarrollo de software dentro de una
a
organizaci´n.
o
La evaluaci´n se basa en un cuestionario que est´ formado por listas de
o a

29. 158
verificaci´n (checklists) de acuerdo con unos atributos clave. De esta manera,
o
se calcula la media agregada por atributos clave y consecuentemente el nivel
de madurez, bas´ndose en los cinco niveles de madurez del CMM.
a
El Bootstrap cubre la unidad de producci´n de software enfocando sus
o
actividades no s´lo en la evaluaci´n sino tambi´n en el planeamiento de ac-
o o e
ci´n.
o
5.4 Proceso de test
Como se ha comentado, los procesos de test se realizan tanto dentro del
´mbito de la ingenier´ de software (e.g. test de verificaci´n y validaci´n),
a ıa o o
como dentro del ambito de la ergonom´ (e.g. test de usabilidad). En este
´ ıa
sentido, es necesario realizar un estudio sobre la formaci´n del proceso de
o
test en la ingenier´ de software.
ıa
Kit (1995, p. 3) define el proceso de test de software como
“los medios a trav´s de los cuales se integran las personas, los
e
m´todos, las mediciones, las herramientas y los equipos con el
e
objetivo de evaluar un producto de software”.
A partir de de esta definici´n, el autor presenta seis elementos esenciales
o
para el proceso de test de software:
1. La calidad del proceso de test (y, consecuentemente, la calidad del
software producido) determina el ´xito del esfuerzo de test.
e
2. La prevenci´n de la migraci´n de defectos a trav´s de la aplicaci´n de
o o e o

30. 159
t´cnicas de test en las fases iniciales del ciclo de vida de desarrollo de
e
software.
3. El uso inmediato de herramientas de test de software.
4. Una persona debe responsabilizarse de la mejora de procesos de test.
5. La realizaci´n de test (testing) es una disciplina profesional que requiere
o
personas entrenadas y calificadas.
6. Cultivar una actitud positiva de eliminaci´n de defectos en el equipo
o
de test.
Dentro de este contexto, se observan avances continuados en la b´squeda
u
de la calidad de software desde las perspectivas de la gesti´n (e.g. el es-
o
tudio de Birk y Rombach (2001) sobre la gesti´n de calidad de software
o
orientado a procesos), de la realizaci´n de test (e.g. el an´lisis de requeri-
o a
mientos funcionales y no-funcionales de procesos de test por Keese (2001)) y
de la construcci´n de heramientas para la realizaci´n de test (e.g. Bromnick
o o
(2001)).
Usando estas consideraciones com punto de partida, se presentan, a con-
tinuaci´n, las actividades que permiten tanto verificar y validar los software,
o
como evaluar su aceptabilidad y la satisfacci´n del usuario.
o
5.4.1 Test de verificaci´n, validaci´n y usabilidad
o o
El test de verificaci´n es una de las fases del ciclo de vida de los procedimien-
o
tos de test. Seg´n Kit (1995) el principal objetivo es detectar la mayor´
u ıa

31. 160
de errores posibles. En este sentido, Schulmeyer y Mackenzie (2000) comen-
tan que la verificaci´n permite garantizar la consistencia entre los productos
o
desarrollados (i.e. los prototipos y la versi´n final del software) y sus requer-
o
imientos predeterminados en la fase de especificaci´n, es decir, se necesita
o
saber si se est´ desarrollando de manera correcta el producto.
a
Por otra parte, seg´n Schulmeyer y Mackenzie (2000) el test de validaci´n
u o
permite garantizar que el software final satisfaga los requerimientos del sis-
tema, es decir, se necesita saber si se desarrolla el producto correcto.
Finalmente est´n los test de usabilidad que son un procedimiento de
a
an´lisis que considera criterios de evaluaci´n previamente seleccionados (v´ase
a o e
Cap´
ıtulo 4, p´gina 102). En este tipo de test se verifica el grado de eficiencia
a
y eficacia con que un usuario desempe˜a sus tareas bajo los requerimientos
n
y restricciones de un producto o servicio y su entorno, evaluando la acepta-
bilidad y satisfacci´n del usuario.
o
Para una mejor compresi´n de los tipos de test de verificaci´n, validaci´n
o o o
y usabilidad, se presenta en la Figura 5.9 el modelo “U en punto” (Dotted-U
Model) propuesto por Software Development Technologies (SDT)6 . Seg´n Kit
u
(1995), este modelo integra el ciclo de vida de desarrollo y el ciclo de test.
6
http://www.sdtcorp.com/trntest.htm

32. 161
Especificación de Modificación del
requerimientos código y de la
especificación
1 11
Validación del
Verificación de sistema y
requerimientos de la aceptabilidad
Especificación del Simulación del Modificación del
diseño funcional producto código y de la
especificación
2 3 9 10
Verificación del Test de usabilidad Validación de la
diseño funcional función
6
Especificación del Modificación del
diseño interno código y de la
Código Modificación del
especificación
código y de la
4 especificación 8
5 7
Verificación del Validación de la
diseño interno integración
Verificación del Validación de
código unidad
Figura 5.9: Adaptaci´n del Modelo U en punto SDT. Fuente:
o
http://www.sdtcorp.com/trntest.htm y Kit (1995)

33. 162
En la Figura 5.9, se puede examinar el alcance de los tres m´todos de
e
test:
1. La verificaci´n del software se caracteriza por las etapas representadas
o
en rojo (i.e. la verificaci´n de requerimientos, de dise˜o y de c´digo).
o n o
2. La validaci´n consiste en las etapas amarillas (i.e. se validan el software
o
o sus componentes respecto a sus funciones predefinidas). Aunque que
Kit (1995) considere el test de usabilidad una actividad de validaci´n,
o
debido a su importancia para la presente tesis se modifica su enfoque
defini´ndola como una tercera actividad.
e
3. Los test de usabilidad, representados por la etapa verde, examinan la
aceptabilidad y satisfacci´n del usuario respecto al software.
o
5.4.2 Importancia de los test
La necesidad de garantizar la alta calidad de los sistemas inform´ticos (i.e.
a
software) ha aumentado las horas de trabajo de los procedimientos de test re-
specto a los de an´lisis, dise˜o y programaci´n. En los ultimos a˜os, diversos
a n o ´ n
autores han publicado documentos en los cuales se constata la preocupaci´n
o
en transformar los procedimientos de test (i.e. un proceso dentro del ciclo de
vida de desarrollo de software) en estudios m´s profundizados.
a
Recientemente, Shepard, Lamb y Kelly (2001) han comentado sobre la im-
portancia de las t´cnicas de verificaci´n y validaci´n de software como parte
e o o
de una disciplina importante de ingenier´ de software, las cuales tienen el
ıa
objetivo de formar desarrolladores de software m´s efectivos. Los autores
a

34. 163
apuntan la dificultad de la inserci´n de dichas t´cnicas en los curr´
o e ıculos de
ingenier´ de software, aunque el panorama ha cambiado en los ultimos a˜os.
ıa ´ n
Por ejemplo, Adamsone, Borzovs, Gills, Linde y Plume (2000) comentan que
el curriculum de cursos en inform´tica en Latvia hace m´s de una d´cada
a a e
que consideran asignaturas sobre test de software, presentando con el mis-
mo grado de importancia las actividades de test y las de an´lisis, dise˜o y
a n
programaci´n.
o
No obstante y aunque parezca contradictorio, el ideal ser´ que el tiempo
ıa
dedicado a las actividades de verificaci´n y validaci´n en la industria del
o o
software se redujera como resultado de mejores pr´cticas de desarrollo de
a
software (Shepard, Lamb y Kelly, 2001).
5.4.3 Proceso de test en los modelos est´ndares
a
El est´ndar ISO/IEC 15504 define un esquema integrado para el desarrollo y
a
aplicaci´n de test a lo largo del ciclo de vida del software, as´ como el modelo
o ı
Bootstrap. Por otra parte, estos modelos aportan referencia t´cnica a los
e
test y c´mo ´stos dan soporte a los dem´s procesos.
o e a
Adem´s el est´ndar ISO/IEC 15504 y el modelo Bootstrap, bajo un punto
a a
de vista operacional, mantienen un entendimiento com´n con los clientes, ya
u
que el producto o el proceso est´ de acuerdo con sus requerimientos. Sin
a
embargo, no se identifica una especializaci´n sistem´tica de los procesos de
o a
test (i.e. los test de verificaci´n, validaci´n y usabilidad).
o o
En el caso del CMM, no se contempla adecuadamente los aspectos rela-
cionados con los test en las areas de proceso clave (key process areas). Tam-
´

35. 164
poco se identifican las pr´cticas de test como una herramienta o mecanismo
a
de mejora del proceso. De esta manera, en el CMM no han sido identificados
algunos conceptos, como por ejemplo el de madurez de los test.
5.5 Modelos espec´
ıficos de proceso de test
De acuerdo con Gelperin y Hetzel (1988), la idea propuesta por diversos inves-
tigadores y profesionales de c´mo transformar la tarea de test en un proceso
o
de costes efectivos, ha crecido equitativamente respecto a la importancia de
dicha tarea.
La evoluci´n de los modelos espec´
o ıficos de proceso de test aumenta satis-
factoriamente la calidad de dichos procesos y consecuentemente, los coloca
en una posici´n relevante dentro de la ingenier´ de software.
o ıa
Como se ha comentado, los modelos y est´ndares de evaluaci´n de pro-
a o
ceso de software ofrecen herramientas para establecer niveles de madurez de
desarrollo y mantenimiento del software. Sin embargo, ha sido constatado
que estos modelos y est´ndares no dirigen adecuadamente sus enfoques a los
a
procesos de test. En este sentido, se presentan, a continuaci´n, dos modelos
o
de evaluaci´n y mejora de procesos de test:
o
• Modelo de madurez del test (Testing Maturity Model - TMM)
• Modelo de mejora del proceso de test (Test Process Improvement - TPI)

36. 165
5.5.1 Modelo de madurez del test - TMM
Considerando que el test es un componente cr´
ıtico en el proceso de desa-
rrollo de software, Burnstein, Suwannasart y Carlson (1996a) y Burnstein,
Suwannasart y Carlson (1996b) han propuesto el Modelo de madurez del test
(Testing Maturity Model - TMM) cuyo objetivo es conducir las evaluaciones y
mejoras de los procesos de test en las organizaciones que desarrollan software.
El modelo TMM es un modelo de evaluaci´n de proceso de test, guiado por
o
el conjunto b´sico de conceptos del CMM y compuesto por dos componentes
a
princinpales: un conjunto de niveles de madurez y una modelo de evaluaci´n
o
(Burnstein, Homyen, Grom y Carlson, 1998). As´ pues, el TMM prescribe
ı
la posici´n que un determinado proceso de test ocupa en la jerarqu´ de
o ıa
madurez del test (v´ase Figura 5.10).
e
Nivel 5: Optimización, Prevención de defectos y Control de
calidad
Optimización de proceso de test
Control de calidad
Aplicación de datos de proceso para prevención de defecto
Nivel 4: Gestión y Medición
Evaluación de calidad de software
Establecer un programa de medición de test
Establecer un programa de revisión amplio de la organización
Nivel 3: Integración
Control y seguimiento del proceso de test
Integrar el test en el ciclo de vida del software
Establecer un programa de entrenamiento técnico
Establecer una organización de test de software
Nivel 2: Definición de fase
Institucionalizar métodos y técnicas de test básico
Iniciar un proceso de planeamiento de test
Desarrollar test y definifir los objetivos de depuración
Nivel 1: Inicial
Figura 5.10: Los niveles de madurez del TMM y sus objetivos. Fuente:
Burnstein, Suwannasart y Carlson (1996a, 1996b)

37. 166
Los niveles de madurez del proceso de test son:
• Nivel 1 - Inicial: El test se caracteriza como un proceso ca´tico. El
o
objetivo del test es mostrar que el software funciona y existe carencia
de recursos, herramientas y de un equipo apropiadamente entrenado.
• Nivel 2 - Definici´n de fase: Se caracteriza por la utilizaci´n de m´todos
o o e
y t´cnicas b´sicas de test que identificar´n si el software est´ de acuerdo
e a a a
con sus especificaciones.
• Nivel 3 - Integraci´n: Se caracteriza por la identificaci´n de test en
o o
todo el ciclo de vida del software. El test es una actividad profesional
que realiza un papel de revisi´n importante (formal o informal) en el
o
control de calidad.
• Nivel 4 - Gesti´n y Medici´n: El test es un proceso medido y cuantifi-
o o
cado. La usabilidad es uno de los atributos de calidad utilizado en el
test del software.
• Nivel 5 - Optimizaci´n, Prevenci´n de defectos y Control de calidad:
o o
Se caracteriza por mecanismos precisos para que el test pueda ser mejo-
rado continuamente. En este nivel se utilizan procedimientos para se-
leccionar y evaluar herramientas de test.
Se describe cada nivel considerando los objetivos de la organizaci´n y la
o
capacidad de test. Adem´s, la estructura de cada nivel (excepto el nivel uno)
a
consiste en un conjunto de objetivos de madurez soportado por sub-objetivos
(o metas) de madurez que son alcanzados por las actividades, tareas y res-
ponsabilidades (ATR). Por una parte, las actividades y tareas representan

38. 167
las acciones que deben ser desempe˜adas en cada nivel con el prop´sito de
n o
mejorar la capacidad del test y, por otra, se asignan responsabilidades, para
las actividades y tareas, a los gestores, a los desarrolladores y “testeadores”
(o revisores) y a los usuarios y clientes (Burnstein, Homyen, Grom y Carlson,
1998). En la Figura 5.11, se presenta la estructura de los niveles de madurez
del modelo TMM.
Niveles
indican contienen
Capacidad de test Objetivos de madurez
Soportados por
Subobjetivos de madurez
Alcanzados por
Actividades/Tareas/Responsabilidades
direccionan Organizados por
Implementación y Visiones críticas
Adaptación de la
organización
Gestor Desarrollador/ Usuario/Cliente
"Testeador"
Figura 5.11: La estructura del modelo de madurez del proceso de test.
Fuente: Burnstein, Suwannasart y Carlson (1996a, 1996b)
De acuerdo con Burnstein, Homyen, Grom y Carlson (1998), el segundo
componente, el modelo de evaluaci´n, consiste en un m´todo que permite a
o e
la organizaci´n evaluar y mejorar sus procesos de test, bas´ndose en un cues-
o a
tionario de evaluaci´n, un procedimiento de evaluaci´n y el entrenamiento y
o o

39. 168
criterios de selecci´n del equipo de evaluaci´n.
o o
Los objetivos de este componente son: proveer un esquema de evaluaci´n
o
de proceso de test de software y un fundamento para la mejora de dichos
procesos a trav´s de an´lisis de datos y planeamiento de acciones, as´ como
e a ı
contribuir con la ingenier´ de proceso de software.
ıa
5.5.2 Mejora del proceso de test - TPI
Koomen y Pol (1999) presentan el modelo de mejora del proceso de test (Test
Process Improvement - TPI), en cual ofrece soporte a la mejora del proceso
de test a trav´s de gu´ pr´cticas que ser´n utilizadas para evaluar el nivel de
e ıas a a
madurez de los test de una organizaci´n. Adem´s, este esquema determina
o a
los puntos fuertes y d´biles de un proceso de test, de manera que ayuda a
e
definir pasos controlados y graduales de mejora.
El modelo TPI se basa en la metodolog´ de test estructurado TMap (Pol
ıa
y Veenendaal, 1998), a partir de diversas recomendaciones de estructuraci´n
o
de proceso de test organizadas en cuatro componentes: el ciclo de vida (C),
las t´cnicas (T), la infraestructura (I) y la organizaci´n (O)(v´ase Figura
e o e
5.12).
T
C
I O
Figura 5.12: Los componentes de soporte para enfoques estructurados de
test. Fuente: Pol y Veenendaal (1998)

40. 169
El modelo TPI, presentado en la Figura 5.13, consiste en cinco compo-
nentes:
Áreas clave
Matriz de
Niveles madurez
de test
Lista de verificación Sugerencias de mejora
Figura 5.13: El esquema general del modelo TPI. Fuente: Koomen and Pol
(1999)
• Las areas clave: Constituyen la base para mejorar y estructurar el
´
proceso de test. Las areas clave comprenden tanto los test de sistema
´
y de aceptaci´n (i.e. test de alto nivel) como los test de unidad y de
o
integraci´n (i.e. test de bajo nivel). El modelo TPI tiene viente areas
o ´
clave:
– Estrategias de test – Entorno de test
– Modelo de ciclo de vida – Entorno de oficina
– Momento de compromiso – Compromiso y motivaci´n
o
– Estimaci´n y planeamiento
o – Funciones de test y entrenamiento
– T´cnicas de especificaci´n de test
e o – Alcance de la metodolog´
ıa
– T´cnicas de test est´tico
e a – Comunicaci´n
o
– M´trica
e – Producci´n de informes
o
– Herramientas de test – Gesti´n de defectos
o

41. 170
– Gesti´n de elementos de test
o – Evaluaci´n
o
– Gesti´n del proceso de test
o – Test de bajo nivel
• Los niveles de madurez: La organizaci´n de las areas clave dentro de
o ´
un proceso de test determina la madurez de dicho proceso (Koomen y
Pol, 1999). Por consiguiente, los niveles de madurez indican el estados
(e.g. A, B, C, etc.) de cada ´rea clave, debido a que ellos conllevan
a
el cumplimiento de determinados requerimientos para las areas clave.
´
Como promedio, existen tres niveles para cada area.
´
• La lista de verificaci´n: Es un instrumento de medici´n objetivo, basado
o o
en preguntas, que permite determinar el nivel de madurez de cada area
´
clave.
• La matriz de madurez del test: Representa un mapa de interrelaciones
entre las ´reas clave y sus niveles de madurez en una escala de 1 a 13
a
distribuida en tres categor´
ıas:
– Controlada (1 al 5).
– Eficiente (6 al 10).
– Optimizada (11 al 13)
• Las sugerencias de mejora: Los resultados de los an´lisis de la matriz de
a
madurez de test proponen acciones de mejora en funci´n de los criterios
o
que se deseen alcanzar.
El proceso de evaluaci´n del modelo TPI se basa en la utilizaci´n de
o o
encuestas y documentaci´n para determinar el estado de cada proceso de
o

42. 171
test. En el procedimiento se consideran las caracter´
ısticas de cada area clave
´
en los diferentes niveles, de manera que, a trav´s del uso de los puntos de
e
verificaci´n (checkpoints), sea posible determinar los puntos fuertes y d´biles
o e
del proceso de test, permitiendo establecer una posici´n relativa en la matriz
o
de madurez del test (Test Maturity Matrix). Adem´s, las sugerencias de
a
mejora son una herramienta que ayuda a alcanzar un determinado nivel de
madurez, ya que establece comentarios e sugerencias para el proceso de test
(Koomen y Pol, 1999).
De acuerdo con Koomen y Pol (1999) el modelo TPI ofrece el soporte
necesario para mejorar el proceso de test a trav´s de la obtenci´n de r´pida
e o a
de informaci´n acerca de la situaci´n actual de dichos procesos. De esta
o o
manera, se considera el modelo como una herramienta de estructuraci´n de
o
acciones de mejora del proceso de test.
Como se ha visto en este cap´
ıtulo, la ingenier´ de software es una disci-
ıa
plina que involucra diversas metodolog´ m´todos, t´cnicas y herramientas
ıas, e e
con el prop´sito de desarrollar sistemas inform´ticos de alta calidad.
o a
Considerando el contexto de la presente investigaci´n (i.e. la interrelaci´n
o o
entre la usabilidad del software educativo y el aprendizaje del usuario), se han
presentado los conceptos m´s importantes sobre la ingenier´ de software y
a ıa
sobre los modelos y est´ndares internacionales que auxilian en las actividades
a
de evaluaci´n de proceso de software y de test. Por lo tanto, el estudio te´rico
o o
presentado ha guiado la preparaci´n del modelo propuesto (v´ase Cap´
o e ıtulo
7).