Embed Size (px)
Citation preview
UNIDAD PROFESIONAL INTERDISCIPLINARIA
DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
“CALIDAD DEL SOFTWARE”
T E S I S
México, D.F. 2010.
INSTITUTO POLITÉCNICO NACIONAL
QUE PARA OBTENER POR EL TÍTULO DE:
LICENCIADO EN CIENCIAS DE LA INFORMÁTICA
P R E S E N T A:
ROSA ELENA AYALA FUENTES
ÍNDICE
RESUMEN .......................................................................................................... I
INTRODUCCIÓN .............................................................................................. VI
CAPÍTULO I
FUNDAMENTOS DE CALIDAD DEL SOFTWARE
1.1 MODELOS Y CARACTERÍSTICAS DE CALIDAD .................................... 4
1.1.1 MODELOS DE CALIDAD ................................................................... 5
1.1.1.1 MODELO PROSOFT (Programa para el Desarrollo de la
Industria del Software) ............................................................................. 6
1.1.1.2 MOPROSOFT ............................................................................ 10
1.1.1.3 NORMA ISO 9000-2000 ............................................................ 11
1.1.1.4 NORMA ISO/IEC TR 15504 ...................................................... 11
1.1.1.5 MODELO DE CAPACIDAD Y MADUREZ P-CMM (Capability
Maturity Model) ...................................................................................... 12
1.1.1.6 MODELO SPICE (Software Process Improvement Capability
determination) ........................................................................................ 16
1.2 CALIDAD DE PROCESO DE INGENIERIA DE SOFTWARE ................... 21
1.3 CALIDAD DEL PRODUCTO DE SOFTWARE .......................................... 22
1.3.1 MODELO DE CALIDAD PARA CALIDAD INTERNA Y EXTERNA .. 23
1.3.2 MODELO DE CALIDAD PARA CALIDAD EN USO ......................... 26
1.3.3 CALIDAD DE SOFTWARE BASADO EN COMPONENTES ............ 27
1.3.3.1 CARACTERÍSTICAS ................................................................. 29
1.4 MEJORA DE CALIDAD ............................................................................. 37
1.4.1 RECOMENDACIONES PARA LA MEJORA CONTÍNUA ................. 41
1.4.2 IMPORTANCIA DE LA MEJORA CONTINUA ................................. 42
CAPÍTULO II
PROCESOS DE ADMINISTRACIÓN DE CALIDAD DE SOFTWARE
2.1 GARANTÍA DE LA CALIDAD DE SOFTWARE ........................................ 44
2.2 ASEGURAMIENTO DE LA CALIDAD ....................................................... 48
2.3 CONTROL DE LA CALIDAD DEL SOFTWARE ....................................... 49
2.3.1 CARACTERÍSTICAS DEL CONTROL DE LA CALIDAD ................. 51
2.4 CERTIFICACIÓN DE LA CALIDAD .......................................................... 52
2.5 COMPROBACIÓN & VALIDACIÓN ......................................................... 54
2.6 EVALUACIONES Y AUDITORIAS ............................................................ 55
2.6.1 PROCESO DE EVALUACIÓN ........................................................ 57
2.6.2 INSPECCIONES .............................................................................. 64
2.6.2.1 EL PROCESO DE INSPECCIÓN .............................................. 66
2.6.3 RECORRIDOS COMPLETOS ......................................................... 69
2.6.4 AUDITORIAS ................................................................................... 69
CAPÍTULO III
CONSIDERACIONES PRÁCTICAS
3.1 REQUERIMIENTOS DE CALIDAD DE SOFTWARE ................................ 72
3.1.1 DEFINICIÓN DE REQUERIMIENTOS DE CALIDAD (DReC ) ........ 75
3.1.2 DESCRIPCIÓN DE LA TÉCNICA DReC ......................................... 77
3.1.3 DOCUMENTACIÓN DE LA TÉCNICA ............................................ 80
3.1.4 APLICACIÓN DE LA TÉCNICA ....................................................... 81
3.2 INFLUENCIA EN LOS FACTORES ........................................................... 82
3.3 SERIEDAD ................................................................................................. 83
3.4 NIVELES DE INTEGRIDAD DEL SOFTWARE ......................................... 83
3.5 CARACTERIZACIÓN DE DEFECTO......................................................... 84
3.6 TÉCNICAS DE DIRECCIÓN DE CALIDAD DE SOFTWARE .................... 86
3.6.1 TÉCNICAS ESTÁTICAS .................................................................. 87
3.6.2 TECNICAS PERSONALES INTENSIVAS ........................................ 87
3.6.3 TÉCNICAS DE EVALUACIÓN ......................................................... 88
3.6.4 TÉCNICA ANALÍTICAS .................................................................... 89
3.6.5 TÉCNICAS DINÁMICAS .................................................................. 90
3.7 PRUEBA .................................................................................................... 90
3.7.1 CLASIFICACIÓN DE PRUEBAS DEL SOFTWARE........................ 92
3.7.2 MARCO DEL TESTEO ..................................................................... 95
3.7.3 MÉTODOS DE TESTEO .................................................................. 95
3.7.4 TIPOS DE PRUEBAS DINÁMICAS.................................................. 97
3.7.5 FASES DE LAS PRUEBAS DINÁMICAS ........................................ 99
3.8 MEDICIÓN DE LA CALIDAD DEL SOFTWARE ..................................... 101
3.8.1 MÉTRICAS DE LA DOCUMENTACIÓN DEL SOFTWARE ........... 105
3.8.2 MÉTRICAS EN LA REUTILIZACIÓN ORIENTADA AL OBJETO ... 106
3.8.3 CALIDAD Y MÉTRICAS VS. REUTILIZACIÓN .............................. 106
CONCLUSIÓN ............................................................................................... 110
BIBLIOGRAFÍA ............................................................................................. 111
I
RESUMEN
CAPITULO 1
FUNDAMENTOS DE CALIDAD DE SOFTWARE
En este capitulo se da una introducción de lo que es la ingeniería de software y
la importancia actual de la calidad del software enfocándonos a la resolución
de dos preguntas esenciales, la primera ¿cómo poder obtener un software de
y con calidad? Y la segunda ¿cómo se puede evaluar dicha calidad a fondo y
completamente?.
La calidad del software busca poder alcanzar dentro de un producto de
software características tales como: Confiabilidad, soporte logístico, agilidad de
respuesta, flexibilidad, facilidad de adopción, integridad, consistencia,
congruencia de diseño y producto, sencillez, entre otros.
Esto es conseguir hoy por hoy productos portables, fáciles de mantener y/o
ampliar, sencillos de entender, de validación accesible, compatibles con otros
sistemas rápidos y efectivos, más un sinfín de características que provoque el
terminar o trascender la llamada crisis del software.
Algunas de las características que debe cumplir un software son corrección,
fiabilidad, eficiencia, facilidad de uso, facilidad de mantenimiento entre otras,
mientras más características reúna un desarrollo de software mayor será su
calidad.
Existen varios modelos de calidad muy útiles que pueden ser usados para
evaluar y medir la calidad de un software algunos de ellos son el modelo
SPICE, el modelo CMM, el modelo PROSOFT y MOPROSOFT entre otros.
La calidad del software tiene dos enfoques diferentes por un lado tenemos a la
calidad del proceso que es cuando se diseña, desarrolla y construye el
software así como cuando se mantiene y por otro lado se tiene la calidad del
producto que es la mejora que se le hace a todo el proceso y al producto en
II
general para esto es necesario comprender desde el principio del proyecto las
necesidades reales y completas de los usuarios con tanto detalle como sea
posible (requerimientos) mientras mas claras y detalladas sean mas fáciles de
solucionar e implementar van a ser.
La Calidad Total en Informática, es el resultado del movimiento global dentro
del proceso de mejoramiento continuo de los estándares de producción en
todos los sectores industriales, en particular, cuando éste se concentra en la
producción de sistemas de información y software especializado. Como la
calidad total no es un producto sino una actividad, la industria del software se
ha visto afectada muy radicalmente y por lo mismo es de gran importancia.
En la actualidad los productores de software están en una situación más
dramática que hace unos años, pues no sólo quieren producir software con
crecientes características de calidad, también tienen la necesidad de producir
software más sofisticado.
Con la mejora continua en las organizaciones se logra a que se desarrollen sus
procesos de una manera más productiva y eficiente para así reducir costos y
poder ofrecer un producto o servicio de calidad.
En el mundo actual, la gestión del conocimiento por parte de la empresa,
adquiere nuevas características, determinadas por la gestión de la información
y de la calidad. En las organizaciones más modernas cohabitan,
indisolublemente ligadas, la gestión de información, del conocimiento y de la
calidad; ellas son organizaciones de excelencia, donde la ética, la motivación y
el buen desempeño rinden incrementos constantes en los resultados y en el
reconocimiento de las empresas.
III
CAPITULO 2
PROCESOS DE ADMINISTRACIÓN DE CALIDAD DE SOFTWARE
Para poder llevar a cabo exitosamente la gestión de la calidad del software es
necesario dejar muy claros los beneficios que va a proporcionar el hecho de
tener que estandarizar y controlar los procesos y formas de trabajo ya
existentes dentro de la organización, ya que es difícil que una organización se
adapte a cambios y nuevos procedimientos sin saber en que los va a beneficiar
hacerlos.
Desarrollar un plan de administración de software no es para nada una tarea
fácil ya que es un factor critico dentro la calidad del software, afortunadamente
actualmente los consultores o evaluadores están haciendo mucho mas fácil
este proceso.
Algunos de los factores que afectan la calidad del software son corrección,
fiabilidad, eficiencia, integridad, facilidad de uso, flexibilidad, facilidad de prueba
entre otras.
Existe un concepto llamado Gestión de la calidad del software que no es otra
cosa que administrar las actividades que se deben llevar a cabo antes, durante
y después de la construcción de un software para alcanzar la calidad del
mismo. Esta actividad le corresponde y se aplica normalmente a las empresas
en el área directiva de la misma, aunque también puede existir dentro de un
proyecto en especifico.
En dicha gestión se determinan la calidad, los objetivos y las responsabilidades
del desarrollo de un producto y se apoya de medios tales como la planificación
de la calidad, el control de la calidad, el aseguramiento de la calidad, la mejora
de la calidad, la comprobación y validación de la calidad, la certificación de la
calidad, evaluaciones , auditorias , inspecciones de la calidad, todos ellos
apoyados en modelos y técnicas que mas se adapten a la organización y que a
la larga y con una buena aplicación pueden arrojar resultados muy
satisfactorios.
IV
CAPITULO 3
CONSIDERACIONES PRÁCTICAS
Los requerimientos del software son una descripción abstracta de los servicios
que el sistema debería proporcionar al cliente, y las limitaciones bajo las cuales
éste debería operar.
La determinación de requerimientos de calidad es un proceso de fijación de
valores (niveles de calidad y estimación de métricas) que serán tomados
inicialmente para la planificación de la calidad y posteriormente como
referencia para la evaluación del producto software.
El usuario es un actor importante en la determinación de los requerimientos de
calidad y su punto de vista debe ser sistemáticamente obtenido.
El desarrollador es un actor que opondrá la opinión del usuario, pero debe
subordinar –finalmente- su opinión a la del usuario si no existe un consenso
sobre los valores de las mismas.
Todo requerimiento debe cumplir con diversos factores como son la seriedad al
realizar el producto, los niveles de integridad del software para evitar posibles
fracasos y la caracterización de los defectos que sirve para futuras revisiones.
Existen varias técnicas de dirección de calidad del software, por ejemplo, las
técnicas estáticas que son aplicadas a la documentación del proyecto, las
técnicas personales intensivas se basan en revisiones y auditorias y requieren
de mas de una persona, técnicas analíticas como análisis de la complejidad,
control del análisis del flujo, y el análisis algorítmico, las técnicas dinámicas que
Incluyen técnicas de prueba, pero también la simulación, el chequeo de
modelos y la ejecución simbólica pueden ser consideradas dinámicas.
V
También tenemos las pruebas que son los procesos del aseguramiento
descritos en la SQA y V&V examinan cada salida concerniente a la
especificación del requerimiento del software para asegurar la consistencia, lo
completo, la corrección, y el buen funcionamiento del software.
Existen varios tipos de pruebas como son prueba genérica, prueba dinámica,
marco del testeo etc.y que aplicadas correctamente resultan bastante efectivas
para enviar un software de calidad.
Por último tenemos la Medición y las métricas que ya sean para el proceso de
desarrollo del software como para la documentación, como para programación
tradicional y orientada a objetos y ahora también dentro de la creación de
software para la reutilización son y serán instrumentos que nos ayuden a tener
una visión más amplia de cómo van y como salieron las cosas al final del
trabajo.
VI
INTRODUCCIÓN
Actualmente la palabra "calidad" se usa cada vez con más frecuencia en las
empresas, ya sea en los sectores de alimentos, industria o servicios y
especialmente en el sector de Tecnología Informática (TI).
Dicha atención se debe en gran parte al interés de la industria sobre la calidad
y a la necesidad de controlar gastos de mantenimiento crecientes.
Hasta hace poco la calidad era responsabilidad del ingeniero de software o el
programador, sin embargo, el creciente interés sobre la calidad del software ha
generado un aumento en el numero de organizaciones enfocadas a la calidad.
El éxito de una organización es dependiente de varios factores: el avance de
tecnologías de calidad de software, compromiso de dirección de alto nivel, y
recursos técnicos y humanos adecuados.
El concepto de calidad tiene varias definiciones formales. Algunas de ellas
ponen mayor énfasis en el producto y otras en el cliente o el servicio. Sin
embargo, todas tienen un mensaje común, que es el de obtener una mejora, ya
sea en el producto software, o en los procesos que llevan a la creación del
mismo.
Para aumentar la calidad se establecen una serie de metodologías formales y
buenas prácticas que permiten tener control sobre lo que está ocurriendo en
todos los niveles del ciclo de vida del software y así poder evaluarlo y
mejorarlo.
Gracias a ellas, se consigue no sólo que el producto final tenga las
características que deseamos (robustez, usabilidad, correctitud, fiabilidad, entre
otros) sino que los procesos asociados sean positivos, los tiempos de entrega
disminuyan, los costos se reduzcan y la satisfacción del cliente sea la
esperada.
VII
Por supuesto existen modelos, métricas y herramientas que complementan
estos procesos y nos ayudan en la mejora de la calidad.
En este proyecto de investigación se pretende cubrir los siguientes objetivos;
• Uno: Clarificar el significado del término Calidad en el desarrollo del
software.
• Segundo: Identificar los diferentes aspectos que se deben considerar
durante el proceso de calidad del software, desde su definición hasta su
mantenimiento, conocer los diferentes modelos de calidad y la técnicas
de medición de la misma y por ultimo conocer y considerar las ventajas
que un software de calidad representa.
Para cubrir dichos objetivos primero debemos entender bien a que se le llama
calidad del software hay quien piensa que la calidad es un simple papeleo
pesado, o muchas reuniones para establecer un proceso, conseguir un sello
de calidad en nuestro producto y así mejorar su publicidad punto que resultaría
muy poco efectivo para la calidad del software, o piensan que simplemente es
tener un producto mejor que el de la competencia sin importar costos ni
garantías. La calidad va mucho mas allá de todo eso y por lo mismo es un tema
que debe preocuparnos ya que los clientes quieren un producto de calidad y
por lo tanto evalúan las soluciones que se les proporcionan, muchas veces con
ayuda de auditores o gente conocedora del campo, los proyectos y definición
de los requerimientos siempre varia de uno a otro, exigen fiabilidad y seguridad
y muy a menudo preguntan o quieren conocer el proceso con el que se
desarrollo su proyecto.
Por todo lo anterior el siguiente proyecto nos presenta los métodos y modelos
que nos pueden ayudar a mejorar la calidad de nuestro producto, así como las
técnicas de dirección de la administración del software, las métricas y/o
medidas de dicho producto todo con el mismo objetivo: presentar un proyecto
que satisfaga las exigencias y necesidades del cliente, que sea seguro y
confiable, que su mantenimiento y su adaptación a otros sistemas y cambios
dentro del mismo sean los propios y sobre todo que los costos no representen
mas que una ganancia una perdida para el cliente
1
CAPÍTULO I
FUNDAMENTOS DE CALIDAD DEL SOFTWARE
Actualmente en el ámbito de la computación se ha venido presentando un
problema bastante serio sobre todo para la industria del software, dicho
problema es la calidad del software. Desde hace varias décadas este tema se
volvió un tema de preocupación para ingenieros, maestros, desarrolladores,
alumnos, productores, investigadores e industriales. Todos ellos preguntándose
y enfocándose a dos preguntas esenciales:
La primera ¿cómo poder obtener un software de y con calidad? Y la segunda
¿cómo se puede evaluar dicha calidad a fondo y completamente?.
Es bien sabido que la industria de la construcción de software es una industria
en la que el concepto de calidad ha generado una gran revolución, primero
que nada por el hecho de que es una disciplina relativamente joven en
comparación a muchas otras en los que los estándares de calidad ya van en
versiones muy avanzadas.
Otro aspecto importante que nos frena en cuanto a lograr calidad es que dicha
industria exige y crece mas rápido que las mismas metodologías y capacidad
de las personas, porque aunque todo se facilita poco a poco por ejemplo el uso
de herramientas CASE (Software de Ingeniería asistida por Computadora), la
ingeniería de software requiere todavía de mucho capital humano e intelectual,
no de insumos ni de materias primas.
Tales circunstancias han provocado una llamada crisis del software, que
principalmente se manifiesta en la demora en entregas del producto, los
excesos de presupuestos, la falta de cumplimiento de los requerimientos
iniciales, entre otros.
2
La pregunta es ¿Existen criterios para evaluar la calidad del software?
Anteriormente la calidad de un programa o sistema se evaluaba de acuerdo al
número de defectos por cada mil líneas de código. En 1988, un estudio
realizado en los EEUU, demostró que se introducían cerca de sesenta defectos
por cada mil líneas de código (60 def/KLOC), durante las etapas de análisis,
desarrollo y puesta en operación ya en la producción la cantidad aumenta.
Actualmente para alcanzar un completo y preciso concepto de la calidad del
software se requiere una clara y eficaz congruencia entre los requerimientos y
características del producto, para poder alcanzar una plena satisfacción del
usuario.
Por lo tanto ahora se busca poder alcanzar dentro de un producto de software
características tales como: Confiabilidad, soporte logístico, agilidad de
respuesta, flexibilidad, facilidad de adopción, integridad, consistencia,
congruencia de diseño y producto, sencillez , entre otros.
Esto es conseguir hoy por hoy productos portables, fáciles de mantener y/o
ampliar, sencillos de entender, de validación accesible, compatibles con otros
sistemas rápidos y efectivos, más un sinfín de características que provoque el
terminar o trascender la llamada crisis del software.
Ahora bien, se sabe que el reto es grande porque no se ha respondido la
pregunta: ¿cómo podemos lograr la gestión y el aseguramiento de la calidad en
el software que se produce?
Podría ser que como primer respuesta se buscará la implementación de la
calidad total en la producción del mismo, esto es, buscar el compromiso
altamente estrecho entre todas las áreas de una organización, incluyendo
servicios y mantenimiento después de la venta.
Claro esta que este debe ser un proyecto planeado a largo plazo ya que
conlleva el cambio y adaptación a muchas nuevas reglas, políticas y
procedimientos, pero sobre todo el paso a un amplio concepto de lo que es
cultura de la calidad total.
3
Dentro de un programa de gestión y aseguramiento de la calidad se deben
tomar en cuenta varios aspectos, primero el modelo a seguir y la definición de
lo que es calidad para la propia empresa o institución, identificar componentes
tipo de resultado y tipo de contribuyente, fijar metas, objetivos y tiempos,
técnicas de medición y de comparación, entre muchas otras cosas que mas
adelante se podrán percibir mas claramente.
Por lo anterior puedo afirmar en términos generales que la industria del
software aun no ha acabado de salir de la fase artesanal, padecemos la
llamada “prisa patológica”, que es consecuencia de aspectos tales como:
• Desorganización.
• Falta de planificación.
• Alta dependencia de los “héroes”.
• Dedicamos nuestros esfuerzos de hoy a arreglar lo que se hizo mal ayer.
• El producto (software) es algo intangible y no constreñido por las leyes
físicas.
• La disciplina, ingeniería del software, es relativamente reciente y muchos
de sus conceptos importantes están aún inmaduros.
• Carencia de un corpus de conocimiento aceptado mayoritariamente que
sirva como fundamentos.
• Escasa presión del mercado.
Todos estos factores dan como resultado una empresa inmadura carente de la
capacidad para alcanzar una calidad total y por lo tanto la mantiene alejada de
lograr productos de software con calidad y mucho menos le permite gestionar
sus procesos de calidad ni evaluar efectivamente sus productos frente a otros
en el mercado.
Algunos aspectos que se pueden observar dentro de una organización
inmadura ante el hecho de crear software de calidad son:
4
• Procesos software normalmente improvisados.
• Si se han especificado, no se siguen rigurosamente.
• Organización reactiva (resolver crisis inmediatas).
• Planes y presupuestos excedidos sistemáticamente, al no estar basados
en estimaciones realistas.
• Si hay plazos rígidos, se sacrifican funcionalidad y calidad del producto
para satisfacer el plan.
• No existen bases objetivas para juzgar la calidad del producto.
• Cuando los proyectos están fuera de plan, las revisiones o pruebas se
recortan o eliminan.
• El 90% de los proyectos no alcanzan los objetivos.
• El 40% fracasan por completo.
• El 29% no se entregan nunca.
• Gastos de adaptación tecnológica al año 2000.
• Coste de demandas y litigios legales añadidos.1
1.1 MODELOS Y CARACTERÍSTICAS DE CALIDAD
Algunas características de calidad con las que debe contar cualquier producto
de software para poder cumplir los requerimientos de usuario así como tiempos
de entrega y confiabilidad son:
Corrección.- Que se refiere a si el producto de software hace lo que se quiere.
Fiabilidad.-Si el producto trabaja de forma fiable todo el tiempo.
Eficiencia.- Si el software se ejecutará en mi hardware lo mejor que pueda.
Seguridad (Integridad).-Se hace la pregunta de si el software es seguro.
Facilidad de uso.- Que tanto está diseñado para ser usado.
Facilidad de mantenimiento.- Si después de entregado se puede corregir.
Flexibilidad.- En algún momento puedo llegar a cambiarlo.
Facilidad de prueba.- Que tan fácil es probarlo.
Portabilidad.- Se refiere a si podré usarlo en otra máquina.
Reusabilidad.- Podré reutilizar alguna parte del software.
1 www.calidaddelsoftware.com.
5
Interoperabilidad.- Podré hacerlo interactuar con otro sistema.
Podríamos listar muchas características más, ya que la calidad es algo muy
complejo y extenso, es claro también que no siempre podremos lograr cubrir en
su totalidad todas y cada una de ellas pero es importante saber que mientras
mas nos acerquemos a cumplirlas mayor calidad tendrá nuestro software.
Existen varios modelos de calidad de software muy útiles, algunos más
complejos que otros pero todos con un mismo fin, lograr la construcción de un
software de calidad que pueda ser medido y evaluado, así como también
comparado con otros, y que por consiguiente sea un software que cubra al
100% los requerimientos iniciales del usuario-cliente.
Dichos modelos de calidad se pueden clasificar en dos grandes grupos:
� Factores que pueden ser medidos directamente.
� Factores que solo pueden ser medidos indirectamente.
Las características se centran en tres aspectos importantes de un producto
software (McCall):
� Características operativas.
� Capacidad de soportar los cambios.
� Adaptabilidad a nuevos entornos.2
1.1.1 MODELOS DE CALIDAD
Un modelo de calidad es un conjunto de buenas prácticas para el ciclo de vida
del software, enfocado en los procesos de gestión y desarrollo de proyectos.
Existen diferentes modelos que incluyen métricas para evaluar diferentes
atributos o características de calidad del producto casi siempre en el nivel del
diseño o del código durante la etapa de desarrollo del software.
2 www.ingenierosoftware.com/calidad
6
Los modelos más actuales generalmente están enfocados a la mejora de
procesos, ya que la idea de calidad total se refiere a la calidad desde el inicio
del proyecto y el hecho de tener mejores procesos nos conlleva a un mejor
resultado.
Algunos modelos de calidad son:
• Modelo PROSOFT.
• Modelo MOPROSOFT.
• NORMA ISO 9000-2000 .
• NORMA ISO/IEC TR 15504.
• Modelo CMM(Modelo de Capacidad y Madurez).
• Modelo SPICE (Mejora de Procesos de Software y capacidad de
determinación).
A continuación se explicará de manera detallada cada uno de los modelos con
el objeto de comprender y tener una visión más amplia de los estándares de
calidad.
1.1.1.1 MODELO PROSOFT (Programa para el Desarrollo de la Industria
del Software)
El modelo PROSOFT se define como:
“El Plan Nacional de Desarrollo 2001 - 2006 que plantea el fomento a la
industria y el mercado de Tecnologías de la Información (TI) con el
objetivo de crear una estrategia para aumentar la competitividad del país.
Como es bien sabido las TI tienen un efecto transversal en toda la
economía de una nación, razón por la cual impactan positivamente la
competitividad de todos los sectores.” 3
3 www.economia.gob.mx/
7
México cuenta con un gran potencial para desarrollar la industria del software
por eso la Secretaría de Economía, en coordinación con organismos
empresariales y empresas del sector tecnológico, diseñaron el Programa para
el Desarrollo de la Industria del Software (PROSOFT).
A continuación menciono algunas estadísticas interesantes acerca de la
situación mexicana dentro de la industria del software:
Actualmente México se ubica en el lugar 50 a nivel mundial con un nivel de
gasto en tecnologías de información y comunicaciones de 3.2% del PIB
(Producto Interno Bruto). Así mismo este rezago es aún mayor en términos de
gasto en software, que es 6 veces inferior al promedio mundial y 9 veces menor
que el de EUA, a diferencia de países como la India, Irlanda y Singapur que
han logrado alcanzar el éxito en base a su industria de software que es la base
de su crecimiento económico.
Realmente México tiene un gran potencial y oportunidades para desarrollar
esta industria al máximo dada su cercanía geográfica y en algunos de sus
estados el mismo huso horario con el mercado de software mas grande del
mundo (EUA), también la red de tratados comerciales mas extensa del mundo
y la afinidad con la cultura de negocios occidental.
Por todo esto el objetivo principal del programa PROSOFT es impulsar
precisamente la industria de software y extender el mercado de tecnologías de
información en México.
PROSOFT tiene fijadas varias metas y estrategias que se pretenden aplicar y
alcanzar a partir de hoy al año 2013, a continuación se enumeran y describen
brevemente:
METAS:
• Lograr una producción anual de software de 5,000 millones de dólares.
• Alcanzar el promedio mundial de gasto en tecnologías de información.
8
• Convertir a México en el líder latinoamericano de desarrollo de software
y contenidos digitales en español.
ESTRATEGIAS:
Para alcanzar esos objetivos, la Secretaría de Economía en conjunto con la
industria y con los organismos gubernamentales relacionados con el sector,
acordaron desarrollar siete estrategias:
1.- Promover las exportaciones y la atracción de inversiones.- Aprovechando
las ventajas del país por su cercanía y el mismo huso horario que EUA,
procurando que las empresas incursionen en nichos de mercado con un alto
valor agregado.
2.- Educación y formación de personal competente en el desarrollo de software,
en cantidad y calidad necesarias.- Ofreciendo capacitación a los ingenieros y
técnicos que se encuentran en el mercado y la adecuación de los planes de
estudio para que sean acordes con las necesidades de la industria.
3.- Contar con un marco legal promotor de la industria.- Un marco legal que
fomente el uso de tecnologías de información y el desarrollo de la industria con
reglas como la norma de conservación de mensajes de datos, factura
electrónica y firma digital.
4.- Desarrollar el mercado interno.- Apoyando a las empresas para que usen
hardware y software en sus operaciones (Inventarios, Normas, Contabilidad) y
en su relación con proveedores y clientes (Digitalización de Cadenas de Valor).
5.- Fortalecer a la industria local.- Mediante programas de financiamiento
adecuado para sus necesidades de capital de trabajo y capacitación, la
disponibilidad de capital de riesgo, el uso de las compras de gobierno para
desarrollar una industria de calidad y la incubación de nuevas empresas de
software.
9
6.- Alcanzar niveles internacionales en capacidad de procesos.- A efecto de
que las empresas cuenten con las mejores prácticas internacionales en la
producción de sus sistemas. Para ello, se impulsará la normalización, la
creación de una entidad local de certificación, se apoyará la investigación y
desarrollo con el fondo sectorial de apoyo creado por la SE (Secretaria de
Economía) y CONACYT (Consejo Nacional de Ciencia y Tecnología) y se
reconocerá a las mejores empresas a través del Premio Nacional de
Tecnología.
7.- Promover la construcción de infraestructura básica y de
telecomunicaciones.- Apoyando el desarrollo de parques de alta tecnología
vinculados a centros de investigación.
Con estas estrategias se beneficiará no sólo la competitividad de la industria
del software, sino también la de la economía en general, puesto que las
empresas mexicanas tendrán más opciones para incorporar las tecnologías de
información en sus procesos productivos y de comercio.
El Programa para el Desarrollo de la Industria del Software (PROSOFT) se
lanzó el 9 de Octubre del 2002 por la Secretaría de Economía, con el objetivo
de crear las condiciones necesarias para que México cuente con una industria
de software competitiva a nivel internacional y asegurar así el crecimiento de la
misma.
Hoy en día la complejidad con que se realizan los sistemas de información y las
exigencias de los mismos va cada vez mas en aumento, y por lo mismo
muchas veces resulta difícil cumplir con las expectativas de los clientes.
También es cierto que cada día surgen mas herramientas, técnicas y modelos
que nos facilitan esta tarea, ayudando a las empresas encargadas de las
tecnologías de información a generar productos de mayor calidad y que
cumplan con los requerimientos de los clientes, así mismo ayudan también a
mejorar costos y tiempos.
10
Anteriormente aunque se reconocía la necesidad de crear software de calidad
realmente no se había hecho un verdadero esfuerzo por alcanzarla,
afortunadamente surgió PROSOFT que como ya mencione es un programa
realmente enfocado a invertir y no escatimar en recursos tanto humano,
intelectual, económico con el fin de colocar a la industria del software como la
base de la economía mexicana, generando mas empleos y posicionando a
México como líder en construcción de software. 4
1.1.1.2 MOPROSOFT
Este modelo surge como consecuencia del análisis de la sexta estrategia
planteada por el PROSOFT, es un modelo concebido, diseñado y desarrollado
por mentes mexicanas, este modelo esta adecuado específicamente para las
necesidades mexicanas y con ventajas mayores a otros modelos.
Tiene mayores ventajas que los modelos que se mencionaran a lo largo del
capítulo porque fue creado tomando lo mejor de todos esos modelos, sus
mejores practicas integrándolas y mejorándolas.
Algunas ventajas son:
• Fácil de entender.
• Fácil de aplicar.
• No es costoso en su adopción.
• Sirve de base para alcanzar evaluaciones exitosas con otros modelos o
normas.
Dicho modelo esta orientado a pequeñas y medianas empresas, hecho
favorable si se considera que aproximadamente el 80% de las empresas
desarrolladoras de software del país se encuentran en esta categoría.
4 www.software.net.mx/desarrolladores/prosoft.
11
Su principal fortaleza es que integra varias de las prácticas propuestas por los
otros modelos y corrige algunas de sus desventajas, como son el hecho de que
no ha sido liberado por completo o al menos falta el modelo de evaluación;
además, está en proceso de convertirse en norma compitiendo con el proyecto
de norma ISO/IEC TR 15504 y aunque no ha sido aprobado, se planea realizar
pilotos en algunas organizaciones para evaluar qué tan fácil resulta su
implantación determinando los recursos necesarios.
Existen más modelos y normas que también están enfocados a lograr la
calidad del software, pero solo mencionare a groso modo dos de ellas por
considerarlas las de mayor relevancia.5
1.1.1.3 NORMA ISO 9000-2000
Es una norma internacional destinada a evaluar la capacidad de la
organización para cumplir los requisitos del cliente, los reglamentarios y los
propios de la organización.
Algunas de sus ventajas son que tiene un mecanismo de certificación bien
establecido y que además esta disponible y es conocido. Y como desventajas
podemos mencionar que no es específica para la industria de software, no es
muy fácil de entender puesto que no está definida como un conjunto de
procesos y además no es fácil de aplicar ya que se conforma de una fuerte
cantidad de procedimientos.
1.1.1.4 NORMA ISO/IEC TR 15504
Esta norma define el modelo de referencia de procesos de software y de
capacidades de procesos que constituyen la base para la evaluación de
procesos de software. Se compone de 9 partes de las cuales la 2, 3 y 9 son
normativas y las demás informativas.
5 alarcos.inf-cr.uclm.es/doc/calidadSI/Index.htm
12
Como ventajas de esta norma podemos mencionar que es específico para el
desarrollo y mantenimiento de software es fácil de entender (24 procesos, 16
páginas) también esta definido como un conjunto de procesos y esta orientado
a mejorar los procesos para contribuir a los objetivos del negocio.
Y como sus desventajas esta que no es práctico ni fácil de aplicar, además
tiene solamente lineamientos para un mecanismo de evaluación. Y todavía no
es norma internacional.6
1.1.1.5 MODELO DE CAPACIDAD Y MADUREZ P-CMM (Capability Maturity
Model)
P-CMM es un modelo de madurez cuyo objetivo principal es desarrollar el
talento e intelecto humano dentro de las organizaciones de desarrollo y
construcción del software.
Dicho modelo describe el proceso evolutivo desde prácticas inconsistentes y
ad-hoc, hasta el desarrollo del conocimiento y habilidades de una fuerza de
trabajo madura y disciplinada.
Todo esto con el fin de atraer, desarrollar, motivar, organizar y retener el talento
necesario para sostener el proceso de desarrollo de software.
Los objetivos estratégicos del P-CMM son:
• Mejorar la capacidad de las organizaciones de software por incrementar
la capacidad de su fuerza de trabajo.
• Asegurar la capacidad del desarrollo de software que es mas un atributo
de la organización que de solo unos pocos individuos.
• Alinear la motivación de los individuos con el de la organización, es decir
que todos persigan el mismo objetivo.
6 www.monografias.com/modelos/call/call.shtml
13
• Retener el recurso humano dentro de la organización, que se
comprometan y quieran a su empresa y mas que buscar un bienestar o
provecho personal lo busquen para si y para su misma organización.
Este modelo pretende ayudar a las empresas desarrolladoras de software de la
siguiente manera:
Primero pretende caracterizar la madurez de todas sus prácticas en la fuerza
de trabajo, propone también un programa de continuo desarrollo en la fuerza
de trabajo, es decir, que el personal no deje de aprender y crecer en su área de
trabajo, además se pretende priorizar las acciones que se tienen que llevar a
cabo de forma inmediata, integra también el desarrollo continuo de la fuerza de
trabajo con el mismo mejoramiento del proceso y por ultimo pero como punto
más importante para mi es que se propone establecer una cultura de
excelencia en la ingeniería de software.
Este modelo consiste o se lleva a cabo en 5 niveles que continuamente
mejoran los estados laborales, espirituales y sentimentales de los trabajadores,
puesto que genera equipos de trabajo, motiva el desempeño, los alienta a
trabajar, entre otros.
Cada nivel es una plataforma bien organizada que promueve el desarrollo de la
fuerza de trabajo dentro de la organización.
Al llevar a cabo cada uno de estos niveles la organización puede introducir
trabajos o actividades que muy probablemente los empleados no puedan
realizar por no estar bien capacitados para hacerlo.
Nivel 1
En este nivel mas que empezar a introducir o ejecutar procedimientos de
mejora es mas bien analizar si dentro de la empresa se presenta alguno de los
siguientes casos, que obviamente no son positivos o benéficos para la misma
organización.
14
Los puntos a considerar son:
• Si el desempeño de actividades de recursos humanos es inconsistente.
• Si hay formularios (como evaluación de desempeño) pero no se capacita
sobre como utilizarlos.
• Si existen jefes o gerentes sin entrenamiento que realizan sus funciones
pero no saben o no están capacitados para dirigir a la fuerza de trabajo.
• Los gerentes no tienen la habilidad de desarrollar sistemáticamente la
capacidad competitiva de su fuerza de trabajo.
Además de considerar problemas frecuentes por los que la fuerza de trabajo
no puede ser efectiva los cuales son:
• Distractores ambientales.
• Objetivos de desempeño ambiguos.
• Falta de conocimientos o habilidades relevantes.
• Comunicación pobre entre la fuerza laboral misma, ya sea entre
subordinados o entre subordinados y el jefe.
Nivel 2
En este nivel se busca eliminar los problemas de las organizaciones que se
detectaron en el Nivel Inicial. En cuanto al ambiente de trabajo, esta diseñado
para establecer y mantener condiciones de trabajo que permitan concentrarse
en sus tareas, sin distracciones innecesarias o inapropiadas.
Los objetivos planteados en este nivel son poner a disposición de todos los
empleados los recursos necesarios para que se sientan cómodos y contentos
al realizar su trabajo y por consiguiente el desempeño de los procesos mejóre,
además de evitar distracciones en el mismo lugar de trabajo. Desde el punto
de vista de la comunicación se pretende establecer un ambiente social que
permita una interacción efectiva entre todo el personal de la organización y
asegura que la fuerza de trabajo tiene las habilidades para compartir
información y coordinar sus actividades eficientemente.
15
Para el contrato de personal, se establece y usa un proceso formal por medio
del cual el talento es reclutado, seleccionado sin preferencias de ningún tipo
excepto el de la habilidad y conocimientos intelectuales para desempeñar sus
funciones correctamente. También establece criterios objetivos para medir el
desempeño grupal e individual y da retroalimentación sobre el mismo para así
aumentar el desarrollo de los empleados día con día y evitarse el
estancamiento o el que los procedimientos y metodologías así como la forma
en que se llevan a cabo los procesos se vuelvan obsoletos.
Un punto muy importante en el que debe enfatizar la organización es en la
forma en que se provee a todos los individuos con remuneración, premios y
beneficios, que es en una sola palabra la motivación basada en su desempeño
y contribución con la organización la cual es un arma que permite tener a los
empleados comprometidos con los objetivos de la misma.
Nivel 3
Se enfoca en la creación de una estructura organizacional para el desarrollo de
la fuerza de trabajo. En este nivel la organización identifica el conocimiento y
las habilidades necesarias para la realización de las actividades de negocios
también desarrolla planes estratégicos para que la fuerza de trabajo pueda y se
le facilite cumplir los objetivos planteados por la organización a corto y largo
plazo. Existen también las posibilidades de promoción para alentar a las
personas a desarrollar sus capacidades de la mejor y más productiva manera.
Propone también utilizar las habilidades de cada individuo a la hora de llevar a
cabo los procesos de trabajo para establecer roles que sirvan para dar el
siguiente paso en el desarrollo del mismo grupo de trabajo.
Por ultimo se establece una cultura de participación que permite un mejor uso
del talento de la gente dentro de la organización para tomar decisiones y
realizar de forma más efectiva el trabajo.
16
Nivel 4
Las tareas por realizar en este nivel se enfocan principalmente en explotar el
conocimiento y la experiencia de los trabajadores de la organización que se
logro desarrollar en el nivel 3. Los procesos basados en la aptitud son usados
para crear ahora procesos integrados y multidisciplinarios. Los grupos de
trabajo son autorizados para manejar sus propios procesos de trabajo y dirigir
la mayoría de sus actividades. Los resultados obtenidos son capturados y
reutilizados. Los consejeros o jefes se apoyan en la infraestructura creada en
este nivel para atender mejor a los individuos y grupos de trabajo en el
desarrollo efectivo de sus capacidades.
Nivel 5
Las actividades realizadas en este nivel se enfocan en improvisar y mejorar
continuamente las actividades y los procesos de la organización así como
también las actividades de la fuerza de trabajo. Los individuos
consecutivamente mejoran los procesos de trabajo personales que usan y por
consiguiente el mismo grupo de trabajo mejora sus procesos por tomar mano
de la buena ejecución individual de los mismos, así como también la
organización evalúa y mejora la relación de rendimiento entre individuos,
grupos de trabajo y unidades todos en conjunto y con los objetivos de negocios
de la organización. Por último se evalúan las oportunidades para improvisar y
renovar las prácticas de la fuerza de trabajo mediante la mejora o ajustes
increméntales la adopción de practicas nuevas e innovadoras y por supuesto
nueva tecnología que facilite el desarrollo de las mismas.7
1.1.1.6 MODELO SPICE (Software Process Improvement Capability
determination)
Este modelo fue creado para la evaluación y mejora de procesos de software,
el cual dio inicio en el año de 1993 y aún se encuentra en la fase de informe
técnico. Dicho modelo es aplicable a cualquier organización o empresa que
quiera mejorar la capacidad de cualquiera de sus procesos de software y se
7 www.ingenierosoftware.com/calidad/cmm.
17
Conceptos
y guía de
introducción
Guía para
determinar
capacidad de
proveedores
Realización
de una
evaluación
Guía de
evaluación
Guía de
calificación de
evaluadores
Vocabulario
Guía de uso
para la mejora
de procesos
Modelo de referencia
para procesos
y capacidad
Modelo de
evaluación
y guía de uso
PP
1
PP
9
PP
7PP
8
PP
6
PP
3PP
4
PP
2
PP
5
puede utilizar como herramienta de evaluación del estado de los procesos de
software de la empresa, además es independiente de la organización, del
modelo del ciclo de viia, de la metodología y la tecnología
Considero este modelo como un marco para métodos de evaluación, no un
método o modelo en sí y abarca los siguientes puntos dentro de la calidad del
software:
• Evaluación de procesos.
• Mejora de procesos.
• Determinación de capacidad.
Esta alineado con el ISO/IEC 12207 e intenta proporcionar un marco en el que
los enfoques existentes puedan armonizarse y funcionar como uno solo.
Los componentes de este modelo se muestran en la siguiente figura:
Figura No. 1 Componentes del Modelo SPICE.
18
El modelo SPICE cuenta con un modelo de referencia llamado P2 el cual
describe los procesos que una organización puede realizar para comprar,
suministrar, desarrollar, operar, mantener y soportar el software, así como los
atributos que caracterizan la capacidad de estos procesos, proporciona una
base para medir la capacidad de los procesos, en función de grado de
consecución de sus atributos.
P2 tiene dos dimensiones: Procesos y Capacidad
Procesos
Contiene los procesos que se han de evaluar y que corresponden con los
procesos del ciclo de vida del software, definidos en el estándar ISO 12207
creado en 1995.
Se agrupan en categorías, en función del tipo de actividad al cual se aplican:
• CUS: Cliente-Proveedor.
• ENG: Ingeniería.
• SUP: Soporte.
• MAN: Gestión.
• ORG: Organización.
La categoría CUS está formada por procesos que afectan directamente al
cliente, soportan el desarrollo y la transición del software al cliente y permiten la
correcta operación y uso del producto y/o servicio software.
• CUS.1 Adquisición de productos software y/o servicios.
• CUS.2 Establecimiento de contratos.
• CUS.3 Identificar las necesidades del cliente.
• CUS.4 Realizar auditorias y revisiones conjuntas.
• CUS.5 Entrega e instalación del software.
• CUS.6 Mantenimiento del software.
19
• CUS.7 Proporcionar servicio al cliente.
• CUS.8 Valorar la satisfacción del cliente.
La categoría ENG está formada por procesos que directamente especifican,
implementan o mantienen el producto software, su relación con el sistema y su
documentación.
• ENG.1 Análisis y diseño de requerimientos del sistema.
• ENG.2 Análisis de requerimientos del software.
• ENG.3 Diseño del software.
• ENG.4 Construcción del software.
• ENG.5 Integración y pruebas del software.
• ENG.6 Integración y pruebas del sistema.
• ENG.7 Mantenimiento del software y del sistema.
La dimensión de procesos SUP está formada por procesos que dan soporte a
cualquiera del resto de procesos (incluidos los SUP), en distintos puntos del
ciclo de vida del software.
• SUP.1 Documentación.
• SUP.2 Gestión de la configuración del software.
• SUP.3 Garantía de calidad.
• SUP.4 Resolución de problemas.
• SUP.5 Realizar revisiones conjuntas.
La dimensión MAN esta formada por procesos utilizados en la gestión de
cualquier tipo de proyecto o proceso en el ciclo de vida del software.
• MAN.1 Gestionar el proceso.
• MAN.2 Gestionar el proyecto.
• MAN.3 Gestionar la calidad.
• MAN.4 Gestionar los riesgos.
20
La dimensión ORG se encuentra formada por procesos que establecen los
objetivos de negocio de la organización.
• ORG.1 Alineamiento de la organización.
• ORG.2 Establecimiento del proceso.
• ORG.3 Evaluación del proceso.
• ORG.4 Mejora del proceso.
• ORG.5 Gestión de recursos humanos.
• ORG.6 Infraestructura.
• ORG.7 Reutilización.
Capacidad
Define una escala de medida para determinar la capacidad de cualquier
proceso y consta de seis niveles:
1. Incompleto.
2. Realizado (Realización del proceso).
3. Gestionado (Gestión de realización, Gestión de productos) .
4. Establecido (Definición de procesos, Recursos de procesos) .
5. Predecible (Medición de procesos, Control de procesos).
6. En optimización (Cambio de procesos, Mejora continua).
Es importante mencionar que cada proceso tiene un conjunto de prácticas base
asociadas; las prácticas base describen las actividades esenciales de un
proceso específico y la realización de las prácticas base indica el grado de
alcance de la finalidad del proceso.
Así como también cada atributo de proceso tiene un conjunto de prácticas de
gestión asociadas las cuales son las que implementan o institucionalizan un
proceso de una manera general y su realización indica la consecución del
atributo en esa instancia del proceso. 8
8 www.ingenierosoftware.com/calidad/spice
21
1.2 CALIDAD DE PROCESO DE INGENIERIA DE SOFTWARE
Cuando hablo de la calidad del producto y la calidad del proceso de software
no me refiero a la misma cosa, un proceso de software se refiere al conjunto de
actividades, métodos, prácticas y transformaciones que se utilizan para
desarrollar y mantener un software así como sus productos asociados (planes,
documentos de diseño, código, casos de prueba, manuales, etc.).
Ahora bien un método de mejoramiento de procesos es un conjunto de
procedimientos, herramientas y entrenamiento para incrementar la calidad del
producto.
Es decir, la calidad del proceso es cuando se diseña, desarrolla y construye el
software así como cuando se mantiene y la calidad del producto es la mejora
que se le hace a todo el proceso y al producto en general.
En los últimos años se ha venido observando la estrecha relación entre la
calidad de los productos de software y los procesos utilizados para construirlos.
El mejoramiento de procesos tiene planteados 4 objetivos básicos para
alcanzar la calidad de los mismos y más que nada empezar a introducirnos de
lleno en la búsqueda de la calidad total.
Dichos objetivos son los siguientes:
• Comprender el estado actual de la práctica de Ingeniería de Software y
gestión en una organización.
• Seleccionar áreas de mejoramiento donde los cambios pueden significar
el mayor beneficio a largo plazo.
• Enfocarse en agregar un verdadero valor agregado al negocio y no solo
quedarnos en alcanzar una utopía del proceso.
• Lograr los objetivos mediante una combinación de procesos efectivos,
con gente preparada, motivada, comprometida y creativa.
22
1.3 CALIDAD DEL PRODUCTO DE SOFTWARE
En la actualidad existen diversos problemas para obtener la calidad del
software. Antes que cualquier cosa hay que saber que la calidad del software
es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y
existencia.
La calidad se puede expresar como eficiencia, flexibilidad, corrección,
confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.
La calidad del software se puede medir y varía de un programa a otro según
para las funciones que se ha elaborado, por ejemplo el software que se
desarrolla para el control de aparatos médicos debe de ser confiable "cero
fallas" un software hecho para ejecutarse una sola vez no requiere el mismo
nivel de calidad; mientras que un producto de software que es utilizado durante
un periodo de 5 años necesita ser confiable, mantenible y flexible para que de
esta manera se puedan disminuir los costos de mantenimiento que pueda
existir durante el tiempo de su explotación.
Al hablar de calidad del producto o calidad total no precisamente se refiere a
lograr una calidad perfecta, es cierto que se requiere calidad en todo, tanto en
el proceso como en el producto final, pero la perfección es algo de lo que se
debe hablar hasta que al menos la calidad total haya sido alcanzada.
Por lo tanto para lograr la calidad en el producto primero que nada es necesario
comprender desde el principio del proyecto las necesidades reales y completas
de los usuarios con tanto detalle como sea posible (requerimientos) mientras
mas claras y detalladas sean mas fáciles de solucionar e implementar van a
ser.
23
Existen diferentes aspectos de la calidad que seria conveniente tomar en
cuenta:
Interna.- Es aquella que es medible a partir de las características intrínsecas,
como por ejemplo el código fuente, la definición de requerimientos, etc.
Externa.- Es aquella que es medible en el comportamiento mismo del producto,
es decir ya que fue entregado puede ser desde una prueba o hasta la
implementación.
En uso.- Esto es durante la utilización efectiva por parte del usuario, cuando el
producto ya esta puesto en marcha y viene ya el mantenimiento, las
actualizaciones, las mejoras, etc.
1.3.1 MODELO DE CALIDAD PARA CALIDAD INTERNA Y EXTERNA
Figura No. 2 Modelo de Calidad Externa e Interna
Calidad externae interna
Funcionalidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad
adecuaciónexactitud
interoperabilidadseguridad de acceso
cumplimiento de la funcionalidad
madureztolerancia afallos
capacidad derecuperación
cumplimiento dela fiabilidad
capacidad paraser entendidocapacidad paraser aprendido capacidad paraser operadocapacidad de atracción
cumplimiento dela usabilidad
comportamientotemporal
utilización de recursos
cumplimiento dela eficiencia
capacidad paraser analizadocapacidad paraser cambiadoestabilidad
capacidad paraser probado
cumplimiento dela mantenibilidad
adaptabilidadinstalabilidadcoexistencia capacidad paraser reemplazado
cumplimiento dela portabilidad
24
Características del modelo:
FUNCIONALIDAD
Adecuación.- Es la capacidad del producto para generar procesos que
funcionen específicamente para los requerimientos especificados por el
usuario.
Exactitud.- Capacidad del producto para proporcionar los resultados o efectos
correctos y acordados, con un buen grado de precisión.
Interoperabilidad.-Capacidad del software para interactuar con otros sistemas,
ya sea con sistemas internos de la empresa o con sistemas del mercado.
Seguridad de acceso.-Capacidad del software para proteger información y
datos de manera que las personas o sistemas no autorizados no puedan
leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o
sistemas autorizados.
Cumplimiento funcional.- Capacidad del software para adherirse a firmas,
convenciones o regulaciones en leyes y prescripciones similares relacionadas
con la funcionalidad.
FIABILIDAD
Madurez.-Capacidad del producto software para evitar fallar como resultado de
fallos en el software.
Tolerancia a fallos.-Capacidad del software para atender el margen de error o
fallos que pudieran surgir durante su operación.
Capacidad de recuperación.-Capacidad del producto para reestablecer un nivel
de prestaciones especificado y de recuperar los datos directamente afectados
en caso de fallo.
Cumplimiento de la fiabilidad.-Capacidad del producto para adherirse a normas,
convenciones o regulaciones relacionadas con al fiabilidad.
25
USABILIDAD
Capacidad para ser entendido.-Capacidad del software que permite al usuario
entender el software, y poder manejarlo asi como tambien para que pueda
determinar si es adecuado para realizar sus operaciones.
Capacidad para ser aprendido.-Se refiere a la facilidad con la cual el software
es aprendido por el usuario, si es claro y entendible.
Capacidad para ser operado.-Capacidad del software que permite al usuario
operarlo y controlarlo.
Capacidad de atracción.-Capacidad del producto ara ser atractivo al usuario.
Cumplimiento de la usabilidad.-Capacidad del producto software para adherirse
a normas, convenciones, guías de estilo o regulaciones relacionadas con el
mismo.
EFICIENCIA
Comportamiento temporal.- Capacidad del producto para proporcionar tiempos
de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones
determinadas y muchas veces condiciones de mucha presión.
Utilización de recursos.- Capacidad del software para maximizar el rendimiento
la utilización de los recursos con los que cuenta.
Cumplimiento de la eficiencia.- Capacidad del software para adaptarse a las
condiciones y exigencias de la industria y de los clientes y/o usuarios.
MANTENIBILIDAD
Capacidad para ser analizado.- Es la capacidad del producto para determinar
cuales son las deficiencias o fallas que presenta el mismo durante su
operación.
Capacidad para ser cambiado.- Es la facilidad con la que se le pueden hacer
modificaciones al software.
Estabilidad.- Capacidad del producto para evitar efectos inesperados que
puedan afectar su operación y que son resultado de las modificaciones que se
le hayan hecho.
26
Capacidad para ser probado.- Permite que el software modificado pueda ser
validado y probado las veces que resulte necesario.
Cumplimiento de la mantenibilidad.- Capacidad del software de poder ser
mantenido y corregido durante la operación del mismo sin que se altere en
ningún momento.
PORTABILIDAD
Adaptabilidad.- Capacidad del software para ser adaptado a diferentes
entornos especificados y diferentes a el mismo sin que cause ningún problema
y que funcione igual en alguna otra aplicación, área, rubro, empresa , etc.
Coexistencia.-Capacidad del software para coexistir con otro software
independiente, en un entorno común, compartiendo recursos comunes.
Capacidad para reemplazar.- Capacidad del software para ser usado en lugar
de otro producto software, para el mismo propósito, en el mismo entorno.
Cumplimiento de la portabilidad.- Capacidad del producto para transferirse o
utilizarse en otros ambientes y procesos diferentes. 9
1.3.2 MODELO DE CALIDAD PARA CALIDAD EN USO
Figura No. 3 Modelo de Calidad para Calidad en Uso
9 www.ideotechnologies.com/calidadexternainterna.html (23/11/2006)
Calidad enUso
Efectividad SatisfacciónProductividad Seguridad de
acceso
27
Características del modelo:
EFECTIVIDAD
Es la capacidad del producto para entregar y mostrar los resultados fijados en
los objetivos, resultados exactos, precisos y completos.
PRODUCTIVIDAD
Capacidad del software para permitir a los usuarios gastar una cantidad
adecuada de recursos con relación a la efectividad alcanzada, en un contexto
de uso especifico.
SEGURIDAD FÍSICA
Capacidad del software para alcanzar niveles aceptables en el riesgo de hacer
daño a personas, al negocio, al software, a las propiedades o al medio
ambiente en un contexto de uso especificado.
SATISFACCIÓN
Capacidad del software para satisfacer a los usuarios cumpliendo con todos los
requerimientos que ellos esperaban o solicitaron.
1.3.3 CALIDAD DE SOFTWARE BASADO EN COMPONENTES
Esta disciplina se basa en el desarrollo de software utilizando software
reutilizable, cuenta actualmente con un creciente interés, tanto desde el punto
de vista académico como el de la industria, ya que la demanda de mecanismos
y herramientas de desarrollo basados en componentes es cada día mayor.
Este paradigma se basa en el uso de los componentes software como
entidades básicas del modelo, entendiendo por componente “una unidad de
composición de aplicaciones software que posee un conjunto de requisitos, y
28
que podría ser desarrollado, adquirido, incorporado al sistema y compuesto con
otros componentes, de forma independiente en tiempo y espacio”.
Una de las principales ventajas del desarrollo de software basado en
componentes se basa en la “reutilización” de los mismos. De esta forma, los
componentes se diseñan y desarrollan con el objetivo de poder ser reutilizados
en otras aplicaciones, reduciendo el tiempo de desarrollo, mejorando la
fiabilidad del producto final, y siendo más competitivos en cuanto a costos.
Aunque hasta ahora la reutilización suele suceder principalmente a nivel interno
dentro de las organizaciones, el uso de los componentes comerciales comienza
a extenderse.
De esta forma se habla de componentes COTS (Commercial-Off-The-Shelf),
que han sido definidos como una clase especial de componentes software,
normalmente de grano grueso, que presentan las siguientes características:
• Son vendidos o licenciados al público en general.
• Los mantiene y actualiza el propio vendedor, quien conserva los
derechos de la propiedad intelectual.
• Están disponibles en forma de múltiples copias, todas idénticas entre sí.
• Su código no puede ser modificado por el usuario.
La cada vez mayor disponibilidad y uso de este tipo de componentes está
impulsando notablemente la creación de un mercado global de componentes
COTS, que está pasando de ser la utopía de hace unos años a una realidad
cada vez más cercana. La tecnología básica de componentes comienza a estar
lo suficientemente madura (a través de plataformas de objetos distribuidos
como EJB, CORBA o .NET) como para que numerosas empresas la adopten
en sus nuevos desarrollos y sistemas de información.
29
La palabra calidad tiene varios significados, una de ellas es la definida por la
Norma ISO 8402 que la define como:
“La totalidad de aspectos y características de un producto o servicio que
tienen que ver con su habilidad para satisfacer las necesidades
declaradas o implícitas”.
Aunque la calidad es un objetivo importante para cualquier producto, no
debemos olvidar que los productos, y también los productos software, se
construyen para ser utilizados.
Por tanto, el principal objetivo de un producto es satisfacer una necesidad (o
varias) de un usuario y, por consiguiente, ofrecer al usuario algún beneficio por
su utilización. Es decir la calidad no es lo único que se busca en un producto
sino que cumpla las necesidades del cliente.
Es importante darnos cuenta de que la calidad de un producto en este caso
software no se refiere únicamente a la entrega de un producto que no tenga
errores, la calidad es mas un proceso de formalización durante todo el proceso
de creación del producto mediante modelos que definan las características que
el mismo debe ir cumpliendo mientras avanza su desarrollo y las mismas
características que medirán la calidad del producto a la hora de ser finalizado y
entregado.10
1.3.3.1 CARACTERÍSTICAS
En general, no existe un consenso a la hora de definir y clasificar las
características de calidad que debe presentar un producto software. Para
guiarnos un poco en esta definición de características tomaremos como base
los estándares internacionales que fueron los primeros en definir y concretar
dichas características.
10 www.msguayaquil.com/blogs/julioc/archive/2006/05/08/Desarrollo-de-Software-Basado-en-
Componentes.aspx
30
Siguiendo su terminología, entendemos por característica de calidad de un
producto software a un conjunto de propiedades mediante las cuales se evalúa
y describe su calidad.
Una característica se puede refinar en múltiples niveles de sub-características.
Ejemplos de características son la funcionalidad, la fiabilidad o la facilidad de
uso. A su vez, la característica funcionalidad se puede descomponer en sub-
características como corrección, interoperatividad y seguridad, entre otras.
Llamaremos atributo a una propiedad de calidad a la que se le puede asignar
una métrica, es decir, un atributo que en determinado momento va a poder ser
medido y evaluado. Con todo esto, un modelo de calidad se define como “un
conjunto de características y sub-características, junto con las relaciones que
existen entre ellas”. Por supuesto, el modelo de calidad a utilizar va a depender
del tipo de producto a evaluar.
Lamentablemente en este sentido, los estándares y propuestas que
actualmente existen son modelos muy generalizados y muy extensos, y por lo
tanto se hace difícil su aplicación en temas más concretos, es muy importante
también tratar de “refinarlos” y particularizarlos en casos mas concretos para
poder esperar mas garantía de éxito.
Es importante señalar que, además de las características de calidad en un
componente, hay otro conjunto de características no relacionadas directamente
con la calidad como pueden ser el precio, la asistencia técnica, las condiciones
de licencia, etc., que también son necesarias a la hora de valorar el
componente más adecuado.
Todas estas características técnicas y no técnicas deben estar documentadas
en un formato aceptado por los participantes en el desarrollo de software.
Un tema adicional pero muy relacionado a este es el de la Calidad de Servicio
(QoS). En su normativa, ISO define el QoS como “un conjunto de calidades
relacionadas con el comportamiento colectivo de uno o más objetos”.
31
En este sentido es importante señalar que fundamentalmente este tipo de
atributos van a coincidir con los atributos de calidad que pueden ser medidos
durante la ejecución del sistema o de los componentes.
Sin embargo, suelen ser más al nivel de sistema que de componentes, pues el
QoS se mide con respecto al comportamiento global del sistema y a los
resultados que éste produce.
Por lo tanto, no es suficiente con disponer de los valores de los atributos de
calidad de los componentes de un sistema, sino también influye la forma en la
que están conectados, el medio de transporte que utilizan para comunicarse, la
complejidad de los protocolos de interacción entre ellos, etc.
A continuación se mencionan algunas propuestas de Calidad en el Desarrollo
Software Basado en Componentes. Dichas propuestas se han dividido en dos
categorías: por un lado, las que presentan propuestas de calidad para el
producto y, por otro, las que lo hacen respecto al proceso.
CALIDAD EN EL PRODUCTO
Una de las primeras referencias acerca de la calidad en el desarrollo de
componentes en concreto es la que define o propone la norma ISO-9126 que
define un modelo general de calidad basado en seis características principales
(funcionalidad, fiabilidad, facilidad de uso, eficiencia, mantenibilidad y
portabilidad), que a su vez se refinan en 21 sub-características [ISO, 1991].
Aunque este modelo de calidad es bastante completo, presenta dos problemas
principales. El primero es la falta de precisión en la definición de tales
características, mientras que el segundo se debe a que no todas esas
características y sub-características son aplicables a componentes software.
Por tanto ese modelo se muestra idóneo como base de partida general, pero
que es necesario refinarlo al caso particular de los componentes, al igual que
se hace para otros desarrollos, como pueden ser las páginas Web u otros.
32
Por otro lado, desde el punto de vista de la arquitectura software y dado la gran
relación que con ella tienen los componentes, es destacable el tratamiento que
da Bass a los atributos de calidad dentro de la arquitectura software como otra
propuesta.
Su trabajo presenta una idea muy interesante y que puede ser aplicada a los
componentes, al proponer una clasificación de los atributos de calidad en
función de si tienen relación con la arquitectura de software o no.
Desde el punto de vista de los componentes podemos pensar si un atributo
está relacionado con un componente como entidad independiente, o bien, está
relacionado con la arquitectura software. Además, en su propuesta Bass divide
los atributos de calidad en los que son aplicables al sistema en ejecución; los
que son aplicables a las tareas de desarrollo o mantenimiento, es decir,
durante el ciclo de vida; los que tienen relación con el entorno comercial del
producto y, los que se aplican a la arquitectura software directamente.
Otro trabajo de gran interés en el ámbito de la arquitectura software es el de
Jan Bosch el cual propone la valoración de los requerimientos de calidad para
una arquitectura, y no sólo la valoración de los requisitos funcionales. Estos
requerimientos de calidad se deben valorar durante la fase de diseño de la
arquitectura software.
Bosch muestra la dificultad de especificar con detalle los requerimientos de
calidad, pero sí encuentra que los requisitos más importantes en la mayoría de
las propuestas existentes presentan alguna forma de lo que denomina perfil
(profile). Un perfil es un conjunto de escenarios, generalmente con alguna
relativa importancia relacionada con cada escenario. Por ejemplo, el perfil de
uso es un conjunto de escenarios que describen la utilización típica del
sistema software. Otros perfiles posibles son el perfil de cambios o el perfil de
riesgos.
Basándose en esta idea, propone perfiles de los atributos de calidad y
selecciona cinco atributos de calidad como los más relevantes desde una
33
perspectiva de ingeniería de sistemas de software en general. Estos atributos
son: Rendimiento, Mantenibilidad, Fiabilidad, Seguridad Física y Seguridad de
Acceso.
Por último, dentro de las propuestas relativas al producto, Preiss presenta
también en su trabajo una clasificación de los atributos de calidad de los
componentes. Para el un atributo de calidad es el grupo de propiedades que
aparecen habitualmente en la literatura con el sufijo “-bilidad” (“ilities” o
“nesses” en inglés). De nuevo, establece la distinción de que estos atributos se
pueden clasificar en dos categorías: los que son observables durante el tiempo
de ejecución y los que son discernibles durante todo el ciclo de vida del
componente.
Los atributos observables en tiempo de ejecución son referidos, en esta
propuesta, como los atributos de Calidad de Servicio (QoS) de los
componentes
De esta forma, Preiss propone que la calidad de un sistema software se puede
valorar mediante un conjunto de atributos de calidad. A la mayoría de estos
atributos los podemos considerar “sistémicos”, es decir, son aplicables a un
sistema software completo o están extendidos por una parte de él. Además, es
importante tener en cuenta que la decisión de qué conjunto de atributos de
calidad son los más importantes va a depender del punto de vista desde donde
miremos el sistema. No es lo mismo el punto de vista de un usuario que el de
un desarrollador, o que el de la persona encargada de su administración y
mantenimiento.
Por lo tanto cuando todos estos autores hablan de atributos QoS se refieren a
un conjunto de atributos de calidad extra-funcionales que son discernibles
durante la ejecución del sistema y que pueden ser vinculados con un caso de
uso particular.11
11 www.wikipedia.org/wiki/Calidad_del_producto
34
CALIDAD EN EL PROCESO
Como ya se menciono anteriormente el proceso de construcción de un
producto software basado en componentes adquiere características especiales.
Los siguientes son trabajos que tratan de forma directa el proceso de desarrollo
basado en componentes y que para este trabajo serian de gran interés:
COCOTS (Construcción COTS).- Este modelo se compone de cuatro
submodelos que recogen las cuatro principales fuentes de los costes de
integración de componentes COTS:
Valoración (Assessment).- Es el proceso mediante el cual los componentes
COTS son seleccionados para ser integrados en el sistema que se está
desarrollando.
Adaptación (Tailoring).- Se refiere a las actividades que siempre hay que
realizar para particularizar el componente, independientemente del producto
donde se va a integrar. Por ejemplo, inicializar los valores de los parámetros,
especificar pantallas de E/S o formato de los informes, configurar protocolos de
seguridad, etc.
Código de Integración (Glue Code).- Es el código nuevo que hay que
desarrollar y probar, externo a los COTS, pero necesario para integrar los
componentes COTS en un sistema.
Volatilidad (Volatility).- Toma en cuenta la frecuencia con la cual aparecen en el
mercado nuevas versiones o actualizaciones de los componentes COTS que
se están utilizando en el sistema durante su desarrollo y puesta en
funcionamiento.
35
Una de las principales desventajas de este modelo es que no se llega a definir
ningún conjunto de atributos de calidad (es decir, un modelo de calidad), lo cual
limita bastante su utilización práctica). 12
QESTA (Quantification, Examination, Specification, Transformation,
Aggregation)
Otro trabajo de gran interés relativo a los temas de calidad en DSBC
(Desarrollo de Software Basado en la Calidad) es el presentado por Hansen en
el cual plantea un proceso de evaluación para seleccionar al mejor candidato
de los posibles componentes que se puedan utilizar.
El núcleo del proceso de evaluación QESTA está basado en un conjunto de
“operaciones” básicas, que son las que van a definir un proceso que permita
realizar una evaluación efectiva de componentes software. A su vez, cada
operación viene determinada por sus datos de entrada, sus datos de salida, y
una descripción de su objetivo y comportamiento básico.
Sus fases son:
• Cuantificación.
• Examen.
• Especificación.
• Transformación.
• Agregación.
Esta propuesta tampoco concreta los atributos de calidad (o “métricas” en su
terminología) que se deben medir dentro del proceso QESTA. Esto limita su
aplicación inmediata, aunque posiblemente esta sea la propuesta que presenta
el proceso de evaluación mejor especificado.
12www.tpmonline.com/articles_on_total_productive_maintenance/rootcause/calidadprocesocau
saraiz02.htm
36
COTS-Based Requirements Engineering (CRE)
El método CRE se desarrolla para facilitar el proceso de selección y evaluación
basado en los requerimientos, prestando una especial atención en el análisis
de los requerimientos extra-funcionales.
La selección de componentes se realiza por rechazo, es decir, los
componentes candidatos que no cumplen alguno de los requerimientos del
cliente van siendo rechazados y retirados de la lista de candidatos. Conforme
esta lista va decreciendo, es necesario aumentar el número y el detalle de los
requerimientos.
El resultado es un proceso iterativo mediante el cual el proceso de adquisición
de los requerimientos permite la selección de productos y, adicionalmente, el
propio proceso de selección genera información para la obtención de nuevos
requerimientos de calidad.
CRE es un método orientado a objetivos, es decir, cada fase se orienta a
conseguir objetivos predefinidos. Para ello, cada fase tiene unas plantillas que
incluyen guías y técnicas para la adquisición y/o modelado de requerimientos y
para la evaluación de productos.
El método tiene cuatro fases iterativas:
• Identificación.
• Descripción.
• Evaluación.
• Aceptación.
Existen dos modelos mas para definir las características de calidad en el
desarrollo de software basado en componentes pero que por el momento solo
mencionare ya que nos desvía del tema principal de este trabajo.
37
Dichos modelos son :
• Off-The-Shelf Option (OTSO)
• Procurement-Oriented Requirements Engineering (PORE)13
1.4 MEJORA DE CALIDAD
La Calidad Total en Informática, es el resultado del movimiento global dentro
del proceso de mejoramiento continuo de los estándares de producción en
todos los sectores industriales, en particular, cuando éste se concentra en la
producción de sistemas de información y software especializado. Como la
calidad total no es un producto sino una actividad, la industria del software se
ha visto afectada muy radicalmente y por lo mismo es de gran importancia.
En la actualidad los productores de software están en una situación más
dramática que hace unos años, pues no sólo quieren producir software con
crecientes características de calidad, también tienen la necesidad de producir
software más sofisticado.
Por otra parte, hoy en día se cuenta con herramientas para producir muchas
más líneas de código y si se mantienen los niveles presentes de calidad, el
cuello de botella se presentará en el esfuerzo de mantenimiento que, en la
actualidad, requiere el apoyar una tasa de desarrollo y producción entre tres y
diez veces más rápida que antes.
Un programa de gestión y aseguramiento de la calidad comienza por elegir un
modelo y establecer una definición de calidad. Esta definición debe analizarse,
para identificar componentes de tipo «resultado» y de tipo «contribuyente».
Los componentes de tipo resultado son unidades bajo las cuales el usuario o
cliente emite un juicio sobre el producto o servicio. Estas unidades son de
relevancia a la actividad del usuario de informática.
13 www.lcc.uma.es/~av/misConfs/CalidadComponentes-UCLM05.ppt
38
Ejemplos de éstas son: El número de veces que no pudo lograr una venta
porque sus sistemas fallaron o la pérdida de oportunidades de negocio por no
contar con la información pertinente.
Las unidades contribuyentes son de tipo técnico y están orientadas a la
tecnología informática; como ejemplo de ellas podemos citar el número de
veces que se pierde la comunicación en un día o el tiempo que se requiere
para levantar una base de datos.
Para obtener una definición aceptable de calidad, se hace uso de los conceptos
de métrica y medida. Una medida puede definirse como la evaluación de una
variable de control. Es necesario remarcar que no es fácil hacer deducciones
sobre una medida. Por ejemplo, una medida de un programa es el número de
líneas de código o el tiempo que tarda un usuario en manejar bien el programa.
Ahora bien, una métrica es la combinación de dos medidas, las cuales
conducen a la evaluación de una unidad de control. Por ejemplo, el total de
defectos sobre el número de líneas de código es una métrica de la calidad de
programación, y cuando esta métrica se eleva, podemos inferir que los
programadores están siendo menos cuidadosos o que existe otro problema.
Otra métrica es el número de funciones de un programa sobre el tiempo
promedio que toma a usuarios inexpertos el dominio del mismo. Esta última
puede categorizarse como una métrica de la facilidad de asimilación.
Los dos siguientes pasos importantes del ciclo continuó de un programa de
calidad son: El control de la calidad y la garantía de la calidad. Para controlar la
calidad, los niveles directivos deben establecer y monitorear un conjunto de
métricas, que les proporcionen información suficiente para actuar con base a
hechos.
39
Los resultados que obtiene un ejecutivo basado en opiniones y que toma
decisiones porque «al parecer» una metodología de diseño no está siendo
satisfactoria, son muy distintos a los que llega uno que analiza datos históricos
de varios meses de labores, donde se observan tendencias en métricas.
Ejemplos de estas tendencias pueden ser:
• Defectos por KLOC (Short fro thousands of lines of code).
• Defectos por funcionalidades.
• Funcionalidades por tiempo de desarrollo.
• Horas hombre sobre número de funcionalidades.
• Funcionalidades sobre nivel de capacitación del equipo de desarrollo.
El conjunto de medidas que maneja cada directivo debe concordar con su
capacidad de acción para poder actuar efectivamente y garantizar calidad.
Así, mientras que un Director de Proyectos deberá monitorear métricas tales
como defectos sobre KLOC y funcionalidades de sistema sobre costos de
desarrollo, un Coordinador de Proyectos deberá monitorear métricas de
productividad, calidad, tiempos de construcción y costos y, finalmente, un
Director de Sistemas deberá monitorear métricas de efectividad, eficiencia de
entrega, eficiencia de mantenimiento, capacidad de respuesta, valor táctico y
valor estratégico.
En resumen, la calidad en informática es un reto más difícil de enfrentar que
otras actividades creativas e industriales. Existen metodologías y mecanismos
para establecer programas que conducen directamente a que cada uno de los
involucrados hagan las cosas cada vez mejor.
En ningún otro campo de la productividad industrial pueden los programas de
calidad total tener mayor impacto que en el campo de la informática,
constituyendo un efectivo valor agregado.
40
Cuando las características de calidad o propiedad del producto o servicio
contribuyen a su adecuación de uso como el rendimiento y fiabilidad que se
obtiene de un software. La calidad de diseño o la adecuación de las
características de calidad diseñadas para la generalidad de usuarios, es
importante ya que el diseño es parte de cómo el usuario se familiarizara con el
sistema para su mejor desempeño.
La calidad de fabricación es la fidelidad con que un producto se ajusta a lo
establecido en su proyecto, o sea como se apega a las necesidades y
requerimientos de el cliente según a lo establecido.
Con los puntos anteriores obtendremos un producto de calidad siempre
tomando como base lo que el cliente quiere, desea y necesita para su mayor
satisfacción. Para que todo lo anterior se lleve acabo de una manera controlada
es necesario que exista un control de calidad en una o varias personas o
departamentos que se encarguen de llevar el control de cada una de las
especificaciones realizadas por el cliente para lograr la calidad siempre.
Para el Dr. Kaoru Ishikawa un autentico control de calidad consiste en
desarrollar, diseñar, producir y servir un producto o servicio de calidad el cual
debe ser lo mas económico posible, útil y siempre satisfactorio para el cliente o
usuario.
Para otros autores como Taylor plantean que los especialistas establecen los
estándares técnicos, los empleados/operarios los cumplen y los supervisores
verifican los resultados una vez terminado el proceso, sin embargo, otros como
Deming destacan la importancia de la flexibilidad en las organizaciones y en la
implementación de la gestión de la calidad total.
Así mismo expresa que para mejorar la calidad, la productividad y la
competitividad es necesario realizar cambios drásticos y aprender cómo se
deben cambiar.
41
Así es como podemos tener un amplio conocimiento de lo que es y lo
importante que es obtener la calidad en cada uno de los procesos para
finalmente tenerlo en los productos o servicios a ofrecer en el mercado. Es así
como esta persona dio a conocer el valor que tiene la calidad y lo importante
que es ofrecer un producto garantizado y confiable para su uso.
El mercado tiene muchas exigencias las cuales deben ser cumplidas y
satisfechas por todas las organizaciones que se encuentren ofreciendo un
producto o servicio es ahí donde se requiere la aplicación de la mejora continua
en los procesos para llegar a la calidad total en cada uno de ellos.
La calidad es un problema de orientación, de liderazgo, de participación de los
empleados y de su formación. En cualquier caso, la mejora de la calidad es un
proceso sin fin, que debe llevarse paso a paso y del que no se pueden esperar
resultados inmediatos.
En el mundo actual, la gestión del conocimiento por parte de la empresa,
adquiere nuevas características, determinadas por la gestión de la información
y de la calidad.
En las organizaciones más modernas cohabitan, indisolublemente ligadas, la
gestión de información, del conocimiento y de la calidad; ellas son
organizaciones de excelencia, donde la ética, la motivación y el buen
desempeño rinden incrementos constantes en los resultados y en el
reconocimiento de las empresas.
1.4.1 RECOMENDACIONES PARA LA MEJORA CONTÍNUA
Muchas de las organizaciones no suelen adquirir un hábito de constancia en la
mejoría de sus productos y servicios y lo cual atrae muchas deficiencias en
cada unos de sus procesos lo ideal es que se planteen un buen hábito de
constancia de mejora para que de esta manera tengan competitividad con las
demás empresas y sobre todo permanecer en el mercado ya que muchas de
ellas no duran mucho por que no son constantes en la mejora de sus procesos.
42
Por tal motivo deben de mejorar constantemente y para siempre en los
procesos de planeación, producción y servicio. Para así poder reducir costos
en los procesos.
Otro de los problemas que existen es que no se adquiere bien el papel de
liderazgo en las empresas y esto atrae como consecuencia de que no haya
buena comunicación, que no se solucionen los problemas que se presenta en
cuanto a maquinaria, procesos etc.
Por lo que se sugiere que se tome bien este papel ya que es uno de los más
importantes el ser líder y tener as u cargo un grupo de personas que están
encargadas de desarrollar alguna actividad especifica que forma parte del
proceso.
El miedo también suele ser uno de los más aterradores problemas que puede
tener una organización, ya que con este no se llega a nada bueno si no a
resultados no deseados, por lo que hay que eliminar el miedo para poder tener
un mejor desarrollo y desenvolvimiento dentro de la empresa en cuanto a la
realización de las actividades como también la opinión de cada uno de los
integrantes de la empresa, por que una opinión o varias puede ayudar bastante
a que una organización mejore sus procesos.
1.4.2 IMPORTANCIA DE LA MEJORA CONTINUA
La importancia que logra tener esta técnica es que a través de su aplicación se
contribuye a mejorar las debilidades y hacer que la organización se fortalezca.
Con la mejora continúa en las organizaciones se logra a que se desarrollen sus
procesos de una manera más productiva y eficiente para así reducir costos y
poder ofrecer un producto o servicio de calidad.14
14 www.buscarportal.com/articulos/iso_9001_mejora_continua.
43
MMeejjoorraa ddee llaa
ccaalliiddaadd
Control de calidad
Garantía de calidad
Calidad total
Detectar
defectos
Prevenir
defectos
Mejora
continua
Tiempo
Figura No. 5 Mejora Continúa15
15 www.uv.mx/iiesca/revista2000/mejora.htm
44
CAPÍTULO II
PROCESOS DE ADMINISTRACIÓN DE CALIDAD DE SOFTWARE
Para poder llevar a cabo exitosamente la gestión de la calidad del software es
necesario dejar muy claros los beneficios que va a proporcionar el hecho de
tener que estandarizar y controlar los procesos y formas de trabajo ya
existentes dentro de la organización, ya que es difícil que una organización se
adapte a cambios y nuevos procedimientos sin saber en que los va a beneficiar
hacerlos.
Desarrollar un plan de administración de software no es para nada una tarea
fácil ya que es un factor critico dentro la calidad del software, afortunadamente
actualmente los consultores o evaluadores están haciendo mucho mas fácil
este proceso.
Existe un proceso de software que ha resultado exitoso el cual consta de cinco
pasos los cuales son los siguientes:
• Formación del equipo de administración de software.
• Determinación de la distribución actual y uso del software que también
es llamado auditoria de software.
• Desarrollo de un plan de administración de software basado en la
determinación.
• Implementación y seguimiento del plan.
• Continuación del programa de administración de software.
2.1 GARANTÍA DE LA CALIDAD DE SOFTWARE
Dentro de la calidad del software existe una compleja mezcla de factores que
varían dependiendo de la aplicación y el cliente que la solicite.
Para mi la garantía de calidad es una actividad esencial en cualquier empresa
que produce productos que van a ser usados por otros.
45
Antes del siglo XX, la garantía de calidad era responsabilidad única de la
persona que construía el producto. La primera función de control y de garantía
de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendió
rápidamente por todo el mundo de las manufacturas. Actualmente cada
compañía la tiene como táctica de mercado la cual consiste en poner en claro y
recalcar explícitamente el hecho de que su producto cuenta con los más altos
estándares de calidad.
La historia de la garantía de calidad en el desarrollo de software ha sido
paralela a la historia en la fabricación de hardware. Durante los primeros años
de información que fueron los 50 y los 60, la calidad de un software era
responsabilidad únicamente del programador.
En los años 70 fue cuando se introdujeron los primeros estándares de garantía
de calidad para el software en los contratos militares de desarrollo de software
y así se han extendido rápidamente en los desarrollos de software del mundo
comercial.
El papel de la garantía del software (SQA por sus siglas en ingles Software
Quality Assurance) se ilustra esquemáticamente en la siguiente figura:
Figura No. 6 Garantía de la Calidad del Software
46
Alguna vez una importante empresa de automóviles dijo la frase “la calidad es
el trabajo número 1”, lo cual quiere dar a entender que lograr la calidad de un
producto de software es trabajo de todos aquellos que interactúen con la
misma organización, los ingenieros de software, gestores de proyecto, clientes,
comerciantes.
Los factores que afectan la calidad del software se clasifica en dos grupos:
1.- Factores que pueden ser medidos directamente, por ejemplo errores o
unidad de tiempo.
Factores que solo pueden ser medidos indirectamente como la facilidad de uso
de mantenimiento.
2.- Los factores de calidad del software se centran en tres aspectos
importantes de un producto de software: sus características operativas, su
capacidad de soportar los cambios y su adaptabilidad a nuevos entornos;
dichos factores son los siguientes:
Corrección. El grado en que un programa satisface sus especificaciones y
consigue los objetivos solicitados por el cliente.
Fiabilidad. El grado en que se puede esperar que un programa lleve a cabo
sus funciones esperadas con la precisión requerida. Esta puede ser medida o
estimada por datos históricos o estadísticos.
Eficiencia. La cantidad de recursos de computadora y de código requeridos
por un programa para llevar a cabo sus funciones.
Integridad. El grado en que puede controlarse el acceso al software o a los
datos, por personal no autorizado.
Facilidad de uso. El esfuerzo requerido para aprender un programa, trabajar
con él, preparar su entrada e interpretar su salida.
47
Facilidad de Mantenimiento. El esfuerzo requerido para localizar y arreglar un
error de un programa.
Flexibilidad. El esfuerzo requerido para modificar un programa operativo.
Facilidad de prueba. El esfuerzo requerido para probar un programa de
manera que se asegure que realiza su función requerida.
Portabilidad. El esfuerzo requerido para transferir el programa desde un
hardware y/o un entorno de sistemas de software a otro.
Reusabilidad. El grado en que un programa ( o partes de un programa ) se
puede reusar en otras aplicaciones. Esto va relacionado con el
empaquetamiento y el alcance de las funciones que realiza el programa.
Facilidad de interoperación. El esfuerzo requerido para acoplar un sistema a
otro.
Es difícil desarrollar medidas directas de los anteriores factores de calidad. Por
lo cual, se define un conjunto de métricas usadas para desarrollar expresiones
para cada uno de los factores de acuerdo a un factor de calidad del software,
coeficientes de regresión y métricas que afectan el factor de calidad.
Ahora bien existe un concepto llamado Gestión de la calidad del software que
no es otra cosa que administrar las actividades que se deben llevar a cabo
antes, durante y después de la construcción de un software para alcanzar la
calidad del mismo. Esta actividad le corresponde y se aplica normalmente a las
empresas en el área directiva de la misma, aunque también puede existir
dentro de un proyecto en especifico.
En dicha gestión se determinan la calidad, los objetivos y las responsabilidades
del desarrollo de un producto y se apoya de medios tales como la planificación
48
de la calidad, el control de la calidad, el aseguramiento de la calidad, y la
mejora de la calidad, a continuación se describen tres de ellos.16
2.2 ASEGURAMIENTO DE LA CALIDAD
Para hablar de garantía de la calidad de software me resulta más conveniente
utilizar la palabra de aseguramiento de calidad, aunque algunos autores
prefieren la palabra garantía que aseguramiento ya que garantía podría
confundirse con la garantía sobre un producto recién adquirido y la palabra
aseguramiento nos crea la idea de confiar en que el producto es un producto
que tiene y es de calidad.
Por lo tanto si la palabra aseguramiento crea una idea de confianza sobre algo
entonces el aseguramiento de calidad del software puede definirse como el
conjunto de actividades que se planean y sistematizan antes y durante la
construcción de un software para precisamente asegurar que dicho producto va
a satisfacer los requisitos iniciales del usuario.
El aseguramiento de calidad del software está presente en:
• Métodos y herramientas de análisis, diseño, programación y
prueba.
• Inspecciones técnicas formales en todos los pasos del
proceso de desarrollo del software.
• Estrategias de prueba multiescala.
• Control de la documentación del software y de los cambios
realizados.
• Procedimientos para ajustarse a los estándares (y dejar claro
cuando se está fuera de ellos).
• Mecanismos de medida (métricas).
• Registro de auditorias y realización de informes.
16 www.monografias.com/trabajos6/isof/isof.shtml
49
Existen dos actividades principales en las que se lleva a cabo mas visiblemente
el aseguramiento de la calidad de un software
• Métricas de software para el control del proyecto.
• Verificación y validación del software a lo largo del ciclo de vida.
• Incluye las pruebas y los procesos de revisión e inspección.
Por otro lado la garantía o aseguramiento de la calidad se refieren más que
nada a la concordancia o congruencia que debe existir entro los requerimientos
funcionales y los de rendimiento previamente establecidos, con los estándares
de desarrollo explícitamente documentados y con las características implícitas
que se espera de todo software.
Podemos tomar a los requerimientos del software como los fundamentos desde
los que se mide la calidad, entonces por consiguiente la falta de concordancia
entre los requerimientos es una falta de calidad, así mismo los estándares que
se especifican antes del diseño del software son también un conjunto de
criterios de desarrollo que guían la forma en que se aplica la ingeniería del
software; si no se siguen ciertos criterios, casi siempre se dará una falta de
calidad ahora bien existen también un conjunto de requerimientos implícitos
que no son otra cosa que el deseo de un buen mantenimiento por parte del
software.
Si el software se ajusta a los requerimientos iniciales del usuario pero falla en
alcanzar los requerimientos implícitos del mismo entonces la calidad queda en
entre dicho. 17
2.3 CONTROL DE LA CALIDAD DEL SOFTWARE
El control de la calidad se refiere a las técnicas y actividades de carácter
operativo que son utilizadas para satisfacer los requerimientos relativos a la
calidad especificados cuando se hace la solicitud del software y que están
centradas en dos objetivos fundamentales:
17www.sma.df.gob.mx/simat2/ponencias/sesion5/aseguramientoycontrolcalidadaireretama.pdf
50
• Mantener bajo control un proceso.
• Eliminar las causas de los defectos en las diferentes fases del ciclo de
vida.
En pocas palabras son las actividades que sirven para evaluar la calidad de los
productos dentro del sistema de calidad de una organización. Por sistema de
calidad se conoce a la estructura organizativa, los procedimientos, procesos y
recursos necesarios para implementar la gestión de calidad mencionada con
anterioridad.
El sistema de calidad se debe adecuar a los objetivos de calidad de la empresa
y la dirección de la empresa es la responsable de fijar la política de calidad y
las decisiones relativas a iniciar, desarrollar, implantar y actualizar el sistema
de calidad.
Un sistema de calidad consta de varias partes, las cuales son las siguientes:
Documentación.- Se refiere al manual de calidad que es el documento escrito
que indica y explica el procedimiento principal para establecer e implantar el
sistema de calidad mismo. Puede haber un manual principal y además uno por
cada área de la empresa, también uno puede estar por productos y otros más
específicos como los proyectos temporales.18
Parte física.-
• Locales.
• Herramientas.
• Ordenadores.
Aspectos humanos.-
• Formación de personal.
18 http://es.wikipedia.org/wiki/Sistema_de_control_de_calidad_de_software
51
• Creación y coordinación de equipos de trabajo.
• Normativas.
ISO.-
• ISO 9000: Gestión y aseguramiento de calidad (conceptos y directrices
generales).
• Recomendaciones externas para aseguramiento de la calidad (ISO
9001, ISO 9002, ISO 9003).
• Recomendaciones internas para aseguramiento de la calidad (ISO
9004).
• MALCOLM BALDRIGE NATIONAL QUALITY AWARD(Premio Nacional
de Calidad Malcolm Baldrige).
2.3.1 CARACTERÍSTICAS DEL CONTROL DE LA CALIDAD
1. Esta normalmente limitado a las pruebas que los propios desarrolladores
llevan a cabo por ejemplo:
• Pruebas bajo presión de tiempo.
• Pruebas bajo presión del EGO.
2. A veces se ejecuta:
En puntos de revisión ligados a las etapas del ciclo de vida del desarrollo del
SW, particularmente antes del pase a producción.
3. Raras veces llega a ejecutarse:
Bajo un conjunto de rígidos patrones (check list) cuya revisión suele consumir
demasiado tiempo y se genera un retraso.19
19 www.qualitrain.com.mx/controldecalidad.index.php
52
2.4 CERTIFICACIÓN DE LA CALIDAD
La certificación de la calidad es un sistema o proceso que consiste en valorar
externamente a la organización, es decir, personas ajenas a la organización
evalúan los proceso y el producto mismo con el fin de demostrar y dar fe de
que la empresa es capaz de desarrollar productos y servicios con calidad.
Los pilares básicos de la certificación de calidad son tres:
• Una metodología adecuada.
• Un medio de valoración de la metodología.
• La metodología utilizada y el medio de valoración de la
metodología deben estar reconocidos ampliamente por la
industria.
Una actividad central que permite garantizar la calidad es la Revisión técnica
formal. Esta es una especie de reunión del personal técnico con el único
propósito de descubrir problemas de calidad.
Una de las principales amenazas para la calidad del software viene de los
cambios. Cada cambio realizado sobre el software en potencia puede introducir
errores o crear efectos laterales que propaguen errores. El proceso de control
de cambios contribuye directamente con la calidad del software, al formalizar
las peticiones de cambio, evaluar la naturaleza de cambio y controlar la
naturaleza de cambio.
El registro de información y la generación de informes para la garantía de
calidad del software, dan procedimientos para la recolección y divulgación de
información.
53
Los objetivos de la reunión técnica formal son :
• Descubrir errores en la función, la lógica o la implementación de
cualquier software.
• Verificar que el software bajo revisión alcance sus requerimientos.
• Garantizar que el software ha sido representado con ciertos estándares
predefinidos.
• Conseguir un software desarrollado de forma uniforme.
• Hacer que los proyectos sean más manejables.
• Se deben establecer directrices para conducir las revisiones técnicas
formales, distribuyéndolas entre los revisores, para ser consensuadas y
seguidas.
A continuación se muestra un conjunto de directrices para las revisiones
técnicas formales:
• Revisar el producto, no al productor.
• Fijar una agenda y mantenerla.
• Limitar el debate y las impugnaciones.
• Enunciar áreas de problemas, pero no intentar resolver cualquier
problema que se ponga de manifiesto (la resolución de problemas debe
ser pospuesta para después de la reunión de revisión).
• Limitar el número de participantes e insistir en la preparación anticipada.
• Desarrollar una lista de comprobaciones para cada producto que haya
de ser revisado.
• Disponer recursos y una agenda para las reuniones técnicas formales.
• Llevar a cabo un buen entrenamiento de todos los revisores (todos los
participantes en la reunión deben recibir algún entrenamiento formal ).20
20 Sanders 94, p. 44
54
Otra de las actividades de la garantía de calidad es la Seguridad del
Software.
Esta es una actividad que se centra en la identificación y evaluación de los
riesgos que podrían producir un impacto negativo en el software y hacer que
falle por completo.
Como parte de la seguridad del software, se dirige un proceso de análisis y
modelización. Primero se identifican los riesgos y se clasifican por su
importancia y grado de riesgo.
Después de haber identificado estos riesgos del sistema, se utilizan técnicas de
análisis para asignar su gravedad y probabilidad de ocurrencia. Se tiene que
analizar el software en el contexto del sistema completo, para que sea efectivo.
Cuando se han identificado y analizado los riesgos, se pueden especificar los
requerimientos del software relacionado con la seguridad.
2.5 COMPROBACIÓN & VALIDACIÓN
La comprobación y validación se esfuerzan en asegurar que la calidad este
construida en el software y de que el software satisfaga las exigencias del
consumidor.
La comprobación y validación trata a la calidad del producto de software
directamente y utiliza las técnicas de prueba que pueden localizar defectos
para poderlos tratar.
El proceso de Verificación & Validación determina si o no los productos de una
actividad dada del desarrollo o del mantenimiento se conforman con el
requerimiento de esa actividad, y si o no el producto de software final satisface
su propósito previsto y resuelve exigencias del consumidor.
La verificación es una tentativa de asegurarse que el producto está construido
correctamente, en el sentido de que los productos finales de una actividad
satisfacen las especificaciones que impusieron ante ellos en actividades
55
anteriores. La validación es una tentativa de asegurarse de que el producto
está bien construido, es decir, el producto satisface su propósito previsto
específico.
El proceso de la verificación y el proceso de la validación comienzan en las
primeras fases del ciclo de vida del software. Proporcionan una examinación de
las características del producto clave en relación al precursor inmediato del
mismo y a las especificaciones que este debe satisfacer.
El plan que resulta documenta y describe los roles y actividades, así como las
técnicas y las herramientas que se utilizarán. Una comprensión de los diversos
propósitos de cada actividad de V&V ayudará en el planeamiento cuidadoso de
las técnicas y de los recursos necesitados para satisfacer futuros propósitos. 21
2.6 EVALUACIONES Y AUDITORIAS
Antes que nada es importante dar una definición de lo que es la evaluación, yo
entiendo la evaluación como la etapa en la que se revisan los resultados
obtenidos del proceso de ciclo de vida del software y se contrastan con los
resultados que se esperaban al inicio del proyecto cuando se plantearon los
objetivos, es decir, es el proceso de información, interpretación y valoración de
las acciones realizadas para poder tomar decisiones, planes de acción y
pensar en la mejora de dichos procesos.
Los resultados de esta medición pueden ser el mejoramiento de la oferta
formativa, determinar si se han conseguido los objetivos planteados, y valorar
la acción formativa de cara a la organización, las actividades de esta etapa, se
realizan a la par con el desarrollo del diagnóstico, de tal manera que se pueden
ir solucionando los problemas que se presenten durante el transcurso del
mismo y al final para medir el logro de los objetivos propuestos.
21 www.emagister.com/calidad-software-tps-963351.htm
56
Existen varios criterios para evaluar un software y definir si conviene adquirirlo,
o si fue bueno o malo. Aunque claro para poder catalogar un software como
bueno o funcional, el mismo debe responder a diversos aspectos como
técnicos, pedagógicos, metodológicos y funcionales.
Algunos de los criterios que podemos tomar en cuenta son los siguientes:
Instalación y Uso Manejable
Si desde el momento de la instalación el software presenta listas interminables
de procedimientos y el proceso es lento y complejo al usuario no le va a gustar
y lo va a rechazar por eso se recomienda que el software se auto instale y de
ser necesario en algún momento futuro disponga de una utilidad de
desinstalación fácilmente localizable y aplicable. Así mismo, es deseable que
una vez instalado presente accesos y menús que faciliten el movimiento de
salida del programa. Es decir que funcione por si solo.
Calidad del Entorno
Siempre es muy recomendable que el software que se esta entregando sea
agradable a la vista, que al usarlo por primera vez te familiarice con el y abra la
mente del usuario a explorarlo y quererlo.
Versatilidad
Este es un aspecto de suma importancia si el software va a ser usado en
diferentes contextos. Es decir si va a ser utilizado por diferentes áreas de
trabajo y estudio, o si va a ser para todo el personal o solo para algunos.
El software debe permitir enfrentar dichas variaciones del contexto formativo.
Es recomendable investigar si el programa es capaz de permitir el cambio en
sus bases de datos por ejemplo, si permite modificar su idioma, el número de
usuarios simultáneos, su conectividad individual o en red, etc.
57
Navegación
Es recomendable que la navegación dentro del programa resulte sencillo, ya
que propiciará su facilidad de uso. El esquema de navegación debe permitir al
usuario tener el control, acceder fácilmente a cualquier contenido. Así mismo
los atajos de teclado deben ser cortos y la escritura desde el teclado debe
verse en pantalla sin errores.
Promueve el Autoaprendizaje e Iniciativa
El software debe crear el entusiasmo en el usuario para aportar ideas o
mejoras al mismo, debe crear las ganas de profundizar en el y volverse experto
y no solo ocupar lo básico para su trabajo.
2.6.1 PROCESO DE EVALUACIÓN
A continuación se muestra la evaluación del producto software según la norma
ISO 14598
Proceso de evaluación
Figura No. 7 Evaluación del producto
Recursos yentorno
Proceso deevaluación
Efecto delproductosoftware
Apoyo a laevaluación
Proceso deevaluación
MétricasInternas
Métricasexternas
Métricas decalidad en
uso
Productosoftware
14598-2
14598-6
14598-3
14598-4
14598-5
14598-1
9126-3 9126-2 9126-4
9126-1
58
Establecer
requerimientos
de evaluación
Establecer propósito de la evaluación (7.1)
Identificar los tipos de producto(s) (7.2)
Especificar el modelo de calidad (7.3)
9126-1 Características de
Calidad
Especificar
evaluación
Seleccionar métricas (8.1)
Establecer niveles para las métricas (8.2)
Establecer criterios de valoración (8.3)
Diseñar evaluación
Producir plan de evaluación (9.1)
Ejecutar
evaluación
Tomar medidas (10.1)
Comparar con criterios (10.2)
Valorar resultados (10.3)
9126-2 Métricas Externas
9126-3 Métricas Internas 14598-6 Módulos de
Evaluación
Proceso de evaluación del producto
Figura No. 8 Proceso de evaluación del producto
La figura anterior se describe a continuación:
Establecer el propósito de la evaluación
Productos intermedios: decidir sobre la aceptación de un producto intermedio
de un subcontratista; decidir cuando un proceso está completo y cuando remitir
los productos al siguiente proceso; predecir o estimar la calidad del producto
final; recoger información con objeto de controlar y gestionar el proceso.
Producto final: decidir sobre la aceptación del producto; decidir cuando
publicar el producto; comparar el producto con otros productos competitivos;
seleccionar un producto entre productos alternativos; valorar tanto el aspecto
59
positivo como negativo cuando está en uso; decidir cuando mejorar o
reemplazar un producto.
Identificar los tipos de producto(s) a ser evaluados
Figura No. 9 Identificación de los productos a evaluar
Requerimientos
Operación
uso y respuesta
mundo real
*ecesidades
Calidad en uso
métricas externas
Especificación
Pruebas
Comportamient
o del sistema
real
-
Requerimientos
de calidad
externos
Calidad externa
métricas
externas
Diseño y Desarrollo
atributos software
Requerimientos
de calidad
internos
Calidad interna
métricas internas
determina
determina
indica
indica
60
Establecer niveles de puntuación para las métricas
Producir un plan de evaluación
El plan de evaluación describe los métodos de evaluación y el programa de
acciones del evaluador (UNE 71048-3, UNE 71048-4 o UNE 71048-5). Debe
ser consistente con el plan de mediciones (UNE 71048-2).
Figura No. 10 Plan de evaluación
nivel planeado
nivel actual
el caso peor
Excede los requisitos
Rango objetivo
Mínimamente aceptable
Inaceptable
satisfactorio
insatisfactorio
valor
medido
escala de medición niveles de puntuación
3. Proceso paraDesarrolladores
4. Proceso paraAdquisidores
5. Proceso paraEvaluadores
2. Planificación y Gestión 6. Documentación demódulos evaluación
61
Necesidad de construir un producto con integridad.
El objetivo del desarrollador de software es construir un producto que tenga
“integridad”, es decir que:
• Satisfaga las necesidades funcionales del usuario.
• Pueda ser seguido fácilmente y completamente a través de su ciclo de
vida.
• Se cumpla con los criterios de desempeño especificados.
• Se cumplan las expectativas de costo.
• Se cumplan las expectativas de fecha de entrega.
Para la construcción de un producto con integridad es necesario llevar a cabo
tres funciones básicas:
• Gestionar el proyecto
• Desarrollar el producto
• Cautelar las propiedades del producto
Actualmente existe como parte de todo este proceso y tópico de la evaluación
del software la llamada serie de Normas UNE 71048 Tecnología de la
Información.
La cual corresponde a la adopción como norma nacional de la serie de Normas
Internacionales ISO/IEC 14598. Como el título lo índica, trata esencialmente de
normalizar el proceso de evaluación del producto software con el propósito de
posibilitar la comparación de diferentes productos o poner de manifiesto sus
aspectos mejorables.
La serie de normas UNE 71048 proporciona métodos para la medición,
valoración y evaluación de la calidad del producto software. No describe
métodos para la evaluación de procesos de producción de software ni métodos
62
para la predicción de costos (por supuesto, las mediciones de la calidad del
producto software pueden usarse para estos fines).
La futura norma PNE 71049 (ISO/IEC 9126) define un modelo de calidad
general, las características de calidad y presenta ejemplos de métricas. La
serie de normas UNE 71048 presentan una visión general de los procesos y los
requerimientos de evaluación del producto software y proporcionan una guía
para la evaluación. Las normas UNE 71048-2 y UNE 71048-6 tratan de la
gestión y soporte de la evaluación corporativa o departamental, en tanto que
las normas UNE 71048-3, UNE 71048-4 e UNE 71048-5 muestran los
requerimientos y constituyen la guía para la evaluación en un proyecto.
La norma UNE 71048: Tecnología de la Información – Evaluación del Producto
Software (Soporte Lógico) esta formada de 6 partes o pasos:
• Parte 1: Visión general.
• Parte 2: Planificación y gestión.
• Parte 3: El proceso para desarrolladores.
• Parte 4: El proceso para adquisidores.
• Parte 5: El proceso para evaluadores.
• Parte 6: Documentación de los módulos de evaluación.
Proceso de evaluación:
La serie de normas UNE 71048 proporciona los requisitos y una guía para el
proceso de evaluación en tres situaciones distintas:
• Desarrollo (mejora) (UNE 71048-3).
• Adquisición (UNE 71048-4).
• Evaluación independiente (incluida evaluación por terceros)
(UNE 71048-5).
63
Proceso para desarrolladores: La norma UNE 71048-3 debe usarse por
organizaciones que proyectan el desarrollo de un nuevo producto o la mejora
de un producto existente y pretenden realizar la evaluación del producto
utilizando los miembros de su propia plantilla de técnicos. Se centra en el uso
de aquellos indicadores que pueden predecir la calidad del producto final
mediante la medición de productos intermedios creados durante el ciclo de
vida.
Proceso para adquisidores: La norma UNE 71048-4 debe usarse por las
organizaciones que proyectan adquirir o reutilizar un producto software
existente o pre-desarrollado. Puede aplicarse para decidir sobre la aceptación
del producto o para la selección de un producto de entre varios alternativos.
(Un producto puede ser auto-contenido, ser una parte de un sistema, o puede
ser parte de un producto mayor).
Proceso para evaluadores: La norma UNE 71048-5 debe usarse por los
evaluadores que lleven a cabo una valoración independiente de un producto
software. Esta evaluación podría realizarse bajo petición de un desarrollador,
adquisidor u otros. Esta parte está destinada a aquellos que realizan
evaluaciones independientes. Con frecuencia trabajan para terceros.
Planificación y Gestión: La norma UNE 71048-2 Planificación y Gestión
contiene requerimientos y guías para las funciones de apoyo a la evaluación
del producto software. El soporte proporcionado está relacionado con la
planificación y gestión del proceso de evaluación del software y las actividades
asociadas, incluyendo desarrollo, adquisición, normalización, control,
transferencia y realimentación de la experiencia de evaluación dentro de la
organización. Esta parte de la Norma UNE 71048 se puede usar por gestores
que deseen generar un plan de evaluación cuantitativo.22
22 www.is.ls.fi.upm.es/udis/docencia/erdsi/Documentacion-Evaluacion-6.pdf
64
2.6.2 INSPECCIONES
Las inspecciones de software surgen a partir de la necesidad actual de poder
producir y entregar software con verdadera y alta calidad.
Algunos grupos de desarrollo creen que la calidad del software es algo en lo
que deben preocuparse una vez que se ha generado el código. Obviamente
esta idea es totalmente un error por todo lo que se ha mencionado a lo largo de
este trabajo, la garantía de la calidad del software es una actividad de
protección que se aplica a lo largo de todo el proceso de ingeniería de
software.
El control de la calidad es una serie de revisiones, y pruebas utilizados a los
largo del ciclo de desarrollo para asegurar que cada producto cumple con los
requerimientos que le han sido asignados.
La garantía de calidad del software comprende una gran variedad de tareas, y
estas están asociadas con dos aspectos diferentes: los ingenieros de software,
que realizan trabajo técnico, y un grupo de aseguramiento de calidad , que son
los que tiene la responsabilidad de la planificación de garantía de calidad.
Es en esta parte del proceso de garantía de calidad en donde se encuentran
las llamadas inspecciones que son como una implementación de las revisiones
formales del software las cuales representan un filtro para el proceso de
ingeniería de software, estas inspecciones se aplican durante el proceso de
desarrollo y construcción del software y sirven para detectar los defectos del
mismo y corregirlos en el mismo momento obviamente antes de entregarlo.
En todo trabajo o actividad de la vida diaria existe la posibilidad de cometer
ciertos errores, errores que solo podrían ser detectados al realizar una revisión
del trabajo en general, es por esto la importancia de este punto.
65
Una revisión es una forma de aprovechar la diversidad de un grupo de
personas para:
� Señalar la necesidad de mejoras en el producto de una sola persona o
de un equipo.
� Confirmar las partes del producto en las que no es necesaria o no es
deseable una mejora.
� Conseguir un trabajo de mayor calidad maximizando los criterios de
correctitud y completitud principalmente.
Comúnmente se ha notado que los defectos o fallas que son lo mismo dentro
de un software se presentan o descubren justamente ya que el producto ha
sido entregado al usuario, esto obviamente es un error y un problema de
calidad del software, por lo tanto el principal objetivo de las inspecciones es
precisamente ese, el descubrir los fallas y/o defectos antes de que el producto
sea entregado.
Por medio de varios estudios como el TRW, Nippon Electric y Mitre Corp., entre
otros se ha demostrado que las inspecciones son efectivas en un 75% a la hora
de detectar errores. Con la detección y la eliminación de un gran porcentaje de
errores, el proceso de inspección reduce substancialmente el costo de los
errores en las fases de desarrollo y mantenimiento.
Por lo tanto es posible asegurar los siguientes beneficios en la detección de
errores al aplicar las inspecciones:
� Reducción de los defectos en el uso del software.
� Reducción de los recursos de desarrollo, sobre todo en las etapas de
codificación y prueba
� Reducción en los costos de mantenimiento correctivo
66
2.6.2.1 EL PROCESO DE INSPECCIÓN
Las inspecciones podría decirse que son un repaso detallado de lo que se esta
haciendo, generalmente se realizan de la siguiente manera, un pequeño grupo
de personas también llamados inspectores revisa un producto de trabajo,
entiéndase por grupo de trabajo 200 líneas de código, o requerimientos, o
diseño entre otros, ya que revisaron esos productos de trabajo se reúnen todos
los grupos y se revisa en conjunto los defectos encontrados. Los productos de
trabajo son considerados en progreso hasta que la inspección y las
correcciones necesarias estén completas.
La inspección consiste en seis pasos:
1.- Planificación: Cuando el desarrollador completa un ‘producto de trabajo’,
se forma un grupo de inspección y se designa un moderador. El moderador
asegura que el ""producto de trabajo"" satisfaga el criterio de inspección. Se le
asignan diferentes roles a las personas que integran el grupo de inspección, así
como la planificación de tiempos y recursos necesarios.
2.- Overview: Si los inspectores no están familiarizados con el desarrollo de el
proyecto, una vista general es necesaria en éste momento. Este es un paso
opcional, pero no menos importante ya que en esta etapa se dará al grupo de
inspección un "background" y el contexto a cubrir por las inspecciones.
3.- Preparación: Los inspectores se preparan individualmente para la
evaluación en la reunión, estudiando los productos de trabajo y el material
relacionado. Aquí es aconsejable la utilización de listas de chequeos para
ayudar a encontrar defectos comunes, el tiempo que pueda llevar esta etapa va
a depender de cuan familiarizado se encuentre el inspector con el trabajo que
debe analizar.
4.- Examen: En esta etapa, los inspectores se reúnen para analizar su trabajo
individual en forma conjunta. El moderador deberá asegurarse que todos los
inspectores están suficientemente preparados.
67
La persona designada como lector presenta el ‘producto de trabajo’,
interpretando o parafraseando el texto, mientras que cada participante observa
en busca de defectos.
Es recomendable que este examen no dure mas de 2 horas ya que la atención
en busca de defectos va disminuyendo con el tiempo. Al terminar con la
reunión, el grupo determina si el producto es aceptado o debe ser nuevamente
elaborado para una posterior inspección.
5.- Retrabajo: El autor corrige todos los defectos encontrados por los
inspectores.
6.- Seguimiento: El moderador revisa las correcciones del autor. Si el
moderador está satisfecho, la inspección está formalmente completa, y el
‘producto de trabajo’ es puesto bajo el control de configuración. 23
A partir de estos seis pasos surge la necesidad de la conformación de:
objetivos, participantes de la inspección y con que roles, productos de trabajo a
inspeccionar y cual deberá ser el resultado de las reuniones de inspección.
Objetivos: El principal objetivo es encontrar defectos en el "producto de
trabajo", de esta manera debemos definir cuales serán las metas a alcanzar
para el cumplimiento de este objetivo.
Grupos de inspección: Se recomienda formar grupos entre 3 y 6 personas.
Dentro de éste grupo debe incluirse al autor de los productos de trabajo.
Roles: Además del autor se deberá tener en cuenta al moderador quien dirige
la inspección y deberá contar con mayor experiencia que el resto, el lector
quien presenta los productos de trabajo en las reuniones y el escriba quien
documenta la descripción y ubicación de los defectos encontrados.
23 Fagan 1986, pag 254,Limusa.
68
Productos de trabajo: El proceso de inspección puede ser aplicado a diferentes
tipos de productos de trabajo que pueden encontrarse en un desarrollo de
software incluyendo requerimientos, diseño, código, test, guías de usuario y
otro tipo de documentación. El estándar de la IEEE no especifica un tamaño ,
pero los productos de trabajo tienen un tamaño de 10 a 20 hojas para
especificación de requerimientos, 200 o 250 líneas de código.
Resultado de las reuniones de inspección: Los dos resultados principales
deben ser: Una lista de defectos a corregir , y un reporte de inspección que
describa que es lo que se inspeccionó, quien la llevo a cabo y el número de
defectos encontrados.
Además de todos los actores indicados anteriormente falta por mencionar un
nuevo actor, que es el llamado “coordinador de inspecciones” y el es la persona
que se encarga de planear y dirigir las inspecciones, entre sus principales
actividades se encuentran las siguientes:
� Aprender sobre inspecciones y convencer al proyecto de utilizarlas.
� Determinar en qué parte del proyecto deben ser utilizadas.
� Crear y documentar específicamente para cada proyecto los
procedimientos de inspección así como los manuales de inspección.
� Organizar entrenamientos en el proceso de inspección manteniendo la
documentación y actualización de dicho entrenamiento.
� Recolectar datos de inspecciones en los proyectos para una base de
datos de inspecciones.
� Analizar datos de inspecciones de distintos proyectos para hacer
recomendaciones de mejoras en los procesos.
Como es de suponerse el proceso de inspecciones puede ser medido tanto en
la planificación, monitoreo, control y mejora para poder maximizar su eficacia y
crear posteriores comparaciones y corregir desvíos que pudieran haber surgido
durante la inspección.24
24 www.monografias.com/trabajos6/isof/isof.shtml
69
2.6.3 RECORRIDOS COMPLETOS
El propósito de los recorridos completos es evaluar un producto de software. Y
educar a una audiencia con respecto a un producto de software.
Los objetivos principales son:
� Encontrar anomalías.
� Mejorar el producto.
� Considerar diferentes alternativas de implementación.
� Evaluar conforme a estándares y especificaciones.
Los recorridos completos son similares a las inspecciones solo que se llevan a
cabo de manera menos formal. Los recorridos completos son primeramente
organizados por el ingeniero de software para dar a sus compañeros de equipo
la oportunidad de revisar el trabajo y asegurar y evaluar su técnica. 25
2.6.4 AUDITORIAS
La Auditoria de Software es un término que se refiere a la investigación y al
proceso de entrevistas que determina cómo se adquiere, distribuye y usa el
software en la organización.
Conducir la auditoria es una de las partes más críticas de un Programa de
Administración de Software, porque la auditoria ayuda a la organización a
tomar decisiones que optimicen sus activos de software.
Un estudio de Print UK Limited, firma de Administración de auditoría, descubrió
que una organización típica con más de 500 PCs muchas veces tiene un 20%
más de computadoras de lo que cree. El Gartner Group también descubrió que
más de un 90% de las organizaciones han incrementado su base de activos de
TI sin haber hecho ningún proceso para su seguimiento.
25 www.emagister.com/auditoria-calidad-software-tps-1413086.htm
70
Una de las razones por las que las organizaciones no maximizan su inversión
en activos de software es que no hay información exacta disponible. La
recopilación de toda la información necesaria es un proceso intenso,
especialmente cuando se hace por primera vez. Otro problema es que la
perspectiva de una auditoría puede ser vista con algunas reservas por algunos
directivos de la organización, preocupados porque pueda interrumpir el flujo de
trabajo, y por algunos usuarios finales que pueden ser forzados a abandonar
sus programas o procedimientos favoritos.
Una de las formas de evitar las objeciones y dejar de lado estos problemas es
planificar cuidadosamente la Auditoría de Software y comunicar su valor por
adelantado.
Por lo tanto recomiendo los siguientes factores como elementos que podrían
favorecer notablemente la colaboración entre la gerencia y el personal a través
del proceso de planificación, el cual es una llave para el éxito de cualquier
auditoria de software.
• Establecer y acordar una serie clara de objetivos y comunicarla a todos
los empleados asociados con la auditoria.
• Enfocarse en los resultados que se requieran de la auditoria y discutir
las áreas donde se crea pueda haber problemas.
• Identificar las áreas simples pero muchas veces olvidadas que necesitan
ser consideradas, tales como:
• Acceso a sitios y creación de mapas de esas locaciones
• Conocer con anticipación los log-on scripts de seguridad o claves.
• Horario de la auditoria (durante el día, noche o fin de semana).
• Diseñar el plan y el cronograma de la auditoria, así como también las
herramientas de auditoria que serán usadas.
• Asignar recursos para cada elemento específico de la auditoria.
71
Al realizar una auditoria será necesario buscar cada pieza de software en la
organización, pero afortunadamente existe una gran cantidad de herramientas
para automatizar la tarea. Este proceso puede ser en su mayor parte manejado
con soluciones de software, especialmente si los sistemas de información de la
organización están centrados en una o más redes, o las aplicaciones de
software se comparten en la red.
Además, este es un paso en el que frecuentemente se contrata a profesionales
externos de auditoria.
La Auditoria de Software incluye cuatro pasos:
1.- Preparación: Determinación del alcance de la auditoria, selección de las
herramientas a utilizarse, identificación de las personas que conducirán la
auditoria incluyendo consultores externos y la elaboración de un cronograma.
2.- Trabajo de campo: Un inventario de activos de software en toda la
organización, con una conciliación de licencias y otra documentación de
propiedad, así como también una revisión de todos los servidores de la red y
otros lugares de almacenamiento de datos.
Este paso deberá incluir también una revisión de los procedimientos de
seguridad y recuperación ante desastres de datos, procedimientos anti-virus y
otras consideraciones especiales.
3.- El Reporte de Auditoria: Se preparará un informe basado en los hallazgos
de la auditoria, e incluirá como un apéndice al Plan de Administración de
Software.
4.- Acciones correctivas: Generalmente durante la primera auditoria el equipo
aprende lo más importante en términos de cálculos de tiempo y planificación de
recursos. Al tomar simples acciones correctivas en los procedimientos y
políticas, esta auditoria puede convertirse en la base, con auditorias adicionales
que requieran significativamente menos trabajo.26
26 www.samsistemas.com.ar/servicios_especiales/auditoria_de_software.html
72
CAPÍTULO 3
CONSIDERACIONES PRÁCTICAS
3.1 REQUERIMIENTOS DE CALIDAD DE SOFTWARE
El modelo ISO/IEC 9126 presenta el concepto de calidad del producto
descompuesto en la calidad interna, externa y en uso. Las necesidades de
calidad del usuario sobre el producto software, contribuyen a especificar los
requerimientos de calidad externa y estos a su vez los requerimientos de
calidad interna. El cumplimiento de los requerimientos de calidad interna,
externa y en uso se deben de comprobar en un proceso que permita evaluar la
calidad a través de las métricas. Este enfoque de tres niveles cubre las
perspectivas del usuario, desarrollador y el producto mismo
La traducción de los requerimientos de calidad a nivel del usuario hacia la
calidad externa e interna representan un problema que el desarrollador debe
resolver en cada proyecto. Lamentablemente la especificación de
requerimientos de calidad externa e interna puede contener diversos errores si
no se cuenta con herramientas adecuadas para dicha actividad. Se sabe que la
definición de requisitos de software es una actividad complicada y describir la
calidad también es complicada.
La traducción de la necesidad de calidad del usuario a requerimientos de
calidad (externa e interna) podría derivarse estableciendo algunas reglas o
modelos utilizando un criterio de comparación relativa cada dos características,
siguiendo los pasos descritos en el estándar de IEEE u obtenerse directamente
de los involucrados utilizando cuestionarios adecuados como se hace en QAW
(Quality Attribute Workshop) Taller de Atributos de Calidad o bien usando los
principios de GQM (Goal/Question/Metrics) Objetivos,Preguntas y Méticas.
La técnica desarrollada se basa en la filosofía de los trabajos de QAW y GQM,
adaptándolos para la determinación de requerimientos de calidad considerando
el punto de vista del usuario.
73
Sommerville , afirma que la mejor forma de asegurar que los requerimientos de
calidad sean verificables, es expresándolos cuantitativamente.
Según Kruchten, el proceso de desarrollo de software parte de una necesidad
expresada por el usuario u otro stakeholder. Estas necesidades son
normalmente traducidas en los requerimientos.
Los requerimientos del software son una descripción abstracta de los servicios
que el sistema debería proporcionar al cliente, y las limitaciones bajo las cuales
éste debería operar.
Estos presentan tres importantes propósitos:
• Permiten a los desarrolladores entender cómo el cliente quiere que
trabaje el sistema.
• Especifican a los diseñadores la funcionalidad y las características que
el sistema debe tener.
• Especifican al grupo de prueba lo que deben demostrar para convencer
al cliente que el sistema satisface sus necesidades.
Los requerimientos del software se clasifican en: Requerimientos Funcionales
(RF) y Requerimientos No Funcionales (RNF). Según ISO 9126, tanto unos
como otros se corresponden con atributos de calidad deseables en un
software.
Estos requerimientos, al tiempo que avanza el proyecto, orientan el diseño de
la arquitectura, así como los casos de prueba que deben ser desarrollados.
Según Whittem los requerimientos de software son documentados con cierto
grado de rigurosidad y a través de un conjunto de especificaciones permiten
definir el alcance del desarrollo.
Estas especificaciones recogen no sólo la visión de los involucrados en el
desarrollo sino también un conjunto de restricciones que impone el negocio en
forma de reglas que limitan las necesidades propias del dominio.
74
La especificación o análisis de estos requerimientos puede hacerse de manera
formal (utilizando modelos matemáticos) o no formal (a través de modelos
que representan las dimensiones de: datos, comportamiento y funcionalidad).
De esta manera, las especificaciones de los requerimientos constituyen el
punto de partida para lograr el acuerdo del equipo de desarrollo acerca del
alcance del esfuerzo; y forman la base para la definición del diseño o la
arquitectura del software, así como los casos de prueba correspondientes.
La norma ISO/IEC 9126-1:2001 presenta los pasos del enfoque de calidad de
producto como un ejemplo orientado a la evaluación de la calidad. 27
Los pasos descritos son:
• Identificación de requerimientos de calidad.
• Especificación de la evaluación.
• Diseño de la evaluación.
• Ejecución de la evaluación.
• Retroalimentación a la organización.
El primer paso debe realizarse durante el Análisis de los Requerimientos y el
resto de pasos durante cada actividad del proceso de desarrollo.
Los tres primeros pasos son descritos con detalle en la norma, el cuarto hace
una referencia a la serie de normas ISO/IEC 14598 y el quinto presenta un
comentario sencillo y directo sobre como realizar la evaluación.
PASO 1.- La identificación de requerimientos de calidad permite determinar los
pesos a ser utilizados en el modelo de calidad y que debe reflejar las
necesidades de calidad del usuario para cada una de las características y sub
características.
27 www.ewh.ieee.org/reg/9/etrans/vol4issue2April2006/4TLA2_6Davila.pdf
75
Los pesos representan la valoración comparada entre las distintas
características y sub características y para ello se puede utilizar una calificación
relativa de alto / medio / bajo o una calificación basada en valores que puede ir
entre 1 y 9.
PASO 2.- La especificación de la evaluación permite identificar los valores
deseables de las métricas a utilizar posteriormente en el desarrollo y en la
evaluación del producto. Estos valores deben orientarse principalmente a cubrir
las necesidades del usuario. La definición de valores deseables depende
directamente de cada atributo del producto.
PASO 3.- El diseño de la evaluación comprende la preparación de un plan de
medición que contenga lo que se entregará y sobre el cual se hará el proceso
de medición y las métricas que se aplicarán.
3.1.1 DEFINICIÓN DE REQUERIMIENTOS DE CALIDAD (DReC )
Ahora bien la técnica más comúnmente utilizada para la definición de
requerimientos de calidad conocida como DReC se propone como “una técnica
para la determinación de los requerimientos de calidad de un producto software
basada principalmente en el punto de vista de usuarios y el punto de vista de
desarrolladores de una manera complementaria”. 28
La definición implica que:
La determinación de requerimientos de calidad es un proceso de fijación de
valores (niveles de calidad y estimación de métricas) que serán tomados
inicialmente para la planificación de la calidad y posteriormente como
referencia para la evaluación del producto software.
28 www.monografias.com/trabajos6/resof/resof.shtml(15/06/2007)
76
El usuario es un actor importante en la determinación de los requerimientos de
calidad y su punto de vista debe ser sistemáticamente obtenido.
El desarrollador es un actor que opondrá la opinión del usuario, pero debe
subordinar –finalmente- su opinión a la del usuario si no existe un consenso
sobre los valores de las mismas.
DReC se orienta principalmente a usuarios finales, por lo que la manera de
relacionarse a él, será en términos lo menos técnicos posible pero con la
claridad necesaria para determinar adecuadamente los valores; DReC se basa
en la serie de normas ISO/IEC 9126, ISO/IEC 14598 y recomendaciones del
Cuerpo de Conocimiento de la administración de Proyectos (PMBOK) del
Project Management Institute.
La herramienta debe ajustarse al contexto de la organización que utilizará el
producto y al de la organización desarrolladora. Primero con la organización
usuaria, por que pueden tener datos sobre los niveles de calidad de los
productos que utilizan y pueden ser tomadas como referencia para los nuevos
productos que requieran.
Y segundo con la organización desarrolladora, por que ellos pueden tener
datos sobre los niveles de calidad obtenidos en proyectos anteriores, que
pueden respaldar el nivel esperado de calidad en el nuevo proyecto. Sin
embargo la técnica puede aplicarse también en las organizaciones usuarias y
desarrolladoras que no cuentan con estos datos históricos; ya que no es una
práctica extendida.
Los objetivos de esta técnica son determinar:
• Las características de calidad interna y externa que son relevantes en el
desarrollo de software.
• Los niveles de calidad de cada característica y sub-característica.
• Los niveles de calidad de los atributos (valores deseables de las
métricas) del producto a desarrollar.
77
Estos objetivos primarios de DReC coinciden con los tres primeros pasos
establecidos por la ISO/IEC 9126 descrito en la sección anterior.
Para la primera aproximación de DReC se han considerado las métricas de los
atributos establecidos para las sub-características internas y externas del
modelo de calidad del producto software, de la serie ISO/IEC 9126.
Los cuestionarios de DReC se han elaborado a partir de las definiciones
propias de la norma de características, sub-características y métricas.
3.1.2 DESCRIPCIÓN DE LA TÉCNICA DReC
Anteriormente se dio una visión general de lo que es esta técnica, ahora vamos
a describirla mas a fondo.
La técnica se compone de 3 pasos:
Paso 1: Seleccionar componentes; el objetivo de este paso es seleccionar un
conjunto de componentes a los cuales se les aplicará el resto de la técnica. La
razón es que un producto software tiene diversos componentes cuyas
necesidades de calidad son diferentes, dependiendo de la función que realizan
dentro del producto final.
Un claro ejemplo se da en los sistemas de información en donde existen
componentes de explotación de información (como reportes) cuyo nivel de
calidad requerido es diferente a los de registro y procesamiento de datos.
La selección de un sub conjunto de componentes sobre el que se aplique una
técnica es una práctica que también se ha usado en otras propuestas, un
ejemplo concreto es Squid.
El resultado del paso es una lista de componentes seleccionados, donde cada
componente puede ser distinguible por usuarios y desarrolladores; este paso
78
puede ser omitido si la organización desarrolladora tiene la lista de
componentes por alguna actividad previa a la aplicación de DReC.
Los sub- pasos que componen este paso son:
Paso 1a. Descomponer el producto software en componentes, se puede utilizar
una estructura de descomposición del trabajo orientada al producto también
conocido como WBS (del inglés Work Breakdown Structure) que es una
práctica recomendada por PMI (PROYECT MANAGMENTE INSTITUTE,
INSTITUTO DE ADMINISTRACION DE PROYECTOS). Opcionalmente se
puede utilizar otra técnica para identificación de componentes.
Paso 1b. Seleccionar los componentes relevantes, es decir, aquellos que son
considerados los más importantes y/o críticos para la solución (sistema
software) que se va a desarrollar.
Paso 2: Definir los valores del modelo de calidad (características y sub-
caracteristicas), el objetivo de este paso es la determinación de los valores a
ser usados en el modelo obtenidos sistemáticamente mediante un cuestionario
que se aplicará a cada componente seleccionado en el paso 1. La razón es que
el modelo de calidad es una representación abstracta de un conjunto de
características y sub características del producto software; sin embargo, el nivel
de importancia de las características y sub características varían entre uno u
otro proyecto y su contexto.
Un software para niños tiene características de calidad muy disímiles con un
software para una sala de urgencias, que uno para un sistema de información
empresarial.
Cada participante contestará el cuestionario de modo que plasme su
percepción sobre la importancia comparada- de las características y sub
características. Los participantes son usuarios y desarrolladores; y el
cuestionario está redactado de manera que sea fácil de comprender
(principalmente para los usuarios); pero cuyas respuestas permitan
internamente ayudar en la determinación de los valores a emplearse en el
modelo de calidad.
79
La hoja de cuestionario se ha elaborado a partir de las definiciones
proporcionadas en la norma ISO/IEC 9126-1: 001 y se compone de 33
preguntas. El resultado deste paso es un modelo de calidad con los pesos
definidos a nivel de características y sub-características.
Los sub pasos que componen este paso son:
Paso 2a. Completar la hoja inicial (DReC00) marcando con una "x" de acuerdo
a cada línea que describe una característica o sub característica. La hoja es
completada por todas las personas convocadas: usuarios y desarrolladores.
Paso 2b. Consolidar la información de todos los participantes, de preferencia
de manera automática usando hojas de cálculo o un producto software ad-hoc
para esta actividad de modo que sea rápido y con resultados confiables.
Paso 2c. Revisar los resultados obtenidos y discutir sobre las respuestas cuya
variación sea significativa hasta encontrar Un consenso entre todos los
participantes de la sesión, la participación será mediante un director de debate.
Se podrá utilizar adicionalmente las hojas “DReC11” y “DReC12” siempre que
se cuente con datos históricos.
Paso 3: Definir los niveles de calidad esperado en los atributos del producto, el
objetivo de este paso es la determinación de los valores a ser usados como
nivel de referencia para las métricas en la evaluación, obtenidos
sistemáticamente mediante la aplicación de un conjunto de cuestionarios que
se aplicarán a cada componente seleccionado en el paso 1.
La razón es que la calidad de un producto será finalmente evaluada cada vez
que el usuario utiliza el software y a la cual comúnmente se le conoce como
calidad en uso, esta calidad -en uso- depende de la calidad externa y ésta a su
vez de la calidad interna del componente.
La determinación debe ser el resultado de una negociación (consenso /
acuerdo) entre los usuarios y los desarrolladores, que apoyados en DReC
pueden reducir la discusión sobre aquellos aspectos en que hay una diferencia
80
de opinión sobre el nivel de calidad requerido. Igual que en el paso anterior, los
participantes son usuarios y desarrolladores, y los cuestionarios están
orientados a los usuarios.
El cuestionario se ha elaborado a partir de las definiciones proporcionadas en
las normas ISO/IEC 9126-2:2003 e ISO/IEC 9126- 2:2003 y se compone de 6
cuestionarios con 25 preguntas en promedio cada uno. El resultado de este
paso es una hoja con los niveles de calidad en cada atributo del producto.
Los sub pasos que componen este paso son:
Paso 3a. Completar la hoja “DReC01” y “DReC02” marcando con una "x" de
acuerdo a cada línea que describe un atributo. La hoja es completada por todas
las personas convocadas: usuarios y desarrolladores
Paso 3b. Consolidar la información de todos los participantes, de preferencia
de manera automática usando hojas de cálculo o un producto software ad-hoc
para esta actividad de modo que sea rápido y con resultados confiables.
Paso 3c. Revisar los resultados obtenidos y discutir sobre las respuestas cuya
variación sea significativa hasta encontrar un consenso entre todos los
participantes de la sesión, la participación será mediante un director de debate.
Se utilizarán adicionalmente las hojas “DReC21” y “DReC22”.
Paso 3d. Repetir los sub-pasos anteriores para los pares de hojas “DReC03”-
“DReC04” y “DReC05”- “DReC06”.29
3.1.3 DOCUMENTACIÓN DE LA TÉCNICA
Esta técnica se basa en un conjunto de documentos y cuestionarios, los cuales
se han derivado principalmente de la serie de normas ISO/IEC 9126; y
plantillas de resultados anteriores, los cuales se han diseñado para almacenar
los requerimientos de calidad de un proyecto determinado (planificado), tanto
29 www.qualitrain.com.mx/procesos/out_req.php
81
para la organización usuario como desarrolladora, y para almacenar los niveles
reales de calidad logrados en dicho proyecto.
Los documentos utilizados en DReC se encuentran enumerados a
continuación:
• DReC00, para la determinación de valores de las características y sub
características, derivado de la ISO/IEC 9126-1:2001[13].
• DReC01..06, para la determinación de niveles de calidad interna y
externa en cada atributo de la característica de funcionalidad, fiabilidad,
eficiencia, usabilidad, facilidad de mantenimiento y portabilidad.
• DReC11, tabla de valores de pesos de calidad planificados por proyecto
y organización.
• DReC12, tabla de valores de pesos de calidad reales por proyecto y
organización.
• DReC21, tabla de valores de métricas de atributos del producto
planificados por proyecto y organización.
• DReC22, tabla de valores de métricas de atributos del producto reales
por proyecto y organización.30
3.1.4 APLICACIÓN DE LA TÉCNICA
DReC se debe aplicar en dos etapas principales: una que cubra el paso 1 y
otra que cubra los pasos 2 y 3 en conjunto.
Para el paso 1, el equipo de desarrollo es el encargado de hacer la
descomposición y la selección de componentes tomando en cuenta las
necesidades del usuario, el producto mismo y los objetivos de la organización
usuaria; esta etapa se puede realizar en una sola sesión.
30 dmi.uib.es/~bbuades/calidad/calidad.PPTv
82
Para el paso 2 y 3 se convoca a un conjunto de personas entre usuarios y
desarrolladores de modo que realicen las actividades indicadas para cada
componente. Se debe tener en cuenta que para cada componente podría
definirse un equipo diferente de personas quienes completen las actividades;
ello dependerá del componente en sí mismo.
Si el número de componentes es muy alto, quizás sea conveniente establecer
un conjunto de sesiones para cubrir todos los componentes, se sugiere que la
evaluación de un componente se realice totalmente dentro de una sola sesión;
dividir la evaluación de un componente en dos sesiones diferentes podría
introducir ruido debido a las conversaciones fuera de sesión de los
participantes.31
3.2 INFLUENCIA EN LOS FACTORES
Son varios los factores que influyen en la planificación, la administración, y la
selección de actividades de SQM(Administración de la calidad del Software) y
sus técnicas, incluyendo:
• El dominio del sistema en el que el software residirá (seguridad-crítico,
misión-crítico, businesscritical).
• Los requerimientos del sistema y el software.
• La propaganda (externo) o el estándar (interno).
• Los componentes para ser utilizados en el sistema.
• El software específico que dirige los estándares aplicables.
• Los instrumentos de métodos y software para ser utilizados para el
desarrollo y la conservación y para la evaluación de la calidad y la
mejora.
• El presupuesto, el personal, la organización del proyecto, los planes, y
planificación de todos los procesos.
• Los usuarios y el uso destinados del sistema.
• El nivel de la integridad del sistema.
31 www.ingenierosoftware.com/calidad/cmm-cmmi-nivel-2.php
83
La información en estos factores influye para saber cómo están organizados y
documentados los procesos de SQM y que tan especificas son las actividades
escogidas para los mismos, así como los recursos que se van a necesitar, y el
esfuerzo que llevara.32
3.3 SERIEDAD
En los casos donde el fracaso del sistema puede tener consecuencias muy
severas, la seriedad en general (hardware, el software, y el humano) es el
requerimiento principal de la calidad más allá de la funcionalidad básica. La
seriedad del software incluye tales características como la critica, la tolerancia,
la seguridad, y el valor práctico.
La certeza es también un criterio que puede ser definido en términos de
seriedad (ISO9126). El sistema en general debe ser completamente fiable
debe tener o proporcionar una confianza alta y deben ser sistemas altos en
integridad. 33
3.4 NIVELES DE INTEGRIDAD DEL SOFTWARE
El nivel de la integridad se determina basándose en las consecuencias posibles
del fracaso del software y la probabilidad del fracaso.
Para el software en el que la seguridad es importantes, las técnicas tales como
el análisis del peligro para el análisis de la seguridad o la amenaza para la
seguridad puede ser utilizado para desarrollar una actividad de planificación
que identificaría los lugares con problemas de alto potencial.
32 alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/rodolfo.pdf
33 www.planetacodigo.com/wiki/glosario:nivel_de_integridad
84
La historia del fracaso de software semejante puede ayudar también a
identificar que técnicas serian más útiles para discernir los defectos y valorar la
calidad. 34
3.5 CARACTERIZACIÓN DE DEFECTO
Los procesos de SQM encuentran defectos. Caracterizar esos defectos lleva a
una comprensión del producto, facilita las correcciones al proceso o el
producto, e informa a la administración del proyecto o al cliente de la posición
del proceso o el producto.
La caracterización de defecto es utilizada también en auditorias y revisiones,
con el líder de la revisión a menudo presentando una lista de anomalías
proporcionadas por miembros del equipo para la consideración en una reunión
de la revisión.
Cuando los nuevos métodos de diseño y las lenguas evolucionan, junto con
avances en tecnologías de software totales, nuevas clases de defectos
aparecen, y requieren mucho esfuerzo para que se interpreten clases antes
definidas. Rastreando defectos, el ingeniero de software está interesado no
sólo en el número de defectos sino también en los tipos de defectos.
Información simple y vana, sin alguna clasificación, no es realmente de ningún
uso para la identificación de las causas subyacentes de los defectos, desde
entonces los tipos específicos de problemas tienen que ser agrupados en
orden por determinaciones para ser hechas sobre ellos.
El punto es que se debe establecer una taxonomía de defecto que sea
significativa a la organización y a los ingenieros de software.
34
www.monografias.com/trabajos6/resof/resof.shtm
85
Generalmente la palabra “defecto” es usada o se refiere a una falta, sin
embargo, las diferentes culturas y estándares pueden usar diferentes
significados para estos términos, por ejemplo:
ERROR: “Diferencia entre un resultado calculado y el resultado correcto”.
FALTA: “Un paso incorrecto, proceso, o definición de datos en un programa de
computadora”.
FRACASO DE: “El resultado incorrecto de una falta”.
ERROR DE: “Una acción humana que produce un incorrecto resultado”.
Los fracasos encontrados en pruebas a consecuencia de faltas de software son
incluidos como defectos.
Los modelos de fiabilidad son construidos a partir de datos de fracaso
coleccionados durante pruebas de software o de software en servicio, y así
pueden ser usados para predecir futuros fracasos y asistir en decisiones acerca
de cuando dejar de probar.
Una acción probable que resulta de conclusiones SQM es que se eliminen los
defectos del producto en el examen.
Otras acciones permiten alcanzar de lleno los objetivos del proyecto a partir de
las conclusiones de actividades SQM. Estas acciones incluyen el análisis y el
resumen de las conclusiones, y la utilización de técnicas de medición para
mejorar el producto así como el rastreo de los defectos y su eliminación.
Los datos en las insuficiencias y defectos encontrados durante la
implementación de técnicas de SQM pueden ser perdidos a menos que se
registren correctamente. Para algunas técnicas como por ejemplo, las
revisiones técnicas, las auditorias, las inspecciones, resulta pertinente dejar
esa información junto con asuntos y decisiones.
86
Cuándo se automatizan algunas de las herramientas que son utilizadas en este
proceso, la misma automatización de la herramienta puede proporcionar la
información del defecto.
Los datos acerca de los defectos pueden ser reunidos y pueden ser registrados
en un SCR (reporte de cambios de software) los cuales se almacenan en la
base de datos para posteriores análisis, dichos informes acerca de defectos
son proporcionados a la administración de la organización.35
3.6 TÉCNICAS DE DIRECCIÓN DE CALIDAD DE SOFTWARE
Las técnicas de Administración de Calidad de software pueden ser clasificadas
en muchos sentidos: estáticas, personales-intensivas, analíticas, y dinámicas.
Técnicas para evaluación de la calidad
Las mediciones que se realizan sobre la calidad pueden tener distintos
objetivos, dependiendo de la situación en la que se encuentre el proyecto y la
aplicabilidad de las técnicas que emplean.
Los modelos de análisis y diseño no se pueden probar en el sentido
convencional, ya que no pueden ejecutarse. Sin embargo se pueden utilizar
revisiones técnicas formales y otras técnicas para examinarlos. Para la
realización de estas pruebas, aunque no se realizan de manera simultánea, se
aplican las mismas técnicas que permiten descubrir errores dentro del contexto
de la sintaxis, semántica y pragmática de los modelos generados en estas
etapas.
Las técnicas aplicadas para la estimación de la calidad se pueden categorizar
de muchas maneras.
35 www.infor.uva.es/~manso/calidad/Cuestionesmedicion.pdf
87
3.6.1 TÉCNICAS ESTÁTICAS
Estas técnicas incluyen la examinación de la documentación del proyecto y del
software, así como de otra información acerca de los productos de software
pero sin ejecutarlos. Estas técnicas pueden incluir las actividades personales-
intensivas o actividades analíticas realizadas por individuos, con o sin la ayuda
de instrumentos automatizados.
Estas técnicas se aplican a la documentación del proyecto pero sin la
ejecución del producto. 36
3.6.2 TECNICAS PERSONALES INTENSIVAS
Incluyen revisiones y auditorias, utilizan técnicas analíticas y las pruebas del
producto.
Las técnicas personales-intensivas incluyen revisiones y auditorías, y pueden
variar de una reunión formal a una reunión informal o a una situación de
chequeo de escritorio, pero al menos debe incluir a dos o más personas. Los
recursos con excepción de los artículos bajo examinación pueden incluir listas
de comprobación y resultados de técnicas y de las pruebas analíticas.
•Técnicas inquisitivas: se destacan los cuestionarios, las listas de chequeo y los
escenarios. Actualmente las técnicas basadas en escenarios cuentan con dos
instrumentos de evaluación relevantes, a saber: el Árbol de Utilidad, y los
Perfiles.
•Técnicas de medición: son utilizadas para responder interrogantes específicas
sobre atributos de calidad determinados. Utilizan instrumentos como los
lenguajes de descripción arquitectónica (ADL), y las métricas, que son
interpretaciones cuantitativas sobre mediciones observables particulares
36 www.portal.educ.ar/noticias/educacion-y-sociedad/metodos-y-tecnicas-de- aseguramiento
88
realizadas sobre la arquitectura. Son utilizadas para medir la complejidad del
sistema, determinar la propensión de fallas de los módulos, etc.37
3.6.3 TÉCNICAS DE EVALUACIÓN
•Estática / Analítica / Inquisitiva + mediciones cualitativas .Aplicable a las
etapas tempranas del proceso. Aplicable a especificaciones de Análisis, Diseño
y Pruebas. Medir atributos de calidad interna. Ejemplos: análisis semántico,
listas de chequeo, cuestionario, métricas, análisis de trazabilidad, escenarios.
•Dinámica / Inquisitiva + mediciones cuantitativas .Aplicable a las etapas
tempranas del proceso .Aplicable al diseño. Atributos de calidad interna.
Ejemplos: métricas, simulación basada en modelos formales, escenarios
(árboles de utilidad, perfiles), simulación basada en ADL, chequeo de modelos.
•Dinámica / Pruebas + mediciones cuantitativas. Aplicable a las etapas tardías
del proceso. Aplicable al código y la integración. Atributos de calidad externa.
Ejemplos: evaluación basada en prototipo, métricas, escenarios (casos de
prueba)
•Dinámica / Inquisitiva + mediciones cuantitativas. Aplicable a las etapas
tardías del proceso. Aplicable al código y la integración. Atributos de calidad
externa. Ejemplos: cuestionarios, métricas.38
37 www.sqs.es/es/(03/06/2007)
38 www.usabilidadweb.com.ar/metodos_eval_calidad_web.php
89
3.6.4 TÉCNICAS ANALÍTICAS
Se aplican a diferentes partes del producto de manera manual o automatizada.
Pueden identificar defectos directamente pero normalmente son parte de otras
técnicas. Esta categoría también incluye los métodos formales.
Un ingeniero de software aplica generalmente las técnicas analíticas. A veces
varios ingenieros de software utilizan la misma técnica, pero cada uno lo aplica
a partes diferentes del producto. Algunas técnicas son instrumentos otros son
manuales. Algunos pueden encontrar los defectos directamente, pero ellos son
utilizados típicamente para sostener otras técnicas. Algúnos incluye también
varias evaluaciones como parte del análisis general de la calidad.
Los ejemplos de tales técnicas incluyen el análisis de la complejidad, control
del análisis del flujo, y el análisis algorítmico. Cada tipo del análisis tiene un
propósito específico, y no toda clase es aplicado a cada proyecto. Un ejemplo
de una técnica de apoyo es el análisis de la complejidad, que no es útil para
determinar si el diseño o la implementación son demasiado complejos de
desarrollar correctamente, para probar, ni para mantener. Los resultados de un
análisis de la complejidad se pueden utilizar también en casos reveladores de
prueba. Las técnicas de defecto-encontrado, tal como el análisis del flujo del
control, se puede utilizar también para dar soporte a otra actividad. Para el
software con muchos algoritmos, el análisis algorítmico es importante,
especialmente cuando un algoritmo inexacto podría causar un resultado
catastrófico.
Otro, más formal, son los tipos de técnicas analíticas conocidas como métodos
formales. Estos son utilizados para verificar software, los requerimientos y los
diseños. La prueba de la exactitud se aplica a partes críticas del software. Por
eso estos métodos han sido utilizados en su mayor parte en la comprobación
de partes cruciales de sistemas críticos, y los requerimientos más específicos
como los de la seguridad. 39
39 www.sqs.es/es/tecnicasevaluacion
90
3.6.5 TÉCNICAS DINÁMICAS
Incluyen técnicas de prueba, pero también la simulación, el chequeo de
modelos y la ejecución simbólica pueden ser consideradas dinámicas.
Las diferentes clases de técnicas dinámicas se realizan a través del desarrollo
y la conservación del software. Generalmente, éstas son técnicas de prueba,
pero técnicas tales como simulación, comprobación del modelo, y la ejecución
simbólica también se pueden considerar dinámicas.
La lectura del código se considera una técnica estática, pero existen ingenieros
bastante calificados o expertos en su trabajo que pueden leer el código así tal
cual como se les presenta, en este sentido, la lectura de código se puede
calificar también como una técnica dinámica.
Esta discrepancia al clasificar indica que personas con papeles diferentes en la
organización pueden considerar y pueden aplicar estas técnicas
diferentemente. 40
3.7 PRUEBA
Los procesos del aseguramiento descritos en la SQA y V&V examinan cada
salida concerniente a la especificación del requerimiento del software para
asegurar la consistencia, lo completo, la corrección, y el buen funcionamiento
del software.
Esta confirmación también incluye las salidas de los procesos del desarrollo y
del mantenimiento, la recopilación, el análisis, y la medición de los resultados.
La SQA se asegura de que los tipos apropiados de pruebas estén planeados,
convertidos, y puestos en ejecución adecuadamente, y V&V desarrolla los
planes de prueba, las estrategias, los casos de estudio y los procedimientos.
40 www.sqs.es/es/tecnicaevaluacion
91
Dos tipos de prueba pueden caer bajo los títulos de SQA y V&V, debido a su
responsabilidad dentro de la calidad al elegir los materiales usados en el
proyecto:
• Evaluación y prueba de las herramientas que se utilizarán en la prueba
de la conformidad del proyecto.
• La revisión de la prueba de la conformidad y de los componentes COTS
que se utilizarán en el producto.
A veces la realización independiente de un proceso de V&V puede ser
realizada o ejecutada para supervisar el proceso de la prueba y atestiguar que
efectivamente se este realizando la ejecución real de la misma y que además
este siendo conducida de acuerdo con los procedimientos especificados. Una
vez más V&V se puede invitar para evaluar la prueba, la suficiencia de los
planes de ejecución y de procedimientos, así como la suficiencia y exactitud de
resultados.
Otro tipo de prueba es el de tercera persona. Los terceros no son el
desarrollador, ni están de cualquier manera asociados al desarrollo del
producto. Los terceros son personas independientes a la organización y
generalmente son escogidos o asignados para realizar las pruebas por parte
de las autoridades de la misma organización. Su propósito es probar un
producto para comprobar si el sistema cumple con los requerimientos
especificados.
Existen otros tipos de pruebas de software por ejemplo las pruebas dinámicas,
de unidad, de integración, entre otras. A continuación se muestra una
clasificación de las mismas.
92
3.7.1 CLASIFICACIÓN DE PRUEBAS DEL SOFTWARE
Figura No. 11 Clasificación de pruebas
Prueba genérica: Cualquier actividad dirigida a evaluar un atributo o
capacidad de un programa o sistema y determinar si alcanza los resultados
requeridos.
Prueba dinámica (testeo)
El testeo: Es el proceso de ejecutar un programa o parte de un programa con
la intención de encontrar bugs. Antes de definir un bug es necesario conocer
varios términos que se suelen confundirse o usarse indistintamente:
Errores: Estos son equivocaciones humanas como los errores tipográficos o
sintácticos.
Defectos: Estos son condiciones impropias de un programa que generalmente
son el resultado de un error.
No todos los errores producen defectos en el programa, como comentarios
incorrectos o algunos errores de documentación.
93
Por el contrario, un defecto puede producirse por causas ajenas a las
herramientas.
Bugs: Son defectos del programa que se encuentran operando el mismo, ya
sea durante la prueba o durante su uso.
Los bugs provienen de los defectos, pero no todos los defectos causan bugs
(algunas están latentes pero nunca se encuentran).
Los defectos pueden encontrarse muchas veces, dando como resultado
múltiples bugs por defecto.
Fallas: Es un mal funcionamiento en una instalación de usuario.
Puede ser provocado por un bug, hardware, etc.
Problemas: Son dificultades encontradas por los usuarios.
Pueden provenir de fallas, mal uso o mal entendimiento.
Los problemas son eventos relacionados con el sistema.
Figura No. 12 Relación entre conceptos
94
Debugging: Proceso de diagnosticar la causa de un bug y corregirlo.
Es una actividad de corrección y no de testeo.
Verificación: Intento de encontrar bugs, ejecutando un programa en un
ambiente simulado o de testeo. Es el proceso que provee la corrección del
programa.
Corrección: Un producto es correcto si posee una sintaxis adecuada ya que
esta sintaxis indica si se está desarrollando el producto correctamente.
Validación: Intento de encontrar bugs, ejecutando un programa en un ambiente
real. Este es el proceso que provee la validez del programa.
Principios básicos del testeo
• El objetivo del testeo es descubrir bugs.
• Un buen caso de prueba es aquel que tiene altas probabilidades de
detectar un bug.
• Una parte necesaria de todo caso de prueba es la descripción del
resultado esperado.
• Los casos de prueba son para condiciones/ entradas válidas e inválidas.
• Se debe evitar el testeo no reproducible.
• Un programador debe evitar testear su propio programa.
• El test completo es casi imposible.
95
3.7.2 MARCO DEL TESTEO
Figura No. 13 Marco del testeo
3.7.3 MÉTODOS DE TESTEO
Caja blanca
Este método de testeo consiste en examinar la estructura y la lógica interna del
programa para poder así derivar los casos de prueba adecuados. Dicho
método comprende las técnicas de:
• Prueba de caminos posibles.
• Prueba de estructuras de datos.
• Prueba de decisiones y estructuras lógicas.
96
Gráficamente, se tiene la siguiente visión:
Figura No. 14 Caja Blanca
Caja negra
En este método para derivar los casos de prueba se examinan solamente los
requerimientos funcionales del programa.
·
Comprende las técnicas de:
• Prueba de valores límite.
• Particiones de equivalencia.
• Prueba por comparación.
Gráficamente, se tiene la siguiente visión:
Figura No. 15 Caja Negra
97
3.7.4 TIPOS DE PRUEBAS DINÁMICAS
Prueba de unidad
Esta prueba como su nombre lo indica revisa y verifica programas o módulos
de forma única o individual, y es ejecutada generalmente en ambientes
aislados o especiales y además casi siempre es ejecutada por la misma
persona que programó el módulo o programa en cuestión.
Esta prueba es la que regularmente encuentra la mayor cantidad de bugs en
el programa.
Esta es una sencilla representación gráfica de esta prueba:
Figura No. 15 Prueba de unidad
Prueba de integración
Esta prueba verifica las interfaces entre las partes de un sistema es decir entre
sus módulos, componentes o subsistemas. La integración en esta prueba
puede ser total (Big Bang) o gradual:
98
Gráficamente esta prueba se representa asi:
Figura No. 16 Prueba de Integración
Prueba de sistema
Esta prueba verifica el sistema global contra sus objetivos iniciales además
recomienda que también se testeen los siguientes conceptos:
• Volumen
• Instalabilidad
• Operabilidad
• Seguridad
• Performance
Esta prueba se representa gráficamente así:
Figura No. 17 Prueba de Sistema
99
Prueba de aceptación
En esta prueba se valida el sistema contra los requerimientos del usuario,
aunque no siempre, son ejecutados, típicamente, en el ambiente real del
usuario además los casos de prueba son generalmente especificados y
ejecutados por los mismos usuarios y así poder tener el visto bueno de quien
en cierta manera es la persona mas importante, puesto que son ellos quien lo
van a utilizar la mayor parte del tiempo.
Prueba de regresión
Su nombre se debe a que se contrapone con las demás pruebas dinámicas,
que son progresivas ya que realizan el testeo de nuevas funciones y
características. Esta prueba es la ejecución de un subconjunto de casos de
prueba, previamente ejecutados y que sirven para asegurar que los cambios a
un programa o sistema no lo degradarían.
Uno de los puntos mas difíciles o complicados de esta prueba es realizar la
correcta selección de los casos de prueba que se deben volver a ejecutar, que
sean casos que realmente nos van a brindar información y resultados útiles.
Esta prueba es el test más común en la etapa de mantenimiento de un sistema
y forma parte de las pruebas dinámicas progresivas.41
3.7.5 FASES DE LAS PRUEBAS DINÁMICAS
Planificación: Se define el plan de pruebas y los objetivos de las mismas.
Dentro de esta etapa se debe especificar, entre otros aspectos los siguientes:
• Funciones, procesos y características a testear y a no testear.
• Métodos, tipos y orden del testeo.
41 www.grupocobos.com.mx/zrc/pruebas.htm
100
• Criterios de aprobación de la prueba.
• Criterio de clasificación de severidad de bugs.
• Ambientes, recursos físicos y herramientas a utilizar.
• Recursos humanos, responsabilidades y cronograma.
Diseño: Se determina cómo cumplir con los objetivos establecidos en la
planificación. Se deben especificar, entre otros:
• Condiciones generales a testear e ítems generales a verificar por función
o proceso.
• Procedimientos de ejecución de casos de prueba.
Derivación de casos: Es la especificación de cada uno de los casos de prueba.
Para cada caso se deben especificar, entre otros:
• Función a testear.
• Condiciones a testear.
• Resultado esperado.
Preparación: Es la confección de todos los elementos necesarios para la
ejecución de la prueba, tales como:
• Archivos.
• Scripts.
• Formularios.
• Tarjetas.
Ejecución: Es la ejecución de cada caso de prueba.
• Por cada caso se deben registrar, entre otros.
• Resultado obtenido.
• Fecha, hora y responsable de la ejecución.
101
Análisis y evaluación: Se analizan los resultados obtenidos y en base a los
criterios establecidos en la planificación se determina lo siguiente:
• Condiciones de suceso de cada bug detectado.
• Severidad de cada bug.
• Aprobación o no de la prueba.
Por todo lo anterior podemos decir que las pruebas ayudan a elevar la calidad
del software, previniendo que los defectos pasen a los usuarios finales,
obviamente este proceso de pruebas no es gratuito y se le debe dedicar un
esfuerzo considerable a su implementación.
Este proceso de pruebas no es trivial y debe planificarse, controlarse y
asignarle recursos altamente calificados, porque cuanto antes se detecte un
defecto, más barato resultará su corrección.
La mejor aproximación a una estrategia de pruebas, es aquella que permite la
superposición de éstas con las actividades específicas de desarrollo.42
3.8 MEDICIÓN DE LA CALIDAD DEL SOFTWARE
Los modelos de la calidad del producto de software a menudo incluyen las
medidas para determinar el grado de cada característica de la calidad
alcanzada por el producto. Si dichos modelos son escogidos apropiadamente,
las medidas pueden sostener la calidad de software de múltiples maneras.
Estos modelos pueden ayudar en el proceso de toma de decisiones por parte
de la administración y pueden también encontrar áreas y embotellamientos
problemáticos dentro de las etapas del ciclo de vida del software; además
también pueden ayudar a los ingenieros de software a valorar la calidad de su
trabajo para propósitos de SQA(Aseguramiento de la Calidad del Software) y
para la mejora de la calidad de los procesos a largo plazo.
42 www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/calidad.htm
102
Con la sofisticación creciente del software, las preguntas de la calidad van más
allá de si o no los trabajos de software logran las metas mensurables de la
calidad.
Mientras que las medidas para características de calidad y características de
producto proporcionan datos generales como por ejemplo el número de
requisitos defectuosos o la proporción de requisitos defectuosos encontrados
en las pruebas, existen técnicas matemáticas y gráficas que se pueden aplicar
para ayudar en la interpretación de dichas medidas. Dichas técnicas se
clasifican de la siguiente manera:
Las que se basan en las estadísticas (por ejemplo, Análisis de Pareto, cartas
de funcionamiento, diagramas de la dispersión, distribución normal),las mismas
pruebas estadísticas por ejemplo, la prueba binomial, la predicción del análisis
de la tendencia de la prueba, por ejemplo, los modelos de la confiabilidad.
Actualmente la necesidad de medir es evidente en la mayoría de las
actividades ya sean técnicas o científicas. Sin embargo, no importa nada mas
contar con medidas sino también saber si dichas medidas son válidas y
efectivas. Para ello debemos recordar la definición de medición como el
"proceso por el cual se asignan números o símbolos a atributos de entidades
del mundo real de tal forma que los describa de acuerdo con reglas claramente
definidas" .43
La validez de la medición en cualquier disciplina técnica o científica se basa en
el respeto a los principios de la teoría general de la medición en concreto, la
llamada teoría representacional de la medición.
Esta idea es análoga a lo que se hace en matemáticas (por ejemplo, en
geometría) donde se definen una serie de axiomas básicos y, a partir de ellos,
se van estableciendo nuevas conclusiones.
43 Fenton y Pfleeger, 1997, p. 5, Mc Graw Hill.
103
El fundamento de la teoría representacional consiste en que toda medición
debe asegurar una adecuada representación del atributo real medido mediante
los símbolos o números asignados. Una representación por medición de un
atributo de una entidad es adecuada si es coherente con la idea conceptual
que sobre dicho atributo se tiene.
Así, los datos obtenidos como medidas deben representar los atributos de las
entidades reales que se pretenden caracterizar y el manejo de dichos datos
deben preservar las relaciones que existen entre dichas entidades. Para
establecer medidas se debe partir de la observación del mundo real o dominio.
Se deben identificar cuáles son las entidades que se van a medir por ejemplo el
código y definir qué atributo se desea caracterizar ejemplo de ello la longitud
del código. Además, es importante identificar las relaciones empíricas que se
pueden establecer entre las entidades reales en relación con el atributo que
interesa.
Estas relaciones pueden ser simples comparaciones que establecen un orden
por ejemplo el código de programas ‘X’ más largo que el del programa ‘y’ o
relaciones de otros tipos, ni siquiera binarias como la relación unaria al decir:
"el código de ‘X’ es largo". Se puede hablar entonces del dominio como de un
sistema de relaciones empíricas.
La medición asigna un valor a cada entidad para caracterizar su atributo y debe
establecer también que relación entre valores se corresponde con cada
relación. Lo importante es que la medición que se establezca no resulte
inconsistente con las relaciones observadas en el mundo real.
Hay que señalar que no siempre las ideas sobre los atributos o sobre las
relaciones empíricas están tan claras o no hay un consenso sobre ellas.
Podemos comenzar por simples valoraciones subjetivas por ejemplo el utilizar
cuestionarios donde se clasifican u ordenan las opiniones de los expertos sobre
un atributo y que no constituyen medidas desde el punto de vista de la teoría
104
de la representación pero que pueden ser analizadas para mejorar la
comprensión sobre el mundo real.
Es posible que tras acumular datos de este tipo se pueda llegar a definir una
medida formal. Por otra parte, debemos recordar que se podrían establecer
múltiples representaciones para un mismo sistema de relaciones empíricas
Una asignación que se establece entre el mundo real y valores de medida se
suele denominar escala de medición. Existen cinco tipos principales de
escalas de medición, las cuales son:
Nominal: simplemente se clasifica cada entidad grupos por ejemplo el código
en diversos lenguajes como COBOL, Basic, C, Java, etc.
Ordinal: se clasifican las entidades en grupos pero estableciendo un orden
De intervalo: establece un orden; además informa sobre que la diferencia
existente entre un valor y otro consecutivo en orden es siempre la misma por
ejemplo tiempo empleado: o días transcurridos desde el comienzo del proyecto.
De ratio: además de lo dicho para la escala de intervalo, tenemos un cero de
referencia como la longitud de código, el número de líneas de código.
Absoluta: además de lo dicho para la escala de ratio, se mide siempre
contando elementos y sólo es posible una representación, la cuenta real de
elementos como por ejemplo el número de personas en un proyecto sólo se
puede medir contándolas.
Estos tipos están presentados en orden creciente de sofisticación. Cuanto
más sofisticada es una escala, más operaciones o transformaciones permite
hacer sobre los valores obtenidos sin quebrar su validez de representación.
Lamentablemente la problemática actual es que a pesar de que pueda parecer
que existen suficientes conocimientos e información sobre este tema, lo cierto
es que todavía existe la necesidad de avanzar en los siguientes aspectos:
105
En la actualidad las propuestas de medidas no suelen tener en cuenta su
validación teórica. Por ello, es especialmente importante tanto que las nuevas
medidas sean analizadas y validadas desde el punto de vista teórico de la
medición además de realizar estudios sobre si las medidas ya existentes
respetan los principios básicos de la medición.
También resulta esencial avanzar en el establecimiento de propiedades
formales para cada atributo así como el estudio de otros atributos menos
conocidos para posibilitar en el futuro el establecimiento de métricas válidas. 44
3.8.1 MÉTRICAS DE LA DOCUMENTACIÓN DEL SOFTWARE
Como ocurre con la cuantificación de la calidad del software, la de un
documento también podría realizarse si se consigue identificar un conjunto
suficientemente representativo de variables de medida para ello.
En este sentido hay que diferenciar, por una parte, la medida de la calidad del
texto incluido en un documento, la calidad de la interfase del documento con el
usuario, la calidad de la estructura del documento, sobre todo en documentos
de hipertexto o hipermedia, y, por otro lado, la calidad de los diagramas o
modelos que aparecen en ellos como consecuencia de haber aplicado alguna
metodología de desarrollo de software.
En este último caso, el establecimiento de variables de medida es más sencillo,
pues vienen impuestas por la propia técnica de modelado, existiendo métricas
tanto para modelos estructurados como orientados a objetos.
La documentación del software puede considerarse un proceso de ingeniería y
también será susceptible de ser medida como proceso y como producto,
utilizando métricas similares a las empleadas en otras ingenierías.
44 www.abits.com.co/productos/lenguajes.asp
106
3.8.2 MÉTRICAS EN LA REUTILIZACIÓN ORIENTADA AL OBJETO
La reutilización del software se esta viendo como una de las mejores
aproximaciones para atajar la crisis del software antes mencionada y
especialmente como compañera inseparable del paradigma orientado a objetos
como una posible solución para dar respuesta a un mercado que exige
productos y servicios cada vez más fiables, baratos y entregados a tiempo.
Existen dos facetas básicas en la reutilización, el desarrollo para reutilización o
el desarrollo con reutilización. Ambas, aunque estrechamente relacionadas,
presentan características peculiares que involucran puntos de vista diversos
que se complementan, y que aún no están suficientemente investigados ni
desarrollados.
Se puede decir que la reutilización es un nuevo modelo de desarrollo de
software que requiere un entorno soportado por tecnología que aún no esta
madura, y un modelo de desarrollo que detalle cuando cómo y dónde reutilizar,
o cómo desarrollar el elemento para la reutilización. Desde esta perspectiva,
los repositorios son un paso más en el proceso para integrar la reutilización en
la ingeniería del software.
La investigación sobre modelos de métricas y validación de los mismos, forma
parte de la estructura que posibilitará que la reutilización se convierta en una
disciplina de ingeniería totalmente incorporada a la ingeniería del software.
3.8.3 CALIDAD Y MÉTRICAS VS. REUTILIZACIÓN
Un modelo de reutilización completo debe aglutinar las diversas vistas que se
tienen de la reutilización del software. De forma simplificada, debe comprender:
a)La vertiente técnica, en la que se recoge tanto el proceso de desarrollo y el
desarrollo para reutilización, y se acerca la reutilización a nuevos entornos
avanzados de desarrollo del software integrándola con herramientas
automáticas.
107
b)La vertiente de proceso, encargada de los aspectos de gestión y
metodología
c)La vertiente de cualificación y/o métricas, que comprende la política de
cualificación de los elementos reutilizables (assets) y de los procesos,
sustentada por las métricas adecuadas.
El proceso de desarrollo para el paradigma de Orientación al Objeto se
comporta de forma diferente al paradigma de desarrollo clásico, las fases de
análisis y diseño no están tan separadas; la diferencia es aún mayor si se
desarrolla con reutilización, pues ésta se encuentra incorporada en el
desarrollo OO a través de mecanismos inherentes al paradigma, como la
herencia.
Vamos a considerar algunos aspectos relevantes de la calidad y de las
métricas, desde el punto de vista de la reutilización, centrándonos en el
proceso y el producto.
PROCESO
El desarrollo de productos software con un alto valor de reutilización supondrá
un incremento de los costos, ya que esto resultará un valor añadido. El modelo
de costes que se utilice deberá incluir de una u otra forma parámetros que
reflejen ese valor añadido al producto. 45
En cuanto a los costos del desarrollo con reutilización se estiman un poco mas
elevados ya que éste es uno de los aspectos más conflictivos de la
reutilización. Los modelos de estimación de costos deberán diferenciar entre
elementos software que se desarrollan por completo y aquellos que se
reutilizan de manera parcial o total.
45 Karlsson, 1995, pp165-168] [Frakes, 1996.LIMUSA
108
En base a esto cabe esperar una reducción en los costos, pues desarrollar con
reutilización debe aumentar la productividad. Sin embargo no todos los autores
coinciden en este punto, según los beneficios de la reutilización hay que
buscarlos en la mejora de otros aspectos como calidad, fiabilidad, etc. y no en
los costos.
PRODUCTO
Las métricas servirán para reflejar y/o controlar, entre otros, la reusabilidad y
factores de calidad que sean de interés en el entorno de desarrollo para
reutilización. Es un hecho que las personas que juegan el papel de
desarrolladores para reutilización, deben poner el máximo interés para que los
assets que producen recuperen la inversión de tiempo y dinero a través de su
reutilización, y las métricas son un medio para cualificar los assets que están
produciendo.
Parece razonable pensar que un asset de baja fiabilidad no es un buen
candidato para reutilizar, en este caso los modelos y métricas de fiabilidad
jugarán un papel importante.
Uno de los soportes para la reutilización, que integra herramientas de
diferentes tipos actuando conjuntamente, es el repositorio. El papel jugado por
la administración de un repositorio no se limitará sólo a publicar y gestionar el
acceso a los assets recibidos.
También formará parte de ella un aspecto fundamental que es el de la
cualificación de los assets, de forma que un determinado asset para ser
considerado como tal deberá pasar por un proceso que lo cualifique o certifique
como elemento de valor y de calidad.
Las métricas del producto son parte de las herramientas a utilizar en este
proceso; y modelos como el FCM(Factor, Criterios, Métricas) o el
GQM(Objetivos, Cuestiones, Métricas), permitirán crear un marco en el que
deducir un conjunto de métricas asociadas a cada factor u objetivo de interés.
109
La explotación del repositorio, en el desarrollo con reutilización, permitirá
obtener información procedente de los usuarios, que puede dar lugar a
revisiones y ajustes en ese conjunto de métricas. El marco que proporcionan
los modelos bayesianos pueden facilitar algunos reajustes, considerando que
permiten realizar modificaciones en las estimaciones a priori, con la llegada de
nueva información. 46
En cualquier caso, se hace necesario el estudio de las propiedades que tienen
las métricas, tanto desde el punto de vista de la medición como desde el punto
de vista estadístico, el estudio de los modelos estadísticos que se utilizan, pues
todo ello permitirá:
• Decidir sobre la adecuación de las métricas o estadísticas y
• Seleccionar la mejor forma de explotar la información que proporcionan.
Así pues podemos decir que las métricas o mediciones ya sea para el proceso
de desarrollo de software, como para la documentación, como para
programación tradicional y orientada a objetos y ahora también dentro de la
creación de software para la reutilización son y serán instrumentos que nos
ayuden a tener una visión más amplia de cómo van y como salieron las cosas
al final del trabajo.
Existen muchos y variados métodos para medir, pero al final todos llegan a la
misma conclusión solo que siguiendo diferentes caminos. Muy probablemente
las métricas las entendamos mejor en el momento mismo de aplicarlas y
observar sus resultados, pero en este trabajo se muestra la información
necesaria para precisamente poder aplicarlas y sobre todo se indica el porque
de medir.
46 McClure, 1997, pp. 158-162, LIMUSA
110
CONCLUSIÓN
La calidad del software como ya hemos visto es un tema que ninguna empresa
puede dejar pasar desapercibida si es que quiere lograr crecer y vender su
producto, mucho mas ahora que vivimos en un mundo de competencia
excesiva en el que de cada producto hay 20 del mismo tipo y por lo que solo la
calidad de cada uno hace la diferencia para el cliente.
La calidad del software para mi, mas que una etapa dentro del ciclo de vida del
software es como un paso primordial dentro de cada etapa, es decir, cada nivel
del ciclo desde la definición del requerimiento hasta su mantenimiento debe
realizarse con una calidad total ya que de cada una de estas etapas dependerá
la entrega de un producto que cubra y satisfaga al máximo la necesidades y
exigencias del cliente.
Afortunadamente en la medida que crece la necesidad de generar dentro de
las empresas el concepto de calidad total también van surgiendo nuevos
modelos y metodologías que nos ayudan a generar un producto de calidad con
procesos de calidad con los cuales resulta más fácil cumplir los requisitos de
calidad que el producto exige.
La calidad es un proceso que puede definirse, implementarse, administrarse,
medirse y mantenerse, es por eso que actualmente escuchamos mucho
mencionar las normas de calidad, las certificaciones de calidad y los sellos de
calidad que le dan renombre a las empresas y por los cuales se enfocan tantos
esfuerzos en alcanzarla, estas revisiones son cada año y las certificaciones son
aproximadamente cada 3 años por lo tanto mientras mejores sean los procesos
de calidad de las empresas mejores y mas satisfactorias resultaran.
Por eso cuando en una organización se concibe el término de calidad total
como base del trabajo diario y se unen esfuerzos, tecnologías, procesos,
modelos, metodologías y revisiones adecuadas se estará entregando sin duda
un producto de calidad y con calidad que cubrirá las expectativas del cliente,
haciéndolo regresar y sobretodo la podrá recomendar otorgando un renombre y
un posicionamiento dentro de la industria.
111
BIBLIOGRAFÍA
CAPÍTULO 1
• PIATTINI, M.G. y GARCÍA F.O., Calidad en el desarrollo y
mantenimiento del software. Editorial Rústica, 344 Págs.
• Jesús M.ª Minguet Melián, , LA CALIDAD DEL SOFTWARE Y SU
MEDIDA
Editorial Universitaria Ramon Areces,264 páginas.
• Davor Gornik., IBM Rational Unified Process: Mejores práticas para los
equipos de desarrollo y calidad de Software Editorial IBM White
Paper.456 pags.
• Bevan, N., "Quality in Use: Meeting User Needs for Quality", Journal of
System and Software, páginas 89 - 96.
• Dustin, E., Rashka, J., and Mcdiarmid, D. ,Quality Web Systems:
Performance, Security, and Usability.
• www.eprints.rclis.org/archive/00002231/01/aci05395.htm
• www.calidaddelsoftware.com/
• www.ibm.com/software/info/ecatalog/es_ES/rational/SW730.html
• www.ingenierosoftware.com/calidad/
• www.software.net.mx/desarrolladores/prosoft/
• www.ingenierosoftware.com/calidad/cmm
• www.monografias.com/modelos/call/call.shtml
• www.monografias.com/trabajos16/calidad-sw-pymes/
• www.slideshare.net/pfsanchez/mejora-de-procesos
• www.ra-ma.es/indices/5446.htm
• www.idg.es/computerworld/articulo/calidad_prosoft
• www.inf.udec.cl/revista/ediciones/productosoftware/lmonsalve
• www.mena.com.mx/metrica_calprod/calidad/
• www.ideotechnologies.com/compania.html
• www.pcpymes.es/Actualidad/mejoras/Infraestructuras/Software
• www.agapea.com/Calidad-en-el-desarrollo-y-mantenimiento-del-software
• www.mityc.es/TI/Secciones/Calidad/NivelesCalidad/
112
• www.rincondelvago.com/control-de-calidad_ti13.html
• www.gestiopolis.com/canales/gerencial/TI_calidad
CAPÍTULO 2
• www.monografias.com/trabajos6/isof/isof.shtml
• www.infoforhealth.org/pr/prs/sj47/j47chap2_3.shtml
• www.sma.df.gob.mx/simat20/ponencias/sesion5/aseguramiento_y_contr
ol_calidadaire_retama.pdf
• www.elprisma.com/apuntes/curso.asp
• www.mgar.net/soc/isointro.htm
• www.gestiopolis.com/canales/gerencial/articulos/27/asesis.htm
• www.es.wikipedia.org/wiki/Sistema_de_control_de_calidad_de_software
• www.qualitrain.com.mx/index.php
• www.emagister.com/gestion-certificacion-calidad-software-sistemas-
criticos-aeronautica-espacio-cursos-2467459.htm
• www.emagister.com/calidad-software-tps-963351.htm
• www.is.ls.fi.upm.es/udis/docencia/erdsi/Documentacion-Evaluacion-6.pdf
• www.eprints.rclis.org/archive/00002231/01/aci05395.htm
• www.lisi.usb.ve/publicaciones/
• www.inei.gob.pe/web/metodologias/attach/lib608/cap10-3.htm
• www.acuavalle.gov.co/docs/contratacion/EVALYCALIFTECNICAModern
Software25Sp07.pdf
• www.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/DIEZ-
INSPECCIONES.pdf
• www.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/DIEZ-
INSPECCIONES.pdf
• www.samsistemas.com.ar/servicios_especiales/auditoriadesoftware.html
• www.emagister.com/auditoria-calidad-software-tps-1413086.htm
113
CAPÍTULO 3
• www.ewh.ieee.org/reg/9/etrans/vol4issue2April2006/4TLA2_6Davila.pdf
• www.monografias.com/trabajos6/resof/resof.shtml
• www.qualitrain.com.mx/procesos/out_req.php
• www.ingenierosoftware.com/calidad/cmm-cmmi-nivel-2.php
• www.alarcos./doc/ISOFTWAREI/rodolfo.pdf
• www.planetacodigo.com/wiki/glosario:nivel_de_integridad
• www.infor.uva.es/manso/calidad/Cuestionesmedicion.pdf
• www.dcc.uchile.cl/web/article-15878.html
• www.portal.educ.ar/noticias/educacion-y-sociedad/metodos-y-tecnicas-
de-aseguram.php
• www.sqs.es/es/
• www.usabilidadweb.com.ar/metodos_eval_calidad_web.php
• www.grupocobos.com.mx/zrc/pruebas.htm
• www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/calidad.htm
• www.abits.com.co/productos/lenguajes.asp
• www.grupocolumbia.com/frame_prueba.htm
• www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-
software
• www.um.es/informatica/estudios/programas/ITIG/06BE.pdf
• www.estrasol.com.mx/acl.php
• www.giro.infor.uva.es/Publications/2004/MLC04/JENUI2004.pdf
• www.wikipedia.org/wiki/Pruebas_de_software
• www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-
software.shtml
• www.pruebasdesoftware.com
• www.iti.upv.es/services/formacion/cursos/list/espec_testeo
• www.sc.ehu.es/jiwdocoj/remis/docs/mmg-2000.ppt
• www.oei.eui.upm.es/Asignaturas/PInformaticos/ficheros/transparencias
• www.sc.ehu.es/jiwdocoj/remis/docs/mmg-2000.ppt
• www.inei.gob.pe/biblioineipub/bancopub/inf/Lib5042/cap20.htm
