SlideShare una empresa de Scribd logo
Proyecto de Calidad de
Software
Licenciatura en Desarrollo de Software
Yessenia Martínez
06/12/2012
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.
Í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
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
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.
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.
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
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.
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
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.
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)
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
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.
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.
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.
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.
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
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
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.
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
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.
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
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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)
adjudica
dos”
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.
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
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>>
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.
Ventana que muestra el registro de los documentos ya
adjudicados, con todos los datos, nombre, estudiante,
fecha, asesor.
Anexo 2 – Casos de uso
Registro de Usuarios
Ingreso al sistema
Selección de Proyecto
Cambio de datos
Registro de Proyecto
Ver documentos adjudicados
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
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.

Más contenido relacionado

La actualidad más candente

Coding Safe Modern C++ With AUTOSAR Guidelines
Coding Safe Modern C++ With AUTOSAR GuidelinesCoding Safe Modern C++ With AUTOSAR Guidelines
Coding Safe Modern C++ With AUTOSAR Guidelines
Perforce
 
Modelos de Processo de Software
Modelos de Processo de SoftwareModelos de Processo de Software
Modelos de Processo de Software
Rogerio P C do Nascimento
 
Modelo psp
Modelo pspModelo psp
Modelo psp
Qaroline Törres
 
The PMO journey
The PMO journeyThe PMO journey
The PMO journey
Tery Everett
 
Evolução de software 1 - Engenharia de Software
Evolução de software 1 - Engenharia de SoftwareEvolução de software 1 - Engenharia de Software
Evolução de software 1 - Engenharia de Software
Eduardo Mendes
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified Process
Omkar Dash
 
EP Unidad03: Planificación financiera y análisis de riesgos
EP Unidad03: Planificación financiera y análisis de riesgosEP Unidad03: Planificación financiera y análisis de riesgos
EP Unidad03: Planificación financiera y análisis de riesgos
Franklin Parrales Bravo
 
Project Management Team
Project Management TeamProject Management Team
Project Management Team
Vinita Thokchom
 
Ciclo de vida del software
Ciclo de vida del softwareCiclo de vida del software
Ciclo de vida del software
masferrer1998
 
Project management fundamentals
Project management fundamentalsProject management fundamentals
Project management fundamentals
shantdey
 
Plan desarrollo software
Plan desarrollo softwarePlan desarrollo software
Plan desarrollo software
Michael Daniel Murillo
 
Part 02 Connecting Business Strategy and Project Management
Part 02 Connecting Business Strategy and Project ManagementPart 02 Connecting Business Strategy and Project Management
Part 02 Connecting Business Strategy and Project Management
Lilis Rusliyawati
 
Sqa
SqaSqa
DSDM (Dynamic System Development Method)
DSDM (Dynamic System Development Method)DSDM (Dynamic System Development Method)
DSDM (Dynamic System Development Method)
urumisama
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
Wagner Zaparoli
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
yurikodelcarmen
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Sérgio Souza Costa
 
Standard For Program Management Changes
Standard For Program Management ChangesStandard For Program Management Changes
Standard For Program Management Changes
gryasam
 
Herramientas asistidas por_computadora
Herramientas asistidas por_computadoraHerramientas asistidas por_computadora
Herramientas asistidas por_computadora
Jorge Garcia
 
PMO Monthly Status-Report Template for Project manager
PMO Monthly Status-Report Template for Project managerPMO Monthly Status-Report Template for Project manager
PMO Monthly Status-Report Template for Project manager
Olivier Rachoin
 

La actualidad más candente (20)

Coding Safe Modern C++ With AUTOSAR Guidelines
Coding Safe Modern C++ With AUTOSAR GuidelinesCoding Safe Modern C++ With AUTOSAR Guidelines
Coding Safe Modern C++ With AUTOSAR Guidelines
 
Modelos de Processo de Software
Modelos de Processo de SoftwareModelos de Processo de Software
Modelos de Processo de Software
 
Modelo psp
Modelo pspModelo psp
Modelo psp
 
The PMO journey
The PMO journeyThe PMO journey
The PMO journey
 
Evolução de software 1 - Engenharia de Software
Evolução de software 1 - Engenharia de SoftwareEvolução de software 1 - Engenharia de Software
Evolução de software 1 - Engenharia de Software
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified Process
 
