Desarrollo de una Intranet para la empresa BINARY · Web viewCarlos Zorrilla Varga INTEGRANTES Grados Espinoza, Herbert Junior. Zuloeta Huerta, Luis Baiker Dedicatoria A toda mi familia

Desarrollo de una Intranet para la empresa BINARY

UNIVERSIDAD TECNOLOGICA DEL PERÚ

FACULTAD DE INGENIERIA INDUSTRIAL

Y DE SISTEMAS

PROYECTO DE TESIS I

ANALISIS Y DISEÑO DE UNA INTRANET BAJO LA METODOLOGIA RUP PARA LA EMPRESA BINARY

(Desarrollo de software y gestión de tecnología)

DOCENTE

MBA Ing. Carlos Zorrilla Varga

INTEGRANTES

Grados Espinoza, Herbert Junior.Zuloeta Huerta, Luis Baiker

UNIVERSIDAD TECNOLOGICA DEL PERÚPágina 1


Dedicatoria

A toda mi familia y en especial para mis padres por todo el apoyo en estos cinco años de vida universitaria.

A cada uno de los profesores que con su ayuda nos permitieron culminar esta etapa tan importante en nuestras vidas.

A mis compañeros, por el magnífico ambiente de estudio que he disfrutado y felicitarlos por todos sus logros obtenidos.

ÍNDICE



DEDICATORIA.........................................................................................................2RESUMEN EJECUTIVO..........................................................................................4

CAPITULO 1: FORMULACIÓN DEL PROBLEMA.................................................51.1 Planteamiento del problema ..............................................................................51.2 Antecedentes de solución..................................................................................51.3 Propuesta de solución........................................................................................61.4 Alcance de la propuesta.....................................................................................61.5 Justificación de la investigación.........................................................................61.6 Objetivos.............................................................................................................71.6.1 Objetivos General............................................................................................71.6.2 Objetivos Específicos......................................................................................7

CAPÍTULO 2. MARCO TEÓRICO...........................................................................82.1 Antecedentes de la investigación.......................................................................82.2 Bases teóricas....................................................................................................92.3 Diagramas de Datos...........................................................................................132.4 Base de Datos....................................................................................................162.5 Modelo de Datos Entidad-Relación (E/R)..........................................................182.6 Diccionario de datos (DD)..................................................................................202.7 UML (LENGUAJE UNIFICADO DE MODELADO).............................................232.8 SISTEMAS DE VARIABLES..............................................................................34

CAPITULO 3: MARCO METODOLOGICO.............................................................353.1 Metodología para el Análisis y Diseño de la solución.......................................373.1.1 Técnicas de procesamiento y análisis de datos.............................................373.1.2 Metodología a Utilizar.....................................................................................403.2 Metodología para el Estudio de Factibilidad de la solución...............................423.2.1 Factibilidad Técnica.........................................................................................423.2.3 Factibilidad Económica....................................................................................443.2.3 Factibilidad Operativa......................................................................................45

CAPITULO 4: ASPECTOS ADMINISTRATIVOS....................................................514.1 Índice preliminar de la tesis................................................................................514.2 Presupuesto y cronograma de Actividades........................................................53

Referencias Bibliográficas....................................................................................54

Resumen ejecutivo



El presente proyecto está dirigido a la empresa BINARY como una futura propuesta para mejorar sus procesos operativos tales como la gestión de proyectos y Control de actualizaciones de los mismos.

BINARY, es una empresa de desarrollo Web y desarrollo de software a medida, actualmente cuenta con un gran cúmulo de información de todo tipo, referente al trabajo que esta realiza, organizada de diversas maneras y distribuida en diferentes computadoras , el grupo no cuenta con un manejo centralizado de todo el proceso, esto provoca que en ocasiones existan problemas en el trabajo o pérdida de alguna documentación, por lo que se hace necesario un sistema que centralice toda la información y que a la vez permita una mayor organización sobre ella.

El proyecto consiste en hacer el análisis y diseño de una intranet. Esta estará basada en un entorno Web, niveles de accesos, y será llevada con el Patrón de diseño MVC (Modelo - Vista - Controlador).

El Análisis y diseño de la intranet se llevará a cabo bajo la metodología RUP, porque es una metodología completa y extensa que intenta abarcar todos los aspectos del desarrollo de un software.

En la sección de Modelado del Negocio se encuentran los artefactos utilizados de la metodología RUP para definir un modelo del negocio, modelos de objetos del negocio y el modelo del dominio.

En la sección Requisitos se encuentra los artefactos definidos según la metodología RUP, es decir, el documento plan de desarrollo de software, el documento visión, el documento glosario, matrices de atributos de todos los requerimientos, los casos de uso y sus especificaciones.

En la sección Análisis/Diseño se muestran tanto el modelo de análisis/diseño (diagrama de clases) como el modelo de datos (modelo entidad – relación).

A continuación se detalla las Tecnologías y Herramientas a usar en el Diseño del Sistema:

Herramientas de Diseño

Herramienta Visual: UML (Rational Rose). Herramienta para el modelo de datos: DBDESIGNER.

Herramientas de Desarrollo

WAMP SERVER (64 BITS) 2.2E- Apache versión 2.2.11- MySQL 5.1.33- PhpMyAdmin 3.4.10.1

Plataforma de Desarrollo: PHP versión 5.2.9-2 IDE de Desarrollo: NetBeans 7.2.



Framework de Desarrollo: CodeIgniter V 2.1.2

El proyecto debe proporcionar una respuesta para el desarrollo de todos los módulos implicados en la INTRANET. Estos módulos se pueden diferenciar en:

Gestión de Usuarios Gestión de Clientes Gestión de Proyectos Gestión de Tareas / Actividades Informe de errores Gestión de reportes Control de Calidad de proyectos

CAPITULO I

1.1 Definición del problema

En la actualidad la empresa BINARY no cuenta con un manejo centralizado de la información, lo que provoca que muchas veces se pierda parte de la misma. Esta carece de una aplicación que organice, gestione y administre toda la documentación encaminada a los usuarios y a la empresa en general, por lo que presentan información dispersa en cada uno de sus áreas, el mecanismo para hacerle llegar las informaciones a los diferentes trabajadores no es el más óptimo.

Para programar los servicios que brindan a cada uno de los clientes usan una aplicación que contiene un módulo de proyectos, en el módulo de proyectos se definen los datos básicos del proyecto tales como la fecha y nombre de un proyecto, también cuenta con una sección de EDTS, en esta los programadores registran sus actividades diarias, cabe mencionar que el EDT no es generado por alguna persona responsable en la repartición de tareas sino por los mismos programadores, causando así una mala definición del proyecto.

Los procesos manuales de BINARY tienden a tener gran cantidad de errores, por la intervención y discrecionalidad humana, además de la lentitud que puede causar.

1.3 Propuesta de solución



Se plantea diseñar una intranet que permita gestionarlos proyectos de la empresa Binary de una manera más eficiente y eficaz, así como también llevar un mejor control y gestión de sus actividades, lograr un adecuado proceso en cuanto a la repartición de tareas hacia los miembros del área de desarrollo y dar soporte a la toma de decisiones.

1.4 Alcances y limitaciones

Este proyecto está orientado a pymes similares la empresa Binary, Esta será desarrollada utilizando software libre, ya que la empresa no cuenta con mucho presupuesto, por lo que se busca implementar una solución que traiga consigo buenos resultados para lograr una mejora de los procesos operativos.

1.5 Justificación

Para casi cualquier empresa de la actualidad, y muy especialmente en un futuro muy cercano, la intranet será un recurso indispensable. Dada la gran cantidad de datos que genera cualquier empresa, se están quedando obsoletos los actuales métodos de inserción y consulta de datos. Una intranet puede resolver estos y otros problemas.

