IEEE Práctica Recomendada para Requisitos de Software Especificaciones

UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES
“UNIANDES”
TESIS DE GRADO PREVIO A LA OBTENCIÓN DEL TITULO DE

INGENIERO EN SISTEMAS
TEMA:
MÉTRICAS DE CALIDAD Y EL DESARROLLO DE SOFTWARE

COMPETITIVO EN LA EMPRESA J-M SOFTWARE DEVELOPER
DE LA CIUDAD DE AMBATO
AUTORES:
TEC. JORGE AGUAYO
TUTOR:
MGS. EDUARDO FERNÁNDEZ
AMBATO-ECUADOR
2014
DEDICATORIA
A Dios, por permitirme llegar a este momento tan importante en mi formación

Profesional. A mi madre y padre por apoyarme en todos los momentos difíciles y
demostrarme siempre su apoyo incondicional y guiarme por el sendero del progreso y
trabajo inculcándome valores de honestidad, respeto y amor. A mi amada esposa quien
con su amor hemos sabido conllevar de mejor manera todas las adversidades
convirtiéndonos en sustento y apoyo mutuo. A mi adorado hijo quien con sus
ocurrencias nos llena de valor y fortaleza para afrontar las adversidades de este difícil
camino de la vida.
AGRADECIMIENTO
Quiero agradecer a todos quienes me ayudaron en mi formación profesional, a Dios por

darme la vida y orgullo de tener a mis padres conmigo. A mi madre y padre por haber
sembrado en mí la semilla del esfuerzo, la dedicación la constancia, el honor, la lealtad,
la verdad y ser los mejores maestros de mi vida con su ejemplo y guiarme permanente.
A mi esposa que me han ayudado a comprender que lo mejor que se tiene en esta vida
es una familia unida. A mis maestros de la carrera pilar fundamental del conocimiento
quienes con su gran sabiduría, profesionalismo y calidad humana me han ayudado a
explotar mis potencialidades.
ÍNDICE GENERAL
PORTADA ...................................................................................................................................
CERTIFICACIÓN DEL ASESOR ...........................................................................................
DECLARACIÓN DE AUTORÍA DE LA TESIS ....................................................................
DEDICATORIA..........................................................................................................................
AGRADECIMIENTO ................................................................................................................
INDICE GENERAL ...................................................................................................................
RESUMEN EJECUTIVO ..........................................................................................................
SUMMARY .................................................................................................................................
INTRODUCCIÓN .................................................................................................................... 1
Antecedentes de la investigación ............................................................................................. 1
Planteamiento del problema.- .................................................................................................. 1
Formulación del problema ....................................................................................................... 5
Delimitación del problema ....................................................................................................... 3
Objeto de Investigación y campo de acción ............................................................................ 3
Identificación de línea de investigación .................................................................................. 3
Objetivo General ....................................................................................................................... 3
Objetivos Específicos ................................................................................................................ 3
Idea a Defender y variables...................................................................................................... 4
Justificación del tema. .............................................................................................................. 4
Metodología ............................................................................................................................... 5
Resumen de la estructura de la tesis ....................................................................................... 6
CAPITULO I ............................................................................................................................. 8
MARCO TEÓRICO ................................................................................................................. 8
1.1 Evolución del Software ....................................................................................................... 8
1.2 Conceptos Generales sobre la Ingenieria del Software ................................................. 12
1.3 Tipos de Software.............................................................................................................. 15
1.4 Etapas en el desarrollo del software................................................................................ 15
1.5 Estándares de calidad para análisis, diseño, construcción y pruebas de software ..... 18
1.6 El I.E.E.E ......................................................................................................................... 18
1.6.2 IEEE práctica recomendada para requisitos de software especificaciones
(IEEE std 830-1998) ............................................................................................................... 20
1.6.2.1 Visión general del producto ...................................................................................... 21
1.6.2.2. Restricciones ............................................................................................................... 23
1.6.3. Estándares del producto fase desarrollo ..................................................................... 24
1.6.4. Estándares del producto fase Mantenimiento .......................................................... 25
1.6.4.1 Estructura del documento del usuario del software ................................................ 26
1.6.4.2. Contenido de información del documento del usuario del software ..................... 27
1.6.4.3. Formato de documentación del usuario del software ............................................ 28
1.6.5. Std 730-1998 norma IEEE para planes de aseguramiento de la calidad del
software . .................................................................................................................................. 31
1.6.5.1 .- El plan de aseguramiento de calidad de software................................................. 32
1.6.5.2 Descripción del diseño del software (sdd). ................................................................ 33
1.6.5.3 Norma IEEE para los planes de gestión de proyectos de software - IEEE std
1058-1998. ................................................................................................................................ 34
1.6.5.4 IEEE estándar para la verificación y validación de software - IEEE STD
1012-2004 ................................................................................................................................. 40
1.6.5.5. Norma IEEE para planes de gestión de la configuración de software - IEEE
STD 828-1998 .......................................................................................................................... 65
1.6.5.6. Estándar iEEE para la documentación de pruebas de software - IEEE STD
829-1998 ................................................................................................................................... 68
1.6.5.7 IEEE practica recomendada para pruebas unitarias de software. IEEE
STD 1008 - 1987 (r 2003) ........................................................................................................ 71
CAPITULO II ......................................................................................................................... 78
MARCO METODOLÓGICO Y PLANTEAMIENTO DE LA PROPUESTA ............... 78
2.1. La Empresa ..................................................................................................................... 78
2.2. Diseño Metodológico ....................................................................................................... 78
2.3. Conclusiones parciales del capitulo ............................................................................... 94
CAPITULO III ........................................................................................................................ 95
DESARROLLO DE LA PROPUESTA ................................................................................ 95
3.1 Tema: ................................................................................................................................. 95
3.2 Descripción de la propuesta ............................................................................................. 95
3.3 Desarrollo de la Propuesta ............................................................................................... 95
3.3.1 Métrica propuesta para evaluar la calidad del software ...................................... 1028
3.3.1.1 Métricas para determinar el factor de calidad ...................................................... 98
3.3.2 Aplicación de la metrica. caso practico .................................................................... 100
3.4. Conclusiones parciales del Capitulo ........................................................................... 107
CONCLUSIONES Y RECOMENDACIONES.................................................................. 109
BIBLIOGRAFIA ........................................................................................................................
ANEXOS ......................................................................................................................................
INDICE DE TABLAS
Tabla 1 Población involucrada en la problemática. .................................................. 82
Tabla 2 Resultados obtenidos pregunta 1. .................................................................. 83
Tabla 10 Resultados obtenidos pregunta 3. ................................................................ 91
INDICE DE GRÁFICOS
Gráfico 1 Ilustración gráfica pregunta 1. ................................................................... 83

Gráfico 10 Ilustración gráfica pregunta 4. ................................................................. 92

RESUMEN EJECUTIVO
La propuesta planteada consistió en la implementación de un conjunto de métricas, las

mismas que permitirán evaluar la calidad de un software y permitir su mejoramiento
respectivo. Dichas métricas se han deducido de un modelo de calidad basado en normas
ISO.
Se desarrolló un portal web demostrativo, en el cual se aplicaron dichas normativas

diseñadas. Las herramientas que hemos utilizado para la realización del portal web son las
denominadas de uso libre, así tenemos: Apache, Mysql, Php, y java script, también se utilizó el
manejador de páginas web como es Dreamweaver.
En cuanto a la tesis en sí esta tiene una parte introductoria donde se plantea el problema
relacionado con la baja calidad del software desarrollado, así mismo se plantean
objetivos y la novedad de que dispone este trabajo investigativo. En el denominado
marco teórico se fundamenta teóricamente todo lo que tiene que ver con desarrollo de
software y normas de calidad, así como también a las métricas que pueden aplicarse en
los diferentes estándares definidos como los ISO.
Luego viene el marco metodológico, donde se desarrolla la investigación de campo,

aquí se ratifica la problemática en base a encuestas y entrevistas, dicha problemática
relacionada con el mayor o menor conocimiento de las estándares mínimos de calidad
que debe tener un software para considerarlo de tipo competitivo.
Finalmente tenemos la propuesta de solución que si consiste en la elaboración de un

conjunto de métricas aplicables para evaluar la calidad de un software desarrollado,
estas métricas basada en el modele de estándares ISO 9620.
SUMMARY
The proposal put forward is the implementation of a set of metrics that will enable them
to evaluate the quality of a software and allow respective improvement .
We developed a web portal demonstration , in which these regulations are designed and
implemented a parallel in it that are not taken into account these regulations , then made
a comparative study between the two for validation of the metrics applied .
The tools we have used to implement the so-called web portal are free to use, as
follows: Apache, MySQL, Php, java script and also use the web handler as
Dreamweaver.
As for the thesis itself this is an introductory part where the problem is related to the
low quality of the software developed, also have objectives and the novelty of this
research work available. In the so-called theoretical framework is based theoretically
everything that has to do with software development and quality standards. Then comes
the methodological framework, which develops the field research, the problem here is
ratified based on surveys and interviews. Finally we have the proposed solution is that if
the development of a set of metrics by which to assess the quality of a developed
software.
INTRODUCCIÓN
Antecedentes de da investigación
Luego de una investigación previa realizada en la biblioteca de la Universidad, se

pudo apreciar que no existen trabajos realizados directamente con el tema, pero se
procedió a revisar tesis que tienen que ver con el área informática, así por ejemplo
podemos señalar el trabajo de los ingeniero Ing. Carlos Martínez y Freddy Baño
“Sistema de Información para la toma de decisiones sobre el nivel de satisfacción de
la comunidad universitaria de Uniandes en base a las características y estándares de
calidad de las instituciones de educación superior del Ecuador”
Por otro lado se pudo consultar en algunos sitios Web como por ejemplo el de la
Escuela Superior Politécnica del Litoral cuya Tesis titulada “EL IMPACTO DE LA
OMISIÓN DE MÉTRICAS DE CALIDAD EN EL DESARROLLO DE
SOFTWARE". Por la Ing. Irma Guadalupe Luna.
Con toda esta información recopilada se concluye que un software se constituye en

una herramienta importante de ayuda en el proceso de generación, manipulación y
control de la información ya sea esta en una Institución Pública o Empresa privada, y
que esta debe ser procesada en ámbitos de calidad para ello se hace necesario
disponer de las Métricas respectiva durante el desarrollo del Software.
Planteamiento del problema.-
El Aseguramiento de la Calidad del Software es un área que suele ser desatendida

dentro del desarrollo de software; la presión en los tiempos de entrega o la falta de
conocimiento son las principales razones por las que las casas constructoras de
software le restan importancia a este punto tan por demás crítico.
Durante los primeros años de la era de la computadora, el software se contemplaba

como un añadido. Desde entonces el campo se ha desarrollado significativamente. La
programación de computadoras era un “arte de andar por casa” para el que existían
pocos métodos sistemáticos. El desarrollo del software se realizaba virtualmente sin
ninguna planificación, hasta que los planes comenzaron a descalabrarse y los costos a
1
correr. Los programadores trataban de hacer las cosas bien, y con un esfuerzo
heroico, a menudo salían con éxito. Los problemas a ser resueltos eran
principalmente de una naturaleza técnica, el énfasis estaba en expresar algoritmos
conocidos eficazmente en algún lenguaje de programación.
En estos primeros años lo normal era que el hardware fuera de propósito general. Por
otra parte, el software se diseña a medida para cada aplicación y tenía una
distribución relativamente pequeña.
La segunda era en la evolución de los sistemas de computadora se extienden desde la

mitad de la década de los sesenta hasta finales de los setenta. La multiprogramación
y los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre -
máquina. Las técnicas interactivas abrieron un nuevo mundo de aplicaciones y
nuevos niveles de sofisticación del hardware y del software. Los sistemas de tiempo
real podían recoger, analizar y transformar datos de múltiples fuentes, controlando
así los procesos y produciendo salidas en milisegundos en lugar de en minutos. Los
avances en los dispositivos de almacenamiento en línea condujeron a la primera
generación de sistemas de gestión de bases de datos.
La segunda era se caracterizó también por el establecimiento del software ya se

desarrollaba para tener una amplia distribución en un mercado multidisciplinario.
Los programas se distribuían para computadoras grandes y para minicomputadoras, a
cientos e incluso a miles de usuarios. Los patronos de la industria, del gobierno y de
la universidad se aprestaban a “desarrollar el mejor paquete de software” y ganar así
mucho dinero.
Conforme crecía el número de sistemas informáticos, comenzaron a extenderse las

bibliotecas de software de computadora. Las empresas desarrollaban proyectos en los
que se producían programas de decenas de miles de sentencias fuente. Los productos
de software comprados al exterior incorporaban cientos de miles de nuevas
sentencias. Una nube negra apareció en el horizonte. Todos esos programas, todas
esas sentencias fuente tenían que ser corregidos cuando se detectaban fallos,
modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos
dispositivos hardware que se hubieran adquirido. Estas actividades se llamaron
colectivamente “mantenimiento del software”.
2
La tercera era en la evolución de los sistemas de computadora comenzó a mediados
de los años setenta y continuó más allá de una década. El sistema distribuido,
múltiples computadoras, cada una ejecutando funciones concurrentemente y
comunicándose con alguna otra, incrementó notablemente la complejidad de los
sistemas informáticos. Las redes de área local y de área global, las comunicaciones
digitales de alto ancho de banda y creciente demanda de acceso “instantáneo” a los
datos, supusieron una fuerte presión sobre los desarrolladores del software. Aún más,
los sistemas y el software que lo permitían, continuaron residiendo dentro de la
industria y de la academia. El uso personal era extraño.
La conclusión de la tercera era se caracterizó por la llegada y amplio uso de los

microprocesadores. El microprocesador ha producido un extenso grupo de productos
inteligentes, desde automóviles hasta hornos microondas, desde robots industriales a
equipos de diagnóstico de suero sanguíneo, pero ninguno ha sido más importante que
la computadora personal. En menos de una década, las computadoras llegarán a ser
fácilmente accesibles al público.
La cuarta era de la evolución de sistemas informáticos se aleja de las computadoras

individuales y de los programas de computadoras, dirigiéndose al impacto colectivo
de las computadoras y del software. Potentes máquinas personales controladas por
sistemas operativos sofisticados, en redes globales y locales, acompañadas por
aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas
informáticas están cambiando de entornos centralizados de grandes computadoras a
entornos descentralizados cliente/servidor. Las redes de información en todo el
mundo proporcionan una infraestructura que iguala a expertos y políticos en pensar
sobre una “superautopista de información” y una “conexión del ciberespacio”. De
hecho Internet se puede observar como un “software” al que pueden acceder usuarios
individuales.
La industria del software ya es la cuna de la economía del mundo. Las decisiones

tomadas por gigantes de la industria tales como Microsoft arriesgan billones de
dólares. A medida que la cuarta generación progresa, han comenzado a surgir nuevas
tecnologías. Las tecnologías orientadas a objetos están desplazando rápidamente los
enfoques de desarrollo de software más convencionales en muchas áreas de
aplicaciones. Aunque las predicciones de las computadoras de “quinta generación””
3
continúan eludiéndonos, “las técnicas de cuarta generación” para el desarrollo del
software están cambiando en forma en que la comunidad del software construye
programas informáticos. Los sistemas expertos y el software de inteligencia artificial
han salido del laboratorio para entrar en aplicaciones prácticas de una gran variedad
de problemas del mundo real.
El software de redes neuronales artificiales junto con la aplicación de lógica difusa

ha abierto posibilidades excitantes para el reconocimiento de patrones y habilidades
de procesamiento de información de carácter humano. La programación de realidad
virtual y los sistemas multimedia ofrecen formas radicalmente diferentes de
comunicar información al usuario final. “Los algoritmos genéticos” ofrecen el
potencial para el software que reside dentro de las computadoras biológicas
masivamente en paralelo. Sin embargo, un conjunto de problemas relacionados con
el software ha persistido a través de la evolución de los sistemas basados en
computadora, y estos problemas continúan aumentado.
En la ciudad de Ambato a principios del año 2011 surge la empresa “J-M Software
Developers®” orientada a dar servicios de desarrollo de software de tipo comercial
orientados tanto a tipo aplicaciones Windows como a Web. Relacionada con el
desarrollo y aplicación de nuevos conocimientos profesionales adquiridos
universitariamente y en la práctica de conocimientos adquiridos bajo soporte de mi
persona como propietario y como pilar fundamental el apoyo incondicional de mis
maestros. En todo este tiempo se han logrado conseguir el desarrollo de algunos
sistemas y portales tanto comerciales como prácticos, pero luego de entregarlos y
hacerlos una evaluación con otros técnicos informáticos se ha podido recoger las
siguientes observaciones:
• Al software le falta generalmente calidad en sus interfaces y en las

combinaciones de colores.
• No se han realizado pruebas adecuadas dentro de las normativas de la
ingeniería del software.
• Varias de las aplicaciones web no cumplen con las normas internacionales de
accesibilidad a la web (herramientas de medición TAW – ERA).
4
Por otro lado la empresa con el deseo de mantenerse y seguir generando trabajo, ha
tratado de buscar entidades en con las cuales se pueda hacer convenios para que “J-
M Software Developer®” se convierta en una desarrolladora de software para estas
Instituciones. La principal dificultad, la falta de confianza ante otras empresas,
además en una ligera evaluación realizada por estas empresas es de que los portales
elaborados no cumplen con ciertos parámetros de accesibilidad, es decir no se ha
considerado el acceso de personas con problemas de oído, visión, movilidad,
dificultades de lectura o comprensión cognitiva, imposibilidad de utilización del
teclado o el ratón, etc.
Esto significa que la empresa está ante un problema relacionado con la calidad de su
trabajo, ya que está desarrollando un software poco competitivo en el mercado y lo
más grave aún es que la empresa no tiene un conjunto de parámetros establecidos
que permitan evaluar dicha calidad del software desarrollado
Formulación del problema

¿Cómo mejorar la calidad del software desarrollado para que sea más competitivo en
el mercado nacional?
Objeto de investigación y campo de acción
Objeto de Estudio: Ingeniería en Sistemas
Campo de Acción: El campo de acción está definido directamente en la Ingeniería
del Software y específicamente en la evaluación de su calidad.
Delimitación: El trabajo investigativo se llevará a cabo en la empresa J-M Software
Developer® de la Ciudad de Ambato, en la Calle Eloy Alfaro y García Moreno que
viene elaborando desde el año 2011.
Identificación de línea de investigación
El trabajo se enmarca en la línea denominada: “Desarrollo de software y