EP Unidad03: Planificación financiera y análisis de riesgos
EP Unidad03: Planificación financiera y análisis de riesgosEP Unidad03: Planificación financiera y análisis de riesgos
EP Unidad03: Planificación financiera y análisis de riesgos
 
Project Management Team
Project Management TeamProject Management Team
Project Management Team
 
Ciclo de vida del software
Ciclo de vida del softwareCiclo de vida del software
Ciclo de vida del software
 
Project management fundamentals
Project management fundamentalsProject management fundamentals
Project management fundamentals
 
Plan desarrollo software
Plan desarrollo softwarePlan desarrollo software
Plan desarrollo software
 
Part 02 Connecting Business Strategy and Project Management
Part 02 Connecting Business Strategy and Project ManagementPart 02 Connecting Business Strategy and Project Management
Part 02 Connecting Business Strategy and Project Management
 
Sqa
SqaSqa
Sqa
 
DSDM (Dynamic System Development Method)
DSDM (Dynamic System Development Method)DSDM (Dynamic System Development Method)
DSDM (Dynamic System Development Method)
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Standard For Program Management Changes
Standard For Program Management ChangesStandard For Program Management Changes
Standard For Program Management Changes
 
Herramientas asistidas por_computadora
Herramientas asistidas por_computadoraHerramientas asistidas por_computadora
Herramientas asistidas por_computadora
 
PMO Monthly Status-Report Template for Project manager
PMO Monthly Status-Report Template for Project managerPMO Monthly Status-Report Template for Project manager
PMO Monthly Status-Report Template for Project manager
 

Similar a Proyecto de calidad de software

Smgp dap (definicion del-alcance)-v2-docx
Smgp dap (definicion del-alcance)-v2-docxSmgp dap (definicion del-alcance)-v2-docx
Smgp dap (definicion del-alcance)-v2-docx
Jose Farias
 
Mariannysbermudez ing
Mariannysbermudez ingMariannysbermudez ing
Mariannysbermudez ing
mariannys bermudez
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
Lucre Castillo Lorenzo
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
Samantha Arguello Valdes
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
Lucre Castillo Lorenzo
 
Proyecto Final - Calidad de Software
Proyecto Final - Calidad de SoftwareProyecto Final - Calidad de Software
Proyecto Final - Calidad de Software
Yessenia I. Martínez M.
 
Gep2009 Eq3 T5 Sdp Fispa
Gep2009 Eq3 T5 Sdp FispaGep2009 Eq3 T5 Sdp Fispa
Gep2009 Eq3 T5 Sdp Fispa
JXCP.86
 
Gep2009 Eq3 T7 Sdp Fispa
Gep2009 Eq3 T7 Sdp FispaGep2009 Eq3 T7 Sdp Fispa
Gep2009 Eq3 T7 Sdp Fispa
JXCP.86
 
Gep2009 Eq3 T7 Solicitud de propuesta Fispa
Gep2009 Eq3 T7 Solicitud de propuesta FispaGep2009 Eq3 T7 Solicitud de propuesta Fispa
Gep2009 Eq3 T7 Solicitud de propuesta Fispa
JXCP.86
 
Diseno implementacion sistema_florez_2014
Diseno implementacion sistema_florez_2014Diseno implementacion sistema_florez_2014
Diseno implementacion sistema_florez_2014
Ronald Almanza
 
Estimación del esfuerzo y costo necesarios para el desarrollo de un proyecto ...
Estimación del esfuerzo y costo necesarios para el desarrollo de un proyecto ...Estimación del esfuerzo y costo necesarios para el desarrollo de un proyecto ...
Estimación del esfuerzo y costo necesarios para el desarrollo de un proyecto ...
Software Guru
 
Ingenieria de software -analizis literario
Ingenieria de software -analizis literarioIngenieria de software -analizis literario
Ingenieria de software -analizis literario
diegos08
 
GERENCIA Y DESAROLLO DE SOFTWARE
GERENCIA Y DESAROLLO DE SOFTWAREGERENCIA Y DESAROLLO DE SOFTWARE
GERENCIA Y DESAROLLO DE SOFTWARE
jhompix
 
Reporte proyecto formativo 2211955
Reporte proyecto formativo   2211955Reporte proyecto formativo   2211955
Reporte proyecto formativo 2211955
CRACMA ACU
 
