PLAN DE CALIDAD PARA PRODUCTO DE SOFTWAR

PLAN DE CALIDAD PARA PRODUCTO DE SOFTWARE
“X-PRO-L”
GONZALO TOMÁS PÉREZ LARA
MEMORIA PARA OPTAR AL TITULO DE
INGENIERO DE EJECUCION EN INFORMATICA
Profesor Guía:
MARCELLO VISCONTI
Profesor Correferente:
LUIS HEVIA
VALPARAISO, CHILE
OCTUBRE, 2005
RESUMEN
X-Pro-L corresponde a una aplicación de software interactiva y didáctica, que permite facilitar y
difundir el autoaprendizaje del sistema operativo Linux.
Se pretende conseguir que el usuario participe de forma real y activa con la aplicación, de manera
que se adquieran de forma progresiva, los conocimientos necesarios que le permitan al interesado
utilizar las funciones principales del ambiente Linux.
Como característica a considerar, destacan la claridad en la entrega de la información y de los
contenidos a través de menús interactivos, imágenes y animaciones.
Lo que se persigue, es que la aplicación sea atractiva para el usuario, de manera que la
comprensión de los temas sea óptima.
Para alcanzar tales objetivos, el sistema debe introducir al usuario a la utilización del gestor de
ventanas GNOME de Linux, guiándolo paso a paso en la ejecución de las distintas tareas y
aplicaciones que utilice cotidianamente.
El objetivo de esta memoria es diseñar el Plan de Calidad, cuyo prototipo preliminar fue creado en
la asignatura “Taller de Titulación” durante el segundo semestre del año 2002 por la Empresa
FACDEL.
ABSTRACT
X-Pro-L is a didactic and interactive software application that makes better known and easier the
process of learning how to use the Linux Operating System.
The user is expected to participate in a real and interactive way in the use of this application, in a
way that he progressively gets the necessary knowledge to use the main functions of the Linux
environment.
One of the main features is the clear delivery of information through interactive menus, images and
animation.
We want the application to be attractive and user-friendly so as to optimize the understanding of the
subjects.
In order to reach these objectives, the system must bring the user to the point where he can use the
Linux window generator GNOME, guiding him each step of the way in the execution of the different
tasks and applications that are of every day use.
The goal of this paper is to design the Quality Plan; its preliminary prototype was designed while
doing the “ Workshop on How to Obtain a Degree” at FACDEL, during the second semester of the
year 2002.
INDICE
1. INTRODUCCIÓN ....................................................................................................................................... 5
1.1 Propósito ................................................................................................................................................. 5
1.2 Alcance .................................................................................................................................................... 5
1.3 Identificación de Productos de Trabajo .................................................................................................. 6
1.4 Descripción del Sistema .......................................................................................................................... 7
1.4.1 Descripción de la situación actual ................................................................................................... 7
1.4.2 Descripción del sistema .................................................................................................................... 9
1.5 Glosario de Términos .............................................................................................................................10
1.6 Acrónimos...............................................................................................................................................10
2. REQUERIMIENTOS..................................................................................................................................11
2.1 Aplicación de las Métricas definidas para el Producto X-Pro-L ...........................................................11
3. MODELO DE DESARROLLO .................................................................................................................14
3.1 Actividades del proceso de desarrollo ...................................................................................................15
3.2 Productos de Trabajo .............................................................................................................................18
3.2.1 Definición de los atributos de calidad .............................................................................................21
3.2.2 Atributos de calidad (evaluados por SQA) por actividades del proceso de desarrollo ...................22
3.2.3 Atributos de calidad (evaluados por QA) por productos de trabajo ...............................................24
3.2.4 Puntos de revisión (hitos) ................................................................................................................27
4. GESTION ............................................................................. ОШИБКА! ЗАКЛАДКА НЕ ОПРЕДЕЛЕНА.
4.1 Organización .................................................................................. Ошибка! Закладка не определена.
4.2 Recursos ......................................................................................... Ошибка! Закладка не определена.
4.2.1 Recursos humanos ................................................................... Ошибка! Закладка не определена.
4.2.2 Infraestructura ......................................................................... Ошибка! Закладка не определена.
4.3 Actividades de SQA ........................................................................ Ошибка! Закладка не определена.
4.4 Responsabilidades .......................................................................... Ошибка! Закладка не определена.
4.5 Riesgos ........................................................................................... Ошибка! Закладка не определена.
4.5.1 Identificación de riesgos .......................................................... Ошибка! Закладка не определена.
4.5.2 Clasificación ............................................................................ Ошибка! Закладка не определена.
4.5.3 Estimación de los riesgos ........................................................ Ошибка! Закладка не определена.
4.5.4 Control de riesgos ................................................................... Ошибка! Закладка не определена.
5. HERRAMIENTAS, TÉCNICAS Y METODOLOGÍAS . ОШИБКА! ЗАКЛАДКА НЕ ОПРЕДЕЛЕНА.
5.1 Aplicación de métodos técnicos formales ...................................... Ошибка! Закладка не определена.
5.2 Revisiones e inspecciones............................................................... Ошибка! Закладка не определена.
5.3 Registro y generación de informes ................................................. Ошибка! Закладка не определена.
5.4 Checklist ......................................................................................... Ошибка! Закладка не определена.
5.4.1 Cheklist por actividades del proceso de desarrollo evaluados por QA ......... Ошибка! Закладка не
определена.
5.4.2 Cheklist por productos de trabajo evaluados por QA ............. Ошибка! Закладка не определена.
5.4.3 Cheklist evidenciados por QA ................................................. Ошибка! Закладка не определена.
6. PRUEBAS ............................................................................ ОШИБКА! ЗАКЛАДКА НЕ ОПРЕДЕЛЕНА.
6.1 Planificación .................................................................................. Ошибка! Закладка не определена.
6.2 Especificación ................................................................................ Ошибка! Закладка не определена.
6.3 Ejecución ........................................................................................ Ошибка! Закладка не определена.
6.4 Análisis de resultados .................................................................... Ошибка! Закладка не определена.
6.4.1 Completación ........................................................................... Ошибка! Закладка не определена.
7. INFORME DE PROBLEMAS Y ACCIONES CORRECTIVAS ............... ОШИБКА! ЗАКЛАДКА НЕ
ОПРЕДЕЛЕНА.
7.1 Informe de Auditoría ...................................................................... Ошибка! Закладка не определена.
7.1.1 Identificación de la auditoría .................................................. Ошибка! Закладка не определена.
7.1.2 Objetos de auditoría ................................................................ Ошибка! Закладка не определена.
7.1.3 Bases para la evaluación ......................................................... Ошибка! Закладка не определена.
7.1.4 Actividades de auditoría .......................................................... Ошибка! Закладка не определена.
7.1.5 Anomalías ................................................................................ Ошибка! Закладка не определена.
7.2 Informe de discrepancias ............................................................... Ошибка! Закладка не определена.
7.2.1 Identificación del proyecto ...................................................... Ошибка! Закладка не определена.
7.2.2 Descripción del problema ....................................................... Ошибка! Закладка не определена.
7.2.3 Resolución ............................................................................... Ошибка! Закладка не определена.
7.3 Informe de Actividades de SQA ...................................................... Ошибка! Закладка не определена.
7.3.1 Identificación del proyecto ...................................................... Ошибка! Закладка не определена.
7.3.2 Identificación del producto / proceso evaluado ...................... Ошибка! Закладка не определена.
8. CONCLUSIONES .............................................................. ОШИБКА! ЗАКЛАДКА НЕ ОПРЕДЕЛЕНА.
9. BIBLIOGRAFÍA ................................................................ ОШИБКА! ЗАКЛАДКА НЕ ОПРЕДЕЛЕНА.
10. ANEXOS ........................................................................... ОШИБКА! ЗАКЛАДКА НЕ ОПРЕДЕЛЕНА.
10.1 Plan de Proyecto .......................................................................... Ошибка! Закладка не определена.
10.2 Plan de Riesgos ............................................................................ Ошибка! Закладка не определена.
10.3 Especificación de Requerimientos ................................................ Ошибка! Закладка не определена.
10.4 Especificación del Sistema (Solución Propuesta)......................... Ошибка! Закладка не определена.
10.5 Especificación Funcional ............................................................. Ошибка! Закладка не определена.
10.6 Plan de Pruebas ........................................................................... Ошибка! Закладка не определена.
10.7 Especificación de Diseño de Sistema ........................................... Ошибка! Закладка не определена.
10.8 Especificación de diseño de soporte ............................................. Ошибка! Закладка не определена.
10.9 Plan de Gestión de la Configuración SCM .................................. Ошибка! Закладка не определена.
10.10 Informe de Pruebas (Testing) ..................................................... Ошибка! Закладка не определена.
10.11 Manual de Usuario ..................................................................... Ошибка! Закладка не определена.
Introducción
1. INTRODUCCIÓN
La rapidez con que el mercado mundial avanza hacia la globalización, hace imprescindible el uso
de la tecnología como primer recurso para concretarla. Dentro de ella, lo que ha tenido éxito en el
último tiempo es la aparición de nuevos sistemas operativos, los cuáles tienen como finalidad,
actuar como intermediario entre el usuario y el computador, de manera que el usuario pueda
ejecutar programas y usar el equipo de manera adecuada. Para que todo esto sea posible, el
sistema debe responder de manera eficiente. Dentro de tales características, el sistema operativo
que ha destacado al respecto es Linux.
Llevado al ámbito nacional, se puede apreciar que dicho recurso ha experimentado un desarrollo
cada vez más creciente en los últimos años, con lo cual se hace patente la necesidad de las
empresas y las personas en general, de encontrar una manera apropiada de adquirir los
conocimientos que les permitan desenvolverse dentro de esta tecnología emergente.
Linux está avanzando en todos los campos de la informática y su número de usuarios crece
rápidamente. Las ventajas técnicas de Linux por sobre otros sistemas operativos comerciales son
muy importantes y evidentes (es estable, y gratuito). Debido a esto, en un futuro cercano Linux
podría convertirse en el sistema operativo del mañana.
Usando las herramientas y tecnología que la informática provee, FACDEL, y todo su equipo ha
decidido contribuir proporcionando los elementos adecuados para satisfacer las necesidades de
todos aquellos con mayor desconocimiento en el área de utilización de Linux, mediante una
aplicación de software que facilite su autoaprendizaje, es decir, una herramienta que guíe y ayude
al usuario a utilizar Linux. Para ello, la herramienta que permitirá conseguir estos objetivos es XPro-L.
1.1 Propósito
El propósito del presente plan es definir la organización, actividades y responsabilidades asociadas
al proceso de SQA durante todo el ciclo de vida del proyecto. Además, entregar guías para la
ejecución de las actividades de SQA, definir los estándares, los procedimientos y las convenciones
que serán utilizados durante estas actividades y establecer las herramientas, técnicas y
metodologías que soportarán las prácticas de SQA.
Por lo tanto, el plan de SQA está dirigido al jefe de proyecto, los desarrolladores y al grupo de
SQA, responsable de la elaboración, actualización y monitoreo del plan.
1.2 Alcance
El presente documento establece, de acuerdo a la política organizacional, las actividades de SQA
que deberán ser ejecutadas durante el ciclo de vida del software definido para la aplicación. El ciclo
de vida comprende las etapas de Planificación, Especificación de Requerimientos, Análisis, Diseño,
Implementación, Instalación (aceptación y entrega), y Operación (Mantención).
El objetivo del Plan de Calidad es comunicar el ámbito, recursos, y herramientas a los gestores del
software y personal técnico, además de entregar a la administración una visibilidad adecuada del
proceso utilizado y los productos construidos durante el proyecto mediante acciones planificadas y
sistemáticas que aseguren la calidad de los procesos y productos.
Plan de Calidad Aplicación X-Pro-L
6
Introducción
1.3 Identificación de Productos de Trabajo
A continuación, se nombran los productos de trabajos que soportan la construcción del sistema.
Descripción
Producto de Trabajo
Plan de Proyecto
Documentación para controlar y monitorear el Proyecto (Ver
anexo Plan de Proyecto).
Plan de Riesgos
Documentación sobre las posibles situaciones en las que el
Proyecto puede verse afectado (ver página 36)
Especificación de Requerimientos
Repositorio central que contiene la información actualizada
de cada uno de los requerimientos detectados.
Descripción de los requerimientos del cliente que deben ser
satisfechos por el equipo de desarrollo (ver anexo
Especificación de Requerimientos)
Especificación del sistema (Solución Propuesta)
Documentación sobre la situación actual, sus problemas y
las mejoras que introduce el desarrollo de la solución que se
propone (ver anexo Especificación del Sistema).
Especificación Funcional
Documentación que especifica en términos no técnicos, que
es lo que la solución hace que se propone (ver anexo
Especificación Funcional).
Plan de pruebas
Documentación que describe las pruebas que serán llevadas
a cabo para demostrar al cliente que la solución satisface los
requerimientos definidos. (ver anexo Plan de Pruebas).
Especificación de Diseño de Sistema
Documentación que define la Arquitectura de la Solución e
identifica todos los componentes del sistema. (ver anexo
Especificación de Diseño de Sistema).
Especificación de Diseño de Soporte
Documentación detallada de los requerimientos de soporte
desde la fase de Implementación a la de Operación (ver
anexo Especificación de Diseño de Soporte).
Plan de aseguramiento de calidad SQA
Plan de gestión de la configuración SCM
Informe de pruebas (testing)
Documentación que define todas las actividades de
aseguramiento de calidad que se harán durante el Proyecto.
Documentación que describe la metodología que se seguirá
para realizar la gestión de la configuración en el proceso de
desarrollo de software, formularios y checklist (ver anexo
Plan de gestión de la configuración SCM).
Documentación que describe los resultados de las pruebas,
los cuales ayudarán a comprobar el “buen” funcionamiento
del software.
Manual de usuario
Documentación que describe el comportamiento del sistema
desde el punto de vista funcional de la aplicación.
Manual de instalación del sistema
Documentación de la especificación de los componentes de
instalación y la forma en que se debe realizar esta tarea.
Avances de la Aplicación
Subproductos que evaluará el cliente.
Diseño de imágenes y escenarios
Elementos gráficos que forman parte de la aplicación
Tabla 1: Identificación Productos de Trabajo
Plan de Calidad Aplicación X-Pro-L
7
Introducción
1.4 Descripción del Sistema
1.4.1 Descripción de la situación actual
La tendencia desde hace un par de años es que en los colegios y en las familias existan
computadores, debido a ello los jóvenes se están habituando a usarlos tempranamente.
La mayoría de estos computadores, funcionan principalmente con el sistema operativo Windows,
debido en gran parte al posicionamiento de éste en el mercado y al desconocimiento de la
existencia de Linux y de sus ventajas.
Actualmente, cuando una persona desea aprender a ocupar Linux, utiliza cualquiera de las
siguientes posibilidades:

Pedir asesoría a personas con mayor experiencia.

Aprender por el método de prueba y error.

Utilizar libros y/o tutoriales relativos al tema.

Realizar un curso pagado.
Las personas actúan con recelo hacia lo nuevo y lo desconocido, esto aumenta debido a que los
métodos mencionados anteriormente no son suficientes para entregar el necesario conocimiento y
la confianza para abordar los nuevos retos, en este caso, la utilización de un nuevo sistema
operativo.
Principalmente, el universo afectado por dicho problema son las personas que comienzan a utilizar
Linux, debido a que no disponen de herramientas didácticas que faciliten su comprensión y su
posterior utilización. Es importante el aprendizaje de este sistema operativo, ya que se está
masificando enormemente a nivel mundial debido al auge de nuevas tecnologías.
Linux es conveniente como estación de trabajo, claro, si el usuario final tiene la disposición y
voluntad de aprender, por solo citar algunos ejemplos, todos los nuevos procedimientos necesarios
para manejar sus ficheros y archivos, montar y desmontar unidades de disquete y CDROM,
aprender a utilizar una nueva aplicación de hoja de cálculo, procesador de textos, base de datos,
es decir, el usuario debe aprender a utilizar un sistema que trabaja distinto y se maneja distinto en
muchos sentidos.
El usuario no-técnico, en la mayoría de los casos no dispone de tiempo para leer, ni tampoco tiene
interés por los manuales tradicionales que le explican cómo y que se debe hacer para realizar una
determinada tarea. El usuario final necesita que todo se resuelva con la menor complejidad posible.
Mientras Linux no posea un entorno intuitivo y que las aplicaciones requieran poca experiencia y
conocimientos técnicos por parte del usuario, seguirá siendo obligatoria una capacitación
adecuada, considerando que va a enfrentarse a un nuevo ambiente, con distintos sistemas de
archivos y nuevos procedimientos. Esta capacitación no se puede obtener de un foro de discusión
o una lista de soporte. Estos son sólo herramientas de ayuda, no la solución, ya que difícilmente
los usuarios avanzados dispondrán del tiempo necesario para dedicar varias horas al día en
elaborar nuevos manuales o cátedras de enseñanza contenidos en un mensaje de correo
electrónico. En lo que refiere a las empresas, éstas deben capacitar adecuadamente a su personal
antes de realizar cualquier implementación, porque de otra forma se obtendrán solamente fracasos
y publicidad negativa para Linux y el software libre en general.
Eventualmente los actuales entornos gráficos alcanzarán un nivel de desarrollo que permitirá un
uso tan sencillo de Linux como lo es actualmente con Windows, sin embargo, salvo que el usuario
comprenda como funciona el sistema de archivos de Linux, esto tomará al menos un par de años
más antes de obtener un producto con tal característica.
Plan de Calidad Aplicación X-Pro-L
8
Introducción
La comprensión de las necesidades de los usuarios finales viene de un sólo lugar: de los mismos
usuarios finales. Lo que ellos hacen en una computadora usualmente se limita a unas cuantas
actividades, usualmente con patrones muy definidos, situación que regularmente cubren productos
similares de otras marcas y plataformas. Las herramientas de trabajo que provee Linux son muy
prácticas y efectivas, pero en muchos casos su imagen es muy diferente al estándar que fijó
Microsoft para las aplicaciones bajo Windows, lo que con el tiempo ha hecho que el novato se
sienta fuera de balance en Linux y opte por buscar una alternativa que se asemeje más a lo que ya
conoce[GP-00].
Se mencionará a continuación, algunas de las diferencias principales entre los sistemas operativos
Linux y Windows [GP-00].
Linux v/s Windows
Linux
Windows
Muy Estable.
Inestable
Fiabilidad probada
No totalmente confiable
Muy adaptable a diversas plataformas Intel, Alfa, Sparc,
Macintosh.
Adaptabilidad sólo en plataformas Intel o clónicas.
Gratis (libre distribución).
Costo elevado (producto comercial).
Administración complicada (interacción con el usuario), salvo Administración más fácil. Ratón e Iconos muy popularizados
en entornos gráficos tipo KDE y el GNOME
Muchas variedades y distribuciones, que muchas veces
difieren bastante entre unas y otras.
Un único fabricante y distribuidor.
sistema abierto.
sistema cerrado
Existe poco software disponible, sólo aplicaciones ofimáticas y Multitud de aplicaciones de terceros, sobre todo con fines
de otro tipo GNU.
comerciales, apoyo de la industria. Los fabricantes de
Hardware se preocupan de suministrar el driver adecuado a
Windows.
Fuentes de los programas disponibles. Libertad de
distribución y mejora
No se dispone de ellas.
Lento aprendizaje, difícil instalación
Más rápido e intuitivo, instalación automatizada.
Muchísimo soporte en Internet y guías. Comunicación fácil
con otros usuarios y con los mismos desarrolladores.
Poco soporte real. Sí en libros.
No ha llegado al público en general, aunque aumenta día a
día.
Es el sistema operativo que más ha contribuido a la
popularización de los PC y de la Informática en general.
El 85% de los computadores del planeta.
Es utilizado por usuarios que buscan estabilidad y fiabilidad
Utilizado por público en general.
(nivel medio – avanzado). Se necesita algo de experiencia y
algunos conocimientos básicos para configurarlo
adecuadamente, sobre todo lo relacionado con multimedia y
redes.
Tabla 2: Linux v/s Windows
Plan de Calidad Aplicación X-Pro-L
9
Introducción
Se destaca que ninguno de los sistemas operativos que existen hoy en día está exento de
pequeños detalles. La diferencia de Linux sobre otros sistemas operativos radica principalmente
en:

Que los errores que pudiesen existir en algún componente de Linux no son tan frecuentes
como los de los "otros" sistemas operativos.

Estabilidad, fiabilidad y robustez para la realización de diversas tareas.

Que cuando se descubre un error, éste siempre se hace público, e incluso, en algunos casos,
se puede obtener el parche correspondiente el mismo día.

Que, si lo desea, y en la mayoría de los casos, puede contactar directamente al autor de la
aplicación, controlador, módulo o programa, quien seguramente le dará respuesta a sus dudas
e inquietudes.

Los métodos de seguridad de Linux son mejores que los de los "otros" sistemas operativos, por
lo que es menos probable que sea víctima de un "Hacker" o que se filtre información fuera de
su PC sin su autorización. En Linux, el acceso a los directorios y los archivos, así como la
capacidad de borrar o modificar estos, depende de los permisos de usuario que estos tengan.

Si se presenta un "error" o algo se "cae", no es necesario reinicializar todo el sistema, bastará
con "matar" y reiniciar la aplicación, programa o servicio. El usuario no perderá tiempo y
productividad. En Linux los servicios como Sendmail, Servidores Web, demonios en general,
aplicaciones, se desempeñan de forma independiente.
Hoy en día se estima que existen más de 30 millones de usuarios de Linux en todo el mundo,
comparados con los más de 450 millones de usuarios de todas las versiones de Windows. Sin
embargo, esta desventaja numérica se acorta cada día más puesto que los usuarios de Linux se
duplican en número cada año, debido principalmente a las características planteadas
anteriormente.
Una característica muy significativa de Linux es su robustez, estabilidad, y distribución gratuita.
Pero, ¿por qué no lidera aún el mercado doméstico?, por que es relativamente nuevo (nació a
principios de los ‘90) y sólo en el último tiempo se ha orientado hacia el público en general, ya que
en sus inicios estaba destinado a usuarios especializados.
1.4.2 Descripción del sistema
La solución a implementar consiste en una aplicación que permitirá adquirir los conocimientos
básicos para interactuar con el sistema operativo Linux. La Aplicación será programada en un
modelo de 3 capas, el que es definido a continuación:
 Capa de Presentación: Tiene por finalidad la interacción con el usuario, aceptando los datos
ingresados y desplegando los que son requeridos.
 Capa de Dominio o Negocio: En esta capa la funcionalidad y las validaciones del negocio se
obtienen a partir del análisis del sistema.
 Capa de Datos: Se encarga sólo de asegurar la persistencia de los datos y su recuperación
eficaz. No debe ocuparse de resolver problemas asociados a las reglas del negocio y/o
presentación, pues corresponden a las otras capas.
Plan de Calidad Aplicación X-Pro-L
10
Introducción
La aplicación permitirá la población de la Base de Datos, y navegar a través de los contenidos. El
sistema será instalado en un servidor que contendrá la aplicación y la Base de Datos. Los
computadores conectados al servidor, estarán conectados en modo Cliente (Capa de
Presentación), permitiendo acceso solo a los perfiles definidos para cada usuario.
Para acceder a la aplicación, se deberá tener un login y password definidos para cada usuario.
1.5 Glosario de Términos
Para lograr un mejor entendimiento de los términos técnicos que se utilizan en el presente Plan de
SQA, se mencionan a continuación los significados de los siguientes términos [WEB-01]:

Aseguramiento de la Calidad del Software (SQA)  El propósito de SQA es entregar a la
administración una visibilidad adecuada del proceso utilizado y los productos construidos
mediante acciones planificadas y sistemáticas que aseguren la calidad de dichos procesos y
productos.

Auditoría  Evaluación independiente de los productos de trabajo y de un conjunto de
procesos de software para asegurar la adherencia con las especificaciones, los estándares,
procedimientos y otros acuerdos.

Gestión de la Configuración del Software (SCM) El propósito de SCM es establecer y
mantener la integridad de los productos a través de todo el ciclo de vida del software, para así
proveer un adecuado control de los cambios en los diversos ítems de configuración.

Revisión  Metodología definida, estructurada y disciplinada para la detección e identificación
de defectos en los productos de trabajo durante el ciclo de vida del software.

