Plan de Calidad para Producto de Software 1 (Corta)

PLAN DE CALIDAD PARA PRODUCTO DE SOFTWARE
X-PRO-L
GONZALO TOMS PREZ LARA
MEMORIA PARA OPTAR AL TITULO DE

INGENIERO DE EJECUCION EN INFORMATICA
Profesor Gua:
MARCELLO VISCONTI
Profesor Correferente:
LUIS HEVIA
VALPARAISO, CHILE
OCTUBRE, 2005
RESUMEN
X-Pro-L corresponde a una aplicacin de software interactiva y didctica, 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 aplicacin, de manera
que se adquieran de forma progresiva, los conocimientos necesarios que le permitan al interesado
utilizar las funciones principales del ambiente Linux.
Como caracterstica a considerar, destacan la claridad en la entrega de la informacin y de los
contenidos a travs de mens interactivos, imgenes y animaciones.
Lo que se persigue, es que la aplicacin sea atractiva para el usuario, de manera que la
comprensin de los temas sea ptima.
Para alcanzar tales objetivos, el sistema debe introducir al usuario a la utilizacin del gestor de
ventanas GNOME de Linux, guindolo paso a paso en la ejecucin de las distintas tareas y
aplicaciones que utilice cotidianamente.
El objetivo de esta memoria es disear el Plan de Calidad, cuyo prototipo preliminar fue creado en
la asignatura Taller de Titulacin durante el segundo semestre del ao 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. INTRODUCCIN.........................................................................................................................................6
1.1 Propsito...................................................................................................................................................6
1.2 Alcance......................................................................................................................................................6
1.3 Identificacin de Productos de Trabajo....................................................................................................7
1.4 Descripcin del Sistema............................................................................................................................8
1.4.1 Descripcin de la situacin actual.....................................................................................................8
1.4.2 Descripcin del sistema...................................................................................................................10
1.5 Glosario de Trminos..............................................................................................................................11
1.6 Acrnimos................................................................................................................................................11
2. REQUERIMIENTOS...................................................................................................................................12
2.1 Aplicacin de las Mtricas definidas para el Producto X-Pro-L............................................................12
3. MODELO DE DESARROLLO..................................................................................................................15
3.1 Actividades del proceso de desarrollo....................................................................................................16
3.2 Productos de Trabajo..............................................................................................................................19
3.2.1 Definicin de los atributos de calidad.............................................................................................22
3.2.2 Atributos de calidad (evaluados por SQA) por actividades del proceso de desarrollo...................23
3.2.3 Atributos de calidad (evaluados por QA) por productos de trabajo...............................................25
3.2.4 Puntos de revisin (hitos).................................................................................................................28
4. GESTION......................................................................................................................................................29
4.1 Organizacin...........................................................................................................................................29
4.2 Recursos..................................................................................................................................................29
4.2.1 Recursos humanos............................................................................................................................29
4.2.2 Infraestructura.................................................................................................................................31
4.3 Actividades de SQA.................................................................................................................................32
4.4 Responsabilidades..................................................................................................................................35
4.5 Riesgos....................................................................................................................................................36
4.5.1 Identificacin de riesgos..................................................................................................................36
4.5.2 Clasificacin....................................................................................................................................36
4.5.3 Estimacin de los riesgos.................................................................................................................37
4.5.4 Control de riesgos............................................................................................................................39
5. HERRAMIENTAS, TCNICAS Y METODOLOGAS..........................................................................44
5.1 Aplicacin de mtodos tcnicos formales...............................................................................................44
5.2 Revisiones e inspecciones.......................................................................................................................44
5.3 Registro y generacin de informes.........................................................................................................46
5.4 Checklist..................................................................................................................................................47
5.4.1 Cheklist por actividades del proceso de desarrollo evaluados por QA...........................................47
5.4.2 Cheklist por productos de trabajo evaluados por QA......................................................................49
5.4.3 Cheklist evidenciados por QA..........................................................................................................57
6. PRUEBAS.....................................................................................................................................................62
6.1 Planificacin...........................................................................................................................................62
6.2 Especificacin.........................................................................................................................................63
6.3 Ejecucin................................................................................................................................................63
6.4 Anlisis de resultados.............................................................................................................................64
6.4.1 Completacin...................................................................................................................................64
7. INFORME DE PROBLEMAS Y ACCIONES CORRECTIVAS............................................................65
7.1 Informe de Auditora...............................................................................................................................65
7.1.1 Identificacin de la auditora...........................................................................................................65
7.1.2 Objetos de auditora.........................................................................................................................65
7.1.3 Bases para la evaluacin.................................................................................................................65
7.1.4 Actividades de auditora..................................................................................................................66

7.1.5 Anomalas.........................................................................................................................................66
7.2 Informe de discrepancias........................................................................................................................69
7.2.1 Identificacin del proyecto...............................................................................................................69
7.2.2 Descripcin del problema................................................................................................................69
7.2.3 Resolucin........................................................................................................................................70
7.3 Informe de Actividades de SQA..............................................................................................................72
7.3.1 Identificacin del proyecto...............................................................................................................72
7.3.2 Identificacin del producto / proceso evaluado...............................................................................72
8. CONCLUSIONES.......................................................................................................................................74
9. BIBLIOGRAFA.........................................................................................................................................78
10. ANEXOS.....................................................................................................................................................79
10.1 Plan de Proyecto...................................................................................................................................79
10.2 Plan de Riesgos.....................................................................................................................................96
10.3 Especificacin de Requerimientos........................................................................................................96
10.4 Especificacin del Sistema (Solucin Propuesta)...............................................................................102
10.5 Especificacin Funcional....................................................................................................................109
10.6 Plan de Pruebas..................................................................................................................................116
10.7 Especificacin de Diseo de Sistema..................................................................................................126
10.8 Especificacin de diseo de soporte...................................................................................................131
10.9 Plan de Gestin de la Configuracin SCM.........................................................................................135
10.10 Informe de Pruebas (Testing)............................................................................................................140
10.11 Manual de Usuario............................................................................................................................141
Introduccin
1. INTRODUCCIN
La rapidez con que el mercado mundial avanza hacia la globalizacin, hace imprescindible el uso
de la tecnologa como primer recurso para concretarla. Dentro de ella, lo que ha tenido xito en el
ltimo tiempo es la aparicin de nuevos sistemas operativos, los cules 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 caractersticas, 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 ms creciente en los ltimos aos, 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 tecnologa emergente.
Linux est avanzando en todos los campos de la informtica y su nmero de usuarios crece
rpidamente. Las ventajas tcnicas 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
podra convertirse en el sistema operativo del maana.
Usando las herramientas y tecnologa que la informtica 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 utilizacin de Linux, mediante una
aplicacin de software que facilite su autoaprendizaje, es decir, una herramienta que gue y ayude
al usuario a utilizar Linux. Para ello, la herramienta que permitir conseguir estos objetivos es XPro-L.
1.1 Propsito
El propsito del presente plan es definir la organizacin, actividades y responsabilidades asociadas
al proceso de SQA durante todo el ciclo de vida del proyecto. Adems, entregar guas para la
ejecucin de las actividades de SQA, definir los estndares, los procedimientos y las convenciones
que sern utilizados durante estas actividades y establecer las herramientas, tcnicas y
metodologas que soportarn las prcticas 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 elaboracin, actualizacin y monitoreo del plan.
1.2 Alcance
El presente documento establece, de acuerdo a la poltica organizacional, las actividades de SQA
que debern ser ejecutadas durante el ciclo de vida del software definido para la aplicacin . El ciclo
de vida comprende las etapas de Planificacin, Especificacin de Requerimientos, Anlisis, Diseo,
Implementacin, Instalacin (aceptacin y entrega), y Operacin (Mantencin).
El objetivo del Plan de Calidad es comunicar el mbito, recursos, y herramientas a los gestores del
software y personal tcnico, adems de entregar a la administracin una visibilidad adecuada del
proceso utilizado y los productos construidos durante el proyecto mediante acciones planificadas y
sistemticas que aseguren la calidad de los procesos y productos.
Plan de Calidad Aplicacin X-Pro-L
Introduccin
1.3 Identificacin de Productos de Trabajo