Plantilla caso prueba
Plantilla caso pruebaPlantilla caso prueba
Plantilla caso prueba
STBG
 
SECUC- SOFTWARE INNOVADOR
SECUC- SOFTWARE INNOVADORSECUC- SOFTWARE INNOVADOR
SECUC- SOFTWARE INNOVADOR
Glery Cardoza López
 
Clase 1 - Introducción a la Ingenieria de Requerimientos.pptx
Clase 1 - Introducción a la Ingenieria de Requerimientos.pptxClase 1 - Introducción a la Ingenieria de Requerimientos.pptx
Clase 1 - Introducción a la Ingenieria de Requerimientos.pptx
OMARTRIANA5
 
6. Plan De Proyecto Bdtransito
6. Plan De Proyecto Bdtransito6. Plan De Proyecto Bdtransito
6. Plan De Proyecto Bdtransito
jeison david
 
Formato ficha proyecto.daniela gonzález. 4
Formato ficha proyecto.daniela gonzález. 4Formato ficha proyecto.daniela gonzález. 4
Formato ficha proyecto.daniela gonzález. 4
DaniiGonzalez98
 
Formato ficha proyecto.daniela gonzález. 4
Formato ficha proyecto.daniela gonzález. 4Formato ficha proyecto.daniela gonzález. 4
Formato ficha proyecto.daniela gonzález. 4
DaniiGonzalez98
 

Similar a Proyecto de calidad de software (20)

Smgp dap (definicion del-alcance)-v2-docx
Smgp dap (definicion del-alcance)-v2-docxSmgp dap (definicion del-alcance)-v2-docx
Smgp dap (definicion del-alcance)-v2-docx
 
Mariannysbermudez ing
Mariannysbermudez ingMariannysbermudez ing
Mariannysbermudez ing
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Proyecto Final - Calidad de Software
Proyecto Final - Calidad de SoftwareProyecto Final - Calidad de Software
Proyecto Final - Calidad de Software
 
Gep2009 Eq3 T5 Sdp Fispa
Gep2009 Eq3 T5 Sdp FispaGep2009 Eq3 T5 Sdp Fispa
Gep2009 Eq3 T5 Sdp Fispa
 
Gep2009 Eq3 T7 Sdp Fispa
Gep2009 Eq3 T7 Sdp FispaGep2009 Eq3 T7 Sdp Fispa
Gep2009 Eq3 T7 Sdp Fispa
 
Gep2009 Eq3 T7 Solicitud de propuesta Fispa
Gep2009 Eq3 T7 Solicitud de propuesta FispaGep2009 Eq3 T7 Solicitud de propuesta Fispa
Gep2009 Eq3 T7 Solicitud de propuesta Fispa
 
Diseno implementacion sistema_florez_2014
Diseno implementacion sistema_florez_2014Diseno implementacion sistema_florez_2014
Diseno implementacion sistema_florez_2014
 
Estimación del esfuerzo y costo necesarios para el desarrollo de un proyecto ...
Estimación del esfuerzo y costo necesarios para el desarrollo de un proyecto ...Estimación del esfuerzo y costo necesarios para el desarrollo de un proyecto ...
Estimación del esfuerzo y costo necesarios para el desarrollo de un proyecto ...
 
Ingenieria de software -analizis literario
Ingenieria de software -analizis literarioIngenieria de software -analizis literario
Ingenieria de software -analizis literario
 
GERENCIA Y DESAROLLO DE SOFTWARE
GERENCIA Y DESAROLLO DE SOFTWAREGERENCIA Y DESAROLLO DE SOFTWARE
GERENCIA Y DESAROLLO DE SOFTWARE
 
Reporte proyecto formativo 2211955
Reporte proyecto formativo   2211955Reporte proyecto formativo   2211955
Reporte proyecto formativo 2211955
 
Plantilla caso prueba
Plantilla caso pruebaPlantilla caso prueba
Plantilla caso prueba
 
SECUC- SOFTWARE INNOVADOR
SECUC- SOFTWARE INNOVADORSECUC- SOFTWARE INNOVADOR
SECUC- SOFTWARE INNOVADOR
 
Clase 1 - Introducción a la Ingenieria de Requerimientos.pptx
Clase 1 - Introducción a la Ingenieria de Requerimientos.pptxClase 1 - Introducción a la Ingenieria de Requerimientos.pptx
Clase 1 - Introducción a la Ingenieria de Requerimientos.pptx
 