Es por eso que uno de los aspectos más importantes para llevar a cabo este proyecto es que contribuya a la mejora en la Gestión de los recursos de la empresa, que los miembros de la empresa puedan consultar su información de manera inmediata y precisa.

Se aprovechará también la potencia de una intranet para tener acceso rápido a cualquier documento de la empresa, siempre que se tenga el nivel de privilegios adecuado. Esta es otra de las ventajas de una intranet, su seguridad. Solo tendrán acceso a los recursos aquellos empleados que lo necesiten realmente. Siguiendo con la potencia y velocidad de acceso a datos de una intranet, el tiempo empleado en realizar cualquier búsqueda de datos de cualquier departamento de la empresa se reduce considerablemente, por lo que la productividad de la empresa mejorará.

La implantación de este proyecto se justifica mediante:

a) Genera una arquitectura de software en base a niveles de acceso.b) Permitir a los trabajadores elaborar consultas de sus actividades programadas.c) Controla el Estado de los proyectos por parte del jefe de proyectos.d) Da Acceso a Definir Proyectos, requerimientos y EDT.e) Muestra alertas cuando un proyecto ha surgido algún cambio.f) Brinda una mejor forma de trabajo.g) Contribuye en una adecuada gestión para la toma de decisiones.h) Ayuda a obtener de manera rápida y eficiente reportes de estadísticas.i) Optimiza la información unificándola y facilitando su tratamiento.j) Acelera el paso de la gestión de la información a la gestión del conocimiento. k) Otorga información a unos y restringir la información a otros de la misma.l) Facilita el uso para los empleados que estén familiarizados con el entorno en el

que trabaja.



1.6 Objetivos

1.6.1 Objetivogeneral

Desarrollar el análisis y diseño de una intranet para la empresa BINARY con el fin de que pueda llevar una mejor gestión de sus actividades.

1.6.2 Objetivos Específicos

Conocer el proceso actual del área de desarrollo de la empresa Binary. Modelar la situación actual del área de desarrollo. Realizar un estudio de factibilidad. Identificar los principales requerimientos del sistema. Diseñar la arquitectura tecnológica necesaria para la implantación del sistema. Medir el impacto económico de la propuesta de solución versus la situación actual.

CAPITULOII



2.1 Antecedentes de la investigación

2.1.1 Proyecto de tesis: “IMPLEMENTACIÓN DE UNA INTRANET PARA MEJORAR LA COMUNICACIÓN DE DATOS EN LA EMPRESA DATAGRAFICS – LIMA”LIMA – PERÚ, 2010

La implementación de la intranet se planifica, programa y diseña de acuerdo con las necesidades de la empresa u organización (en el nivel de los servicios a implementarse). Es así como la intranet no sólo debe ser diseñada por los ingenieros informáticos de la empresa sino también todo un equipo organizacional como un proyecto que tenga en cuenta las necesidades de todas las partes que interactúan con la empresa. En una intranet se puede disponer de múltiples documentos de cualquier tipo (de texto, imágenes, videos, audio, entre otros.). Asimismo, la intranet puede proporcionar una función de trabajo en grupo muy interesante. Éstas son algunas de las funciones que puede ofrecer una intranet:

- Acceso a la información sobre la empresa (tablero de anuncios) - Acceso a documentos técnicos - Motores de búsqueda para la documentación - Intercambio de datos entre compañeros de trabajo - Nómina del personal - Dirección de proyectos, asistencia en la toma de decisiones, agenda, ingeniería asistida por ordenador

Mensajería electrónica - Foros de discusión, listas de distribución, chat directo. - Video conferencia. - Portal de Internet.

Por consiguiente, una intranet favorece la comunicación dentro de la empresa y limita errores como resultado de un flujo de información reducido. Se debe actualizar la información disponible en la intranet para prevenir conflictos entre versiones.Una intranet es un conjunto de servicios de Internet (por ejemplo, un servidor Web) dentro de una red local, es decir que es accesible sólo desde estaciones de trabajo de una red local o que es un conjunto de redes bien definidas invisibles (o inaccesibles) desde el exterior. Hasta hace poco, las empresas dependían de sistemas y medios informáticos llamados ´´ propietarios´´ para poner sus ordenadores en red, un proceso costoso que consumía mucho tiempo. Al usar las nuevas tecnologías de Internet, las Intranets resuelven este problema, simplificando la comunicación y colaboración interna.El aumento de la productividad es la principal ventaja para el desarrollo de un intranet es el acceso a una información actualizada de una manera útil y sencilla redunda en un ahorro de tiempo. Si a esto, le unimos la existencia de una serie de aplicaciones desarrolladas para facilitar las labores de los/as empleados/as, el aumento de Productividad será significativa.



Es escasa la inversión en la implantación de una Intranet no requiere una inversión demasiado costosa y además se amortiza muy rápidamente. El gasto en equipamiento es muy bajo respecto a la adopción de otras tecnologías, al tratarse de un sistema abierto que suele preservar el ya existente. El desarrollo lleva a un objetivo de corporativismo y conocimientos compartidos, esta ventaja adquiere toda su importancia si cada departamento gestiona y mantiene su propia documentación en la Intranet común. De la misma manera su diseño personalizado, en una Intranet puede ser diseñada en función de las necesidades reales de la organización. Esto resulta clave, ya que habíamos visto que el enfoque estratégico que debe de tener la Intranet es la deestar plenamente orientada a sus usuarios/as (empleados/as) con el fin de facilitarles su día a día. Tanto la información como las aplicaciones desarrolladas deben responder a sus necesidades y expectativas.

2.2 Bases teóricas

2.2.1 ¿Que es una Intranet?

Considérela como un sitio web interno, diseñado para ser utilizado dentro de los límites de la compañía. Lo que distingue una Intranet de un sitio de Internet, es que las intranets son privadas y la información que en ella reside tiene como objetivo asistir a los trabajadores en la generación de valor para la empresa.El 80% de la información que se utiliza diariamente para realizar el trabajo no está en los sistemas transaccionales de las empresas.

Se estima que un empleado promedio consume entre un 25% y 30% de su tiempo buscando información. Esto significa que las empresas pierden mensualmente un 30% del dinero correspondiente al costo de sus empleados, sumado al lucro cesante derivado de este tiempo improductivo en los que los empleados no generan valor para la empresa.

Las organizaciones insumen gran cantidad de información para dar soporte a su operativa diaria; información generada internamente como proveniente de fuentes externas. Viven de esta información, memorandos, reportes, información de productos, análisis de mercados, contratos, artículos de interés, minutas de reunión, información interna, manuales y procedimientos, etc.

Pero su acceso no es siempre fácil. Si no está organizada, relacionada y distribuida de forma apropiada, no genera valor para el negocio, desaprovechando uno de los activos más importantes de la Empresa: El Conocimiento.

Una Intranet pone a disposición esta información a lo largo y ancho de la empresa, las 24 horas del día, los 365 días del año, trabajando en la oficina, estando de viaje o desde la casa haciendo trabajo remoto. Todo bajo un esquema de seguridad y control de acceso que asegura que cada persona puede ver únicamente lo que le corresponde.



Pero la intranet no se limita únicamente a compartir documentos electrónicos, promueve nuevas formas de colaboración y acceso a los sistemas. Ya no es necesario reunir a todos en una sala para discutir un proyecto. Maquetas preliminares, diseños e información pueden ser compartidos en línea, a través de una junta virtual, donde cada participante puede estar en su propio escritorio, viendo un documento y discutiéndolo por teléfono, con telefonía en línea, o a través de un foro de discusión. Equipos de personas alrededor del mundo pueden trabajar juntos sin tener que invertir en gastos de viaje. La capacitación en línea disminuye los costos de traslados, infraestructura y coordinación de horarios. El resultado de esto es un aumento increíble en la eficiencia