Prueba (Testing)  Actividad que evalúa los atributos y la capacidad de un programa o
sistema para determinar si se cumple con los resultados definidos.
1.6 Acrónimos
Acrónimo
Significado
SQA
Software Quality Assurance, Aseguramiento de la Calidad del Software
SCM
Software Configuration Management, Gestión de Configuración del Software
WBS
Work Breakdown Structure
Tabla 3: Listado de Acrónimos
Plan de Calidad Aplicación X-Pro-L
11
Requerimientos
2. REQUERIMIENTOS
Un requerimiento es un aspecto del producto requerido o deseado por el cliente. Los
Requerimientos Funcionales cubren las funciones y operaciones a realizar para proporcionar un
sistema que operará de acuerdo a las necesidades del usuario. Al elaborar una lista completa de
las percepciones de los usuarios respecto a sus requerimientos, se definen las funciones que
tendrán que ser realizadas por el sistema a desarrollar. En cambio, un Requerimiento No Funcional
indica cómo se deben hacer todas las actividades de desarrollo para obtener un producto con la
mayor calidad posible ya que ésta puede hacer la diferencia entre el éxito o fracaso de una
aplicación.
Las métricas usadas para medir la calidad de los Requerimientos No Funcionales del Producto XPro-L son los siguientes [MUN-00]:

Interfaz: Se basa en lo referente a la calidad de la Interfaz usuaria

Portabilidad: Capacidad de la aplicación para funcionar correctamente en diferentes
configuraciones, ya sean de software o hardware.

Performance: Requerimientos reales de la performance, velocidad, precisión, disponibilidad,
nivel de servicio, volúmenes de datos, entre otros.

Operacional: Ambiente en que el usuario operará el producto.

Mantenibilidad: Es el tiempo esperado y el permitido para el mantenimiento o la realización
de cambios.

Seguridad: Requerimientos para permitir el acceso, restringir mal uso, hechos anormales,
entre otros.
2.1 Aplicación de las Métricas definidas para el Producto X-Pro-L
 Interfaz
La interfaz para esta aplicación debe ser simple en la entrega de datos, topología de letra
adecuada a la vista, colores adecuados, rápidos y eficientes para la selección e ingreso de datos al
sistema.
Objetivos

Simplicidad en la entrega de datos, sin tener necesidad de instrucciones para su uso.

Tipología de la letra adecuada a la vista y que no produzca rechazo por el usuario.

Forma rápida y eficiente para seleccionar e ingresar datos al sistema.

La interfaz debe mostrar la estructura de los contenidos, de manera rápida de entender para el
usuario, además de figuras didácticas, colores y enlaces, para una mejor comprensión y
profundización de los temas.
Criterios de Aceptación

La interfaz debe mostrar en todo momento la estructura de árbol que presenta para la
organización de los contenidos.

La rapidez de respuesta de la aplicación, ante los datos que se seleccionan e ingresan no
debe superar los 2 seg.
Plan de Calidad Aplicación X-Pro-L
12
Requerimientos
 Portabilidad
Para la utilización de la aplicación, debe considerarse el correcto funcionamiento desde el sistema
operativo Linux y el hardware apropiado para su uso.
Objetivos

Los equipos deben contar con ciertas características mínimas para el correcto funcionamiento
del sistema.

La aplicación debe funcionar bajo el sistema operativo Linux.

La aplicación debe acoplarse a la totalidad de módulos construidos y los que puedan ser
incorporados de forma posterior.
Criterios de Aceptación


La aplicación debe ejecutarse sin ningún problema en los distintos computadores donde sea
instalado. Para ello, las características mínimas son:

Procesador Pentium III, 733 Mhz o similar

Disco Duro de 10 GB

256 MB Ram
La aplicación debe funcionar bajo el sistema operativo Linux Red Hat 7.0 (o distribución
equivalente) y usar el Motor de Base de Datos MySQL.
 Performance
Rapidez de respuesta a las consultas realizadas a la base de datos y manejo de grandes
volúmenes de datos.
Objetivos

La aplicación debe entregar una respuesta rápida a la consulta realizada.

La aplicación debe permitir el manejo rápido de grandes volúmenes de datos.
Criterios de Aceptación

La rapidez de respuesta no debe ser mayor a 5 [seg] desde que se realizó la actualización.

La aplicación debe permitir el manejo de 10000 registros.
 Operacional
Por otra parte, la información desplegada por pantalla debe ser clara y sencilla, sin mayor
sobrecarga de imágenes e información, de manera que no sea dificultoso el entendimiento de los
datos desplegados.
Objetivos

La aplicación debe mostrar un número adecuado de figuras dinámicas y estáticas, evitando la
sobrecarga de ellas.

La aplicación debe mostrar un número de preguntas que no sobrecargue la interfaz.
Criterios de Aceptación

No se deben desplegar más de 3 figuras dinámicas y 5 figuras dinámicas en forma simultánea.

No se deben desplegar más de 10 preguntas por cada módulo a evaluar.
Plan de Calidad Aplicación X-Pro-L
13
Requerimientos
 Mantenibilidad
El mantenimiento debe ser realizado a medida que se reporten fallas o inconsistencias que no sean
descubiertas durante el desarrollo, éstas fallas serán descubiertas por los mismos usuarios de la
aplicación dándolas a conocer a través de e-mail o personalmente al Administrador.
Objetivos

La aplicación debe funcionar correctamente sin la necesidad de modificaciones posteriores al
equipo.

La mantención debe ser realizada en horarios en que no se ocupe la Aplicación.

Se debe considerar el tiempo de mantención y los módulos afectados por los cambios, ya sean
correctivos o perfectivos.
Criterios de Aceptación

El tiempo de mantención estará restringido según las líneas de código del módulo afectado,
debido a que existen componentes que son de gran complejidad, por lo cual tendrán un tiempo
mayor de mantención.

La aplicación debe ser actualizada una vez cada seis meses, debido a los continuos cambios
que puedan sufrir las versiones de la aplicación.

La documentación necesaria debe tener descrito los cambios realizados, además de los pasos
seguidos en el proceso de desarrollo y mantenciones posteriores.

El código fuente de la aplicación debe ser comentado al menos en un 50% del total, y claros en
su estructura.
 Seguridad
La aplicación debe tener la capacidad de detectar consultas, equivocadas o mal intencionadas por
parte del usuario.
Por otra parte, el hecho de que los datos se modificarán constantemente, se debe tener un
respaldo periódico de la aplicación.
Objetivos

Los datos no deben ser modificados por terceros.

Se debe asegurar la recuperación de los datos, en caso de fallar la aplicación.

La aplicación debe poseer un control de acceso al sistema, con el fin de evitar el
procesamiento de datos erróneos.

Se debe establecer un perfil para el administrador, quien tendrá acceso a la información clave
de la aplicación.
Criterios de Aceptación

Las claves del administrador del sistema deben ser de un largo determinado, con el fin de
evitar la entrada de personas ajenas al sistema.

Se debe respaldar la aplicación una vez a la semana.

Toda persona que desee ingresar a la aplicación debe tener asignado un login y password.

Los usuarios de la aplicación deben obligatoriamente actualizar su login y password una vez al
mes.
Plan de Calidad Aplicación X-Pro-L
14
Modelo de Desarrollo
3. MODELO DE DESARROLLO
Se optó por la estrategia de desarrollo “Modelo Incremental”, el cual aplica secuencias lineales de
forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un
“incremento” del software. La elección de la estrategia seleccionada se debe a que la intención es
entregar el software en partes pequeñas, pero utilizables, llamadas “incrementos”, es decir, cada
“incremento” se construye sobre aquél que ya ha sido entregado [PRE-01].
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial,
es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias (algunas
conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión
detallada). Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el
incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las
necesidades del cliente y la entrega de funciones, y características adicionales. Este proceso se
repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. Los
primeros incrementos son versiones “incompletas” del producto final, pero proporcionan al usuario
la funcionalidad que precisa y también una plataforma para la evaluación. El desarrollo incremental
es particularmente útil cuando la dotación de personal no está disponible para una implementación
completa en la fecha límite que se haya establecido para el proyecto. Los primeros incrementos se
pueden implementar con menos personas [PRE-01].
Otro punto a considerar, es que pese a que el cliente está abierto a recibir nuevas soluciones a sus
problemas, no tiene claro cuáles son sus requisitos ideales. Debido a esto, la construcción
temprana del sistema nos puede llevar a desarrollar una solución inútil. Como solución a esto, se
entregará una versión del programa X-Pro-L con la implementación de algunas funciones, dejando
el proyecto abierto a que en una futura etapa de desarrollo, entregue una nueva versión del
proyecto que agregue nuevas funcionalidades (un incremento).
Ingeniería Sistemas
de Información
Análisis
Incremento 1
Diseño
Código
Entrega de 1°
Incremento
Prueba
Incremento 2
Análisis
Diseño
Código
Entrega de 2°
Incremento
Prueba
Incremento 3
Análisis
Diseño
Código
Prueba
Entrega de 3°
Incremento
Incremento 4
Análisis
Diseño
Código
Prueba
Entrega de 4°
Incremento
Figura 1: Modelo Incremental
Plan de Calidad Aplicación X-Pro-L
15
Modelo de Desarrollo
3.1 Actividades del proceso de desarrollo

