SISTEMA WEB DE GESTIÓN DE DOCUMENTACIÓN Y Seguimienoto

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
PROYECTO DE GRADO
SISTEMA WEB DE GESTIÓN DE DOCUMENTACIÓN Y

SEGUIMIENTO DE TRÁMITES BASADO EN BPM
CASO: SERVICIO NACIONAL DEL SISTEMA DE REPARTO
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA

MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS
POSTULANTE: KAREN ELIZABETH SALAZAR CARPIO
TUTOR METODOLÓGICO: M. SC. ALDO RAMIRO VALDEZ ALVARADO
ASESOR: M. SC. MOISÉS MARTIN SILVA CHOQUE
LA PAZ – BOLIVIA
2015
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
CAPÍTULO 11. MARCO INTRODUCTORIO
1.1 INTRODUCCIÓN
La documentación representa la mayor parte de la inteligencia de una organización
representando la memoria de la entidad por ello las empresas e instituciones públicas y
privadas desarrollan un enfoque disciplinado para el resguardo de la información. Es por ello
que representa a uno de los activos más valiosos de la empresa y, al igual que con cualquier
activo, debe protegerse totalmente, administrarse meticulosamente y ser fácilmente
accesible.
Sin embargo, a medida que crece la empresa, también lo hace el volumen de su información,
difícilmente de controlar, especialmente cuando los colaboradores aplican sus propios y
distintos métodos de archivar. Sin poder acceder a su información inmediatamente,
desperdiciando tiempo valioso en buscar documentos que saben que existen pero que no
pueden encontrar, lo que por último producirá ineficiencia a nivel empresarial, en
consecuencia, las decisiones de negocios se ven afectadas debido a la incapacidad de obtener
rápidamente la información necesaria.
Mediante la administración de la información se puede revolucionar la capacidad para
capturar, archivar, recuperar, editar y procesar rápidamente los documentos y procesar
rápidamente los documentos y la información de forma segura y eficiente, ayudando a
mejorar la productividad y reducción de los costos.
Cada empresa tiene procesos de negocios críticos que generalmente se dividen en tareas
individuales, se distribuyen y dependen del rendimiento puntual de numerosas personas.
La clave para mantener el flujo constante de los procesos de negocios críticos se fundamenta
en un diseño inteligente, transparente y responsable. Es importante contar con una
herramienta para el apoyo del sostenimiento e impulso para el crecimiento a través de la
mejora continua, ayudando a que la empresa trabaje más inteligentemente al conectar a las
personas y a los procesos con la información.
1.2 ANTECEDENTES
1.2.1 ANTECEDENTES INSTITUCIONALES
El Servicio Nacional del Sistema de Reparto (SENASIR) es un organismo operativo,
administra las prestaciones de largo plazo del Sistema de Reparto, tiene como misión otorgar
y pagar prestaciones del Sistema de Reparto y reconocer aportes para la Compensación de
Cotizaciones para una jubilación más digna. [Decreto Supremo N° 27066,2003]
La misión: “Servicio Nacional del Sistema de Reparto (SENASIR)”, otorgar y pagar

prestaciones del Sistema de Reparto y reconocer aportes para la Compensación de
Cotizaciones para una jubilación más digna. [Portal Web SENASIR, 2014]
La visión: “Servicio Nacional del Sistema de Reparto (SENASIR)”, ser una institución con
compromiso social, respeto a la identidad plurinacional que innova y aporta al vivir bien.
[Portal Web SENASIR, 2014]
La institución al ser de naturaleza exclusivamente operativa, tiene las siguientes atribuciones:

 Resolver sobre el derecho de renta, en caso que le correspondería al derechohabiente
del Rentista titular del Sistema de Reparto.
 Suspender provisional o definitivamente la renta, dentro de la potestad de revisión
establecida en disposiciones que rigen para el Sistema de Reparto.
 Establecer la representación legal en las acciones comenzadas por o contra del
SENASIR, así como continuar con los procesos judiciales seguidos por la ex Dirección
de Pensiones.
 Realizar labores de fiscalización por aportes devengados del Sistema de Reparto.
 Realizar la gestión de cobro de las contribuciones en mora del Sistema de Reparto, en
el marco de las disposiciones normativas en vigencia.
La Entidad posee una jerarquía de unidad de funcionamiento con la finalidad de organizar,

planear, controlar y dirigir los objetivos de la institución, la siguiente estructura orgánica
muestras los niveles del SENASIR.
2
DIRECTOR GENERAL
EJECUTIVO
Secretaria general Auditoría interna
Comisión nacional de
prestaciones del Planificación
sistema de reparto
Unidad Unidad de Unidad Unidad Jurídica Unidad

Nacional de Fiscalización y Cobro Tecnologías de Administrativa
Operaciones de Adeudos Información Financiera
Área de Recursos de
Reclamación
Área Soporte e Área de
Área Área Fiscalización
Infraestructura Contabilidad
Pagos
Tecnológica
Área Coactivo Social
Área Área de
Área de Área Procesamiento
Cobro de Presupuestos
Reparto de Prestaciones
Adeudos Área de Procesos
Judiciales y Trámites
Área Administrativos Área
Área Seguimiento
Operativa Área de Tesorería
de Descargos
Análisis y
Desarrollo de
Área de Bienes y
Sistemas
Servicios
Unidad
Compensación de Unidad
Cotizaciones Desarrollo
Administraciones Organizacional
Área Regionales
Registros y
Observados Área Organización
Agencias y Métodos
Área Emisión, Regionales
Novedades y Doble
Percepción Área Gestión de
Talento Humano y
Área de Capacitación
Certificación
y Archivo
Área de
Central
Procesamiento de
planillas
Figura 1.1. Organigrama del SENASIR

Fuente: Servicio Nacional del Sistema de Reparto (SENASIR)
3
1.2.2 ANTECEDENTES DE PROYECTOS SIMILARES
Los proyectos de grado extraídos de la biblioteca de la carrera de Informática de la
Universidad Mayor de San Andrés coadyuvarán en la realización del presente proyecto para
obtener una referencia documental relacionados con el manejo de la correspondencia en
distintas entidades sean públicas o privadas, las mismas de describen a continuación.
 Sistema de Registro de Correspondencia para la Compañia Boliviana de Energia Electrica
S.A. COBEE-BCP, elaborado por Carlos Javier Arancibia Ramos el año 2004, tiene por
objetivo realizar un sistema de registro de correspondencia enfatizando la reingenieria del
proceso de manejo de la correspondencia con herramientas de la BPR o reingenieria de
procesos de negocios, realizando una evaluacion de la Base de Datos y utilizando el
proceso de mineria de datos para obtener información que se necesite por la gerencia de
la compañia.
 Chasqui Digital E-Correspondencia para la Facultad de Ciencias Puras y Naturales,
realizado por Aleida Raquel Ibañes Apaza el año 2008, que realiza el diseño de un
workflow o reingenieria de procesos de negocios para automatizar las tareas de recepcion,
control, seguimiento y remision de correpondencia de acuerdo a un conjunto de reglas
procedimentales, realizando el proceso de diseño con la metodologia RUP y lenguaje de
modelado UML, usando además el framework PRADO que basado en el manejo
componentes y la administracion de eventos permite agilizar el proceso de desarrollo de
aplicaciones Web con PHP5.
 Sistema de envío y recepcion de documentos para la Fuerza Area Boliviana realizado por
Gabriela Surco Aguilar el año 2009, que realiza el diseño de un sistema de automatización
del proceso de registro, recepción y despacho de documentos utilizando RUP, UML y
OOHDM (Metodologia de Diseño de Hipermedia Orientado a Objetos) que es una mezcla
de estilos de desarrollo de prototipos donde se contempla los objetos que representa la
navegación como vistas de los objetos detallados en el modelo conceptual, el uso de
abstracciones apropiadas para organizar los aspectos de la navegación y que divide la
navegación en cuatro actividades: modelos conceptual, diseño de la navegación, diseño
de interfaz abstracta e implementación.
4
 Sistema Web de registro, seguimiento y control de correpondencia basado en BPM para
la Carrera de Informática elaborado por Alan Rodrigo Corini Guarachi el año 2014, con
el propósito de brindar una herramienta que coadyuve con las tareas de registro, control y
seguimiento de la correspondencia interna mediante la metodología AUP que contempla
la fase de inicio, elaboración, construcción y transición. Además de la implementación de
BPM articulando los procesos y la tecnología para generar un valor agregado al negocio.
Cabe mencionar que la institución maneja el Sistema de Administración y Registro de
Correspondencia (SARCO) desarrollado por el Área de Análisis y Desarrollo de Sistemas
dependiente de la Unidad de Tecnologías de la Información el año 2010, para el proceso de
registro de la correspondencia externa que ingresa a la institución.
1.3 PLANTEAMIENTO DEL PROBLEMA

Al realizar el análisis del funcionamiento del Sistema de Administración y Registro de
Correspondencia (SARCO) dentro de la institución, se evidenció que el proceso es realizado
semi manual, además de no coadyuvar en la comunicación entre las unidades produciendo
demora en la respuesta y a su vez repercutiendo con el proceso de negocio de la institución.
1.3.1 PROBLEMA CENTRAL

¿Cómo mejorar el seguimiento del proceso de respuesta de la correspondencia para atender
oportunamente las solicitudes internas y externas generadas constantemente?
1.3.2 PROBLEMAS SECUNDARIOS

Los problemas secundarios establecidos en el proyecto son:
 La información de la documentación emitida por las unidades dependientes del
SENASIR se encuentra dispersada en libros manuales ocasionando desconocimiento
en el seguimiento del proceso de respuesta.
 Reasignación de correlativos a un documento que llega más de una vez a una unidad
a pesar de contar anteriormente con un correlativo único haciendo un mal uso de los
mismos.
 Generación de correlativos duplicados dentro de una misma unidad, lo que impide
realizar un adecuado seguimiento de la documentación generada.
5
 No existe medidas alertivas para coadyuvar con el cumplimiento del plazo de
respuesta, por lo que la correspondencia puede ser contestada con demora o incluso
nunca ser atendida.
 No existe relación del proceso del trámite con la correspondencia que es entregada
por el titular de la renta, derecho habiente y/o apoderado a las oficinas del SENASIR
impidiendo realizar un adecuado seguimiento.
 No existe control en la generación de documentos emitidos por los funcionarios de
cada unidad con la respectiva aprobación del Jefe de Unidad.
1.4 DEFINICIÓN DE OBJETIVOS
1.4.1 OBJETIVO GENERAL

Desarrollar un Sistema Web de Gestión de Documentación y Seguimiento de trámites,
basado en el Gestión de Proceso de Negocio o Business Process Management (BPM)
brindado una respuesta con celeridad asegurando el control absoluto e instantáneo de la
documentación.
1.4.2 OBJETIVOS ESPECÍFICOS

Los objetivos especificos para el presente proyecto son:
 Centralizar la información de la documentación emitida por las diferentes unidades,
administradoras, agencias para atender oportunamente los requerimientos solicitados.
 Posibilitar el reingreso del documento que cuenta con un número de hoja de ruta que
llega más de una vez a una misma unidad para no generar un nuevo correlativo.
 Utilizar correlativos conformados por la sigla de la unidad y un número único para
controlar la emision de los cites para su posterior seguimiento.
 Elaborar alertas preventivas sobre el estado de la documentación para realizar el
cumplimiento de las actividades dentro de la institución.
 Relacionar el seguimiento del trámite con la correspondencia entregada por el
beneficiario para conocer el estado en el que se encuentra.
6
 Controlar la generación de los cites de los documentos que fueron remitidos por los
funcionarios de una unidad con la respectiva aprobación del Jefe de Unidad y/o
Administrador.
1.5 JUSTIFICACIÓN
1.5.1 JUSTIFICACIÓN ECONÓMICA

El sistema desarrollado coadyuvará en mejorar la administración de los recursos fisicos
proporcionados por el estado para el buen desempeño en las actividades laborales y la
atención a los beneficiarios. Mediante el sistema se obtendrá información confiable y
accesible evitando la utilización de libros o archivadores de registro de cites, reduciendo el
gasto económico en el material de escritorio proporcionado a cada unidad.
Con respecto a las licencias, el sistema se encuentra desarrollado mediante el lenguaje de
programación “php” bajo el estándar de licencia libre, trabajará con el sistema operativo
Linux y el gestor de la base de datos “Sql Server”, la licencia fue adquirido anteriormente
por la entidad, por ello no implicaría un gasto la implementación del sistema de
correspondencia teniendo en cuenta que la institución cuenta con la infraestructura, intranet
y servidores que albergan los actuales sistemas que estan en funcionamiento.
1.5.2 JUSTIFICACIÓN SOCIAL

En una investigacion exploratoria se vio la necesidad de contar con un sistema interno de
correpondencia para el SENASIR que ayude en el registro, control y seguimiento de la
documentación, desde que ingresa hasta el despacho por las unidades involucradas.
El ámbito de impacto abarcará a los beneficiarios que esten en curso de trámite,
permitiéndoles realizar el seguimiento de la correspondencia emitida e incrementará el
rendimiento de los funcionarios públicos al contar con una herramienta que coadyuve al
control minucioso y constante de toda solicitud que ingrese a la entidad y además de tener
un control estratégico en la toma de decisiones a los altos niveles gerenciales.
El sistema desarrollado ayudará a la Unidad de Correspondencia a realizar las asignaciones
a cada área alertando en caso que el funcionario destinatario se encuentre de vacaciones para
no obstaculizar el flujo normal del proceso de respuesta e incluso generar reportes de
7
asignaciones utilizados para el respaldo de las asignaciones realizadas por las secretarias de
cada unidad.
1.5.3 JUSTIFICACIÓN TECNOLÓGICA

Se trata de una técnica que aumenta considerablemente la velocidad de desarrollo de los
programas debido a la reutilización de los objetos. El elemento principal de la programación
orientada a objetos es el objeto Ajax al ser una técnica que trabaja de forma asíncrona.
La utilización del framework Codeigniter, para el desarrollo de aplicaciones en php, de esta
manera separar la lógica del negocio con la arquitectura de la web. Además de reutilizar
código en múltiples módulos del sistema con la premisa de programación orientada a objetos
para obtener código compacto, entendible y sencillo de mantener.
Se utiliza AngularJS para el desarrollo de los frontend (lo que ve el usuario final)
comunicándose con CSS, HTML, JavaScript para minimizar las peticiones de las llamadas
al servidor.
El gestor de la base de datos es SQL Server 2008 y para acceder de forma efectiva a la base
de datos desde un contexto orientado a objetos, es necesaria una interfaz que traduzca la
lógica de los objetos a la lógica relacional.
1.6 ALCANCES Y LÍMITES
1.6.1 ALCANCES
El sistema será capaz de realizar las siguientes tareas mencionadas:
 Registro de la Correspondencia, que permitirá ingresar la información con respecto
al documento recepcionado, debido a su importancia los datos registrados deben tratar
de ser lo más explicitos posibles para evitar extravios.
 Asignación de la Correspondencia, que designará a unidad y al responsable quien
emitira una respuesta en caso de ser necesario.
 Modificación del Registro de la Correspondencia, que permitirá corregir cualquier
error de redacción o transcripción al momento de ingresar los datos. Solamente
cuando el mismo lo haya realizado y no asi la correspondencia registrada por otros
usuarios.
8
 Seguimiento de la Correspondencia, que se encargará de dirigir el estado de la
correspondencia desde el momento en que se registra hasta el momento en que se
archiva. Se controlara las unidades por las cuales un determinado documento ha
pasado asi como las fechas y el tiempo que permanecio un documento en una unidad.
 Notificación, que se realizará a través de alertas antes que el plazo de respuesta vaya
a finalizar.
 Culminación de la Correspondencia, que será utilizada para finalizar la nota asignada
asi mismo registrar datos relevantes para el archivo de la documentación.
1.6.2 LÍMITES
El presente proyecto de grado contemplará como límites a los siguientes puntos.
 No se logrará adoptar sanciones con respecto a la correspondencia que no haya sido
atendida.
 El sistema no dará respuesta en caso de que la correspondencia quedará pendiente de
atención.
 El sistema no tomará en cuenta a las agencias regionales que no tuviesen el acceso al
internet.
 El sistema únicamente sera aplicado a las unidades y/o áreas dependientes del
SENASIR.
1.7 APORTES
1.7.1 PRÁCTICO
Al implementar el enfoque disciplinado Business Process Management BPM se orienta a los
procesos de negocio, personas y tecnologias de informacion mejorando toda la institucion e
identificando los puntos debiles y fortaleciendo las actividades importantes.
La institución podrá dar una respuesta oportuna con respecto a las solicitudes que llegan a la
institución brindando una herramienta que realice el constante control así mismo aumentando
la productividad, mejorando la atención y el servicio a los jubilados.
9
1.7.2 TEÓRICO
En este tipo de procesos, los documentos, o mejor dicho la información que proporcionan los
documentos, y el movimiento de los mismos a través de los departamentos de la
organización, son importantes.
Los procesos gestionaran el conocimiento de una organización, es decir todo la
documentación de solicitudes. Por ello aplicar un sistema de workflow a procesos de negocio
de este tipo supone convertir el conocimiento en un valor de primer orden.
1.8 METODOLOGÍA
En el desarrollo del sistema web se utilizará el método científico, al ser un conjunto de
procedimientos racionales para alcanzar los objetivos de la investigación mediante técnicas
de observación, reglas para el razonamiento y los modos de comunicar los resultados
experimentales y teóricos.
Así mismo se usará la investigación exploratoria, considerada como el primer acercamiento
científico a un problema, siendo una metodología idónea para un problema que todavía no
ha sido abordado para luego pasar a la investigación descriptiva y representar todos los
componentes del proyecto.
La metodología de software para el presente trabajo es la Programación Extrema XP con sus
respectivas cuatro fases que contemplan la planificación, diseño, desarrollo y pruebas.
Permitiendo un desarrollo de software inmediato y además de contar con una tecnología que
permita la reutilización de código.
El método que se aplicará para el desarrollo del sistema web es IFML orientado para aquellas
aplicaciones que tienen una alta interacción de datos, donde el factor más importante es el
desarrollo de la interfaz de usuario. La difusión de ésta metodología beneficia al desarrollo,
simplifica y agiliza sus ciclos, pero también facilita a las personas menos técnicas a enfocarse
en el análisis e involucrarse en el proceso de desarrollo de las aplicaciones, colaborando
activamente con el equipo de tecnologías.
10
CAPÍTULO 22. MARCO TEÓRICO
2.1 INGENIERÍA DE SOFTWARE
IEEE1 define a la Ingeniería del Software como: “La aplicación de un enfoque sistemático,
disciplinado y cuantificable al desarrollo, operación y mantenimiento del software” [HANS
V. 2002].
La ingeniería de software es una disciplina que concierne a todos los aspectos de la
producción del software. En la construcción y desarrollo de proyectos se aplican métodos y
técnicas para resolver los problemas, la informática aporta herramientas y procedimientos
sobre los que se apoya la ingeniería del software.
Los objetivos de la Ingeniería del Software son:
 Mejorar la calidad de los productos de software
 Aumentar la productividad y trabajo de los ingenieros del software
 Facilitar el control del proceso de desarrollo de software
 Suministrar a los desarrolladores las bases para construir software de alta calidad en
