Este documento presenta el proyecto de calidad de software para el sistema de gestión de proyectos (SGOAP) de la Universidad X. Describe los antecedentes, requisitos funcionales y técnicos, modelo de procesos que incluye planificación, monitoreo y control de calidad, y el plan de garantía de calidad. El objetivo es establecer parámetros para obtener un sistema de calidad siguiendo el modelo CMMI nivel 2.

1. Proyecto de Calidad de
Software
Licenciatura en Desarrollo de Software
Yessenia Martínez
06/12/2012

2. Universidad Tecnológica de Panamá
Centro Regional de Bocas del Toro
Facultad de Ingeniería en Sistemas Computacionales
Licenciatura en Desarrollo de Software
Asignatura
Calidad de Software
Trabajo Final
Estudiante
Yessenia Martínez 1-724-96
Facilitador
Domingo Villagra
Changuinola, 07 de Diciembre de 2012.

3. Índice
Índice................................................................................................................................ 2
Introducción ..................................................................................................................... 4
Contenido......................................................................................................................... 1
1. Antecedentes del Problema .......................................................................... 1
2. Requerimientos de la Aplicación ................................................................... 1
2.1 Requerimientos técnicos............................................................................. 1
2.2 Requerimientos Funcionales ...................................................................... 2
3. Modelo de procesos ...................................................................................... 4
3.1 Gestión de requisitos .................................................................................. 4
3.2 Planificación de proyectos .......................................................................... 4
3.3 Monitorización y control de proyectos......................................................... 9
3.4 Medición y análisis...................................................................................... 9
3.5 Aseguramiento de la calidad....................................................................... 9
3.6 Gestión de la configuración ...................................................................... 10
4. Plan de Garantía de la Calidad del Software............................................... 11
4.1 Objetivos de la calidad.............................................................................. 11
4.2 Administración .......................................................................................... 11
4.2.1 Organización............................................................................................. 11
4.2.2 Roles y responsabilidades ........................................................................ 12
4.3 Estándares y Guías .................................................................................. 13
4.4 Medidas, Métricas..................................................................................... 15
4.5 Plan de Revisiones y Auditoría ................................................................. 18
4.6 Pruebas y Evaluación ............................................................................... 18
5. Casos de Prueba........................................................................................... 0
Conclusión ....................................................................................................................... 0

4. Webgrafía......................................................................................................................... 1
Anexos ............................................................................................................................. 2
Anexo 1 - Diseño de Interfaz de Usuario..................................................................... 2
Anexo 2 – Casos de uso ................................................................................................ 5
Anexo 3 – Glosario.......................................................................................................... 8
Anexo 4 – Lista de riesgos............................................................................................. 8

5. Introducción
El presente documento contiene la información sobre la gestión del Proyecto
SGOAP con el se pretende establecer los parámetros para obtener un sistema de
calidad en base al modelo CMMI nivel 2.
El objetivo principal es constituir un documento que contiene los lineamientos que
el equipo de trabajo deberá seguir a lo largo del proyecto con el fin de mantener
un control y cumplir los objetivos generados del análisis del problema.
La calidad se define como la propiedad o conjunto de características de un
elemento que le dotan de una ventaja competitiva. La calidad de software es aquel
proceso en donde se verifica que el software o aplicación cumpla con los
requerimientos o necesidades del cliente, integrando la velocidad de respuesta de
la aplicación, el sistema de seguridad y confiabilidad.
El documento se encuentra dividido de la siguiente manera:
Antecedentes del problema.
Requisitos de la aplicación.
Modelo de procesos.
Plan de garantías de la calidad
de software.
Casos de prueba.

