ACTIVIDADES DEL PROCESO DE DESARROLLO 1. FASE DE INICIO

ACTIVIDADES DEL PROCESO DE DESARROLLO
1.
FASE DE INICIO
A1.1: Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual
para lograr un entendimiento común y obtener su compromiso con el
proyecto.
PLAN DE DESARROLLO
Descripción del proyecto:
Se requiere construir una aplicación web que permita la venta de libros a través de
internet. Básicamente la aplicación se apoyará en un catálogo electrónico de libros,
actualizado continuamente con la información recibida desde las editoriales; en el
catálogo se conservarán los datos básicos de cada libro. Se permitirá mostrar información
de los libros, realizar ventas, pedidos, y pagos.
Este Sistema será desarrollado para una importante librería Chilena, que dará soporte
mediante su comercio electrónico, similar al utilizado por la empresa Amazon
(www.amazon.com).
Recursos:

Humanos: Se cuenta con un grupo de cuatro estudiantes de séptimo semestre de
ingeniería de sistemas de la Universidad del Cauca a los cuales se les asignará un
rol específico para la realización del proyecto.

Físicos: Se cuenta con un equipo portátil para el desarrollo del trabajo, tres de
escritorio y además los equipos que se encuentran disponibles dentro de las
instalaciones de la Universidad del Cauca.