una forma eficiente.
 Definir una disciplina que garantice la producción y el mantenimiento de los
productos software desarrollados en el plazo fijado y dentro del costo estimado.
La ingeniería de software se relaciona con varias disciplinas como Gerencia, Matemáticas,
Gestión de proyectos, Gestión de calidad, Ingeniería de sistemas, Ergonomía del software.
Abarca un conjunto de áreas del conocimiento que son la base fundamental para el diseño de
un proyecto software; estas áreas son: Requerimientos, Diseño, Construcción, Pruebas,
Mantenimiento, Gestión de la configuración, Gestión de la Ingeniería, Procesos de
ingeniería, Herramientas y Calidad del software.
A continuación se detallan las más importantes. [HANS V. 2002]
 Requerimiento de Software, un requerimiento se define como una exigencia que
debe ser cumplida para dar solución a un problema del mundo real. Contiene áreas
1
Instituto de Ingenieros Eléctricos y Electrónicos (Institute of Electrical and Electronics Engineers) es la Asociación Internacional sin
ánimo de lucro formada por profesionales de las nuevas tecnologías, dedicada a la estandarización.
11
como: especificación de requerimientos, análisis, validación, clasificación y
negociación.
 Diseño del software, es el proceso de definir la arquitectura, componentes, interfaces
y otras características relativas al sistema como: fundamentos claves en el diseño,
estructura y calidad, son algunas de las áreas secundarias que comprende el diseño
del software.
 Construcción del software, se refiere a la creación detallada de un sistema software
a través de la combinación de codificación, verificación, pruebas de unidad, pruebas
de integración y depuración.
 Pruebas del software, consiste en la verificación dinámica del comportamiento de
un software ante un conjunto limitado de casos de pruebas. Contiene áreas como:
niveles de pruebas y técnicas de pruebas.
 Mantenimiento de software, las actividades de mantenimiento comienzan
teóricamente cuando el producto final es terminado, pero en la práctica empieza desde
etapas mucho más tempranas, debido a los cambios en las necesidades del usuario a
las que la aplicación debe adaptarse.
2.2 CICLO DE VIDA DE DESARROLLO DEL SOFTWARE
El ciclo de vida denominado paradigma es el conjunto de fases por las que pasa el sistema
que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o
remplazado.
Entre las funciones que debe tener el ciclo de vida se pueden destacar:
 Determinar el orden de las fases del proceso de software
 Establecer los criterios de transición para pasar de una fase a la siguiente.
 Definir las entradas y salidas de cada fase.
 Describir los estados por los que pasa el producto.
 Describir las actividades a realizar para transformar el producto.
 Definir un esquema que sirve como base para planificar, organizar, coordinar y
desarrollar.
12
2.3 MODELOS TRADICIONALES
La ingeniería del software establece y se fundamenta de una serie de modelos que muestran
las distintas etapas, estados por los que pasa un producto de software, desde su concepción
inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la
retirada del producto.
A estos modelos se les denomina “Modelos de Ciclo de Vida del Software”.

[SOMMERVILLE I. 2001]
Un modelo de ciclo de vida del software, describe las fases principales de desarrollo de
software. Existen varias alternativas de modelos de ciclo de vida y la elección para un
determinado proyecto es de suma importancia.
A continuación se muestran algunos de los modelos tradicionales, más utilizados.

[SOMMERVILLE I. 2001]
2.3.1 MODELO EN CASCADA

El modelo cascada es también llamado ciclo de vida clásico, fue uno de los primeros modelos
para la creación del software, es uno de los modelos más simples y conocidos.
El modelo en cascada denominado así por la posición de las fases que parecen caer en cascada
por gravedad hacia las siguientes fases, es el enfoque metodológico que ordena
rigurosamente las etapas del proceso para el desarrollo del software, de tal forma que el inicio
de cada etapa debe esperar a la finalización de la etapa anterior.
Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final que se
encarga de determinar si el proyecto está listo para avanzar a la siguiente fase.
Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de
vida. La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente
revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.
13
Figura 2.1. Modelo en Cascada
Fuente: Benefield, 1956
2.3.2 MODELO ITERATIVO

El desarrollo iterativo es un proceso de desarrollo de software, creado en respuesta a las
debilidades del modelo tradicional de cascada. Este modelo busca reducir el riesgo que surge
entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de
recogida de requisitos. [PRESSMAN, 2014]
Figura 2.2. Modelo Iterativo

Fuente: Pressman, 2005
14
Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le
entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El
cliente es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras.
Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del
cliente.
2.3.3 MODELO EN ESPIRAL

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez
por Barry Boehm en 1988, combinado características del modelo de prototipos y el modelo
en cascada.
El modelo en espiral está pensado para proyectos largos, caros y complicados de clasificar.
Básicamente consiste en una serie de ciclos que se repiten en forma de espiral, donde cada
bucle o iteración representa un conjunto de actividades.
Las actividades no están fijadas por prioridad, sino que las siguientes se eligen en función
del análisis de riesgo, comenzando por el bucle anterior. Para cada ciclo existen cuatro
actividades: determinación de objetivos, análisis de riesgo, planificación, desarrollo y
pruebas.
Figura 2.3. Modelo en Espiral

Fuente: Cota, 1994
15
2.3.4 MODELO DE PROCESO EVOLUTIVO
Los sistemas complejos evolucionan lo cual hace que sea casi interminable un software
perfecto, entonces se realiza una versión limitada con el conjunto de requerimientos básicos,
este tipo de modelos logran que se llegue al objetivo desarrollando prototipos cada vez más
evolucionados debido a que hay constante comunicación con el cliente. [GUTIÉRREZ, D.
2011]
Inicia con la definición de los objetivos globales para el software, luego se identifican los
requisitos conocidos y las áreas del esquema en donde es necesaria más definición y de esta
forma proporcionar una vista preliminar del software.
Este modelo es básicamente prueba y error, en caso de que al usuario no le gustara una parte
del prototipo significaría que se debe corregir el error hasta que el usuario quede satisfecho.
Además el prototipo debe ser construido en poco tiempo, usando los programas adecuados y
no se debe utilizar mucho dinero. La construcción del prototipo nos asegura que nuestro
software sea de mejor calidad, además de que su interfaz sea de agrado para el usuario.
Figura 2.4. Modelo de Prototipos

Fuente: Zachman, 1999
2.4 MANIFIESTO ÁGIL
A principios del 2000 en las montañas Wasatch de Utah, se reunieron diecisiete
desarrolladores convencidos de que era necesario un cambio en las metodologías “clásicas”
de desarrollo de software.
16
Tras esta reunión se creó The Agile Alliance2, es una organización, sin ánimo de lucro,
dedicada a promover los conceptos relacionados con el desarrollo con el desarrollo ágil de
software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de
partida fue el Manifiesto Ágil, un documento que resume la filosofía “ágil”, estableciendo
bajo cuatros principios. [Beck & Beedle.2001].
 Se valora a los individuos y las iteracciones, sobre los procesos y las herramientas.
 Se valora a las aplicaciones que funcionan sobre la documentación exhaustiva.
 Se valora la colaboración del cliente sobre las negociaciones contractuales.
 Se valora la respuesta al cambio sobre el seguimiento de un plan.
A continuación se describen las metodologías ágiles más notables.
 Scrum3
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle, define un marco para la
gestión de proyectos, que se ha utilizado con éxito durante los últimos diez años. Indicada
especialmente para proyectos con un rápido cambio de requisitos, el desarrollo de software
se realiza mediante iteraciones, denominadas sprints con una duración de treinta días
aproximadamente, el resultado de cada sprint es un incremento ejecutable que se muestra al
cliente.
 Crystal Methologies4
Se trata de un conjunto de metodologías para el desarrollo de software centradas en las
personas que componen el equipo y la reducción al máximo del número de artefactos
producidos.
El desarrollo de software se considera un juego cooperativo de invención y comunicación,
limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se
deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de
trabajo en equipo definidas.
2
Traducido al español: La Alianza Ágil Software Development
3
www.controlchaos.com
4
www.crystalmethodologies.org
17
 Dynamic Systems Development Method (DSDM)5
Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el
objetivo de crear una metodología RAD unificada.
Presenta como características un proceso iterativo e incremental y el equipo de desarrollo y
el usuario trabajan juntos. Propone cinco fases: estudio, visibilidad, estudio del negocio,
modelado funcional, diseño, construcción e implementación.
 Adaptive Software Development(ASD)6
La principal característica es ser, orientado a los componentes software más que a las tareas
siendo tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales:
especulación, colaboración y aprendizaje.
En la primera de ellas se inicia el proyecto y se planifican las características del software, en
la segunda se desarrollan las características y finalmente en la tercera se revisa su calidad
para la entrega final al cliente.
 Lean Development(LD)7
Utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD los cambios se
consideran riesgos pero si se manejan adecuadamente se pueden convertir en oportunidades
que mejoren la productividad del cliente. Destacándolo por el mecanismo para implementar
los cambios.
 eXtreme Programming8
La metodología XP define cuatro variables para cualquier proyecto de software: costo,
tiempo, calidad y alcance. Además, se especifica que, de estas cuatro variables, sólo tres de
ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores
(clientes y jefes de proyecto).
El valor de la variable restante podrá ser establecido por el equipo de desarrollo, en función
de los valores dados por el cliente. Este mecanismo indica que, por ejemplo, si el cliente
5
www.dsdm.org
6
www.adaptivesd.com
7
www.poppendieck.com
8
www.extremeprogramming.org
18
establece el alcance y la calidad, y el jefe de proyecto el precio, el grupo de desarrollo tendrá
libertad para determinar el tiempo que durará el proyecto.
2.5 MADUREZ DE SOFTWARE EN METODOLOGÍAS ÁGILES

La Tabla 2.1 compara las distintas aproximaciones ágiles en base a tres parámetros: vista del
sistema como algo cambiante, tener en cuenta la colaboración entre los miembros del equipo
y características más específicas de la propia metodología como son simplicidad, excelencia
técnica, resultados, adaptabilidad entre otros. También incorpora como referencia no ágil el
Capability Madurity Model10 (CMM)
CMM ASD CRYTAL DSDM FDD LD SCRUM XP
Sistema como algo cambiante 1 5 4 3 3 4 5 5
Colaboración 2 5 5 4 4 4 5 5
CARACTERÍSTICAS METODOLOGÍA (CM)
- Resultados 2 5 5 4 4 4 5 5
- Simplicidad 1 4 4 3 5 3 5 5
- Adaptabilidad 2 5 5 3 3 4 4 3
- Excelencia técnica 4 3 3 4 4 4 5 5
- Prácticas de colaboración 2 5 5 4 4 4 5 5
Media CM 2,2 4,4 4,4 3,6 3,8 4 4,2 4
Media Total 1,7 4,8 4,5 3,6 3,6 4 4,7 5
Tabla 2.1. Ranking de Agilidad (Los valores más altos representan una mayor agilidad)
Fuente: INTECO, 2009
Como se observa en la Tabla 2.1, todas las metodologías ágiles tienen una significativa
diferencia del índice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y XP
como las más ágiles.
2.6 DIFERENCIAS ENTRE LAS METODOLOGÍAS TRADICIONALES Y

ÁGILES
Existen distintas propuestas metodológicas para el desarrollo de software. Por una parte
tenemos aquellas propuestas más tradicionales que se centren en el control del proceso,
19
estableciendo rigurosamente las actividades involucradas, los artefactos a producir y las
herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y
necesarias en un gran número de proyectos, pero también han presentado problemas en otros.
La filosofía de las metodologías ágiles consiste en centrarse en otras dimensiones, como por
ejemplo el factor humano o el producto software, las cuales dan mayor valor al individuo, a
la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy
cortas.
En la Tabla 2.2 recoge esquemáticamente las principales diferencias entre metodologías
tradicionales y metodologías ágiles.
Metodologías Ágiles Metodologías Tradicionales
Especialmente preparados para cambios Cierta resistencia a los cambios.
durante el proyecto.
Impuestas internamente (por el equipo de Impuestas externamente.
desarrollo)
Proceso menos controlado, con pocos Proceso mucho más controlado, con
principios. numerosas políticas y/o normas.
No existe contrato tradicional o al menos es Existe un contrato prefijado.
bastante flexible.
El cliente es parte del equipo de desarrollo. El cliente interactúa con el equipo de
desarrollo mediante reuniones.
Grupos pequeños (Menos de 10 integrantes) Grupos grandes y posiblemente
y trabajando en el mismo sitio. distribuidos.
Pocos artefactos Más artefactos.
Pocos roles Más roles.
Menos énfasis en la arquitectura del La arquitectura del software es esencial y se
software. expresa mediante modelos.
Tabla 2.2. Diferencias entre metodologías ágiles y no ágiles.

Fuente: Beck, 2003
20
2.7 METODOLOGÍA DE DESARROLLO DEL SISTEMA
2.7.1 METODOLOGÍA DE DESARROLLO XP (eXtreme Programing)
El ciclo de vida de un proyecto XP incluye, al igual que las otras metodologías, entender lo
que el cliente necesita, estimar el esfuerzo, crear la solución y entregar el producto final al
cliente. Sin embargo, XP propone un ciclo de vida dinámico, donde se admite expresamente
que, en muchos casos, los clientes no son capaces de especificar sus requerimientos al
comienzo de un proyecto. [César F. & Acebal 2002]
Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones), con entregables
funcionales al finalizar cada ciclo. En cada iteración se realiza un ciclo completo de análisis,
diseño, desarrollo y pruebas, pero utilizando un conjunto de reglas y prácticas que
caracterizan a XP.
La metodología XP define cuatro variables para cualquier proyecto de software: costo,
tiempo, calidad y alcance. Además, se especifica que, de estas cuatro variables, solo tres de
ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores
(clientes y jefes de proyectos). El valor de la variable restante podrá ser establecido por el
equipo de desarrollo, en función de los valores de las otras tres.
Figura 2.5. Flujo de Trabajo XP

Fuente: ONESS, 2005
21
Típicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones. La siguiente Figura 2.6
esquematiza los ciclos de desarrollo en cascada e iterativos tradicionales (por ejemplo,
incremental o espiral), comparados con el de XP.
Figura 2.6. Ciclo de Desarrollo Tradicionales

Fuente: Acebal & César, 2002
2.7.2 CICLO DE VIDA DE XP
Si bien el ciclo de vida de un proyecto XP es muy dinámico, se puede separar en fases. Varios
de los detalles acerca de las tareas de estas fases se detallan a continuación. [BECK K. 2003]
2.7.2.1 FASE DE PLANIFICACIÓN

XP plantea la planificación como un permanente diálogo entre la parte empresarial y técnica
del proyecto, en la que los primeros decidirán el alcance – ¿qué es lo realmente necesario
del proyecto? –, la prioridad – qué debe ser hecho en primer lugar –, la composición de las
versiones – qué debería incluir cada una de ellas – y la fecha de las mismas. En cuanto a los
técnicos, son los responsables de estimar la duración requerida para implementar las
funcionalidades deseadas por el cliente, de informar sobre las consecuencias de determinadas
decisiones, de organizar la cultura de trabajo y, finalmente, de realizar la planificación
detallada dentro de cada versión. XP no es sólo un método centrado en el código – que lo es
–, sino que sobre todo es un método de gestión de proyectos software. [BECK K. 2003]
22
La metodología XP tiene un conjunto importante de reglas y prácticas para sus distintas fases.
[BECK, K.2003]
A continuación se describen los conceptos básicos de esta planificación.
a) Historias de Usuarios (User Stories)
El sistema es desarrollado para el cliente, por lo tanto, el usuario es quien decide que tareas
realizará la aplicación. Este planteamiento se desarrolla a lo largo del proyecto: el cliente es
quien decide que hacer. Como primer paso se debe dar una idea clara de lo que será el
proyecto en sí. Las historias de usuario son utilizadas como herramienta para dar a conocer
los requerimientos del sistema al equipo de desarrollo. Son pequeños textos en los que el
cliente describe una actividad que realizará el sistema; la redacción de los mismos se realiza
bajo la terminología del cliente, no del desarrollador, de forma que sea clara y sencilla, sin
profundizar en detalles.
Se puede considerar que las historias de usuario en XP juegan un papel similar a los casos de
uso en otras metodologías, pero en realidad son muy diferentes. Las historias de usuario solo
muestran la silueta de una tarea a realizarse. Por esta razón es fundamental que el usuario o
un representante del mismo se encuentren disponibles en todo momento para solucionar
dudas, estas no proporcionan información detallada acerca de una actividad específica.
Las historias de usuario también son utilizadas para estimar el tiempo que el equipo de
desarrollo tomará para realizar las entregas. En una entrega se puede desarrollar una o varias
historias de usuario, esto depende del tiempo que demore la implementación de cada una de
las mismas.
Historia de Usuario
Número: Usuario:
Nombre Historia:
Prioridad en negocio: Riesgo en desarrollo:
Puntos estimados: Iteración asignada:
Descripción:
Tabla 2.3 Historia de Usuario

