Plan de Calidad para Producto de Software Jheral Andrea

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...........................................................................................................................................6
1.1 Propósito...................................................................................................................................................6
1.2 Alcance......................................................................................................................................................6
1.3 Identificación de Productos de Trabajo....................................................................................................7
1.4 Descripción del Sistema............................................................................................................................8
1.4.1 Descripción de la situación actual.....................................................................................................8
1.4.2 Descripción del sistema...................................................................................................................10
1.5 Glosario de Términos.............................................................................................................................11
1.6 Acrónimos...............................................................................................................................................11
2. REQUERIMIENTOS...................................................................................................................................12
2.1 Aplicación de las Métricas 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 Definición 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 revisión (hitos).................................................................................................................28
4. GESTION......................................................................................................................................................29
4.1 Organización..........................................................................................................................................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 Identificación de riesgos..................................................................................................................36
4.5.2 Clasificación....................................................................................................................................36
4.5.3 Estimación de los riesgos.................................................................................................................37
4.5.4 Control de riesgos............................................................................................................................39
5. HERRAMIENTAS, TÉCNICAS Y METODOLOGÍAS..........................................................................44
5.1 Aplicación de métodos técnicos formales...............................................................................................44
5.2 Revisiones e inspecciones.......................................................................................................................44
5.3 Registro y generación 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 Planificación...........................................................................................................................................62
6.2 Especificación.........................................................................................................................................63
6.3 Ejecución................................................................................................................................................63
6.4 Análisis de resultados.............................................................................................................................64
6.4.1 Completación...................................................................................................................................64
7. INFORME DE PROBLEMAS Y ACCIONES CORRECTIVAS...........................................................65
7.1 Informe de Auditoría...............................................................................................................................65
7.1.1 Identificación de la auditoría...........................................................................................................65
7.1.2 Objetos de auditoría.........................................................................................................................65
7.1.3 Bases para la evaluación.................................................................................................................65
7.1.4 Actividades de auditoría..................................................................................................................66
7.1.5 Anomalías.........................................................................................................................................66
7.2 Informe de discrepancias........................................................................................................................69
7.2.1 Identificación del proyecto...............................................................................................................69
7.2.2 Descripción del problema................................................................................................................69
7.2.3 Resolución........................................................................................................................................70
7.3 Informe de Actividades de SQA..............................................................................................................72
7.3.1 Identificación del proyecto...............................................................................................................72
7.3.2 Identificación del producto / proceso evaluado...............................................................................72
8. CONCLUSIONES.......................................................................................................................................74
9. BIBLIOGRAFÍA.........................................................................................................................................78
10. ANEXOS....................................................................................................................................................79
10.1 Plan de Proyecto...................................................................................................................................79
10.2 Plan de Riesgos.....................................................................................................................................96
10.3 Especificación de Requerimientos........................................................................................................96
10.4 Especificación del Sistema (Solución Propuesta)...............................................................................102
10.5 Especificación Funcional....................................................................................................................109
10.6 Plan de Pruebas..................................................................................................................................116
10.7 Especificación de Diseño de Sistema..................................................................................................126
10.8 Especificación de diseño de soporte...................................................................................................131
10.9 Plan de Gestión de la Configuración SCM.........................................................................................135
10.10 Informe de Pruebas (Testing)............................................................................................................140
10.11 Manual de Usuario............................................................................................................................141
Introducción
1. INTRODUCCIÓN
Para la empresa de buses Autoboy S.A se realiza un plan de calidad del software con el fin de
dar confiabilidad a este proyecto. La calidad se convierte en un importante punto diferenciador,
además de aumentar la satisfacción general del cliente, disminuir costos y optimizar los
recursos.
1.1 Propósito
El propósito de este documento es definir el plan de calidad del proyecto de buses Autoboy S.A,
así como proporcionar herramientas técnicas y metodologías para la realización de las actividades
propuestas para satisfacer la necesidad del cliente.
1.2 Alcance
Este documento establece las actividades realizadas para asegurar la calidad del proyecto de
buses Autoboy S.A. El alcance de este plan de aseguramiento de la calidad es verificar que todo el
software y la documentación que debe ser entregada cumplan con los requisitos técnicos y
necesidades del cliente, se debe seguir un procedimiento para la examinación del documento y
determinar que se cumplen todos los requisitos y que el rendimiento del sistema sea óptimo.
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.
Producto de Trabajo Descripción
Plan de Proyecto El sistema contara con el desarrollo plantillas de