2.2.2 Sitio Web

El Sitio Web es un conjunto de una o varias páginas web que están organizadas jerárquicamente y relacionadas entre sí. Un sitio brinda a los usuarios de forma ágil eintegrada el acceso a las aplicaciones e información que posee. La página web principal de un sitio web suele llamarse índex y posee la extensión .htm, .php, .asp, entre otras.Uno de los grandes errores se da cuando un "sitio web" y una "página web" son tomados como sinónimos, pero no son tal.Los sitios web pueden construirse utilizando Editores Web y son accedidos a través de una dirección URL (generalmente un dominio), utilizando un navegador web (Internet Explorer, Mozilla Firefox, Safari, Opera, Google Chrome, etc).El objetivo de la información que se puede encontrar en un Sitio Web es llegar a conocer qué ofrece el sitio, productos, promociones, noticias, etc. La información puede ser de tipo texto, imagen, audio y video siempre y cuando cumpla con su objetivo.Se pueden encontrar diversas aplicaciones en un Sitio Web como son chats, foros, descargas, buscadores, compra electrónica, etc.; para que el usuario interactúe con el sitio y pueda obtener beneficios, tanto para el dueño del sitio como para cada uno de los usuarios.

2.2.3 Aplicación Web

La Aplicación Web es un software que puede ser ejecutado desde Internet o una intranet. La Aplicación Web es ligera y se la puede crear con cualquier lenguaje de programación que soporte los navegadores web (HTML, Java Script, Java, etc.), además permite interactuar con los datos del sistema desde cualquier computador conectado a Internet en el lugar y el momento que desee el usuario, sin la necesidad de instalar un software predeterminado. No necesitan ser descargadas, instaladas y configuradas. El usuario accede a su cuenta online y está listo para trabajar sin importar cuál es suconfiguración o su hardware; múltiples usuarios al mismo tiempo pueden utilizar la aplicación. Consecuentemente en vez de crear clientes para Windows, Mac OS X, GNU/Linux, y otros sistemas operativos, la aplicación web se escribe una vez y se ejecuta igual en todas partes. Sin embargo, hay aplicaciones inconsistentes escritas con HTML, CSS, DOM y otras especificaciones para navegadores web que pueden causar problemas en el



desarrollo y soporte de las aplicaciones web. Adicionalmente, la posibilidad de los usuarios de personalizar muchas de las características de la interfaz (tamaño y color de fuentes, tipos de fuentes, inhabilitar JavaScript) puede interferir con la consistencia de la aplicación web.

2.2.4Metodología RUP

La metodología RUP tiene tres características principales que son: Proceso Dirigido por los Casos de Uso Proceso Iterativo e Incremental Proceso Centrado en la Arquitectura

2.2.4.1 Proceso Dirigido por los Casos de Uso

Los casos de uso son la representación gráfica de los procesos que se realizan dentro de un sistema, integran el trabajo de las diferentes etapas de un proyecto, requisitos, análisis, diseño, implementación y pruebas.

En la Figura 2.8 se muestra el estado de los aspectos de los Casos de Uso a la culminación de cada fase:Figura 2.8 Estado de los aspectos de los Casos de Uso al finalizar cada fase

2.2.4.2 Proceso Iterativo e Incremental



El ciclo de vida es Incremental ya que pasamos de fase en fase secuencialmente y es Iterativo porque una vez que concluimos las fases, repetimos las mismas no sin antes verificar y corregir errores en la iteración anterior, hasta obtener un producto software compatible con las necesidades del cliente.

Para cada iteración se debe tomar en cuenta: Estudiar los riesgos en cada iteración. Análisis de los casos de uso Diseño estético del sistema, de los formularios y páginas que componen el

sistema. Acoplamiento del nuevo código y pruebas que van mejorando con cada

iteración. Evaluación del prototipo en cada entrega al usuario final. Entrega de documentación e instalación del prototipo.

2.2.4.3 Proceso Centrado en la Arquitectura

La metodología RUP establece el mejoramiento sucesivo de una arquitectura, construida y mostrada en un prototipo evolutivo.

2.3 Diagramas de Datos

2.3.1 Diagrama de Contexto



El diagrama de contexto es un caso especial del diagrama de flujo de datos, en dondeuna sola burbuja representa todo el sistema.

El diagrama de contexto muestra a través de flujos de datos las interacciones existentes entre los agentes externos y el sistema, sin describir en ningún momento la estructura del sistema de información.

En este tipo de diagrama, el sistema de información debe representarse como un único proceso de muy alto nivel con entradas y salidas hacia los agentes externos que lo limitan, de forma equivalente a una caja negra.

Teniendo en cuenta que este diagrama debe de ser comprensible, no es posible representar todos los flujos de datos del sistema en él, sino más bien debe representarse en él una visión general del sistema desde la perspectiva de los propietarios de sistemas siguiendo dos lineamientos básicos:

Representar únicamente los flujos de datos que tengan algo que ver con el objetivo principal del sistema.

Utilizar flujos de datos compuestos que representen a aquellos que sean similares.

Dentro de éste diagrama se enfatizan varias características importantes del sistema:

Las personas, organizaciones y sistemas con los que se comunica el sistema. Son conocidos como terminadores.

Los datos que el sistema recibe del mundo exterior y que deben procesarse de alguna forma.

Los datos producidos por el sistema y que se enviarán al exterior.

Los almacenes de datos que el sistema comparte con los terminadores.

La frontera entre el sistema y el resto del mundo.

2.3.1.1 Elementos del Diagrama de Contexto

El diagrama de contexto consiste de terminadores, flujos de datos y flujos de control, almacenes de datos y un solo proceso, que consiste en una sola burbuja. El nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo convenido.

Los terminadores se representan por medio de rectángulos y se comunican con el sistema utilizando flujos de datos o de control, los cuales son representados por flechas, o a travésde almacenes externos. Hay que recalcar que los terminadores no se comunican entre sí, al menos no en el diagrama de contexto, ya que denotarían interacciones externas al sistema.



2.3.2 Diagrama de flujos de datos

El diagrama de flujo de datos es un modelo que describe los flujos de datos o tuberías, los procesos que cambian o transforman los datos en un sistema, las entidades externas que son fuente o destino de los datos (y en consecuencia los límites del sistema) y los almacenamientos o depósitos de datos a los cuales tiene acceso el sistema, permitiendo así describir el movimiento de los datos a través del sistema.

En síntesis, el Diagrama de Flujo de Datos describe:

los lugares de origen y destino de los datos (los límites del sistema), las transformaciones a las que son sometidos los datos (los procesos internos), los lugares en los que se almacenan los datos dentro del sistema, y los canales por donde circulan los datos.

2.3.2.1 Características

Relevante: Ya que posibilitar comunicar diferentes modelos para así facilitar el entendimiento entre el usuario y el analista de sistemas.

Lógico: Ya que no identifica soporte físico. Descendente: Se construye en forma descendente, de lo general a lo particular.

El DFD posee niveles de desagregación o explosión o apertura de burbujas. El Nivel 0 o Diagrama de Contexto es aquel que muestra una sola burbuja y las entidades externas o terminadoras con los que interactúa el sistema.

2.3.2.2 Simbología

Entidad Externa

Son generalmente clases lógicas de cosas o de personas, las cuales representan una fuente o destino de transacciones, como por ejemplo clientes, empleados, proveedores, etc., con las que el sistema se comunica. También pueden ser una fuente o destino específico, como por ejemplo Departamento Contable.

Como el sistema que está bajo análisis acepta datos de otro sistema o bien se los provee, este otro sistema es una Entidad Externa.



