IEEE Práctica Recomendada para Requisitos de Software Especificaciones
IEEE Práctica Recomendada para Requisitos de Software Especificaciones
“UNIANDES”
AUTORES:
TEC. JORGE AGUAYO
TUTOR:
AMBATO-ECUADOR
2014
DEDICATORIA
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
INDICE DE GRÁFICOS
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.
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
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.
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.
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.
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.
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:
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
el mercado nacional?
5
Objetivo General
Software Developer®”
Objetivos Específicos
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.
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.
Metodología
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,
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
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
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
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.
10
la universidad se aprestaban a “desarrollar el mejor paquete de software” y ganar así
mucho dinero.
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.
12
La estructuración de las diferentes ingenierías como disciplinas profesionales
reconocidas donde se enuncian los tres elementos que constituyen una disciplina
son:
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
14
1.3 Tipos de Software
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.
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.
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))
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.6 El I.E.E.E.
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.
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
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.
Esta sub sección describirá brevemente los contenidos y la organización del resto de
la ERS.
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.
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.
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 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.
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.
• 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
IEEESTANDARDSASSOCIATION, “830-1016 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
24
A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado.
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.
IEEE estándar para la documentación de software del usuario. IEEE std 1063-
2001 3
3
IEEESTANDARDSASSOCIATION, “1063-1998 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
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.
A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado
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.
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.
28
• Color de la fuente y tamaño del papel
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.
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
4
IEEESTANDARDSASSOCIATION, “730-1998 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
31
A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado
1.6.5.1.- El plan de aseguramiento de calidad de software
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.
32
Papeles y responsables. Esta sección identifica los elementos específicos de la
organización que es responsable de las tareas.
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.
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.
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.
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.
1.6.5.3 Norma IEEE para los planes de gestión de proyectos de software - IEEE
std 1058-1998 5
5
IEEESTANDARDSASSOCIATION, “1058-1998 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
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
A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado
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.
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.
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
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.
40
1.6.5.4 IEEE estándar para la verificación y validación de software - IEEE STD
1012-2004 6
6
IEEESTANDARDSASSOCIATION, “1012-1998 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
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
o Consideraciones especiales
42
o Consideraciones especiales
43
Prueba de o Objetivo de la prueba
configuración o Técnica
o Criterio de aceptación
o Consideraciones especiales
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
Repositorio de pruebas
red o subred
46
Hitos del proyecto de Actividad que determina Esfuerzo Fecha de Fecha de
verificación el hito comienzo finalización
Planificar la verificación
Evaluar la verificación
47
A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado
Estrategia de verificación
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.
48
Técnica
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
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:
Criterio de aceptación
• Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han
sido debidamente identificados.
Consideraciones especiales
Objetivo de la prueba
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.
Criterio de aceptación
• Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han
sido debidamente identificados.
Consideraciones especiales
Objetivo de la prueba
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
Criterio de aceptación
• Cada ventana ha sido verificada exitosamente siendo consistente con una versión
de referencia o estándar establecido.
Consideraciones especiales
Prueba de performance
Objetivo de la prueba
52
Peores casos de condiciones de trabajo conocidas.
Técnica
Criterio de aceptación
• 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.
Consideraciones especiales
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.
Objetivo de la prueba
Técnica
Criterio de aceptación
Consideraciones especiales
• 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)
Objetivo de la prueba
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.
Criterio de aceptación
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
Consideraciones especiales
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.
Objetivo de la prueba
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.
56
Consideraciones especiales
• ¿qué período de tiempo se considera aceptable para condiciones de gran
volumen?
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.
Objetivo de la prueba
• 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.
Criterio de aceptación
• 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.
Consideraciones especiales
• 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.
Objetivo de la prueba
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.
Criterio de aceptación
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.
Consideraciones especiales
Prueba de configuración
Objetivo de la prueba
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.
Criterio de aceptación
Consideraciones especiales
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.
Objetivo de la prueba
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.
Criterio de aceptación
• 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
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
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.
Informes de verificación
64
Para quien Es el retorno para los implementadores de la tarea de
consolidación, que detalla los errores encontrados para
que puedan ser corregidos.
Fecha de liberación Será liberado luego de cada consolidación.
[Indique la versión y la fecha de liberación de todas las
versiones de este informe.]
Evaluación de la 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.
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.
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:
7
IEEESTANDARDSASSOCIATION, “828-1998 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
68
• Horario scmp
• Recursos scmp
• Plan de mantenimiento scmp
A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado.
Propósito. Está sección detalla el objetivo específico y ámbito particular del scmp.
• 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
• Identificación de configuración
• Control de configuración
• Auditoria de configuración
Identificación de configuración
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.
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
Registr • Propósito
o de • Identificador de registro de pruebas
prueba • Descripción
s • Actividades y entradas de sucesos
A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado.
Plan de pruebas
8
IEEESTANDARDSASSOCIATION, “829-1998 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
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.
Í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.
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.
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.
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
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.
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.
A continuación se describirá brevemente cada uno de los pasos que hay que aplicar
en este estándar estudiado.
9
IEEESTANDARDSASSOCIATION, “1008-1998 - IEEE Recommended practice for Software
Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html
74
Fase de perfeccionamiento del plan de pruebas
Información del plan de pruebas unitarias requisitos generales para las pruebas
unitarias
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 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
76
• Especificación de pruebas para pruebas previas.
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
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.
78
• Modificar las especificaciones de los procedimientos de pruebas
• Obtener los datos de las pruebas
• Ejecutar las pruebas adicionales
Verificar las salidas
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:
80
CAPITULO II
2.1. La Empresa
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.
Función Número
Gerente de la empresa 1
Desarrolladores 5
Clientes 25
TOTAL 31
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.
Si………….. No…………
Total 58 100%
No
19%
Si
81%
83
Pregunta # 2. ¿Considera primordial la rapidez con la que se cargue un
software en su máquina?
Si………….. No…………
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………..
Total 58 100%
No
9%
Si
91%
85
Pregunta # 4. ¿Considera usted que los programas que usted usa en su empresa son
totalmente seguros?
Si………. No……
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…………
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………….
No
29%
Si
71%
88
Resultados de la encuesta realizada a los desarrolladores
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…………
Total 10 100%
Si
20%
No
80%
90
Pregunta # 3. ¿Considera usted que le falta calidad al software producido a nivel de
la empresa J-M Software Developer®?
Si………. No………..
Total 10 100%
No
10%
Si
90%
91
Pregunta # 4. ¿Considera usted que se desconoce de las normas internacionales que
definen la calidad de un software?
Si………. No……..…
No
30%
Si
70%
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…………
No
10%
Si
90%
93
Pregunta # 6. ¿Considera usted que la seguridad que tenga un software, eleva su
calidad significativamente?
Si………. No………….
No
30%
Si
70%
94
Entrevista realizada al gerente de la empresa.
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.
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.
95
2.3 Conclusiones parciales del capitulo
• 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
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.
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
Fc= c1 * m1 + c2 * m2 + … + cn * mn
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
internacionales.
99
3.3.1.1 Métricas para determinar el factor de calidad
100
Característica a ser evaluada
EFICIENCIA Es rápido y mínimo el uso de recursos?
Subcaracteristica Descripción Métrica %
Tiempo de respuesta Celeridad de procesamiento 0-100 6
101
3.3.2Aplicación de la métrica. Caso práctico.
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.
F2 = 4 + 3,5 + 4,0
F2 = 11,5
105
F3 = 90*0,1 + 92*0,08 + 95*0,12
F3 = 9 +7,36 + 11,4
F3 = 27,76
F4 = m1*p1 + m2*p2
F4 = 82*0,06 + 92*0,04
F4 = 4,92 +3,68
F4 = 8,6
106
Reemplazando valores tenemos
F4 = 4,92 +3,68
F4 = 8,6
F6 = 4,92 +3,68
F6 = 12
FC = F1+F2+F3+F4+F5+F6
FC= 11, 3 + 11, 5 + 27, 76 + 8, 6 + 8, 6 + 12
F9 = 79.76
107
internacional, es decir en definitiva la aplicación tiene estándares de calidad bastante
aceptable.
– 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
– 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.
110
BIBLIOGRAFÍA
LABORATORIOS DE SOFTWARE.
http://www.inti.gov.ar/software/LaCis_sanluis
www.inti.gov.ar.
www.inti.gob.ar
0
ANEXOS
Pregunta # 1. ¿Es para usted muy importante la combinación de colores que se tenga
en un programa cualquiera?
Si………….. No…………
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……
Si…………… No…………
Si………. No………….
1
Cuestionario para los desarrolladores internos y externos de la empresa
Si………….. No…………
Si………. No………..
Si………. No……..…
Si…………… No…………
Si………. No………….
2
Guía de entrevista para el gerente