O15 I

IMPACTO DE LAS PRUEBAS NO FUNCIONALES EN LA MEDICIÓN DE LA
CALIDAD DEL PRODUCTO SOFTWARE DESARROLLADO
ALEJANDRO OCAMPO ACOSTA

LUISA MARCELA CORREA TAPASCO
UNIVERSIDAD TECNOLÓGICA DE PEREIRA

FACULTAD DE INGENIERÍAS ELÉCTRICA, ELECTRÓNICA, FÍSICA Y
CIENCIAS DE LA COMPUTACION
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
PEREIRA
2011
1
IMPACTO DE LAS PRUEBAS NO FUNCIONALES EN LA MEDICIÓN DE LA
CALIDAD DEL PRODUCTO SOFTWARE DESARROLLADO
ALEJANDRO OCAMPO ACOSTA

LUISA MARCELA CORREA TAPASCO
Monografía para optar al título de Ingeniero de Sistemas y Computación
Asesor
Ph.D. JULIO CESAR CHAVARRO
Docente
UNIVERSIDAD TECNOLÓGICA DE PEREIRA

FACULTAD DE INGENIERÍAS ELÉCTRICA, ELECTRÓNICA, FÍSICA Y
CIENCIAS DE LA COMPUTACION
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
PEREIRA
2011
2
Nota de aceptación
________________________________
________________________________
________________________________
________________________________
________________________________
________________________________
Presidente del Jurado
________________________________
Jurado
________________________________
Jurado
Pereira, Octubre de 2011
3
CONTENIDO
pág.
INTRODUCCION. .................................................................................................. 10
1. EL PROBLEMA OBJETO DE ESTUDIO. GENERALIDADES ........................... 11
1.1 DEFINICIÓN DEL PROBLEMA ....................................................................... 11
1.2 JUSTIFICACIÓN .............................................................................................. 13
1.3 OBJETIVOS ..................................................................................................... 14
1.3.1 Objetivo general ........................................................................................... 14
1.3.2 Objetivos específicos .................................................................................... 15
1.4 MARCO CONCEPTUAL .................................................................................. 15
1.4.1 Calidad del software ..................................................................................... 15
1.4.2 Ciclo de vida del software ............................................................................. 15
1.4.3 Procesos ....................................................................................................... 15
1.4.4 Pruebas no funcionales ................................................................................ 16
1.4.5 Verificación de software ................................................................................ 16
1.4.6 Validación de Software ................................................................................. 16
1.4.7 CMMI (Capability Maturity Model Integration). .............................................. 16
1.4.8 Scampi .......................................................................................................... 16
1.4.9 IT-Mark.......................................................................................................... 17
1.4.10 ISO 9001 ..................................................................................................... 17
1.4.11 ITIL .............................................................................................................. 17
1.4.12 MoProSoft ................................................................................................... 17
1.4.13 Probar software ........................................................................................... 18
1.4.14 Depurar software ........................................................................................ 18
1.4.15 No conformidad y/o hallazgo ....................................................................... 18
1.4.16 Pruebas funcionales. .................................................................................. 18
4
1.4.17 Pruebas no funcionales............................................................................... 19
1.5 MARCO TEÓRICO .......................................................................................... 19
1.6 MARCO HISTÓRICO ....................................................................................... 21
1.6.1 Empresas colombianas de Testing ............................................................... 21
2. LAS PRUEBAS NO FUNCIONALES. ................................................................ 24
2.1 CARÁCTER DE LAS PRUEBAS NO FUNCIONALES .................................... 24
2.1.1 Estándares relacionados con las pruebas de software ................................. 24
2.1.2 Ingeniería de requerimientos ........................................................................ 25
2.1.3 Estrategias de pruebas de software en general ............................................ 33
2.1.4 Descripción del proceso de pruebas no funcionales. .................................. 34
2.1.5 Desarrollo de caso de prueba ....................................................................... 39
3. MÉTODOS DE PRUEBAS. ................................................................................ 41
3.1 MÉTODOS ESTÁTICOS.................................................................................. 42
3.1.1 Inspecciones ................................................................................................. 42
3.1.2 Walkthroughs ................................................................................................ 44
3.2 MÉTODOS DINÁMICOS.................................................................................. 44
3.2.1 Pruebas de unidad. ....................................................................................... 45
3.2.2 Pruebas de integración ................................................................................. 45
3.2.3 Pruebas de sistema. ..................................................................................... 46
3.3 ATRIBUTOS DE CALIDAD DEL SOFTWARE QUE SON EVALUABLES AL
APLICAR PRUEBAS NO FUNCIONALES ............................................................. 47
3.3.1 Características evaluables del requerimiento de Fiabilidad ......................... 50
3.3.2 Características evaluables del requerimiento de Portabilidad...................... 51
3.3.3 Características evaluables del requerimiento de Eficiencia ......................... 52
3.3.4 Características evaluables del requerimiento de Mantenibilidad ................. 53
3.3.5 Características evaluables del requerimiento de Usabilidad ........................ 54
3.4 ANÁLISIS DEL PAPEL ASIGNADO A LAS PRUEBAS NO FUNCIONALES EN
LAS METODOLOGÍAS ÁGILES Y EN LAS METODOLOGÍAS TRADICIONALES.
............................................................................................................................... 62
5
3.4.1 Pruebas no funcionales según Metodologías ágiles. .................................... 62
3.4.2 Pruebas no funcionales según metodologías tradicionales .......................... 65
3.4.3 Metodología de pruebas en V ....................................................................... 68
4. METRICAS PROPUESTAS PARA LA MEDICIÓN DE LOS REQUERIMIENTOS
NO FUNCIONALES. .............................................................................................. 70
4.1 RECOPILACIÓN DE MÉTRICAS PARA ATRIBUTOS DE CALIDAD VISTOS
COMO REQUERIMIENTOS NO FUNCIONALES ................................................. 70
4.2 MÉTRICAS PARA VALIDAR LOS REQUISITOS NO FUNCIONALES ........... 73
4.2.1Usabilidad. ..................................................................................................... 73
4.2.2 Fiabilidad....................................................................................................... 74
4.2.3 Portabilidad ................................................................................................... 75
4.2.4 Mantenibilidad ............................................................................................... 75
4.3 PROPUESTA DEL MÉTODO DE EVALUACIÓN DE LOS REQUERIMIENTOS
NO FUNCIONALES. .............................................................................................. 76
4.3.1 Fase 1. Levantamiento de requerimientos. ................................................... 76
4.3.2 Fase 2. Análisis ............................................................................................. 77
4.3.3 Fase 3. Diseño .............................................................................................. 78
4.3.4 Fase 4. Implementación ................................................................................ 79
4.4 DEFINICIÓN DEL MÉTODO DE EVALUACIÓN. ............................................. 80
4.4.1 Roles y responsabilidades ............................................................................ 80
4.4.2 Planificación de las pruebas ......................................................................... 81
4.4.3 Diseño de las pruebas .................................................................................. 82
4.4.4 Ejecución de las pruebas. ............................................................................. 83
4.4.5 Análisis de los resultados.............................................................................. 83
4.4.6 Validar criterios de aceptación ...................................................................... 83
4.4.7 Certificación ................................................................................................. 83
4.5 AUTOMATIZACIÓN DE PRUEBAS A ATRIBUTOS NO FUNCIONALES,
USANDO HERRAMIENTAS PARA LA EVALUACIÓN DE LOS ATRIBUTOS ..... 84
5. CONCLUSIONES Y RECOMENDACIONES. ................................................... 87
6
BIBLIOGRAFÍA ...................................................................................................... 89
7
LISTA DE TABLAS
pág.
Tabla 1.Requerimientos funcionales y no funcionales ........................................... 28
Tabla 2. Restricciones. .......................................................................................... 28
Tabla 3. Estándar de la IEEE 829-1983................................................................. 36
Tabla 4. Plantilla recomendada para caso de prueba. ........................................... 40
Tabla 5. Niveles de pruebas. ................................................................................. 42
Tabla 6. RFN fiabilidad. ......................................................................................... 50
Tabla 7. RFN portabilidad ...................................................................................... 51
Tabla 8. RFN eficiencia. ......................................................................................... 52
Tabla 9. RFN Mantenibilidad.................................................................................. 54
Tabla 10. RFN Usabilidad. ..................................................................................... 55
Tabla 11. Esquema general de las listas de chequeo modificadas. ....................... 60
Tabla 12. Tareas y artefactos de usabilidad propuestos. ....................................... 61
Tabla 13. Diferencias entre metodologías ágiles y metodologías tradicionales. .... 63
Tabla 14. Atributos de calidad fragmentados en características. ........................... 72
Tabla 15. Esquema general de las listas de chequeo modificadas. ....................... 74
Tabla 16. Modelo de caos de uso para requerimientos no funcionales. ................ 79
Tabla 17. Herramientas. ........................................................................................ 84
8
LISTA DE FIGURAS
Pág.
Figura 1. Tipos de requerimientos. ........................................................................ 27
Figura 2.Tipos de requerimientos de software. ...................................................... 27
Figura 3. Categorías de requerimientos no funcionales. ........................................ 29
Figura 4. Tipos de requerimientos no funcionales y sus categorías. ..................... 30
Figura 5. Ciclo de vida del desarrollo de software. ................................................ 31
Figura 6. Estrategias de pruebas. .......................................................................... 34
Figura 7. Jerarquía de requisitos no funcionales. .................................................. 48
Figura 8. ISO/IEC 9126. ......................................................................................... 48
Figura 9. Iteraciones de RUP ................................................................................. 67
Figura 10. Miembros del equipo de RUP. .............................................................. 67
Figura 11. Relaciones entre productos de desarrollo y niveles de prueba. ............ 68
Figura 12. Método propuesto para la evaluación de los atributos no funcionales. . 81
9
INTRODUCCION.
En los últimos años, el incremento constante del software desarrollado en

Colombia, y la necesidad de mejorar su calidad, ha conllevado la necesidad de
utilizar una serie de estándares y procesos para mejorar la calidad de este. Sin
embargo, muchas empresas no han tenido en cuenta estos estándares o
procesos de mejora hacia la calidad, haciendo que sus productos sean deficientes
y muy costosos; es por ello que existe la necesidad de establecer unos procesos
de pruebas no funcionales en el software haciendo de ello un producto confiable,
usable y de alta calidad.
Una de las características que se tienen en los procesos de las pruebas no

funcionales, es la de encontrar errores en la realización de una aplicación para
luego poder corregirlos en las etapas del ciclo de vida antes de salir al mercado,
logrando un acercamiento a un software de buena calidad y reducir costos en
estos.
Para la realización de este material monográfico se analizaron varios estándares

de niveles pruebas no funcionales, aplicados a las metodologías agiles y robustas
durante las etapas de desarrollo. También se observaron las diferentes
herramientas a utilizar durante cada requerimiento no funcional que se tiene.
El interés de la realización monográfica es brindar una orientación, a las

organizaciones desarrolladoras de software, en la realización de pruebas no
funcionales, debido a que los diferentes problemas que surgen por no realizar
estas antes de salir a producción, puede ser muy costoso. En el mundo del
software, la importancia que se le debe dar las pruebas no funcionales en el
desarrollo es vital, porque con estas se genera confiabilidad, seguridad y lo mejor
de todo: hasta se pueden salvar vidas!
10
1. EL PROBLEMA OBJETO DE ESTUDIO. GENERALIDADES.
1.1 DEFINICIÓN DEL PROBLEMA
La industria del software en Colombia es un sector joven, si se encuadra en las

organizaciones que se dedican a la investigación, desarrollo y comercialización de
software; por ser tan joven es inmaduro pero en constante evolución y en
búsqueda de mejorar continuamente.
Dichas formas de mejoramiento, son entre tanto no solo los modelos de mejora
de proceso disponibles, sino además que se encuentren al alcance financiero de
la empresa, o se halla también a través de adopciones de buenas prácticas de
desarrollo, sin la supervisión de alguna entidad autorizada para certificarles los
avances de mejora realizados, o a través de los apoyos que proporciona el
gobierno por medio del Ministerio de Tecnologías de la Información y las
comunicaciones.
Debido a la gran desarticulación entre las federaciones y el estado, no se tienen

cifras exactas acerca de la cantidad de casas desarrolladoras en Colombia, sin
embargo, según el DANE1 en el país existen ―más de 650 empresas de desarrollo
de software‖2, de las cuales en la región cafetera se cuenta con ―48 empresas
legalmente establecidas en las cámaras de comercio respectivas, 20 en la ciudad
de Manizales, 16 en Pereira y 12 en Armenia‖ 3, sin tener en cuenta las que
ingresaron al gremio el año inmediatamente anterior.
Es el constante surgimiento de nuevas empresas, el que exige a las

organizaciones que ya se encuentran en dicho segmento, que se preocupen por
mejorar la calidad de su producto. Adicionalmente, deben enfocar sus esfuerzos
en garantizar cumplimiento en la entrega del producto, respetando los tiempos
establecidos y precios, y es el factor del tiempo de entrega – Time to market, por
el cual las organizaciones priorizan el desarrollo del software sobre la calidad, ya
que además no tienen en cuenta la aplicación de pruebas a lo largo del proceso
1
Departamento Administrativo Nacional de Estadística
2
HESHUSIUS RODRÍGUEZ, Karen, Desafíos de una industria en formación. Mayol Ediciones.2009.293p.
ISBN 978-958-8307-56.
3
CUESTA MEZA, Albeiro. Caracterización de la industria del software en el triangulo del café-Colombia.Madrid.2008.9P.
11
de desarrollo del producto software, por ende, olvidan también las pruebas no
funcionales.
Las fábricas de software del país, no sólo se enfrentan contra su propios
parámetros establecidos para sus proyectos de desarrollo, como lo es tiempo, el
precio final, entre otros, sino que además, deben enfrentar al mercado respectivo,
el cual exige ser competitivo debido a la globalización.
Es por lo anterior que las actuales empresas del gremio, deben contar con un alto
grado de especialización en sus funciones, lo cual han logrado en el país ―130
empresas mediante la certificación ISO 9000, una empresa con certificación
CMMI categoría V y otras cinco están en proceso de obtener esta certificación‖4,
datos correspondientes al 2006.
Se puede entonces inferir, que un porcentaje menor a la cuarta parte del total de
las casas desarrolladores de software existentes en el país, realizan un proceso
completo para desarrollar su producto con calidad. Se exceptúan aquellas que
sólo cuentan con certificación ISO 9000, ya que esto no garantiza que se lleve a
cabo el proceso formal de aplicación de pruebas, tanto funcionales como no
funcionales. Finalmente, la ISO 9000 no garantiza que se aporte a la calidad del
producto desarrollado, por el contrario si garantiza, que se realiza una gestión en
el proceso de desarrollo con calidad.
En la actualidad la realización de pruebas no funcionales, como lo son usabilidad,

estabilidad, escalabilidad, eficiencia, seguridad, permiten la evaluación y medición
de la calidad del software. Si se tiene en cuenta que por muy alto que sea el nivel
funcional del software desarrollado, si la aplicación no es funcional, simplemente
será inútil, sin embargo siendo tan importantes, no son aplicadas ya que se
prioriza el desarrollo del producto, buscando cumplir con las entregas y minimizar
costos por retrasos, pero esto luego se revierte con el tiempo, ya que el error
hallado en producción es más costoso que el hallado en un ambiente controlado.
Ante lo antes expuesto, se ha planteado un problema de investigación el cual se

buscará responder con éste proyecto:
4
ISBN 978-958-8307-56.
12
¿Es posible determinar el conjunto de características de los requerimientos no
funcionales que permitan mejorar la calidad del software, al aplicar pruebas no
funcionales?
1.2 JUSTIFICACIÓN
Colombia alcanzó una tasa de crecimiento del 48%, en el mercado del software
latinoamericano, entre el 2000 y el 2004. Y de acuerdo con las estadísticas
ofrecidas por el DANE entre 1995 y el 2004 se duplicó el número de empresas
dedicadas al desarrollo de Software. Esto afirma el incremento desmesurado de
casas desarrolladoras de software tanto a nivel regional, como nacional.
Lo antes mencionado es un incentivo hacia mejorar el nivel de la calidad del