programación de Sistemas”
5
Objetivo General
Elaborar un conjunto de estrategias que se constituyan en una métrica fácil y
eficiente para evaluar la calidad de un software desarrollado por la empresa “J-M
Software Developer®”
Objetivos Específicos
• Analizar fuentes bibliográficas referentes Ingeniería del software, metodologías
de desarrollo, pruebas, Normas ISO referente a la calidad y procesos de
mejoramiento continuo aplicados al desarrollo de software.
• Diagnosticar la aplicación de estándares de calidad utilizados durante el
desarrollo de software actualmente en la empresa.
• Aplicar las métricas propuestas en algunos casos de estudio.
Idea a Defender y variables
Idea a defender: “Con la aplicación de un conjunto de métricas de calidad diseñadas

en esta tesis, se logrará el desarrollo de un software más competitivo en el mercado
por parte de la empresa “J-M Software Developer®”
Variable independiente: Métricas de calidad
Variable Dependiente: Desarrollo de software competitivo
Justificación del tema.
Del planteamiento del problema se deduce que este incide directamente en la calidad
del software, dicha calidad se hace referencia a diversos aspectos del desarrollo como
por ejemplo apariencia, seguridad, utilidad y celeridad de procesos.
La aplicación de las métricas diseñadas en este trabajo investigativo, generan

automáticamente algunas mejoras en el desarrollo de software, así por ejemplo:
6
• La apariencia del mismo mejora considerablemente en base a un mejor diseño y
sobre todo a una adecuada combinación de colores.
• La seguridad de acceso se eleva, esto quiere decir que se tienen mayores
controles en cuanto a validación de datos.
• La celeridad en los procesos es mayor en base al diseño dinámico.
• El software se hace más competitivo y de acuerdo a estándares internacionales.
Por todo lo mencionado anteriormente se justifica plenamente la realización del

presente trabajo investigativo como tesis de grado para la obtención del título de
ingeniero
Metodología
El presente trabajo utiliza la siguiente metodología investigativa
Cualitativa: Determina las características o descripciones de la realidad del

problema planteado, en este caso la poca competitividad que posee el software
desarrollado por la empresa.
Cuantitativa: Permitirá determinar en base a estadísticas las características del

fenómeno y sus relaciones, para proporcionar la manera de establecer, formular,
fortalecer y revisar los procesos de elaboración de software con estándares de calidad
en cada uno de ellos
Los tipos de investigación que se utilizaron son:
Descriptiva mediante este tipo de investigación, que utiliza el método de análisis, se

logra caracterizar el objeto de estudio de una situación concreta, explicativa requiere
la combinación de los métodos analíticos o sintéticos con el deductivo y el inductivo,
se trata de responder o dar cuenta de los porqués del objeto que se investiga. Tiene
que ver esencialmente a los niveles de calidad que se aplican en cada fase de
desarrollo
Bibliográfica que nos ayuda a recabar información para la investigación, para ello se
consulta en libros, documentos de archivos, folletos y páginas web, lo cual es de gran
7
importancia para la elaboración del marco teórico relacionado con Normas ISO,
estándares de calidad, métricas de calidad, arquitectura de software e ingeniería de
software,
De campo se realizará en el lugar establecido donde se sitúa el problema, en este

caso se llevó a efecto en la empresa J-M Software Developer®
Entre las técnicas para recopilar información tenemos:
La encuesta, es la técnica que permite recopilar información mediante un

cuestionario que es elaborado previamente por el investigador, esta encuesta está
orientada a los desarrolladores de software y a los clientes
La entrevista, es un acto de comunicación oral que se establece entre dos o más

personas, en este caso se la aplico al gerente.
Los instrumentos que se emplearan son la guía de entrevistas que permitirá recopilar
información en forma verbal a través de preguntas previamente elaboradas al
gerente, los cuestionarios son unas series de preguntas que realiza el investigador
para determinar las ventajas y desventajas que presenta el fenómeno investigado, en
este caso se los utilizó para encuestar a clientes y desarrolladores
Resumen de la estructura de la tesis
El trabajo investigativo se encuentra estructurada en cuatro secciones bien

diferenciadas que son:
La introducción, la cual recopila aspectos importantes de la investigación como los

antecedentes del presente trabajo, el planteamiento del problema enfocado a las
dificultades para elaborar software de calidad, los objetivos relacionados a elevar la
calidad del software y más.
El Capítulo uno que concierne al marco teórico aborda toda la información

relacionada con la ingeniería del software, el desarrollo del mismo y las normativas
generales de la calidad dada por las normas ISO.
8
En el segundo capítulo se puede encontrar los resultados de la investigación de
campo, la cual corresponde a las encuestas a las personas involucradas con el
desarrollo de software, en este caso programadores y clientes
En el tercer capítulo se presenta el desarrollo de la propuesta donde se estructura el

diseño de algunas normativas y se procede a la aplicación de las mismas para evaluar
un producto sencillo.
Por último se muestran las conclusiones del trabajo investigativo y las

recomendaciones del mismo para que la propuesta de solución cumplan formalmente
con el propósito para el cual fue desarrollado.
Elementos de novedad, aporte teórico y significación práctica, en dependencia

del alcance de la tesis.
El trabajo Investigativo que se ha desarrollado y que se denomina “Métricas de

Calidad y el Desarrollo de Software Competitivo” permitirá al proponente generar
un aporte teórico importante, este aporte tiene esencialmente que ver con aspectos
relacionados a la calidad en el desarrollo de software, el presente trabajo
investigativo es quizás uno de los pocos en su área y recopila datos relacionados a
estándares internacionales aplicados para el desarrollo de software, esto hace que el
aporte teórico sea interesante por ende novedoso.
El tema en sí constituye una novedad ya que se sale de los parámetros normales que
se han venido dando en trabajo de investigación previos a la obtención de un título de
ingeniero.
En cuanto a su significación práctica se puede señalar que una vez diseñadas las
métricas se las aplica en el desarrollo de un prototipo a través del cual se podrá
evidenciar la calidad desigual de los programas desarrollados como ejemplos.
9
CAPITULO I
MARCO TEÓRICO
1.1 Evolución del software
Haciendo un poco de historia se puede señalar que durante los primeros años de la
era de la computadora, el software se contemplaba como un añadido. Desde entonces
el campo se ha desarrollado tremendamente. La programación de computadoras era
un “arte de andar por casa” para el que existían pocos métodos sistemáticos. El
desarrollo del software se realizaba virtualmente sin ninguna planificación, hasta que
los planes comenzaron a descalabrarse y los costos a correr. Los programadores
trataban de hacer las cosas bien, y con un esfuerzo heroico, a menudo salían con
éxito. Los problemas a ser resueltos eran principalmente de una naturaleza técnica, el
énfasis estaba en expresar algoritmos conocidos eficazmente en algún lenguaje de
programación. (PRESSMAN Roger (2006))
En estos primeros años lo normal era que el hardware fuera de propósito general. Por
otra parte, el software se diseña a medida para cada aplicación y tenía una
distribución relativamente pequeña.
Avanzando cronológicamente se puede señalar que la segunda era en la evolución de

los sistemas de computadora se extienden desde la mitad de la década de los sesenta
hasta finales de los setenta. La multiprogramación y los sistemas multiusuario
introdujeron nuevos conceptos de interacción hombre - máquina. Las técnicas
interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de
sofisticación del hardware y del software. Los sistemas de tiempo real podían
recoger, analizar y transformar datos de múltiples fuentes, controlando así los
procesos y produciendo salidas en milisegundos en lugar de en minutos. Los avances
en los dispositivos de almacenamiento en línea condujeron a la primera generación
de sistemas de gestión de bases de datos. (SOMMERVILLE Ian (2004))
Esta segunda era se caracterizó también por el establecimiento del software ya se

desarrollaba para tener una amplia distribución en un mercado multidisciplinario.
Los programas se distribuían para computadoras grandes y para minicomputadoras, a
cientos e incluso a miles de usuarios. Los patronos de la industria, del gobierno y de
10
la universidad se aprestaban a “desarrollar el mejor paquete de software” y ganar así
mucho dinero.
Conforme crecía el número de sistemas informáticos, comenzaron a extenderse las

bibliotecas de software de computadora. Las casas desarrollaban proyectos en los
que se producían programas de decenas de miles de sentencias fuente. Los productos
de software comprados al exterior incorporaban cientos de miles de nuevas
sentencias. Una nube negra apareció en el horizonte. Todos esos programas, todas
esas sentencias fuente tenían que ser corregidos cuando se detectaban fallos,
modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos
dispositivos hardware que se hubieran adquirido. Estas actividades se llamaron
colectivamente “mantenimiento del software”. (SANCHEZ Salvador (2009))
La tercera era en la evolución de los sistemas de computadora comenzó a mediados

de los años setenta y continuó más allá de una década. El sistema distribuido,
múltiples computadoras, cada una ejecutando funciones concurrentemente y
comunicándose con alguna otra, incrementó notablemente la complejidad de los
sistemas informáticos. Las redes de área local y de área global, las comunicaciones
digitales de alto ancho de banda y creciente demanda de acceso “instantáneo” a los
datos, supusieron una fuente presión sobre los desarrolladores del software. Aún
más, los sistemas y el software que lo permitían, continuaron residiendo dentro de la
industria y de la academia. El uso personal era extraño.
La conclusión de la tercera era se caracterizó por la llegada y amplio uso de los

microprocesadores. El microprocesador ha producido un extenso grupo de productos
inteligentes, desde automóviles hasta hornos microondas, desde robots industriales a
equipos de diagnóstico de suero sanguíneo, pero ninguno ha sido más importante que
la computadora personal. En menos de una década, las computadoras llegarán a ser
fácilmente accesibles al público. (PRESSMAN Roger (2006))
La cuarta era de la evolución de sistemas informáticos se aleja de las computadoras

individuales y de los programas de computadoras, dirigiéndose al impacto colectivo
de las computadoras y del software. Potentes máquinas personales controladas por
sistemas operativos sofisticados, en redes globales y locales, acompañadas por
aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas
11
informáticas están cambiando de entornos centralizados de grandes computadoras a
entornos descentralizados cliente/servidor. Las redes de información en todo el
mundo proporcionan una infraestructura que iguala a expertos y políticos en pensar
sobre una “superautopista de información” y una “conexión del ciberespacio”. De
hecho Internet se puede observar como un “software” al que pueden acceder usuarios
individuales.
1.2 Conceptos generales sobre la Ingeniería del software.
La ingeniería del software se trata desde la perspectiva de grupos de ingenieros y

diseñadores fundamentalmente, pero también otros roles profesionales como gestores
del proceso de desarrollo, analista, etc y no desde la perspectiva de un programador
aislado.
La ingeniería del software es una disciplina de la ingeniería cuya meta es el

desarrollo costeable de sistemas de software. Éste es abstracto e intangible. No está
restringido por materiales, o gobernado por leyes físicas o por procesos de
manufactura. De alguna forma, esto simplifica la ingeniería del software ya que no
existen limitaciones físicas del potencial del software. Sin embargo, esta falta de
restricciones naturales significa que el software puede llegar a ser extremadamente
complejo y muy difícil de entender.
La definición más utilizada de Ingeniería de Software es la aplicación de un enfoque

sistemático, disciplinado y cuantificable al desarrollo, la operación y el
mantenimiento del software. (SÁNCHEZ Salvador (2009))
Según esta definición el ingeniero de software es un desarrollador en sentido amplio

que desempeña un rol como profesional en la producción de software
Sin embargo la ingeniería tal y toco hoy la entendemos siempre resulta en algún
artefacto concreto. Estos artefactos pueden ser utilidades finales o elementos para ser
reutilizables en otros procesos de ingeniería. En cambio a la ingeniería del software
su resultado útil son las aplicaciones de las cuales los usuarios se sirven para hacer
más eficaz, controlado o eficiente su trabajo
12
La estructuración de las diferentes ingenierías como disciplinas profesionales
reconocidas donde se enuncian los tres elementos que constituyen una disciplina
son:
• Aspecto colegial: El conocimiento y competencia del profesional debe haber

sido válido por la comunidad de sus pares
• Aspecto cognitivo: Ese conocimiento y competencia consensualmente valido
debe descansar en criterios racionales y científicos
• Aspecto moral: El juicio y los consejos profesionales deben orientarse a un
conjunto de valores sustantivos
Las diferentes ramas o disciplinas ingenieriles difieren en el objeto de la producción,

pero todas ellas tiene en común tres aspectos específicos:
• La ciencia de la ingeniería que se ocupa de los principios y mecanismos

subyacentes de la disciplina
• Procesos de diseño, que generalmente incluyen una fase de
conceptualización, y una fase de diseño detallado
• Aspectos de gestión y organización, pues la tecnología que se produce
implica tanto a las personas como a las organizaciones. Además, las propias
personas que crean tecnología no suelen trabajar aisladas, sino en equipo y
organizaciones
En el caso de la ingeniería del Software, las actividades de diseño serian asimilables

a lo que normalmente conocemos como desarrollo. Es importante distinguir
claramente entre ciencia de la computación e ingeniería del Software, utilizando el
conocimiento que es el objeto de la ciencia de la computación, Hay que separar los
conocimientos de la ingeniería del Software en sí misma y la práctica de la
ingeniería: (SOMMERVILLE Ian (2004))
• Las ciencias que se aplican en la ingeniería del Software son la ciencia de la

computación y otras ciencias que son de utilidad para aspectos determinados,
como las relativas a la organización, la economía, la psicología y por
supuesto las matemáticas en general. Para dominios muy concretos también
13
se necesitan conocimientos específicos de ciertas ciencias. Así, en la
ingeniería del Software aeroespacial se requieren conocimientos de física,
mientras que para el desarrollo del software para biotecnología, serán
necesarios ciertos conocimientos de biología
• La ingeniería del software como ciencia es la aplicación del método científico

a la teorización y creación de conocimientos sobre la propia ingeniería del
Software. Está dedicada al estudio de sus actividades y centrada en generar
teoría, modelos explicativos o enunciados descriptivos sobre la práctica de la
ingeniería.
• La práctica de la ingeniería que está orientada a prescribir como deben

realizarse las actividades propias de la disciplina. Es un aspecto
complementario con la ciencia de la ingeniería, pues la ciencia necesita de la
observación de la práctica, y l practica a su vez se perfecciona de acuerdo con
el conocimiento generado por la ciencia
La ingeniería del software es una disciplina de la ingeniería que comprende todos

los aspectos de la producción de software desde las etapas iníciales de la
especificación del sistema, hasta el mantenimiento de éste después de que se
utiliza. En esta definición, existen dos frases clave:
• Disciplina de la ingeniería. Los ingenieros hacen que las cosas funcionen.

Aplican teorías, métodos y herramientas donde sean convenientes, pero las
utilizan de forma selectiva y siempre tratando de descubrir soluciones a los
problemas, aun cuando no existan teorías y métodos aplicables para
resolverlos. Los ingenieros también saben que deben trabajar con
restricciones financieras y organizacionales, por lo que buscan soluciones
tomando en cuenta estas restricciones.
• Todos los aspectos de producción de software. La ingeniería del software no
sólo comprende los procesos técnicos del desarrollo de software, sino
también con actividades tales como la gestión de proyectos de software y el
desarrollo de herramientas, métodos y teorías de apoyo a la producción de
software.
14
1.3 Tipos de Software
Software de Aplicación: aquí se incluyen todos aquellos programas que permiten al

usuario realizar una o varias tareas específicas. Aquí se encuentran aquellos
programas que los individuos usan de manera cotidiana como: procesadores de texto,
hojas de cálculo, editores, telecomunicaciones, software de cálculo numérico y
simbólico, videojuegos, entre otros.
Software de Programación: son aquellas herramientas que un programador utiliza

para poder desarrollar programas informáticos. Para esto, el programador se vale de
distintos lenguajes de programación. Como ejemplo se pueden tomar compiladores,
programas de diseño asistido por computador, paquetes integrados, editores de texto,
enlazadores, depuradores, intérpretes, entre otros.
Software de Sistema: es aquel que permite a los usuarios interactuar con el sistema
operativo así como también controlarlo. Este sistema está compuesto por una serie de
programas que tienen como objetivo administrar los recursos del hardware y, al
mismo tiempo, le otorgan al usuario una interfaz. El sistema operativo permite
facilitar la utilización del ordenador a sus usuarios ya que es el que le da la
posibilidad de asignar y administrar los recursos del sistema, como ejemplo de esta
clase de software se puede mencionar a Windows, Linux y Mac OS X, entre otros.
Además de los sistemas operativos, dentro del software de sistema se ubican las
herramientas de diagnóstico, los servidores, las utilidades, los controladores de
dispositivos y las herramientas de corrección y optimización, etcétera.
1.4 Etapas en el desarrollo del software
Al inicio de un desarrollo (no de un proyecto), esta es la primera fase que se realiza,

y, según el modelo de proceso adoptado, puede casi terminar para pasar a la próxima
etapa (caso de Modelo Cascada Realimentado) o puede hacerse parcialmente para
luego retomarla (caso Modelo Iterativo Incremental u otros de carácter evolutivo).
En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y

especifican las características funcionales y no funcionales que deberá cumplir el
futuro programa o sistema a desarrollar. (PRESSMAN Roger (2006))
15
Las bondades de las características, tanto del sistema o programa a desarrollar, como
de su entorno, parámetros no funcionales y arquitectura dependen enormemente de lo
bien lograda que esté esta etapa. Esta es, probablemente, la de mayor importancia y
una de las fases más difíciles de lograr certeramente, pues no es automatizable, no es
muy técnica y depende en gran medida de la habilidad y experiencia del analista que
la realice.
Involucra fuertemente al usuario o cliente del sistema, por tanto tiene matices muy
subjetivos y es difícil de modelar con certeza o aplicar una técnica que sea «la más
cercana a la adecuada» (de hecho no existe «la estrictamente adecuada»). Si bien se
han ideado varias metodologías, incluso software de apoyo, para captura, e licitación
y registro de requisitos, no existe una forma infalible o absolutamente confiable, y
deben aplicarse conjuntamente buenos criterios y mucho sentido común por parte del
o los analistas encargados de la tarea; es fundamental también lograr una fluida y
adecuada comunicación y comprensión con el usuario final o cliente del sistema.
El artefacto más importante resultado de la culminación de esta etapa es lo que se

conoce como especificación de requisitos software o simplemente documento ERS.
Como se dijo, la habilidad del analista para interactuar con el cliente es fundamental;
lo común es que el cliente tenga un objetivo general o problema que resolver, no
conoce en absoluto el área (informática), ni su jerga, ni siquiera sabe con precisión
qué debería hacer el producto software (qué y cuantas funciones) ni, mucho menos,
cómo debe operar. En otros casos menos frecuentes, el cliente «piensa» que sabe
precisamente lo que el software tiene que hacer, y generalmente acierta muy
parcialmente, pero su empecinamiento entorpece la tarea de licitación. El analista
debe tener la capacidad para lidiar con este tipo de problemas, que incluyen
relaciones humanas; tiene que saber ponerse al nivel del usuario para permitir una
adecuada comunicación y comprensión.
Escasas son las situaciones en que el cliente sabe con certeza e incluso con
completitud lo que requiere de su futuro sistema, este es el caso más sencillo para el
analista.
16
Las tareas relativas a captura, e licitación, modelado y registro de requisitos, además
de ser sumamente importante, puede llegar a ser dificultosa de lograr acertadamente
y llevar bastante tiempo relativo al proceso total del desarrollo; al proceso y
metodologías para llevar a cabo este conjunto de actividades normalmente se las
asume parte propia de la Ingeniería de Software, pero dada la antedicha complejidad,
actualmente se habla de una Ingeniería de requisitos , aunque ella aún no existe
formalmente. (SÁNCHEZ Salvador (2009))
Hay grupos de estudio e investigación, en todo el mundo, que están exclusivamente

