Escolar Documentos
Profissional Documentos
Cultura Documentos
As como en la actualidad, las organizaciones son cada vez complejas, cada da incorporan
nuevas tecnologas a su forma de trabajar con lo que consiguen competir en el mercado
globalizado que el mundo actualmente maneja. Por esta razn es importante la
implementacin y la utilizacin de la tecnologa en las actividades de desarrollo institucional
permitiendo de esta manera mejorar la forma de trabajo, logrando hacerse competitivos.
1
Algunos expertos comparan la era de la Revolucin Industrial con la poca que actualmente
est viviendo la tecnologa, pues cada da se utiliza nuevas aplicaciones software, nuevos
equipos, nuevas maneras de hacer las cosas y la organizacin que no est preparada para estos
cambios, (que no tenga capacidad de informacin o que la misma sea muy dbil) simplemente
no puede competir contra el resto de organizaciones, es por tal razn que en la empresa de
comunicacin UNITEL- Oruro se desarrollara un sistema de informacin para el rea
Comercial, el cual coadyuvara en la toma de decisin en los procesos que se llevan a cabo
dentro de esta.
ANTECEDENTES
En la Radio y la Televisin han sido valiosos los avances en programas computarizados para
la edicin de imgenes y sonido, as como la inclusin de sistemas cada da ms
especializados para lograr transmisiones a distancia en directo. As, desde siempre la
evolucin de la tecnologa ha sido tambin importante para mejorar la labor de los medios de
comunicacin. En el Cine por su parte, ya se habla de dibujos animados elaborados totalmente
a travs de programas de computacin y los efectos especiales son ms accesibles. Adems,
todos estos avances, aunque resulten costosos al inicio, han logrado en cada medio de
comunicacin el abaratamiento de los procesos tanto de produccin como de transmisin de
sus mensajes.
Las emisoras de ATB La Paz, Bolivisin, PAT, Televisin Boliviana, Red Uno, UNITEL
Cochabamba, cuentan con sistemas de informacin administrativas para el manejo de la
informacin generada por los procesos administrativos. En los Dpto. de comercializacin y
otros Departamentos en general cuentan con sistemas de informacin los cuales son de su
propiedad.
UNITEL Potos, UNITEL Cobija, UNITEL Oruro, UNITEL Sucre, UNITEL Tarija y
UNITEL Trinidad, son compaas regionales de administracin autnoma, respecto a la
administracin centralizada de UNITEL La Paz, UNITEL Santa Cruz, UNITEL
Cochabamba.
2
UNITEL Oruro
A mediados del ao 1988 canal 2 TVO por entonces en la frecuencia 3, nace como iniciativa
de realizar una tele club, tomando conciencia que hacer televisin en ese entonces significaba
una inversin considerable, por ello el riesgo de apostar al avance tecnolgico en nuestra
ciudad y su desarrollo, hace que el pionero Juan Carlos Soria Mendoza cumpla los sueos de
muchos oriundos de sta. Por supuesto que por las transformaciones y dada las circunstancias
esto hizo que naciera la primera televisin privada en Oruro y un 1ro de noviembre se ingres
como canal 3, fecha en la que se comienza a compartir la televisin con toda la poblacin de
nuestra ciudad. (SORIA, 2015) (Anexos A)
3
ESTRUCTURA DE LA INSTITUCIN
4
INFORMACIN DOCUMENTAL Y ESTADSTICA
UNITEL LaPaz 40
UNITEL Santa Cruz 42
UNITEL Cochabamba 60
UNITEL Potos 35
UNITEL Cobija 20
UNITEL Oruro 60
UNITEL Sucre 56
UNITEL Tarija 60
UNITEL Trinidad 50
TOTAL 47
UNITEL RANCKING
Trinidad UNITEL La Paz
12% 10%
UNITEL Santa
UNITEL Tarija Cruz
14% 10%
UNITEL
UNITEL Sucre Cochabamba
13% 14%
UNITEL Potos
UNITEL Oruro UNITEL Cobija 8%
14% 5%
Figura2. Estadstica de Audiencia
Fuente: (Soria, 2014).
5
Realizando un diagnstico y seguimiento al flujo de trabajo de la empresa de comunicacin
UNITEL ORURO, especficamente hablando del rea afectada en este caso el rea
Comercial. Esta rea es encargada directa de realizar todos los Registro de la Cartera de
Clientes, los diversos Contratos Publicitarios que se manejan actualmente, se encarga tambin
del Registro de los Pagos y Plan de Pagos, as mismo el registro de los diferente Paquetes
Publicitarios que se hace para un determinado cliente, tambin registra y genera el Pauteo para
el cliente, Registro de la Programacin y los tarifarios. Teniendo un reporte de 80 contratos
aproximadamente que se realizan por mes, ya sea por avisos, difusin de espacios convenidos,
venta de espacios alquilados, venta de cromas, venta de rejillas bajas y otros, como muestra se
muestra en la tabla 2 y la figura 3.
Difusin de Espacios
Convenidos Venta de Rejilla Baja
1% 21%
Venta de Espacios
Alquilados
2%
Venta de Avisos
Espacios 50%
Publicitarios
16%
Venta de
Cromas
10%
Figura3.Contratos mensuales
Fuente: (OLMOS, 2016)
6
TRABAJOS DESARROLLADOS
SITUACIN PROBLEMTICA
La elaboracin manual del registro de los datos del cliente ocasiona la demora en la
realizacin de los contratos. Adems, prdida de estos y duplicidad de la informacin.
El deficiente control en los reportes que se realizan de forma manual de los planes de
pagos del cliente provoca pagos retrasados y prdidas econmicas considerables.
El Seguimiento inadecuado del control de los pauteos que se realizan en forma manual
hace que el encargado de la difusin del spot duplique las salidas de la publicidad de
los clientes o caso contrario no difunda algunos pases.
7
La no elaboracin de rdenes de difusin origina reclamos de clientes al encargado de
emisin por la no difusin de su spot en fecha exacta segn sus contratos.
Una vez que se hizo un anlisis crtico sobre los problemas de la empresa en el rea comercial,
nace la pregunta:
OBJETIVO GENERAL
OBJETIVOS ESPECFICOS
Disear la Base de Datos correspondiente, para organizar los datos que el sistema
utilizara para mejorar el manejo de la informacin.
Construir la interface de usuario que permitan una interaccin Usuario Sistema para
proporcionar informacin necesaria.
8
Evaluar la aplicacin desarrollada, realizando las pruebas de valoracinpara evaluar la
funcionalidad e integridad del sistema.
OBJETO DE ESTUDIO
CAMPO DE ACCIN
HIPTESIS
9
JUSTIFICACIONES
JUSTIFICACIN TCNICA
JUSTIFICACIN ECONMICA
Los beneficios tangibles de los sistemas de informacin son el tiempo y el dinero que se
ahorra cuando se automatiza los procesos. El presente proyecto se justifica econmicamente
por que permitir reducir costos y gastos administrativos del rea Comercial. Asimismo, el
manejo del sistema de informacin reducir los tiempos en los procesos administrativos,
evitando realizar tareas complementarias innecesarias por prdida de contratos y otros.
JUSTIFICACIN SOCIAL
10
ALCANCES Y LIMITACIONES
ALCANCES
Posibilitar una comunicacin fluida entre los encargados de emisin y el rea comercial
sobre manejo de informacin sobre los pauteos1 obteniendo de esta manera una mejoraen
los procedimientos que se llevan a cabo para la emisin de los Spot Publicitarios.
LIMITACIONES
1
Hoja de detalle para el cliente, referente a la cantidad de pases y programas donde se emitir su respectivo spot
publicitario
11
APORTE TERICO
APORTE PRCTICO
Los clientes quienes utilizan los servicios que brinda a la empresa UNITEL - ORURO a
quienes se atender de forma eficiente y eficaz.
APORTE ACADMICO
La metodologa puede ser adaptada y adecuada a cualquier trabajo de proyectos, ya sean estos
sencillos o complejos, podr constituirse en un aporte acadmico para la carrera de ingeniera
de Sistemas e Informtica.
12
INGENIERA DEL PROYECTO
METODOLOGA
MTODO/MODELO
OBJETIVOS
TCNICA Y ACTIVIDAD
ESPECFICOS
HERRAMIENTAS
Determinar los
requerimientos del rea
Comercial de la empresa de Mtodo Furps+2
Recogida de informacin.
comunicacin UNITEL Entrevistas.
Captura de requisitos
ORURO, con el propsito Metodologa aUP
Disear el Modelado del
de alcanzar un adecuado correspondiente a la Fase
Negocio
conocimiento del rea y de Inicio
generar de manera Herramienta Rational Rose
apropiada el diseo del
sistema a desarrollar.
Metodologa aUP
Analizar los requerimientos Recolectar informacin
correspondiente a la Fase
de la empresa para para el diseo.
de Elaboracin
estructurar el modelo del Realizar el anlisis de los
Herramienta Enterprise
sistema. diagramas de casos de uso
Architect
Graficar Diagrama de
Disear la Base de Datos Metodologa aUP
Secuencias
correspondiente, para correspondiente a la Fase
Graficar diagrama de
organizar los datos que el de Elaboracin
clases
sistema utilizara para Herramienta Enterprise
Estructurar el modelo
mejorar el manejo de la Architect
relacional y la base de
informacin. Herramienta SQL Server
datos
Construir la interface de Lenguaje Unificado de
Modelacin UML. Seleccionar la plataforma
usuario que permita una
Metodologa aUP de trabajo
interaccin Usuario correspondiente a la Fase Programacin y
Sistema para proporcionar de Construccin, diseo de produccin de software
entradas y salidas Desarrollar el sistema de
informacin necesaria.
Herramienta Enterprise informacin.
Architect
2
Es un acrnimo de las siglas en ingls, establece cinco caractersticas como factores de calidad.
13
METODOLOGA
MTODO/MODELO
OBJETIVOS
TCNICA Y ACTIVIDAD
ESPECFICOS
HERRAMIENTAS
Evaluar la aplicacin
Lenguaje Unificado de Elaboracin del diagrama
desarrollada, realizando las
Modelacin UML. de componentes
pruebas de valoracin para Metodologa aUP Diagrama de despliegue
evaluar la funcionalidad e correspondiente a la Fase Disear el plan de pruebas
de Construccin - Elaboracin de pruebas y
integridad del sistema.
su verificacin
14
1.1 INTRODUCCIN
Es una disposicin de personas, actividades, datos, reales y tecnologa integrados entre s con
el propsito de apoyar y mejorar las operaciones cotidianas de una empresa, as como
satisfacer las necesidades de informacin para la resolucin de problemas y la toma de
decisiones por parte de los directivos de la empresa.
1.3METODOLOGA aUP
En la actualidad muchos productos de software tienen que ser capaces de integrarse a sistemas
presentes en las organizaciones. En algunos casos se trata de perfeccionar sistemas,
desarrollados anteriormente, en otros de construir mdulos nuevos para que interacten con
sistemas ya existentes y finalmente en otras instituciones se trata de crear un sistema de
informacin nuevo. Este ltimo es precisamente el caso desarrollado en el presente proyecto.
15
Para conocer el funcionamiento del sistema en estudio recurrimos al lenguaje de modelado
UML yaUP, este lenguaje es una de las herramientas ms interesantes en el mundo actual del
desarrolla de Sistema. Esto se debe a que permite a los creadores de sistemas generar diseos
que capturen las ideas en una forma convencional y fcil de comprender para comunicarlas a
otras personas y a los interesados en el mismo.
Al igual que el RUP el aUP toma la misma divisin de sus fases, obsrvese en la siguiente
figura 1.2, con la nica modificacin que el aUP reagrupa algunas de las disciplinas.
Fases
Concepcin Elaboracin Construccin Transicin
Disciplina y Actividades
Proceso
Modelado del Negocio
Implementacin
Test y pruebas
Despliegue
Apoyo
Configuracin y cambio
Direccin del Proyecto
Adaptacin
I1 E1 C1 C2 CN T1 T2
Iteraciones
1.3.2.1 Concepcin
Identificar el alcance inicial del proyecto, proveer una arquitectura potencial para el sistema,
y obtener un financiamiento inicial del proyecto y la aceptacin de los stakeholders.
En esta fase se establece el caso del negocio con el fin de delimitar el alcance del sistema,
saber qu se cubrir y delimitar el alcance del proyecto. Es decir, esta fase pone en marcha el
proyecto.
17
Priorizar Casos de Uso, detallar caso de Uso
Estructurar el modelo de casos de Uso
1.3.2.2 Elaboracin
Probar la arquitectura del sistema; hacer un prototipo de arquitectura que elimine los riesgos
tcnicos para probar que el proyecto es factible.
Su objetivo principal es plantear la arquitectura para el ciclo de vida del producto. En esta fase
se realiza la captura de la mayor parte de los requerimientos funcionales, manejando los
riesgos que interfieran con los objetivos del sistema, acumulando la informacin necesaria
para el plan de construccin y obteniendo suficiente informacin para hacer realizable el caso
del negocio. En esta fase se realiza actividades como:(JACOBSON, 2000)
1.3.2.3 Construccin
De forma regular e incremental, construir software que funcione y satisfaga las necesidades
de mayor prioridad de los stakeholders del proyecto.
Su objetivo principal es alcanzar la capacidad operacional del producto. En esta fase a travs
de sucesivas iteraciones e incrementos se desarrolla un producto software, listo para operar,
ste es frecuentemente llamado versin beta. Se ejecutan actividades tales como:
(JACOBSON, 2000)
18
Se desarrollan todos los casos de uso a travs de iteraciones.
Se obtiene la documentacin completa del software.
1.3.2.4 Transicin
Su objetivo principal es realizar la entrega del producto operando, una vez realizadas las
pruebas de aceptacin por un grupo especial de usuarios y habiendo efectuado los ajustes y
correcciones que sean requeridos. Se efectan actividades tales como: (JACOBSON, 2000)
Definen actividades que el equipo de desarrolladores debe realizar para construir, validar y
entregar un software que satisfaga las necesidades de los stakeholders.
Modelado
19
La participacin activa de los stakeholders es fundamental para el xito.
Se recomienda la arquitectura en capas.
Implementacin
Pruebas. Realizar una evaluacin de los objetivos para asegurar la calidad. Esto
incluye encontrar defectos, validar que el sistema funciona como fue diseado y
Despliegue. Planear la entrega del sistema y ejecutar el plan para hacer que el sistema
El UML, est compuesto por diversos elementos grficos que se combinan para formar
diagramas con finalidad de presentar diversas perspectivas de un sistema y obtener un
resultado. Durante este proceso las mejores soluciones son logradas permitiendo un alto grado
de lluvia de ideas, es lo que llamamos Desarrollo Conjunto de Aplicaciones, donde participan
todos los usuarios potenciales del sistema a ser diseado.
20
1.4.1 DIAGRAMAS DE CASOS DE USO
Un caso de uso(figura 1.3) esuna secuencia de transacciones que son desarrolladas por un
sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de
casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema
mediante su interaccin con los usuarios y/u otros sistemas. O lo que es igual, un diagrama
que muestra la relacin entre los actores y los casos de uso en un sistema. Una relacin es una
conexin entre los elementos del modelo, por ejemplo, la relacin y la generalizacin son
relaciones.
Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al
mostrar cmo reacciona una respuesta a eventos que se producen en el mismo. En este tipo de
diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema
que se modela y que puede interactuar con l; un ejemplo de actor podra ser un usuario o
cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes:
estereotip
o
generalizacin
21
Alcances del Sistema:
La caja representa el lmite (alcance) del sistema, esto puede ser til cuando se modela
un sistema complejo el cual se divide en subsistemas, ayuda a dejar claro qu
subsistema se est modelando.
El caso ms vital es cuando se puede sacar factor comn del comportamiento de dos o
ms casos de uso originales
Un diagrama que utiliza <<include>> probablemente est mejor visto como refinamiento de
tal diagrama, sobre el que se han tomado algunas decisiones de diseo
Generalizaciones
Dos actores, o dos casos de uso, pueden estar relacionados por medio de la generalizacin, al
igual que dos clases, cuando los casos de uso estn relacionados a travs de una generalizacin
la idea es mostrar una tarea y una versin especializada de la misma.
22
1.4.2 DIAGRAMAS DE CLASES
Los diagramas de clases(figura 1.4) representan un conjunto de elementos del modelo que son
estticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre
ellos.
Algunos de los elementos que se pueden clasificar como estticos son los siguientes:
Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se
representa un grupo de elementos del modelo. Un sistema es un nico paquete que contiene el
resto del sistema, por lo tanto, un paquete debe poder anidarse, permitindose que un paquete
contenga otro paquete.
Clases: Una clase representa un conjunto de objetos que tienen una estructura, un
comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto
de objetos que comparte los mismos atributos, operaciones, mtodos, relaciones y significado.
En UML una clase es una implementacin de un tipo. Los componentes de una clase son:
Atributo. Representa alguna propiedad de la clase, que se encuentra en todas las instancias de
la clase, definen la estructura de una clase y de sus correspondientes objetos. Los atributos
corresponden a sustantivos y sus valores pueden ser sustantivos o adjetivos.
Dentro de una clase, los nombres de los atributos deben ser nicos (aunque puede aparecer el
mismo nombre de atributo en diferentes clases).
23
Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo
e incluso su valor por defecto.
Operacin. Tambin conocido como mtodo, es un servicio proporcionado por la clase que
puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se
realiza.
Las clases pueden tener varios parmetros formales, son las clases denominadas plantillas.
Sus atributos y operaciones vendrn definidos segn sus parmetros formales. Las plantillas
pueden tener especificados los valores reales para los parmetros formales, entonces reciben el
nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en el que se
podra aparecer su plantilla.
Relacionando con las clases nos encontramos con el trmino utilidad, que se corresponde con
una agrupacin de variables y procedimientos globales en forma de declaracin de clase,
tambin puede definirse como un estereotipo (o nueva clase generada a partir de otra ya
existente) de un tipo que agrupa variables globales y procedimientos en una declaracin de
clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y
operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser
conveniente durante la programacin.
Relacin entre clases: Las clases se relacionan entre s de distintas formas, que marcan los
tipos de relaciones existentes:
Asociacin:
Es una relacin que describe un conjunto de vnculos entre clases. Pueden ser binarias o n-
arias, segn se implican a dos clases o ms. Las relaciones de asociacin vienen identificadas
por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las
clases, en el caso del rol de asociacin (existen otros tipos de roles segn la relacin a la que
identifiquen). Indican la informacin ms importante de las asociaciones. Es posible indicar
el nmero de instancias de una clase que participan en una relacin mediante la llamada
multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos
24
que se relacionan pueden estar ordenados. Las relaciones de asociacin permiten especificar
qu objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un
atributo o conjunto de atributos de una asociacin que determina los valores que indican
cuales son los valores que se asociarn.
Una asociacin se dirige desde una clase a otra (o un objeto a otro), el concepto de
navegabilidad se refiere al sentido en el que se recorre la asociacin.
Existe una forma especial de asociacin, la agregacin, que especifica una relacin entre las
clases donde el llamado "agregado" indica el todo y el "componente" es una parte del mismo.
Composicin:
Es un tipo de agregacin donde la relacin de posesin es tan fuerte como para marcar otro
tipo de relacin. Las clases en UML tienen un tiempo de vida determinado, en las relaciones
de composicin, el tiempo de vida de la clase que es parte del todo (o agregado) viene
determinado por el tiempo de vida de la clase que representa el todo, por tanto, es equivalente
a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos.
Generalizacin:
Cuando se establece una relacin de este tipo entre dos clases, una es una Superclase y la otra
es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase.
Puede haber ms de una clase que se comporte como subclase.
Dependencia:
Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay
varios tipos:
25
Diagrama de secuencia.
Diagrama de colaboracin.
Diagrama de estado.
Diagrama de actividad.
Muestran las interacciones entre un conjunto de objetos, ordenadas segn el tiempo en que
tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado
parecido al de los objetos representados en los diagramas de colaboracin, es decir son
instancias concretas de una clase que participa en la interaccin. El objeto puede existir slo
durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la
ejecucin de la interaccin. Un diagrama de secuencia representa una forma de indicar el
perodo durante el que un objeto est desarrollando una accin directamente o a travs de un
procedimiento.
En este tipo de diagramas tambin intervienen los mensajes, que son la forma en que se
comunican los objetos: el objeto origen solicita (llama a) una operacin del objeto destino.
Existen distintos tipos de mensajes segn cmo se producen en el tiempo: simples, sncronos,
y asncronos.
26
Diagramas de componentes
Diagrama de plataformas despliegue
Los requisitos son capacidades y condiciones con las cuales debe estar conforme el sistema. El
primer reto del trabajo de los requisitos es encontrar, comunicar y recordar lo que realmente se
necesita, de manera que tenga un significado claro para el cliente y para los desarrolladores.
Los requisitos se clasifican de acuerdo al modelo FURPS+ (Functional, Usability, Reliability,
Performance, Supportability) (Anexos 1)
27
Evidentemente, los requisitos influyen en la arquitectura del sistema. Se entiende como
arquitectura los diferentes paquetes que constituyen el proyecto. Es el nivel ms elevado de
abstraccin del proyecto y define los componentes que van a participar en la elaboracin del
sistema.
La Definicin de requerimientos
La Especificacin de requerimientos
Modelo FURPS+, usando el acrnimo FURPS (por las siglas en ingls) para describir las
principales categoras de requisitos:
Funcionalidad
Facilidad de Uso
Confiabilidad
Rendimiento
Soporte
El signo + dentro del nombre del modelo indica que se deben de incluir requisitos tales
como:
Restricciones de diseo
Requisitos de Implementacin
Requisitos de Interface
Requisitos Fsicos
28
1.6 MTODO DE EVALUACIONES SUMARIAS
c. Asignacin de puntajes a los tems. - Se asigna un puntaje a cada tem a fin de clasificarlos
segn reflejen actitudes positivas o negativas.
29
1.6.2 FORMATO DE UN TPICO ELEMENTO DE EVALUACIONES SUMARIAS
CON 5 NIVELES DE RESPUESTA
Definitivamente Si
Probablemente Si
Indeciso
Probablemente No
Definitivamente No
Se debe hacer una distincin importante entre la escala de tipo Likert y elemento de tipo
Likert, la escala es una suma de las respuestas de los elementos del cuestionario. Los
elementos Likert van acompaados por una escala visual anloga.
Al inicio de un proyecto de software, cuando apenas se conoce los casos de uso y sus actores
asociados, se puede proyectar una breve descripcin de cada caso de uso, en el cual se
describe de forma breve la funcionalidad que este debe brindar.
30
El UUCP son los puntos de caso de uso sin ajustar, estos nos pueden servir para tener una idea
un poco ms precisa de la dificultad de los casos de uso e interfaces, tomado en cuenta los
pesos de los actores (UAW) y los pesos de los casos de uso (UUCW).
Donde:
Aplicando el anlisis de punto de funcin a estos casos de uso, se puede obtener una
estimacin trivial del tamao y a partir de ella una estimacin del esfuerzo.
Consiste en la evaluacin de la complejidad de los actores con los que tendr que interactuar el
sistema. Este puntaje se calcula determinando si cada actor es una persona u otro sistema, a la
forma en que este interacta con el caso de uso, y la cantidad de actores de cada tipo, ver
siguiente tabla:
Para determinar el nivel de complejidad se puede realizar mediante dos mtodos: basado en
transacciones o basado en clases de anlisis.
Una transaccin es un conjunto de actividades atmicas, lo que quiere decir que se ejecutan
todas o no se ejecutan ninguna.
TIPO DE CASO
DESCRIPCIN FACTOR
DE USO
SIMPLE 3 transacciones o menos 5
MEDIO 4 a 7 transacciones 10
COMPLEJO Ms de 7 transacciones 15
Basado en clases de anlisis: Toma en cuenta el nmero de clases que tiene un caso de uso y
lo evala segn la siguiente tabla:
32
= =
=1 . (3)
Este se compone de 13 puntos que evalan la complejidad de los mdulos del sistema que se
desarrolla, cada uno de estos factores tienen un peso definido con los cuales se obtendr
puntos ponderados por cada uno de ellos, segn la valoracin que se le asigne.
33
T11 Incluye objetivos especiales de seguridad 1
T12 Provee acceso directo a terceras partes 1
T13 Se requiere facilidades especiales de 1
entrenamiento a usuario
DESCRIPCIN VALOR
Irrelevante De 0 a 2
Medio De 3 a 4
Esencial 5
Factores ambientales.
Los factores sobre los cuales se realiza la evaluacin son 8 puntos, que estn relacionados con
las habilidades y experiencia de grupo de personas involucradas con el desarrollo del proyecto
FACTOR DESCRIPCIN PESO
E1 Familiaridad con el modelo del proyecto utilizado 1.5
E2 Experiencia en la aplicacin 0.5
E3 Experiencia en orientacin a objetos 1
E4 Capacidad del analista lder 0.5
E5 Motivacin 1
E6 Estabilidad de los requerimientos 2
E7 Personal parte-time -1
E8 Dificultad del lenguaje de programacin -1
Este clculo se realiza con fin de tener una aproximacin del esfuerzo, pensando solo en el
desarrollo segn las funcionalidades de los cosos de uso. Est basado en los factores
ambientales y se calcula de la siguiente manera:
Primero se debe contar la cantidad de factores ambientales del E1 al E6 que tienen una
puntuacin menor a 3, tambin contar la cantidad de estos mismos del E7 y E8 que son
mayores que 3.
FACTOR FILTRO
De E1 a E6 factor < 3
De E7 a E8 Factor > 3
E = UCP * CF
Dnde:
E: Esfuerzo estimado en horas persona
UPC: Puntos de caso de uso ajustados
35
CF: horas persona.
Al realizar la multiplicacin de UCP por las horas personas se consigue un esfuerzo
estimado, que representa una parte del total del esfuerzo de todo el proyecto, generalmente un
40%. Este 40% se refiere al esfuerzo total para el desarrollo de las funcionalidades especficas
en los casos de uso.
ACTIVIDAD PORCENTAJE
Anlisis 10%
Diseo 20%
Programacin 40%
Pruebas 15%
Sobre carga 15%
36
requerimientos a travs de las etapas del anlisis, modelos de diseo, pruebas y
mantenimiento.
Posee un comprensivo soporte UML 2.1 para los trece diagramas de UML.
Modelado extensivo para requisitos, diseo de interfaz de usuario.
Extensivo soporte para la administracin de proyectos.
Soporte para ingeniera directa y reversa para diferentes lenguajes.
Facilidad para llevar acabo el modelado de base de datos.
Es una herramienta de alta velocidad, escalabilidad, usabilidad y seguridad.
Enterprise Architect es una poderosa herramienta para especificar, documentar y construir sus
proyectos de software, permite el diseo y construccin de diferentes sistemas usando UML.
Manejo de complejidad con herramientas para seguir dependencias, cambios en los modelos y
una interfaz de usuario intuitiva. Desarrollar vistas personales y extractos del modelo para uso
personal o el uso en equipo
37
Dada la importancia que tienen en el mundo real las interrelaciones entre los datos, es
imprescindible que la base de datos sea capaz de almacenar estas interrelaciones, al igual que
hace con otros elementos (como las entidades y atributos), siendo esta una diferencia esencial
respecto a los ficheros donde no se almacenan las interrelaciones.
Integridad: Reglas que se deben satisfacer para controlar la cada de los datos mas all del
control particular de la aplicacin.
Los DDL (Lenguaje de Descripcin de Datos) que permiten crear y definir nuevas
Bases de Datos, campos e ndices.
Los DML (Lenguaje de Manipulacin de Datos) que permiten generar consultas para
ordenar, filtrar y extraer datos de la Base de Datos SQL SERVER 2014 SERVIDOR
DE BASE DE DATOS
Delphi, en particular, utiliza una arquitectura estructurada en dos niveles. En el nivel inferior
se encuentra el Motor de Datos de Borland, BorlandDatabaseEngine (BDE siglas en ingles),
que es un conjunto de funciones agrupadas en bibliotecas dinmicas (DLLs). Esta biblioteca
no es orientada a objetos, no permite eventos, y los errores se notifican del modo tradicional:
un valor de retorno de la funcin que falla. Pero el segundo nivel de la arquitectura se encarga
de corregir estos fallos: el programador de Delphi no utiliza directamente las funciones del
BDE, sino por mediacin de objetos definidos en la VCL, que es la biblioteca de componentes
de Delphi.
39
Un uso habitual de Delphi, es el desarrollo de aplicaciones visuales y de bases de datos
cliente-servidor y multicapas. Debido a que es una herramienta de propsito mltiple, se usa
tambin para proyectos de casi cualquier tipo.
Delphi permite de manera sencilla ejecutar trozos de cdigo en respuesta a acciones o eventos
(sucesos) que ocurren durante el tiempo que un programa se ejecuta.
Los eventos pueden generarse debido a la recepcin de seales desde elementos de hardware
como el ratn o el teclado, o pueden producirse al realizar alguna operacin sobre un elemento
de la propia aplicacin.
40
2.1 INTRODUCCIN
1) rea Produccin
a. Realizacin
b. Emisin
2) rea Comercial
3) rea Financiero Contable
a) Recurso Humano
4) rea Prensa
41
- Rejillas De Auspicio Exclusivo. Es un separador audiovisual breve, con el cual se
identifica un espacio exclusivo dentro la estructura de un programa de carcter
informativo.
- Avisos en General. Son avisos que se elaboran y difunden en toda la red local.
rea de prensa, esta rea se ocupa de los reportajes, de la realizacin de entrevista y todo
aquello concerniente al trabajo de comunicacin y edicin de estos.
Tambin se tiene el rea de difusin o emisin esta se ocupa de emitir todos los Spot,
propagandas, publicidades y otros a travs del Canal 2 ORURO Red UNITEL.
42
2.3 MODELADO DEL NEGOCIO
El modelado del negocio es una tcnica para comprender los procesos de negocio de la
organizacin. Durante el proceso de planteamiento usted examina la estructura de la
organizacin e identifica los principales roles o papeles as las interrelaciones existentes entre
ellas.
El modelado del negocio est soportado por dos tipos de modelos de UML: el modelado de
casos de usos y modelos de objetos.
Encargado Comercial
Gestionar Contrato
Empresa
Gerente
Jefe contabilidad
El diagrama que representa los diferentes subsistemas en las que se ha dividido la institucin,
a nivel de abstraccin se representa mediante los modelos de objetos de los casos de uso del
negocio:
2.3.1.1 Modelo de Objetos del caso de uso del Negocio: Gestionar Contratacin
Genera VoBo
Contratacion
Usuario
Jefe Contabilidad
Figura. 2.2. Modelo de Objetos del caso de uso del negocio: Gestionar Contratacin
44
2.3.1.2 Modelo de Objetos del caso de uso del Negocio: Gestionar Contratos
El encargado del rea comercial para realizar un contrato (Figura 2.3), primero verifica la
programacin y tarifario que la empresa maneja segn tipo de publicidad, luego se procede al
registro del cliente, seguidamente se realiza el registro de la Orden de Publicidad, previa
seleccin de tipo de contrato (Banners, Espacios Publicitarios y Avisos), en caso que el
contrato sea Banners, se proceder a la seleccin de das y horarios de emisin.
Espacios Publicitarios, se procede a seleccin de uno de los tres tipos de este (Paquetes, Costo
por segundo y Pases). Paquetes: Registro de datos del Paquetes.
Posteriormente se Registra el contrato y el plan de pagos si este fuera el caso, finalmente se
tiene el reporte de publicidades al aire.
Orden Publicidad
Programacion
Registra
Registra Paquete
Registra
Verifica Pagos
Empresa
Solicita contrato, detalle pases y registro de pagos
Jefe contabilidad
Solicita VoBo
Crea
Cliente
Escoge Verifica Encargado Comercial VoBo
Personal
Particular Registra
Llena Datos Gerente Administrativo
VoBo genera Plan Pagos
Tarifario
Tipo Publicidad
Contratos
45
2.4 REQUISITOS MODELO FURPS+
Para una mejor comprensin y estudio del proyecto, se optar pordividir por mdulos de
acuerdo a las reas de trabajo que se tiene en la empresa.
-rea RRHH:
En la figura2.4 se muestra todos los requisitos encontrados en l, y este representa las
relaciones entre funciones.
La tabla2.1 muestra un listado de funciones del sistema en el rea de RRHH, que representa lo
que el sistema tendr que realizaren esta rea.
REFERENCIA REQUERIMIENTOS
F1 Registrar datos Personales y de contratacin del empleado
El jefe de contabilidad debe registrar al usuario, donde este es un
F2
empleado de la empresa que tiene algunos atributos
Tabla2.1 Funciones del sistema en el rea de RRHH
46
-rea Comercial
En la figura 2.5 se muestra todos los requisitos encontrados en el rea de comercial, y este
representa las relaciones entre funciones.
custom Features
Gestionar
Paquetes
Imprimir Detalle
tags
Pases
Role = F7
Registro y tags
Verificacion de Role = F8
Programacion
tags
Role = F3
Reporte Economico
tags
Role = F12
Generar y
Imprimir Contrato Gestionar
Registrar Pagos
Contrato
tags tags
tags
Role = F11 Role = F9
Role = F1
Generar y
Registrar Plan
Pagos
tags
Role = F10
47
La tabla 2.2 muestra un listado de funciones del sistema en el rea de Comercializacin, que
representa lo que el sistema tendr que realizar en esta rea.
REFERENCIA REQUERIMIENTOS
F1 Realizar Registro y edicin del contrato para el cliente, se identifican 3
tipos de contratos.
F2 Registrar Datos cliente
F3 Verificar o registrar la Programacin que maneja toda la red
F4 Verificar o registrar el Tarifario
F5 Seleccionar tipo de Publicidad
F6 Registrar la orden de publicidad segn el tipo de publicidad requerida
F7 Registrar y / o editar datos Paquetes
F8 Imprimir Detalle Pases Cliente
F9 Generar y/o Registrar Pagos del cliente
F10 Generar y / o Registrar Plan de Pagos
F11 Imprimir contratos
F12 Realizar informes diarios, semanales mensuales y anuales de acuerdo a
los requerimientos del usuario
F13 Generar Reportes de Publicidad al Aire
Tabla 2.2 Funciones del sistema en el rea Comercial (Contratos)
La tabla 2.3 muestra un listado de atributos del sistema que son las caractersticas o
dimensiones que el sistema debe presentar, los atributos del sistema que se detalla a
continuacin presentan restricciones de frontera que son condiciones obligatorias de frontera.
DETALLES Y
REFERENCIA ATRIBUTO
RESTRICCIN DE FRONTERA
A1 Facilidad de (Detalle) tendr un agradable interfaz grfica de
uso usuario (GUI), el uso del sistema en lo posible no ser
complicado de manipular,
A2 Confiabilidad (Detalle) Ser confiable por que los trabajos de
clculo y la realizacin de registros se har de forma
48
DETALLES Y
REFERENCIA ATRIBUTO
RESTRICCIN DE FRONTERA
ms precisa, y recuperacin a fallos
A3 Rendimiento (Restriccin de frontera )Los clculos y procesos se
harn en el menor tiempo posible
A4 Soporte (Detalle) El sistema Debe funcionar en los siguientes
sistemas
operativos Windows /ME/XP
49
3.1 INTRODUCCIN
El anlisis del sistema persigue como objetivo realizar una investigacin del sistema a partir
de los requerimientos obtenidos y proponer una solucin parcial, MODELO DE CASOS DE
USO DEL SISTEMA
El modelo de Caso de Uso es la base para los dems modelos de desarrollo de software; a
continuacin, se identifica los actores y Casos de Uso del sistema en la empresa de
comunicacin UNITEL-ORURO.
Para una mejor comprensin del diagrama de casos de uso del sistema se realiza el siguiente
diagrama de paquetes (Figura 3.1):
50
uc Identificar usuario
Jefe Comercial
Administrador del
Sistema
3.2.1 PAQUETE:- Identificar Usuario
51
Identificar Usuario
Jefe Contabilidad
Usuario
Encargado Emision
Gerente Administrativ o
52
3.2.3 PAQUETE: - rea Comercial
53
3.3. IDENTIFICARACTORES
Un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso
de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una
persona en particular, sino ms bien la labor que realiza frente al sistema, en la Figura 3.5 Se
identifican los actores.
uc Actores
Gerente Administrativ o
Jefe Contabilidad
(from Recursos humanos)
Jefe Comercial
(from Recursos humanos)
Usuario
Encargado Emision
(from Comercial)
Administrador del
Sistema
54
El modelo de Casos de Uso es la descripcin formal textual de cada uno de los actores y casos
de Uso del Sistema, por lo tanto, los actores identificados en el Sistema se documentan a
continuacin mediante el siguiente formato:
Actor GerenteAdministrador
Caso de uso
Tipo Primario
Descripcin Es el actor principal y representa a la persona que se encarga de la
revisin de informes y reportes en general, es tambin el encargado
de registrar los contratos.
Actor Usuario
Caso de uso
Tipo Primario
Descripcin Es el actor principal y representa a cualquier persona que quiera
utilizar el sistema de informacin para la empresa de comunicacin
UNITEL-ORURO.
55
Actor Administrador del sistema
Caso de uso Registrar Usuario
Tipo Secundario
Descripcin El administrador del sistema, es el encargado de crear a los
usuarios asignndoles una determinada clave y cuenta de usuario,
por medio de este controlar que tipo de usuarios son, y determinar
que mdulos puedan manipular. ste tiene acceso a todos los
mdulos que el sistema presenta
56
Actor Encargado de Emisin
Caso de uso Publicidad Aire
Tipo Secundario
Descripcin Es el actor principal y representa a la persona encargada de recibir
la generacin de reportes de las publicidades que tiene que
difundirse.
La descripcin de los Casos de Uso representa todas las posibles interacciones de los actores
con el sistema, el formato de documentacin de los Casos de Uso es el Siguiente:
57
3.4.1 PAQUETE: IDENTIFICAR USUARIO
IDENTIFICAR USUARIO
ADMINISTRADOR
Contrasea: xxxxxxxxxxxxxx
CANCELAR INGRESAR
58
Caso de Uso Identificar usuario
Registro de usuario.
59
3.4.2 PAQUETE: AREA RECURSO HUMANO
REGISTRO DE USUARIO
CUENTAS DE USUARIO
REGISTRAR DATOS ACTUALIZAR DATOS
CI: 9999999
xxxxxxxxxxxxxx
Nombres:
Apellidos: xxxxxxxxxxxxxx
Cargo: xxxxxxxxxxxxxx
60
Caso de Uso Identificar Y Registrar usuario
Usuario (Encargado de emisin, Jefe Comercial, Jefe
Actores Contabilidad, Gerente Administrador,UNITEL Oruro y
Administrador del sistema)
Tipo Primario
Registrar un usuario, que ya este registrado como empleado, para
Propsito el uso del sistema de informacin administrativo para UNITEL-
Oruro
Este caso de uso se inicia por el usuario, tiene la finalidad de
Resumen
registra a un determinado usuario para el uso del sistema
Se necesita haber ejecutado anteriormente el Caso de Uso
Precondicin
Registrar Empleado Con el Sub flujo registrar
El Administrador del Sistema Procede hacer el registro del
usuario
61
(S-2) Aceptar Registro de usuario
El Sistema almacena un nuevo Registro de usuario.
62
CASO DE USO: Registrar Empleado-Contratacin
EMPLEADO
REGISTRAR DATOS EMPLEADO / CONTRATACION ACTUALIZAR DATOS EMPLEADO / CONTRATACION
DATOS PERSONALES
Direccion: xxxxxxxxxxxxxxxxxxxx
DATOS CONTRATACION
Horarios de Trabajo:
Desde Hrs. 99:99:99 Hasta Hrs. 99:99:99 Desde Hrs. 99:99:99 Hasta Hrs. 99:99:99
Primer Turno Segundo Turno
Forma de Pago: xxxxxxxx Dpto. Trabajo: xxxxxxxxxxxx Tipo Contrato: xxxxxxxxxxxx Sueldo Basico: 99999
63
Caso de Uso Registrar Empleado Contratacin
64
(S-3) Modificar Registro personal.
El Sistema muestra un listado del personal,
donde puede seleccionar un empleado y
recuperar sus respectivos datos, para luego
modificarlos.
(S-6) Cancelar
65
3.5.3 PAQUETE: REA COMERCIAL
DATOS CLIENTE
CLIENTE
REGISTRAR DATOS ACTUALIZAR DATOS
Datos Empresa
XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX
Razn Social: Descripcion:
XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX
Direccin: Telfono:
9999999999 99999999999
Nro. Nit Nfax:
XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX
Categora: Tipo Cliente:
Datos Contacto
XXXXXXXXXXXXXXXXX
Nombre:
XXXXXXXXXXXXXXXXX
Email:
99999999
Telefono
66
Caso de Uso Gestionar Cliente
Buscar (S-4)y Cerrar
Precondicin
Flujo Principal 1. El sistema muestra al usuario 2 pestaas: Registrar Datos y
Modificar datos.
67
Caso de Uso Gestionar Cliente
corrija los datos.
(E-2) El sistema muestra un mensaje el cliente ya fue registrado
FPROGRAMACION
PROGRAMACION
REGISTRAR PROGRAMACION NACIONAL ACTUALIZAR PROGRAMACION
Detalle Programacin
XXXXXXXXXXXXXX
Nombre Programa:
99:99
Horario de Difusion:
XXXXXXXXXX
Tipo:
XXXXXXXXXXXXXXX
Clasificacin
XXXXXXXXXXXXX
Categora:
Nro. de Cortes 99
(S-5)Actualizar datos
El sistema permite la Actualizacin de los datos registrados
TARIFARIO
TARIFARIO
INGRESAR DATOS
ESPACIOS PUBLICITARIOS
XXXXXXXXXXXXXXXXXXXXXXX AVISOS
INGRESE COSTOS
Monto: 9999,9999 xx
70
Caso de Uso Verificar / Registrar Tarifario
uso para registrar tarifario. Tiene la funcionalidad de
Nuevo (S-1), Aceptar (S-2) Cancelar (S-3)y Cerrar.
Precondicin Se requiere anteriormente haber ejecutado el caso de
uso Registrar Programacin.
Flujo Principal 1. El usuario escoge el tipo de publicidad en la
cual requiere ingresar el tarifario.
2. Si el usuario escoge, el tipo de Publicidad:
Banner o Avisos
2.1 El usuario ingresa el programa a buscar,
el sistema devuelve una lista de todos los
programas Nacionales registrados, para
luego realizar su tarifario.
2.2 El sistema muestra al usuario opciones:
Nuevo (S-1), Aceptar (S-2) Cancelar (S-
3) y Cerrar.
2.3 El actor selecciona una de las opciones
que presenta el registro del tarifario.
3. Si el usuario escoge, el tipo de Publicidad:
Espacios Publicitarios
3.1 El usuario ingresa el programa a buscar,
el sistema devuelve una lista de todos los
programas Nacionales registrados, para
luego realizar su tarifario.
3.2 El sistema presenta dos opciones, Por
Pase (S-4) y Costo Por Seg. (S-5)
3.3 El sistema contina con la opcin que ha
sido seleccionada.
3.4 El sistema muestra al usuario opciones:
Nuevo (S-1), Aceptar (S-2) Cancelar (S-
71
Caso de Uso Verificar / Registrar Tarifario
3) y Cerrar.
4. El sistema contina con la opcin que ha sido
seleccionada.
5. El usuario sale de la ventana con la opcin
cerrar.
Subflujos (S-1) Introducir registro de un nuevo programa
El Sistema permite el llenado de los datos
respectivos.
(S-1) Aceptar registro de tarifario
El Sistema guarda el registro de un nuevo programa
(E-1)
(S-3) Cerrar
Despus de hacer el uso del caso de uso el usuario
puede Cerrar la ventana.
Excepciones (E-1) El sistema muestra un mensaje de error:
Ingrese Datos Costo, y se solicita al usuario que
corrija los datos.
72
CASO DE USO: Registrar Orden de Publicidad
FOrdenPublicidad
ORDEN DE PUBLICIDAD
ELEGIR CLIENTE ESCOGER TIPO PUBLICIDAD
XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX
Duracin: Unidad:
Texto Texto Texto
XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX
Nro. Pases:
XXXXXXXXXXXXXXXXX
CATEGORIA:
PROGRAMA:
73
Caso de Uso Registrar Orden de Publicidad
Publicidad, para realizar su respectivo contrato.
Resumen El Usuario (Jefe Comercial) inicia este caso de
uso. Tiene la funcionalidad de Buscar, Nuevo,
Aceptar, Cancelar, Calcular, Imprimir y Cerrar.
Precondicin Se debe de haber ejecutado el caso de uso
Registrar Tipo Publicidad, Gestionar Cliente,
verificar y/o registrar Programacin, Verificar
y/o registrar tarifario.
Flujo Principal 1. El sistema muestra al usuario la opcin
de ingresar tipo de cambio del dlar,
una vez introducido el tipo de cambio,
el sistema muestra el listado de todos
los clientes y el listado de los diferentes
tipos de publicidades.
74
Caso de Uso Registrar Orden de Publicidad
muestra al usuario varias opciones:
Nuevo (S-1), Aceptar (S-2), Cancelar
(S3), Calcular (S4), Adicionar (S-5),
Imprimir (S-6) y Cerrar (S-6).
4. Si el usuario selecciona el tipo de
publicidad Espacios Publicitarios, el
sistema muestra tres pestaas: Paquetes,
Costo/Seg. y Pase. Si el usuario escoge
la Pestaa Paquetes, el sistema muestra
un listado de todos los paquetes
registrados. Tiene las opciones: Nuevo
(S-1), Aceptar (S-2), Cancelar (S3)
Imprimir (S-6),y Cerrar (S-7).
(S-2) Aceptar
El sistema guarda un nuevo registro de la orden
de publicidad (E-1)
75
Caso de Uso Registrar Orden de Publicidad
(S-3)Cancelar
El Sistema permite hacer la cancelacin de
dicho registro.
(S-4) Adicionar
El sistema permite adicionar la programacin
con su tarifario respectivo, para la difusin del
Spot del cliente.(E-2)
(S-5)Calcular
El sistema permite realizar clculo de los costos
de la orden de publicidad, de acuerdo a los
datos introducidos.
76
CASO DE USO: Gestionar Contrato
FContrato
DETALLE CLIENTE
xxxxxxxxxxxxxxxxxxx
Xxxxxxxxxxxxx xxxxxxxxxxx CI: 9999999 Exp: xx
Nombre Representado:
Datos contrato
Costos
Forma de Pago
77
Caso de Uso Gestionar Contrato
Actores Encargado Comercial
Tipo
Propsito Permite registrar un nuevo contrato para el cliente.
Resumen El usuario (Encargado Comercial) inicia este caso de uso, tiene la
funcionalidad de Buscar (S-5) Nuevo, Guardar, Imprimir, Modificar
y Cerrar.
Precondicin Se debe de haber ejecutado con anterioridad el caso de uso
Registrar Ordene de Publicidad
Flujo principal 1. (S-5) El usuario introduce cliente a buscar, el sistema muestra
una lista de todos los clientes registrados.
78
(S-4) Imprime Registro/ Contrato
El Sistema imprime el contrato del cliente una vez llenado todos los
campos necesarios.
PLAN PAGOS
ELEGIR CLIENTE ESCOGER TIPO PUBLICIDAD
9999999999
Monto:
Nro. Cheque: 999999999
999999999
Nro. Factura:
ACEPTAR
REGISTRAR PAGOS
99999,9999
Total Pago:
CERRAR
Tabla 3.15 Descripcin del caso de uso: Generar / Registrar Plan De Pagos
80
CASO DE USO:Generar Detalle Pases
NRO. XXXX
DETALLE DE PASES
XXXXXXXXXXXXXXXXX LOGO
COBERTURA:
XXXXXXXXXXXXXXXXX
CLIENTE:
99999,99
COSTO:
XXXXXXXXXXXXXXXXX
SPOT:
99/99/99 99/99/99
EMISON:
99
DURACION:
9999
TOTAL PASES:
FReportesEconomicos
ACEPTAR CERRAR
82
CASO DE USO: Generar Publicidad Aire
83
de pases, dentro del programa elegido, para su respectiva emisin.
4. Tiene la opcin (S-1) Cerrar y (S-2) Salir emisin.
Subflujos (S-1) Si el usuario presiona cerrar termina el caso de uso (E-1)
(S-2)Si el usuario presiona Salir, Se cierra la ventana
Excepciones (E-1) El sistema muestra un mensaje de advertencia Esta seguro
de cerrar, se Perdern todas sus Observaciones
Tabla 3.18 Descripcin del caso de uso: Generar Publicidad Aire
CASO DE USO: Generar Reporte de Contratos
84
Caso de Uso Generar Reporte de Contratos
Actores Encargado Comercial
Tipo
Propsito Imprimir Reporte de Contratos Registrado para el cliente
Resumen Este caso de uso permite imprimir el detalle del Contrato
registrado para cada cliente.
Precondicin
Flujo Principal 1. El usuario escoge la opcin Imprimir de la ventana de
Contratos
2. El sistema muestra al usuario un reporte del detalle de
su contrato del cliente, el usuario tiene la opcin de
imprimir dicho contrato.
Subflujos
Excepciones
Tabla 3.19 Descripcin del caso de uso:Generar Reporte De Contratos
85
Caso de Uso Gestionar Paquete
Actores Jefe Comercial
Tipo
Propsito Permite realizar la Gestin de un nuevo Paquete para el cliente,
donde el usuario registra el Nuevo Paquete, para realizar su
respectivo contrato.
Resumen El Usuario (Jefe Comercial) inicia este caso de uso. Tiene la
funcionalidad de Nuevo, Aceptar, Cancelar, Buscar, Adicionar,
Modificar Imprimir y Cerrar.
Precondicin Se debe de haber ejecutado el caso de uso Registrar Tipo
Publicidad, Gestionar Cliente, verificar y/o registrar
Programacin, Verificar y/o registrar tarifario.
Flujo Principal 1. El sistema presenta las opciones de: Nuevo (S-1), Aceptar
(S-2), Cancelar (S-3), Buscar (S-4), Adicionar (S-5),
Modificar (S-6), Imprimir (S-7) y Cerrar (S-8).
2. El usuario escoge una de las opciones que presenta el
caso de uso Gestionar Paquetes.
3. El sistema contina con la opcin que eligi el usuario.
Subflujos (S-1) Nuevo
El Sistema permite el llenado de los datos respectivos para el
registro del nuevo paquete para el cliente.
(S-2) Aceptar
El sistema guarda un nuevo registro del Paquete (E-1).
(S-3)Cancelar
El Sistema permite hacer la cancelacin de dicho registro.
(S-4) Buscar
El usuario tiene la opcin de buscar tanto la programacin como
los paquetes registrados
(S-5) Adicionar
El sistema permite adicionar la programacin con su tarifario
respectivo, para el registro del Detalle del Paquete, para luego
realizar su orden de publicidad (E-2).
86
El usuario busca el paquete, el sistema muestra una lista con
todos los paquetes registrados para luego modificarlo, el usuario
tambin puede modificar la programacin que se escogi para un
paquete ya registrado.
PUBLICIDAD
DATOS DEL TIPO DE PUBLICIDAD
Nombre: XXXXXXXXXXXXXXXXX
Detalle: XXXXXXXXXXXXXXXXX
87
Caso de Uso Registrar Tipo Publicidad
Actores Encargado Comercial
Tipo
Propsito Registra un tipo de publicidad que la empresa maneja.
Resumen El usuario (Encargado Comercial) inicia este caso de uso, para
realizar el correspondiente registro del tipo de publicidad, para
luego de esta manera realizar su orden de publicidad.
Precondicin
Flujo Principal 1. El sistema muestra al usuario la opcin de Nuevo(S-1)
Aceptar(S-2) y Cerrar(S-3)
88
4.1 INTRODUCCIN
El diseo del sistema persigue como objetivo proponer la solucin del sistema a partir de los
requerimientos y el anlisis, el cual se implementar en el lenguaje de programacin Object
Pascal con el Borland Developer Studio 2006
La Figura. 4.1 Muestra el Diagrama de Secuencia para el Caso de Uso Identificar Usuario
89
La Figura. 4.2 Muestra el Diagrama de Secuencia para el Caso de Uso Registrar Empleado
Contratacin
90
La Figura. 4.3 Muestra el Diagrama de Secuencia para el Caso de Uso Registrar Usuario
92
La Figura 4. 5 Muestra el Diagrama de Secuencia para el Caso de Uso: Gestionar Cliente
93
La Figura 4.6 muestra el diagrama de Secuencias para el Caso de uso:Verificar / Registrar
Programacin
96
La Figura 4.9 muestra el Diagrama de Secuencias para el caso de uso: de Registrar Tarifario
Banners
97
La Figura 4.10 muestra el Diagrama de Secuencias para el Caso de Uso: Gestionar Paquete
99
La Figura 4.12 muestra el Diagrama de Secuencias para el Caso de Uso: Detalle orden de
Publicidad, con el tipo de publicidad: Espacios Publicitarios Paquetes
100
La Figura 4.13 Muestra el Diagrama de Secuencias de para el caso de uso: Detalle orden de
Publicidad con el Tipo de Publicidad: Espacios Publicitarios Por Pase
101
La Figura 4.14 muestra el Diagrama de Secuencias para el Caso de Uso: Detalle orden de
Publicidad, con el tipo de publicidad: Banners
102
La Figura 4.15 muestra el Diagrama de Secuencias para el Caso de Uso: Detalle orden de
Publicidad, con el tipo de publicidad: Avisos
104
La Figura 4.17 muestra el Diagrama de Secuencias para el Caso de Uso: Generar/ Registrar
Plan Pagos
105
La Figura 4.18 muestra el diagrama de Secuencias ara el Caso de Uso: Publicidad al Aire
106
La Figura 4.19 muestra el Diagrama de Secuencias para el Caso de Uso: Generar Detalle de
Pases
107
La Figura 4.20 muestra el Diagrama de Secuencias para el Caso de Uso: Generar Reportes
Econmicos
108
La Figura 4.21 muestra el Diagrama de Secuencias Para el Caso de Uso: Generar Reportes
Contrato
109
class Schema1
TPaquetes TContrato
TPlanPagos TPagos
- NPaquetes: int - NContrato: Int
- NombrePaquete: Varchar - NPlanPagos: Int - NUsuario: Int - NPagos: Int
- CostoPaquete: Float - NContrato: Int - NCliente: Int - NContrato: Int
- UCostoPaquete: Varchar - NCliene: Int - NOrdenPublicidad: Int - NCliente: Int
- DuracionPaquete: Integer - FechaActualPlanPagos: Date - NombreRepresentado: Varchar - NumFactura: Varchar
- UDuracionPaquete: Int - Total: Float - CiRepresentado: Varchar - Numcheque: Varchar
- DetallePaquete: Varchar - ACuenta: Float - ExpRepresentado: Varchar - FechaLimite: Varchar
- TotalPases: Int - Saldo: Float - NombreRepresentante: Varchar - FechaActualPago: Date
- FechaRegistroPaquete: Date - NFactura: Varchar - CIRepresentante: Varchar - TotalPago: Float
- NCheque: Varchar 0..* 1..* - ExpRepresentante: Varchar 1..* 0..* - NumCuotas: Int
+ BuscarPaquete() : void - Cancelado: Varchar - N_PoderRepresentado: Varchar
+ NuevoPaquete() : void - N_PoderRepresentante: Varchar + Buscar() : void
+ RegistrarPaquete() : void TEmpelado + Buscar() : void - FechaActualContrato: Date + GenerarPagos() : void
+ ModificarPaquete() : void + MostrarContratos() : void - CostoEmision: Float + RegistrarPago() : void
- CodEmpleado: int
+ GenerarPlanPagos() : void - TotalContrato: Float + MostrarContratos() : void
- Apellidos: Varchar
1..* 1..* + RegistrarPlanPagos() : void - Moneda: Varchar
- Departamento: Varchar
- NumFactura: Varchar
- Direccion: Varchar
Contiene - TipoPago: TPublicidad
- Edad: int
- Cancelado: Varchar
- Email: Varchar
4.3 MODELO DE DATOS
110
- NUsuario: int
1 - NCliente: int
- NPublicidad: int
- Cobertura: Varchar
1 TDetalleOrdenPubli - NombreSpot: Varchar
- Duracion: int
TDetalleContratacion - NDetalleOrdenPubli: Int TPublicidad
TContratacion - UDuracion: Varchar
- NDetallecontratacion: int - NOrdenPublicidad: Int - FechaActualOrden: Date
- NFicha: int - NPublicidad: int
- NFicha: int - NProgramacion: Int - FechaInicio: Date
- Cargo: Varchar Contiene 1..* 1..* - NombrePublicidad: Varchar
- NTarifario: Int - FechaFin: Date
diagrama de clases persistentes se muestra en la Figura 4.22
+ MostrarPrograrmacion() : void
+ NuevaProgramacion() : void + RegistrarTarifario() : void
+ InsertarDetalleOrdenPublicidadPaquete() : void
+ ModficarProgramacion() : void
+ ModificarDetalleOrdenPublicidadPaquete() : void
+ BuscarProgramacion() : void
+ BuscarDetalleOrdenPublicidadPaquete() : void
+ EliminarProgramacion() : void
+ GenerarPublicidadAirePaquete() : void
+ ImprimirDetallePasesPaquete() : void
Las clases persistentes, son aquellas que deben ser almacenadas en una Base de Datos. El
4.4 BASE DE DATOS
Se define como una coleccin de tablas donde cada una tiene un nmero especfico de
columnas y un nmero de filas. Cada elemento de la tabla guarda un valor primitivo, como
enteros, cadenas, etc. De esta manera cada objeto se representa como una fila en una tabla y
donde cada columna corresponde a un atributo distinto en el objeto.
Como se defini lneas arriba en la Figura 4.23 se muestra el Modelo Relacional para el
Sistema.
111
TPlanPagos * TContrato *
NPlanPagos
NContrato
NContrato TPagos *
NUsuario
TPaquetes * NPagos
NCliente
NCliente
NPaquetes NContrato
FechaActualPlanPagos
NOrdenPublicidad
NombrePaquete NCliente
Total
TEmpleado * NombreRepresentado
CostoPaquete NumFactura
Acuenta
CodEmpleado CiRepresentado
UCostoPaquete NumCheque
Saldo
NEmpleado ExpRepresentado
DuracionPaquete FechaLimite
NFactura
Nacionalidad NombreRepresentante
UDuracionPaquete FechaActualPAgo
NCheque
Expi CIRepresentante
DetallePAquete TotalPago
Cancelado
lsm ExpRepresentante
TotalPases NumeroCuotas
NPasaporte N_PoderRepresentado
FechaRegistroPaquete
Nombres N_PoderRepresentante
Apellidos FechaActualContrato
FecNac CostoEmision
Edad TotalContrato
Pais Moneda
Departamento NumFactura
Provincia TipoPago
EstCivil Cancelado
TUsuario * TCliente *
NHijos NUsuario NumCheque Ncliente
NombreConyuge CodEmpleado TipoContrato NombreCliente
FonoFijos TipoUsuario Estado DescripcionCliente
TDetallePaquetes * FonoCel FechaUsuario NumeroMeses TipoCliente
NDetallePaquetes Email Contrasena NitCliente
NPaquetes Email1 CuentaUsuario TelefonoEmpresa
NProgramacion Direccion NFax
FechaRegistroDetalle
NombreContacto
EmailContacto
112
Categoria
Direccion
FonoContacto
TOrdenPubli *
TDetalleContratacion * TDetalleOrdenPubli * NOrdenPublicidad
NDetalleContratacion
TContratacion *
NDetalleOrdenPubli NUsuario
NFicha TPublicidad *
NFicha
113
Nombre del Tipo Longitud Descripcin
Campo
Numrico 4 Cdigo generado de la contratacin del
NFicha
empleado
CodEmpleado Numrico 4 Cdigo del Empleado
Cargo Texto 50 Cargo que desempeara el empleado
FechAdm Fecha 8 Fecha de que ingreso a trabajar en la
empresa
Regional Texto 15 En cul de las sucursales a nivel
nacional ingreso a trabajar el empleado
GradoInst Texto 50 Grado de estudio realizado por el
empleado
HorPrim1 Texto 10 Registro de Horarios primer turno
entrada
HorPrim2 Texto 10 Registro de Horarios primer turno
salida
HorSeg1 Texto 10 Registro de Horarios segundo turno
Entrada
HorSeg2 Texto 10 Registro de Horarios segundo turno
salida
FormaPago Texto 20 Forma en la que se remunera
econmicamente al empleado
DptoTrabajo Texto 30 Se refiere al Area de trabajo del
empleado
TipoContrato Texto 30 Qu tipo de contrato tiene el empleado
SueldoBasico Moneda 10 Sueldo que se le asigna al empleado
Rd Texto 10
114
Nombre del Campo Tipo Longitud Descripcin
NDetalleContratacion Numrico 4 Cdigo generado del Detalle de
contratacin del empleado
115
MDULO COMERCIAL
116
CiRepresentado Texto 7 Nmero de carnet del representado
ExpRepresentado Texto 7 Es la Extensin de la Cedula de
Identidad
NombreRepresentante Texto 20 Numero de Libreta de servicio militar
CIRepresentante Texto 7 Numero CI del representante
ExpRepresentante Texto 7 Es la Extensin de la Cedula de
Identidad
N_PoderRepresentado Texto 30 Nmero del poder del Representando
N_PoderRepresentante Texto 30 Nmero del Poder del Representante
EmailRepresentante Texto 30 Direccin de correo electrnico
FechaActualContrato Fecha 8 Fecha Actual en la que realiza el
contrato
CostoEmision Moneda 10 Costo de la emisin del spot
publicitario por mes
TotalContrato Moneda 10 Costo Total del contrato
Moneda Texto 3 Re refiere al tipo de moneda con la
que se efectuara el pago por el
contrato
NumFactura Texto 9 Numero de factura
TipoPago Texto 7 Se refiere al tipo de pago que se
realizara por el contrato
Cancelado Texto 2 Se refiere al pago total del contrato
NumCheque Texto 9 Numero de Cheque
NumeroMeses Numrico 4 Total de pases del spot publicitario
TipoContrato Texto 20 Se refiere al tipo de contrato
Estado Texto 20 Se refiere al estado en que se
encuentra un contrato en un
determinado tiempo
117
Nombre del Campo Tipo Longitud Descripcin
Numrico 4 Cdigo generado para el registro de la
NProgramacion
programacin
Hrs Texto 10 Se refiere al horario de difusin de la
programacin
NombrePrograma Texto 50 Nombre del programa
TipoPrograma Texto 20 Tipo de programa
Categoria Texto 2 Categora a la que pertenece el
programa
ClasePrograma Texto 20 Se refiere a que clase pertenece el
programa
CantidadCortes Numrico 4 Se refiere a la cantidad de cortes
publicitarios que tendr un programa
118
Nombre del Campo Tipo Longitud Descripcin
NOrdenPublicidad Numrico 4 Cdigo generado para el registro de la
Orden de Publicidad
119
NumPases Numrico 4 Se refiere al nmero de pases que
tendr el contrato
CostoContrato Moneda 10 Se refiere al costo que tendr el detalle
orden de publicidad
UCostoContrato Texto 5 Se refiere a la moneda del costo del
Detalle de orden de publicidad
120
del plan de pagos
Total Moneda 10 Se refiere a la cantidad total en el plan
de pagos
Acuenta Moneda 10 Se refiere a la cantidad que se pagara
en el plan de pagos
Saldo Moneda 10 Se refiere a la cantidad sobrante
despus de realizar el pago en el plan
de pagos
Cancelado Texto 2 Se refiere al pago total del contrato en
el plan de pagos
NFactura Texto 10 Numero de Factura
NCheque Texto 10 Numero de cheque
Cancelado Texto 10 Se refiere al total de pagos del contrato
121
Paquete
UCostoPaquete Texto 5 Es la Moneda del costo del paquete
Duracion Numrico 4 Se refiere a la duracin del spot del
paquete
UDuracion Texto 10 Se refiere A la unidad de la duracin
DetallePaquete Texto 30 Es un detalle del nuevo paquete
TotalPases Numrico 4 Se refiere, al total de pases del spot que
tendr el paquete.
FechaRegistroPaquete Fecha 8 Se refiere a la fecha actual en que se
realiz el Registro del Paquete
122
5.1 INTRODUCCIN
Cuando construimos software es necesario integrar los componentes propios con los
componentes de terceros. Un diagrama de componentes muestra la parte fsica de un sistema,
archivos, libreras, tablas, etc.
Los componentes forman el software que debe ser desplegado en algn hardware para su
ejecucin. Cada elemento fsico en el que se ejecute los componentes se conoce como un
nodo. Un diagrama de despliegue muestra la distribucin de los componentes a travs de los
nodos y sus relaciones entre ellos.
123
5.3 DIAGRAMA DE DESPLIEGUE
124
Caso de uso: Identificar usuario
125
Caso de uso: Registrar Empleado Contratacin
126
Caso de Uso: Gestionar Paquete
127
Caso de Uso: Verificar / Registrar Programacin
128
Caso de Uso: Orden de Publicidad
129
Figura 5.11 Interfaz Orden de Publicidad
Caso de Uso: Gestionar Contrato
130
Caso de uso: Generar / Registrar Plan Pagos
131
Caso de Uso: Generar / Reporte Publicidad Aire
132
Caso de Uso: Generar Reportes de Contratos
133
5.5 CRITRIO DE VALIDACIN de la hiptesis
5.6
Esta prueba ser desarrollada para verificar el cumplimiento dela hiptesis, el cual indica que
mediante la implementacin del sistema de informacin desarrollado se mejorara el flujo de
informacin en los procesos que se realizan en esta rea reduciendo el tiempo de trabajo en las
transacciones realizadas.
Para la presente evaluacin, se seleccion el proceso del registro del detalle de pases y
posterior registro de los contratos para los respectivos clientes. Solo se considera el registro
del detalle de pases y contratos, asumiendo que el cliente ya est registrado, el paquete creado
y el tarifario registrado el tipo de publicidad registrado.
El proceso a ser medido (Registro Detalle de Pases) considera el tiempo empleado desde el
registro del detalle, registro del contrato, hasta la impresin del pauteo y contrato del cliente,
antes y despus de la implementacin de la aplicacin.
La hiptesis planteada:
134
El Sistema de Informacin NO Coadyuva en la reduciendo del tiempo en las transacciones.
Para el control y manejo de la informacin que se genera en el proceso administrativo del rea
comercial de la empresa de comunicacin UNITEL ORURO, reduciendo el tiempo en las
transacciones.
Paso 1:
Hipotesis
Paso 2
135
18 14
19 8
20 9
21 15
22 12
23 13
24 10
25 12
26 8
27 11
28 9
29 10
30 15
31 10
(Anexo B)
Paso 3
0: A B
1 : A> B
Regin de Rechazo.
1 1
> +2 . ;
R = { + }
136
1 15
2 11
3 15
4 7
5 9
6 14
7 8
8 10
9 9
10 11
11 13
12 15
13 11
14 9
15 10
16 11
17 10
18 14
19 8
20 9
21 15
22 12
23 13
24 10
25 12
26 8
27 11
28 9
29 10
30 15
31 10
Media muestral:
=1 1
= = 11,13
137
TIEMPO )
(
Nro.
(Min)
1 15 14.95
2 11 0.02
3 15 14.95
4 7 17.08
5 9 4.55
6 14 8.22
7 8 9.82
8 10 1.28
9 9 4.55
10 11 0.02
11 13 3.48
12 15 14.95
13 11 0.02
14 9 4.55
15 10 1.28
16 11 0.02
17 10 1.28
18 14 8.22
19 8 9.82
20 9 4.55
21 15 14.95
22 12 0.75
23 13 3.48
24 10 1.28
25 12 0.75
26 8 9.82
27 11 0.02
28 9 4.55
29 10 1.28
30 15 14.95
31 10 1.28
S2 = 6.05
Desviacin Estndar
138
S=6.05 = 2.46
139
Tabla 5.3 Tiempos Registrados con el sistema Despus
Media muestral:
=1 1
= = 5,47
TIEMPO )
(
Nro.
(Min)
1 6 0.2809
2 5 0.2209
3 7 2.3409
4 5 0.2209
5 4 2.1609
6 5 0.2209
7 3 6.1009
8 5 0.2209
9 6 0.2809
10 7 2.3409
11 4 2.1609
12 4 2.1609
13 4 2.1609
14 7 2.3409
15 7 2.3409
16 6 0.2809
17 5 0.2209
18 5 0.2209
19 6 0.2809
20 7 2.3409
21 7 2.3409
22 5 0.2209
23 4 2.1609
24 3 6.1009
25 7 2.3409
26 5 0.2209
27 6 0.2809
28 6 0.2809
29 7 2.3409
30 6 0.2809
140
31 7 2.3409
Varianza:
=1( )
2
S2 =
1
S2 = 1.57
Desviacin Estndar
141
S=1.57 = 1.25
En la siguiente Tabla 5.5 se muestra el resumen de los tiempos tomados antes y despus de la
implantacin del sistema de informacin.
TIEMPO 1 TIEMPO 2
Nro.
Antes (Min) Despus (Min)
1 15 6
2 11 5
3 15 7
4 7 5
5 9 4
6 14 5
7 8 3
8 10 5
9 9 6
10 11 7
11 13 4
12 15 4
13 11 4
14 9 7
15 10 7
16 11 6
17 10 5
18 14 5
19 8 6
20 9 7
21 15 7
22 12 5
23 13 4
24 10 3
25 12 7
26 8 5
142
TIEMPO 1 TIEMPO 2
Nro.
Antes (Min) Despus (Min)
27 11 6
28 9 6
29 10 7
30 15 6
Intervalo de confianza:
1 - 0,05 = 0.95
T=1.671
Figura 5.18. Distribucin normal
2 2
2 ( 1) +( 1)
sp =
+ 2
(311)6.05+(311) 1.57
sp2= = 3.81
31+312
= 3.81 = 1.95
1 1
+ = 0.25
31 31
= {
> 1.67160;0,05 1.95 0.25}
143
= {11.13 5.47 > 0.81}
Se puede decir entonces, que se tiene la suficiente evidencia muestral para: Rechazar la
hiptesis nula 0 y aceptar la hiptesis alternativa H1,que, con la aplicacin del Sistema de
informacin, coadyuva en el control y manejo de la informacin que se genera en el proceso
administrativo del rea Comercial de la Empresa de Comunicacin UNITEL-ORURO,
reduciendo el tiempo de las transacciones, de forma que esta sea confiable y oportuna.
144
Las ponderaciones para el Mtodo de Evaluaciones Sumarias son:
Escala Puntuacin
Definitivamente Si 4
Probablemente Si 3
Indeciso 2
Probablemente No 1
Definitivamente No 0
Para valorar la aceptacin de los usuarios hacia el sistema, se proporcion un cuestionario con
10 preguntas (Anexo B), al siguiente personal de la empresa de Comunicacin UNITEL
Oruro.
Gerente administrativo
Jefe Comercial
Jefe Contabilidad
Encargado Emisin
Evaluando los resultados de las 10 encuestas realizadas, las puntuaciones obtenidas para cada
alternativa se detallan en la Tabla 5.2 antes de la implantacin del Sistema de Informacin.
145
4 3 5 1 1
5 2 3 1 2 2
6 5 3 2
7 2 2 4 2
8 3 3 3 1
9 5 3 2
10 4 2 2 2
Total 31 30 9 19 11
Evaluando los resultados de las 10 encuestas realizadas, las puntuaciones obtenidas para cada
alternativa se detallan en la Tabla 5.3, despus de la implantacin del Sistema de Informacin
146
8 5 3 2
9 7 2 1
10 6 3
Total 63 27 9 0 0
Comparando los resultados de las mediciones, se demuestra que el uso del nuevo sistema de
informacin es altamente aceptada por los usuarios del sistema.
147
6.1 INTRODUCCIN
el sistema se comporta de la forma esperada. Tambin se ejecutan pruebas para validar los
requisitos no funcionales que fueron establecidos.
Los procedimientos de prueba especifican cmo se llevan a cabo los casos de prueba en forma
de instrucciones.
a) Pruebas de caja negra: son ejecutadas en casos de uso, stas se dedican a verificar el
comportamiento observable externamente del sistema, este tipo de pruebas no estn
basadas en el conocimiento del diseo interno del programa en cambio se enfocan en los
requerimientos establecidos y en la funcionalidad del sistema.
Datos de Entrada:
148
Evaluacin de clases equivalencia
Clase de
N de caso Usuario Contrasea Resultado
equivalencia
1 1 Adminis Adminis77 Acceso valido
2 2 Admin 123 Acceso denegado
Condiciones de ejecucin:
149
Tabla 6.4 Procedimiento 2: Ingresar Usuario [Admin] Contrasea [123]
Resultado esperado: Restringe el acceso a los datos [Admin] y [123]
Datos de Entrada:
Condiciones de ejecucin:
150
1. Ejecutar la aplicacin
2. Se ingresa al sistema mediante el usuario y contrasea
proporcionados por el administrador del sistema.
3. En la pantalla Gestionar cliente, en el campo Nitingrese el
Procedimiento
Nit del cliente [153112021] y en el campo Nombre ingrese
el nombre del Cliente [ADMIN S.R.L.] y pulse el botn
ACEPTAR.
4. Su registro fue ingresado de forma correcta
El Nit[153112021] y el nombre [ADMIN S.R.L.] se almacena
Resultado
correctamente.
Tabla 6.7 Procedimiento 1: Registrar cliente, Nit [153112021] Nombre [ADIM S.R.L.]
b) Pruebas de sistema: en el proyecto se llevaron a cabo las siguientes pruebas (Anexos C):
151
Pruebas de instalacin, verifican que el sistema puede ser instalado en la plataforma
del cliente y que el sistema funcionar correctamente cuando sea instalado, en la
institucin se llev a cabo la instalacin del sistema y se verific su correcta
instalacin por los usuarios de la empresa de comunicacin Unitel ORURO.
152
7.1 INTRODUCCIN
Los Puntos de caso de uso es un mtodo de estimacin de esfuerzo para proyectos de software,
a partir de sus casos de uso. Fue desarrollado por Gustav Karner en 1993, basndose en el
mtodo de puntos de funcin, y supervisado por Ivar Jacobson. El mtodo de puntos de caso
de uso utiliza los actores y coso de usos relevantes para calcular el esfuerzo que significa
desarrollar un sistema de informacin. A los casos de uso se les asigna una complejidad
basada en transacciones, entendidas como una interaccin de usuario y el sistema mientras que
a los actores se les asigna una complejidad basada en su interaccin con las interfaces de
acceso a otros sistemas.
153
7.2.2 FACTOR DE PESO DE LOS CASOS DE USO SIN AJUSTAR (UUCW)
154
instalacin
T7 0.5 3 1.5 El sistema debe ser fcil de
usar
T8 2 0 0 El sistema no requiere ser
portable
T9 1 3 3 El sistema est estructurado
para que los cambios
realizados afecten lo menos
posible las funcionalidades del
mismo
T10 1 3 3 La concurrencia en el sistema
es tratada con importancia
T11 1 4 4 Los usuarios cuentan con una
contrasea para el ingreso al
sistema
T12 1 0 0 Los usuarios deben estar
registrados para hacer uso del
sistema
T13 1 0 0 Se debe incluir un manual de
usuario para garantizar la
correcta usabilidad del sistema
TOTAL 21
155
7.2.4 FACTORES AMBIENTALES
156
UCP = UUCP * TCF * EF
UCP = 109*0.81*0,62
UPC = 54.74
E = UCP * CF
E= 54.74 * 20
E = 1094.79 Horas hombre
TDesarrollo = 2486 / 1
157
TDesarrollo = 2486
Por tanto, el costo total del proyecto es de 6215 $us, para un tiempo de desarrollo de
10 meses aproximadamente.
158
8.1 CONCLUSIONES
Durante el desarrollo del presente proyecto, se pudo evidenciar muchas situaciones y casos
especiales para su tratamiento en las distintas reas de Trabajo, pero a manera de conocer el
contexto del sistema se plasm el modelo del negocio, gracias a la contribucin de la empresa,
a travs de la revisin de documentacin, informes y reportes.
Tambin se elabor una base de datos capaz de almacenar todos los procesos que se manejan
en el rea comercial, para obtener informacin real y confiable y disminuir las prdidas de
informacin relevante y necesaria.
159
Los casos de prueba ayudaron a comprobar las entradas y sus respectivos resultados que
fueron los esperados, en cuanto a los procedimientos, stos coadyuvaron a reforzar los
resultados que se esperaba que diera el Sistema de Informacin, la misma que fue capaz de
reemplazar el proceso manual que exista antes.
Se puede mencionar tambin que la implementacin del sistema presenta un ahorro de tiempo
significativo a la hora de realizar las distintas tareas en el rea Comercial, adems no implica
costos significativos, debido a que se hace uso de los medios y recursos con los que cuenta
actualmente la empresa.
8.2 RECOMENDACIONES
Se recomienda sistematizar las otras reas de trabajo para tener un mejor control en las
transacciones que se realizan en cada una de ellas.
160
usuarios no deben compartir las contraseas de Usuario, con el fin de asegurar la veracidad,
integridad y confiabilidad de la informacin.
161
9.1 REFERENCIA BIBLIOGRFICA
Escalas Likert [internet]. 20 octubre 2014; [Consultado 2016 Octubre 1]. Disponible
en:
http://es.wikipedia.org/wiki/EscalasLikert
Modelado del negocio [internet]; [consultado 30 enero 2017 ]. Disponible en:
http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro10/351_modelado_del_negocio.
html
162
Ingeniera de software [internet]. 5a edicin; PDF [consultado 2014 Octubre 12].
Disponible en:
http://dis.unal.edu.co/~fgonza/courses/2003/ingSoft1/CAP5.pdf
Puntos de casos de uso [internet]. 22 junio 2010; [consultado 2016diciembre 28].
Disponible en:
http://es.wikipedia.org/wiki/Puntos_de_caso_de_uso
El Proceso Unificado gil: fases y disciplinas [internet]. 7 junio 2012; [consultado
2016octubre 20]. Disponible en:
http://nosolopau.com/2012/06/07/mas-sobre-el-proceso-unificado-agil-fases-y-disciplinas/
163
ANEXO A
NOTA PERIDICO RECONOCIMIENTOS
164
METODO FURPS+
Los requisitos Funcionales los cuales especifican funciones que el sistema debe ser capaz de
realizar, sin tomar restricciones fsicas a consideracin.
Los Requisitos no Funcionales los cuales describen atributos del sistema o atributos del
ambiente del sistema.
Pero existen muchas clasificaciones de requisitos. Una de estas es el modelo FURPS+, usando
el acrnimo FURPS (por las siglas en ingls) para describir las principales categoras de
requisitos:
Funcionalidad
Facilidad de Uso
Confiabilidad
Rendimiento
Soporte
El signo + dentro del nombre del modelo indica que se deben de incluir requisitos tales
como:
Restricciones de diseo
Requisitos de Implementacin
Requisitos de Interfase
Requisitos Fsicos
Funcionalidad
Los requisitos de funcionalidad deben incluir:
Conjunto de Caractersticas
Capacidades
Seguridad
165
Facilidad de Uso
Deben incluir subcategoras tales como:
Factores humanos
Estticos
Consistencia en la Interfaz de Usuario
Ayuda en lnea
Asistentes
Documentacin del usuario
Material de capacitacin
Confiabilidad
Se considera requisitos de confiabilidad:
Frecuencia y severidad de fallas
Recuperacin a fallos
Tiempo entre fallos
Rendimiento
Un requisito de rendimiento impone condiciones a los requisitos funcionales. Por ejemplo, a
una accin dada, se pueden especificar los siguientes parmetros de rendimiento:
Velocidad
Eficiencia
Disponibilidad
Tiempo de Respuesta
Tiempo de Recuperacin
Utilizacin de Recursos
Soporte
Los requisitos de soporte pueden incluir:
Requisitos de instalacin
Requisitos de Configuracin
166
Requisitos de Adaptabilidad
Requisitos de Compatibilidad
Requisitos de Diseo
Tambin llamados restricciones de diseo, especifican o restringen el diseo de un sistema.
Requisitos de Implementacin
Un requisito de implementacin especifica o restringe la codificacin o construccin de un
sistema. Algunos ejemplos son:
Estndares requeridos
Lenguajes de implementacin
Polticas para la integridad de la Base de Datos
Limites de los recursos
Ambientes de operacin
Requisitos de Interfase
Un requisito de interfaseespecfica:
Un elemento externo con el cual el sistema debe de interactuar
Restricciones en formato, tiempos u otros factores.
Requisitos Fsicos
Un requisito fsico especifica una caracterstica fsica que el sistema debe de poseer, por
ejemplo:
material
forma
peso
tamao
Este tipo de requisitos puede ser usado para representar requisitos de hardware, as como la
configuracin de red requerida.
167
ANEXO B
TABLA DE T STUDENT
168
CUESTIONARIO
CUESTIONARIO
Las afirmaciones que se encuentran a continuacin son opiniones antes de implantar el sistema
informtico, marque por favor que tan de acuerdo est usted con estas preguntas.
1. Con los recursos manuales que cuenta realiza sin problema el desempeo de sus funciones?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
3. Existe una optimizacin de los recursos existentes para el mejor desempeo de sus
actividades?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
4. La creacin de todos los respaldos a sus actividades es facilitada por los recursos existentes?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
8. Actualmente usted considera que se maneja de forma apropiada las salidas del spot de los
clientes?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
169
9. Usted considera que los reportes que tiene al realizar todo el proceso de la informacin que se
maneja, le ayuda a tomar decisiones confiables?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
1. Usted est conforme y cmodo con las tareas que realiza en forma manual?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
CUESTIONARIO
Las afirmaciones que se encuentran a continuacin son opiniones despus de implantar el sistema
informtico, marque por favor que tan de acuerdo est usted con estas preguntas
1. Considera Ud. (s), que el sistema de informacin le facilita las tareas que realiza dentro
de la empresa?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
170
6. Tiene facilidad para realizar los Contratos y Pauteos de los clientes?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
8. El Sistema de informacin ayuda a controlar mejor las salidas del spot diariamente?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
10. Usted considera que el aprendizaje del manejo del sistema de Informacin fue
sencillo?
Definitivamente Si Probablemente Si Indeciso Probablemente No Definitivamente No
171
ANEXO C
PRUEBAS DE CONFIGURACIN
- rea contabilidad
- rea Comercial
- Gerencia
- Emisin
172
Gerencia, Sistema Operativo Windows
10, configuracin del sistema
Tcnica Se realiz la apertura de los programas
que estn instalados en la maquina donde
se realiz la configuracin del sistema de
informacin:
- Sistema de informacin
Comercial
173
ANEXO B
FICHA DE TRABAJO DE CAMPO
174