software desarrollado, ya que es lamentable y tan común, encontrar que las
empresas priorizan distintos factores para el desarrollo de un producto software
frente a la calidad del mismo, todo ello por no perder sus objetivos planteados
inicialmente en un proyecto de desarrollo software, puesto que buscan responder
a los clientes con el producto solicitado, aún a costa de la calidad del mismo.
En otros casos no concluyen con éxito los proyectos contratados en el tiempo

estipulado. Lo anterior se afirma con base en los informes ―CHAOS‖ del Standish
Group, quienes periódicamente evalúan el sector, en su reporte de 2010, en el
que se concluye que ha ocurrido un retroceso en éste campo, con respecto a años
anteriores, puesto que se halló que ―sólo el 32% de los proyectos son exitosos, y
el 44% están comprometidos por el presupuesto, esfuerzo o fechas y el 24% de
los proyectos son cancelados‖.
En el país la industria del software tiene una tendencia exponencial donde a mayor
tiempo, mayor cantidad de proveedores software, y de igual forma se incrementa
la cantidad de consumidores, los cuales cada vez requieren productos con
características más complejas, las cuales se traducen en condiciones críticas del
software, al ser productos innovadores.
Al requerir productos a la medida se incrementa la probabilidad de que se

presenten fallas, errores en el sistema, lo cual ratifica, la importancia de la
definición, evaluación y medición del software, aplicando en su proceso de
desarrollo, las pruebas no funcionales.
13
Se busca entonces establecer un instrumento teórico que permita a las
organizaciones del segmento de mercado afectado, la orientación hacia la mejora
de la calidad, mediante la aplicación de pruebas no funcionales, si se tiene en
cuenta que ―la única estrategia posible para el proveedor es conseguir la calidad
solicitada al menor coste posible‖5, para lograr ser competitivos en el mercado, ya
que la calidad en el software, aunque es tomada como trascendental y evidente
que exista en los productos desarrollados, y su grado de importancia es tan alto,
que efectivamente se logre afectar cada acción de la vida moderna.
Tal es el efecto de importancia que ha causado el software en Colombia, que ha

llegado a ser parte de los sectores que el estado impulsa para el desarrollo y
crecimiento del país. Y es así como se debe impulsar y buscar también que las
empresas empiecen a incluir en su proceso de desarrollo de software,
metodologías de aplicación de pruebas no funcionales, logrando así, dar valor
agregado al producto software y enfocado hacia mejorar el nivel de calidad del
mismo, y alcanzando los beneficios de éste, como lo es minimizar la ocurrencia de
un error o un fallo en producción, lo cual se representa en minimización de los
costos del error en producción.
Teniendo en cuenta las dificultades antes planteadas, se busca en este proyecto,

desarrollar una monografía, que permita servir de base u objeto de argumentación
para enfatizar hacia la implementación de pruebas no funcionales, de tal forma
que las empresas de software de la región se sientan motivadas, hacia la
adopción del proceso de pruebas no funcionales, comprendiendo sus impactos
hacia la mejora de la calidad en sus productos software.
1.3 OBJETIVOS
1.3.1 Objetivo general
Establecer un referente conceptual y teórico de los requerimientos no funcionales

que aportan a la calidad del producto software del proceso de pruebas
correspondientes
5
PIATTINI VELTHUIS, MARIO G. Calidad de Sistemas Informáticos. ISBN 978-84-7897-734-5
14
1.3.2 Objetivos específicos
- Establecer un análisis comparativo del tratamiento que cada metodología otorga

a los requerimientos no funcionales
- Definir un modelo de medición para los requerimientos no funcionales que

afectan la calidad del software desarrollado.
- Proponer un método de evaluación de los requerimientos no funcionales,

orientado a fortalecer la calidad del producto de software que se desarrolla, de
manera independiente de la metodología.
1.4 MARCO CONCEPTUAL
1.4.1 Calidad del software. Es el grado con el que un sistema, componente o

proceso cumple los requerimientos especificados y las necesidades o expectativas
del cliente o usuario.
1.4.2 Ciclo de vida del software. Un modelo de ciclo de vida software es cualquier
caracterización descriptiva de la evolución del software. Es sencillo articular un
modelo de ciclo de vida que indique cómo deben ser desarrollados los sistemas
software. Esto es posible ya que la mayor parte de los modelos son intuitivos, por
lo que muchos detalles de desarrollo pueden ser ignorados o generalizados. Sin
embargo, puede preocupar la relativa validez y robustez de tales ciclos de vida
cuando se desarrollan diferentes clases de aplicaciones en diferentes entornos de
desarrollo."Hay que observar o recoger datos durante todo el proceso de
desarrollo de un sistema; periodo de tiempo que suele medirse en años‖.
1.4.3 Procesos. El proceso ayuda a los miembros de una organización a alcanzar

los objetivos estratégicos ayudando a trabajar más inteligentemente, no más duro,
y de un modo más consistente. Los procesos eficaces también proporcionan un
medio para introducir y utilizar nuevas tecnologías de forma que permitan
responder mejor a los objetivos estratégicos de la organización. Un proceso de
software proporciona la estructura desde la que se puede establecer un detallado
plan para el desarrollo del software.
15
1.4.4 Pruebas no funcionales. Éstas se realizan para verificar que el software
desarrollado cumple con los requerimientos no funcionales establecidos por el
cliente. Existen varios tipos de pruebas no funcionales, entre las más comunes
están las pruebas de seguridad, pruebas de rendimiento, pruebas de usabilidad,
pruebas de portabilidad, entre otras.
1.4.5 Verificación de software. Técnica y actividad ligada al control de calidad del

software se trata de comprobar si los productos construidos en una fase de ciclo
de vida satisfacen los requisitos establecidos en una fase anterior y/o si el
software construido satisface los requisitos del usuario.
1.4.6 Validación de Software. Técnica y actividad ligada al control de calidad del

software se trata de comprobar si los productos construidos en una fase de ciclo
de vida, funciona como el usuario quiere y realiza las funciones que se habían
solicitado.
1.4.7 CMMI (Capability Maturity Model Integration). Modelo de madurez de

mejora de los procesos para el desarrollo de productos y de servicios. Consiste en
las mejores prácticas que tratan las actividades de desarrollo y de mantenimiento
que cubren el ciclo de vida del producto, desde la concepción a la entrega y el
mantenimiento.
El propósito de CMMI para desarrollo es ayudar a las organizaciones a mejorar

sus procesos de desarrollo y de mantenimiento, tanto para los productos como
para los servicios.
Las categorías de las áreas de proceso de CMMI son gestión de procesos, gestión
de proyectos, ingeniería y soporte.
1.4.8 Scampi. El método SCAMPI se utiliza para la evaluación de las

organizaciones que usan CMMI, y un resultado de una evaluación es una
calificación [Ahern 2005]. Si en una evaluación se usa la representación continua,
la calificación es un perfil de nivel de capacidad. Si en una evaluación se usa la
representación por etapas, la calificación es un nivel de madurez (p.ej., nivel de
madurez 3).
16
Los métodos de evaluación SCAMPI son generalmente métodos aceptados que
se usan para realizar evaluaciones utilizando modelos CMMI. El Documento de
definición del método —Method Definition Document (MDD) de SCAMPI— define
las reglas para asegurar la consistencia de las calificaciones de la evaluación.
1.4.9 IT-Mark. Su objetivo es brindar un sello de calidad para pequeñas y

medianas empresas de Tecnologías de la Información, que acredita su madurez y
capacidad.
También tiene como objetivo mejorar la efectividad organizacional y el éxito en el

mercado mediante la mejora de sus procesos. El servicio proporciona
conocimiento sobre las capacidades técnicas y gerenciales de la organización a
través de la identificación de fortalezas y debilidades, así como del descubrimiento
áreas a mejorar de acuerdo con sus metas de negocio. 6
1.4.10 ISO 9001. es una norma internacional que se aplica a los sistemas de
gestión de calidad (SGC) y que se centra en todos los elementos de
administración de calidad con los que una empresa debe contar para tener un
sistema efectivo que le permita administrar y mejorar la calidad de sus productos o
servicios.7
1.4.11 ITIL. es un conjunto de conceptos y prácticas para la gestión de servicios

de tecnologías de la información. ITIL da descripciones detalladas de un extenso
conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a
lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son
independientes del proveedor y han sido desarrollados para servir como guía que
abarque toda infraestructura, desarrollo y operaciones de TI.
1.4.12 MoProSoft. es un modelo de procesos para la industria de software

nacional de México promovido por la Secretaría de Economía, que fomenta la
estandarización de la operación a través de la incorporación de las mejores
prácticas en gestión e ingeniería de software. La adopción del modelo permite
elevar la madurez de los procesos para las organizaciones que desarrollan y/o
6
Resumen modelo IT-Mark web-http://www.fedesoft.org/downloads/Sinertic/RESUMEN_MODELO_IT_MARK.pdf
7
Normas ISO 9000. Web-http://www.normas9000.com/index.html
17
mantienen software para ofrecer servicios con calidad y alcanzar niveles
internacionales de competitividad. 8
1.4.13 Probar software. Determinar la existencia de errores, defectos o fallas en

el software.
1.4.14 Depurar software: Detectar el lugar donde existe el error, por consiguiente
su eliminación de su origen.
1.4.15 No conformidad y/o hallazgo. Es una desviación de los resultados

esperados, en otras palabras, es un error, defecto o falla que va más allá del
alcance de las pruebas ejecutadas. Se categorizan de la siguiente forma:
- ―Bloqueantes: Es el tipo de no conformidad que detiene la operación de un

programa/componente o hace que este arroje resultados que impiden la
continuidad de la operación del cliente.
- Funcionales: Es el tipo de no conformidad que se presenta cuando al ejecutar

una opción particular del sistema creada para dar solución a un requerimiento
funcional, no se evidencia que el requerimiento se solucione.
- Presentación: Son no conformidades relacionadas con la presentación de los

resultados en la ejecución de una opción del sistema. Estos deben ajustarse a los
estándares definidos y con las reglas gramaticales y ortográficas del idioma en
que es presentada la solución‖9.
1.4.16 Pruebas funcionales. Aquellas evaluaciones que se realizan sobre la

ejecución de funcionalidades del sistema, verificando la existencia de errores,
defectos o fallas en la solución software comparándola frente a los requerimientos
funcionales.
8
Moprosoft web-http://moprosoft.info/Quees.aspx
9
Manual de procedimientos Aseguramiento de calidad del software. Web-http://procesos.univalle.edu.co. Mayo 2009
18
1.4.17 Pruebas no funcionales. Aquellas evaluaciones que se realizan sobre los
elementos que están ―presentes en los resultados de la ejecución de
10
funcionalidades del sistema‖ .
1.5 MARCO TEÓRICO
Las fábricas de software a lo largo de la historia se ha visto y aún lo hacen, deben

estar enfrentándose continuamente a diversos factores económicos, sociales, de
entorno, entre otros, que afectan su razón de social o razón de ser, como lo es el
entregar un producto software desarrollado a la medida, por lo tanto afectando la
calidad del producto elaborado. Cabe mencionar que dichas causas o problemas
que se presentan al desarrollar un producto software son los siguientes:
- Requisitos mal gestionados

- Comunicación ambigua e imprecisa en el equipo
- Arquitectura frágil superficial
- Complejidad impresionante
- Inconsistencia entre requisitos, diseño e implementación
- Insuficientes pruebas
- Estimación subjetiva
- Proceso de desarrollo en cascada
- Falta de gestión en la configuración
- Ausencia de herramientas de apoyo
- No planificar y medir el alcance del proyecto
Lo anterior es sólo una muestra de aquellas causas que provocan que la eficiencia
y eficacia de las organizaciones desarrolladoras de software, no se alcancen,
además de no permitir una conclusión con éxito de sus proyectos propuestos, y
que finalmente terminen siendo una pérdida, tanto en presupuesto, como en
tiempo tanto por parte del cliente como de la empresa.
Afortunadamente en la actualidad el enfoque de algunas fábricas desarrolladoras

de software, es hacia el mejoramiento continuo en el proceso, sin embargo, el
tema no está tan difundido entre las mismas.
10
Manual de procedimientos Aseguramiento de calidad del software. Web-http://procesos.univalle.edu.co. Mayo 2009
19
Con base al artículo del The Economic Times, ―Testing becoming the fastes –
growing niche within the IT space‖11, en el que se confirma que las actividades del
desarrollo de pruebas están en continuo crecimiento y que además permite
avanzar hacia la calidad en los productos software.
Y aún más interesante es conocer la opinión de las organizaciones con

experiencia en tecnología, las cuales opinan según este artículo, que los jóvenes
están enfocando sus intereses hacia las carreras de ―testing‖, como también que
se encuentran con compañías que enfocan sus esfuerzos hacia capacitar sus
profesionales en ésta rama, ya que en el mercado no se encuentran profesionales
con éstos conocimientos.
El director de Sistemas Maveric, Ranga Reddy, comenta que el giro que ha dado
el proceso de pruebas sobre el desarrollo software, ha sido drástico, ya que se
afecta de forma positiva el tema presupuestal específicamente. Es decir que las
compañías de tecnología, se están orientando hacia mejorar la calidad de sus
productos software, incluyendo el proceso de pruebas dentro de su estructura
organizacional.
En concordancia con lo anterior, en 2006 según Fedesoft, ―sólo el 10% de las

empresas locales‖12 lograron incursionar en mercados internacionales, puesto que
cumplieron con las normas internacionales de calidad, lo cual pocas fábricas de
software alcanzaron. Es por ello que se motiva hacia la implementación de
procesos que estén enfocados hacia la mejora continua de la calidad del software.
Cabe entonces destacar la importancia del desarrollo de pruebas software, puesto

que con el mismo se busca dar un apoyo para disminuir el riesgo de ocurrencia de
fallos y presencia de errores en producción. Adicionalmente se está disminuyendo
la presencia del usuario a lo largo del desarrollo, ya que al implementar pruebas
software, no será necesario estar solicitando al cliente su apoyo en probar, o su
opinión de si el software está sobre el camino correcto o incorrecto.
Finalmente, el no cumplimiento de un requerimiento no funcional puede llegar a

que un sistema entero sea inutilizable, ya sea porque este no es fiable, colocando
12
ISBN 978-958-8307-56.
20
en riesgo a la empresa o personas, un ejemplo de ello es el software realizado
para los aviones, el cual sino es confiable expone la vida de la clientes que viajan,
es por esto que las pruebas no funcionales son parte importante en el calidad del
software, donde se busca explotar al máximo los beneficios de la aplicación y no
se incremente su costo.
1.6 MARCO HISTÓRICO
La calidad del software afecta no solamente al cliente y al proveedor del producto,

sino también a la sociedad.
La producción de software inicia, y se convierte en negocio rentable, sin embargo,

es entonces cuando se hace necesario tener estándares de calidad para conocer
si el producto que se está recibiendo cumple con los requerimientos y atributos de
calidad.
Debido a la creciente automatización y por ende, su presencia tanto en sistemas

de navegación de los submarinos, los sistemas de radiación médicos, software
para diagnósticos de médicos, gestión de semáforos, las telecomunicaciones del
planeta entero, entre otras innumerables aplicaciones, es decir, que los sistemas
a los cuales se expone no a una sola persona, sino millones. Es por ello que un
error en producción, provoca no sólo pérdidas millonarias, sino también puede
afectar cantidad de vidas humanas, y animales. Por lo tanto al realizar pruebas no
sólo disminuye el riesgo de ocurrencia de errores, sino también mejora la
arquitectura, diseño, y adicionalmente incrementa el tiempo de vida del software
desarrollado, puesto que proporciona facilidad de mantenimiento.
1.6.1 Empresas colombianas de Testing
- Choucair Testing S.A. ―Su servicio se realiza de forma paralela a las diferentes
etapas de desarrollo de software y comprende pruebas funcionales, de
rendimiento, de seguridad en aplicativos y de migración de datos‖13.
13
Ventana informática. Pruebas de software y gestión documental. Julio 2009. 200p. ISSN 0123 – 9678.
21
- Green SQA. ―Ofrece servicios de Pruebas de Software, Aseguramiento de
Calidad y Consultoría a la industria del software, contribuyendo al aumento de la
productividad y competitividad de las empresas mediante la optimización de sus
procesos de desarrollo.
Brindan acompañamiento en el desarrollo y/o mantenimiento de aplicaciones, así