especificación de caso de uso, plantillas de especificación de
guiones de pruebas, caso de uso, diagramas de secuencia,
diagramas de actividad, diagramas de comunicación.,
desarrollo diagramas de máquina de estado, diagramas de
panorama de la iteración.
Plan de Riesgos El sistema contara con firewalls aplicativos a páginas web,

para trabajar en el sistema de una forma más segura
protegiendo a este de hackers o software malicioso que
quiera ingresar al equipo a través de la red, y así no poner
en riesgo la integridad de la información almacenada en la
base de datos.
Especificación de Requerimientos Dar a conocer algunos conceptos básicos para una mejor
interpretación de lo que va a tratar el sistema, donde se
guiará al lector por tres fases que contendrá dicho
documento sobre el sistema de contabilidad diaria para los
buses de la empresa Autoboy S.A.
Especificación del sistema (Solución Propuesta) El sistema da Información Contable de Autobuses (SICA),
donde se refleja las distintas temáticas y estructuras bajo las
cuales se desarrolla el software.
Especificación Funcional El sistema de contabilidad web el cual permitirá administrar

la contabilidad de cada uno de los vehículos de la empresa.
Este será utilizado por personal encargado de la contabilidad
en la empresa Autoboy S.A
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 El sistema de contabilidad se ofrecerá exclusivamente en

interfaz WEB, lo cual facilitará la utilización y la interacción
de este con cada uno de los usuarios, el diseño se
implementará teniendo en cuenta los colores institucionales
de la empresa.
Solo podrá ser ejecutado desde Windows.
Especificación de Diseño de Soporte El diseño y la implementación del sistema debe ser sencilla,
acorde para que los usuarios que interactúen con ella, se les
facilite su manejo, independientemente del medio con el cual
se desarrolle.
Plan de aseguramiento de calidad SQA Documentación que define todas las actividades de
aseguramiento de calidad que se harán durante el Proyecto.
Plan de gestión de la configuración SCM 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).
Informe de pruebas (testing) 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

Introducción
1.4 Descripción del Sistema

1.4.1 Descripción de la situación actual
Un software de contabilidad diaria para la empresa de Buses Autoboy S.A de la ciudad de Tunja.
Este software permitirá al usuario verificar toda la información relacionada con los buses,
conductores, las rutas, las planillas de rotación y a la vez generar una liquidación mostrando los
ingresos y egresos que tiene un bus.
El sistema tendrá grandes beneficios para la empresa ya que va a permitir llevar la contabilidad sin
la necesidad de estar utilizando papel y lápiz, y con ello los propietarios sabrán con exactitud la
contabilidad de su vehículo mea a mes.
El sistema de contabilidad es un producto que está diseñado para trabajar en entorno web, lo que
permitirá su utilización de forma rápida y eficaz, y a la vez conectado a una base de datos donde
se encontrará toda la información y así obtener una mejor respuesta.
Este sistema será un software independiente de los demás sistemas que maneja la empresa, ya
que está actualmente tiene una página web, pero esta es publica para cualquier usuario por ende
no se podrá incorporar el software a esta ya que se restringen la entrada a ciertos usuarios.
El software de contabilidad diaria para Buses consistirá o contará con las siguientes
funcionalidades:
El sistema permitirá crear, consultar, modificar e inactivar:

 Buses.
 Conductores.
 Rutas.
 Planillas.
 Ingresos.
 Egresos.
 Buses.
1.4.2 Descripción del sistema
El sistema de buses un sistema dedicado a la administración y seguimiento de requerimientos para