6. Contenido
1. Antecedentes del Problema
En los últimos años en la Universidad X ha aumentado la población estudiantil de
las diferentes facultades. Debido a esto, la cantidad de proyectos presentados
como trabajos de fin de carrera crece considerablemente y su gestión es algo
engorrosa ya que se realiza de forma manual. Es por esto que se requiere tener
un sistema que permita el control sobre los proyectos informáticos y proyectos de
fin de carrera que son ofertados y adjudicados, específicamente de la Escuela
Técnica Superior de Ingenierías Informática y de Telecomunicaciones.
2. Requerimientos de la Aplicación
2.1 Requerimientos técnicos
2.1.1 Arquitectura del Sistema
El sistema será desarrollado con los lenguajes JSP, Javascript, HTML y CSS.
Para
2.1.2 Hardware
o Memoria RAM 512MB
o Módem 128 kbps
o Resolución mínima de pantalla de 800x600 pixeles
Conexión a Internet
2.1.3 Software.
o Navegador web.

7. 2.1.4 Autenticación de usuarios
Para validar el ingreso al sistema, se le solicitará al usuario una serie de datos de
acceso (nombre de usuario y contraseña) las cuales deberán ser consultadas en
la base de datos a fin de determinar su existencia en el sistema. En caso de que
exista, el sitio deberá redirigir a su perfil personal, en caso contrario, se debe
mostrar un mensaje de error.
2.1.5 Seguridad en las comunicaciones
La información que viaje a través de la red e Internet, debe encontrarse
encriptada, con el fin de evitar la manipulación por terceros.
2.1.6 Formatos de archivo
Toda la documentación generada por el sistema se adecuará a los siguientes
formatos:
PDF
Excel
2.2 Requerimientos Funcionales
2.2.1 Control de solicitudes de proyectos
El sistema debe permitir el registro de las solicitudes de adjudicación de proyectos
por parte de los usuarios (estudiantes) interesados.
2.2.2 Accesibilidad y usabilidad

8. El sistema a desarrollar deberá cumplir con las diferentes normativas para la
accesibilidad de las personas con discapacidad. En cuanto a su diseño, su interfaz
debe ser fácil de comprender, y usar.
2.2.3 Gestión de usuarios
La gestión de usuarios permitirá la existencia de tres perfiles, que deberían ser los
siguientes:
Perfil del Docente (para los posibles candidatos a ser asesores de
proyectos)
Perfil del Estudiante (para los alumnos que deseen participar en la
adjudicación de proyectos)
Administrador Local (para la administración de la información que genere el
sistema)
2.2.4 Búsqueda de información
El sistema debe brindar una opción para realizar búsquedas de información sobre
los proyectos, tanto de forma general como definida por el usuario.
2.2.5 Documentos generados
Listado de solicitudes de adjudicación de proyectos.
Listado de docentes disponibles.
Listado de estudiantes en espera.
Listado de proyectos adjudicados.

9. 2.2.6 Guía de uso
El sistema debe contener un manual o guía de uso accesible desde cualquier
parte de la web.
3. Modelo de procesos
3.1 Gestión de requisitos
Consiste en identificar los aspectos que el sistema en desarrollo debe cumplir en
cuanto a las necesidades del cliente.
Los requisitos técnicos y funcionales del sistema se encuentran definidos en los
puntos 2.1 y 2.2 respectivamente, de la sección Requerimientos de la Aplicación,
en este documento.
3.2 Planificación de proyectos
La planificación del proyecto trata de proporcionar un marco de trabajo que permita al
gestor de planificación hacer estimaciones en cuanto a recursos, costos y planificación
temporal, con el fin de cumplir las condiciones exigidas por el cliente.
Las actividades a realizar son las siguientes:
3.2.1 Fases del Proyecto
Fase de Inicio
Descripción de la situación actual de la empresa.
Planificación del proyecto.
Evaluación de riesgos

10. Fase de Elaboración
Entrevistas a los clientes y futuros usuarios.
Elaboración del documento de Visión
Creación del glosario
Análisis del problema.
Definición de requisitos.
Selección de requisitos funcionales y no funcionales.
Especificación de los casos de uso
Realización de los diagramas de la base de datos.
Diseño de la interfaz de usuario.
Realización de los diagramas de entrada y salida de datos.
Fase de Construcción
Estructurar el modelo de implementación.
Implementar los diseños realizados en la fase de Análisis y Diseño.
Desarrollo de la base de datos.
Codificación del sistema.
Definir los tipos de pruebas a realizar.
Realizar pruebas de cada módulo del sistema.
Fase de Transición
Creación de la documentación del sistema.
Planificación de la implementación final del sistema.