como en la implementación de sistemas de gestión de calidad tales como la
norma ISO9001 y el modelo CMMI.
Está vinculado como miembro del HASTQB (HispanicAmerica Software

TestingQualificationBoard) desde Febrero de 2011‖14.
- Software Quality Assurance, SQA S.A. ―Dedicada a prestar servicios de

consultoría y aseguramiento de calidad de software, cuyo enfoque es entender las
necesidades de los clientes para brindar soluciones enfocadas en contribuir a la
disminución de costos generando mayor confianza de los productos de software
en producción‖15.
- Litsa Consulting Ltda: ―Dedicada a la consultoría en sistemas, desarrollo de

software especializados y a la medida‖16
- Galia Technologies Ltda. ―GaliaTech fue creada con el fin de ofrecer al mercado
regional el conocimiento y experiencia que sus socios han obtenido a lo largo de
sus años como consultores del área de TI. Cuya visión es la de convertirse en una
de las empresas de tecnología con mayor cobertura y conocimiento en procesos
de calidad; apoyando a las compañías de la región en mejorar sus servicios de TI,
logrando así, el fortalecimiento de estas y la satisfacción de sus usuarios‖.17
- Indudata Ltda. Lleva 20 años en el mercado colombiano prestando servicios

profesionales en Ingeniería de requerimientos, Testing, Gestión de la
configuración, ISO 27000, Gestión de proyectos, buscando ―apoyar los
proveedores de tecnología y a las áreas de TI de las compañías en facilitarles el
14
Green SQA .Web- http://www.greensqa.com/. Septiembre 2010.
15
Software Quality Assurance, SQA S.A.Web - http://www.sqasa.com/
16
Litsa Consulting Ltda. Web - http://www.litsacnsulting.com/
17
Galia Technologies Ltda .Web- http://www.galiatech.com/empresa.htm
22
logro de sus objetivos y alcanzar el éxito en informática, la manera de hacerlo
siempre ha sido apoyándonos en los estándares mas reconocidos y con mayores
resultados a nivel mundial, por este motivo nos hemos convertido en un referente
en la utilización de las buenas.
Buscan garantizar a nuestros clientes la exitosa formulación, operación y

sostenibilidad de la Gestión y Calidad en proyectos y procesos de Software‖ 18
Para finalizar, ―la calidad es la piedra angular sobre la cual todas las otras
estrategias necesitan descansar, tales como la innovación, administración
financiera y planificación‖19.
18
Indudata . Web- http://www.indudata.com/
19
HAMMOND,Joshua. Presidente American Quality Foundation
23
2.LAS PRUEBAS NO FUNCIONALES.
2.1 CARÁCTER DE LAS PRUEBAS NO FUNCIONALES
2.1.1 Estándares relacionados con las pruebas de software
-IEEE 829 – 1998. Documentación de pruebas de software. ―El propósito de esta

norma es describir una serie de documentos de prueba de software. Un
documento de prueba estándar puede facilitar la comunicación, proporcionando un
marco común de referencia‖.
-IEEE 982.1. Diccionario estándar de medidas para producir software fiable. Se

describe el proceso de prueba compuesto por una jerarquía de fases, actividades
y tareas y define un conjunto mínimo de tareas para cada actividad. La norma es
aplicable a la unidad de pruebas digitales de cualquier software. Los conceptos de
ingeniería de software y pruebas en la que esta norma se basa es en el enfoque,
la orientación y los recursos de información para ayudar con la implementación y
uso de la unidad estándar de prueba.
-Pruebas de unidad del software. Es la conducta que toman las pruebas locales
frente a un modulo del sistema, es decir, sirven para demostrar o determinar si el
funcionamiento de un modulo es el correcto. Estas pruebas también son
conocidas como pruebas unitarias.
-Verificación y validación del software. Es el nombre dado a los procesos y

pruebas de software, en donde la verificación satisface los requerimientos
funcionales o no funcionales. La validación determina si el sistema satisface las
expectativas del cliente sobre el producto realizado.
-ISO/IEC 25051 – 2006. Requisitos de calidad de productos de software y las

instrucciones para las pruebas: Esta norma determina como probar los productos
de software con los requerimientos de calidad establecidos.
24
-ISO/IEC 29119. Estándar de pruebas software: sirve de base a las pruebas en el
mundo de desarrollo del software eliminando inconsistencia entre algunas normas
actuales, las cuales no cuentan con pruebas establecidas.
-ISO/IEC 25000:2005. Ingeniería del software, SQuaRE: es un conjunto de

normas las cuales se fundamentan a través de la ISO 9126 y la ISO 14598
(Evaluación del Software), la cual tiene como objetivo primordial el de guiar el
desarrollo de productos de software con las especificación de calidad.
ISO/IEC 9126 Factores de calidad del software. El estándar ISO/IEC 9126 fue
reemplazado por SQuaRE, ISO 25000:2005 el cual contiene los identicos
parámetros. Este estándar se divide en cuatro partes las cuales son modelo de
calidad, métricas externas, métricas internas y calidad en las métricas de uso.
Esta norma fue creada con el fin de evaluar los productos de software, señalando
las propiedades de la calidad, también puede ser de utilidad para definir los
requerimientos de calidad.
2.1.2 Ingeniería de requerimientos. Ya nombrados algunos de los actuales

estándares relacionados con las pruebas de software, se procederá a definir el
concepto de Ingeniería de requerimientos, la cual ―trata de establecer lo que el
sistema debe hacer, sus propiedades emergentes deseadas y esenciales, y las
restricciones en el funcionamiento del sistema y los procesos de desarrollo del
software‖.20 Es decir, es la interpretación por parte del equipo desarrollo, de las
necesidades, restricciones de los clientes y/o usuarios.
Un requerimiento es una característica que debe cumplir el sistema para alcanzar

un objetivo. El conjunto de éstos crea un prototipo del sistema final, el cual es
extraído de las ideas abstractas que representan las necesidades. Quedando
establecidos en un documento denominado especificación de requerimientos, el
cual se define luego de pasar de un previo análisis, estudio de viabilidad, entre
otros procesos relacionados y pertinentes.
Para lograr definir estos requerimientos se dispone de varias técnicas, como lo

son los siguientes:
20
SOMMERVILLE, Ian, Ingeniería de software . Séptima edición.Madrid, España: Pearson Educación S.A, 2005. 667p.
25
- Entrevistas.
- Intercambio de opiniones entre el equipo de trabajo.
- Lluvia de ideas entre el grupo de trabajo (Brainstorming).
- Cuestionario (Check-List)
Es típico confundir un requisito con la forma de solución a una necesidad, como lo

es por ejemplo, el decir, para el sistema se debe tener una tabla en base de datos
denominada de X forma.
En la etapa Inicial de un proyecto se debe establecer en un documento, de una

manera informal, las necesidades del cliente, de tal forma que quede descrita de
forma abstracta lo que éste desea. Por consiguiente se establece en un
documento formal, filtrando lo descrito en el informal, transformándolo en tareas
viables, escrito en una forma detallada, y comprensible tanto para el cliente como
para el equipo de trabajo, por ende, se define lo que se conoce como
requerimientos.
-Especificación de los requerimientos
Tanto los requerimientos funcionales como los no funcionales ―se especifican

como sentencias declarativas‖21 y usando casos de uso, ya que éste último facilita
la comprensión tanto para el cliente como para el equipo de trabajo, permitiendo
una mejor comunicación entre los mismos.
Como recomendación, para la definición de cada requisito se debe seguir la

siguiente estructura: Sujeto + verbo activo. Como ejemplo las siguientes
sentencias:
- El sistema debe …
- Se requiere que el sistema …
- El sistema hará …
En dicha definición de los requerimientos, se debe identificar cada uno según el

tipo de requerimiento al que pertenece, con base a la siguiente clasificación:
21
CLAVIJO RODRÍGUEZ, Diana Lucia. Gestión de requisitos, Junio 2011. Pág. 22.
26
Figura 1. Tipos de requerimientos.
Fuente: Sommerville, Ian. Ingeniería del software, en [1].
-Requerimientos del usuario: Sentencias de la visión que el cliente tiene del qué
debe hacer el sistema, declarado en su lenguaje natural, conteniendo también las
restricciones que éste establece, las cuales no afectan la parte operativa del
sistema.
-Requerimientos de software: este define cómo debe funcionar el producto, en

donde se especifican las limitaciones o restricciones sobre la funcionalidad del
mismo, teniendo en cuenta que se debe tener total claridad en lo descrito,
evitando ambigüedades. Estos son tan importantes ya que se establece el
comportamiento del producto.
Los requerimientos de software se dividen en requerimientos de dominio, en

funcionales, no funcionales, o también conocidos como componentes FURPS+,
modelo propuesto por Robert Grady y Hewlett Packard (HP):
Figura 2.Tipos de requerimientos de software.
27
Tabla 1.Requerimientos funcionales y no funcionales
Funcionales No funcionales (URPS)

Reability Performance Supportability
Funcionalidad Usabilidad
(Confiabilidad) (Rendimiento) (Soporte)
Especificaciones Facilidad de uso Capacidad de Tiempo de Facilidad de
que debe ser capaz recuperación a respuesta a someterse a
de ejecutar el fallos solicitudes mantenimient
sistema o
Eficiencia Configurable
Tabla 2. Restricciones.
+ (Restricciones)
Requisitos de implementación Estándares de codificación, Lenguajes de
Implementación, Políticas de integridad de BD
Requisitos de diseño Restricciones de diseño -
Sistemas operativos
-Ambientes
-Compatibilidad
-Estándares
Requisitos de interfaces Elementos externos con los que no interactuar,
Restricciones de formato y otros factores usados por
una interacción
-Requerimientos de dominio (+): ―Son requerimientos de alto nivel que quizás se

describen mejor como requerimientos ―no debería‖, definen el comportamiento del
sistema que no es aceptable―22, es decir, son aquellas especificaciones que son
restricciones para el sistema.
-Requerimientos funcionales (F): Son las capacidades o características que debe

cumplir, en cuanto a funcionamiento, definidas a través de las entradas y salidas
esperadas.
22
28
-Requerimientos no funcionales (URPS): ―Describen atributos del sistema o
atributos del ambiente del sistema‖23. Éste tipo de requisitos se divide en
―requerimientos del producto, requerimientos organizacionales, requerimientos
externos‖24.
Figura 3. Categorías de requerimientos no funcionales.
-Requerimientos del producto: Definen el comportamiento del producto:
Fiabilidad (Reliability)
Usabilidad (Usability)
Portabilidad
Eficiencia
Capacidad de soporte (Supportability)
-Requerimientos Organizacionales: hacen parte de las políticas y procedimientos

existentes en la organización del cliente y en la del desarrollador.
-Requerimientos Externos: Este incluye en los requerimientos que derivan

factores externos al sistema y su proceso de desarrollo.
23
SCALONE, Fernanda. Estudio comparativo de los modelos y estándares de calidad del software.Buenos Aires,
Argentina. junio 2006. 138p.
24
29
De los tres anteriores se derivan a su vez de la manera como se observa en la
figura 1.
Figura 4. Tipos de requerimientos no funcionales y sus categorías.
Para finalizar, el origen de los requerimientos no funcionales parten de diversos

factores, entre ellos a restricciones de ―presupuesto, a políticas de la
organización, a la interoperabilidad del sistema con otros sistemas software o
hardware, también surgen de los otros factores externos como la seguridad o la
legislación sobre la privacidad‖[1].
Es pertinente aclarar que el proceso de pruebas es distinto a la depuración, ya que

el primero hace referencia a determinar la existencia de errores en el producto,
30
mientras que el segundo, se define para encontrar el lugar de origen del error y
erradicarlo. Donde primero se prueba para luego depurar.
Se toma entonces como concepto de pruebas de software al ―proceso
empleado para identificar que una aplicación sea correcta, completa, segura y de
buena calidad en el desarrollo‖25. Es considerado un proceso complejo de aplicar
dentro del ciclo de vida del desarrollo es, significando un alto costo, pero de igual
considerado ―elemento crítico para determinar la calidad del producto‖26.
Teniendo claro lo anterior, se pasa entonces a definir que para mejorar la calidad
del producto, se inicia por el proceso de pruebas, y para fines del presente
proyecto monográfico, sólo se hace énfasis en pruebas no funcionales. Las cuales
se deben realizar a lo largo del ciclo de vida del desarrollo de software, es decir,
debe ser transparente al ciclo de vida:
Figura 5. Ciclo de vida del desarrollo de software.
Fuente: PRESSMAN, Roger S. Ingeniería del software, en [2].
Se realizan para garantizar entregas de calidad y liberación de un producto con un

número mínimo de fallas, errores o defectos, asegurando así una mayor
confiabilidad tanto para las áreas de desarrollo, como para lograr la satisfacción de
los usuarios finales.
Sin embargo en la actualidad a éste proceso no se le da la verdadera importancia

que tiene, es menospreciado, puesto que aún se tiene la concepción de que este
25
Definición de testeo de software. Santa fé.Web-http://www.alegsa.com.ar/Dic/testeo%20del%20software.php. 2008.
26
VENTANA INFORMÁTICA. Pruebas de software y gestión documental. Julio 2009.197p. ISSN 0123 – 9678.
31
proceso va siempre al final de cada fase del ciclo de vida del desarrollo (Figura 1).
Pudiéndose inferir que la baja calidad de un producto, se observa con la cantidad
de reporte de errores, por ende, mayor soporte al cliente.
Reiterando que en todo proyecto es difícil cumplir con el cronograma establecido,

por ende le huyen a ésta fase, con la argumentación de ―no disponer del recurso
tiempo‖, adicionalmente, porque no encuentran como demostrar el aporte del
proceso de pruebas no funcionales sobre la calidad del producto desarrollado,
puesto que se espera tener un valor que indique el nivel de calidad alcanzado, en
cuanto a los aspectos no funcionales del sistema, como ocurre con las pruebas
funcionales, cuyo resultado es medible y alcanzable, contrario de las pruebas no
funcionales, a las cuales se les asigna valores subjetivos.
Debido a lo antes expuesto, se dificulta la verificación del impacto que generan

las pruebas sobre los requerimientos no funcionales, y por tanto no se cuenta con
indicadores verídicos, con los cuales se le pueda demostrar al cliente la
justificación de su gran importancia sobre la calidad del producto final.
Adicionalmente porque para ―verificar de forma objetiva los requerimientos no

funcionales cuantitativos puede ser muy alto el coste‖27 y el cliente que adquiere el
aplicativo no encuentra justificación a los altos costos del proceso.
Sin embargo, es necesario persuadir a las organizaciones de la importancia de

éste proceso sobre los requerimientos no funcionales, buscando justificar que
deberían invertir por lo menos un ―50% de los recursos del proyecto a éste, y un
80% cuando el software a desarrollar es de misión crítico‖28. Puesto que el valor
agregado es en calidad y fiabilidad, logrando garantizar la disminución en la
ocurrencia de errores.
El proceso de pruebas es una técnica de la verificación y la validación, donde

estos últimos son los nombres que se le dan a los procesos de análisis y pruebas.
27
28
AGUIAR FERNÁNDEZ , María del Mar. Ingeniería del software y pruebas.. Revista española de electrónica. Septiembre
2000. 90p. Número 550.
32
Es válido aclarar que la verificación tiene como principal objetivo, determinar si el
producto cumple con los requerimientos funcionales y no funcionales
especificados por el cliente, mientras la validación determina si el software
funciona correctamente y satisface las expectativas que el cliente tiene sobre este.
Por ende el proceso de pruebas no funcionales, permite validar y verificar el

producto desarrollado, de tal forma, que se inicia la planeación y ejecución del
proceso al iniciar el proyecto, es por ello, que se realizan revisiones a
requerimientos levantados, a revisión de diseño.
2.1.3 Estrategias de pruebas de software en general. Se disponen de dos tipos,