el proyecto de software. Con el sistema de buses de la empresa Autoboy S.A se debe lograr el
mejoramiento de la cálida y la eficacia en el control de requisitos y dar un mejor aseguramiento a
los requerimientos.
El sistema de contabilidad es un producto que está diseñado para trabajar en entorno web, lo que
permitirá su utilización de forma rápida y eficaz, y a la vez conectado a una base de datos donde
se encontrará toda la información y así obtener una mejor respuesta.
Este sistema será un software independiente de los demás sistemas que maneja la empresa, ya
que está actualmente tiene una página web, pero esta es publica para cualquier usuario por ende
no se podrá incorporar el software a esta ya que se restringen la entrada a ciertos usuarios.
1.5 Glosario de Términos
Ieee: Instituto de Ingenieros Eléctricos y Electrónicos.
Software contable: Se llama software contable a los programas de contabilidad o paquetes

contables, destinados a sistematizar y simplificar las tareas de contabilidad.

Plataformas Informáticas: Una plataforma es, por ejemplo, un sistema operativo, un gran
software que sirve como base para ejecutar determinadas aplicaciones compatibles con este.
Base de datos: formato estructurado para organizar y mantener informaciones que pueden ser
fácilmente recuperadas.
Botón/Icono: Símbolo gráfico que representa una acción que el usuario puede realizar de forma
interactiva. (En los primeros años del desarrollo del hipertexto se denominaban botones a los
iconos)
Hardware (maquinaria): componentes físicos de una computadora o de una red, a diferencia de

los programas (software) o elementos lógicos que los hacen funcionar.
Interfaz (Interface): zona de contacto o conexión entre dos componentes de hardware; entre dos
aplicaciones, o entre un usuario y una aplicación. Apariencia externa de una aplicación informática.
Interfaz Gráfica de Usuario (GUI): componente de una aplicación informática que el usuario
visualiza y a través de la cual opera con ella. Está formada por ventanas, botones, menús e iconos,
entre otros elementos.
Interfaz de Usuario Basada en Web (WUI): Interfaz gráfica de usuario con la apariencia típica de
una página web.
Interfaz para Programas de Aplicación (API): conjunto de convenciones de programación que

definen cómo se solicita un servicio desde un programa.
Internet Explorer (IE): programa navegador o visualizador del WWW desarrollado por Microsoft.
ISO: International Organization for Standardization. Organización Internacional para la
Estandarización.
Página web: documento creado en formato HTML (Hypertext Markup Language) que es parte de
un grupo de documentos hipertexto o recursos disponibles en la World Wide Web.
WWW o la WEB o World Wide Web: medio más popular de comunicación en Internet. Sistema
de distribución y recuperación de información hipermedia (hipertexto+multimedia) almacenada en
los diferentes nodos de Internet.
Planilla: formulario con espacios en blanco para rellenar, en los que se dan informes, se hacen
peticiones o declaraciones.
Ingresos: son las entradas económicas que recibe una persona, una familia, una empresa, una
organización, un gobierno. El tipo de ingreso que recibe una persona o una empresa u
organización depende del tipo de actividad que realice (un trabajo, un negocio, una venta, etc.)
Egresos: denomina gasto o egreso a la anotación o partida contable que disminuye el beneficio o
aumenta la pérdida de una sociedad o persona física.
Aseguramiento de la Calidad del Software (SQA): 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: 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): 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.
1.6 Acrónimos
Acrónimo Significado
Ieee Instituto de Ingenieros Eléctricos y Electrónicos.

GUI Interfaz Gráfica de Usuario
WUI Interfaz de Usuario Basada en Web
API Interfaz para Programas de Aplicación
WWW World Wide Web
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

Requerimientos
2. REQUERIMIENTOS
 Fiabilidad El software contara con herramientas antibloqueo para evitar que aparezcan o se
presenten posibles congestiones durante la ejecución de alguna funcionalidad del sistema, y
a la vez se harán diagnósticos trimestralmente para ver los fallos que este presentando.
 Disponibilidad: El software de contabilidad estará continuamente disponible las 24 horas del