11. 3.2.2 Presupuesto
Recurso humano
Recurso
Nº
Tipo
Recurso
Cantidad Nombre Recurso Cantid
ad
1 Humano 3 Horas Planificación 40
2 Humano 3 Horas Análisis 56
3 Humano 3 Horas Diseño 64
4 Humano 5 Horas Desarrollo 224
5 Humano 5 Horas Pruebas e
implantación
312
Recurso Económico
Recurso Cantidad Costo Unitario (en
Balboas)
Costo Total (en
Balboas)
Papelería 2 5.00 10.00
Computadoras
portátiles
3 770.29 2310.87
Transporte 4 2.80 11.20
Servidor 1 1272.23 1272.23
Salarios (mensual, 3 meses)

12. Jefe del proyecto 1 1450.00 4350.00
Analista del
sistema
1 1300.00 3900.00
Ingeniero de
Software
1 1200.00 3600.00
Programadores 2 1000.00 6000.00
Capacitaciones
(si se requiere)
5000.00 5000.00
Imprevistos (10
%)
2645.43
Total 29099.73
3.2.3 Cronograma del Proyecto

13. Fase
Nro.
Iteraciones
Duración
Fase de Inicio 2 1 semana
Fase de Elaboración 2 3 semanas
Fase de Construcción 4 5 semanas
Fase de Transición 2 3 semanas
3.2.4 Estimación del proyecto
La estimación del proyecto se realizará con las siguientes técnicas de estimación:
Opinión de expertos: Se consultan varios expertos en las técnicas de
desarrollo de software propuestas y en el dominio de aplicación. Cada uno
de ellos estima el costo del proyecto. Estas estimaciones se comparan y
discuten. El proceso de estimación se itera hasta que se acuerda una
estimación.
Modelo COCOMO: Es una una jerarquía de modelos de estimación de
Software. Creado por Barry Boehm.
o Modelo I (Básico) Semiacoplado: Calcula el esfuerzo y el costo del
desarrollo de Software en función del tamaño del programa,
expresado en las líneas estimadas.

14. 3.3 Monitorización y control de proyectos
Brinda una idea sobre el estado actual del proyecto para tomar acciones
preventivas en caso de que el proyecto se desvíe de su plan. Los controles que se
llevarán a cabo en el proyecto son los siguientes:
Control del avance de las actividades e hitos señalados en el cronograma.
Controlar los costos del proyecto.
Realizar informes sobre el rendimiento y avances del proyecto.
Seguimiento y control de los riesgos detectados.
3.4 Medición y análisis
La medición y análisis permite a la organización reunir información objetiva
(medición) con el fin de dar soporte a la dirección y gerencia.
El propósito del proceso de medición y análisis es identificar en qué problemas
debe enfocarse la empresa, permitiendo definir acciones correctivas, asignando
los recursos necesarios que permitan mejorar los procesos.
Para la medición y análisis, se utilizarán una serie de métricas que se encuentran
definidas en la sección Métricas y Medidas del Plan de Garantías de Calidad del
Software.
3.5 Aseguramiento de la calidad
Implica garantizar que el equipo de trabajo cumpla con cada uno de los procesos
establecidos. Es un conjunto de actividades planeadas y sistemáticas para
proporcionar la confianza adecuada dentro del proyecto.

15. Para asegurar la calidad, se utilizará como guía la Norma ISO 9001; es de
carácter genérico y especifica los requisitos para un Sistema de Gestión de
Calidad para las organizaciones. Sin embargo, el cumplimiento de esta norma no
garantiza que se esté controlando que la calidad del producto final sea buena.
Simplemente garantiza que la empresa ha adoptado una organización definida y
controlada.
3.6 Gestión de la configuración
Es la disciplina encargada de garantizar la integridad del producto en desarrollo
durante todo el ciclo de vida. Para lograr el objetivo de minimizar errores y mejorar
la calidad, se debe identificar, organizar y controlar las modificaciones que sufre el
producto.
Los elementos que conforman la configuración del software incluyen:
Ejecutables.
Código Fuente.
Modelos de datos.
Modelos de procesos.
Especificaciones de requisitos.
Pruebas.
Para cada uno de los elementos mencionados anteriormente, se almacenará lo
siguiente:
Nombre.

