PLAN DE CALIDAD PARA PRODUCTO DE SOFTWARE 1 (Corta)

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 Libertadores 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 Libertadores,
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 Libertadores. 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 Documentación para controlar y monitorear el Proyecto (Ver

anexo Plan de Proyecto).
Plan de Riesgos Documentación sobre las posibles situaciones en las que el

Proyecto puede verse afectado (ver página 36)
Especificación de Requerimientos Repositorio central que contiene la información actualizada

de cada uno de los requerimientos detectados.
Descripción de los requerimientos del cliente que deben ser
satisfechos por el equipo de desarrollo (ver anexo
Especificación de Requerimientos)
Especificación del sistema (Solución Propuesta) Documentación sobre la situación actual, sus problemas y
las mejoras que introduce el desarrollo de la solución que se
propone (ver anexo Especificación del Sistema).
Especificación Funcional Documentación que especifica en términos no técnicos, que

es lo que la solución hace que se propone (ver anexo
Especificación Funcional).
Plan de pruebas Documentación que describe las pruebas que serán llevadas
a cabo para demostrar al cliente que la solución satisface los
requerimientos definidos. (ver anexo Plan de Pruebas).
Especificación de Diseño de Sistema Documentación que define la Arquitectura de la Solución e

identifica todos los componentes del sistema. (ver anexo
Especificación de Diseño de Sistema).
Especificación de Diseño de Soporte Documentación detallada de los requerimientos de soporte

desde la fase de Implementación a la de Operación (ver
anexo Especificación de Diseño de Soporte).
Plan de aseguramiento de calidad SQA 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
La tendencia desde hace un par de años es que en los colegios y en las familias existan
computadores, debido a ello los jóvenes se están habituando a usarlos tempranamente.
La mayoría de estos computadores, funcionan principalmente con el sistema operativo Windows,
debido en gran parte al posicionamiento de éste en el mercado y al desconocimiento de la
existencia de Linux y de sus ventajas.
Actualmente, cuando una persona desea aprender a ocupar Linux, utiliza cualquiera de las
siguientes posibilidades:
 Pedir asesoría a personas con mayor experiencia.

 Aprender por el método de prueba y error.
 Utilizar libros y/o tutoriales relativos al tema.
 Realizar un curso pagado.
Las personas actúan con recelo hacia lo nuevo y lo desconocido, esto aumenta debido a que los
métodos mencionados anteriormente no son suficientes para entregar el necesario conocimiento y
la confianza para abordar los nuevos retos, en este caso, la utilización de un nuevo sistema
operativo.
Principalmente, el universo afectado por dicho problema son las personas que comienzan a utilizar
Linux, debido a que no disponen de herramientas didácticas que faciliten su comprensión y su
posterior utilización. Es importante el aprendizaje de este sistema operativo, ya que se está
masificando enormemente a nivel mundial debido al auge de nuevas tecnologías.
Linux es conveniente como estación de trabajo, claro, si el usuario final tiene la disposición y
voluntad de aprender, por solo citar algunos ejemplos, todos los nuevos procedimientos necesarios
para manejar sus ficheros y archivos, montar y desmontar unidades de disquete y CDROM,
aprender a utilizar una nueva aplicación de hoja de cálculo, procesador de textos, base de datos,
es decir, el usuario debe aprender a utilizar un sistema que trabaja distinto y se maneja distinto en
muchos sentidos.
El usuario no-técnico, en la mayoría de los casos no dispone de tiempo para leer, ni tampoco tiene
interés por los manuales tradicionales que le explican cómo y que se debe hacer para realizar una
determinada tarea. El usuario final necesita que todo se resuelva con la menor complejidad posible.
Mientras Linux no posea un entorno intuitivo y que las aplicaciones requieran poca experiencia y
conocimientos técnicos por parte del usuario, seguirá siendo obligatoria una capacitación
adecuada, considerando que va a enfrentarse a un nuevo ambiente, con distintos sistemas de
archivos y nuevos procedimientos. Esta capacitación no se puede obtener de un foro de discusión
o una lista de soporte. Estos son sólo herramientas de ayuda, no la solución, ya que difícilmente
los usuarios avanzados dispondrán del tiempo necesario para dedicar varias horas al día en
elaborar nuevos manuales o cátedras de enseñanza contenidos en un mensaje de correo
electrónico. En lo que refiere a las empresas, éstas deben capacitar adecuadamente a su personal
antes de realizar cualquier implementación, porque de otra forma se obtendrán solamente fracasos
y publicidad negativa para Linux y el software libre en general.
Eventualmente los actuales entornos gráficos alcanzarán un nivel de desarrollo que permitirá un
uso tan sencillo de Linux como lo es actualmente con Windows, sin embargo, salvo que el usuario
comprenda como funciona el sistema de archivos de Linux, esto tomará al menos un par de años
más antes de obtener un producto con tal característica.