día, los 7 días de la semana para cada uno de los usuarios autorizados, no estará disponible
solo si la organización desea apagar el servidor.
 Mantenibilidad: El sistema contara con un manual especificando cada una de las

características y funcionalidades del sistema, esto para el caso en que se presente una falla
de valor mínimo donde el usuario con la ayuda de este pueda resolverla en su momento. Al
sistema se le hará un mantenimiento trimestralmente esto lo realizará personal especializado
en el área de informática, esto con el fin de corregir errores presentes y a la vez realizar
nuevas actualizaciones que requiera el sistema.
 Portabilidad: El sistema será desarrollado con herramientas gratuitas y de soporte completo

como java y con una base de datos SQLite, todo por los bajos requerimientos y excelentes
recursos que proveen. El sistema en un principio estará desarrollado única y exclusivamente
para Windows, de lo contrario no podrá tener acceso a dicho software.
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, colores adecuados, rápidos
y eficientes para la selección e ingreso de datos al sistema.
Objetivos
 Establecer un programa de calidad para el proyecto.

 Identificar las actividades de requerimientos del proyecto de la empresa de buses Autoboy
S.A.
Criterios de Aceptación
 Revisar y aprobar un plan de calidad para el software.

 Revisar y aprobar el plan de calidad del proyecto de la empresa de buses Autoboy S.A.
 Auditar y reportar las funciones del sistema.
 Identificar y asegurarse que los factores de calidad se implementen en el software.
 La rapidez de respuesta de la aplicación, ante los datos que se seleccionan e ingresan no debe
superar los 2 segundos.

Requerimientos
 Portabilidad
Para la utilización de la aplicación, debe considerarse el correcto funcionamiento del sistema 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 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
 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.
 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.
 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.

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.
 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.
 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.

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 Incremento 1

de Información
Entrega de 1°
Análisis Diseño Código Prueba
Incremento
Incremento 2
Entrega de 2°
Incremento
Incremento 3
Entrega de 3°
Incremento
Incremento 4
Entrega de 4°
Incremento
Figura 1: Modelo Incremental

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

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 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.

 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.


 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?
3.2.2 Atributos de calidad (evaluados por SQA) por actividades del proceso de desarrollo
Producto Planificación
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
Tabla 5: Especificación de Requerimientos
Tabla 6: Análisis

Producto Diseño
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
Producto Implementación
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
Producto Instalación (Aceptación y Entrega)

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)
Producto Operación (Mantención)

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)

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 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,
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.
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%.
Eficiencia
Encargado (s) revisión final Cliente, Jefe de Proyectos
Tabla 14: Especificación de Sistema (Solución Propuesta)

Producto Especificación Funcional

Objetivo Cuantificable Se requiere participación del cliente.
Se requiere participación del Jefe de Proyectos.
Debe ser suficientemente claro, es decir, explicado de
manera No técnica para el entendimiento del cliente en un
100%.
Eficiencia
Encargado (s) revisión final Jefe de Proyecto, Cliente
Tabla 15: Especificación Funcional
Producto Plan de Pruebas

Se requiere participación del Arquitecto de Sistemas.
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,
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

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%
Eficiencia
Tabla 17: Especificación de Diseño de Sistema
Producto Especificación de Diseño de Soporte

