INGENIERÍA WEB

1. Problema

Se requiere una webapp para un evento de software, un sistema de inscripciones donde gestione

los registros de los inscritos a dicho evento, la webapp tiene que realizar el CRUD (guardar,

actualizar, insertar, eliminar), en la ficha de registro se requieren ingresar mínimo los siguientes

datos:

Nombres
Apellidos
Correo
Cédula (validación de la cedula)
Dirección
Teléfono
Cargo
Curso
Taller (Taller1, taller2, taller3) un inscrito puede inscribirse a uno o varios talleres

Con base a los requerimientos anteriores desarrolle y documente todas las fases que tiene la

metodología para la creación de las webapp, para esta documentación ser presentada como

entregable final.

2. Fase de Creación

2.1 Captura de requisitos

La propuesta de aplicación web guarda características de simplicidad, por tanto para el análisis y

la planificación se desarrollara bajo la técnica de entrevistas como método idóneo para la captura

de requisitos. Así se ha iniciado estas entrevistas con los patrocinadores y demás interesados del

proyecto a fin de obtener los requerimientos; por ahora estos procesos se los llevaba en forma

manual.

2
2.1. Requisitos:

Datos.- Los datos a ser registrados deben actualizarse inmediatamente en todo

el sistema por lo que su integridad es la mayor prioridad a tener en cuenta.

Interfaz.- El sistema deberá presentar el formulario de registro de los inscritos en

los talleres como principal funcionalidad y el resto de funcionalidades deben estar

“alrededor” de esta.

Navegación.- La navegación del sistema debe ser 100% responsive y debe contar con

soporte para tablets de 7’’ en adelante (la navegación por teléfonos móviles no se requiere).

A nivel de usuario, la navegación de ser lo más simple posible, teniendo formatos de una

sola página en lo posible y no sobrecargando ménus y opciones.

2.2. Requerimientos Funcionales.-

Nro. de Requisito Descripción

R1 Ingresar datos de inscripciones
R2 Guardar datos de inscripciones
R3 Actualizar datos de inscripciones
R4 Eliminar datos de inscripciones

2.3. Requerimientos no funcionales.- La plataforma deberá ser compatible con los

principales navegadores y garantizar un completo soporte sobre distintos sistemas

operativos (Windows, Mac, GNU/Linux).

Al ser una webapp, deberá ser accesible ya sea por red local con un servidor en la propia red o

directamente por internet, contando con métodos de seguridad básicos como protocolo hhtps.

Su desarrollo contará con buena documentación y que sean libres y de código abierto.

La base de datos principal a usarse también será libre y de código abierto y su administración se lo

realizara desde Xampp control panel v3.2.2.

3
3. Fase de Planificación

3.1 Selección de Software.- En base a los requerimientos antes mencionados se han

determinado los siguientes componentes de software a usarse por el equipo de desarrollo:

 Lenguaje de programación JavaScript.

 Se podrá cualquier compilador como CoffeScript o Backbone si el equipo o un
desarrollador lo desea.
 Framework MeteorJS.
o Contiene servidor web basado en Socket.io con soporte para
protocolo seguro y muchas seguridades generales.
o Permite definir por cuenta propia el modelo de la aplicación (MVC,
MVVC, etc) o crear una nueva o simplemente no usar ninguna en
específico.
o Permite usar el mismo lenguaje (JavaScript) tanto para frontend
como para backend, o al ser JS pone a disposición el uso directo de
otros frameworks frontend como AngularJS.
o Cuenta con administración nativa del motor de bases de datos no
relacionales MongoDB.
 Base de datos MongoDB.
 Sistema de control de versiones GIT.
Tabla Nro.1 Componentes de Software

3.2 Selección de hardware

 Servidor HP Proliant ML110 Gen9

Tabla Nro.2 Componentes de Hardware

3.3 Equipo de trabajo

Rol Nombre
Arquitecto software Carlos Egüez
Analista Carlos Egüez
Desarrollador Carlos Egüez
Tester Carlos Egüez

 Arquitecto software: Diseña la base de datos, define las capas, protocolos y sistemas de

seguridad que la plataforma tendrá soporte.

 Analista: Genera, documenta y verifica la efectividad de los casos de uso.

 Desarrollador: Codifica la aplicación de acuerdo a los casos de uso y las indicaciones

del arquitecto de software.

4
  Tester: Verifica la completa ejecución de los casos de uso a nivel de usuario. Ejecuta la

aplicación en busca de bugs y reporta sobre ellos indicando si se tratan de pruebas

unitarias, de integración, etc.

3.4 Estructura de navegación:

La aplicación web se compone de una página de inicio que contiene el formulario para el registro
(ingresar), con cuatro páginas de contenido o secundarias con indicaciones o ayuda. Dado que es
una aplicación sencilla, se utilizará una estructura jerárquica. Las relaciones de las páginas entre sí
configuran la estructura del sitio A partir de la página de inicio se vinculan mediante enlaces al
resto de las páginas mediante código HTML.

3.5 Fase de Contenido:

La aplicación web básicamente comprende el formulario de registro de datos