16. Versión.
Estado.
Localización.
Para la creación de estos elementos, se utilizarán cuestionarios y entrevistas
aplicadas a los miembros del equipo de trabajo.
4. Plan de Garantía de la Calidad del Software
4.1 Objetivos de la calidad
El principal objetivo es brindar a los administradores del proyecto y a su equipo de trabajo
información relevante sobre los procesos que involucran el desarrollo del sistema.
Con el fin de que el sistema se ajuste a las necesidades del cliente, se establecen las
siguientes pautas:
Identificar y atender los puntos que no cumplan con los estándares establecidos.
Evaluar los procesos que involucran al sistema.
Crear un plan de cumplimiento.
4.2 Administración
4.2.1 Organización
Los miembros del equipo del proyecto SGOAP son:
Administrador del proyecto.
Analista del sistema.
Desarrolladores de software.
Ingeniero de software.

17. Verificador.
La siguiente figura muestra a los miembros del equipo y los diferentes roles a los que
fueron asignados.
4.2.2 Roles y responsabilidades
En la siguiente tabla se define cada una de las responsabilidades que tiene cada
persona, con el fin de asegurar la calidad del producto final.
Rol Responsabilidad
Jefe del proyecto Encargado de la gestión de la calidad del proyecto,
además de comunicar si existe algún error en el plan
de calidad.
Analista Realiza las funciones de análisis de los requerimientos
del sistema del cual se parte a desarrollar la aplicación y
Proyecto SGOAP Jefe del proyecto
Analista
Desarrolladores
Ingenieros de software
Verificadores

18. organizar sus datos en base a los estándares de calidad
Ingenieros de software Desarrollar el diseño de arquitectura y bajo nivel del
software, según los estándares de calidad que se
encuentran en el plan de calidad.
Desarrolladores Su función es la de construir el código que dará lugar al
producto basado en métricas, estándares y herramientas
de codificación establecidas.
Verificadores Llevar a cabo las revisiones de software en todas las
fases del proyecto.
4.3 Estándares y Guías
Estándares de la World Wide Web Consortium (W3C): La W3C es un consorcio
internacional que produce recomendaciones para la World Wide Web. Las
especificaciones que se utilizarán se definen a continuación:
Diseño y aplicaciones web (Involucra los estándares de HTML 5, CSS 3,
Ajax y otros).
Arquitectura web: La Arquitectura Web se centra en las tecnologías y
principios fundamentales sobre los que se sostiene la Web, incluyendo
URIs y HTTP.
Web de los Dispositivos: Se centra en tecnologías que permiten el acceso a
la Web desde cualquier lugar, en cualquier momento y a través de cualquier
dispositivo. Esto incluye acceso a la Web desde teléfonos móviles y otros

19. dispositivos móviles, además del uso de la tecnología Web en electrónica
de consumo, impresoras, televisión interactiva, incluso en automóviles.
Norma ISO 9126 (reemplazado por el proyecto SQuaRE, ISO 25000:2005): El
modelo establece diez características, seis que son comunes a las vistas interna y
externa y cuatro que son propias de la vista en uso:
Vista Interna y Externa
o Funcionalidad, capacidad del software de proveer los servicios
necesarios para cumplir con los requisitos funcionales.
o Fiabilidad, capacidad del software de mantener las prestaciones
requeridas del sistema, durante un tiempo establecido y bajo un
conjunto de condiciones definidas.
o Usabilidad, esfuerzo requerido por el usuario para utilizar el producto
satisfactoriamente.
o Eficiencia, relación entre las prestaciones del software y los
requisitos necesarios para su utilización.
o Mantenibilidad, esfuerzo necesario para adaptarse a las nuevas
especificaciones y requisitos del software.
o Portabilidad, capacidad del software ser transferido de un entorno a
otro.
Vista en Uso
o Efectividad, capacidad del software de facilitar al usuario alcanzar
objetivos con precisión y completitud.