Mediante la designación de alguna cosa o de algún sistema como Entidad Externa estamos estableciendo implícitamente que se encuentra fuera de los límites del sistema que estamos considerando por lo cual no nos interesa la transformación o proceso que se realiza dentro de ellos, es decir que están fuera del control del sistema que se está modelando. Son sólo proveedores o requeridores de datos del sistema bajo consideración.

Por todo ello, ni el analista ni el diseñador pueden cambiar ni los contenidos ni la forma de trabajo de un terminador.

Proceso

Indican aquellos lugares dentro del sistema en donde la información (flujos de datos) que ingresan se procesa o transforman. Es decir, son las funciones o procesos que transforman entradas de datos en salidas de información.

Su nombre deberá ponerse mediante una frase imperativa, que consistirá idealmente de un verbo activo seguido por una clausula objeto, cuanto más simple mejor. Al analista le servirá pensar que la descripción de la función es "una orden a un empleado sin conocimiento del tema". Estas frases imperativas no tienen sujeto; tan pronto como se introduce un sujeto se habrá indicado como deberá realizarse físicamente la función ("El operador ingresará los datos del alumno").

Un proceso puede ser físicamente una oficina repleta de empleados, un procedimiento, o una combinación de actividades manuales y automatizadas.

Flujo de datos

Representa un transporte de paquetes de datos desde su origen hasta su destino, es decir que representa una estructura de datos en movimiento de una parte del sistema a otro.

Un flujo muestra las interfaces entre los elementos del DFD.

Puede imaginarse como una tubería por donde se envían paquetes de datos, pero deberá tener una descripción de su contenido la cual deberá elegirse de forma que sea lo más útil posible a los usuarios que revisen el DFD.

La flecha indica la dirección del flujo.

Puede estar contenido físicamente en una nota, una factura, una llamada telefónica, de programa a programa, etc. Es decir, en cualquier medio por el cual los datos pasan de una entidad o proceso a otra.

Almacén o archivo



Representa un archivo lógico en donde se agregan o de donde se extraen datos. Es una estructura de datos, pero estática.

Puede ser físicamente un archivo de tarjetas, una microficha, un archivo, o un archivo en cinta o diskette.

Deberá elegirse el nombre que sea más descriptivo para el usuario, que identifique los paquetes de datos que contiene.

2.4 Base de Datos

Una base de datos (cuya abreviatura es BD) es una entidad en la cual se pueden almacenar datos de manera estructurada, con la menor redundancia posible. Diferentes programas y diferentes usuarios deben poder utilizar estos datos. Por lo tanto, el concepto de base de datos generalmente está relacionado con el de red ya que se debe poder compartir esta información. De allí el término base. "Sistema de información" es el término general utilizado para la estructura global que incluye todos los mecanismos para compartir datos que se han instalado.

Administración de bases de datos

Rápidamente surgió la necesidad de contar con un sistema de administración para controlar tanto los datos como los usuarios. La administración de bases de datos se realiza con un sistema llamado DBMS (Databasemanagementsystem [Sistema de administración de bases de datos]). El DBMS es un conjunto de servicios (aplicaciones de software) para administrar bases de datos, que permite:

un fácil acceso a los datos

el acceso a la información por parte de múltiples usuarios

la manipulación de los datos encontrados en la base de datos (insertar, eliminar, editar)


http://es.kioskea.net/contents/initiation/concept.php3


El DBMS puede dividirse en tres subsistemas:

El sistema de administración de archivos: para almacenar información en un medio físico

El DBMS interno: para ubicar la información en orden

El DBMS externo: representa la interfaz del usuario

Los DBMS principales

Los principales sistemas de administración de bases de datos son:

BorlandParadox Filemaker IBM DB2 Ingres Interbase Microsoft SQL server Microsoft Access Microsoft FoxPro Oracle Sybase

MySQL

PostgreSQL mSQL

SQL Server 11

2.5 Modelo de Datos Entidad-Relación (E/R)


http://www.hughes.com.au/products/msql/

http://www.sybase.com/

http://www.oracle.com/

http://www.microsoft.com/



http://www.borland.fr/interbase/

http://www.ingres.com/

http://www.software.ibm.com/

http://www.filemaker.com/

http://www.borland.com/


Cuando se utiliza una base de datos para gestionar información, se está plasmando una

parte del mundo real en una serie de tablas, registros y campos ubicados en un

ordenador; creándose un modelo parcial de la realidad. Antes de crear físicamente estas

tablas en el ordenador se debe realizar un modelo de datos.

Se suele cometer el error de ir creando nuevas tablas a medida que se van

necesitando, haciendo así el modelo de datos y la construcción física de las tablas

simultáneamente. El resultado de esto acaba siendo un sistema de información

parcheado, con datos dispersos que terminan por no cumplir adecuadamente los

requisitos necesarios.

Entidades y Relaciones

El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En

el modelo E/R se parte de una situación real a partir de la cual se

definen entidades y relaciones entre dichas entidades:

Entidad.- Objeto del mundo real sobre el que queremos almacenar información

(Ej: una persona). Las entidades están compuestas de atributos que son los datos

que definen el objeto (para la entidad persona serían DNI, nombre, apellidos,

dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se

repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para

la entidad persona una clave seria DNI). En toda entidad siempre hay al menos

una clave que en el peor de los casos estará formada por todos los atributos de la

tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos

atendiendo a estas normas:

Que sea única.

Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se

asigna a cada cliente un número de cliente?.

Que sea mínima, ya que será muy utilizada por el gestor de base de

datos.

Relación.- Asociación entre entidades, sin existencia propia en el mundo real que

estamos modelando, pero necesaria para reflejar las interacciones existentes entre

entidades. Las relaciones pueden ser de tres tipos:



Relaciones 1-1.- Las entidades que intervienen en la relación se asocian

una a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la

relación MATRIMONIO).

Relaciones 1-n.- Una ocurrencia de una entidad está asociada con

muchas (n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y

entre ellos la relación TRABAJAR-EN).

Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la

relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la

entidad ALUMNO, la entidad EMPRESA y entre ellos la relación

MATRÍCULA).

Representación gráfica de Entidades y Relaciones

Para asimilar fácilmente un diseño de datos cuando se emplea el modelo E/R se utilizan

los siguientes elementos gráficos:

La utilización de estos elementos dará como resultado lo que se denomina

el esquema entidad-relación de la base de datos. Los ejemplos que se incluyen en el

apartado anterior, gráficamente quedarían como sigue:



2.6 Diccionario de datos (DD)

Un diccionario de datos es un catálogo, un depósito, de los elementos en un sistema.

Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma

en que están estructurados para satisfacer los requerimientos de los usuarios y las

necesidades de la organización. En un diccionario de datos se encuentra la lista de todos

los elementos que forman parte del flujo de datos en todo el sistema. Los elementos más

importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda los

detalles y descripciones de todos estos elementos.

Si los analistas desean conocer cuántos caracteres abarca un determinado dato o qué

otros nombres recibe en distintas partes del sistema, o dónde se utiliza, encontrarán las

respuestas en un diccionario de datos desarrollado en forma apropiada.

El diccionario se desarrolla durante el análisis de flujo de datos y auxilia a los analistas

que participan en la determinación de los requerimientos de sistemas. Sin embargo, como

se verá más adelante, también se emplea su contenido durante el diseño de sistemas.

(En lo que toca al análisis de flujo de datos sólo son necesarios los detalles de flujo de

datos. Pero después son necesarios detalles como la longitud de los datos, el volumen de

transacciones y la secuencia en que se emplean. Es aconsejable capturar todas estas

particularidades al mismo tiempo que se lleva a cabo la investigación detallada. Todos los

detalles son validados al mismo tiempo que se verifica la información sobre el flujo de

datos.)





Como arquitectura de un sistema es la organización o estructura de sus partes más