Fuente: Beck 2000
23
b) Plan de Entregas (Realease Plan)
Después de tener ya definidas las historias de usuario es necesario crear un plan de
publicaciones, en inglés "Release planning", donde se indiquen las historias de usuario que
se crearán para cada versión del programa y las fechas en las que se publicarán estas
versiones. Un "Release plan" es una planificación donde los desarrolladores y clientes
establecen los tiempos de implementación ideales de las historias de usuario, la prioridad con
la que serán implementadas y las historias que serán implementadas en cada versión del
programa.
Después de un "Release plan" tienen que estar claros estos cuatro factores: los objetivos que
se deben cumplir (que son principalmente las historias que se deben desarrollar en cada
versión), el tiempo que tardarán en desarrollarse y publicarse las versiones del programa y el
número de personas que trabajarán en el desarrollo e indicar cómo se evaluará la calidad del
trabajo realizado.
c) Plan de Iteraciones
Todo proyecto que siga la metodología X.P. se divide en iteraciones, 3 semanas de duración
aproximadamente. Al comienzo de cada iteración los clientes deben seleccionar las historias
de usuario definidas en el "Release planning" que serán implementadas. También se
seleccionan las historias de usuario que no pasaron el test de aceptación que se realizó al
terminar la iteración anterior. Estas historias de usuario son divididas en tareas de entre 1 y
3 días de duración que se asignarán a los programadores.
d) Velocidad del Proyecto
La velocidad del proyecto es una medida que representa la rapidez con la que se desarrolla
el proyecto; estimarla es muy sencillo, basta con contar el número de historias de usuario que
se pueden implementar en una iteración; de esta forma, se sabrá el cupo de historias que se
pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto
controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la
iteración. Es conveniente revaluar esta medida cada 3 o 4 iteraciones y si se aprecia que no
es adecuada hay que negociar con el cliente un nuevo "Release Plan".
24
e) Tarjetas de Clase, Responsabilidad, Colaboración (CRC)
Las Tarjetas de Clase, Responsabilidad, Colaboración (CRC), sirven para dejar el
pensamiento procedimental para incorporarse al enfoque orientado a objetos. Cada tarjeta
representa una clase con su nombre en la parte superior, en la sección inferior izquierda están
descritas las reponsabilidades y a la derecha las clases que le sirven de soporte.
En el proceso de diseñar el sistema por medio de las tarjetas CRC como máximo dos personas
se ponen de pie adicionando o modificando las tarjetas, prestando atención a los mensajes
que éstas se transmiten mientras los demás miembros del grupo que permanecen sentados,
participan en la discusión obteniendo así lo que puede considerarse un diagrama de clases
preliminar.
Un esquema típico de tarjeta CRC puede ser aquel en el que se indiquen los siguientes datos:
Nombre de la clase, Nombre de las superclases y subclases (si procede), las responsabilidades
de la clase, las clases con las que va a colaborar para poder realizar las responsabilidades
indicadas, autor y fecha.
Nombre de la Clase
Responsabilidades Colaboradores
Tabla 2.4. Tarjetas C.R.C

Fuente: Ambler, 2000
2.7.2.2 FASE DE DISEÑO
a) Diseños simples
Una de las partes más importantes de la filosofía XP es la simplicidad en todos los aspectos.
Se considera que un diseño sencillo se logra más rápido y se implementa en menos tiempo,
por lo cual esto es lo que se busca.
La idea es que se haga el diseño más sencillo que cumpla con los requerimientos de las
historias de usuario. En XP se prefiere tener una descripción del sistema o parte de él, en
25
lugar de una serie de complejos diagramas que probablemente tomen más tiempo y sean
menos constructivos.
b) Glosario de términos
Usar glosarios de términos y una correcta especificación de los nombres de métodos y clases
ayudará a comprender el diseño y facilitará sus posteriores ampliaciones y la reutilización
del código.
c) Riesgos
Si surgen problemas potenciales durante el diseño, XP sugiere utilizar una pareja de
desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese
problema.
d) Funcionalidad extra
Nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será
utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el desarrollo de
funcionalidad extra es un desperdicio de tiempo y recursos.
e) Refactorizar
Como se trató al principio de este apartado, el diseño es una tarea permanente durante toda
la vida del proyecto y la refactorización concreta este concepto. Como en cualquier
metodología tradicional en XP se inicia el proceso de desarrollo con un diseño inicial. La
diferencia es que en las metodologías tradicionales este diseño es tan global y completo como
se es posible tomando generalmente mucho tiempo en lograrse y con la creencia de que si se
ven forzados a modificarlo será un fracaso para el grupo de desarrollo. El caso de XP es el
opuesto. Se realiza un diseño muy general y simple que no debe tardar en conseguirse, al cual
se hacen adiciones y correcciones a medida que el proyecto avanza, con el fin de mantenerlo
tanto correcto como simple.
2.7.2.3 FASE DE CODIFICACIÓN

La codificación es un proceso que se realiza en forma paralela con el diseño y la cual está
sujeta a varias observaciones por parte de XP consideradas controversiales por algunos
expertos tales como la rotación de los programadores o la programación en parejas.
26
A continuación una descripción de los siguientes temas: cliente siempre presente, codificar
primero la prueba, integración secuencial e integraciones frecuentes.
a) Cliente siempre presente
Es una parte más del equipo de desarrollo, su presencia es indispensable en las distintas fases
de XP. A la hora de codificar una historia de usuario su presencia es aún más necesaria. No
olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos
en los que serán implementadas. Antes del desarrollo de cada historia de usuario el cliente
debe especificar detalladamente lo que ésta hará y también tendrá que estar presente cuando
se realicen los test que verifiquen que la historia implementada cumple la funcionalidad
especificada.
b) Codificar primero la prueba
Crear test que prueben el funcionamiento de los distintos códigos implementados nos ayudará
a desarrollar dicho código. Crear estos test antes nos ayuda a saber qué es exactamente lo que
tiene que hacer el código a implementar y sabremos que una vez implementado pasará dichos
test sin problemas ya que dicho código ha sido diseñado para ese fin. Se puede dividir la
funcionalidad que debe cumplir una tarea a programar en pequeñas unidades, de esta forma
se crearán primero los test para cada unidad y a continuación se desarrollará dicha unidad,
así poco a poco conseguiremos un desarrollo que cumpla todos los requisitos especificados.
c) Programación en Parejas
Todo el código debe ser creado por parejas de programadores sentados ambos frente a un
único computador lo que en principio representa una reducción de un 50% en productividad,
sin embargo, según XP no es tal la pérdida. Se entiende que no hay mucha diferencia, en lo
que a la cantidad se refiere, entre el código producido por una pareja bajo estas condiciones
que el creado por los mismos miembros trabajando en forma separada, con la excepción que
uno o ambos programadores sean muy expertos en la herramienta en cuestión.
27
En este proyecto no se aplicará la programación en parejas por tratarse de un proyecto
individual pero será supervisado por el tutor y asesor para verificar la correcta aplicación de
la metodología.
d) Integración Secuencial
Uno de los mayores inconvenientes presentados en proyectos de software tienen que ver con
la integración sobre todo si todos los programadores son dueños de todo el código.
Para saldar este problema han surgido muchos mecanismos, como darle propiedad de
determinadas clases a algunos desarrolladores, los cuales son los responsables de mantenerlas
actualizadas y consistentes. Sin embargo, sumado al hecho que esto va en contra de la
propiedad colectiva del código no se solucionan los problemas presentados por la
comunicación entre clases. XP propone que se emplee un esquema de turnos con el cual solo
una pareja de programadores integre a la vez. De esta forma se tiene plena seguridad de cuál
es la última versión liberada y se le podrán hacer todas las pruebas para garantizar que
funcione correctamente, conocido como integración secuencial.
e) Integración Secuencial
Se deben hacer integraciones cada pocas horas y siempre que sea posible no debe transcurrir
más de un día entre una integración de otra. De esta forma se garantizan que no surjan
problemas como que, un programador trabaje sobre versiones obsoletas de alguna clase. Es
evidente que entre más se tarde en encontrar un problema más costoso será resolverlo y con
la integración frecuente se garantiza que el mencionado problema sea evitado por completo.
2.7.2.4 FASE DE PRUEBAS

XP enfatiza mucho los aspectos relacionados con las pruebas, clasificándolas en diferentes
tipos y funcionalidades específicas, indicando quien, cuando y como deben ser
implementadas y ejecutadas.
Del buen uso de las pruebas depende el éxito de otras prácticas, tales como la propiedad
colectiva del código y la refactorización. Cuando se tienen bien implementadas las pruebas
no habrá temor de modificar el código del otro programador en el sentido que si se daña
28
alguna sección, las pruebas mostraran el error y permitirán encontrarlo. El mismo criterio se
aplica a la refactorización. Uno de los elementos que podría obstaculizar que un programador
cambie una sección de código funcional es precisamente hacer que esta deje de funcionar. Si
se tiene un grupo de pruebas que garantice su buen funcionamiento, este temor se mitiga en
gran medida.
a) Pruebas Unitarias
Estas pruebas se aplican a todos los métodos no triviales de las clases del proyecto con la
condición que no se liberará ninguna clase que no tenga asociada su correspondiente paquete
de pruebas. Uno de los elementos más importantes en estas es que idealmente deben ser
construidas antes que los métodos mismos, permitiéndole al programador tener máxima
claridad sobre lo que va a programar antes de hacerlo, así como conocer cada uno de los
casos de prueba que deberá pasar, lo que optimizará su trabajo y su código.
Deben ser construidas por los programadores con el empleo de algún mecanismo que permita
automatizarlas de modo tal que su implementación y ejecución consuman el menor tiempo
posible permitiendo sacarles el mejor provecho. El empleo de pruebas unitarias completas
facilitan la liberación continua de versiones por cuanto al implementar algo nuevo y
actualizar la última versión, solo es cuestión de ejecutar de forma automática las pruebas
unitarias ya creadas para saber que la nueva versión no contiene errores.
b) Pruebas de Aceptación
Las pruebas de aceptación, también llamadas pruebas funcionales son supervisadas por el
cliente basándose en los requerimientos tomados de las historias de usuario. En todas las
iteraciones, cada una de las historias de usuario seleccionadas por el cliente deberá tener una
o más pruebas de aceptación, de las cuales deberán determinan los casos de prueba e
identificar los errores que serán corregidos. Las pruebas de aceptación son pruebas de caja
negra, que representan un resultado esperado de determinada transacción con el sistema. Para
que una historia de usuario se considere aprobada, deberá pasar por todas las pruebas de
aceptación elaboradas para dicha historia. Es importante resaltar la diferencia entre las
pruebas de aceptación y las unitarias, en lo que al papel del usuario se refiere.
29
Mientras que en las pruebas de aceptación juega un papel muy importante seleccionando los
casos de prueba para cada historia de usuario e identificándolo los resultados esperados, en
lo segundo no tiene ninguna intervención por ser de competencia del equipo de
programadores.
c) Cuando se encuentra un error
Al momento de encontrar un error debe escribirse una prueba antes de intentar corregirlo. De
esta forma tanto el cliente logrará tener completamente claro cuál fue y dónde se encontraba
el mismo, como el equipo de desarrollo podrá enfocar mejor sus esfuerzos para solucionarlo.
Si el error fue reportado por el cliente y creó la correspondiente prueba de aceptación junto
al equipo de desarrollo, el programador encargado podrá a su vez producir nuevas pruebas
unitarias que le permita ubicar la sección específica donde el error se encuentra.
[JOSKOWINCZ J. 2000]
2.8 METODOLOGÍAS DE MODELADO WEB

Existen numerosas metodologías de modelado para aplicaciones web. Las mismas surgieron
con el nacimiento del hipertexto (Landow, 1995) y fueron evolucionando a lo largo del
tiempo incorporando distintas características y mejoras orientadas a la web. Los aspectos
fundamentales que estas metodologías incorporan son la descripción de la información a
visualizar, la navegación que se puede realizar para alcanzar dicha información y cómo será
la visualización por parte del usuario final. Además muchas de las metodologías fueron
diseñadas pensando en el enfoque MDD9 permitiendo derivar parte del código fuente partiendo
de los modelos realizados.
La Figura 2 muestra las principales metodologías de modelado y sus años de publicación, así como
también la relación existente entre ellas.
9
Desarollo Dirigido por Modelos (MDD)
30
Figura 2.7. Principales metodologías de modelado para web
Fuente: Martín, 2015
2.8.1 IFML
IFML10(Interaction Flow Modeling Language) nace el 2013 como estándar surgido del
OMG, basado en WEBML, permite especificar las vistas de la aplicación, su contenido, los
eventos que se disponen en la interfaz y las acciones que dichos eventos producen en el
sistema vinculándolos con la lógica de negocio convirtiéndose en una herramienta para los
arquitectos de sistemas, ingenieros de software y desarrolladores de software.
“IFML soporta la descripción independiente de la plataforma de interfaces gráficas de
usuario para aplicaciones desplegadas o accedidas en sistemas como computadoras de
escritorio, laptops, PDAs (Personal Digital Assistant), teléfonos móviles y tablets. El foco
principal está puesto en la estructura y comportamiento de la aplicación como la percibe el
10
OMG, Interaction Flow Modeling Language,2013
31
usuario final. El lenguaje de modelado también incorpora referencias a los datos y a la lógica
de negocios que influencia la experiencia del usuario. Esto se logra respectivamente
referenciando los objetos del modelo de dominio que proveen el contenido que se muestra
en la interfaz y las acciones que pueden ser desencadenadas al interactuar con la interfaz.”
[Brambilla Marco F.P., 2014]
“IFML no cubre el modelado de cuestiones de visualización (como layouts, estilo y look and
feel), tampoco está diseñado para el modelado de juegos o aplicaciones altamente
interactivas… está orientado a aplicaciones web de negocio que manejan datos.” [Bambrilla
Marco B.S., 2014]
2.8.1.1 MODELO DE DOMINIO

El Modelo del Dominio organiza la información principal identificando la especificación de
los requerimientos a un modelo de dominio comprensible y coherente.
Figura 2.8. Modelo de Dominio

Fuente: OMG, 2014
32
2.8.1.2 MODELO DE LA LÓGICA DEL NEGOCIO
El modelo de la Lógica del Negocio especifica los objetos del negocio y los métodos
necesarios para identificar los casos de uso. Los diagramas estáticos y dinámicos de UML
empleados para remarcar las interfaces de los objetos y seguir los mensajes de la notación
orientada al proceso como los diagramas de actividades y secuencia de UML.
Por otro lado, los modelos del proceso BPMN11y BPEL12 proporcionan una conveniente
manera de representar los flujos de trabajo de los objetos y servicios. La lógica de negocio
puede ser referenciada en el front-end para mostrar cual operación puede ser desencadenada
al interactuar con la interface13.
Figura 2.9. Modelo de la Lógica del Negocio

Fuente: OMG,2014
2.8.1.3 MODELO DE LA COMPOSICIÓN DE LA INTERFAZ DE USUARIO

El modelo de la Composición de la Interfaz de Usuario permite identificar las interacciones
del usuario con el front-end de la aplicación para poder contar con herramienta fácil de
entender para el equipo de trabajo.
11
Business Process Model and Notation (BPMN)
12
Business Process Execution Language (BPEL)
13
Interfaz es lo que conocemos como interface, se utiliza para nombrar a la conexión funcional entre dos sistemas o dispositivos de
cualquier tipo dando una comunicación entre distintos niveles.
33
Figura 2.10. Modelo de la Composición de la Interfaz
Fuente: OMG, 2014
2.9 BPM
BPM (Business Process Management) es un modelo centrado en los procesos de negocio,
que abarca la creación, ejecución y optimización de dichos procesos, de este modo BPM
permite tener una visibilidad completa y en tiempo real del negocio. BPM está diseñado para
que su ejecución se dé de forma cíclica en pro del mejoramiento de los procesos de negocio
de una compañía ajustada a los cambios del mercado, finalmente la velocidad del mercado
requiere que la adaptación de este modelo tenga apoyo sobre las tecnologías de información
de la empresa que lo adopta, haciendo fundamental el uso de una BPMS.
Figura 2.11. Desarrollo de BPM

Fuente: Oracle,2013
34
En cuanto a las posición de las BPMS en el desarrollo de software, un estudio realizado por
Pegasystems (compañía prioritaria en BPMS según IDC14) la ganancia en productividad que
tiene el uso de BPMS sobre los lenguajes orientados a objetos, es de 5 a 7 veces por encima,
entiéndase ganancia en productividad, a la relación del tiempo que tomó el desarrollo
particular de una aplicación en la suite BPMS de Pegasystems contra el mismo proyecto de
desarrollo realizado en el estado del arte de lenguajes orientados a objetos.
Figura 2.12. Ganancia en Productividad en el desarrollo de aplicaciones

Fuente: Pegasystems,2014
2.10 BPMN 2.0
Business Process Modeling Notation (BPMN) v2.015 es el estándar actual a nivel mundial
para modelar flujos y servicios de los procesos de negocio. El objetivo de un modelo de
proceso es compartir el conocimiento del negocio a los trabadores involucrados con dicho
proceso, de forma que pueda dirigir el trabajo y el esfuerzo hacia la misma dirección, para
14
IDC MarketScape. : http://www.oracle.com/us/corporate/analystreports/infrastructure/idc-marketscapebpm-425228.pdf.
15
OMG, «Business Process Model and Notation (BPMN)», http://www.omg.org/spec/BPMN/2.0/PDF.
35
esto la forma en la que se describe y modela un proceso debe ser rigurosa, de manera que sea
lo más independiente posible su interpretación de la persona que lo observe. Debido a las
facilidades que ofrece para la simulación las características de la notación BPMN v2.0, esta
notación se considera la base para el desarrollo de modelos de proceso de negocio.
2.10.1 USOS DE BPMN

Un modelo de un proceso de negocio modelado en BPMN v2.0 se puede realizar en diferentes
vistas con diferentes niveles de abstracción, esto permite comunicar diferente tipo de
información a diferente tipo de audiencia:
 Workflow: Describe como una entidad está involucrada con el proceso, usualmente
son procesos internos.
 Colaboración: Muestra la interacción entre dos o más entidades del negocio.
 Coreografía: Implica interacción entre entidades para un proceso especifico, pero
además define un comportamiento esperado de las interacciones de estas entidades.
2.10.2 NOTACIÓN
Para la representación de una determinada secuencia de actividades de negocio e información
de apoyo, existen diferentes maneras de hacerlo a partir del estándar:
 Mapas: Un simple diagrama de flujo que solo muestra nombre de actividades y
condicionales dentro del proceso.
 Descripciones: provee más detalles acerca de las actividades como por ejemplo las
personas que interactúan, posibles datos e información.
 Modelos: Es un diagrama con información suficiente para que el proceso pueda ser
analizado y simulado.
 Conversación: Describe en detalle la comunicación entre entidades del negocio.
2.10.3 ELEMENTOS BÁSICOS