Tiempo: El tiempo con el cual se cuenta para el desarrollo del proyecto es durante
las actividades del segundo periodo académico del 2011.
Disponibilidad de tiempo:
El tiempo del cual disponen los integrantes del grupo es de 4 horas semanales para
dedicarlas al desarrollo del proyecto.
Inicio de actividades del proyecto: 27 agosto de 2011.
Finalización del proyecto: Febrero de 2012
2.
FASE DE REQUISITOS
A2.1: Distribuir tareas a los miembros del equipo de trabajo según su rol, de
acuerdo al Plan de Desarrollo actual.
Ver Plantilla
Responsable de la administración del proyecto específico (RAPE):
●
A2.1: Distribuir tareas a los miembros del equipo de trabajo según su rol,
de acuerdo al plan de desarrollo actual.
Equipo de trabajo (ET):
●
A1.1: Revisar con los miembros del equipo de trabajo el plan de desarrollo
actual para lograr un entendimiento común y obtener su compromiso con el
proyecto.
●
A2.2: Documentar la especificación de requisitos.
●
A2.8: Modificación del prototipo de interfaz de usuario y su incorporación a
la especificación de requisitos.
●
A3.2: Analizar la especificación de requisitos para modelar las unidades
funcionales del sistema.
●
A3.2: Documentar la especificación del sistema.
●
A3.3: Definir la plataforma tecnológica.
●
A3.4: Presentar la arquitectura candidata al cliente y esperar su
aprobación.
●
A5.1: Diseñar los casos de prueba de aceptación del sistema.
Cliente (CL):
●
A2.2: Documentar la especificación de requisitos.
●
A2.6: Efectuar pruebas de usabilidad del prototipo de interfaz de usuario
con usuarios.
●
A3.4: Presentar la arquitectura candidata al cliente y esperar su
aprobación.
●
A5.2: Ejecutar los casos de prueba de aceptación del sistema.
Diseñador de la interfaz (DU):
●
A2.5: Elaborar el prototipo de la interfaz.
●
A2.6: Efectuar pruebas de usabilidad del prototipo de interfaz de usuario
con usuarios
●
A2.7: Modificación del prototipo de interfaz de usuario y su incorporación
a la especificación de requisitos.
●
A5.4: Elaborar un Manual de Usuarios del sistema
Programador (PR):
●
A4.1: Implementar o modificar Componente(s) con base a la parte
detallada de la Especificación del Sistema.
●
A4.3: Integrar los componentes en subsistemas.
●
A5.2: Ejecutar los casos de prueba de aceptación del sistema.
●
A5.3: Validar y corregir los defectos encontrados.
Responsable de desarrollo de software (RD):
●
A2.3: Elaborar el diagrama de casos de uso.
●
A2.4: Elaborar el formato de alto nivel de los casos de uso.
●
A3.1: Elaborar el diagrama de clases del sistema.
●
A4.2: Incorporar software a la configuración de software.
A2.2: Documentar la especificación de requisitos.
Ver Plantilla
Este documento permitirá especificar los requisitos funcionales y no funcionales del
sistema priorizados del más al menos relevante, también se organizará de forma modular
para tener una mayor organización en su entendimiento.
A2.3: Elaborar el diagrama de casos de uso.
A2.4: Elaborar el formato de alto nivel de los casos de uso.
Ver Plantilla
Este formato de alto nivel describe cada caso de uso de una manera muy simple para ser
entendida fácilmente por clientes y desarrolladores.
A2.5. Elaborar el prototipo de la interfaz.
Para lograr que la aplicación final ofrezca un servicio amable y placentero a los usuarios
se creó inicialmente un primer prototipo, el cual fue diseñado utilizando un wireframes.
Un wireframe es una representación esquemática de una página web sin elementos
gráficos que muestran contenido y comportamiento de las páginas. Sirven como
herramienta de comunicación y discusión entre arquitectos de información,
programadores, diseñadores y clientes. También se pueden utilizar para comprobar la
usabilidad de un sitio web. Su principal ventaja es que ofrece una perspectiva basada
solamente en la arquitectura del contenido, obviando el diseño.
Prototipo agregar libro:
Prototipo listar catálogo:
Prototipo editar libro:
A2.6: Efectuar pruebas de usabilidad del prototipo de interfaz de usuario con
usuarios.
Ver Plantilla
El método utilizado fue el de evaluación heurística, la cual consiste en analizar la
conformidad de la interfaz con unos principios reconocidos de usabilidad (la “heurística”)
mediante la inspección de varios evaluadores expertos.
En cualquier evaluación heurística es necesario implicar a varios evaluadores. Se
recomienda normalmente utilizar de tres a cinco evaluadores ya que se consideran
suficientes y la inclusión de un mayor número de los mismos no garantiza una mejora en
el resultado. En definitiva, se lleva a cabo realizando por parte de cada evaluador
una revisión de la interfaz. Cuando se han terminado todas las evaluaciones se permite
a los evaluadores comunicar los resultados y sintetizarlos. Este procedimiento
es importante para asegurar evaluaciones independientes e imparciales de
cada evaluador. Los resultados de la evaluación se pueden registrar como informes
escritos de cada evaluador o haciendo que los evaluadores comuniquen verbalmente
sus comentarios a un observador mientras inspeccionan la interfaz.
Para nuestro caso se eligió un solo evaluador, el Ingeniero Andrés Fernando Solano, un
experto en usabilidad.
A2.7: Modificación del prototipo de interfaz de usuario y su incorporación a la
Especificación de Requisitos.
De acuerdo a la evaluación de usabilidad se obtuvieron los siguientes resultados:
Prototipo final de listar catálogo:
Prototipo final de agregar libro:
Prototipo final de editar libro:
3.
FASE DE DISEÑO
A3.1: Elaborar el diagrama de clases del sistema.
A3.2. Documentar la Especificación del Sistema.
Ver Plantilla
El documento de especificación del sistema contiene la descripción textual y grafica de la
estructura de los componentes de software.
A3.3. Definir la plataforma tecnológica. Ver Plantilla
Para realizar el módulo de gestión del catálogo se utilizaron varias herramientas que
facilitaron el desarrollo del mismo, tales como: un framework de desarrollo (Kumbia), un
programa para realizar prototipos (Wireframe), un programa de modelamiento de UML
(Power Designer), además de un entorno de desarrollo de aplicaciones web (WAMP).
A3.4. Presentar la arquitectura candidata al cliente y esperar su aprobación.
Ver Plantilla
Al momento de tener la arquitectura completa del primer requisito se la presenta al cliente
para su aprobación. Esto se consigna en un documento para tener certeza de lo que se
pide y empezar con el desarrollo.
4.
FASE DE DESARROLLO
A4.1: Implementar o modificar Componente(s) con base a la parte detallada de la
Especificación del Sistema.
Listar catálogo:
Agregar libro:
Editar libro:
Ver libro:
A4.2. Incorporar Software a la Configuración de Software.
La configuración de software es el conjunto consistente de productos de software, que
incluye: Especificación de Requisitos, Especificación del Sistema, Software, Prototipo de
la Interfaz de Usuario.
A4.3. Integrar los componentes en subsistemas.
Se integran en un solo módulo los subsistemas mostrados en A4.1 para generar el
software como tal.
5.
FASE DE PRUEBAS
A5.1. Diseñar los casos de prueba de aceptación del sistema .
Ver Plantilla
Realizar casos de prueba de aceptación de un sistema en general es una actividad
primordial para el desarrollo de cualquier componente o subsistema de dicho sistema. En
este documento se plasmarán unos sencillos casos para verificar la calidad del producto.
A5.2. Ejecutar los Casos de prueba de aceptación del sistema.
Se ejecutan los casos de prueba definidos en la actividad A5.1 para comprobar los
posibles defectos que el sistema pueda presentar para su posterior corrección.
A5.3. Validar y corregir los defectos encontrados
Ver Plantilla
Así como es importante realizar casos de prueba y plasmarlos en un documento, también
lo es realizar un reporte de lo ocurrido en el momento de ejecutar dichos casos. En este
documento se muestra que ocurre en determinados casos y cuál es la acción se toma.
A5.4. Elaborar un Manual de Usuarios del sistema
El manual de usuario no se lo elaborará por el momento ya que sólo se ha terminado un
requisito. Cuando se tenga la aplicación completa ya se lo realizará.