relevantes. Además de las características principales de RUP, existen otras que también

son parte de la metodología y que no se debe dejar de lado, como son:

1. Tamaño del proyectoRUP está pensado para ser utilizado en proyectos grandes, en cuanto a tamaño y

duración. Ésta característica podemos aceptarla en nuestro proyecto debido a que

RUP es de carácter general y puede acoplarse a cualquier tipo de proyecto.

2. Obtención de requisitosRUP describe los requerimientos del sistema desde el punto de vista del usuario,

valiéndose de los Casos de Uso, eso si, sin inmiscuirse en detalle de

implementación para que tenga capacidad de mejoramiento y análisis.

3. Carga de trabajoRUP es un proceso pesado, toma como punto primordial la generación de

documentación, que servirá para el control del desarrollo de software en todas sus

fases. Con el manejo de esta documentación se trata de prevenir y corregir riesgos

y/o fallos que se pueden generar en el desarrollo del proyecto.

4. Relación con el clienteÉsta metodología es útil con el cliente porque al final de cada fase presenta los

resultados obtenidos para ser evaluados y si son aceptados se sigue con la

siguiente fase. La calidad de los documentos serán evaluados en todo el ciclo de

vida del proyecto.

5. DesarrolloLa metodología RUP se basa en un proceso iterativo, esto permite llegar a obtener

la solución sin entrar demasiado en muchos detalles.

6. Conocimiento sobre la arquitecturaEl RUP intentará reducir la complejidad del software que se va a producir a través

de la planificación intensiva, esto se debe a que se evita que por la falta de alguna

parte del equipo se vaya abajo el proyecto por la insuficiencia de conocimiento.



2.7 UML (LENGUAJE UNIFICADO DE MODELADO) El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas

estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de

lo que estos diagramas y símbolos significan. Esto le brinda al profesional del software el

tener una notación estándar para modelar las aplicaciones.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software,

sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en

los cuales modelar sistemas.

Diagramas de Casos de Uso para modelar los procesos de negocios.

Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

Diagramas de Colaboración para modelar interacciones entre objetos.

Diagramas de Estado para modelar el comportamiento de los objetos en el

sistema.

Diagramas de Actividad para modelar el comportamiento de los

Casos de Uso, objetos u operaciones.

Diagramas de Clases para modelar la estructura estática de las clases en el

sistema.

Diagramas de Objetos para modelar la estructura estática de los objetos en el

sistema.

Diagramas de Componentes para modelar componentes. Diagramas de

Implementación para modelar la distribución del sistema.

UML es una consolidación de muchas de las notaciones y conceptos más usados

orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch,

James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a

objetos más populares.

UML prescribe una notación estándar y semánticas esenciales para el modelado de un

sistema orientado a objetos. Un diseño orientado a objetos puede ser modelado con

cualquiera de las metodologías existentes en la actualidad, pero esto conlleva a que los

revisores deban aprender la semántica y notaciones de la metodología empleada, antes

que intentar entender el diseño en sí. Ahora con UML, los diseñadores diferentes,

modelando sistemas diferentes pueden sobradamente entender cada uno los diseños de

los otros.

Se muestra ahora una descripción detallada de cada uno de sus componentes.



2.7.1. CASO DE USO Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de

actividades de un sistema que produce un resultado concreto y tangible. Los casos de uso

son descriptores de las interacciones típicas entre los usuarios de un sistema y ese

mismo sistema. Representan el interfaz externo del sistema y especifican que requisitos

de funcionamiento debe tener este.

Ejemplo Casos de Uso

Cuando se trabaja con casos de uso, es importante tener presentes algunas sencillas

reglas:

Cada caso de uso está relacionado como mínimo con un actor.

Cada caso de uso es un iniciador (es decir, un actor)

Cada caso de uso lleva a un resultado relevante (un resultado con “valor

intrínseco”)

Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de

relaciones más comunes entre casos de uso son:

<<include>> que especifica una situación en la que un caso de uso tiene lugar

dentro de otro caso de uso

<<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado

punto de extensión) un caso de uso será extendido por otro.



Generalización que especifica que un caso de uso hereda las características del

“súper” caso de uso, y puede volver a especificar algunas o todas ellas de una

forma muy similar a las herencias entre clases.

Casos de Uso Extends

2.7.2. ACTOR Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema

participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente

real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos.

Los actores no representan a personas físicas o a sistemas, sino su papel. Esto significa

que cuando una persona interacciona con el sistema de diferentes maneras (asumiendo

diferentes papeles), estará representado por varios actores. Por ejemplo, una persona

que proporciona servicios de atención al cliente telefónicamente y realiza pedidos para los

clientes Plan de Tesis Proyectos de Ingeniería de Sistemas I

Universidad Tecnológica del Perú Página: 19

Estaría representada por un actor “equipo de soporte” y por otro actor “representante de

ventas”.



2.7.2.1 DESCRIPCIÓN DE CASOS DE USO

Las descripciones de casos de uso son reseñas textuales del caso de uso. Normalmente

tienen el formato de una nota o un documento relacionado de alguna manera con el caso

de uso, y explica los procesos o actividades que tienen lugar en el caso de uso.

2.7.3 DIAGRAMA DE CLASES Los diagramas de clases muestran las diferentes clases que componen un sistema y

cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas

“estáticos” porque muestran las clases, junto con sus métodos y atributos, así como las

relaciones estáticas entre ellas: qué clases “conocen” a qué otras clases o qué clases

“son parte” de otras clases, pero no muestran los métodos mediante los que se invocan

entre ellas.

2.7.3.1 CLASE Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de

esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto

de atributos (cada objetos tiene el suyo propio). Las clases están representadas por

rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones

de la clase en otros dos “compartimentos” dentro del rectángulo.

2.7.3.2 ATRIBUTOS En UML, los atributos se muestran al menos con su nombre, y también pueden mostrar su

tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados

visualmente:

+ Indica atributos públicos

# Indica atributos protegidos

Indica atributos privados



2.7.3.3 OPERACIONES Las operaciones (métodos) también se muestran al menos con su nombre, y pueden

mostrar sus parámetros y valores de retorno. Las operaciones, al igual que los atributos,

se pueden mostrar visualmente:

+ Indica operaciones públicas

# Indica operaciones protegidas

Indica operaciones privadas

2.7.4 ASOCIACIONES DE CLASES Las clases se pueden relacionar con otras de diferentes maneras:

2.7.4.1. GENERALIZACIÓN La herencia es uno de los conceptos fundamentales de la programación orientada a

objetos, en la que una clase “recoge” todos los atributos y operaciones de la clase de la

que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más

atributos y operaciones propias.

En UML, una asociación de generalización entre dos clases, coloca a estas en una

jerarquía que representa el concepto de herencia de una clase derivada de la clase base.

En UML, las generalizaciones se representan por medio de una línea que conecta las dos

clases, con una flecha en el lado de la clase base.

2.7.4.2. ASOCIACIONES Una asociación representa una relación entre clases, y aporta la semántica común y la

estructura de muchos tipos de “conexiones” entre objetos.

Las asociaciones son los mecanismos que permiten a los objetos comunicarse entre sí.

Describe la conexión entre diferentes clases (la conexión entre los objetos reales se

denomina conexión de objetos o enlace).

Las asociaciones pueden tener un papel que especifica el propósito de la asociación y

pueden ser unidireccionales o en dos direcciones (indicando si los dos objetos

participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno

de ellos el que recibe información del otro). Cada extremo de la asociación también tiene

un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están

relacionados con un objeto del extremo contrario.

En UML, las asociaciones se representan por medio de líneas que conectan las clases

participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada



uno de los participantes. La multiplicidad se muestra como un rango [mín. - máx.] de