la detección y la prevención, donde en la primera tiene como objetivo encontrar
errores y pasar a corregirlos, antes de liberar el software a producción, mientras
que en la segunda, se realiza al terminar cada etapa del desarrollo, para prever
errores antes de su ocurrencia, sin continuar a la siguiente etapa, hasta no
garantizar la eliminación de los orígenes de los errores hallados en la etapa actual.
En cuanto a costos, es claro que al realizar tempranamente una eliminación de un

error es menos costoso, que encontrar el mismo en la última etapa del desarrollo,
ya que en ese punto, se han generado a partir del mismo, nuevos errores. Es por
tanto que el usar la estrategia de Prevención es menos costoso, ya que se
resuelve el problema antes de su ocurrencia, sin tener que esperar a finalizar
todas las etapas para corregirlo.
Es por ello que hay que realizar bien las actividades desde la primera vez, o
también conocido como RFT.
33
Figura 6. Estrategias de pruebas.
Fuente: Revista española de electrónica, en [3]
2.1.4 Descripción del proceso de pruebas no funcionales. Las actividades a

desarrollar para la aplicación de pruebas no funcionales del software a
implementar, son las siguientes:
- Planeación de las pruebas, se debe realizar desde el mismo momento en que se

definen fechas de entrevistas con el cliente para definir los requisitos.
Uno de los principios básicos que se debe tener en la planificación de pruebas de

software es designar los recursos apropiados para la ejecución de las pruebas,
determinar los grupos de personas que van a participar en las pruebas y estimar el
calendario de las pruebas, siendo todo esto de gran utilidad para los ingenieros de
software.
34
La planeación de pruebas logra enfocar al grupo que realiza estas cual es la
situación aplicativo y así prepararlos a los diferentes tipos de pruebas que se van
a emplear.
Los planes de pruebas están constituido por un conjunto pruebas, en donde se

determina que atributos de pruebas se desean llevar acabo como la fiabilidad,
usabilidad, entre otros.
El plan de pruebas tiene los siguientes elementos:
-Identificador del plan

-Alcance
-Ítems a probar
-Estrategias
-Categorización de la configuración
-Documentación
-Procedimientos especiales
-Recursos
-Calendario
-Riesgos
-Responsables
35
Tabla 3. Estándar de la IEEE 829-1983.
Fuente: Plan de pruebas, en [4]
- Diseño de las pruebas29
Las pruebas pueden ser planteadas por componentes o módulos, de tal forma que
se inicie desde lo más pequeño hacia lo más grande e integrado
El diseño de los casos de pruebas se hace con el principal objetivo de buscar

una gran cantidad de errores, en un plazo corto y con el mínimo esfuerzo. Con el
diseño de estos casos de pruebas se determina cuales son los mejores
procedimientos a seguir, las técnicas a emplear y sus medidas que aplicar. En
estas también se miran los datos a ingresar y las respectivas salidas que están
tendrán.
29
Proyecto de grado, plan de negocios para la creación de servicio y asesoría de pruebas de software. Web-
http://recursosbiblioteca.utp.edu.co/tesisdigitales/texto/65811M828.html
36
La realización del diseño de los casos de pruebas tiene un objetivo más, en el
cual se busca determinar si estas cumplen con la verificación y validación de los
requerimientos no funcionales.
Los productos de software se pueden probar utilizando dos criterios los cuales
son:
El conocimiento del funcionamiento del producto, este se efectúa aplicando las

pruebas de caja blanca.
El conocimiento de la función especifica para la que fue diseñado el producto,

este se realiza por medio de las pruebas de caja negra.
- Ejecución de las pruebas, se deben ejecutar antes de iniciar el desarrollo y se

debe definir criterios de finalización del proceso de pruebas, Idealmente se da por
finalizado cuando los casos de pruebas son ejecutados y se han corregido los
errores hallados. Ejecutando nuevamente los casos de pruebas, usando o no los
mismos datos, pero buscando garantizar la eliminación del error, defecto o falla. Y
verificando que no se hayan generado nuevos.
Otro criterio de finalización para este proceso es el número de ciclos de pruebas
- Control, seguimiento y retroalimentación
Es decir que inicialmente se debe definir un plan de pruebas, estableciendo los

artefactos a probar, el alcance, asignando recursos, luego establecer los casos de
pruebas a ejecutar. Realizando posteriormente un ciclo de pruebas, de tal forma
que éste será exitoso si se haya errores. Finalmente será un buen proceso o en
particular un buen caso de prueba, si detecta defectos, errores, o fallas antes no
halladas en el producto. Pero si por el contrario, al finalizar el proceso de pruebas
no funcionales, no se encuentran errores, será un proceso que habrá agregado
sólo costos y pérdidas de tiempo en el proyecto.
37
Es fácil desviarse del objetivo principal de las pruebas no funcionales, como ya se
había mencionado antes, ya que se puede visualizar como que su prioridad es la
de demostrar que no hay errores de este tipo, es decir, que toman como el
proceso exitoso al no hallar errores, fallas o defectos, estando en una total
equivocación. El ejemplo más claro lo presentan los desarrolladores, puesto que
éstos al ejecutar sus pruebas unitarias, se conocen el camino común y sin errores,
saltando sobre los mismos, una y otra vez, es decir, que no están buscando los
errores, sino que están demostrando que el software funciona correctamente y por
tanto que corresponde a una confiabilidad total del mismo.
Sin embargo, el ejecutar el ciclo y casos de pruebas, no garantizan la ausencia de

errores en el producto desarrollado, es decir, no se certifica que los defectos
desaparezcan en su totalidad, ya que sus causas son múltiples.
Dentro de dichas causas de los errores, se encuentran los relacionados con la

tecnología elegida, es decir, no realizar una elección correcta de la herramienta de
desarrollo, fallas en el estudio de viabilidad, mala distribución de recursos del
proyecto, la equivocada asignación de roles, la mala comunicación entre el equipo
de trabajo, también debido a la poca experiencia del desarrollador, es decir, falta
de conocimiento, o por el contrario por demasiada experiencia, lo que genera
confianza en sí mismo, obviando errores por creer que no ocurrirán.
Por otra parte, quien debe realizar las pruebas, no debe ser el mismo personal
involucrado en el desarrollo del producto, ya que éstos no guardan una madurez lo
suficientemente firme, como para criticar de forma constructiva su propia creación,
además no visualiza más allá de lo que ya conoce del producto, lo cual genera
que siempre ejecute el mismo curso, obviando caminos distintos, por donde
posiblemente se encuentren fallas, errores, defectos.
El proceso de pruebas es más productivo si es realizado por personal que conoce

la lógica del negocio y del proyecto, con facilidades de adaptar su experiencia al
proceso. Mientras que en el proceso de depuración, la presencia del autor del
producto, es decir, del desarrollador, es una parte fundamental.
En cuanto a las entradas del proceso de pruebas, se debe establecer una bitácora
de datos, los cuales no deben ser datos reales, acatando la circular externa 052
38
del 2007, ―No utilizar datos de producción en los ambientes de pruebas‖30. Esta
bitácora de datos permite visualizar distintas situaciones.
Cada entrada es conocida como caso de prueba, el cual debe tener definidas los
objetivos, tanto las respuestas esperados, como las equivocadas, por cada caso
de prueba.
Los ingenieros probadores o tester son quienes toman los requerimientos como
base para desarrollar las pruebas de verificación y validación para el sistema. Por
lo tanto son los encargados de definir los casos de pruebas, los cuales deben
tenerlos bien documentados, teniendo un conocimiento previo del producto e
informándose con el equipo desarrollador.
2.1.5 Desarrollo de caso de prueba
El caso de prueba permite a la persona encargada de probar la aplicación, definir

si el producto cumple con los requerimientos establecidos. Para esto no se tiene
una plantilla establecida como estándar, algunos ítems que se recomiendan tener
en cuenta al realizar un caso de prueba son los siguientes:
- Id caso de prueba
- Módulo a probar
- Descripción del caso
- Pre-Requisitos
- Data necesaria (valores a ingresar)
- Pasos o secuencia lógica
- Resultado esperado (Correcto o Incorrecto)
- Resultado Obtenido
- Observaciones o comentarios
- Analista de Pruebas (Responsable de las pruebas)
- Fecha de ejecución
- Estado (concluido, pendiente, en proceso)
30
. Superintendencia financiera de Colombia. Web-http://www.netsecuritysuite.com/pdf/Norma-052.pdf .Circular externa
052 del 2007
39
Tabla 4. Plantilla recomendada para caso de prueba.
Plantilla para casos de pruebas

Campo a diligenciar
Id caso de prueba
Nombre de caso de prueba
Descripción
Precondiciones
Relaciones de caso de uso
Pasos y condiciones ejecución
Resultado esperado
Estado de caso de prueba
Resultado obtenido
Errores asociados
Responsable del diseño
Responsable ejecución
Comentarios
Fuente: Plantilla para caso de prueba, en [5].
40
3.MÉTODOS DE PRUEBAS.
Aunque existen dos tipos de métodos de pruebas, los estáticos y los dinámicos, se
orientarán hacia su aplicación a atributos no funcionales para esta monografía.
Por ende se explican los niveles de pruebas y los actores respectivos.
-Niveles pruebas del modelo
Algunos de los niveles de pruebas que existen son las pruebas unitarias,
integración, sistema y aceptación.
Pruebas unitarias: son las que realiza el desarrollador del producto.

Pruebas de Integración: son realizadas por el desarrollador del producto
Pruebas de Sistema: las realiza el equipo de pruebas.
Pruebas de Aceptación-Usuario: se realiza al final de todas las pruebas antes
mencionadas, cuando el producto se encuentra listo.
41
Tabla 5. Niveles de pruebas.
Niveles de Pruebas
Pruebas Objetivos Integrantes Ambiente Método
Encontrar errores
Unitarias de logica y Programadores Desarrollo Caja Blanca
algoritmos
Encontrar errores
de interfaz y las
relaciones Caja Blanca,
Integración existente entre los Programadores Desarrollo Ascendente,
componentes Descendente
Encontrar errores
en la
Funcional implementación Tester,Analistas Desarrollo Funcional
de requerimientos
Encontrar fallas en
Sistema los requerimientos Tester,Analistas Desarrollo Funcional
Encontrar falla en
la implementacion Tester,Analistas,
Aceptación Productivo Funcional
del sistemas Cliente
3.1 MÉTODOS ESTÁTICOS
3.1.1 Inspecciones. Las inspecciones de software son conocidas en el mundo

como inspecciones de código, estas surgieron en IBM donde se lleva un registro
a los problemas que se presenta en el software, como los errores o defectos que
tenga el aplicativo.
-Inspecciones Formales de usabilidad
Los métodos de inspección cuentan con 4 hasta 8 inspectores, donde se delegan

roles a cada uno de estos. Luego que se designan los roles se reparten ―los
documentos del diseño a inspeccionar y las instrucciones pertinentes‖, 31 donde
cada uno tiene asignados unos objetivos y propósitos, basados en las
necesidades del usuario, cada uno debe dar cumplimiento con su labor individual.
31
Inspecciones. Web-http://www.sidar.org/recur/desdi/traduc/es/visitable/inspeccion/FUInsp.htm
42
Los datos recolectados serán informados o intercambiados en reuniones formales,
así, cuando se ha encontrado los defectos por el equipo inspector, serán
pasados al equipo diseño.
El equipo de trabajo de las inspecciones formales es conformado por personas

que estén en el proyecto como en la parte de diseño, desarrollo, documentación,
supervisión, calidad, entre otros.
En las reuniones formales que se realizan, cada inspector deberá asumir uno de
los siguientes roles:
Moderador: son los encargados de pasar los materiales solicitados y recogerlos,

planificar las reuniones laborales, y delegar funciones para las respectivas
correcciones de los defectos.
Propietario: este es el que diseña el sitio web y se le delegan las respectivas

modificaciones de defectos que se encontraron.
Secretario: toma un documento formal el cual tiene los defectos usabilidad

planteados en las reuniones laborales realizadas.
Inspector: las personas faltan pueden tomas varios roles, los cuales son
inspeccionar el diseño presentando documentación de las deficiencias
La asignación de documentos de trabajo entre los inspectores, son los

siguientes32 :
- Descripciones del site.

- Pantallas con sus correspondientes distribuciones de objetos.
- Perfiles de usuarios.
- Tareas de usuario.
- Heurísticos a usar.
- Formulario de recogida de deficiencias de usabilidad.
32
Inspecciones. Web-http://webusable.com/useTechniques_B.htm
43
Estas técnicas de inspección se pueden realizar usando diferentes medios de
evaluación, entre ellos los siguientes:
- Evaluación Heurística: las personas encargadas de los aspectos de la usabilidad

determinan la interfaz de usuario, ya sea de algún sitio web y ―luego lo evalúan
contra una lista de principios heurísticos mayoritariamente aceptados‖ 33.
Se ha determinado que 5 inspectores de usabilidad detectan un 80% de los

defectos de una aplicación web, mientras 15 inspectores podrían determinar un
100%.
Para la evaluación se establecen unas categorías en donde colocan los problemas

dándoles así una clasificación, y cada uno de los inspectores analiza estos sin
intercambiar ideas.
Las evaluaciones heurísticas se pueden ejecutar en cualquiera de las fases del

ciclo de vida, pero son de gran aporte al principio de este ciclo.
- Ensayo cognoscitivo: los evaluadores son personas con un alto grado de

experiencia donde recrean los escenarios de acuerdo a las especificaciones del
sitio web, además se ponen en la posición del usuario a través analizando cada
una de las interfaces que hay de usuarios.
- Ensayo Pluralista: se realizan reuniones con los desarrolladores, diseñadores,

usuarios y expertos de usabilidad, donde estos últimos son los que las coordinan
para tratar temas acerca de las respectivas funciones que realiza el usuario en el
sitio web y sobre las interfaces de usuario
3.1.2 Walkthroughs (Paseos cognitivos). Son revisiones que se llevan a cabo sin
la ejecución de código.
3.2 MÉTODOS DINÁMICOS
33
Inspecciones. Web-http://webusable.com/useTechniques_B.htm
44
3.2.1 Pruebas de unidad. ―Se puede decir que una prueba unitaria es una
actividad mediante la cual se ejecuta un proceso a partir de unos datos de
entrada, que son los casos de prueba, y que llega a una salida determinada,
buscando detectar los posibles defectos de su interior‖34. Se ejecutan hasta
alcanzar un nivel definido como óptimo.
Se dividen en pruebas de caja negra y de caja blanca, donde la primera es

realizada por el personal de desarrollo, y está orientada a demostrar que cumple
con cada función operacional, mientras se buscan los errores de cada función, y la
segunda busca asegurar que las operaciones procedimentales y codificadas
correspondan a las especificadas.
No se analiza este tipo de pruebas, ya que su aplicación al producto software no

aporta a la calidad de los requerimientos no funcionales. Puesto que ésta centra
sus esfuerzos en verificar la lógica del procesamiento interno del software.
3.2.2 Pruebas de integración. Este tipo de pruebas es aplicable para aquellos

productos desarrollados por componentes o módulos. Se realiza para garantizar
que al integrar dichos módulos funcionen según lo especificado, probando hallar
los errores asociados al proceso de ensamblaje, para comprobar sus interfaces en
el trabajo en conjunto.
- Pruebas de integración ascendente
Estas pruebas empiezan desde el modulo inferior hasta llegar al modulo superior
de la jerarquía. A medida que las pruebas avanzan desde el nivel inferior hasta el
superior se reducen el número de pruebas que se realizan por separado.
Algunas de las ventajas que se encuentran en las pruebas ascendentes son las
desventajas de las pruebas descendentes y viceversa. La selección de la prueba
ya sea descendente o ascendente depende primordialmente del producto a
desarrollar y en otras ocasiones del plan que se tenga del proyecto.
- Pruebas de integración descendente
34
AGUIAR FERNÁNDEZ , María del Mar. Ingeniería del software y pruebas.. Revista española de electrónica. Septiembre
2000. 94p. Número 550.
45
Esta se realizan empezando desde el modulo principal hasta llegar a los módulos
inferiores en jerarquía. Las pruebas se encuentran manejado por el modulo de
control principal y estas a su vez estas se van desplazando a módulos inferiores,
se debe tener en cuenta que las pruebas se realizan cada vez que un nuevo
modulo ingrese o se cree.
En estas pruebas se pueden generar problemas en los resultados, si el un modulo