En la Figura se muestra los elementos básicos para el modela de procesos mediante BPMN.
36
Figura 2.13. Elementos Básicos BPMN
Fuente: Bizagi, 2011
2.10.3.1 ACTIVIDADES
Describen una tarea específica dentro de un proceso de negocio.
Nombre Descripción
Actividades Simples Las actividades simples son actividades
cuyo trabajo no se descompone en más
detalle.
Actividades Compuestas Las actividades compuestas son Sub-

Procesos, es decir, que incluye a su vez un
conjunto de actividades y una secuencia
lógica (proceso) que indica que dicha
actividad puede ser analizada en más
detalle.
Tareas Automáticas Son tareas que no se realizan manualmente,
es decir, que las realiza un sistema
informático sin intervención humana. A
estas tareas también se les llama servicios.
Tabla 2.5. BPMN Actividades
37
2.10.3.2 COMPUERTAS
Las compuertas permiten el manejo de una secuencia de eventos, hace posible que exista
una clara coordinación entre actividades.
Nombre Descripción
Compuerta Se representa por la figura del rombo
y se usa para controlar la divergencia
o convergencia de la secuencia de
flujo. Esto determina las tradicionales
decisiones lógicas, así como la
creación de nuevos caminos, la
difusión de estos o su unión.
Compuerta Inclusiva
Cuando se utiliza una compuerta

inclusiva (elemento de divergencia),
es necesario asegurarse que al menos
exista un camino válido.
Temporizador
Un elemento temporizador(elemento
en círculo) que representa una espera
intermedia
Evento
Se trata de una actividad intermedia
depende de un actor externo y no de
un actor interno a la institución.
Compuerta Inclusiva basada en Eventos
Es una compuerta que permite
habilitar varios caminos alternativos
38
pero UNO SOLO de ellos será
tomado. El que toma primero
deshabilita a los otros.
Tabla 2.6. BPMN Compuertas

2.10.3.3 CONECTORES
Son los que definen una secuencia entre actividades, dándole sentido y estructura al proceso
que se está modelando.
Conector Asociación
La línea de flujo normal de secuencia se Una asociación se representa por una línea
refiere al flujo que se presenta a través de las punteada y se usa para asociar datos, texto
actividades hasta terminar en un evento de y otros artefactos con los objetos de flujo.
salida. El flujo de secuencia se representa Se usan por motivos de documentación y
por una línea sólida con una cabeza de comunicación para crear diagramas más
flecha sólida y se usa para mostrar el orden comprensibles.
(la secuencia) en el que las diferentes
actividades se ejecutaran en el proceso.
Tabla 2.7. BPMN Conectores
2.10.3.4 RESPONSABILIDADES
Las responsabilidades (canales o swimlanes) son un mecanismo para organizar actividades
en categorías separadas visualmente para ilustrar diferentes responsabilidades o roles
participantes en un proceso.
Figura 2.14. Canales o Swinlanes BPMN

39
2.10.3.5 FASES
Una fase es una subdivisión dentro de un lane o canal y se extiende a través de él
verticalmente. Se utiliza para organizar y categorizar actividades mostrando los posibles
estados que un proceso puede tener durante su ciclo de vida.
Figura 2.15. Canales o Swinlanes BPMN

2.11 MODELO MVC

Las siglas provienen de “Model View Controller”, es un patrón de arquitectura de software
que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres
capas distintas. Este modelo de trabajo se ve frecuentemente en aplicaciones web, donde la
vista es la página que visita el usuario, el modelo es el sistema de gestión de base de datos y
el controlador es el responsable de recibir los eventos de entrada desde la vista. De esta forma
el trabajo tiene como objetivos principales la utilización del código ya implementado y el
facilitar la evolución de manera independiente de los módulos del sistema.
Al utilizar MVC para el desarrollo de aplicaciones es posible tener diferentes vistas para un
mismo modelo permitiendo al desarrollador desplegar la información consistente de distintas
40
formas mediante tablas o gráficos. MVC permite construir nuevas vistas sin necesidad de
modificar el modelo previamente establecido, facilitando el desarrollo de forma modular.
Figura 2.16. Arquitectura Modelo Vista Controlador.

Fuente: ANEXSOFT, 2014
2.11.1 CAPAS DEL MODELO MVC
El patrón se encuentra dividido en tres capas:
 Modelo: es la representación específica de la información sobre la cual funciona la
aplicación. Es la encargada de acceder a la capa de almacenamiento de datos, siendo
independiente del medio o sistema de almacenamiento. El modelo además define las
funcionalidades de la aplicación.
 Vista: se encarga de representar el modelo en un formato adecuado para interactuar,
generalmente se refiere a la interfaz del usuario de la aplicación. La vista es la
encargada de resaltar u ocultar ciertos atributos del modelo mediante el uso de filtros
de presentación. La vista interactúa con el modelo mediante preguntas o mensajes
que cumplen con una terminología y semántica pertenecientes al modelo.
 Controlador: este elemento se encarga de recibir, manejar y responder a eventos
(usualmente desencadenados por el usuario), del flujo de trabajo de la aplicación y de
la lógica del sistema. El controlador interactúa tanto con el modelo como con la vista
y es el encargado de mantener y gestionar la relación entre ambas capas. En la
implementación de MVC para marcos de trabajo tipo web, el controlador se encarga
41
de responder a las acciones del usuario, interactuar con el modelo y decidir que vista
debe ser mostrada (en caso de ser necesario).
2.12 ARQUITECTURA FACADE

El patrón de la fachada es un patrón de diseño que se utiliza a menudo en la programación
orientada a objetos. Una fachada es, de hecho, una clase de envolver una biblioteca compleja
para proporcionar una interfaz más sencilla y más legible a ella. El patrón de la fachada
también se puede utilizar para proporcionar una API unificada y bien diseñada para un grupo
de APIs complejas.
Modelo
Controlador
Angular
Vista
Figura 2.17. Arquitectura FACADE en el sistema

Fuente: Elaboración Propia
2.13 CORRESPONDENCIA
2.13.1 CORRESPONDENCIA EXTERNA
Este tipo de correspondencia es aquel que llega de la parte externa de la institución del
SENASIR, como ser ministerios, instituciones públicas, empresas privadas, seguros médicos,
entre otros. Por esta razón, este tipo de correspondencias son recibidos por los siguientes
cargos:
 Técnico en correspondencia
 Responsable de observación (Unidad Compensación de Cotizaciones)
 Secretaria de la Unidad Jurídica
 Secretaria de la Unidad de Fiscalización y cobro de adeudos
42
 Secretaria de la Unidad Nacional de Operaciones
2.13.2 CORRESPONDENCIA INTERNA

Este tipo de correspondencia es aquel que es enviado y recibido entre las unidades, áreas,
responsables, que se encuentran en el interior de la institución, las personas encargadas de
realizar la recepción son todas las secretarias de las unidades del SENASIR
2.13.3 CORRESPONDENCIA DE LAS REGIONALES

Al mismo tiempo, en la institución se debe de considerar como correspondencias internas a
aquellas que son remitidas por 7 administrativas y 19 agencias regionales, que se encuentran
en distintos puntos del territorio nacional, llegan a la institución central mediante currier y
dependen de las oficinas principales que se encuentran en la ciudad de La Paz asignarlas a su
destino.
43
CAPÍTULO 3 MARCO APLICATIVO
3.1 SISTEMA WEB EMPLEANDO LA METODOLOGÍA XP Y EL MODELO
IFML
En este caso, BPMN formara parte del modelo IFML dando soporte a la documentación del
presente proyecto, en función a las fases de XP, ya que las historias de usuario no
proporcionan especificaciones funcionales de manera estandarizada.
En la tabla se muestra el uso de IFML, dentro de la metodología ágil XP, siguiendo los
principios del “Manifiesto Ágil”.
Al existir diversos artefactos y modelos por parte de ambas metodologías mencionadas se
seleccionó las más representativas y útiles al momento de desarrollo del proyecto
representado por la Tabla 3.1.
METODOLOGÍA XP PROCESOS XP PROCESOS IFML PROCESOS
BPM
FASE DE Historias de Usuario Identificación de
PLANIFICACIÓN Roles
Plan de
Entregas(Release Plan)
Iteraciones
FASE DE DISEÑO Tarjetas C.R.C. Modelo de Dominio
Modelo de la Lógica Notación
del Negocio BPMN
FASE DE Modelo de la
CODIFICACIÓN Composición de
lnterfaz de Usuario.
FASE DE PUESTA EN Pruebas de Aceptación Modelo de
PRODUCCIÓN Presentación
Tabla 3.1. Interrelación de Metodologías
A continuación se describirán cada una de las actividades mencionadas, cada una con sus
respectivos artefactos y modelos generados.
3.2 FASE DE PLANIFICACIÓN

La Fase de Exploración tiene como objetivo definir varios procesos de XP, iniciamos las
historias de usuario, mediante las reuniones realizadas con el personal de la institución
44
involucrada en el desarrollo del sistema web. La obtención de requerimientos consecuencia
de los diálogos contemplados con los clientes y futuros usuarios del sistema. Mediante la
Tabla 3.2 se puede observar un resumen del listado de los requerimientos.
REFERENCIAS REQUERIMIENTOS PRIORIDAD
R1 Registro de la Correspondencia. ALTA
R2 Bandeja de Correspondencia ALTA
R3 Generacion del Cite asignado por cada unidad ALTA
R4 Seguimiento ALTA
R5 Reportes ALTA
Tabla 3.2. Listado de Requerimientos
3.2.1 CLASIFICACIÓN E IDENTIFICACIÓN DE ROLES (ACTORES)

Se debe identificar a todos los actores que van a interactuar con el Sistema Web, evitando
errores en el manejo y posteriormente clasificarlo en clases y subclases de actores.
[SOTO&PALMA, 2004]
Esta clasificación permite incorporar medidas de seguridad en el acceso al sistema por roles
otorgados a determinados usuarios.
 Rol de Usuario: Representa al usuario que interactúa con el Sistema Web y puede
observar la bandeja de correspondencia.
 Rol de Usuario Técnico: Representa al usuario que podrá registrar la
correspondencia externa, modificarla si existiera algún error en la transcripción,
confirmar correspondencia recepcionada y asignación de la misma.
 Rol de Usuario Secretaria: Representa al usuario que podrá realizar la culminación
de la correspondencia, confirmación de la utilización de un cite determinado para la
emisión de la documentación por cada unidad. Además de realizar la asignación de
la correspondencia derivada por el proveído del Jefe de la Unidad.
45
 Rol de Usuario Jefe de Unidad: Representa al usuario que podrá realizar el
seguimiento de la cantidad de correspondencia es designada a su unidad y además de
observar el plazo estimado de la respuesta emitida.
 Rol de Usuario de Desbloqueo: Representa al usuario que podrá realizar el
desbloqueo de las notas bloqueadas por no ser confirmado en el lapso de 24 horas
después de haberse realizado la asignación.
 Rol de Usuario de Respaldo: Representa al usuario que podrá realizar las mismas
acciones de las secretarias en caso que se encuentre de vacación.
 Rol de Usuario de Funcionario: Representa al usuario que puede recibir
correspondencia.
3.2.2 HISTORIAS DE USUARIO
Iniciado con el conjunto de requerimientos, se construyó conjuntamente con el cliente una
variedad de historias de usuario, las cuales se caracterizan por describir las prioridades,
riesgos e iteraciones que son explicadas a continuación.
 Prioridad, de acuerdo a conversaciones con el cliente se tiene tres grados de
prioridad para el desarrollo e implementación de las historias de usuario como ser:
alta, normal y baja.
 Riesgos en desarrollo, es el riesgo que existe al desarrollar de forma inadecuada la
solución de las historias de usuario, se tienen tres grados de riesgos, las cuales son:
alta, normal y baja.
 Iteración asignada, es el número de iteración en el que se espera poder implementar
la historia de usuario, el tiempo promedio de entrega en cada iteración es
aproximadamente de 5 semanas, se pretende desarrollar e implementar todas las
historias de usuarios en 3 iteraciones.
 Puntos estimados, es el tiempo promedio en semanas de desarrollo los cuales se
miden en la escala de 1 a 5 semanas de desarrollo aproximadamente.
A continuación se detallan las historias de usuario recabadas en distintas reuniones llevadas

a cabo con el personal de dicha unidad, según cronograma establecido.
46
HISTORIA DE USUARIO Nro. 1 (ver Tabla 3.3), responde a la necesidad de realizar el
registro de la correspondencia interna y externa.
Historia de Usuario
Número: 1 Usuario: Técnico
Nombre Historia: Registro de la Correspondencia
Prioridad en negocio: Alta Riesgo en desarrollo: Baja
Puntos estimados: 3 Iteración asignada: 1
Descripción:
El funcionario que recibe la documentación, sellará con la fecha y hora de recepción.
Posteriormente registra las notas recibidas con los siguientes datos: fecha, número de
correlativo, cite, guía, referencia, fecha como máximo plazo máximo de atención. En caso que
la documentación perteneciera a un beneficiario deberá ser relacionado con el mismo,
incluyendo el carnet de identidad si fuera posible.
Tabla 3.3. Historia de Usuario: Registro de la Correspondencia
HISTORIA DE USUARIO Nro. 2 (ver Tabla 3.4), responde a la necesidad de observar la

correspondencia como ser: pendientes, confirmados y culminados.
Historia de Usuario
Número: 2 Usuario: Funcionario
Nombre Historia: Bandeja de Correspondencia
Descripción:
Se observará el listado de asignaciones pendientes y/o confirmadas realizadas por la unidad
remitente. Para evitar que se bloqueen o queden pendientes de atención las notas en el sistema,
las unidades o áreas deberán recoger del Área de Recepción de Correspondencia y confirmar
en un tiempo de 24 horas hábiles.
Tabla 3.4. Historia de Usuario: Bandeja de Correspondencia
HISTORIA DE USUARIO Nro. 3 (ver Tabla 3.5), responde a la necesidad de controlar

la generación del cite asignado a cada documento.
Historia de Usuario
Número: 3 Usuario: Funcionario, Secretaria, Respaldo
Nombre Historia: Generación del Cite asignado por cada unidad
47
Descripción:
La correspondencia emitida por cada unidad debe ser registrada en el sistema mediante un
número único que identifique al documento de la unidad emisora.
Tabla 3.5. Historia de Usuario: Generación del cite asignado por cada unidad
HISTORIA DE USUARIO Nro. 4 (ver Tabla 3.6), responde a la necesidad de realizar el

seguimiento respectivo a la correspondencia emitida.
Historia de Usuario
Nombre Historia: Seguimiento
Descripción:
Se deberá permitir el seguimiento de una nota dentro del sistema, mediante la opción de
búsqueda del documento con los parámetros más distintivos.
Tabla 3.6. Historia de Usuario: Seguimiento
HISTORIA DE USUARIO Nro. 5 (ver Tabla 3.7), responde a la necesidad de realizar los
reportes de hojas de solvencia que son utilizadas en constancia de la asignación.
Historia de Usuario
Nombre Historia: Reportes
Descripción:
Se elaborará los reportes para ser un instrumento de constancia de la asignación realizada.
Tabla 3.7. Historia de Usuario: Reportes
La siguiente tabla muestra Tabla 3.8 muestra un resumen de las historias de usuarios y su
implementación.
48
Nro.
Historia HISTORIAS PRIORIDAD RIESGO PUNTOS ITERACIÓN
H1 Registro de la
Correspondencia. ALTA BAJA 3 1
H2 Bandeja de 1
Correspondencia ALTA BAJA 3
H3 Generacion del Cite 2
de cada unidad. ALTA BAJA 3
H4 Seguimiento ALTA BAJA 3 3
H5 Reportes ALTA BAJA 3 3
Tabla 3.8 Resumen de las Historias de Usuario
3.2.3 PLAN DE ENTREGA (RELEEASE PLANNING)

Definidos las historias de usuario, continuamos junto al cliente planificando un plan de
publicaciones, de la implementación de las historias de usuario para cada versión del sistema
y una aproximación del tiempo de desarrollo requerido para su implementación además de
las tarjetas de tareas (Task Cards) en la que se tendrá una aproximación del tiempo de
desarrollo de cada una de las tareas necesarias para la implementación de las principales
historias de usuario en las distintas iteraciones.
De la misma manera que las historias de usuario, las tareas cuentan con una estructura similar,
tienen un nombre, un número de tarea, puntos estimados y el número de historia de usuario
a la cual pertenecen además de contar con:
 Tipo de Tarea, existen varios tipos de tarea entre los cuales están el de Desarrollo,
Corrección, Mejora o también alguna otra que será especifica.
 Fecha de Inicio y Finalización, son las fechas en que iniciaran y finalizaran las
actividades de cada una de las tareas.
49
3.2.3.1 PRIMERA ITERACIÓN
La siguiente iteración se proyecta implementar las historias de usuario con mayor grado de
prioridad para el cliente, ya que los mismos representan para la institución prioridad alta.
Las historias de usuario que se implementan en esta iteración son las siguientes:
H1. Registro de la Correspondencia
H2. Bandeja de Correspondencia
A continuación mostramos el conjunto de tareas necesarias para la implementación de la
historia de usuario H1. Registro de la Correspondencia Externa
Tarea
Número tarea: 1 Número historia: 1
Nombre tarea: Formulario de Registro de Correspondencia Externa
Tipo de tarea : Desarrollo Puntos estimados: 1
Fecha inicio: 16/08/2015 Fecha fin: 20/08/2015
Descripción: se creara un interfaz para ver el formulario de registro.
Tabla 3.9. Tarea: Formulario de Registro de Correspondencia Externa

Tareas necesarias para la implementación de la historia de usuario H2. Bandeja de
Correspondencia.
Tarea
Nombre tarea: Modificación de la Correspondencia Registrada
Descripción:
Se podrá modificar los datos de la correspondencia registrada, siempre que no haya sido
confirmada por la unidad destino.
Tabla 3.10. Modificación de la Correspondencia Registrada
50
Se mostrara el conjunto de tareas asociadas a la historia de usuario H2. Asignación de
Correspondencia.
Tarea
Nombre tarea: Búsqueda Correspondencia Externa
Descripción:
La búsqueda del documento deberá realizarse mediante los campos de guía, número de
correlativo y fecha del documento.
Tabla 3.11. Búsqueda Correspondencia Externa
3.2.3.2 SEGUNDA ITERACIÓN