A continuacin, se nombran los productos de trabajos que soportan la construccin del sistema.
Producto de Trabajo
Descripcin
Plan de Proyecto
Documentacin para controlar y monitorear el Proyecto (Ver

anexo Plan de Proyecto).
Plan de Riesgos
Documentacin sobre las posibles situaciones en las que el

Proyecto puede verse afectado (ver pgina 36)
Especificacin de Requerimientos
Repositorio central que contiene la informacin actualizada

de cada uno de los requerimientos detectados.
Descripcin de los requerimientos del cliente que deben ser
satisfechos por el equipo de desarrollo (ver anexo
Especificacin de Requerimientos)
Especificacin del sistema (Solucin Propuesta)
Documentacin sobre la situacin actual, sus problemas y

las mejoras que introduce el desarrollo de la solucin que se
propone (ver anexo Especificacin del Sistema).
Especificacin Funcional
Documentacin que especifica en trminos no tcnicos, que

es lo que la solucin hace que se propone (ver anexo
Especificacin Funcional).
Plan de pruebas
Documentacin que describe las pruebas que sern llevadas

a cabo para demostrar al cliente que la solucin satisface los
requerimientos definidos. (ver anexo Plan de Pruebas).
Especificacin de Diseo de Sistema
Documentacin que define la Arquitectura de la Solucin e

identifica todos los componentes del sistema. (ver anexo
Especificacin de Diseo de Sistema).
Especificacin de Diseo de Soporte
Documentacin detallada de los requerimientos de soporte

desde la fase de Implementacin a la de Operacin (ver
anexo Especificacin de Diseo de Soporte).
Plan de aseguramiento de calidad SQA
Documentacin que define todas las actividades de

aseguramiento de calidad que se harn durante el Proyecto.
Plan de gestin de la configuracin SCM
Documentacin que describe la metodologa que se seguir

para realizar la gestin de la configuracin en el proceso de
desarrollo de software, formularios y checklist (ver anexo
Plan de gestin de la configuracin SCM).
Informe de pruebas (testing)
Documentacin que describe los resultados de las pruebas,

los cuales ayudarn a comprobar el buen funcionamiento
del software.
Manual de usuario
Documentacin que describe el comportamiento del sistema

desde el punto de vista funcional de la aplicacin.
Manual de instalacin del sistema
Documentacin de la especificacin de los componentes de

instalacin y la forma en que se debe realizar esta tarea.
Avances de la Aplicacin
Subproductos que evaluar el cliente.
Diseo de imgenes y escenarios
Elementos grficos que forman parte de la aplicacin

Tabla 1: Identificacin Productos de Trabajo
Introduccin
1.4 Descripcin del Sistema

1.4.1 Descripcin de la situacin actual
La tendencia desde hace un par de aos es que en los colegios y en las familias existan
computadores, debido a ello los jvenes se estn habituando a usarlos tempranamente.
La mayora 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 asesora a personas con mayor experiencia.
Aprender por el mtodo de prueba y error.
Utilizar libros y/o tutoriales relativos al tema.
Realizar un curso pagado.
Las personas actan con recelo hacia lo nuevo y lo desconocido, esto aumenta debido a que los
mtodos mencionados anteriormente no son suficientes para entregar el necesario conocimiento y
la confianza para abordar los nuevos retos, en este caso, la utilizacin 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 didcticas que faciliten su comprensin y su
posterior utilizacin. Es importante el aprendizaje de este sistema operativo, ya que se est
masificando enormemente a nivel mundial debido al auge de nuevas tecnologas.
Linux es conveniente como estacin de trabajo, claro, si el usuario final tiene la disposicin 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 aplicacin de hoja de clculo, 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-tcnico, en la mayora de los casos no dispone de tiempo para leer, ni tampoco tiene
inters por los manuales tradicionales que le explican cmo 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 tcnicos por parte del usuario, seguir siendo obligatoria una capacitacin
adecuada, considerando que va a enfrentarse a un nuevo ambiente, con distintos sistemas de
archivos y nuevos procedimientos. Esta capacitacin no se puede obtener de un foro de discusin
o una lista de soporte. Estos son slo herramientas de ayuda, no la solucin, ya que difcilmente
los usuarios avanzados dispondrn del tiempo necesario para dedicar varias horas al da en
elaborar nuevos manuales o ctedras de enseanza contenidos en un mensaje de correo
electrnico. En lo que refiere a las empresas, stas deben capacitar adecuadamente a su personal
antes de realizar cualquier implementacin, porque de otra forma se obtendrn solamente fracasos
y publicidad negativa para Linux y el software libre en general.
Eventualmente los actuales entornos grficos alcanzarn 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 aos
ms antes de obtener un producto con tal caracterstica.
Introduccin
La comprensin de las necesidades de los usuarios finales viene de un slo 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, situacin que regularmente cubren productos
similares de otras marcas y plataformas. Las herramientas de trabajo que provee Linux son muy
prcticas y efectivas, pero en muchos casos su imagen es muy diferente al estndar 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 ms a lo que ya
conoce[GP-00].
Se mencionar a continuacin, 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 slo en plataformas Intel o clnicas.
Gratis (libre distribucin).
Costo elevado (producto comercial).
Administracin complicada (interaccin con el usuario), salvo Administracin ms fcil. Ratn e Iconos muy popularizados
en entornos grficos 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, slo aplicaciones ofimticas 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
distribucin y mejora
No se dispone de ellas.
Lento aprendizaje, difcil instalacin
Ms rpido e intuitivo, instalacin automatizada.
Muchsimo soporte en Internet y guas. Comunicacin fcil

