Modulo Evaluacion Software 2010

ESCUELA DE CIENCIAS BASICAS
TECNOLOGIA E INGENIERIA
MDULO EVALUACIN DE SOFTWARE
Cdigo del Curso: 301569
Francisco Nicols Javier Solarte Solarte
francisco.solarte@unad.edu.co
solartefrancisco@gmail.com
2010
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD
ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA - ECBTI
CURSO DE EVALUACIN DE SOFTWARE - CDIGO 301569__________________________________________
2
TABLA DE CONTENIDO
UNIDAD 1. PROCESO DE DESARROLLO DE SOFTWARE Pag.
Capitulo 1 CICLO DE VIDA PARA PRODUCTOS SOFTWARE 17
Leccin 1 Conceptos Generales sobre ciclos de vida 18
Leccin 2 Ciclos de vida tradicionales 20
Leccin 3 Ciclos de vida alternativos 23
Leccin 4 Modelos de proceso de produccin de software 24
Leccin 5 Ciclos de vida giles 28
Capitulo 2 DESARROLLO DE SOFTWARE 34
Leccin 1 Procesos de Gestin del Proyecto 36
Leccin 2 Procesos de Pre-desarrrollo 39
Leccin 3 Procesos de Desarrollo 41
Leccin 4 Procesos de Post-Desarrollo 46
Leccin 5 Procesos Integrales del Proyecto 49
Capitulo 3 CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE 52
Leccin 1 Definicin de Calidad 54
Leccin 2 Sistemas de Calidad en la empresa 55
Leccin 3 Normatividad de Calidad 57
Leccin 4 Ingeniera de Software y Calidad 59
Leccin 5 Gestin de la Calidad del Software 60
UNIDAD 2. ESTNDARES, METRICAS DE CALIDAD Y PRUEBAS DEL
SOFTWARE
Capitulo 4 Calidad del Software 68
Leccin 1 La Calidad del Software 70
Leccin 2 Calidad del Producto Software Norma ISO/IEC 9126 72
Leccin 3 Calidad del Producto software Norma ISO/IEC 14598 75
Leccin 4 Calidad del Producto Software Norma ISO/IEC 25000
(SquaRE)
80
Leccin 5 Modelos de Mejora de Procesos de Software 82
Capitulo 5 MTRICAS DE CALIDAD DEL SOFTWARE 87
Leccin 1 Conceptos Bsicos de Mtricas 88
Leccin 2 Mtricas del Software 91
Leccin 3 Mtricas de Calidad del Software 94
Leccin 4 Mtricas Tcnicas del Software 95
Leccin 5 Estructura para las Mtricas de Calidad del software 98
Capitulo 6 PRUEBAS DEL SOFTWARE 104
Leccin 1 La Prueba del software 106
Leccin 2 Tcnicas de diseo de Casos de Prueba 108
Leccin 3 Estrategias de Aplicacin de Pruebas del Software 114
Leccin 4 Pruebas de Software para Objetos 122
Leccin 5 Pruebas de Software Basado en Componentes 127
UNIDAD 3. EVALUACIN DE SOFTWARE
Capitulo 7 METODOLOGA TCNICA PARA LA EVALUACIN DE
SOFTWARE
136
3
Leccin 1 Modelos Tradicionales para la Evaluacin de la Calidad
del software
138
Leccin 2 Norma de Evaluacin ISO/IEC 9126 142
Leccin 3 Proceso de Evaluacin de Software 151
Leccin 4 Mtricas Externas Basados en ISO/IEC 9126 156
Leccin 5 Mtricas Internas Basados en ISO/IEC 9126 159
Capitulo 8 METODOLOGIAS DE EVALUACIN DE LA
ARQUITECTURA DEL SOFTWARE
162
Leccin 1 Evaluacin de la Arquitectura del software 164
Leccin 2 Tcnicas de Evaluacin de la arquitectura del software 166
Leccin 3 Mtodos de Evaluacin de la arquitectura de software 172
Leccin 4 Mtodos de Evaluacin de Arquitectura de un Atributo
Especfico
179
Leccin 5 Mtodo de evaluacin de la Arquitectura de Software
MECABIT
184
Capitulo 9 APLICACIONES DE LA EVALUACIN DE SOFTWARE 192
Leccin 1 Metodologa para la Evaluacin de la Calidad en Modelos
UML
194
Leccin 2 Implementacin de la Metodologa con SPEM y EPFC 200
Leccin 3 Evaluacin de Software Educativo Multimedia 202
Leccin 4 Modelos de Evaluacin de Software Educativo Multimedia 205
Leccin 5 Plantillas de Evaluacin de Software Multimedia 214
4
LISTADO DE TABLAS
Pag.
Tabla 1 Proceso de Iniciacin del Proyecto 37
Tabla 2 Proceso de Seguimiento y Control del Proyecto 37
Tabla 3 Proceso de Gestin de Calidad del software 38
Tabla 4 Proceso de Exploracin de Conceptos 39
Tabla 5 Proceso de asignacin de Sistema 41
Tabla 6 Proceso de requisitos o Requerimientos 42
Tabla 7 Proceso de requisitos o Requerimientos 45
Tabla 8 Proceso de Implementacin 46
Tabla 9 Proceso de Instalacin 47
Tabla 10 Proceso de Operacin y Soporte 47
Tabla 11 Proceso de Mantenimiento 48
Tabla 12 Proceso de Retiro 48
Tabla 13 Proceso de verificacin y Validacin 50
Tabla 14 Proceso de gestin de la Configuracin 50
Tabla 15 Proceso de Desarrollo de la documentacin 51
Tabla 16 Proceso de Formacin 51
Tabla 17 Caractersticas de Calidad interna y externa ISO/IEC 9126 73
Tabla 18 Caractersticas de Calidad en Uso ISO/IEC 9126 74
Tabla 19 Origen de Errores y Defectos en un Proyecto Software 90
Tabla 20 Tabla de Registro de Datos de Metricas Orientadas Hacia el
Tamao
92
Tabla 21 Tabla para Clculo de Puntos de Funvin 92
Tabla 22 Caractersticas y definicin de puntos de funcin (a) 93
Tabla 23 Caractersticas y definicin de puntos de funcin (b) 94
Tabla 24 Factores de calidad de McCall 95
Tabla 25 Mtricas para el esquema de puntuacin 96
Tabla 26 Mtricas del modelo de Calidad FURPS 97
Tabla 27 Caractersticas y Subcaractersticas modelo ISO/IEC 9126 98
Tabla 28 Actividades y definicin de Mtricas Tcnicas de Software 99
Tabla 29 Mtrica Bang 100
Tabla 30 Medidas de Complecin de pruebas 102
Tabla 31 Objetivos, Principios, y Caractersticas de los Atributos de la
Prueba
108
Tabla 32 Pruebas de Caja Blanca 109
Tabla 33 Pruebas de Caja Negra 111
Tabla 34 Lista de comprobaciones para la prueba de interfaces 115
Tabla 35 Pruebas de Unidad de Software Orientado a Objetos 125
Tabla 36 Pruebas de Integracin de Software Orientado a Objetos 126
Tabla 37 Pruebas de Sistema de Software Orientado a Objetos 126
Tabla 38 Tabla de criterios a tener en cuenta al evaluar un software 153
Tabla 39 Caractersticas y Subcaratersticas ISO/IEC 9126 155
Tabla 40 Mtricas Externas ISO/IEC 9126 156
5
Tabla 41 Mtricas Internas ISO/IEC 9126 159
Tabla 42 Descripcin de atributos de calidad observables va ejecucin 166
Tabla 43 Descripcin de atributos de calidad no observables va
ejecucin
166
Tabla 44 Perfiles, Categorias, Pesos, y Mtricas Asociados a atributos
de Calidad
169
Tabla 45 Pasos para la Evaluacin Basada en Simulacin 170
Tabla 46 Pasos para la Evaluacin Basada en Modelos Matemticos 171
Tabla 47 Instrumentos asociados a las distintas tcnicas de evaluacin
de arquitecturas de software
172
Tabla 48 Pasos contemplados por el mtodo de evaluacin SAAM 173
Tabla 49 Pasos del mtodo de evaluacin ATAM 174
Tabla 50 Pasos del mtodo de evaluacin ARID 175
Tabla 51 Pasos del mtodo de evaluacin CBAM 177
Tabla 52 Etapas contempladas por el mtodo de evaluacin de
arquitecturas propuesto por Bosch
178
Tabla 53 Actividades del Mtodo de Comparacin de Arquitecturas
Basado en el Modelo ISO/IEC 9126 Adaptado para
Arquitecturas de Software de Losavio
179
Tabla 54 Comparacin entre los mtodos ALMA, PASA, SALUTA y
SNA
183
Tabla 55 Grupos de Trabajo en el Mtodo MECABIT 185
Tabla 56 Fases Contempladas en el Mtodo de evaluacin de
Arquitecturas MECABIT
186
Tabla 57 Subconjunto del rbol de Utilidad Iinicial Propuesto por el
Mtodo MECABIT
189
Tabla 58 Algunas Preguntas para Analizar los Elementos de Diseo
Identificados
189
Tabla 59 Tabla de Personas, grupos y Roles 195
Tabla 60 Catlogo de Elementos 197
Tabla 61 Fases del Proceso de Evaluacin 199
Tabla 62 Caractersticas de los Productos de Software Educativo
Multimedia
203
Tabla 63 Partes de la calidad educacional del MEC 206
Tabla 64 Calidad computacional del MEC y sus elementos 206
Tabla 65 Elementos considerados en la viabilidad del recurso
informtico
206
Tabla 66 Elementos Considerados en la Valoracin Comprensiva del
MEC
207
Tabla 67 Algunos elementos de la valoracin por experto en contenido
del MEC
207
Tabla 68 Elementos considerados en la valoracin por experto en
metodologa
207
Tabla 69 Aspectos tcnicos de la evaluacin de software de Bostock 209
6
Tabla 70 Aspectos pedaggicos de la evaluacin de software de
Bostock
210
Tabla 71 Esquema de evaluacin del producto final 211
Tabla 72 Criterios y Subcriterios para Evaluacin de la Calidad del
Software Educativo
211
Tabla 73 Caractersticas de las variables segn criterios de calidad 212
Tabla 74 Algunas caractersticas de la ficha de evaluacin de software 213
Tabla 75 Ficha de Catalogacin y Evaluacin 215
Tabla 76 Ficha de Diseo de actividades 218
7
LISTADO DE GRFICOS Y FIGURAS
Pag.
Figura 1 Modelo en Cascada 20
Figura 2 Ciclo de vida en cascada con validacin 22
Figura 3 Ciclo de vida en espiral 27
Figura 4 Ciclo de vida XP 29
Figura 5 Metodologa SCRUM 30
Figura 6 Ciclo de vida FDD 33
Figura 7 Modelo de Gestin de calidad ISO 9001: 2000 58
Figura 8 Esquema general de un modelo de calidad del software 70
Figura 9 Ciclo de vida de la calidad 71
Figura 10 Calidad en el ciclo de vida del software 72
Figura 11 Modelo de calidad interna y externa del producto software 73
Figura 12 Modelo de calidad del producto software para la calidad en
uso
74
Figura 13 Norma ISO/IEC 14598 76
Figura 14 Arquitectura de la serie de normas ISO/IEC 25000 80
Figura 15 Modelo de referencia para la arquitectura Square 81
Figura 16 Mtricas del Proceso y Mejoras en el Proceso de Software 89
Figura 17 Anlisis de Problemas y causas de calidad del software 90
Figura 18 Identificacin de causas de errores o defectos en un
software
91
Figura 19 Prueba de Caja Blanca 109
Figura 20 Prueba de Caja Negra 110
Figura 21 Integracin Incremental Descendente 118
Figura 22 Depuracin de errores 122
Figura 23 Norma de Evaluacin ISO/IEC 9126 143
Figura 24 Evaluacin Interna, externa y Calidad de Uso ISO/IEC 9126 144
Figura 25 Caracterstica de Funcionalidad 145
Figura 26 Caracterstica de Confiabilidad 146
Figura 27 Caracterstica de Usabilidad 147
Figura 28 Caracterstica de Eficiencia 148
Figura 29 Caracterstica de Mantenibilidad 149
Figura 30 Caracterstica de Portabilidad 150
Figura 31 Caracterstica de Calidad de Uso 151
Figura 32 Clasificacin de las Tcnicas de Evaluacin 165
Figura 33 Mtodo de evaluacin de arquitecturas ALMA 180
Figura 34 Mtodo de evaluacin de arquitecturas PASA 181
Figura 35 Mtodo de evaluacin de arquitecturas SALUTA 182
Figura 36 Mtodo de evaluacin de arquitecturas SNA 183
Figura 37 Roles y relaciones en el proceso de evaluacin 195
Figura 38 Diagrama de actividad generado por EPFC para la actividad
Obtencin y Anlisis de Artefactos a Evaluar de la fase 2
(Especificacin), del proceso de evaluacin
202
8
ASPECTOS DE PROPIEDAD INTELECTUAL Y VERSIONAMIENTO
El presente mdulo ha sido compilado y diseado en el ao 2010 por el
Ingeniero de sistemas Francisco Nicols Javier Solarte Solarte, docente de la
UNAD, quien a la fecha labora en el CEAD de Pasto, dentro de su currculo
formativo cuenta con los siguientes estudios: Ingeniero de Sistemas de la
Universidad INCCA de Colombia, Especialista en Multimedia educativa, y
Especialista en Auditoria de Sistemas de la Universidad antonio Nario y Magister
en docencia de la Universidad de La Salle. Adems cuenta con experiencia en
Docencia Universitaria desde 1995 en las diferentes universidades de la ciudad de
san Juan de Pasto y actualmente se desempea como docente auxiliar de la
UNAD.
Esta es la primera versin actualizada del curso y en el proceso de revisin
participa la Escuela ECBTI con respecto a los contenidos y la VIMMEP en la
revisin del CORE quienes apoyan el proceso de revisin del estilo del mdulo y
dan recomendaciones disciplinares, didcticos y pedaggicos para acreditar y
mejorar el curso.
El mdulo fue iniciado el mes de julio de 2010, y se termina en el mes de
noviembre del mismo ao, a peticin de la directora nacional de la Cadena de
Formacin de Sistemas, Ingeniera Alexandra Aparicio.
9
UNIDAD 1
Nombre de la Unidad PROCESO DE DESARROLLO DE SOFTWARE
Introduccin Esta unidad esta dedicada principalmente a la explicacin
de los modelos de cilo de vida de los sistemas, al proceso
de de desarrollo de software y a los conceptos de calidad
y calidad en el mbito del software, estos temas sirven de
base al proceso de evaluacin del proceso y el producto
software obtenido para que el ingeniero de software tenga
los fundamentos y una perspectiva sufiecientes para
poder evaluar el software.
Justificacin En la evaluacin del software es importante recalcar que
no solo se evala el producto, sino tambin, el proceso de
desarrollo de software y es de vital importancia que el
ingeniro de software y la empresa conozcan los modelos y
la metodologa basada en estndares para el desarrollo
de un producto tan especial como lo es el software.
Intencionalidades
Formativas
- El estudiante reconoce los ciclos de vida aplicables para
el desarrollo de los difrentes productos software
- El estudiante conoce uno de los estndares y cada una
de las etapas de desarrollo de software
- El estudiante conoce los conceptos de calidad, calidad
de software y algunos de los estndares ms reconocidos
aplicados al producto software.
Denominacin de
captulos
CAPITULO 1: CICLOS DE VIDA DEL SOFTWARE
Denominacin de
Lecciones
Leccin 1. Conceptos Generales sobre ciclos de vida
Denominacin de
Lecciones
Leccin 2. Ciclos de vida tradicionales
Denominacin de
Lecciones
Leccin 3. Ciclos de vida alternativos
Denominacin de
Lecciones
Leccin 4. Modelos de proceso de produccin de software
Denominacin de
Lecciones
Leccin 5. Ciclos de vida giles
Denominacin de
captulos
CAPITULO 2: DESARROLLO DE SOFTWARE
Denominacin de
Lecciones
Leccin 1. Procesos de Gestin del Proyecto
Denominacin de
Lecciones
Leccin 2. Procesos de Pre-Desarrrollo
Denominacin de
Lecciones
Leccin 3. Procesos de Desarrollo
Denominacin de
Lecciones
Leccin 4. Procesos de Post-Desarrollo
10
Denominacin de
Lecciones
Leccin 5. Procesos Integrales del Proyecto
Denominacin de
captulos
CAPITULO 3: CONCEPTOS DE CALIDAD Y CALIDAD
DEL SOFTWARE
Denominacin de
Lecciones
Leccin 1.Definicin de Calidad
Denominacin de
Lecciones
Leccin 2. Sistemas de Calidad en la empresa
Denominacin de
Lecciones
Leccin 3: Normatividad de Calidad
Denominacin de
Lecciones
Leccin 4: Ingeniera de Software y Calidad
Denominacin de
Lecciones
Leccin 5. Gestin de la Calidad del Software
11
INTRODUCCIN
Hace algunos aos, el desarrollo de aplicaciones informticas se llevaba a
cabo de forma individual, generando lneas de cdigo y probando lo realizado.
Este proceso se realizaba sin necesidad de documentacin alguna y como haba
baja movilidad las empresas pensaban que cuando hubiera necesidad de la
persona para realizar modificaciones l estara all para solucionar los problemas.
A pesar de que esa forma de escribir cdigo era un adelanto, nunca se llego a
pensar que posteriormente se convertira en un problema y que en el caso de
software que contena errores en la base de datos este deba desecharse
completamente y comenzar nuevamente.
Esta forma de desarrollar software es muy comn en las empresas y
sucede normalmente porque no se sigue un enfoque de desarrollo conocido como
ciclo de vida, y es el escaso tiempo dedicado a la planificacin, pues normalmente,
se codifica y se prueba dando buenos resultados cuando el software es pequeo.
Pero para otro tipo de proyectos resulta peligroso ya que no se conoce el progreso
del proyecto, ni tampoco su calidad simplemente se codifica y se prueba hasta
terminar el proyecto.
Por este motivo es probable que las aplicaciones desarrolladas utilizando
estos mtodos sean poco flexibles y ante posibles modificaciones se puedan
incrementar los costos de los proyectos y en algunos casos se vuelvan
irrealizables por la no existencia de documentacin para efectuarlas. Otro
problema es que las aplicaciones resulten incompletas y no reflejen en su
totalidad los requerimientos de los clientes, que no esten completamente
funcionales o que tengan baja fiabilidad. Adems pueden provocar el descontento
en los clientes pues, pueden producir retrasos en la entrega o que aparezcan
errores una vez entregados.
Por lo tanto es necesario que todo el esfuerzo de desarrollo de software se
enfoque en el uso de un ciclo de vida que contemple todas sus etapas desde la
concepcin hasta finalizar con el retiro del mismo cuando ya no se utiliza.
Todas las organizaciones y estudiosos de la ingeniera de software se han
ocupado del estudio de estos problemas para proponer nuevos enfoques y
actividades tendientes a mejorar los procesos de construccin y revisin de
software. As se han desarrollado modelos de referencia para la adquisicin,
desarrollo, explotacin, soporte y mantenimiento de software.
El instituto de ingeniera de software ha desarrollado el Modelo de Madurez
de la Capacidad ( Capability Maturity Model, CMM), el cual proporciona a las
organizaciones de software una orientacin sobre como hacerse con el control del
proceso de desarrollo y mantenimiento de software, y como evolucionar hacia una
cultura de la ingeniera de software y de gestin por excelencia.
12
Los organismos IEEE e ISO/IEC han publicado normas respectivamente,
IEEE-1074, e ISO/IEC 12207-1. Actualmente, ISO/IEC ha desarrollado dentro del
marco de la evaluacin de software un informe tcnico alineado con el anterior,
ISO/IEC TR 15504-2, y especficamente la La serie de normas ISO/IEC 14598
para evaluacin de software, la norma ISO/IEC 9126 que posteriormente se
unificaran en la serie de normas ISO/IEC 25000 denominadas SQuaRE, que
abarcar a la serie ISO/IEC 14598 e ISO/IEC 9126. Todos estos modelos establecen
los diferentes procesos implicados a la hora de desarrollar sistemas informticos,
desde que surge la idea o necesidad de desarrollar las aplicaciones hasta que
estos se retiran de explotacin.
Sin embargo ninguno de estos modelos impone la utilizacin de un ciclo de
vida especfico o mtodo de desarrollo concreto, sino que cada empresa debera
seleccionar los procesos que considere necesario realizar, estableciendo sus
propios ciclos de vida software.
La Ingeniera de software y especficamente el curso de Evaluacin de
software es uno de los componentes fundamentales de la estructura curricular del
programa de Ingeniera de sistemas, pues incorpora en su contenido todo lo
referente a los ciclos de vida de los sistemas, el proceso de construccin de
software, las mtricas de software, las pruebas de software, los estndares de
calidad, la evaluacin de la arquitectura de los sistemas, y la evaluacin general
de productos software de diferente tipo, con el propsito de verificar y evaluar su
correcta realizacin. Este curso, se enmarca dentro del campo de formacin
profesional y tiene como objetivo la preparacin de los estudiantes y futuros
profesionales en su labor como desarrolladores de software, auditores o
consultores de productos informticos dentro de una organizacin.
El mdulo esta compuesto de tres unidades generales, y cada una de ellas
esta integrada por captulos y lecciones, dentro de las cuales se distingue:
Unidad 1: Proceso de Desarrollo de software dentro de esta unidad se
incluye los ciclos de vida del software, los procesos de software, las metodologas
de desarrollo de software, la gestin de proyectos de software y aspectos
relacionados con estos temas.
Unidad 2: Calidad del Software, dentro de esta unidad se incluye las
mtricas de calidad, estandares de calidad de software, pruebas del software,
gestin de la calidad de software.
Unidad 3: Evaluacin de software, dentro de esta unidad se incluye la
especificacin de las mtricas ISO/IEC 9126, los mtodos de evaluacin y las
aplicaciones que aunque diversas, tratan de recoger las nuevas investigaciones
sobre estos temas tan importantes para la vida profesional del ingeniero.
13
JUSTIFICACIN
Uno de los intereses en la formacin de los estudiantes del programa de
ingeniera de sistemas y en mbito disciplinar, es su formacin integral a travs del
desarrollo de competencias, que le permitan interactuar en diferentes contextos,
haciendo de ellos profesionales competitivos, generadores de cambio y progreso.
El curso de evaluacin de software no es la excepcin, ya que centra al
estudiante en aspectos relacionados con los sistemas de informacin empresarial
donde con sus habilidades y conocimientos puede contribuir al desempeo y
cumplimiento exitoso de los procedimientos de la organizacin. El estudiante como
profesional estar preparado para planificar, disear, desarrollar y evaluar
software, identificando situaciones de riesgo y sugerir controles que garantice la
calidad de los productos de software.
El curso, esta dirigido a estudiantes que se encuentren en la etapa final del
proceso de formacin y especficamente que conozcan el campo de la Ingeniera
de Software, ya que los mtodos de evaluacin de software estn ligados al
proceso de construccin o adquisicin del software.
El curso permite el desarrollo de competencias cognitivas, comunicativas,
contextuales y valorativas, fundamentales para la formacin profesional y la
interaccin en otros contextos. El logro de estas competencias exige una
planificacin responsable en su proceso de aprendizaje autnomo si se quieren
obtener resultados positivos en el desarrollo del curso, ya que el trabajo es en
parte individual y otra la interaccin en grupos colaborativos pequeos.
La evaluacin de software permite llevar a la prctica los conocimientos
adquiridos en los cursos del componente de ingeniera de software que son la
base del profesional en sistemas y permite integrar las otras reas del
conocimiento necesarias para realizar un proceso de evaluacin bajo normas
estndares.
Adems una de las tareas ms difciles en la eleccin de software, una vez
conocidos los requerimientos del sistema, es el de determinar si un cierto producto
de software cumple con los requerimientos. Despus de la seleccin inicial, es
necesario conocer los estndares de calidad y hacer una revisin exhaustiva del
cumplimiento de las normas, y cuales son las ventajas frente a los otros productos.
14
INTENCIONALIDADES FORMATIVAS
PROPSITO
Fundamentalmente, el curso pretende desarrollar las capacidades,
habilidades y destrezas de los estudiantes durante el proceso de evaluacin de
software, donde deber conocer y aplicar los conocimientos acerca de ciclos de
vida, estndares de calidad, las mtricas de calidad y las para hacer la revisin de
los diferentes tipos de productos software.
Con esto se contribuir al mejoramiento de los procesos de calidad del
software en las organizaciones, a travs de la aplicacin de procedimientos y
estndares de calidad tanto en el proceso de produccin de software como en la
bsqueda de soluciones apropiadas para dar solucin a problemas del uso y la
integracin de sistemas de informacin computacionales.
OBJETIVOS
- Identificar dentro de los procesos de desarrollo de software los diferentes
enfoques o ciclos de vida de acuerdo a cada proyecto, conocer cada una de las
fases o etapas de cada ciclo de vida
- Reconocer los conceptos bsicos y las caractersticas de la evaluacin de
software
- Conocer los tipos de pruebas, mtricas y estndares de calidad para la
evaluacin de software y aplicar procedimientos para la evaluacin de software
tendientes a evaluar el proceso de desarrollo y los productos comerciales.
- Identificar y analizar los estndares actuales utilizados para evaluar la calidad del
software y cuales son los significados de los factores y requisitos que debe cumplir
un software de calidad.
- Aplicar los conceptos de la evaluacin de software y aplicar procedimientos para
la evaluacin de software tendientes a evaluar el proceso de desarrollo y los
productos comerciales.
METAS
El estudiante estar capacitado para:
- Identificar los ciclos de vida para desarrollo de software
- Identificar las fases o etapas de cada uno de los ciclos de vida.
- Identificar los aspectos a tener en cuenta en la calidad de software
15
- Identificar y conocer los estndares y mtricas de calidad de software
- Conocer y comprender los procedimientos para la evaluacin de software.
COMPETENCIAS
- El estudiante identifica, analiza, y comprende los diferentes enfoques o ciclos de
vida utilizados para el desarrollo de software de acuerdo al tipo de proyecto, cada
una de las fases y cmo asegurar la calidad durante cada una de las fases.
- El estudiante esta en capacidad de identificar los estndares de calidad, las
mtricas, los factores y requisitos que se deben cumplir los productos software.
- El estudiantes esta en la capacidad de realizar los procedimientos de evaluacin
de software de manera objetiva y respetando los principios de la tica profesional.
- El estudiante esta en capacidad de comprender la realidad de un entorno
empresarial y elabora propuestas para el desarrollo de software y evaluar posibles
soluciones mejorando el desempeo de las mismas contribuyendo al desarrollo de
la regin.
16
UNIDAD 1
PROCESO DE
DESARROLLO DE
SOFTWARE
17
CAPITULO 1
CICLOS DE VIDA DEL
SOFTWARE
18
1.1 LECCIN 1: CONCEPTOS GENERALES SOBRE CICLOS DE VIDA
El ciclo de vida de software es la descripcin de las distintas formas de
desarrollo de un proyecto informtico. Es la orientacin que se sigue para que a
partir de los requerimientos del cliente se obtengan sistemas que puedan ser
utilizados por los usuarios. Otra de las definiciones ms tcnicas, dice que un ciclo
de vida es un conjunto de fases o etapas, procesos y actividades requeridas para
el desarrollo y la explotacin de un producto software.
El ciclo de vida seleccionado en un proyecto, influye en el xito del mismo,
asegurando que cada actividad aporte al cumplimiento del objetivo que se ha
propuesto. Dependiendo del ciclo de vida seleccionado, se puede aumentar la
velocidad de desarrollo, mejorar la calidad, el control y el seguimiento del
proyecto, minimizar los costos y los riesgos, y mejorar las relaciones con los
clientes.
El ciclo de vida en cascada, fue uno de los primeros modelos de ciclo de
vida que formaliz un conjunto de procesos de desarrollo de software. Este
modelo describe un orden secuencial en la ejecucin de los procesos asociados.
El modelo espiral se postul como una alternativa al modelo de cascada. La
ventaja de este modelo radica en el perfeccionamiento de las soluciones
encontradas con cada ciclo de desarrollo, en trminos de dar respuesta a los
requerimientos inicialmente analizados. El modelo de cascada y el modelo espiral
suponen que los requerimientos del cliente no cambian radicalmente en el
transcurso del desarrollo del sistema.
Los prototipos apoyan diferentes modelos de ciclo de vida. Un prototipo
tiene el objetivo de mostrar al cliente o a la gerencia del proyecto el resultado que
se obtendr de la implementacin de cada uno de los requerimientos del cliente
una vez terminado el desarrollo. La solucin a algunos de los problemas
presentados por las metodologas tradicionales se logra con una gran evolucin
del modelo espiral. El proceso unificado propone la elaboracin de varios ciclos de
desarrollo, donde cada uno finaliza con la entrega al cliente de un producto
terminado. Este se enmarca entre los conocidos modelos iterativo-incremental.
Algunos grupos de desarrollo han experimentado soluciones que basan su
fundamento en la adaptabilidad de los procesos de desarrollo, esta comunidad de
desarrolladores e investigadores han nombrado su trabajo bajo lo que se conoce
como metodologas giles. Las metodologas giles, promueve la formalizacin de
procesos adaptables. La compilacin de los principios y valores que resaltan las
metodologas giles fue formalizada en el manifiesto para el desarrollo de software
gil.
La metodologa XP, una de las metodologias giles ms difundidas que
define pocas reglas y pocas prcticas. XP promueve la adaptabilidad de los
procesos de desarrollo basndose en los principios y prcticas que presenta.
19
Quienes trabajan usando XP deben seguir procesos disciplinados, adems de
combinar la disciplina con la adaptabilidad necesaria del proceso. Las
metodologas de Cristal se basan en el principio de que tipos diferentes de
proyectos requieren tipos diferentes de metodologas. La metodologa escogida
debe depender de dos factores: el nmero de personas en el proyecto, y las
consecuencias de los errores. Conforme al principio de las metodologas giles,
Scrum recalca la imposibilidad de encontrar procesos definidos y repetibles
cuando no existen problemas, personas, ni ambientes definidos y repetibles.
Al utilizar las metodologas tradicionales el problema es que casi nunca se
logra planear bien el esfuerzo requerido para seguir la metodologa. Pero si se
logra definir mtricas que apoyen la estimacin de las actividades de desarrollo. El
no poder predecir siempre los resultados de cada proceso significa que
actualmente se debe hacer frente a la necesidad de adaptacin de los procesos
de desarrollo que son llevados por parte de los equipos que construyen software.
Tener metodologas diferentes para aplicar de acuerdo con el proyecto que
se desarrolle resulta interesante ya que estas pueden involucrar prcticas tanto de
metodologas giles como de metodologas tradicionales. De esta manera se
puede plantear una metodologa por cada proyecto, el problema se centrar en
definir cada una de las prcticas, y en el momento preciso definir parmetros para
saber cual usar.
Al elegir el modelo de ciclo de vida se debe tener en cuenta algunos
factores como el contexto, fundamentos bsicos, los obstculos y ventajas. Esto
incluye realizar un estudio de las prcticas que se van a poner en ejecucin dentro
de un proyecto. Los modelos deben ser estructurados teniendo en cuenta las
caractersticas propias del proyecto y pueden ser hbridos con una mezcla de
modelos tradicionales y giles.
Un modelo de ciclo de vida exitoso en un contexto, no necesariamente lo es
en otro contexto. Por ejemplo, ante el surgimiento de los Parques Tecnolgicos
que incluyen empresas de desarrollo de software, se debe tomar en cuenta las
caractersticas propias del contexto de un grupo de jvenes emprendedores sin
altos recursos para realizar inversin, con necesidad de poner en el mercado en
relativo poco tiempo un software altamente funcional de excelente calidad. Ante
este panorama se plantea la necesidad de redefinir el modelo de desarrollo con el
fin de mejorar los resultados en trminos de un conjunto de atributos como pueden
ser la calidad del software y la precisin de los planes realizados. Tambin surgen
las preguntas de cmo evaluar el proceso de desarrollo, la identificacin del
conjunto de caractersticas que rodean los desarrollos, e impactan de manera
significativa los resultados del equipo y cmo identificar el conjunto de prcticas
adecuadas para incluir en un nuevo modelo de ciclo de vida de desarrollo.
A continuacin se hace un repaso de los diferentes ciclos de vida
existentes, teniendo en claro que no existe un modelo de ciclo de vida general
para cualquier tipo de proyecto. Cada proyecto debe seleccionar para cada caso
20
especfico el ciclo de vida ms adecuado, teniendo en cuenta la cultura
empresarial, el deseo de asumir riesgos, el rea de aplicacin, la volatilidad de los
requisitos y su entendimiento. El ciclo de vida elegido servir para relacionar las
tareas que forman parte del proceso software de cada proyecto.
1.2 LECCIN 2: CICLOS DE VIDA TRADICIONALES
1.2.1. Ciclo de vida clsico o en cascada
Este modelo fue presentado por primera vez por Royce en 1970. Se
representa frecuentemente como un simple modelo con forma de cascada de las
etapas del software, como lo muestra la siguiente figura:
Figura 1. Modelo en Cascada
En este modelo la evolucin del producto software procede a travs de una
secuencia ordenada de transiciones de una fase a la siguiente segn el orden
lineal. Este modelo semeja una mquina de estados finitos para la descripcin de
la evolucin del producto software. El modelo en cascada ha sido til para ayudar
a estructurar y gestionar grandes proyectos de desarrollo de software dentro de
las organizaciones. Este modelo permite iteraciones durante el desarrollo, dentro
de un mismo estado o de un estado a otro anterior. La mayor iteracin se produce
cuando una vez terminado el desarrollo y cuando se ha visto el software
producido, se decide comenzar de nuevo y redefinir los requerimientos del
usuario.
21
Sin embargo, durante el desarrollo se puede tomar decisiones que den
lugar a las diferentes alternativas. Por ejemplo, dependiendo del anlisis de
requisitos se puede implementar el sistema desde cero, o adoptar uno ya
existente, o comprar un paquete que proporcione las funcionalidades requeridas.
El modelo en cascada ha sido transformado numerosas veces y es el ms
utilizado, aunque incorporando infinidad de variaciones que eliminan el carcter
simplista del mismo. An hoy en da se asume que para que un proyecto tenga
xito, todas las fases del modelo deben cumplirse y cualquier desarrollo en
diferente orden de estados dar un producto de inferior calidad.
Entre las limitaciones que se argumentan a este modelo se pueden sealar
las siguientes: El modelo asume que los requisitos se pueden conseguir antes de
iniciar la etapa de diseo, eso para los sistemas nuevos es poco realista, el
mantener los requisitos requiere seleccionar el hardware, pero la terminacin de
un proyecto puede llevar aos, y dada la velocidad de obsolescencia de la
tecnologa, es probable que el software final utilice hardware obsoleto, en caso de
sistemas no desarrollados para clientes especficos, y los desarrollados por
terceros, que frecuentemente salen al mercado, los requisitos son determinados
por los desarrolladores, por eso es mejor desarrollar primero una parte del sistema
y posteriormente optimizarlo.
Pero el punto ms lgido de este modelo es que enva al cliente el producto
solamente despus de que se han consumido el 90% de los recursos, esto
significa que la mayor parte de la retroalimentacin del cliente sobre sus
necesidades se obtiene al final.
Este ciclo de vida tiene tres factores muy positivos: El primero, es que las
etapas estn organizadas de un modo lgico, una etapa no puede llevarse a cabo
hasta que se haya tomado las decisiones de continuar a la siguiente, es as como,
el diseo espera a los requisitos, la codificacin espera al diseo, el segundo es
que cada etapa incluye un proceso de revisin y se necesita la aceptacin del
producto antes de que la salida de la etapa pueda utilizarse, y el tercero es que el
ciclo es iterativo, en cuanto a que reconoce que los problemas encontrados en
etapas inferiores afectan a las decisiones de las etapas superiores.
Existe una visin alternativa de este modelo que enfatiza la validacin de
los productos y el proceso de composicin existente en la construccin de
sistemas software. Este proceso consiste en lo siguiente: Los requerimientos
generales se dividen en requerimientos de hardware y software, los
requerimientos de software llevan al anlisis preliminar de mltiples funciones,
cada una de las cuales se expande en el diseo detallado que a su vez
evoluciona en un nmero mayor de programas unitarios, al ensamblar el producto
se procede al contrario, dentro de un proceso de sntesis o composicin, donde
primero se aceptan los programas unitarios probados, estos se agrupan en
mdulos que a su vez deben ser aceptados una vez probados, luego, los mdulos
se agrupan para certificar el grupo formado por todos ellos incluyen todas las
22
funcionalidades deseadas y finalmente, el software es integrado con el hardware
hasta formar un nico sistema informtico que satisface los requerimientos
globales.
El producto obtenido en cada etapa no solo determina que debe hacerse en
la fase siguiente del proceso, sino que tambin establece los criterios para
determinar si el producto compuesto y ensamblado satisface los objetivos de la
etapa. El ciclo de vida esta estructurado de tal modo que en cada etapa se define
qu debe hacerse en el prximo paso de descomposicin, pero tambin se
documentan los criterios para determinar si el producto compuesto que resulta
satisface las intencionalidades que se tenan hacia l.
1.2.2 Ciclo de vida de refinamiento sucesivo o mejora iterativa
Las etapas que forman este ciclo de vida son las mismas que el modelo en
cascada y su realizacin sigue el mismo orden. Sin embargo, este modelo
recomienda desarrollar los sistemas software a travs de un refinamiento y
mejora continuos desde las especificaciones de alto nivel del sistema hasta los
componentes de cdigo fuente. Este modelo asume que el producto generado en
cada etapa no se produce de manera lineal, del principio al final de la etapa, sino
al contrario, predica la generacin de productos de manera iterativa mediante un
proceso de refinamiento. Debido a la marcha atrs permitida en el modelo en
cascada, se abre un camino desde una etapa hacia otra anterior, el refinamiento
iterativo puede producirse tambin a nivel global de todas las etapas.
Figura 2: ciclo de vida en cascada con validacin
23
1.2.3 Ciclo de vida con emisin gradual
Este modelo propone desarrollar sistemas produciendo, en primer lugar, las
funciones esenciales de operacin y posteriormente proporcionar a los usuarios
mejoras y versiones ms capaces del sistema a intervalos regulares. Este modelo
combina el ciclo de vida clsico de software con mejoras iterativas a nivel del
desarrollo del sistema global. Tambin proporciona una manera de distribuir
peridicamente actualizaciones del mantenimiento de software comercial.
1.2.4 Estndares militares y prcticas industriales
Las empresas industriales adoptan con frecuencia alguna variacin del
modelo clsico como base de la prctica del desarrollo de software. Muchos
proveedores de la administracin americana organizan sus actividades de
acuerdo con los modelos del ciclo de vida del estndar militar, tal como el de la
norma MIL-STD-2167 de 1987. Tales estndares subrayan no solo alguna
variacin de las actividades del ciclo de vida clsico, sino que tambin contienen lo
documentos que deben entregarse a los clientes que necesitan sistemas software
o mecanismos complejos como sistemas software embebidos. Estos estndares
deben ser compatibles con la garanta de calidad del software, la gestin de
configuraciones y la verificacin y validacin independiente de servicios en un
proyecto de desarrollo con ms de un contratista. Estos modelos ponen especial
nfasis en la definicin de productos entregables, revisones, hitos y tcnicas
requeridas en cada caso.
1.3 LECCIN 3: CICLOS DE VIDA ALTERNATIVOS
Existen por lo menos tres conjuntos alternativos a los modelos de evolucin
de los productos software tradicionales. Estos modelos centran su atencin bien
sobre productos diferentes a los clsicos o sobre procesos especiales de
produccin o sobre entornos de produccin. Dado que estos modelos no estn
an muy extendidos, se considera fundamental su presentacin aqu por las
potencialidades que presentan.
1.3.1 Ensamblaje de componentes reutilizables
El enfoque bsico de la reutilizacin es configurar y especializar
componentes de software ya existentes. Sin embargo, la granularidad de los
componentes, es decir, el tamao, complejidad y capacidad funcional, vara
grandemente a lo largo de los distintos enfoques. La mayora de ciclos de vida
basados en ensamblaje de componentes intentan utilizar componentes similares a
estructuras de datos con los algoritmos incorporados para su manipulacin
24
denominados componentes de grano fino. Sin embargo, el uso de componentes
de grano fino no constituye un enfoque distinto a la evolucin del producto
software tradicional. Otros enfoques intentan utilizar componentes ensamblando
funcionalmente sistemas o subsistemas completos; por ejemplo, sistemas de
gestin de interfaces de usuario, en este caso se trata de componentes de grano
grueso. El uso o la reutilizacin de estos componentes aparecen como un enfoque
alternativo al desarrollo de sistemas software. Hay probablemente, muchas formas
de emplear componentes de software reutilizables al desarrollar software. Sin
embargo, hasta ahora parece ser que la mejor forma de implementacin rpida es
usarlo durante el diseo arquitectnico. Los componentes reutilizables tambin
pueden usarse con propsitos de prototipado.
1.3.2 Generacin de aplicaciones
Es un enfoque de desarrollo de software similar a la reutilizacin de
componentes de software de grano grueso, pero en este caso, parametrizados.
Tales componentes estn especializados en un dominio de aplicacin, va un
lenguaje de especificacin formalizado usado como entrada para el generador de
la aplicacin. Ejemplos comunes de este enfoque son las interfaces
estandarizados de aplicaciones de sistemas de gestin de bases de datos que
incluyen generadores de informes, grficos, editores especficos de la aplicacin e
interfaz de usuario. El uso de generadores da lugar a un modelo de evolucin del
producto software mediante el cual la actividad de diseo del software o es casi
eliminada, o reducida a un problema de diseo de bases de datos. Similarmente
los usuarios de los generadores de aplicaciones esperan habitualmente
proporcionar especificaciones de entrada y servicios de mantenimiento de la
aplicacin. Estas capacidades son posibles dado que los generadores pueden
producir solo sistemas software especfico para un pequeo nmero de dominios
de aplicacin similares y en especial aquellos que dependen de un sistema de
gestin de bases de datos.
1.4 LECCIN 4: MODELOS DE PROCESO DE PRODUCCIN DE
SOFTWARE
1.4.1 Modelos operativos
El enfoque operativo para el desarrollo de software supone la existencia de
un lenguaje de especificain formal y un entorno de proceso. Las especificaciones
estn codificadas en el lenguaje y constituyen un proptotipo funcional del sistema
especificado. Cuando tales especificaciones son desarrolladas gradualmente, el
prototipo resultante puede refinarse y desarrollarse en sistemas funcionalmente
ms completos que siempre estn operativos durante su desarrollo. Variaciones
dentro de este enfoque representan esfuerzos donde el prototipo es el fin
25
buscado, o bien situaciones donde los prototipos especificados se conservan
operativos pero refinados dentro de un sistema completo.
1.4.1.1Automatizacin de la programacin y del proceso software: La
automatizacin del proceso y la programacin estn relacionados con el desarrollo
de las especificaciones formales de cmo una familia de sistemas software debe
desarrollarse, estas especificaciones deberan proporcionar una estimacin para la
organizacin y descripcin de las distintas cadenas de produccin software, como
estn interrelacionadas, cundo iteran, y qu herramientas software deberan
utilizarse.
El desarrollo de software utilizando tcnicas de cuarta generacin se
caracteriza por facilitar la especificacin de algunas de las funcionalidades de alto
nivel. La herramienta genera a continuacin, el cdigo o parte de l a partir de la
especificacin. Esta especificacin se hace en un lenguaje lo ms prximo al
lenguaje natural. El concepto de desarrollo con uso de herramientas de cuarta
generacin se utiliza varias herramientas dentro de las cuales se encuentran los
lenguajes no procedimentales para las bases de datos, generacin de informes y
pantallas de captura, para la generacin de cdigo y las capacidades grficas de
alto nivel combinados con hojas de clculo.
Una vez hecha la especificacin de los requerimientos, la generacin de
cdigo es casi automtica, con lo que el tiempo de desarrollo se reduce
drsticamente. Con el cdigo generado se empieza a revisar las funcionalidades
de la aplicacin y se va aadiendo prestaciones de forma interactiva hasta
completar el producto.
Esta tcnica permite la construccin de programas al usuario y permite la
revisin y actualizacin personal, con lo que es muy difcil la equivocacin en
cuanto al cumplimiento de requerimientos. En la actualidad su uso se reduce a
sistemas de gestin con un grado de complejidad no muy elevado.
1.4.1.2 Automatizacin del Software Basado en Conocimientos: Este modelo
intenta llevar el proceso de automatizacin hasta sus lmites al suponer que
pueden usarse las especificaciones de proceso para desarrollar directamente
sistemas software y configurar entornos de desarrollo para soportar las tareas en
curso.
Los sistemas expertos son un caso particular en el ciclo de vida del
software, ya que su particularidad les hace disponer de sus propios ciclos de vida.
En este ciclo de vida las fases se pueden activar en paralelo, y reactivar en
cualquier momento, sin necesidad de ejecutar ciclos completos. Se pueden utilizar
tcnicas de prototipado, pero la expansin al sistema final a partir del prototipo es
mucho ms directa, ya que pueden bastar con incrementar la base de reglas de
inferencia o la base de conocimientos.
26
Por otra parte, la definicin interna de lo que debe hacer el sistema experto
no queda clara ni siquiera al final del desarrollo, porque lo que se trata de
modelizar es el razonamiento de los expertos humanos. Por lo tanto no existen
nunca unos requisitos claros para poder validar el resultado.
Las fases de desarrollo de un sistema experto son las siguientes:
Identificacin del problema, estudio de factibilidad, identificacin de subproblemas,
identificacin de conceptos y relaciones, diseo conceptual, diseo detallado,
cdigo, prueba de razonamiento, prueba del conocimiento, validacin, conversin,
mantenimiento y mejoras.
Muchas de estas etapas se producen en paralelo e influyen unas en otras,
con lo que el diagrama de bloques que lo representa, en vez de ser secuencial es
un grupo de cajas que interactan, pero que estn una al lado de la otra en el
tiempo.
El enfoque comn a estos tres modelos mencionados es buscar la
automatizacin del modelo de transformacin continuo. A su vez, esto implica un
entorno automatizable capaz de registrar el desarrollo formalizado de las
especificaciones operativas, transformando y refinando sucesivamente dichas
especificaciones en un sistema implementado, asimilando los requisitos de
manteniemiento al insertar las especificaciones nuevas en el desarrollo, y luego
llevando el desarrollo revisado a la implementacin.
1.4.2 Modelos no operativos
Estos modelos incorporan mtodos de proceso dirigidos por las
especificaciones y por los prototipos.
1.4.2.1 Modelo en espiral: El modelo en espiral representa un enfoque dirigido al
anlisis de riesgos y estructuracin de procesos de software. El enfoque incorpora
mtodos de proceso dirigidos por las especificaciones y por los prototipos. Esto se
lleva a cabo representando ciclos de desarrollo iterativos en forma de espiral,
denotando los ciclos internos del ciclo de vida anlisis y prototipado temprano, y
los externos el modelo clsico. La dimensin radial indica los costos de desarrollo
acumulativos y la angular el progreso hecho en cada desarrollo en espiral.
El anlisis de riesgos, que busca identificar situaciones que pueden causar
el fracaso o sobrepasar el presupuesto o el plazo, aparecen durante cada ciclo de
la espiral. En cada ciclo, el anlisis de riesgos representa la misma cantidad de
desplazamiento angular, mientras que el volumen desplazado barrido denota el
crecimiento de los niveles de esfuerzo requeridos para el anlisis de riesgo como
lo muestra la siguiente figura:
27
Figura 3: ciclo de vida en espiral
Una de las ventajas de este modelo es que permite utilizar los modelos de
proceso de construccin de software tradicionales, mientras su orientacin al
riesgo evita muchas dificultades. De hecho, en situaciones apropiadas, el modelo
en espiral proporciona una combinacin de los modelos existentes para un
proyecto determinado.
Otras ventajas de este modelo son las siguientes: Presta atencin a las
opciones que permiten la reutilizacin de software existente, est centrado en la
eliminacin de errores y alternativas poco atractivas, no establece una
diferenciacin entre desarrollo de software y mantenimiento del sistema, y
proporciona un marco estable para desarrollos integrados hardware - software.
1.4.2.2 Modelos de Transformacin contnua: Estos modelos proponen un
proceso por el cual los sistemas software se desarrollan a travs de una serie de
transformaciones continuas de problemas establecidos en especificaciones
abstractas dentro de implementaciones concretas.
Se propone un esquema por el cual no hay ciclo de vida tradicional ni
etapas separadas, en su lugar se llevan a cabo una serie de transformaciones y
refinamientos graduales de especificaciones abstractas para llegar a programas
ms concretos. En este sentido, las frases que definen el problema y los sistemas
28
software pueden emerger de algunas maneras juntas y as continuar
coevolucionando.
Los modelos de transformacin continuada tambin se acomodan al inters
de los formalistas del software que buscan de manera precisa, las propiedades
formales de las especificaciones de los sistemas software. De acuerdo a esto, los
formalismos especificados pueden ser transformados matemticamente en
propiedades que una implementacin fuente debera satisfacer.
1.4.2.3 Modelos de Procesos Miscelneos: Se han propuesto muchas
variaciones de los modelos de proceso y ciclos de vida no operativos. Esto incluye
ciclos de vida completamente interconectados que se acomodan a las transiciones
entre dos fases sujetas a la satisfaccin de sus precondiciones y sus
postcondiciones as como a las variaciones de los componentes sobre el ciclo de
vida tradicional y modelos de transformacin contina.
1.4.2.4 Modelos de entorno de produccin software: El proceso de produccin
o de producto de la evolucin del software, los modelos del entorno de produccin
dirigen su atencin a la organizacin y gestin de estrategias para desarrollar y
producir sistemas software. Como tales, el foco es menos tecnolgico y ms
estratgico. Pero debera quedar claro que tales estrategias afectan tanto a los
productos software que consiguen desarrollarse, como a la forma que ser
organizado el proceso de produccin del software. Entre estos modelos se pueden
mencionar los siguientes: Modelos de proceso de Gestin de Proyectos software,
Modelos Organizadores de Desarrollo de Software, Modelos de ciclo de Vida de
Recursos de Clientes, modelos de Transicin y Transferencia de tecnologa
software y otros modelos para la organizacin, fabricacin y produccin de
sistemas software.
1.5 LECCIN 5: CICLOS DE VIDA GILES
El trmino gil aplicado al desarrollo de software nace en el ao 2001, tras una
reunin en donde participan un grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores o impulsores de metodologas de software.
Su objetivo fue esbozar los valores y principios que deberan permitir a los grupos
desarrollar software rpidamente y respondiendo a los cambios que puedan surgir
a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de
desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por
la documentacin que se genera en cada una de las actividades desarrolladas.
Despus de dicha reunin nace The Agile Alliance, una organizacin,
dedicada a promover los conceptos relacionados con el desarrollo gil de software
y ayudar a las organizaciones para que adopten dichos conceptos, algunos de
estos modelos propuestos y ms difundidos pertenecientes a esta filosofa son:
29
1.5.1 Programacin Extrema (XP)
Kent Beck, el padre de XP, describe la filosofa de XP como una metodologa gil
que potencia las relaciones interpersonales como clave para el xito en desarrollo
de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje
de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin
fluida entre todos los participantes, simplicidad en las soluciones implementadas y
disposicin para enfrentar los cambios. XP se define como adecuada para
proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto
riesgo tcnico. Los principios y prcticas son de sentido comn pero llevadas al
extremo, de ah proviene su nombre.
Figura 4: Ciclo de vida XP
1.5.2 SCRUM
Este un proceso gil que se puede usar para gestionar y controlar
desarrollos complejos de software y productos usando prcticas iterativas e
incrementales. Es un proceso incremental iterativo para desarrollar cualquier
producto o gestionar cualquier trabajo. Aunque este proceso estaba previsto que
fuera para la gestin de proyectos de desarrollo de software, se puede usar
tambin para la ejecucin de equipos de mantenimiento de software o como un
enfoque de gestin de programas.
SCRUM define un marco para la gestin de proyectos, que se ha utilizado
con xito durante los ltimos 10 aos. Est especialmente indicada para proyectos
con un rpido cambio de requisitos. Sus principales caractersticas se pueden
30
resumir en dos. El desarrollo de software se realiza mediante iteraciones,
denominadas sprints, con una duracin de 30 das, el resultado de cada sprint es
un incremento ejecutable que se muestra al cliente. La segunda caracterstica
importante son las reuniones a lo largo proyecto, entre ellas destaca la reunin
diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin.
SCRUM es un esqueleto de proceso que incluye un conjunto de prcticas y
roles predefinidos, los roles principales son el ScrumMaster que mantiene los
procesos y trabaja junto con el jefe de proyecto, el Product Owner que
representa a las personas implicadas en el negocio y el Team que incluye a los
desarrolladores. Durante cada iteracin (sprint- periodos de tiempo), tpicamente
un periodo de 2 a 4 semanas (longitud decidida por el equipo), el equipo crea un
incremento de software operativo.
Figura 5: Metodologa SCRUM
El conjunto de caractersticas que entra en una iteracin viene del backlog
del producto, que es un conjunto priorizado de requisitos de trabajo de alto nivel
que se han de hacer. Los tems que entran en una iteracin se determinan durante
la reunin de planificacin de la iteracin. Durante esta reunin, el Product Owner
informa al equipo de los tems en el backlog del producto que quiere que se
completen. El equipo determina entonces a cuanto de eso puede comprometerse
a completar durante la siguiente iteracin.
31
1.5.3 Agile Unified Process (AUP)
El proceso unificado gil (AUP) es una versin simplificada de RUP
desarrollada por Scout Ambler. Describe un enfoque simple, fcil de entender, del
desarrollo de software de aplicacin de negocios usando tcnicas y conceptos
giles. AUP aplica tcnicas giles incluyendo desarrollo orientado a pruebas,
modelado gil, gestin de cambios gil y refactorizacin de bases de datos para
mejorar la productividad.
La naturaleza en serie de AUP se presenta en cuatro fases: Inicio, el
objetivo es identificar el alcance inicial del proyecto, una arquitectura potencial
para el sistema y obtener fondos y aceptacin por parte de las personas
involucradas en el negocio; la elaboracin, el objetivo es probar la arquitectura del
sistema; la construccin, el objetivo es construir software operativo de forma
incremental que cumpla con las necesidades de prioridad ms altas de las
personas involucradas en el negocio; transicin, el objetivo es validar y desplegar
el sistema en el entorno de produccin.
1.5.4 Dynamic System Development Method (DSDM)
Nace en 1994 con el objetivo de crear una metodologa RAD unificada. Sus
principales caractersticas son: es un proceso iterativo e incremental y el equipo de
desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad,
estudio del negocio, modelado funcional, diseo y construccin, y finalmente
implementacin. Las tres ltimas son iterativas, adems de existir realimentacin a
todas las fases.
El mtodo de desarrollo de sistemas dinmico (DSDM) es una metodologa
de desarrollo de software originalmente basada en la metodologa RAD. DSDM es
un enfoque iterativo e incremental que enfatiza la participacin continua del
usuario cuyo objetivo es entregar sistemas software en tiempo y presupuesto
ajustndose a los cambios de requisitos durante el proceso de desarrollo. DSDM
es uno de los mtodos giles para el desarrollo de software, y forma parte de la
Alianza gil.
Como extensin del desarrollo rpido de aplicaciones, DSDM se centra en
proyectos de sistemas de informacin que se caracterizan por planificaciones y
presupuestos estrictos. DSDM trata las caractersticas ms comunes de los
proyectos de sistemas de informacin, incluyendo presupuestos sobrepasados,
plazos de entrega desaparecidos y falta de participacin del usuario y compromiso
de la alta gerencia.
1.5.5 Crystal Methodologies
Se trata de un conjunto de metodologas para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo y la
32
reduccin al mximo del nmero de artefactos producidos. El desarrollo de
software se considera un juego cooperativo de invencin y comunicacin, limitado
por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se
deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener
polticas de trabajo en equipo definidas. Estas polticas dependern del tamao del
equipo, establecindose una clasificacin por colores, por ejemplo Crystal Clear (3
a 8 miembros) y Crystal Orange (25 a 50 miembros).
Crystal Clear es un miembro de la familia de metodologas Crystal como
describe Alistair Cockburn y se considera un ejemplo de metodologa gil. Crystal
Clear est pensado para aplicarse a equipos pequeos de 6 a 8 desarrolladores
ubicados en el mismo sitio trabajando en sistemas que no son crticos. La familia
de metodologas Crystal se centra en la eficiencia y habitabilidad como
componentes de la seguridad del proyecto. Crystal Clear se centra en las
personas, no en los procesos o artefactos.
Crystal Clear cuenta con las siguientes propiedades: Entrega frecuente de
cdigo usable a los usuarios, mejora reflexiva, comunicacin osmtica
preferiblemente estando en la misma ubicacin, seguridad personal, fcil acceso a
los usuarios expertos y pruebas automatizadas, gestin de la configuracin e
integracin frecuente.
1.5.6 Adaptive Software Development (ASD)
Sus principales caractersticas son: iterativo, orientado a los componentes
software ms que a las tareas y tolerante a los cambios. El ciclo de vida que
propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje. En
la primera de ellas se inicia el proyecto y se planifican las caractersticas del
software; en la segunda desarrollan las caractersticas y finalmente en la tercera
se revisa su calidad, y se entrega al cliente. La revisin de los componentes sirve
para aprender de los errores y volver a iniciar el ciclo de desarrollo.
1.5.7 Feature-Driven Development (FDD)
Define un proceso iterativo que consta de 5 pasos. Las iteraciones son
cortas (hasta 2 semanas). Se centra en las fases de diseo e implementacin del
sistema partiendo de una lista de caractersticas que debe reunir el software.
33
Figura 6: Ciclo de vida FDD
1.5.8 Lean Development (LD)
Definida por Bob Charette a partir de su experiencia en proyectos con la
industria japonesa del automvil en los aos 80 y utilizada en numerosos
proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran
riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades
que mejoren la productividad del cliente. Su principal caracterstica es introducir un
mecanismo para implementar dichos cambios.
34
CAPITULO 2
DESARROLLO DE SOFTWARE
35
INTRODUCCIN
A continuacin se describe en detalle las fases o subprocesos que
conforman el proceso base de construccin de software correspondiente al
estndar IEEE 1074-1989. Cada subproceso detalla el nivel de propsito,
actividades involucradas y documentacin principal propuesta por el estndar. El
estndar determina el conjunto de actividades esenciales, no ordenadas en el
tiempo, que deben ser incorporadas dentro de un modelo de ciclo de vida de un
producto software. Este modelo es seleccionado y establecido por el usuario para
el proyecto a desarrollar, ya que la norma no define un ciclo de vida particular.
El estndar ha sido escrito por organizaciones responsables de la gestin y
desarrollo de software y est dirigido a los gestores de proyectos, a los
desarrolladores de software, a los responsables de la garanta de calidad, a
quienes ejecutan tareas de apoyo, y al personal de mantenimiento.
El proceso base para la construccin de software consiste en analizar las
necesidades de la organizacin en un dominio, bajo un marco de gestin,
seguimiento, control y gestin de la calidad. El proceso de software est
compuesto de cuatro procesos principales cada uno de los cuales agrupa una
serie de actividades que se encargan de la realizacin de sus requisitos
asociados. Estos son los siguientes:
- Proceso de seleccin de un modelo de ciclo de vida del producto que
identifica y selecciona un ciclo de vida para el software que se va a a
construir.
- Proceso de gestin del proyecto, donde se crean la estructura del proyecto
y aseguran el nivel apropiado de la gestin del mismo durante todo el ciclo
de vida del software.
- Procesos orientados al desarrollo del software, que producen, instalan,
operan y mantienen el software y lo retiran de su uso. Se clasifican en
procesos de pre-desarrollo, desarrollo y post-desarrollo.
- Procesos integrales del proyecto, que son necesarios para completar con
xito lasa actividades del proyecto software. Aseguran la terminacin y
calidad de las funciones del mismo. Son simultneos a los procesos
orientados al desarrollo de software e incluyen e incluyen actividades de no
desarrollo.
En el modelo de proceso software se puede detallar los cuatro procesos
principales: el proceso de seleccin del ciclo de vida, el proceso de gestin dl
proyecto, los procesos orientados al desarrollo del software y los procesos
integrales del proyecto.
36
2.1 LECCIN 1: PROCESOS DE GESTIN DEL PROYECTO
La gestin del proyecto presupone establecer condiciones para el desarrollo
del mismo, la gestin involucra actividades dentro de las cuales tenemos:
La planificacin de proyectos, define la prediccin de la duracin de las
actividades y tareas a nivel individual, los recursos requeridos, la concurrencia y la
superposicin de tareas para que sean desarrollados en paralelo y el camino
crtico a travs de la red de actividades.
La estimacin, que se define como la prediccin de personal, el esfuerzo y
costos que se requerir para terminar todas las actividades y productos conocidos
asociados con el proyecto.
La determinacin del tamao del producto a desarrollar, que es una de las
primeras tareas en la gestin del proyecto, ya que sin conocerlo adecuadamente,
no es posible planificar y estimar el esfuerzo necesario. El tamao se define como
la cantidad de cdigo fuente, especificaciones, casos de prueba, documentacin
del usuario y otros productos tangibles que son la salida del proyecto.
El seguimiento de proyectos, que es la recoleccin de datos y su
acumulacin sobre recursos consumidos, costos generados, e hitos asociados con
el proyecto.
La medicin de un proyecto, que se define como el registro de todos los
productos generados en el mismo, de todos los recursos requeridos, planificacin
y superposicin de todas las actividades y de todos los factores que impactan en
el proyecto como los conocimientos, mtodos, herramientas, lenguajes,
limitaciones, problemas y el entorno fsico.
2.1.1 Proceso de iniciacin del proyecto
Abarca aquellas actividades de creacin de la estructura del proyecto, aqu
se define el ciclo de vida del software para este proyecto y se establecen los
planes para su gestin. Se determinan los costos y recursos necesarios a fin de
ejecutar las distintas tareas que demanda el proyecto. Se identifican y seleccionan
estndares, metodologas y herramientas para la gestin, herramientas para la
ejecucin del mismo y por ltimo se prepara y establece un plan para su
implementacin adecuada y oportuna. El plan de gestin de proyectos software
que conducir al desarrollo se produce como culminacin de este proceso.
A continuacin se presenta una tabla de actividades a realizar, la
documentacin que se obtine y cuales tcnicas se aplican.
37
Actividades a realizar Documentacin de
salida
Tcnicas a utilizar
Establecer el mapa de
actividades para el ciclo
de vida del software
seleccionado
Asignar los recursos del
proyecto
Definir el entorno del
proyecto
Planificar la gestin del
proyecto
Plan de
gestin del
proyecto
Plan de retiro
Anlisis de camino crtico
(CPM)
Anlisis PERT
Diagrama de GANTT
Tcnicas Estadsticas
Tcnicas de simulacin
(mtodo de MONTECARLO)
Puntos de funcin
Modelos empricos de
estimacin (COCOMO,
PUTMAN)
Tcnicas de
Descomposicin Funcional
Tabla 1: Proceso de iniciacin del proyecto
2.1.2 Proceso de seguimiento y control del proyecto
Es un proceso iterativo de seguimiento, registro y gestin de costos,
problemas y rendimiento de un proyecto durante su ciclo de vida. En este proceso
se realiza un anlisis de riesgos de tipo econmico, tcnico, operativo, de soporte,
y del programa o calendario, que permite identificar los problemas potenciales,
determinar su probabilidad de ocurrencia y su impacto, y establecer los pasos para
su gestin. De aqu surge el plan de contingencias donde se identifica los riesgos,
se evalan y se gestionan. En la siguiente tabla se identifican las actividades a
realizar, la documentacin que se obtine y cuales tcnicas se aplican.
salida
Tcnicas a utilizar
Analizar los riesgos
Realizar la
planificacin de
contingencias
Gestionar el proyecto
Archivar los registros
Implementar el
sistema de informes
de problemas
Anlisis de
riesgos
Plan de
contingencias
Registro histrico
de proyectos
Anlisis de riesgo tcnico
(Modelizacin y
Simulacin Esttica y
Dinmica, prototipado,
revisiones, auditorias)
Anlisis de riego
econmico (Anlisis de
finanzas, Retorno de la
inversin)
Anlisis de riesgo
operativo y de soporte
Anlisis de ri riesgo de
programa (Anlisis del
camino crtico CPM,
Tcnicas de nivelacin de
recursos)
Tabla 2: Proceso de seguimiento y control del proyecto
38
2.1.3 Proceso de gestin de la calidad del software
El objetivo es la planificacin y administracin de las acciones necesarias
para proveer una confianza adecuada en la calidad de los productos software que
satisfagan los requerimientos tcnicos establecidos. En el proceso de gestin de la
calidad del software se abarcan actividades en todo el ciclo de vida y se
documenta en un plan de garanta de la calidad del software. Para abordar este
proceso de proteccin del software globalmente se consideran los siguientes
aspectos: Las mtricas para el control del proyecto, la verificacin y validacin,
incluyendo pruebas, procesos de revisin, y la gestin de la configuracin del
producto.
Las mtricas del software se definen como la aplicacin continua de
tcnicas basadas en las medidas de los procesos de desarrollo de software y de
sus productos para producir una informacin de gestin significativa y oportuna, a
la vez que se mejoran los procesos y sus productos.
La verificacin y la validacin del software involucran actividades
imprescindibles para el control de la calidad del software. Se entiende por
verificacin al conjunto de actividades para la comprobacin de que un producto
software esta tcnicamente bien construido, es decir, que el producto funciona.
En general, comprobar si los productos construidos en el ciclo de vida
satisfacen los requisitos establecidos en las fases anteriores, decidiendo si el
producto hasta el momento es consistente y completo. De modo complementario
la validacin trata la comprobacin de que el producto software construido es el
que se deseaba construir, es decir que funciona como el usuario quiere y hace las
funciones que fueron concertadas con l. En la siguiente tabla se identifican las
actividades a realizar, la documentacin que se obtine y cuales tcnicas se
aplican.
salida
Tcnicas a aplicar
Planificar la garanta de la
calidad del software
Desarrollar mtricas de
calidad
Gestionar la calidad del
software
Identificar necesidades de
mejora de la calidad
Plan de
garanta de
calidad del
software
Recomendacio
nes de mejora
de calidad del
software
Tcnicas de planificacin
y Estimacin
Mtricas de calidad del
software
Tabla 3: Proceso de gestin de calidad del software
39
2.2 LECCIN 2: PROCESOS DE PRE-DESARROLLO
Son los procesos que se deben realizar antes de que comience el
desarrollo propiamente dicho del software. El desarrollo se inicia con la
identificacin de una necesidad de automatizacin. Esta necesidad para ser
satisfecha necesita de una nueva aplicacin, o cambio de todo o parte de la
aplicacin existente. El proceso de pre-desarrollo abarca desde el reconocimiento
del problema hasta la determinacin de los requisitos funcionales a nivel de
sistema, pasando por el estudio de viabilidad de la solucin software.
2.2.1 Proceso de exploracin de conceptos
Este proceso incluye la identificacin de una necesidad, la formulacin de
soluciones potenciales, el estudio de viabilidad, y refinamiento a nivel de sistema.
Una vez establecidos sus lmites, se genera el informe de la necesidad del sistema
a desarrollar. Este informe inicia el proceso de asignacin del sistema y/o el
proceso de requisitos, y alimentan los procesos de gestin del proyecto. El informe
de la necesidad es un documento que constituye la base de todo el trabajo de
ingeniera posterior. En la siguiente tabla se identifican las actividades a realizar, la
documentacin y cuales tcnicas se aplican.
Actividades a realizar Documentacin de salida Tcnicas a aplicar
Identificar ideas o
necesidades
Formular soluciones
potenciales
Conducir estudios
de viabilidad
Planificar la
transicin del
sistema
Refinar y finalizar la
idea o necesidad
Modelo de la situacin
actual
Modelo del dominio del
problema
Informe preliminar de
necesidades
Soluciones alternativas
posibles
Soluciones
recomendadas
Plan de transicin
Informe del impacto de
la transicin
Tcnicas de
adquisicin de
conocimientos
Anlisis econmico
Anlisis tcnico
Anlisis alternativos
Tcnicas de
modelizacin
(Diagramas DFD)
Prototipado
Tabla 4: Proceso de exploracin de conceptos
2.2.2 Procesos de asignacin del sistema
Este proceso se realiza cuando el sistema requiere tanto del desarrollo de
hardware como el de software, o cuando no se est seguro que solo se necesita
desarrollo de software. En el informe de necesidad se identifica las entradas, el
procesamiento que se aplica a la entrada, las salidas requeridas y las funciones
del sistema total, que permiten desarrollar la arquitectura del sistema e identificar
las funciones del hardware, del software y de las interfaces. Este proceso culmina
40
con la especificacin de requisitos del software, la especificacin de requisitos del
hardware y la especificacin de la interfaz del sistema.
Se comienza estableciendo los requisitos de todos los elementos del
sistema y luego asignando un subconjunto de estos requisitos del software, para
su anlisis y refinamiento en el proceso de requisitos. Este planteamiento del
sistema es esencial cuando el software debe interrelacionarse con otros
elementos, tales como hardware, personas y bases de datos.
El anlisis de sistema requiere una comunicacin intensa entre el cliente y
el analista. El cliente debe comprender los objetivos del sistema y ser capaz de
exponerlos claramente. El analista debe ser qu preguntas hacer, que consejos
dar y qu investigacin realizar, pues si la comunicacin se rompe, el xito del
proyecto entero estar en peligro. En el anlisis del sistema se definen los
objetivos del mismo, la informacin que se va a obtener, la informacin que se va
a suministrar, las funciones, el comportamiento y el rendimiento requerido.
Una vez que la funcin, el rendimiento y las interfaces estn delimitados, se
procede a realizar la tarea denominada asignacin. Durante la asignacin, las
funciones son asignadas a uno o ms elementos genricos del sistema, es decir,
software, hardware, personal, bases de datos, documentacin, procedimientos.
Esencialmente, lo que se hace es asignar a cada elemento del sistema un mbito
de funcionamiento y de rendimiento.
Asignadas las funciones, se puede crear un modelo que represente las
interrelaciones, entre los distintos elementos del sistema y establezca una base
para los posteriores pasos de anlisis de requisitos y de diseo. Se representa el
sistema definido mediante modelos de la arquitectura del sistema (salida, entrada,
proceso y control, interfaz de usuario, mantenimiento y autocomprobacin). En
primer lugar se realiza un diagrama de contexto de la arquitectura, que establece
los lmites de informacin entre los que se esta implementando el sistema y el
entorno en el que va a funcionar. Luego, se refina el diagrama de contexto de la
arquitectura considerando con ms detalle la funcin del sistema. Se identifican
los subsistemas principales que permiten el funcionamiento del sistema
considerado en el contexto definido por el diagrama. Se definen los subsistemas
principales en un diagrama de flujo de arquitectura. El diagrama de flujo de
arquitectura muestra los subsistemas principales y las lneas importantes de flujo
de informacin (control y datos).
El diagrama inicial de flujo de la arquitectura se constituye en el nodo raz
de la jerarqua de diagramas de flujo. Se puede ampliar cada subsistema del
diagarama de flujo inicial en otro diagrama de arquitectura dedicado
exclusivamente a l. Este proceso de descomposicin de arriba hacia abajo
permite disponer de una jerarqua de diagramas de flujo del sistema, donde cada
uno de ellos se puede utilizar como punto de partida para los posteriores pasos de
ingeniera del subsistema que describe. En la siguiente tabla se identifican las
actividades a realizar, la documentacin y cuales tcnicas se aplican.
41
Analizar las
funciones del
sistema
Desarrollar la
arquitectura del
sistema
Descomponer los
requisitos del
sistema
Especificacin de requisitos
del sistema
funcionales del hardware
Especificacin de la interfaz
del sistema
Descripcin funcional del
sistema
Arquitectura del sistema
Tcnicas de
adquisicin de
conocimientos
Tcnicas de
modelizacin
(Diagramas DFD)
Tabla 5: Proceso de asignacin del sistema
2.3 LECCIN 3: PROCESOS DE DESARROLLO
Son los procesos que se deben realizar para la construccin del producto
software. Estos definirn qu informacin obtener y como estructurar los datos,
qu algoritmos usar para procesar los datos y cmo implementarlos, y qu
interfaces desarrollar para operar con el software y cmo hacerlo. A partir del
informe de la necesidad, con el soporte de las actividades de los procesos
integrales y bajo el plan de gestin del proyecto, los procesos de desarrollo
producen el software (cdigo y documentacin).
2.3.1 Procesos de requisitos
Incluye actividades iterativas dirigidas al desarrollo de la especificacin de
requisitos del software. Para la determinacin completa y consistente de todos los
requerimientos del software el anlisis se enfatiza sobre la salida resultante, la
descomposicin de los datos, el procesamiento de los datos, las bases de datos y
las interfaces de usuario, del software y del hardware.
La especificacin de requerimientos del software es el establecimiento
conciso y preciso de un conjunto de requisitos que deben ser satisfechos por un
producto software, indicando el procedimiento mediante el cual se puede
determinar si se satisfacen los requerimientos dados. Describe los requisitos
funcionales, de rendimiento y de interfaz de software y definen los entornos de
operacin y soporte. Este documento es la salida con la cual culmina este
proceso.
Existen tres tipos de requerimientos:
Requerimiento Funcional, que especifica la funcin que un sistema o
componente de un sistema debe ser capaz de realizar.
42
Un requerimiento de rendimiento especifica una caracterstica numrica
tanto esttica (nmero de terminales del sistema, nmero de usuarios simultneos
que soportar el sistema, nmero de archivos o registros del mismo, etc.) como
dinmica (tiempo de procesamiento en el sistema) que debe tener un sistema o
componente de un sistema.
Los requisitos de interfaz, que determinan caractersticas que el software
debe soportar para cada interfaz humano del producto software (interfaz de
usuario), las caractersticas lgicas de cada interfaz entre el producto software y
los componentes de hardware del sistema (interfaz del hardware), el uso de otros
productos software (un sistema de gestin de base de datos, un sistema operativo,
un paquete estadstico) e interfaces con otros sistemas de aplicacin (interfaz de
software).
Existen adems otros atributos del software (seguridad, consistencia,
facilidad de traza, etc.) que pueden dar lugar a requisitos especficos del mismo,
por ejemplo la restriccin a determinados datos. En la siguiente tabla se identifican
las actividades a realizar, la documentacin y cuales tcnicas se aplican.
Actividades a realizar Documentacin de salida Tcnicas a utilizar
Definir y
desarrollar los
requerimientos
del software
Definir los
requerimientos
de interfaz
Priorizar e
integrar los
requerimientos
del software
Especificacin de
requisitos del
software
Especificacin de
requisitos de interfaz
con el usuario
Especificacin de
con otro software
Especificacin de
con hardware
Especificacin de
con el sistema fsico
Tcnicas orientadas a los
procesos: Anlisis
estructurado (Diagramas de
flujo de datos DFD,
Diccionario de datos DD,
Especificacin de procesos
primitivos EPP), SADT,
Diagramas de transicin de
estados, Diagramas de
descomposicin, WRS, RBS,
OBS, Actigramas.
Tcnicas orientadas a datos:
Diagramas entidad-relacin,
datagramas
Tcnicas orientadas a
objetos: Diagramas de
clases y objetos, jerarqua
de clases y objetos
Tcnicas formales de
especificacin: Tcnicas
relacionales (relaciones
recurrentes, expresiones
regulares), Tcnicas
Orientadas al estado (Tablas
de decisin, tablas de
eventos, tablas de transicin,
redes de PETRI), Tcnicas
de prototipos.
Tabla 6: Proceso de requisitos o requerimientos
43
2.3.2 Proceso de diseo
Su objetivo es realizar una representacin coherente y organizada del
sistema software que satisfaga la especificacin de requisitos del software. La
calidad de dicha representacin se puede evaluar. El proceso de diseo traduce el
qu hacer de las especificaciones de los requerimientos en el cmo hacerlo de
las especificaciones de diseo. Inicialmente, la representacin describe una visin
sistmica y holstica del software. Posteriores refinamientos de diseo conducen a
una representacin que se acerca al cdigo fuente.
El diseo de software puede verse desde dos perspectivas: la tcnica y la
de gestin del proyecto. Desde el punto de vista tcnico el diseo comprende
cuatro actividades: diseo de los datos, diseo arquitectnico, diseo
procedimental y diseo de interfaces. Desde el punto de vista de gestin del
proyecto, el diseo va del diseo arquitectnico (diseo preliminar o de alto nivel)
al diseo detallado (diseo de bajo nivel).
Desde el punto de vista de la gestin, el nivel de diseo arquitectnico se
focaliza en las funciones y estructuras de las componentes que conforman el
sistema software. El nivel de diseo detallado se ocupa del refinamiento de la
representacin arquitectnica que lleva a una estructura de datos detallada y a las
representaciones algortmicas que se usan para cada componente modular del
software.
El proceso de diseo de software comienza con la actividad de realizar el
diseo arquitectnico. Esta actividad genera la descripcin del diseo
arquitectnico del software en donde se describe cada una de las componentes
software, se especifican los datos, las relaciones y restricciones, y se definen
todas las interfaces externas (usuario, software y hardware) y los internos (entre
componentes). La ltima actividad del proceso de diseo es realizar el diseo
detallado, donde se genera la descripcin del diseo del software, que especifica
la estructura de los datos, los algoritmos y la informacin de control de cada
componente software, y los detalles de las interfaces (usuario, hardware y
software).
El diseo detallado se deriva del diseo preliminar; en consecuencia, sus
correspondientes actividades se realizan en consecuencia mientras que el resto
de las actividades de este proceso (analizar el flujo de informacin, disear la base
de datos, disear las interfaces, desarrollar los algoritmos) se ejecutan en paralelo.
Una actividad relevante es el diseo de la base de datos que comprende el
diseo conceptual, lgico y fsico, de la base de datos. Los requisitos se modelizan
dentro de un esquema externo que describe las entidades de datos, atributos,
relaciones y restricciones. Los distintos esquemas externos se integran en un
esquema conceptual nico. El esquema conceptual se aplica entonces en un
esquema lgico dependiente de la implementacin. Finalmente, se definen las
estructuras fsicas de datos y los caminos de acceso.
44
Como ya se mencion, desde el punto de vista tcnico y en el contexto de
los diseos preliminar y detallado, se llevan a cabo varias actividades de diseo
diferentes: diseo de datos, diseo arquitectnico, diseo procedimental y diseo
de la interfaz.
El diseo de datos, que transforma el modelo del campo de informacin,
creado durante el anlisis, en las estructuras de datos que se van a requerir para
implementar el software.
El diseo arquitectnico, que define las relaciones entre los principales
elementos estructurales del programa. El objetivo principal de este diseo es
desarrollar una estructura de programa modular y representar las relaciones de
control entre los mdulos. El diseo arquitectnico mezcla la estructura de
programas y la estructura de datos y define las interfaces que facilitan el flujo de
los datos a lo largo del programa.
El diseo procedimental, que transforma los elementos estructurales en una
descripcin procedimental del software; se realiza despus de que se ha
establecido la estructura del programa y de los datos.
El diseo de la interfaz, que establece principalmente la disposicin y los
mecanismos para la interaccin hombre - mquina.
El diseo es el proceso en el que se asienta la calidad del desarrollo de
software ya que produce las representaciones del software de las que puede
evaluarse su calidad. El diseo es la nica forma mediante la cual se puede
traducir con precisin los requerimientos del cliente en un producto o sistema
acabado. El diseo de software sirve como base de todas las posteriores etapas
del desarrollo y del proceso de mantenimiento.
Para evaluar la calidad de una representacin del diseo se deben tener en
cuenta las siguientes consideraciones:
1. Jerarquizacin, es decir, que debe exhibir una organizacin jerrquica
que haga un uso inteligente del control entre los componentes del
software.
2. Modularidad, esto es, que el software debe estar dividido de forma
lgica en elementos que realicen funciones y subfunciones especficas.
3. separabilidad, o contener representaciones distintas y separadas de los
datos y de los procedimientos.
4. Independencia funcional, de modo que lleve a conseguir mdulos que
exhiban caractersticas funcionales independientes.
45
5. Conectividad, que lleva a producir interfaces que reduzcan la
complejidad de las conexiones entre los mdulos y el entorno exterior.
6. Reproductibilidad, es decir, que debe obtenerse mediante un mtodo
que sea reproducible y que est conducido por la informacin obtenida
durante el anlisis de los requerimientos del software.
En la siguiente tabla se identifican las actividades a realizar, la documentacin
y cuales tcnicas se aplican.
Realizar el diseo
arquitectnico
Analizar el flujo de
informacin
Disear la base de
datos
Disear las
interfaces
Seleccionar o
desarrollar
algoritmos
Realizar el diseo
detallado
Descripcin de
diseo del software
Descripcin de la
arquitectura del
software
Descripcin del
flujo de informacin
Descripcin de la
base de datos
Descripcin de las
interfaces
Descripcin de los
algoritmos
Tcnicas orientadas a los
procesos: Diseo
estructurado (Anlisis de
transformacin, Anlisis de
transaccin), Diseo del
dilogo de las interfaces,
Diseo lgico o diseo del
perfil, HIPO.
datos: Modelo lgico de
datos, modelo fsico de
datos, Warnier, Jackson.
objetos: Modelos de
clases/objetos, diagrama
de mdulos.
Tcnicas de diseo a bajo
nivel: Programacin
estructurada (diagramas
arborescentes, diagramas
de chapin), Programacin
orientada a objetos
(diagrama de procesos),
warnier, Jackson, tcnicas
de prototipado, tcnicas de
refinamiento.
Tabla 7: Proceso de diseo
2.2.3 Proceso de Implementacin
Este proceso transforma la representacin del diseo detallado de un
producto software a una realizacin en un lenguaje de programacin apropiado. El
proceso de implementacin produce el cdigo fuente, el cdigo de la base de
datos y la documentacin, que constituyen la manifestacin fsica del diseo de
acuerdo a los estndares y metodologas del proyecto. Adems, en este proceso
se debe integrar el cdigo y la base de datos. En el caso de que el sistema conste
de componentes hardware y software, se debe planificar y realizar la integracin
del sistema.
46
La salida de este proceso esta sujeta a las pruebas de verificacin y
validacin adecuadas. El cdigo y la base de datos junto con la documentacin
producida durante los procesos previos son la primera representacin completa
del producto software. En la siguiente tabla se identifican las actividades a realizar,
la documentacin y cuales tcnicas se aplican.
Crear los datos de
prueba
Crear el cdigo fuente
Generar el cdigo objeto
Crear la documentacin
de operacin
Planificar la integracin
Realizar la integracin
Datos para las pruebas
Documentacin del
sistema
Documentacin de
usuario
Plan de integracin
Sistema software
integrado
Warnier
Jackson
Lenguajes de
programacin.
Tabla 8: Proceso de Implementacin
2.4 LECCIN 4: PROCESOS DE POST-DESARROLLO
Son los procesos que se deben realizar para instalar, operar, soportar,
mantener y retirar un producto software. Una vez terminada la prueba del
software, ste est casi preparado para ser entregado a los usuarios finales. Sin
embargo, antes de la entrega se llevan a cabo una serie de actividades de
garanta de calidad para asegurar que se hayan generado y catalogado los
registros, y documentos internos adecuados, que se ha desarrollado una
documentacin de alta calidad para el usuario, y que se han establecido los
mecanismos apropiados de control de configuraciones.
Tan pronto como se entregue el software a los usuarios finales, el trabajo
del ingeniero del software cambia, en este momento el enfoque pasa de la
construccin al mantenimiento; correccin de errores, adaptacin al entorno y
mejora de la funcionalidad. En todos los casos, la modificacin del software no
solo afecta al cdigo, sino tambin a la configuracin entera, es decir, a todos los
documentos, datos y programas desarrollados en la fase de planificacin y
desarrollo.
2.4.1 Proceso de instalacin
Implica el transporte y la instalacin de un sistema software desde el
entorno de desarrollo al entorno de destino. Incluye la carga de la base de datos,
las modificaciones necesarias del software, las comprobaciones en el entorno de
destino y la aceptacin del cliente. Si durante la instalacin surge un problema se
identifica e informa acerca de l.
47
El proceso de instalacin verifica que se implemente la configuracin
adecuada del software y termina con la aceptacin formal del mismo por parte del
cliente conforme a lo especificado en el plan de gestin del proceso software y la
realizacin con xito de la prueba de aceptacin del usuario. En la siguiente tabla
se identifican las actividades a realizar y la documentacin.
Actividades a realizar Documentacin de salida
Planificar la instalacin
Distribuir el software
Instalar el software
Cargar la base de datos
Aceptar el software en el entorno de operacin
Plan de instalacin de software
Informe de instalacin
Tabla 9: Proceso de instalacin
2.4.2 Proceso de operacin y soporte
Involucra la operacin del sistema por parte del usuario y el soporte
continuo al usuario que incluye asistencia tcnica, consultas con el usuario y
registro de las peticiones de soporte en el histrico de peticiones de soporte. As,
este proceso puede desencadenar la actividad del proceso de mantenimiento que
provee informacin de realimentacin al ciclo de vida del software. En la siguiente
tabla se identifican las actividades a realizar, y la documentacin.
Operar el sistema
Proveer de asistencia tcnica y
consultas
Mantener el histrico de las peticiones
de soporte
Histrico de las peticiones de soporte
Tabla 10: Proceso de operacin y soporte
2.4.3 Proceso de mantenimiento
Se interesa por los errores, defectos, fallas, mejoras y cambios del software.
Un requisito de mantenimiento del software inicia los cambios del ciclo de vida del
software; ste se reasigna y se ejecuta.
El mantenimiento se centra en el cambio que va asociado a la correccin de
errores, a las adaptaciones requeridas por la evolucin del entorno del software y
a las modificaciones debidas a los cambios de los requisitos del cliente dirigidos a
reforzar o ampliar el sistema. El proceso de mantenimiento vuelve a aplicar los
pasos del ciclo de vida, pero en el contexto del software ya existente.
Durante el mantenimiento se encuentran tres tipos de cambios:
48
Correccin: Incluso llevando a cabo las mejores actividades de garanta de
calidad, es muy probable que el cliente descubra defectos en el software. El
mantenimiento correctivo cambia el software para corregir los defectos.
Adaptacin: con el paso del tiempo es probable que cambie el entorno
original para el que se desarroll el software. El mantenimiento adaptativo consiste
en modificar el software para acomodarlo a los cambios de su entorno externo.
Mejora: conforme utilice el software, el cliente o usuario puede descubrir
funciones adicionales que podra interesar que estuvieran incorporadas al
software. El mantenimiento perfectivo ampla el software ms all de sus
requisitos funcionales originales.
La salida de este proceso son las recomendaciones del mantenimiento que
entran al ciclo de vida del software en el proceso de exploracin de conceptos
para mejorar la calidad del sistema software. En la siguiente tabla se identifican las
actividades a realizar, y la documentacin.
Operar el sistema
Proveer de asistencia tcnica y
consultas
Mantener el histrico de las peticiones
de soporte
Histrico de las peticiones de soporte
Tabla 11: Proceso de Mantenimiento
2.4.4 Proceso de Retiro
Se puede decir que es la jubilacin de un sistema existente de su soporte
activo o de su uso mediante el cese de su operacin o soporte, o su reemplazo
por un nuevo sistema o por su actualizacin. Si el sistema en uso se reemplaza
por un nuevo sistema se requiere un tiempo de operacin en paralelo. En este
periodo se utiliza el sistema en retiro para los resultados oficiales, mientras se
prepara el nuevo sistema para su operacin formal. Es un perodo de formacin
para el usuario sobre el nuevo sistema y de validacin del mismo. En la siguiente
tabla se identifican las actividades a realizar, y la documentacin.
Notificar al usuario
Conducir las operaciones en paralelo
Retirar el sistema
Plan de retiro
Tabla 12: Proceso de retiro
49
2.5 LECCIN 5: PROCESOS INTEGRALES DEL PROYECTO
Son procesos simultneos y complementarios a los procesos orientados
hacia el desarrollo. Incluyen actividades imprescindibles para que el sistema
construido sea fiable (procesos de verificacin y validacin, gestin de la
configuracin) y sea utilizado al mximo de sus capacidades (procesos de
formacin, documentacin). Los procesos integrales comprenden dos tipos de
actividades: Aquellas que se realizan discretamente y se aplican dentro de un
ciclo de vida del software y las que se realizan para completar otra actividad, estas
solo se invocan y no se aplican dentro del ciclo de vida para cada instancia.
2.5.1 Proceso de verificacin y validacin
Abarca la planificacin y la realizacin de todas las tareas de verificacin,
incluyendo pruebas de verificacin, revisiones y auditorias, y de todas las tareas
de validacin, incluyendo pruebas de validacin, que se ejecutan durante el ciclo
de vida del software para asegurar que se satisfacen todos los requisitos del
software.
Una actividad til para la verificacin y la validacin del software es la
prueba del software. Constituye el proceso de ejecucin del software con
determinados datos de entrada, para observar los resultados que produce y
compararlos con los resultados tericos que debera producir, para esos datos de
entrada, con el objeto de detectar posibles fallas. Las pruebas del software solo
podrn realizarse cuando en el proceso de desarrollo ya exista cdigo ejecutable.
La depuracin es un proceso frecuentemente asociado a las pruebas que
consiste en tratar de deducir donde estn los defectos en el software que
provocan que ste no funcione adecuadamente. Estudia los resultados de las
pruebas y otras actividades de control para intentar buscar qu est mal en el
software. En la siguiente tabla se identifican las actividades a realizar, la
documentacin y cuales tcnicas se aplican.
Planificar la
verificacin y
validacin
Ejecutar las tareas
de verificacin y
validacin
Recoger y analizar
los datos de las
mtricas
Planificar las
pruebas
Desarrollar las
especificaciones de
las pruebas
Ejecutar las pruebas
Plan de verificacin
y validacin
Informes de
evaluacin
Plan de pruebas
Especificacin de
las pruebas
Informe resumen
de las pruebas
Software aprobado
Tcnicas de prueba de
caja blanca (cobertura de
sentencias, cobertura de
decisin y de ramificacin,
cobertura de condicin,
cobertura de
decisin/condicin,
cobertura de condicin
mltiple)
Tcnicas de prueba de
caja negra (Particin de
equivalencias, anlisis de
valores lmites, grficos de
causa/efecto, conjetura de
error)
50
Revisiones formales
Auditorias
Tabla 13: Proceso de verificacin y validacin
2.5.2 Proceso de gestin de la configuracin
Este proceso involucra un conjunto de actividades desarrolladas para
gestionar los cambios durante todo el ciclo de vida del software. Identifica la
estructura de un sistema (qu rutinas, mdulos, datos, archivos lo componen) en
un momento dado a lo que se le denomina configuracin del sistema. Su objetivo
es el control de los cambios en el sistema, mantener su coherencia y su
rastreabilidad o trazabilidad, y poder realizar auditorias de control sobre la
evolucin de las configuraciones.
La gestin de la configuracin realiza las siguientes funciones: Identificacin
de la configuracin de un sistema o descripcin documentada de las
caractersticas reales del sistema en un determinado momento; control de la
configuracin, establece la configuracin inicial o bsica y controla los cambios en
los elementos de la misma; informes del estado de la configuracin; auditorias de
la configuracin, revisiones independientes de la configuracin para comprobar
que los elementos de la configuracin cumplen los requisitos de configuracin
establecidos. En la siguiente tabla se identifican las actividades a realizar, y la
documentacin.
Planificar la gestin de la configuracin
Realizar la identificacin de la
configuracin
Realizar el control de configuracin
Realizar la informacin del estado de
la configuracin
Plan de gestin de configuracin del
software
Orden de cambio de ingeniera
Cambio de estado
Informe de estado
Tabla 14: Proceso de gestin de la configuracin
2.5.3 Proceso de desarrollo de documentacin
El proceso de desarrollo de documentacin para el desarrollo y uso del
software es el conjunto de actividades que planifican, disean, implementan,
editan, producen, distribuyen y mantienen los documentos necesarios para los
desarrolladores y los usuarios. En la siguiente tabla se identifican las actividades a
realizar, y la documentacin.
51
Planificar la documentacin
Implementar la documentacin
Producir y distribuir la documentacin
Plan de documentacin
Tabla 15: Proceso de desarrollo de documentacin
2.5.4 Proceso de formacin
Incluye la planificacin, desarrollo, validacin e implementacin de los
programas de formacin de desarrolladores, personal de soporte tcnico y clientes
o usuarios y la elaboracin de los materiales de formacin adecuados. Para
conseguir una utilizacin efectiva del sistema software, se debe proporcionar a los
usuarios del sistema instrucciones, gua y ayuda para el entendimiento de las
capacidades del sistema y de sus limitaciones. Por ello es imprescindible la
formacin de los usuarios en el nuevo sistema.
El desarrollo de productos software de calidad depende en gran medida de
los conocimientos de las personas y del personal especializado involucrados en el
proyecto. Por ello, es esencial la formacin de los desarrolladores y personal de
soporte tcnico. En la siguiente tabla se identifican las actividades a realizar, y la
documentacin.
Planificar el programa de formacin
Desarrollar los materiales de formacin
Validar el programa de formacin
Implementar el programa de formacin
Plan de formacin
Tabla 16: Proceso de desarrollo de formacin
52
CAPITULO 3
CONCEPTOS DE CALIDAD Y
CALIDAD DEL SOFTWARE
53
INTRODUCCIN
El avance informtico actual es muy alto comparado con lo se tena en los
aos 90, al hablar de desarrollo de software se hace ms notable, en el hecho por
ejemplo de pasar de una programacin de cdigo lnea a lnea, a un mtodo de
programacin grfico orientado a objetos donde el desarrollo es mas rpido y
atractivo para el cliente.
Ms sin embargo con estas ventajas que se tiene con las nuevas
herramientas de desarrollo de software se olvida la calidad del producto que es
entregado, no es solamente una calidad grfica, o la calidad de velocidad en la
respuesta, hay que tener en cuenta otras cualidades, para buscar una integralidad
al afirmar que el software es de calidad.
Los desarrolladores del software, opinan que el sus productos son los
mejores del mercado, pero no se han preguntado que opina el cliente. El tener un
documento que explique los requerimientos para evaluar el software ayuda al
desarrollo, compra o auditora de cualquier aplicacin informtica del mercado,
teniendo en cuenta que hoy en da es muy importante para las empresas privadas
o pblicas la inversin en este tipo de producto, los cuales verifican la calidad a la
hora de entrar a produccin, donde se detectan las falencias, reportando all
prdidas.
Este captulo presenta indicadores de calidad de un software; al momento
de la entrega, basados en los estndares de calidad sugeridos la norma ISO/IEC
9126; de la ISO (Organizacin Internacional de Normalizacin) y la IEC (Comisin
Electrotcnica Internacional).
54
3.1 LECCIN 1: DEFINICIN DE CALIDAD
Inicialmente la calidad hace referencia al proceso industrial donde W. E.
Deming propuso la idea de calidad como conformidad a requisitos y confiabilidad
en el funcionamiento. Posteriormente surgen otras definiciones de calidad como la
de J. Juran que propone una definicin breve: Quality is fitness for use; es decir,
la calidad es la adecuacin del producto al uso donde esta definicin incluye las
caractersticas del producto que permiten obtener la satisfaccin del usuario y,
adems, supone la ausencia de deficiencias. Para P. Crossby el concepto de
Juran se asume pero tambin destaca la prevencin: Cero defectos o Hacerlo
bien a la primera. En la bibliografa son frecuentes las definiciones de calidad
pero en su gran mayora todas ellas se acercan al concepto expresado por Juran.
La definicin oficial, y ms completa, es la de la norma ISO 9000:2000 que
define la calidad en general como: Grado en el que un conjunto de caractersticas
inherentes cumple con los requisitos, donde los requisitos son las necesidades o
expectativas establecidas, generalmente implcitas u obligatorias y las
caractersticas se refieren a cualquier tipo de rasgo diferenciador. Tambin se
debe recordar que las necesidades pueden variar en el tiempo, por lo que hay que
prever la revisin de la especificacin.
Esta definicin permite comprender que la consecucin de la calidad puede
tener tres orgenes:
3.1.1 La calidad realizada: Que es la calidad obtenida por la persona que realiza
el trabajo gracias a su habilidad en la ejecucin de una tarea. Se potencia con la
mejora de las habilidades personales y tcnicas de los participantes en un proceso
determinado.
3.1.2 La calidad programada: Que es la calidad que se ha encomendado
conseguir a la persona reponsabIe de ejecutar el trabajo. Se potencia con la
elaboracin de una especificacin que sirva de buena referencia a los
participantes en un proceso. Esta aperece descrita en una especificacin, en un
documento de diseo o en un plano constructivo.
3.1.3 La calidad necesaria: La que el cliente exige con mayor o menor grado de
concrecin o, al menos, la que le gustara recibir. Se potencia con una adecuada
obtencin de informacin de la idea de calidad de los clientes y de su percepcin
de la misma.
La gestin de la calidad pretender entonces, conseguir que estos tres crculos
coincidan entre s.
55
3.2 LECCIN 2: SISTEMAS DE CALIDAD EN LA EMPRESA
La poltica de la calidad forma parte de la poltica general de la empresa,
por eso es importante que la direccin o gerencia exprese dicha poltica de
manera explcita al igual que lo hace para la poltica financiera, de personal, etc.
Por lo tanto, la gestin de la calidad forma parte de las tareas de la direccin, y
para tener xito, se debe contar con el compromiso y la participacin de todos.
Incluye la planificacin estratgica, la asignacin de recursos, las actividades
sistemticas, y evaluaciones entre otras. Actualmente, de forma general, se suele
apoyar en la creacin de lo que se denomina sistema de calidad para la
organizacin.
Un sistema de gestin de calidad es un un sistema para establecer polticas
y los objetivos con respecto a la calidad y para lograr dichos objetivos se debe
aplicar a la direccin y control de una organizacin. Este sistema de calidad se
adeca a los objetivos fijados por la empresa en cuanto al tema. La direccin es la
responsable de fijar las polticas de calidad y las decisiones relativas a iniciar,
desarrollar, implantar y actualizar el sistema de calidad.
Uno de los factores fundamentales del trabajo en este nivel consiste en fijar
la estructura organizativa con lneas de jerarqua y de comunicacin ligada al
sistema de gestin de calidad. Para ser til el sistema de calidad debe cumplir con
las siguientes caractersticas: Ser eficaz y comprendido por todos, dar confianza
en satisfacer las necesidades de los clientes y poner mayor nfasis en prevenir
que en detectar y corregir.
Un sistema de calidad consta de dos partes, una escrita y otra prctica. La
parte escrita est en una serie de documentos en los cuales se describe el
sistema, los procedimientos, entre otros, ajustndose a una norma habitualmente
se usa la noma ISO 9001. Y la parte prctica que tiene dos vertientes principales,
una que tiene en cuenta los aspectos fsicos (locales, herramientas,
computadores) y otra que toma los aspectos humanos como la formacin del
personal (tanto en tcnicas de calidad corno en tcnicas de reuniones,
comunicacin) y en creacin y coordinacin de equipos de trabajo.
El manual de calidad es el documento principal para establecer e implantar
un sistema de calidad, en el se documentan todos los elementos, los requisitos y
los medios que adopte la empresa para su sistema de calidad se deben establecer
por escrito, ordenadamente, en forma de polticas y procedimientos. El manual de
calidad debe describir adecuadamente el sistema de gestin de la calidad para
servir como referencia permanente al implantar o al aplicar el sistema.
El manual de calidad incluye las polticas de calidad que se han adoptado,
la definicin del sistema de calidad, la presentacin de la estructura de la
organizacin y la referencia a los procedimientos aplicables. Segn la norma ISO
9OO4 y la norma UNE 66-907-91, se puede sugerir la siguiente estructura de un
manual de calidad:
56
3.2.1 Captulos de introduccin
ndice
Declaracin de la direccin de la empresa
Poltica de calidad y objetivos generales de la empresa respecto a la calidad
Objeto y campo de aplicacin del manual de calidad
Terminologa
Gestin del manual de calidad (procedimiento para cambios, aprobacin, etc.)
Presentacin de la empresa
3.2.2 Disposiciones para conseguir la calidad
En general en el orden del ciclo de vida. El manual de calidad se establece
principalmente para uso interno de la empresa aunque puede facilitar las
relaciones cliente-proveedor, adems es un elemento clave en el proceso de
certificacin del sistema de calidad de la empresa.
El manual de calidad se completa con procedimientos o instrucciones
especficas para ciertas actividades o procesos que deben mencionarse
explcitamente en dicho manual. Para cada empresa suelen existir procedimientos
particulares, cuyo fundamento debe ser la buena prctica y la experiencia en el
trabajo diario y los cdigos, las normas y las especificaciones a los que deben
ajustarse.
Para las organizaciones de desarrollo de software, se suelen incluir los
procedimientos (tcnicas y metodologas) para realizar y documentar el anlisis de
los sistemas, para realizar y documentar el diseo de los sistemas o de sus bases
de datos, entre otros. En general, indicarn la metodologa a aplicar, algunos
ejemplos tpicos de procedimientos relacionados con el desarrollo pueden ser el
procedimiento de especificacin de requisitos del software, el procedimiento para
las pruebas del software, el procedimiento de estilo de codificacin, etc.
Otros documentos importantes en el sistema de calidad son los que aportan
evidencias sobre la aplicacin de calidad, sobre todo el proceso de desarrollo, en
ellos se evidencia, los registros de datos sobre calidad, almacenamientos de datos
sobre las actividades relacionadas con la calidad o sobre la evaluacin de los
productos. Normalmente suelen incluir datos de pruebas, datos sobre las
revisiones e inspecciones, datos de costes de actividades. Estos se deben
conservar incluso despus de acabar el proyecto para analizar las tendencias de
la calidad obtenida y corregir las causas de defectos.
Algunas de las caractersticas que debera tener la documentacin en
cualquier caso son las siguientes: Tener como objetivo facilitar los medios para el
buen funcionamiento del sistema de calidad, Tambin debe servir para dejar
constancia del nivel de calidad alcanzado, ser legible, estar fechada, limpia,
identificable y archivada, e incluir todo tipo de documentos como especificaciones,
y procedimientos.
57
3.3 LECCIN 3: NORMATIVIDAD DE CALIDAD
La normativa de calidad surge inicialmente en empresas de algunos de los
sectores de seguridad crtica como el militar, nuclear, y aeroespacial. La normativa
nuclear ha inspirado muchas otras normas, sin embargo, La revolucin normativa
para todos los sectores se produjo con la llegada de la serie de normas ISO 9000,
inicialmente con la norma de gestin y aseguramiento de la calidad ISO 9000, y
posteriormente tres normas con recomendaciones para el aseguramiento externo
de la calidad, la ISO 9001, 9002 y 9003 dependiendo de qu parte del ciclo de la
calidad fuera el centro de actividad de la empresa y una norma ISO 9004 con
recomendaciones para la gestin interna de la calidad.
Sin embargo, la reciente revisin de la serie 9000 realizada en el ao 2000,
cambi la filosofa y la estructura de las normas 9000, ahora existe una nica
norma ISO 9001:2000 que abarca todos los aspectos necesarios de todas las
actividades del ciclo de vida. Las organizaciones que antes empleaban las normas
ISO 9002 y 9003, aplicarn la ISO 9001:2000 limitando su mbito de aplicacin. El
cambio de filosofa experimentado se basa en incrementar la importancia de la
mejora continua y el ciclo PDCA (Plan-Do-Check-Act), as como una mayor
definicin de los procesos y de la evaluacin de la satisfaccin de clientes y
usuarios. La importancia de estas normas reside en que se emplean como base
para que las empresas se certifiquen en procesos y que transmita a sus clientes la
confianza en que trabaja con procedimientos que permiten asegurar la calidad en
sus actividades.
Figura 7: Modelo de Gestin de calidad ISO 9001: 2000
58
En el caso del software que es un producto muy especial, fue necesario
hacer una interpretacin de la versin ISO 9001:1994 generando la gua ISO
9000-3:1997 que es la Gua para aplicar ISO 9001 al desarrollo, suministro y
mantenimiento de software. Con la llegada de la norma ISO 9001:2000, la gua
ISO 9000-3 es aplicable y til aunque requiere una actualizacin.
La gua contempla tres aspectos principales de disposiciones adaptadas a
la terminologa y caractersticas especiales del software como producto, el primero
es el marco de trabajo de la empresa (sistema de calidad, responsabilidad de la
direccin y la realizacin de acciones correctivas), el segundo que muestra las
actividades del ciclo de vida (Revisin de contrato, especificacin, planificacin,
planificacin de la calidad, diseo, implementacin, revisiones, pruebas,
aceptacin, replicacin, entrega, instalacin y mantenimiento), y el tercero donde
estn las actividades de apoyo (Gestin de configuracin, control de documentos,
mtricas, convenciones y reglas, herramientas, formacin, registros de calidad y
compras).
Desde el punto de vista prctico, la ISO 9001:2000 incluye las siguientes
disposiciones:
3.3.1 Responsabilidad de la direccin
Desde un mbito general muestra el compromiso con la satisfaccin del
cliente, promoviendo una determinacin eficaz de requisitos y de las necesidades
del cliente, establece una poltica de calidad que debe llevar a una planificacin de
la calidad y de sus objetivos, a travs de un sistema de gestin de calidad en el
que deben existir revisiones formales de la gestin realizada.
3.3.2 Gestin de recursos
Para determinar y proporcionar lo necesario para la gestin de calidad,
especialmente en el mbito de los recursos humanos donde debe realizarse la
adecuada poltica de asignacin a tareas, determinar, realizar y evaluar el impacto
de las acciones de formacin y cualificacin, y de competencias profesionales. No
se deben olvidar otros recursos como la informacin, las infraestructuras
necesarias y el entorno de trabajo.
3.3.3 Gestin de los procesos
Con disposiciones para las actividades de gestin, los procesos
relacionados con el cliente, el diseo y el desarrollo de productos y servicios, la
gestin de compras y proveedores, la produccin y la operacin de servicios, el
control de las no-conformidades de las entregas respecto de los requisitos
establecidos y los servicios post-entrega.
59
3.3.4 Medicin, anlisis y mejora
Contempla la medicin del rendimiento del sistema, medicin de procesos,
medicin de productos y/o servicios y el control de la propia medicin y de los
medios de inspeccin y prueba. En cuanto a anlisis de datos, se trata de obtener
las conclusiones apropiadas para emprender acciones de mejora relacionadas con
correcin de errores, prevencin de problemas para el futuro y el establecimiento
de procesos de mejora continua.
3.4 LECCIN 4: INGENIERA DE SOFTWARE Y CALIDAD
Para hablar de la calidad en el software, se debe tener en cuenta que este
es un producto con caractersticas particulares, por lo cual se hace necesario
adaptar la terminologa creada y aplicada en los sectores industriales. Algunas de
estas caractersticas del software son las siguientes:
El software se desarrolla, no se fabrica ya que todo el costo de produccin
se centra en el diseo de la primera copia. El software es un producto lgico, el
verdadero producto del software es el diseo de una serie de instrucciones para el
computador, su existencia en papel o en soporte magntico no es ms que una
representacin en un cdigo o lenguaje de las instrucciones.
El software no se degrada con el uso, ya que la naturaleza lgica del
software permite que permanezca inalterable por muy intensa que sea su
utilizacin. Se puede degradar su representacin magntica pero no su esencia.
La complejidad del software, la ausencia de controles adecuados hace que
el software sea entregado muchas veces y conscientemente con defectos, incluso
pblicamente declarados. En el sector informtico, incluso, se llega a cobrar una
cuota de mantenimiento para reparar los defectos que el propio productor del
software ha entregado con el mismo.
Un porcentaje muy grande de la produccin de software se hace an a
medida. En vez de emplear componentes existentes y ensamblarlos, aunque las
bibliotecas de funciones o componentes estn ya cambiando en parte esta
situacin.
El software es extraordinariamente flexible, ya que se puede cambiar con
facilidad reutilizando trozos de un producto para construir otro. Sin embargo, la
facilidad para cambiarlo es tambin un peligro que hay que controlar.
El diccionario estndar de ingeniera del software IEEE Std.6l0, indica que
software son los programas de ordenador, los procedimientos y, posiblemente, la
documentacin asociada y los datos relativos a la operacin del sistema
informtico. No se limita al cdigo solamente y se debe tener en cuenta el
software en cualquier estado de evolucin (diseos, especificaciones, datos de
prueba, etc), si se quiere obtener calidad en el software. Tambin conviene
60
recordar que la calidad del software se debe obtener a medida que se construye;
no es un aadido que se pueda poner una vez desarrollado el software.
3.5 LECCIN 5: GESTIN DE LA CALIDAD DEL SOFTWARE
La definicin del estndar IEEE Std.610-1991, indica que calidad del
software es el grado con el que un sistema, componente o proceso cumple con los
requisitos especificados y las necesaidades expectativas del cliente o usuario.
Esta definicin es la que ms se ajusta al concepto de concordancia del software
producido con los requisitos explcitamente establecidos, con los estndares de
desarrollo expresamente fijados y con los requisitos implcitos, no establecidos
formalmente, que desea el usuario.
Los requisitos se reflejan en la especificacin de requisitos de manera
explcita, el documento constituye la culminacin de la etapa de anlisis dentro del
proceso de desarrollo. Los requisitos pueden ser funcionales, cuando se
determinan las funciones que debe realizar el software y no funcionales como el
rendimiento, la seguridad, el tiempo de respuesta, la interfaz, etc. De igual forma,
los estndares y las normas, determinan cmo se debe realizar el proceso de
desarrollo de software. Adems, existen requisitos implcitos, no expresamente
declarados, pero que el usuario del software desea obtener.
Para hacer el estudio de la calidad del software se debe conocer primero
los principales trminos empleados en esta rea, algunos de ellos son:
3.5.1 Gestin de la calidad del software (Software Quality Management)
Son las actividades coordinadas para dirigir y controlar una organizacin en
lo relativo a la calidad. Esto se puede entender como el aspecto de la funcin
general de la gestin que detemina y aplica la poltica de calidad (objetivos y
directrices generales de calidad de una empresa). Normalmente la gestin de
calidad se aplica a nivel de empresa, por lo que incluye planificacin estratgica,
asignacin de recursos, etc.
3.5.2 Aseguramiento de la calidad del software (Software Quality
Assurance)
Es la parte de la gestin de la calidad orientada a proporcionar confianza en
que se cumplirn los requisitos de la calidad. A nivel del software, podra
presentarse como el conjunto de actividades planificadas y sistemticas
necesarias para aportar la confianza en que el producto satisfar los requisitos
dados de calidad. Tambin puede referirse, en el software al conjunto de
actividades para evaluar el proceso mediante el cual se desarrolla el producto. El
aseguramiento pretende dar confianza en que el producto tiene calidad.
61
3.5.3 Control de la calidad del software (Software Quality Control)
Es la parte de la gestin de la calidad orientada al cumplimiento de los
requisitos de la calidad. Suele incluir las tcnicas y actividades de carcter
operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas
en dos objetivos fundamentales, el de mantener bajo control un proceso y eliminar
las causas de defectos en las diferentes fases del ciclo de vida. En general, son
las actividades para evaluar la calidad de los productos desarrollados. Tambin,
en el software, puede ser el proceso de verificar el propio trabajo o el de un
compaero.
3.5.4 Verificacin y validacin del software (Software Verication and
Validation)
Que es una actividad ligada al control de la calidad en el mbito del
software. La verificacin hace refrencia a comprobar si los productos construidos
en una fase del ciclo de vida satisfacen los requisitos establecidos en la fase
anterior. Se suele decidir si el producto esta completo y es consistente. Aqu se
realizan las actividades para comprobar si un producto software esta tcnicamente
bien construido y si funciona. Y la validacin que se refiere a comprobar si el
software construido satisface los requisitos del usuario. Por lo tanto, son las
actividades de comprobacin de que el producto software construido es el que se
deseaba construir, es decir, si el producto funciona como el usuario quiere y
realiza las funciones que se haban solicitado.
62
GLOSARIO DE TRMINOS
Automatizacin: Es el uso de sistemas o elementos computarizados y
electromecnicos para controlar maquinarias y/o procesos industriales
sustituyendo a operadores humanos.
Ciclo de Vida: El ciclo de vida de software es la descripcin de las distintas
formas de desarrollo de un proyecto informtico.
Ciclo de Vida gil: Es un marco de trabajo conceptual de la ingeniera de
software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de
vida del proyecto. Existen muchos mtodos de desarrollo gil; la mayora minimiza
riesgos desarrollando software en cortos lapsos de tiempo. El software
desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar
de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin,
anlisis de requerimientos, diseo, codificacin, revisin y documentacin.
Componente Software: Son todos aquellos recursos desarrollados para un fin
concreto y que puede formar solo o junto con otros, un entorno funcional requerido
por cualquier proceso predefinido.
Estndar: Base o modelo en el que todo el mundo se ha puesto de acuerdo.
IEEE: Corresponde a las siglas de (Institute of Electrical and Electronics
Engineers) en espaol Instituto de Ingenieros Elctricos y Electrnicos, una
asociacin tcnico-profesional mundial dedicada a la estandarizacin, entre otras
cosas.
ISO: (Internacional Standards Organization) Organizacin Internacional de
estndares fundada en 1946, con sede principal en Ginebra, ISO establece o fija
estndares internacionales. Se ocupa de todos los campos, excepto la electricidad
y la electrnica, que se rigen por la Internacional Electrotechnical Comisin (IEC),
tambin en Ginebra.
Modelo: Un modelo es una estructura conceptual que sugiere un marco de ideas
para un conjunto de descripciones que de otra manera no podran ser
sistematizadas.
Proceso: El proceso de ingeniera de software se define como un conjunto de
etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso,
la obtencin de un producto de software de calidad.
Requerimientos: Caractersticas que se desea que posea un sistema o un
software.
63
Calidad: La calidad es herramienta bsica para una propiedad inherente de
cualquier cosa que permite que esta sea comparada con cualquier otra de su
misma especie.
Calidad de Software: Caractersticas propias del software que se desea controlar
y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se
degradan fsicamente, sino que se desarrolla; El software puede tener errores,
incidencias pero no son similares a lo que cualquier equipo de carcter fsico.
ISO 9001: Es un conjunto de normas sobre la calidad y la gestin.
Gestin de Calidad de Software: Es un conjunto de actividades de la funcin
general de la Direccin que determina la calidad, los objetivos y las
responsabilidades. Se basa en la determinacin y aplicacin de las polticas de
calidad de la empresa.
64
FUENTES DOCUMENTALES
Bibliografa de referencia:
Beck, K.. .Extreme Programming Explained. Embrace Change., Pearson
Education, 1999. Traducido al espaol como: .Una explicacin de la programacin
extrema. Aceptar el cambio., Addison Wesley, 2000.
CETTICO, Centro Transferencia tecnolgica en Informtica y Comuicaciones.,
Enciclopedia de Informtica y Computacin, Ingeniera de software e Inteligencia
artificial. Universidad Politcnica de Madrid 1999.
De Domingo, J. y Arranz, A., Calidad y mejora continua, Ed Donostiarra. 1997.
Piatini, Mario y col. Analisis y Diseo de Aplicaciones Informticas de Gestin, Una
Perspectiva de Ingeniera de Software, Alfaomega 2004. Pginas 109 164.
BRAUDE. Ingeniera de software, una perspectiva orientada a objetos. Mxico.
2003. Alfaomega grupo editor. S.A.
HUMPHREY, Watts S. Introduccin al proceso de software personal. Pearson
Addison wesley. 2001.
NORRIS. Ingeniera de software explicada. Grupo Noriega editores de Colombia.
PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos,
tcnicas y mtodos para la gestin del cambio. Editorial Alfaomega-Rama.
PRESSMAN, Roger S. Ingeniera del Software. Un enfoque prctico. Quinta
edicin. Espaa. 2002. Editorial McGraw Hill.
SOMMERVILLE, Ian. Ingeniera de software. 6. Edicin. Pearson Addison
Wesley. 2001
Direcciones Electronicas (webgrafa)
http://www.pressman5.com
http://www.wiley.com/college/braude
http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/PDF/SEGlossary.pdf
http://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppt
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html
http://www.sistemas.unam.mx/software.html
65
UNIDAD 2
Nombre de la Unidad ESTNDARES, MTRICAS DE CALIDAD Y PRUEBAS
DEL SOFTWARE
Introduccin En este captulo se trata los temas que son el fundamento
de la calidad del software y su evaluacin, entre ellas
estn los modelos y estndares actuales de calidad, que
detallan las caractersticas mediante las cuales se hace la
evaluacin, las mtricas de calidad y las mtricas tcnicas
de calidad del software que son los indicadores, las
escalas de medicin cualitativa o cuantitaiva y las pruebas
del software que se ejecutan para verificacin de la
calidad del producto o proceso.
Justificacin Esta unidad es quiza una de las ms importantes para la
evaluacin del software, ya que se identifica en ella los
tipos de evaluacin esttica y dinmica mediante el uso
de las mtricas y las pruebas del software. Los estndares
son los que permiten referencias cuales caractersticas se
evaluar y que mtricas y pruebas se asocian a ellas.
Intencionalidades
Formativas
- El estudiante conoce los estndares y modelos utilizados
para la evaluacin de la calidad del software
- El estudiante reconoce las caractersticas internas,
externas y de usabilidad dentro de los estndares
- El estudiante asocia cada una de las caractersticas con
las mtricas y las pruebas a realizar en cada caso
- El estudiante define de acuerdo a las especificaciones
del cliente, las caractersticas, subcaractersticas, mtricas
y pruebas a utilizar
Denominacin de
captulos
CAPITULO 4: ESTANDARES Y MODELOS DE
Denominacin de
lecciones
Leccin 1. La Calidad del Software
Denominacin de
lecciones
Leccin 2. Calidad del Producto Software Norma
ISO/IEC 9126
Denominacin de
lecciones
Leccin 3. Calidad del Producto software Norma
ISO/IEC 14598
Denominacin de
lecciones
Leccin 4. Calidad del Producto Software Norma
ISO/IEC 25000 (SquaRE)
Denominacin de
lecciones
Leccin 5. Modelos de Mejora de Procesos de Software.
Denominacin de
captulos
CAPITULO 5: MTRICAS DE CALIDAD DEL
SOFTWARE
Denominacin de Leccin 1. Conceptos Bsicos de Mtricas
66
lecciones
Denominacin de
lecciones
Leccin 2. Mtricas del Software
Denominacin de
lecciones
Leccin 3. Mtricas de Calidad del Software
Denominacin de
lecciones
Leccin 4. Mtricas Tcnicas del Software
Denominacin de
lecciones
Leccin 5. Estructura para las Mtricas de Calidad del
software
Denominacin de
captulos
CAPITULO 6: PRUEBAS DEL SOFTWARE
Denominacin de
lecciones
Leccin 1. La Prueba del software
Denominacin de
lecciones
Leccin 2. Tcnicas de diseo de Casos de Prueba
Denominacin de
lecciones
Leccin 3. Estrategias de Aplicacin de Pruebas del
Software
Denominacin de
lecciones
Leccin 4. Pruebas de Software para Objetos
Denominacin de
lecciones
Leccin 5. Pruebas de Software Basado en Componentes
67
UNIDAD 2
ESTNDARES,
MTRICAS DE CALIDAD
Y PRUEBAS DEL
SOFTWARE
68
CAPITULO 4
ESTNDARES Y MODELOS DE
69
INTRODUCCIN
La calidad es un concepto complejo, que se viene aplicando en el campo de
la informtica desde hace muchos aos. En particular, la aplicacin de la calidad al
producto software toma cuerpo con la aparicin de los primeros modelos de
calidad de producto y se fortalece con la propuesta de normas internacionales que
comienzan a ser utilizados como marco de referencia para el campo profesional y
acadmico.
En el ao de 1987 la oficina internacional para la estandarizacin (ISO) y la
Comisicin Electrotcnica internacional (IEC), constituyeron un comit tcnico
conjunto con la finalidad de proponer normas internacionales en el campo de las
tecnologas de la informacin y los equipos.
En 1985 se inici el desarrollo la norma internacional ISO/IEC y fue
publicada en 1991 como ISO/IEC 9126:1991: Tecnologa de la Informacin
Evaluacin del Producto Software Caractersticas de la Calidad y Gua para su
Aplicacin. Utilizaron como base para la definicin de las caractersticas, el
concepto de calidad que posteriormente aparecera en la norma ISO 8402 y que
est basada en las necesidades del usuario. Antes de la publicacin de la norma
ISO/IEC 9126, los trabajos de McCall, Boehm y otros fueron adoptados y
mejorados. Esta norma constituy el primer esfuerzo internacional para unificar y
uniformizar los trminos de calidad referido al producto software y proponer una
estructura basada en caractersticas y subcaractersticas de calidad.
En 1994, se determina la revisin de la norma ISO/IEC 9126 debido a que
se estaban desarrollando normas internacionales en el rea de evaluacin de la
calidad de productos. Resultado de la revisin, se producen dos series de normas;
ISO/IEC 9126 referida al modelo de calidad del producto software y la ISO/IEC
14598 referida a la evaluacin de la calidad del producto. La publicacin completa
de ambas series, se iniciaron en julio de 1998 y concluyeron en abril de 2004,
habindose elaborado 4 normas en las serie 9126 y 6 normas en la serie 14598.
Una nueva propuesta de calidad de producto se plantea en 1999 y se
aprueba en el 2000. La propuesta se denomina proyecto SquaRE (Software
product Quality REquirements) con la idea de proponer un nuevo marco de
referencia para el tema de calidad de producto software, pero esta vez
orientndose a ver la calidad del producto como resultado de un proceso. La serie
de normas internacionales tendrn la numeracin 25000 y an no esta completa.
Cada una de estas normas est dividida en caractersticas y
subcaractersticas internas, externas y de usabilidad que hacen posible definir las
mtricas asociadas a cada una de estas y el tipo de pruebas que se deben llevar a
cabo en la evaluacin de software.
70
4.1 LECCIN 1: LA CALIDAD DEL SOFTWARE
El software es un componente presente en una gran cantidad de
actividades y su correcta operacin es a menudo crtica para el xito del negocio
y/o la seguridad de las personas. El desarrollo o seleccin de productos software
de gran calidad es, por tanto, de suma importancia. Una especificacin y
evaluacin detallada de la calidad del producto software es un factor clave para
asegurar la calidad adecuada. Esto se puede lograr definiendo de manera
apropiada las caractersticas de la calidad y teniendo en cuenta el propsito del
uso del producto software. Es importante que cada caracteristica relevante de la
calidad del producto software sea especificada y evaluada utilizando mtricas
validadas o de amplia aceptacin.
En la norma ISO/IEC 14598 se define al modelo de calidad como un
conjunto de caractersticas y la relacin entre las mismas, que conforman la base
para especificar requerimientos de calidad y evaluar la calidad, en la siguiente
figura se muestra un modelo de calidad de dos niveles para las caractersticas y
subcaractersticas y en el tercer nivel presenta las mtricas; estas ltimas se
pueden obtener de la medicin de los diversos atributos que tiene el producto y
que influyen en cada subcaracterstica.
Figura 8: Esquema general de un modelo de calidad del software
Garvin presenta un enfoque interesante y muy influyente, con cinco visiones
de la calidad: La visin trascendental que puede ser reconocida pero no definida,
la visin del usuario como la adecuacin al propsito del usuario, la visin del
productor como conformidad con la especificacin, la visin del producto basada
en las caractersticas observables del producto, y la visin basada en el valor que
el cliente esta dispuesto a pagar por ella.
El modelo ISO/IEC 9126 presenta el concepto de calidad en uso, la
calidad externa y la calidad interna que corresponden con la visin del
usuario, del productor y del producto.
71
La siguiente figura representa el ciclo de vida de la calidad que muestra la
influencia o dependencia entre los distintos enfoques de calidad interna,
externa y en uso.
Figura 9: Ciclo de vida de la calidad
La siguiente figura representa la calidad como parte del ciclo de vida de
desarrollo de software. En este grfico tambin se aprecia que las necesidades
de calidad del usuario sobre el producto de software, contribuyen a especificar los
requerimientos de calidad externa y estos a su vez los requerimientos de calidad
interna. El cumplimiento de los requisitos de calidad interna se comprobarn en
un proceso de verificacin que permitir medirlo, el cumpliemiento de requisitos
de calidad externa se comprobarn en un proceso de validacin que permitir
medirlo y finalmente la satisfaccin de las necesidades de la calidad del producto
se comprobarn en un proceso de evaluacin que permitir medir la calidad en
uso.
72
Figura 10: Calidad en el ciclo de vida del software
4.2 LECCIN 2: CALIDAD DEL PRODUCTO SOFTWARE NORMA ISO/IEC
9126
La norma ISO/IEC 9126 presentan dos modelos de calidad, el primero
referido a la calidad interna y externa y el segundo modelo referido a la calidad en
uso, a continuacin se describe cada uno de ellos.
4.2.1 Calidad interna y externa
La norma ISO/IEC 9126 define la calidad interna como la la totalidad de las
caractersticas del producto software desde una perspectiva interna. La calidad
interna es medida y evaluada en base a los requerimientos de calidad interna
La calidad externa se define como la totalidad de las caractersticas del
producto software desde una perspectiva externa. Es la calidad del software
cuando es ejecutado, la cual es tpicamente medida y evaluada mientras se
prueba en un ambiente simulado, con datos simulados y usando mtricas
externas. Durante las pruebas, muchas fallas sern descubiertas y eliminadas.
Sin embargo algunas fallas todava pueden permanecer despus de las pruebas.
Como es difcil corregir la arquitectura de software u otros aspectos
fundamentales del diseo del software, el diseo fundamental permanece sin
cambios a travs de las pruebas.
En la siguiente figura se representa el modelo de calidad interna o externa,
se muestra un conjunto de seis caractersticas: funcionalidad, fiabilidad,
usabilidad, eficiencia, facilidad de mantenimiento y portabilidad.
73
Figura 11: Modelo de calidad interna y externa del producto software
En la siguiente tabla se muestra las seis caractersticas y las definiciones
de cada una de ellas.
Caracterstica Definicin
Funcionalidad Capacidad del producto software para proveer las funciones que
satisfacen las necesidades explcitas e implcitas cuando el software se
utiliza bajo condiciones especficas.
Fiabilidad Capacidad del producto software para mantener un nivel especificado de
funcionamiento cuando se est utilizando bajo condiciones especficadas
Usabilidad Capacidad del producto software de ser entendido, aprendido usado y
atractivo al usuario, cuando es usado bajo las condiciones especificadas
Eficiencia Capacidad del producto software para proveer un desempeo apropiado,
de acuerdo a la cantidad de recursos utilizados y bajo las condiciones
planteadas
Facilidad de
mantenimiento
Capacidad del producto software para ser modificado. Las modificaciones
pueden incluir correcciones, mejoras o adaptacin del software a
cambios en el entorno, en requerimientos y especificaciones funcionales
Portabilidad Capacidad del producto software de ser trasladado de un entorno a otro
Tabla 17: Caractersticas de la calidad interna y externa ISO/IEC 9126.
4.2.2 Calidad en uso
La norma ISO/IEC 9126 define la calidad en uso como la perspectiva del
usuario de la calidad del producto software cuando ste es usado en un ambiente
especfico y un contexto de uso especfico. ste mide la extensin para la cual los
74
usuarios pueden conseguir sus metas en un ambiente particular, en vez de medir
las propiedades del software en si mismo. La siguiente figura representa el modelo
de la calidad en uso que muestra un conjunto de 4 caractersticas: efectividad,
productividad, integridad, y satisfaccin.
Figura 12: Modelo de calidad del producto software para la calidad en uso.
La definicin de cada una de las caractersticas de la calidad en uso se
muestra en la siguiente tabla:
Carcaterstica Definicin
Efectividad La capacidad del producto software para permitir a los usuarios lograr las
metas especificadas con precisin y completitud en un contexto de uso
especfico
Productividad La capacidad del producto software para permitir a los usuarios emplear
cantidades apropiadas de recursos en relacin a la efectividad lograda en
un contexto de uso especfico
Integridad La capacidad del producto software para lograr niveles aceptables de
riesgo de dao a las personas, negocio, software, propiedad o entorno en
un contexto de uso especfico
Satisfaccin La capacidad del producto software para satisfacer a los usuarios en un
contexto de uso especfico
Tabla 18: Caractersticas de la calidad en uso ISO/IEC 9126
Las mtricas de calidad del producto se aplican a los diversos atributos del
producto y permiten determinar posteriormente los niveles de calidad del producto.
Las mtricas que se pueden aplicar de acuerdo a los atributos estn definidas en
las normas ISO/IEC 9126 2 para el caso de la calidad externa, la ISO/IEC 9126
3 para el caso de la calidad interna y la ISO/IEC 9126 4 para el caso de la
calidad en uso. En todos los casos, las normas sealan que las mtricas
presentadas no pretenden ser exhaustivas y completas, ni limita la posibilidad de
usar otras mtricas de acuerdo a las necesidades del usuario.
Las mtricas internas pueden ser aplicadas durante el diseo y la
codificacin del producto software no ejecutable y proporciona a todos los
involucrados el beneficio de conocer la calidad del producto duracte su
75
construccin y tomar decisiones sobre esa base para conseguir el producto con la
calidad esperada.
Las mtricas externas pueden ser aplicadas durante la prueba y operacin
del producto software ejecutable y proporciona a todos los involucrados el
beneficio de conocer la calidad del producto software durante las pruebas u
operacin y saber si cumple con la calidad esperada.
Las mtricas de calidad en uso miden el nivel en que un producto software
cumple con las necesidades especficas de los usuarios en un contexto de uso
determinado por los escenarios en los que el usuario realiza sus tareas.
14598
El estandar ISO/IEC 14598 es actualmente usado como base metodolgica
para la evaluacin del producto software. Los productos de software son solo una
parte de la historia, tambin es necesario considerar mediciones en el proceso
empleado para disear, desarrollar, probar, y controlar el producto. En esto juega
un papel importante la ISO/IEC 14598 que ofrece una visin general, explica la
relacin entre su serie y el modelo de calidad de la ISO/IEC 9126, define los
trminos tcnicos utilizados, contiene requisitos generales para la especificacin y
evaluacin de la calidad del software, y clarifica los conceptos generales. Adems
provee un marco de trabajo para evaluar la calidad de todos los tipos de productos
software y establece requisitos para los mtodos de medicin y evaluacin de los
productos de software.
Es importante sealar que, la serie de normas ISO/IEC 14598 proporciona
un marco de trabajo para evaluar la calidad de todos los tipos de productos de
software e indica los requisitos para los mtodos de medicin y para el proceso de
evaluacin. La norma ISO/IEC 14598 consta de seis partes que describen los
requisitos del proceso de evaluacin en tres situaciones diferentes: Requisitos
para desarrolladores (parte 3), Requisitos para compradores (parte 4), Requisitos
para evaluadores (parte 5).
76
Figura 13: Norma ISO/IEC 14598
4.3.1 ISO/IEC 14598 Parte 1: Visin General
Bsicamente provee una visin general de las otras cinco partes y explica la
relacin entre la evaluacin del producto software y el modelo de calidad definido
en la ISO/IEC 9126. Adicionalmente, hace la presentacin del proceso de
evaluacin desglosado en los siguientes pasos: Establecer los requerimientos de
evaluacin, especificar la evaluacin, planear la evaluacin, Ejecutar la
evaluacin.
4.3.2 ISO/IEC 14598 Parte 2: Planificacin y Gestin
Esta parte contiene los requerimientos y las guas para las funciones de
soporte tales como el planeamiento y gestin para la evaluacin del producto del
software. Fundamentalmente, en esta parte, se planifican las mediciones y las
actividades de evaluacin, especficamente se incluye: Preparacin de las
polticas, definicin de objetivos organizacionales y de mejora, identificacin de la
tecnologa, asignacin de responsabilidades, Identificacin e implementacin de
tcnicas de evaluacin para software desarrollado y adquirido, entrenamiento en
tecnologa, recopilacin de datos y herramientas, comparacin y administracin de
mejoras dentro de la organizacin.
4.3.3 ISO/IEC 14598 Parte 3. El Proceso para desarrolladores
Esta parte provee los requerimientos y las recomendaciones para la
evaluacin del producto software cuando la evaluacin es conducida en paralelo
77
con el desarrollo y llevada a cabo por el desarrollador. Se enfoca en el uso de
indicadores que pueden predecir la calidad final del producto midiendo los
productos intermedios que se desarrollan durante el ciclo de vida. Esta parte cubre
el planeamiento y evaluacin de mediciones internas y externas con el fin de
asegurar de que la calidad del producto sea incorporada en la fase de desarrollo.
Una vez identificadas las caractersticas fundamentales de calidad y el marco de
trabajo, deben ser definidas las etapas siguientes:
4.3.3.1 Organizacin: Los aspectos organizacionales de desarrollo y de soporte
deben formar parte de todo el sistema de calidad y del plan de mediciones.
4.3.3.2 Planeamiento del Proyecto y requerimientos de Calidad: El desarrollo y
el ciclo de vida de soporte deben ser establecidos y documentados durante el plan
de calidad o en otros documentos. Es de vital importancia verificar que el
productor y las medidas de control requeridas sean tcnicamente factibles,
razonables y alcanzables.
4.3.3.3 Especificaciones: Esta es la fase, el desarrollador realiza un mapeo de
los requerimientos internos y externos de calidad, con relacin a las
especificaciones. Los requerimientos de mediciones resultantes de esta fase
deben ser un tipo de mapeo entre las especificaciones de requerimientos,
requerimientos externos de calidad, requerimientos internos correspondientes de
calidad y atributos especificados junto a sus escalas de medicin y valores
objetivos que contribuyan a la cuantificacin de la calidad del software, todo esto
puede enfocarse por proyecto o por producto.
4.3.3.4 Diseo y planeamiento: Los procedimientos requeridos para el anlisis y
recopilacin de datos necesitan ser definidos. De esta manera, el plan incluir:
Cronogramas, asignacin de responsabilidades, uso de herramientas, bases de
datos y entrenamiento especializado requerido. La precisin de las mediciones y
tcnicas estadsticas deben ser especificadas. En esta fase tambin deber
consideerarse como los resultados de las mediciones impactarn en el desarrollo
y los planes de contingencia y de mejora.
4.3.3.5 Montaje y pruebas: durante la etapa de montaje y pruebas, las
mediciones actuales son recolectadas, se realizan anlisis apropiados y se toman
acciones necesarias. En cada fase del desarrollo debe procurarse lograr un
montaje primeramente enfocado a las caractersticas internas y externas de
calidad que definan la calidad global del producto y que puedan ser validades por
los resultados de las pruebas y la experiencia del usuario.
Y como etapa final del proyecto, deber ser conducida una revisin general
para determinar la efectividad global del ejercicio de recoleccin, para identificar
costos versus costos, establecer la validez de las mtricas usadas e identificar
puntos en los cuales podran obtenerse beneficios para proyectos futuros. El
resultado de esta revisin podra retroalimentar directamente el lanzamiento de
futuros productos.
78
4.3.4 ISO/IEC 14598 Parte 4. El proceso para compradores
Esta parte provee los requerimientos y las recomendaciones para que la
evaluacin del producto software sea conducida en funcin a los compradores que
planean adquirir o re-usar un producto de software existente o pre-desarrollado.
Los que adquieren el producto pueden comprar paquetes completos ya sea
desarrollados segn ciertas especificaciones o pre-desarrollados para un mercado
ms general. Los compradores tambin podran ser desarrolladores que desean
integrar productos estndar en sus propios diseos de software, o de
desarrolladores buscando herramientas especficas de software. Al respecto,
cuatro etapas son necesarias:
Establecimiento de los requerimientos: El alcance de la evaluacin necesita ser
establecido. Los requerimientos para la calidad delsoftware definidos en la
ISO/IEC 9126 pueden ser usados como punto de partida pero otros aspectos
como el costo y el de cumplimiento a regulaciones debern ser tambin
considerados. El tiempo de la evaluacin necesita ser consistente con los
objetivos; enfoques muy tempranos podran no proporcionar una figura adecuada
de la situacin mientras que enfoques muy tardos podran ser muy limitados en su
uso.
4.3.4.1 Especificacin de la Evaluacin: Durante la redaccin de las
especificaciones, debe considerarse: Los requerimientos de calidad a ser
evaluados correlacionados con la calidad en uso y mtricas externas con
prioridades adems de un umbral de aceptacin definido, el alcance y lo que
cubren los casos de prueba donde sean aplicables referencias a mdulos de
evaluacin, los mtodos de recoleccin de mediciones, informacin requerida y
mtodos de anlisis.
4.3.4.2 Diseo de la Evaluacin: El tipo de evaluacin depende del tipo de
software que est siendo evaluado. Software bajo desarrollo puede ser abordado
en puntos discretos durante el desarrollo o cuando estcompleto. Un plan de
evaluacin necesita considerar: Necesidades de acceso a la documentacin del
producto, herramientas de desarrollo y personal, requerimientos en costos y
conocimientos, cronograma de evaluacin y arreglos de contingencia, y criterio
para decisiones de evaluacin, mtodos y herramientas de reporte,
procedimientos para la validacin y estandarizacin sobre proyectos futuros.
4.3.4.3 Ejecucin de la Evaluacin: Aunque esta etapa podra ser simplemente
un registro en un libro de seguimiento, podra tenerse la necesidad de incluir: Los
resultados mismos y la trazabilidad del producto as como informacin de
configuracin, registros de anlisis, resultados y decisiones, problemas,
limitaciones en las mediciones y cualquier compromiso con relacin a los objetivos
originales, conclusiones sobre los resultados de la evaluacin pero tambin sobre
los mtodos empleados.
79
4.3.5 ISO/IEC 14598 - Parte 5: El Proceso para Evaluadores
Esta parte provee los requerimientos y recomendaciones para la evaluacin del
producto software cuando la evaluacin es conducida por evaluadores
independientes. En esta parte tiene un rol importante los requerimientos de
evaluacin, las especificaciones de evaluacin,el diseo de la evaluacin, las
actividades de evaluacin y el reporte de evaluacin.Estas etapas son resumidas
a continuacin:
4.3.5.1 Requerimientos de Evaluacin: Los requerimientos deberan
adicionalmente definir: La extensin del la cobertura (o el alcance), los objetivos
de evaluacin y mtodos de reporte, las calificaciones e independencia requeridas
de un evaluador.
4.3.5.2 Especificacin de la Evaluacin: Las especificaciones adicionalmente
deberan cubrir: Definicin del alcance y formato en las mtricas empleadas
identificando como debern ser derivadas a partir de los requerimientos del
producto, la identificacin de mediciones no determinsticas para asegurar que
ciertos niveles de frecuentabilidad y objetividad requeridos sean obtenidos, la
identificacin de mtodos de correlacin con relacin a los resultados de las
mediciones.
Se tienen identificadas tres sub-actividades con relacin a la especificacin
de la evaluacin: El anlisis de la descripcin del producto, la especificacin de las
mediciones a ser realizadas, la verificacin de la especificacin resultante frente a
los requerimientos de evaluacin.
4.3.6 ISO/IEC 14598 - Parte 6: Documentacin de los Mdulos de Evaluacin
Esta parte provee las guas para la documentacin del mdulo de
evaluacin. Estos mdulos representan la especificacin del modelo de calidad y
las correspondientes mtricas internas y externas que sern aplicadas a una
evaluacin en particular. Incluye mtodos y tcnicas de evaluacin ms las
mediciones actuales resultantes de su aplicacin. En esta parte tambinse
considera la administracin efectiva de complejidades inherentes a las cuestiones
de medicin.
Las actividades de medicin coordinadas son una caracterstica para una
evaluacin efectiva y un plan necesita proveer un cronograma de evaluacin que
provea al mismo tiempo informacin ptima cuando la evaluacin sea conducida
durante el desarrollo. Los mdulos de la evaluacin son componentes claves de la
ISO/IEC 14598-6 y son usados para proveer un formato consistente y repetible de
reporte.Dichos mdulos proveen: Visibilidad de la informacin necesitada para
cuadrar con requerimientos especficos de calidad, Documentacin de las
interfaces necesarias con herramientas de medicin.
80
25000 (SquaRE)
Desde el ao 2000 se viene trabajando el proyecto SquaRE que pretende
establecer un modelo para la especificacin y evaluacin de un producto software,
lo que ha llevado a reordenar la actual distribucin de normas internacionales
ISO/IEC 9126 e ISO/IEC 14598 y considerando otras normas desarrolladas hasta
la fecha. En la siguiente figura se puede apreciar la nueva arquitectura de la serie
de normas 25000.
Figura 14: Arquitectura de la serie de normas ISO/IEC 25000
ISO 25000:2005 (SQuaRE -Software Quality Requirements and Evaluation)
es una nueva serie de normas que se basa en ISO 9126 y en ISO 14598
(Evaluacin del software). Uno de los principales objetivos de la serie SQuaRE es
la coordinacin y harmonizacin del contenido de ISO 9126 y de ISO 15939:2002
(Measurement Information Model). ISO 15939 tiene un modelo de informacin que
ayuda a determinar que se debe especificar durante la planificacin, performance
y evaluacin de la medicin. Para su aplicacin, cuenta con los siguientes pasos:
Recopilar los datos, Preparacin de los datos y Anlisis de los datos.
La integracin de ISO 9126 e ISO 15939 permiten plantear un proceso de 4
pasos: El primero, la identificacin de los requerimientos relacionados a la calidad
del producto, es decir, seleccionar la parte del modelo de calidad (ISO/IEC 9126-n)
que resulta relevante para la evaluacin de calidad, el segundo, la identificacin
del contexto de interpretacin. Es decir, seleccin de los valores de referencia y
determinacin de los target especificados en un contexto determinado, tercero,
uso de las medidas derivadas de la etapa de preparacin de los datos, y el cuarto,
comparacin y anlisis de los resultados obtenidos respecto de un conjunto de
valores de referencia.
81
SQuaRE incluye un estndar de requerimientos de calidad. Est compuesto
por 14 documentos agrupados en 5 tpicos: Administracin de la Calidad 2500n,
Modelo de Calidad 2501n, Medidas de Calidad 2502n, Requerimientos de
Calidad 2503n y Evaluacin de la Calidad 2504n.
Administracin de la Calidad: Abarca la Gua para SquaRE y Planificacin y
Administracin.
Modelo de Calidad: Describe el modelo de calidad interno / externo y la calidad
en uso y presenta caractersticas y subcaractersticas.
Medidas de Calidad: Medicin de primitivas, Medidas para la calidad interna,
Medidas para la calidad externa y Medidas para la calidad en uso.
Requerimientos de Calidad: Permite habilitar la calidad del software a ser
especificado en trminos de requerimientos de calidad durante todo el ciclo de
vida de un proyecto de software o adquisicin, mantenimiento y operacin.
Evaluacin de la Calidad: Evaluacin de la Calidad, Proceso para
desarrolladores, Proceso para compradores, Proceso para evaluadores y
Documentacin del mdulo de evaluacin.
En la figura siguiente se puede apreciar el modelo de referencia SquaRE,
de la cual hay una reestructuracin de los contenidos, se alinea a otros
documentos existentes, y se amplian aspectos que las normas anteriores slo se
seala a manera de informacin.
Figura 15: Modelo de referencia para la arquitectura Square
82
LECCIN 5: MODELOS DE MEJORA DE PROCESOS DE SOFTWARE
La mejora de proceso software es un mecanismo de mejora continua de la
calidad, el cual bsicamente consiste en aplicar de forma consistente las prcticas
que proporcionan buenos resultados y eliminar o cambiar aquellas prcticas que
causan problemas. Para aplicar la mejora de proceso software, es necesario tener
claro tres aspectos fundamentales: Seleccin del modelo de mejora del proceso a
utilizar, Seleccin del modelo de proceso a utilizar como referencia, Seleccin del
mtodo a utilizar en la etapa de evaluacin.
A continuacin se indican de forma breve cmo han ido surgiendo los
diferentes modelos de mejora continua del proceso software, as como los
diferentes mtodos de evaluacin en el mundo.
5.1 Estados Unidos
En noviembre de 1986, el Instituto de Ingeniera del Software (Software
Engineering Institute, SEI) de Pittsburgh, ante la demanda por parte del
Departamento de Defensa de los Estados Unidos (Department of Defense, DoD)
de un modelo que pudiera valorar la capacidad de sus contratistas software,
empez a desarrollar un modelo sobre la madurez del proceso software. En
septiembre de 1987, el SEI public el primer borrador del modelo de madurez del
proceso software y un cuestionario asociado con respuestas del tipo si o no que
no recogen diferentes niveles de cumplimiento sobre los aspectos tratados.
Este modelo y el cuestionario culminaron en agosto de 1991 en la versin
1.0 del Modelo de Madurez de Capacidad para el Software (Capahility Maturity
Model, CMM). Utilizando este modelo como base, el SEI comercializ dos
mtodos para determinar la madurez del proceso software de una empresa:
Evaluacin del Proceso Software y Valoracin de la Capacidad Software.
La versin 1.1 del CMM public en febrero de 1993 junto con la
actualizacin del mtodo SCE (v.2.0) para que estuviese alineado con la versin
1.1 del CMM. Muchas empresas han modificado el mtodo SPA para alinearlo con
la versin 1.1 del CMM; una de estas empresas ha sido el Instituto para la Mejora
del Proceso Software que ha propuesto el mtodo de Evaluacin Enfocado en la
Accin. En mayo de 1995, el SEI actualiz el SPA, denominndose mtodo de
Evaluacin basada en el CMM para la Mejora Interna del Proceso v.1.0 (CMM-
Based Appraisal for Internal Process Improvemnent, CBA IPI). Se generaron
nuevas versiones ms consistentes del CBA IPI y de SCE en abril de 1996 donde
se utilizan aproximaciones comunes para interpretar el CMM y para recoger y
analizar los datos. Actualmente, se encuentra disponible el CMMI, que recoge
aspectos tanto del CMM como de ISO/IEC 15504.
83
5.2 Unin Europea
En 1988, la Comisin de la Comunidad Europea comenz a realizar un
estudio sobre el comportamiento de su principal programa de Tecnologas de la
Informacin, el Programa Estratgico Europeo para la Investigacin en
Tecnologas de la Informacin descubrindose que la transferencia de tecnologa
en el rea particular de la ingeniera del software no haba tenido el xito esperado
a diferencia de lo acaecido en otras reas como la fabricacin. As, entre octubre
de 1990 y febrero de 1993, la CEC desarroll un proyecto ESPRIT de
investigacin denominado BOOTSTRAP para dotar a Europa de un mtodo de
evaluacin y mejora del proceso software. Este proyecto fue uno de los pioneros
en Europa sobre mejora del proceso software (European System and Software
Iniciative, ESSI). Se desarroll tomando como base el CMM, la serie de
estndares lSO 9000 y el modelo genrico de proceso, PSS 005, de la Agencia
Espacial Europea. A partir de febrero de 1991, el mtodo ha sido gestionado y
desarrollado por un grupo de inters econmico europeo, llamado Instituto
Bootstrap, el cual public la versin 2.3 en septiembre de 1995 y la versin 3.0 en
febrero de 1997 (con ISO/IEC 15504).
5.3 ISO/IEC
Durante 1990-91, el DTI del Reino Unido patrocin un estudio de
investigacin, denominado ImprovelT, para analizar los mtodos de evaluacin y
valorar la capacidad de ingeniera del software de los contratistas potenciales.
Este estudio descubri que existan numerosos mtodos de evaluacin que
estaban en uso o bajo desarrollo. Tambin identific un apoyo muy extendido por
parte de las empresas al desarrollo de un mtodo comn de dominio pblico y,
preferiblemente, respaldado por un estndar internacional.
As, en junio de 1991, el grupo de Estndares Internacionales para la
Ingeniera del Software aprob un perodo de estudio con base de ImprovelT, para
investigar la necesidad y las caractersticas de un estndar de evaluacin del
proceso software. El informe del estudio indicaba que exista un consenso
internacional sobre la necesidad y los requisitos de un estndar de evaluacin del
proceso software. En junio de 1992 se estableci un nuevo grupo de trabajo para
desarrollar este estndar internacional que, en enero de 1993, lanz el proyecto
denominado Mejora del Proceso Software y Determinacin de la Capacidad para
desarrollar un estndar internacional de evaluacin y mejora del proceso software.
El proyecto toma como base las mejores caractersticas de los siguientes mtodos
y/o modelos de evaluacin: CMM, TRILLIUM, Software Technology Diagnostic
(STD) y Bootstrap. El conjunto de los borradores de SPICE se publicaron como
informes tcnicos durante 1995; posteriormente le ha seguido un perodo de
prueba que an no ha finalizado. De hecho, se dice que actualmente se encuentra
en fase de pruebas y slo en el entorno de grandes empresas, sin existir todava
experimentacin comercial con el mtodo. Finalmente, en 1998 se convirti en el
estndar internacional ISO/IEC 15504 versin 3.3 de evaluacin del proceso
software.
84
Actualmente, las dos lneas, CMM e ISO 15504, han confluido en lo que se
ha denominado CMMI (capability Maturity Model integration). CMMI contempla
ambas visiones mediante su representacin continua (perspectiva ISO) [CMMI,
2001a] y por etapas (perspectiva CMM) [CMMI, 2001b]. Tambin se incluye un
mtodo de evaluacin denominado SCAMPI [SCAMPI, 2001].
Los principales modelos de mejora del proceso software son:
5.4 Modelo IDEAL
Desarrollado por el SEI (Software Engineering Institute) Constituido por
bucle continuo de 5 etapas (Initiation, Diagnosing, Estahlishing, Acting and
Leveraging). La etapa inicial es el comienzo del programa de mejora. Una vez que
se tiene el patrocinio y los recursos adecuados, se evala el estado actual de la
prctica de software (diagnstico). Posteriormente, se establecen la estrategia de
implementacin y los planes de accin para la mejora (establecimiento). Por
ltimo, se ejecutan los planes y las mejoras recomendadas (actuacin) y se
difunden (analizando las lecciones aprendidas y los resultados de la mejora, al
mismo tiempo que se revisa la aproximacin realizada) para el siguiente ciclo de
mejora.
5.5 ISO/IEC TR 1550 Parte 7
Gua para utilizacin en la mejora del proceso [ISO, l998]. La mejora del
proceso software se considera, igualmente, como un proceso continuo, donde una
empresa se mueve continuamente alrededor de un ciclo de mejora.
5.6 Modelo de mejora del proceso software desarrollado por ISPI (Institute
for Software Process Improvement)
A continuacin, se describen brevemente cada una de las etapas del
modelo de mejora: Compromiso a la mejora del proceso software por parte de la
Alta Direccin para que se involucre en el proyecto de mejora, Evaluacin del
proceso software para determinar cul es el estado actual del proceso software de
la compaa, es decir sus puntos fuertes y dbiles, con objeto de determinar los
procesos que se van a mejorar, Infraestructura y planes para la mejora del
proceso software para crear la estructura necesaria de mejora del proceso,
Implantacin de la mejora del proceso software para realizar las actividades
definidas previamente en el plan.
Los dos modelos de proceso utilizados habitualmente en la etapa de
evaluacin son el Modelo de Madurez de la Capacidad (CMM) y la parte 2 del
estndar ISO 15504. Como se ha indicado anteriormente, el modelo de procesos
se utiliza en la etapa de evaluacin con objeto de conocer cmo est el propio
proceso software de la empresa con respecto a dicho modelo.
85
La etapa de evaluacin se puede llevar a cabo desde dos puntos de vista
diferentes: Enfoque de evaluacin del proceso que es un enfoque colaborativo y
su objeto es determinar las fortalezas y debilidades del proceso software de la
compaa, y el enfoque de valoracin de la capacidad software que se trata ms
bien de un enfoque auditor y su objeto es identificar qu subcontratistas
cualificados podrn llevar a cabo el desarrollo software a contratar. Actualmente,
con el nuevo CMMI se utiliza el mtodo SCAMPI como mtodo de evaluacin para
la mejora del proceso.
86
CAPITULO 5
MTRICAS DE CALIDAD DEL
SOFTWARE
87
INTRODUCCIN
Los trminos de mtricas, medicin, y medida en muchos de los casos han sido
relacionados con los instrumentos utilizados mediante un mtodo especfico al
acto mecnico de tomar una medicin mediante escalas cualitativas o
cuantitativas que determinan los valores de esa medicin.
En general es as, pero los tres conceptos son diferentes, y sern tratados en este
captulo. Pero lo que no se puede admitir es que sea un acto mecnico ya que el
proceso de medicin involucra muchas actividades, inicia con la seleccin y
definicin de la caracterstica que se quiere medir, posteriormente se definir que
mtricas es posible usar para la medicin, luego se definir la escala de tipo
cuantitativo o cualitativo y el mtodo, y por ltimo se procede a hacer al anlisis de
cmo se hara la medicin.
En este captulo se tratar estos temas tan importantes para el proceso y
procedimiento de la evaluacin de software, que se convertirn en la clave para
realizarla, ya que, de ella depende el xito o fracaso de la evaluacin.
88
5.1 LECCIN 1: CONCEPTOS BSICOS DE MTRICAS
La palabra mtrica, es muy comn asociarla con las palabras medicin y
medida, aunque estas tres son distintas. La medicin es el proceso por el cual los
nmeros o smbolos son asignados a atributos o entidades en el mundo real tal
como son descritos de acuerdo a reglas claramente definidas. La medida
proporciona una indicacin cuantitativa de la extensin, cantidad, dimensiones,
capacidad o tamao de algunos atributos de un proceso o producto. Mtrica se
define como una medida cuantitativa del grado en que un sistema, componente o
proceso posee un atributo dado o tambin una medida cuantitativa del grado en
que el sistema, componente o proceso posee un atributo dado.
Un Indicador es la mtrica o una combinacin de mtricas que proporcionan
una visin profunda del proceso del software, del proyecto software o del producto
en s. Un indicador proporciona una visin profunda que permite ajustar el
producto, el proyecto o el proceso. El objetivo principal de los indicadores de
proceso es evaluar las condiciones de funcionamiento de un proceso y poder tener
una visin de la eficacia de un proceso existente. Durante un tiempo considerable
se recopilan las mtricas de todos los proyectos y se proporcionan indicadores
para obtener mejoras en el software.
Los mtodos de medicin o clculo son unas secuencias lgicas de
operaciones y potenciales heursticas, expresadas de forma genrica, que permite
la realizacin de una descripcin de actividad. El tipo de mtodo de medicin va a
depender de la naturaleza de las operaciones utilizadas para cuantificar el atributo.
Pueden distinguirse dos tipos: Subjetivo, cuando la cuantificacin supone un juicio
realizado por un ser humano, y Objetivo, cuando la cuantificacin est basada en
mtodos numricos.
Una escala es un conjunto de valores con propiedades definidas. Las
escalas pueden ser escalas numricas (Continua o Discreta) o escala Categrica.
Los tipos de escala pueden ser: Nominal, Ordinal, Intervalo, entre otras.
En este sentido la mtrica es la correspondencia de un dominio real o
emprico a un mundo formal, matemtico. La medida incluye al valor numrico o
nominal asignado al atributo de un ente por medio de dicha correspondencia. Las
mtricas peden ser de tipo directo cuando no dependen de ninguna mtrica de
otro atributo e indirecta cuando se deriva de una o ms mtricas de otros atributos.
Algunos ejemplos de Mtricas Directas son: Longitud del Texto del Cuerpo
de una Pgina (medido por cantidad de palabras), Cantidad de Enlaces Rotos
Internos (medidos por la presencia de errores del tipo 404), Cantidad de Imgenes
con Texto Alternativo (medido por la presencia de la etiqueta ALT o con texto no
nulo, en cada una de las imgenes vinculadas a las pginas de un sitio Web).
Algunos ejemplos de Mtricas Indirectas son: Porcentaje de Enlaces Rotos
de un Sitio, Porcentaje de Presencia de la propiedad ALT.
89
Ahora se estudir brevemente el amplio campo de las mtricas del
software, ya que es la tcnica que junto a revisiones, pruebas y gestin de
configuracin constituye el conjunto principal de medios operativos para el
aseguramiento de la calidad en el proyecto.
En general, para la evaluacin de la calidad es ms habitual centrarse en
medidas del producto que en medidas de procesos, aunque estas ltimas pueden
ser tiles para medir ciertos aspectos como la fiabilidad, se mide el tiempo medio
entre fallos de software a lo largo de algn perodo de prueba, etc. Para mejorar
cualquier proceso se debe medir atributos del proceso, definir y desarrollar un
juego de mtricas para esos atributos, y utilizar las mtricas para encontrar
indicadores para la estrategia de mejora.
Figura 16: Mtricas del Proceso y Mejoras en el Proceso de Software
La eficacia de un proceso de software se mide a travs de un juego de
mtricas segn los resultados que provienen del proceso. Dentro de estos
resultados se debe incluir: Medida de los errores detectados antes de la entrega
del software, defectos detectados, productos de trabajo entregados, esfuerzo
humano y tiempo consumido y ajuste con la planificacin.
Tambin se debe incluir mtricas para medir las caractersticas de tareas
especficas de la ingeniera del software, como la medida del tiempo y del esfuerzo
para llevar a cabo actividades de proteccin, actividades genricas de ingeniera
de software.
Para una organizacin es importante estar a gusto con la recopilacin y la
utilizacin de mtricas de proceso, de stas se deriva la identificacin de
90
indicadores llevando a un enfoque ms riguroso denominado Mejora estadstica
del proceso de software (MEPS). Este enfoque utiliza el anlisis de fallas del
software para recopilar informacin de errores y defectos. Para realizar un anlisis
de fallas se debe seguir los siguientes pasos: Categorizar por origen de todos los
errores y defectos, Registrar el costo de corregir cada error o el del defecto,
Contar el nmero de errores y de defectos de cada categora, calcular el costo
global de errores y defectos de cada categora, para posteriormente, desarrollar
planes para eliminar los errores y defectos ms costosos.
Para determinar las principales causas que pueden ocasionar defectos en
el software y con base en ello extraer los indicadores que permitan a una
organizacin de software modificar su proceso para reducir la frecuencia de
errores y defectos se utiliza el diagrama de espina. En el diagrama de espina, la
lnea central, representa el factor de calidad o el problema en consideracin. Las
lneas diagonales conectadas a la lnea central indican una causa potencial del
problema de calidad.
Figura 17: Anlisis de Problemas y causas de calidad del software
Por ejemplo, en la siguiente tabla se muestra las causas y su origen de
fallas en un proyecto de software:
Origen de errores o
defectos
Causa %
Lgica 20
Manejo de datos 10.9
estndares 6.9
Diseo Especificaciones 25.5
Interfaz de software 6.0
Interfaz de Hardware 7.7
Comprobacin de errores 10.9
Cdigo
Interfaz de usuario 11.7
Tabla 19: Origen de errores o defectos y causas en un proyecto software
91
Utilizando el diagrama de espina para la identificacin de las causas
especficas para este problema, sera:
Figura 18: Identificacin de causas de errores o defectos en un software
Las mtricas del Proyecto se utilizan para minimizar la planificacin de
desarrollo, ya que realizan ajustes y minimizan los retrazos. Adems se utilizan
para evaluar la calidad de los productos. A medida que mejora la calidad se
minimizan los defectos. Las mtricas del proyecto de software sugiere que los
proyectos deben medir: Las entradas, la dimensin de los recursos que se
requieren para realizar el trabajo, las salidas, medidas de las entradas o productos
creados durante el proceso de ingeniera de software, y resultados, medidas que
indican la efectividad de las entregas.
5.2 LECCIN 2: MTRICAS DEL SOFTWARE
Las mtricas del software se pueden categorizar en:
5.2.1 Medidas Directas: Dentro de estas se pueden incluir: el costo y el esfuerzo
aplicado, Las lneas de cdigo producidas (LCD), La velocidad reejecucin, El
tamao de la memoria y los defectos informados durante un periodo de tiempo
establecido.
5.2.2 Mtricas Indirectas: Dentro de estas estn la funcionalidad, La calidad, La
complejidad, La eficiencia, la Fiabilidad, La facilidad de uso y La facilidad de
mantenimiento.
5.2.3 Mtricas orientadas al tamao: Provienen de la normalizacin de las
medidas de calidad y/o productividad considerando el tamao del software que se
haya producido, los datos registrados se muestran en la siguiente tabla:
92
Proyecto LCD Esfuerzo Costo $ Pginas de
documentacin
Errores Defectos Personas
IRIS 18.200 24 200000 945 134 86 4
Tabla 20: Tabla de registro de datos de mtricas orientadas al tamao
Teniendo en cuenta los datos de la tabla anterior, se puede derivar otras
mtricas para comparar varios proyectos. Por ejemplo: Errores por KLDC (miles
de lneas de cdigo), Defectos por KLDC, Pginas de documentacin por KLDC,
Errores por persona/mes, LDC por persona/mes, Costo ($) por pgina de
documentacin
5.3.4 Mtricas orientadas a la funcin: Las mtricas del software orientadas a
la funcin permiten la medida de la funcionalidad de la aplicacin. Esta mtrica fue
propuesta busca identificar los factores crticos que determinan el tamao del
software y por consiguiente, estimar el esfuerzo y el costo para desarrollarlo. De
aqu nace la tcnica de anlisis de puntos de funcin, que mide una aplicacin con
base en las funciones que ste realiza por solicitud del usuario final.
Los puntos de funcin se obtienen utilizando una funcin emprica basado
en medidas cuantitativas del dominio de informacin del software y valoraciones
subjetivas de la complejidad del software. Los puntos de funcin se calculan
utilizando la siguiente tabla:
Factor de ponderacin Parmetros
de medicin
Cuenta
Simple Medio Complejo
Nmero de
entradas de
usuario
X 3 4 6 =
Nmero de
salidas de
usuario
X 4 5 7 =
Nmero de
peticiones de
usuario
X 3 4 6 =
Nmero de
archivos
X 7 10 15 =
Nmero de
interfaces
externas
X 5 7 10 =
Costo_total
Tabla 21: Tabla de clculo de puntos de funcin
Se determinan 5 caractersticas del mbito de la informacin y los clculos
aparecen en la posicin apropiada en la tabla. Los valores del mbito de
informacin estn definidos de la siguiente forma:
93
Caracteratica Definicin
Nmero de entradas de usuario Se cuenta cada entrada de usuario que proporcione
al software diferentes datos orientados a la
aplicacin
Nmero de salidas de usuario Se cuenta cada salida que proporciona al usuario
informacin orientada a la aplicacin. En este
contexto las salidas se refieren a informes, pantallas,
mensajes de error
Nmero de peticiones de usuario Una peticin esta definida como una entrada
interactiva que resulta de la generacin de algn tipo
de respuesta en forma de salida interactiva. Se
cuenta cada peticin por separado
Nmero de archivos Se cuenta cada archivo maestro lgico
Nmero de interfaces externas Se cuentan todas las interfaces legibles por la
mquina por ejemplo: archivos de datos, en cinta o
discos que son utilizados para transmitir informacin
a otro sistema.
Tabla 22: Caractersticas y definicin de puntos de funcin (a)
Cuando han sido recogidos los datos anteriores, se asocia el valor de
complejidad a cada cuenta. Las organizaciones que utilizan mtodos de puntos
de funcin desarrollan criterios para determinar si una entrada es denominada
simple, media o compleja. No obstante la determinacin dela complejidad es algo
subjetivo.
PF = Cuenta_total * [0.65 + 0.01* sumatoria (f
i
)]
PF Punto de funcin
Cuenta_total Es la suma de todas las entradas obtenidas
f
i
Donde i=1 hasta 14. son los valores de ajuste de la complejidad basados en las
respuestas a las cuestiones sealadas de la siguiente tabla:
Evaluar cada factor de 0 a 5
0 1 2 3 4 5
No
influencia
Incidental Moderado Medio Significativo Esencial
F
i
:
1 Requiere el sistema copias de seguridad y de recuperacin
fiable?
2 Se requiere comunicacin de datos?
3 Existen funciones de procesamiento distribuido?
4 Es crtico el rendimiento?
5 Se jecutar el sistema en un entorno operativo existente y
fuertemente utilizado?
6 Requiere el sistema entrada de datos interactivo?
7 Requiere la entrada de datos interactiva que las transacciones de
entrada se lleven a cabo sobre mltiples pantallas u operaciones?
8 Se actualizan los archivos maestros de forma interactiva?
94
9 Son complejas las entradas, las salidas, los archivos o las
peticiones?
10 Es complejo el procesamiento interno?
11 Se ha diseado el cdigo para ser reutilizable?
12 Estn incluidas en el diseo la conversin y la instalacin?
13 Se ha diseado el sistema para soportar mltiples instalaciones
en diferentes organizaciones?
14 Se ha diseado la aplicacin para facilitar los cambios y para ser
fcilmente utilizada por el usuario?
Tabla 23: Caractersticas y definicin de puntos de funcin (b)
Una vez calculados los puntos de funcin se usan como medida de la
productividad, calidad y otros productos del software.
Productividad= PF/persona-mes
Calidad= Errores/ PF
Costo= Pesos/PF
Documentacin= Pginas_documentadas/ PF
5.3 LECCION 3: MTRICAS DE CALIDAD DEL SOFTWARE
El objetivo de la Ingeniera de Software es desarrollar y producir software de alta
calidad y para lograrlo es fundamental aplicar mtodos y herramientas efectivos
dentro del contexto de un proceso de desarrollo de software. Dentro de las
medidas de calidad del software estn:
5.3.1 Correccin: Es el grado en el que el software cumple su funcin, la medida
ms comn es: Defectos por KDLC (miles de lneas de cdigo)
5.3.2 Facilidad de mantenimiento: es la facilidad con la que se puede corregir
un programa si se encuentra un error. Se utiliza medidas indirectas como: Tiempo
medio de cambio (TCM), que es el tiempo que tarda en: Analizar una peticin,
Disear una modificacin, Implementar un cambio o Probar y realizar un cambio.
5.3.3 Integridad: mide la capacidad del software para resistir ataques. Se define
como, Integridad= Sumatoria [(1-amenaza)*(1-seguridad)], para ello se debe tener
en cuenta los siguientes atributos: Amenaza que es la probabilidad de que un
ataque ocurra en un tiempo determinado, y la seguridad que es la probabilidad de
que se pueda repeler el ataque de un tipo determinado.
5.3.4 Facilidad de Uso: Mide la amigabilidad del software con el usuario final. Se
mide en funcin de: Habilidad intelectual o fsica para aprender el sistema, El
tiempo requerido para hacer uso eficiente del sistema, Aumento de la
productividad y la Valoracin subjetiva de la disposicin de los usuarios hacia el
sistema.
95
5.3.5 Eficacia de la eliminacin de defectos: La eficacia de la eliminacin de
defectos (EED), es una mtrica que permite medir la habilidad de filtrar las
actividades de la garanta de calidad y de control, ya que es aplicable a todas las
actividades del marco de trabajo del proceso. Se definen de la siguiente forma:
EED= E/ (E+ D), Donde E es el nmero de errores encontrados antes de la
entrega del software y D es el nmero de defectos encontrados despus de la
entrega. El valor ptimo de EED es 1, que significa que no se han encontrado
defectos en el software.
5.4 LECCIN 4: MTRICAS TCNICAS DEL SOFTWARE
Las mtricas tcnicas para el software proporcionan una manera sistemtica de
valorar la calidad basndose en un conjunto de reglas. Tambin proporcionan al
ingeniero del software descubrir y corregir problemas potenciales antes de que se
conviertan en defectos catastrficos.
5.4.1 Factores de calidad de McCall
McCall y Cavano definieron un juego de factores de calidad como los
primeros pasos hacia el desarrollo de mtricas de a calidad del software. Estos
factores evalan el software desde tres puntos de vista distintos: Operacin del
producto, Revisin del producto y Transicin del producto. A continuacin se
muestran los factores de calidad de McCall, las caractersticas asociadas y la
definicin de cada una de ellas:
1. Operaciones del producto - Caractersticas operativas
Correccin: Hace lo que se
le pide?
El grado en que una aplicacin satisface sus especificaciones
y consigue los objetivos encomendados por el cliente.
Fiabilidad: Lo hace de
forma fiable todo el tiempo?
El grado que se puede esperar de una aplicacin lleve a cabo
las operaciones especificadas y con a precisin requerida.
Eficiencia: Qu recursos
hardware y software
necesito?
La cantidad de recursos hardware y software que necesita
una aplicacin para realizar las operaciones con los tiempos
de respuesta adecuados.
Integridad: Puedo controlar
su uso?
El grado con que puede controlarse el acceso al software o a
los datos a personal no autorizado.
Facilidad de uso: Es fcil y
cmodo de
manejar?
El esfuerzo requerido para aprender el manejo de una
aplicacin, trabajar con ella, introducir datos y conseguir
resultados
2. Revisin del producto - Capacidad para soportar cambios
Facilidad de mantenimiento:
Puedo localizar los fallos?
El esfuerzo requerido para localizar y reparar errores.
Fiexibilidad: Puedo aadir
nuevas opciones?
El esfuerzo requerido para modificar una aplicacin en
funcionamiento.
Facilidad de prueba: Puedo
probar todas las opciones?
El esfuerzo requerido para probar una aplicacin de forma que
cumpla con lo especificado en los requisitos.
3. Transicin del producto - Adaptabilidad a nuevos entornos
Portabilidad: Podr usarlo
en otra mquina?
El esfuerzo requerido para transferir a aplicacin a otro
hardware o sistema operativo.
Reusabilidad: Podr utilizar
alguna parte del software en
Grado en que partes de una aplicacin pueden utilizarse en
otras aplicaciones
96
otra aplicacin?
Interoperabilidad: Podr
comunicarse con otras
aplicaciones o sistemas
informticos?
El esfuerzo necesario para comunicar la aplicacin
con otras aplicaciones o sistemas informticos
Tabla 24: Factores de calidad de McCall
5.4.2 Mtricas para el esquema de puntuacin
Las mtricas pueden ir en forma de lista de comprobacin para evaluar y puntuar
atributos especficos del software. La puntucin va en una escala del O (bajo) al
10 (alto). Se emplean las siguientes mtricas en el esquema de puntuacin:
Facilidad de auditora La facilidad con la que se puede comprobar el cumplimiento de los
estndares.
Exactitud La exactitud de los clculos y del control.
Estandarizacin de
comunicaciones
El grado de empleo de estndares de interfaces, protocolos y
anchos de banda.
Complexin El grado con que se ha logrado la implementacin total de una
funcin.
Concisin Lo compacto que es el programa en trminos de lneas de cdigo.
Consistencia El empleo de un diseo uniforme y de tcnicas de documentacin
a lo largo del proyecto de desarrollo del software
Estandarizacin de
datos
El empleo de estructuras y tipos de datos estndares a lo largo del
programa.
Tolerancia al error El dao causado cuando un programa encuentra un error.
Eficiencia de ejecucin El rendimiento del funcionamiento de un programa.
Capacidad de
expansin
El grado con que se pueden ampliar el diseo arquitectnico, de
datos o procedimental.
Generalidad La amplitud de aplicacin potencial de los componentes del
programa.
Independencia del
software
El grado con que se desacopla el software del hardware donde
opera.
Instrumentacin El grado con que el programa vigila su propio funcionamiento e
identifica los errores que ocurren.
Modularidad La independencia funcional de componentes de programa.
Operatividad La facilidad de operacin de programa
Seguridad La disponibilidad de mecanismos que controlan o protegen los
programas y tos datos.
Autodocumentacin El grado en que el cdigo fuente proporcionan documentacin
significativa
Simplicidad El grado de facilidad con que se puede entender un programa.
Independencia del
sistema software
El grado de independencia de programa respecto a las
caractersticas del lenguaje de programacin no estndar,
caractersticas del sistema operativo y otras restricciones.
Trazabilidad La capacidad de seguir una representacin del diseo o un
componente real del programa hasta los requisitos
Formacin El grado en que ayuda el software a manejar el sistema o los
nuevos usuarios.
Tabla 25: Mtricas para el esquema de puntuacin
97
5.4.3 Mtricas del modelo de Calidad FURPS
El modelo de MCCall ha servido de base para modelos de calidad
posteriores, y este es el caso del modelo FURPS, producto del desarrollo de
Hewlett-Packard. En este modelo se desarrollan un conjunto de factores de
calidad de software, bajo el acrnimo de FURPS.
F Functionality - funcionalidad
R Usability usabilidad facilidad de uso
R Realiability confiabilidad
P Performance desempeo
S supportability-capacidad de soporte
La siguiente tabla, presenta la clasificacin de los atributos de calidad que
se incluyen en el modelo, junto con las caractersticas asociadas a cada uno de
ellos:
Factor de Calidad Atributos
Funcionalidad Caractersticas y capacidades del programa
Generalidad de las funciones
. Seguridad del sistema
Facilidad de uso Factores humanos
Factores estticos
Consistencia de la interfaz
Documentacin
Confiabilidad Frecuencia y severidad de las fallas
Exactitud de las salidas
Tiempo medio de fallos
Capacidad de recuperacin ante fallas
Capacidad de prediccin
Rendimiento Velocidad del procesamiento
Tiempo de respuesta
Consumo de recursos
Rendimiento efectivo total
Eficacia
Capacidad de Soporte Extensibilidad
Adaptabilidad
Capacidad de pruebas
Capacidad de confl9uracin
Compatibilidad
Requisitos de instalacin
Tabla 26: Mtricas del modelo de Calidad FURPS
El modelo FURPS incluye, adems de los factores de calidad y los
atributos, restricciones de diseo y requerimientos de implementacin, fsicos y de
interfaz. Las restricciones de diseo especifican o restringen el diseo del sistema.
Los requerimientos de implementacin especifican o restringen la codficacion o
construccin de un sistema. Por su parte, los requerimientos de interfaz
especifican el comportamiento de los elementos externos con los que el sistema
98
debe interactuar. Por ltimo, los requerimientos fsicos especifican ciertas
propiedades que el sistema debe poseer, en trminos de materiales, forma, peso,
tamao.
5.4.4 Factores de calidad ISO 9126
El estndar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los
atributos clave de calidad para un producto de software. Este estndar es una
simplificacin del Modelo de McCalI, e identifica seis caractersticas bsicas de
calidad que pueden estar presentes en cualquier producto de software. El
estndar provee una descomposicin de las caractersticas en subcaractersticas,
que se muestran en la siguiente tabla:
Caracterstica Subcaracterstica
Funcionalidad Adecuacin
Exactitud
Interoperabilidad
Seguridad
Confiabilidad Madurez
Tolerancia a fallas
Recuperabilad
Usabilidad Entendibilidad
Capacidad de aprendizaje
Operabilidad
Eficiencia Comportamiento en tiempo
Comportamiento de recursos
Mantenibilidad Analizabilidad
Modificabilidad
Estabilidad
Capacidad de pruebas
Portabilidad Adaptabilidad
Instalabilidad
.Reemplazabilidad
Tabla 27: Caractersticas y Subcaractersticas modelo ISO/IEC 9126
Las mtricas ISO / IEC 9126 no son necesariamente usados para
mediciones directas, pero proveen una valiosa base para medidas indirectas, y
una excelente lista para determinar la calidad de un sistema.
5.5 LECCIN 5: ESTRUCTURA PARA LAS MTRICAS TCNICAS DEL
SOFTWARE
Es importante establecer una estructura fundamental y un conjunto de
principios bsicos para la medicin de mtricas tcnicas para el software. Los
principios bsicos de la medicin, sugeridos por Roche, pueden caracterizarse
mediante cinco actividades:
99
Actividad Definicin
Formulacin Obtencin de medidas y mtricas del software apropiadas para la
representacin de software
Coleccin Mecanismo empleado para acumular datos necesarios para obtener las
mtricas formuladas.
Anlisis Clculo de las mtricas y aplicacin de herramientas matemticas.
Interpretacin Evaluacin de los resultados de las mtricas en un esfuerzo por
conseguir una visin interna de la calidad de la representacin.
Realimentacin Recomendaciones obtenidas de a interpretacin de mtricas tcnicas
transmiitidas al equipo software.
Tabla 28: Actividades y definicin de Mtricas Tcnicas de Software
Los principios que se pueden asociar con la formulacin de las mtricas
tcnicas son los siguientes: Los objetivos de la medicin que deben establecerse
antes de empezar la recoleccin de datos, Todas las tcnicas sobre mtricas
deben definirse sin ambigedades, Las mtricas deberan obtenerse basndose
en una teora vlida para el dominio de aplicacin, Hay que hacer las mtricas a
medida para acomodar mejor los productos y procesos especficos.
Roche sugiere los siguientes principios para la recoleccin y anlisis de
datos: Siempre que sea posible, la recogida de datos y el anlisis debe
automatizarse, Se deben aplicar tcnicas estadsticas vlidas para establecer las
relaciones entre os atributos internos del producto y las caractersticas externas de
la calidad, Se deben establecer directrices de interpretacin y recomendaciones
para todas las mtricas.
La mtrica obtenida y las medidas que conducen a ello deben tener las
siguientes caractersticas: Simples y fciles de calcular, Emprica e intuitivamente
persuasivas, Consistentes y objetivas, Consistentes en el empleo de unidades y
tamaos, Independiente del lenguaje de programacin, Un mecanismo eficaz para
la realimentacin de calidad.
5.5.1 Mtricas del Modelo de Anlisis
En esta fase, las mtricas tcnicas proporcionan una visin interna a la calidad del
modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la
intencin de predecir el tamao del sistema resultante; es probable que el
tamao y la complejidad del diseo estn directamente relacionados. Dentro de
las mtricas del modelo de anlisis tenemos:
5.5.1.1 Mtricas basadas en la Funcin: La mtrica del punto de funcin se
utiliza como medio para predecir el tamao de un sistema obtenido a partir de un
modelo de anlisis. Para visualizar esta mtrica se utiliza un diagrama de flujo de
datos, el cual se evaluar para determinar las siguientes medidas clave que son
necesarias para el clculo de a mtrica de punto de funcin: Nmero de entradas
100
del usuario, Nmero de salidas del usuario, Nmero de consultas del usuario,
Nmero de archivos, Nmero de interfaces externas.
5.5.1.2 Mtrica Bang
Puede aplicarse para desarrollar una indicacin del tamao del software a
implementar como consecuencia del modelo del anlisis. Para calcular la mtrica
bang, el desarrollador de software evala primero un conjunto de primitivas. Las
primitivas se determinan evaluando el modelo de anlisis y desarrollando cuentas
para los siguientes elementos de la tabla:
Primitivas funcionales (Pfu) Transformaciones que aparecen en el nivel inferior de un
diagrama de flujo de datos.
Elementos de datos (ED) Los atributos de un objeto de datos, los elementos de datos no
compuestos y aparecen en el diccionario de datos.
Objetos (OB) Objetos de datos
Relaciones (RE) Las conexiones entre objetos de datos.
Estados (ES) El nmero de estados observables por el usuario en el
diagrama de transicin de estados.
Transiciones (TR El nmero de transacciones de estado en el diagrama de
transicin de estado.
Adems, se determinan medidas adicionales para:
Primitivas modificadas de
funcin manual (PMFu)
Funciones que caen fuera del limite del sistema y que deben
modificarse para acomodarse al nuevo sistema.
Elementos de datos de
entrada (EDE)
Aquellos elementos de datos que se introducen en el sistema.
Elementos de datos de
salida (EDS)
Aquellos elementos de datos que se sacan en el Sistema.
Elementos de datos
retenidos (EDR)
Aquellos elementos de datos que son retenidos (almacenados)
por el sistema.
Muestras (tokens) de datos
(TCi)
Las muestras de datos que existen en el limite de la i-sima
primitiva funcional (evaluada para cada primitiva).
Conexiones de relacin
(Rei)
Las relaciones que conectan el i-simo objeto en el modelo de
datos con otros objetos.
Tabla 29: Mtrica Bang
5.5.2 Mtricas del Modelo de Diseo
Se concentran en las caractersticas de la arquitectura del programa, con
nfasis en la estructura arquitectnica y en la eficiencia de los mdulos. Estas
mtricas son de caja negra en el sentido que no requieren ningn conocimiento
del trabajo interno de un mdulo en particular del sistema. Card y Glass definen
las siguientes tres medidas de complejidad:
La complejidad estructural, S(i), de un mdulo i se define de a siguiente
manera:
S(i)=f
2
out
(i) Donde f
out
(i) es la expansin del mdulo i. La expansin indica el
nmero de mdulos que son invocados directamente por el mdulo i.
101
La complejidad del sistema, C(i), se define como la suma de las
complejidades estructural y de datos C(i)= S(i) + D(i). La complejidad de datos,
D(i), proporciona una indicacin de la complejidad en la interfaz interna de un
mdulo y se define como: D(i)=v(i)/[f
out
(i) + 1]. Donde v(i) es el nmero de variables
de entrada y salida que entran y salen del mdulo i.
Fenton sugiere varias mtricas de morfologa simples que permiten
comparar diferentes arquitecturas mediante un conjunto de dimensiones directas.
Las mtricas a aplicar son:
Tamao= n + a. Donde n es el nmero de nodos (mdulos) y a es el nmero de
arcos (lneas de control). Para la arquitectura mostrada se tiene tamao=
17+18=35.
Profundidad= camino ms largo desde el nodo raz a un nodo hoja. Para el
ejemplo Profundidad= 4
Amplitud=nmero mximo de nados de cualquier nivel de la arquitectura. Para el
ejemplo amplitud= 6
Relacin arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura
y proporciona una indicacin sencilla de acoplamiento de la arquitectura. Para el
ejemplo r=18/17= 1.06
5.5.3 Mtricas del Codigo Fuente
Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez
que se han generado o estimado el cdigo despus de completar el diseo. Estas
medidas son:
n
1
: nmero de operadores diferentes que aparecen en el programa.
N
2
: nmero de operandos diferentes que aparecen en el programa.
N
1
: nmero total de veces que aparece el operador.
N
2
: nmero total de veces que aparecen el operando.
Halstead utiliza medidas primitivas para desarrollar expresiones par la
longitud global del programa; volumen mnimo potencial para un algoritmo; el
volumen real (nmero de bits requeridos para especificar un programa); el nivel
del programa (una medida de la complejidad del software); nivel del lenguaje (una
constante para un lenguaje dado); y otras caractersticas tales como el esfuerzo
de desarrollo, tiempo de desarrollo e incluso el nmero esperado de fallos en el
software.
Halstead propone las siguientes mtricas:
Longitud N se puede estimar como: N = n
1
log
2
n
1
+ n
2
log
2
n
2
Volumen de programa se define como: V = N n
1
log
2
(n
1
+ n
2
).
102
Tomando en cuenta que V variar con el lenguaje de programacin y
representa el volumen de informacin (en bits) necesarios para especificar un
programa.
5.5.4 Mtricas para Pruebas
Las mtricas para pruebas se concentran en el proceso de prueba, no en
las caractersticas tcnicas de as pruebas mismas. En general, los responsables
de las pruebas deben fiarse en las mtricas de anlisis, diseo y cdigo para que
sirvan de gua en el diseo y ejecucin de los casos de prueba. El esfuerzo de las
pruebas tambin se puede estimar utilizando mtricas obtenidas de las medidas
de Halstead. Usando la definicin del volumen de un programa, y, y nivel de
programa, NP, el esfuerzo de la ciencia del software puede calcularse como:
NP = 1/[(n1/2) x (N2/n2)) (Ec. 1)
e = V/NP (Ec. 2)
El porcentaje del esfuerzo global de pruebas a asignar a un mdulo k se
puede estimar utilizando la siguiente relacin:
Porcentaje de esfuerzo de pruebas (k) = e(k)/ Se(i) (Ec. 3)
Donde e(k) se calcula para el mdulo k utilizando las ecuaciones (Ec. 1) y
(Ec. 2) la suma en el denominador de la ecuacin (Ec. 3) es la suma del esfuerzo
de la ciencia del software a o largo de todos los mdulos del sistema. A medida
que se van haciendo las pruebas, tres medidas diferentes proporcionan una
indicacin de la complecin de las pruebas:
Medida de
amplitud de las
pruebas.
Proporciona una indicacin de cuantos requisitos se han probado del
nmero total de ellos. Indica la complecin del plan de pruebas.
Profundidad de
las pruebas
Medida del porcentaje de los caminos bsicos independientes probados
con relacin al nmero total de estos caminos en el programa. e puede
calcular una estimacin razonablemente exacta del nmero de caminos
bsicos sumando a complejidad ciclomtica de todos los mdulos del
programa.
Perfiles de fallos e emplean para dar prioridad y categorizar los errores. La prioridad indica
la severidad del problema. Las categoras de los fallos proporcionan una
descripcin de un error, de manera que se puedan llevar a cabo anlisis
estadstco de errores.
Tabla 30: medidas de Complecin de pruebas
5.5.5 Mtricas del Mantenimiento
Todas las mtricas descritas pueden utilizarse para el desarrollo de nuevo
software y para el mantenimiento del existente. El estndar IEEE 982.1-1988
103
sugiere el ndice de madurez del software (IM) que proporciona una indicacin de
la estabilidad de un producto software basada en los cambios que ocurren con
cada versin del producto. Con el IM se determina a siguiente informacin:
MT= Nmero de mdulos en la versin
Actual Fc = Nmero de mdulos en la versin actual que se han cambiado
Fa= Nmero de mdulos en a versin actual que se han aadido
Fe= Nmero de mdulos en la versin actual que se han eliminado
El ndice de madurez del software se calcula de la siguiente manera;
IM= [MT - (Fc + Fa + Fe)]I/MT
A medida que el IM se aproxima a 1 el producto se empieza a estabilizar.
El IM puede emplearse tambin como mtrica para la planificacin de las
actividades de mantenimiento del software.
104
CAPITULO 6
PRUEBAS DEL SOFTWARE
105
INTRODUCCIN
Una de las caractersticas tpicas del desarrollo de software basado en el
ciclo de vida es la realizacin de controles peridicos, norrnalmente coincidiendo
con la terminacin de cada una de las etapas, del producto o los documentos.
Estos controles pretenden una evaluacin de la calidad de los productos
generados para poder detectar posibles defectos cuanto antes. in embargo, todo
sistema o aplicacin, independientemente de estas revisiones, debe ser probado
mediante su ejecucin controlada antes de ser entregado al cliente. Estas
ejecuciones o ensayos de funcionamiento, posteriores a la terminacin del cdigo
del software, se denominan habitualmente pruebas.
Cuando se desarrolla software, dentro del ciclo de vida se ha establecido
formalmente que la prueba es una actividad fundamental dentro de cada una de
las etapas del proceso de desarrollo de software. A partir de la prueba se puede
determinar la calidad de los productos implementados.
Desde hace mucho tiempo, la prueba ha sido un tema muy importante en la
ingeniera de software, a partir de cual se han generado un gran nmero de
trabajos. En este captulo se presenta una revisin tcnica sobre la prueba de
software, abordndose fundamentalmente los enfoques de prueba propuestos
para probar software construido bajo un enfoque funcional, orientado a objetos y
basado en componentes.
Las pruebas constituyen un mtodo ms para poder verificar y validar el
software cuando ya est en forma de cdigo ejecutable. La verificacin es el
proceso de evaluacin de un sistema o de uno de sus componentes para
determinar si los productos satisfacen las condiciones impuestas al comienzo de
dicha fase, y la validacin hace referencia al proceso de evaluacin de un sistema
o de uno de sus componentes durante o al final del proceso de desarrollo para
determinar si satisface los requisitos especificados. As, validar una aplicacin
implica comprobar si satisface los requisitos marcados por el usuario.
106
6.1 LECCIN 1: LA PRUEBA DEL SOFTWARE
Indiscutiblemente la prueba es una actividad fundamental en los procesos
de desarrollo de software. La prueba de software permite al desarrollador
determinar si el producto generado satisface las especificaciones que han sido
establecidas en el diseo. As mismo, una prueba de software permite detectar la
presencia de errores que pudieran generar salidas o comportamientos
inapropiados durante su ejecucin.
De acuerdo a la IEEE, el concepto de prueba se define como una actividad
en la cual un sistema o componente es ejecutado bajo condiciones especficas, se
observan o almacenan los resultados y se realiza una evaluacin de algn aspecto
del sistema o componente. Para Myers, probar es el proceso de ejecutar un
programa con el fin de encontrar errores.
Cuando se habla de condiciones especficas, se puede suponer la
presencia de una especie de ambiente de operacin de la prueba, para el cual
deben existir determinados valores para las entradas y las salidas, as como
tambin ciertas condiciones que delimitan a dicho ambiente de operacin,
formalmente esto es conocido como Caso de Prueba.
El objetivo de las pruebas es la deteccin de errores o fallas y defectos en
el software. Se trata de una actividad a posteriori, para la deteccin de problemas
en el software, y la posterior rectificacin. La mayora de los estudios revelan que
los mejores programadores incluyen una cierta media de defectos por cada 1.000
lneas de cdigo. Los defectos no son siempre el resultado de la negligencia, sino
que en su aparicin influyen mltiples factores como la mala comunicacin entre
los miembros del equipo que da lugar a malentendidos en los requisitos pedidos.
Por todo ello, el descubrimiento de un defecto significa un xito para la mejora de
la calidad del software. Las recomendaciones de G. J. Myers MYERS para las
pruebas son las siguientes:
1. Cada caso de prueba debe definir el resultado de salida esperado. Este
resultado esperado es el que se compara con el realmente obtenido de la
ejecucin en la prueba. Las discrepancias entre ambos se consideran sntomas de
un posible defecto en el software.
2. El programador debe evitar probar sus propios programas porque desea
demostrar que funcionan sin problemas. Lo ideal sera que probara el software el
peor enemigo de quien lo ha construido, ya que as se asegurara una bsqueda
implacable de cualquier error cometido.
3. Se debe inspeccionar a conciencia el resultado de cada prueba para descubrir
posibles sntomas de defectos. Lamentablemente es frecuente pasar por alto
sntomas bastante claros. Esto invalida todo el esfuerzo realizado en la
planificacin, diseo y ejecucin de pruebas.
107
4. Al generar casos de prueba, se deben incluir datos de entrada vlidos y
esperados, asi como, datos no validos e inesperados.
5. Las pruebas deben centrarse en dos objetivos: Probar si el software no hace lo
que debe, y Probar si el software hace lo que no debe, es decir, si provoca efectos
secundarios adversos.
6. Se deben evitar los casos no documentados ni diseados con cuidado ya que
suele ser necesario probar una y otra vez el software hasta que queda libre de
defectos. No documentar o guardar los casos significa repetir constantemente el
diseo de casos de prueba.
7. No deben hacerse planes de prueba suponiendo que no hay defectos en los
programas y dedicando pocos recursos a las pruebas. Hay que asumir que
siempre hay defectos y hay que detectarlos. Las estadsticas confirman cerca del
40% del esfuerzo de desarrollo se consume en pruebas y depuracin.
8. La experiencia parece indicar que donde hay un defecto hay otros, es decir, la
probabilidad de descubrir nuevos defectos en una parte del software es
proporcional al nmero de defectos ya descubierto.
9. Las pruebas son una tarea ms creativa que el desarrollo de software. Siempre
se han considerado las pruebas como una tarea destructiva y rutinaria. No existen
tcnicas rutinarias para el diseo de pruebas y hay que recurrir al ingenio para
alcanzar un buen nivel de deteccin de defectos con los recursos disponibles.
La filosofa ms adecuada para las pruebas consiste en planificarlas y
disearlas de forma sistemtica para poder detectar el mximo nmero y variedad
de defectos con el mnimo consumo de tiempo y esfuerzo. Un buen caso de
prueba es aquel que tiene una gran probabilidad de encontrar un defecto no
descubierto an, ya que el xito de una prueba consiste en detectar un defecto no
encontrado antes.
La prueba de software se realiza con el propsito de encontrar algo que
difiera a las especificaciones planteadas para el producto o bien, para detectar la
presencia de situaciones que pudieran generar resultados inapropiados. En la
siguiente tabla se muestran los objetivos, los principios, las caractersticas y los
atributos principales que deben tener las pruebas:
La prueba es un proceso de ejecucin de un programa con la intencin
de descubrir un error.
Un buen caso de prueba es aquel que tiene alta probabilidad de
mostrar un error no descubierto hasta entonces.
Objetivos de las
pruebas
Una prueba tiene xito si se descubre un error.
Hacer un seguimiento de las pruebas hasta los requisitos del cliente
Plantear y disear las pruebas antes de generar ningn cdigo
Principios de las
Pruebas
El 80% de todos los errores se centran en solo en el 20% de los
108
mdulos
Empezar las pruebas en mdulos individuales y avanzar hasta probar
el sistema entero.
No son posibles las pruebas exhaustivas
Deben realizarse por un equipo independiente al equipo de desarrollo
Operatividad
Objetividad
Controlabilidad
Capacidad de descomposicin
Simplicidad
Estabilidad
Caractersticas de un
software fcil de
probar
Facilidad de comprensin
Ms alta probabilidad de encontrar un error.
No debe ser redundante
Atributos de una
buena prueba
No debera ser ni demasiado sencilla ni demasiado compleja
Tabla 31: Objetivos, Principios, y Caractersticas de los Atributos de la Prueba
6.2 LECCIN 2: TCNICAS DE DISEO DE CASOS DE PRUEBA
El objetivo de las tcnicas de diseo de casos de prueba es el de conseguir
una confianza aceptable en que se detectarn los defectos existentes sin consumir
una cantidad excesiva de recursos. Toda la disciplina de pruebas debe moverse
en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los
casos para descubrir los defectos existentes.
La idea fundamental para el diseo de casos de prueba consiste en la
elleccin de algunas posibilidades de funcionamiento del software que por sus
caractersticas, se consideren representativas del resto. As si no se detectan
defectos en el software al ejecutar dichos casos, se puede tener un cierto nivel de
confianza en que el programa no tiene defectos. La dificultad de esta idea es
saber elegir los casos que se deben ejecutar. De hecho, una eleccin puramente
aleatoria no proporciona demasiada confianza en que se puedan detectar todos
los defectos existentes.
6.2.1 Pruebas de caja blanca
Las pruebas de caja blanca enfocan su atencin a los detalles
procedimentales del software, por ello la implementacin de estas pruebas
depende fuertemente de la disponibilidad de cdigo fuente. Este tipo de pruebas,
permiten generar casos para ejercitar y validar los caminos de cada mdulo, las
condiciones lgicas, los bucles y sus lmites, as como tambin para las
estructuras de datos.
Las pruebas inician con la observacin de que un programa difcilmente
puede considerarse como probado por completo si su cdigo contiene partes que
nunca han sido ejecutadas. Este mtodo analiza la estructura lgica del programa
y, para cada alternativa que puede presentarse, los datos de prueba ideados
conducirn a ella. Se procura escoger los que verifiquen cada posibilidad en las
109
proposiciones case, las clusulas de cada proposicin if y la condicin de
terminacin de cada ciclo.
Figura 19: Prueba de Caja Blanca
En un programa complejo este mtodo es imprctico, pero en un mdulo
pequeo constituye un excelente medio de prueba y depuracin. En una prueba
que se vale del mtodo de la caja blanca, se tornan patentes las ventajas de un
diseo de programa modular. Un buen criterio de prueba para proyectos extensos
consiste en aplicar los mtodos a cada mdulo pequeo conforme se escriba;
luego se usan esos datos en las secciones ms amplias del programa una vez
terminadas.
Las pruebas de caja blanca tambin son conocidas como pruebas de caja
de cristal o pruebas estructurales. Algunas de las pruebas ms significativas
dentro de este enfoque son mostradas en la siguiente tabla:
Prueba Definicin
Prueba de caminos En este tipo de prueba se realiza un anlisis sobre una representacin
grfica de un programa denominada grafo de control. En este grafo,
los nodos representan bloques de instrucciones de un programa y los
flujos de ejecucin para dichas instrucciones se representan por medio
de aristas. A partir de este grafo, se puede identificar un conjunto
bsico de caminos de ejecucin, sobre el cual se pueden realizar
pruebas con el propsito de ejercitar el flujo de ejecucin de los
caminos en una unidad.
Prueba de condiciones Basndose en un grafo de control, pueden generarse casos de prueba
para elementos individuales de expresiones lgicas. De esta forma se
pretende probar cada condicin con todas sus posibles alternativas.
Prueba de ciclos A partir del grafo de control, pueden generarse casos de prueba para
las iteraciones definidas en los programas con el propsito de verificar
si se realizan de forma correcta.
Prueba de definicin
de datos
Estas pruebas son realizadas con el objetivo de encontrar posibles
contradicciones o redundancias en la definicin de los datos utilizados
en el software. Para ello se realiza un anlisis del comportamiento de
cada uno de los datos o cada una de los flujos de ejecucin.
Tabla 32: Pruebas de Caja Blanca
110
6.2.2 Pruebas de caja negra
Estas son conocidas como pruebas funcionales o pruebas de
comportamiento, concentran la atencin en generar casos de prueba que permitan
ejercitar los requisitos funcionales de un programa. A diferencia de las pruebas de
caja blanca, que se basan en la lgica interna del software, este tipo de pruebas
se concentran en su funcionalidad, por lo que mucho del trabajo se realiza
interactuando con la interfaz del software. Los casos de prueba generados en este
enfoque, se disean a partir de valores entrada y salida. De esta forma, se puede
determinar la validez de una salida para un conjunto de entradas proporcionadas.
Los datos de prueba se escogern atendiendo a las especificaciones del
problema, sin importar los detalles internos del programa, a fin de verificar que el
programa corra bien. Los criterios mnimos que guiarn al escoger los datos de
prueba:
Valores Fciles: El programa se depurar con datos de fcil comprobabilidad.
Valores tpicos realistas: Se ensayar un programa con datos seleccionados
para que representen como se aplicar. Los Datos deben ser sencillos, de modo
que los resultados sean verificables en forma manual.
Valores extremos o Valores ilegales: Cuando en un programa entra basura, su
salida habr de ser un mensaje de error adecuado. Es preferible que el programa
ofrezca indicacin de errores en la entrada y que realice clculos que sigan siendo
factibles luego de desechar la entrada equivocada.
Figura 20: Prueba de Caja Negra
Con la aplicacin de pruebas de caja negra se permite detectar errores
como funciones incorrectas o ausentes, errores en estructuras de datos, errores
de rendimiento, errores de interfaz, as como errores de inicializacin y
terminacin. Con la aplicacin de esa tcnica se obtiene un conjunto de pruebas
que reduce el nmero de casos de pruebas y dicen algo sobre la presencia o
111
ausencia de errores. Algunas de las pruebas ms conocidas en este contexto se
muestran en la siguiente tabla:
Prueba Definicin
Particin equivalente La idea de esta tcnica, es en dividir los valores vlidos y no vlidos
para entradas y salidas en un nmero reducido de particiones de
forma que, el comportamiento del software sea el mismo para
cualquier valor contenido en una particin particular. El propsito
principal de una particin es reducir la cantidad de casos de prueba
generados en el proceso.
Anlisis de los valores
lmite
La generacin de casos de prueba en esta tcnica, se enfoca en los
valores limites, esto bajo la consideracin de que existe una tendencia
a fallar precisamente cuando el software trabaja con valores extremos
de la variable de entrada. Generalmente los valores establecidos para
generar los casos de prueba son el mnimo, valores un poco arriba del
mnimo, valor mximo y valores un poco arriba del mximo.
Pruebas segn la
experiencia (error
guessing)
Este tipo de prueba la generacin de casos se realiza a partir de la
intuicin y la experiencia. La idea bsica es redactar una lista de las
posibles fallas o de las posibles situaciones en las cuales suele ocurrir
algn problema y as desarrollar casos de prueba basados en la
informacin contenida en estas listas.
Tablas de decisin Este tipo de prueba permite describir el comportamiento de un
programa a partir de un conjunto de acciones que este realiza cuando
se opera bajo determinadas condiciones. En este enfoque, las
condiciones pueden ser interpretadas como entradas de un programa
y las acciones como las salidas producidas. Para ello se pueden
utilizar conectores lgicos y (and), o (or) y no (not). Al involucrar
aspectos de lgica, se dice que este tipo de prueba se hace ms
rigurosa, que permite adems transformar una especificacin en
lenguaje natural en una especificacin ms formal.
Tabla 33: Pruebas de Caja Negra
A continuacin se presentan las distintas tcnicas de diseo de casos de caja
negra:
6.2.2.1 Particiones o clases de equivalencia: Utiliza las cualidades que definen
un buen caso de prueba de la siguiente manera: Cada caso debe cubrir el mximo
nmero de entradas, Debe tratarse el dominio de valores de entrada dividido en un
nmero finito de clases de equivalencia donde la prueba de un valor
representativo de una clase permite suponer que el resultado obtenido ser el
mismo que el obtenido probando cualquier otro valor de la clase.
El mtodo de diseo de casos consiste en la identificacin de clases de
equivalencia y la creacin de los casos de prueba corespondientes. Para
identificar las posibles clases de equivalencia de un programa a partir de su
especificacin deben seguirse los siguientes pasos: primero, la identificacin de Ia
condiciones de entradas al programa, Segundo, a partir de ellas, se identifican
clases de equivalencia que pueden ser de datos vlidos o de datos no vlidos o
errneos.
112
La identificacin de las clases se realiza basndose en el principio de
igualdad de tratamiento, donde todos los valores de la clase deben ser tratados de
la misma manera por el programa. Existen algunas reglas que ayudan a identificar
clases:
Si se especifica un rango de valores para los datos de entrada (por ejemplo, el
nmero estar comprendido entre 1 y 49), se crear una clase vlida (1>=
nmero <= 49) y dos clases no vlidas (nmero < 1 y nmero > 49).
Si se especifica un nmero de valores (por ejemplo. se pueden registrar de uno
a tres propietarios de un piso), se crear una clase vlida (1<= propietarios >=3) y
dos no vlidas (propietarios< 1 y propietarios>3).
Una situacin del tipo booleana (por ejemplo, el primer carcter debe ser una
letra), se identifican una clase vlida (es una letra) y una no vlida (no es una
letra).
Si se especfica un conjunto de valores admitidos (por ejemplo, pueden
registrarse tres tipos de inmuebles: Casas, apartamentos y locales comerciales) y
se sabe que eI programa trata de forma diferente cada uno de ellos, se identifica
una clase vlida por cada valor (en este caso son tres: Casas, apartamentos y
locales comerciales) y una no vlida (cualquier otro caso: por ejemplo, lote o
finca).
En cualquier caso, si se sospecha que ciertos elementos de una clase no se
tratan igual que el resto de la misma, debe dividirse en clases menores.
La aplicacin de estas reglas para la derivacin de clases de equivalencia
permite desarrolla los casos de prueba para cada elemento de datos del dominio
de entrada.
El ltimo paso del mtodo es el uso de las clases de equivalencia para
identificar los casos de prueba correspondientes. Este proceso consta de las
siguientes fases: Fase 1, la asignacin de un nmero nico a cada clase de
equivalencia. Fase 2, hasta que todas las clases de equivalencia hayan sido
cubiertas por casos de prueba, se tratar de escribir un caso que cubra tantas
clases vlidas, no incorporadas, como sea posible. Fase 3, hasta que todas las
clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba,
escribir un caso para una nica clase no vlida sin cubrir.
6.2.2.2 Anlisis de Valores Lmite (AVL): Mediante la experiencia, se ha podido
constatar que los casos de prueba que exploran las condiciones lmite de un
programa producen un mejor resultado pura la deteccin de defectos, es decir, es
ms probable que los defectos del software se acumulen en estas condiciones. Se
puede definir las condiciones lmite como las situaciones que se hallan
directamente arriba, abajo y en los mrgenes de las clases de equivalencia.
113
El anlisis de valores lmite es un tcnica de diseo de casos que
complementa a la de particiones de equivalencia. Aunque parezca que el AVL es
simple de usar, su aplicacin tiene mltiples matices que requieren un gran
cuidado a la hora de disear las pruebas. Las reglas para identificar clases son las
siguientes:
Si una condicin de entrada especifica un rango de valores (-1.0 <= valor <=
1.0) se deben generar casos para los extremos del rango (-1.0 y +1.0) y casos no
vlidos para situaciones justo ms all de los extremos (-1.001 y +1.001, en el
caso que se admitan tres decimales).
Si la condicin de entrada especifica un nmero de valores (el archivo de
entrada tendr de 1 a 255 registros), hay que escribir casos para Ios nmeros
mximo, mnimo, uno ms del mximo y uno menos del mnimo de valores (0,
1,255 y 256 registros).
Usar la regla 1 para la condicin de salida (el descuento mximo aplicable en
compra al contado ser el 50%, el mnimo ser el 6%). Se escribirn casos para
intentar obtener descuentos de 5.99%, 6%, 50% y 50.01%.
Usar la regla 2 para cada condicin de salida (el programa puede mostrar de 1 a
4 listados). Se escrihen casos para intentar generar 0, 1, 4 y 5 listados.
Si la entrada o la salida de un programa es un conjunto ordenado, los casos
deben concentrarse en el primero y en el ltimo elemento.
Es recomendable utilizar el ingenio para considerar todos los aspectos y
matices, a veces sutiles, para la aplicacin del AVL.
6.2.3 Conjetura de errores
Esta tcnica consiste en enumerar una lista de errores posibles que pueden
cometer los desarrolladores o de situaciones propensas a ciertos errores. Despus
se generan casos de prueba en base a dicha lista que suelen corresponder con
defectos que aparecen comnmente y no con aspectos funcionales. No existen
directrices eficaces que puedan ayudar a generar este tipo de casos, lo nico que
se puede hacer es presentar algunos ejemplos que reflejan esta tcnica. Algunos
valores a tener en cuenta para los casos especiales son los siguientes:
El valor 0 es una situacin propensa a error tanto en la salida como en la
entrada.
En situaciones en las que se introduce un nmero variable de valores, conviene
centrarse en el caso de no introducir ningn valor y el de un solo valor. Tambin
puede ser interesante el de todos los valores iguales.
114
es recomendable suponer que el programador haya podido malinterpretar algo
en la especificacin.
Tambin interesa imaginar lo que el usuario puede introducir como entrada a un
programa. Se dice que se debe prever toda clase de acciones de un usuario como
si fuera a sabotear el programa.
6.2.4 Pruebas Aleatorias
En las pruebas aleatorias se simula la entrada habitual del programa
creando datos para introducir en l que sigan la secuencia y la frecuencia con las
que podran aparecer en la prctica diaria, de forma contnua, sin descanso. Esto
implica usar herramientas denominadas generadores de pruebas a las que se
alimenta con una descripcin de datos y secuencias de entradas posibles as
como una estimacin de probabilidad de ocurrir cada una de ellas en el uso real.
Si el proceso de generacin de pruebas se ha realizado correctamente, se
crearn todas las posibles entradas del programa en todas las combinaciones
posibles, aunque no sea necesario hacer esto para una prueba adecuada.
Tambin se puede conseguir, indicando la distribucin estadstica que siguen, que
la frecuencia de entrada para orientar correctamente nuestras pruebas hacia
aquello que es ms probable que suceda en la prctica real.
6.3 LECCIN 3: ESTRATEGIAS DE APLICACIN DE PRUEBAS DEL
SOFTWARE
Una estrategia de prueba integra las tcnicas de diseo de casos de prueba en un
conjunto de pasos bien planeados que dan como resultado la correcta
construccin del software. Una estrategia de prueba de software proporciona una
gua para los desarrolladores del software, para la organizacin de control de
calidad y para el cliente. Por tanto una estrategia de software debe incorporar la
planificacin de la prueba, el diseo de casos de prueba, la ejecucin de pruebas
y la agrupacin y evaluacin de los datos resultantes.
6.3.1 Prueba de unidad
La prueba de unidad centra el proceso de verificacin en la menor unidad
del diseo del software. Aqu se prueban los caminos de control importantes, con
el fin de descubrir errores dentro del mbito de un mdulo. La complejidad relativa
de las pruebas y errores descubiertos se encuentra limitada por los lineamientos
establecidos por la prueba de software.
Se prueba la Interfaz del mdulo para asegurar que la informacin fluye en
forma adecuada hacia y desde la unidad del programa que est siendo probada.
Se analizan las estructuras de datos para asegurar que los datos mantienen su
integridad temporal durante todos los pasos de ejecucin del algoritmo. Se prueba
las condiciones lmite para asegurar que el mdulo funciona correctamente dentro
115
de los lmites establecidos por el procesamiento, se activan los caminos bsicos
de la estructura de control con el fin de asegurar de que las sentencias del mdulo
se ejecutan por lo menos una sola vez, y finalmente, se prueban todos los
caminos de manejo de errores. Myers, propone una lista de comprobaciones para
la prueba de interfaces que se muestra en el siguiente cuadro:
Es igual el nmero de parmetros de entrada al nmero de
argumentos?
Coinciden las caractersticas (atributos) de los parmetros
con los argumentos?
Coinciden el sistema de unidades de los parmetros con el de
los argumentos?
Son correctos el nmero, atributos y el orden de los
argumentos de las funciones incorporadas?
Existen referencias o parmetros que no estn asociados con
el punto de entrada actual?
Entran slo argumentos alterados?
Son consistentes las definiciones de variables globales entre
mdulos?
lista de comprobaciones para
la prueba de interfaces de un
mdulo
Se pasan las restricciones como argumentos?
Son correctos los atributos de los archivos?
Son correctas las sentencias de apertura?
Coinciden las especificaciones de formato con las sentencias
de Entrada/Salida?
Coincide el tamao del buffer con el tamao del registro?
Se abren los archivos antes de usarlos?
Se tienen en cuenta las condiciones de fin de archivo?
Se manejan errores de Entrada/Salida?
Cuando un mdulo tenga
operaciones bsicas de
Entrada/Salida externa, se
deben llevar a cabo pruebas
adicionales
Hay algn error textual en la informacin de salida?
Tabla 34: Lista de comprobaciones para la prueba de interfaces
Se deben disear casos de prueba para descubrir errores tales como:
Tipificacin impropia o inconsistente, Inicializacin o valores implcitos errneos,
Nombres de variables incorrectos, Tipos de datos inconsistentes, Desbordamiento
o errores en el direccionamiento de memoria.
Adems se deben disear casos de prueba para detectar errores causados
por clculos incorrectos o flujos de control inapropiados. Entre los errores ms
comunes en los clculos estn: Procedencia aritmtica incorrecta mal aplicada,
Operaciones de modo mixto, Inicializaciones incorrectas, Falta de precisin,
Representacin incorrecta de una expresin.
Los casos de prueba deben descubrir errores como: Comparaciones entre
tipos de datos distintos, Operadores lgicos o de procedencia incorrecta,
Terminacin de ciclos inapropiada o inexistente, Falta de salida cuando se
encuentra una iteracin mal aplicada, Variables internas a un ciclo modificadas en
forma inadecuada.
116
Entre los errores que se deben comprobar estn los siguientes: La
condicin de error hace que intervenga el sistema antes que el mecanismo de
errores, Descripcin ilegible del error, El error sealado no corresponde con el
error encontrado, La descripcin del error no proporciona suficiente informacin
para ayudar en la localizacin de la causa del error.
La prueba de los lmites es la ltima etapa de la prueba de unidad y quiz la
ms importante. El software falla en sus condiciones lmite, o sea, que
frecuentemente aparece un error cuando se procesa el elemento n-simo de un
arreglo n-dimensional, cuando se hace la i-sima repeticin de un ciclo de x pasos
o cuando se llega a los valores mximo mnimo permitidos. Los casos de prueba
que ejerciten las estructuras de datos por debajo o encima de los mnimos y
mximos permitidos son apropiados para descubrir estos errores.
La estrategia de aplicacin y la planificacin de las pruebas pretenden
integrar el diseo de los casos de prueba en una serie de pasos bien coordinados
a travs de la creacin de distintos niveles de prueba, con diferentes objetivos.
Adems, permite la coordinacin del personal de desarrollo, y del cliente, gracias a
la definicin de los papeles que deben desempear cada uno y la forma de
llevarlos a cabo.
En general, la estrategia de pruebas es la siguiente: Las pruebas
comienzan a nivel de mdulo, una vez terminadas, progresan hacia la integracin
del sistema completo y su instalacin, y culminan cuando el cliente acepta el
producto y se pasa a su explotacin inmediata. Esta serie tpica de etapas se
describe con mayor detalle a continuacin:
Se comienza en la prueba de cada mdulo, que normalmente la realiza el propio
personal de desarrollo en su entorno.
Con el esquema del diseo del software, los mdulos probados se integran para
comprobar sus interfaces en el trabajo conjunto.
El software totalmente ensamblado se prueba como un conjunto para comprobar
si cumple o no tanto los requisitos funcionales como los de rendimientos,
seguridad, etc.
EI software ya validado se integra con el resto del sistema para probar su
funcionamiento conjunto.
Por ltimo, el producto final se pasa a la prueba de aceptacin para que el
usuario compruebe en su propio entorno de explotacin si lo acepta como est o
no.
6.3.2 Pruebas de integracin
Las pruebas de integracin estn totalmente ligadas a la forma prevista de
integrar los distintos componentes del software hasta contar con el producto global
117
que debe entregarse. As, las pruebas de integracin implican una progresin
ordenada de pruebas que parte desde los componentes y que culmina en el
sistema completo. Su objetivo fundamental es la prueba de las interfaces entre
componentes o mdulos.
La prueba de Integracin es una tcnica sistemtica para construir la
estructura del programa mientras que al mismo tiempo, se llevan a cabo pruebas
para detectar errores asociados con la interaccin. El objetivo es tomar los
mdulos probados en unidad y estructurar un programa que est de acuerdo con
lo que dicta el diseo.
Una vez que los mdulos funcionen por separado y hayan pasado la prueba
de unidad es necesario realizar las pruebas para ver cmo funcionan juntos todos
los mdulos. Normalmente aqu es donde pueden surgir los problemas en la unin
de los mdulos. Los datos se pueden perder en una interfaz, un mdulo puede
tener un efecto adverso sobre otro mdulo; las subfunciones, cuando se
combinan, pueden no producir el objetivo principal deseado, las estructuras de
datos globales pueden presentar problemas.
Existen 2 tipos de integracin, la primera es no incremental en donde se
intenta elaborar software en mdulos grandes, en otros casos un slo mdulo,
pero en ellos es ms difcil aislar los errores y cuando alguno de ellos es corregido
produce otros errores. El segundo tipo de integracin es incremental en donde se
desarrollan mdulos pequeos y funcionales que hacen que los errores sean ms
fcil de aislar y corregir, es ms probable que se puedan probar completamente
las interfaces y aplicar un enfoque de prueba sistemtico.
6.3.2.1 Integracin incremental ascendente: El proceso empieza combinando
primero los mdulos de ms bajo nivel en grupos que realizan alguna subfuncin
especfica, donde se busca reducir el nmero de pasos de integracin. Luego se
describe para cada grupo un mdulo impulsor o conductor, que es un mdulo que
permite simular la llamada a los mdulos, introducir los datos de prueba a travs
de los parmetros de llamada y recoger los resultados a travs de los de salida.
Posteriormente, se prueba cada grupo empleando su impulsor y por ltimo se
eliminan los mdulos impulsores de cada grupo y se sustituyen por los mdulos
del nivel superior de la jerarqua.
6.3.2.2 Integracin Incremental Descendente: La integracin incremental
descendente comienza con el mdulo de control principal y va incorporando
mdulos subordinados progresivamente. No existe un procedimiento general para
determinar cul de los mdulos subordinados posibles es mejor incorporar
primero, es decir, no se puede dar una regla general que permita determinar la
secuencia ptima de incorporacin de mdulos. Hay que estudiar en cada caso
cul es el mejor orden de incorporacin para minimizar el esfuerzo o para lograr
una mejor organizacin. La siguiente figura muestra la integracin incremental
descendente
118
Figura 21: Integracin Incremental Descendente
Las etapas fundamentales de la integracin descendente son las siguientes:
El mdulo raz es el primero. e escriben mdulos ficticios para simular la
presencia de los subordinados ausentes que sern llamados por el mdulo raz.
Una vez probado el mdulo raz se sustituye uno de los subordinados ficticios por
el mdulo correspondiente segn el orden elegido. e incorporan ficticios para
recoger las llamadas del ltimo incorporado.
e ejecutan las correspondientes pruebas cada vez que se incorpora un mdulo
nuevo.
Al terminar cada prueba, se sustituye un ficticio por su correspondiente real.
6.3.2.3 Integracin no incremental: En este tipo de integracin cada mdulo
requiere de los siguientes elementos para ser probado:
Un mdulo impulsor, que transmite o impulsa los datos de prueba al mdulo y
muestra los resultados de dichos casos de prueba.
Uno o ms mdulos ficticios que simulan la funcin de cada mdulo subordinado
llamado por el mdulo que se va a probar.
Despus de probar cada mdulo por separado, se ensamblan todos ellos
de una sola vez para formar el programa completo y probarlo en conjunto. La
119
integracin no incremental es el nico caso en el que las pruebas de unidad y las
de integracin estn totalmente separadas.
6.3.3 Prueba del sistema
La prueba del sistema es el proceso de prueba de un sistema integrado de
hardware y software para comprobar si cumple los requisitos especificados, es
decir: Cumplimiento de todos los requisitos funcionales, considerando el producto
software fin al al completo, en un entorno de sistema, El funcionamiento y
rendimiento en las interfaces hardware, software, de usuario y de operador,
Adecuacin de la documentacin de usuario, Ejecucin y rendimiento en
condiciones lmite y de sobrecarga.
Los casos para la prueba del sistema tienen tres fuentes principales para su
diseo: Casos basados en los requisitos gracias a tcnicas de caja negra
aplicadas a las especificaciones, Casos necesarios para probar el rendimiento del
sistema y de su capacidad funcional (pruebas de volumen de datos, de lmites de
procesamiento, etc.), Casos basados en el diseo de alto nivel aplicando tcnicas
de caja blanca aplicadas a los flujos de datos de alto nivel (por ejemplo, de los
diagramas de flujo de datos).
6.3.4 Prueba de aceptacin
El objetivo de esta prueba es comprobar si el producto est listo para ser
implantado para el uso operativo en el entorno del usuario. Si la prueba del
sistema determin la capacidad real del sistema y permiti a la organizacin de
desarrollo tener confianza en que estaba listo para su funcionamiento, la prueba
de aceptacin es la prueba planificacda y organizada formalmente para determinar
si se cumplen los requisitos de aceptacin marcados por el cliente.
Las caracteristicas principales de esta prueba son las siguientes:
Participacin del usuario, se enfoca hacia la prueba de los requisitos de usuario
especificados, es la fase final del proceso para crear una confianza en que el
producto es el apropiado para su uso en explotacin.
Las recomendaciones generales que pueden darse para la prueba de
aceptacin son las siguientes: Debe contarse con criterios de aceptacin
previamente aprobados por el usuario, No hay que olvidar validar tambin la
documentacin y los procedimentos de uso, Las pruebas se deben realizar en el
entorno en el que se utilizar el sistema.
Si se trata de un sistema contratado, la prueba se realiza bajo control de la
organizacin de desarrollo en el entorno real de trabajo ayudando al usuario
(prueba alfa). En el caso de productos de inters general, se entregan versiones
(versiones beta) a usuarios de confianza, sin control directo, que informarn de la
opinin que les merece la aplicacin.
120
6.3.5 Prueba de validacin y verificacin
Al conjunto de actividades que aseguran que el software implementa
correctamente una funcin especfica se denomina Verificacin. La Validacin se
refiere a un conjunto diferente de actividades que aseguran que el software
construido se ajusta a los requisitos y necesidades del cliente.
La definicin de Verificacin y Validacin envuelve lo que se conoce como
calidad del software, en donde los mtodos de anlisis, de diseo y de
implementacin actan para mejorar la calidad al proporcionar tcnicas continuas
y resultados predecibles. Las revisiones tcnicas formales de inspeccin ayudan a
asegurar la calidad la calidad de los productos, a lo largo del proceso la medicin y
el control se aplican sobre cada elemento de una configuracin del software. La
prueba constituye un elemento importante para evaluar la calidad y de descubrir
los errores. Cabe mencionar que la prueba no se debe contemplar como una red
de seguridad. La aplicacin adecuada de los mtodos y de las herramientas, las
revisiones tcnicas formales efectivas y una slida gestin y medida, conducen a
la calidad, que se confirma durante la prueba.
Es importante mencionar que la validacin y verificacin abarcan un amplio
rango de la calidad del software que incluyen revisiones tcnicas formales,
auditoras de configuracin y calidad, supervisin de rendimiento, simulacin,
estudio de viabilidad, revisin de la documentacin, revisin de la base de datos,
anlisis de algoritmos, pruebas de desarrollo, prueba de calificacin y prueba de
instalacin.
La prueba de validacin se logra cuando las expectativas razonables del
cliente se cumplen, en donde incluyen la especificacin de requisitos, documentos
en donde se describen los atributos del software visibles para el usuario, esta
informacin forma la base del enfoque a la prueba de validacin. El procedimiento
de prueba estar diseado para asegurar que se satisfacen los requisitos
funcionales, que se alcanzan todos los requisitos de rendimiento, que la
documentacin es correcta y que se alcanzan otros requisitos tales como
portabilidad, compatibilidad, recuperacin de errores, facilidad de mantenimiento,
entre otros.
6.3.6 Prueba del sistema
La prueba del sistema tiene la finalidad de verificar que se hayan integrado
correctamente cada uno de los elementos del sistema. Comprende las siguientes
pruebas:
6.3.6.1 Prueba de Recuperacin: La prueba de recuperacin es una prueba que
se hace al sistema forzando a que produzca fallas de software de muchas
maneras y verificando que la recuperacin se lleve a cabo, ya sea
121
automticamente o manual, tomando en cuenta los recursos que se requieran
para efectuar la recuperacin.
6.3.6.2 Prueba de Seguridad: La prueba de seguridad intenta verificar la
aplicacin de los mecanismos de proteccin incorporados en el sistema. Durante
la prueba el encargado de la prueba desempea el papel de intruso tratando de
violar la seguridad del sistema, intentando obtener las claves de acceso por
cualquier medio externo; debe bloquear el sistema, negando as el servicio a otras
personas adems de producir errores a propsito en el sistema; o debe curiosear
los datos pblicos intentando encontrar una clave de acceso al sistema.
6.3.6.3 Prueba de Resistencia: La prueba de resistencia est diseada para
enfrentar a los programas en situaciones anormales, es decir ejecutar el sistema
en forma que demande recursos en cantidad, frecuencia o volmenes anormales.
El encargado de la prueba debe intentar colapsar el sistema y para lograrlo se
puede tomar en consideracin lo siguiente: Disear pruebas especiales que
generen 10 o ms interrupciones por segundo, Incrementar las frecuencias de
datos de entrada en un orden de magnitud con el fin de comprobar como
responden las funciones de entrada, Ejecutar casos de prueba que requieran al
mximo de memoria o de espacio en disco, Disear casos de prueba que
produzcan excesivas bsquedas de datos almacenados en disco.
6.3.7 Depuracin
La depuracin aparece como resultado de una prueba efectiva, es decir,
cuando en un caso de prueba se encuentra un error, la depuracin es el proceso
que resulta en la eliminacin de un error. Se debe tomar en cuenta que la
depuracin no es una tcnica de prueba, aunque siempre se da como
consecuencia de la prueba. En la siguiente figura se muestra que el proceso de
depuracin comienza en los casos de prueba, se evalan los resultados y resulta
una falta de correspondencia entre los esperados y los reales, el proceso de
depuracin intenta hacer corresponder el sistema con una causa, llevando as a la
correccin del error.
122
Figura 22: Depuracin de errores
La depuracin tiene como objetivo principal encontrar y corregir la causa de
un error en el software, existen 3 enfoques que se pueden proponer en la
depuracin:
La categora de depuracin "eliminacin de causas" se manifiesta mediante
induccin o deduccin. Los datos relacionados con la ocurrencia del error se
organizan para llegar a las posibles causas; se desarrolla una lista de las causas y
se llevan a cabo las pruebas para eliminar cada una.
La categora de depuracin por "fuerza bruta" es la categora
probablemente la ms comn y la menos eficiente en el momento de aislar la
causa del error del software en donde se confa que en algn lugar de la gran
cantidad de informacin producida nos puede llevar finalmente al xito, lo ms
frecuente es que se desperdicie tiempo y esfuerzo.
La vuelta atrs es el enfoque ms normal para la depuracin, que se puede
usar con gran xito en programas pequeos. Partiendo de donde se detecta el
error hacia atrs en el cdigo fuente hasta llegar a la posicin del error.
6.4 LECCIN 4: PRUEBA DE SOFTWARE PARA OBJETOS
El software construido a partir del modelo orientado a objetos tambin
requiere ser sometido a pruebas con el propsito de garantizar su calidad. En
trminos generales, se puede decir que los dos enfoques ms representativos en
materia de pruebas, de caja blanca y de caja negra, son aplicables al software
orientado a objetos en cierta medida. Sin embargo, existen algunas caractersticas
123
del software orientado a objetos que generan problemas adicionales no cubiertos
por las tcnicas tradicionales de prueba.
La unidad bsica para la prueba de software orientado a objetos es la clase.
A pesar de ello, cuando se prueba al software orientado a objetos, no es posible
realizar una prueba para una clase por s misma, sino que hay que realizarla para
una instancia de sta, es decir para un objeto.
Una caracterstica importante del enfoque orientado a objetos es la
encapsulacin. Un objeto encapsula su estado y sus funciones asociadas. La
abstraccin, concepto que define la capacidad de solo destacar las caractersticas
esenciales de un objeto de tal forma que se puede separar su comportamiento
esencial de su implementacin, va estrechamente ligada con la encapsulacin.
El ocultar todos los detalles del objeto que no contribuyen a sus
caractersticas esenciales, por ejemplo su estructura y la implementacin de sus
mtodos, hace que parte de un objeto sea inaccesible para el mundo.
Naturalmente, esto obstaculiza la eficiencia de las pruebas, ya que para realizarlas
se requiere monitorear el estado de un objeto. Esto es difcil de realizar con
caractersticas como la encapsulacin y la abstraccin, pues la dificultad de
visualizar el estado interno del objeto impide consultar informacin que podra
requerirse para el desarrollo de la prueba.
La herencia es otra de las caractersticas que han venido a facilitar en gran
medida el desarrollo de sistemas orientados a objetos. Puede pensarse que esto
apoya la prevencin de fallas al construir software. Desgraciadamente, se ha
comprobado que mediante esta prctica, se tienen muchas posibilidades de
cometer errores, porque generalmente los elementos heredados son sometidos a
algn tipo de refinamiento o redefinicin y en algunos casos eliminacin de
componentes. Todas estas situaciones hacen pensar que realizar una prueba a
los mtodos heredados debe ser una regla ms que una excepcin.
La herencia en cierta medida trae como consecuencia reuso, lo que genera
una interrogante con respecto a la formulacin de las pruebas: las subclases de
una clase que ya ha sido probada, deben de ser probadas nuevamente. Si la
respuesta es s, se habla de diferentes niveles de herencia lo que incrementa el
nmero de pruebas a realizar.
Otro aspecto que determina la dificultad de las pruebas que se realizan al
software orientado a objetos es el polimorfismo. Cada vez que se realiza una
instancia diferente de un objeto como producto del polimorfismo en los mtodos,
se requiere una prueba separada. Realizar una prueba separada para cada una
de la formas de un mtodo es una tarea difcil, la complejidad y el tiempo
requerido crece considerablemente cuando se tienen que definir todos los posibles
errores y obstculos que pueden presentarse.
124
En los sistemas orientados a objetos, el flujo de control se lleva a cabo
mediante el paso de mensajes entre objetos. Cuando un mensaje es enviado de
un objeto u otro, la consecuencia es, generalmente, que el objeto receptor ejecute
alguna operacin para examinar o alterar su estado. El paso de mensajes es un
punto fundamental al realizar la prueba.
6.4.1 Mtodos de prueba de software orientado a objetos.
Muchas de las generalidades de los mtodos de prueba tradicionales han
sido adaptadas considerando las caractersticas del modelo orientado a objetos,
con el propsito de que puedan ser aplicables en este nuevo contexto.
Actualmente, existen muy pocas investigaciones sobre el estudio de prueba de
software orientado a objetos; ya que el rea de prueba de software es bastante
compleja y dentro de este marco de objetos existe una carencia de mtodos
robustos para garantizar la realizacin de las pruebas de forma eficaz. En este
panorama se presenta el estado actual en cuanto a prueba de software orientado
a objetos en trminos del nivel de prueba.
6.4.1.1 Pruebas de unidad
En el software orientado a objetos la menor unidad a considerar para
realizar una prueba es la clase. La prueba de clases en el mbito de software
Orientado a Objetos es equivalente a la prueba de unidad realizada al software
tradicional. Esta prueba est fundamentalmente dirigida a las operaciones
encapsuladas por la clase, as como al estado y comportamiento del objeto que se
implementa en ella. El nfasis de la prueba de unidad es verificar que esta
pequea unidad trabaje correctamente en forma aislada, antes de proceder a
integrarla en el sistema.
Los mtodos contenidos en una clase pueden ser muchos y una operacin
en particular de ese conjunto, a consecuencia de la herencia, puede existir como
parte de varias clases diferentes. Por lo tanto el significado de prueba de unidad
cambia en muchos sentidos y es importante disearla bajo ciertas
consideraciones.
Se han propuesto estrategias para llevar a cabo las pruebas de unidad
considerando aspectos como el orden en que los mtodos son sometidos a la
prueba, el orden en que una jerarqua de clases puede ser probada, ejercitar el
flujo de datos o bien el anlisis del estado del objeto.
Los aspectos que deben considerarse para construir casos de prueba para
una clase deben verificar que esta proporcione los servicios que promete, que
responda correctamente a las condiciones esperadas y, ms an, ante las
inesperadas. Aspectos adicionales pueden el verificar si la clase contiene y
permite disponer de todas las funciones asociadas a ella o que cada mtodo de la
clase ejecute su responsabilidad especificada. Algunas de las tcnicas ms
populares para realizar pruebas de unidad se muestran en la siguiente tabla:
125
Prueba Definicin
Pruebas estructurales Si se tiene la disponibilidad de cdigo fuente, pueden realizarse
pruebas estructurales a las unidades sometidas a la prueba. Las
acciones de esta actividad pueden disearse con el propsito de
ejercitar todas las rutas del cdigo, las condiciones establecidas
o bien las ciclos definidos en el programa.
Prueba de valores limite Mediante esta tcnica se prueba la unidad bajo situaciones
inusuales o extremas, con el propsito verificar cmo son
manejadas por el software. Para ello, los casos de prueba
suministrados son diseados considerando valores frontera, es
decir los valores mnimo y mximo que la unidad puede aceptar,
as como tambin aquellos valores cercanos a las fronteras
identificadas.
Prueba basada en estados Para esta tcnica, se generarn casos de prueba para un
contexto en donde una clase se modela como una mquina de
estados con secuencias de transiciones, con esto se pretende
analizar el estado de los objetos de acuerdo a su
comportamiento. Una vez que se ha establecido un modelo de
estados con base en los atributos del objeto, se consideran en la
prueba los mtodos necesarios para poder observar los cambios
de estado. La aplicacin de esta tcnica permite observar alguna
de las siguientes situaciones: se produce un cambio a un estado
correcto, se produce cambio a un estado incorrecto, no hay
cambio de estado, se produce un estado indefinido correcto o
bin, se produce un estado indefinido incorrecto.
Prueba incremental La prueba incremental dirige su atencin a las subclases
generadas como consecuencia de la herencia, siendo la clase
padre una clase previamente probada. Aunque existen
situaciones en las que ste tipo de pruebas se descarta, se
pueden identificar algunas en las que no estaran de ms:
cuando se han agregado o modificado propiedades y/o mtodos,
cuando existen propiedades y mtodos que se han heredado y
no se han alterado, pero que realizan algn tipo de interaccin
con elementos nuevos o modificados.
Tabla 35: Pruebas de Unidad de Software Orientado a Objetos
6.4.1.2 Pruebas de integracin.
Cuando se aplican pruebas de integracin al software orientado a objetos,
se pretende demostrar que las unidades que ya han sido sometidas a un proceso
de prueba y funcionan correctamente, lo hacen de igual forma cuando interactan
y se integran con otras unidades del sistema. Prcticamente, el trabajo de esta
prueba se concentra en la interaccin de mtodos en diferentes unidades.
Existe una coincidencia en los dos enfoques para realizar este tipo de
pruebas: el basado en hilos y el basado en uso. En el primero, pretende que todas
las clases respondan a sencillas entradas externas, provenientes de otra unidad.
De esta forma, se realizan casos de prueba para cada clase en la unidad, con lo
cual un hilo de este conjunto se ejercita.En el enfoque basado en uso, se realizan
pruebas para clases las cuales usan servicios de otras clases. En la siguiente
tabla se presentan algunos mtodos para realizar pruebas de integracin:
126
Prueba Definicin
Mtodo de Caminos de
Mensajes
Este mtodo se concentra principalmente en probar aquellos
caminos que se generan por un evento de entrada y terminan
con un evento de salida
El mtodo de Overbek En este mtodo se prueban las clases por pares, donde una
hace el papel de cliente y otra el de servidor, establecindose
para estas dos conjuntos de pruebas. El primer conjunto, son
pruebas orientadas a verificar si los mensajes de entrada y de
salida generados son correctos; es decir si se usa correctamente
cualquier clase servidora y si todas las secuencias de
operaciones son correctas. En el segundo conjunto se verifica
adems de lo anterior, si la clase cliente siempre satisface las
precondiciones de la clase servidora, as como tambin si
satisface las salidas esperadas por la clase servidora.
El mtodo de Kung Este mtodo emplea una estrategia de ingeniera en reversa
sobre el cdigo de las unidades con el propsito de generar un
diagrama de relaciones entre objetos. A partir de este diagrama
se propone un orden para las pruebas que minimiza el uso de
cabos. El diagrama se convierte en un grafo acclico, que puede
contener varios clusters de objetos y los ordenan
topolgicamente. Su mtodo involucra las etapas de pruebas de
unidad y de integracin y puede usarse tambin para pruebas de
regresin.
Tabla 36: Pruebas de Integracin de Software Orientado a Objetos
6.4.1.3 Pruebas de sistema.
Las pruebas de unidad se concentran en verificar si las funcionalidades
descritas en las especificaciones o en los requisitos iniciales corresponden a las
que se presentan en el producto final. En esta rea, al igual que la de pruebas de
integracin, se han generado pocos trabajos, por lo que se emplean muchos de
los mtodos tradicionales.
Prueba Definicin
Prueba de funcin La prueba de funcin comnmente es llevada a cabo por el
grupo de personas que desarrollaron el producto. Este enfoque
se orienta a confirmar que la aplicacin alcanza los
requerimientos y la funcionalidad especificadas por el usuario
Pruebas de aceptacin En este tipo de pruebas, versiones que an no han sido
liberadas en el mercado, son ofrecidas a ciertos grupos de
usuarios con el propsito de que las utilicen. El propsito de sto
es que los usuarios reporten defectos que pudieran presentarse.
Prueba bajo stress Para realizar esta prueba, el sistema somete a condiciones
extremas de trabajo, como pueden ser un alto volumen de
transacciones o un gran nmero de usuarios. Aplicando este
enfoque, se puede verificar si el sistema se comporta como se
espera an ante este tipo de escenarios.
Tabla 37: Pruebas de Sistema de Software Orientado a Objetos
127
6.5 LECCIN 5: PRUEBA DE SOFTWARE BASADO EN COMPONENTES.
La construccin de software a partir de componentes es una prctica
relativamente nueva, por lo que no es extrao que sea escasa la existencia de
trabajos generados al respecto. Puesto que el desarrollo basado en componentes
presenta algunas similitudes con el enfoque orientado a objetos, para un
componente pueden ser aplicables algunas de sus consideraciones, incluso en
materia de prueba. Aspectos como la herencia, encapsulacin, polimorfismo, liga
dinmica o mecanismos de comunicacin, son comunes entre ambos modelos. Es
evidente que para hacer las pruebas de componentes ms robustas, ser
necesario considerar las caractersticas propias del enfoque de componentes.
En la mayora de los casos, los criterios de prueba de caja negra son los
ms aplicados a los componentes, puesto que la disponibilidad del cdigo fuente
es nula en la mayora de las veces. Debido a que un componente es una unidad
concreta, con una funcin bien definida, no basta realizar pruebas para su
evaluacin; de igual forma se requieren procesos de prueba para su seleccin y
para su integracin.
Durante la etapa de construccin de un componente, el desarrollador puede
aplicar las tcnicas de prueba de unidad y de integracin tradicionales del modelo
Orientado a Objetos, sin embargo en lo que respecta a la seleccin y evaluacin,
considerar el punto vista del usuario es un aspecto vital para la realizacin de la
prueba. Finalmente en el marco de pruebas de integracin, consideraciones como
la arquitectura de la aplicacin, el software intermediario y los modelos de los
componentes, deben agregarse a los criterios de evaluacin.
Con el propsito de organizar algunas de las estrategias de prueba de
componentes ms comunes, en las siguientes secciones se presenta una
descripcin de las mismas en los trminos que se presentaron para el enfoque
orientado a objetos, de nivel unidad y nivel de integracin.
6.5.1 Pruebas de unidad.
Aunque la realizacin de pruebas de unidad es una actividad que en algn
momento es llevada a cabo por el desarrollador, existe un marco de trabajo
adicional a considerar: el de la persona que se interesa en el componente con el
fin de integrarlo en sus sistemas.
Actualmente son pocos los trabajos en materia de pruebas de unidad para
componentes, dos sobresalientes en este ramo son el proyecto Trusted
Components y el Proyecto Kimera, aunque este ltimo no esta dirigido totalmente
a componentes, sino a la seguridad de las mquinas virtuales de Java cada vez
que se carga una clase.
Trusted Components, es un proyecto de investigacin paras asistir a la
industria de construccin de software mediante libreras probadas de
128
componentes. Las pruebas que se aplican a los componentes se construyen bajo
la combinacin de varios enfoques como diseo por contrato, como pruebas
matemticas, mtricas, validacin exhaustiva en proyectos prcticos y manejo de
cambios rigurosos.
6.5.2 Pruebas de integracin.
Si las pruebas de nivel de unidad para componentes muestran severas carencias,
en nivel de integracin, al igual que en otros enfoques de desarrollo, las carencias
son an ms notables. Sin embargo, existen coincidencias en cuanto a las
problemticas comunes al integrar componentes:
6.5.2.1 El volumen y la lentitud: Cuando se utilizan componentes dentro de un
sistema, no siempre se utilizan todas sus capacidades, lo que hace que cierta
parte del cdigo no sea necesario. Este problema se agrava cuando se tienen
sistemas grandes, afectndose as su rendimiento.
6.5.2.2 Los mecanismos de comunicacin utilizados: Se han presentado
algunas contrariedades e inconsistencias al utilizar dentro de un mismo sistema
varios mecanismos de comunicacin como eventos, mensajes o bien el paso de
parmetros.
129
GLOSARIO DE TRMINOS
Arquitectura de software: Es un diseo global de una aplicacin que incluye su
descomposicin en partes.
Calidad: La calidad es herramienta bsica para una propiedad inherente de
cualquier cosa que permite que esta sea comparada con cualquier otra de su
misma especie.
Calidad de Software: Caractersticas propias del software que se desea controlar
y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se
degradan fsicamente, sino que se desarrolla; El software puede tener errores,
incidencias pero no son similares a lo que cualquier equipo de carcter fsico.
Calidad externa: La magnitud de satisfaccin de un producto con relacin a
necesidades establecidas cuando es usado bajo condiciones especficas.
Calidad interna: El total de atributos de un producto que determina su capacidad
para satisfacer necesidades establecidas cuando es usado bajo condiciones
especficas.
Componente Software: Son todos aquellos recursos desarrollados para un fin
concreto y que puede formar solo o junto con otros, un entorno funcional requerido
por cualquier proceso predefinido.
Documentacin de pruebas del software: Documento que especifica todos los
aspectos del proceso de pruebas para una aplicacin.
Estndar: Base o modelo en el que todo el mundo se ha puesto de acuerdo.
Gestin de Calidad de Software: Es un conjunto de actividades de la funcin
general de la Direccin que determina la calidad, los objetivos y las
responsabilidades. Se basa en la determinacin y aplicacin de las polticas de
calidad de la empresa.
ISO: (Internacional Standards Organization) Organizacin Internacional de
estndares fundada en 1946, con sede principal en Ginebra, ISO establece o fija
estndares internacionales. Se ocupa de todos los campos, excepto la electricidad
y la electrnica, que se rigen por la Internacional Electrotechnical Comisin (IEC),
tambin en Ginebra.
ISO 9001: Es un conjunto de normas sobre la calidad y la gestin.
ISO/IEC 9126: Es un estndar internacional para la evaluacin del software. Est
supervisado por el proyecto SQuaRE, ISO 25000:2005, el cul sigue los mismos
130
conceptos. El estndar est dividido en cuatro partes las cuales dirigen,
respectivamente, lo siguiente: modelo de calidad, mtricas externas, mtricas
internas y calidad en las mtricas de uso.
ISO/IEC 14598: Norma para la evaluacin del producto software. Esta norma
comprende las siguientes seis partes que especifican el proceso a seguir para
evaluar software: ISO/IEC 14598-1 Visin general; ISO/IEC 14598-2 Planificacin
y Gestin; SO/IEC 14598-3 Procedimiento para desarrolladores; ISO/IEC 14598-4
Procedimiento para compradores; ISO/IEC 14598-5, Procedimiento para
evaluadores; ISO/IEC 14598-6 Documentacin de los mdulos de evaluacin.
ISO/IEC 25000: Especificacin de requerimientos de calidad del software y
evaluacin de la calidad del software, soportada por el proceso de medicin de
calidad del software.
Mtrica: Una escala de medicin y un mtodo usado para la medicin.
Modelo: Un modelo es una estructura conceptual que sugiere un marco de ideas
para un conjunto de descripciones que de otra manera no podran ser
sistematizadas.
Proceso: El proceso de ingeniera de software se define como un conjunto de
etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso,
la obtencin de un producto de software de calidad.
Prueba: Actividad durante la cual los desarrolladores encuentran diferencias entre
el sistema y sus modelos ejecutando el sistema (o partes de l) con conjuntos de
datos de entrada de prueba.
Prueba de Caja Blanca: Prueba que se enfoca en la estructura interna de un
componente.
Prueba de Caja Negra: Prueba que se enfoca en el comportamiento de
entrada/salida de un componente sin considerar su implementacin.
Pruebas del sistema: Proceso de probar una aplicacin completa (no sus partes).
131
Cavano, J.P., McCall, J.A., A Framework for the Measurement of Software Quality,
Proc. of the ACM Software Quality Assurance Workshop, pp. 133-139, Nov. 1978.
De Domingo, J. y Arranz, A., Calidad y mejora continua, Ed Donostiarra. 1997.
G. Heineman and W. Council (Eds.). Component-Based Software Engineering
Putting the Pieces Together, Addison-Wesley, 2001.
ISO/IEC 14598-1:1999. Information technology software product evaluation - part
1: General overview. International Standard ISO/IEC 14598-1, ISO, April 1999.
ISO/IEC 9126-1:2001. Software engineering product quality part 1: Quality model.
International Standard ISO/IEC 9126-1, International Standard Organization, June
2001.
James M. Bieman and Linda M. Ott. Measuring functional cohesion. Technical
Report CS-93-109, Fort Collins, CO, USA, 24 June 1993.
James A. McCall, Paul K. Richards, and Gene F. Walters. Factors in software
quality, volume III: Preliminary handbook on software quality for an acquisition
manager. Technical Report RADC-TR-77-369, vol. III, Hanscom AFB, MA 01731,
1977.
MEYER, Bertrand. Construccin de software orientado a objetos. Segunda
edicin. Madrid. 1999. Prentice Hall.
Miller, E., Howden, W. E., Tutorial, Software Testing & Validation Techniques, 2a
ed., IEEE Computer Society Press, 1981.
Murine, G.E. , Integrating software quality metrics with software QA, Quality
Progress vol.21, no.11; pp. 38-43; Nov. 1988.
Norman E. Fenton and Shari Lawrence Pfleeger. Software Metrics: A Rigorous &
Practical Approach. Brooks/Cole, 2 edition, January 1998.
Piatini, Mario y col. Analisis y Diseo de Aplicaciones Informticas de Gestin, Una
Perspectiva de Ingeniera de Software, Alfaomega 2004. Pginas 109 164.
132
PIATTINI, Mario. VILLALBA, Jose y otros. Mantenimiento del software: modelos,
tcnicas y mtodos para la gestin del cambio. Editorial Alfaomega-Rama.
Wesley. 2001
T.J. McCabe. A software complexity measure. IEEE Transactions on Software
Engineering, 2(4):308320, 1976.
http://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.php
http://www.ii.uam.es/~jlara/docencia/is1.2003/recursos.html
http://www.bvs.sld.cu/revistas/aci/vol3_3_95/aci05395.htm Oscar M. Fernndez
Carrasco1, Delba Garca Len2 y Alfa Beltrn Benavides3
http://www.lcc.uma.es/~av/misConfs/Calidad%20de%20Componentes%20CR
%20Junio%202004.ppt#345,2,Agenda
http://www.willydev.net/descargas/articulos/general/CalidadSoftware.pdf
http://www.pcm.gob.pe/portal_ongei/banconormas1.asp
http://www.iso.org
http://www.bulltek.com/Spanish_Site/ISO%209000%20INTRODUCCION/TL
%209000%20Spanish/ISO9000-3_Spanish/iso9000-3_spanish.html
133
UNIDAD 3
Nombre de la Unidad EVALUACIN DE SOFTWARE
Introduccin La evaluacin de software en la actualidad es uno de los
elementos que debe ser tenido en cuenta en el proceso
de construccin de un producto software, como tambin,
en el producto terminado. La evaluacin del producto
software es la garanta que debe brindar el fabricante de
que su producto cumple con las normas de calidad
internacionales para estos productos tan especiales.
Adems la evaluacin de productos software contribuye al
mejoramiento de los procesos en la empresa, ya que,
permite la verificacin y validacis de todas y cada una de
las caractersticas del producto no importando si se trate
de una aplicacin pequea o compleja.
En este captulo se tratar de identificar la metodologa
tcnica para la evaluacin de software, las metodologias
de evaluacin de la arquitectura y algunas de las
aplicaciones de la evaluacin de software.
Justificacin Actualmente cada uno de los productos de software que
salen comercialmente al mercado deben garantizar al
menos el cumplimiento de normas estndares de calidad
que permitan a los usuarios determinar el grado de
eficiencia, eficacia y confiabilidad de estos productos. Y
una de las funciones encomendadas a los ingenieros es la
de evaluar los productos software y determinar cual de
ellos es el ms apropiado para la organizacin o para uno
de los procesos dentro de ella.
Por lo tanto es importante que los futuros profesionales
adquieran el conocimiento y las habilidades para cumplir
cabalmente con sus funciones dentro de la organizacin.
Intencionalidades
Formativas
- El estudiante conoce y aplica la norma de calidad
ISO/IEC 9126 para la evaluacin de software
- El estudiante esta en capacidad de relacionar los
conceptos de evaluacin, caractersticas, metricas,
pruebas y llevarlos a la prctica
- El estudiante conoce las diferentes metodoligias para la
evaluacin del proceso y producto software
- El estudiante adquire nuevos conocimientos y puede
transferirlos aplicandolos a su entorno laboral llevndolos
a la prctica
Denominacin de
captulos
CAPTULO 7. METODOLOGA TCNICA PARA LA
EVALUACIN DE SOFTWARE
Denominacin de Leccin 1. Modelos Tradicionales para la Evaluacin de la
134
lecciones Calidad del software
Denominacin de
lecciones
Leccin 2. Norma de Evaluacin ISO/IEC 9126
Denominacin de
lecciones
Leccin 3. Proceso de Evaluacin de Software
Denominacin de
lecciones
Leccin 4. Mtricas Externas Basados en ISO/IEC 9126
Denominacin de
lecciones
Leccin 5. Mtricas Internas Basados en ISO/IEC 9126
Denominacin de
captulos
CAPTULO 8: METODOLOGAS DE EVALUACIN
PARA ARQUITECTURA DEL SOFTWARE
Denominacin de
lecciones
Leccin 1. Evaluacin de la Arquitectura del software
Denominacin de
lecciones
Leccin 2. Tcnicas de Evaluacin de la arquitectura del
software
Denominacin de
lecciones
Leccin 3. Mtodos de Evaluacin de la arquitectura de
software
Denominacin de
lecciones
Leccin 4. Mtodos de Evaluacin de Arquitectura de un
Atributo Especfico
Denominacin de
lecciones
Leccin 5. Mtodo de evaluacin de la Arquitectura de
Software MECABIT
Denominacin de
captulos
CAPTULO 9: APLICACIONES DE LA EVALUACIN DE
SOFTWARE
Denominacin de
lecciones
Leccin 1. Metodologa para la Evaluacin de la Calidad
en Modelos UML
Denominacin de
lecciones
Leccin 2. Implementacin de la Metodologa con SPEM y
EPFC
Denominacin de
lecciones
Leccin 3. Evaluacin de Software Educativo Multimedia
Denominacin de
lecciones
Leccin 4. Modelos de Evaluacin de Software Educativo
Multimedia
Denominacin de
lecciones
Leccin 5. Plantillas de Evaluacin de Software
Multimedia
135
UNIDAD 3
EVALUACIN DE
SOFTWARE
136
CAPITULO 7
MTODOLOGA TCNICA DE
EVALUACIN DE SOFTWARE
137
INTRODUCCIN
La metodologa para evaluacin tcnica de software considera una serie de
pasos que deben ser tenidos en cuenta cuando se trata de realizar este proceso
tan complejo, por eso es necesario que se conozcan y se haga el seguimientos de
ellos para realizar una buena evaluacin del producto.
Dentro de los estndares de calidad ms utilizados esta el estndar definido
por la ISO/IEC 9126 el cual toma en consideracin la evaluacin de las
caractersticas internas, externas y de calidad en uso. A su vez cada una de las
caractersticas se divide en subcaractersticas que se pueden definir y a las cuales
se les puede establecer unas mtricas, pruebas y escalas de medicin que
permitan establecer una valoracin para el producto en la caracerstica que haya
sido elegida.
En este captulo se tratar el tema de algunas de las metodologias
existentes para la evaluacin de software, dentro de ella se ha elegido la norma
ISO/IEC y de ella se har el seguiemiento hasta llegar a definir las mtricas que
son la base para realizar el proceso de evaluacin de software.
138
7.1 LECCIN 1: MODELOS TRADICIONALES DE EVALUACIN DE LA
Cuando se trata de evaluar la calidad de un producto software hay que
tener en cuenta que la calidad es un concepto muy complejo y que, adems,
depende mucho del punto de vista que se adopte. La evaluacin se basa en la
descomposicin del concepto genrico de calidad en propiedades ms sencillas
de medir y evaluar. Este tipo de descomposicin recibe el nombre de modelo de
calidad. Los modelos de calidad ms conocidos y utilizados han sido los de
Boehm y McCall.
El modelo de McCall se basa en descomponer el concepto de calidad en
tres usos o capacidades importantes para un producto software desde el punto de
vista del usuario: La capacidad de operacin, la capacidad para ser modificado y
la capacidad de transicin o de adaptacin a otros entornos.
Cada capacidad o uso se descompone en una serie de factores que
determinan la calidad en cada una de las capacidades antes mencionadas. Por lo
tanto, existen una serie de factores que se puede evaluar ms fcilmente que las
capacidades para tener una visin apropiada de la calidad. Estos factores son
conceptos de alto nivel de abstraccin, a continuacin se ofrecen las definiciones
de estos factores:
Facilidad de uso: Grado de esfuerzo necesario para aprender a utilizar el
software, preparar la entrada de datos e interpretar la salida del mismo.
Integridad: Grado en que se puede controlar el acceso del personal al software o
a los datos que utiliza.
Eficiencia: Necesidades de recursos hardware y software requeridos por el
software evaluado para realizar sus funciones.
Fiabilidad: Grado o probabilidad de que el software no falle al realizar sus
funciones.
Correccin: Grado en que el software cumple sus especificaciones.
Flexibilidad: Facilidad o grado de esfuerzo necesario para modificar el software
en funcionamiento.
Facilidad de Prueba: Esfuerzo necesario (o facilidad) para probar el software de
modo que se tenga un cierto grado de confianza en que realiza adecuadamente
sus funciones.
Facilidad de Manteniemiento: Facilidad o grado de esfuerzo para mantener
operativo el software mediante la correccin o depuracin de los problemas que
puedan aparecer durante su funcionamiento.
139
Transportabilidad: Facilidad o grado de esfuerzo necesario para transportar o
migrar el software de un entorno de operacin a otro.
Capacidad de reutilizacin: Capacidad o grado de esfuerzo para que el software
o alguna de sus partes puedan ser utilizadas en otros desarrollos de software.
Capacidad de Interoperacin: Capacidad o grado de esfuerzo necesario para
que el software o un sistema puedan operar conjuntamente con otros sistemas o
aplicaciones de software.
Cada factor deteminante de la calidad se descompone, a su vez, en una
serie de criterios o propiedades que determinan su calidad, Los factores se
suponen conceptos de alto nivel que, como la propiedad genrica de la calidad,
son demasiado abstractos para ser significativos o poder ser medidos o evaluados
directamente. Por lo tanto, existen una serie de criterios de calidad de ms bajo
nivel osea ms detallados. Estas propiedades elementales o criterios son
propiedades internas del software, que no dependen en su apreciacin de quin
est observndolas y que los desarrolladores de software consideran que influyen
en la calidad, algunos de estos son:
Facilidad de Operacin: Propiedades del software que determinan la facilidad de
las operaciones y de los procedimientos relativos a la explotacin del software.
Facilidad de Comunicacin: Propiedades del software que proporciona1 eficacia
y facilidad en las comunicaciones.
Facilidad de Formacin o Aprendizaje: Propiedades del software que
proporcionan al usuario informacin de operaciones reales o que facilitan la
familiarizacin inicial con el producto.
Control de Accesos: Propiedades del software que proporcionan facilidades para
el control de accesos al software y a los datos que maneja.
Facilidad de Auditoria: Propiedades del software que proporcionan facilidades
para realizar auditoria del software, de los datos empleados o de los resultados
obtenidos.
Efieciencia de ejecucin: Propiedades del software que proporcionan un
consumo mnimo de recursos de procesamiento al realizar sus operaciones.
Eficiencia de Almacenamiento: Propiedades del software que proporcionan unas
necesidades mnimas de memoria para su operacin.
Exactitud o Precisin: Propiedades del software que proporcionan el grado de
precisin requerido para los resultados que hay que obtener.
140
Consistencia: Propiedades del soflware que proporcionan tcnicas y
documentacin uniforme y coherente a las distintas etapas del software.
Tolerancis a Fallos: Propiedades que proporcionan la continuidad del
funcionamiento bajo condiciones no habituales.
Modularidad: Propiedades del software que proporcionan una estructura de
mdulos adecuadamente independientes.
Simplicidad: Propiedades del software que proporcionan la implantacin de
funcioncs de la manera ms comprensible posible.
Complecin: Propiedades del software que proporcionan la implantacin total de
todas las funciones requeridas.
Rastreabilidad o facilidad de Traza: Propiedades del software que proporcionan
una taza o pista reconocible desde los requisitos hasta su implantacin en relacin
a un desarrollo especfico y a un determinado entorno de operaciones.
Autodescripcin: Propiedades del software que proporcionan explicaciones
sobre el desarrollo de cada funcin.
Capacidad de Expansin: Propiedades del software que proporcionan facilidades
para aadir nuevas capacidades funcionales o datos al sistema.
Generalidad: Propiedades del software que proporcionan amplitud a las funciones
realizadas.
Instrumentacin: Propiedades de] software que proporcionan la posibilidad de
observar el comportamiento del software durante su ejecucin.
Independencia entre Sistema y Software: Propiedades del software que
determinan su dependencia de su entorno lgico de trabajo.
Independencia del Hardware: Propiedades del software que determinan su
dependencia de su entorno fsico de trabajo (CPU, dispositivos, etc.).
Normalizacin o Compatibilidad de Comunicaciones: Propiedades del
software que favorecen una fcil intercomunicacin del sistema con otros.
Normalizacin o Compatibilidad de Datos: Propiedades del software que
determinan la posibilidad de utilizacin comn de datos con otros sistemas.
Este tipo de modelos de evaluacin de la calidad han gozado de una gran
aceptacin en el mundo del software. Esto ha motivado que se hayan intentado
establecer como estndares por parte de diversos organismos. As, la norma IEEE
1061 propone un modelo de medicin muy parecido al de McCall denominado
141
modelo factor/criterio/mtrica, y la norma ISO 9126 establece un modelo propio de
calidad cuya base es similar al de McCaIl.
En los aos ochenta, cambi el enfoque de los modelos de evaluacin de la
calidad, ya que se impuls la creacin de modelos particulares para cada empresa
o para cada proyecto en vez de utilizar un mismo modelo para todos los casos, se
implant as, de forma efectiva, el concepto de calidad relativa. En el caso de Gilb,
se propone la creacin de una especificacin de requisitos de calidad para cada
proyecto, que deben escribir conjuntamente el usuario y el analista. Se trata
fundamentalmente de determinar una lista de las caractersticas que definen la
calidad de la aplicacin. Dichas caractersticas pueden ser totalmente originales,
aunque lo ms normal es que se inspiren o se tomen directamente de alguno de
los modelos tradicionales. Las distintas caractersticas se pueden medir mediante
varias subcaractersticas o mtricas detalladas. Para cada una de stas se deben
especificar los siguientes conceptos:
Nombre y definicin de la caracterstica.
Escala o unidades de medicin.
Recogida de datos o prueba.
El peor valor aceptable.
El valor previsto.
El valor ptimo.
El valor del sistema actual.
Comentarios.
En algunos casos, este enfoque de Gilb se ha asociado indirectamente a la
filosofa QFD (Quality Function Deplovrnent: Despliegue de la funcin de la
calidad) que se aplica en el mbito de la gestin de la calidad industrial, aunque
existen trabajos especficos de aplicacin de QFD al software. Por otra parte, el
enfoque de GiIb ha inspirado trabajos posteriores como el del proyecto
COQUAMO (Constructive Quality Model: Modelo Constructivo de la Calidad) que
propone una herramienta automatizada que ayuda a determinar (mediante
plantillas) el modelo de calidad ms apropiado para un proyecto.
Otro enfoque relativista de medicin de la calidad del software es el
representado por el paradigma GQM (Goal-Question-Metric: Objetivo-Pregunta-
Mtrica) propuesto por Basili y Rombach. Aunque se trata de un enfoque general
de la medicin, se trata de un mtodo muy apropiado para evaluar la calidad del
software en cada proyecto. La idea consiste en que toda actividad de medicin
debe estar precedida por la identificacin de un objetivo a lograr, que lleva a
plantearse una serie de interrogantes sobre aspectos ms puntuales de la calidad,
esto llevar, a su vez, a disponer de una serie de mtricas que nos permitan
responderlas. Aunque inicialmente puede parecer poco prctico el uso del modelo
GQM, la reflexin que implica su construccin es valiosa ya que permite aclarar el
concepto de calidad que se persigue en el proyecto.
142
Por ltimo, se debe decir que existe un enfoque ms primitivo de medir la
calidad que se basa en considerarla equivalente a la ausencia de defectos,
entendidos stos como fallos, defectos o errores conocidos. La ventaja de esta
manera de medir es que los datos sobre defectos se pueden obtener fcilmente
slo con mantener un sistema de registro de la informacin generada en el
proyecto a partir de los datos aportados por las tcnicas de deteccin de defectos.
Los informes de las revisiones donde se indican los defectos encontrados, los
resultados de las pruebas del software, las peticiones de cambios que debe
gestionar la gestin de la configuracin, etc. Es muy habitual obtener medidas que
relacionan el nmero de defectos con el tamao del software. As, por ejemplo,
una propuesta tpica de recoleccin de datos incluye:
N de problemas informados.
N de problemas evaluados.
N de problemas reales.
N de problemas abiertos, pendientes de resolucin.
N de problemas cerrados.
Tiempo que permanece un problema abierto.
Tiempo que permanece un problema hasta ser evaluado.
Distribucin de problemas por fase del desarrollo, por prioridad, por categora
(grave, leve, esttico), etc.
Este enfoque de medicin est inspirado en el control estadstico de
procesos aplicado en la industria convencional de fabricacin. Uno de los casos
ms conocidos de aplicacin de este enfoque es el del programa de medicin
aplicado por Grady en Hewlett-Packard. El problema principal de este enfoque es
que la existencia de un defecto no siempre acarrea un problema de calidad en el
software y, por lo tanto, resulta menos riguroso que otros modelos. Sin embargo,
cuenta con la ventaja de que, en una empresa mnimarnente organizada, la
recogida de datos resulta barata y relativamente sencilla.
7.2 LECCIN 2: NORMA DE EVALUACIN ISO/IEC 9126
Esta norma Internacional fue publicada en 1992, la cual es usada para la
evaluacin de la calidad de software, llamado Information technology-Software
product evaluation-Quality characteristics and guidelines for their use; o tambin
conocido como ISO 9126 (o ISO/IEC 9126). Este estndar describe 6
caractersticas generales: Fucionalidad, Confiabilidad, Usabilidad, Eficiencia,
Mantenibilidad, y Portabilidad.
La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software
desde diferentes criterios asociados con adquisicin, requerimientos, desarrollo,
uso, evaluacin, soporte, mantenimiento, aseguramiento de la calidad y auditoria
de software. Los modelos de calidad para el software se describen as:
143
Calidad interna y externa: Especifica 6 caractersticas para calidad interna y
externa, las cuales, estn subdivididas. Estas divisiones se manifiestan
externamente cuando el software es usado como parte de un sistema Informtico,
y son el resultado de atributos internos de software.
Calidad en uso: Calidad en uso es el efecto combinado para el usuario final de
las 6 caractersticas de la calidad interna y externa del software. Especifica 4
caractersticas para la calidad en uso.
Al unir la calidad interna y externa con la calidad en uso se define un
modelo de evaluacin mas completo, se puede pensar que la usabilidad del
modelo de calidad externa e interna pueda ser igual al modelo de calidad en uso,
pero no, la usabilidad es la forma como los profesionales interpretan o asimilan la
funcionabilidad del software y la calidad en uso se puede asumir como la forma
que lo asimila o maneja el usuario final. Si se unen los dos modelos, se puede
definir que los seis indicadores del primer modelo tienen sus atributos y el modelo
de calidad en uso sus 4 indicadores pasaran hacer sus atributos, mirndolo
grficamente quedara asi:
Figura 23: Norma de Evaluacin ISO/IEC 9126
Se establecen categoras para las cualidades de la calidad externa e interna
y calidad en uso del software, teniendo en cuenta estos 7 indicadores
(funcionalidad, confiabilidad, utilidad, eficiencia, capacidad de mantenimiento,
portabilidad y calidad en uso), que se subdividen a su vez en en varios
indicadores; estas se pueden medir por mtrica interna o externa.
144
Figura 24: Evaluacin Interna, externa y Calidad de Uso ISO/IEC 9126
Las definiciones se dan para cada caracterstica y subcaracterstica de
calidad del software que influye en la calidad. Para cada caracterstica y
subcaracterstica, la capacidad del software es determinada por un conjunto de
atributos internos que pueden ser medidos. Las caractersticas y sub
caractersticas se pueden medir externamente por la capacidad del sistema que
contiene el software.
7.2.1 Funcionalidad
Funcionalidad es la capacidad del software de cumplir y proveer las
funciones para satisfacer las necesidades explcitas e implcitas cuando es
utilizado en condiciones especficas. A continuacin se muestra la caracterstica
de Funcionalidad y las subcaractersticas que cubre:
145
Figura 25: Caracterstica de Funcionalidad
La funcionalidad se divide en 5 criterios:
Adecuacin: La capacidad del software para proveer un adecuado conjunto de
funciones que cumplan las tareas y objetivos especificados por el usuario.
Exactitud: La capacidad del software para hacer procesos y entregar los
resultados solicitados con precisin o de forma esperada.
Interoperabilidad: La capacidad del software de interactuar con uno o ms
sistemas especficos.
Seguridad: La capacidad del software para proteger la informacin y los datos de
manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos
para realizar operaciones, y la capacidad de aceptar el acceso a los datos de los
usuarios o sistemas autorizados
Conformidad de la funcionalidad: La capacidad del software de de cumplir los
estndares referentes a la funcionalidad.
7.2.2 Confiabilidad
La confiabilidad es la capacidad del software para asegurar un nivel de
funcionamiento adecuado cuando es utilizando en condiciones especificas. En este
caso al confiabilidad se amplia a sostener un nivel especificado de funcionamiento y
no una funcin requerida.
146
Figura 26: Caracterstica de Confiabilidad
La confiabilidad se divide en 4 criterios:
Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra
errores. Ejemplo, la forma como el software advierte al usuario cuando realiza
operaciones en la unidad de diskett vacia, o cuando no encuentra espacio
suficiente el disco duro donde esta almacenando los datos.
Tolerancia a errores: La capacidad que tiene el software para mantener un nivel
de funcionamiento en caso de errores.
Recuperabilidad: La capacidad que tiene el software para restablecer su
funcionamiento adecuado y recuperar los datos afectados en el caso de una falla.
Conformidad de la fiabilidad: La capacidad del software de cumplir a los
estndares o normas relacionadas a la fiabilidad.
7.2.3 Usabilidad
La usabilidad es la capacidad del software de ser entendido, aprendido, y
usado en forma fcil y atractiva. Algunos criterios de funcionalidad, fiabilidad y
eficiencia afectan la usabilidad, pero para los propsitos de la ISO/IEC 9126 ellos
no clasifican como usabilidad. La usabilidad esta determinada por los usuarios
finales y los usuarios indirectos del software, dirigidos a todos los ambientes, a la
preparacin del uso y el resultado obtenido.
147
Figura 27: Caracterstica de Usabilidad
La usabilidad se divide en 5 criterios:
Entendimiento: La capacidad que tiene el software para permitir al usuario
entender si es adecuado, y de una manera fcil como ser utilizado para las tareas
y las condiciones particulares de la aplicacin. En este criterio se debe tener en
cuenta la documentacin y de las ayudas que el software entrega.
Aprendizaje: La forma como el software permite al usuario aprender su uso.
Tambin es importante considerar la documentacin.
Operabilidad: La manera como el software permite al usuario operarlo y
controlarlo.
Atraccin: La presentacin del software debe ser atractiva al usuario. Esto se
refiere a las cualidades del software para hacer ms agradable al usuario,
ejemplo, el diseo grfico.
Conformidad de uso: La capacidad del software de cumplir los estndares o
normas relacionadas a su usabilidad.
7.2.4 Eficiencia
La eficiencia del software es la forma del desempeo adecuado, de acuerdo
a al nmero recursos utilizados segn las condiciones planteadas. Se debe tener
en cuenta otros aspectos como la configuracin de hardware, el sistema operativo,
entre otros.
148
Figura 28: Caracterstica de Eficiencia
Comportamiento de tiempos: Los tiempos adecuados de respuesta y
procesamiento, el rendimiento cuando realiza su funcin en condiciones
especificas. Ejemplo, ejecutar el procedimiento mas complejo del software y
esperar su tiempo de respuesta, realizar la misma funcin pero con mas cantidad
de registros.
Utilizacin de recursos: La capacidad del software para utilizar cantidades y
tipos adecuados de recursos cuando este funciona bajo requerimientos o
condiciones establecidas. Ejemplo, los recursos humanos, el hardware,
dispositivos externos.
Conformidad de eficiencia: La capacidad que tiene el software para cumplir con
los estndares o convenciones relacionados a la eficiencia.
7.2.5 Capacidad de mantenimiento
La capacidad de mantenimiento es la cualidad que tiene el software para
ser modificado. Incluyendo correcciones o mejoras del software, a cambios en el
entorno, y especificaciones de requerimientos funcionales.
149
Figura 29: Caracterstica de Mantenimiento
El mantenimiento se divide en 5 criterios:
Capacidad de ser analizado: La forma como el software permite diagnsticos de
deficiencias o causas de fallas, o la identificacin de partes modificadas.
Cambiabilidad: La capacidad del software para que la implementacin de una
modificacin se pueda realizar, incluye tambin codificacin, diseo y
documentacin de cambios.
Estabilidad: La forma como el software evita efectos inesperados para
modificaciones del mismo.
Facilidad de prueba: La forma como el software permite realizar pruebas a las
modificaciones sin poner el riesgo los datos.
Conformidad de facilidad de mantenimiento: La capacidad que tiene el
software para cumplir con los estndares de facilidad de mantenimiento.
7.2.6 Portabilidad
La capacidad que tiene el software para ser trasladado de un entorno a otro.
150
Figura 30: Caracterstica de Portabilidad
Adaptabilidad: Es como el software se adapta a diferentes entornos
especificados (hardware o sistemas operativos) sin que implique reacciones
negativas ante el cambio. Incluye la escalabilidad de capacidad interna (Ejemplo:
Campos en pantalla, tablas, volmenes de transacciones, formatos de reporte,
etc.).
Facilidad de instalacin: La facilidad del software para ser instalado en un
entorno especifico o por el usuario final.
Coexistencia: La capacidad que tiene el software para coexistir con otro o varios
software, la forma de compartir recursos comunes con otro software o dispositivo.
Reemplazabilidad: La capacidad que tiene el software para ser remplazado por
otro software del mismo tipo, y para el mismo objetivo. Ejemplo, la remplazabilidad
de una nueva versin es importante para el usuario, la propiedad de poder migrar
los datos a otro software de diferente proveedor.
Conformidad de portabilidad: La capacidad que tiene el software para cumplir
con los estndares relacionados a la portabilidad.
7.2.7 Calidad en uso
Calidad en uso es la calidad del software que el usuario final refleja, la
forma como el usuario final logra realizar los procesos con satisfaccin, eficiencia
y exactitud. La calidad en uso debe asegurar la prueba o revisin de todas las
opciones que el usuario trabaja diariamente y los procesos que realiza
espordicamente relacionados con el mismo software.
151
Figura 31: Caracterstica de Calidad en Uso
Eficacia: La capacidad del software para permitir a los usuarios finales realizar los
procesos con exactitud e integridad.
Productividad: La forma como el software permite a los usuarios emplear
cantidades apropiadas de recursos, en relacin a la eficacia lograda en un
contexto especfico de uso. Para una empresa es muy importante que el software
no afecte al productividad del empleado
Seguridad: Se refiere al que el Software no tenga niveles de riesgo para cuasar
dao a las personas, instituciones, software, propiedad intelectual o entorno. Los
riesgos son normalmente el resultado de deficiencias en la funcionalidad
(Incluyendo seguridad), fiabilidad, usabilidad o facilidad de mantenimiento.
Satisfaccin: La satisfaccin es la respuesta del usuario a la interaccin con el
software, e incluye las actitudes hacia el uso del mismo. A continuacin se
describe un cuadro donde podemos resumir las caractersticas y cada uno de sus
atributos, este cuadro le ayudara a visualizar elporceso de evaluacion.
7.3 LECCIN 3: PROCESO DE EVALUACIN DE SOFTWARE
El proceso de evaluacin de software se inicia con una visin cualitativa y
deriva en una evaluacin cuantitativa, siendo todo el proceso documentado y
cumpliendo los siguientes pasos:
152
7.3.1 Estado del Software
Que se refiere al conocimiento del el estado del software, estableciendo si
se trata de un desarrollo sin terminar o un producto terminado para la entrega al
cliente.
7.3.2 Identificar el tipo de software
Donde se debe especificar el tipo de software a evaluar, si es un sistema
operativo, software de seguridad, software de ofimtica, lenguaje de
programacin, base de datos, aplicativo a la medida, entre otros.
7.3.3 Perfiles de Evaluadores
Teniendo como marco conceptual al estndar ISO/IEC9126, se consideran
tres perfiles de usuario, a un alto nivel de abstraccin para desarrollo de software,
usuarios finales, desarrolladores, y gerentes. El estndar afirma que la relativa
importancia de las caractersticas de calidad vara dependiendo del punto de vista
considerado y de la crtica de los componentes del software a evaluar.
La visin del usuario final, concierne al inters de los mismos en usar el
software, como as tambin su performance, su eficiencia, su facilidad de uso,
entre otros aspectos. Los usuarios finales no estn interesados en caractersticas
internas o de desarrollo del software.
La visin de calidad del desarrollador debe considerar no slo los
requerimientos del software para la visin del usuario sino tambin la calidad para
los desarrollos intermedios resultantes de las actividades de la fase de desarrollo.
Se debe tener en cuenta que los desarrolladores estn preocupados en
caractersticas de calidad del software como mantenibilidad y portabilidad.
La visin de calidad del gerente es una visin integradora, que incorporar
requerimientos de negocio a las caractersticas individuales. Ejemplo, un gerente
esta interesado en el equilibrio entre la mejora del software y los costos y tiempos
establecidos.
7.3.4 Especificar los Objetivos
Se debe conocer los objetivos tanto generales como especficos del software.
7.3.5 Aplicar el modelo de calidad
Donde se debe elaborar un instrumento o formato donde aplique el modelo
de calidad externo e interno y calidad de uso. Si existe un comit o conjunto de
personas encargadas de la evaluacin, el instrumento debe ser aprobado por los
participantes.
153
7.3.6 Criterios de la evaluacin
Donde se tiene en cuenta los criterios de evaluacin que parten de los 7
indicadores principales los cuales fueron especificacdos en la leccin anterior. Los
criterios para evaluar el software se dividen en dos grandes bloques: uno dedicado
a criterios que son aplicables a cualquier tipo de software, y otro conjunto
compuesto por criterios adaptables al grupo de software evaluados. En este caso
se definen los criterios de la evaluacin segn el tipo de software, para el cual
debe conformar un equipo evaluador, este ejercicio ayuda a definir que opciones
se deben evaluar con ms detalle y valor.
tipos de software ejemplos orden del criterio de
evaluacin
evaluadores
financieros contabilidad,
bancarios,
carteras, pagos,
costos, nominas, etc
1. Seguridad
2. Tiempo de respuesta
3. Exactitud de la
informacin
4. Recuperabilidad
personal de sistemas,
contador o financiero,
auxiliar, digitador
administrativos recursos humanos,
administracin de
documentos,
hospitalarios, etc
1. Tiempo de respuesta
2. Seguridad
3. Exactitud de la
informacin
4. Recuperabilidad
administrativo,
auxiliar, digitador
educativos materias
acadmicas,
enciclopedias,
tutores, manuales
1. Facilidad de
comprensin
2. calidad grafica
3. portabilidad
docente, alumno
a la medida produccin, radio
terapia, control de
maquinas, etc
Los criterios o indicadores
estn sujetos a la
actividad especfica del
software
personal que
conozcael proceso
manual o automtico,
cliente
Tabla 38: Tabla de criterios a tener en cuenta al evaluar un software
7.3.7 Seleccionar mtricas: Que se obtienen de los indicadores especificados
en el modelo. Los niveles o escalas son especificadas de acuerdo a lo que se
quiera medir, se debe tener en cuenta ciertos criterios para la asignacin de
puntajes, por ejemplo a cada mtrica seleccionada se le asigna un puntaje
mximo de referencia, se debe tener en cuenta que la suma de los puntajes
mximos de todas las mtricas debe ser igual o aproximado a 100 puntos, que el
personal que participa en la evaluacin debe establecer niveles de calificacin
cualitativa con base a los puntajes (por ejemplo: de 0 a 1 Inaceptable, de 2 a 3
mnimo aceptable, ms de 3 Aceptable o satisfactorio), otro ejemplo de calificacin
cualitativa puede ser (Deficiente, Insuficiente, Aceptable, Sobresaliente,
Excelente), en la mtricas se permite usar nmeros enteros o hasta con un
decimal de aproximacin, se debe definir por cada mtrica, un puntaje mnimo de
aprobacin, y al final de de la evaluacin, dependiendo del puntaje si es mayor o
menor a lo propuesto, considerar si el software cumple o no cumple con los
objetivos propuestos.
154
7.3.8 Establecer criterios: La persona que participa en el proceso de evaluacin
debe tener criterios con respecto al indicador que se esta analizando, Es
importante tener en cuenta que el criterio debe ajustar al tipo de software que se
va a evaluar.
7.3.9 Tomar medidas: Para la medicin, las mtricas seleccionadas se aplican al
software. Los resultados son valores expresados en las escalas de las mtricas,
definidos previamente.
7.3.10 Resultados: Los resultados del proceso de evaluacin genera un cuadro
de resultados por cada uno de losprincipales indicadores y el total final de
resultado.
7.3.11 Documentacin: El proceso de evaluacin se documenta, indicando la
fecha, empresa, los cargos, nombres y apellidos, dependencia de las personas
que participan en el proceso de evaluacin, especificando las etapas en las que
participaron.
7.3.12 Seguimiento: Donde si el resultado de la evaluacin tiene observaciones o
indicadores de calidad bajos, y el personal que lo evala permite realizar la
correccin, se programa otra evaluacin donde se verifique que el proceso mejora,
el tiempo que se estime debe influir en los criterios de la aproxima evaluacin.
A partir de cada una de las caractersticas, y subcaractersticas de la norma
ISO/IEC 9126, se ha includo las preguntas generales para cada una de ellas, la
siguiente tabla muestra las caractersticas, la pregunta planteada para ella, las
subcaractersticas y los cuestionamientos para cada una de ellas:
CARACTERISTICA PREGUNTA SUBCARATERISTICA PREGUNTA
ADECUACIN Tiene el conjunto de
funciones apropiadas
para las tareas
especificadas?
EXACTITUD Hace lo que fue
acordado en forma
esperada y correcta?
INTEROPERABILIDAD Interacta con otros
sistemas especificados?
FUNCIONALIDAD Las funciones y
Propiedades
satisfacen
las necesidades
Explcitas e
implcitas;
esto es, el qu?
CONFORMIDAD Est de acuerdo con las
leyes o normas y
estndares, u otras
prescripciones?
MADUREZ Con qu frecuencia
presenta fallas por
defectos o errores?
CONFIABILIDAD Puede mantener
el
nivel de
rendimiento,
bajo ciertas
condiciones
TOLERANCIA A
ERRORES
Si suceden fallas, como
se comporta en cuanto a
la performancia
155
especificada? y por cierto tiempo?
RECUPERABILIDAD Es capaz de recuperar
datos en caso de fallas?
ENTENDIMIENTO Es fcil de entender y
reconocer la estructura y
la lgica y su
aplicabilidad?
APRENDIZAJE Es fcil de aprender a
usar?
OPERABILIDAD Es fcil de operar y
controlar?
USABILIDAD El software, es
fcil de usar y de
aprender?
ATRACCIN Es atractivo el diseo
del software?
COMPORTAMIENTO
DE TIEMPOS
Cul es el tiempo de
respuesta y performancia
en la ejecucin de la
funcin?
EFICIENCIA Es rpido y
minimalista en
cuanto a uso de
recursos, bajo
ciertas
condiciones?
UTILIZACION DE
RECURSOS
Cuntos recursos usa y
durante cunto tiempo?
CAPACIDAD DE SER
ANALIZADO
Es fcil diagnosticar una
falla o identificar partes a
modificar?
CAMBIALIDAD Es fcil de modificar y
adaptar?
ESTABILIDAD Hay riesgos o efectos
inesperados cuando se
realizan cambios?
CAPACIDAD DE
MANTENIMIENTO
Es fcil de
modificar y testear?
FACILIDAD DE
PRUEBA
Son fciles de validar
las modificaciones?
ADAPTABILIDAD Es fcil de adaptar a
otros entornos con lo
provisto?
FACILIDAD DE
INSTALACION
Es fcil de instalar en el
ambiente especificado?
REMPLAZABILIDAD Es fcil de usarlo en
lugar de otro software
para ese ambiente?
PORTABILIDAD Es fcil de
transferir de un
ambiente a otro?
COEXISTENCIA Comparte sin dificulta
recursos con otro
software o dispositivo?
EFICACIA La eficaz el software
cuando el usuario final
realiza los procesos?
CALIDAD EN USO Muestra el
usuario final
aceptacin y
seguridad del
software?
PRODUCTIVIDAD Muestra el usuario final
rendimiento en sus tareas
cotidianas del proceso
especfico?
SEGURIDAD El software tiene niveles
de Riesgo que causan
dao al usuario final?
156
Tabla 39: Caractersticas y Subcaratersticas ISO/IEC 9126
7.4 LECCIN 4: MTRICAS EXTERNAS BASADOS EN ISO/IEC 9126
Adems de los cuestionarios generales, se presenta cada caracterstica, la
sub caracterstica, y las mtricas a evaluar, estas mtricas pueden ser la base
para elaborar cuestionarios teniendo en cuenta la norma ISO/IEC 9126, para
poder realizar el anlisis de las mtricas externas de acuerdo a las caractrsticas
propias del software a evaluar y a las caractersticas y subcaracteraticas
seleccionadas para la evaluacin, en la siguiente tabla se muestra las mtricas
externas para evaluacin de software.
caracterstica sub caracterstica nombre mtrica
Funcionalidad Idoneidad Adecuacin funcional
Integridad funcional de aplicacin
Cobertura de aplicacin funcional
Estabilidad de la especificacin funcional
(volatilidad)
Precisin Precisin a la expectativa
Precisin de cmputo
Precisin
Interoperabilidad Intercambiabilidad de datos (formato de base
de datos))
Intercambiabilidad de datos (intento del
usuario de xito basado en el intercambio)
Seguridad Acceso auditabilidad
Acceso controlabilidad
Datos de prevencin de la corrupcin
Funcionalidad de
Cumplimiento
Cumplimiento funcional
Interfaz estndar de cumplimiento
Confiabilidad Madurez latente estimada de densidad de fallos
Falta de densidad en contra de casos de
prueba
Falta de resolucin
Error de la densidad
Error de la eliminacin
Tiempo medio entre fallos
Prueba de cobertura (cobertura de las
operaciones especificadas escenario de
prueba)
Prueba de madurez
Tolerancia a Fallos Evitar desglose
Evitar la falta
Evitar el funcionamiento incorrecto
Recuperacin Disponibilidad
Tiempo medio de inactividad
Tiempo medio de recuperacin
Reinicio
Restaurabilidad
Restaurar la eficacia
Fiabilidad de
Cumplimiento
Confiabilidad de cumplimiento
157
Usabilidad Comprensibilidad Integridad de la Descripcin
Integridad de acceso
Integridad de acceso en uso
Demostracin de la eficacia
Funciones evidentes
Funcin comprensibilidad
Comprender la entrada y salida
Aprendizaje Facilidad de funcin de aprendizaje
Facilidad de aprendizaje para realizar una
tarea en uso
Eficacia de la documentacin del usuario y / o
sistema de ayuda
Eficacia de la documentacin del usuario y / o
ayudar a los sistemas en uso
Ayuda de accesibilidad
Ayuda de frecuencia
Operabilidad Coherencia operacional en el uso
Correccin de errores
Correccin de errores en el uso
Disponibilidad predeterminada del valor de
uso
Mensaje comprensibilidad en uso
No necesita explicacin en mensajes de error
Recuperacin de error operativo en uso
Tiempo entre las operaciones de un error
humano en uso
Capacidad de deshacer (correccin de error
del usuario)
Personalizacin
Operacin de reduccin de procedimiento
Accesibilidad fsica
Atractivo Atractivo de interaccin
Personalizacin de interfaz de aspecto
Cumplimiento de
Usabilidad
Usabilidad de cumplimiento
Eficiencia Tiempo de
Comportamiento
Tiempo de respuesta
Tiempo de respuesta (tiempo medio de
respuesta)
Rendimiento
Rendimiento (cantidad promedio de
rendimiento)
Rendimiento (peor ratio de rendimiento de
caso)
Tiempo de respuesta
Tiempo de vuelta (media para el tiempo de
entrega)
Tiempo de vuelta (peor caso cociente del
tiempo de entrega)
Tiempo de espera
Utilizacin de Recursos Dispositivos Entrada/ Salida de utilizacin
Entrada / Salida lmites de carga
Entrada/Salida errores relacionados
Entrada/Salida radio de cumplimiento
158
Tiempo de espera de E / S de la utilizacin de
los dispositivos
Mxima utilizacin de la memoria
Media de ocurrencia de errores de memoria
Relacin entre el error de memoria / hora
Mxima utilizacin de la transmisin
Medios de comunicacin la utilizacin del
dispositivo de equilibrio
Media de ocurrencia de errores de
transmisin
Media de error de transmisin por tiempo
Utilizacin de la capacidad de transmisin
Cumplimiento de
Eficiencia
Eficiencia de Cumplimiento
Mantenimiento Analizabilidad Pistas de capacidad de auditoria
Apoyar la funcin de diagnstico
Falta capacidad de anlisis
Falta de eficiencia de anlisis
Estado de capacidad de supervisin
Modificacin Cambiar la eficiencia del ciclo
Cambiar la implementacin mientras
transcurre el tiempo
Modificacin de la complejidad
Parametrizado modificable
Cambio del software de capacidad de control
Estabilidad Cambio de porcentaje de xito
Modificacin de la localizacin del
impacto(Error emergentes despus del
cambio)
Comprobabilidad Disponibilidad de una funcin de prueba
Vuelva a probar la eficiencia
Prueba de reinicio
Cumplimiento de
Mantenimiento
Cumplimiento de mantenimiento
Portabilidad Adaptabilidad Capacidad de adaptacin de las estructuras
de datos
Hardware adaptabilidad ambiental
Organizacin de adaptacin al medio
ambiente
Trasladar la facilidad de uso
Sistema de adaptacin de software del medio
ambiente
Instalacin Facilidad de instalacin
Facilidad de instalacin, Reintentar
Co-existencia Disponible co-existencia
Sustituir Uso continuo de los datos
Funcin de la inclusin
Apoyo a los usuarios la coherencia funcional
Cumplimiento
Portabilidad
Cumplimiento de portabilidad
Tabla 40: Mtricas Externas ISO/IEC 9126
159
7.5 LECCIN 5: MTRICAS INTERNAS BASADOS EN ISO/IEC 9126
Ahora se presenta las caractersticas, la sub caractersticas, y las mtricas
internas para evaluar software, esta tabla ha sido elaborada teniendo en cuenta la
norma ISO/IEC 9126. Para el anlisis de las mtricas internas, tambin pueden
ser complementados de acuerdo a las caractrsticas propias del software a
evaluar.
caracterstica sub caracterstica nombre mtrica
Funcionalidad IDONEIDAD Adecuacin funcional
Integridad funcional de aplicacin
Cobertura de aplicacin funcional
Estabilidad de la especificacin funcional
(volatilidad)
PRECISIN Precisin de cmputo
Precisin
INTEROPERABILIDAD Intercambiabilidad de datos (formato de
base de datos)
Coherencia de interfaz (protocolo)
SEGURIDAD Acceso auditabilidad
Acceso controlabilidad
Datos de prevencin de la corrupcin
Cifrado de datos
FUNCIONALIDAD DE
CUMPLIMIENTO
Cumplimiento funcional
Entre sistemas estndar de cumplimiento
Confiabilidad MADUREZ Deteccin de fallas
Eliminacin de fallos
Prueba de adecuacin
TOLERANCIA A FALLOS Evitar fallas
Evitar el funcionamiento incorrecto
RECUPERACIN Restauracin
Restauracin efectiva
FIABILIDAD DE
CUMPLIMIENTO
Confiabilidad de cumplimiento
Usabilidad COMPRENSIBILIDAD Integridad de la Descripcin
Demostracin de la capacidad
Funciones evidentes
Funcin de la comprensibilidad
APRENDIZAJE Integridad de la documentacin del usuario
y / o sistema de ayuda
OPERABILIDAD Entrada, asegurar su validez
Usuario, cancela la operacin
Usuario, deshacer la operacin
Personalizacin
160
Accesibilidad fsica
Estado de operacin capacidad de
vigilancia
Consistencia operacional
Claridad en los mensajes
Interfaz claridad en los elementos
Recuperacin de errores operacional
ATRACTIVO Atractivo de interaccin
Aparicin de personalizacin
CUMPLIMIENTO DE
USABILIDAD
Usabilidad de cumplimiento
Eficiencia TIEMPO DE
COMPORTAMIENTO
Tiempo de respuesta
Rendimiento de tiempo
Tiempo por turno
UTILIZACIN DE
RECURSOS
Utilizacin de Entradas y Salidas
Utilizacin de mensaje de Entrada y Salida
Utilizacin de memoria
Utilizacin de memoria de mensajes densos
Transmisin de Utilizacin
CUMPLIMIENTO DE
EFICIENCIA
Eficiencia de Cumplimiento
Mantenimiento ANALIZABILIDAD Actividad de grabacin
Preparacin de la funcin de diagnstico
MODIFICACIN Cambio de Registros
ESTABILIDAD Impacto del cambio
Modificacin de la localizacin del impacto
COMPROBABILIDAD Integridad de los incorporados en las
pruebas de funcin
Autonoma de la capacidad de prueba
Prueba de observabilidad de progreso
CUMPLIMIENTO DE
MANTENIMIENTO
Cumplimiento de mantenimiento
Portabilidad ADAPTABILIDAD Capacidad de adaptacin de las estructuras
de datos
Hardware adaptabilidad ambiental
Organizacin de adaptacin al medio
ambiente
Trasladar la facilidad de uso
Sistema de adaptacin de software del
medio ambiente
INSTALACIN Facilidad de instalacin, vuelva a intentar
Esfuerzo de instalacin
Flexibilidad de instalacin
CO-EXISTENCIA Disponible co-existencia
SUSTITUIR Uso continuo de los datos
Funcin de la inclusin
161
CUMPLIMIENTO
PORTABILIDAD
Cumplimiento de portabilidad
Tabla 41: Mtricas Internas ISO/IEC 9126
162
CAPITULO 8
METODOLOGIAS DE
EVALUACIN DE LA
ARQUITECTURA DEL
SOFTWARE
163
INTRODUCCIN
La Arquitectura de Software es una prctica joven tiene sus orgenes en la
dcada de 1960, pero solo hasta los aos 90, Dewayne Perry y Alexander Wolf, la
exponen en el sentido que hoy se conoce. A partir de ese momento la Arquitectura
de Software comenz a tener auge vertiginoso tanto en la academia como en la
industria, desarrollndose los de estilos arquitectnicos, los ADL (Leguajes de
Descripcin Arquitectnica), que aunque poco difundidos, han dado al traste con la
creacin de diferentes tipos de arquitecturas como las basadas en componentes.
La Arquitectura de Software se convierte en un factor importante en cuanto
a lograr en ella una alta calidad la importancia radica en que la arquitectura es el
corazn de todo sistema informtico y determina cules sern los niveles de
calidad asociados al sistema.
No sirve de nada un sistema que no cumple con los atributos de calidad que
se especificaron en los requerimientos no funcionales de los clientes. Por lo que
disear una correcta arquitectura va a determinar el xito o fracaso de un sistema
de software, en la medida que esta cumpla o no con sus objetivos. Debido a esto,
para reducir los riesgos, y como buena prctica de ingeniera, es recomendable
realizar evaluaciones a la arquitectura del software.
En este captulo se explica el procedimiento para realizar la evaluacin de
una arquitectura, destacando algunos mtodos de evaluacin existentes, al final
se har el estudio de una propuesta denominada MECABIC o Mtodo de
Evaluacin de la Calidad de Arquitecturas Basadas en la Integracin de
Componentes, cuyo objetivo principal es evaluar y analizar la calidad de este tipo
de Arquitectura de Software.
Aqu se har la revisin de los diferentes mtodos de la evaluacin de
arquitecturas de software, para analizar e identificar potencialidades de los
diferentes mtodos o procedimientos y hacer el estudio de las caractersticas
comparativas de cada una de ellas.
Se realizar un estudio del estado del arte de la evaluacin de arquitecturas
de software. Para introducirse en el tema se tratan aspectos como los principales
problemas que causa la arquitectura en un proyecto, tambin se define que es la
evaluacin de arquitecturas, sus caractersticas, objetivos que persigue. Se hace
adems un anlisis de cundo y por qu una determinada arquitectura debe ser
evaluada y los beneficios que reporta.
164
8.1 LECCIN 1: EVALUACIN DE LA ARQUITECTURA DE SOFTWARE
La evaluacin de software es como un estudio de factibilidad que pretende
detectar posibles riesgos, y buscar recomendaciones para contenerlos, teniendo
en cuenta que la evaluacin se realiza antes de la implementacin de la solucin.
El objetivo de evaluar una arquitectura es saber si puede habilitar los
requerimientos, atributos de calidad y restricciones para asegurar que el sistema
construido cumple con las necesidades de las personas que estn relacionadas
con el sistema.
La evaluacin de una arquitectura de software es una tarea donde se
pretende medir propiedades del sistema en base a especificaciones abstractas,
como por ejemplo los diseos arquitectnicos. Las mediciones que se realizan
sobre una arquitectura de software pueden tener distintos objetivos de tipo
cualitativo, cuantitativo, o mximos y mnimos tericos.
La medicin cualitativa se aplica para la comparacin entre arquitecturas
candidatas y tiene relacin con la intencin de saber la opcin que se adapta
mejor a cierto atributo de calidad. La medicin cuantitativa busca la obtencin de
valores que permitan tomar decisiones en cuanto a los atributos de calidad de una
arquitectura de software, el esquema general es la comparacin con mrgenes
establecidos, como lo son los requerimientos de desempeo, para establecer el
grado de cumplimiento de una arquitectura candidata, o tomar decisiones sobre
ella. La medicin de mximo y mnimo terico contempla los valores tericos para
efectos de la comparacin de la medicin con los atributos de calidad
especificados, el conocimiento de los valores mximos o mnimos permite el
establecimiento claro del grado de cumplimiento de los atributos de calidad.
El propsito de realizar evaluaciones a la arquitectura, es para identificar y
analizar riesgos potenciales en su estructura y sus propiedades, que afecten al
software resultante, verificar que los requerimientos no funcionales estn
presentes en la arquitectura, as como determinar el grado de stisfaccin de los
atributos de calidad. Un atributo de calidad es una caracterstica de calidad que
afecta a un elemento, donde el trmino caracterstica se refiere a aspectos no
funcionales y el termino elemento a componente.
La evaluacin de la arquitectura puede realizarse en cualquier momento,
pero se propone dos etapas distintas para realizarlas: La evaluacin temprana que
puede realizarse sin necesidad de que la arquitectura est completamente
especificada para efectuar la evaluacin, abarca las fases tempranas de diseo y
del desarrollo, y la evaluacin tarde que se hace cuando la arquitectura ya esta
establecida y la implementacin se ha completado.
Generalmente las evaluaciones a la arquitectura se hacen por miembros del
equipo de desarrollo, arquitecto, diseador, entre otros. Otro actor interesado por
165
los resultados de una evaluacin es el cliente, ya que dependiendo de los
resultados puede tomar decisiones de continuar o no con el proyecto.
Las tnicas de evaluacin de arquitecturas se clasifican en tcnicas cualitativas y
tcnicas cuantitativas. Las tcnicas cualitativas basadas en preguntas sobre la
arquitectura (cuestionarios: abiertas y tempranas, checklist: especfico del dominio
de la aplicacin, y escenarios: especficas del sistema, para arquitectura
avanzada), y las cuantitativas que utiliza mtricas como acoplamiento, cohesividad
en los mdulos, profundidad en herencias, modificabilidad.
Generalmente las tcnicas de evaluacin cualitativas son utilizadas cuando
la arquitectura est en construccin, mientras que las tcnicas de evaluacin
cuantitativas se usan cuando la arquitectura ya ha sido implantada.
Figura 32: Clasificacin de las Tcnicas de Evaluacin.
Las evaluaciones pueden ser planeadas o no planeadas: Las planeadas
que son aquellas que han sido planificadas por el ciclo de vida de desarrollo,
siendo parte de las actividades del proyecto, y las no planeadas que se presentan
cuando la arquitectura contiene varios defectos que han sido detectados en las
etapas tardas del desarrollo.
La arquitectura puede ser evaluada teniendo en cuenta la clasificacin de
los atributos de calidad, donde se hace la clasificacin en dos categoras:
Observables va ejecucin que son aquellos atributos que se determinan del
comportamiento del sistema en tiempo de ejecucin. La descripcin de algunos de
estos atributos se presenta en la siguiente tabla:
Atributo de calidad Descripcin
Disponibilidad Es la medida de disponibilidad del sistema para el uso.
Confidencialidad Es la ausencia de acceso no autorizado a la informacin.
166
Funcionalidad Habilidad del sistema para realizar el trabajo para el cual fue
concebido.
Desempeo Es el grado en el cual un sistema o componente cumple con sus
funciones designadas, dentro de ciertas restricciones dadas, como
velocidad, exactitud o uso de memoria
Confiabilidad Es la medida de la habilidad de un sistema a mantenerse operativo a
lo largo del tiempo
Seguridad externa Ausencia de consecuencias catastrficas en el ambiente. Es la medida
de ausencia de errores que generan prdidas de informacin
Seguridad interna Es la medida de la habilidad del sistema para resistir a intentos de uso
no autorizados y negacin del servicio, mientras se sirve a usuarios
legtimos
Tabla 42: Descripcin de atributos de calidad observables va ejecucin
No observables va ejecucin: aquellos atributos que se establecen durante
el desarrollo del sistema. La descripcin de algunos de estos atributos se presenta
en la siguiente tabla.
Atributo de calidad Descripcin
Configurabilidad Posibilidad que se otorga a un usuario experto a realizar ciertos
cambios al sistema
Integrabilidad Es la medida en que trabajan correctamente componentes del sistema
que fueron desarrollados separadamente al ser integrados.
Integridad Es la ausencia de alteraciones inapropiadas de la informacin
Interoperabilidad Es la medida de la habilidad de que un grupo de partes del sistema
trabajen con otro sistema
Modificabilidad Es la habilidad de realizar cambios futuros al sistema
Mantenibilidad Es la capacidad de someter a un sistema a reparaciones y evolucin
Portabilidad Es la habilidad del sistema para ser ejecutado en diferentes ambientes
de computacin. Estos ambientes pueden ser hardware, software o
una combinacin de los dos
Reusabilidad Es la capacidad de disear un sistema de forma tal que su estructura
o parte de sus componentes puedan ser reutilizados en futuras
aplicaciones
Escalabilidad Es el grado con el que se pueden ampliar el diseo arquitectnico, de
datos o procedimental
Capacidad de
Prueba
Es la medida de la facilidad con la que el software, al ser sometido a
una serie de pruebas, puede demostrar sus fallas
Tabla 43: Descripcin de atributos de calidad no observables va ejecucin
8.2 LECCIN 2: TCNICAS DE EVALUACIN DE ARQUITECTURAS DE
SOFTWARE
Las tcnicas utilizadas para la evaluacin de atributos de calidad requieren
grandes esfuerzos del ingeniero de software para crear especificaciones y
predicciones. Estas tcnicas requieren informacin del sistema a desarrollar que
no est disponible durante el diseo arquitectnico, sino al principio del diseo
detallado del sistema.
167
Las tcnicas existentes en la actualidad para evaluar arquitecturas permiten
hacer una evaluacin cuantitativa sobre los atributos de calidad a nivel
arquitectnico, pero se tienen pocos medios para predecir el mximo (o mnimo)
terico para las arquitecturas de software. Debido al costo de realizar este tipo de
evaluacin, en muchos casos los arquitectos de software evalan
cualitativamente, para decidir entre las alternativas de diseo. Se han propuesto
diferentes tcnicas de evaluacin de arquitecturas de software, algunas son:
Evaluacin basada en escenarios, Evaluacin basada en simulacin, Evaluacin
basada en modelos matemticos y Evaluacin basada en experiencia.
8.2.1 Evaluacin basada en escenarios
Un escenario es una breve descripcin de la interaccin de alguno de los
involucrados en el desarrollo del sistema con ste. Por ejemplo, un usuario har la
descripcin en trminos de la ejecucin de una tarea; un encargado de
mantenimiento har referencia a cambios que deban realizarse sobre el sistema;
un desarrollador se enfocar en el uso de la arquitectura para efectos de su
construccin o prediccin de su desempeo.
Un escenario consta de tres partes: El estmulo, que es la parte del
escenario que explica o escribe lo que el involucrado en el desarrollo hace para
iniciar la interaccin con el sistema, incluye la ejecucin de tareas, cambios en el
sistema, ejecucin de pruebas, configuracin, etc. El contexto, que describe qu
sucede en el sistema al momento del estmulo. Y la respuesta que describe a
travs de la arquitectura, cmo debera responder el sistema ante el estmulo.
Este ltimo elemento es el que permite establecer cul es el atributo de calidad
asociado.
Los escenarios permiten concretar y entender atributos de calidad. Kazman
y Carriere coinciden en la importancia del uso de los escenarios, no slo para
efectos de la evaluacin de arquitecturas de software. Actualmente las tcnicas
basadas en escenarios cuentan con dos instrumentos de evaluacin relevantes, a
saber: el Utility Tree propuesto por Kazman, y los Profiles propuestos por Bosch.
8.2.1.1 Utility Tree: Un Utility Tree es un esquema en forma de rbol que presenta
los atributos de calidad de un sistema de software, refinados hasta el
establecimiento de escenarios que especifican con suficiente detalle el nivel de
prioridad de cada uno. La intencin del uso del Utility Tree es la identificacin de
los atributos de calidad ms importantes para un proyecto particular. No existe un
conjunto preestablecido de atributos, sino que son definidos por los involucrados
en el desarrollo del sistema al momento de la construccin del rbol.
El Utility Tree contiene como nodo raz la utilidad general del sistema. Los
atributos de calidad asociados al mismo conforman el segundo nivel del rbol, los
cuales se refinan hasta la obtencin de un escenario lo suficientemente concreto
para ser analizado y otorgarle prioridad a cada atributo considerado. Cada atributo
168
de calidad perteneciente al rbol contiene una serie de escenarios relacionados, y
una escala de importancia y dificultad asociada, que ser til para efectos de la
evaluacin de la arquitectura.
8.2.1.2 Perfiles (Profiles): Un perfil o profile es un conjunto de escenarios,
generalmente con alguna importancia relativa asociada a cada uno de ellos. El uso
de perfiles permite hacer especificaciones ms precisas del requerimiento para un
atributo de calidad. Los perfiles tienen asociados dos formas de especificacin:
Los perfiles completos que definen los escenarios importantes como parte
del perfil. Esto permite al ingeniero de software realizar un anlisis de la
arquitectura para el atributo de calidad estudiado de una manera completa, puesto
que incluye todos los posibles casos. Su uso se reduce a sistemas relativamente
pequeos y slo es posible predecir conjuntos de escenarios completos para
algunos atributos de calidad.
Los perfiles seleccionados que se asemejan a la seleccin de muestras
sobre una poblacin en los experimentos estadsticos. Se toma un conjunto de
escenarios de forma aleatoria, de acuerdo a algunos requerimientos. La
aleatoriedad no es totalmente cierta por limitaciones prcticas, por lo que se fuerza
la realizacin de una seleccin estructurada de elementos para el conjunto de
muestra. Si bien es informal, permite hacer proposiciones cientficamente vlidas.
Para la definicin de un perfil, es necesario seguir tres pasos: definicin de
las categoras del escenario, seleccin y definicin de los escenarios para la
categora y asignacin del peso a los escenarios. La definicin de categoras de
escenarios divide la poblacin de escenarios en poblaciones ms pequeas, que
cubren aspectos particulares del sistema. La seleccin y definicin de escenarios
para cada categora selecciona un conjunto de escenarios representativo para la
subpoblacin. Luego, en la asignacin del peso a los escenarios, dependiendo del
perfil, el peso de un escenario tiene diferentes significados. Se definen escalas
que de alguna forma sean cuantificables y puedan ser convertidas a pesos
relativos.
Cada atributo de calidad tiene un perfil asociado. Algunos perfiles pueden
ser usados para evaluar ms de un atributo de calidad. Han sido seleccionados
cinco atributos de calidad que son considerados de mayor relevancia para una
perspectiva general de ingeniera de software, ellos son: desempeo
(performance), mantenibilidad (maintainability), confiabilidad (reliability), seguridad
externa (safety) y seguridad interna (security).
La efectividad de la tcnica es altamente dependiente de la
representatividad de los escenarios. Existe la evaluacin de funcionalidad basada
en escenarios, y es utilizada en el diseo orientado a objetos para especificar
comportamiento del sistema. La diferencia entre este tipo de evaluacin y la
evaluacin arquitectnica basada en escenarios radica en que la ltima utiliza los
escenarios para evaluar atributos de calidad, en lugar de verificar o describir
169
funcionalidad, adems de que se usan otros escenarios para definir otros atributos
de calidad. La siguiente tabla muestra para cada atributo de calidad, el perfil
asociado, la forma en que se definen las categoras, el significado de los pesos y
posibles mtricas de evaluacin.
Atributo Perfil Categoras Pesos Mtricas
Mantenibilid
ad
Perfil de
mantenimiento
(Maintainance
profile)
Se organizan
alrededor de las
interfaces del sistema
(sistema operativo,
interfaces con el
usuario, interfaces
con otros sistemas).
Los escenarios de
cambio describen
modificaciones en los
requerimientos
Indican la
probabilidad de
ocurrencia del
cambio de
escenario en
un perodo de
tiempo
- Impacto en trmino
de lneas de cdigo
que tienen que
cambiarse
- Se requiere un
estimado de lneas de
cdigo de los
componentes
arquitectnicos.
Desempeo Perfil de uso
(Usage profile)
Descompone los
escenarios de uso
basado en los tipos
de usuario y/o
interfaces del sistema
Representan la
frecuencia
relativa
del escenario
- Funcionalidad de
componentes
- Comportamiento del
sistema en
respuesta a los
escenarios de
uso en el perfil
- Promedio y peor
caso de latencia por
sincronizacin y
sobrecarga en el
sistema
Confiabilida
d
Perfil de uso
(Usage profile)
Confiabilidad de los
componentes, genera
la confiabilidad de los
escenarios de uso
Indica la
robustez
del sistema
- Datos estimados de
confiabilidad del
componente
- Datos histricos de
confiabilidad del
componente
Seguridad
Interna
Perfil de
seguridad
(Security
profile)
Perfil de uso
(usage profile)
Basada en todas las
interfaces del
sistema
Indica la
probabilidad de
fallas
Depende del aspecto
de seguridad a ser
evaluado. Por
ejemplo, la
disponibilidad puede
evaluarse en trminos
del nmero de veces
que se ejecutan
operaciones de
seguridad.
Seguridad
Externa
Perfil de peligro
(Hazard profile)
Se organizan de
acuerdo a
documentos
de certificacin
(puntos de
interaccin del
sistema con el
mundo real, o
componentes crticos
del sistema)
Indican la
probabilidad de
falla u
ocurrencia de
consecuencias
desastrosas.
Bosch (2000) no
establece ejemplos
170
Tabla 44: Perfiles, categorias, Pesos, y Mtricas Asociados a atributos de Calidad
La evaluacin basada en escenarios puede ser empleada para comparar
dos arquitecturas y para la evaluacin absoluta de una arquitectura. La diferencia
est en que la evaluacin absoluta requiere mayor cantidad de datos estimados y
cuantitativos necesarios para la evaluacin.
La tcnica se puede descompones en dos etapas: El anlisis de impacto,
que toma como entrada el perfil y la arquitectura de software, para cada escenario
del perfil, se evala el impacto de la arquitectura y se obtienen los resultados. La
etapa de prediccin de resultados, donde los resultados sern usados para
pronosticar el valor del atributo de calidad estudiado de acuerdo a las mtricas
existentes.
8.2.2 Evaluacin basada en simulacin
La evaluacin basada en simulacin utiliza una implementacin de alto nivel
de la arquitectura de software. El enfoque bsico consiste en la implementacin de
componentes de la arquitectura y la implementacin del contexto del sistema
donde se supone va a ejecutarse. La finalidad es evaluar el comportamiento de la
arquitectura bajo diversas circunstancias. Una vez disponibles estas
implementaciones, pueden usarse los perfiles respectivos para evaluar los
atributos de calidad. El proceso de evaluacin basada en simulacin sigue los
pasos mostrados en la siguiente tabla:
Pasos Definicin
Definicin e implementacin del
contexto
Consiste en identificar las interfaces de la arquitectura
de software con su contexto, y decidir cmo ser
simulado el comportamiento del contexto en tales
interfaces.
Implementacin de los
componentes arquitectnicos
La descripcin del diseo arquitectnico debe definir las
interfaces y las conexiones de los componentes, por lo
que estas partes pueden ser tomadas directamente de
la descripcin de diseo.
Implementacin de los
componentes arquitectnicos
La descripcin del diseo arquitectnico debe definir las
interfaces y las conexiones de los componentes, por lo
que estas partes pueden ser tomadas directamente de
la descripcin de diseo.
Implementacin del perfil Dependiendo del atributo de calidad que el arquitecto de
software intenta evaluar usando simulacin, el perfil
asociado necesitar ser implementado en el sistema. El
arquitecto de software debe ser capaz de activar
escenarios individuales, as como tambin ejecutar un
perfil completo usando seleccin aleatoria, basado en
los pesos normalizados de los mismos.
Simulacin del sistema e inicio del
perfil
El arquitecto de software ejecutar la simulacin y
activar escenarios de forma manual o automtica, y
obtendr resultados de acuerdo al atributo de calidad
que est siendo evaluado.
171
Prediccin de atributos de calidad Dependiendo del tipo de simulacin y del atributo de
calidad evaluado, se puede disponer de cantidades
excesivas de datos, que requieren ser condensados.
Esto permite hacer conclusiones acerca del
comportamiento del sistema.
Tabla 45: Pasos para la Evaluacin Basada en Simulacin
En el mbito de las simulaciones, se encuentra la tcnica de
implementacin de prototipos. Esta tcnica implementa una parte de la
arquitectura de software y la ejecuta en el contexto del sistema. Es utilizada para
evaluar requerimientos de calidad operacional, como desempeo y confiabilidad.
8.2.3 Evaluacin basada en modelos matemticos
La evaluacin basada en modelos matemticos se utiliza para evaluar
atributos de calidad operacionales. Permite una evaluacin esttica de los
modelos de diseo arquitectnico, y se presentan como alternativa a la simulacin,
dado que evalan el mismo tipo de atributos. Ambos enfoques pueden ser
combinados, utilizando los resultados de uno como entrada para el otro. El
proceso de evaluacin basada en modelos matemticos sigue los pasos
mostrados en la siguiente tabla:
Pasos Definicin
Seleccin y adaptacin del modelo
matemtico
Existen varios modelos matemticos para medir sus
atributos de calidad, los cuales tienden a ser muy
elaborados y detallados, as como tambin requieren de
cierto tipo de datos y anlisis. Parte de estos datos
requeridos no estn disponibles a nivel de arquitectura,
y la tcnica requiere mucho esfuerzo para la evaluacin
arquitectnica, por lo cual se debe adaptar el modelo.
Representacin de la arquitectura
en trminos del modelo
El modelo matemtico seleccionado y adaptado no
asume necesariamente que el sistema que intenta
modelar consiste de componentes y conexiones. Por lo
tanto, la arquitectura necesita ser representada en
trminos del modelo.
Estimacin de los datos de entrada
requeridos
El modelo matemtico an cuando ha sido adaptado,
requiere datos de entrada que no estn incluidos en la
definicin bsica de la arquitectura. Es necesario
estimar y deducir estos datos de la especificacin de
requerimientos y de la arquitectura diseada.
Prediccin de atributos de calidad Una vez que la arquitectura es expresada en trminos
del modelo y se encuentran disponibles todos los datos
de entrada requeridos, el arquitecto est en capacidad
de calcular la prediccin resultante del atributo de
calidad evaluado.
Tabla 46: Pasos para la Evaluacin Basada en Modelos Matemticos
172
Entre los instrumentos que se cuentan para las tcnicas de evaluacin de
arquitecturas de software basada en modelos matemticos, se encuentran las
Cadenas de Markov y los denominados Reliability Block Diagrams.
8.2.4 Evaluacin basada en experiencia
En muchas ocasiones los arquitectos e ingenieros de software otorgan
valiosas ideas que resultan de utilidad para evitar decisiones erradas de diseo.
Aunque todas estas experiencias se basan en factores subjetivos como la intuicin
y la experiencia. Sin embargo, la mayora de ellas puede ser justificada por una
lnea lgica de razonamiento, y pueden ser la base de otros enfoques de
evaluacin.
Existen dos tipos de evaluacin basada en experiencia: la evaluacin
informal, que es realizada por los arquitectos de software durante el proceso de
diseo, y la realizada por equipos externos de evaluacin de arquitecturas. La
siguiente tabla muestra los instrumentos utilizados por las diferentes tcnicas de
evaluacin.
Tcnica de Evaluacin Instrumento de Evaluacin
Basada en Escenarios - Profiles
- Utility Tree
Basada en Simulacin - Lenguajes de Descripcin
Arquitectnica (ADL)
- Modelos de colas
Basada en Modelos
Matemticos
- Cadenas de Markov
- Reliability Block Diagrams
Basada en Experiencia - Intuicin y experiencia
- Tradicin
- Proyectos similares
Tabla 47: Instrumentos asociados a las distintas tcnicas de evaluacin de
arquitecturas de software
8.3 LECCIN 3: MTODOS DE EVALUACIN DE ARQUITECTURAS DE
SOFTWARE
Los mtodos de anlisis de arquitecturas de software hace que el proceso
sea repetible, y ayuda a garantizar que las respuestas correctas con relacin a la
arquitectura pueden hacerse durante las fases tempranas de diseo. Es en este
punto donde los problemas encontrados pueden ser solucionados de una forma
relativamente poco costosa. Un mtodo de evaluacin sirve de gua a los
involucrados en el desarrollo del sistema, en la bsqueda de conflictos que puede
presentar una arquitectura, y sus soluciones.
173
Actualmente existen mltiples mtodos de evaluacin han sido propuestos
para la evaluacin de la arquitectura del software. A continuacin se presentan
algunos de los ms importantes:
8.3.1 Software Architecture Analysis Method (SAAM)
El Mtodo de Anlisis de Arquitecturas de Software denominado SAAM, es
el primero que fue ampliamente promulgado y documentado. El mtodo fue
originalmente creado para el anlisis de la modificabilidad de una arquitectura,
pero en la prctica ha demostrado ser muy til para evaluar de forma rpida
distintos atributos de calidad, tales como modificabilidad, portabilidad,
escalabilidad e integrabilidad.
El mtodo de evaluacin SAAM, se enfoca en la enumeracin de un
conjunto de escenarios que representan los cambios probables a los que estar
sometido el sistema en el futuro. Como entrada principal, es necesaria alguna
forma de descripcin de la arquitectura a ser evaluada. Las salidas de la
evaluacin del mtodo SAAM son las siguientes:
- Una proyeccin sobre la arquitectura de los escenarios que representan los
cambios posibles ante los que puede estar expuesto el sistema
- Entendimiento de la funcionalidad del sistema, e incluso una comparacin de
mltiples arquitecturas con respecto al nivel de funcionalidad que cada una
soporta sin modificacin
Si se evala una sola arquitectura se obtienen los lugares en los que la
misma puede fallar, en trminos de los requerimientos de modificabilidad. Para el
caso en el que se cuenta con varias arquitecturas candidatas, el mtodo produce
una escala relativa que permite observar qu opcin satisface mejor los
requerimientos de calidad con la menor cantidad de modificaciones. Los pasos
que contempla el mtodo de evaluacin SAAM se muestran en la siguiente tabla:
1. Desarrollo de escenarios Un escenario es una breve descripcin de usos anticipados
odeseados del sistema. De igual forma, estos pueden incluir
cambios a los que puede estar expuesto el sistema en el futuro.
2. Descripcin de la
arquitectura
La arquitectura se descibe haciendo uso de alguna notacin
arquitectnica que sea comn a todas las partes involucradas en
el anlisis. Deben incluirse los componentes de datos y
conexiones relevantes, as como la descripcin del
comportamiento general del sistema.
3. Clasificacin y asignacin
de prioridad de los
escenarios
La clasificacin de los escenarios puede hacerse en dos clases:
Un escenario directo, que es el que puede satisfacerse sin la
necesidad de modificaciones en la arquitectura.
Un escenario indirecto, que es aquel que requiere modificaciones
174
en la arquitectura para poder satisfacerse.
Los escenarios indirectos son de especial inters para SAAM,
pues son los que permiten medir el grado en el que una
arquitectura puede ajustarse a los cambios de evolucin que son
importantes para los involucrados en el desarrollo.
4. Evaluacin individual de
los escenarios indirectos
Para cada escenario indirecto, se listan los cambios necesarios
sobre la arquitectura, y se calcula su costo. Una modificacin
sobre la arquitectura significa que debe introducirse un nuevo
componente o conector, o que alguno de los existentes requiere
cambios en su especificacin.
5. Evaluacin de la
interaccin entre escenarios
Cuando dos o ms escenarios indirectos proponen cambios sobre
un mismo componente, se dice que interactan sobre ese
componente. Es necesario evaluar este hecho, puesto que la
interaccin de componentes semnticamente no relacionados
revela que los componentes de la arquitectura efectan funciones
semnticamente distintas. De forma similar, puede verificarse si la
arquitectura se encuentra documentada a un nivel correcto de
descomposicin estructural.
6. Creacin de la evaluacin
global
Debe asignrsele un peso a cada escenario, en trminos de su
importancia relativa al xito del sistema. Esta asignacin de peso
suele hacerse con base en las metas del negocio que cada
escenario soporta. En el caso de la evaluacin de mltiples
arquitecturas, la asignacin de pesos puede ser utilizada para la
determinacin de una escala general.
Tabla 48: Pasos contemplados por el mtodo de evaluacin SAAM
8.3.2 Architecture Trade-off Analysis Method (ATAM)
El Mtodo de Anlisis de Acuerdos de Arquitectura denominado ATAM, est
inspirado en tres reas distintas: los estilos arquitectnicos, el anlisis de atributos
de calidad y el mtodo de evaluacin SAAM. El mtodo ATAM revela la forma en
que una arquitectura especfica satisface ciertos atributos de calidad, y provee una
visin de cmo los atributos de calidad interactan con otros; osea, los tipos de
acuerdos que se establecen entre ellos.
El mtodo se concentra en la identificacin de los estilos arquitectnicos o
enfoques arquitectnicos utilizados. Estos elementos representan los medios
empleados por la arquitectura para alcanzar los atributos de calidad, as como
tambin permiten describir la forma en la que el sistema puede crecer, responder
a cambios, e integrarse con otros sistemas. El mtodo de evaluacin ATAM
comprende nueve pasos, agrupados en cuatro fases. La siguiente tabla presenta
las fases y sus pasos enumerados, junto con su descripcin.
Fase 1: Presentacin
1. Presentacin del ATAM El lder de evaluacin describe el mtodo a los participantes,
trata de establecer las expectativas y responde las preguntas
propuestas.
2. Presentacin de las metas
del negocio
Se realiza la descripcin de las metas del negocio que
motivan el esfuerzo, y aclara que se persiguen objetivos de
tipo arquitectnico.
175
3. Presentacin de la
arquitectura
El arquitecto describe la arquitectura, enfocndose en cmo
sta cumple con los objetivos del negocio.
Fase 2: Investigacin y anlisis
4. Identificacin de los enfoques
arquitectnicos
Estos elementos son detectados, pero no analizados.
5. Generacin del Utility Tree Se elicitan los atributos de calidad que engloban la utilidad
del sistema (desempeo, disponibilidad, seguridad,
modificabilidad, usabilidad, etc.), especificados en forma de
escenarios. Se anotan los estmulos y respuestas, as como
se establece la prioridad entre ellos.
6. Anlisis de los enfoques
arquitectnicos
Con base en los resultados del establecimiento de prioridades
del paso anterior, se analizan los elementos del paso 4.
En este paso se identifican riesgos arquitectnicos, puntos de
sensibilidad y puntos de balance.
Fase 3: Pruebas
7. Lluvia de ideas y
establecimiento de prioridad de
escenarios.
Con la colaboracin de todos los involucrados, se
complementa el conjunto de escenarios.
8. Anlisis de los enfoques
arquitectnicos
Este paso repite las actividades del paso 6, haciendo uso de
los resultados del paso 7. Los escenarios son considerados
como casos de prueba para confirmar el anlisis realizado
hasta el momento.
Fase 4: Reporte
9. Presentacin de los
resultados
Basado en la informacin recolectada a lo largo de la
evaluacin del ATAM, se presentan los hallazgos a los
participantes.
Tabla 49: Pasos del mtodo de evaluacin ATAM
8.3.3 Active Reviews for Intermediate Designs (ARID)
El mtodo ARID es conveniente para realizar la evaluacin de diseos
parciales en las etapas tempranas del desarrollo. En ocasiones, es necesario
saber si un diseo propuesto es conveniente, desde el punto de vista de otras
partes de la arquitectura. ARID es un hbrido entre Active Design Review (ADR) y
Architecture Trade-Off Method (ATAM). ADR es utilizado para la evaluacin de
diseos detallados de unidades del software como los componentes o mdulos.
Las preguntas giran en torno a la calidad y completitud de la documentacin y la
suficiencia, el ajuste y la conveniencia de los servicios que provee el diseo
propuesto.
Tanto ADR como ATAM proveen caractersticas tiles para el problema de
la evaluacin de diseos preliminares. En el caso de ADR, los involucrados
reciben documentacin detallada y completan cuestionarios, cada uno por
separado. En el caso de ATAM, est orientado a la evaluacin de toda una
arquitectura.
Ante la necesidad de evaluacin en las fases tempranas del diseo, se
propone la utilizacin de las caractersticas que proveen tanto ADR como ATAM
176
por separado. De la combinacin de ambas filosofas surge ARID, para efecto de
la evaluacin temprana de los diseos de una arquitectura de software. La
siguiente tabla muestra los pasos del mtodo de evaluacin ARID, con una breve
descripcin de cada uno:
Fase 1: Actividades Previas
1. Identificacin de los
encargados de
la revisin
Los encargados de la revisin son los ingenieros de software
que se espera que usen el diseo, y todos los involucrados en
el diseo. En este punto, converge el concepto de encargado
de revisin de ADR e involucrado del ATAM.
2. Preparar el informe de
Diseo
El diseador prepara un informe que explica el diseo. Se
incluyen ejemplos del uso del mismo para la resolucin de
problemas reales. Esto permite al facilitador anticipar el tipo de
preguntas posibles, as como identificar reas en las que la
presentacin puede ser mejorada.
3. Preparar los escenarios
base
El diseador y el facilitador preparan un conjunto de
escenarios base. De forma similar a los escenarios del ATAM
y el SAAM, se disean para ilustrar el concepto de escenario,
que pueden o no ser utilizados para efectos de la evaluacin.
4. Preparar los materiales Se reproducen los materiales preparados para ser
presentados en la segunda fase. Se establece la reunin, y los
involucrados son invitados.
Fase 2: Revisin
5. Presentacin del ARID Se explica los pasos del ARID a los participantes.
6. Presentacin del diseo El lder del equipo de diseo realiza una presentacin, con
ejemplos incluidos. Se propone evitar preguntas que
conciernen a la implementacin o argumentacin, as como
alternativas de diseo. El objetivo es verificar que el diseo es
conveniente.
7. Lluvia de ideas y
establecimiento de
prioridad de escenarios
Se establece una sesin para la lluvia de ideas sobre los
escenarios y el establecimiento de prioridad de escenarios.
Los involucrados proponen escenarios a ser usados en el
diseo para resolver problemas que esperan encontrar.
Luego, los escenarios son sometidos a votacin, y se utilizan
los que resultan ganadores para hacer pruebas sobre el
diseo.
8. Aplicacin de los
escenarios
Comenzando con el escenario que cont con ms votos, el
facilitador solicita pseudo-cdigo que utiliza el diseo para
proveer el servicio, y el diseador no debe ayudar en esta
tarea. Este paso contina hasta que ocurra alguno de los
siguientes eventos:
- Se agota el tiempo destinado a la revisin
- Se han estudiado los escenarios de ms alta prioridad
- El grupo se siente satisfecho con la conclusin alcanzada.
Puede suceder que el diseo presentado sea conveniente,
con la exitosa aplicacin de los escenarios, o por el contrario,
no conveniente, cuando el grupo encuentra problemas o
deficiencias.
9. Resumen Al final, el facilitador recuenta la lista de puntos tratados, pide
opiniones de los participantes sobre la eficiencia del ejercicio
177
de revisin, y agradece por su participacin.
Tabla 50: Pasos del mtodo de evaluacin ARID
8.3.4 Modelo de Negociacin WinWin
El modelo WinWin provee un marco de referencia general para identificar y
resolver conflictos de requerimientos. El modelo utiliza la teora W, que pretende
que todo involucrado salga ganador. De esta forma, asiste a los involucrados en el
desarrollo a identificar y negociar distintos aspectos, reconciliando conflictos entre
las opciones de ganancias para todos.
Aunque el modelo propone la resolucin de posibles conflictos, no siempre
es posible llegar a un acuerdo. En este sentido, el mtodo CBAM provee medios
para establecer los balances necesarios, y un marco de referencia para la
discusin que puede llevar a una posible solucin del problema.
8.3.5 Cost-Benefit Analysis Method (CBAM)
El mtodo de anlisis de costos y beneficios denominado (CBAM), es un
marco de referencia que no toma decisiones por los involucrados en el desarrollo
del sistema. Uno de los elementos que introduce el mtodo son las llamadas
estrategias arquitectnicas, que consisten en posibles opciones para la resolucin
de conflictos entre atributos de calidad presentes en una arquitectura.
El mtodo CBAM abarca los siguientes aspectos: Seleccin de escenarios,
Evaluacin de los beneficios de los atributos de calidad, Cuantificacin de los
beneficios de las estrategias arquitectnicas, Cuantificacin de los costos de las
estrategias arquitectnicas y las implicaciones de calendario, Clculo del nivel de
deseabilidad y la Toma de decisiones. La siguiente tabla muestra los pasos
pertenecientes al marco de referencia para evaluacin de arquitecturas de
software para este mtodo:
1. Seleccin de escenarios Cada involucrado en el desarrollo identifica sus condiciones
de ganancia. Este paso provee las bases para la identificacin
de las caractersticas ideales del sistema esperadas por los
involucrados.
2. Identificacin de los
conflictos entre atributos de
calidad
La lista de condiciones de ganancia es revisada con la
intencin de identificar conflictos entre atributos de calidad.
Los conflictos son categorizados en directos o potenciales.
3. Exploracin de las opciones
en busca de la resolucin de
conflictos
Con base en los conflictos detectados en el paso anterior, los
involucrados pueden generar opciones de resolucin de
conflictos, o estrategias arquitectnicas.
4. Medicin de los beneficios
de los atributos de calidad
Para ayudar en el proceso de toma de decisiones, los
involucrados en el desarrollo deben calcular tanto los costos
como los beneficios de las estrategias arquitectnicas
elaboradas en el paso
178
anterior. Para esto, se calcula una escala de atributos de
calidad, donde se asigna un puntaje a cada atributo.
5. Cuantificacin de los
beneficios
Las escalas establecidas son utilizadas para la evaluacin de
las estrategias arquitectnicas planteadas en el paso 3. El
resultado de la evaluacin permite observar el beneficio de
cada uno de los cambios arquitectnicos propuestos.
6. Cuantificacin de costos e
implicaciones de calendario
En este paso se calculan los costos e implicaciones de
calendario que aplican para cada una de las estrategias
arquitectnicas propuestas en el paso 3. No se propone un
modelo especfico para la realizacin de la estimacin de
costos y tiempo.
7. Clculo del nivel de
Deseabilidad
Este paso contempla una mtrica especial, que se refleja
como el cociente entre los beneficios y los costos obtenidos.
Las estrategias arquitectnicas que resulten con valores
mayores se proponen como las ms recomendables.
8. Alcanzar un acuerdo La recomendacin general es la documentacin del proceso.
La acumulacin de evidencia permite el establecimiento de un
posible consenso, a la hora de la toma de decisiones sobre la
arquitectura de un sistema de software.
Tabla 51: Pasos del mtodo de evaluacin CBAM
8.3.6 Mtodo Diseo y Uso de Arquitecturas de Software propuesto por
Bosch
Bosch plantea, en su mtodo de diseo de arquitecturas de software, que el
proceso de evaluacin debe ser visto como una actividad iterativa, que forma parte
del proceso de diseo, tambin iterativo. Una vez que la arquitectura es evaluada,
pasa a una fase de transformacin, asumiendo que no satisface todos los
requerimientos. Luego, la arquitectura transformada es evaluada de nuevo. El
proceso de evaluacin propuesto por Bosch se divide en dos etapas, que son
presentadas en la siguiente tabla:
Etapa I
1. Seleccin de atributos de
calidad
Deben seleccionarse aquellos atributos que se consideran
cruciales para el xito del sistema, y cuya satisfaccin
resulte poco clara a nivel de arquitectura. Resulta necesario
porque es poco factible y poco til evaluar todos los
atributos de calidad, dado que requiere una gran cantidad
de tiempo.
2. Definicin de los perfiles Para cada atributo de calidad seleccionado, se definen los
perfiles respectivos para efectos de la evaluacin.
3. Seleccin de una tcnica de
evaluacin
Para la evaluacin de los atributos de calidad dependientes
del diseo de la arquitectura se recomienda utilizar la
evaluacin basada en escenarios, as como tambin los
modelos basados en mtricas o modelos matemticos.
Los atributos de calidad operacionales (observables va
ejecucin) pueden evaluarse con tcnicas de simulacin o
modelos matemticos. La seleccin de la tcnica, y la
implementacin concreta de sta depende del objetivo y
exactitud de la evaluacin.
Etapa II
4. Ejecucin de la evaluacin Para cada atributo de calidad, las tcnicas arrojan valores
179
cuantitativos.
5. Obtencin de resultados Los resultados se resumen en una tabla que contiene el
nivel requerido, el nivel predicho, y un indicador, que puede
tener diversos significados: si el atributo se satisface o no, si
necesita ser negociado con el cliente, o existencia de alguna
relacin negativa con otro atributo de calidad. El arquitecto
puede decidir acerca de la realizacin de transformaciones
sobre la arquitectura actual, y efectuar una nueva
evaluacin. Una vez que concluye el proceso de evaluacin,
con los resultados obtenidos es posible decidir entre la
continuacin, renegociacin o cancelacin del proyecto.
Tabla 52: Etapas contempladas por el mtodo de evaluacin de arquitecturas
propuesto por Bosch
8.3.7 Mtodo de Comparacin de Arquitecturas Basada en el Modelo
ISO/IEC 9126 Adaptado para Arquitecturas de Software
Losavio proponen un mtodo para evaluar y comparar arquitecturas de
software candidatas, que hace uso del modelo de especificacin de atributos e
calidad adaptado del modelo ISO/IEC 9126. Para la evaluacin se plantea la
especificacin de los atributos de calidad haciendo uso de un modelo basado en
estndares internacionales ISO/IEC 9126 que ofrecen una vista amplia y global de
los atributos de calidad, tanto a usuarios como arquitectos del sistema, para
efectos de la evaluacin. El mtodo contempla siete actividades que son
mostradas y descritas en la siguiente tabla:
Actividades
1. Analizar los requerimientos funcionales y no funcionales principales del sistema, para
establecer las metas de calidad
2. Utilizar el modelo de calidad ISO/IEC 9126 adaptado para arquitecturas de software. Algunas
mtricas pueden definirse con mayor nivel de detalle
3. Presentar las arquitecturas candidatas iniciales
4. Construir la tabla comparativa para las arquitecturas candidatas
5. Establecer prioridades para las subcaractersticas de calidad tomando en cuenta los
requerimientos de calidad del sistema
6. Analizar los resultados obtenidos y resumidos en la tabla, de acuerdo con las prioridades
establecidas
Tabla 53: Actividades del Mtodo de Comparacin de Arquitecturas Basado en el
Modelo ISO/IEC 9126 Adaptado para Arquitecturas de Software de Losavio
8.4 LECCIN 4: MTODOS DE EVALUACIN DE ARQUITECTURA DE UN
ATRIBUTO ESPECFICO
180
Existen otros mtodos de evaluacin de arquitectura del software, que evalan
solamente uno de los atributos de calidad especficado por el evaluador, algunos
de ellos son:
8.4.1 Architecture Level Modifiability Analysis ALMA
Este mtodo es el resultado de los trabajo de investigacin de Brengtsson y
Lassing, el atributo de calidad que analiza este mtodo es la facilidad de
modificacin, este atributo se refiere a la capacidad de un sistema para ser
ajustado debido a cambios en los requerimientos, o en el entorno, as como la
adicin de nuevas funcionalidades.
ALMA es un mtodo de evaluacin orientado a metas, que se apoya en el
uso de escenarios de cambio, los cuales escriben los eventos posibles que
provocaran cambios al sistema, y como se llevaran a cabo estos. El mismo
consta de cinco pasos como se muestran en la siguiente figura:
Figura 33: Mtodo de evaluacin de arquitecturas ALMA
8.4.2 Performance Assessment of Software Architecture PASA
PASA es el resultado del trabajo de Williams y Smith, el mismo utiliza
diversas tcnicas de evaluacin, tales como la aplicacin de estilos
181
arquitectnicos, anti-patrones, guas de diseo y modelos. El atributo de calidad
que analiza este mtodo es el desempeo, se interesa en saber qu tanto tiempo
le toma al sistema software responder cuando una o varios eventos ocurren, as
como determinar el nmero de eventos procesados en un intervalo de tiempo
dado.
Este mtodo tambin se basa en escenarios y puede aplicarse de forma
temprana o tarda. Los escenarios generados en este mtodo sirven como punto
de partida para la construccin de modelos de desempeo. Uno de los requisitos o
precondiciones es que la arquitectura debe estar previamente documentada y en
caso de que no est completa se debe extraer el resto de la informacin a los
miembros del equipo.
Figura 34: Mtodo de evaluacin de arquitecturas PASA
8.4.3 Scenario based Architecture Level Usability Analysis SALUTA
Es el primer mtodo desarrollado para evaluar arquitecturas desde la
perspectiva de la facilidad del uso del sistema, siendo el resultado de los estudios
de Folmer y Gurp. Este mtodo hace uso de marcos de referencia que expresan
las relaciones que existen entre facilidad de uso y Arquitectura de Software.
Dichos marcos de referencias incluyen un conjunto integrado de soluciones de
diseo como patrones de diseos u propiedades que tienen un efecto positivo
sobre la facilidad de uso en un sistema software.
SALUTA analiza cuatro atributos que estn directamente relacionados con
la facilidad de uso de un sistema de software: Facilidad de aprendizaje, Eficiencia
182
de uso, Confiabilidad y Satisfaccin. El mtodo se basa en escenarios, que en
este caso, son escenarios de uso que agrupan uno a ms perfiles de uso valga la
redundancia, donde cada uno representa la facilidad de uso requerida por el
sistema. Se recomienda utilizarlo una vez que se ha especificado la arquitectura,
pero antes de implementarla. La siguiente figura muestra los cuatro pasos del
mtodo:
Figura 35: Mtodo de evaluacin de arquitecturas SALUTA
8.4.4 Survivable Network Analysis SNA
Es un mtodo desarrollado por el CERT (Computer Emergency Response
Team) que forma parte del SEI (Software Engineering Institute). Este mtodo
ayuda a identificar la capacidad de supervivencia en un sistema, analizando su
arquitectura. La supervivencia es la capacidad que tiene un sistema para
completar su misin a tiempo, ante la presencia de ataques, fallas o accidentes.
Para evaluar esta supervivencia SNA utiliza tres propiedades claves: Resistencia,
Reconocimiento y Recuperacin.
Este procedimiento puede ser realizado despus de la especificacin de la
arquitectura, durante la implementacin de esta, o posteriormente. SNA se basa
en la tcnica de escenarios de uso, e identifica dos tipos de escenarios:
Escenarios normales, que se componen de una serie de pasos donde los usuarios
invocan servicios y obtienen acceso a activos, tales como bases de datos,
Escenarios de intrusin, en los que se representan diferentes tipos de ataques al
sistema. En la siguiente tabla se muestra cada uno de los pasos del mtodo:
183
Figura 36: Mtodo de evaluacin de arquitecturas SNA
La siguiente tabla muestra una tabla comparativa de cada uno de los mtodos de
evaluacin de arquitectura mencionados anteriormente:
ALMA PASA SALUTA SNA
Meta Predecir el costo
de mantenimiento,
evaluar riesgos,
comparacin entre
arquitecturas
Analizar la
arquitectura con
respecto a los
objetivos de
desempeo de un
sistema
Predecir la
facilidad de uso
de un sistema
analizando la
arquitectura
Identificar la
capacidad de
supervivencia de
un sistema ante
presencia de
ataques, fallas o
accidentes
Atributo de
calidad
Facilidad de
modificacin
desempeo Facilidad de uso supervivencia
Tcnica de
evaluacin
Escenarios de
cambio
escenarios Escenarios de
uso
Escenarios de
uso normales y
escenarios de
intrusin
entradas Especificacin de
la arquitectura,
requerimientos no
funcionales
Especificacin de
la arquitectura
Especificacin de
la arquitectura,
requerimientos
no funcionales
relacionados con
la facilidad de
uso
Especificacin de
la arquitectura
184
salidas Dependiendo de la
meta de
evaluacin se
generan los
resultados
Hallazgos
encontrados, pasos
especficos a
seguir y
recomendaciones
Grado de
facilidad de uso
que soporta la
arquitectura
evaluada
Modificaciones
recomendadas
de la arquitectura
y mapa de
supervivencia
Personas
involucradas
Arquitecto y
equipo de
desarrollo
Arquitecto, equipo
de desarrollo y
administradores del
proyecto
Arquitecto,
ingenieros de
requerimientos o
ingenieros
responsables por
la facilidad de
uso
Arquitecto,
diseador
principal,
propietarios del
sistema, usuarios
Duracin No especificado 7 das No especificado No especificado
Validacin
del mtodo
Sistemas de
control embebido,
sistemas mdicos,
telecomunicacione
s, sistemas
administrativos
Sistemas basados
en la web,
aplicaciones
financieras, y
sistemas en tiempo
real
Algunos casos de
estudio que
incluyen
principalmente
sistemas web
Sistemas
comerciales y de
gobierno
Tabla 54: Comparacin entre los mtodos ALMA, PASA, SALUTA y SNA.
8.5 LECCIN 5: MTODO DE EVALUACIN DE ARQUITECTURA MECABIC
MECABIT es uno de los mtodos para evaluar Arquitecturas de Software
Basadas en Componentes con el objetivo de que sea aplicado en Arquitecturas
Orientadas a Servicios. Este anlisis se realiza desde el punto de vista, que bajo
ciertas y determinadas situaciones o condiciones, se puede ver un servicio como
un componente.
El MECABIC est inspirado en ATAM, al mtodo se le incluyeron en
algunos de sus pasos un enfoque de integracin de elementos de diseo,
inspirado en la construccin de partes arquitectnicas adoptado por el Architecture
Based Design (ABD). Adems se propone un rbol de utilidad inicial basado en el
modelo de calidad ISO/IEC 9126 instanciado para Arquitectura de Software
propuesto por Losavio. La adopcin de este modelo por parte del MECABIC
permite concentrarse en caractersticas que dependen exclusivamente de la
arquitectura, y al ser un estndar facilita la correspondencia con caractersticas de
calidad consideradas por los mtodos estudiados. Los escenarios incluidos en
este rbol son especficos para aplicaciones basadas en componentes.
En el mtodo MECABIC participan tres grupos de trabajo: Los arquitectos,
el evaluador y los relacionados. Para la especificacin de la calidad se hace uso
de un rbol de utilidad, el cual tiene como nodo raz la bondad o utilidad del
sistema. En el segundo nivel del rbol se encuentran los atributos de calidad. Las
hojas del rbol de utilidad son escenarios, los cuales representan mecanismos
mediante los cuales extensas declaraciones de cualidades son hechas especficas
y posibles de evaluar. La generacin del rbol de calidad incluye un paso que
permite establecer prioridades. Para el anlisis de la arquitectura se utiliza la
185
tcnica de escenarios, soportada por cuestionarios, para identificar lo que desean
los participantes. La siguiente tabla muestra los participantes en el mtodo
MECABIT:
Equipo Definicin Fases en las
que participan
Arquitectos Responsables de generar y documentar una Arquitectura
de Software para el sistema estudiado.
Todas
Evaluador Integrado por personas expertas en asuntos de calidad
quienes guiarn el proceso de evaluacin de la
arquitectura
Todas
Relacionados Son las personas involucradas de alguna manera con el
sistema: programadores, usuarios, gerentes, entre otros.
Fases 1, 3 y
4.
Tabla 55: Grupos de Trabajo en el Mtodo MECABIT.
8.5.1 Fases del Mtodo
El mtodo consta de cuatro fases, la de presentacin, la de investigacin y
anlisis, la de prueba y la presentacin de resultados. A continuacin se describe
cada una de las fases:
8.5.1.1 Fase1 Presentacin: En esta fase se da a conocer el mtodo entre
todos los grupos, el sistema y su organizacin, y finalmente se presenta cul es la
arquitectura que debe ser evaluada. En esta fase se realiza una presentacin del
mtodo MECABIC para que los participantes comprendan en qu punto de la
aplicacin del mtodo se encuentran en cada momento.Tambin se da a conocer
la arquitectura inicial a evaluar y qu caractersticas de calidad se esperan lograr.
8.5.1.2 Fase2 Investigacin y Anlisis: En esta fase se determina de qu
manera se va estudiar la arquitectura, se pide a las personas que estn
relacionadas con el sistema, ya sea un desarrollador, usuario o gerente, que
expresen de una manera precisa que escenarios de calidad se desean y se
analiza si la arquitectura es apropiada o se requieren modificaciones para que lo
sea. En esta fase slo participan el grupo evaluador y grupo de arquitectos. En
esta fase se identifican elementos de diseo que ayuden a analizar la arquitectura,
se especifican los requerimientos planteados durante el paso 2 y se analiza cmo
responden los elementos de diseo considerados a los requerimientos.
8.1.1.3 Fase3 - Prueba: Consiste en la revisin de la segunda fase y en ella
participan todos los grupos.
8.1.1.4 Fase4 Presentacin de Resultados: En la ltima fase se lleva a cabo a
presentacin de los resultados. En esta fase participan todos los grupos. Fase de
Generacin de la arquitectura final y reporte. En este momento se cuenta ya con
un anlisis de todas las decisiones que se han producido hasta el momento. Si no
186
hay conflictos y se puede concluir que existe una arquitectura adecuada para los
requerimientos de calidad de las personas involucradas en la evaluacin, entonces
se puede pasar al paso 10 directamente. Si por el contrario en algn elemento de
diseo existen decisiones en las que resulte favorecido algn requerimiento,
entonces los usuarios y desarrolladores son los que tienen que determinar o
acordar cules requerimientos favorecer.
En la siguiente tabla se muestra el mtodo MECABIT, con cada una de las fases y
el detalle de los pasos que se deben dar para la aplicacin del mtodo:
Fase 1: Fase de presentacin
1. Presentacin del mtodo. En el primer paso el director de evaluacin presenta el mtodo
ante los participantes con el proyecto. Se explica el proceso que
debe cumplir cada participante del proyecto, se responden
preguntas y se establecen las expectativas y el contexto sobre
las actividades o tareas restantes. La finalidad es que todas las
personas involucradas en el sistema comprendan la secuencia
de los pasos a seguir, los instrumentos utilizados en cada paso
y las salidas del mtodo. Se pide a las personas que comenten
sus expectativas o que hagan preguntas particulares acerca de
lo que esperan de la aplicacin del mtodo.
2. Presentacin de las
directrices del negocio.
Cada persona que posee una responsabilidad sobre la
evaluacin, necesitan comprender el contexto del sistema y los
aspectos primarios del contexto del negocio que motivan su
desarrollo. Se explica a las personas el contexto del sistema y
los requerimientos del negocio dentro del cual va a funcionar el
sistema. Algunos tpicos que debera contener esta
presentacin son: las funcionalidades ms importantes del
sistema, los objetivos del negocio y el contexto relacionado con
el proyecto, el grupo dirigente de los desarrolladores y usuarios,
las directrices arquitectnicas, restricciones tcnicas,
gerenciales, econmicas y polticas y obertura de la evaluacin
y lmites del sistema.
3. Presentacin de la
arquitectura.
El arquitecto o grupo de representantes explican a las personas
como desarrollador, usuario o gerente, cul es la arquitectura
evaluada. Debe contener una clara diferenciacin estructural, la
cual deber mostrar claramente las relaciones entre
componentes de la arquitectura y las diferentes granularidades
involucradas. El arquitecto cubre restricciones tcnicas y los
alcances arquitectnicos usados para alcanzar los
requerimientos. El arquitecto debe transmitir lo esencial y de
esta manera abreviada la informacin de la arquitectura que
requiere el equipo.
Fase2: Investigacin y Anlisis
4. Identificacin de
elementos de diseo.
Contemplan alternativas de diseo de la arquitectura, que
posteriormente sern analizadas para ver cmo responden a los
requerimientos de calidad. La arquitectura debe ser evaluada
completamente desde el sistema con sus componentes de
mayor granularidad, hasta el mnimo nivel de granularidad que
corresponde a los componentes. Se propone identificar
elementos de diseo dentro de una arquitectura basada en
componentes, como un componente, y el conjunto de
componentes con los cuales interacta, un conjunto de
asociaciones que sea de inters sobre alguna caracterstica de
187
calidad particular o conjunto de decisiones que tenga influencia
considerable sobre otros elementos de diseo. Para identificar
un elemento de diseo se considera los servicios ofrecidos por
los componentes disponibles y las diferentes opciones para
definir los servicios de los componentes desarrollados para el
sistema. La manera de documentar los elementos de diseo
depende de la importancia que pueda tener dentro de la
evaluacin, del conjunto de decisiones o adaptaciones a
realizar, y del conocimiento de las personas que estn
relacionadas con el sistema y estn en la evaluacin.
5. Generacin del rbol de
utilidad.
El rbol de utilidad inicial especifico a partir del cual seleccionan
un conjunto de escenarios de inters, est basado en el modelo
de calidad ISO/IEC 9126-1 para arquitecturas de software. Se
asume que al aplicar el mtodo, las funcionalidades presentes
en el sistema son las que necesitan los usuarios, y no se incluye
escenarios de aptitud (subcaracterstica de funcionalidad).
Posteriormente, se consideran escenarios no contemplados en
el rbol inicial de utilidad. En este paso el grupo evaluador
presenta los diferentes escenarios a considerar al resto de los
participantes y se decide cules son los que sern incluidos en
el rbol de utilidad. Este paso brinda la posibilidad de verificar si
es necesario incluir en el rbol de utilidad algn otro escenario.
La seleccin del resto de los escenarios puede realizarse por
votacin como propone originalmente el ATAM. Luego se
organizan los escenarios de calidad introducidos no
contemplados en la tabla de generacin del rbol de utilidad
inicial por caractersticas de calidad. Posteriormente, se procede
a priorizarlos, es decir, ordenar los escenarios ya que de esta
manera se puede tener una orientacin para tomar decisiones
arquitectnicas, y personas pueden determinar de lo que
esperan del sistema, y obtener una idea sobre en qu medida
va a ser satisfecho.
Posteriormente se procede a asignar un orden a los escenarios
de calidad de un sistema utilizando dos criterios: Evaluar el
riesgo de no considerar el escenario donde se responde las
preguntas: qu pasa si este escenario no se cumple?,
cuntas personas se ven afectadas?, es posible compensar
el no responder a este escenario?), Evaluar el esfuerzo
necesario para lograr cumplir con el escenario (se determina
que cambios o integraciones de nuevos componentes se deben
realizar para satisfacer el escenario).
Finalmente, se construye el rbol de utilidad con las salidas del
paso anterior. La prioridad del escenario define en este mtodo
como un par (X, Y) en el cual X define el esfuerzo de satisfacer
el escenario, y la Y indica los riesgos que se corren al excluirlos
del rbol de utilidad. Los posibles valores para X e Y son A
(Alto), B (Bajo) y M (Medio).
6. Anlisis de elementos de
diseo para ASBC.
Se analizan los elementos de diseo identificados en el paso 4 o
de nuevos elementos de diseo que puedan ser identificados,
para determinar cmo influyen sobre la realizacin de los
escenarios de calidad presentes en el rbol de utilidad generado
en el paso 5.
188
Los componentes proveen un conjunto de puertos que se deben
ir extendiendo para proporcionar nuevos servicios, los cuales a
su vez pueden ser ofrecidos para que otros componentes los
extiendan. Se debe evaluar un conjunto de opciones que
indiquen una manera de definir una relacin entre puertos, de
acuerdo a algn criterio de calidad. Los escenarios de calidad
deben ser aplicados a la arquitectura que ha sido generada. El
equipo de evaluacin se orienta con las preguntas de anlisis
propuestas por el mtodo para determinar decisiones sobre la
arquitectura. Se debe preguntar si las decisiones tomadas
permiten alcanzar los escenarios de calidad planteados. Si la
respuesta es negativa se deben reconsiderar cualquiera de las
decisiones que han sido hechas. Las decisiones identificadas
anteriormente, pueden relacionarse con determinados
elementos de diseo. Se deben estudiar los riesgos que
introduce la decisin en particular, o si sta contribuye a algn
riesgo ya determinado. Tambin se pueden documentar
decisiones que no han sido tomadas o asuntos no resueltos que
a juicio del equipo de evaluacin pueden ser resueltos en un
futuro estudiando con ms detalle el elemento de diseo
considerado.
Fase3: prueba
7. Revisin del rbol de
utilidad.
Se propone utilizar escenarios de calidad para representar los
intereses de todos los grupos de la evaluacin y confirmar que
se han evaluado los requerimientos deseados de calidad. El
equipo de evaluacin puede facilitar la elaboracin de
escenarios haciendo uso del conjunto de pasos propuestos en el
paso 6. Los escenarios del rbol de utilidad que no hayan sido
considerados, son colocados por las personas como
desarrolladores y usuarios en el paquete de tormenta de ideas,
lo que les da la oportunidad de revisar escenarios poco
atendidos. Los escenarios generados se comparan con la lista
inicialmente considerada en el rbol de utilidad. En caso de que
la consideracin y priorizacin coincida, entonces se puede
decir los escenarios evaluados son adecuados para el grupo de
interesados en el sistema. Cuando no se logra un acuerdo entre
los dos grupos de desarrolladores y usuarios posiblemente no
se representaron adecuadamente los intereses de los
involucrados. Los desarrolladores deben analizar tambin los
escenarios que ya han sido evaluados, para verificar que hayan
recibido la importancia adecuada.
Una vez que el nuevo escenario ha sido considerado se pueden
presentar tres casos: El escenario duplica un escenario ya
considerado en el rbol de utilidad, El escenario pasa a ser una
hoja de una rama ya existente, No existe rama para el escenario
debido a que no haba sido considerado previamente. Los
primeros dos casos sugieren que la arquitectura de software ha
sido creada de acuerdo con las expectativas de los usuarios,
mientras que en el tercer caso, se ha fallado al considerar algn
aspecto de calidad importante y puede existir un riesgo a
documentar.
8. Revisin de los elementos
de diseo definidos.
El equipo evaluador debe estudiar de qu manera los elementos
de diseo analizados en el paso 6, promueven los escenarios
propuestos por el nuevo grupo de usuarios y desarrolladores. En
189
caso que no promuevan las caractersticas de calidad deseadas,
deben ser reconsiderados.
Fase4: Presentacin de los resultados
9. Generacin de los
acuerdos.
Se decide cul ser la arquitectura adoptada por el sistema.
Para ello se debe buscar un consenso en cuanto a las opciones
que existan, en caso de que no se haya identificado alguna
notablemente mejor. Si existen requerimientos de calidad que
no han sido logrados se debe brindar la posibilidad de replantear
los requerimientos de calidad que no hayan podido ser
alcanzados, para aprovechar posibles ventajas de la
arquitectura. Esta es una negociacin crtica, ya que de fallar,
implicara la necesidad de replantear la arquitectura, y de tener
xito hay que cuidar que los requerimientos de calidad no
resueltos sean equivalentes, para que los usuarios y
desarrolladores estn contentos con el sistema. Finalmente, se
documentan todos aquellos requerimientos de calidad para los
cuales no es posible encontrar una solucin, justificando las
razones.
10. Presentacin de los
resultados.
Se presenta un resumen de la aplicacin del mtodo, de forma
oral y/o escrita. Se deben incluir entonces, los siguientes
documentos a partir de los cuales se inici la evaluacin:
a) Contexto del negocio.
b) Requerimientos de Calidad.
c) Restricciones.
d) Arquitectura producida.
e) Anlisis de elementos de diseo identificados.
f) Conjunto de escenarios negociados.
g) Conjunto de preguntas para evaluacin de atributos.
h) rbol de Utilidad.
i) No-riesgos documentado.
j) Puntos sensibles y de negociacin.
Tabla 56: Fases Contempladas en el Mtodo de evaluacin de Arquitecturas
MECABIT.
La generacin del rbol de utilidades, descrito en el punto 5 de la fase 2,
acerca de la Investigacin y Anlisis, del mtodo es tomada de acuerdo a la norma
ISO/IEC 9126 y adaptada para la evaluacin de la arquitectura de software. A
continuacin se muestra el rbol de utilidad aplicado para el mtodo MECABIT.
Caracterstica Sub-caracterstica Escenario
El sistema posee componentes capaces de leer
datos provenientes de otros sistemas.
Interoperabilidad
El sistema posee componentes capaces de producir
datos para otro sistema.
Los resultados ofrecidos por los componentes
sistema son exactos.
Precisin
La comunicacin entre los componentes no altera la
exactitud de los datos
Funcionalidad
Seguridad El sistema detecta la actuacin de un intruso e
190
impide acceso a los componentes que manejen
informacin sensible
El sistema asegura que los componentes no pierdan
datos ante un ataque (interno o externo).
Los componentes respetan un estndar de
fiabilidad.
Obediencia
(Compliance)
La comunicacin entre los componentes no viola los
estndares de fiabilidad.
Madurez Los componentes del sistema manejan entradas de
datos de datos incorrectas.
Tolerancia a fallas Todas las operaciones ejecutadas por los
componentes se realizan correctamente bajo
condiciones adversas.
Los componentes del sistema no fallan bajo ciertas
condiciones especificadas.
Fiabilidad
Capacidad de
restablecimiento o
recuperacin Ante problemas con el ambiente un subconjunto
determinado de los componentes puede continuar
prestando sus servicios.
Tiempo de
comportamiento
El sistema debe recibir los servicios de sus
componentes en el transcurso de un tiempo
indicado.
Los componentes pueden compartir recursos
adecuadamente.
Eficiencia
Recursos utilizados
El sistema controla que ningn componente se
quede sin recursos cuando los necesita.
Es posible verificar el estado de los componentes
del sistema.
El sistema brinda facilidad para adaptar un
componente.
Mantenibilidad Habilidad de cambio,
estabilidad, prueba
El sistema debe facilitar la sustitucin/adaptacin de
un componente.
Adaptabilidad El sistema debe continuar funcionando
correctamente aun cuando los servicios de los
componentes provistos por el ambiente varen.
Capacidad de
Instalacin
Los componentes pueden instalarse fcilmente en
todos los ambientes donde debe funcionar.
Portabilidad
Co-existencia Los componentes manejan adecuadamente
recursos compartidos del sistema.
Tabla 57: Subconjunto del rbol de Utilidad Iinicial Propuesto por el Mtodo
MECABIT
A continuacin tambin se presenta una tabla de preguntas sobre los
elementos de revisin del diseo identificados en el punto 8 de la fase 3, del
mtodo MECABIT.
Caracterstica Sub-caracterstica Preguntas de anlisis
Precisin Puede la comunicacin entre los
componentes introducir imprecisiones en los
servicios ofrecidos por los componentes?
Funcionalidad
Interoperabilidad Dnde se encuentran los componentes que
permiten al sistema interactuar con otros
sistemas?
191
Madurez Existen decisiones para minimizar el manejo
incorrecto de datos en la comunicacin entre
componentes?
Fiabilidad
Tolerancia a fallas Cmo se detecta el funcionamiento
incorrecto de un componente?
Eficiencia Tiempo de
comportamiento
Cmo es la relacin entre el nmero de
componentes de las diferentes partes de la
arquitectura?
Cmo se verifica el funcionamiento correcto
de un componente?
Cmo se verifica el estado de una
comunicacin entre componentes?
Mantenibilidad Habilidad de cambio,
estabilidad, prueba
Cmo se facilita el reemplazo de un
componente?
Capacidad de
Instalacin
Existe un mecanismo para determinar si
todos los componentes del sistema se
encuentran correctamente instalados?
Portabilidad
Co-existencia Existe alguna manera de identificar las
reglas para interactuar con componentes de
sistemas externos a la arquitectura?
Tabla 58: Algunas Preguntas para Analizar los Elementos de Diseo Identificados
192
CAPITULO 3
APLICACIONES DE EVALUACIN
DEL SOFTWARE
193
INTRODUCCIN
La industria de software cada vez esta ms consolidada y ofrece un
sinnmero de productos que pretenden satisfacer las necesidades en
diversos campos, y por eso es necesario que se tome en consideracin las
diversas metodologas de evaluacin que estn surgiendo, ya que cada una
de ella pretende evaluar productos software especficos.
Actualmente el campo de la evaluacin de software ha adquirido mayor
madurez y debe responder a la medicin de calidad de cada uno de los
productos y del proceso de construccin, es por eso que en este captulo se
tratan dos aplicaciones la primera esta relacionada conla evaluacin del
proceso y es la aplicacin de la evaluacin a los diseos UML y la segunda
aplicada a uno de los productos que adquiere una importacia significativa
aplicada al campo educativo, son los productos software que de alguna
manera complementan o suplen la educacin presencial.
A continuacin se describir algunos de los metodos para realizar la
evaluacin UML y los modelos ms reconocidos para la evaluacin de los
productos software educativos multimedia.
194
9.1 LECCIN 1: METODOLOGA PARA LA EVALUACIN DE LA
CALIDAD EN LOS MODELOS UML
El campo de l a calidad de las especificaciones y ms concretamente,
en la calidad de los modelos UML, es relativamente nuevo y solo desde 1998 se
contemplan propuestas sobre la calidad en el modelado con UML, este tema es
de suma actualidad y relevancia, pero carece todava de suficiente madurez. Por
eso, se ha elaborado en esta leccin un seguimiento a una de las metodologas de
evaluacin de la calidad en los modelos UML, enmarcada dentro del proyecto
denomi nado EVVE Entorno para la Verificacin y Validacin de
Especificaciones software.
A partir de los principales estndares, normas y metodologas existentes
en la actualidad relacionados con la evaluacin del software, se ha elaborado l a
met odol og a EVVE, analizando las caractersticas clave de cada uno de
ellos y seleccionando, adaptando e integrando los aspectos ms relevantes.
Las principales caractersticas de la metodologIa EVVE, se pueden
resumir en los siguientes principios bsicos: Est formada por un conjunto
estructurado de procesos, Est orientada a la relacin con el cliente y a la
externalizacin de la evaluacin de calidad, Est pensada para ser una
metodologIa fcilmente adaptable, y Est soportada por un conjunto de tcnicas y
herramientas.
La metodologa EVVE proporciona un marco de trabajo donde se
identifica claramente el qu, cundo, y el quin, de cada una de las fases y
actividades de los procesos, as como la secuencia de pasos que se debe
seguir a la hora de llevar a cabo la evaluacin. Adems, est orientada a la
relacin con el cliente de manera que el cliente se encuentra involucrado en la
toma de decisiones. La metodologa contempla el modo de trabajo
externalizado, de manera que para realizar la evaluacin no sea necesario
encontrarse en las instalaciones del cliente, sino que se pueda planificar,
disear y realizar la evaluacin externamente, ponindose en contacto con el
cliente en los momentos puntuales en los que sea necesario.
La metodologa de evaluacin EVVE, puede ser adaptada a las distintas
necesidades del cliente, existiendo unos catlogos de tcnicas de evaluacin
que determinan el nivel y profundidad con el que se desea realizar la
evaluacin, las mtricas de calidad que se obtendrn y las herramientas de
evaluacin que se utilizarn.
La metodologa EVVE def i ne un marco de trabajo que permite determinar
los procesos para llevar a cabo la evaluacin de los modelos UML del software.
La metodologa, en un principio estaba pensada para trabajar con diagramas
de casos de uso, diagramas de clases, y diagramas de transicin de estados. La
195
metodologa de evaluacin EVVE se puede aplicar a cualquier modelo de anlisis
y diseo, siempre que est especificado bajo la notacin UML. Adems puede
ser utilizada independientemente del modelo de ciclo de vida de desarrollo
seguido por la empresa cliente. De manera que no existe un proceso, fase,
actividad o tarea del ciclo de vida a partir del cual se pueda empezar a
aplicar la metodologa de evaluacin.
9.1.1 Personas, Grupos y Roles
A continuacin se detallan los roles y grupos identificados a lo largo del
proceso de evaluacin, as como las principales tareas y responsabilidades de
cada uno de ellos. En la siguiente figura se observa los roles involucrados en el
proceso de evaluacin segn la metodologa EVVE, as como la relacin que
existe entre ellos:
Figura 37: Roles y relaciones en el proceso de evaluacin.
Tal y como se aprecia en la figura, la comunicacin entre las empresas
(cliente y evaluadora) es realizada a travs del patrocinador y del evaluador jefe.
stos a su vez sern los que se comuniquen directamente con sus equipos
internos. A continuacin se muestra en una tabla los roles y grupos involucrados
en la metodologa EVVE.
Roles y Grupos Descripcin
Empresa cliente Representa a la organizacin que ha expresado su
intencin y/o necesidad de contratar los servicios de
evaluacin de la calidad de los modelos UML.
Patrocinador de la
evaluacin
El patrocinador de la evaluacin es el representante
de la empresa cliente que se pone en contacto con la
empresa evaluadora para expresar la necesidad de
evaluacin de la calidad de sus modelos UML. En algunos
196
casos, el patrocinador de la evaluacin podr disponer de
un equipo de trabajo interno formado por personal propio
de la empresa.
Equipo de la empresa cliente Sirve de apoyo al patrocinador de la evaluacin. Su
principal responsabilidad consiste en analizar los
resultados reportados por la empresa evaluadora para
detectar defectos o inconsistencias. La existencia de este
equipo no es necesaria siempre, depende de la
envergadura del proyecto a evaluar.
Empresa evaluadora Representa la organizacin que ha sido contratada para
llevar a cabo el proceso de evaluacin. La empresa
evaluadora necesitar disponer de un evaluador jefe y uno o
varios evaluadores que formaran el equipo de trabajo que
llevar a cabo el proceso de evaluacin.
Evaluador jefe Es el representante de la empresa evaluadora y lder del
equipo de evaluacin, cuyo objetivo es asegurar el
correcto desarrollo del proceso de evaluacin. Este rol
debe ser ocupado por un profesional con conocimientos en
el anlisis y diseo con UML y con experiencia en la
prctica de las principales normas y estndares sobre
evaluacin del producto y procesos software.
Evaluador Est encargado de realizar las actividades y tareas
propias del proceso de evaluacin. Este rol deber
ser ocupado por una persona con conocimientos de
modelado UML y de la metodologa de evaluacin.
Las principales responsabilidades son, realizar las
actividades de evaluacin asignadas por el evaluador jefe y
recoger informacin del propio proceso de evaluacin.
Equipo de evaluacin Representa el equipo de la empresa evaluadora, formado
por el evaluador jefe y un conjunto de uno o varios
evaluadores de calidad (segn los requisitos del proyecto).
Su principal objetivo es cumplir con los requisitos de
evaluacin acordados con el patrocinador dentro de los
tiempos planificados.
Tabl a 59: Tabl a de Personas, Grupos y Roles
9.1.2 Catlogo de elementos
Los elementos pueden ser de entrada y/o salida para las actividades del
proceso de evaluacin, siendo algunos de ellos entregables finales del proyecto
de evaluacin. En la siguiente tabla se detallan todos los elementos
(documentos, informes, catlogos, artefactos, etc.) que se identifican a lo
largo de las actividades de evaluacin.
El emento Detal l e
Informacin de contacto Documento donde la empresa evaluadora recoge los datos
de contacto de la empresa cliente. Como mnimo debe
presentar la siguiente informacin: Nombre de la empresa,
la direccin, el telfono/Fax, Pgina Web, Persona de
contacto, Email de contacto.
Contrato de evaluacin Este documento representa el primer entregable del
197
proyecto de evaluacin y ser generado como resultado de
la pl ani f i caci n. En l se recogen las condiciones bajo
las que se realizar el proyecto de evaluacin. Est
dividido en dos partes:
1. Propuesta tcnica de evaluacin: contiene aspectos
tcnicos del contrato de evaluacin tales como el objetivo
de la evaluacin, el plan de trabajo, el equipo de trabajo, el
calendario y el esfuerzo necesario.
2. Propuesta econmica de evaluacin: contiene
aspectos econmicos del contrato de evaluacin tales
como el precio, el modo de facturacin, las clusulas, las
condiciones generales, etc.
Modelo de calidad genrico Es un documento propiedad de la empresa evaluadora
y contiene el conjunto de caractersticas, subcaractersticas
y atributos de calidad que se pueden evaluar para cada
artefacto software. Las caractersticas y
subcaractersticas de calidad se encuentran detalladas en
la norma ISO 25010.
Modelo de calidad especfico Es un documento que solo contiene el conjunto de
caractersticas, subcaractersticas y atributos de calidad
que la empresa cliente ha seleccionado para el proyecto
de evaluacin. Este documento es pblico y est
integrado dentro de la especificacin de la evaluacin que
representa el tercer entregable del proceso de evaluacin.
Catlogo de herramientas de
evaluacin
Es un documento propiedad de la empresa evaluadora y
que permite identificar las herramientas necesarias y su
modo de utilizacin, en funcin de las tcnicas de
evaluacin que se vayan a utilizar para evaluar los
modelos UML.
Plan de evaluacin Este documento pblico para ambas partes, y representa
el segundo entregable del proyecto de evaluacin. Una
primera versin se desarrolla previamente al inicio del
proyecto de evaluacin, incluida en la propuesta tcnica
del contrato de evaluacin. Esta primera versin es
refinada por ambas partes tras la aceptacin del contrato,
generndose as la versin definitiva del plan de
evaluacin, que guiar todos los procesos y actividades
realizados durante el proyecto. Este documento es
generado como resultado de la planificacin del proceso
de evaluacin y est sujeta a cambios durante todo el
proyecto de evaluacin.
Conjunto de artefactos a evaluar Entendiendo por artefactos los modelos UML que la
empresa cliente quiere validar, y toda la documentacin
necesar i a para comprender correctamente la
naturaleza y contenido de dichos modelos. Es
responsabilidad del patrocinador que los artefactos a
evaluar estn disponibles en las fechas planificadas,
asi como es responsabilidad del evaluador jefe asegurar
que los artefactos entregados para ser evaluados cumplen
con los requisitos impuestos por las tcnicas y
herramientas que se van a utilizar en el proceso de
evaluacin.
Especificacin de la evaluacin Este documento representa el tercer entregable del
proyecto de evaluacin y como tal es pblico para
ambas empresas. La especificacin de la evaluacin
ser generada como resultado de la especificacin del
198
proceso de evaluacin donde se recoje el conjunto de
artefactos a analizar, el modelo de calidad especfico que
se va a analizar, qu tcnicas se van a utilizar, qu mtricas
se esperan obtener, qu herramientas se van a manejar,
entre otros. En definitiva un conjunto de caractersticas a
evaluar por cada uno de los modelos UML, las tcnicas y
herramientas que se utilizarn y el listado de mtricas e
indicadores que se esperan obtener. Esta
especificacin posteriormente se incluye dentro del
informe final de evaluacin, conforme lo establece la
norma ISO/IEC 14598.
Informe de evaluacin Este doc ument o representa el cuarto entregable del
proyecto de evaluacin y como tal es pblico para ambas
empresas. El informe de evaluacin se genera como
resultado de la fase de conclusin y estar formado por
un documento con todos los resultados obtenidos
mediante las tcnicas de evaluacin, las conclusiones
obtenidas del anlisis de dichos resultados y un conjunto
de recomendaciones y acciones futuras para la mejora de
los modelos UML, adems de la especificacin de la
evaluacin. Una caracterstica importante del informe es la
retroalimentacin que se produce posteriormente a la
presentacin de los resultados y en cuyo caso la
empresa cliente reporta a la empresa evaluadora
mediante el documento peticin de modificacin.
Peticin de modificacin Este artefacto representa el quinto entregable del
proceso de evaluacin y como tal es pblico para
ambas empresas. Este documento se genera como
resultado de la fase de conclusin y representa el
documento mediante el cual la empresa cliente,
manifiesta sus opiniones y posibles cambios respecto a los
resultados presentados en el informe de evaluacin. La
empresa evaluadora recibir el documento que
evaluar, revisar y actualizar el informe de
evaluacin de acuerdo a los cambios sugeridos. El
informe modificado ser nuevament e entregado a la
empresa cliente. El resultado de esta peticin no es ms
que un refinamiento del informe de evaluacin as como la
mejora del proceso de evaluacin.
Informacin interna de
evaluacin
Adems durante la evaluacin se genera documentacin
relacionada con el propio proceso. Esta informacin
principalmente son informes del proceso de gestin y
monitorizacin, informes de mtricas de la propia
evaluacin, informes de cambios y ajustes realizados
durante la evaluacin, informes de defectos y
adaptaciones realizadas en la infraestructura de
evaluacin, entre otros. Posteriormente esta informacin
e s utilizada por los procesos Gestin de la Evaluacin y
Gestin de la Infraestructura para realizar una mejora
continua del proceso de evaluacin.
Tabla 60: Catlogo de Elementos
199
9.1.3 Procesos de la metodologa de evaluacin
La metodologa de evaluacin EVVE se encuentra compuesta por tres procesos
principales: Proceso de gestin de la evaluacin, Proceso de evaluacin y
Proceso de gestin de la infraestructura.
9.1.3.1 Proceso de evaluacin: Este proceso representa el esqueleto de la
metodologa de evaluacin ya que contiene las fases de planificacin,
especificacin, ejecucin y conclusin del proyecto de evaluacin. El proceso de
evaluacin se descompone en cuatro fases que son mostradas en la siguiente
tabla:
Fase Descripcin
Fase 1: Planificacin El objetivo de esta fase es la elaboracin del contrato y
la obtencin de un plan de evaluacin de los modelos
UML. Esta fase est formada por cuatro actividades:
Contratacin, Arranque del proyecto, Planificacin detallada y
Consolidacin del plan.
Fase 2: Especificacin El objetivo de esta fase es definir el alcance de la
evaluacin, determinando el conjunto de caractersticas que
se van a evaluar para cada uno de los modelos UML
(artefactos), las tcnicas y herramientas que se van a
utilizar para realizar la evaluacin, los niveles de evaluacin
(bajo, medio o alto) que se van a aplicar a cada
artefacto y el listado de indicadores y mtricas que se
esperan obtener. Esta fase est formada por cuatro
actividades: Obtencin y anlisis de artefactos a evaluar,
Seleccin del modelo de calidad y las tcnicas, Planificacin
interna de la evaluacin, Verificacin de la especificacin.
Fase 3: Ejecucin El objetivo de la fase de ejecucin es la aplicacin de las
tcnicas de evaluacin y el lanzamiento de las
herramientas (utilizando como entrada los artefactos a
evaluar) para obtener los resultados iniciales (mtricas de
ms bajo nivel) sobre la calidad de los modelos UML. Una
vez obtenidos los resultados iniciales, es necesario
asegurar su veracidad (pueden existir defectos en los
resultados) y realizar su almacenamiento de una manera
unificada que permita su posterior explotacin. Esta fase est
formada por tres actividades: Aplicacin de tcnicas de
evaluacin, Anlisis de la ejecucin, Unificacin de
resultados.
Fase 4: Conclusin El objetivo de la fase de conclusin es la elaboracin del
informe de evaluacin y la presentacin de los resultados
tanto al patrocinador como al resto de personas involucradas
dentro de la empresa cliente. Esta fase est formada por tres
actividades: Elaboracin del informe de evaluacin,
Presentacin de resultados, Correccin del informe y
finalizacin de la evaluacin.
Tabla 61: Fases del Proceso de Evaluacin
200
9.1.3.2 Proceso de gestin de la evaluacin: Es el proceso de soporte al
proceso de evaluacin, que permite controlar, evaluar y mejorar el propio proceso
de evaluacin. Este proceso est formado nicamente por una fase, denominada
de igual manera que el proceso. Esta fase a su vez se descompone en tres
actividades bien diferenciadas: Monitorizacin, Documentacin, Ajuste y
Evolucin.
9.1.3.3 Proceso de gestin de la infraestructura: Es el proceso de soporte
al proceso de evaluacin, que permite gestionar todo lo relacionado con la
infraestructura necesaria para llevar a cabo el proceso de evaluacin (tcnicas
y herramientas de evaluacin). Este proceso est formado nicamente por una
fase, denominada de igual manera que el proceso. Esta fase a su vez se
descompone en tres actividades bien diferenciadas: Especificacin de la
infraestructura, Mantenimiento de la infraestructura, Adaptacin y transferencia de
la infraestructura.
9.2 LECCIN 2: IMPLEMENTACIN DE LA METODOLOGA CON SPEM Y
EPFC
SPEM 2.0 (Software & System Process Engineering Metamodel) es un
metamodelo de OMG considerado como el estndar de facto en la industria
para la representacin de modelos de procesos de ingeniera del software e
ingeniera de sistemas. Por otro lado, dentro de la plataforma abierta Eclipse, se
ha desarrollado un editor de SPEM 2 llamado EPFC (Eclipse Process
Framework Composer), que permite definir, gestionar y reutilizar un repositorio
de fragmentos de mtodos y procesos. De modo que con EPFC se pueden
crear implementaciones en formato SPEM 2 de cualquier mtodo, proceso o
metodologa de ingeniera del software.
La idea central de SPEM 2 para representar procesos est basada en tres
elementos bsicos: rol, producto de trabajo y tarea.
- Las tareas representan el esfuerzo a hacer.
- Los roles representan quin lo hace.
- Los productos de trabajo representan las entradas que se utilizan en
las tareas y las salidas que se producen.
9.2.1 Ventajas de SPEM y EPFC
Las principales razones por las que se han seleccionado SPEM y
EPFC para la implementacin prctica de la metodologa EVVE, frente a otras
alternativas son las que se describen a continuacin:
201
- El formato en el que se maneja la informacin en las metodologas
suelen ser documentos de texto natural.
- La creacin, revisin, reutilizacin, adaptacin y generacin de
documentacin para las metodologas suele ser un proceso puramente
manual.
- EPFC permite crear metodologas y procesos con un rico contenido
(texto con formato, imgenes, elementos multimedia, etc.).
- EPFC proporciona una estructura de gestin comn para todo el
contenido metodolgico de una organizacin.
- EPFC proporciona un entendimiento claro y visual de cmo se
relacionan las diferentes tareas de una metodologa.
- EPFC permite seleccionar, combinar, adaptar y ensamblar de forma
rpida procesos a partir del contenido de mtodo creado.
- EPFC permite publicar la documentacin de los procesos y
metodologas modelados en formato para la web.
- EPFC reduce el coste de reutilizacin de contenidos de mtodo
en una organizacin.
9.2.2 Diagrama de actividad generado por EPFC
A continuacin, se presenta el flujo de trabajo generado por EPFC para
las tareas que se realizan en la actividad Obtencin y Anlisis de Artefactos a
Evaluar, actividad que pertenece a la fase 2 (Especificacin) del proceso de
evaluacin especificado anteriormente.
Tal y como se puede ver en la siguiente figura, esta actividad est
compuesta por 3 tareas las cuales se deben realizar en orden secuencial.
Adems para cada una de las tareas se muestra en el margen superior izquierdo
la abreviatura del rol implicado en su realizacin.
EPFC permite la generacin automtica de este tipo de diagramas a
partir de la informacin de la metodologa introducida en el sistema.
Adems, desde este tipo de diagramas, EPFC facilita la navegacin directa
a cada uno de los componentes de la metodologa (roles, tareas, productos
de trabajo) identificando la trazabilidad bidireccional entre todos estos elementos.
202
Figura 38: Diagrama de actividad generado por EPFC para la actividad
Obtencin y Anlisis de Artefactos a Evaluar de la fase 2 (Especificacin), del
proceso de evaluacin.
9.3 LECCIN 3: EVALUACIN DE SOFTWARE EDUCATIVO MULTIMEDIA
Una de las aplicaciones ms estudiadas en la actualidad es la Evaluacin
del Software Educativo Multimedia. Las caractersticas que debe cumplir un buen
software multimedia formativo atienden a diversos aspectos funcionales, tcnicos
y pedaggicos, que se enuncian a continuacin en la siguiente tabla:
Caracterstica Descripcin
Facilidad de uso e instalacin Hace referencia a que los programas puedan ser realmente
utilizados por la mayora de las personas, y para ello se hace
necesario que sean agradables, fciles de usar y
autoexplicativos, de manera que los usuarios puedan
utilizarlos inmediatamente sin tener que realizar la lectura de
los manuales, ni largas tareas previas de configuracin. En
cada momento el usuario debe conocer el lugar del programa
donde se encuentra y tener la posibilidad de moverse segn
sus preferencias: retroceder, avanzar, y un sistema de ayuda
online solucione las dudas que puedan surgir. Adems la
instalacin del programa deber ser sencilla, rpida y
transparente. Tambin se debe tener en cuenta la existencia
203
de una utilidad para desintalar para cuando se quiera quitar el
programa.
Versatilidad (adaptacin a
diversos contextos)
Hace referencia a la funcionalidad, es decir, que sean
fcilmente integrables con otros medios didcticos en los
diferentes contextos formativos, pudindose adaptar a
diversos entornos, estrategias didcticas, y usuarios. Para
lograr esta versatilidad debe tener unas caractersticas que
permitan su adaptacin a los distintos contextos. Por ejemplo
que sean programables (que permitan la modificacin de
parmetros como grado de dificultad, tiempo para las
respuestas, nmero de usuarios simultneos, idioma), que
sean abiertos (permitiendo la modificacin de los contenidos
de las bases de datos), que incluyan un sistema de evaluacin
y seguimiento o control (informes de las actividades realizadas
por los estudiantes: temas, nivel de dificultad, tiempo invertido,
errores, itinerarios seguidos para resolver los problemas), que
permitan continuar los trabajos empezados con anterioridad, y
que promuevan el uso de otros materiales (fichas,
diccionarios) y la realizacin de actividades complementarias
(individuales y en grupo colaborativo).
Calidad del entorno
audiovisual
El atractivo de un programa depende en gran manera de su
entorno comunicativo. Algunos de los aspectos que ms
deben cuidarse son: el diseo general claro y atractivo de las
pantallas (sin exceso de texto y que resalte los hechos
notables), la calidad tcnica y esttica en sus elementos
(ttulos, mens, ventanas, iconos, botones, espacios de texto-
imagen, formularios, barras de navegacin, barras de estado,
elementos hipertextuales, fondo), elementos multimedia
(grficos, fotografas, animaciones, vdeos, voz, msica), estilo
y lenguaje, tipografa, color, composicin, entre otros, la
adecuada integracin de medios.
La calidad en los contenidos
(bases de datos)
Adems de las consideraciones pedaggicas sobre la
seleccin y estructuracin de los contenidos segn las
caractersticas de los usuarios, se debe tener en cuenta: La
informacin que se presenta es correcta y actual, los textos no
tienen fallas, no hay discriminaciones, la presentacin y
documentacin.
Navegacin e interaccin Los sistemas de navegacin y la forma de gestionar las
interacciones con los usuarios determinan su facilidad de uso
y amigabilidad, por eso se debe tener en cuenta los siguientes
aspectos: Mapa de navegacin, Sistema de navegacin, la
velocidad entre el usuario y el programa es adecuada, el uso
del teclado, el anlisis de respuestas, La gestin de preguntas,
respuestas y acciones, la ejecucin del programa.
Originalidad y uso de
tecnologa avanzada
Los programas deben presentar entornos originales, bien
diferenciados de otros materiales didcticos, y que utilicen las
crecientes potencialidades del computador y de las
tecnologas multimedia e hipertexto en general, donde el
computador resulte potenciador del proceso de aprendizaje,
favorezca la asociacin de ideas y la creatividad, permita la
prctica de nuevas tcnicas, la reduccin del tiempo y del
esfuerzo necesarios para aprender y facilite aprendizajes ms
completos y significativos.
Capacidad de motivacin Para motivar al estudiante, las actividades de los programas
deben despertar y mantener la curiosidad y el inters de los
usuarios hacia la temtica de su contenido, sin provocar
204
ansiedad y evitando que los elementos ldicos interfieren
negativamente en los aprendizajes. Tambin conviene que
atraigan a los profesores y les animen a utilizarlos.
Adecuacin a los usuarios y a
su ritmo de trabajo
Los programas deben tener en cuenta la audiencia de los
estudiantes a los que van dirigidos y los progresos que vayan
realizando. Cada sujeto construye sus conocimientos sobre los
esquemas cognitivos que ya posee, y utilizando determinadas
tcnicas. Esta adecuacin se manifestar en tres mbitos
principales: Los contenidos deben ser significativos para los
estudiantes y estar relacionados con situaciones y problemas
de su inters, actividades de tipo de interaccin, duracin,
elementos motivacionales, mensajes de correccin de errores
y de ayuda, niveles de dificultad, itinerarios, progresin y
profundidad de los contenidos segn los aprendizajes
realizados, Y el entorno de comunicacin.
Potencialidad de los recursos
didcticos
Los programas multimedia utilizan potentes recursos
didcticos para facilitar los aprendizajes de sus usuarios. Entre
estos recursos se pueden destacar: Proponer diversos tipos
de actividades que permitan diversas formas de utilizacin y
de acercamiento al conocimiento, utilizar organizadores
previos al introducir los temas, sntesis, resmenes y
esquemas, emplear diversos cdigos comunicativos, incluir
preguntas para orientar la relacin de los nuevos
conocimientos con los conocimientos anteriores de los
estudiantes, tutorizacin las acciones de los estudiantes,
orientando su actividad, prestando ayuda cuando lo necesitan
y suministrando refuerzos.
Fomento de la iniciativa y el
autoaprendizaje
Las actividades de los programas educativos deben potenciar
el desarrollo de la iniciativa y el aprendizaje autnomo de los
usuarios, proporcionando herramientas cognitivas para que los
estudiantes hagan el mximo uso de su potencial de
aprendizaje, puedan decidir las tareas a realizar, la forma de
llevarlas a cabo, el nivel de profundidad de los temas y puedan
autocontrolar su trabajo. Adems estimularn el desarrollo de
habilidades metacognitivas y estrategias de aprendizaje en los
usuarios, que les permitirn planificar, regular y evaluar su
propia actividad de aprendizaje, provocando la reflexin sobre
su conocimiento y sobre los mtodos que utilizan al pensar.
Enfoque pedaggico actual El aprendizaje es un proceso activo en el que el sujeto tiene
que realizar una serie de actividades para asimilar los
contenidos informativos que recibe. Las actividades de los
programas deben estar en consonancia con las tendencias
pedaggicas actuales, para que su uso en las aulas y dems
entornos educativos provoque un cambio metodolgico en
este sentido. Por lo tanto los programas evitarn la simple
memorizacin y presentarn entornos heursticos centrados en
los estudiantes que tengan en cuenta las teoras
constructivistas y los principios del aprendizaje
significativo donde adems de comprender los contenidos
puedan investigar y buscar nuevas relaciones.
La documentacin Los programas debern tener una informacin acerca de sus
caractersticas, forma de uso y posibilidades didcticas. Esta
documentacin debe tener una presentacin agradable, con
textos bien legibles y adecuados a sus destinatarios, y resultar
til, clara, suficiente y sencilla. Se distingue tres partes: Ficha
resumen (con las caractersticas bsicas del programa), El
205
manual del usuario (Presenta el programa, informa sobre su
instalacin y explica sus objetivos, contenidos, destinatarios,
modelo de aprendizaje que propone, sus opciones y
funcionalidades), la gua didctica (con sugerencias didcticas
y ejemplos de utilizacin que propone estrategias de uso y
indicaciones para su integracin curricular).
Esfuerzo cognitivo Las actividades de los programas, contextualizadas a partir de
los conocimientos previos e intereses de los estudiantes,
deben facilitar aprendizajes significativos y transferibles a otras
situaciones mediante una continua actividad mental en
consonancia con la naturaleza de los aprendizajes que se
pretenden. As desarrollarn las capacidades y las estructuras
mentales de los estudiantes y sus formas de representacin
del conocimiento (categoras, secuencias, redes conceptuales,
representaciones visuales) mediante el ejercicio de actividades
cognitivas del varios tipos (control psicomotriz, memorizar,
comprender, comparar, relacionar, calcular, analizar, sintetizar,
razonamiento, pensamiento divergente, imaginar, resolver
problemas, expresin, crear, experimentar, explorar, reflexin
metacognitivareflexin sobre su conocimiento y los mtodos
que utilizan al pensar y aprender).
Tabla 62: Caractersticas de los Productos de Software Educativo Multimedia
9.4 LECCIN 4: MODELOS DE EVALUACIN DE SOFTWARE EDUCATIVO
MULTIMEDIA
Existe una diversidad de herramientas y modelos para la evaluacin de productos
de software multimea educativos, dentro de ellos se han elegido algunos que son
los ms representativos y de los cuales se describir la metodologa de aplicacin.
Cada modelo tiene unas caractersticas especficas que diferencian y a la vez
complementan a los otros modelos. A continuacin se har una descripcin de los
modelos seleccionados, las caractersticas y componentes que deben ser
evaluados.
9.4.1 Modelo de evaluacin de materiales educativos computarizados de
Galvis
Uno de los modelos ms conocidos para la evaluacin de productos
educativos computarizados (MEC) es planteado por Galvis, que propone un
modelo que ser descrito por sus componentes y criterios. Este autor establece la
evaluacin como actividad necesaria para la elaboracin de informacin requerida
en la toma de decisiones, siendo aplicable a cualquier sistema. Para la evaluacin
sistemtica de los MEC, se establecen criterios relevantes y consistentes,
Adems de la creacin de instrumentos de evaluacin vlidos y confiables segn
las fuentes de informacin apropiadas al respecto. Los MEC se desarrollan para
satisfacer necesidades educativas que no pueden ser abordadas por otros medios
de enseanza, y por consiguiente, debe ser de calidad y viables de utilizar por
parte de los usuarios a quienes va dirigido.
206
La evaluacin sistemtica de los MEC comprende evaluar los aspectos de
Calidad educativa, Calidad computacional y Probabilidad de uso del recurso
informtico. A continuacin se presentan las tablas donde se muestra las partes
en que se descompone cada aspecto mencionado anteriormente.
ASPECTOS VARIABLES CRITERIOS
Funcin educativa del tipo de MEC Aborda la necesidad educativa Generales
Funcin administrativa Suministra informacin til para el
docente
Objetivos del material El nivel de dificultad es adecuado a la
necesidad educativa
Contenido Es claro, conciso y actualizado.
Enseanza
Estrategias de Instruccin Estas son coherentes y suficientes
para lograr los objetivos previstos.
Opinin y actitud del estudiante. Es positiva frente al programa. Aprendizaje
Realimentacin de su
desempeo
Se ofrece en forma oportuna,
amigable y adecuada.
Tabla 63: Partes de la calidad educacional del MEC
ASPECTOS VARIABLES INDICADORES
Generales Funciones segn el usuario
Caractersticas de: interfaz,
programa, programacin.
Fcil de utilizar. Amigable. Claridad de
instrucciones. Legibles. Bien
documentada
Estructura de la informacin Son eficientes y adecuadas a los datos
del programa
Tcnicos
Recursos computacionales Los suministrados por el equipo son
utilizados al mximo
Tabla 64: Calidad computacional del MEC y sus elementos
VARIABLES CRITERIOS
Requerimientos de Hardware Los diversos equipos se pueden conseguir en el mercado
Requerimientos de Software Los diversos softwares que amerita son fciles de usar
Requerimientos de personal El personal tcnico de orientacin al usuario es localizable.
Requerimientos financieros Estos son accesibles a los aprendices del programa.
Tabla 65: Elementos considerados en la viabilidad del recurso informtico
En cuanto a los tipos de evaluaciones de los recursos educativos computarizados,
este autor propone la Valoracin comprensiva del MEC por expertos y la Prueba
con estudiantes. En la siguiente tabla se muestra las variables, indicadores y
criterios de valoracin considerados en esta prueba.
VARIABLES INDICADORES CRITERIOS PARA VALORAR
Relevancia y
pertinencia
Contenido, objetivos.
Tipo de software educativo.
El programa satisface una necesidad
educativa que no puede ser lograda con otros
medios existentes
207
Viabilidad Requerimientos
computacionales.
Requerimientos fsicos.Costos
El software educativo es viable de utilizar por
los usuarios a quien se dirige considerando
sus recursos disponibles. Los costos de
adquisicin y mantenimiento permiten la
accesibilidad del MEC por los aprendices.
Interactividad Participacin que exige del
usuario.
El MEC emplea al mximo la capacidad de
interaccin que suministra el computador.
Calidad como
tipo de
aplicacin
Funciones educativas que
asume el MEC.
El tipo o combinaciones de MEC requeridos
segn la necesidad educativa son un buen
prototipo de estos.
Tabla 66: Elementos Considerados en la Valoracin Comprensiva del MEC
La evaluacin por expertos del MEC, se refiere a la revisin y crtica por
especialistas en contenido, metodologa e informtica, de grupos distintos a sus
desarrolladores a fin de que exista objetividad en las apreciaciones. La valoracin
de software educativo por experto en contenido y en metodologa se muestra en
las siguientes tablas. Estas se refieren a los aspectos generales relativos a:
objetivos que persigue, contenidos, motivacin, metodologa, interfaz y otros.
Cada tem puede ser evaluado con cinco opciones de respuesta (excelente,
bueno, regular, malo, no aplica). Adems en el instrumento se solicita la anotacin
de los defectos encontrados en el MEC, su ubicacin y posible solucin, junto con
las fortalezas, debilidades, el uso potencial y las sugerencias para lograr su
aplicacin.
VARIABLES INDICADORES
Objetivos El nivel de complejidad es adecuado para el uso de software
Contenido Es coherente, suficiente y actualizado en relacin a los objetivos
Desarrollo del
contenido
El estudiante siempre esta informado sobre su ubicacin dentro del
contenido.
Herramientas Estas son: adecuadas, sencillas de usar y facilitan la exploracin.
Retroinformacin Su orientacin es suficiente y adecuada a la actuacin del aprendiz.
Tabla 67: Algunos elementos de la valoracin por experto en contenido del MEC
VARIABLES INDICADORES
Objetivos Definidos claramente.
Motivacin Se mantiene el inters por el logro de los objetivos.
Metodologa Se sustenta en una didctica adecuada al contenido a ensear.
Las pantallas no se encuentran sobrecargadas de informacin. Interfaz de salida
El vocabulario o terminologa es apropiada para el nivel cultural del
usuario.
Tabla 68: Elementos considerados en la valoracin por experto en metodologa
Posteriormente es necesario comprobar que para los usuarios reales
(docentes y estudiantes) representa un apoyo para el logro de sus objetivos. Esta
labor se lleva a cabo con las pruebas: piloto (realizada a una muestra
representativa de la poblacin a la que se dirige el software) y de campo (se aplica
a toda la poblacin). Adicionalmente, se propone la encuesta final del MEC para
208
recabar informacin sobre sus aspectos didcticos, lo que permitir hacer los
ajustes y recomendaciones necesarias para su uso en el proceso de enseanza-
aprendizaje.
El aporte de Galvis al modelo de evaluacin de software educativo lo
constituye el tratamiento sistmico de la valoracin de los materiales educativos
computarizados, por cuanto establece diversos tipos de pruebas (juicio de
expertos en contenido, metodologa e informtica; pruebas piloto y de campo,
encuestas a los usuarios) son realizadas por diferentes fuentes de informacin
(informantes). Adems especifica las variables, indicadores y criterios de
evaluacin que responden a la calidad educativa y computacional del recurso
informtico. En los instrumentos de evaluacin resalta la consideracin de los
problemas del material, su localizacin y posible solucin, junto con sus aspectos
positivos, negativos y sugerencias de uso en el proceso de enseanza-aprendizaje
real.
9.4.2 Lista de control para la evaluacin de software educativo de Bostock
Otro de los autores que propone una lista de Control para la Evaluacin de
Software Educativo es Bostock, la cual ha sido reestructurada y actualizada. Las
siguientes tablas presentan las variables, caractersticas ms importantes y los
indicadores de los aspectos tcnicos y pedaggicos.
En referencia a los aspectos tcnicos ms importantes se muestran las
siguientes categoras: Proteccin del programa, Calidad y disposicin de las
pantallas e Interactividad. Al evaluar el software se debe considerar los casos en
que el formato del programa tenga daos, o requiera de otro software adicional
para su funcionamiento, casos donde se hace necesario disponer de otras copias
del mismo y disponer de elementos de hardware adicionales para la operatividad
de la aplicacin.
Los aspectos pedaggicos abarcan desde los objetivos hasta la
adaptabilidad del software. Esta ltima categora define el rol del docente durante
la aplicacin del software en funcin de lo que le permita realizar el programa
frente a sus estudiantes. La evidencia de progreso del estudiante, muestra las
formas como la aplicacin puede llevar a cabo este seguimiento, que junto a la
realimentacin, establecen un posible tratamiento frente a respuestas incorrectas
del aprendiz.
VARIABLES CARACTERSTICAS Y/O INDICADORES
Equipos necesarios y materiales de apoyo del Software:
Se dispone de informacin sobre la capacidad de memoria y los
perifricos requeridos? Hay un manual sobre la instalacin y la puesta
en marcha del programa? Especifica las caractersticas mnimas
necesarias para su correcta operacin?
Asistencia tcnica: La ofrece? Te ayuda a recuperar fallas?
Requerimientos
tcnicos
Proteccin del programa: Posee un mecanismo de seguridad que no
permite la copia no autorizada del programa? Tiene el usuario un
209
respaldo disponible? Reemplazan los CDs defectuosos? La
informacin se limita a un nmero determinado de estaciones de
trabajo? Se debe mantener el CD o el Internet conectado para poder
acceder al material?
Validacin: El programa fue validado por especialistas? Puede el
usuario obtener una versin de prueba?
Organizacin de la Pantalla: Se refiere al uso del espacio y la forma en
que la informacin se despliega en la pantalla.
Texto en la pantalla: La presentacin del texto le permite al usuario
leerlo de forma sistemtica? Estn las palabras importantes de los
prrafos enfatizadas? El fondo de la pantalla permite leer sin problemas
el texto? Hay un cambio en la pgina cuando se presenta nueva
informacin? El espaciado entre las palabras y las lneas es ptimo?
Grficos: Se encuentran bien posicionados? Son las imgenes
ambiguas? Hay acceso a una ilustracin cada vez que sea necesario?
Color: Se usa el color para captar la atencin hacia puntos
importantes? Hay suficiente contraste de color entre el fondo, los
grficos y el texto? Hay colores especficos para ciertos tipos de
mensajes?
Sonido: Puede el usuario controlar el sonido? Se usa
apropiadamente el sonido para captar la atencin?
Calidad y disposicin de las pantallas: Hay variedad? La transicin
es adecuada? Se pueden sobreponer? Es posible controlar la
velocidad de transicin? Se utilizan seales para atraer la atencin
hacia partes importantes?
Interactividad: Definida para un software educativo como, si reacciona
de una manera que sea variada y adaptable segn las respuestas de
sus diferentes usuarios y si le permite a este ltimo afectar la manera en
la cual el software procede
Puede el usuario: Obtener ayuda? Detener el programa y salir a
voluntad? Ver el objetivo alcanzado hasta el momento y los que faltan?
Controlar la velocidad de la presentacin? Controlar la cantidad de
informacin?
Diseo de la
Interfase
Respecto al programa, despus de elecciones del usuario:
Puede mostrar diferentes mensajes? Puede seleccionar diferentes
alternativas dependiendo de la dificultad? Puede proveer una
retroalimentacin diferenciada adaptada? Puede tomar en cuenta las
diferentes formas de trabajar? Puede ayudar al usuario? Le da pistas
o acepta respuestas aproximadas?
Tabla 69: Aspectos tcnicos de la evaluacin de software de Bostock
VARIABLES CARACTERSTICAS Y/O INDICADORES
Estructura interna del
software
Es la divisin de los mdulos la apropiada? Estn los objetivos de
cada modulo explicados apropiadamente? Los diferentes
procedimientos tienen coherencia hacia una idea principal?
Legibilidad Determina si es agradable para leerlo.
Texto: Se usa un vocabulario adecuado al nivel de educacin del
usuario? Las oraciones estn estructuradas con coherencia?
Grficos: Complementan y se identifican con el texto? Son de
tamao apropiado? Su complejidad esta adecuada al nivel de
educacin del aprendiz?
Analizador de
respuestas
Consiste en todas las operaciones que se utilizan para lidiar con las
respuestas en un lenguaje comn. Su calidad depende de la
extensin y la variedad de las respuestas que es capaz de
210
interpretar. Hay varias maneras de expresar los mismos resultados
numricos? Se especifica la unidad requerida? Acepta que la
respuesta numrica en unidades se exprese de distintas maneras?
Permite el uso de respuestas aproximadas o equivalentes
semnticos?
Contenido Es preciso, progresivo y actualizado? Contiene introducciones a
los temas, o relaciones con los temas anteriores? Se le da
importancia a los puntos esenciales? Las simulaciones
corresponden con el ambiente real? Contiene ejemplos
apropiados?
Retroalimentacin Es la informacin dada al usuario sobre la validez de sus respuestas
Es apropiada al nivel educativo del aprendiz? Puede variar
dependiendo de la respuesta? Especifica que respuesta fue la
incorrecta, por qu fue incorrecta y cul sera la correcta?
Evidencia del progreso
del usuario
Puede el usuario evaluar los resultados de una sesin de uso?
Puede el aprendiz llevar un registro de la experiencia de
aprendizaje realizada? Puede el usuario conocer los objetivos
alcanzados? Puede el estudiante acceder a una lista de futuras
actividades sugeridas?
Adaptabilidad Puede el instructor modificar la documentacin y/o los ejemplos?
Puede el docente cambiar objetivos? Se puede usar el programa
en diferentes intervalos de tiempo eficazmente? Puede el instructor
modificar la libertad y por lo tanto el progreso del aprendizaje del
usuario?
Tabla 70: Aspectos pedaggicos de la evaluacin de software de Bostock
Esta lista de control de evaluacin de software educativo aporta una
variedad de preguntas que orientan al evaluador en el proceso. Otro elemento
importante lo constituye la proteccin del programa, factor que se debe considerar
cuando se presentan fallas en la aplicacin. El instrumento integra explicaciones
de algunas variables, aspecto que puede canalizar las dudas del evaluador y lo
hace bastante concreto y prctico. Por otra parte, ofrece resultados cualitativos ya
que no especifica una valoracin cuantitativa de los tems.
9.4.3 Metodologa de evaluacin de software educativo de Cataldi
Otra de las autoras que propone un modelo de evaluacin es Cataldi, quien
establece la importancia de la evaluacin del software educativo por el crecimiento
rpido de la cantidad de stos en el mercado. Los docentes tienen la necesidad de
evaluarlos para determinar su grado de adecuacin a su propio entorno, mientras
que los estudiantes requieren saber cmo pueden mejorar sus aprendizajes
mediante una aplicacin especfica. En general, el desarrollo de instrumentos de
evaluacin y el hecho de utilizarlos con un programa en particular y un grupo de
usuarios especfico no aporta resultados generalizables a todas las reas de uso,
pero ofrece orientaciones en su seleccin para los docentes.
Cataldi propone una metodologa de evaluacin de software educativo en
tres momentos de su ciclo de vida. Una evaluacin interna realizada por el equipo
de desarrolladores del programa durante la creacin de prototipos. Otra externa,
211
aplicada al producto final por los docentes; y la evaluacin contextualizada
efectuada en un contexto parecido a aquel para el cual fue elaborado el software,
que brinda informacin sobre las reacciones de los usuarios de la eficacia de la
aplicacin.
El software educativo integra dos aspectos fundamentales a evaluar: el
tcnico y el pedaggico que conlleva a establecer la calidad tcnica y educativa.
La calidad educativa de estas aplicaciones se refiere a la potenciacin de
habilidades cognitivas y de adquisicin de conocimientos a partir del uso del
software en particular. La siguiente tabla muestra los aspectos pedaggicos,
didcticos y los tcnicos
ASPECTOS CRITERIOS
Facilidad de Uso Utilidad
Grado de adaptacin a otros niveles de usuarios
Claridad de contenidos
Nivel de actualizacin
Interfase de navegacin
Nivel de Motivacin
Es adecuado para la comprensin del tema?
Pedaggicos y
didcticos
Es adecuado para el aprendizaje del tema?
Hay documentacin y ayudas? Tcnicos
Son adecuados los recursos que necesita?
Tabla 71: Esquema de evaluacin del producto final
La autora sostien que el software educativo debe reunir algunas
caractersticas de acuerdo a las necesidades de aplicacin y los objetivos
educativos a lograr, y tambin debe responder a la calidad y pertinencia, as se
establece en la siguiente tabla el criterio de usabilidad y varios subcriterios,
valorados segn tres niveles: muy bueno (valorado con 3 puntos), bueno (2
puntos) y malo (1 punto).
CRITERIO UTILIDAD SUBCRITERIOS VALORACIN
Utilidad externa Velocidad de aprendizaje; facilidad de uso; nivel
de adiccin.
Muy bueno, bueno y
malo.
Utilidad interna Nivel de legibilidad; grado de comprensin; uso
de mens, grficos e imgenes; mensajes de
errores e informacin; ayudas online; definicin
de adecuacin de la interfase
Muy bueno, bueno y
malo.
Tabla 72: Criterios y Subcriterios para Evaluacin de la Calidad del Software
Educativo
A partir de la revisin de la informacin presentada en las tablas anteriores,
junto al cuestionario de evaluacin del producto final, se presenta la siguiente tabla
que indica las caractersticas de las variables segn los criterios de calidad
previstos.
212
CATEGORAS DIMENSIONES ALGUNAS CARACTERSTICAS
Tcnica Interfase La interfase es amigable y de fcil manejo.
El diseo general de la pantalla es adecuado.
La secuenciacin de las pantallas se rige por criterios.
El uso de ventanas, botones, colores, tipos de letras es
adecuado.
El uso de iconos es correcto.
La utilizacin de teclas rpidas es til.
Contenidos Su seleccin es adecuada y actualizada.
El programa se puede adaptar a otros niveles de
usuarios.
Su estructura le permite al usuario conocer hacia donde
va en los aprendizajes.
Se le facilita la comprensin del tema al aprendiz.
Pedaggica
Condiciones
relativas
al usuario
Despierta su inters.
Prefiere que el programa sea tutorial.
Le gustara sonidos en los videos
El programa le permite ver cosas que no se hubiese
imaginado.
Tabla 73: Caractersticas de las variables segn criterios de calidad
En cuanto a la evaluacin contextualizada del software educativo, se debe
realizar experiencias para establecer las diferencias en cuanto al logro de
aprendizajes significativos entre un software elaborado con la metodologa
extendida en los aspectos pedaggicos y otro de idntica funcionalidad pero
desarrollado con una metodologa tradicional.
9.4.4 Instrumento de evaluacin de recursos multimedia de Soto y Gmez
Soto y Gmez, proponen un instrumento de evaluacin de recursos
multimedia para la atencin a la diversidad, denominado EVALA, que es una
base de datos sobre software educativo que pretende ser un instrumento de apoyo
a los docentes en la labor de evaluacin y seleccin de recursos informticos, con
el propsito de favorecer la integracin de las TIC en el sistema educativo.
La ficha de evaluacin del software contiene las siguientes partes: Datos del
programa (datos descriptivos de la aplicacin), Aspectos curriculares (relativos al
currculum, destinatarios y la descripcin educativa), Aspectos pedaggicos
(motivacin, contenidos, interactividad y las capacidades que desarrolla), Aspectos
tcnicos-estticos (el entorno audiovisual, navegacin y calidad de contenidos),
Observaciones y valoracin global. Los aspectos pedaggicos y tcnicos-estticos
son valorados en una escala cuantitativa de 1 a 5 puntos, uno es muy bajo y 5
muy alto. A continuacin se muestra la siguiente tabla, donde se presentan
algunas caractersticas de este instrumento.
ASPECTOS VARIABLES CARACTERSTICA O INDICADORES
Identificacin del
programa
Ttulo de la aplicacin.
Datos del autor o empresa.
Datos del
programa
Requerimientos Informacin sobre el procesador mnimo.
213
tcnicos Espacio que ocupa en disco.
Configuracin de colores y rea de pantalla.
Tipo de adquisicin
del software.
La aplicacin es gratuita.
Tipo de dificultad que
aborda
Un icono la indica: auditiva, visual, motorica
Destinatarios Edad recomendada
Ubicacin en el
currculum
Etapa educativa. Ciclo dentro de la etapa.
rea/mbito.
Contenidos
curriculares
Se presenta en orden de importancia
Curriculares
Descripcin
educativa
del programa
Objetivos, niveles de dificultad, opciones de
impresin, informes de evaluacin
Capacidad de
motivacin
Es motivante si: elementos del mismo (colores,
animaciones, sonidos) atraen la curiosidad del
aprendiz.; las actividades atraen al docente y les
anima a usarlo con sus estudiantes.
Los contenidos son significativos para el usuario y
se relacin con situaciones y problemas de su
inters.
Adecuacin a los
contenidos
Presenta niveles de dificultad acorde con los
estudiantes.
La velocidad entre el usuario y el programa
(animaciones, lectura de datos) es adecuada.
Interactividad
Se tutoriza la accin del aprendiz, orientando su
actividad, prestando ayuda efectiva oportunamente y
ofrece refuerzos positivos.
Pedaggicos
Capacidades que
desarrolla
Segn los niveles cognoscitivos de Bloom:
conocimientos, comprensin, anlisis, creatividad,
resolucin de problemas.
Diseo general claro y atractivo de las pantallas, sin
exceso de texto y que resalte a simple vista los
hechos notables.
Calidad tcnica y esttica de: ttulos, mens,
ventanas, iconos, botones, grficos, animaciones,
videos, voz.
Entorno audiovisual
Adecuada integracin de medias al servicio del
aprendizaje sin redundancias.
Facilidad de uso y amigabilidad del software.
Mapa de navegacin bien estructurado, de acceso
fcil y rpido a los distintos elementos del programa.
Navegacin
Sistema de navegacin transparente que permita al
aprendiz ejercer el control efectivo sobre el
programa.
Informacin presentada cientficamente correcta y
actualizada.
Tcnico-esttico
Calidad de los
contenidos
Si no hay discriminaciones, los contenidos y
mensajes no son negativos o tendenciosos.
Observaciones Aspectos relevantes Ventajas y desventajas Recomendaciones para su
uso
Datos de utilidad acerca de suinstalacin, manejo y
funcionamiento.
Valoracin global Puntuacin de
aspectos
Se ilustra con nmero de estrellas.
214
Pedaggicos y
tcnicos-estticos.
Tabla 74: Algunas caractersticas de la ficha de evaluacin de software
Este instrumento de evaluacin aporta una forma sencilla para la valoracin
de software educativos, integrando aspectos cualitativos con cuantitativos, utiliza
smbolos para la valoracin global y para identificar el tipo de dificultad que
aborda. En los aspectos pedaggicos resalta el establecimiento de niveles de
dificultad de acuerdo a los usuarios, adems de precisar las capacidades que
desarrolla el programa. Desde el punto de vista tcnico-esttico esta integracin
resulta muy favorable, permitiendo que especficamente el entorno audiovisual,
presente tanto un diseo claro en las pantallas como atractivo en sus
componentes.
9.5 LECCIN 5: PLANTILLAS DE EVALUACIN DE SOFTWARE
MULTIMEDIA
Al seleccionar un programa para utilizarlo en una determinada situacin
educativa hay que considerar dos aspectos fundamentales: sus caractersticas y
su adecuacin al contexto en el que se quiere utilizar. Para conocer las
caractersticas de un programa, el profesor debe leer el manual e interactuar con
l con el propsito de determinar sus objetivos, los contenidos, el planteamiento
didctico, el tipo de actividades que presenta, la calidad tcnica, es decir, deber
realizar una evaluacin del programa.
Para facilitar esta evaluacin objetiva de las caractersticas de un programa,
se propone una ficha de catalogacin y evaluacin que permitir recoger los
rasgos principales del programa y algunas valoraciones sobre sus aspectos
tcnicos, pedaggicos y funcionales.
FICHA DE CATALOGACIN Y EVALUACIN MULTIMEDIA
Ttulo del programa
(+ versin, idiomas)
Autores
(+ e-mail)
Editorial
(+ ao, lugar, web)
Temtica
(rea, materia)
215
Objetivos
.
.
.
Contenidos que se tratan
(hechos, conceptos, procedimientos, actitudes)
.
.
.
Destinatarios
(caractersticas, etapa educativa)
(subrayar uno o varios de cada apartado)
TIPOLOGA: EJERCITACIN-TUTORIAL-BASE DE DATOS-LIBRO-SIMULADOR-JUEGO-
CONSTRUCTOR-HERRAMIENTA
USOS POSIBLES: ENTRENAR - INSTRUIR - INFORMAR - MOTIVAR - EXPLORAR -
EXPERIMENTAR EXPRESARSE - COMUNICARSE - ENTRETENER - EVALUAR -
PROCESAR DATOS
ENFOQUE PEDAGGICO: CONDUCTISTA - COGNITIVISTA - CONSTRUCTIVISTA -
NINGUNO
DOCUMENTACIN: MANUAL - GUA DIDCTICA - MANUAL ON-LINE - GUA DIDCTICA
ON-LINE - OTROS NINGUNA
Breve descripcin
.
.
.
Requisitos tcnicos
(hardware y software)
Valores que potencia o presenta
ASPECTOS FUNCIONALES. UTILIDAD
valorar EXCELENTE, ALTA, CORRECTA o BAJA
- Eficacia (puede facilitar el logro de los objetivos que pretende)
216
- Facilidad de uso e instalacin (entorno amable)
- Versatilidad (ajustable, modificable, niveles de dificultad, evaluacin, informes)
ASPECTOS TCNICOS Y ESTTICOS
- Calidad del entorno audiovisual (pantallas)
- Calidad en los contenidos (texto,audiovisual...)
- Navegacin e interaccin
- Originalidad y uso de tecnologa avanzada
ASPECTOS PEDAGGICOS
Esfuerzo cognitivo que exigen sus actividades:
marcar uno o varios
CONTROL PSICOMOTRIZ
MEMORIZACIN /EVOCACIN
COMPRENSIN / INTERPRETACIN
COMPARACIN / RELACIN (orden, clases...)
ANLISIS / SNTESIS
CLCULO
RAZONAMIENTO (deductivo, inductivo, crtico)
PENSAMIENTO DIVERGENTE / IMAGINACIN
RESOLUCIN DE PROBLEMAS
EXPRESIN (verbal, escrita, grfica...) / CREAR
EXPLORACIN / EXPERIMENTACIN
REFLEXIN METACOGNITIVA
OBSERVACIONES
Ventajas que comporta respecto a otros medios
.
Problemas e inconvenientes
.
A destacar...
. IMPRESIN PERSONAL. me ha gustado: si no lo recomendara: si no
NOMBRE DE LA PERSONA EVALUADORA Y FECHA:
Tabla 75: Ficha de Catalogacin y Evaluacin
9.5.1 Aspectos a considerar en la seleccin de producto multimedia
217
Para cada situacin educativa concreta puede aconsejar, la utilizacin de
determinados programas educativos multimedia como generadores de actividades
de aprendizaje para los estudiantes y, por otra parte, un mismo programa puede
convenir utilizarlo de manera distinta en contextos educativos diferentes. Como
norma general conviene utilizar un determinado programa cuando su empleo
aporte ms ventajas que la aplicacin de otros medios didcticos alternativos. Y
en cuanto a la forma de utilizacin, nuevamente ser la que proporcione ms
ventajas. La utilizacin de los medios debe venir condicionada por los siguientes
factores:
Las caractersticas del material: Hardware necesario, calidad tcnica, facilidad
de uso, objetivos y contenidos, actividades, planteamiento pedaggico...
La adecuacin del material a las circunstancias: Que caracterizan la situacin
educativa donde se piensan aplicar: objetivos, caractersticas de los estudiantes,
contexto, entre otros.
El coste: Costo del material o el esfuerzo que hay que realizar para poder
disponer de l. Tambin hay que considerar la posibilidad de utilizar otros medios
alternativos que puedan realizar la misma funcin pero de manera ms eficiente.
9.5.2 Diseo de actividades con soporte multimedia
Para disear actividades formativas con soporte multimedia hay que tener en
cuenta diversos aspectos:
Las caractersticas del contexto educativo: Marco general, caractersticas.
Las caractersticas de los estudiantes: Edad, capacidades, conocimientos y
habilidades previas, experiencias, actitudes, intereses, entorno sociocultural.
Los objetivos educativos que se persiguen: Con la realizacin de la actividad y
su importancia dentro del marco del programa de la materia.
Los contenidos: que se tratarn.
La seleccin de los materiales didcticos: Se considerarn las caractersticas
de los materiales, adecuacin a la situacin educativa (estudiantes, objetivos) y el
costo de los diversos materiales al alcance.
La funcin que tendr el material: Segn las caractersticas del material y segn
la manera en que se utilice, un mismo programa puede realizar diversas
funciones: Motivacin del estudiante; Fuente de informacin y transmisin de
contenidos; Entrenamiento, ejercitacin, prctica, adquisicin de habilidades de
procedimiento, memorizar; Instruir (conducir aprendizajes); Introduccin y
actualizacin de conocimientos previos; Ncleo central de un tema; Repaso,
218
refuerzo; Recuperacin; Ampliacin, perfeccionamiento; Entorno para la
exploracin (libre o guiada), descubrimiento; Entorno para experimentar, Investigar
(explorar el conocimiento); Evaluacin; Medio de expresin personal (escrita, oral,
grfica); Medio de comunicacin; Instrumento para el proceso de datos;
Entretenimiento
El entorno en el que se utilizar: Espacio, en el aula normal, en la biblioteca o
sala de estudio, en el aula informtica, en la empresa, en casa; Tiempo,
escolar/laboral, extraescolar, en casa; Otras caractersticas y condicionantes.
La organizacin de la actividad: Se considerar especialmente: Agrupamiento,
individual, parejas, grupo pequeo, grupo grande; mbito de aplicacin, todos los
estudiantes, slo algunos estudiantes (refuerzo, recuperacin, ampliacin de
conocimientos), slo el profesor.
La metodologa: La manera en la que se va a utilizar el programa: Papel del
programa (Informacin que facilitar al estudiante, Tareas que propondr, Modo
en que debern realizarse); Papel de los estudiantes (Tareas que realizarn los
estudiantes; Nivel de autonoma en el uso del programa, si es libre, semidirigido,
dirigido, siguiendo las instrucciones especficas del profesor; Interacciones de
cada estudiante (Con el programa, Con otros compaeros: consultas, opiniones,
comentarios, Con el profesor: consultas, orientaciones, ayudas, Con otros
materiales fuentes de informacin); Tcnicas de aprendizaje que se utilizarn (
Repetitivas (memorizando), Elaborativas (relacionando la nueva informacin con la
anterior): subrayar, resumir, esquematizar, elaborar diagramas y mapas
conceptuales, Exploratorias: explorar, experimentar, Regulativas (analizando y
reflexionando sobre los propios procesos cognitivos, metacognicin)); Papel del
profesor (Informacin inicial a los estudiantes (objetivos, trabajo a realizar,
materiales y metodologa, fuentes de informacin), Orientacin y seguimiento de
los trabajos (dinamizacin, asesoramiento y orientacin); Tcnicas de enseanza
que se utilizarn ( Motivacin, Ejercicios de memorizacin, Prcticas para la
adquisicin de habilidades de procedimiento, Enseanza directiva, Exploracin
guiada, Experimentacin guiada, Descubrimiento personal, Expresin personal,
Comunicacin interpersonal, Metacognicin.
Empleo de materiales complementarios. Cules?, cmo?
El sistema de evaluacin que se seguir para determinar en que medida los
estudiantes han logrado los aprendizajes previstos y la funcionalidad de las
estrategias didcticas utilizadas.
DISEO DE ACTIVIDADES CON SOPORTE MULTIMEDIA
Contexto educativo
.
219
Estudiantes
(edad, capacidades, conocimientos...)
Objetivos que se persiguen
.
.
.
Contenidos que se tratan
(hechos, conceptos, procedimientos, actitudes)
.
.
.
Programa multimedia
(subrayar uno o varios de cada apartado)
FUNCIN QUE REALIZAR: ENTRENAR - INSTRUIR - INFORMAR - MOTIVAR -
EXPERIMENTAR -
EXPRESARSE - COMUNICARSE - ENTRETENER - EVALUAR - PROCESAR DATOS
ENTORNO DE USO:CLASE-AULA INFORMTICA-OTRAS SALAS-USO EXTRAESCOLAR-
CASA
ORGANIZACIN: TODOS LOS ESTUDIANTES-ALGUNOS-SLO PROFESOR
USO INDIVIDUAL - PAREJAS - GRUPO - - - TODOS A LA VEZ - SUCESIVAMENTE
El programa
(informacin que facilitar, tareas que propondr)
.
.
El estudiante
(tareas, autonoma, interacciones, tcnicas de aprendizaje)
.
220
.
El profesor
(informacin inicial, seguimiento, tcnicas de enseanza)
.
.
Sistema de evaluacin
.
Tabla 76: Ficha de Diseo de actividades
9.5.3 Aspectos a considerar en la evaluacin contextual
La evaluacin contextual considera la forma en la que un determinado
programa, independientemente de su calidad tcnica y pedaggica, ha sido
utilizado en un contexto educativo concreto, valorando su eficacia y eficiencia.
Como en definitiva durante la sesin de trabajo con el programa los estudiantes
han realizado unas actividades cognitivas, se trata de valorar en que medida han
sido las ms idneas para lograr los objetivos previstos y de que manera se poda
haber organizado mejor la sesin.
La evaluacin contextual tiene en cuenta los objetivos educativos que se
pretendan y el grado en el que se han logrado, los contenidos tratados, el empleo
de la infraestructura disponible, las caractersticas de los estudiantes y la
estrategia didctica utilizada por el profesor.
Los objetivos educativos y los resultados obtenidos: A partir de la
consideracin de los objetivos educativos previstos y los contenidos que se han
tratado se evalan los aprendizajes realizados por los estudiantes para determinar
el grado en el que se han conseguido. Este estudio constituye la parte ms
importante de la evaluacin contextual. Si se han conseguido los objetivos
previstos queda demostrado que la utilizacin del programa ha sido correcta; en
caso contrario, habr que revisar con ms detalle los dems elementos: la
adecuacin del programa a los estudiantes, el aprovechamiento de la
infraestructura y la metodologa que se ha empleado.
Los contenidos tratados: Su grado de profundidad y extensin. Ha sido
suficiente?
Los recursos utilizados: Al evaluar los recursos empleados se pretende
determinar el aprovechamiento que se ha hecho de los medios materiales
disponibles y considerar la posibilidad de utilizarlos de otra forma ms eficiente.
221
Los alumnos: Aqu deben considerarse las caractersticas de los estudiantes:
edad, conocimientos y habilidades previas, experiencias anteriores, capacidades,
estilos cognitivos e intereses, a fin de determinar el grado de adecuacin de las
actividades del programa a las circunstancias de los alumnos. Tambin se
considerarn aspectos como la motivacin de los estudiantes durante la sesin y
su opinin sobre las actividades realizadas.
La organizacin y la metodologa didctica: La metodologa didctica utilizada
por el profesor constituye el principal elemento determinante del xito de la
intervencin didctica, por lo tanto se considerarn: las actividades previas
realizadas sobre la materia del programa, la motivacin que ha realizado el
profesor antes de la sesin, la distribucin de los estudiantes, la autonoma que se
les ha dado para interactuar con el programa, las sugerencias y seguimiento que
ha realizado durante la sesin, las actividades posteriores, etc.
Instrumentos para la evaluacin contextual: La evaluacin de la eficacia y la
eficiencia de un programa debe realizarse a partir de la observacin de su
utilizacin por parte de los estudiantes y de los profesores y mediante la recogida
de informaciones de diverso tipo: Informes ( caractersticas de los estudiantes);
Informes(aprendizajes realizados y objetivos previstos); Observacin e informacin
del profesorado (utilizacin de los recursos disponibles, caractersticas del
material, metodologa utilizada); Valoraciones de los estudiantes sobre su
percepcin de los aprendizajes realizados, utilidad del programa y nivel de
satisfaccin; Valoraciones de los profesores sobre los aprendizajes realizados por
los estudiantes, utilidad del programa y nivel de satisfaccin.
222
Allen, R. y Garlan, D. (1997). A Formal Basis for Architectural Connection. ACM
Trans. on Software Engineering and Methodology.
A. Cechich, M. Piattini and A. Vallecillo (Eds.). Component-Based Software
Quality: Methods and Techniques, LNCS 2693, Springer-Verlag, 2003.
Bosch, J. (1996). Language Support for Component Communication in LayOM. En
Muhlhauser, M. (ed.), Special Issues in Object-Oriented Programming. Workshop
Reader of ECOOP96, pags. 131138. Dpunkt Verlag.
CALERO, C. y Otros,CALERO, CORAL / MORAGA, Ma ANGELES / PIATTINI
VELTHUIS, MARIO G. Calidad Del Producto Y Proceso Software. Editorial RA
MA . 2010
Cavano, J.P., McCall, J.A., A Framework for the Measurement of Software Quality,
Proc. of the ACM Software Quality Assurance Workshop, pp. 133-139, Nov. 1978.
De Millo, R. A. et al., Software Testing and Evaluation, Benjamin/Cummings Pub.
Co., 1987.
Eclipse Fundation, Eclipse An open development Platform, Eclipse
Foundation,2007.
Hivart, M.P.; Romain, M.M.; Software Quality measurement in complex systems,
Proceedings 7th International Conference on Reliability and Maintainability; Brest,
France; pp. 18-22, Jun. 1990.
ISO/IEC 9126-1:2001. Software engineering product quality part 1: Quality model.
International Standard ISO/IEC 9126-1, International Standard Organization, June
2001.
ISO, ISO/IEC 25000 Software and system engineering Software product
Quality Requirements and Evaluation (SQuaRE) Guide to SQuaRE, ISO, 2005.
James A. McCall, Paul K. Richards, and Gene F. Walters. Factors in software
223
quality, volume III: Preliminary handbook on software quality for an acquisition
manager. Technical Report RADC-TR-77-369, vol. III, Hanscom AFB, MA 01731,
1977.
Miller, E., Howden, W. E., Tutorial, Software Testing & Validation Techniques, 2a
ed., IEEE Computer Society Press, 1981.
Norma ISO/IEC TR 9126-3: 2003 - Software engineering -- Product quality --
Otto Preiss, Alain Wegmann, and Jason Wong. On quality attribute based software
engineering. In Proc. of the 27th Euromicro Conference, Warsaw, Poland,
September 2001. IEEE CS Press.
Richards Adrion, W., Branstad M.A., Cherniavsky, J.C., Validation, Verification and
Testing of Computer Software, Computing Surveys, Vol. 14, No 2, pp. 159-192,
Junio 1982.
Rodrguez Nuria, Martnez William.Planificacin y evaluacin de Proyectos
Informticos. Editorial Universidad Estatal a Distancia, San Jos, Costarrica. 2006.
Wesley. 2001
http://www.monografias.com/trabajos5/inso/inso.shtml
http://www.willydev.net/descargas/articulos/general/CalidadSoftware.pdf
http://www.lcc.uma.es/~av/Docencia/Doctorado/tema1.pdf
http://www.iso.org
http://www.bulltek.com/Spanish_Site/ISO%209000%20INTRODUCCION/TL
%209000%20Spanish/ISO9000-3_Spanish/iso9000-3_spanish.html
http://www.gestiopolis.com/canales2/gerencia/1/modcalidad.htm

Modulo Evaluacion Software 2010

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modulo Evaluacion Software 2010

Cargado por

Copyright:

Formatos disponibles

ESCUELA DE CIENCIAS BASICAS

También podría gustarte