Planificación
Planificación / definición de recursos, tiempo y otras informaciones relacionadas con el proyecto
según la evaluación del cliente poniendo énfasis en lo que se debe modificar y lo que se debe
mantener.
Durante la etapa de planificación, SQA debe participar de la elaboración del Plan de Proyecto. Es
su responsabilidad producir el Plan de SQA y verificar que los procesos, procedimientos y
estándares identificados en el Plan de Proyecto sean apropiados, claros, específicos y auditables.
El contenido del Plan de SQA debe identificar: evaluaciones, auditorías y revisiones, estándares,
procedimientos de seguimiento y reporte de errores, y documentación por producir.

Especificación de requerimientos (Definición)
Esta fase comienza cuando se han identificado los problemas o necesidades de negocios, cuya
solución requiere un análisis y especificación. En esta etapa el equipo de proyecto debe entender
al cliente en términos de sus problemas y dirección, sus capacidades técnicas y de organización y
su potencial futuro. Para esto hay que analizar:

Las metas de la organización, sus objetivos y factores críticos de éxito.

Los procesos de negocios y flujos de información actuales.

Requerimientos de solución, en términos de procesos y principios de negocios, estructura
organizacional y arquitectura tecnológica.

Beneficios de la solución e impacto en la organización, recursos humanos y ambiente
tecnológico.
En esta etapa no se debe pensar en posibles soluciones, sino solamente en el problema, es decir,
se de describir el problema en forma de requerimientos.
SQA debe corroborar que en la Especificación estén expresados todos los requerimientos, de
manera tal que puedan ser verificados en el producto final.

Análisis
Durante esta fase se analiza la Especificación de Requerimientos con el objetivo de identificar las
soluciones que satisfagan los requerimientos, se analizan diferentes alternativas de solución y se
selecciona solo una, y se genera el informe de Solución Propuesta [MA-02].
En la fase de Análisis, dentro de las actividades de SQA se incluye asegurar:

La adherencia del Análisis y su documentación a los estándares definidos en el Plan de
Proyecto.

La incorporación de los resultados de las inspecciones en el Análisis.

Diseño
Esta etapa se centra en el "cómo", en la forma cómo debe construirse el sistema de software de
acuerdo a la información obtenida de la etapa de análisis. En esta etapa se define como deberá
implementarse el sistema de software. Los modelos creados en la fase de análisis determinan
claramente cuál debe ser el comportamiento general del sistema en un entorno ideal. Los modelos
a crear en la fase de diseño determinan, ya sobre el entorno propio de la organización, cómo
Plan de Calidad Aplicación X-Pro-L
16
Modelo de Desarrollo
deberá implementarse el sistema. Por otra parte, en esta fase el Equipo de Proyecto define la
funcionalidad y solución física que va a satisfacer los requerimientos definidos [MA-02].
En la fase de diseño, dentro de las actividades de SQA se incluye asegurar:

La adherencia del diseño y su documentación a los estándares definidos en el Plan del
Proyecto.

La presencia de todo módulo en el diseño.

La incorporación de los resultados de las inspecciones en el diseño.

El ingreso del diseño a la configuración del software, tras su aprobación.

Implementación
La implementación se establece como la "construcción" del sistema. La actividad sólo lleva a la
práctica el sistema que se modeló en la fase de diseño. La fase incluye las actividades de
codificación e integración de los diferentes módulos constitutivos del sistema. En la fase de
implementación, cada componente de la solución, identificado en la Especificación de Diseño de
Sistema, se diseña en detalle (si corresponde), se construye, se ensambla, se prueba y se integra
con otros componentes relacionados. Los componentes se prueban como un todo. MA-02]:
Los posibles componentes son:
 Productos estándares disponibles y componentes construidos para el cliente.
 Componentes construidos solo para el cliente.
 Componentes derivados de prototipos, usados preliminarmente para verificar todo o parte del
diseño y, en algunos casos, para llegar a ser parte de la solución.
Los componentes individuales son distribuidos por varias disciplinas y terceras partes. Es esencial
que el Equipo aplique los principios de control de cambios, administración de la configuración y
reportes. Esta fase involucra a muchas personas trabajando simultáneamente, pero con
independencia en tareas complejas. Por lo tanto, es muy importante que los planes para apoyar
esta fase sean conocidos y los roles y responsabilidades estén claramente definidas.
El software generado en la fase de implementación no puede ser “entregado” a los clientes, para
que funcione, sin practicarle antes una serie de pruebas. Las pruebas son tendientes a encontrar
defectos en el sistema final debidos a omisión o mal interpretación de alguna parte del análisis o el
diseño.
Los defectos deberán entonces detectarse y corregirse en esta fase del proyecto. En ocasiones los
defectos pueden deberse a errores en la implementación de código (errores propios del lenguaje o
sistema de implementación), aunque en esta etapa es posible realizar una efectiva detección de los
mismos, ellos deben ser detectados y corregidos en la fase de implementación.
A SQA le corresponde auditar:

Los resultados de las actividades de diseño y codificación.

El estado de todos los entregables.

Las actividades de gestión de configuración y de la biblioteca del software.

Los informes sobre desviaciones y las acciones correctivas.

Garantizar la concordancia de las pruebas con el Plan y los procedimientos definidos, así como
también toda desviación sea informada y corregida.

Certificar que las actividades de prueba se han completado satisfactoriamente y que el
software y su documentación se encuentran listos para la entrega del producto final.
Plan de Calidad Aplicación X-Pro-L
17
Modelo de Desarrollo

Instalación (Aceptación y Entrega)
Aceptación (negativa o positiva) de las representaciones de la aplicación por parte del cliente.
Durante la fase de instalación, todas las componentes de la solución se distribuyen al cliente y se
instalan. La solución se prueba como un todo en un ambiente operacional hasta que esté lista para
la prueba de aceptación formal por parte del cliente [MA-02].
La Prueba de Aceptación quiere demostrar al cliente que la solución cumple los requerimientos de
la Especificación Funcional. El cliente confirma por escrito que todas las pruebas han sido exitosas
y que acepta la solución [MA-02].
La salida de esta fase es transferir la propiedad de la solución a la organización cliente.
En la fase de aceptación, SQA es responsable de realizar la última auditoria de configuración del
software, con el objetivo de determinar que los deliberables están listos para la entrega.

Operación (Mantención)
Esta es la fase post-aceptación del proyecto, durante la cual se mantiene y soporta la solución
según lo acordado entre las partes.
En esta fase el software es puesto en funcionamiento con los usuarios y el entorno de la
organización. Es común que estas etapas requieran de trabajo adicional del equipo de
desarrolladores, especialmente en procesos de configuración adecuada, utilidades menores de
copias de respaldo, administración de seguridad o reportes adicionales. Esta es la fase postaceptación del proyecto, durante la cual se mantiene y soporta la solución según lo acordado entre
las partes [MA-02].
Se hace una revisión para registrar datos estadísticos y discutir sobre áreas de experiencia que
puedan ser útiles para otros proyectos en el futuro.
El contenido del proyecto se archiva y se considera el proyecto terminado.
Después del período de garantía, se puede continuar con la mantención de la solución.
En la fase de Operación, SQA es responsable de asegurar que los requerimientos de calidad se
han cumplido y que las actividades de aseguramiento de calidad se han realizado.
Durante la operación pueden presentarse correcciones o mejoras que originen pequeños “ciclos de
desarrollo”. En tal caso, se repetirán las actividades de SQA descritas con anterioridad [SOM-00].
Plan de Calidad Aplicación X-Pro-L
18
Modelo de Desarrollo
3.2 Productos de Trabajo
A continuación, se definen los productos de trabajo que deberían entregarse dentro del desarrollo
del proyecto:

Plan de Proyecto
Para contar con una forma de monitorear y controlar lo que se está llevando a cabo dentro del
desarrollo del proyecto. El Plan de Proyecto proporciona un repositorio central que contiene la
información de planificación e implementación requerida para ejecutar el plan de proyecto entero.
Provee un resumen y una integración de todos los planes contenidos en el proyecto y de todos los
proyectos contenidos en el programa. Posibilita el monitoreo del progreso del proyecto de manera
consistente con el plan.
El Plan de Proyecto inicial refleja la información que está disponible en la fase de análisis. Al tener
información más detallada, según avanza el proyecto, el plan de proyecto es actualizado de
acuerdo con esto. La cobertura del Plan de Proyecto es el proyecto completo, pero en cualquier
punto del tiempo, normalmente contendrá actividades detalladas solamente para la fase actual y la
fase siguiente [MA-02] (ver anexo Plan de Proyecto).
 Plan de Riesgos
El Plan de Riesgos establece las posibles situaciones en las que el proyecto podría verse afectado.
Para ello, se realiza un Análisis de Riesgos, a través de la cual se establecerán las acciones a
tomar en caso que se concreten dichas situaciones. Básicamente, el Plan de Riesgos debe
contemplar la: definición de los riesgos, la posibilidad de que se concrete cada uno de los riesgos
detectados, definir que tan grande sería el impacto de cada riesgo identificado en el proyecto,
definir e indicar cuales son los eventos indicadores de que el riesgo se ha concretado, y definir el
plan de contingencia para cada uno de ellos (Ver página 36).
 Especificación de Requerimientos
La Especificación de Requerimientos proporciona un repositorio central que contiene la información
actualizada de cada uno de los requerimientos detectados, como el número secuencial que
identifica en forma única al requerimiento, tipo de requerimiento, identificación de requerimiento
original (cuando es reclasificado), estado del requerimiento, persona que lo planteó, categoría del
requerimiento, nombre del requerimiento, fecha en que se da por aprobado el requerimiento por
parte del cliente, nombre de la persona que da por aprobado el requerimiento. Todo esto, permitirá
una administración correcta de los requerimientos del proyecto [MA-02].
Por otra parte, la Especificación de Requerimientos refleja las necesidades de negocio, los
requerimientos necesarios para resolver aquellas necesidades, y objetivos del cliente que buscan
una solución. Este es el primer documento que se genera en un proyecto y debe ser conciso, claro
y completo; de modo tal que sea la base para las siguientes etapas. Por otro lado, debe ser escrito
en un lenguaje de alto nivel, en términos del negocio. Debiera ser capaz de ser producido en un
tiempo limitado, y no debería contener detalles específicos a menos que sean considerados
requisitos para el negocio. La Especificación de Requerimientos forma la base para el desarrollo de
la Solución Propuesta, pero al mismo tiempo difieren, pues ésta refleja las necesidades y objetivos
de negocio traducidos en requerimientos para una solución. La Solución Propuesta detalla
especificaciones para una solución específica seleccionada a partir de un número de alternativas
posibles [MA-02] (ver anexo Especificación de Requerimientos).
Plan de Calidad Aplicación X-Pro-L
19
Modelo de Desarrollo

Especificación del Sistema (Solución Propuesta)
Mostrando como es la situación actual, sus problemas y las mejoras que introduce el desarrollo de
la solución que se propone. La Solución Propuesta especifica en términos no técnicos cómo la
solución satisface al cliente y es la base para la Especificación Funcional, que es producida en la
fase de diseño. Incluye también el soporte operacional propuesto que es la base para formular el la
Especificación de Diseño de Soporte [MA-02] (ver anexo Especificación del Sistema).

Especificación Funcional
La Especificación Funcional especifica en términos no técnicos, qué es lo que la solución hace
para el usuario. Este es un documento muy importante, por que provee una única definición formal
del total de los requerimientos que satisface la solución, y por que es la base para planificar el
diseño y para desarrollar e implementar el Proyecto.
Para el desarrollo de la Especificación Funcional, se toma como base lo escrito en los documentos
de Especificación de Requerimientos y Solución Propuesta [MA-02] (ver anexo Especificación
Funcional).

Plan de pruebas
El Plan de Pruebas es un documento estrechamente alineado con la Especificación Funcional, el
cual describe las pruebas que serán llevadas a cabo para demostrar al cliente que la solución
satisface los requerimientos y que la solución cumple con el uso que se pretende en el ambiente
operacional del cliente (Verificación y Validación) [MA-02] (ver anexo Plan de Pruebas).
 Especificación de Diseño de Sistema
La Especificación de Diseño del Sistema define la Arquitectura de la Solución e identifica todos los
componentes del sistema. Establece las interfaces y la especificación a alto nivel de cada
componente. Para cada componente se establece: la descripción de la componente, diagrama de
flujo de datos de la componente, interfaces de la componente, estructura de datos de la
componente, diseño funcional de la componente, criterios de diseño y restricciones de la
componente, especificación de test de la componente e integración, y ambiente de la componente.
Por otro lado, también especifica un nivel básico de implementación y los test de componentes e
integración que se utilizan en la fase de implementación [MA-02] (ver anexo Especificación de
Diseño de Sistema).
 Especificación de Diseño de Soporte
La Especificación de Diseño de Soporte provee documentación detallada de los requerimientos de
soporte desde la fase de implementación a la de operación. Los requerimientos de soporte al
cliente deben ser claramente establecidos para identificar áreas críticas que pudieran requerir
recursos significativos [MA-02] (ver anexo Especificación de Diseño de Soporte).

Plan de Aseguramiento de Calidad SQA
El Plan de QA define todas las actividades de aseguramiento de calidad que se harán durante el
proyecto. La importancia de este plan reside en contar con un documento formal con instrucciones
explícitas acerca de la forma de llevar a cabo cada una de las actividades previamente planificadas
y de esta forma poder controlar cada una de las variables que inciden en el correcto desarrollo del
producto.
Plan de Calidad Aplicación X-Pro-L
20
Modelo de Desarrollo
El Proyecto, debe tener definidas ciertas actividades para cumplir con sus estándares de calidad,
entre ellas realizar revisiones e inspecciones dentro del proyecto, llevar a cabo testing de los
módulos desarrollados, entre otras. Estas actividades, serán realizadas durante todo el proceso de
desarrollo del software para asegurar que este cumpla con los criterios de calidad impuestos.
Algunas de las etapas a seguir son las de llevar a cabo controles sobre la documentación del
software, códigos fuentes, manuales e informes de requerimientos, mantener toda la
documentación con respecto a los cambios efectuados durante el desarrollo, llevar a cabo
procedimientos que permitan asegurar los ajustes de los estándares de desarrollo de software,
mecanismos para realizar mediciones de manejo de información e identificación de procesos, entre
otros.
Por otra parte, el Plan de QA, entrega todos los procedimientos y estándares que se llevarán a
cabo durante el desarrollo del proyecto, así como los formularios y checklist correspondientes. Se
entrega junto con el Plan de Proyecto [MA-02].

Plan de Gestión de la Configuración SCM
Describe la metodología que se seguirá para realizar la gestión de la configuración en el proceso
de desarrollo de software, los formularios y checklist [MA-02] (ver anexo Plan de gestión de la
configuración SCM).

Informe de pruebas (testing)
Los resultados de estas pruebas ayudarán a comprobar el “buen” funcionamiento del software una
vez integrados sus componentes (ver anexo Informe de pruebas).

Manual de usuario
Explica el comportamiento del sistema desde el punto de vista funcional de la Aplicación. Para ello,
se basa en el documento de Especificación Funcional (ver anexo Manual de Usuario).

Manual de instalación del sistema
Especificación de los componentes de instalación y la forma en que se debe realizar esta tarea.