de jerarquía superior depende de los cálculos realizados por módulos de jerarquía
inferior y estos producen fallas, el tester o encargado de realizar las pruebas
tendrá un retraso en el tiempo para las otras pruebas hasta encontrar las fallas de
los módulos faltantes.
3.2.3 Pruebas de sistema. Tienen como objetivo principal hallar los errores en
integración. Son aplicables a los cinco atributos de calidad de software.
- Pruebas de validación alfa
Éstas se pueden iniciar posteriormente a la culminación de las pruebas de

integración, si fueron realizadas, y se centran principalmente en las acciones
visibles para el usuario, y en la salida del sistema que éste puede reconocer.
Se realizan para comprobar si el software ensamblado, da cumplimiento a

requerimientos de eficiencia, portabilidad, usabilidad, Mantenibilidad, fiabilidad.
- Pruebas de validación beta
Estas pruebas son realizadas en el equipo que va a quedar finalmente instalada la

aplicación, en donde esta será probada directamente por usuario final y no tendrá
control sobre esta el desarrollador.
Los clientes se encargan de comunicar los problemas encontrados a los

desarrolladores, los cuales tomaran las precauciones para corregir los problemas
presentados en la versión beta. Después de corregir estos problemas en la
aplicación, se sacara otra versión nueva al mercado mejorada para diferentes
clientes.
46
-Pruebas de desempeño
Diseñadas para probar el sistema en tiempo de ejecución en ambientes

contextualizados al real. Éste tipo de pruebas proveen información acerca de
lugares donde se generan los cuellos de botella del sistema.
Son realizadas en cualquier nivel de desarrollo, es decir, se debería evaluar cada

módulo individual. Sin embargo, esto no garantiza que el sistema quede estable,
es por ello, que se espera hasta la integración de la arquitectura software que se
realiza, puesto que es allí donde se puede asegurar el verdadero desempeño del
producto software.
- Pruebas de tensión o stress
Con este tipo de pruebas se busca llevar al límite la capacidad de tolerancia del
sistema, a través de diversas formas, puede ser, iniciando sesión con una
cantidad de usuarios al sistema, y ―si el sistema debe gestionar x mega – bits por
segundo de una línea de comunicaciones, probar a aumentar ese ancho de
banda‖35 de tal forma que se llegue a un dato que indique dicho límite del sistema.
Se enfrenta el sistema a situaciones anormales, es decir, enfrentarlo a peticiones

de usuario con una frecuencia definida, para determinar su uso de recursos en
dichas circunstancias y su reacción ante la misma. Busca sobrecargar el sistema,
para hallar estados de inestabilidad o procesamiento inapropiado.
3.3 ATRIBUTOS DE CALIDAD DEL SOFTWARE QUE SON EVALUABLES AL

APLICAR PRUEBAS NO FUNCIONALES
A continuación se describe la jerarquía de los requisitos no funcionales en la

figura:
35
RAMÓN ÁLVAREZ, José - ARIAS CALLEJA, Manuel. Análisis, diseño y mantenimiento del software.Departamento de
Inteligencia-Artificial–ETSI-Informática-UNED. Web- http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node49.html.
Consulta [20/09/2011]
47
Figura 7. Jerarquía de requisitos no funcionales.
Fuente: Requisitos no funcionales, en [6].
Figura 8. ISO/IEC 9126.
Fuente: Calidad de componentes software, en [7].
Al analizar la jerarquía de requerimientos no funcionales y al realizar una

integración de lo establecido en la ISO/IEC 9126 – Calidad del producto de
software, la cual define seis categorías de requerimientos, como se puede
observar en la figura 2, los cuales garantizan la calidad del software, donde cada
uno a su vez tiene asociados diferentes requerimientos no funcionales, lo que
según Ian Sommerville, en su libro Ingeniería de requerimientos séptima edición,
define los mismos como requerimientos del producto y el modelo FURPS+, los
48
establece como cinco categorías, siendo los mismos requerimientos. De lo anterior
se determinan las categorías y atributos que interesan para la actual monografía.
- Funcionalidad
- Usabilidad
- Eficiencia
- Fiabilidad
- Portabilidad
- Mantenibilidad
A partir de los requerimientos antes mencionados, exceptuando el requerimiento

de funcionalidad, puesto que no entra en el alcance de éste proyecto, se procede
a describir los atributos principales que se pueden llegar a medir a una medición
del nivel de aporte de los distintos tipos de pruebas mencionados en el numeral
3.1 y 3.2, de tal forma que se pueda inferir su aporte hacia la calidad del producto
software desarrollado.
Entendiéndose como atributo, aquella entidad que tiene un producto software, que
posee la característica de poder ser verificada o medida. Donde la medición
implica asignar un valor a dicha entidad.
Dichos atributos no se encuentran definidos como estándares ya que se

diferencian entre uno y otro producto software, dependiendo de la lógica del
negocio y por tanto del producto que se requiere desarrollar.
Debido a la dificultad para identificar y cuantificar con objetividad dichos atributos

no funcionales, es por ello que se requiere conocer las técnicas para medirlos, de
tal forma que se pueda intentar estudiar el impacto de los mismos sobre la calidad
del software, independiente del modelo o metodología de desarrollo. Finalmente,
estos atributos son evaluados de forma subjetiva, debido a su difícil identificación
en la recolección de requerimientos, ya que su levantamiento se realiza de igual
forma para los funcionales como para los no funcionales.
Es por ello que la identificación de errores en producción, relacionados a estos
atributos, según la experiencia de empresas reconocidas, son los más difíciles de
resolver estando ya en operación y afectando unos altos costos.
49
Adicionalmente, se hace necesario reconocer la alta dificultad para independizar
los requerimientos funcionales de los no funcionales, ya que esto también
depende del nivel de detalle al que se quiera llegar en su recopilación.
3.3.1 Características evaluables del requerimiento de Fiabilidad
Tabla 6. RFN fiabilidad.
Requerimiento (Categoría) Características evaluables

Recuperabilidad
Frecuencia de fallas
Fiabilidad
Disponibilidad
Severidad de fallas
Características evaluables
Relacionado a la capacidad de la aplicación para recuperarse en el menor tiempo

ante la ocurrencia de una falla del sistema, además de garantizar no perder datos
en el envió hacia el servidor o hacia los clientes.
De este atributo se derivan las características de disponibilidad.
Madurez: Capacidad del producto software para evitar fallar como resultado de
fallos o defectos en el software.
Recuperabilidad: Capacidad del producto software para reestablecer un nivel de

desempeño especificado y de recuperar los datos afectados luego de la ocurrencia
de una falla
50
Tolerancia a fallos: Capacidad del software para mantener un nivel especificado
de desempeño en caso de fallos del software o de infringir sus interfaces
especificados.
Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a

normas, convenciones o regulaciones relacionadas con al fiabilidad.
3.3.2 Características evaluables del requerimiento de Portabilidad
Tabla 7. RFN portabilidad

Adaptabilidad
Instalabilidad
Portabilidad
Facilidad de adaptación al cambio
Co - existencia
Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes

entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos
proporcionados para este propósito por el propio software considerado.
Instalabilidad: Capacidad del producto software para ser instalado en un entorno

especificado.
Coexistencia: Capacidad del producto software para coexistir con otro software
independiente, en un entorno común, compartiendo recursos comunes.
Capacidad para reemplazar: Capacidad del producto software para ser usado en
lugar de otro producto software, para el mismo propósito, en el mismo entorno.
51
Cumplimiento de la portabilidad: Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la portabilidad.
Como en todo proceso responsable se debe definir la(s) persona(s)

responsable(s) de hacer la planeación de la medición de los atributos, encargados
también de hacer pública esa planeación, buscando la aceptación, compromiso
del equipo de trabajo, y solicitando al líder del proyecto, la asignación del recurso
tecnológico, humano, presupuestal.
3.3.3 Características evaluables del requerimiento de Eficiencia
Tabla 8. RFN eficiencia.

Tiempo de respuesta
Desempeño
Eficiencia Tráfico generado en las comunicaciones
Tiempo de recuperación a fallas
Utilización de recursos (Memoria)
Comportamiento temporal o en relación al tiempo: Capacidad del producto

software para proporcionar tiempos de respuesta, tiempos de procesamiento y
velocidad en la ejecución de funciones, bajo condiciones determinadas.
Comportamiento en relación al uso de recursos: Capacidad del producto software

para usar las cantidades y tipos de recursos adecuados cuando el software lleva a
cabo su función bajo condiciones determinadas.
Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a

normas o convenciones relacionadas con la eficiencia.
52
De este atributo se derivan las características de rendimiento, escalabilidad.
Características que enmarcan entre otros, los tiempos de respuestas solicitados
por el cliente, capacidades de ofrecer un servicio de acuerdo lo solicitado.
Es también pertinente recordar el concepto de requerimientos de desempeño para

un sistema, el cual se define como que ―Un sistema con buen desempeño es
aquel que realiza su función en el menor tiempo posible y utilizando la menor
cantidad de recursos. Para efectos prácticos, y a pesar de las diversas categorías
de requisitos de desempeño que pueden existir, los desarrolladores que
construyen sistemas en los cuales el desempeño es un requisito importante, se
enfocan fundamentalmente en la velocidad a la cual el sistema puede realizar su
función, teniendo en cuenta los recursos finitos y sus características de Calidad
del software‖36.
Al momento de probar este atributo, se evalúa la conformidad del sistema o

componente con respecto a los requerimientos de desempeño de este tipo
especificados.
Generalmente se llevan a cabo la aplicación de pruebas a éste requerimiento,

usando herramientas de pruebas automáticas (scripts o robots). Puesto que para
valorar éste atributo es necesaria la simulación de altas cantidades de
transacciones al tiempo, simulando carga y volumen de información, buscando
monitorear el desempeño del aplicativo frente a esto.
Se ejecutan sobre los procesos críticos del aplicativo. Donde los procesos críticos
deben ser definidos por el director del proyecto y el equipo de trabajo.
3.3.4 Características evaluables del requerimiento de Mantenibilidad
36
SERNA, Sergio. Especificación formal de requisitos temporales no funcionales. Web-
http://www.bdigital.unal.edu.co/3928/1/98553427_2011_1.pdf. Consulta [21/09/2011]
53
Tabla 9. RFN Mantenibilidad.

Analizabilidad
Facilidad de cambio
Mantenibilidad
Facilidad de prueba
Estabilidad
Capacidad para ser analizado: Es la capacidad del producto software para serle
diagnosticadas deficiencias o causas de los fallos en el software, o para identificar
las partes que han de ser modificadas, es decir, es el grado de complejidad para
diagnosticar deficiencia y causas de falla
Capacidad para ser modificado: Capacidad del producto software que permite que
una determinada modificación sea implementada.
Estabilidad: Capacidad del producto software para evitar efectos inesperados

debidos a modificaciones del software.
Capacidad para ser probado: Capacidad del producto software que permite que el
software modificado sea validado, es decir, facilidad de ser probado
Cumplimiento de la mantenibilidad: Capacidad del producto software para

adherirse a normas o convenciones relacionadas con la mantenibilidad.
3.3.5 Características evaluables del requerimiento de Usabilidad
54
Tabla 10. RFN Usabilidad.
Requerimiento (Categoría) Característicasevaluables

Operabilidad
Aprendizaje
Atractividad
Comprensibilidad
Capacidad para ser entendido: Capacidad del producto software que permite al
usuario entender si el software es adecuado y cómo puede ser usado para unas
tareas o condiciones de uso particulares.
Capacidad para ser aprendido: Capacidad del producto software que permite al
usuario aprender sobre su aplicación.
Capacidad para ser operado: Capacidad del producto software que permite al
usuario operarlo y controlarlo.
Capacidad de atracción: Capacidad del producto software para 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 la
usabilidad.
En la actualidad se ha avanzado con respecto a concienciar sobre la importancia

de realizar pruebas a este factor de calidad, así lo indican Beatriz E. Florián,
Oswaldo Solarte, Javier M. Reyes, de la Escuela de Ingeniería de Antioquia, al
55
afirmar que “las pruebas y evaluaciones durante el desarrollo del producto han
ganado amplia aceptación como estrategia para mejorar la calidad del
37
producto‖ . Es decir, que ya se considera como uno de los atributos
fundamentales para alcanzar el éxito de un proyecto. Lo cual ha generado ―un
interés creciente en el mundo del desarrollo de software como factor de calidad‖38.
Sin embargo, aunque se reconozca la importancia de lograr un producto de

software de calidad en el uso, no ha sido fuerte su difusión, lo que conlleva a que
dicho proceso aún no sea un factor incondicional en el ciclo de desarrollo software.
Por otra parte no es de desconocer que la aplicación de pruebas a este factor de

calidad del software, al ser realizado en etapas tempranas del desarrollo, como lo
es en levantamiento de requisitos, diseño del software y posteriormente la
ejecución de prueba de usabilidad, finalizando con la verificación de la interfaz,
proporciona al producto mejoras visibles en cuanto a calidad, tanto para
desarrolladores como para probadores (Tester).
Entre tanto para valorizar la usabilidad, se hace necesario describir brevemente

las estrategias de clasificación de usuarios, debido a la necesidad de identificas
según el orden jerárquico de desempeño de los mismos, frente a las herramientas
computacionales39, teniendo en cuenta que el usuario hace parte fundamental del
proceso de desarrollo y sus ideas son valiosas para valorar este atributo,
buscando obtener a lo largo del desarrollo una retroalimentación por parte de
éste.
- Estrategia de conocimiento y experiencia: Basada en el uso de las herramientas

computacionales
- Estrategia de estructuración de las tareas de interacción: Basada en los modelos

mentales de los usuarios con respecto al uso de las tecnologías en su trabajo.
37
Revista EIA. Escuela de Ingeniería de Antioquia, Medellín (Colombia). Julio 2010. 123p .Numero 13. ISSN 1794-1237.
38
FERRÉ, 2003; CHEIKHI, Abran y SURYN, 2006.
39
SHNEIDERMAN y PLAISANT. 2006
56
Grupos de usuarios de pruebas:
- ―Usuario novato o inexperto: Es aquel cuyo nivel de conocimiento en uso de

herramientas computacionales es bajo, es decir, que dentro de sus actividades
cotidianas, su interacción con aplicativos se encuentra entre 0% y 20%.
- Usuario intermedio: Es aquel cuyo nivel de conocimiento e interacción con

aplicativos, se encuentra entre un 20% y un 80%.
- Usuario avanzado: Es aquel cuyas actividades cotidianas le exigen estar en

interacción con aplicativos, entre 80% y más.
- Desarrollador: Se propone al desarrollador como un integrante más del proceso

de evaluaciones de usabilidad. Para evitar las observaciones técnicas que se
alejan un poco de los criterios de interacción humano – computador (IHC).
- Auditor: Es quien realiza la verificación del sistema desde el punto de vista

funcional, pero teniendo en cuenta criterios de usabilidad. Es el experto en
usabilidad, que además debe tener conocimientos en ingeniería del software y en
las tecnologías utilizadas en el desarrollo del producto. El auditor no participa en
las etapas de análisis e implementación del software. Permite que la evaluación
se desarrolle de una manera menos subjetiva y evita la posibilidad de tener
apreciaciones que estén descontextualizadas respecto a la interacción de los
usuarios potenciales con la aplicación―40.
Métodos de evaluación del atributo de usabilidad.
Existen métodos empíricos y no empíricos, dentro de los que se conciben los

siguientes métodos:
- Métodos de análisis: En ésta se busca observar la facilidad con que los usuarios
realizan determinadas operaciones en el aplicativo.
40
Revista EIA.Escuela de Ingeniería de Antioquia, Medellín (Colombia). Julio 2010.127p. Numero 13.ISSN 1794-1237
57
- Métodos de inspección: Principalmente se busca evaluar la interfaz
- Métodos de indagación: se busca ―obtener información con respecto a los

gustos, disgustos, necesidades y comprensión del sistema de parte de los
usuarios‖41.
Adicionalmente, como forma de valoración de este factor se usan también las