abocados a idear modelos, técnicas y procesos para intentar lograr la correcta
captura, análisis y registro de requisitos. Estos grupos son los que normalmente
hablan de la Ingeniería de requisitos; es decir se plantea ésta como un área o
disciplina pero no como una carrera universitaria en sí misma.
Algunos requisitos no necesitan la presencia del cliente, para ser capturados o

analizados; en ciertos casos los puede proponer el mismo analista o, incluso, adoptar
unilateralmente decisiones que considera adecuadas. Por citar ejemplos probables:
Algunos requisitos sobre la arquitectura del sistema, requisitos no funcionales tales
como los relativos al rendimiento, nivel de soporte a errores operativos, plataformas
de desarrollo, relaciones internas o ligas entre la información a almacenar en caso de
bases o bancos de datos, etc. Algunos funcionales tales como opciones secundarias o
de soporte necesarias para una mejor o más sencilla operatividad; etc.
La obtención de especificaciones a partir del cliente (u otros actores intervinientes)

es un proceso humano muy interactivo e iterativo; normalmente a medida que se
captura la información, se la analiza y realimenta con el cliente, refinándola,
puliéndola y corrigiendo si es necesario; cualquiera sea el método de ERS utilizado.
EL analista siempre debe llegar a conocer la temática y el problema que resolver,

dominarlo, hasta cierto punto, hasta el ámbito que el futuro sistema a desarrollar lo
abarque. Por ello el analista debe tener alta capacidad para comprender problemas de
muy diversas áreas o disciplinas de trabajo (que no son específicamente suyas); así
por ejemplo, si el sistema a desarrollar será para gestionar información de una
aseguradora y sus sucursales remotas, el analista se debe compenetrar en cómo ella
17
trabaja y maneja su información, desde niveles muy bajos e incluso llegando hasta
los gerenciales.
Dada a gran diversidad de campos a cubrir, los analistas suelen ser asistidos por
especialistas, es decir gente que conoce profundamente el área para la cual se
desarrollará el software; evidentemente una única persona (el analista) no puede
abarcar tan vasta cantidad de áreas del conocimiento. En empresas grandes de
desarrollo de productos software, es común tener analistas especializados en ciertas
áreas de trabajo. (PRESSMAN Roger (2006))
1.5 Estándares de calidad para análisis, diseño, construcción y pruebas de

software
La calidad es un parámetro difícil de definir y por lo tanto complicado de lograr.
Características del software:

• La complejidad es difícil de estimar
• La calidad es difícil de medir
• El proceso de desarrollo es muy dependiente de factores humanos
o Difícil de controlar
o Está expuesto a altos riesgos
• El mantenimiento es costoso
Se puede definir como un plan de calidad del desarrollo de un software al:
“Conjunto planificado y sistemático de acciones necesarias para proveer la confianza
de un Producto que cumpla con los requerimientos técnicos establecidos”
1.6 El I.E.E.E.
Es la mayor y más importante organización profesional del mundo. Reúne a más de

375.000 miembros en más de 160 países, entre estudiantes, profesionales,
catedráticos y científicos en áreas tales como ingeniería eléctrica y electrónica e
ingeniería informática. Está dividida administrativamente en 10 regiones, integrada
por 300 secciones.
18
Es un desarrollador líder en normas de la industria, la IEEE-SA cuenta con
relaciones estratégicas con el IEC, ISO, y la UIT, cumple con todos los requisitos
establecidos por la ordenanza de la organización mundial del comercio, tiene una
cartera de 1300 proyectos en el marco de las normas y el desarrollo, la IEEE-SA es la
principal fuente para la organización, en una amplia gama de tecnologías, se
desarrolla a nivel mundial las normas en una gran gama de industrias incluyendo,
biomedicina y salud, el poder y la energía, tecnología de la información, la
telecomunicaciones, el trasporte y la nanotecnología y muchas más, los expertos
técnicos del mundo participan en el desarrollo de la IEEE normas.
1.6.1 Estándar de ingeniería de Software
Se define como un estándar a la Regla o base de comparación que se utiliza para

medir algún aspecto del software
¿Por qué utilizar Estándares?
• Son indispensables cuando muchas personas, productos y herramientas deben

coexistir.
o Promueven el buen uso de métodos y herramientas.
o Permite la comunicación entre los desarrolladores.
• Facilitan el mantenimiento del software.
• Facilitan la capacitación del personal.
• Proveen una base para evaluar los diferentes productos de software
19
1.6.2 IEEE práctica recomendada para requisitos de software especificaciones
(IEEE std 830-1998) 1
• Introducción o Propósito
o Alcance
o Definiciones, Siglas y
Abreviaturas
o Referencias
o Visión general del producto
• Descripción General o Perspectiva del Producto

o Funciones del Producto
o Características de los usuarios
o Restricciones
o Suposiciones y Dependencias
• Requisitos Específicos o Requisitos Funcionales

o Requisitos de interfaces
Externas
o Requisitos de Rendimiento
o Atributos
Todas estas actividades permiten definir el proceso de software de una organización.

A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado.
Introducción.- En esta sección se proporcionará una introducción a todo el

documento de Especificación de Requisitos Software. Consta de varias sub
secciones, las cuales son propósito, ámbito del sistema, definiciones, referencias y
visión general del documento.
Propósito.- Se definirá el propósito del documento ERS y se especificará a quién va

dirigido el documento.
1
IEEESTANDARDSASSOCIATION, “830-1998 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
20
Ámbito del sistema.- En esta sub sección se pondrá nombre al futuro sistema, se
explicará lo que el sistema hará y lo que no hará, se describirán los beneficios,
objetivos y metas que se espera alcanzar con el futuro sistema y se mantendrán
referencias a los documentos de nivel superior que puedan existir.
Definiciones, acrónimos y abreviaturas.- Se definirán aquí todos los términos,

acrónimos y abreviaturas utilizadas en el desarrollo de la ERS.
Referencias. Se presentará una lista completa de todos los documentos referenciados

en la ERS.
1.6.2.1 Visión general del producto.
Esta sub sección describirá brevemente los contenidos y la organización del resto de
la ERS.
Descripción general.- En esta sección se describen todos aquellos factores que

afectan al producto y a sus requisitos. En esta sección no se describen los requisitos,
sino su contexto. Los detalles de los requisitos de describen en la sección 3,
detallándolos y haciendo más fácil su comprensión. Normalmente podemos
encontrar las siguientes sub secciones: perspectiva del producto, funciones del
producto, características de los usuarios, restricciones, suposiciones y futuros
requisitos.
Perspectiva del producto.- Esta sección describe el producto en caso de ser

independiente o si es dependiente de otro sistema más grande entonces debe
especificar los requisitos y las interfaces entre ese sistema y el software, en este caso
deben describir como operará el software. En las interfaces de sistema, usuario,
hardware, software, comunicaciones, memoria, funcionamientos y requisitos de
adaptación de sitio.
Interfaces de sistema.- Esta sección detalla cada interfaz e identifica la

funcionalidad del software para sacar los requisitos del sistema y las interfaces.
21
Interfaces de usuario.- Esta sección describe las características de la configuración
como son formatos de pantalla, reportes, menús, páginas, opciones de mensajes de
error largos o cortos y todos estos requisitos deben ser verificados, los atributos del
sistema se especificarán con el título facilidad de uso.
Interfaces de hardware.- Esta sección específica las características lógicas y los

componentes de hardware del sistema.
Interfaces de software.- Esta sección específica el uso de otros productos de

software e interfaces con otros sistemas. Estos deben identificarse con: nombre,
código, número de la especificación, número de versión y fuente.
Interfaces de comunicaciones.- Esta sección específica varias interfaces de

comunicaciones como los protocolos de las redes locales, etc.
Memoria.- Esta sección específica cualquier característica aplicable y límites en la

memoria primaria y secundaria.
Funcionamientos.- Esta sección específica los funcionamientos normales y

especiales requeridos por el usuario.
Requisitos de adaptación de sitio
Esta sección específica el sitio o los rasgos que se deben relacionar a características
que deben modificarse para adaptar el software a una instalación particular.
Funciones del producto. Esta sección proporciona una síntesis de las principales
funciones que realiza el software.
Características del usuario. Esta sección describe las características generales de

los usuarios del producto que incluye nivel educativo, experiencia y especialización
técnica.
22
1.6.2.2. Restricciones
Esta sección describe en forma general cualquier otro punto que limite las opciones
de los diseñadores. Estos incluyen: políticas reguladoras, limitaciones de hardware,
interfaces a otras aplicaciones, funciones de auditorías, funciones de control,
requisitos de lenguaje, requisitos de fiabilidad, credibilidad de la aplicación y
seguridad.
Suposiciones y dependencias
Esta sección detalla cada uno de los factores que afectan a los requisitos declarados
en el ERS.
Requisitos específicos. Esta sección contiene todos los requisitos de software

apropiadamente detallados para permitirles a los creadores diseñar el sistema para
satisfacer los requisitos, esta sección es la más grande e importante del Ers.
Requisitos funcionales. Esta sección define las funciones que tendrá el software,
aceptando y procesando las entradas y generando las salidas.
Requisitos de interfaces externas. Ésta sección detalla todas las entradas y salidas
del sistema software. Debe completar la descripción de la interfaz y no debe repetirse
la información.
Requisitos de rendimiento. Pretende definir una serie de parámetros mensurables

del sistema que imponen restricciones sobre el mismo. Generalmente están asociados
a tiempos de respuesta, tiempos de espera y duración de tareas batch. Estos
requerimientos son muy importantes ya que la no satisfacción de los mismos implica
un fracaso del sistema, por lo que deben tener una prioridad alta.
1.6.2.3 Atributos
23
Seguridad. Esta sección específica los factores que protegen el software de accesos
provisionales, modificación, destrucción. Los requisitos específicos pueden tener:
• Utilizar técnicas criptográficas
• Mantener registros específicos o una serie de historia de datos
• Asignar ciertas funciones a módulos diferentes
• Restringir comunicaciones entre algunas áreas del programa
• Revisar la integridad de datos para variables críticas.
1.6.3 Estándares del producto fase desarrollo
IEEE práctica recomendada para las descripciones de diseño de software -

IEEE std 1016-1998 2
IEEE 1016 es un estándar para “descripción de un diseño de software”, entendiendo

por tal la representación que sirve para comunicar cómo está diseñado el sistema.
Especifica la información que una descripción de este tipo ha de contener y la
organización o esquema de presentación recomendada. Puede aplicarse a software de
cualquier tipo destinado a funcionar en un ordenador. Su aplicación no está
restringida por ninguna consideración relativa al tamaño, complejidad o carácter
crítico del software
• Consideraciones para • Ciclo de vida de software

producir un SDD • SDD dentro del ciclo de vida
• Propósito de un SDD
• Contenido de • Introducción
información de la • Entidades de diseño
descripción de Diseño • Atributos de entidades de diseño
• Organización de la • Introducción
descripción del Diseño • Visión de Diseño
2
24
Software del ciclo de vida.- El ciclo de vida de un sistema de software se define

normalmente como el período de tiempo que comienza cuando un producto de
software es la concepción y termina cuando el producto ya no está disponible para su
uso. El enfoque de ciclo de vida es una ingeniería eficaz herramienta de gestión y
proporciona un modelo para un contexto en el que para discutir la preparación y uso
de los SDD.
Sdd dentro del ciclo de vida. Para ambos nuevos sistemas de software y sistemas
existentes bajo mantenimiento, es importante asegurarse de que el diseño y
implementación que utiliza un sistema de software para satisfacer los requisitos de
conducción de dicho sistema. La documentación mínima necesaria para hacer esto se
define en IEEE Std 730-1998. El SDD es uno de estos productos requeridos. Se
registra el resultado de los procesos de diseño que se llevan a cabo durante la fase de
diseño.
Propósito de un sdd.- El SDD muestra cómo el sistema de software se estructura

para satisfacer los requisitos identificados en el software requisitos de la
especificación IEEE Std 830-1998. Es una traducción de los requisitos en una
descripción del software estructura, componentes de software, interfaces, y los datos
necesarios para la fase de implementación. En esencia, el SDD se convierte en un
plan detallado para la actividad de ejecución. En un SDD completa, cada requisito
debe ser trazable a una o más entidades de diseño.
1.6.4 Estándares del producto fase Mantenimiento
IEEE estándar para la documentación de software del usuario. IEEE std 1063-
2001 3
3
25
En esta norma van los requisitos mínimos para la estructura, el contenido de la
información y el formato de documentación para el usuario, que incluye tanto los
documentos impresos y electrónicos utilizados en el entorno de trabajo de los
usuarios de los sistemas que contengan software, se ofrecen en esta norma.
Estructura del Documento del U • Estructura General del Documento

suario del Software Componentes Iniciales
Contenido de Información del D • Contenido de Datos de Identificación
ocumento del Usuario del Softw • Información para Uso del documento
are • Concepto de Operación
• Información para Uso General del Software
• Información para Procedimientos y Tutoriales
• Información sobre Terminología
• Información sobre Fuentes de Información Relacio
nadas
Formato de Documentación de • Uso de Formato Impreso o Electrónico

Usuario del Software • Legibilidad
• Formatos para Representar Elementos de Interface
s de Usuario
• Formatos para Características del Document
o para Acceder a la Información
• Formato para Características de navegación
en este estándar estudiado
1.6.4.1 Estructura del documento del usuario del software.

Esta sección puede ser estructurada en un solo documento o una serie de documentos
impresos o electrónicos.
Estructura general del documento. Esta sección debe estructurar la documentación

en unidades con contenido único, como puede ser:
26
• Un documento impreso es estructurado dentro de las unidades lógicas llamadas
capítulos, subdivididos dentro del tema, los cuales pueden ser divididos dentro de
subtemas e impresos en unidades físicas llamadas páginas.
• Un documento electrónico es estructurado dentro de las unidades lógicas
llamadas temas y presentados en unidades físicas llamadas paginas o pantallas.
Componentes iniciales. Esta sección debe empezar con datos de identificación y la

introducción, el primer capítulo o tema del documento es la introducción, describe el
alcance y el propósito del software.
1.6.4.2 Contenido de información del documento del usuario del software
Contenido de datos de identificación. Esta sección debe contener la siguiente

información:
• Título del Documento
• Versión y Fecha del Documento
• Versión del Producto Software
• Responsable del Documento
Información para uso del documento. Esta sección debe incluir información de
cómo manejar el documento y recomendar como consultar las secciones del
documento, si un documento está contenido de varios volúmenes puede tener una
guía separada del contenido. La documentación puede incluir la identificación y la
versión del documento y software.
Concepto de operación.- Esta sección debe explicar los antecedentes para el uso del
software, usando como un antecedente el método visual o verbal del proceso de
trabajo o en forma general lo que hará el software y el documento, este antecedente
debe ser explicado en términos familiares para el usuario.
Información para uso general del software.- Esta sección debe incluir la siguiente
información:
27
• Instalación y desinstalación del software
• Características de interconexión
• Acceso al software.
• Navegación y salida del software mediante el acceso al sistema.
• Operación de datos (editar, guardar, leer, imprimir, actualizar y borrar).
• Métodos de cancelación, interrumpiendo y reinicio de operación.
Información para procedimientos y tutoriales.- Esta sección debe incluir la

siguiente información:
• Visión general del propósito del procedimiento y explicar los conceptos
necesarios no incluido en otras partes.
• Identificar las actividades técnicas y administrativas que deben ser hechas
antes de empezar como pueden ser software adicional, identificación de
drivers, interconexiones o protocolos.
• Advertencias relevantes, prevenciones y notas que aplican al procedimiento
entero.
Información sobre terminología.- Esta sección debe incluir un glosario de términos

ordenados alfabéticamente, tanto de abreviaciones y siglas no familiares al usuario,
el glosario puede ser impreso o electrónico.
Información sobre fuentes de información relacionadas.- Esta sección puede

incluir lo siguiente:
• Especificación de requerimientos, especificación de diseño, estándares
aplicados, para el software y la documentación.
• Planes de prueba y procedimientos para el software y la documentación.
• La documentación del hardware y software.
La documentación debe indicar si la referencia contiene material informativo.
1.6.4.3 Formato de documentación del usuario del software
Esta sección incluye el formato del documento:
• Presentación del documento Impreso o electrónico

• Tipo y tamaño de fuente
28
• Color de la fuente y tamaño del papel
Uso de formatos impresos o electrónicos.- Esta sección debe presentar la siguiente

información, tanto impresa como electrónica:
• Información de Hardware y de software
• Información e instrucciones de instalación
• Instrucciones para utilizar el software.
• Instrucciones para el acceso al software
• Características del software diseñadas para permitir la impresión de
documentos electrónicos.
Legibilidad.- Esta sección describe como debe ser la documentación impresa o

electrónica del usuario:
• La documentación debe ser legible
• Usar papel de color o color de fondo de pantalla, la documentación en línea
debe permanecer legible si el usuario es capaz de agrandar, acortar o reformar
la pantalla o ventana.
Formatos para representar elementos de interfaces de usuario. Esta sección

describe las interfaces gráficas del usuario del software, como los botones, iconos,
usos especiales de claves de teclado o claves de combinaciones y las respuestas
deben ser presentadas en documentación por gráfico consistente o formatos
tipográficos para que cada uno de los elementos sea distinguido del texto. La
documentación debe incluir una representación de elemento. Su propósito y una
explicación de su acción (consecuencia funcional) con ejemplos de operaciones
actuales.
Formatos para características del documento para acceder a la información
Cuadro de contenidos.- Un cuadro de contenidos debe tener encabezados de los

capítulos o títulos de tópicos bajados al tercer nivel. La tabla de contenidos incluye
solo el primer nivel de encabezados, la documentación electrónica puede exhibir
cuadros de contenidos en formato expandibles para proveer el nivel principal y
29
acceso detallado a encabezados. El cuadro de contenidos debe incluir también
apéndices, glosario, e índice.
Lista de ilustraciones. Esta sección contiene las tablas, lista de figuras o una lista de
ilustraciones, si el documento contenido más de 5 ilustraciones numeradas y no es
visible poner una referencia de texto. Las ilustraciones deben tener el número y título
como un punto de acceso a cada uno.
Índice. Esta sección describe cómo organizar el índice, este debe ser
alfabéticamente, los gráficos o conceptos con un punto de acceso para cada uno de
los documentos impresos, cuando tenga más de 40 páginas deben incluir un índice.
Los puntos de acceso puede ser número de páginas, número de tópicos, número de
ilustraciones, o referencias a otro índice de entrada. Los documentos electrónicos con
más de 40 tópicos deben incluir una herramienta de búsqueda un índice de los puntos
de acceso estos son los enlaces electrónicos.
Formatos para características de navegación. Esta sección incluye el encabezado