valores no negativos, con un asterisco (*) representando el infinito en el lado máximo.

5.3.4.3 AGREGACIÓN Son tipos especiales de asociaciones en las que las dos clases participantes no tienen un

estado igual, pero constituyen una relación “completa”. Una agregación describe cómo se

compone la clase que asume el rol completo de otras clases que se encargan de las

partes. En las agregaciones, la clase que actúa como completa, tiene una multiplicidad de

uno.

En UML, las agregaciones están representadas por una asociación que muestra un rombo

en uno de los lados de la clase completa.

2.7.4.4 COMPOSICIÓN Las composiciones son asociaciones que representan agregaciones muy fuertes. Esto

significa que las composiciones también forman relaciones completas, pero dichas

relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente

existen como parte del conjunto, y si este es destruido las partes también lo son.

En UML, las composiciones están representadas por un rombo sólido al lado del conjunto.



2.7.5 DIAGRAMAS DE SECUENCIA Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en

que se invocan) en un momento dado. Los diagramas de secuencia ponen especial

énfasis en el orden y el momento en que se envían los mensajes a los objetos.

En los diagramas de secuencia, los objetos están representados por líneas intermitentes

verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es

vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un

objeto a otro en forma de flechas con los nombres de la operación y los parámetros.

Los mensajes pueden ser o bien sincrónico, el tipo normal de llamada del mensaje donde

se pasa el control al objeto llamado hasta que el método finalice, o asíncronos donde se

devuelve el control directamente al objeto que realiza la llamada. Los mensajes

sincrónicos tienen una caja vertical en un lateral del objeto que invoca, muestra el flujo del

control del programa.

2.7.6 DIAGRAMAS DE COLABORACIÓN



Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos

que participan en una situación determinada. Esta es más o menos la misma información

que la mostrada por los diagramas de secuencia, pero destacando la forma en que las

operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan

el interés en las relaciones entre los objetos y su topología.

En los diagramas de colaboración los mensajes enviados de un objeto a otro se

representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la

secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar una

situación o flujo de programa específicos y son unos de los mejores tipos de diagramas

para demostrar o explicar rápidamente un proceso dentro de la lógica del programa.

2.7.7 DIAGRAMA DE ESTADO Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y

los estímulos que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como máquinas de estado o autómatas finitos

que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a

través de un estímulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo

NetServer puede tener durante su vida uno de los siguientes estados:

Listo

Escuchando

Trabajando

Detenido

Y los eventos que pueden producir que el objeto cambie de estado son:



Se crea el objeto

El objeto recibe un mensaje de escucha

Un cliente solicita una conexión a través de la red

Un cliente finaliza una solicitud

La solicitud se ejecuta y ser termina

El objeto recibe un mensaje de detención

etc.

Los estados son los ladrillos de los diagramas de estado. Un estado pertenece a

exactamente una clase y representa un resumen de los valores y atributos que puede

tener la clase. Un estado UML describe el estado interno de un objeto de una clase

particular.

Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar

representados por estados, sino únicamente aquellos cambios que pueden afectar

significativamente a la forma de funcionamiento del objeto.

Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que no

hay ningún evento que pueda devolver a un objeto a su estado de inicio, y de la misma

forma no hay ningún evento que pueda sacar a un objeto de su estado de fin.



Ejemplo de diagrama de estado

2.7.8. DIAGRAMA DE ACTIVIDAD Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los

diagramas de actividad son una forma especial de los diagramas de estado, que

únicamente (o mayormente) contienen actividades.

Los diagramas de actividad son similares a los diagramas de flujo procesales, con la

diferencia de que todas las actividades están claramente unidas a objetos.

Los diagramas de actividad siempre están asociados a una clase, a una operación o a un

caso de uso. Los diagramas de actividad soportan actividades tanto secuenciales como

paralelas. La ejecución paralela se representa por medio de iconos de espera, y en el

caso de las actividades paralelas, no importa en qué orden sean invocadas (pueden ser

ejecutadas simultáneamente o una detrás de otra).



2.7.9 DIAGRAMAS DE COMPONENTES Los diagramas de componentes muestran los componentes del software (ya sea las

tecnologías que lo forman como Kparts, componentes CORBA, Java Beans o

simplemente secciones del sistema claramente distintas) y los artilugios de que está

compuesto como los archivos de código fuente, las librerías o las tablas de una base de

datos.

Los componentes pueden tener interfaces (es decir clases abstractas con operaciones)

que permiten asociaciones entre componentes.

2.7.10 DIAGRAMAS DE IMPLEMENTACIÓN



Los diagramas de implementación muestran las instancias existentes al ejecutarse así

como sus relaciones. También se representan los nodos que identifican recursos físicos,

típicamente un ordenador así como interfaces y objetos (instancias de las clases).

2.8SISTEMAS DE VARIABLES 2.8.1 VARIABLE DEPENDIENTE

Entrega de proyectosLa creación de una Web o Software a través de determinados desarrollos

informáticos y la elaboración de una estrategia que defina la presencia del

CLIENTE.

2.8.2 VARIABLES INDEPENDIENTES Normas de excelencia Claridad organizacional Calor y apoyo - Trabajo en Equipo Recompensa – Salario Seguridad Responsabilidad Liderazgo Comunicación



5.6.3. VARIABLES DE CAUSA Y EFE



CAPITULO III

3.1 Metodología para el análisis y diseño de la solución:

Situación actual

En la actualidad la empresa BINARY no cuenta con un manejo centralizado de la información, lo que provoca que muchas veces se pierda parte de la misma. Esta carece de una aplicación que organice, gestione y administre toda la documentación encaminada a los usuarios y a la empresa en general, por lo que presentan información dispersa en cada uno de sus áreas, el mecanismo para hacerle llegar las informaciones a los diferentes trabajadores no es el más óptimo.

Para programar los servicios que brindan a cada uno de los clientes usan una aplicación que contiene un módulo de proyectos, en el módulo de proyectos se definen los datos básicos del proyecto tales como la fecha y nombre de un proyecto, también cuenta con una sección de EDTS, en esta los programadores registran sus actividades diarias, cabe mencionar que el EDT no es generado por alguna persona responsable en la repartición de tareas sino por los mismos programadores, causando así una mala definición del proyecto.

Los procesos manuales de BINARY tienden a tener gran cantidad de errores, por la intervención y discrecionalidad humana, además de la lentitud que puede causar.



3.1.1 Técnicas de procesamiento y análisis de datos:

3.1.1.1 Diagrama de Contexto







3.1.2 Metodología a utilizar

En el desarrollo de este proyecto se empleara una metodología Orientada a Objetos (OO), basándose en el Proceso Unificado de Desarrollo de Software RUP.

RUP se basa en los siguientes 6 principios:

• Establece un conjunto de fases adaptables al contexto y necesidades de cada proyecto.

• Permite balancear las prioridades de las partes interesadas.

• Promueve la colaboración a través de equipos.

• Permite obtener productos en cada iteración del proyecto. Permite la evaluación al terminar cada iteración, para redefinir e iniciar la siguiente iteración.

• Promueve elevar el nivel de abstracción durante el proyecto, lo cual motiva el uso de conceptos reutilizables, el análisis de soluciones arquitectónicas, la reutilización del código y la representación visual del proyecto mediante el Lenguaje Unificado de Modelado (UML), como en este proyecto. Este principio evita que el ingeniero de software vaya directamente de los requisitos a la codificación.

• Controla la calidad en todos los aspectos de cada iteración.

Esta metodología fue seleccionada por los siguientes motivos:

• Es un marco de trabajo que permite el desarrollo exitoso de software iterativo e incremental.

• Junto con UML, constituye la metodología estándar más utilizada para el análisis, diseño e implementación de sistemas orientados a objetos.