Avances de la Aplicación
Subproductos que evaluará el cliente

Diseño de imágenes y escenarios
Elementos gráficos que forman parte de la aplicación.
Plan de Calidad Aplicación X-Pro-L
21
Modelo de Desarrollo
3.2.1 Definición de los atributos de calidad

Con una perspectiva orientada hacia la Revisión del Producto se tienen los siguientes factores
[MUN-00]:

1º.
Mantenimiento
¿Se pueden corregir los errores?
2º.
Flexibilidad
¿Pueden cambiarlo?
3º.
Prueba
¿Puede ser probado?
Tomando una perspectiva desde la Operación del Producto se tienen los siguientes factores:
4º.
Corrección
¿Hace lo que se le pidió?
5º.
Confiabilidad
¿Es confiable todo el tiempo?
6º.
Facilidad de uso
¿Está diseñado para ser usado?
7º.
Integridad
¿Es seguro (inviolable)?
8º.
Eficiencia
¿Podrá ejecutarse lo mejor que pueda?


Con una perspectiva de la Transición del Producto se tienen los siguientes factores:
9º.
Portabilidad
¿Podrá usarse en otra máquina?
10º.
Rehusabilidad
¿Podrá rehusar algo del software?
11º.
Interoperatividad
¿Podrá interactuar con otro sistema?
Otros atributos definidos son los siguientes:
12º.
Completitud
¿Se encuentran todas las funciones y restricciones en
el sistema?
13º.
Claridad
Son suficientemente claros los conceptos e ideas que
se intentan expresar?
Plan de Calidad Aplicación X-Pro-L
22
Modelo de Desarrollo
3.2.2 Atributos de calidad (evaluados por SQA) por actividades del proceso de desarrollo
Planificación
Producto
Objetivo Cuantificable
La Planificación del proyecto debe respetar los plazos
establecidos.
Se requiere la participación del cliente.
Atributos de Calidad
Claridad, Mantenimiento, Flexibilidad, Confiabilidad,
Corrección, Facilidad de uso, Eficiencia, Integridad.
Encargado (s) revisión final
Gerente de Proyecto, Jefe de Proyecto, Cliente
Tabla 4: Planificación
Producto
Especificación de Requerimientos (Definición)
Objetivo Cuantificable
Se requiere la participación del cliente.
No se debe consumir más de un 20% del tiempo total del
proyecto.
Deben estar identificados los problemas o necesidades de
Negocios en un 90%.
Las metas de la organización, sus objetivos y factores
críticos de éxito deben ser analizados en un 100%.
Los Procesos de Negocios y flujos de información actuales
deben ser analizados en un 100%.
Los Requerimientos de la Solución, en términos de Procesos
y principios de negocios, estructura organizacional y
arquitectura tecnológica, deben ser analizados en un 100%
Los beneficios de la Solución e impacto en la organización,
recursos humanos y ambiente tecnológico deben ser
analizados en un 100%.
Nota: En esta etapa no se debe pensar en posibles
soluciones, sino solamente en el problema, es decir, se debe
describir el problema en forma de Requerimientos
Atributos de Calidad
Claridad, Mantenimiento, Flexibilidad, Corrección,
Confiabilidad, Facilidad de uso, Integridad, Eficiencia
Encargado (s) revisión final
Cliente, Jefe de Proyectos
Tabla 5: Especificación de Requerimientos
Análisis
Producto
Objetivo Cuantificable
Se requiere la participación del cliente.
Se requiere la participación del Analista de Negocios
No se debe consumir más de un 30% del tiempo total del
proyecto.
Se deben identificar las soluciones que satisfagan la
Especificación de Requerimientos, en un 100%, y
seleccionar solo una.
Se debe documentar la Solución Propuesta en un 100%.
Se debe preparar el Plan inicial del Proyecto en un 70% del
total y de QA en un 80%, basado en la Solución Propuesta.
Atributos de Calidad
Completitud, Claridad, Mantenimiento, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Cliente, Jefe de Proyectos
Tabla 6: Análisis
Plan de Calidad Aplicación X-Pro-L
23
Modelo de Desarrollo
Diseño
Producto
Objetivo Cuantificable
No se debe consumir más de un 60% del tiempo total del
Proyecto.
Se requiere de la participación del Arquitecto de Sistema.
Se requiere la participación del Diseñador.
Se requiere de la participación del Jefe de Proyectos.
Se requiere participación del Analista de Negocios
Se debe definir la Funcionalidad y Solución Física que va a
satisfacer los Requerimientos en un 90%.
Se debe planificar cómo se va a implementar y aceptar la
Solución Propuesta en un 90%.
Se debe planificar el soporte de la Solución Propuesta en un
90%.
Atributos de Calidad
Claridad, Completitud, Mantenimiento, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Arquitecto de Sistema, Jefe de Proyectos, Cliente
Tabla 7: Diseño
Implementación
Producto
Objetivo Cuantificable
No se debe consumir más de un 60% del total del Proyecto.
Las Pruebas no deben superar más del 30% del total del
Proyecto.
Los componentes de la Solución deben ser construidos en
un 100%.
Las Pruebas deben cubrir el 100% de los Componentes
construidos.
Atributos de Calidad
Corrección, Claridad, Mantenimiento, Integridad,
Completitud, Facilidad de uso, Integridad, Eficiencia
Encargado (s) revisión final
Jefe de Proyecto, Cliente, Arquitecto de Sistema
Tabla 8: Implementación
Instalación (Aceptación y Entrega)
Producto
Objetivo Cuantificable
Se requiere la participación del cliente.
La Solución se prueba 100% en un ambiente operacional
hasta que esté lista para la prueba de aceptación formal por
parte del cliente.
El cliente debe estar de acuerdo en que la Solución cumple
la Especificación Funcional, que la Solución ha sido
distribuida y que la Organización acepta la propiedad de la
Solución, en un 100%.
Se debe registrar, revisar y corregir la Solución para los
defectos identificados en un 100%.
Se debe involucrar al personal de Soporte para facilitar el
traspaso exitoso, en un 80%.
Atributos de Calidad
Mantenimiento, Corrección, Claridad, Confiabilidad,
Integridad, Completitud, Facilidad de uso, Eficiencia
Encargado (s) revisión final
Cliente
Tabla 9: Instalación (Aceptación y Entrega)
Operación (Mantención)
Producto
Objetivo Cuantificable
Se requiere la participación del cliente.
Se debe hacer una revisión para registrar datos estadísticos
y discutir sobre áreas de experiencia que puedan ser útiles
para otros proyectos en el futuro, en un 80%.
Se debe archivar el contenido del Proyecto y considerar el
proyecto como terminado, en un 100%.
Se debe proveer soporte para la Mantención de la Solución
en un 100%.
Atributos de Calidad
Corrección, Flexibilidad, Facilidad de uso, Corrección,
Confiabilidad, Claridad
Encargado (s) revisión final
Cliente
Tabla 10: Operación (Mantención)
Plan de Calidad Aplicación X-Pro-L
24
Modelo de Desarrollo
3.2.3 Atributos de calidad (evaluados por QA) por productos de trabajo
Producto
Plan de Proyecto
Objetivo Cuantificable
El documento no debe superar las 200 hojas
Debe ser comprendido en un 98% por la totalidad del Equipo
de trabajo.
La Planificación del Proyecto debe ser capaz de soportar
Eventos No Planificados que se puedan producir en el
transcurso del Proyecto. Los EVNP no deben cubrir más de
un 10% del tiempo total del Proyecto.
Se requiere participación del cliente.
El Plan del Proyecto debe contemplar la estrategia,
organización, riesgos, contingencias, recursos y tareas, en
un 100% para la fase de diseño.
Atributos de Calidad
Claridad, Mantenimiento, Flexibilidad, Confiabilidad,
Facilidad de uso, Integridad, Eficiencia
Encargado (s) revisión final
Gerente de Proyecto, Jefe de Proyecto, Cliente
Tabla 11: Plan de Proyecto
Producto
Plan de Riesgos
Objetivo Cuantificable
El documento no debe superar las 50 hojas.
El documento como mínimo debe contener 20 riesgos.
Atributos de Calidad
Claridad, Mantenimiento, Flexibilidad, Corrección,
Confiabilidad, Facilidad de uso, Integridad, Eficiencia.
Encargado (s) revisión final
Jefe de Proyectos
Tabla 12: Plan de Riesgos
Producto
Especificación de Requerimientos
Objetivo Cuantificable
Se requiere participación del Jefe de Proyectos.
Se requiere participación del cliente.
Se requiere participación del Analista de Negocios.
Debe existir un 100% de conformidad en los acuerdos entre
Cliente y Jefe de Proyectos.
Se debe permitir una administración eficiente ante los
estados y cambios que sufran los requerimientos, en un
100%.
Debe ser suficientemente claro, es decir, explicado de
manera No técnica para el entendimiento del cliente.
Deben estar contemplados el 100% de los Requerimientos
planteados por el cliente.
Deben estar contemplados un 100% de los Requerimientos
Derivados.
Atributos de Calidad
Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Jefe de Proyectos, Cliente
Tabla 13: Especificación de Requerimientos
Producto
Especificación de Sistema (Solución Propuesta)
Objetivo Cuantificable
Se requiere participación del Jefe de Proyectos.
Se requiere participación del cliente.
Se requiere participación del Analista de Negocios.
Debe existir un 100% de conformidad en los acuerdos entre
cliente y desarrolladores.
Debe ser claro, es decir, explicado de manera No técnica
para el entendimiento del cliente en un 100%.
La Solución que se presenta al cliente debe ser rigurosa en
sus restricciones, en un 100%.
Atributos de Calidad
Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Cliente, Jefe de Proyectos
Tabla 14: Especificación de Sistema (Solución Propuesta)
Plan de Calidad Aplicación X-Pro-L
25
Modelo de Desarrollo
Especificación Funcional
Producto
Objetivo Cuantificable
Se requiere participación del cliente.
Se requiere participación del Jefe de Proyectos.
Se requiere participación del Analista de Negocios.
Debe existir un 100% de conformidad en los acuerdos entre
cliente y desarrolladores.
Debe ser suficientemente claro, es decir, explicado de
manera No técnica para el entendimiento del cliente en un
100%.
Atributos de Calidad
Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Jefe de Proyecto, Cliente
Tabla 15: Especificación Funcional
Producto
Plan de Pruebas
Objetivo Cuantificable
Se requiere participación del cliente.
Se requiere participación del Jefe de Proyectos.
Se requiere participación del Arquitecto de Sistemas.
Se requiere participación del Analista de Negocios.
El plan de pruebas debe abarcar todos los módulos de la
aplicación.
Las Pruebas deben cubrir el 100% de la Aplicación.
Las Pruebas deben abordar en un 100% los tipos de prueba:
unitaria, integración, y sistema.
Las Pruebas deben abordar en un 100% los enfoques:
Funcional, Seguridad, Calidad, Rendimiento, Aceptación, e
Instalación.
Atributos de Calidad
Claridad, Completitud, Mantenimiento, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Cliente, Jefe de Proyectos, Analista de Negocios
Tabla 16: Plan de Pruebas
Producto
Especificación de Diseño de Sistema
Objetivo Cuantificable
Se requiere participación del cliente.
Se requiere participación del Jefe de Proyectos.
Se requiere participación del Arquitecto de Sistemas.
El desarrollador debe comprender en un 98% el documento.
La Solución (desde el punto de vista del Diseño) debe
contemplar el 100% de los Requerimientos acordados con el
cliente.
La Solución (desde el punto de vista del Diseño) debe
contemplar el 100% de los Requerimientos derivados.
La Solución (desde el punto de vista del Diseño) debe ser lo
suficientemente flexible para soportar en el futuro nuevas
funcionalidades en un 90%
Atributos de Calidad
Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Cliente, Jefe de Proyectos
Tabla 17: Especificación de Diseño de Sistema
Producto
Especificación de Diseño de Soporte
Objetivo Cuantificable
Se requiere participación del cliente.
Se requiere participación del Jefe de Proyectos.
Debe existir un 100% de conformidad en los acuerdos entre
cliente y desarrolladores.
El Documento no debe superar las 100 hojas.
Atributos de Calidad
Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Cliente, Jefe de Proyectos
Tabla 18: Especificación de Diseño de Soporte
Plan de Calidad Aplicación X-Pro-L
26
Modelo de Desarrollo
Producto
Plan de Aseguramiento de Calidad (SQA)
Objetivo Cuantificable
Se requiere la participación del Jefe de QA.
Se requiere la participación del Jefe de Proyectos.
Se debe asegurar en un 100%, que la calidad requerida para
la solución y el proceso de desarrollo esté definido,
incorporado y verificado en todas las fases del proyecto.
En el Plan de QA se deben definir en un 100% todas las
actividades de aseguramiento de calidad que se harán
durante el proyecto.
Atributos de Calidad
Mantenimiento, Claridad, Flexibilidad, Corrección,
Confiabilidad, Facilidad de uso, Integridad, Eficiencia
Encargado (s) revisión final
Jefe de Proyectos, Jefe de QA
Tabla 19: Plan de Aseguramiento de Calidad
Producto
Informe de Pruebas (Testing) de la Integridad del
Sistema, Unidad, y Aceptación
Objetivo Cuantificable
El cliente debe comprender en un 98% el documento.
Se deben detectar a lo menos un 40% de errores en los
Casos de Prueba aplicados.
Atributos de Calidad
Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Cliente, Persona de QA, Jefe de Proyectos
Tabla 20: Informe de Pruebas (Testing)
Producto
Manual de Usuario
Objetivo Cuantificable
El manual no debe manejar un lenguaje técnico, debe ser
entendido en un 95% por los usuarios finales
No debe superar las 50 hojas
Atributos de Calidad
Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Desarrollador, Jefe de Proyectos
Tabla 21: Manual de Usuario
Producto
Manual de Instalación del Sistema
Objetivo Cuantificable
El manual no debe superar las 50 hojas
Atributos de Calidad
Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia
Encargado (s) revisión final
Desarrollador, Jefe de Proyectos
Tabla 22: Manual de Instalación del Sistema
Plan de Calidad Aplicación X-Pro-L
27
Anexos
3.2.4 Puntos de revisión (hitos)
Se identifican como puntos de revisión aquellos que permiten validar y controlar las tareas
realizadas dentro de cada etapa del ciclo de desarrollo y por cada cambio producido en
mantención. Debe ser utilizado por la unidad de SQA durante la planificación para verificar el
correcto establecimiento de los hitos de calidad [WEB-01].







