Ingeniería de software

1,296 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,296
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ingeniería de software

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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).

×