• El proyecto se desarrolla de acuerdo a los principios que plantea esta metodología.

• Esta metodología es utilizada para el desarrollo de software dentro de la institución donde se aplica el caso práctico. El proyecto abarca las dos primeras fases del ciclo de vida del proceso unificado.

Iniciación: fase en la que se definen los diferentes alcances del proyecto y se describen con los casos de uso.

Elaboración: fase en la que se realiza la planificación del proyecto, se especifican en detalle los casos de uso y se realiza el diseño de la arquitectura del sistema sin llegar a la especificación del método de programación.

Se presenta a continuación 2 tablas con los marcos de trabajos seguidos durante este proyecto, el primer marco de trabajo organizado por flujos de trabajo del proceso unificado y el segundo marco de trabajo organizado por fases del proceso unificado, en ambos marcos se pueden visualizar los artefactos obtenidos.



Marco de trabajo organizado por flujos de trabajo fundamentales del Proceso Unificado, aplicado en proyecto.

FASE ARTEFACTOModelado del negocio

Procesos del negocio Diagrama de actividades

Requerimientos Diagrama de casos de uso y Especificación de casos de uso.

Análisis Diagrama de clases. Diagrama de secuencia de sucesos. Diagrama de estados.

Diseño Diagrama de componentes. Modelo entidad relación. Prototipo.

Implementación No es parte de la presente tesis. Pruebas No es parte de la presente tesis.

Marco de trabajo organizado por fases del Proceso Unificado, aplicado en el proyecto.

FASE ARTEFACTOInicio Modelado del negocio - Procesos del negocio

Modelado del negocio - Diagramas de actividades Requerimientos - Visión del proyecto. Requerimientos - Diagrama de casos de uso.

Elaboración Requerimientos - Diagrama de casos de uso y Especificación de casos de uso.

Diseño - Prototipo. Análisis - Diagrama de clases. Análisis - Diagrama de secuencia de sucesos. Análisis - Diagrama de estados. Diseño - Diagrama de componentes. Diseño - Modelo entidad relación.

Construcción No es parte de la presente tesis. Transición No es parte de la presente tesis. Diseño de la investigación

Para el diseño de la intranet haremos uso de un lenguaje de modelado UML debido a que esta herramienta constituye una metodología estándar muy utilizada para el análisis, diseño e implementación de sistemas orientados a objetos.

Población y muestra

La población está definida por todos los proyectos que se realizan en la empresa Binary.

Cantidad de proyectos 5



Técnicas e instrumentos de recolección de datos

Técnicas

Son un conjunto de reglas y procedimientos que permiten establecer la relación con el objeto o sujeto de la investigación. En el presente proyecto se hará uso de las siguientes técnicas:

- Encuestas- Observación- Entrevistas- Sesión de grupo

Instrumentos

Mecanismo que usa el investigador para recolectar y registrar la información.

- Cuestionario- Listas de chequeo- formularios- escalas de opinión

3.2 Metodología para el Estudio de Factibilidad (viabilidad) de la Solución:

Estudio de Factibilidad

La Empresa Binary cuenta con una infraestructura que permite considerar ampliamente el desarrollo de una intranet, pero el solo contar con la infraestructura física no es un factor que determine la ejecución de un proyecto. En esta sección se presenta una valoración de la factibilidad de la implementación de una intranet como un medio de gestión y planificación de proyectos.

3.2.1 Factibilidad Técnica

Este tipo de factibilidad busca determinar que los recursos tecnológicos y humanos con que cuenta la organización son óptimos para el funcionamiento del nuevo sistema o si será necesario adquirir nuevo equipo tecnológico o personal calificado.

De acuerdo a la información obtenida durante la investigación de campo realizada en las instalaciones en la Empresa Binary, se presenta a continuación la infraestructura tecnológica y humana actual con el proyecto.

Recursos tecnológicos de la Empresa Binary.

Hardware EspecificaciónProcesador Intel Xeon 2.8 ghz.Memoria Primaria 2GB DDR ECC REGMemoria Secundaria Discos duros de 500 GB ultra 320 SCSI 10.000



rpmTarjeta de red 100 MbpsSoftware EspecificaciónServidor Web ApacheSistema Operativo Windows Server 2008Base de datos Mysql, PostgressMódulos Php, Perl, C++

Especificaciones técnicas mínimas requeridas para el sistema.

Tabla de especificaciones técnicas.

Hardware EspecificaciónCliente

Procesador Pentium III, equivalente o superiorMemoria 128 MB o superiorTarjeta de red 100 Mbps

ServidorProcesador Pentium IV, equivalente o superiorMemoria 512 MB o superiorTarjeta de red 100 Mbps o superiorSoftware Especificación

ClienteSistema Operativo Windows, Linux, etc.Navegador Internet Explorer, Mozilla, FireFox, etc.

ServidorSistema Operativo Windows, Linux, SolarisWebServer Apache, IIS MicrosoftBase de datos Mysql, Sql server, Oracle, etc.Otro Modulo PHP(para plataforma seleccionada)Recurso Humano(Cargo) ExperienciaUn Administrador de Servidores Web Conocimiento en administración, configuración

de servidores Web Apache y IIS.Conocimiento de publicación de sitios Web.

Luego de presentar los recursos con que cuenta la empresa Binary actualmente y los requeridos por el sistema, se comprueba que la empresa Binary cuenta con la información de tecnología y humana necesaria para llevar a cabo la implementación del presente proyecto.

3.2.2 Factibilidad Operativa.



Técnicas de recolección de Datos

Esta evolución se llevó a cabo realizando un levantamiento de información basándonosen unas encuestas y en breves entrevistas sostenidas con el personal involucrado de la empresa Binary, se demostró que estos no presenta ninguna oposición al cambio por lo que el sistema se muestra factible operacionalmente, a continuación se muestra los resultados de las evaluaciones realizadas.

ENCUESTA

Esta encuesta estuvo dirigida al personal que labora en el departamento de Desarrollo de la empresa Binary, la misma fue realizada a los jefes de área.

1) ¿Usted considera que el método actual para el proceso de Gestión de proyecto es eficiente?

Posibles Respuestas Resultados PorcentajeSi 12 80%No 3 20%

Porcentaje

2) Según la escala ¿Cuál es su nivel de satisfacción en cuanto a los procesos actuales para el registro de proyectos?

Posibles Respuestas Resultados PorcentajeExcelente 1 6,67%Bueno 5 33,33%Regular 9 60,00%Malo 0 0,00%



a) Excelente; Series1; 0.0666666666666667; 7%

b) Bueno; Series1; 0.333333333333333;

33%

c) Regular; Series1; 0.600000000000001;

60%

a) Excelente

b) Bueno

c) Regular

d) Malo

3) ¿Cómo considera usted que es el proceso de consulta para los proyectos pasados?

Posibles Respuestas Resultados PorcentajeExcelente 1 6,67%Bueno 6 40,00%Regular 8 53,33%Malo 0 0,00%

a) Exce-lente; Se-

ries1; 6.67%

b) Bueno; Series1; 40.00%

c) Regu-lar; Series1;

53.33%d) Malo;

Series1; 0.00%

Series1

4) Según la escala ¿Qué grado de eficiencia posee la gestión actual de proyectos? Siendo 5 Excelente y 1 Malo

Escala 5 4 3 2 1

Respuestas 0 4 2 9 0



Regular; Series1; 0.26666666666666

7; 27%

Bueno; Series1; 0.13333333333333

3; 13%Muy Bueno; Series1; 0.60000000000000

1; 60%

Malo

Regular

Bueno

Muy Bueno

Excelente

5) ¿Existe algún manual de procedimientos por escrito en donde se describan lo pasos del proceso actual de la gestión de proyectos?


a) Si; Series1; 0.8; 80%