En esta iteración se implementara las funcionalidades dedicadas
H3. Generación de Documentos
Se mostrara el conjunto de tareas asociadas a la historia de usuario H3. Generacion de
Documentos.
Tarea
Nombre tarea: Registro del Documento
Descripción:
Se deberá registrar el documento, clasificado por el tipo de documento, especificando las
características de la documentación.
Tabla 3.12. Registro del Documento
3.2.3.3 TERCERA ITERACIÓN
En esta iteración se implementara las funcionalidades dedicadas
51
H5. Seguimiento
H6.Reporte
Se mostrara el conjunto de tareas asociadas a la historia de usuario H5. Seguimiento.
Tarea
Nombre tarea: Reporte de Respaldo de la Correspondencia Externa
Descripción:
Toda correspondencia asignada a las diferentes unidades y/o áreas será a través de los
reportes extraídos del sistema.
Tabla 3.13. Reporte de Respaldo de la Correspondencia Externa
Se mostrara el conjunto de tareas asociadas a la historia de usuario H6. Reporte.
Tarea
Nombre tarea: Reporte de Respaldo de la Asignación
Descripción:
La correspondencia asignada por el Jefe de la Unidad, se deberá registrar en el sistema,
para conocer quien atendió la nota.
Tabla 3.14. Reporte de Respaldo de la Asignación
Luego de especificar el conjunto de tareas necesarias en las historias de usuario, podemos

construir la siguiente tabla con el cronograma de actividades a desarrollarse, durante el ciclo
de vida del proyecto.
52
Agosto Septiembre Octubre Noviembre Mayo
Fases de
Semanas Semanas Semanas Semanas Semanas
desarrollo
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
1. Planificación
2. Diseño
3. Desarrollo
4. Pruebas
Planificación 1ª Iteración 2ª Iteración 3ª Iteración
Figura 3.1. Cronograma de actividades: iteraciones del proyecto.

3.2.4 VELOCIDAD DEL PROYECTO

Como pudimos observar en la Tabla 3.2 contaremos con 5 iteraciones, es así que dividiremos
el tiempo que tenemos para desarrollar el sistema, aproximadamente en 4 meses, en tiempos
de iteración relativamente iguales. A fin de no acelerar ni lentizar el proyecto y que el mismo
se desarrolle de manera práctica y sin presión.
También podemos promediar la velocidad del proyecto utilizando:
Velocidad del Proyecto= Número de Historias de Usuario/Número de Iteraciones.
Remplazando los valores en la fórmula, tenemos:
Velocidad del Proyecto=5/3
Velocidad del Proyecto=1.6
Este indicador se interpreta de la siguiente manera: en cada iteración se avanzará en promedio

1 de historias de usuario y un 60% de la historia siguiente.
53
3.3 FASE DE DISEÑO
En esta fase se presentan diseños simples como sugiere la metodología XP, ya que para lograr
un mejor comprensión de la funcionalidad del sistema, el diseño debe ser sencillo entendible
para que los costos de tiempo, esfuerzo y desarrollo sean bajos.
3.3.1 TARJETAS CRC

El uso de las Tarjetas C.R.C. (Class, Responsabilities and Collaboration) permiten al
programador centrarse y apreciar el desarrollo de la programación.
La finalidad de estas tarjetas es facilitar la implementación de las clases definidas
anteriormente, las mismas que serán utilizadas en el desarrollo del Software orientado a la
Web, a continuación se presentan todas las tarjetas C.R.C.
TARJETA CRC Nro. 1. (ver Tabla 3.15), referente a la Correspondencia.
CORRESPONDENCIA
Objetivos o Responsabilidades Colaboradores
 Generar cite por unidad.
Jquery Validate, para validar los
 Generar cite por funcionario
campos de ingreso de información.
 Alta de la correspondencia.
Angular
 Modificación de la correspondencia.
Listado de Roles
 Asignación del destinatario
Tabla 3.15. Tarjeta C.R.C. Correspondencia
TARJETA CRC Nro. 2. (ver Tabla 3.16), referente a los Usuarios.
USUARIOS
Usuario autentificado con
privilegios.
 Generar la encriptación de la contraseña. Jquery Validate, para validar
 Modificar la contraseña los campos de ingreso de
 Controlar el ingreso por sesiones información.
Angular
Tabla 3.16. Tarjeta C.R.C. Usuarios

54
TARJETA CRC Nro. 3. (ver Tabla 3.17), referente a la Bandeja.
BANDEJA
 Generar listado de la Bandeja
Usuario autentificado con
 Contar las solicitudes
privilegios.
 Mostrar asignaciones
Angular
 Mostrar confirmaciones
 Mostrar culminaciones
Tabla 3.17. Tarjeta C.R.C. Bandeja
TARJETA CRC Nro. 4. (ver Tabla 3.18), referente a los Reportes.
REPORTES
 Reportes por asignaciones Datos formato JSON
 Reportes para la hoja de ruta Angular
 Exportar reportes
Tabla 3.18. Tarjeta C.R.C. Bandeja
3.3.2 MODELO DEL DOMINIO

El modelo de dominio representa las diferentes tablas y las relaciones que serán necesarias
para el Sistema Web.
El modelo estructural (ver figura 3.2) representa el total de entidades y relaciones a utilizar
en el presente proyecto estos se ven representados en forma de tablas.
55
Figura 3.2. Modelo de Dominio del Sistema Web
El modelo Entidad- Relación se muestra en la Figura 3.3
56
Figura 3.3. Modelo Entidad - Relación
El diagrama de clases pertenecientes al sistema web se muestra a continuación.
Figura 3.4.1 Modelo de Clases

57
3.3.3 MODELO DE LA LÓGICA DEL NEGOCIO
El modelo de la lógica de negocio mediante la notación BPMN se muestra a continuación.
La Figura 3.3 refleja el flujo de trabajo de la Correspondencia Interna.
Figura 3.5. Correspondencia Interna

La Figura 3.4 refleja el flujo de trabajo del Préstamo de Documento.
58
Figura 3.6. Préstamo de Documentos
La Figura 3.5 refleja el flujo de trabajo de la Correspondencia Externa.
59
Figura 3.7. Correspondencia Externa
60
3.3.4 MODELO COMPOSICIÓN DE LA INTERFAZ DE USUARIO
El sistema desarrollado para el siguiente proyecto se realizará el modelado de Diagramas
IFML que involucran la aplicación y además del modelo de Datos, con ello se tiene como
objetivo que la interfaz (Mockup) no se realice sin antes tener sus modelos que las respaldan.
3.3.4.1 MODELO PARA EL MÓDULO LOGIN

A. IFML Login
En este Diagrama IFML podemos observar cómo se comportará el sistema al inicio de la
misma, el diagrama proveerá la funcionalidad del inicio de sesión por medio de las
funcionalidades de “Iniciar Sesión”. Este diagrama respaldará al Mockup elaborado. (Ver
Figura 3.2)
Figura 3.8. Diagrama IFML Pantalla de Inicio

B. Mockups Login
El Mockup provee la primera visualización del sistema, la misma permitirá el ingreso al
sistema. Cuenta con etiquetas, la primera llamada “Usuario” con su respectivo campo, servirá
para digitar el nombre de usuario, enseguida se muestra la segunda etiqueta llamada
“Contraseña” con su respectivo campo, para digitar la contraseña. Seguidamente que
digitemos nuestras credenciales aparecerá nuestro segundo Diagrama IFML llamado
“Principal”.
61
Figura 3.9. Pantalla de Inicio
3.3.4.2 MODELO PARA EL MÓDULO PRINCIPAL
En el Diagrama IFML(Ver Figura 3.3) se pueden observar claramente los módulos:
 Correspondencia Interna
Representa a toda la correspondencia entre las unidades
 Correspondencia Externa
 Bandeja
 Bandeja de Elaborados
 Bandeja de Recibidos
 Bandeja de Enviados
 Reportes
 Libros
 Libros de Registro
 Seguimiento
 Búsqueda Avanzada
 Configuración
 Perfil de Usuario
 Cambiar Contraseña
62
Figura 3.10. Diagrama IFML Módulo Principal
3.4 FASE DE CODIFICACIÓN
En esta fase de la metodología XP, la codificación de cada una de las historias de usuario se
realiza junto al cliente, permitiendo de esta forma una retroalimentación en la compresión de
lo que el cliente quiere priorizar más en las entregas del sistema.
El desarrollo de la funcionalidades del Sistema Web fue realizado con el lenguaje de
programación PHP , codeigniter que es uno de los framework PHP orientados a ocuparse el
backend del Sitio Web, Simultáneamente con el Framework Bootstrap enfocado a tratar el
Frontend del Sitio Web, Herramientas tecnológicos populares entre la comunidad de
desarrolladores, ya que permite que los programadores sean mucho más productivo a la vez
que crean código de más calidad, además de utilizar como gestor de base de datos MySQL,
capaz de almacenar una enorme cantidad de datos de gran variedad y de distribución para
cubrir la necesidad de cualquier tipo de organización.
63
A continuación se muestra las capturas de pantalla de los módulos que se desarrollan para el
sistema que se realizaron a través de las historias de usuarios y requerimientos.
Figura 3.11. Login

Figura 3.12. Documentos Elaborados

64
Figura 3.13. Correspondencia Pendiente
Figura 3.14. Documentos enviados

65
Figura 3.15. Nueva Correspondencia Interna
Figura 3.16. Nueva Correspondencia Interna

66
Figura 3.17. Nueva Correspondencia Externa para datos del Documento
Figura 3.18. Nueva Correspondencia Externa para datos de la asignación

67
Figura 3.19. Nueva Correspondencia Externa datos de la Institución
Figura 3.20. Datos del Documento

68
3.5 FASE DE PRUEBAS
En esta de la metodología de programación extrema XP, la fase de pruebas es una de las fases
más importantes ya que nos permiten verificar junto al cliente que se pudo atender los
requerimientos especificados en las historias de usuario que fueron implementados en
versiones anteriores y que necesitan ser modificadas, mejoradas o simplemente descartadas.
El tipo de pruebas realizadas en esta fase son pruebas de aceptación descritas a continuación
3.5.1 PRUEBAS DE ACEPTACIÓN

Este tipo de pruebas fueron realizadas para cada entrega de software en las distintas
iteraciones que se tuvo, ya que fueron definidas en el reverso de cada historia de usuario.
Las siguientes tablas muestran todas las pruebas de aceptación requeridas por el cliente en
cada historia de usuario, además de la iteración en la cual fueron solucionadas correctamente.
PRUEBAS DE ACEPTACIÓN Nro. 1 (ver Tabla 3.19), referente al Registro de

Correspondencia.
Pruebas de Aceptación
Nombre Historia: Registro de la Correspondencia
Descripción:
 Digitar usuario contraseña verificar su estado en el sistema, comprobar
restricciones
 Completar todos los datos del formulario Correctamente, informar que se cumplió
exitosamente el registro en el Sistema Web
Test de Aceptación: Aceptado por el personal en la primera iteración
Tabla 3.19. Prueba de Aceptación: Registro de Correspondencia
PRUEBAS DE ACEPTACIÓN Nro. 2 (ver Tabla 3.20), referente al Registro de
Correspondencia
Nombre Historia: Bandeja de Correspondencia
69
Descripción:
 Seleccionar la opción de Bandeja de Confirmación
 Seleccionar la opción de la Bandeja de Recepción
 Seleccionar la Bandeja de Pendientes
Test de Aceptación: Aceptado por el personal en la primera iteración
Tabla 3.20. Prueba de Aceptación: Bandeja de Correspondencia
PRUEBAS DE ACEPTACIÓN Nro. 3 (ver Tabla 3.21), referente a la Generación del cite
de cada unidad.
Nombre Historia: Generación del cite de cada unidad
Descripción:
 Generar automáticamente el cite de la unidad al realizar un nuevo registro.
Test de Aceptación: Aceptado por el personal en la segunda iteración.
Tabla 3.21. Pruebas de Aceptación: Generación del cite de cada unidad
PRUEBAS DE ACEPTACIÓN Nro. 4 (ver Tabla 3.22), referente al Seguimiento.
Nombre Historia: Seguimiento
Descripción:
 Verificar la existencia de correspondencia pendiente mediante búsquedas.
Test de Aceptación: Aceptado por el personal en la segunda iteración.
Tabla 3.22. Pruebas de Aceptación: Seguimiento
PRUEBAS DE ACEPTACIÓN Nro. 5 (ver Tabla 3.23), referente a los Reportes.

Nombre Historia: Reportes
70
Descripción:
 Generar las hojas de solvencia.
 Ingresa las fechas para obtener el reporte
 Selecciona el evento para exportarlo a Pdf
Test de Aceptación: Aceptado por el personal en la tercera iteración.
Tabla 3.23. Pruebas de Aceptación: Reportes
71
CAPÍTULO 4 MÉTRICAS DE CALIDAD Y SEGURIDAD
4.1 CALIDAD DE SOFTWARE

4.1.1 INTRODUCCIÓN
El propósito fundamental de la ingeniería de software es construir un software de calidad,
por consiguiente este capítulo se detalla la calidad del sistema.
La medición de control de calidad de software se realizará a través de métricas de control de
calidad basados en la tesis Doctoral “Metodología Cuantitativa para la Evaluación y
Comparación de la Calidad de Sitios Web” de Luis Antonio Olsina (OLSINA, 1999). El
Sistema Web considera 4 aspectos como ser usabilidad, funcionalidad, confiabilidad y
eficiencia.
4.1.2 DEFINICIÓN Y ESPECIFICACIÓN DE REQUERIMIENTOS DE

CALIDAD
Esta fase trata con actividades y procedimientos, modelado y especificación de los
requerimientos de calidad. A partir de un proceso de evaluación realizado en una mezcla de
estrategias prescriptivas y descriptivas (el enfoque de modelo mixto de calidad), y con el fin
de analizar, comparar, comprender y potencialmente mejorar características y atributos de
artefactos Web, los requerimientos deben responder a necesidades y deseos de un perfil (de
usuario y dominio establecidos.
Se puede definir el dominio de la aplicación, desde el punto de vista de la evaluación, como

a un sistema real o abstracto del universo que existe independientemente del sistema de
evaluación. Consiste de un conjunto de entes a los que se le atribuyen propiedades, atributos,
características), manifiestan un comportamiento y se relacionan. El rango de evaluación de
las preguntas planteadas para medir la calidad de software se lo detalla en la tabla 4.1:
Rango Descripción
0 No existe la característica
1-50 Malo
51-60 Regular
61-70 Optimo
72
70-100 Excelente
Tabla 4.1. Rango de calificación
Fuente: Elaboración propia
La encuesta se realizó en las primeras fases de la implementación del sistema para la
usabilidad del sistema (Tabla 4.2).
1. Usabilidad Descripción Nota% Personas
1.1 1.1 Comprensibilidad Global del sitio
Comprensibilidad 1.1.1 Esquema de Organización Global
Global del sitio 1.1.1.1 Mapa del Sitio 100 5
1.1.1.2 Tabla de Contenidos 90 5
1.1.1.3 Índice alfabético 0 5
1.1.2 Calidad en el Sistema de Etiquetado 90 5
1.1.3 Visita guiada Orientada 90 5
1.1.4 Mapa de Imagen 90 5
1.2 Mecanismos 1.2.1 Calidad en la ayuda
de ayuda y 1.2.1.1 Ayuda explicatoria Orientada 90 5
retroalimentación 1.2.1.2 Ayuda en la búsqueda 95 5
en línea 1.2.2 Indicador de última actualización
1.2.2.1 Global (de todo el sitio web) 100 5
1.2.2.2 Restringido (por subsitio o página) 90 5
1.2.3 Directorio de direcciones
1.2.3.1 Directorio e-mail 100 5
1.2.3.2 Directorio TE-Fax 50 5
1.2.3.3 Directorio Correo postal 50 5
1.2.4 Facilidad FAQ 90 5
1.3 Aspectos de 1.3.1 Cohesividad al agrupar los objetos de 100 5
interfaces y control principales
estéticos 1.3.2 Permanencia y estabilidad en la
presentación de los controles principales
1.3.2.1 Permanencia de controles directos 90 5
1.3.2.2 Permanencia de controles indirectos 95 5
1.3.2.3 Estabilidad 100 5
1.3.3 Aspectos de estilo 95 5
1.3.4 Preferencia estética 100 5
73
1.4 Misceláneas 1.4.1 Soporte a lenguaje extranjero 0 5
1.4.2 Atributo “Qué es lo Nuevo” 80 5
1.4.3 Indicador de resolución de pantalla 85 5
Tabla 4.2. Sub-características de Usabilidad
Las sub características de la funcionalidad se las detalla en la Tabla 4.3
2. Funcionalidad Descripción Nota% Personas

2.1 Aspectos de 2.1.1 Mecanismo de búsqueda en el sitio
Búsqueda y web
recuperación 2.1.1.1 Búsqueda restringida 100 5
2.1.1.2 Búsqueda global 90 5
2.2 Aspectos de 2.2.1 Navegabilidad 100 5
navegación y 2.2.2 Objetos de control navegacional 95 5
exploración 2.2.3 Predicción navegacional 85 5
2.3 Aspectos del 2.3.1 Relevancia de contenido 100 5
dominio 2.3.2 Relevancia de enlaces 90 5
2.3.3 Servicio de grupo de noticias 0 5
2.3.4 Aspectos varios 90 5
Tabla 4.3. Sub-características de Funcionalidad
Las sub características de la confiabilidad se las detalla en la Tabla 4.4
3. Confiabilidad Descripción Nota% Personas
3.1 No deficiencia 3.1.1 Errores de enlaces
3.1.1.1 Enlaces rotos 90 5
3.1.1.2 Enlaces inválidos 90 5
3.1.1.3 Enlaces no implementados 95 5
3.1.2 Errores o deficiencias varias
3.1.2.1 Deficiencias o cualidades ausentes 85 5
3.1.2.2 Deficiencias o resultados 85 5
3.1.2.3 Nodos destinos (inesperadamente) 90 5
3.1.2.4 Nodos web muertos (sin enlaces de 90 5
retorno)
Tabla 4.4. Sub-características de Confiabilidad
Las sub características de la eficiencia se las detalla en la Tabla 4.5
4. Eficiencia Descripción Nota% Personas
4.1 Performance 4.1.1 Páginas de acceso rápido 95 5
74
4.2 Aspectos de 4.2.1 Accesibilidad de información
navegación y 4.2.1.1 Soporte a versión sólo texto 85 5
exploración 4.2.1.2 Legibilidad al desactivar la
propiedad imagen del browser
4.2.1.2.1 Imagen con título 100 5
4.2.1.2.2 Legibilidad global 100 5
4.2.2 Accesibilidad de ventanas 85 5
Tabla 4.5. Sub-características de Eficiencia
4.1.3 DEFINICIÓN E IMPLEMENTACIÓN DE LA EVALUACIÓN

