1. PROYECTO DE CALIDAD
DE SOFTWARE
Elaborado por:
Yessenia Martínez

2. INTRODUCCIÓN
El objetivo principal es constituir un documento que contiene los
lineamientos basados en el CMMI Nivel 2, 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.
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.

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

4. 2. REQUERIMIENTOS DE LA APLICACIÓN
2.1 Requerimientos Técnicos
2.1 .1 Arquitectura:
El sistema será desarrollado con los lenguajes HTML5, CSS y
PHP, siguiendo una arquitectura en tres capas, las cuales se
definen a continuación:
 Capa Cliente: Compuesta por la interfaz de usuario que
interactuará con la capa de negocio a través de Internet.
 Capa de Negocio: Integrado por un conjunto de clases que
tendrán que poder desplegarse en un servidor de
aplicaciones, donde se encapsulará la lógica de negocios del
sistema web.
 Capa de Datos: Encargada de conectarse con el gestor de
base de datos MySQL a fin de realizar operaciones de
consulta e inserción de información.

5. REQUERIMIENTOS DE LA APLICACIÓN
2.1 .2 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 .3 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.

6. REQUERIMIENTOS DE LA APLICACIÓN
2.1 .4 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.

7. REQUERIMIENTOS DE LA APLICACIÓN
2.2.2 Accesibilidad y usabilidad
 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
 Perfil del Estudiante
 Administrador Local

8. REQUERIMIENTOS DE LA APLICACIÓN
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. REQUERIMIENTOS DE LA APLICACIÓN
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.

10. MODELO DE PROCESOS

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

12. MODELO DE PROCESOS
 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
 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.

13. MODELO DE PROCESOS
 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 .

14. MODELO DE PROCESOS
 3.2.2 Presupuesto
Recurso humano
Recurso Tipo Cantidad Nombre Recurso Cantidad
Nº Recurso
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 312

15. MODELO DE PROCESOS
 3.2.2 Presupuesto
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)
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

16. MODELO DE PROCESOS
 3.2.3 Cronograma del Proyecto

17. MODELO DE PROCESOS
Nro.
Fase Duración
Iteraciones
Fase de Inicio 2 1 semana
Fase de Elaboración 2 3 semanas
Fase de 4 5 semanas
Construcción
Fase de Transición 2 3 semanas

18. MODELO DE PROCESOS
 3.1 Gestión de requisitos
 Estimación del proyecto
La estimación del proyecto se realizará con las siguientes
técnicas de estimación:
 Opinión de expertos
 Modelo COCOMO

19. MODELO DE PROCESOS
 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.

20. MODELO DE PROCESOS
 3.4 Medición y análisis
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.

21. MODELO DE PROCESOS
 3.5 Aseguramiento de la calidad
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.

22. MODELO DE PROCESOS
 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.

23. MODELO DE PROCESOS
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.
 Versión.
 Estado.
 Localización.

24. PLAN DE GARANTÍAS
PARA LA CALIDAD DE
SOFTWARE

25. 4. PLAN PARA 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.

26. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 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. Analista
 Verificador.
Desarrolladores
Proyecto SGOAP Jefe del proyecto
Ingenieros de software
Verificadores

27. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 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 organizar sus datos en base a
los estándares de calidad

28. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
Rol Responsabilidad
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.

29. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 4.3 Estándares y Guías
 Estándares de la World Wide Web Consortium (W3C).
 Diseño y aplicaciones web (Involucra los estándares de HTML
5, CSS 3, Ajax y otros).
 Arquitectura web
 Web de los Dispositivos
 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.

30. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 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 que 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

31. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 Estimación de Esfuerzo de Desarrollo de Software
 Líneas de código
 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:

32. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 Métricas de Usabilidad Web
 Métricas y Heurísticas de Usabilidad
 Comprensión Global del Sitio
 Ayuda y Retroalimentación
 Aspectos de Interfaces y Estéticos
 Métricas De Éxito
Registra el porcentaje de usuarios de la prueba capaces de
lograr lo que se pidió.
Fórmula: Éxito = (nº tareas terminadas +(nº medias 0.5))100/nº
total de tareas

33. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 Métricas Y Heurísticas De Funcionalidad
 Búsqueda y Recuperación
 Búsqueda Restringida
 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.

34. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 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.

35. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 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 externa del sistema.
 Prueba de caja blanca: Es un tipo de pruebas de software que se
realiza sobre las funciones internas de un módulo. Están dirigidas a
las funciones internas.

36. 4. PLAN PARA LA CALIDAD DEL
SOFTWARE
 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.
 Árbol de Utilidad (Utility Tree): 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.
 Perfiles (Profiles): 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.

37. CASOS DE PRUEBA

38. 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.
Id Módulo a Descripción del Data Pasos a seguir Pre-requisitos Resultado esperado
probar caso requerida
CP001 Registro de El usuario se Nombre, o Ingresar al sitio Ninguno Registro de los datos
usuario registra en el apellido, web. en el sistema.
sistema para rol, o Seleccionar
solicitar su carrera, opción de
ingreso. asignatur registro.
a, usuario, o Ingresar datos
contraseñ seleccionados.
a

39. 5. CASOS DE PRUEBA
Id Módulo a Descripción del Data Pasos a seguir Pre-requisitos Resultado esperado
probar caso requerida
CP002 Ingreso al El usuario ingresa Nombre de o Ingresar al sitio Los datos a Ingreso al panel de
sistema a la ventana de Usuario, web. ingresar deben control de usuario.
inicio de sesión e contraseña o Seleccionar estar en la base
ingresa el nombre de acceso opción de inicio de datos.
de usuario y de sesión.
contraseña o Ingresar usuario
registrado en el y contraseña.
paso anterior.

40. 5. CASOS DE PRUEBA
Id Módulo a probar Descripción del caso Data requerida Pasos a seguir
CP003 Selección de El usuario ingresa a la Nombre del o Selecciona la opción de panel
Proyectos sección de oferta de proyecto, fecha, de control.
proyectos, selecciona el que nombre del o Ingresa a la sección de
desea y envía los datos para asesor. adjudicación de proyectos.
su evaluación. o Selecciona el proyecto a
participar.
o Envía los datos.

41. 5. CASOS DE PRUEBA
Id Módulo a Descripción del Data Pasos a seguir Pre-requisitos Resultado esperado
probar caso requerida
CP004 Cambio de El usuario cambia Nombre de o Ingresa al panel de Debe estar Cambio de datos.
datos sus datos de usuario, Control. registrado en el
ingreso al sistema. contraseña, o Cambia los datos sistema.
nuevo de acceso.
usuario,
nueva
contraseña.

42. 5. CASOS DE PRUEBA
Id Módulo a probar Descripción del caso Data requerida Pasos a seguir
CP005 Registro de proyecto El usuario ingresa los datos Título del proyecto, o Ingresa al panel de control.
de un nuevo proyecto. fecha, asesor. o Selecciona opción de ingreso de
nuevo proyecto.
o Ingresa los datos.
o Envía los datos

43. 5. CASOS DE PRUEBA
Id Módulo a Descripción del Data Pasos a seguir Pre-requisitos Resultado esperado
probar caso requerida
CP006 Ver El usuario visualiza Ninguna o Ingresa al panel de Debe estar Visualización de la
Documentos la información de control. registrado en el información solicitada.
adjudicados aquellos proyectos o Selecciona opción sistema.
que han sido “Ver documentos
seleccionados. adjudicados”

44. 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 sir ven 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 sof tware, 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.

45. GRACIAS