El Documento no debe superar las 100 hojas.
Eficiencia
Tabla 18: Especificación de Diseño de Soporte

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.
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
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
Eficiencia
Encargado (s) revisión final Desarrollador, Jefe de Proyectos
Tabla 22: Manual de Instalación del Sistema
fscommand("allowscale", false);
fscommand("allowscale", false);
//our map is 2-dimensional array
myMap1 = [[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],

[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]];
//declare game object that holds info
game = {tileW:30, tileH:30};
//walkable tile
game.Tile0 = function () { };
game.Tile0.prototype.walkable = true;
game.Tile0.prototype.frame = 1;
//wall tile
game.Tile1 = function () { };
game.Tile1.prototype.walkable = false;
game.Tile1.prototype.frame = 2;
//declare char object, xtile and ytile are tile where chars center is
char = {xtile:2, ytile:1, speed:2, moving:false};
//building the world
function buildMap(map)
{
//attach mouse cursor
_root.attachMovie("mouse", "mouse", 2);
//attach empty mc to hold all the tiles and char
_root.attachMovie("empty", "tiles", 1);
//declare clip in the game object
game.clip = _root.tiles;
//get map dimensions
var mapWidth = map[0].length;
var mapHeight = map.length;
//loop to place tiles on stage
for (var i = 0; i<mapHeight; ++i)
{
for (var j = 0; j<mapWidth; ++j)
{
//name of new tile
var name = "t_"+i+"_"+j;
//make new tile object in the game
game[name] = new game["Tile"+map[i][j]]();
//attach tile mc and place it
game.clip.attachMovie("tile", name, i*100+j*2);
game.clip[name]._x = (j*game.tileW);
game.clip[name]._y = (i*game.tileH);
//send tile mc to correct frame
game.clip[name].gotoAndStop(game[name].frame);
}
}
//add the character mc
game.clip.attachMovie("char", "char", 10000);
//declare clip in the game object
char.clip = game.clip.char;
//calculate starting position
char.x = (char.xtile*game.tileW)+game.tileW/2;
char.y = (char.ytile*game.tileW)+game.tileW/2;
//place char mc
char.clip._x = char.x;
char.clip._y = char.y;
char.clip.gotoAndStop(char.frame);
}
function moveChar(ob)
{
//is char in the center of tile
if ((ob.x-game.tileW/2)%game.tileW == 0 and (ob.y-game.tileH/2)%game.tileH == 0)
{
//calculate the tile where chars center is
ob.xtile = Math.floor(ob.x/game.tileW);
ob.ytile = Math.floor(ob.y/game.tileH);
//choose direction
//right
if (game["t_"+ob.ytile+"_"+(ob.xtile+1)].walkable and game.targetx>ob.xtile)
{
ob.dirx = 1;
ob.diry = 0;
//left
}
else if (game["t_"+ob.ytile+"_"+(ob.xtile-1)].walkable and game.targetx<ob.xtile)
{
ob.dirx = -1;
ob.diry = 0;
//up
}
else if (game["t_"+(ob.ytile+1)+"_"+ob.xtile].walkable and game.targety>ob.ytile)
{
ob.dirx = 0;
ob.diry = 1;
//down
}
else if (game["t_"+(ob.ytile-1)+"_"+ob.xtile].walkable and game.targety<ob.ytile)
{
ob.dirx = 0;
ob.diry = -1;
//none
}
else
{
ob.moving = false;
return;
}
}
//move
ob.y += ob.speed*ob.diry;
ob.x += ob.speed*ob.dirx;
//update char position
ob.clip._x = ob.x;
ob.clip._y = ob.y;
//face the direction
ob.clip.gotoAndStop(ob.dirx+ob.diry*2+3);
}
function getTarget()
{
//must click on walkable tile
if (game["t_"+game.ymouse+"_"+game.xmouse].walkable)
{
//update target tile
game.targetx = game.xmouse;
game.targety = game.ymouse;
//get moving
char.moving = true;
}
}
function work()
{
//find on which tile mouse is
game.xmouse = Math.round((_root._xmouse-game.tileW/2)/game.tileW);
game.ymouse = Math.round((_root._ymouse-game.tileH/2)/game.tileH);
//place mouse mc
_root.mouse._x = game.xmouse*game.tileW;
_root.mouse._y = game.ymouse*game.tileH;
var ob = char;
//move char
if (!ob.moving)
{
//stop walk animation
ob.clip.char.gotoAndStop(1);
}
else
{
moveChar(ob);
//walk animation
ob.clip.char.play();
}
}
//make the map
buildMap(_root["myMap1"]);
stop();
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.

 Análisis
 Revisión y Aprobación de la Especificación del Sistema (Solución Propuesta).

 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
 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
 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.

 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.