Introducción
La comprensión de las necesidades de los usuarios finales viene de un sólo lugar: de los mismos
usuarios finales. Lo que ellos hacen en una computadora usualmente se limita a unas cuantas
actividades, usualmente con patrones muy definidos, situación que regularmente cubren productos
similares de otras marcas y plataformas. Las herramientas de trabajo que provee Linux son muy
prácticas y efectivas, pero en muchos casos su imagen es muy diferente al estándar que fijó
Microsoft para las aplicaciones bajo Windows, lo que con el tiempo ha hecho que el novato se
sienta fuera de balance en Linux y opte por buscar una alternativa que se asemeje más a lo que ya
conoce[GP-00].
Se mencionará a continuación, algunas de las diferencias principales entre los sistemas operativos
Linux y Windows [GP-00].
Linux v/s Windows
Linux Windows
Muy Estable. Inestable

Fiabilidad probada No totalmente confiable
Muy adaptable a diversas plataformas Intel, Alfa, Sparc, Adaptabilidad sólo en plataformas Intel o clónicas.
Macintosh.
Gratis (libre distribución). Costo elevado (producto comercial).
Administración complicada (interacción con el usuario), salvo Administración más fácil. Ratón e Iconos muy popularizados
en entornos gráficos tipo KDE y el GNOME
Muchas variedades y distribuciones, que muchas veces Un único fabricante y distribuidor.
difieren bastante entre unas y otras.
sistema abierto. sistema cerrado
Existe poco software disponible, sólo aplicaciones ofimáticas y Multitud de aplicaciones de terceros, sobre todo con fines
de otro tipo GNU. comerciales, apoyo de la industria. Los fabricantes de
Hardware se preocupan de suministrar el driver adecuado a
Windows.
Fuentes de los programas disponibles. Libertad de No se dispone de ellas.
distribución y mejora
Lento aprendizaje, difícil instalación Más rápido e intuitivo, instalación automatizada.
Muchísimo soporte en Internet y guías. Comunicación fácil Poco soporte real. Sí en libros.
con otros usuarios y con los mismos desarrolladores.
No ha llegado al público en general, aunque aumenta día a Es el sistema operativo que más ha contribuido a la
día. popularización de los PC y de la Informática en general.
El 85% de los computadores del planeta.
Es utilizado por usuarios que buscan estabilidad y fiabilidad Utilizado por público en general.
(nivel medio – avanzado). Se necesita algo de experiencia y
algunos conocimientos básicos para configurarlo
adecuadamente, sobre todo lo relacionado con multimedia y
redes.
Tabla 2: Linux v/s Windows

Introducción
Se destaca que ninguno de los sistemas operativos que existen hoy en día está exento de
pequeños detalles. La diferencia de Linux sobre otros sistemas operativos radica principalmente
en:
 Que los errores que pudiesen existir en algún componente de Linux no son tan frecuentes
como los de los "otros" sistemas operativos.
 Estabilidad, fiabilidad y robustez para la realización de diversas tareas.
 Que cuando se descubre un error, éste siempre se hace público, e incluso, en algunos casos,
se puede obtener el parche correspondiente el mismo día.
 Que, si lo desea, y en la mayoría de los casos, puede contactar directamente al autor de la
aplicación, controlador, módulo o programa, quien seguramente le dará respuesta a sus dudas
e inquietudes.
 Los métodos de seguridad de Linux son mejores que los de los "otros" sistemas operativos, por
lo que es menos probable que sea víctima de un "Hacker" o que se filtre información fuera de
su PC sin su autorización. En Linux, el acceso a los directorios y los archivos, así como la
capacidad de borrar o modificar estos, depende de los permisos de usuario que estos tengan.
 Si se presenta un "error" o algo se "cae", no es necesario reinicializar todo el sistema, bastará