con otros usuarios y con los mismos desarrolladores.
Poco soporte real. S en libros.
No ha llegado al pblico en general, aunque aumenta da a

da.
Es el sistema operativo que ms ha contribuido a la

popularizacin de los PC y de la Informtica en general.
El 85% de los computadores del planeta.
Es utilizado por usuarios que buscan estabilidad y fiabilidad

Utilizado por pblico en general.
(nivel medio avanzado). Se necesita algo de experiencia y
algunos conocimientos bsicos para configurarlo
adecuadamente, sobre todo lo relacionado con multimedia y
redes.
Tabla 2: Linux v/s Windows
Introduccin
Se destaca que ninguno de los sistemas operativos que existen hoy en da est exento de
pequeos detalles. La diferencia de Linux sobre otros sistemas operativos radica principalmente
en:
Que los errores que pudiesen existir en algn componente de Linux no son tan frecuentes
como los de los "otros" sistemas operativos.
Estabilidad, fiabilidad y robustez para la realizacin de diversas tareas.
Que cuando se descubre un error, ste siempre se hace pblico, e incluso, en algunos casos,
se puede obtener el parche correspondiente el mismo da.
Que, si lo desea, y en la mayora de los casos, puede contactar directamente al autor de la

aplicacin, controlador, mdulo o programa, quien seguramente le dar respuesta a sus dudas
e inquietudes.
Los mtodos de seguridad de Linux son mejores que los de los "otros" sistemas operativos, por
lo que es menos probable que sea vctima de un "Hacker" o que se filtre informacin fuera de
su PC sin su autorizacin. 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 aplicacin, programa o servicio. El usuario no perder tiempo y
productividad. En Linux los servicios como Sendmail, Servidores Web, demonios en general,
aplicaciones, se desempean de forma independiente.
Hoy en da se estima que existen ms de 30 millones de usuarios de Linux en todo el mundo,

comparados con los ms de 450 millones de usuarios de todas las versiones de Windows. Sin
embargo, esta desventaja numrica se acorta cada da ms puesto que los usuarios de Linux se
duplican en nmero cada ao, debido principalmente a las caractersticas planteadas
anteriormente.
Una caracterstica muy significativa de Linux es su robustez, estabilidad, y distribucin gratuita.
Pero, por qu no lidera an el mercado domstico?, por que es relativamente nuevo (naci a
principios de los 90) y slo en el ltimo tiempo se ha orientado hacia el pblico en general, ya que
en sus inicios estaba destinado a usuarios especializados.
1.4.2 Descripcin del sistema
La solucin a implementar consiste en una aplicacin que permitir adquirir los conocimientos
bsicos para interactuar con el sistema operativo Linux. La Aplicacin ser programada en un
modelo de 3 capas, el que es definido a continuacin:
Capa de Presentacin: Tiene por finalidad la interaccin 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 anlisis del sistema.
Capa de Datos: Se encarga slo de asegurar la persistencia de los datos y su recuperacin
eficaz. No debe ocuparse de resolver problemas asociados a las reglas del negocio y/o
presentacin, pues corresponden a las otras capas.
10
Introduccin
La aplicacin permitir la poblacin de la Base de Datos, y navegar a travs de los contenidos. El

sistema ser instalado en un servidor que contendr la aplicacin y la Base de Datos. Los
computadores conectados al servidor, estarn conectados en modo Cliente (Capa de
Presentacin), permitiendo acceso solo a los perfiles definidos para cada usuario.
Para acceder a la aplicacin, se deber tener un login y password definidos para cada usuario.
1.5 Glosario de Trminos

Para lograr un mejor entendimiento de los trminos tcnicos que se utilizan en el presente Plan de
SQA, se mencionan a continuacin los significados de los siguientes trminos [WEB-01]:
Aseguramiento de la Calidad del Software (SQA) El propsito de SQA es entregar a la

administracin una visibilidad adecuada del proceso utilizado y los productos construidos
mediante acciones planificadas y sistemticas que aseguren la calidad de dichos procesos y
productos.
Auditora Evaluacin independiente de los productos de trabajo y de un conjunto de

procesos de software para asegurar la adherencia con las especificaciones, los estndares,
procedimientos y otros acuerdos.
Gestin de la Configuracin del Software (SCM) El propsito de SCM es establecer y

mantener la integridad de los productos a travs de todo el ciclo de vida del software, para as
proveer un adecuado control de los cambios en los diversos tems de configuracin.
Revisin Metodologa definida, estructurada y disciplinada para la deteccin e identificacin

de defectos en los productos de trabajo durante el ciclo de vida del software.
Prueba (Testing) Actividad que evala los atributos y la capacidad de un programa o

sistema para determinar si se cumple con los resultados definidos.
1.6 Acrnimos
Acrnimo
Significado
SQA
Software Quality Assurance, Aseguramiento de la Calidad del Software
SCM
Software Configuration Management, Gestin de Configuracin del Software
WBS
Work Breakdown Structure
Tabla 3: Listado de Acrnimos
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
tendrn que ser realizadas por el sistema a desarrollar. En cambio, un Requerimiento No Funcional
indica cmo 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
aplicacin.
Las mtricas 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 aplicacin para funcionar correctamente en diferentes

configuraciones, ya sean de software o hardware.
Performance: Requerimientos reales de la performance, velocidad, precisin, disponibilidad,

nivel de servicio, volmenes 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 realizacin

de cambios.
Seguridad: Requerimientos para permitir el acceso, restringir mal uso, hechos anormales,
entre otros.
2.1 Aplicacin de las Mtricas definidas para el Producto X-Pro-L

Interfaz
La interfaz para esta aplicacin debe ser simple en la entrega de datos, topologa de letra
adecuada a la vista, colores adecuados, rpidos y eficientes para la seleccin e ingreso de datos al
sistema.
Objetivos
Simplicidad en la entrega de datos, sin tener necesidad de instrucciones para su uso.
Tipologa de la letra adecuada a la vista y que no produzca rechazo por el usuario.
Forma rpida y eficiente para seleccionar e ingresar datos al sistema.
La interfaz debe mostrar la estructura de los contenidos, de manera rpida de entender para el
usuario, adems de figuras didcticas, colores y enlaces, para una mejor comprensin y
profundizacin de los temas.
Criterios de Aceptacin
La interfaz debe mostrar en todo momento la estructura de rbol que presenta para la
organizacin de los contenidos.
La rapidez de respuesta de la aplicacin, ante los datos que se seleccionan e ingresan no