20. o Productividad, capacidad del software de permitir a los
usuarios gastar la cantidad apropiada de recursos en relación a la
efectividad obtenida.
o Seguridad, capacidad del software para cumplir con los niveles de
riesgo permitidos tanto para posibles daños físicos como para
posibles riesgos de datos.
o Satisfacción, capacidad del software de cumplir con las expectativas
de los usuarios en un contexto determinado.
IEEE 1012 – 2004: Estándar de Verificación y Validación de Software:
Determina si los productos de una actividad de desarrollo dada se ajustan a los
requisitos de la actividad y si el software satisface su uso previsto y las
necesidades del usuario.
4.4 Medidas, Métricas
Métricas de Calidad y Fiabilidad
Tiempo medio entre fallos: Tiempo de operatividad del sistema antes de
que aparezcan fallos.
TMEF = TMDF + TMDR
Disponibilidad: Probabilidad de que el sistema se encuentre disponible para
su uso.
Disponibilidad = TMDF / (TMDF + TMDR) ×100

21. Estimación de Esfuerzo de Desarrollo de Software
Líneas de código
La métrica de tamaño tradicional para estimar el esfuerzo de desarrollo y
productividad ha sido LOC (Lines Of Code) o SLOC (Source Lines Of Code).
Generalmente, el modelo de estimación de esfuerzo consiste de dos partes. La
primera provee una base de estimación como una función del tamaño del
software, y es de la siguiente forma:
donde E es el esfuerzo estimado en meses hombre, A, B y C son constantes y
KLOC es el tamaño estimado del sistema final en miles de líneas de código. La
segunda parte del modelo modifica esta estimación en base a cuantificar la
influencia de factores de ambiente, por ejemplo la utilización de diferentes
metodologías, habilidad del equipo de desarrollo y restricciones de hardware.
Métricas de Usabilidad Web
Métricas y Heurísticas de Usabilidad
Comprensión Global del Sitio
Representa a todas aquellas facilidades que permiten a la audiencia tener
una rápida comprensión tanto de la estructura organizativa, como del
contenido del sitio Web, facilitando el rápido acceso y el recorrido del mismo
y sus componentes.

22. Esquema de Organización Global
Visita Guiada
Mapa de Imagen
Ayuda y Retroalimentación
Ayuda
Retroalimentación Basada en Formularios
Retroalimentación Basada en Enlaces
Aspectos de Interfaces y Estéticos
Uniformidad en el Estilo
Métricas De Éxito
La métrica más simple para medir la usabilidad de un sitio es la tarifa del éxito al
realizar una tarea representativa: registre el porcentaje de usuarios de la prueba
capaces de lograr lo que se pidió.
Es una métrica burda pero es fácil de recolectar y constituye una estadística
reveladora. Tarea terminada tiene peso 1, tarea a medio terminar tiene un peso
0,5 y no realizada 0.
Fórmula: Éxito = (nº tareas terminadas +(nº medias 0.5))100/nº total de tareas
Métricas Y Heurísticas De Funcionalidad
Búsqueda y Recuperación
Búsqueda Restringida

23. Búsqueda Global
Personalización de la Recuperación
Métricas de Eficiencia
Páginas de Acceso Rápido: El tiempo de descarga estará en función del tamaño
de la página estática y la velocidad de la línea de conexión establecida. Fórmula:
tiempo descarga = f( T, c) siendo T tamaño de la página y c la velocidad de
conexión.
4.5 Plan de Revisiones y Auditoría
Para el plan de revisiones y auditoria, se realizará al finalizar cada semana
revisiones sobre los avances del proyecto para visualizar qué tareas han sido
cumplidas satisfactoriamente y retroalimentar a los miembros del proyecto. El
equipo de trabajo será considerado como auditor de los documentos generados y
utilizará servicios de terceras personas para analizar el trabajo realizado.
4.6 Pruebas y Evaluación
Las pruebas que se le realizarán al sistema para comprobar su calidad se listan a
continuación:
Prueba de caja negra: Esta prueba implica una variada selección de los datos de
prueba así como una buena interpretación de los resultados para determinar el
nivel de optimización de la funcionalidad del sistema.
El principal objetivo es determinar la funcionalidad del software y parte de tratar al
programa como si fuera una función matemática, estudiando si las respuestas o