evaluaciones heurísticas y las pruebas de usuario. En donde las primeras hacen
parte de los métodos no empíricos, proporcionando la visión que posee el
desarrollador sobre la interfaz, mientras que las segundas, hacen parte de los
métodos empíricos totalmente, permitiendo obtener la visión que posee el
usuario sobre la interfaz. Aunque ambas pertenezcan a métodos diferentes,
forman un complemento ideal de retroalimentación, permitiendo alcanzar una
mayor calidad en la definición de la interfaz requerida.
Tao establece un modelo con base en estados de máquina y heurísticas de

usabilidad. Donde los estados de máquina permiten modelar la interacción del
usuario con el aplicativo, mientras que la heurística de usabilidad aporta mejoras
en el diseño en las interfaces de usuario.
Por otro lado, Singh incluye pruebas de usabilidad en la metodología ágil

SCRUM, lo que definió como U-SCRUM, en la cual propone como artefactos a
probar, ―los roles de usuario, la visión de experiencia de usuario y el plan del
producto‖. Se tiene también la propuesta de Granollers et al (2005), de Juristo,
Moreno y Sánchz – segura (2007), y Aveledo, de la Rosa y Moreno (2008).
En la tabla 8, se encuentran la plantilla o lista de chequeo para evaluar la

usabilidad, la cual contiene por cada etapa de desarrollo (Ingeniería de requisitos,
análisis y diseño, codificación y pruebas, pruebas con usuarios, y verificación), las
actividades propuestas por cada etapa, donde cada actividad se relaciona a uno o
41
Revista EIA. Escuela de Ingeniería de Antioquia, Medellín (Colombia). Julio 2010.125p. Numero 13.ISSN 1794-1237
58
varios artefactos entregables, quienes a su vez cada uno tiene asignado un
identificador. Finalmente esta plantilla permite realizar una evaluación consistente
y objetiva hacia el atributo de usabilidad.
Adicionalmente, se cuenta con unos actores involucrados en cada etapa del

proceso de desarrollo de software, los cuales a su vez tienen asignados unas
responsabilidades con respecto a los artefactos establecidos.
Para la propuesta, cada etapa genera unos resultados, los cuales se toman como
entradas para la etapa siguiente. Donde dicho ciclo de desarrollo se toma de
forma cíclica e iterativa, beneficiándose por las retroalimentaciones que se
generan por cada ciclo de ejecución.
En esta propuesta para el evaluador, se valoran las características de usabilidad

de la plantilla, según el nivel de realización o nivel de cumplimiento desde 1 – poco
importante, hasta 5 – Fundamental. No se define como nivel de cumplimiento
valorado 1 o 0, es decir, un si cumple o no cumple, puesto que esto es radical,
generando resultados imprecisos. Además para el evaluador se asigna un peso a
cada característica de usabilidad de la plantilla, según el nivel de importancia,
desde 0 – La característica no se cumple en absoluto, 100 – La característica se
cumple por completo, proporcionando un indicador de cada característica
evaluada desde el punto de vista de los evaluadores de la interfaz.
Con la justificación de la calificación se busca hallar las causas de las valoraciones

altas, bajas, según el nivel de cumplimiento y la ponderación de importancia
asignada por el usuario.
59
Tabla 11. Esquema general de las listas de chequeo modificadas.
Característica de Ponderación de Nivel de

usabilidad por importancia 1 (poco), 5 cumplimiento Justificación
comprobar (fundamental) (0 -100)
Pregunta que Opción 1
.
indaga sobre el .
cumplimiento de .
una características Opción N
de usabilidad
Fuente: Revista de la Escuela de Ingeniería de Antioquia, en [8].
60
Tabla 12. Tareas y artefactos de usabilidad propuestos.
Tareas de usabilidad Artefactos entregables