de los capítulos y tópico, página o título de pantalla y número de pantalla,
encabezados de página, los iconos de navegación deben ser proveídos para que los
usuarios puedan determinar su localización dentro del impreso o documento
electrónico. La documentación puede incluir explicaciones del sistema y
característica específicas.
Las características de navegación deben tener:

• Tabla de contenidos
• Índice
Las características de navegación deben usar formatos consistentes como:

• Enlaces calificados, color o gráfico para distinguirlos el texto simple
• Los enlaces entre tópicos relacionados deben ser bidireccionales, para
cualquier tópico para que los usuarios tengan acceso.
• La referencia electrónica debe ser accesible desde el software que documenta
y debe tener salir de la documentación y retorna al software.
30
El software puede ser enlazado a la ayuda en línea, tutoriales o documentos de
referencia de varias maneras, tales como las siguientes:
• A través de un punto de entrada para ayudar al sistema.
• A través de botones de ayuda en las pantallas del software que proveen
información en un tópico en particular (caja de dialogo y ayudar del nivel de
campo).
• A través de ayuda de contexto sensitivo y texto (claves de herramientas)
1.6.5. Std 730-1998 norma IEEE para planes de aseguramiento de la calidad del
software4
Este estándar especifica el formato y contenido del plan de

aseguramiento de calidad de software, esta etapa tiene como objetivo la consecución
de un primer documento en que queden reflejados los requerimientos y
funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se
va a desarrollar)
Plan de Asegura • Propósito

miento de Calid • Documentos de Referencia
ad de Software • Administración
• Documentación
• Estándares, Practicas y Métricas
• Revisiones de Software
• Pruebas
• Reporte de Problemas y Acciones Correctivas
• Herramientas, Técnicas y Metodología
• Control de Medios de Comunicación
• Control de Proveedor
• Colección de Registros, Mantenimiento y Retención
• Capacitación
• Gestión de Riesgo
• Procedimiento de Cambio SQAP e Historia
4
31
1.6.5.1.- El plan de aseguramiento de calidad de software
El SQAP tiene en la primera página la fecha de emisión, el estado del documento y la

identificación de la organización que realiza el documento, este será aprobado por el
gerente de cada unidad de organización.
Propósito. Está sección detalla el objetivo específico y ámbito particular del SQAP,
se debe incluir el nombre y uso del software señalando en qué fase del ciclo de vida
del software se aplicará el SQAP.
Documentos de referencia. Esta sección lista los documentos que fueron utilizados
para desarrollar el SQAP, estos documentos incluyen las políticas y leyes que
llevaron a desarrollar este plan, La versión y fecha de cada documento debe estar
incluido en la lista.
Administración. Esta sección describe la estructura de la organización del proyecto,

sus tareas, papeles y responsabilidades.
Organización. Esta sección trata la estructura organizacional que interviene y

controla la calidad del software y describe los principales elementos de la
organización, para verificar, evaluar y monitorear la calidad del software, siendo la
organización la responsable de preparar y mantener el SQAP.
Tareas. Esta sección describe:

• Fase del ciclo de vida en la que se aplicara el SQAP
• Tareas a realizarse
• Criterio de entrada y salida de cada tarea
• Relación y secuencia de las tareas
• Horario del plan
32
Papeles y responsables. Esta sección identifica los elementos específicos de la
organización que es responsable de las tareas.
Evaluación de recursos de aseguramiento de calidad
Esta sección evalúa los recursos y costos a ser consumidos en el aseguramiento y

control de la calidad.
Documentación. Esta sección realiza las siguientes funciones:

• Identifica la documentación para controlar el desarrollo, verificando y valida
el uso y mantenimiento del software.
• Lista los documentos que deben ser revisados
Requisitos mínimos de documentación. Esta sección asegura que la

implementación del software cumple con los documentos básicos para satisfacer los
requisitos técnicos.
Descripción de los requisitos del software (srd). Esta sección específica los
requisitos que pueden ser escritos por el proveedor (interno o externo), cliente o
ambos, cada requisito debe ser identificado y definido únicamente para verificar y
validar objetivamente.
1.6.5.2 Descripción del diseño del software (sdd)
Esta sección toma la estructura del software para satisfacer los requisitos (srd). El
SDD debe describir los componentes y subcomponentes del diseño del software
incluyendo la base de datos e interfaz interna para lo cual se puede realizar un
prototipo.
Plan de verificación y validación. Esta sección se utiliza para determinar que el

producto software este acorde a los requisitos y si cumple con las expectativas del
usuario. El plan de verificación y validación puede ser adjuntado a un solo
33
documento y define la verificación y validación de tareas, entrada y salida de
información para salvaguardar el nivel de integridad del software.
Reporte de resultados de verificación y validación. Esta sección describe los

resultados de las actividades realizadas en el software de acuerdo al plan.
Documentación del usuario. Esta sección guía al usuario en la instalación,

operación, administración y mantenimiento del producto software, este documento
describe el control y la secuencia de la información de entrada, opciones,
limitaciones del programa y otra información, con este documento el usuario puede
manipular el sistema.
Plan de gestión de configuración del software (smcp). Esta sección documenta las
actividades del smcp en el que se definen las rutas para mantener, guardar, asegurar,
controlar y documentar las versiones en las bibliotecas, este plan se aplica a la parte
del ciclo de vida que se desarrolle el sqap.
Otra documentación. Esta sección identifica otros documentos aplicables al

proyecto de desarrollo del software, puede incluir los siguientes documentos:
• Plan de proceso de desarrollo
• Métodos de ingeniería de software/proceso/descripción de herramientas.
• Plan de gestión del proyecto software
• Plan de mantenimiento
• Plan de seguridad del software
• Plan de integración del software.
1.6.5.3 Norma IEEE para los planes de gestión de proyectos de software - IEEE
std 1058-1998 5
5
34
Este estándar describe el formato y contenido del plan de gestión del proyecto
software, se aplica a cualquier tipo o tamaño de proyecto software
Introducción. • Visión general del proyecto.

• Productos finales.
• Evolución del plan de proyecto.
• Documentos de referencia.
• Definiciones y acrónimos.
• Organización • Modelos de
del proyecto. procesos.
• Estructura
organizativa.
• Fronteras e
interfaces
organizativas.
• Responsabilidades
• Procesos de gestión. • Objetivos y prioridades de gestión.
• Suposiciones, dependencias y restricciones.
• Gestión de riesgos.
• Mecanismos de supervisión y control.
• Plan de personal.
• Proceso técnico • Metodologías, técnicas y herramientas.

• Documentación software.
• Funciones de apoyo al proyecto.
• Plan de desarrollo. • Paquetes de trabajo.

• Dependencias.
• Recursos.
• Presupuesto y distribución de recursos.
Calendario.
Introducción
Visión general del proyecto. Esta subsección del pgps incluirá un resumen conciso
de los objetivos del proyecto, el producto a entregar, las principales actividades de
35
trabajo, los principales productos de trabajo, los principales hitos, los recursos
necesarios, y el calendario y el presupuesto maestro.
La descripción del proyecto incluirá asimismo la relación de este proyecto a otros
proyectos, según corresponda. Esta descripción, no se interpretará como una
especificación oficial de los requisitos del producto. La referencia a la especificación
de los requisitos del software se presentará en este tramo de la pgps.
Productos finales. Esta subsección del pgps incluirá en la lista todos los ítems que se
entrega al cliente, las fechas de entrega, los lugares de entrega, y las cantidades
necesarias para satisfacer los términos del acuerdo de proyecto. Esta lista de
entregables del proyecto, no se interpretará como una declaración oficial de los
requisitos del proyecto.
Evolución del plan del proyecto. Esta subsección del pgps debería especificar los
planes para llevar a cabo tanto las actualizaciones planificadas del plan, como las no
planificadas del pgps. Este apartado se especificará también los mecanismos
utilizados para colocar la versión inicial del pgps bajo el cambio de control y para
controlar los cambios posteriores a la spmp.
Documentos de referencia. Esta subsección del pgps debería ofrecer una lista
completa de todos los documentos y otras fuentes de información referenciadas en el
pgps. Cada documento debería ser identificado por un título, número de informe,
autor y organización que lo publicó. Otras fuentes de información tales como
ficheros electrónicos, deberían ser identificadas de una manera no ambigua usando
identificadores, tales como el número de versión y la fecha de su publicación.
Cualquier desviación de los estándares referenciados o políticas debería ser
identificado y aportado las correspondientes justificaciones.
Definiciones y acrónimos. Esta subsección del pgps debería definir o proveer

referencias a los términos y acrónimos necesarios para comprender adecuadamente el
pgps.
Organización del proyecto
36
Modelo de procesos. Esta subsección del pgps debería definir las relaciones entre las
funciones principales del proyecto y las actividades, especificando el calendario de
los hitos principales, documentos bases, revisiones, productos de trabajo, productos
entregables, y el fin del proyecto. El modelo de procesos puede ser descrito
utilizando una combinación de notaciones textuales y gráficas.
El modelo de proceso puede incluir las actividades de iniciación y finalización del
proyecto.
Estructura organizativa. Esta sub sección del pgps debería describir la estructura
para la gestión interna del proyecto. Dispositivos gráficos tales como gráficos de
organizaciones jerárquicas o diagramas de matrices pueden ser usados para
representar las líneas de autoridad, responsabilidad y comunicación dentro del
proyecto.
Límites e interfaces organizativos. Esta subsección del pgps debería describir los
límites administrativos y de gestión entre el proyecto y cada una de las siguientes
entidades: organización que se encarga del proyecto, la organización cliente,
organizaciones subcontratadas o cualquier otra entidad organizativa que interaccione
con el proyecto. Además, las interfaces de administración y gestión de las funciones
de soporte del proyecto, tales como la gestión de configuración, control de calidad y
verificación y validación se especificarán en este apartado.
Responsabilidades. Esta subsección del psmp deberá determinar y precisar la

naturaleza de cada función importante proyecto y actividad, e identificar a los
individuos que son responsables de las funciones y actividades. Una matriz de
funciones y actividades versus las personas responsables pueden ser utilizadas para
representar las responsabilidades del proyecto.
Procesos de gestión. Esta sección de la pgps especificará objetivos y prioridades de

gestión; suposiciones del proyecto, las dependencias y las limitaciones, técnicas de
gestión de riesgos, la supervisión y el control de los mecanismos que se utilizarán, y
el plan de personal.
Objetivos y prioridades de gestión. Esta subsección del pgps dará cuenta de la

filosofía, objetivos y prioridades para la gestión de las actividades realizadas durante
37
el proyecto. Los temas que se especifican pueden incluir, pero no se limitan a, la
frecuencia y los mecanismos para la generación de informes que se utilizarán; la
prioridad de los requisitos, el programa y presupuesto para este proyecto, los
procedimientos de gestión de riesgos que ha de seguirse, y una declaración de
intenciones para adquirir, modificar, o utilizar el software existente
Suposiciones, dependencias y restricciones. Esta subsección del pgps debería
afirmar los supuestos en los que está basado el proyecto, los acontecimientos
externos de los que el proyecto depende y las restricciones que bajo las cuales el
proyecto va a ser guiado.
Gestión de riesgos. Esta subsección del pgps debería identificar y valorar los
factores de riesgos asociados al proyecto. Esta subsección también debería prescribir
mecanismos para el rastreo de varios factores de riesgo e implementar planes de
contingencia. Los factores de riesgos que deberían ser considerados incluyen riesgos
contractuales, tecnológicos, riesgos debidos al tamaño y complejidad del proyecto,
riesgos en la adquisición y retención del personal, y riesgos en lograr que el cliente
acepte el producto.
Mecanismos de supervisión y control. Esta subsección del pgps debería definir los
mecanismos para generar informes, los formatos de los informes, flujos de
información, mecanismos de auditoría y revisión, y otras herramientas y técnicas que
pueden ser usadas para controlar las adiciones al pgps.
El control del proyecto debería ocurrir en el nivel de paquetes de trabajo. La relación
entre los mecanismos para controlar el proyecto y las funciones de soporte deberían
ser trazadas en este nivel.
Plan del personal. Esta sección del pgps especificará el número y tipo de personal
necesario para llevar a cabo el proyecto. Los niveles de cualificación requeridos, los
tiempos de comienzo, la duración de la necesidad, y los métodos de obtención, la
formación, retención y eliminación gradual del personal se especificarán
Procesos técnicos. Esta sección del pgps deberá especificar los métodos técnicos,
herramientas y técnicas analíticas que se utilizarán en el proyecto. Además, el plan
para la documentación de software se especifica, y los planes para las funciones de
38
soporte del proyecto, como garantía de la calidad, gestión de configuración, la
verificación y validación pueden ser especificados
Metodologías, herramientas y técnicas. Esta subsunción de la pgps deberá

especificar el/los sistema informático(s), metodología/s de desarrollo, la/s estructura
del equipo, el/los lenguaje de programación, y otras anotaciones, herramientas,
técnicas y métodos que deben utilizarse para especificar, diseñar, construir, probar,
integrar, documentar, modificar o mantener o ambos (según corresponda) las
prestaciones del proyecto. Además, las normas técnicas, políticas y procedimientos
que rigen el desarrollo o la modificación o ambos de los productos de trabajo y las
prestaciones del proyecto se incluirán, ya sea directamente o por referencia a otros
documentos.
Documentación del software. Esta subsección del pgps debería contener o

referenciar el plan de documentación del proyecto software. El plan del documento
debería especificar los requisitos de documentación, los hitos, líneas base, revisiones
y la finalización de la documentación del software. El plan de documentación
también puede contener una guía de estilo, convenciones en la nomenclatura y
formatos del documento. El plan de documentación podría incluir un resumen de la
agenda y los recursos necesarios para el esfuerzo de la documentación. El estándar
ansi/ieee 829-1983 “standard for software test documentation” ofrece el estándar
para la documentación de pruebas del software.
Funciones de apoyo al proyectos. Esta subsección del pgps debería contener

directamente o por referencia los planes para las funciones de soporte para el
proyecto software. Estas funciones pueden incluir, pero no están limitadas a, gestión
de la configuración, aseguramiento de la calidad del software, y verificación y
validación. Los planes para las funciones de soporte al proyecto deberán ser
desarrollados a un nivel de detalles consistente con las otras secciones del pgps. En
particular, se deben especificar las responsabilidades, requerimientos de recursos,
agendas y herramientas para cada una de las funciones de soporte al proyecto. La
naturaleza y tipo de las funciones de soporte al proyecto variarán de un proyecto a
otro; de todos modos, la ausencia del aseguramiento de calidad software, gestión de
39
la configuración o plan de verificación y Validación debe ser explícitamente
justificado en los planes de los proyectos que no los incluyan.
Plan de desarrollo
Paquetes de trabajo. Esta subsección del pgps debería especificar los paquetes de
trabajo para las tareas y actividades que deben completarse en orden para satisfacer
los acuerdos del proyecto. Cada paquete de trabajo debería ser unívocamente
identificado; la identificación puede estar basada en un esquema numerado y títulos
descriptivos. Se puede usar un diagrama que describa la división de las actividades
en sub-actividades y tareas (estructura de desglose) para describir las relaciones
jerárquicas entre los distintos paquetes de trabajo.
Dependencias. Esta subsección del pgps debería especificar las relaciones de orden
entre los distintos paquetes de trabajo para reflejar de alguna forma las
interdependencias entre ellos y la dependencia de acontecimientos externos al
proyecto. Se pueden usar técnicas tales como las listas de dependencia, redes de
actividades, y método de camino crítico para describir las dependencias entre los
distintos paquetes de trabajo.
Requerimientos de recursos. Esta subsección del pgps debería proporcionar, en

función del tiempo, estimaciones del total de los recursos necesarios para completar
el pgps. El número y tipo del personal, tiempo de computación, software de soporte,
ordenadores, facilidades de laboratorios y oficinas, viajes, y requerimientos de
mantenimiento para los recursos de proyectos deberían ser especificados.
Presupuesto y distribución de recursos. Esta subsección del pgps debería

especificar la localización de las herramientas y recursos de las distintas funciones
del proyecto, actividades y tareas. Se puede usar un esquema de ganancia de valores
para localizar herramientas y recursos, y para llevar un control del gasto y de la
utilización de los recursos.
40
1.6.5.4 IEEE estándar para la verificación y validación de software - IEEE STD
1012-2004 6
Este estándar describe verificación de software y procesos de validación que se

utilizan para determinar si los productos de software de una actividad cumple los
requisitos de la actividad y para determinar si el software satisface las necesidades
del usuario para el uso previsto. El alcance incluye el análisis, evaluación, revisión,
inspección, evaluación y prueba de productos y procesos.
6
41
Requerimientos para verificar
Estrategia de verificación • Tipos de pruebas o
• Prueba de integridad o Objetivo de la prueba técnica
de los datos y la base o Técnica
de datos o Criterio de aceptación
o Consideraciones especiales
• Prueba de o Objetivo de la prueba
funcionalidad o Técnica
o Criterio de aceptación
• Prueba de ciclo del o Objetivo de la prueba

negocio o Técnica
• Prueba de interface de o Objetivo de la prueba

usuario o Técnica
• Prueba de performance o Objetivo de la prueba
o Técnica
• Prueba de carga o Objetivo de la prueba
o Técnica
42
• Prueba de esfuerzo o Objetivo de la prueba

(stress, competencia o Técnica
por recursos, bajos o Criterio de aceptación
recursos) o Consideraciones especiales
• Prueba de volumen o Objetivo de la prueba

o Técnica
o Consideraciones
especiales

seguridad y o Técnica
control de o Criterio de aceptación
acceso o Consideraciones especiales

fallas y o Técnica
recuperación o Criterio de aceptación
43
Prueba de o Objetivo de la prueba
configuración o Técnica

instalación o Técnica

documentos o Técnica
Herramientas
44
1. Recursos 1.1. Roles
• Rol • Cantidad mínima de o Responsabilidades
recursos recomendada
• Responsable de o Identifica, prioriza e implementa
verificación los casos de prueba.
o Genera el plan de verificación.
o Genera el modelo de prueba.
o Evalúa el esfuerzo necesario para
verificar.
o Proporciona la dirección técnica.
o Adquiere los recursos
apropiados.
o Proporciona informes sobre la
verificación.
• Asistente de o Ejecuta las pruebas
verificación o Registra los resultados de las
pruebas.
o Recuperar el software de errores.
o Documenta los pedidos de
cambio.
• Administrador de base o Realiza la gestión y
de datos mantenimiento del entorno de los
datos (base de datos) de prueba y
los recursos.
o Administra la base de datos de
prueba.
45
Sistema
Recurso Nombre/tipo
Servidor de base de datos