con "matar" y reiniciar la aplicación, programa o servicio. El usuario no perderá tiempo y
productividad. En Linux los servicios como Sendmail, Servidores Web, demonios en general,
aplicaciones, se desempeñan de forma independiente.
Hoy en día se estima que existen más de 30 millones de usuarios de Linux en todo el mundo,
comparados con los más de 450 millones de usuarios de todas las versiones de Windows. Sin
embargo, esta desventaja numérica se acorta cada día más puesto que los usuarios de Linux se
duplican en número cada año, debido principalmente a las características planteadas
anteriormente.
Una característica muy significativa de Linux es su robustez, estabilidad, y distribución gratuita.
Pero, ¿por qué no lidera aún el mercado doméstico?, por que es relativamente nuevo (nació a
principios de los ‘90) y sólo en el último tiempo se ha orientado hacia el público en general, ya que
en sus inicios estaba destinado a usuarios especializados.
1.4.2 Descripción del sistema
El sistema de buses de la empresa libertadores es un sistema dedicado a la administración y

seguimiento de requerimientos para el proyecto de software. Con el sistema de buses de la
empresa Libertadores 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.
1.5 Glosario de Términos
Para lograr un mejor entendimiento de los términos técnicos que se utilizan en el presente Plan de
SQA, se mencionan a continuación los significados de los siguientes términos [WEB-01]:
 Aseguramiento de la Calidad del Software (SQA)  El propósito de SQA es entregar a la

administración una visibilidad adecuada del proceso utilizado y los productos construidos
mediante acciones planificadas y sistemáticas que aseguren la calidad de dichos procesos y
productos.
 Auditoría  Evaluación independiente de los productos de trabajo y de un conjunto de
procesos de software para asegurar la adherencia con las especificaciones, los estándares,
procedimientos y otros acuerdos.

 Gestión de la Configuración del Software (SCM) El propósito de SCM es establecer y
mantener la integridad de los productos a través de todo el ciclo de vida del software, para así
proveer un adecuado control de los cambios en los diversos ítems de configuración.
 Revisión  Metodología definida, estructurada y disciplinada para la detección e identificación
de defectos en los productos de trabajo durante el ciclo de vida del software.
 Prueba (Testing)  Actividad que evalúa los atributos y la capacidad de un programa o
sistema para determinar si se cumple con los resultados definidos.
1.6 Acrónimos
Acrónimo Significado
SQA Software Quality Assurance, Aseguramiento de la Calidad del Software
SCM Software Configuration Management, Gestión de Configuración del Software
WBS Work Breakdown Structure
Tabla 3: Listado de Acrónimos

Requerimientos
2. REQUERIMIENTOS
Un requerimiento es un aspecto del producto requerido o deseado por el cliente. Los Requisitos
Funcionales cubren las necesidades y operaciones para proporcionar un sistema que operará de
acuerdo a las necesidades del cliente.
 Operacional: Ambiente en que el usuario operará el producto.

 Mantenibilidad: Es el tiempo esperado y el permitido para el mantenimiento o la realización
de cambios.
 Seguridad: Requerimientos para permitir el acceso, restringir mal uso, hechos anormales,
entre otros.
 Interfaz: Se basa en lo referente a la calidad de la Interfaz usuaria
 Portabilidad: Capacidad de la aplicación para funcionar correctamente en diferentes
configuraciones, ya sean de software o hardware. Performance: Requerimientos reales de la
performance, velocidad, precisión, disponibilidad, nivel de servicio, volúmenes de datos, entre
otros.
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 libertadores.
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 Libertadores.
 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 1 (Corta)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PLAN DE CALIDAD PARA PRODUCTO DE SOFTWARE 1 (Corta)

Загружено:

Авторское право:

Доступные форматы

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 Documentación para controlar y monitorear el Proyecto (Ver

Plan de Riesgos Documentación sobre las posibles situaciones en las que el

Especificación de Requerimientos Repositorio central que contiene la información actualizada

Especificación Funcional Documentación que especifica en términos no técnicos, que

Especificación de Diseño de Sistema Documentación que define la Arquitectura de la Solución e

Especificación de Diseño de Soporte Documentación detallada de los requerimientos de soporte

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

1.4.1 Descripción de la situación actual

 Pedir asesoría a personas con mayor experiencia.

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

Linux v/s Windows

Muy Estable. Inestable

Tabla 2: Linux v/s Windows

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

1.4.2 Descripción del sistema

El sistema de buses de la empresa libertadores es un sistema dedicado a la administración y

1.5 Glosario de Términos

 Aseguramiento de la Calidad del Software (SQA)  El propósito de SQA es entregar a la

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

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

 Operacional: Ambiente en que el usuario operará el producto.

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 12

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 13

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

Ingeniería Sistemas Incremento 1

Figura 1: Modelo Incremental

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

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

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

 La adherencia del diseño y su documentación a los estándares definidos en el Plan del

La implementación se establece como la "construcción" del sistema. La actividad sólo lleva a la

Los posibles componentes son:

 Productos estándares disponibles y componentes construidos para el cliente.