24. salidas son ¨codominio¨ de los datos entrantes ¨dominio¨. La prueba de caja negra
tiene otras metas, determinar la eficiencia del programa desde el desempeño en el
equipo, el tiempo de retardo de las salidas hasta el nivel de recuperación del
sistema luego de fallas o caídas sean estas producidas por manejo incorrecto de
datos, equipo, o producidas externamente como cortes de energía.
Prueba de caja blanca: Para esta prueba se consideran tres importantes puntos.
I) Conocer el desarrollo interno del programa, determinante en el análisis de
coherencia y consistencia del código.
II) Considerar las reglas predefinidas por cada algoritmo.
III) Comparar el desarrollo del programa en su código con la documentación
pertinente.
La primera parte de esta prueba es el análisis estático.
o Análisis estático Manual
o Inspección: Determina si el código esta completo y correcto, como
también las especificaciones.
o Walkthrough: Interrelación informal entre testers, creadores y
usuarios del sistema.
o Análisis estático Automático
o Verificación estática: Compara los valores generados por el
programa con los rangos de valores predefinidos haciendo una

25. descripción del funcionamiento de los procedimientos en términos
booleanos determinando los puntos de falla.
o Ejecución simbólica: Hace un seguimiento de la comunicación entre
funciones, módulos, aplicaciones, luego de que todas las partes
hayan sido verificadas por separado.
La segunda parte de esta es el análisis dinámico. Para esto se cuenta con
diferentes tipos de herramientas.
o Análisis de cobertura: Examina las extensiones del código, haciendo una
caja blanca por modulo.
o Trafico: Sigue todos los caminos de comunicación entre módulos
guardando los valores de las variables en cada uno de ellos.
o Simulador: Simula partes del sistema para el cual el hardware no esta
habilitado.
o Sintonía: Testea los recursos utilizados durante la ejecución del programa.
o Prueba de certeza: Examina las construcciones lógicas del programa.
Para la evaluación se utilizará lo siguiente:
Evaluación Basada en Escenarios
Un escenario es una breve descripción de la interacción de alguno de los
involucrados en el desarrollo del sistema con éste. Un escenario consta de tres
partes: el estímulo, el contexto y la respuesta. El estímulo es la parte del escenario
que explica o describe lo que el involucrado en el desarrollo hace para iniciar la
interacción con el sistema.

26. Entre las ventajas de su uso están:
o Son simples de crear y entender.
o Son poco costosos y no requieren mucho entrenamiento.
o Son efectivos.
Actualmente las técnicas basadas en escenarios cuentan con dos instrumentos de
evaluación relevantes, a saber:
o Árbol de Utilidad (Utility Tree)
Un UT es un esquema en forma de árbol que presenta los atributos de calidad
de un sistema de software, refinados hasta el establecimiento de escenarios
que especifican con suficiente detalle el nivel de prioridad de cada uno.
La intención de su uso es la identificación de los atributos de calidad más
importantes para un proyecto particular. Cada atributo de calidad perteneciente
al árbol contiene una serie de escenarios relacionados, y una escala de
importancia y dificultad asociada, que será útil para efectos de la evaluación de
la arquitectura.
o Perfiles (Profiles)
Un perfil (Profile) es un conjunto de escenarios, generalmente con alguna
importancia relativa asociada a cada uno de ellos. El uso de perfiles permite
hacer especificaciones más precisas del requerimiento para un atributo de
calidad. Los perfiles tienen asociados dos formas de especificación: perfiles
completos y perfiles seleccionados.