red o subred
nombre del servidor
nombre de la base de datos
Pc cliente para pruebas

requerimientos especiales
Repositorio de pruebas
red o subred
nombre del servidor
46
Hitos del proyecto de Actividad que determina Esfuerzo Fecha de Fecha de
verificación el hito comienzo finalización
Planificar la verificación
Elaborar casos de prueba

Ajuste y control de
verificación
Ejecutar la verificación
Evaluar la verificación
Entregables o Modelo de casos de prueba

o Informes de verificación
o Evaluación de la verificación
o Informe final de verificación
Dependencias [opcional] o Dependencia de personal [opcional]

o Dependencia de software [opcional]
o Dependencia de datos y base de datos de prueba [opcional]
Riesgos [opcional] o Planificación [opcional]

o Técnico [opcional]
o Gestión [opcional]
47
Requerimientos para verificar
En la lista a continuación se presentan los elementos, casos de uso, requerimientos

funcionales y requerimientos no funcionales, que serán verificados.
Lista de los requerimientos más importantes a ser verificados. En esta sección
indique qué elementos serán verificados.
Estrategia de verificación
• Esta sección presenta el enfoque recomendado para la verificación. Describe

como se verificarán los elementos.
• Para cada tipo de prueba, proporcione una descripción de la prueba y porque será
implementada y ejecutada.
• Si un tipo de prueba no será implementada y ejecutada, indique brevemente cual
es la prueba que no se implementará o ejecutará y una justificación de ello.
• Se indicarán las técnicas usadas y el criterio para saber cuándo una prueba se
completó (criterio de aceptación).
• Las pruebas se deben ejecutar usando bases de datos conocidas y controladas en
un ambiente seguro.
Tipos de pruebas
En las secciones a continuación, que son los tipos de pruebas a realizar, para cada
tipo de prueba en lugar de explicar el contenido de cada sección y subsección se
incluyen ejemplos.
Prueba de integridad de los datos y la base de datos
Objetivo de la prueba. Asegurar que los métodos y procesos de acceso a la base de

datos funcionan correctamente y sin corromper datos.
48
Técnica
• Invoque cada método o proceso de acceso a la base de datos con datos

válidos y no válidos.
• Inspeccione la base de datos para asegurarse de que se han guardado los datos
correctos, que todos los eventos de la base de datos ocurrieron correctamente,
o repase los datos devueltos para asegurar que se recuperaron datos correctos
por la vía correcta.
Criterio de aceptación
Todos los métodos y procesos de acceso a la base de datos funcionan como fueron
diseñados y sin datos corruptos.
Consideraciones especiales
• La prueba requiere un entorno de administración de dbms o controladores para

ingresar o modificar información directamente en la base de datos.
• Los procesos deben ser invocados manualmente.
• Se deben usar bases de datos pequeñas para aumentar la facilidad de inspección
de los datos para verificar que no sucedan eventos no aceptables.
Prueba de funcionalidad.- La prueba de funcionalidad se enfoca en requerimientos

para verificar que se corresponden directamente a casos de usos o funciones y reglas
del negocio. Los objetivos de estas pruebas son verificar la aceptación de los datos,
el proceso, la recuperación y la implementación correcta de las reglas del negocio.
Este tipo de prueba se basa en técnicas de caja negra, que consisten en verificar la
aplicación y sus procesos interactuando con la aplicación por medio de la interface
de usuario y analizar los resultados obtenidos.
Objetivo de la prueba
• Asegurar la funcionalidad apropiada del objeto de prueba, incluyendo la
navegación, entrada de datos, proceso y recuperación.
49
Técnica
Ejecute cada caso de uso, flujo de caso de uso, o función usando datos válidos y no
válidos, para verificar lo siguiente:
• Se obtienen los resultados esperados cuando se usan datos válidos.

• Cuando se usan datos no válidos se despliegan los mensajes de error o
advertencia apropiados.
• Se aplica apropiadamente cada regla del negocio.
• Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han
sido debidamente identificados.
• Identificar o describir aquellos elementos o problemas (internos o externos) que

impactaron en la implementación y ejecución de las pruebas de funcionalidad.
Prueba de ciclo del negocio
• Esta prueba debe simular las actividades realizadas en el proyecto en el tiempo.

Se debe identificar un período, que puede ser un año, y se deben ejecutar las
transacciones y actividades que ocurrirían en el período de un año. Esto incluye
todos los ciclos diarios, semanales y mensuales y eventos que son sensibles a la
fecha.
• Asegurar que la aplicación funciona de acuerdo a los requerimientos del negocio.
Técnica La prueba debe simular ciclos de negocios realizando lo siguiente:
50
• Las pruebas de funcionalidad se deben modificar para aumentar la cantidad de
veces que se ejecuta cada función, simulando varios usuarios diferentes en un
período determinado.
• Todas las funciones sensibles a la fecha se deben ejecutar con fechas válidas y no
válidas o períodos de tiempos válidos y no válidos.
• Para cada prueba realizada verificar lo siguiente:
• Se obtienen los resultados esperados cuando se usan datos válidos.
• Cuando se usan datos no válidos se despliegan los mensajes de error o
advertencia apropiados.
• Se aplica apropiadamente cada regla del negocio.
• Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han
sido debidamente identificados.
• Las fechas del sistema y eventos requieren actividades de soporte especiales. Se

requieren las reglas del negocio para identificar apropiadamente los
requerimientos y procedimientos a ser verificados.
Prueba de interface de usuario
• Esta prueba verifica que la interface de usuario proporcione al usuario el acceso y

navegación a través de las funciones apropiada. Además asegura que los objetos
presentes en la interface de usuario se muestren como se espera y conforme a los
estándares establecidos por la empresa o de la industria.
• Verificar que: la navegación a través de los elementos que se están probando

reflejen las funciones del negocio y los requerimientos, incluyendo manejo de
51
ventanas, campos y métodos de acceso; los objetos de las ventanas y
características, como menú es, tamaño, posición, estado funcionen de acuerdo a
los estándares.
Técnica
• Crear o modificar pruebas para cada ventana verificando la navegación y los

estados de los objetos para cada ventana de la aplicación y cada objeto dentro de
la ventana.
• Cada ventana ha sido verificada exitosamente siendo consistente con una versión
de referencia o estándar establecido.
• No todas las propiedades de los objetos se pueden acceder.
Prueba de performance
• En esta prueba se miden y evalúan los tiempos de respuesta, los tiempos de

transacción y otros requerimientos sensitivos al tiempo. El objetivo de la prueba
es verificar que se logren los requerimientos de performance. La prueba de
performance es implementada y ejecutada para poner a punto los destinos de
pruebas de performance como función de condiciones de trabajo o
configuraciones de hardware.
Verificar la performance de determinadas transacciones o funciones de negocio bajo

ciertas condiciones:
Condiciones de trabajo normales conocidas.
52
Peores casos de condiciones de trabajo conocidas.
Técnica
Usar procedimientos de prueba desarrollados para verificar funciones o ciclos de

negocio.
Modificar archivos de datos para aumentar el número de transacciones o los
procedimientos de prueba para aumentar el número de iteraciones de ocurrencia de
transacciones.
Las pruebas se deben ejecutar en una máquina (mejor caso de prueba un solo usuario,
una sola transacción) y se debe repetir con múltiples usuarios (virtuales o reales).
• Con una transacción o un usuario: éxito completo de la prueba sin fallas y dentro
del tiempo esperado o requerido.
• Con múltiples transacciones y varios usuarios: éxito completo de la prueba sin
fallas y dentro de un tiempo aceptable.
Las pruebas de performance deben incluir un trabajo de fondo en el servidor. Esto se

puede realizar de distintas formas:
Enviar transacciones directamente al servidor, generalmente en la forma de consultas
(SQL).
Crear usuarios virtuales para simular muchos clientes, generalmente varios cientos.
Se pueden usar herramientas de emulación de terminar remota para lograr este
objetivo. Esta técnica también se usa para cargar la red con “trafico”.
Usar muchos clientes físicos, cada uno corriendo procedimientos de prueba.
La prueba de performance se debe realizar en una máquina dedicada para permitir
control total y medición exacta.
Las bases de datos usadas para las pruebas de performance deben tener un tamaño
similar a las reales.
53
Prueba de carga
La prueba de carga somete los objetos a verificar a diferentes cargas de trabajo para
medir y evaluar los comportamientos de performance y la habilidad de los objetos de
continuar funcionando apropiadamente bajo diferentes cargas de trabajo. El objetivo
es determinar y asegurar que el sistema funciona apropiadamente en circunstancias
de máxima carga de trabajo esperada. Además evaluar las características de
performance, como tiempos de respuesta, tiempos de transacciones y otros elementos
sensitivos al tiempo.
• Verificar el comportamiento de performance de determinados componentes del

software bajo condiciones de trabajo diferentes.
Técnica
• Usar pruebas desarrolladas para funciones o ciclos de negocios y modificar

archivos de datos para aumentar el número de transacciones o las pruebas para
aumentar la cantidad de ocurrencia de transacciones.
• Para múltiples transacciones y múltiples usuarios: realización exitosa de las

pruebas sin fallas y dentro del tiempo aceptable.
• La prueba de carga debe realizarse en una máquina dedicada para tener control
total y exactitud de mediciones.
• Las bases de datos usadas para la prueba deben tener un tamaño similar a las
reales.
54
Prueba de esfuerzo (stress, competencia por recursos, bajos recursos)
La prueba de esfuerzo en un tipo de prueba de performance implementada y

ejecutada para encontrar errores cuando hay pocos recursos o cuando hay
competencia por recursos. Poca memoria o poco espacio de disco pueden revelar
fallas en el software que no aparecen bajo condiciones normales de cantidad de
recursos. Otras fallas pueden resultar al competir por recursos compartidos como
bloqueos de bases de datos o ancho de banda de red. La prueba de esfuerzo también
puede usarse para identificar el trabajo máximo que el software puede manejar.
Verificar que el software funciona apropiadamente y sin error bajo condiciones de
esfuerzo, como son:
• Poca memoria o sin disponibilidad de memoria en el servidor
• Cantidad máxima de clientes conectados
• Múltiples usuarios realizando la misma operación sobre los mismos datos
• Peor caso de volumen de operaciones.
• El objetivo de la prueba de esfuerzo es también identificar y documentar las
condiciones bajo las cuales el sistema falla y no continua funcionando
apropiadamente.
Técnica
• Usar las pruebas desarrolladas para performance y prueba de carga.
• Para probar recursos limitados, las pruebas se deben ejecutar en una sola
máquina, y se debe reducir o limitar la memoria en el servidor.
• Para las pruebas de esfuerzo restantes, deber usarse múltiples clientes, cualquiera
que ejecute las mismas pruebas o pruebas complementarias para producir el peor
caso de volumen de operaciones.
Todas las pruebas planeadas se ejecutaron y se alcanzaron o excedieron los límites
del sistema sin que el software fallara o las condiciones bajo las que ocurre una falla
en el software están fuera de las condiciones especificadas.
55
• Las pruebas de esfuerzo de red pueden requerir herramientas de red para

cargar la red con mensajes o paquetes.
• La cantidad de disco del servidor usada por el sistema debe ser reducida
temporalmente para restringir el espacio disponible para crecimiento de la
base de datos.
• Sincronizar el acceso simultáneo de varios clientes accediendo a los mismos
datos.
Prueba de volumen
La prueba de volumen somete el software a grandes cantidades de datos para
determinar si se alcanzan límites que causen la falla del software. La prueba de
volumen identifica la carga máxima continua que puede manejar el software a prueba
en un período dado.
Verificar que el software funciona correctamente con volúmenes de datos grandes:
Máximo (real o físicamente posible) número de clientes conectados, o simulados,
todos realizando la misma operación (peor caso de operación) por un período de
tiempo extenso. Máximo tamaño de base de datos y múltiples consultas ejecutadas
simultáneamente.
Técnica
Usar pruebas desarrolladas para prueba de performance y prueba de carga.
Se deben usar múltiples clientes, ejecutando las mismas pruebas o pruebas
complementarias para producir el peor caso de volumen de operaciones o mezcla en
un período de tiempo extenso. Se debe crear el tamaño máximo de base de datos
(real, escalado o con datos representativos) y múltiples clientes ejecutando consultas
simultáneamente por un período de tiempo extenso.
Criterio de aceptación Todas las pruebas planificadas se ejecutaron y se han

alcanzado o excedido los límites especificados sin que el software falle.
56
• ¿qué período de tiempo se considera aceptable para condiciones de gran
volumen?
Prueba de seguridad y control de acceso
La prueba de seguridad y control de acceso se enfoca en dos áreas de seguridad:

Seguridad en el ámbito de aplicación, incluyendo el acceso a los datos y a las
funciones de negocios.
Seguridad en el ámbito de sistema, incluyendo conexión, o acceso remoto al sistema.

La seguridad en el ámbito de aplicación asegura que, basado en la seguridad deseada
los actores están restringidos a funciones o casos de uso específicos o limitados en
los datos que están disponibles para ellos.
La seguridad en el ámbito de sistema asegura que, solo los usuarios con derecho a
acceder al sistema son capaces de acceder a las aplicaciones y solo a través de los
puntos de ingresos apropiados.
• Seguridad en el ámbito de aplicación: verificar que un actor pueda acceder solo a
las funciones o datos para los cuales su tipo de usuario tiene permiso.
• Seguridad en el ámbito de sistema: verificar que solo los actores con acceso al
sistema y a las aplicaciones, puedan acceder a ellos.
Técnica
• Seguridad en el ámbito de aplicación: identificar y hacer una lista de cada
tipo de usuario y las funciones y datos sobre las que cada tipo tiene permiso.
• Crear pruebas para cada tipo de usuario y verificar cada permiso creando
operaciones específicas para cada tipo de usuario.
• Modificar el tipo de usuario y volver a ejecutar las pruebas para los mismos
usuarios. En cada caso, verificar que las funciones o datos adicionales están
correctamente disponibles o son denegados.
57
• Acceso en el ámbito de sistema: ver consideraciones especiales más abajo.
• Para cada tipo de actor conocido las funciones y datos apropiados están
disponibles, y todas las operaciones funcionan como se espera y ejecutan las
pruebas de funcionalidad de la aplicación.
• El acceso al sistema debe ser discutido con el administrador del sistema o la
red. Esta prueba no puede requerirse como tal, es una función del
administrador del sistema o de la red.
Prueba de fallas y recuperación
• Las pruebas de fallas y recuperación aseguran que el software puede