Planificación

Revisión y aprobación del plan de SQA.

Revisión y aprobación del plan de proyecto.

Revisión y aprobación del plan de riesgos.

Reporte del estado y los resultados de las actividades de SQA.
Especificación de requerimientos (Definición)

Revisión y aprobación de la especificación de requerimientos.

Reporte del estado y los resultados de las actividades de SQA.
Análisis

Revisión y Aprobación de la Especificación del Sistema (Solución Propuesta).

Reporte del estado y los resultados de las actividades de SQA.
Diseño

Revisión y aprobación de la Especificación de Diseño de Sistema.

Revisión y aprobación de la Especificación Funcional del Sistema.

Revisión y aprobación de la Especificación de Diseño de Soporte del Sistema.

Revisión y aprobación del Plan de Pruebas del sistema

Reporte del estado y los resultados de las actividades de SQA.
Implementación

Revisión y aprobación de los casos de prueba.

Revisión y aprobación de la especificación de los procedimientos de prueba.

Revisión y aprobación del código y su documentación.

Revisión y aprobación de los resultados de la prueba de unidad, integración, y sistema

Reporte del estado y los resultados de las actividades de SQA.

Reporte del estado y los resultados de las actividades de SQA.

Revisión y aprobación del Manual de Usuario.

Revisión y Aprobación del Manual de Instalación del Sistema
Instalación (Aceptación y entrega)

Revisión y aprobación el software y su documentación.

Reporte del estado y los resultados de las actividades de SQA.
Operación (Mantención)

Revisión y aprobación de cada cambio producido durante la mantención en su
especificación, diseño, implementación y prueba.

Revisión y aprobación de la documentación asociada a los cambios.

Revisión y aprobación de la nueva versión del software y de su documentación.

Reporte del estado y los resultados de las actividades de SQA.
Plan de Calidad Aplicación X-Pro-L
28