6. Plan De Proyecto Bdtransito
6. Plan De Proyecto Bdtransito6. Plan De Proyecto Bdtransito
6. Plan De Proyecto Bdtransito
 
Formato ficha proyecto.daniela gonzález. 4
Formato ficha proyecto.daniela gonzález. 4Formato ficha proyecto.daniela gonzález. 4
Formato ficha proyecto.daniela gonzález. 4
 
Formato ficha proyecto.daniela gonzález. 4
Formato ficha proyecto.daniela gonzález. 4Formato ficha proyecto.daniela gonzález. 4
Formato ficha proyecto.daniela gonzález. 4
 

Más de Yessenia I. Martínez M.

Estructuras de datos fundamentales
Estructuras de datos  fundamentalesEstructuras de datos  fundamentales
Estructuras de datos fundamentales
Yessenia I. Martínez M.
 
Guia de lectura - Una herramienta para el estudio de estructura de datos y al...
Guia de lectura - Una herramienta para el estudio de estructura de datos y al...Guia de lectura - Una herramienta para el estudio de estructura de datos y al...
Guia de lectura - Una herramienta para el estudio de estructura de datos y al...
Yessenia I. Martínez M.
 
Guía de estudio -Módulo 1
Guía de estudio -Módulo 1Guía de estudio -Módulo 1
Guía de estudio -Módulo 1
Yessenia I. Martínez M.
 
Programación del curso - Estructura de Datos I
Programación del curso - Estructura de Datos IProgramación del curso - Estructura de Datos I
Programación del curso - Estructura de Datos I
Yessenia I. Martínez M.
 
Taller
TallerTaller
Psicosociología
PsicosociologíaPsicosociología
Psicosociología
Yessenia I. Martínez M.
 
Los Valores
Los ValoresLos Valores
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Yessenia I. Martínez M.
 
Teamlab - Información Básica
Teamlab - Información BásicaTeamlab - Información Básica
Teamlab - Información Básica
Yessenia I. Martínez M.
 
Guía para el Desarrollo de un Plan de Seguridad - Políticas y Procedimientos
Guía para el Desarrollo de un Plan de Seguridad - Políticas y ProcedimientosGuía para el Desarrollo de un Plan de Seguridad - Políticas y Procedimientos
Guía para el Desarrollo de un Plan de Seguridad - Políticas y Procedimientos
Yessenia I. Martínez M.
 
Comparación Técnica de Protocolos de Capa Física: Cable 10BaseT VS. Fibra Óptica
Comparación Técnica de Protocolos de Capa Física: Cable 10BaseT VS. Fibra ÓpticaComparación Técnica de Protocolos de Capa Física: Cable 10BaseT VS. Fibra Óptica
Comparación Técnica de Protocolos de Capa Física: Cable 10BaseT VS. Fibra Óptica
Yessenia I. Martínez M.
 
Visualización de Redes: Herramientas y Técnicas para la Creación y Evaluación...
Visualización de Redes: Herramientas y Técnicas para la Creación y Evaluación...Visualización de Redes: Herramientas y Técnicas para la Creación y Evaluación...
Visualización de Redes: Herramientas y Técnicas para la Creación y Evaluación...
Yessenia I. Martínez M.
 
Proyecto final (Administración) - Improvising Moments Bar Café
Proyecto final (Administración) - Improvising Moments Bar CaféProyecto final (Administración) - Improvising Moments Bar Café
Proyecto final (Administración) - Improvising Moments Bar Café
Yessenia I. Martínez M.
 
El Folklore Infantil
El Folklore InfantilEl Folklore Infantil
El Folklore Infantil
Yessenia I. Martínez M.
 
Indicadores de abuso sexual en la infancia
Indicadores de abuso sexual en la infanciaIndicadores de abuso sexual en la infancia
Indicadores de abuso sexual en la infancia
Yessenia I. Martínez M.
 
Linux Open SuSE
Linux Open SuSELinux Open SuSE
Linux Open SuSE
Yessenia I. Martínez M.
 
Herramientas Gráficas para MySQL
Herramientas Gráficas para MySQLHerramientas Gráficas para MySQL
Herramientas Gráficas para MySQL
Yessenia I. Martínez M.
 