ELEMENTAL
Con respecto a la fase de Definición e Implementación de la Evaluación Elemental la misma
trata con actividades, modelos, técnicas, heurísticas y herramientas para determinar criterios
de evaluación para cada atributo cuantificable y realizar el proceso de medición.
Particularmente, nos interesa la calidad de artefactos Web como característica de estudio.
A continuación se mencionarán los distintos criterios que se consideran para la recolección
de datos:
Título: Mapa del sitio Código: 1.1.1.1 Tipo: Atributo
Característica de más alto Usabilidad
nivel
Super-características Esquema de organización global
Definición/ Comentarios Un mapa del sitio es una representación con
componentes gráficos, que muestra la estructura o
arquitectura global (a menudo jerárquica) del sitio web
como un todo.
Tipo de Criterio elemental Es un criterio binario, discreto y absoluto: solo se
pregunta si está disponible (1) o si no está disponible
Escala de preferencia
Tipo de recolección de datos Manual, observacional

Tabla 4.6. Criterios de recolección de datos de más alto nivel para Usabilidad
Fuente: Olsina, 1999
75
En la tabla 4.7 se muestra los criterios de recolección de datos de más alto nivel para
funcionalidad.
Título: Mapa del sitio Código: 2.1.1.1 Tipo:Atributo
Característica de más alto Funcionalidad
nivel
Super-características Búsqueda restringida
Definición/ Comentarios Algunas veces, tiene sentido brindar al usuario con la
facilidad de búsqueda restringida a un subsitio o parte de
un sitio, debido a que el mismo es altamente cohesivo o
distintivo del resto de la información del sitio web global.
Tipo de Criterio elemental Es un criterio multi-nivel, discreto y absoluto, definido
como subconjunto. Podemos decir que: 0 = no
disponible mecanismos de búsqueda restringida; 1 =
búsqueda básica: mecanismo de búsqueda por
nombre/apellido; 2 = 1 +búsqueda extendida o avanzada
Tipo de recolección de datos Manual

Tabla 4.7. Criterios de recolección de datos de más alto nivel para Funcionalidad
confiabilidad.
Título: Enlaces rotos Código: 3.1.1 Tipo:Atributo
Característica de más alto Confiabilidad
nivel
Super-características Errores de enlaces
Definición/ Comentarios Este atributo representa básicamente a los enlaces
encontrados que conducen a nodos destino ausentes
(también llamados enlaces ausentes o pendientes)
Tipo de Criterio elemental Es un criterio de variable normalizada, continuo y
absoluto; en donde si BL=Número de enlaces rotos
encontrados. TL = Número total de enlaces del sitio. La
76
fórmula para computar la variable es: X = 100 – (BL *
100/TL) * 10; donde, si X < 0 entonces X = 0.
Tipo de recolección de datos Automatizado

Tabla 4.8. Criterios de recolección de datos de más alto nivel para Confiabilidad
eficiencia.
Título: Enlaces rotos Código: 4.1.1 Tipo : Atributo
Característica de más alto Eficiencia
nivel
Super-características Performance
Definición/ Comentarios Para este atributo, se mide el tamaño de todas las
páginas (estáticas) del sitio Web considerando todos sus
componentes gráficos, tabulares y textuales. El tamaño
de cada página se especifica como una función del
tiempo de espera y de la velocidad mínima establecida
para una línea de comunicación dada.
Se especifica un tamaño umbral aceptable, para el
tamaño total de cada página, por ejemplo, el de 35,2 Kb.
Una página de este tamaño requiere 20 segundos para
ser bajada a una taza de 14,400 bps. Ese es el tiempo
aceptable que un usuario debe esperar, sin que se ponga
impaciente.
Tipo de Criterio elemental Es un criterio multi-variable, continuo y absoluto
Tipo de recolección de datos Automatizado

Tabla 4.9. Criterios de recolección de datos de más alto nivel para Eficiencia
77
4.1.4 DEFINICIÓN E IMPLEMENTACIÓN DE LA DEFINICIÓN GLOBAL
En la fase de Definición e Implementación de la evaluación global se trata con actividades,
modelos, procedimientos y herramientas para determinar los criterios de agregación de las
preferencias de calidad elemental (obtenidas en la fase anterior, a partir del árbol de
requerimientos), para producir la preferencia global para cada sistema de información
interviniente.
Figura 4.1. Tres funciones simples de agregación de preferencias

En la figura 4.2 se muestra los indicadores necesarios para calcular la eficiencia y

confiabilidad.
Figura 4.2. Ejemplo de Estructura de agregación de preferencias parciales para la

confiabilidad y eficiencia
78
En la figura 4.3 se muestra los indicadores que se deben considerar para el cálculo de
calidad de software.
Figura 4.3. Ejemplo de Estructura de agregación de preferencias parciales para la

usabilidad y funcionalidad
79
Para obtener el indicador de calidad global e indicadores parciales (IG/P), se puede emplear
la siguiente estructura de agregación, tomando en cuenta el modelo aditivo.
𝑰𝑮
= (𝑷𝟏 ∗ 𝑰𝑬𝟏 + ⋯ + 𝑷𝒏𝑰𝑬𝒏)(𝟎)
𝑷
Donde:
IEi: Son los indicadores elementales o parciales, conforme al nivel del árbol que se calcule.
Pi: Son los pesos que modelan la importancia relativa de cada indicador elemental o parcial
dentro de un grupo.
Consideraciones:
Cada Pi debe ser mayor a cero y la sumatoria en un grupo o subgrupo debe dar uno,
realizando los cálculos necesarios con la ecuación (0) se obtendrán los siguientes
resultados.
En la tabla 4.10 se muestra los resultados obtenidos para el cálculo de atributos, usabilidad,
para el control de calidad.
Preferencias de Calidad para atributos de usabilidad
1.1.1 Esquema de Organización Global
IEi Pi (IEi*Pi)
1.1.1.1 Mapa del sitio 100 0.2 20
1.1.1.2 Tabla de Contenidos 90 0.4 36
1.1.1.3 Índice Alfabético 0 0.4 0
TOTAL 56
1.2.1 Calidad de la ayuda
IEi Pi (IEi*Pi)
1.2.1.1 Ayuda explicatoria orientada 90 0.6 54
1.2.1.2 Ayuda de la búsqueda 95 0.4 38
TOTAL 92
1.2.2 Indicador de última actualización
IEi Pi (IEi*Pi)
1.2.2.1 Global (de todo el sitio web) 100 0.5 50
80
1.2.2.2 Restringido (por subsitio o página) 90 0.5 45
TOTAL 95
1.2.3 Directorio de direcciones
IEi Pi (IEi*Pi)
1.2.3.1 Directorio E-mail 100 0.5 50
1.2.3.2 Directorio TEL-Fax 50 0.25 12.5
1.2.3.3 Directorio Correo postal 50 0.25 12.5
TOTAL 75
1.3.2 Permanencia y estabilidad en la presentación de los controles principales
IEi Pi (IEi*Pi)
1.3.2.1 Permanencia de controles directos 90 0.4 36
1.3.2.2 Permanencia de controles indirectos 95 0.4 38
1.3.2.3 Estabilidad 100 0.2 20
TOTAL 94
Tabla 4.10. Resultado de las preferencias de calidad para atributos de usabilidad
En la tabla 4.11 se muestra los resultados obtenidos para el cálculo de los sub atributos de
usabilidad, para el control de calidad.
Preferencias de calidad para sub-características de usabilidad
1.1 Comprensibilidad global sitio
IEi Pi (IEi*Pi)
1.1.1 Esquema de organización global 56 0.35 19.6
1.1.2 Calidad en el sistema de etiquetado 90 0.15 13.5
1.1.3 Visita guiada orientada 90 0.2 18
1.1.4 Mapa de imagen 90 0.3 27
TOTAL 78.1
1.2 Mecanismos de Ayuda y retroalimentación en línea
IEi Pi (IEi*Pi)
1.2.1 Calidad en la ayuda 92 0.2 18.4
1.2.2 Indicador de última actualización 95 0.2 12
1.2.3 Directorio de direcciones 75 0.25 18.75
81
1.2.4 Facilidad FAQ 90 0.1 9
TOTAL 58.15
1.3 Aspectos de Interfaces y estéticos
IEi Pi (IEi*Pi)
1.3.1 Cohesividad al agrupar los objetos de control 100 0.15 15
principales
1.3.2 Permanencia y estabilidad en la presentación de los 94 0.3 28.2
controles principales
1.3.3 Aspectos de estilo 95 0.3 28.5
1.3.4 Preferencia estética 100 0.25 25
TOTAL 96.7
1.4 Misceláneas
IEi Pi (IEi*Pi)
1.4.1 Soporte a lenguaje extranjero 0 0.5 0
1.4.2 Atributo “Que es lo nuevo” 80 0.35 28
1.4.3 Indicador de resolución de pantalla 85 0.15 12.75
TOTAL 40.75
Tabla 4.11. Resultado de las preferencias de calidad para sub características de usabilidad
En la tabla 4.12, se muestra los resultados obtenidos de la usabilidad del Sistema de

correspondencia.
1.Usabilidad
IEi Pi (IEi*Pi)
1.1 Comprensibilidad global del sitio 78.1 0.35 27.335
1.2 Mecanismos de ayuda y retroalimentación en línea 58.15 0.25 14.5375
1.3 Aspectos de interfaces y estéticos 96.7 0.3 29.01
1.4 Misceláneas 40.75 0.1 4.075
TOTAL 74.9575
Tabla 4.12. Resultado de las preferencias de calidad para características de usabilidad
El total de los resultados de usabilidad (Tabla 4.12) es 74.96 lo que significa que el sistema
es usable, las características que afectaron la usabilidad del sistema y tomar en cuenta para
futuras mejoras.
82
En la tabla 4.13 se muestra los resultados obtenidos para el cálculo de los atributos de
funcionalidad, para el control de calidad.
Preferencias de calidad para atributos de funcionalidad

2.1.1 Mecanismo de Búsqueda en el sitio web
IEi Pi (IEi*Pi)
2.1.1.1 Búsqueda restringida 100 0.6 60
2.1.1.2 Búsqueda global 90 0.4 36
TOTAL 96
Tabla 4.13. Resultado de las preferencias de calidad para atributos de funcionalidad
En la tabla 4.14 se muestra los resultados obtenidos para el cálculo de los sub atributos de
funcionalidad, para el control de calidad.
Preferencias de calidad para sub características de funcionalidad

2.2 Aspectos de navegación y exploración
IEi Pi (IEi*Pi)
2.2.1 Navegabilidad 100 0.35 35
2.2.2 Objetos de control navegacional 95 0.35 33.25
2.2.3 Predicción Navegacional 85 0.3 25.5
TOTAL 93.75
2.3 Aspectos del dominio
IEi Pi (IEi*Pi)
2.3.1 Relevancia de contenido 100 0.25 25
2.3.2 Relevancia de enlaces 90 0.2 18
2.3.3 Servicio de grupo de noticias 0 0.25 0
2.3.4 Aspectos varios 90 0.15 13.5
TOTAL 56.5
Tabla 4.14. Resultado de las preferencias de calidad para sub características de
funcionalidad
En la tabla 4.15, se muestra los resultados obtenidos de la funcionalidad del Sistema de

Correspondencia.
83
2. Funcionalidad
IEi Pi (IEi*Pi)
2.1 Aspectos de búsqueda y recuperación 96 0.25 24
2.2 Aspectos de navegación y exploración 93.75 0.35 32.8125
2.3 Aspectos del dominio 56.5 0.4 22.6
TOTAL 79.4125
Tabla 4.15. Resultado de las preferencias de calidad para características de funcionalidad
El total de los resultados de funcionalidad (Tabla 4.15) es de 79.4% lo que significa que el
sistema es funcional, las características que afectaron la funcionalidad del sistema y tomar
en cuenta para futuras mejoras estas descritas en las tablas anteriores.
En la tabla 4.16, se muestra los resultados obtenidos para el cálculo de los atributos de
confiabilidad, para el control de calidad.
Preferencias de calidad para atributos de confiabilidad

3.1.1 Errores de enlaces
IEi Pi (IEi*Pi)
3.1.1.1 Enlaces rotos 90 0.4 36
3.1.1.2 Enlaces inválidos 90 0.4 36
3.1.1.3 Enlaces no implementados 95 0.2 19
TOTAL 89
3.1.2 Errores o deficiencias varias
IEi Pi (IEi*Pi)
3.1.2.1 Deficiencias o cualidades ausentes 85 0.25 21.25
3.1.2.2 Deficiencias o resultados 85 0.25 21.25
3.1.2.3 Nodos destinos (inesperadamente) 90 0.25 22.5
3.1.2.4 Nodos web muertos (sin enlaces de retorno) 90 0.25 22.5
TOTAL 87.5
Tabla 4.16. Resultado de las preferencias de calidad para atributos de confiabilidad
En la tabla 4.17, se muestra los resultados obtenidos para el cálculo de las sub características
de confiabilidad, para el control de calidad.
84
Preferencias de calidad para sub-características de confiabilidad
3.1 No deficiencia
IEi Pi (IEi*Pi)
3.1.1 Errores de Enlaces 89 0.6 53.4
3.1.2 Errores o deficiencia varias 87.5 0.4 35
TOTAL 88.4
Tabla 4.17. Resultado de las preferencias de calidad para sub características de
confiabilidad
En la tabla 4.18, se muestra los resultados obtenidos de la confiabilidad del Sistema de

correspondencia.
3. Confiabilidad
IEi Pi (IEi*Pi)
3.1 No deficiencia 88.4 1 88.4
TOTAL 88.4%
Tabla 4.18. Resultado de las preferencias de calidad para características de confiabilidad
El total de los resultados de confiabilidad (Tabla 4.18) es de 88.4% lo que significa que el
sistema es confiable, las características que afectaron la funcionalidad del sistema y tomar en
cuenta para futuras mejoras estas descritas en las tablas anteriores.
En la tabla 4.19, se muestra los resultados obtenidos para el cálculo de los atributos de
eficiencia, para el control de calidad.
Preferencias de calidad para atributos de eficiencia
4.2.1.2 Legibilidad al desactivar la propiedad imagen del browser
IEi Pi (IEi*Pi)
4.2.1.2.1 Imagen con titulo 100 0.5 50
4.2.1.2.2 Legibilidad global 100 0.5 50
TOTAL 100
4.2.1 Accesibilidad de información
IEi Pi (IEi*Pi)
4.2.1.1 Soporte a versión solo texto 85 0.8 68
85
4.2.1.2 Legibilidad al desactivar la propiedad imagen del 100 0.2 20
browser
TOTAL 88
Tabla 4.19. Resultado de las preferencias de calidad para atributos de eficiencia
En la tabla 4.20, se muestra los resultados obtenidos para el cálculo de las sub características
de eficiencia, para el control de calidad.
Preferencias de calidad para sub-características de eficiencia

4.1 Performancia
IEi Pi (IEi*Pi)
4.1.1 Páginas de acceso rápido 95 1 95
TOTAL 95
4.2 Accesibilidad
IEi Pi (IEi*Pi)
4.2.1 Accesibilidad de información 88 0.8 70.4
4.2.2 Accesibilidad de ventanas 85 0.2 17
TOTAL 87.4
Tabla 4.20. Resultado de las preferencias de calidad para sub características de eficiencia
En la tabla 4.21, se muestra los resultados obtenidos de la eficiencia del Sistema de

Correspondencia.
4. Eficiencia
IEi Pi (IEi*Pi)
4.1 Performancia 95 0.8 76
4.2 Accesibilidad 87.4 0.2 17.48
TOTAL 93.48
Tabla 4.21. Resultado de las preferencias de calidad para características de eficiencia
El total de los resultados de eficiencia (Tabla 4.18) es de 93.48 lo que significa que el sistema
es eficiente, las características que afectaron la funcionalidad del sistema y tomar en cuenta
para futuras mejoras estas descritas en las tablas anteriores.
86
4.1.5 RESULTADOS DE LA CALIDAD DEL SISTEMA
La tesis Doctoral WEBQEM de Olsina plantea 3 niveles de barras de calidad esto es,
insatisfactorio (de 0 a 40%), marginal (desde 40 al 60%) y satisfactorio (desde 60 a 100%)
se basa en el esquema de aceptabilidad de modelo ISO como IEEE. Como se muestra en la
figura 4.4.
Figura 4.4. Preferencias parciales para las características de más alto nivel
Los resultados de la calidad del Sistema de Correspondencia se lo detalle en la tabla 4.22.
Característica de Calidad
IEi Pi (IEi*Pi)
1.Usabilidad 74.9 0.3 22.47
2.Funcionalidad 79.4 0.3 23.82
3.Confiabilidad 88.4 0.2 17.68
4.Eficiencia 93.48 0.2 18.696
TOTAL 82.666
Tabla 4.22. Resultado de las preferencias de calidad
87
De acuerdo a los resultados de la tabla 4.22 que se recopiló durante todo este proceso de
calidad de software se puede observar los resultados más mínimos como superiores, haciendo
un análisis se puede observar que hay que mejorar la usabilidad del sistema por su resultado
obtenido.
De acuerdo a la valoración y evaluación de calidad de software aplicando el modelo
WEBQEM se puede observar que el usuario tendrá la satisfacción del 82.7% el valor
obtenido se encuentra dentro de los márgenes de satisfacción definidos en WEBQEM
descritos en la figura 4.4.
4.1.6 PRUEBAS DE SOFTWARE

4.1.6.1 PRUEBAS DE RENDIMIENTO
El objetivo de las pruebas de rendimiento o estrés es simular el comportamiento de una
aplicación cuando se ve sometido a la concurrencia de un número elevado de usuarios. Para
la realización de estas pruebas, existen numerosas herramientas que permiten someter a una
aplicación a la acción de cientos o miles de usuarios siendo una de ellas la herramienta Open
Source JMeter, que ha adquirido una especial relevancia principalmente por su versatilidad
y bajo coste y es la que se utilizó en el proyecto.
Se realizaron pruebas con 25, 50 y 100 hilos, simulando la concurrencia de usuarios, bajo
una plantilla, utilizando diferentes parámetros.
Al realizar las pruebas con 25 hilos, los resultados que se obtiene son:
Figura 4.5. Reporte Resumen con 25 hilos concurrentes