debe superar los 2 seg.
12
Requerimientos
Portabilidad
Para la utilizacin de la aplicacin, debe considerarse el correcto funcionamiento desde el sistema
operativo Linux y el hardware apropiado para su uso.
Objetivos
Los equipos deben contar con ciertas caractersticas mnimas para el correcto funcionamiento
del sistema.
La aplicacin debe funcionar bajo el sistema operativo Linux.
La aplicacin debe acoplarse a la totalidad de mdulos construidos y los que puedan ser
incorporados de forma posterior.
La aplicacin debe ejecutarse sin ningn problema en los distintos computadores donde sea
instalado. Para ello, las caractersticas mnimas son:
Procesador Pentium III, 733 Mhz o similar
Disco Duro de 10 GB
256 MB Ram
La aplicacin debe funcionar bajo el sistema operativo Linux Red Hat 7.0 (o distribucin
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
volmenes de datos.
Objetivos
La aplicacin debe entregar una respuesta rpida a la consulta realizada.
La aplicacin debe permitir el manejo rpido de grandes volmenes de datos.
La rapidez de respuesta no debe ser mayor a 5 [seg] desde que se realiz la actualizacin.
La aplicacin debe permitir el manejo de 10000 registros.
Operacional
Por otra parte, la informacin desplegada por pantalla debe ser clara y sencilla, sin mayor
sobrecarga de imgenes e informacin, de manera que no sea dificultoso el entendimiento de los
datos desplegados.
Objetivos
La aplicacin debe mostrar un nmero adecuado de figuras dinmicas y estticas, evitando la

sobrecarga de ellas.
La aplicacin debe mostrar un nmero de preguntas que no sobrecargue la interfaz.
No se deben desplegar ms de 3 figuras dinmicas y 5 figuras dinmicas en forma simultnea.
No se deben desplegar ms de 10 preguntas por cada mdulo a evaluar.
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 sern descubiertas por los mismos usuarios de la
aplicacin dndolas a conocer a travs de e-mail o personalmente al Administrador.
Objetivos
La aplicacin debe funcionar correctamente sin la necesidad de modificaciones posteriores al

equipo.
La mantencin debe ser realizada en horarios en que no se ocupe la Aplicacin.
Se debe considerar el tiempo de mantencin y los mdulos afectados por los cambios, ya sean
correctivos o perfectivos.
El tiempo de mantencin estar restringido segn las lneas de cdigo del mdulo afectado,
debido a que existen componentes que son de gran complejidad, por lo cual tendrn un tiempo
mayor de mantencin.
La aplicacin debe ser actualizada una vez cada seis meses, debido a los continuos cambios
que puedan sufrir las versiones de la aplicacin.
La documentacin necesaria debe tener descrito los cambios realizados, adems de los pasos
seguidos en el proceso de desarrollo y mantenciones posteriores.
El cdigo fuente de la aplicacin debe ser comentado al menos en un 50% del total, y claros en
su estructura.
Seguridad
La aplicacin 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 modificarn constantemente, se debe tener un
respaldo peridico de la aplicacin.
Objetivos
Los datos no deben ser modificados por terceros.
Se debe asegurar la recuperacin de los datos, en caso de fallar la aplicacin.
La aplicacin debe poseer un control de acceso al sistema, con el fin de evitar el

procesamiento de datos errneos.
Se debe establecer un perfil para el administrador, quien tendr acceso a la informacin clave
de la aplicacin.
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 aplicacin una vez a la semana.
Toda persona que desee ingresar a la aplicacin debe tener asignado un login y password.
Los usuarios de la aplicacin deben obligatoriamente actualizar su login y password una vez al
mes.
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 eleccin de la estrategia seleccionada se debe a que la intencin es
entregar el software en partes pequeas, pero utilizables, llamadas incrementos, es decir, cada
incremento se construye sobre aqul 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 bsicos, pero muchas funciones suplementarias (algunas
conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisin
detallada). Como un resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el
incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las
necesidades del cliente y la entrega de funciones, y caractersticas 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 tambin una plataforma para la evaluacin. El desarrollo incremental
es particularmente til cuando la dotacin de personal no est disponible para una implementacin
completa en la fecha lmite 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 cules son sus requisitos ideales. Debido a esto, la construccin
temprana del sistema nos puede llevar a desarrollar una solucin intil. Como solucin a esto, se
entregar una versin del programa X-Pro-L con la implementacin de algunas funciones, dejando
el proyecto abierto a que en una futura etapa de desarrollo, entregue una nueva versin del
proyecto que agregue nuevas funcionalidades (un incremento).
Incremento 1
Ingeniera Sistemas
de Informacin
Anlisis
Diseo
Cdigo
Entrega de 1
Incremento
Prueba
Incremento 2
Anlisis
Diseo
Cdigo
Entrega de 2
Incremento
Prueba
Incremento 3
Anlisis
Diseo
Cdigo
Prueba
Entrega de 3
Incremento
Incremento 4
Anlisis
Diseo
Cdigo
Prueba
Entrega de 4
Incremento
Figura 1: Modelo Incremental
15
3.1 Actividades del proceso de desarrollo
Planificacin
Planificacin / definicin de recursos, tiempo y otras informaciones relacionadas con el proyecto

segn la evaluacin del cliente poniendo nfasis en lo que se debe modificar y lo que se debe
mantener.
Durante la etapa de planificacin, SQA debe participar de la elaboracin del Plan de Proyecto. Es
su responsabilidad producir el Plan de SQA y verificar que los procesos, procedimientos y
estndares identificados en el Plan de Proyecto sean apropiados, claros, especficos y auditables.
El contenido del Plan de SQA debe identificar: evaluaciones, auditoras y revisiones, estndares,
procedimientos de seguimiento y reporte de errores, y documentacin por producir.
Especificacin de requerimientos (Definicin)
Esta fase comienza cuando se han identificado los problemas o necesidades de negocios, cuya
solucin requiere un anlisis y especificacin. En esta etapa el equipo de proyecto debe entender
al cliente en trminos de sus problemas y direccin, sus capacidades tcnicas y de organizacin y
su potencial futuro. Para esto hay que analizar:
Las metas de la organizacin, sus objetivos y factores crticos de xito.
Los procesos de negocios y flujos de informacin actuales.
Requerimientos de solucin, en trminos de procesos y principios de negocios, estructura
organizacional y arquitectura tecnolgica.
Beneficios de la solucin e impacto en la organizacin, recursos humanos y ambiente
tecnolgico.
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 Especificacin estn expresados todos los requerimientos, de
manera tal que puedan ser verificados en el producto final.
Anlisis
Durante esta fase se analiza la Especificacin de Requerimientos con el objetivo de identificar las
soluciones que satisfagan los requerimientos, se analizan diferentes alternativas de solucin y se
selecciona solo una, y se genera el informe de Solucin Propuesta [MA-02].
En la fase de Anlisis, dentro de las actividades de SQA se incluye asegurar:
La adherencia del Anlisis y su documentacin a los estndares definidos en el Plan de

Proyecto.
La incorporacin de los resultados de las inspecciones en el Anlisis.
Diseo
Esta etapa se centra en el "cmo", en la forma cmo debe construirse el sistema de software de
acuerdo a la informacin obtenida de la etapa de anlisis. En esta etapa se define como deber
implementarse el sistema de software. Los modelos creados en la fase de anlisis determinan
claramente cul debe ser el comportamiento general del sistema en un entorno ideal. Los modelos
a crear en la fase de diseo determinan, ya sobre el entorno propio de la organizacin, cmo
16
deber implementarse el sistema. Por otra parte, en esta fase el Equipo de Proyecto define la
funcionalidad y solucin fsica que va a satisfacer los requerimientos definidos [MA-02].
En la fase de diseo, dentro de las actividades de SQA se incluye asegurar:
La adherencia del diseo y su documentacin a los estndares definidos en el Plan del

Proyecto.
La presencia de todo mdulo en el diseo.
La incorporacin de los resultados de las inspecciones en el diseo.
El ingreso del diseo a la configuracin del software, tras su aprobacin.
Implementacin
La implementacin se establece como la "construccin" del sistema. La actividad slo lleva a la

prctica el sistema que se model en la fase de diseo. La fase incluye las actividades de
codificacin e integracin de los diferentes mdulos constitutivos del sistema. En la fase de
implementacin, cada componente de la solucin, identificado en la Especificacin de Diseo de
Sistema, se disea 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 estndares 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
diseo y, en algunos casos, para llegar a ser parte de la solucin.
Los componentes individuales son distribuidos por varias disciplinas y terceras partes. Es esencial
que el Equipo aplique los principios de control de cambios, administracin de la configuracin y
reportes. Esta fase involucra a muchas personas trabajando simultneamente, 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 estn claramente definidas.
El software generado en la fase de implementacin 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 omisin o mal interpretacin de alguna parte del anlisis o el
diseo.
Los defectos debern entonces detectarse y corregirse en esta fase del proyecto. En ocasiones los
defectos pueden deberse a errores en la implementacin de cdigo (errores propios del lenguaje o
sistema de implementacin), aunque en esta etapa es posible realizar una efectiva deteccin de los
mismos, ellos deben ser detectados y corregidos en la fase de implementacin.
A SQA le corresponde auditar:
Los resultados de las actividades de diseo y codificacin.
El estado de todos los entregables.
Las actividades de gestin de configuracin 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
tambin toda desviacin sea informada y corregida.
Certificar que las actividades de prueba se han completado satisfactoriamente y que el
software y su documentacin se encuentran listos para la entrega del producto final.
17
Instalacin (Aceptacin y Entrega)
Aceptacin (negativa o positiva) de las representaciones de la aplicacin por parte del cliente.
Durante la fase de instalacin, todas las componentes de la solucin se distribuyen al cliente y se
instalan. La solucin se prueba como un todo en un ambiente operacional hasta que est lista para
la prueba de aceptacin formal por parte del cliente [MA-02].
La Prueba de Aceptacin quiere demostrar al cliente que la solucin cumple los requerimientos de
la Especificacin Funcional. El cliente confirma por escrito que todas las pruebas han sido exitosas
y que acepta la solucin [MA-02].
La salida de esta fase es transferir la propiedad de la solucin a la organizacin cliente.
En la fase de aceptacin, SQA es responsable de realizar la ltima auditoria de configuracin del
software, con el objetivo de determinar que los deliberables estn listos para la entrega.
Operacin (Mantencin)
Esta es la fase post-aceptacin del proyecto, durante la cual se mantiene y soporta la solucin
segn lo acordado entre las partes.
En esta fase el software es puesto en funcionamiento con los usuarios y el entorno de la
organizacin. Es comn que estas etapas requieran de trabajo adicional del equipo de
desarrolladores, especialmente en procesos de configuracin adecuada, utilidades menores de
copias de respaldo, administracin de seguridad o reportes adicionales. Esta es la fase postaceptacin del proyecto, durante la cual se mantiene y soporta la solucin segn lo acordado entre
las partes [MA-02].
Se hace una revisin para registrar datos estadsticos 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.
Despus del perodo de garanta, se puede continuar con la mantencin de la solucin.
En la fase de Operacin, 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 operacin pueden presentarse correcciones o mejoras que originen pequeos ciclos de
desarrollo. En tal caso, se repetirn las actividades de SQA descritas con anterioridad [SOM-00].
18
3.2 Productos de Trabajo

A continuacin, se definen los productos de trabajo que deberan 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
informacin de planificacin e implementacin requerida para ejecutar el plan de proyecto entero.
Provee un resumen y una integracin 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 informacin que est disponible en la fase de anlisis. Al tener
informacin ms detallada, segn 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 podra verse afectado.
Para ello, se realiza un Anlisis de Riesgos, a travs de la cual se establecern las acciones a
tomar en caso que se concreten dichas situaciones. Bsicamente, el Plan de Riesgos debe
contemplar la: definicin de los riesgos, la posibilidad de que se concrete cada uno de los riesgos
detectados, definir que tan grande sera 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 pgina 36).
La Especificacin de Requerimientos proporciona un repositorio central que contiene la informacin
actualizada de cada uno de los requerimientos detectados, como el nmero secuencial que
identifica en forma nica al requerimiento, tipo de requerimiento, identificacin de requerimiento
original (cuando es reclasificado), estado del requerimiento, persona que lo plante, categora 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 administracin correcta de los requerimientos del proyecto [MA-02].
Por otra parte, la Especificacin de Requerimientos refleja las necesidades de negocio, los
requerimientos necesarios para resolver aquellas necesidades, y objetivos del cliente que buscan
una solucin. 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 trminos del negocio. Debiera ser capaz de ser producido en un
tiempo limitado, y no debera contener detalles especficos a menos que sean considerados
requisitos para el negocio. La Especificacin de Requerimientos forma la base para el desarrollo de
la Solucin Propuesta, pero al mismo tiempo difieren, pues sta refleja las necesidades y objetivos
de negocio traducidos en requerimientos para una solucin. La Solucin Propuesta detalla
especificaciones para una solucin especfica seleccionada a partir de un nmero de alternativas
posibles [MA-02] (ver anexo Especificacin de Requerimientos).
19
Especificacin del Sistema (Solucin Propuesta)