Ingeniería de requisitos (Análisis del negocio, especificación de requisitos
funcionales y no funcionales, validación de requisitos)
Modelado para la especificación del
Revisión de escenarios actuales o
contexto de uso (MEC)
deseados (usuarios, tareas, ambientes)
Lista de características de usabilidad para
Descripción de características de
tener en cuenta dentro del desarrollo
usabilidad deseadas
(LCU)
Definición de las funciones del software
Documento de requisitos validado
con mayor impacto en las tareas de los
teniendo en cuenta aspectos de
usuarios
usabilidad (DRV)
Definición de requisitos de uso y su
Documento de priorización de requisitos
validación
de usabilidad del producto (DPR)
Análisis y diseño (Subsistemas, componentes, módulos de software, diseño de
Diseño de escenarios y tareas de los Especificación funcional del producto con
usuarios (diseño de interacción) énfasis en el diseño detallado de la
Diseño de la ayuda interacción (EF)
Diseño de listas de chequeo de Diseño de la interfaz de usuario (DIU)
usabilidad (Plantillas) Plantillas de las listas de chequeo (PLC)
Codificación y pruebas (Código fuente, ejecución de pruebas de los
Reporte de la evaluación de usabilidad
Implementación de las interfaces de
realizada por los desarrolladores (REUD)
usuario
Diagnósticos de los defectos de
Validación de los prototipos del
usabilidad (DDU)
software contra la especificación,
Lista de inconformidades para ser
utilizando las listas de chequeo y la lista
depuradas (LID)
de características de usabilidad para
Interfaz de usuario validada y depurada
tener en cuenta
(IUV)
Pruebas con usuarios (Ejecución de pruebas α y β con usuarios seleccionados)
Resultados de las pruebas de usabilidad
realizadas por los usuarios (RPUU)
Validación de funciones teniendo en
Diagnósticos de los defectos de
cuenta aspectos de usabilidad utilizando
usabilidad (DDU)
listas de chequeo
Lista de inconformidades para ser
depuradas (LI)
Verificación (Verificación funcional, verificación del producto, verificación del
Resultados de las evaluación de
usabilidad realizadas por los auditores
Verificación de funciones teniendo en del sistema (REUA)
cuenta aspectos de usabilidad utilizando Diagnósticos de los defectos de
listas de chequeo usabilidad (DDU)
Lista de nuevos requisitos de usabilidad e
inconformidades (LI)
61
3.4 ANÁLISIS DEL PAPEL ASIGNADO A LAS PRUEBAS NO FUNCIONALES EN
LAS METODOLOGÍAS ÁGILES Y EN LAS METODOLOGÍAS TRADICIONALES.
3.4.1 Pruebas no funcionales según Metodologías ágiles. Las metodologías

agiles asigna más responsabilidades a su grupo de trabajo y una continua
comunicación con el cliente, donde este brinda una colaboración. Esto se debe
para tener una mejor efectividad en el desarrollo de los proyectos.
Lo que se busca con estas metodologías ágiles es que se adapte a ambientes

donde se presenten requerimientos cambiantes y los tiempos de entrega sean
demasiado cortos, manteniendo así una alta calidad en sus productos. Estas
metodologías agiles son muy criticadas por las personas que aun manejan
metodologías tradicionales.
Las metodologías tradicionales se caracterizan por ser muy rígidas y por su alta
documentación en cada una de las actividades desarrolladas.
El software sin documentación es un desastre, tanto en las metodologías ágiles

como tradicionales, en donde las primeras documentan los procesos, si estos
son de vital importancia, los cuales deben ser cortos y centrarse en lo
fundamental.
Las metodologías ágiles se encuentran orientadas más al cliente que a los

procesos.
XP es una las metodologías ágiles que han tenido gran a aceptación en el mundo
de desarrollo de software, donde se cuenta con cuatro variables que son costo,
tiempo, calidad y alcance.
No hay una metodología, ya sea ágil o tradicional que proporcione una total
garantía en el desarrollo de un proyecto de software cualquiera, debido a que se
tiene que observar el ambiente donde se va a desarrollar este.
Existen varias diferencias entre las metodologías agiles y las metodologías

tradicionales las cuales se muestran a continuación:
62
Tabla 13. Diferencias entre metodologías ágiles y metodologías tradicionales.
Metodologías Ágiles Metodologías Tradicionales

Basadas en heuristicas
provenientes de practicas de Basadas en normas provenientes
producción de código. de estándares seguidos por el
entorno de desarrollo.
Especialmente preparadas para Cierta resistencia a los cambios.
cambios durante el proyecto.
Impuestas internamente ( por el Impuestas externamente

equipo de desarrollo).
Procesos menos controlados, con Procesos mucho mas controlado,

pocos principios con numerosas politicas/normas
No existe contrato tradicional o al Existe un contrato prefijado.

menos es bastente flexible.
El cliente es parte del equipo de El cliente interactúa con el equipo

desarrollo de desarrollo mediante reuniones.
Grupos pequeños (<10 Grupos granddes y posiblemente

integrantes) y trabajando en el distribuidos.
mismo sitio.
Pocos artefactos. Más artefactos.
Pocos roles Más roles.
Menos énfasis en la arquitectura La arquitectura del software es

del software. esencial y se expresa mediante
modelos.
Fuente: Metodologías ágiles para el desarrollo de software: eXtreme Programming, en [9].
-Pruebas no funcionales según Metodología ágil XP (Programación Extrema)
Metodología centrada en el trabajo en equipo, promovido por un buen clima

laboral, excelente comunicación, sencillez para la codificación, y preocupación en
el crecimiento personal de los profesionales implicados en el proyecto. XP busca
que haya una mejor interacción con el cliente, con cual se debe estar en constante
comunicación.
XP se desenvuelve bastante bien en proyecto donde sus requerimientos son

cambiantes e imprecisos.
63
Para XP las pruebas son inseparables del desarrollo42, y es por ello que XP
sugiere que a lo largo del ciclo de desarrollo se realicen test continuos, de tal
forma que sea posible la adaptación del producto a los cambios solicitados por el
cliente, y por tanto define que:
1. Desarrollado previamente probado

2. Desarrollo de pruebas incremental a partir de los escenarios
3. Participación del usuario en el desarrollo de las pruebas y en la validación
4. El uso de bancos de pruebas automatizados
Encargado de pruebas (Tester)
―El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.

Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para pruebas.‖ 43
Encargado de seguimiento (Tracker)
―El encargado de seguimiento proporciona realimentación al equipo en el proceso

XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado, comunicando los resultados para mejorar
futuras estimaciones
.
También realiza el seguimiento del progreso de cada iteración y evalúa si los
objetivos son alcanzables con las restricciones de tiempo y recursos presentes.
Determina cuándo es necesario realizar algún cambio para lograr los objetivos de
cada iteración.‖ 44
Programación dirigida por las pruebas (―Test-driven programming‖)
42
SOMMERVILLE, Ian. Ingeniería de software. Séptima Edición. Madrid, España: Pearson Educación S.A, 2005. 677 p
43
Metodologías ágiles para el desarrollo de software: eXtreme Programming (XP).Web -
http://www.willydev.net/descargas/masyxp.pdf
44
Metodologías ágiles para el desarrollo de software: eXtreme Programming (XP).Web -
http://www.willydev.net/descargas/masyxp.pdf
64
Ya sean pruebas funcionales o no funcionales en las metodologías ágiles como
XP se cuenta con un diseño de pruebas bien estructurado antes de comenzar a
desarrollar el producto, luego de esta fase el programador empezará a desarrollar
la aplicación donde tendrá que hacer un esfuerzo para que su software pase el
nivel requerido al aplicarse las pruebas diseñadas, es por esto que facilita al
desarrollador a moldearse a los requerimientos que el cliente exige.
Estas pruebas a las que se enfrenta el aplicativo desarrollado, son las pruebas
unitarias, las cuales son diseñadas por otro integrante del equipo, donde cada
módulo tiene que realizarlas para lograr su posterior liberación.
- Detección y corrección de errores
Cuando se encuentran un error (bug), inmediatamente es corregido por el equipo

desarrollador, teniendo en cuenta la prevención de no volverlos a cometer. Luego
de que el error fue eliminado se generan más pruebas para determinar si este fue
eliminado en su totalidad.
- Pruebas de aceptación
Estas se consideran como pruebas de caja negra, donde se ingresan unos datos
y se esperan unas determinadas salidas. En esta prueba se espera que el cliente
sea que verifique si los resultas son los esperados. Si se hallan fallas en los
resultados se deberá indicar cual tiene mayor prioridad, sin obviar a las otras. El
fallo de estos resultados se debe informar al equipo para que tengan en cuenta lo
sucedido.
3.4.2 Pruebas no funcionales según metodologías tradicionales
- Metodología Rational Unified Process (RUP)
Esta metodología se encarga de delegar tareas y responsabilidades su

organización de desarrollo de software, contando con un numeroso grupo de
programadores. Lo que se busca con RUP es tener un software de alta calidad
65
donde se satisfaga las necesidades de los clientes, con un calendario establecido
y unos costos predecibles.
Los procesos de esta metodología valoran las tareas y el calendario a través de la

velocidad de iteraciones de acuerdo a las estimaciones originales.
RUP cuenta con grandes ventajas frente a XP donde se hace realce en los
requerimientos y su diseño. Su principal ventaja es que cuenta con buenas
prácticas las cuales se prueban en el área desarrollada, contrario a XP ya que sus
prácticas son inestables.
La metodología RUP cuenta con cuatro fases las cuales son45:
-Inicio: en esta se define el alcance del proyecto.

-Elaboración: definición, análisis y diseño.
-Construcción: implementación.
-Transición: fin del proyecto y puesto en producción.
Las fases de RUP se pueden descomponer en iteraciones, entendiéndose en este

caso por iteración el ciclo de desarrollo completo en donde se obtendrá como
resultado una aplicación ya sea interna o externa.
45
Metodología Rational Unified Process (RUP). Web -
http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/RUP%20vs.%20XP.pdf
66
Figura 9. Iteraciones de RUP
Fuente: Metodología Rational Unified Process (RUP), en [10]
Figura 10. Miembros del equipo de RUP.
Fuente: Metodología Rational Unified Process(RUP), en [10]
67
Características de RUP
-Cuenta con un detallado orden en el levantamiento de requerimientos.

-Busca defectos en sus fases iníciales.
-Procura disminuir en gran medidas los cambios.
-Sigue un orden total en el análisis y diseño.
-Las necesidades que presentan los clientes no son fáciles de comprender.
-Una de las grandes diferencias con XP, es que se reúne con los clientes con citas
formales, mientras que en XP hace parte del equipo de desarrollo.
Los Test en esta evalúan la calidad que tiene el producto desarrollado, ―El papel
del testeo no es asegurar la calidad, pero sí evaluarla, y proporcionar una
realimentación a tiempo, de forma que las cuestiones de calidad puedan
resolverse de manera efectiva en tiempo y coste.‖46
Los aspectos de fiabilidad, funcionalidad y el rendimiento, son algunos de los que

busca RUP evaluar en los productos.
3.4.3 Metodología de pruebas en V
Figura 11. Relaciones entre productos de desarrollo y niveles de prueba.
Fuente: Metodología Rational Unified Process, en [10]
46
Metodología Rational Unified Process (RUP).Web-http://www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Trabajo-
Guia%20RUP.pdf
68
Este modelo tiene una gran ventaja por su intuición, ya describe los procesos del
ciclo de desarrollo contando en cada una de sus fases, con diferentes clases de
pruebas, es decir, se realiza el análisis y el desarrollo en paralelo con las pruebas.
El modelo V empieza por los requerimientos de los usuarios y a la vez se van

determinando los casos de prueba de aceptación que este va a tener, en la
siguiente fase del modelo se establece si cumple con las especificaciones y se
define cuales serán los primeros casos de pruebas de sistemas que se harán en
esta fase, ya cuando se a cumplido con la fase anterior se pasara a la próxima, la
cual es la fase de de modularidad del diseño y se generara un bosquejo de los
casos de pruebas de integración, luego de pasar todas las otras fases
mencionadas con sus respectivos casos de pruebas se analizaran los algoritmos y
establecerán los casos de prueba de unidad.
Una de las desventajas que tiene este modelo es que es muy detallado, en donde
la documentación que debe tener es demasiada y puede generar inconsistencias,
debido a los cambios que pueden generar los proyectos, siendo tedioso y
complicados corregirlos.
69
4. METRICAS PROPUESTAS PARA LA MEDICIÓN DE LOS REQUERIMIENTOS
NO FUNCIONALES.
4.1 RECOPILACIÓN DE MÉTRICAS PARA ATRIBUTOS DE CALIDAD VISTOS

COMO REQUERIMIENTOS NO FUNCIONALES
Antes de iniciar se plantea la siguiente cuestión, ¿Por qué se mide un atributo de

calidad software implicado como un requerimiento no funcional?, la respuesta es
sencilla, porque se requiere verificar en qué grado satisface las necesidades del
cliente.
Como se requiere verificar el grado de satisfacción, es necesario medir ese valor

agregado que ofrecen las pruebas a los atributos de calidad, vistos como
requerimientos no funcionales, puesto que ―cuando puedes medir lo que estás
diciendo y expresarlo en números, sabrás algo acerca de eso; pero cuando no
puedes medirlo, cuando no puedes expresarlo en números, tus conocimientos
serán escasos y no satisfactorios‖47, es decir, que no basta con decir qué
beneficios proporcionan las pruebas a atributos no funcionales, sino también es
necesario conocer el valor aproximado que aporta cada atributo de la calidad al
producto software.
Es por ello que se pretende con la recopilación de métricas llegar a un

acercamiento de valoración de los atributos no funcionales, luego de aplicársele
pruebas, siendo continua su valoración durante el ciclo de vida del software, pero
no en todo momento, puesto que se torna complejo y exhausto. Se busca que sea
independiente de la metodología de desarrollo, para así determinar el nivel de
aporte a la calidad que ofrecen dichos atributos al aplicársele las pruebas.
Es pertinente también recordar la dificultad para definir medidas adecuadas a cada

atributo de calidad, asociado a requerimientos no funcionales, sin embargo para
este estudio se tomaron como base las medidas establecidas por Ian Sommerville,
y Pressman.
47
LORD, kelvin
70
Se trae como referencia algunas métricas para la medición, y adicionalmente se
decide fragmentar cada atributo en características más pequeñas, tomando como
referencia la ISO/IEC 9126.
Se aclara que no es fácil definir las características para cada atributo, cuando
cada uno tiene una concepción diferente, dependiente del contexto en el que se
interprete, sin embargo, de forma global se presentan los más generales en la
tabla 14.
71
Tabla 14. Atributos de calidad fragmentados en características.
Atributo de calidad como RNF Concepto medible y evaluable

Operabilidad
Aprendizaje (Tiempo de formación)
Atractividad
Comprensibilidad (Número de ayudas)
Analizabilidad
Facilidad de cambio
Mantenibilidad
Facilidad de prueba
Estabilidad
Recuperabilidad
Frecuencia de fallas (Tiempo medio entre fallos)
Fiabilidad
Disponibilidad (Porcentaje de no disponibilidad)
Severidad de fallas (Tasa de ocurrencias de fallos)
Adaptabilidad
Instalabilidad (Número de sistemas operativos o
navegadores sobre los que funciona)
Portabilidad
Facilidad de adaptación al cambio
Peso del aplicativo (Kbytes)
Co - existencia
Tiempo de respuesta por transacción (promedio,
máximo)
Desempeño (Número de usuarios activos que permite
el sistema)
Tráfico generado en las comunicaciones ( cantidad de
Eficiencia datos que pueden ser transferidos en un segundo)
Tiempo de recuperación a fallas
Utilización de recursos (Memoria)
Rendimiento (Transacciones procesadas por segundo)
Tiempo de actualización de interfaces
72
4.2 MÉTRICAS PARA VALIDAR LOS REQUISITOS NO FUNCIONALES
Aunque sea reiterativo, es importante recordar la dificultad para cuantificar el nivel

de cumplimiento de los requerimientos no funcionales, y en sí, del aporte a la
calidad del software de esto, ya que éstos generalmente se cuantifican de forma
subjetiva; sin embargo a continuación se describen algunas métricas para
cuantificar dichos atributos de calidad vistos como requerimientos no funcionales.
A continuación se describen algunas métricas establecidas para cuantificar los

cinco factores, usabilidad, eficiencia, fiabilidad, portabilidad, mantenibilidad, los
cuales generalmente son utilizados como medidas indirectas, haciendo parte de
una excelente lista para determinar su aporte a la calidad del software.
4.2.1Usabilidad. Para evaluar y medir éste atributo, se deben principalmente

realizar checklist sobre los ítems que se encuentran a continuación, para luego
ponderar y definir un nivel de calidad y cumplimiento con respecto a los
requerimientos iníciales establecidos.
Evaluar interfaces graficas de usuarios (IGU)
Evaluar prototipos de Interfaces de Usuario: Cada uno de los prototipos de

Interface de usuario representa un ejemplo de la interface de usuario que será
construida para el sistema. Estos prototipos sirven para validar el diseño de la
interface de usuario.
Evaluar la compatibilidad de interfaces entre componentes del software.
Encontrar errores de interfaces
73
Tabla 15. Esquema general de las listas de chequeo modificadas.
Característica de Ponderación de Nivel de

usabilidad por importancia 1 (poco), 5 cumplimiento Justificación
comprobar (fundamental) (0 -100)
Opción 1
Pregunta que .
indaga sobre el .
cumplimiento de .
una características Opción N
de usabilidad
4.2.2 Fiabilidad. Lo que busca la fiabilidad es que el software se encuentre

funcionando de manera consistente y en forma correcta durante el tiempo que se
necesita emplearlo, y logrando que este si este falla, su facilidad de recuperación
sea ágil y fácil
Los usuarios que utilizan el aplicativo desarrollado buscan tener un software que
su funcionamiento sea el adecuado, mientras los desarrolladores además de que
su funcionamiento sea el correcto, también esperan que el números de fallos
presentados puedan ser solucionados sin causar problemas al sistema mientras
se realizan las pruebas, haciendo que crezca la confiabilidad en el software.
La confiabilidad en relación con la incertidumbre, es tomada de tipo -1

(incertidumbre), en donde nos muestra la utilización del sistema, es por ello, que
en un determinado instante de tiempo hasta la próxima falla es incierto y lo cual
se tomara como una variable aleatoria.
En el estudio de una variable aleatoria se utiliza la distribución exponencial

encausada en las pruebas que tenga fallas cero, derivando una función de cifras
de fallas, suponiendo que el número de fallas en el t debe ser igual:
a = constante
74
b = constante
Con ello se puede determinar el número de horas que se deben probar para
satisfacer los objetivos propuestos por la confiabilidad, es por ello, que se
establecen 3 entradas:
- Número proyectado promedio de fallas (fallas)

- Número total de fallas observadas en las pruebas (fallas probadas)
- Número total de horas de ejecución de pruebas hasta la última falla.
Fórmula de las horas necesarias de prueba para cero fallas
Ln[(fallas)/(0,5 + fallas)] * (horas hasta última falla)

Ln[(0,5 + fallas) / (fallas probadas + fallas) ]
4.2.3 Portabilidad. Es la facilidad del software para ser utilizado de una plataforma
a otra, la cual cuenta con unos determinados atributos, entre ellos están la
facilidad de instalación, ajuste, adaptación a los cambios
La facilidad de instalación puede ser la medida de acuerdo a la siguiente relación:
X=A/B
A: es el número de instalaciones exitosas que el usuario realizó.

B: es el número total de instalaciones que realizó el usuario.
4.2.4 Mantenibilidad. El índice de madurez de software (IMS) establecido por la

IEEE 982.1-1988 determina la estabilidad de un producto de software basada a los
diferentes cambios presentados durante las versiones.
Variables del índice de madurez de software (IMS):
75
-MT = Número de módulos en la versión actual.
-Fc = Número de módulos en la versión actual que se han cambiado.
-Fa = Número de módulos en la versión actual que se han añadido.
-Fe = Número de módulos en la versión actual que se han eliminado.
Fórmula del índice de madurez del software:
IMS= [MT - (Fc + Fa + Fe)]/MT
A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar 48
4.3 PROPUESTA DEL MÉTODO DE EVALUACIÓN DE LOS REQUERIMIENTOS

NO FUNCIONALES.
El método propuesto está orientado a fortalecer la calidad del producto de

software que se desarrolla, de manera independiente de la metodología. El
método pretende ser aplicado a lo largo del ciclo de vida del desarrollo, buscando
ser lo más sencillo posible, y de forma iterativo.
A lo largo del ciclo de vida del desarrollo se definen unas actividades específicas
por cada etapa del ciclo de vida del desarrollo, respetando la metodología o
modelo de desarrollo:
4.3.1 Fase 1. Levantamiento de requerimientos.
1. En esta se deben registrar y documentar:
2. Se debe identificar los requerimientos funcionales de los no funcionales sin

desligarlos obligatoriamente de los funcionales, puesto que de muchos
48
PRESSMAN, Roger S. Ingeniería del software. Un enfoque práctico. Sexta Edición. Estados Unidos: McGraw Hill, 2005.
900 p.
76
requerimientos funcionales parten los no funcionales, es por ello, que se deben
diferenciar mas no aislarlo uno del otro si no es necesario.
En esta etapa se aplican pruebas estáticas como lo son las inspecciones,

revisiones y/o walktroughs
4.3.2 Fase 2. Análisis
1. Cada requerimiento debe ser especificado de forma clara, consistente,

verificable, cuantificado en cifras verídicas, medibles y reales. De tal forma que no
queden abiertos a un amplio rango de interpretaciones subjetivas, es decir,
evitando dejarlos registrados en términos pobres, ni difusos.
Específico: sin ambigüedad, usando terminología consistente, simple y con el

apropiado nivel de detalle.
Medible: es posible verificar que el requerimiento ha sido encontrado. Entonces,

¿qué tests deben ser realizados? ¿O qué criterio debe tomarse para verificar que
se encuentra el requerimiento?
Accesible: se refiere a técnicamente factible. Cabe la pregunta ¿cuál es su juicio

profesional sobre la ―habilidad técnica para hacer‖ del requerimiento?
Realizable: es realista, si se dan los recursos
Rastreable (ubicable): se lo puede vincular desde su concepción (a través de su

especificación), a su diseño siguiente, implementación y test.
77
Puesto que cuando un requerimiento no funcional no está especificado en valores
medibles, es difícil saber si será realizable y verificable.
2. Clasificarlos por categorías, según correspondan a los siguientes atributos de

calidad software:49
- Usabilidad
- Fiabilidad
- Eficiencia
- Mantenibilidad
- Portabilidad
3. Priorizar los requerimientos no funcionales según las perspectiva del

stakeholder, ya que se deben identificar que requerimientos.
En esta etapa se aplican pruebas estáticas como lo son las inspecciones,

revisiones y/o walktroughs.
4.3.3 Fase 3. Diseño
1. Partiendo de la documentación de los requerimientos no funcionales, se

procede en esta fase a la modelación de éstos en casos de uso extendido para
los requerimientos no funcionales.
49
DIGIÓN DE GRIMALDI, Leda Beatriz. Departamento de Informática. Fac. de Ciencias Exactas y Tecnologías,
Universidad Nacional de Santiago. del Estero. Belgrano 1900. Santiago del Estero (CP. 4200).
78
Tabla 16. Modelo de caos de uso para requerimientos no funcionales.
Caso de uso # identificar el caso de uso a partir de un numero de referncia

Se refiere al objetivo a cumplirse a traves del caso de uso y las
Descripcion
fuente de requerimiento.
Actores Se define una lista de actores que participan en el caso de uso
Son las condiciones que deben ser verdaderas para el caso de
Suposiciones
uso se ejecute con el éxito.
Son las acciones interactivas necesarias entre los actores y el
Pasos
sistema para que se alcance el objetivo.
Variaciones
Indica cualquier variacion de los pasos en el caso de uso.
(Optativo)
Define la lista de requerimientos no funcionales que el caso de
uso debe reconocer. Los requerimientos no funcionales se
listan en la forma:
No funcionales <palabra-clave>:<requerimiento>, donde palabra-clave incluye
(pero no está limitado) a Perfomance, Confiabilidad, Tolerancia
de falla, Frecuencia, Prioridad. Cada requerimiento se expresa
en lenguaje natural o con un formalismo apropiado.
Aspectos Se refiere a situaciones puntuales pendientes de resolver
Fuente: Un estudio inicial de requerimientos no funcionales a través del caso de uso, en [11]
2. Priorizar los casos de usos para así definir los elementos críticos a probar.
3. Partiendo del diseño de casos de uso extendidos, se registra y documenta el

diseño de los casos de pruebas, mínimamente uno por cada caso de uso,
definiendo con el líder de calidad el número de máximo o limite de casos de
prueba a diseñar, buscando no tornar a un proceso complejo y exhausto
4.3.4 Fase 4. Implementación
En esta fase como se cuenta con un producto o módulo, se realizan pruebas

cortas que fueron diseñadas en la etapa anterior, es decir, se ejecutan teniendo en
79
cuenta que en su diseño se categorizó dependiendo del atributo de calidad a
evaluar, para verificar el nivel de cumplimiento de los requerimientos no
funcionales.
4.4 DEFINICIÓN DEL MÉTODO DE EVALUACIÓN.
En cada etapa del desarrollo se debe ejecutar los siguientes pasos del método, y
desempeñado por los roles que se describen a continuación:
4.4.1 Roles y responsabilidades
Líder de calidad
Analista de sistemas. Encargado de la administración y especificación de

requerimientos, modelado del negocio
Ingeniero desarrollador. Encargado de codificación del aplicativo, definiendo el

alcance de los módulos del proyecto o del producto software,
Analista de pruebas. Encargado de realizar las actividades del método

propuesto para la evaluación de los requerimientos no funcionales, ejecutando las
pruebas con regularidad y difundir los resultados al equipo de desarrollo
Cliente. Establece y define la prioridad de los requerimientos no funcionales a

implementar, según al beneficio a recibir de los mismos, de tal forma que quedan
para futuras iteraciones los que sean menos impactantes para el sistema y que se
determinen como críticos.
Adicionalmente, se tienen en cuenta que en cada etapa del desarrollo se tienen

los siguientes suministros:
80
Figura 12. Método propuesto para la evaluación de los atributos no funcionales.
4.4.2 Planificación de las pruebas. Inicialmente describe las metas y objetivos

para cada iteración del ciclo de pruebas, teniendo en cuenta los elementos a
probar, asignación de recursos requeridos y finalmente obtener la documentación
recopilada de la ejecución de las pruebas realizadas según la fase del desarrollo,
tal como se definió anteriormente.
A continuación se define los pasos y documentación entregable
81
- Definir el Propósito, es necesario leer la documentación recolectada del sistema
solicitado
- Definir el alcance
Establecer artefactos o elementos a probar y priorizarlos, es decir, determinar
según el impacto sobre el aplicativo si ocurriese un error de determinado atributo
- Definir objetivos de la evaluación

- Definir un cronograma
Estimar el cronograma, dentro del cual se definan tiempo por validación de cada
componente o producto elegido
- Identificar las características del ambiente de pruebas
Este se debe establecer de acuerdo al ambiente final en el que se deberá

implantar el producto, por ende, el ambiente de pruebas debe ser lo más exacto
posible al real
Se realiza la planeación para validar los elementos, de tal forma que se asegure
que el producto o componente sea apropiado para ser liberado a producción.
4.4.3 Diseño de las pruebas
- Diseñar los casos de pruebas a aplicar o en su defecto las inspecciones,

revisiones a realizar, especificando los resultados esperados.
-Definir criterios de validación, teniendo en cuenta las características de los

productos a validar, y las restricciones del cliente
- Definir criterios de finalización de la validación
82
Se debe establecer el plan de pruebas, de tal forma que se limite el tiempo y se
evite incrementar costos por falta de planeación del tiempo.
4.4.4 Ejecución de las pruebas. Se aplican las pruebas con los datos que se
tienen.
4.4.5 Análisis de los resultados. En esta etapa se deben analizar los resultados de
las evaluaciones propuestas, según la categoría y se compara con los resultados
esperados, para determinar un nivel de cumplimiento
-Resumen de evaluación de pruebas

Al finalizar la ejecución de las pruebas planeadas y diseñadas, se organizan en un
documento, de tal forma que se le presenta el análisis de los resultados de las
pruebas, como también los casos de pruebas usados y las métricas utilizadas para
definir si pasaba o no las pruebas.
4.4.6 Validar criterios de aceptación. Se analizan los resultados uno por uno,
determinando que va y que no va. Después se analizan todos los resultados para
determinar si se puede aceptar o no, los requerimientos no funcionales en el
software, éstos deben ser aceptados por el cliente final, quien evalúa los
entregables por cada iteración de pruebas.
Todo debe quedar registrado en un reporte donde se tenga constancia de cuáles

fueron los errores habidos y su posible falla, así dando a conocer al desarrollador
cuales fueron las inconsistencias presentadas durante la etapa de pruebas.
4.4.7 Certificación
-Actividades de cierre: gestión de las pruebas.
83
Los ciclos de pruebas deben estar coordinados con los ciclos de desarrollo,
porque esto puede causar un retraso en el producto del software y por ende va en
detrimento de la percepción del cliente.
Los atributos no funcionales se conocen como características de calidad, las

cuales se deben tener en cuenta tanto al diseñar como al implementar el software.
Por ende en el presente documento, se propone un modelo que sirva de
orientación hacia la evaluación de éstos, que a su vez afectan la calidad del
software desarrollado.
Las siguientes fases propuestas, se deben realizar a lo largo del ciclo de vida del
producto o componente, independiente de la metodología de desarrollo.
4.5 AUTOMATIZACIÓN DE PRUEBAS A ATRIBUTOS NO FUNCIONALES,

USANDO HERRAMIENTAS PARA LA EVALUACIÓN DE LOS ATRIBUTOS
Debido a que las pruebas manuales son exhaustivas y por tanto toman tiempo en
su aplicación, requiriendo además recursos en personal, reprocesos en máquina,
entre otros. Se recomienda la utilización de herramientas libres disponibles para
reducir tiempos en ejecución de pruebas a atributos no funcionales:
Tabla 17. Herramientas.
Aspecto a medir Herramientas

Estaticas
SONAR,Maven,Hudson,PMD,C
Pruebas
Calidad de Codigo heckStyle,SourceMonitor
Seguridad Yasca Reports,FindBugs

Funcionales TestLink
Dinamicas
Pruebas
Strerss y rendimiento Jmeter,Selenium

Seguridad Acunetix,ParosProxy
Regresion QTP
Gestion de incidencias y de JIRA
Otras
demanda
Reporting OHM QA Portal,Excel,ppt.
84
-Yasca Reports: es una herramienta que busca cuales son las vulnerabilidades en
la seguridad, la calidad del código, su rendimiento, sus informes los genera en
html,xml , entre otros formatos
-TestLink: esta herramienta permite generar y gestionar casos de pruebas,

lográndose hacer un seguimiento de los resultados obtenidos a través de la
prueba en una forma dinámica. Con esta herramienta se permite determinar los
requerimientos e indicar el orden y la asignación de tareas que se tengan.
-JMeter: es una herramienta realizada como proyecto de Apache Jakarta

encargada para la realización de pruebas de carga, donde se mide y se analiza la
eficiencia y el desempeño de las aplicaciones a probar, siendo una herramienta
que hace su mayor énfasis a aplicaciones web.
-Selenium: permite realizar grabaciones, editar y la depuración de pruebas. Esta

herramienta es una extensión de Firefox. Las pruebas generadas las guarda en
formato HTML, script de Ruby o en cualquier otro formato. Las pruebas realizadas
con Selenium son compatibles con muchos browser, con pruebas de regresión,
sirve de apoyo a metodologías ágiles, su documentación es disciplinada con los
casos de pruebas.
-Acunetix: encuentra los posibles fallos y vulnerabilidades que no permitan el buen

funcionamiento de la web en su seguridad, también comprueba el estado del
servidor. Esta herramienta informa como pueden ser reparados las posibles fallas
encontradas en su ejecución.
-ParosProxy: esta herramienta sirve para evaluar la seguridad en aplicaciones web

y se encuentra escrito en java
-QTP (Quick Test Professional): se centra en la calidad de sus productos haciendo

automatización de pruebas de regresión. Esta herramienta por lo general se
85
utiliza en interfaces graficas de los usuarios teniendo en cuenta la automatización
de los casos de prueba.
-JIRA: hace un completo seguimiento a proyectos y problemas de software con el
fin de mejorar la calidad y su desempeño del software. JIRA es utilizado en
algunas compañías como eje central en un grupo de desarrolladores.
-Excel: es una aplicación en la cual hace referencia al manejo de hojas de

cálculos, en donde su función es la realizar tareas de reportes, estadísticas,
financieras, contables, matemáticas, entre otras funciones. Esta herramienta fue
desarrollada por el equipo de Microsoft.
-PPT (Microsoft PowerPoint): fue desarrollada por Microsoft, se utiliza para hacer
presentaciones con imágenes, audio y texto. Las funciones de esta herramienta
son varias, pero el en caso de pruebas no funcionales se tiene como fin el de
mostrar informes a los desarrolladores, tester, clientes y personas que tengan que
ver con el producto de software a desarrollar.
86
5. CONCLUSIONES Y RECOMENDACIONES.
Durante proceso de desarrollo del producto de software, se debe realizar la

documentación y registro de requerimientos no funcionales, para determinar el
impacto sobre el aplicativo si ocurriese un error de determinado atributo.
Se debe estar abiertos a las expectativas de los clientes, definiendo y evaluando

las características de los requisitos funcionales y no funcionales, para definir: si
son o no realizables, su claridad, conveniencia, pertinencia, etc.
Cuando un equipo de desarrollo realiza pruebas intensivas, con los estándares

de codificación, se empezará a tener un producto de calidad más rápido y más
seguro.
Se debe evitar la tentación de entregar el trabajo más rápido, omitiendo procesos

de pruebas. Entregas de producto con fallos, repercutirá en la confianza de los
clientes.
Las empresas desarrolladoras de software se deben concientizar que las pruebas

no funcionales son parte fundamental en el impacto del producto final. Los errores
detectados a tiempo pueden evitar el incremento de costos, los cuales afectan
directamente a la organización.
El proceso de pruebas genera costos, por tanto se debe seleccionar de manera

cuidadosa tanto las pruebas a realizar, como los componentes a probar. Esto es
posible determinarlo, con base en la importancia de las piezas de software en el
producto final.
No se encuentra una diferencia significativa en el empleo de las herramientas y

técnicas que se utilizan para la realización de pruebas funcionales o no
funcionales, entre metodologías ágiles y robustas.
87
No todas las pruebas se pueden aplicar a los proyectos de software, lo que se
busca es tener un software de alta calidad y que las empresas desarrolladoras
aumenten su prestigio.
Las pruebas no aseguran la ausencia de errores, sólo demuestran que existen

defectos en el software, para así ser corregidos por los desarrolladores.
Como recomendaciones finales, se proponen:
Es evidente la ausencia de profesionales recién egresados de las universidades

colombianas, que se encuentren capacitados en estos temas; lo cual, no sólo
genera desmotivación por parte de los empresarios que requieren personal en
esta área, para solicitar egresados de las universidades, sino que prefieren traer
profesionales de otros países latinoamericanos.
En el programa de Ingeniería de sistemas y computación, se debería enfatizar y

no sólo perfilar profesionales capacitados en codificación y desarrollo, sino en
profesionales con habilidades de Ingenieros de software, analistas de calidad del
software y probadores (tester).
88
BIBLIOGRAFÍA
[1]. SOMMERVILLE, Ian. Ingeniería de software. Séptima Edición. Madrid,

España: Pearson Educación S.A, 2005. 677 p.
[2]. PRESSMAN, Roger S. Ingeniería del software. Un enfoque práctico. Sexta

Edición. Estados Unidos: McGraw Hill, 2005. 900 p.
[3]. REVISTA ESPAÑOLA DE ELECTRÓNICA. (Número 550: 2000: Pág. 90).

Ingeniería del software y pruebas. María del Mar Aguilar Fernández.
[4].PLAN DE PRUEBAS. Internet (www.ldc.usb.ve

<http://ldc.usb.ve/~teruel/ci4713/clases2001/planPruebas.html>)
[5]. Plantilla para caso de prueba. Internet (www.scielo.unal.edu.co

http://www.scielo.unal.edu.co/scielo.php?pid=S1692-
33242009000300004&script=sci_arttext )
[6].REQUISITOS NO FUNCIONALES. Internet (www.ecured.cu

<http://www.ecured.cu/index.php/Archivo: Requesitos_no_funcionales.JPG>)
[7].CALIDAD DE COMPONENTES SOFTWARE. Internet (www.eduardoleyton.com

<http://www.eduardoleyton.com/apuntes/ISO_9126_12207_UST.pdf>)
[8]. REVISTA EIA, ISSN 1794-1237. (Número 13: Julio 2010: Pág.131). Escuela
de Ingeniería de Antioquia, Medellín -Colombia.
[9]. Metodologias ágiles para el desarrollo de software: eXtreme Programming

(XP). Internet (www.willydev.net/descargas/masyxp.pdf
<http://www.willydev.net/descargas/masyxp.pdf>)
89
[10]. Metodología Rational Unified Process (RUP).Internet (www.usmp.edu.pe
<http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulosRUP%20vs.%20
XP.pdf>)
[11]. Un estudio inicial de requerimientos no funcionales a través del caso de uso.

Internet (Www.jidis.frc.utn.edu.ar/papers/141242db4850df4caa8b371faf07.pdf
< http://www.jidis.frc.utn.edu.ar/papers/141242db4850df4caa8b371faf07.pdf >).
[12]. Desafíos y oportunidades de la industria del software en América Latina.

Internet (www.eclac.org/publicaciones/xml/5/35655/Capitulo5.pdf
<http//: www.eclac.org/publicaciones/xml/5/35655/Capitulo5.pdf>)..[Marzo 2009].
[13]. Departamento Nacional de Planeación, agenda interna para la competitividad

y productividad sector software. Internet (www.dnp.gov.co<http www.dnp.gov.co
>).
[14]. ESI, European Software Institute, Numero de empresas certificadas en

CMMI. Internet (www.sei.cmu.edu. <http://www.sei.cmu.edu>).[Marzo 2009].
[15]. European Software Institute. Industrialización en la producción de software.

―Situación actual del desarrollo de software‖. España: Citado de (Jones & Curtis,
US DoD, Ben-Menachemand & Marliss). [2008].
[16]. Fedesoft, federación Colombiana de la industria del software y tecnologías

relacionadas. Internet (www.fedesoft.org /index.php/tic+colombia/newest.
<http://www.fedesoft.org/index.php/tic+colombia/newest.>) [Octubre 2008].
[17]. Fedesoft, federación Colombiana de la industria del software y tecnologías

relacionadas.Internet(www.dis.eafit.edu.co/EstrategiasTIC/attachments/193_Fedes
oft%20Colombia.pdf<http://www.dis.eafit.edu.co/EstrategiasTIC/attachments/193_
Fedesoft%20Colombia.pdf>). [Marzo 2006].
[18]. Instituto Colombiano de Normas Técnicas y Certificación. Presentación y

elaboración de trabajos y tesis de grado: compendio de normas técnicas
colombianas sobre documentación. Bogotá, ICONTEC 2008. 112 p. ISBN 958-
938-307-6
90
[19]. JOYANES AGUILAR, Luis. Investigación doctoral ―Modelo para la
industrialización del software en el triangulo del café- Colombia [Marzo 2009].,.
[20]. Lerma, Héctor Daniel; Metodología De La Investigación. Pereira.

Postergraph.1999. ISBN958-33-0913-3
[21]. University of Michigan-dearborn. (2007). Software engineering program.

Department of Computer and Information Science. Estados Unidos: College of
Engineering and Computer Science.
[22]. Circular externa 052 del 2007. Superintendencia financiera de Colombia.

Internet(netsecuritysuite.com/pdf/Norma-052.pdf
<http://www.netsecuritysuite.com/pdf/Norma-052.pdf>).
91

O15 I

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

O15 I

Cargado por

Copyright:

Formatos disponibles

IMPACTO DE LAS PRUEBAS NO FUNCIONALES EN LA MEDICIÓN DE LA

CALIDAD DEL PRODUCTO SOFTWARE DESARROLLADO

ALEJANDRO OCAMPO ACOSTA

UNIVERSIDAD TECNOLÓGICA DE PEREIRA

ALEJANDRO OCAMPO ACOSTA

Monografía para optar al título de Ingeniero de Sistemas y Computación

UNIVERSIDAD TECNOLÓGICA DE PEREIRA

Pereira, Octubre de 2011

Tabla 1.Requerimientos funcionales y no funcionales ........................................... 28

Tabla 2. Restricciones. .......................................................................................... 28

Tabla 3. Estándar de la IEEE 829-1983................................................................. 36

Tabla 4. Plantilla recomendada para caso de prueba. ........................................... 40

Tabla 5. Niveles de pruebas. ................................................................................. 42

Tabla 6. RFN fiabilidad. ......................................................................................... 50

Tabla 7. RFN portabilidad ...................................................................................... 51

Tabla 8. RFN eficiencia. ......................................................................................... 52

Tabla 9. RFN Mantenibilidad.................................................................................. 54

Tabla 10. RFN Usabilidad. ..................................................................................... 55

Tabla 11. Esquema general de las listas de chequeo modificadas. ....................... 60

Tabla 12. Tareas y artefactos de usabilidad propuestos. ....................................... 61

Tabla 13. Diferencias entre metodologías ágiles y metodologías tradicionales. .... 63

Tabla 14. Atributos de calidad fragmentados en características. ........................... 72

Tabla 15. Esquema general de las listas de chequeo modificadas. ....................... 74

Tabla 16. Modelo de caos de uso para requerimientos no funcionales. ................ 79

Tabla 17. Herramientas. ........................................................................................ 84

Figura 1. Tipos de requerimientos. ........................................................................ 27

Figura 2.Tipos de requerimientos de software. ...................................................... 27

Figura 3. Categorías de requerimientos no funcionales. ........................................ 29

Figura 4. Tipos de requerimientos no funcionales y sus categorías. ..................... 30

Figura 5. Ciclo de vida del desarrollo de software. ................................................ 31

Figura 6. Estrategias de pruebas. .......................................................................... 34

Figura 7. Jerarquía de requisitos no funcionales. .................................................. 48

Figura 8. ISO/IEC 9126. ......................................................................................... 48

Figura 9. Iteraciones de RUP ................................................................................. 67

Figura 10. Miembros del equipo de RUP. .............................................................. 67

Figura 11. Relaciones entre productos de desarrollo y niveles de prueba. ............ 68

Figura 12. Método propuesto para la evaluación de los atributos no funcionales. . 81

En los últimos años, el incremento constante del software desarrollado en

Una de las características que se tienen en los procesos de las pruebas no

Para la realización de este material monográfico se analizaron varios estándares

El interés de la realización monográfica es brindar una orientación, a las

1.1 DEFINICIÓN DEL PROBLEMA

La industria del software en Colombia es un sector joven, si se encuadra en las

Debido a la gran desarticulación entre las federaciones y el estado, no se tienen

Es el constante surgimiento de nuevas empresas, el que exige a las

En la actualidad la realización de pruebas no funcionales, como lo son usabilidad,

Ante lo antes expuesto, se ha planteado un problema de investigación el cual se

Lo antes mencionado es un incentivo hacia mejorar el nivel de la calidad del

En otros casos no concluyen con éxito los proyectos contratados en el tiempo

Al requerir productos a la medida se incrementa la probabilidad de que se

Tal es el efecto de importancia que ha causado el software en Colombia, que ha

Teniendo en cuenta las dificultades antes planteadas, se busca en este proyecto,

1.3.1 Objetivo general

Establecer un referente conceptual y teórico de los requerimientos no funcionales

- Establecer un análisis comparativo del tratamiento que cada metodología otorga

- Definir un modelo de medición para los requerimientos no funcionales que

- Proponer un método de evaluación de los requerimientos no funcionales,

1.4 MARCO CONCEPTUAL

1.4.1 Calidad del software. Es el grado con el que un sistema, componente o

1.4.3 Procesos. El proceso ayuda a los miembros de una organización a alcanzar

1.4.5 Verificación de software. Técnica y actividad ligada al control de calidad del

1.4.6 Validación de Software. Técnica y actividad ligada al control de calidad del

1.4.7 CMMI (Capability Maturity Model Integration). Modelo de madurez de