27. A pesar de todos los elementos definidos alrededor de dicha técnica de
evaluación, ésta presenta como desventaja que es dependiente de manera
directa del perfil definido para el atributo de calidad que va a ser evaluado.
La efectividad de la técnica es altamente dependiente de la
representatividad de los escenarios. Es importante destacar que la
definición de los casos de uso debe ser independiente del perfil de uso,
debido a que los casos de uso permiten optimizar el diseño arquitectónico, y
puede resultar una muestra no representativa de la población de escenarios
para la evaluación de cierto atributo de calidad.

28. 5. Casos de Prueba
Los casos de prueba son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de
una aplicación es parcial o completamente satisfactorio.
A continuación se lista los casos de prueba del proyecto:
Id Módulo
a
probar
Descripció
n del caso
Data
requerida
Pasos a seguir Pre-
requisit
os
Resultado
positivo
Resultado negativo
CP0
01
Registro
de
usuario
El usuario
se registra
en el
sistema
para
solicitar su
Nombre,
apellido,
rol, carrera,
asignatura,
usuario,
contraseña
o Ingresar
al sitio
web.
o Seleccio
nar
opción
Ninguno Registro de
los datos en
el sistema.
Fallo en el registro del
nuevo usuario.
Mensaje al usuario
indicando que intente
nuevamente ingresar los
datos.

29. ingreso. de
registro.
o Ingresar
datos
seleccion
ados.
CP0
02
Ingreso
al
sistema
El usuario
ingresa a la
ventana de
inicio de
sesión e
ingresa el
nombre de
usuario y
contraseña
Nombre de
Usuario,
contraseña
de acceso
o Ingresar
al sitio
web.
o Seleccio
nar
opción
de inicio
de
sesión.
Los
datos a
ingresar
deben
estar en
la base
de
datos.
Ingreso al
panel de
control de
usuario.
Fallo en el ingreso al
sistema.
El sistema muestra mensaje
de error.

30. registrado
en el paso
anterior.
o Ingresar
usuario y
contrase
ña.
CP0
03
Selecció
n de
Proyect
os
El usuario
ingresa a la
sección de
oferta de
proyectos,
selecciona
el que
desea y
envía los
datos para
su
Nombre del
proyecto,
fecha,
nombre del
asesor.
o Seleccio
na la
opción
de panel
de
control.
o Ingresa a
la
sección
de
adjudicac
Debe
estar
registrad
o en el
sistema.
Debe
haber
accedid
o al
sistema.
Envío y
confirmación
al usuario de
la información
seleccionada.
Muestra mensaje de error.

31. evaluación. ión de
proyecto
s.
o Seleccio
na el
proyecto
a
participar
.
o Envía los
datos.
CP0
04
Cambio
de datos
El usuario
cambia sus
datos de
ingreso al
Nombre de
usuario,
contraseña
, nuevo
o Ingresa
al panel
de
Control.
Debe
estar
registrad
o en el
Cambio de
datos.
Muestra mensaje de error.
Los datos no se actualizan.

32. sistema. usuario,
nueva
contraseña
.
o Cambia
los datos
de
acceso.
sistema.
CP0
05
Registro
de
proyecto
El usuario
ingresa los
datos de
un nuevo
proyecto.
Título del
proyecto,
fecha,
asesor.
o Ingresa
al panel
de
control.
o Seleccio
na
opción
de
ingreso
de nuevo
proyecto.
Debe
estar
registrad
o en el
sistema.
Debe
tener rol
de
administ
rador
Registro del
nuevo
proyecto.
Datos no se registran.
Se muestra un mensaje de
error.

33. o Ingresa
los
datos.
o Envía los
datos
CP0
06
Ver
Docume
ntos
adjudica
dos
El usuario
visualiza la
información
de aquellos
proyectos
que han
sido
selecciona
dos.
Ninguna o Ingresa
al panel
de
control.
o Seleccio
na
opción
“Ver
documen
tos
Debe
estar
registrad
o en el
sistema.
Visualización
de la
información
solicitada.
No se visualiza la
información (Datos elegidos
pueden ser inválidos)

34. adjudica
dos”