Plan de Calidad para Producto de Software Jheral Andrea

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Plan de Calidad para Producto de Software Jheral Andrea

Încărcat de

Drepturi de autor:

Formate disponibile

PLAN DE CALIDAD PARA PRODUCTO DE SOFTWARE

GONZALO TOMÁS PÉREZ LARA

MEMORIA PARA OPTAR AL TITULO DE

Plan de Calidad Aplicación X-Pro-L 6

1.3 Identificación de Productos de Trabajo

Producto de Trabajo Descripción

Plan de Proyecto El sistema contara con el desarrollo plantillas de

Plan de Riesgos El sistema contara con firewalls aplicativos a páginas web,

Especificación Funcional El sistema de contabilidad web el cual permitirá administrar

Especificación de Diseño de Sistema El sistema de contabilidad se ofrecerá exclusivamente en

Manual de usuario Documentación que describe el comportamiento del sistema

Manual de instalación del sistema Documentación de la especificación de los componentes de

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

1.4 Descripción del Sistema

El sistema permitirá crear, consultar, modificar e inactivar:

1.4.2 Descripción del sistema

El sistema de buses un sistema dedicado a la administración y seguimiento de requerimientos para

1.5 Glosario de Términos

Ieee: Instituto de Ingenieros Eléctricos y Electrónicos.

Software contable: Se llama software contable a los programas de contabilidad o paquetes

Plan de Calidad Aplicación X-Pro-L 8

Hardware (maquinaria): componentes físicos de una computadora o de una red, a diferencia de

Interfaz para Programas de Aplicación (API): conjunto de convenciones de programación que

Aseguramiento de la Calidad del Software (SQA): Entregar a la administración una visibilidad

Auditoría: Un conjunto de procesos de software para asegurar la adherencia con las

Gestión de la Configuración del Software (SCM): mantener la integridad de los productos a

Ieee Instituto de Ingenieros Eléctricos y Electrónicos.

WUI Interfaz de Usuario Basada en Web

API Interfaz para Programas de Aplicación

WWW World Wide Web

SQA Software Quality Assurance, Aseguramiento de la Calidad del Software

SCM Software Configuration Management, Gestión de Configuración del

WBS Work Breakdown Structure

Tabla 3: Listado de Acrónimos

 Disponibilidad: El software de contabilidad estará continuamente disponible las 24 horas del

 Mantenibilidad: El sistema contara con un manual especificando cada una de las

 Portabilidad: El sistema será desarrollado con herramientas gratuitas y de soporte completo

2.1 Aplicación de las Métricas definidas para el Producto X-Pro-L

 Establecer un programa de calidad para el proyecto.

 Revisar y aprobar un plan de calidad para el software.

Plan de Calidad Aplicación X-Pro-L 11

Para la utilización de la aplicación, debe considerarse el correcto funcionamiento del sistema y el

 Procesador Pentium III, 733 Mhz o similar

Rapidez de respuesta a las consultas realizadas a la base de datos y manejo de grandes

 La aplicación debe entregar una respuesta rápida a la consulta realizada.

 La aplicación debe mostrar un número adecuado de figuras dinámicas y estáticas, evitando la

 No se deben desplegar más de 3 figuras dinámicas y 5 figuras dinámicas en forma simultánea.

Plan de Calidad Aplicación X-Pro-L 12

 La aplicación debe funcionar correctamente sin la necesidad de modificaciones posteriores al

 Los datos no deben ser modificados por terceros.

Plan de Calidad Aplicación X-Pro-L 13

Ingeniería Sistemas Incremento 1

Figura 1: Modelo Incremental

Plan de Calidad Aplicación X-Pro-L 14

3.1 Actividades del proceso de desarrollo

Planificación / definición de recursos, tiempo y otras informaciones relacionadas con el proyecto

 Especificación de requerimientos (Definición)

 Las metas de la organización, sus objetivos y factores críticos de éxito.

 La adherencia del Análisis y su documentación a los estándares definidos en el Plan de