personales, para ingresar a los participantes, un menú de eliminar; ambas funciones nos
mostrará el formulario para validar, guardar o eliminar los datos del registro. En una tabla
despliega las personas inscritas y en la parte inferior nos muestra un formulario para
modificar, actualizar cualquier registro.

3.6 Fase de Diseño

3.6.1 Conceptual

Esta aplicación está enfocada a la captura de datos personales, es por ello que se
creará una matriz de datos en forma de formulario para que el usuario sepa lo que tiene que
escribir en cada campo; Existirá un botón llamado Ingreso, al presionar el botón, se
almacenará la información en la base de datos.

En la página principal, existirá un enlace a una página de ayuda, en ella se mostrará

información en mayor detalle, la información requerida y sus restricciones. Debe existir
un enlace para regresar a la página de inicio.

5
3.6.2 Diseño Navegacional

Considerando que el requerimiento es la captura de datos y se hará mediante un

formulario, la ubicación de los campos será secuencialmente en un orden vertical (en forma de

bloque); tal y como se muestra en la Gráfica nro. 2 y 3. A continuación se encontrará el formulario

de registro de datos y finalmente, un botón Ingreso, el mismo que ejecutará el script que graba la

información en la base de datos.

3.6.3 Diseño de Interfaz

El contenido de la aplicación es corto y simple y claro, lo que evitará confusiones al

usuario. En la página principal se encuentra información de los inscritos. Adicionalmente se

encuentra el formulario para el ingreso de la información personal de registro. La idea es que

la página sea sencilla pero llamativa; sin contenido pesado que haga lenta la navegación en la

misma; debemos tomar en cuenta que el objetivo de la aplicación es el registro de información de

los usuarios, y será diseñada con orientación a cumplir dicho objetivo.

3.6.4 Usabilidad y Accesibilidad

La usabilidad del sistema está hecho de la forma más sencilla posible solamente se

necesita llenar los campos requeridos y guardar, eliminar o modificar. Para consultar únicamente

damos “click” en inscritos dentro del menú principal y nos despliega la tabla de los estudiantes,

participantes inscritos.

6
 Para accesar a la aplicación web, basta con ingresar al internet y abrir la página

institucional y registrarse, para salir únicamente damos “click” en la “x” de la ventana del

navegador.

4. Fase de Programación

4.1 Selección de recursos

El lenguaje de desarrollo utilizado es JavaScript en la última versión disponible y

manteniendo su actualización a lo largo del proceso de desarrollo. Como gestor de base de datos

se utilizó MongoDB; y como servidor web se usa el nativo del framework MeteorJS.

4.2 Diseño de la base de datos

Al trabajarse con una base de datos no relacional, se tiene la posibilidad de cambiar en

cualquier momento la definición de los documentos (tuplas en bases relacionales) y de sus

colecciones (tablas en bases relacionales) permitiendo así que se parta de la necesidad inicial de

la información de un registro y que conforme avance el desarrollo el arquitecto diseñe las

colecciones y documentos que se vayan requiriendo.

4.3 Modularidad del software

Capa Uno

Base de datos MongoDB

Lenguaje de Programación Javascript (se da por sentado el uso de HTML y CSS para la parte
visual)

Capa Dos

Diseño físico de la base de datos (leer el apartado 5.1)

Capa Tres

Código de la aplicación.

7
5. Fase de Testeo

5.1 Caso de Prueba 1.

Se inserta los datos del formulario correctamente.

Resultado:

Cuando es ingresado los datos necesarios al formulario estos se ingresan a la base de datos.

5.2 Caso de Prueba 2.

Título: Insertar los datos del formulario con cedula en blanco y existente, nombres en blanco.

Resultado:

La aplicación realiza una validación AJAX, a fin de hacerlo de forma asincrónica sin

necesidad de recargar la página del navegador; esto en caso de que los campos cedula y

nombres sean enviados en blanco; o, en caso que los datos hayan sido llenados correctamente

la aplicación hace una consulta a la base de datos para verificación de si existe este registro;

de ser así el caso, mostrará un mensaje de: “Cedula ya existe” y vuelve a formulario.

5.3 Caso de Prueba 3.

Título: Consulta de registros en base de datos.

Resultado:

Muestra todos los datos de la base de datos en una tabla.

5.4 Caso de Prueba 4.

Título: modificar datos de registro.

Resultado:

Muestra todos los datos de la base de datos modificados en una tabla.

5.5 Caso de Prueba 5.

Título: borrar datos de registro.

Resultado:

8
 Muestra todos los datos de la base de datos en una tabla actualizada, sin el registro que fue

borrado

9. Referencias bibliográficas
1.- http://www.hablandoencorto.com/2014/03/herramientas-seo-analisis.html
2.- https://www.meteor.com/
3.- http://es.slideshare.net/rpedraza/pedraza-blancocodinacavaller2013-
especificacionrequisitosweb
4.- https://velocity.readme.io/
5.- https://www.mongodb.org/
6.- http://www.websa100.com/blog/2013/05/26/el-testeo-la-mejor-forma-de-rentabilizar-el-e-
mail-marketing