35. Conclusión
En este documento se ha mostrado que existen diferentes maneras de evaluar la
calidad de un sistema en el proceso de desarrollo, lo que significa que se deben
elegir aquellas que se adapten a las necesidades del proyecto.
Para elegir las técnicas y criterios que aseguren que el proyecto cumpla con su
propósito, es necesario tomar en cuenta los estándares establecidos por
asociaciones como la IEEE y para el caso de aplicaciones web, la W3C que sirven
como guía para la elaboración de un buen plan de aseguramiento de la calidad.
El hecho de que exista un plan de calidad de software, no implica que la calidad
del producto terminado sea 100% perfecto, por lo que es importante llevar un
control de todas las actividades a seguir y determinar a tiempo los riesgos que
implica llevar a cabo el proyecto.

36. Webgrafía
García Mireles, Gabriel Alberto. Introducción a la gestión de requerimientos.
Recuperado el 05 de diciembre de 2012 del sitio web: www.mat.uson.mx/mireles/
Introgestionreq_archivos/frame.htm
Desarrollo de Casos de Prueba - Calidad y Software, (s.f.). Recuperado el 06
de diciembre de 2012 del sitio web: calidadysoftware.com/testing/casos_de_
prueba.php
Prueba de software, (s.f.). Recuperado el 06 de diciembre de 2012 del sitio web:
html.rincondelvago.com/prueba-de-software.html
Técnicas de Evaluación de Arquitectura de Software, (s.f.). Recuperado el 06
de diciembre de 2012 del sitio web:
http://www.ecured.cu/index.php/Tecnicas_de_Evaluacion_de_Arquitectura_de_Sof
tware

37. Anexos
Anexo 1 - Diseño de Interfaz de Usuario
Ventana que permite al usuario registrarse, según
el rol del mismo
Ventana que da la Bienvenida al <<SGOAP>>

38. Ventana que le permite al Usuario escoger el
proyecto según su facultad.
Sección principal, muestra los datos personales del
usuario, de mismo modo este puede cambiarlos
también.

39. Ventana que muestra el registro de los documentos ya
adjudicados, con todos los datos, nombre, estudiante,
fecha, asesor.

40. Anexo 2 – Casos de uso
Registro de Usuarios
Ingreso al sistema

41. Selección de Proyecto
Cambio de datos

42. Registro de Proyecto
Ver documentos adjudicados

43. Anexo 3 – Glosario
1. PHP: Lenguaje de programación usado generalmente en la creación de
contenidos para sitios web.
2. SGOAP: Sistema de Gestión de Ofertas y Adjudicación de Proyectos.
3. MySQL: Es un sistema de gestión de bases de datos relacional, multihilo
y multiusuario muy utilizado en aplicaciones web y por herramientas de
seguimiento de errores.
4. Usuario: Persona que utilizará el sistema.
5. Cliente: Persona que solicita la creación del sistema.
6. CSS: Hojas de estilo en cascada. Es un lenguaje usado para definir la
presentación de un documento estructurado escrito en HTML.
7. Hito: Acontecimiento muy importante que marca un punto de referencia.
8. HTML: Hace referencia al lenguaje de marcado predominante para la
elaboración de páginas web que se utiliza para describir y traducir la
estructura y la información en forma de texto, así como para
complementar el texto con objetos tales como imágenes.
Anexo 4 – Lista de riesgos
A continuación, se presenta una lista con los riesgos que se pueden presentar a lo
largo del proyecto y sus posibles soluciones:
Riesgo Solución
Daños de equipos informáticos
utilizados para el desarrollo de la
Revisar periódicamente el equipo
informático utilizado, con el fin de evitar

44. aplicación. daños irreparables y pérdida de
información.
Falta de personal para llevar a cabo el
trabajo.
Tener personal contingente el cual
pueda.
Incompatibilidad del sistema con los
equipos informáticos disponibles.
Verificar durante la fase de
requerimientos el hardware y software
actual de los equipos.
Pérdida de la información Realizar respaldos periódicamente
tanto de la base de datos como del
proyecto
Falta de experiencia en el manejo de
las herramientas de desarrollo
Capacitar al personal en las
herramientas que requieran.
Requisitos del sistema poco claros Reunirse más a menudo con el cliente y
los futuros usuarios a fin de aclarar los
requisitos del sistema.