recuperarse de fallas de hardware, software o mal funcionamiento de la red
sin pérdida de datos o de integridad de los datos.
• La prueba de recuperación es un proceso en el cual la aplicación o sistema se
expone a condiciones extremas, o condiciones simuladas, para causar falla,
como fallas en dispositivos de entrada/salida o punteros a la base de datos
inválidos. Los procedimientos de recuperación se invocan y la aplicación o
sistema es monitoreado e inspeccionado para verificar que se recupera
apropiadamente la aplicación o sistema y se logre la recuperación de datos.
Verificar que los procesos de recuperación (manual o automáticos) recuperen
apropiadamente la base de datos, aplicaciones y sistema a un estado conocido y
deseado. En la prueba se incluyen los siguientes tipos de condiciones:
• Interrupción de energía al cliente
• Interrupción de energía al servidor
• Interrupción de comunicaciones mediante los servidores de la red
• Interrupción de comunicación o pérdida de energía de los discos del servidor
o con los controladores
58
• Ciclos incompletos (procesos de filtro de datos interrumpidos, procesos de
sincronización de datos interrumpidos)
• Punteros a la base de datos o claves inválidos
• Elementos de datos en la base de datos inválidos o corruptos.
Técnica
Se deben usar las pruebas creadas para probar funcionalidad y ciclos de negocio para
crear una serie de operaciones. Una vez logrado el punto de comienzo deseado, se
deben realizar o simular las siguientes acciones, individualmente:
• Interrumpir la energía del cliente: apagar el pc.
• Interrumpir la energía del servidor: simular o iniciar el proceso de apagado
del servidor.
• Interrupción por medio de los servidores de red: simular o iniciar la pérdida
de comunicación con la red (desconectar físicamente la comunicación o
apagar el servidor de red o router.
• Interrumpir la comunicación o quitar la energía de los discos del servidor o
sus controladores: simular o eliminar físicamente a la comunicación con uno
o más controladores de disco o los discos.
Una vez que se lograron o simularon estas condiciones, se deben invocar los
procedimientos de recuperación.
Las pruebas de ciclos incompletos utilizan la misma técnica excepto que los procesos
de bases de datos deben ser abortados a sí mismos o terminados prematuramente.
Las últimas dos pruebas requieren que se logre un estado conocido de la base de
datos. Se deben corromper manualmente campos de la base de datos, punteros y
claves trabajando directamente sobre la base de datos (utilizando herramientas para
la base de datos). Se deben ejecutar las pruebas de funcionalidad y ciclo de negocio y
verificar que los ciclos se completen.
59
• En todos los casos, la aplicación, la base de datos y el sistema deben, en la
realización procedimientos de recuperación, volver a un estado conocido y
deseable. Este estado incluye corrupción de datos limitada a los campos, punteros
o claves corruptos conocidos, y reportes indicando los procesos u operaciones
que no se completaron debido a las interrupciones.
• Los procedimientos para desconectar cables (simulando falta de energía o

pérdida de comunicación) no son deseables o factibles. Se pueden requerir
métodos alternativos, como software de diagnóstico. Se requieren los grupos
de recursos de sistemas, bases de datos y red.
• Estas pruebas deben ejecutarse fuera del horario de trabajo normal o en una
máquina aislada.
Prueba de configuración
• La prueba de configuración verifica el funcionamiento del software con

diferentes configuraciones de software y hardware.
• Verificar que el software funcione apropiadamente en las configuraciones

requeridas de hardware y software
Técnica
Usar las pruebas de funcionalidad.
• Abrir y cerrar varias sesiones de software que no son objeto de prueba, como
parte de la prueba o antes de comenzar la prueba.
• Ejecutar operaciones seleccionadas para simular la interacción del actor con
el software objeto de prueba y con el software que no es objeto de prueba.
60
• Repetir los procedimientos anteriores minimizando la memoria convencional
disponible en la máquina cliente.
• Por cada combinación de software objeto de prueba y software que no es objeto

de prueba, todas las operaciones son completadas exitosamente sin fallas.
Todo el software que no es objeto de prueba que es necesario y debe estar accesible.
• ¿qué aplicaciones se usan normalmente?
• ¿qué información se maneja en las aplicaciones que se usan normalmente, y que
tamaño de información?
• Los sistemas, red, servidores de red, bases de datos, etc., deben ser documentados
como parte de esta prueba.
Prueba de instalación
• La prueba de instalación tiene dos propósitos. Uno es asegurar que el software
puede ser instalado en diferentes condiciones (como una nueva instalación, una
actualización, y una instalación completa o personalizada) bajo condiciones
normales y anormales. Condiciones anormales pueden ser insuficiente espacio en
disco, falta de privilegios para crear directorios, etc. El otro propósito es verificar
que, una vez instalado, el software opera correctamente. Esto significa
normalmente ejecutar un conjunto de pruebas que fueron desarrolladas para
prueba de funcionalidad.
Verificar que el software objeto de prueba se instala correctamente en cada
configuración de hardware requerida bajo las siguientes condiciones:
Instalación nueva, una nueva máquina, nunca instalada previamente con [nombre del
proyecto]
Actualización, máquina previamente instalada con [nombre del proyecto], con la
misma versión
61
Actualización, máquina previamente instalada con [nombre del proyecto], con una
versión anterior.
Técnica
• Manualmente o desarrollando programas, para validar la condición de la máquina
destino (nueva, nunca instalado, misma versión, versión anterior ya instalada).
• Realizar la instalación.
• Ejecutar un conjunto de pruebas funcionales ya implementadas para la prueba de
funcionalidad.
• Las pruebas de funcionalidad de [nombre de proyecto] se ejecutan exitosamente
sin fallas.
Herramientas
Ingrese una lista con las herramientas usadas en el proyecto, como son herramientas
de gestión de sistema de bases de datos (dbms), herramientas para gestión de
proyecto, seguimiento de errores, monitoreo de cubrimiento de pruebas, etc. Para
cada herramienta indique la tarea para la que se usa, el nombre de la herramienta, el
origen (vendedor o software hecho en la empresa) y la versión.
Recursos
• En esta sección se presentan los recursos recomendados para el proyecto [nombre

de proyecto], sus principales responsabilidades y su conocimiento o habilidades.
Roles En la tabla a continuación se muestra la composición de personal para el

proyecto [nombre del proyecto] en el área verificación del software.
62
Rol CMR Responsabilidades
Responsable de verificación (Cantidad Identifica, prioriza e implementa los casos de
mínima de prueba.
recursos • Genera el plan de verificación.
recomend • Genera el modelo de prueba.
ada) • Evalúa el esfuerzo necesario para verificar.
• Proporciona la dirección técnica.
• Adquiere los recursos apropiados.
• Proporciona informes sobre la verificación.
Asistente de verificación • Ejecuta las pruebas
• Registra los resultados de las pruebas.
• Recuperar el software de errores.
• Documenta los pedidos de cambio.
Administrador de base de • Realiza la gestión y mantenimiento del entorno
datos de los datos (base de datos) de prueba y los
recursos.
• Administra la base de datos de prueba.
Sistema
En la siguiente tabla se establecen los recursos de sistema necesarios para realizar la
verificación. Es recomendable que el sistema simule el entorno de producción,
reduciendo los accesos y los tamaños de bases de datos si fuera apropiado.
Recurso Nombre/tipo
Servidor de base de datos
red o subred
nombre del servidor
nombre de la base de datos
Pc cliente para pruebas
requerimientos especiales
Repositorio de pruebas
red o subred
nombre del servidor
Hitos del proyecto de verificación

La verificación del [nombre de proyecto] debe incorporar actividades de prueba para
cada verificación identificada en las secciones anteriores. Se deben identificar los
hitos del proyecto de verificación separados para comunicar los logros de estado de
proyecto.
63
Actividad que determina el Esfuerzo Fecha de Fecha de
hito comienzo finalización
Planificar la verificación
Elaborar casos de prueba
Ajuste y control de
verificación
Ejecutar la verificación
Evaluar la verificación
• Las últimas tres actividades se repiten en cada iteración. Debería incluir en estas
tablas los datos de todas las iteraciones del proyecto.
Entregables
• En esta sección enumere los documentos, herramientas e informes que se crearán,
por quien, para quién y cuándo serán liberados.
• Para cada entregable deberá indicar las fechas en que son liberadas todas las
versiones del mismo.
1.2. Modelo de casos de prueba
Documento Modelo de casos de prueba

Creado por El responsable de verificación, [nombre del responsable
de verificación.
Para quien Es la guía para realizar las pruebas del sistema y lo
usarán los asistentes de verificación y el responsable de
verificación cuando se ejecuten las pruebas del sistema.
Fecha de liberación Será liberado el [fecha de primera liberación].
Informes de verificación
Documento Se genera un documento informe de verificación

unitaria por cada prueba unitaria que se realice al
sistema.
Creado por Las personas que ejecutan las pruebas.
Para quien Es el retorno para los implementadores de la tarea de
verificación, que detalla los errores encontrados para
que puedan ser corregidos.
Fecha de liberación Será liberado luego de cada verificación unitaria.
[Indique la versión y la fecha de liberación de todas las
versiones de este informe.]
Documento Se genera un documento informe consolidación por
cada consolidación que se realice al sistema.
64
consolidación, que detalla los errores encontrados para
Fecha de liberación Será liberado luego de cada consolidación.
Documento Se genera un documento informe de verificación de

integración por cada prueba de integración que se
realice al sistema.
Fecha de liberación Será liberado luego de cada verificación de integración.
Documento Se genera un documento informe de verificación de

sistema por cada prueba de sistema que se realice.
Fecha de liberación Será liberado luego de cada verificación de sistema.
[Indique la fecha de liberación de este informe.]
Evaluación de la verificación
Documento Se genera un documento evaluación de la verificación

por cada prueba que se realice al sistema. Este
documento contiene las fallas encontradas en el sistema,
la cobertura de la verificación realizada y el estado del
sistema.
Creado por El responsable de verificación, que toma como fuente de
su trabajo los informes de verificación.
Para quien Es el resumen de la tarea de verificación y es el retorno
para todo el equipo de trabajo del estado del sistema.
Fecha de liberación Será liberado luego de cada verificación, unitaria, de
integración y de sistema.
Informe final de verificación
65
Documento El documento informe final de verificación es el
resumen de la verificación final del sistema antes de que
sea liberado al entorno del usuario.
Creado por El responsable de verificación, que toma como fuente de
su trabajo los informes de verificación.
Para quien Indica el estado del sistema.
Fecha de liberación Será liberado luego de la verificación final del sistema.
Dependencias [opcional]. En esta sección se detallan las dependencias, si existen,

de las actividades de verificación respecto a otros elementos del sistema.
Dependencia de personal [opcional] En esta sección se detallan las necesidades de

personal para el equipo de verificación, la cantidad y habilidades.
Dependencia de software [opcional]. En esta sección se detallan los requisitos que

debe cumplir el software a ser verificado para que se realice la verificación. Por
ejemplo, que debe tener una verificación previa por parte del implementador, que
debe estar en fecha disponible para verificar.
Dependencia de hardware [opcional]. En esta sección se detallan las necesidades

de disponibilidad de hardware para realizar las tareas de verificación. Por ejemplo,
horario, cantidad de horas que debe estar disponible para que las tareas de
verificación se puedan realizar dentro del cronograma establecido.
Dependencia de datos y base de datos de prueba [opcional]. [En esta sección se

detallan las necesidades de disponibilidad de dato y de la base de datos para realizar
las tareas de verificación. Por ejemplo, conjuntos de datos necesarios para la
verificación, horarios de acceso a la base de datos que permitan que las tareas de
verificación se puedan realizar dentro del cronograma establecido.
Riesgos [opcional] En esta sección se detallan los riesgos detectados que puedan
afectar la normal realización de las tareas de verificación.
66
Planificación [opcional]. En esta sección se plantean los riesgos relativos a la
planificación. Por ejemplo, si una cronograma es muy ajustado un pequeño retraso en
la liberación del software para verificar atrasa la verificación y por consiguiente las
actividades que dependen de esta, provocando un retraso en el cronograma de todo el
proyecto.
Técnico [opcional]. En esta sección se plantean los riesgos técnicos que afectan a la
verificación. Por ejemplo, si existe un sistema anterior se deberá hacer una
verificación en paralelo con el anterior en lugar de liberar la versión en un punto de
trabajo a modo de prueba del sistema.
Gestión [opcional]. En esta sección se plantea como mediante la gestión se pueden

mitigar los riesgos en las tareas de verificación.
Niveles de gravedad de error

En muchas actividades del proceso de verificación se deben clasificar los errores
según su nivel de gravedad. Se asigna un nivel de gravedad a los errores para poder
capturar de alguna manera su impacto en el sistema. Además para poder evaluar la
verificación y el sistema. A continuación se da una sugerencia de cuatro niveles
diferentes de gravedad de error:
• Catastrófico: un error cuya presencia impide el uso del sistema.
• Crítico: un error cuya presencia causa la pérdida de una funcionalidad crítica del
sistema. Si no se corrige el sistema no satisfará las necesidades del cliente.
• Marginal: un error que causa un daño menor, produciendo pérdida de efectividad,
pérdida de disponibilidad o degradación de una funcionalidad que no se realiza
fácilmente de otra manera.
• Menor: un error que no causa perjuicio al sistema, pero que requiere
mantenimiento o reparación. No causa pérdida de funcionalidades que no se
puedan realizar de otra manera.
Niveles de aceptación para los elementos verificados

Se debe establecer un nivel de aceptación para los elementos verificados para poder
establecer el estado en el que se encuentra el proyecto.
67
En esta sección defina niveles de aceptación y los criterios de pertenencia a cada
nivel. Como ejemplo de niveles de aceptación:
• No aprobado: el elemento verificado tiene errores catastróficos (uno o varios) que

impiden su uso o tiene errores críticos (uno o varios) que hacen que el elemento
verificado no sea confiable. El usuario no puede depender de él para realizar el
trabajo.
• Aprobado con observaciones: el elemento verificado no tiene errores
catastróficos, ni errores críticos, pero tiene errores marginales (uno o varios) que
hacen que el elemento de software se degrade en algunas situaciones.
• Aprobado: el elemento verificado no tiene errores o tiene errores menores que no
afectan el normal funcionamiento del elemento.
1.6.5.5. Norma IEEE para planes de gestión de la configuración de software -

IEEE STD 828-1998 7
Este estándar describe una serie de documentos básicos de pruebas de software,

especifica el formato y contenido del documento de pruebas de forma individual
Plan de gestión de configuración software (scmp)
• Introducción • Propósito
• Alcance
• Definiciones y
acrónimos
• Referencias
• Gestión scmp • Identificación de
configuración
• Control de
configuración
• Auditoria de
configuración
• Actividades scmp • Identificación de
configuración
• Control de
configuración
• Auditoria de
configuración
7
68
• Horario scmp
• Recursos scmp
• Plan de mantenimiento scmp
Plan de gestión de configuración software (scmp)
La información del SCMP puede ser presentada en cualquier formato, secuencia o

localización, este documento debe tener un título y definir un formato para el
documento.
Introducción. Esta sección incluye: Propósito, Alcance, Definiciones y acrónimos, y

Referencias
Propósito. Está sección detalla el objetivo específico y ámbito particular del scmp.
Alcance: Esta sección describe la aplicación, limitación y antecedentes de desarrollo

del proyecto software e identifica otro software a ser incluido como parte del plan.
Definiciones y acrónimos: Esta sección establece una terminología común entre

todos los usuarios del plan.
Referencias: Esta sección describe los documentos relacionados, estos se identifican

individualmente.
Gestión scmp. Esta sección incluye 3 temas:
• Organización
• Responsables
• Políticas, directivas y procedimientos
Organización: Esta sección identifica los equipos que participan o son responsables
de cualquier actividad en el scmp y las relaciones de equipos.
Responsables: Esta sección asigna responsables para las actividades del scm.
69
Políticas, directivas y procedimientos: Esta sección describe las restricciones
externas del plan.
Actividades scmp
Esta sección incluye:
• Identificación de configuración
• Control de configuración
• Auditoria de configuración
Identificación de configuración
Esta sección identifica el nombre y describe las características físicas y funcionales

de la documentación en sus respectivas fases del ciclo de vida del software, los
elementos de configuración a ser controlados se identifican en los ítems de
configuración (ci) y la estructura de cada línea base, tiene la versión y descripción de
cada elemento.
Control de configuración
Esta sección identifica y documenta los cambios de las líneas bases de los ítems de
configuración, los cambios incluyen documentación para realizar el cambio, análisis
y valuación de la petición de cambio, aprobación o desaprobación de la petición,
verificación, implementación y realización del cambio.
Auditoria de configuración: Esta sección describe e identifica las revisiones a ser

aplicadas en el proyecto y define el objetivo, horario, procedimiento, participantes,
registro de acciones correctivas y aprobación.
Horario scmp: Esta sección establece la secuencia y coordinación de la información

para identificar las actividades del scmp y para todos los programas afectados en este
plan, este horario incluye la duración del plan y puede ser representado en un gráfico
o comunicar está información.
Recursos scmp: Esta sección identifica las herramientas, técnicas, equipos, personal
y necesidades de capacitación para implementar el scmp.
70
Plan de mantenimiento scmp Esta sección identifica las actividades y responsables
para asegurar el scmp durante el ciclo de vida del software, está documentación debe
ser revisada al inicio de cada fase con los cambios y aprobaciones. 8
1.6.5.6. Estándar iEEE para la documentación de pruebas de software - IEEE

STD 829-1998
Este estándar describe una serie de documentos básicos de pruebas de software,

especifica el formato y contenido del documento de pruebas de forma individual.
Plan de • Propósi • Identificación del plan de pruebas

prueba to • Introducción
s • Ítems de pruebas
• Características a ser probadas
• Características a no ser probadas
• Aproximación
• Criterio de ítem pasa/falla
• Criterios de suspensión y requisitos
de reanudación
• Pruebas a entregar
• Tareas de pruebas
• Necesidades del entorno
• Responsabilidades
• Necesidades del personal y
capacitación
• Horarios
• Riesgos y contingencias
• Aprobación
Registr • Propósito
o de • Identificador de registro de pruebas
prueba • Descripción
s • Actividades y entradas de sucesos
Plan de pruebas
8
71
Propósito. Esta sección describe el alcance, ámbito, recursos, horario de actividades,
responsable para cada tarea y el riesgo asociado con este plan.
Identificación del plan de pruebas. Esta sección asigna el identificador al plan.
Introducción. Esta sección describe las características a ser probadas y la referencia

de los siguientes documentos: autorización de proyecto, plan de proyecto, plan de
aseguramiento de calidad, plan de gestión de configuración y estándares si estos
existen.
Ítems de pruebas. Esta sección específica las características de los requisitos lógicos
o físicos antes de probar, el nivel, versión y revisión del ítems de pruebas. La
siguiente documentación es de referencia en caso de que exista: especificación de
requerimientos, especificación de diseño, guía del usuario, guía de operación y guía
de instalación del software.
Características a ser probadas. Esta sección identifica todas las características y

combinaciones del software a ser probadas.
Características a no ser probadas. Esta sección identifica todas las características y

combinaciones del software que no serán probadas y sus razones.
Aproximación. Esta sección específica las actividades principales, técnicas y

herramientas que se utilizan para probar las características. La aproximación debe ser
descrita para identificar las tareas principales y estimar el tiempo requerido.
Criterio de ítem pasa / falla. Esta sección específica el criterio a ser utilizado para
determinar cada ítem que pasa o falla en la prueba.
Criterios de suspensión y requisitos de reanudación. Esta sección específica el

criterio utilizado para suspender todo o una parte de las actividades de prueba, está
actividad debe repetirse cuando la prueba es resumida.
72
Pruebas a entregar. Esta sección incluye los siguientes documentos: plan de
prueba, especificaciones de diseño de prueba, especificaciones de caso de prueba,
especificaciones de procedimiento de prueba, reportes de transmisión de ítems de
prueba, registro de pruebas, reportes de incidentes de pruebas, reportes de pruebas.
Tareas de pruebas. Esta sección identifica todas las dependencias de tareas internas
y la capacitación requerida.
Necesidades del entorno. Esta sección describe las características físicas y de

comunicaciones, sistema de software, nivel de seguridad y herramientas.
Responsabilidades. Esta sección identifica los grupos responsables de administrar,

diseñar, preparar, ejecutar y revisar las pruebas.
Necesidades del personal y capacitación
Esta sección específica las pruebas al personal por nivel de habilidades e identifica
las opciones de capacitación.
Horarios. Esta sección describe los horarios del proyecto y estima el tiempo
requerido para hacer cada tarea.
Riesgos y contingencias. Esta sección describe las suposiciones de alto riesgo del
plan, especifica los planes de contingencia que requieren horarios que cumplan con
la fecha de entrega.
Aprobación. Esta sección específica los nombres y títulos de todas las personas que
aprobaran el plan. Provee espacio para las firmas y fechas.
Registro de pruebas
Propósito. Esta sección describe la ejecución de las pruebas.
Identificador de registro de pruebas
73
Esta sección asigna el identificador al plan.
Descripción. Esta sección identifica los términos que van hacer probados y los
atributos del entorno, para ejecutar las pruebas.
Actividades y entradas de sucesos. Esta sección registra las fechas de incidencias,

tiempo y responsable.
1.6.5.7. IEEE practica recomendada para pruebas unitarias de software. IEEE
STD 1008 - 1987 (r 2003) 9
Esta norma describe un método sólido para las pruebas de software de la unidad, y
los conceptos y supuestos en que se basa. También proporciona orientación e
información de recursos.
Plan de Fase de perfeccionamiento • Aproximación general del plan, recursos y

pruebas del plan de pruebas horarios
unitarias • Características a ser probadas
• Desarrollo del plan general
Fase de adquisición: • Diseñar el conjunto de pruebas
conjunto de pruebas • Ejecutar el desarrollo del plan y diseño
Fase de medida: pruebas • Ejecutar los procedimientos de pruebas
unitarias • Verificar la terminación
• Evaluar el esfuerzo de las pruebas
unitarias
Plan de pruebas unitarias
9
74
Fase de perfeccionamiento del plan de pruebas
Aproximación general del plan, recursos y horarios. El plan de pruebas unitarias

debe empezarse a realizar cuando se inicie el plan de pruebas de software, ya que
este documento se adjunta al plan general.
Entradas del plan

• Proyecto del plan
• Documentación de los requisitos del software
Tareas del plan

• Especificar una aproximación del plan de pruebas unitarias.
• Especificar las características a ser probadas que serán cubiertas por el plan, cada
tabla debe tener un caso de prueba unitaria.
• Especificar los requerimientos que satisfaga la prueba para que termine esta.
• Determinar los recursos que se requiere para ejecutar las pruebas unitarias
considerando: hardware, comunicaciones, software, herramientas.
• Especificar un horario para las actividades de las pruebas unitarias.
Salidas del plan
Información del plan de pruebas unitarias requisitos generales para las pruebas
unitarias
Características a ser probadas
Determinar entradas
• Documentación de requisitos de unidad
• Documentación de diseño de arquitectura del software
Determinar tareas
• Describir los requisitos para asegurar que estos son únicos.
75
• Identificar los requisitos y procedimientos adicionales que pueden ser
probados en este tipo de prueba.
• Identificar datos de entrada y salida.
• Describir los datos válidos y no válidos para realizar la prueba.
Determinar salidas
• Lista de elementos a ser incluidos en la prueba.
• Clasificar los requisitos.
Desarrollo del plan general
Desarrollar las entradas

• Lista de elementos a incluirse en la prueba.
• Información del plan de pruebas unitarias.
Desarrollo de tareas
• Identificar los casos de prueba existente.
• Identificar los recursos para ejecutar las pruebas unitarias.
• Especificar el horario para las pruebas
Desarrollo de salidas
• Información específica del plan de pruebas unitarias.
• Especificación de los recursos para las pruebas
Fase de adquisición: conjunto de pruebas
Diseñar el conjunto de pruebas
Diseñar las entradas

• Documentación de requerimientos.
• Lista de elementos a ser incluidos en las pruebas.
• Información del plan de pruebas unitarias
• Documentación del diseño
76
• Especificación de pruebas para pruebas previas.
Diseñar las tareas

• Diseñar la arquitectura para las pruebas, basadas en las características a ser
probadas.
• Poner los casos de pruebas, puede estar de acuerdo a la información del
estándar IEEE 829 o especificadas en una sección suplementaria.
Diseñar las salidas
• Especificación del diseño de las pruebas unitarias.

• Especificaciones de pruebas separadas.
• Especificaciones de casos de pruebas separadas.
Ejecutar el desarrollo del plan y diseño
Ejecutar entradas
• Información del plan de pruebas unitarias
• Documentación de especificaciones de los casos y diseño de pruebas unitarias
• Descripción de los datos
• Recursos para las pruebas
• Ítems de pruebas
• Herramientas de pruebas
Ejecutar tareas
• Obtener y verificar los datos de pruebas, incluir datos adicionales necesarios
para asegurar la consistencia y la integridad.
• Obtener los recursos.
• Obtener los ítems de pruebas para asegurar la ejecución y la satisfacción de la
prueba.
Ejecutar salidas
• Verificar los datos de las pruebas
77
• Configuración de los ítems de pruebas
• Información de pruebas
Fase de medida: pruebas unitarias
Ejecutar los procedimientos de pruebas
Ejecutar entradas
• Verificar los datos de prueba.
• Recursos de las pruebas
• Configuración de ítems de prueba
• Especificación de los casos de pruebas
Ejecutar tareas
• Ejecutar las pruebas
• Determinar los resultados
Ejecutar salidas
• Registrar la información de la ejecución de las pruebas en él se incluirá el
ingreso de prueba, descripciones de la prueba, incidentes, resultados de
análisis de fracaso de la prueba, etc.
• Especificación y datos de las pruebas revisadas.
Verificar las entradas

• Terminación de los requisitos.
• Información de la ejecución.
Verificar las tareas

• Información de la ejecución.
• Evaluar las pruebas de unidad
• Si es necesario realizar las pruebas suplementarias o cuando las pruebas no
son satisfactorias, suplementar con las pruebas de serie como son:
• Actualizar las pruebas arquitectónicas y aumentar los casos de pruebas
78
• Modificar las especificaciones de los procedimientos de pruebas
• Obtener los datos de las pruebas
• Ejecutar las pruebas adicionales
Verificar las salidas
• Revisar la información registrada de las pruebas y los casos adicionales de

pruebas
• Verificar los datos de pruebas adicionales si se ha producido
Evaluar el esfuerzo de las pruebas unitarias
Evaluar las entradas

• Especificación del diseño de pruebas unitarias
• Información de ejecución
• Información de revisión
Evaluar las tareas

• Describir el estado de las pruebas, identificar incidentes de pruebas no
resueltas y las razones para la falta de resolución
• Evaluar el diseño e implementación en contra de los requerimientos pasados
sobre los resultados de prueba
Evaluar las salidas

• Completar reporte de resumen de pruebas
Calidad en el sistema web.
Según PIATTINI Mario (2004), con la aparición de la web se observa un cambio

significativo en la manera de especificar y construir software que dificulta mucho
más la estimación de proyectos. El alcance y la complejidad de estas aplicaciones
varían extensamente y pueden abarcar desde servicios de escala reducida hasta
aplicaciones empresariales La evolución de las aplicaciones web, también implica el
79
aumento de la complejidad en diseñar, desarrollar, mantener y manejar estos sistemas
de información.
Para PANTALEO Guillermo (2011), la calidad del software puede ser entendida
como el grado en el cual el usuario percibe que el software satisface sus expectativas.
El tipo y número de actividades de garantía de calidad que es necesario adaptar en
una organización depende mucho del tamaño y complejidad de los productos
software que se estén desarrollando. Actualmente se han publicado una serie de guías
de estilos y criterios que ayudan a mejorar el diseño y autoría de las aplicaciones
web.
PIATTINI Mario (2004) afirma que así como en el software tradicional las
propiedades de los productos web deben ser estructuradas de manera sistemática
para permitir la medición y evaluación de la calidad. La calidad en uso es la visión
del usuario en la calidad que contiene un producto y que se mide en términos de los
resultados del uso del software, más que las propiedades del propio software. La
usabilidad es un factor necesario para el éxito de una aplicación web, pero no es
necesario desarrollar una aplicación usable para que tenga éxito. El triunfo o fracaso
de un proyecto dependerá de la experiencia del usuario.
Una de las métricas más usadas en el ambiente web es l OOmFP que sirve para la
medición del tamaño funcional del sistema web. El método OOmFP ofrece un
entorno de generación automática de código basado en modelos conceptuales.
Existen dos métricas según los autores anteriores que determinan la calidad de un
software en general, estas son:
• Porcentaje de código repetido en el software:

• Complejidad ciclomática
80
CAPITULO II
MARCO METODOLÓGICO Y PLANTEAMIENTO DE LA PROPUESTA
2.1. La Empresa
La empresa “J-M Sotware Developer”, nace de la iniciativa de su gerente-

propietario, como una manera práctica de aplicar los conocimientos adquiridos
durante su vida estudiantil, viendo al desarrollo de software como un medio
diferente de generar ingresos y de hacer empresa. Se inicia con la elaboración de
pequeños programas orientados generalmente al ámbito comercial y usualmente
para utilización en empresas de familiares.
Su filosofía de trabajo se resume en lo siguiente:
Misión: Elaborar software de calidad, utilizando las mejores técnicas y plantillas

para que nuestras clientes se sienta satisfechos.
Visión: Posicionarnos como una de las mejores empresas de la provincia y una de

las más importantes del país dedicada a la elaboración de software con estándares de
calidad a nivel internacional.
2.2. Diseño Metodológico.
La modalidad investigativa que se ha utilizado en esta tesis es la denominada cuali-

cuantitativa. La investigación cualitativa es el procedimiento metodológico que se
caracteriza por utilizar palabras, textos, discursos, dibujos, gráficos e imágenes para
comprender la vida social por medio de significados y desde una perspectiva
holística, pues se trata de entender el conjunto de cualidades interrelacionadas que
caracterizan a un determinado fenómeno y se la aplico para determinar los objetos
cualitativos del problema como el mal servicio, eficiencia y más.
La investigación cuantitativa se caracteriza por recoger, procesar y analizar datos

cuantitativos o numéricos sobre variables previamente determinadas. Esto ya hace
darle una connotación que va más allá de un mero listado de datos organizados como
81
resultado; pues estos datos que se muestran en el informe final, están en total
consonancia con las variables que se declararon desde el principio y los resultados
obtenidos van a brindar una realidad específica a la que estos están sujetos. Dicha
metodología se la aplico para determinar estadísticamente los síntomas de la
problemática.
Los tipos de investigación aplicados son:
• Bibliográfica: Este tipo de investigación se la desarrolla en base a la recopilación

de la información de fuentes primarias, se la utilizó para desarrollar el marco
teórico orientado esencialmente a ingeniería del software y normas ISO
• De Campo: se la lleva a cabo en base a encuestas o entrevistas y se la aplico para
desarrollar el marco metodológico. Se entrevistó a los desarrolladores de la
empresa así como a clientes de la misma
La población involucrada en la problemática descrita en el inicio de este trabajo

investigativo está estructurada de la siguiente forma:
Función Número
Gerente de la empresa 1
Desarrolladores 5
Clientes 25
TOTAL 31
Tabla 1 Población involucrada en la problemática.
Se define como la muestra, a un porcentaje de la población, pero en este caso como

la población es muy pequeña la misma se convierte en la muestra.
Las técnicas de investigación aplicadas fueron: Entrevista al gerente y encuestas a

desarrolladores y clientes
82
Los instrumentos utilizados fueron: Cuestionarios específicos para clientes y
desarrolladores, así como también guía de entrevista para el gerente.
Luego de realizada la investigación de campo se procedió a tabular los resultados de
las encuestas, los cuales se detallan a continuación.
Resultados de la encuesta realizada a los clientes de la empresa
Pregunta # 1. ¿Considera usted muy importante la combinación de colores que se

tenga en un programa cualquiera?
Si………….. No…………
Respuesta Frecuencia Porcentaje

No 11 19%
Si 47 81%
Total 58 100%
Tabla 2 Resultados obtenidos pregunta 1.
No
19%
Si
81%
Gráfico 1 Ilustración gráfica pregunta 1.
Para la gran mayoría es muy importante la combinación de colores en el software

que utilizan o que pueden apreciar
83
Pregunta # 2. ¿Considera primordial la rapidez con la que se cargue un
software en su máquina?
Si………….. No…………

No 13 22%
Si 45 78%
Total 58 100%
No
22%
Si
78%
Para la gran mayoría de los investigados la rapidez con la que se cargue un software
es muy importante
84
Pregunta # 3. ¿Cree usted que el uso de un software acelera los procesos operativos
de una empresa?
Si………. No………..

Si 53 91%
No 5 9%
Total 58 100%
No
9%
Si
91%
Casi la totalidad de los clientes investigados señalan que el uso de un software

permite la aceleración de los procesos operativos de una empresa
85
Pregunta # 4. ¿Considera usted que los programas que usted usa en su empresa son
totalmente seguros?
Si………. No……

Si 41 71%
No 17 29%
Total 58 100%
No
29%
Si
71%
La gran mayoría considera que los programas que utilizan en sus empresas tienen las
seguridades necesarias
86
Pregunta # 5. ¿Considera usted que las empresas o personas que desarrollan
software en el Ecuador deben elevar la calidad del mismo?
Si…………… No…………

Si 55 95%
No 3 5%
Total 58 100%
No
5%
Si
95%
Para casi la totalidad de los investigados los desarrolladores de software deben elevar
la calidad de los programas que hacen.
87
Pregunta # 6. ¿Cree usted que el desarrollo de software es una actividad muy
lucrativa en el Ecuador?
Si………. No………….

Si 41 71%
No 17 29%
Total 58 100%
No
29%
Si
71%
Un elevado porcentaje de usuarios creen que el desarrollo de software se ha

convertido en una actividad bastante lucrativa
88
Resultados de la encuesta realizada a los desarrolladores
Pregunta # 1. ¿Cree usted que la actividad de desarrollo de software es una actividad

muy lucrativa?
Si………… No…….. Un poco……..

Si 5 50%
No 2 20%
Un poco 3 30%
Total 10 100%
No
Un poco 20%
30%
Si 50%
Para la mitad de los investigados la actividad del desarrollo de software esta entre
poco y nada lucrativa.
89
Pregunta # 2. ¿Cree usted que el software producido en el Ecuador es competitivo a
nivel internacional?
Si………….. No…………

Si 2 20%
No 8 80%
Total 10 100%
Si
20%
No
80%
La gran mayoría de los desarrolladores manifiesta que el software producido a nivel

nacional no es competitivo para el ámbito internacional.
90
Pregunta # 3. ¿Considera usted que le falta calidad al software producido a nivel de
la empresa J-M Software Developer®?
Si………. No………..

Si 9 90%
No 1 10%
Total 10 100%
No
10%
Si
90%
Los desarrolladores manifiestan que le falta calidad al software producido por la

empresa
91
Pregunta # 4. ¿Considera usted que se desconoce de las normas internacionales que
definen la calidad de un software?
Si………. No……..…

Si 7 70%
No 3 30%
Total 10 100%
No
30%
Si
70%
La gran mayoría concuerda en que se desconocen las normas internacionales que

definen la calidad de un programa o software
92
Pregunta # 5. ¿Cree usted que debería estructurarse un conjunto de métricas o
parámetros para que nos ayuden a elevar la calidad del software desarrollado en la
empresa?
Si…………… No…………

Si 9 90%
No 1 10%
Total 10 100%
No
10%
Si
90%
Casi la totalidad de los investigados señala que debería estructurarse un conjunto de

métricas para definir la calidad de un software desarrollado en la empresa
93
Pregunta # 6. ¿Considera usted que la seguridad que tenga un software, eleva su
calidad significativamente?
Si………. No………….

Si 6 60%
No 4 40%
Total 10 100%
No
30%
Si
70%
La mayoría ratifica que la seguridad de un software para controlar el acceso y sus

datos eleva la calidad del mismo ante el usuario
94
Entrevista realizada al gerente de la empresa.
Pregunta N° 1. ¿Cree usted que la actividad de desarrollo de software es una

actividad muy lucrativa?
Bueno, la cultura general de la gente está orientada a la copia de los sistemas, razón
por la cual muchas empresas no invierten en ellos, pero las políticas gubernamentales
están incidiendo en que se deben cumplir estrictamente normas como el pago de
impuesto y transacciones electrónicas entonces se está acrecentando la demanda de
software a medida haciendo que este sea más remunerativo.
Pregunta N° 2. ¿Considera usted que el software desarrollado por el empresa es

competitivo a nivel internacional?
A nivel regional creo que nuestro software si es competitivo, pero para el ámbito
internacional no, tenemos muchas deficiencias en cuanto al desconocimiento de
normas internacionales que definen la calidad de un software a nivel internacional.
Pregunta N° 3. ¿A nivel interno de la empresa, se tiene algún conjunto de

métricas que define la calidad del software desarrollado?
Lamentablemente no tenemos estructurado un conjunto de parámetros que nos

permitan evaluar la calidad de cada proceso de desarrollo de software, normalmente
tratamos de que el software tenga seguridad y fiabilidad de los datos.
Pregunta N° 4. ¿Considera usted que sería beneficioso para la empresa disponer

de un conjunto de métricas para mejorar la calidad del software desarrollado?
Sería muy importante cumplir con los parámetros requeridos en un estándar de

calidad internacional para elevar la calidad de cada proceso de elaboración de un
software para que este al final disponga de una mayor calidad y sea competitivo
incluso a nivel internacional
95
2.3 Conclusiones parciales del capitulo
• Para los usuarios los parámetros de calidad de un software están dados

esencialmente por la presentación, por la rapidez de carga y por la seguridad que
brinde el mismo.
• Se considera que existe un desconocimiento general entre los desarrolladores con

respecto al uso de normas o parámetros internacionales para elevar la calidad de
un software desarrollado.
• La empresa J-M Software Developers® no tiene definido controles o métricas

relacionadas a la calidad de un software, por lo que este a lo mejor es competitivo
localmente pero no a nivel nacional y peor aún a nivel internacional.
• La actividad relacionada al desarrollo de software, está siendo impulsada por

nuevas políticas estatales ya que se está cambiando la cultura de la gente con
relación al respeto que se debe tener para los derechos de autor.
• Se cree que para la empresa “J-M Software Developers®” será muy importante
disponer de un conjunto de métricas que definan y sobre todo eleven la calidad
de un software desarrollado en ella
96
CAPITULO III
DESARROLLO DE LA PROPUESTA
3.1 Tema: Métricas de calidad y el desarrollo de software competitivo en la empresa

J-M Software Developer® de la ciudad de Ambato
3.2 Descripción de la propuesta
La propuesta de solución al problema planteado en la introducción del presente

trabajo investigativo, consiste en seleccionar un grupo de métricas adecuadas para la
empresa y desarrollar un portal web aplicándolas, se espera que la aplicación web
resultante disponga de la calidad requerida para competir con productos similares
desarrollados por empresas similares a nivel nacional o internacional
3.3 Desarrollo de la Propuesta
De manera general se define a un producto como el resultado de un proceso, siendo

el proceso la realización de varias actividades tendientes a lograr un objetivo. De la
experiencia y de la teoría de proyectos se conoce que el desarrollo de un proceso
involucra recursos materiales, económicos y humanos. En el caso de la ingeniería del
software, estos conceptos son plenamente aplicados y se puede entender como
producto al software y como proceso a todas las fases de su elaboración.
Se entiende como métrica una medida del grado en que un sistema, componente o
producto posee un atributo dado. El mayor o menor número de atributos que
contenga un producto y que satisfagan los requerimientos de los clientes, determinan
la calidad del mismo. En la mayoría de casos las métricas nos ayudan a entender el
proceso técnico que se desarrolla para elaborar un producto, el proceso para intentar
mejorarlo. El producto se mide para mejorar su calidad.
Para la presente propuesta se ha tomado como base el modelo de calidad de un

producto de software establecido por el estándar ISO 9126, este modelo señala que
97
todos los componentes de calidad del mismo están inmersos en 6 factores
fundamentales con sus categorías respectivas que son:
– Funcionabilidad
o Adecuación
o Exactitud
o Interoperabilidad
o Conformidad
o Seguridad
– Confiabilidad
o Madurez
o Tolerancia a fallos
o Recuperación
– Usabilidad
o Comprensibilidad
o Facilidad de aprender
o Operabilidad
– Eficiencia
o Tiempo de respuesta
o Uso de recursos
– Mantenibilidad
o Capacidad de análisis
o Capacidad de modificación
o Estabilidad
o Facilidad de prueba
– Portabilidad
o Adaptabilidad
o Facilidad de instalación
o Conformidad
o Capacidad de reemplazo
98
3.3.1 Métrica propuesta para evaluar la calidad del software
Es comprensible el hecho de que desarrollar medidas directas de la calidad de un

software es algo bastante complejo y subjetivo, es por ello la razón de ser del
presente trabajo investigativo, como parte medular del mismo se propone la siguiente
fórmula para dicha evaluación.
Fc= c1 * m1 + c2 * m2 + … + cn * mn
Cada factor de calidad Fc se puede obtener como combinación de una o varias

métricas.
Ci. Es el factor de ponderación de la métrica i, que dependerá de cada aplicación

específica, este factor esta dado en porcentaje y representa la importancia del proceso
en el desarrollo o ejecución de la aplicación
Mi. Es la métrica que se puntúa de 0 a 100
Cada parámetro de medición puede tener su propia valoración, eso dependerá del
usuario, para el presente caso se consideran diversos valores por parámetro, la suma
de esos valores debe dar 100 puntos, si el software cumple por lo menos el 60% de lo
requerido se lo puede calificar como un software de calidad que cumple estándares
internacionales.
Igualmente la ponderación queda a criterio de cada caso, aunque en este trabajo se lo
valora específicamente para cada tributo
99
3.3.1.1 Métricas para determinar el factor de calidad
Característica a ser evaluada

Las funciones y propiedades satisfacen las necesidades
FUNCIONABILIDAD
implícitas y explicitas?
Subcaracteristica Descripción Métrica %
Efectúa las tareas especificadas en su
Adecuación 0-100 4
definición
Exactitud Resultados acordes a las necesidades 0-100 3
Interacción con otros programas

Interoperabilidad 0-100 3
especificados previamente
Software se adhiere a leyes y
Conformidad 0-100 4
prescripciones similares
Control adecuado de accesos
Seguridad 0-100 6
indebidos

Puede mantener el nivel de rendimiento bajo ciertas
CONFIABILIDAD
condiciones y determinado tiempo?
Medida de la frecuencia de fallas por
Madurez 0-100 5
errores
Habilidad para mantener un nivel
Tolerancia a fallos especifico de funcionamiento a pesar 0-100 5
de existir una falla
Recuperación del nivel de operación

Recuperación 0-100 5
y de los datos

USABILIDAD El software es fácil de usar y de aprender?
El usuario comprende fácilmente su
Comprensibilidad 0-100 10
funcionamiento
El usuario puede aprender
Facilidad de aprender 0-100 8
rápidamente su manejo
Puede ser operado y controlado

Operabilidad 0-100 12
fácilmente
100
EFICIENCIA Es rápido y mínimo el uso de recursos?
Tiempo de respuesta Celeridad de procesamiento 0-100 6
Uso de recursos Exigencia y uso de recursos 0-100 4
Característica a ser evaluada?

MANTENIBILIDAD Es fácil de modificar y verificar?
Permite identificar las partes a
Capacidad de análisis 0-100 3
modificar
Capacidad de
Se puede modificar fácilmente 0-100 3
modificación
Se pueden evaluar riesgos a efectos
Estabilidad 0-100 2
inesperados por modificaciones
SE puede validar el software luego

Factibilidad de prueba 0-100 2
de ser modificado

PORTABILIDAD Es fácil de transferir de un ambiente a otro?
Adaptabilidad Se puede adaptar fácilmente a 0-100 4

entornos diferentes de trabajo
Facilidad de
Es fácil de instalar 0-100 4
instalación
Conformidad Tiene estándares de portabilidad 0-100 3
Capacidad de Puede ser fácilmente reemplazado

0-100 4
reemplazo por otro producto
101
3.3.2Aplicación de la métrica. Caso práctico.
Como parte complementaria de la propuesta se ha desarrollado una parte de un

software y se lo ha sometido a una evaluación con la métrica propuesta.
Primeramente con fines ilustrativos se muestran varias de las partes de esta
aplicación web publicada en Internet y luego la sometemos a la métrica propuesta
para obtener un criterio sobre la calidad del mismo.
El presente software es un portal web para hacer comercio electrónico, está instalado
en Internet y posee el dominio http://asaderotungurahua.com.
102
103
El software ha sido evaluado con las métricas propuestas y a criterio del realizador,
estos son los resultados.

Las funciones y propiedades satisfacen las necesidades
FUNCIONABILIDAD
implícitas y explicitas?
Efectúa las tareas especificadas en su
Adecuación 50 4
definición
Exactitud Resultados acordes a las necesidades 40 3

Interacción con otros programas
Interoperabilidad 70 3
especificados previamente
Software se adhiere a leyes y
Conformidad 60 4
prescripciones similares
Control adecuado de accesos
Seguridad 60 6
indebidos
El primer factor quedaría aplicando la formula.
F1 = m1*p1 + m2*p2 + m3*p3 + m3* p4
Reemplazando valores tenemos
F1 = 50*0,04 + 40*0,03 + 70*0,03 + 60*0,04 + 60*0,06
F1 = 2 + 1,2 + 2,1 + 2,4 + 3,6

F1 = 11,3.
104
Puede mantener el nivel de rendimiento bajo ciertas
CONFIABILIDAD
condiciones y determinado tiempo?
Medida de la frecuencia de fallas por
Madurez 80 5
errores
Habilidad para mantener un nivel
Tolerancia a fallos especifico de funcionamiento a pesar 70 5
de existir una falla
Recuperación del nivel de operación

Recuperación 80 5
y de los datos
El segundo factor quedaría aplicando la formula.
F2 = m1*p1 + m2*p2 + m3*p3
F2 = 80*0,05 + 70*0,05 + 80*0,05
F2 = 4 + 3,5 + 4,0
F2 = 11,5

USABILIDAD El software es fácil de usar y de aprender?
Su característica Descripción Métrica %
El usuario comprende fácilmente su
Comprensibilidad 90 10
funcionamiento
El usuario puede aprender
Facilidad de aprender 92 8
rápidamente su manejo
Puede ser operado y controlado

Operabilidad 95 12
fácilmente
El tercer factor quedaría aplicando la formula.

F3 = m1*p1 + m2*p2 + m3*p3
105
F3 = 90*0,1 + 92*0,08 + 95*0,12
F3 = 9 +7,36 + 11,4
F3 = 27,76

EFICIENCIA Es rápido y mínimo el uso de recursos?
Tiempo de respuesta Celeridad de procesamiento 82 6
Uso de recursos Exigencia y uso de recursos 85 4
El cuarto factor quedaría aplicando la formula.
F4 = m1*p1 + m2*p2
F4 = 82*0,06 + 92*0,04
F4 = 4,92 +3,68
F4 = 8,6
Característica a ser evaluada?

MANTENIBILIDAD Es fácil de modificar y verificar?
Permite identificar las partes a
Capacidad de análisis 30 3
modificar
Capacidad de
Se puede modificar fácilmente 50 3
modificación
Se pueden evaluar riesgos a efectos
Estabilidad 75 2
inesperados por modificaciones
SE puede validar el software luego

Factibilidad de prueba 75 2
de ser modificado
El quinto factor quedaría aplicando la formula.
F5 = m1*p1 + m2*p2 + m3*p3 + m4*p4
106
F4 = 30*0,03 + 50*0,03+75*0,02 + 75*0,02
F4 = 4,92 +3,68
F4 = 8,6

PORTABILIDAD Es fácil de transferir de un ambiente a otro?
Adaptabilidad Se puede adaptar fácilmente a 90 4

entornos diferentes de trabajo
Facilidad de
Es fácil de instalar 80 4
instalación
Conformidad Tiene estándares de portabilidad 80 3
Capacidad de Puede ser fácilmente reemplazado

70 4
reemplazo por otro producto
El sexto factor quedaría aplicando la formula.
F6 = m1*p1 + m2*p2 + m3*p3 + m4*p4
F6 = 90*0,04 + 80*0,04 + 80*0,03 + 70*0,04
F6 = 4,92 +3,68
F6 = 12
Para obtener el factor total se suma cada parámetro
FC = F1+F2+F3+F4+F5+F6
FC= 11, 3 + 11, 5 + 27, 76 + 8, 6 + 8, 6 + 12
F9 = 79.76
Como el factor de calidad es superior a 70 se asume que el mismo tiene los

parámetros y normas de calidad para ser aceptado en el ámbito nacional e
107
internacional, es decir en definitiva la aplicación tiene estándares de calidad bastante
aceptable.
3.4 Conclusiones parciales del capitulo
El desarrollo de la propuesta en el presente trabajo investigativo ha generado las

siguientes conclusiones:
– La construcción de un conjunto de métricas que determinen la calidad de un

software implican una serie de conocimientos relacionados con el campo de la
calidad en general. El modelo propuesto se base en un estándar ISO que define la
mayor o menor calidad de un producto, en este caso el producto es un software.
– Se ha trabajado sobre el criterio de evaluar el producto, mas no se ha tratado de

evaluar los procesos de desarrollo, porque eso implicaría definir un rango mayor
de métricas que obviamente saldrían del enfoque original del presente trabajo.
– Existen diversos modelos relacionados con la construcción de métricas

relacionadas a la calidad del desarrollo y a la calidad del software en genera, se
ha considerado que la evaluación del producto era el objetivo fundamental y por
ende se trabajó en base a ello.
– Las métricas son muy variables en dos aspectos: el valor asignado a un atributo y
el peso de influencia en la calidad del mismo, esto significa que cada de ellas es
fácilmente adaptable al criterio que quiera darle cualquier evaluar de software.
108
CONCLUSIONES Y RECOMENDACIONES
De manera general se pueden emitir las siguientes conclusiones:
– La calidad es un factor muy importante hoy en día, pero también su evaluación es

un proceso bastante subjetivo, eso quiere decir que para unos, ciertos factores
serán más importantes que para otros, lo que hace muy dificultoso la designación
de los niveles de calidad de un software para que este sea competitivo en el
mercado.
– Aunque en el presente trabajo investigativo solo se trabajó en el aspecto de las

métricas relacionadas con la evaluación de la calidad de un software ya
desarrollado, sería interesante que se complemente el presente trabajo con un
conjunto de métricas orientadas a ser aplicadas durante el desarrollo de un
software.
– Existen diferentes modelos y parámetros que determinan la calidad de un

producto software, pero estos van cambiando con el tiempo y con las tendencias
en cuanto al desarrollo de software.
– No existen modelos específicos para la evaluación de productos del tipo

aplicación web, tal vez con el tiempo los factores de calidad propuestos en ciertos
modelos se orienten exclusivamente a los portales web.
– Es importante también concluir que la calidad es un factor que cada día va más
intrínseco en todo proceso de fabricación, incluyen a aquellos productos que son
netamente el resultado del intelecto humano, como es el caso de un software.
109
En base a las conclusiones emitidas, se pueden definir las siguientes
recomendaciones:
– Difundir mucho más los conceptos relacionados con la calidad, entre los
estudiantes de Ingeniería de Sistemas, esto debido a que es un aspecto muy poco
tratado durante el estudio de la materia de Ingeniería del software y
programación.
– También es recomendable el hecho de que los estándares de calidad definidos en

ciertos modelos, se orienten adecuadamente para que sean aplicados durante el
desarrollo de software, especialmente durante la fase de diseño y programación.
– Es recomendable también que los desarrolladores de software dispongan de

conocimientos relacionados con otros procesos de evaluación de la calidad de un
software como es el método TAW (Test de accesibilidad web).
110
BIBLIOGRAFÍA
• PIATINNI Mario- GARCIA Félix, “Calidad en el desarrollo y mantenimiento del

software “, Editorial Alfaomega Ra-ma, 2007, Madrid-España.
• PRESSMAN Roger S. (2003). “Ingeniería del software. Enfoque práctico”,

Editorial Prentice-Hall, Madrid-España.
• SOMMERVILLE Ian, “Ingeniería del Software”, Addison-Wesley, México-

México, 2002.
• BOLAÑOS Daniel-ALMUDENA Alonso, “Pruebas de software y JUnit. Un

análisis en profundidad”, Prentice-Hall, Madrid-España, 2007
• MUÑOZ Carlos (2002) “Auditoria de sistemas computacionales”, Prentice

Hall, México.
• LAUDON Kennet “Sistemas de Información Gerencial”, Prentice – Hall,

Madrid-España, 2004
• D'SOUSA Carmen (2004), “Auditoria de sistemas”, www.monografias.com
• KENDALL & KENDALL “Sistemas de Información”, Prentice-Hall, Madrid-

España, 2005.
LABORATORIOS DE SOFTWARE.
http://www.inti.gov.ar/software/LaCis_sanluis
www.inti.gov.ar.
www.inti.gob.ar
0
ANEXOS
Cuestionario para los clientes de la empresa
Pregunta # 1. ¿Es para usted muy importante la combinación de colores que se tenga
en un programa cualquiera?
Si………….. No…………
Pregunta # 2. ¿Considera primordial la rapidez con la que se cargue un

software en su máquina?
Si………….. No…………
Pregunta # 3. ¿Cree usted que el uso de un software acelera los procesos operativos
de una empresa?
Si………. No………..
Pregunta # 4. ¿Considera usted que los programas que usted usa en su empresa son
totalmente seguros?
Si………. No……
Pregunta # 5. ¿Considera usted que las empresas o personas que desarrollan

software en el Ecuador deben elevar la calidad del mismo?
Si…………… No…………
Pregunta # 6. ¿Cree usted que el desarrollo de software es una actividad muy

lucrativa en el Ecuador?
Si………. No………….
1
Cuestionario para los desarrolladores internos y externos de la empresa
Pregunta # 1. ¿Cree usted que la actividad de desarrollo de software es una actividad

muy lucrativa?
Si………… No…….. Un poco……..
Pregunta # 2. ¿Cree usted que el software producido en el Ecuador es competitivo a

nivel internacional?
Si………….. No…………
Pregunta # 3. ¿Considera usted que la falta calidad al software producido a nivel de

la empresa J-M Software Developers®?
Si………. No………..
Pregunta # 4. ¿Considera usted que se desconoce de las normas internacionales que

definen la calidad de un software?
Si………. No……..…
Pregunta # 5. ¿Cree usted que debería estructurarse un conjunto de métricas o

parámetros para que nos ayuden a elevar la calidad del software desarrollado en la
empresa?
Si…………… No…………
Pregunta # 6. ¿Considera usted que la seguridad que tenga un software, eleva su

calidad significativamente?
Si………. No………….
2
Guía de entrevista para el gerente
Entrevista realizada al gerente de la empresa.
Pregunta N° 1. ¿Cree usted que la actividad de desarrollo de software es una

actividad muy lucrativa?
Pregunta N° 2. ¿Considera usted que el software desarrollado por el empresa es

competitivo a nivel internacional?
Pregunta N° 3. ¿A nivel interno de la empresa, se tiene algún conjunto de métricas

que define la calidad del software desarrollado?
Pregunta N° 4. ¿Considera usted que sería beneficioso para la empresa disponer de

un conjunto de métricas para mejorar la calidad del software desarrollado?

IEEE Práctica Recomendada para Requisitos de Software Especificaciones

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

IEEE Práctica Recomendada para Requisitos de Software Especificaciones

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES

TESIS DE GRADO PREVIO A LA OBTENCIÓN DEL TITULO DE

MÉTRICAS DE CALIDAD Y EL DESARROLLO DE SOFTWARE

MGS. EDUARDO FERNÁNDEZ

A Dios, por permitirme llegar a este momento tan importante en mi formación

Quiero agradecer a todos quienes me ayudaron en mi formación profesional, a Dios por

Tabla 1 Población involucrada en la problemática. .................................................. 82

Tabla 2 Resultados obtenidos pregunta 1. .................................................................. 83

Tabla 3 Resultados obtenidos pregunta 2. .................................................................. 84

Tabla 4 Resultados obtenidos pregunta 3. .................................................................. 85

Tabla 5 Resultados obtenidos pregunta 4. .................................................................. 86

Tabla 6 Resultados obtenidos pregunta 5. .................................................................. 87

Tabla 7 Resultados obtenidos pregunta 6. .................................................................. 88

Tabla 8 Resultados obtenidos pregunta 1. .................................................................. 89

Tabla 9 Resultados obtenidos pregunta 2. .................................................................. 90

Tabla 10 Resultados obtenidos pregunta 3. ................................................................ 91

Tabla 11 Resultados obtenidos pregunta 4. ................................................................ 92

Tabla 12 Resultados obtenidos pregunta 5. ................................................................ 93

Tabla 13 Resultados obtenidos pregunta 6. ................................................................ 94

Gráfico 1 Ilustración gráfica pregunta 1. ................................................................... 83

Gráfico 2 Ilustración gráfica pregunta 2. ................................................................... 84

Gráfico 3 Ilustración gráfica pregunta 3. ................................................................... 85

Gráfico 4 Ilustración gráfica pregunta 4. ................................................................... 86

Gráfico 5 Ilustración gráfica pregunta 5. ................................................................... 87

Gráfico 6 Ilustración gráfica pregunta 6. ................................................................... 88

Gráfico 7 Ilustración gráfica pregunta 1. ................................................................... 89

Gráfico 8 Ilustración gráfica pregunta 2. ................................................................... 90

Gráfico 9 Ilustración gráfica pregunta 3. ................................................................... 91

Gráfico 11 Ilustración gráfica pregunta 5. ................................................................. 93

Gráfico 12 Ilustración gráfica pregunta 6. ................................................................. 94

La propuesta planteada consistió en la implementación de un conjunto de métricas, las

Se desarrolló un portal web demostrativo, en el cual se aplicaron dichas normativas

Luego viene el marco metodológico, donde se desarrolla la investigación de campo,

Finalmente tenemos la propuesta de solución que si consiste en la elaboración de un

Luego de una investigación previa realizada en la biblioteca de la Universidad, se

Con toda esta información recopilada se concluye que un software se constituye en

Planteamiento del problema.-

El Aseguramiento de la Calidad del Software es un área que suele ser desatendida

Durante los primeros años de la era de la computadora, el software se contemplaba

La segunda era en la evolución de los sistemas de computadora se extienden desde la

La segunda era se caracterizó también por el establecimiento del software ya se

Conforme crecía el número de sistemas informáticos, comenzaron a extenderse las

La conclusión de la tercera era se caracterizó por la llegada y amplio uso de los

La cuarta era de la evolución de sistemas informáticos se aleja de las computadoras

La industria del software ya es la cuna de la economía del mundo. Las decisiones

El software de redes neuronales artificiales junto con la aplicación de lógica difusa

• Al software le falta generalmente calidad en sus interfaces y en las

Formulación del problema

Objeto de investigación y campo de acción

Objeto de Estudio: Ingeniería en Sistemas

Campo de Acción: El campo de acción está definido directamente en la Ingeniería

del Software y específicamente en la evaluación de su calidad.

Delimitación: El trabajo investigativo se llevará a cabo en la empresa J-M Software

Developer® de la Ciudad de Ambato, en la Calle Eloy Alfaro y García Moreno que

viene elaborando desde el año 2011.

Identificación de línea de investigación

El trabajo se enmarca en la línea denominada: “Desarrollo de software y

Elaborar un conjunto de estrategias que se constituyan en una métrica fácil y

eficiente para evaluar la calidad de un software desarrollado por la empresa “J-M

• Analizar fuentes bibliográficas referentes Ingeniería del software, metodologías

de desarrollo, pruebas, Normas ISO referente a la calidad y procesos de

mejoramiento continuo aplicados al desarrollo de software.

• Diagnosticar la aplicación de estándares de calidad utilizados durante el