b) No; Series1; 0.2; 20%

a) Sib) No

6) ¿Cuál es el volumen de proyectos que se incorporan al (departamento de Desarrollo) mensualmente?

Posibles Respuestas Resultados PorcentajeDe 1 a 2 12 6,67%De 2 a 4 3 40,00%De 4 a 6 0 53,33%Más de 6 0 0,00%



7) ¿Está de acuerdo en automatizar los procesos de Gestión de proyectos?


a) Si; Porcentaje

de Respues-tas;

100.00%

b) No; Porcentaje de Respuestas;

0.00%

Porcenta-je de Respues-tas

8) En su opinión ¿cree usted que es importante tener un control de los proyectos por medio de un sistema que trabaje con otro departamento?

Posibles Respuestas Resultados PorcentajeSi 14 93.33%No 1 6.67%



a) Si; Series1; 93.33%

b) No; Series1; 6.67%

Series1

9) ¿Considera eficiente utilizar un Sistema vía web que controle el avance del proyecto?

Posibles Respuestas Resultados PorcentajeSi 14 93.33%No 1 6.67%

10) ¿Está de acuerdo con la generación de informes de error por medio de una intranet?

Posibles Respuestas Resultados PorcentajeTotalmente de acuerdo 14 6,67%De acuerdo 1 40,00%Indiferente 0 53,33%En desacuerdo 0 0,00%



a) Totalmen-te de acuerdo; Porcentaje de Respuestas;

93.33%

b) De acuerdo; Por-

centaje de Respuestas;

6.67%

Porcentaje de Respuestas


11) ¿Cuál de las siguientes palabras describiría mejor un sistema de gestión de proyectos?

Posibles Respuestas Resultados PorcentajeRápido 4 26,67%Fácil 4 26,67%Dinámico 7 46,67%Ordenado 5 33.33%Estructurado 2 13.33%Económico 2 13.33%Puntual 2 13.33%Seguro 4 26,67%

Rápido; Porcentaje de Respuestas;

26.67%

Fácil; Porcentaje de Respuestas; 26.67%

Dinámico; Porcenta-je de Respuestas;

46.67%

Ordenado; Porcen-taje de Respuestas;

33.33%

Estructurado; Por-centaje de Respues-

tas; 13.33%

Económico; Porcen-taje de Respuestas;

13.33%

Puntual; Porcentaje de Respuestas;

13.33%

Seguro; Porcentaje de Respuestas;

26.67%


12) ¿Estaría usted de acuerdo a recibir apoyo de los estudiantes delaUTP en un proyecto dirigido a mejorar los procesos realizados en la empresa Binary?



Estoy de Acuerdo;

Porcentaje de Respues-tas; 100.00%

No estoy de Acuerdo;

Porcentaje de Respues-tas; 0.00%

Porcentaje de RespuestasPorcentaje de Respues-tas

Esta Última es una Pregunta para una respuesta abierta, y luego del análisis de la misma todos los encuestados concluyen que están de acuerdo.

En el estudio de las tres primeras preguntas se logró observar que el personal que labora en las diferentes áreas considera que los métodos actuales utilizados les permiten realizar sus labores, cumpliendo con los objetivos planteados. Mas sin embargo en el análisis de la pregunta 4 determinamos que sus procesos satisfacen las necesidades existentes pero no de manera eficiente.

En el análisis de las preguntas 7, 8, 9 las respuestas obtenidas nos demuestran que un 90% del personal involucrado con el sistema actual no representa ninguna oposición al cambio y acepta contundentemente la implantación de un sistema Intranet. Por lo tanto el Sistema propuesto se considera factible operacionalmente.

CAPITULO IV

4.1 Índice preliminar de la tesis



ÍNDICE

AGRADECIMIENTO................................................................................................2DEDICATORIA.........................................................................................................3INTRODUCCIÓN......................................................................................................6

CAPITULO 1: FORMULACIÓN DEL PROBLEMA.................................................71.1 Planteamiento del problema ..............................................................................131.2 Antecedentes de solución..................................................................................231.3 Propuesta de solución........................................................................................241.4 Alcance de la propuesta.....................................................................................251.5 Justificación de la investigación.........................................................................251.6 Objetivos.............................................................................................................261.6.1 Objetivos General............................................................................................261.6.2 Objetivos Específicos......................................................................................26

CAPÍTULO 2. MARCO TEÓRICO...........................................................................272.1 Antecedentes de la investigación.......................................................................282.2 Bases teóricas....................................................................................................282.3 Diagramas de Datos...........................................................................................292.4 Base de Datos....................................................................................................292.5 Modelo de Datos Entidad-Relación (E/R)..........................................................302.6 Diccionario de datos (DD)..................................................................................312.7 UML (LENGUAJE UNIFICADO DE MODELADO).............................................342.8 SISTEMAS DE VARIABLES..............................................................................35

CAPITULO 3: MARCO METODOLOGICO.............................................................413.1 Metodología para el Análisis y Diseño de la solución.......................................413.1.1 Técnicas de procesamiento y análisis de datos.............................................413.1.2 Metodología a Utilizar.....................................................................................413.2 Metodología para el Estudio de Factibilidad de la solución...............................463.2.1 Factibilidad Técnica.........................................................................................463.2.3 Factibilidad Económica....................................................................................47

CAPITULO 4: ASPECTOS ADMINISTRATIVOS....................................................494.1 Índice preliminar de la tesis................................................................................494.2 Presupuesto y cronograma de Actividades........................................................50

CAPITULO 5: SOLUCION PROPUESTA................................................................495.1 Requerimientos Funcionales..............................................................................495.2 Requerimientos no Funcionales.........................................................................505.3Casos de Usos Relacionados al Proyecto..........................................................505.4Matriz de trazabilidad..........................................................................................505.5Diagrama de clases.............................................................................................505.6Diagramas de interacción....................................................................................505.7Diagrama de Secuencia......................................................................................505.8Modelo físico de datos.........................................................................................505.9Prototipos del Sistema.........................................................................................50



CAPITULO 6: CONCLUSIONES Y RECOMENDACIONES...................................494.1 Conclusiones......................................................................................................494.2 Recomendaciones..............................................................................................50

Referencias Bibliográficas....................................................................................52Glosario de Términos.............................................................................................53



4.2 Presupuesto y cronograma de actividades



Referencia

ALVAREZ A. JOSE V. “Uso de Estándares E-learning en espacios educativos”. Revista Fuentes. Disponible en: http://www.cica.es/aliens/revfuentes/campo_02.htm

AVGERIOU P., PAPASALOUROS A. & RETAILS S., (2003) “LearningTechnologySystem: issues, trends, challenges”. Disponible en: http://www.softlab.ntua.gr/~retal/papers/conferences/ioste_cyp2001/LTSreview_fin.pdf

http://es.slideshare.net/lulyta78/proyecto-de-aplicacin-intranets-redes-privadas

http://upcommons.upc.edu/pfc/bitstream/2099.1/11785/1/PFC_GMV_Ruben_Garcia_Tamayo.pdf

Bibliografía

Manual Java URL:http://www.webtaller.com/manualjava/indice_manual_java.php Instalador XAAMP URL:http://www.filestube.com/6278c9b77011ba6d03ea,g/NetBeans-IDE-6-8-ml-XAAMP-windows.html Instalador Del My SQL EssentialURL: http://dev.mysql.com/downloads/connector/odbc/5.0.html Instalador del My SQL GUI URL: http://dev.mysql.com/downloads/gui-tools/5.0.html


Documents

Desarrollo de una Intranet para la empresa BINARY · Web viewCarlos Zorrilla Varga INTEGRANTES Grados Espinoza, Herbert Junior. Zuloeta Huerta, Luis Baiker Dedicatoria A toda mi familia