Mostrando como es la situacin actual, sus problemas y las mejoras que introduce el desarrollo de
la solucin que se propone. La Solucin Propuesta especifica en trminos no tcnicos cmo la
solucin satisface al cliente y es la base para la Especificacin Funcional, que es producida en la
fase de diseo. Incluye tambin el soporte operacional propuesto que es la base para formular el la
Especificacin de Diseo de Soporte [MA-02] (ver anexo Especificacin del Sistema).
La Especificacin Funcional especifica en trminos no tcnicos, qu es lo que la solucin hace
para el usuario. Este es un documento muy importante, por que provee una nica definicin formal
del total de los requerimientos que satisface la solucin, y por que es la base para planificar el
diseo y para desarrollar e implementar el Proyecto.
Para el desarrollo de la Especificacin Funcional, se toma como base lo escrito en los documentos
de Especificacin de Requerimientos y Solucin Propuesta [MA-02] (ver anexo Especificacin
Funcional).
Plan de pruebas
El Plan de Pruebas es un documento estrechamente alineado con la Especificacin Funcional, el
cual describe las pruebas que sern llevadas a cabo para demostrar al cliente que la solucin
satisface los requerimientos y que la solucin cumple con el uso que se pretende en el ambiente
operacional del cliente (Verificacin y Validacin) [MA-02] (ver anexo Plan de Pruebas).
La Especificacin de Diseo del Sistema define la Arquitectura de la Solucin e identifica todos los
componentes del sistema. Establece las interfaces y la especificacin a alto nivel de cada
componente. Para cada componente se establece: la descripcin de la componente, diagrama de
flujo de datos de la componente, interfaces de la componente, estructura de datos de la
componente, diseo funcional de la componente, criterios de diseo y restricciones de la
componente, especificacin de test de la componente e integracin, y ambiente de la componente.
Por otro lado, tambin especifica un nivel bsico de implementacin y los test de componentes e
integracin que se utilizan en la fase de implementacin [MA-02] (ver anexo Especificacin de
Diseo de Sistema).
La Especificacin de Diseo de Soporte provee documentacin detallada de los requerimientos de
soporte desde la fase de implementacin a la de operacin. Los requerimientos de soporte al
cliente deben ser claramente establecidos para identificar reas crticas que pudieran requerir
recursos significativos [MA-02] (ver anexo Especificacin de Diseo de Soporte).
Plan de Aseguramiento de Calidad SQA
El Plan de QA define todas las actividades de aseguramiento de calidad que se harn durante el
proyecto. La importancia de este plan reside en contar con un documento formal con instrucciones
explcitas 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.
20
El Proyecto, debe tener definidas ciertas actividades para cumplir con sus estndares de calidad,
entre ellas realizar revisiones e inspecciones dentro del proyecto, llevar a cabo testing de los
mdulos desarrollados, entre otras. Estas actividades, sern 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 documentacin del
software, cdigos fuentes, manuales e informes de requerimientos, mantener toda la
documentacin con respecto a los cambios efectuados durante el desarrollo, llevar a cabo
procedimientos que permitan asegurar los ajustes de los estndares de desarrollo de software,
mecanismos para realizar mediciones de manejo de informacin e identificacin de procesos, entre
otros.
Por otra parte, el Plan de QA, entrega todos los procedimientos y estndares que se llevarn 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 Gestin de la Configuracin SCM
Describe la metodologa que se seguir para realizar la gestin de la configuracin en el proceso
de desarrollo de software, los formularios y checklist [MA-02] (ver anexo Plan de gestin de la
configuracin SCM).
Informe de pruebas (testing)
Los resultados de estas pruebas ayudarn 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 Aplicacin. Para ello,
se basa en el documento de Especificacin Funcional (ver anexo Manual de Usuario).
Manual de instalacin del sistema
Especificacin de los componentes de instalacin y la forma en que se debe realizar esta tarea.
Avances de la Aplicacin
Subproductos que evaluar el cliente
Diseo de imgenes y escenarios
Elementos grficos que forman parte de la aplicacin.
21
3.2.1 Definicin de los atributos de calidad
Con una perspectiva orientada hacia la Revisin 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 Operacin del Producto se tienen los siguientes factores:
4.
Correccin
Hace lo que se le pidi?
5.
Confiabilidad
Es confiable todo el tiempo?
6.
Facilidad de uso
Est diseado para ser usado?
7.
Integridad
Es seguro (inviolable)?
8.
Eficiencia
Podr ejecutarse lo mejor que pueda?
Con una perspectiva de la Transicin del Producto se tienen los siguientes factores:
9.
Portabilidad
Podr usarse en otra mquina?
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?
22
3.2.2 Atributos de calidad (evaluados por SQA) por actividades del proceso de desarrollo
Producto
Planificacin
Objetivo Cuantificable
La Planificacin del proyecto debe respetar los plazos