Normalización Usando Dependencias Funcionales - Segunda Forma Normal
Normalización Usando Dependencias Funcionales - Segunda Forma NormalNormalización Usando Dependencias Funcionales - Segunda Forma Normal
Normalización Usando Dependencias Funcionales - Segunda Forma Normal
Yessenia I. Martínez M.
 
Sistema Operativo Solaris
Sistema Operativo SolarisSistema Operativo Solaris
Sistema Operativo Solaris
Yessenia I. Martínez M.
 
Modelos Lógicos Basados en Objetos
Modelos Lógicos Basados en ObjetosModelos Lógicos Basados en Objetos
Modelos Lógicos Basados en Objetos
Yessenia I. Martínez M.
 

Más de Yessenia I. Martínez M. (20)

Estructuras de datos fundamentales
Estructuras de datos  fundamentalesEstructuras de datos  fundamentales
Estructuras de datos fundamentales
 
Guia de lectura - Una herramienta para el estudio de estructura de datos y al...
Guia de lectura - Una herramienta para el estudio de estructura de datos y al...Guia de lectura - Una herramienta para el estudio de estructura de datos y al...
Guia de lectura - Una herramienta para el estudio de estructura de datos y al...
 
Guía de estudio -Módulo 1
Guía de estudio -Módulo 1Guía de estudio -Módulo 1
Guía de estudio -Módulo 1
 
Programación del curso - Estructura de Datos I
Programación del curso - Estructura de Datos IProgramación del curso - Estructura de Datos I
Programación del curso - Estructura de Datos I
 
Taller
TallerTaller
Taller
 
Psicosociología
PsicosociologíaPsicosociología
Psicosociología
 
Los Valores
Los ValoresLos Valores
Los Valores
 
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
 
Teamlab - Información Básica
Teamlab - Información BásicaTeamlab - Información Básica
Teamlab - Información Básica
 
Guía para el Desarrollo de un Plan de Seguridad - Políticas y Procedimientos
Guía para el Desarrollo de un Plan de Seguridad - Políticas y ProcedimientosGuía para el Desarrollo de un Plan de Seguridad - Políticas y Procedimientos
Guía para el Desarrollo de un Plan de Seguridad - Políticas y Procedimientos
 
Comparación Técnica de Protocolos de Capa Física: Cable 10BaseT VS. Fibra Óptica
Comparación Técnica de Protocolos de Capa Física: Cable 10BaseT VS. Fibra ÓpticaComparación Técnica de Protocolos de Capa Física: Cable 10BaseT VS. Fibra Óptica
Comparación Técnica de Protocolos de Capa Física: Cable 10BaseT VS. Fibra Óptica
 
Visualización de Redes: Herramientas y Técnicas para la Creación y Evaluación...
Visualización de Redes: Herramientas y Técnicas para la Creación y Evaluación...Visualización de Redes: Herramientas y Técnicas para la Creación y Evaluación...
Visualización de Redes: Herramientas y Técnicas para la Creación y Evaluación...
 
Proyecto final (Administración) - Improvising Moments Bar Café
Proyecto final (Administración) - Improvising Moments Bar CaféProyecto final (Administración) - Improvising Moments Bar Café
Proyecto final (Administración) - Improvising Moments Bar Café
 
El Folklore Infantil
El Folklore InfantilEl Folklore Infantil
El Folklore Infantil
 
Indicadores de abuso sexual en la infancia
Indicadores de abuso sexual en la infanciaIndicadores de abuso sexual en la infancia
Indicadores de abuso sexual en la infancia
 
Linux Open SuSE
Linux Open SuSELinux Open SuSE
Linux Open SuSE
 
Herramientas Gráficas para MySQL
Herramientas Gráficas para MySQLHerramientas Gráficas para MySQL
Herramientas Gráficas para MySQL
 
Normalización Usando Dependencias Funcionales - Segunda Forma Normal
Normalización Usando Dependencias Funcionales - Segunda Forma NormalNormalización Usando Dependencias Funcionales - Segunda Forma Normal
Normalización Usando Dependencias Funcionales - Segunda Forma Normal
 
Sistema Operativo Solaris
Sistema Operativo SolarisSistema Operativo Solaris
Sistema Operativo Solaris
 
Modelos Lógicos Basados en Objetos
Modelos Lógicos Basados en ObjetosModelos Lógicos Basados en Objetos
Modelos Lógicos Basados en Objetos
 

Proyecto de calidad de software

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