88
De la figura 4.5 se puede observar que con 25 hilos ejecutándose concurrentemente hay un
error de 0.0%. La gráfica resultante se la puede ver en la figura 4.6.
Figura 4.6. Gráfico de Resultados con 25 hilos concurrentes


89


90

La Tabla 4.23 permite observar un resumen de los datos informados por todas las pruebas
realizadas:
Nro de Nro de Med Mi Ma Desv % Rendimi Kb/s Media de
Hilos Peticiones ia n x Estandar Error ento ec Bytes
59 15,4
25 250 104 43 6 156,74 0 8,3/sec 6 1897,1
58 18,4
500 101 30 148,28 0,00 10/sec 1.897,0
50 1 8
29 55,6
100 972 102 29 54 231,42 0,82 34,5/sec 9 1948,6
Tabla 4.23. Tabla resumen de las pruebas de rendimiento
91
Analizando los resultados de la tabla 4.23 se puede observar que trabajando con 100 hilos
concurrentes, hay un porcentaje de error de 0.82, sin embargo el número de usuarios estimado
es de 85, por lo que el sistema soporta la cantidad de usuarios prevista anteriormente.
4.2 SEGURIDAD
La seguridad es uno de los aspectos más importantes, siendo el software desarrollado para la
web y tomando en cuenta que los datos almacenados son de mucha importancia. Por lo tanto
las políticas y estrategias de control que se consideran con las siguientes:
 Políticas de control de acceso al Sistema Web.
 Políticas de respaldo de la base de datos.
 Políticas de registro de los eventos realizados por los usuarios.
4.2.1 POLÍTICAS DE CONTROL DE ACCESO AL SISTEMA WEB

Las políticas de control de acceso al sistema Web son:
 El acceso al sistema es controlado mediante el email que es el usuario y su contraseña.
 La encriptación se realiza mediante la función MD5 utilizado en la librería de

“encriptación”, desarrollado para la encriptación de contraseñas de los usuarios.
 Se hace el control de sesiones para que usuarios no autenticados no puedan ingresar

al sistema. El control de tiempo inactivo de la sesión, para cerrar automáticamente la
sesión que los usuarios que por cualquier motivo no lo hayan hecho.
4.2.2 POLÍTICAS DE RESPALDO A LA BASE DE DATOS

Las políticas de respaldo a la Base de Datos son:
 Los archivos de configuración para el acceso a la base de datos, el framework
CodeIgniter hace que las conexiones sean seguras.
 Al utilizar el comando "bind" del framework Codeigniter, los valores pasados a las
consultas de base de datos son automáticamente "escapados", produciendo consultas
seguras, no debiendo realizarse manualmente el "escape" de los parámetros.
92
$sql = "SELECT * FROM tabla WHERE x = ? AND y = ? AND z = ?";
$this->db->query($sql, array(u, 'v', 'w'));
 El respaldo de la base de datos es muy importante por lo cual se realiza el backups o
resguardo para la seguridad de la información.
4.2.3 POLÍTICAS DE REGISTROS DE EVENTOS

Los logs o eventos realizados por los usuarios en el sistema de información permiten el
seguimiento y monitoreo de los accesos de los usuarios a las diferentes funciones. Por ello
se diseñó campos para cuándo y quién realizo cambios en los valores de los campos de esta
forma realizar las auditorias correspondientes.
En la siguiente figura se muestra los campos para estos eventos.
Figura 4.11. Campos de registro de eventos

Para el buen uso del Sistema se recomienda lo siguiente:
 Se recomienda al administrador principal del Sistema Web, asignar o aumentar

ciertos privilegios, solo a usuarios capacitados para el manejo el mismo.
 Se recomienda a los usuarios el cambio periódico de sus contraseñas para la seguridad

de sus cuentas y principalmente del sistema.
 Se recomienda realizar el mantenimiento preventivo y correctivo del sistema para su

buen funcionamiento y prevención de fallas.
93
CAPÍTULO 5 ANÁLISIS COSTO BENEFICIO
5.1 COCOMO II
En todo proyecto es importante tener la planificación o estimación de costo del proyecto,
tanto de los costos en tiempo, y esfuerzo. Uno de los métodos para realizar es el COCOMO
II (COnstructive COst MOdel) orientado a los puntos función. Para estimar el costo total del
sistema se tomaran en cuenta los siguientes costos: Costo de la elaboración del proyecto,
costos del software desarrollado, costos de la implementación del Sistema.
El costo total del proyecto desarrollado es la suma del costo de software de desarrollo más el
costo de implementación más el costo de elaboración del proyecto.
5.1.1 COSTOS DEL SOFTWARE DESARROLLADO

Ahora aplicaremos las formulas básicas de esfuerzo, tiempo calendario y personal requerido.
Las fórmulas de COCOMO que utilizaremos serán las siguientes:
E = ab (KLDC)bb
D = cb (E)db
Dónde: E: Esfuerzo aplicado en personas por mes.
D: Tiempo de desarrollo en mes.
KLDC: Número estimado de líneas de código distribuidas (en miles).
En la siguiente tabla se muestran los tipos de proyectos de software.
Proyecto de software ab bb cb db
Orgánico 2.4 1.05 2.5 0.38
Semiacoplado 3.0 1.12 2.5 0.35
Empotrado 3.6 1.2 2.5 0.32
Tabla 5.1. Tipos de proyectos de Software

Fuente: COCOMO, Marvin Romero, 2013
94
Orgánicos: proyectos relativamente sencillos, menores de 50KDLC líneas de código, en los
cuales se tiene experiencia de proyectos similares y se encuentran en entornos estables.
Semiacoplados: proyectos intermedios en tamaño y complejidad y de tamaño (menores de

300 KDLC), donde la experiencia en este tipo de proyectos es variable y las restricciones
intermedias.
Empotrados: proyectos bastantes complejos en los que apenas se tiene experiencia y se

engloban en un entorno de gran innovación técnica. El proyecto al que se adecua al
Semiacoplado por lo tanto remplazando en las formulas anteriores tenemos:
Se utilizara el punto función encontrada donde PF = 1000, a continuación realizamos la

conversión de punto función a miles de líneas de código mediante la siguiente tabla.
Lenguaje Nivel Factor LDC/PF
Java 6 53
Visual Basic 7 46
ASP 9 36
Visual C++ 9.5 34
PHP 9 12
Ensamblador 10 320
C 9 150
Tabla 5.2. Factor LCD/PF de lenguajes de programación

Fuente: COCOMO, Marvin Romero, 2013
LDC = PF * Factor LDC/PF
LDC = 1000 * 12 = 12000
KLDC= 12
E = 3 * (12)1.12 = 48,50 [personas/mes]
95
D = 2.5 * (48,50)0.35 = 9,02 [meses]
El personal requerido para el desarrollo del proyecto se obtiene de la siguiente formula:
Número de programadores = E/D = 48,50/9,72 =4,98
Por lo tanto se necesitan 5 programadores para el desarrollo del proyecto. El costo de salario
por programador es de 80 $us/mes. Por lo tanto con este dato la estimación del costo del
software se calculará con la siguiente formula:
Costo de software = Número de Programadores x Salario del programador x Numero de

Meses
= 5 x600x9 = 3600 $us.
Por lo tanto el costo de desarrollo del software es de 27000 $us.
5.1.2 ANÁLISIS DE LOS BENEFICIOS CON EL VAN Y EL TIR

Para analizar los beneficios que se obtendrá con la implementación del sistema se hará uso
del método VAN y TIR. El VAN (Valor actual neto) es un indicador financiero que mide
los flujos de los futuros ingresos y egresos que tendrá el proyecto, para determinar si luego
de descontar la inversión inicial, nos quedaría alguna ganancia. Si el resultado es positivo,
el resultado es viable. Para hallar el VAN del proyecto de inversión requerimos tres valores
de acuerdo a la siguiente fórmula
𝑉𝐴𝑁 = 𝐵𝑁𝐴 − 𝐼𝑛𝑣𝑒𝑟𝑠𝑖𝑜𝑛

Donde BNA es el beneficio neto actualizado, el cual debe ser actualizado de acuerdo a la tasa
de descuento TD, que es la tasa de oportunidad, rendimiento o rentabilidad mínima que se
espera ganar. Entonces para hallar el VAN se necesitan: tamaño de la inversión, flujo de
caja neto proyectado y la tasa de descuento del 10% que se espera ganar, faltar el flujo de
caja neto proyectado que se lo obtiene del siguiente análisis
96
Descripción Año 1 Año 2 Año 3 Año 4 Año 5
Producto 16500 16500 16500 16500 16500
por uso de
software
Total 16500 16500 16500 16500 16500
Tabla 5.3. Ingresos
En la tabla 5.3 se espera ingresos por 16500 $us. Que provienen de recursos del uso del
producto.
Materiales directos
Hojas 230 235 240 245 250
Tinta para impresora 200 210 220 230 240
Material de escritorio (bolígrafos, lápices, 150 160 170 180 190
etc)
Remuneraciones al personal
Sueldo – Salario CAT 2(4 empleados) 4450 4450 4450 4450 4450
destinan un 25% de su tiempo
Sueldo – Salario CAT 5 (1 empleado) destina 4480 4480 4480 4480 4480
el 80%
Previsión social, indemnización, etc. 1000 1000 1000 1000 1000
Costos Indirectos
Comunicaciones 100 100 100 100 100
Depreciación(*) 1500 1500 1500 1500 0
Adecuación y/o Capacitación (**) 1500 1500 1500 1500 1500
Materiales indirectos (***) 500 500 500 500 500
Mano de obra indirecta (***) 500 500 500 500 500
Total 14610 14635 14660 14685 13210
Tabla 5.4. Total Egresos Estimados
En la tabla 5.4 de egresos estimados expresados en $us. Se tomarán en cuenta las siguientes
observaciones:
(*) La depreciación estimada
(**) La adecuación y/o capacitación, son gastos extraoficiales del sistema, puede que estos
recursos estimados se gasten en la adecuación del software, como también capacitación en el
sistema o uso de herramientas.
97
(***) Gastos extraoficiales por mal funcionamiento de hardware o software de las máquinas
y/o reparación de impresoras, scanner, etc.
Tomando en cuenta las observaciones anteriores a los gastos estimados, se tiene un costo de
14360 $us. En estos 5 años del proyecto.

Total Ingreso 16500 16500 16500 16500 16500
Total Egreso 14610 14635 14660 14685 13210
Flujo de Caja 1890 1865 1840 1815 3290
Tabla 5.5. Flujo de Caja Neto
En la tabla 5.5 se obtiene el flujo de caja neto, el cual es la diferencia entre ingresos y egresos.
El beneficio neto nominal sería de 10700, y la utilidad lógica sería de 5088.83 pero este
beneficio o ganancia no sería real (Solo nominal) por que no se estaría considerando el valor
del dinero en el tiempo, por lo que cada período debemos actualizarlo a través de una tasa de
descuento (Tasa de rentabilidad mínima que esperamos ganar). Aplicando la fórmula
tenemos:
1890 1865 1840 1815 3290 1890

𝑉𝐴𝑁 = 1
+ 2
+ 3
+ 4
+ 5
+
(1 + 0.1) (1 + 0.1) (1 + 0.1) (1 + 0.1) (1 + 0.1) (1 + 0.1)6
− 5611.17
𝑉𝐴𝑁 = 7924.4 − 5611.17
𝑉𝐴𝑁 = 2313.25
Como el resultado obtenido es mayor a cero en gran medida, se concluye que el proyecto es
viable y la utilización del sistema va por mucho más tiempo que cinco años.
La TIR (Tasa Interna de Retorno) es la tasa de descuento (TD) de un proyecto de inversión

que permite que el BNA sea igual a la inversión (VAN igual a 0). La TIR es la máxima TD
que puede obtener un proyecto para que sea rentable, pues una mayor tasa ocasionaría que el
BNA sea menor que la inversión (VAN menor a 0).
98
Entonces para hallar el TIR se necesita la inversión igual a 5611.17, además de los valores
de ganancia esperados son descritos en la tabla 5.5.
Para hallar el TIR hacemos uso de la fórmula del VAN, solo que en vez de hallar el VAN (El
cual reemplazamos por 0), estaríamos hallando la tasa de descuento.
1890 1865 1840 1815 3290

0= 1
+ 2
+ 3
+ 4
+ − 5611.17
(1 + 𝑟) (1 + 𝑟) (1 + 𝑟) (1 + 𝑟) (1 + 𝑟)5
𝑟 = 𝑇𝐼𝑅 = 24.00 %
Como el resultado obtenido es mayor a la tasa de descuento (TIR > TD), se concluye que el
proyecto es rentable.
99
CAPÍTULO 6 CONCLUSIONES Y RECOMENDACIONES
6.1 CONCLUSIONES
En el presente proyecto se desarrolló el Sistema Web de Gestión de Documentación y
Seguimiento de trámites basado en la Gestión de Proceso de Negocio o Business Process
Management (BPM), con el cuál se logró asegurar el control absoluto e instantáneo de la
documentación.
A continuación se describen los detalles de las mejoras.
 Se centralizó la información de la documentación emitida por las diferentes unidades,

administradoras y agencias para atender oportunamente los requerimientos
solicitados.
 Se posibilitó el reingreso del documento que cuenta con un número de hoja de ruta y
llega más de una vez a una unidad para no generar un nuevo correlativo.
 Se utilizó correlativos conformados por la sigla de la unidad acompañados por un
número único para controlar la emisión de los cites para su posterior seguimiento.
 Se elaboró alertas preventivas sobre el estado de la documentación para realizar el
cumplimiento de las actividades dentro de la institución.
 Se relacionó el seguimiento del trámite con la correspondencia entregada por el
beneficiario para conocer el estado en el que se encuentra.
 Se controló la generación de los cites de los documentos que fueron remitidos por los
funcionarios de una unidad con la respectiva aprobación del Jefe de Unidad y/o
Administrador.
6.2 RECOMENDACIONES
Las recomendaciones que se plantean a continuación son de importancia para la institución.
 Implementar el proyecto para capturar, indexar y almacenar los documentos

generados.
 Implementar el módulo de control de la información que sea impresa.
100
 Implementar el módulo de captura de información desde dispositivos como
impresoras, fax y scanner.
101
BIBLIOGRAFÍA
A continuación se menciona la bibliografía utilizada en el presente proyecto.
ACEBAL & CESAR F. 2002. Reglas y Practicas en eXtreme Programming
ANGELINE D.. 2011. 5 Razones para Programar con el Framework PHP CodeIgniter [en
linea] http://www.blogdephp.com/5-razones-para-programar-con-el-framework-php-
codeigniter/[Consulta: 10 octubre 2015]
ARANCIBIA R, C. 2004. Sistema de Registro de Correspondencia para la Compañia
Boliviana de Energia Electrica S.A. COBEE-BCP. Ingeniería de Sistemas Informáticos. La
Paz, Universidad Mayor de San Andrés, Facultad de Ciencias Puras y Naturales. 120p.
BECK K. 2003. Explicación de la Programación Extrema. 2da ed. Professional, Boston
Addison Wesley.
BECK & BEEDLE. 2001. Manifiesto para el Desarrollo Ágil de Software [En línea] http://
agilemanifesto.org [Consulta: 23 junio 2015].
BRAMBILLA Marco, B. S., 2014. Fifteen Years of Industrial Model-Driven Development
in Software Front-End: from WebML to WebRatio and IFML. Novática(228), 36.
BRAMBILLA Marco, F. P., 2014. Interaction Flow Modeling Language: Model-Driven UI
Engineering of Web and Mobile Apps with IFML. Morgan Kaufmann - Elsevier.
BRAMBILLA, M. C.,2012. Model-driven software engineering in practice (Vol. 1).
Synthesis Lectures on Software Engineering.
CALLA CH, R.A. Escritorio Web: Herramientas Colaborativas Administrativas. (Agenda
Telefonica, Activos Fijos, Marcados de Asistencia, Servicios y Enlaces) La Paz, Universidad
Mayor de San Andres, Facultad de Ciencias Puras y Naturales. 102p.
CAMARGO J.J., OTALORA J. E., ALVARADO A.B. 2010. Todo alrededor de BPM. [En
línea]<http://www.unilibre.edu.co/revistaingeniolibre/revista9/articulos/Todo-alrededor-de-
BPM.pdf> [consulta:15 junio 2015]
CHAVEZ Q,J. Sistema Web de Gestión de Proyectos. Ingeniería de Sistemas Informáticos.
La Paz, Universidad Mayor de San Andrés, Facultad de Ciencias Puras y Naturales. 109p.
102
CORINI G, A.R. Sistema Web de Registro, Seguimiento y Control de Correspondencia
Basado en BPM.). Ingeniería de Sistemas Informáticos. La Paz, Universidad Mayor de San
Andrés, Facultad de Ciencias Puras y Naturales. 104p.
DECRETO SUPREMO N° 27066, 2003. Bolivia: Ministerio de Economía y Finanzas
Públicas 12p. 6 de Junio. Artículo 6.
GUTIERREZ, D. 2011. Métodos de Desarrollo de Software. Universidad de los Andes. Julio
de 2011.
HANS V. 2002. La construcción y el razonamiento sobre conocimiento arquitectónico. Ed.
C. Hofmeister, I. Crnkovic y R. Reussner, Springer LNCS 4214, 2002, pp 39-47
HERRRERA N. 2011. Software para la Gestión de documentos y control de flujo de procesos
para la empresa Science&Technology LTDA. Ingeniera de Sistemas. Bucaramanga,
Universidad Industrial de Santander Facultad de Ingenieras Físico - Mecánicas Escuela de
Ingeniería de Sistemas e Informática. 126p.
HITPASS B. 2014. Business Process Management Fundamentos y Conceptos de
Implementación. 3era ed. Chile, BHH. 332p.
IBAÑES A. A, 2008. Chasqui Digital E-Correspondencia. Ingeniería de Sistemas
Informáticos. La Paz, Universidad Mayor de San Andrés, Facultad de Ciencias Puras y
Naturales. 131p.
JOSKOWINCZ J. 2000. Reglas y Prácticas en eXtreme Programming. [En línea] http://
http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf [Consulta 24
septiembre 2015]
MARTÍN P. 2015. Desarrollo por Modelos Basado en Componentes de Interfaz de Usuario.
Doctor en Ciencias Informáticas Universidad Nacional de la Plata Facultad de
Informática.138p.
OLSINA, D.L. (1999). Métricas, Criterios y Estrategias para Evaluar Calidad” Argentina:
Gidis, Facultad de Ingeniería, UNL Pan.
103
OSPINA D. 2012. Implementación de Sistema de Información MUREX usando la
metodología BPM (Business Process Management). Ingeniero de Sistemas. Medellin,
Universidad EAFIT Escuela de Ingeniería Departamento de Informática y Sistemas. 77p.
PAREDES G.,V. 2014. Escritorio Web: Inicio de la Plataforma Colaborativa (UTIStreaming,
UTIBook, UTIQuiosco, Normativa, Permisos, Cumpleaños, Quejas y Sugerencias).
Ingenieria de Sistemas Informaticos. La Paz, Universidad Mayor de San Andres, Facultad de
Ciencias Puras y Naturales. 110p.
PORTAL WEB SENASIR, 2014. Misión-Visión-Objetivos [En línea] http://www. senasir.
gob.bo/index.php/senasir/mision-vision-objetivos. [Consulta: 22 junio 2015].
PRESSMAN R. 2014. Ingeniería del Software: Un enfoque práctico. Ed. Mc Graw Hill. 7ma
ed. Bogotá Colombia.
SOMMERVILLE I. 2001. Ingeniería del Software. Ed. Pearson Addison Wesley. 3era ed.
Madrid España.
SURCO A. G, 2009. Sistema de envío y recepcion de documentos para la Fuerza Area
Boliviana. Ingeniería de Sistemas Informáticos. La Paz, Universidad Mayor de San Andrés,
Facultad de Ciencias Puras y Naturales. 121p.
104
ÍNDICE
1. MARCO INTRODUCTORIO ..................................................................................... 2