establecidos.
Se requiere la participacin del cliente.
Atributos de Calidad
Claridad, Mantenimiento, Flexibilidad, Confiabilidad,

Correccin, Facilidad de uso, Eficiencia, Integridad.
Encargado (s) revisin final
Gerente de Proyecto, Jefe de Proyecto, Cliente

Tabla 4: Planificacin
Producto
Especificacin de Requerimientos (Definicin)

No se debe consumir ms de un 20% del tiempo total del
proyecto.
Deben estar identificados los problemas o necesidades de
Negocios en un 90%.
Las metas de la organizacin, sus objetivos y factores
crticos de xito deben ser analizados en un 100%.
Los Procesos de Negocios y flujos de informacin actuales
deben ser analizados en un 100%.
Los Requerimientos de la Solucin, en trminos de Procesos
y principios de negocios, estructura organizacional y
arquitectura tecnolgica, deben ser analizados en un 100%
Los beneficios de la Solucin e impacto en la organizacin,
recursos humanos y ambiente tecnolgico 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
Claridad, Mantenimiento, Flexibilidad, Correccin,

Confiabilidad, Facilidad de uso, Integridad, Eficiencia
Cliente, Jefe de Proyectos

Tabla 5: Especificacin de Requerimientos
Producto
Anlisis

Se requiere la participacin del Analista de Negocios
proyecto.
Se deben identificar las soluciones que satisfagan la
Especificacin de Requerimientos, en un 100%, y
seleccionar solo una.
Se debe documentar la Solucin 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 Solucin Propuesta.
Completitud, Claridad, Mantenimiento, Flexibilidad,

Correccin, Confiabilidad, Facilidad de uso, Integridad,
Eficiencia

Tabla 6: Anlisis
23
Producto
Diseo

Proyecto.
Se requiere de la participacin del Arquitecto de Sistema.
Se requiere la participacin del Diseador.
Se requiere de la participacin del Jefe de Proyectos.
Se requiere participacin del Analista de Negocios
Se debe definir la Funcionalidad y Solucin Fsica que va a
satisfacer los Requerimientos en un 90%.
Se debe planificar cmo se va a implementar y aceptar la
Solucin Propuesta en un 90%.
Se debe planificar el soporte de la Solucin Propuesta en un
90%.
Claridad, Completitud, Mantenimiento, Flexibilidad,

Eficiencia
Arquitecto de Sistema, Jefe de Proyectos, Cliente

Tabla 7: Diseo
Producto
Implementacin
No se debe consumir ms de un 60% del total del Proyecto.

Las Pruebas no deben superar ms del 30% del total del
Proyecto.
Los componentes de la Solucin deben ser construidos en
un 100%.
Las Pruebas deben cubrir el 100% de los Componentes
construidos.
Correccin, Claridad, Mantenimiento, Integridad,

Completitud, Facilidad de uso, Integridad, Eficiencia
Jefe de Proyecto, Cliente, Arquitecto de Sistema

Tabla 8: Implementacin
Producto
Instalacin (Aceptacin y Entrega)

La Solucin se prueba 100% en un ambiente operacional
hasta que est lista para la prueba de aceptacin formal por
parte del cliente.
El cliente debe estar de acuerdo en que la Solucin cumple
la Especificacin Funcional, que la Solucin ha sido
distribuida y que la Organizacin acepta la propiedad de la
Solucin, en un 100%.
Se debe registrar, revisar y corregir la Solucin para los
defectos identificados en un 100%.
Se debe involucrar al personal de Soporte para facilitar el
traspaso exitoso, en un 80%.
Mantenimiento, Correccin, Claridad, Confiabilidad,

Integridad, Completitud, Facilidad de uso, Eficiencia
Cliente
Tabla 9: Instalacin (Aceptacin y Entrega)
Producto

Se debe hacer una revisin para registrar datos estadsticos
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 Mantencin de la Solucin
en un 100%.
Correccin, Flexibilidad, Facilidad de uso, Correccin,

Confiabilidad, Claridad
Cliente
Tabla 10: Operacin (Mantencin)
24
3.2.3 Atributos de calidad (evaluados por QA) por productos de trabajo

Producto
Plan de Proyecto
El documento no debe superar las 200 hojas

Debe ser comprendido en un 98% por la totalidad del Equipo
de trabajo.
La Planificacin del Proyecto debe ser capaz de soportar
Eventos No Planificados que se puedan producir en el
transcurso del Proyecto. Los EVNP no deben cubrir ms de
un 10% del tiempo total del Proyecto.
Se requiere participacin del cliente.
El Plan del Proyecto debe contemplar la estrategia,
organizacin, riesgos, contingencias, recursos y tareas, en
un 100% para la fase de diseo.
Claridad, Mantenimiento, Flexibilidad, Confiabilidad,

Facilidad de uso, Integridad, Eficiencia
Gerente de Proyecto, Jefe de Proyecto, Cliente

Tabla 11: Plan de Proyecto
Producto
Plan de Riesgos
El documento no debe superar las 50 hojas.

El documento como mnimo debe contener 20 riesgos.
Claridad, Mantenimiento, Flexibilidad, Correccin,

Confiabilidad, Facilidad de uso, Integridad, Eficiencia.
Jefe de Proyectos
Tabla 12: Plan de Riesgos
Producto
Se requiere participacin del Jefe de Proyectos.
Se requiere participacin del Analista de Negocios.
Debe existir un 100% de conformidad en los acuerdos entre
Cliente y Jefe de Proyectos.
Se debe permitir una administracin eficiente ante los
estados y cambios que sufran los requerimientos, en un
100%.
Debe ser suficientemente claro, es decir, explicado de
manera No tcnica 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.
Completitud, Mantenimiento, Claridad, Flexibilidad,

Eficiencia
Jefe de Proyectos, Cliente

Tabla 13: Especificacin de Requerimientos
Producto
Especificacin de Sistema (Solucin Propuesta)

cliente y desarrolladores.
Debe ser claro, es decir, explicado de manera No tcnica
para el entendimiento del cliente en un 100%.
La Solucin que se presenta al cliente debe ser rigurosa en
sus restricciones, en un 100%.

Eficiencia

Tabla 14: Especificacin de Sistema (Solucin Propuesta)
25
Producto

Debe ser suficientemente claro, es decir, explicado de
manera No tcnica para el entendimiento del cliente en un
100%.

Eficiencia
Jefe de Proyecto, Cliente

Tabla 15: Especificacin Funcional
Producto
Plan de Pruebas

Se requiere participacin del Arquitecto de Sistemas.
El plan de pruebas debe abarcar todos los mdulos de la
aplicacin.
Las Pruebas deben cubrir el 100% de la Aplicacin.
Las Pruebas deben abordar en un 100% los tipos de prueba:
unitaria, integracin, y sistema.
Las Pruebas deben abordar en un 100% los enfoques:
Funcional, Seguridad, Calidad, Rendimiento, Aceptacin, e
Instalacin.
Claridad, Completitud, Mantenimiento, Flexibilidad,

Eficiencia
Cliente, Jefe de Proyectos, Analista de Negocios

Tabla 16: Plan de Pruebas
Producto

Se requiere participacin del Arquitecto de Sistemas.
El desarrollador debe comprender en un 98% el documento.
La Solucin (desde el punto de vista del Diseo) debe
contemplar el 100% de los Requerimientos acordados con el
cliente.
La Solucin (desde el punto de vista del Diseo) debe
contemplar el 100% de los Requerimientos derivados.
La Solucin (desde el punto de vista del Diseo) debe ser lo
suficientemente flexible para soportar en el futuro nuevas
funcionalidades en un 90%

Eficiencia

Tabla 17: Especificacin de Diseo de Sistema
Producto

El Documento no debe superar las 100 hojas.

Eficiencia