1.1 INTRODUCCIÓN ................................................................................................... 2
1.2 ANTECEDENTES .................................................................................................. 2
1.2.1 ANTECEDENTES INSTITUCIONALES .......................................................... 2
1.2.2 ANTECEDENTES DE PROYECTOS SIMILARES .......................................... 4
1.3 PLANTEAMIENTO DEL PROBLEMA................................................................. 5
1.3.1 PROBLEMA CENTRAL..................................................................................... 5
1.3.2 PROBLEMAS SECUNDARIOS ......................................................................... 5
1.4 DEFINICIÓN DE OBJETIVOS .............................................................................. 6
1.4.1 OBJETIVO GENERAL ....................................................................................... 6
1.4.2 OBJETIVOS ESPECÍFICOS ............................................................................... 6
1.5 JUSTIFICACIÓN .................................................................................................... 7
1.5.1 JUSTIFICACIÓN ECONÓMICA ....................................................................... 7
1.5.2 JUSTIFICACIÓN SOCIAL ................................................................................. 7
1.5.3 JUSTIFICACIÓN TECNOLÓGICA ................................................................... 8
1.6 ALCANCES Y LÍMITES ........................................................................................ 8
1.6.1 ALCANCES ......................................................................................................... 8
1.6.2 LÍMITES .............................................................................................................. 9
1.7 APORTES ................................................................................................................ 9
1.7.1 PRÁCTICO .......................................................................................................... 9
1.7.2 TEÓRICO........................................................................................................... 10
1.8 METODOLOGÍA .................................................................................................. 10
2. MARCO TEÓRICO ................................................................................................... 11

2.1 INGENIERÍA DE SOFTWARE ............................................................................ 11
2.2 CICLO DE VIDA DE DESARROLLO DEL SOFTWARE .................................. 12
2.3 MODELOS TRADICIONALES ........................................................................... 13
2.3.1 MODELO EN CASCADA ................................................................................ 13
2.3.2 MODELO ITERATIVO .................................................................................... 14
2.3.3 MODELO EN ESPIRAL ................................................................................... 15
2.3.4 MODELO DE PROCESO EVOLUTIVO ......................................................... 16
2.4 MANIFIESTO ÁGIL ............................................................................................. 16
105
2.5 MADUREZ DE SOFTWARE EN METODOLOGÍAS ÁGILES.......................... 19
2.6 DIFERENCIAS ENTRE LAS METODOLOGÍAS TRADICIONALES Y ÁGILES
19
2.7 METODOLOGÍA DE DESARROLLO DEL SISTEMA ...................................... 21
2.7.1 METODOLOGÍA DE DESARROLLO XP (eXtreme Programing) ................. 21
2.7.2 CICLO DE VIDA DE XP .................................................................................. 22
2.7.2.1 FASE DE PLANIFICACIÓN ..................................................................... 22
2.7.2.2 FASE DE DISEÑO ..................................................................................... 25
2.7.2.3 FASE DE CODIFICACIÓN ....................................................................... 26
2.7.2.4 FASE DE PRUEBAS ................................................................................. 28
2.8 METODOLOGÍAS DE MODELADO WEB ........................................................ 30
2.8.1 IFML .................................................................................................................. 31
2.8.1.1 MODELO DE DOMINIO .......................................................................... 32
2.8.1.2 MODELO DE LA LÓGICA DEL NEGOCIO ........................................... 33
2.8.1.3 MODELO DE LA COMPOSICIÓN DE LA INTERFAZ DE USUARIO 33
2.9 BPM ....................................................................................................................... 34
2.10 BPMN 2.0 .............................................................................................................. 35
2.10.1 USOS DE BPMN ........................................................................................... 36
2.10.2 NOTACIÓN ................................................................................................... 36
2.10.3 ELEMENTOS BÁSICOS .............................................................................. 36
2.10.3.1 ACTIVIDADES.......................................................................................... 37
2.10.3.2 COMPUERTAS.......................................................................................... 38
2.10.3.3 CONECTORES .......................................................................................... 39
2.10.3.4 RESPONSABILIDADES ........................................................................... 39
2.10.3.5 FASES ........................................................................................................ 40
2.11 MODELO MVC .................................................................................................... 40
2.11.1 CAPAS DEL MODELO MVC ...................................................................... 41
2.12 ARQUITECTURA FACADE................................................................................ 42
2.13 CORRESPONDENCIA ......................................................................................... 42
2.13.1 CORRESPONDENCIA EXTERNA .............................................................. 42
2.13.2 CORRESPONDENCIA INTERNA ............................................................... 43
2.13.3 CORRESPONDENCIA DE LAS REGIONALES ........................................ 43
3 MARCO APLICATIVO ............................................................................................. 44
106
3.1 SISTEMA WEB EMPLEANDO LA METODOLOGÍA XP Y EL MODELO IFML
44
3.2 FASE DE PLANIFICACIÓN ................................................................................ 44
3.2.1 CLASIFICACIÓN E IDENTIFICACIÓN DE ROLES (ACTORES) ............... 45
3.2.2 HISTORIAS DE USUARIO .............................................................................. 46
3.2.3 PLAN DE ENTREGA (RELEEASE PLANNING) .......................................... 49
3.2.3.1 PRIMERA ITERACIÓN ............................................................................ 50
3.2.3.2 SEGUNDA ITERACIÓN ........................................................................... 51
3.2.3.3 TERCERA ITERACIÓN ............................................................................ 51
3.2.4 VELOCIDAD DEL PROYECTO ...................................................................... 53
3.3 FASE DE DISEÑO ................................................................................................ 54
3.3.1 TARJETAS CRC ............................................................................................... 54
3.3.2 MODELO DEL DOMINIO ............................................................................... 55
3.3.3 MODELO DE LA LÓGICA DEL NEGOCIO .................................................. 58
3.3.4 MODELO COMPOSICIÓN DE LA INTERFAZ DE USUARIO .................... 61
3.3.4.1 MODELO PARA EL MÓDULO LOGIN .................................................. 61
3.3.4.2 MODELO PARA EL MÓDULO PRINCIPAL.......................................... 62
3.4 FASE DE CODIFICACIÓN .................................................................................. 63
3.5 FASE DE PRUEBAS ............................................................................................. 69
3.5.1 PRUEBAS DE ACEPTACIÓN ......................................................................... 69
4 MÉTRICAS DE CALIDAD Y SEGURIDAD .......................................................... 72
4.1 CALIDAD DE SOFTWARE ................................................................................. 72
4.1.1 INTRODUCCIÓN ............................................................................................. 72
4.1.2 DEFINICIÓN Y ESPECIFICACIÓN DE REQUERIMIENTOS DE CALIDAD
72
4.1.3 DEFINICIÓN E IMPLEMENTACIÓN DE LA EVALUACIÓN ELEMENTAL
75
4.1.4 DEFINICIÓN E IMPLEMENTACIÓN DE LA DEFINICIÓN GLOBAL ....... 78
4.1.5 RESULTADOS DE LA CALIDAD DEL SISTEMA ....................................... 87
4.1.6 PRUEBAS DE SOFTWARE ............................................................................. 88
4.1.6.1 PRUEBAS DE RENDIMIENTO ............................................................... 88
4.2 SEGURIDAD ........................................................................................................ 92
4.2.1 POLÍTICAS DE CONTROL DE ACCESO AL SISTEMA WEB .................... 92
4.2.2 POLÍTICAS DE RESPALDO A LA BASE DE DATOS ................................. 92
4.2.3 POLÍTICAS DE REGISTROS DE EVENTOS ................................................. 93
107
5 ANÁLISIS COSTO BENEFICIO ............................................................................ 94
5.1 COCOMO II .......................................................................................................... 94
5.1.1 COSTOS DEL SOFTWARE DESARROLLADO ............................................ 94
5.1.2 ANÁLISIS DE LOS BENEFICIOS CON EL VAN Y EL TIR ........................ 96
6 CONCLUSIONES Y RECOMENDACIONES ...................................................... 100
6.1 CONCLUSIONES ............................................................................................... 100
6.2 RECOMENDACIONES ...................................................................................... 100
BIBLIOGRAFÍA .............................................................................................................. 102
108
ÍNDICE DE FIGURAS
FIGURA 1.1. ORGANIGRAMA DEL SENASIR ........................................................................................................ 3
FIGURA 2.1. MODELO EN CASCADA ................................................................................................................. 14
FIGURA 2.2. MODELO ITERATIVO ..................................................................................................................... 14
FIGURA 2.3. MODELO EN ESPIRAL .................................................................................................................... 15
FIGURA 2.4. MODELO DE PROTOTIPOS ............................................................................................................ 16
FIGURA 2.5. FLUJO DE TRABAJO XP .................................................................................................................. 21
FIGURA 2.6. CICLO DE DESARROLLO TRADICIONALES ...................................................................................... 22
FIGURA 2.7. PRINCIPALES METODOLOGÍAS DE MODELADO PARA WEB ......................................................... 31
FIGURA 2.8. MODELO DE DOMINIO ................................................................................................................. 32
FIGURA 2.9. MODELO DE LA LÓGICA DEL NEGOCIO ........................................................................................ 33
FIGURA 2.10. MODELO DE LA COMPOSICIÓN DE LA INTERFAZ ....................................................................... 34
FIGURA 2.11. DESARROLLO DE BPM ................................................................................................................ 34
FIGURA 2.12. GANANCIA EN PRODUCTIVIDAD EN EL DESARROLLO DE APLICACIONES .................................. 35
FIGURA 2.13. ELEMENTOS BÁSICOS BPMN ...................................................................................................... 37
FIGURA 2.14. CANALES O SWINLANES BPMN .................................................................................................. 39
FIGURA 2.15. CANALES O SWINLANES BPMN .................................................................................................. 40
FIGURA 2.16. ARQUITECTURA MODELO VISTA CONTROLADOR. ..................................................................... 41
FIGURA 2.17. ARQUITECTURA FACADE EN EL SISTEMA ................................................................................... 42
FIGURA 3.1. CRONOGRAMA DE ACTIVIDADES: ITERACIONES DEL PROYECTO. ............................................... 53
FIGURA 3.2. MODELO DE DOMINIO DEL SISTEMA WEB................................................................................... 56
FIGURA 3.3. MODELO ENTIDAD - RELACIÓN .................................................................................................... 57
FIGURA 3.4. CORRESPONDENCIA INTERNA ...................................................................................................... 58
FIGURA 3.5. PRÉSTAMO DE DOCUMENTOS ..................................................................................................... 59
FIGURA 3.6. CORRESPONDENCIA EXTERNA ..................................................................................................... 60
FIGURA 3.7. DIAGRAMA IFML PANTALLA DE INICIO ........................................................................................ 61
FIGURA 3.8. PANTALLA DE INICIO .................................................................................................................... 62
FIGURA 3.9. DIAGRAMA IFML MÓDULO PRINCIPAL ........................................................................................ 63
FIGURA 3.10. LOGIN ......................................................................................................................................... 64
FIGURA 3.11. DOCUMENTOS ELABORADOS ..................................................................................................... 64
FIGURA 3.12. CORRESPONDENCIA PENDIENTE ................................................................................................ 65
FIGURA 3.13. DOCUMENTOS ENVIADOS .......................................................................................................... 65
FIGURA 3.14. NUEVA CORRESPONDENCIA INTERNA ....................................................................................... 66
FIGURA 3.15. NUEVA CORRESPONDENCIA INTERNA ....................................................................................... 66
FIGURA 3.16. NUEVA CORRESPONDENCIA EXTERNA PARA DATOS DEL DOCUMENTO ................................... 67
FIGURA 3.17. NUEVA CORRESPONDENCIA EXTERNA PARA DATOS DE LA ASIGNACIÓN ................................. 67
FIGURA 3.18. NUEVA CORRESPONDENCIA EXTERNA DATOS DE LA INSTITUCIÓN ........................................... 68
FIGURA 3.19. DATOS DEL DOCUMENTO .......................................................................................................... 68
FIGURA 4.1. TRES FUNCIONES SIMPLES DE AGREGACIÓN DE PREFERENCIAS ................................................. 78
FIGURA 4.2. EJEMPLO DE ESTRUCTURA DE AGREGACIÓN DE PREFERENCIAS PARCIALES PARA LA
CONFIABILIDAD Y EFICIENCIA ................................................................................................................. 78
FIGURA 4.3. EJEMPLO DE ESTRUCTURA DE AGREGACIÓN DE PREFERENCIAS PARCIALES PARA LA USABILIDAD
Y FUNCIONALIDAD .................................................................................................................................. 79
FIGURA 4.4. PREFERENCIAS PARCIALES PARA LAS CARACTERÍSTICAS DE MÁS ALTO NIVEL ............................ 87
109
FIGURA 4.5. REPORTE RESUMEN CON 25 HILOS CONCURRENTES................................................................... 88
FIGURA 4.6. GRÁFICO DE RESULTADOS CON 25 HILOS CONCURRENTES ......................................................... 89
FIGURA 4.7. REPORTE RESUMEN CON 50 HILOS CONCURRENTES................................................................... 89
FIGURA 4.8. GRÁFICO DE RESULTADOS CON 50 HILOS CONCURRENTES ......................................................... 90
FIGURA 4.9. REPORTE RESUMEN CON 100 HILOS CONCURRENTES................................................................. 90
FIGURA 4.10. GRÁFICO DE RESULTADOS CON 100 HILOS CONCURRENTES ..................................................... 91
FIGURA 4.11. CAMPOS DE REGISTRO DE EVENTOS .......................................................................................... 93
110

SISTEMA WEB DE GESTIÓN DE DOCUMENTACIÓN Y Seguimienoto

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SISTEMA WEB DE GESTIÓN DE DOCUMENTACIÓN Y Seguimienoto

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

SISTEMA WEB DE GESTIÓN DE DOCUMENTACIÓN Y

PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

La misión: “Servicio Nacional del Sistema de Reparto (SENASIR)”, otorgar y pagar

La institución al ser de naturaleza exclusivamente operativa, tiene las siguientes atribuciones:

La Entidad posee una jerarquía de unidad de funcionamiento con la finalidad de organizar,

Secretaria general Auditoría interna

Unidad Unidad de Unidad Unidad Jurídica Unidad

Figura 1.1. Organigrama del SENASIR

1.3 PLANTEAMIENTO DEL PROBLEMA

1.3.1 PROBLEMA CENTRAL

1.3.2 PROBLEMAS SECUNDARIOS

1.4 DEFINICIÓN DE OBJETIVOS

1.4.1 OBJETIVO GENERAL

1.4.2 OBJETIVOS ESPECÍFICOS

1.5.1 JUSTIFICACIÓN ECONÓMICA

1.5.2 JUSTIFICACIÓN SOCIAL

1.5.3 JUSTIFICACIÓN TECNOLÓGICA

1.6 ALCANCES Y LÍMITES

2.2 CICLO DE VIDA DE DESARROLLO DEL SOFTWARE

A estos modelos se les denomina “Modelos de Ciclo de Vida del Software”.

A continuación se muestran algunos de los modelos tradicionales, más utilizados.

2.3.1 MODELO EN CASCADA

2.3.2 MODELO ITERATIVO

Figura 2.2. Modelo Iterativo

2.3.3 MODELO EN ESPIRAL

Figura 2.3. Modelo en Espiral

Figura 2.4. Modelo de Prototipos

2.5 MADUREZ DE SOFTWARE EN METODOLOGÍAS ÁGILES

2.6 DIFERENCIAS ENTRE LAS METODOLOGÍAS TRADICIONALES Y

Tabla 2.2. Diferencias entre metodologías ágiles y no ágiles.

Figura 2.5. Flujo de Trabajo XP

Figura 2.6. Ciclo de Desarrollo Tradicionales

2.7.2.1 FASE DE PLANIFICACIÓN

Tabla 2.3 Historia de Usuario

Tabla 2.4. Tarjetas C.R.C

2.7.2.3 FASE DE CODIFICACIÓN

a) Cliente siempre presente

b) Codificar primero la prueba

2.7.2.4 FASE DE PRUEBAS

2.8 METODOLOGÍAS DE MODELADO WEB

2.8.1.1 MODELO DE DOMINIO

Figura 2.8. Modelo de Dominio

Figura 2.9. Modelo de la Lógica del Negocio

2.8.1.3 MODELO DE LA COMPOSICIÓN DE LA INTERFAZ DE USUARIO

Figura 2.11. Desarrollo de BPM

Figura 2.12. Ganancia en Productividad en el desarrollo de aplicaciones

2.10.1 USOS DE BPMN

2.10.3 ELEMENTOS BÁSICOS

Actividades Compuestas Las actividades compuestas son Sub-

Cuando se utiliza una compuerta

Tabla 2.6. BPMN Compuertas

Figura 2.14. Canales o Swinlanes BPMN

Figura 2.15. Canales o Swinlanes BPMN

2.11 MODELO MVC

Figura 2.16. Arquitectura Modelo Vista Controlador.

2.12 ARQUITECTURA FACADE