Tabla 18: Especificacin de Diseo de Soporte
26
Producto
Plan de Aseguramiento de Calidad (SQA)
Se requiere la participacin del Jefe de QA.

Se requiere la participacin del Jefe de Proyectos.
Se debe asegurar en un 100%, que la calidad requerida para
la solucin 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 harn
durante el proyecto.
Mantenimiento, Claridad, Flexibilidad, Correccin,

Confiabilidad, Facilidad de uso, Integridad, Eficiencia
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 Aceptacin
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.

Eficiencia
Cliente, Persona de QA, Jefe de Proyectos

Tabla 20: Informe de Pruebas (Testing)
Producto
Manual de Usuario
El manual no debe manejar un lenguaje tcnico, debe ser

entendido en un 95% por los usuarios finales
No debe superar las 50 hojas

Eficiencia
Desarrollador, Jefe de Proyectos

Tabla 21: Manual de Usuario
Producto
Manual de Instalacin del Sistema
El manual no debe superar las 50 hojas

Eficiencia
Desarrollador, Jefe de Proyectos

Tabla 22: Manual de Instalacin del Sistema
27
Anexos
3.2.4 Puntos de revisin (hitos)

Se identifican como puntos de revisin aquellos que permiten validar y controlar las tareas
realizadas dentro de cada etapa del ciclo de desarrollo y por cada cambio producido en
mantencin. Debe ser utilizado por la unidad de SQA durante la planificacin para verificar el
correcto establecimiento de los hitos de calidad [WEB-01].
Planificacin
Revisin y aprobacin del plan de SQA.
Revisin y aprobacin del plan de proyecto.
Revisin y aprobacin del plan de riesgos.
Reporte del estado y los resultados de las actividades de SQA.
Especificacin de requerimientos (Definicin)

Revisin y aprobacin de la especificacin de requerimientos.
Anlisis
Revisin y Aprobacin de la Especificacin del Sistema (Solucin Propuesta).
Diseo
Revisin y aprobacin de la Especificacin de Diseo de Sistema.
Revisin y aprobacin de la Especificacin Funcional del Sistema.
Revisin y aprobacin de la Especificacin de Diseo de Soporte del Sistema.
Revisin y aprobacin del Plan de Pruebas del sistema
Implementacin
Revisin y aprobacin de los casos de prueba.
Revisin y aprobacin de la especificacin de los procedimientos de prueba.
Revisin y aprobacin del cdigo y su documentacin.
Revisin y aprobacin de los resultados de la prueba de unidad, integracin, y sistema
Revisin y aprobacin del Manual de Usuario.
Revisin y Aprobacin del Manual de Instalacin del Sistema
Instalacin (Aceptacin y entrega)

Revisin y aprobacin el software y su documentacin.
Revisin y aprobacin de cada cambio producido durante la mantencin en su
especificacin, diseo, implementacin y prueba.
Revisin y aprobacin de la documentacin asociada a los cambios.
28
Revisin y aprobacin de la nueva versin del software y de su documentacin.


Plan de Calidad para Producto de Software 1 (Corta)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Plan de Calidad para Producto de Software 1 (Corta)

Uploaded by

Copyright:

Available Formats

PLAN DE CALIDAD PARA PRODUCTO DE SOFTWARE

GONZALO TOMS PREZ LARA

MEMORIA PARA OPTAR AL TITULO DE

7.1.4 Actividades de auditora..................................................................................................................66

Plan de Calidad Aplicacin X-Pro-L

1.3 Identificacin de Productos de Trabajo

Documentacin para controlar y monitorear el Proyecto (Ver

Documentacin sobre las posibles situaciones en las que el

Repositorio central que contiene la informacin actualizada

Especificacin del sistema (Solucin Propuesta)

Documentacin sobre la situacin actual, sus problemas y

Documentacin que especifica en trminos no tcnicos, que

Documentacin que describe las pruebas que sern llevadas

Especificacin de Diseo de Sistema

Documentacin que define la Arquitectura de la Solucin e

Especificacin de Diseo de Soporte

Documentacin detallada de los requerimientos de soporte

Plan de aseguramiento de calidad SQA

Documentacin que define todas las actividades de

Plan de gestin de la configuracin SCM

Documentacin que describe la metodologa que se seguir

Informe de pruebas (testing)

Documentacin que describe los resultados de las pruebas,

Documentacin que describe el comportamiento del sistema

Manual de instalacin del sistema

Documentacin de la especificacin de los componentes de

Subproductos que evaluar el cliente.

Diseo de imgenes y escenarios

Elementos grficos que forman parte de la aplicacin

Plan de Calidad Aplicacin X-Pro-L

1.4 Descripcin del Sistema

Pedir asesora a personas con mayor experiencia.

Aprender por el mtodo de prueba y error.

Utilizar libros y/o tutoriales relativos al tema.

Realizar un curso pagado.

Plan de Calidad Aplicacin X-Pro-L

Linux v/s Windows

Muy adaptable a diversas plataformas Intel, Alfa, Sparc,

Adaptabilidad slo en plataformas Intel o clnicas.

Gratis (libre distribucin).

Costo elevado (producto comercial).

Un nico fabricante y distribuidor.

Lento aprendizaje, difcil instalacin

Ms rpido e intuitivo, instalacin automatizada.

Muchsimo soporte en Internet y guas. Comunicacin fcil

Poco soporte real. S en libros.

No ha llegado al pblico en general, aunque aumenta da a

Es el sistema operativo que ms ha contribuido a la

Es utilizado por usuarios que buscan estabilidad y fiabilidad

Plan de Calidad Aplicacin X-Pro-L

Estabilidad, fiabilidad y robustez para la realizacin de diversas tareas.

Que, si lo desea, y en la mayora de los casos, puede contactar directamente al autor de la

Si se presenta un "error" o algo se "cae", no es necesario reinicializar todo el sistema, bastar

Hoy en da se estima que existen ms de 30 millones de usuarios de Linux en todo el mundo,

Plan de Calidad Aplicacin X-Pro-L

La aplicacin permitir la poblacin de la Base de Datos, y navegar a travs de los contenidos. El

1.5 Glosario de Trminos

Aseguramiento de la Calidad del Software (SQA) El propsito de SQA es entregar a la

Auditora Evaluacin independiente de los productos de trabajo y de un conjunto de

Gestin de la Configuracin del Software (SCM) El propsito de SCM es establecer y

Revisin Metodologa definida, estructurada y disciplinada para la deteccin e identificacin

Prueba (Testing) Actividad que evala los atributos y la capacidad de un programa o

Software Quality Assurance, Aseguramiento de la Calidad del Software