UNIVERSIDAD SAN PEDRO

FACULTAD DE INGENIERA
ESCUELA ACADEMICO PROFESIONAL DE INGENIERIA INFORMTICA Y DE SISTEMAS

PROGRAMA AVANZADO DE ESTUDIOS INGENIERA INFORMTICA Y DE SISTEMAS

ANALISIS, DISEO DE UN SISTEMA INFORMATICO WEB PARA MEJOAR EL PROCESO DE ESTIMACIN DE COSTOS DE PROYECTOS DE CONTRUCCION CIVIL EMPRESAX DE LA CIUDAD DE LIMA 2013 PARA LA EMPRESA

INFORME PARA OBTENER EL TITULO PROFESIONAL DE INGENIERO INFORMTICO Y DE SISTEMAS

PRESENTADO POR: Bach. SAENZ GUERRERO LUIS MIGUEL ASESOR: Dr. FERNANDO VEGA HUINCHO HUARAZ PERU - 2013

DEDICATORIA

Este trabajo lo dedico a mi familia, y en especial a mis padres, me apoyaron, como durante en todo quienes otras este

ocasiones,

anhelado trabajo. A mi esposa y a mi hijo, quienes con su apoyo y

presencia, me incentivaron hacia la culminacin del mismo. Luis

AGRADECIMIENTO
A la Universidad de San Pedro y de

Escuela

Informtica

Sistemas por haberme brindado la oportunidad de incrementar mis conocimientos, a los Seores

catedrticos por sus orientaciones y sabios consejos, y en especial a mi asesor quin me encamin hacia la culminacin del presente trabajo.

Luis

PRESENTACIN

Seores Miembros del Jurado:

El autor

INDICE GENERAL
DEDICATORIA AGRADECIMIENTO PRESENTACIN RESUMEN ABSTRACT INTRODUCCIN CAPITULO I PLAN DE INVESTIGACION 1.1. DATOS GENERALES DE LA EMPRESA 1.1.1. Razn social 1.1.2. Direccin 1.1.3. Giro del Negocio 1.1.4. Historia 1.1.5. Organigrama 1.1.6. Misin 1.1.7. Visin 1.1.8. Logo de la institucin 1.2.REALIDAD PROBLEMATICA 1.3.FORMULACION DEL PROBLEMA 1.4. SELECCIN DEL PROBLEMA 1.5.OBJETIVOS 1.5.1. Objetivos Generales 1.5.2. Objetivos Especficos 1.6. HIPOTESIS 1.7. JUSTIFICACION 1.7.1. Econmica 1.7.1. Tcnica 1.7.1. Operativa 1.7.1. Social 2 3 4 5 6 10 12 12 12 12 12 12 12 13 14 14 14 14 16 16 16 16 16 17 17 17 17 18 18

1.8. LIMITACIONES CAPITULO II SISTEMAS INFORMATICOS Y EL ESTUDIO DE MERCADO 2.1. ANTECEDENTES 2.2. SISTEMAS INFORMATICOS 2.2.1. Definicin 2.2.2. Elemento de un sistema informtico 2.2.3. Panorama general de los sistemas en las instituciones 2.2.4. Sistema informtico desde la perspectiva cliente servidor 2.2.5. Metodologa 2.2.6. Lenguaje Unificado de Modelado 2.2.7. Ingeniera de software 2.2.8. Ingeniera de software 2.2.8. PHP 5.0 2.2.9. MySQL 5.0 2.2.10. Rational Rose Enterprise Edition 2.3. ESTUDIO DE MERCADO 2.3.1. Objetivo del estudio de mercado 2.3.2. mbito de aplicacin del estudio de mercado 2.3.3. Clases de mercado 2.3.4. Procesos de estudio de mercado 2.3. TERMINOLOGIA BASICA CAPITULO III DESCRIPCION DE LA METODOLOGIA 3.1. ESTUDIO DE MERCADO 3.2. DIAGRAMA DE CASO DE USO DEL NEGOCIO 3.3. PROTOTIPOS 3.4. CODIGO FUENTE CONCLUSIONES RECOMENDACIONES BIBLIOGRAFIA

18 19 19 19 19 19 20 21 22 33 35 47 47 47 48 49 50 52 53 54 55 63 65 65 65 66 74 86 122 123 124

CAPTULO I PLAN DE INVESTIGACIN

1.1. REALIDAD PROBLEMTICA

1.2. SELECCIN DEL PROBLEMA

1.3. FORMULACIN DEL PROBLEMA

1.4. OBJETIVOS 1.4.1. Objetivos Generales:

1.4.2. Objetivos Especficos:

1.5. HIPOTESIS . 1.6. JUSTIFICACIN El proyecto se justifica en los siguientes aspectos: 1.6.1. Econmica .

1.6.2.

Tcnica

1.6.3.

Operativa

1.7. LIMITACIONES

CAPTULO II SISTEMAS INFORMATICOS Y ESTIMACION DE COSTO 2.1. ANTECEDENTES

2.2. SISTEMAS INFORMATICOS 2.2.1. Definicin Un sistema informtico es un conjunto de partes que funcionan relacionndose entre s con un objetivo preciso. Sus partes son: hardware, software y las personas que lo usan. Por ejemplo, una computadora, sus dispositivos perifricos y la persona que la maneja, pueden constituir un sistema informtico.

Un sistema informtico puede formar parte de un sistema de informacin; en este ltimo la informacin, uso y acceso a la misma, no necesariamente est informatizada. Por ejemplo, el sistema de archivo de libros de una biblioteca y su actividad en general es un sistema de informacin. Si dentro del sistema de informacin hay computadoras que ayudan en la tarea de organizar la biblioteca, entonces ese es un sistema informtico.

En un sistema informtico se utilizan computadoras para almacenar, procesar y/o acceder a informacin. En un sistema de informacin se pueden utilizar computadoras, pero no es necesario. El acceso a la informacin puede ser fsico (por ejemplo, una persona se encarga de buscar en un archivador). Tanto el sistema informtico como el sistema de informacin, incluyen a las personas que acceden o producen informacin dentro del sistema. Las personas tienen que capacitarse para entender el funcionamiento y procedimientos que soporta sistema. Ambos sistemas tienen un propsito. Por ejemplo, gestionar el acceso y distribucin de libros una biblioteca,

administrar la entrada/salida de mercadera, personal y otros recursos de un comercio, etc. Un sistema informtico es cualquier estructura dinmica fruto de la unin entre elementos bsicos como hardware y software. Un sistema informtico standard integra un computador que opera a travs de dispositivos programables para almacenar, transformar y procesar datos. 2.2.2. Elementos de un sistema informtico En general, la mayora de sistemas informticos disponen de los siguientes elementos: Hardware: El Hardware es el conjunto de elementos fsicamente visuales en un sistema de procesamiento de datos (EDP en ingles o PED en castellano). Es el equipo propiamente dicho. Bajo este trmino se incluye tanto a la computadora como a los equipos perifricos: Impresoras, discos duros, monitores, unidades de respaldo, etc. Llamamos entonces hardware al conjunto de dispositivos mecnicos y electrnicos que porman parte de la computadoara. Es el primer elemneto de un sisemas de computacin y corresponde a toda la maquinaria y al equipo relacionado al mismo.

Grfico N 03. Hardware

Software: Conjunto de instrucciones denominadas programas que son ejecutados y procesados por la unidad central de procesamiento del

computador y permiten ejecutar un conjunto de tareas para la cual ha sido diseado o creado. Es el segundo elemento de un sistema informtico. Datos y/o Informacin: Es la materia prima o unidad bsica del procesamiento computacional. Constituye la entrada del sistema para que esta sea procesada, de ella se obtiene informacin, y de la informacin el conocimiento, materia prima bsica de la toma de decisiones. Es el tercer elemento de un sistema informtico.

Grfico N 04. Software

Manware o Humanware: Persona o conjunto de personas capacitadas o preparadas para utilizar y trabajar adecuada y eficientemente en un sistema de cmputo. Es el cuarto elemento de un sistema de cmputo.

2.2.3. Panorama General de los Sistemas en las Instituciones Ningn Sistema por s mismo proporciona toda la informacin que la institucin requiere. Las instituciones cuentan con muchos sistemas de informacin que sirven a los diferentes niveles y funciones. As, los

sistemas tpicos que se encuentran en las instituciones se disean para apoyar a los trabadores o gerentes de cada nivel y en la funcin de ventas y mercadotecnia, manufactura, contabilidad, finanzas y recursos humanos.

10

2.2.4. Sistema Informtico desde la perspectiva Cliente/Servidor Definicin de cliente servidor Sistema distribuido entre multiples procesadores donde hay clientes que solicitan servicios y servidores que les proporcionan servicios. Separa los servicios situando cada uno en su plataforma mas adecuada.

Desde el punto de vista funcional, se puede definir la computacin Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la informacin en forma trasparente an en entornos multiplataforma. En el modelo cliente servidor, el cliente enva unmensaje solicitando un determinado servicio a un servidor (hace una peticin), y este enva uno o varios mensajes con la respuesta (provee el servicio).

En esta arquitectura la capacidad de proceso est repartida entre los clientes y los servidores, aunque son ms importantes las ventajas de tipo organizativo debidas a la centralizacin de la gestin de la informacin y la separacin de responsabilidades, lo que facilita y clarifica el diseo del sistema. La separacin entre cliente y servidor es una separacin de tipo lgico, donde el servidor no se ejecuta necesariamente sobre una sola mquina ni es necesariamente un slo programa. Los tipos especficos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propsitos varan de unos servicios a otros, la arquitectura bsica seguir siendo la misma. Una disposicin muy comn son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando as el grado de distribucin del sistema.

11

Los principales componentes del esquema cliente /servidor son entonces los clientes (terminales), los servidores y la infraestructura de comunicaciones.

Los clientes realizan generalmente funciones como: Manejo de la interfaz del usuario. Captura y validacin de los de entrada. Generacin de consultas e informes sobre las base de datos. Por su parte los servidores realizan, entre otras, las siguientes funciones: Gestin de perifricos compartidos. Control de accesos concurrentes a base de datos compartidas. Enlaces de comunicaciones con otras redes de rea local o extensa. Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y este, le responde proporcionado. Normalmente, pero no necesariamente, el cliente y el servidor estn ubicados en distintos procesadores. Los clientes se suelen situar en ordenadores personales y/o estaciones de trabajo y los servidores en procesadores departamentales o de grupo.

A.

Componentes Esenciales de la Infraestructura Cliente/Servidor Una infraestructura cliente/servidor consta de tres componentes esenciales, todos ellos de igual importancia y estrechamente ligados: Plataforma Operativa. La plataforma deber soportar todos los modelos de distribucin cliente/servidor, todos los servicios de comunicacin, y deber utilizar, preferentemente, componentes estndar de la industria para los servidos de distribucin. Los desarrollos propios deben coexistir con las aplicaciones estndar y su integracin deber ser imperceptible para el usuario. Igualmente,

podan acomodarse programas escritos utilizando diferentes tecnologas y herramientas.

12

Entorno de Desarrollo de Aplicaciones. Debe elegirse despus de la plataforma operativa. Aunque es conveniente evitar la proliferacin de herramientas de desarrollo, se garantizar que el enlace entre estas y el middleware no sea excesivamente rgido.

Un entorno de aplicacin incremental, debe posibilidad la coexistencia de procesos cliente y servidor desarrollados con distintos lenguajes de programacin y/o herramientas, as como utilizar distintas tecnologas (por ejemplo, lenguaje procedural, lenguaje orientados a objetos, multimedia), y que han sido puestas en explotacin en distintos momentos del tiempo.

Gestin de Sistemas. Estas funciones aumentan considerablemente el costo de una solucin, pero no se pueden evitar. Siempre deben adaptarse a las necesidades de la organizacin, y al decidir la plataforma operativa y el entorno de desarrollo, es decir, en las primeras fases de la definicin de la solucin.

Merece la pena considerar los aspectos siguientes: Qu necesitamos gestionar? Dnde estarn situados los procesadores y estaciones de trabajo? Cuntos tipos distintos se soportaran? Qu tipo de soporte es necesario y quien lo proporciona?

13

Grfico N 05: Distribucin de computadoras en sistema Cliente-Servidor.

B. Funcionamiento de un sistema cliente-servidor Un Sistema Cliente/Servidor funciona tal como se detalla en el siguiente diagrama:

CLIENTE

Solicitudes
SERVIDOR

Respuestas
CLIENTE

Solicitudes
Grfico N 06: Funcionamiento del sistema Cliente-Servidor.

Es decir el cliente enva una solicitud al servidor mediante su direccin IP y el puerto, que est reservado para un servicio en particular que se ejecuta en el servidor y luego el servidor recibe la solicitud y responde a la direccin IP del equipo cliente y su puerto.

C. Niveles o capas Arquitectura en 2 niveles. Se utiliza para describir los sistemas cliente/servidor en donde el cliente solicita recursos y el servidor responde directamente a la solicitud, con sus propios recursos. Esto significa que el servidor no requiere otra aplicacin para proporcionar parte del servicio.

NIVEL 1
Solicitud Http Archivos Sql Voip

NIVEL 2 Envo de Solicitudes Envo de 14 Respuestas

Cliente

Servidor

Grfico N 07: Arquitectura Cliente-Servidor en 2 Niveles.

Arquitectura en 3 niveles. En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la arquitectura generalmente est compartida por: Un cliente, es decir, el equipo que solicita los recursos, equipado con una interfaz de usuario (generalmente un navegador Web) para la presentacin. El servidor de aplicaciones (tambin denominado software intermedio), cuya tarea es proporcionar los recursos solicitados, pero que requiere de otro servidor para hacerlo.

El servidor de datos, que proporciona al servidor de aplicaciones los datos que requiere.

NIVEL 1
Solicitud Http Archivos Sql Voip

NIVEL 2 Envo de Solicitudes Envo de Respuestas Servidor de Aplicaciones

NIVEL 3

Cliente

Servidor de Base de Datos

Consulta de SQL

15

Grfico N 08: Arquitectura Cliente-Servidor en 3 Niveles.

En una arquitectura de tres niveles, los trminos "capas" y "niveles" no significan lo mismo ni son similares. El trmino "capa" hace referencia a la forma como una solucin es segmentada desde el punto de vista lgico: Presentacin/ Lgica de Negocio/ Datos. En cambio, el trmino "nivel" corresponde a la forma en que las capas lgicas se encuentran distribuidas de forma fsica. Por ejemplo: Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en un solo ordenador (Presentacin+lgica+datos). Se dice que la arquitectura de la solucin es de tres capas y un nivel. Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en dos ordenadores (presentacin+lgica,

lgica+datos). Se dice que la arquitectura de la solucin es de tres capas y dos niveles. Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en tres ordenadores (presentacin, lgica, datos). La arquitectura que la define es: solucin de tres capas y tres niveles. Arquitectura en mltiples niveles. En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea especializada (un servicio). Por lo tanto, un servidor puede utilizar los servicios de otros servidores para proporcionar su propio servicio. Por consiguiente, la arquitectura en 3 niveles es potencialmente una arquitectura en N-niveles

NIVEL 1

Cliente

NIVEL 2

16

Servidor

Grafico N 09: Arquitectura Cliente-Servidor N-niveles.

D. Programacin por N capas La programacin por capas es un estilo de programacin en el que el objetivo primordial es la separacin de la lgica de negocios de la lgica de diseo; un ejemplo bsico de esto consiste en separar la capa de datos de la capa de presentacin al usuario.

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algn cambio, slo se ataca al nivel requerido sin tener que revisar entre cdigo mezclado. Un buen ejemplo de este mtodo de programacin sera el modelo de interconexin de sistemas abiertos.

Adems, permite distribuir el trabajo de creacin de una aplicacin por niveles; de este modo, cada grupo de trabajo est totalmente abstrado del resto de niveles, de forma que basta con conocer la API que existe entre niveles.

En el diseo de sistemas informticos actual se suele usar las arquitecturas multinivel o Programacin por capas. En dichas arquitecturas a cada nivel se le confa una misin simple, lo que permite

17

el diseo de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten). El diseo ms utilizado actualmente es el diseo en tres niveles (o en tres capas).

Grfico N10: Diseo en 3 Capas.

Capa de presentacin Es la que ve el usuario (tambin se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la informacin y captura la informacin del usuario en un mnimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se comunica nicamente con la capa de negocio. Tambin es conocida como interfaz grafica y debe tener la caracterstica de ser "amigable" (entendible y fcil de usar) para el usuario.

Capa de negocio Es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envan las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lgica del negocio) porque es aqu donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentacin, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos para almacenar o recuperar datos de l. Tambin se consideran aqu los programas de aplicacin.

18

Capa de datos Es donde residen los datos y es la encargada de acceder a los mismos. Est formada por uno o ms gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperacin de informacin desde la capa de negocio.

Todas estas capas pueden residir en un nico ordenador, si bien lo ms usual es que haya una multitud de ordenadores en donde reside la capa de presentacin (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o ms ordenadores. As, si el tamao o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirn las peticiones del ordenador en que resida la capa de negocio. Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separacin, esta capa de negocio podra residir en uno o ms ordenadores que realizaran solicitudes a una nica base de datos. En sistemas muy complejos se llega a tener una serie de ordenadores sobre los cuales corre la capa de datos, y otra serie de ordenadores sobre los cuales corre la base de datos.

E. Costos y Beneficios de Cliente/Servidor Los costos de la implementacin de soluciones cliente/servidor no deben contemplarse solo en trminos absolutos, sino que deben medirse en funcin del beneficio que reporten los nuevos desarrollos. Como el precio de los ordenadores personales ha bajado tanto en los ltimos aos, con frecuencia se comete el error de pensar que las soluciones cliente/servidor son ms econmicos que las basadas en ordenadores tradicionales. Estudios independientes indican que el costo del hardware

19

y software, en un periodo de 5 aos, representa solamente el 2% de los costos totales. En el caso de sistemas distribuidos, el 80% restante son costos de infraestructura y gastos de explotacin. Los beneficios percibidos de la implantacin de un modelo cliente/servidor se encuentran, generalmente, en algunas de estas categoras: La productividad que se obtiene en las estaciones de trabajo programables con interfaz grafica de usuario, que permite acceder e integrar aplicaciones muy intuitivamente. La abundancia de software disponible comercialmente, como por ejemplo procesadores de texto, hojas de clculo, sistemas basados en el conocimiento, correo, etc. La cercana del usuario a aplicaciones y datos que son necesarios para su actividad, compartiendo servicios y costos. La disponibilidad de potencia de clculo a nivel personal, sin la responsabilidad del mantenimiento del sistema y del software de aplicaciones. La disponibilidad de herramientas de desarrollo fciles de usar, reduciendo la dependencia del departamento informtico. Los beneficios obtenidos por la alta direccin, seguramente estn entre los procesos de negocio: Uno mejor ajuste del sistema de informaron a la organizacin y a los procesos de negocio. Cada tarea se puede ubicar en la plataforma que sea ms eficaz, y los recursos informticos se pueden aplicar progresivamente. Las funciones y los datos se pueden localizar donde sean necesarios para la operativa diaria sin cambiar las aplicaciones. Mayor proteccin de activos informticos e integracin de los sistemas y aplicaciones ya existentes.

20

 Acceso a la informacin cuando y donde la necesitan los usuarios. Este es, probablemente, el mayor activo corporativo. Disponibilidad de aplicaciones estndar (comprar en vez de desarrollar). Libertad para migrar a plataformas de sistemas alternativos y usar servidores especializados. Una respuesta ms rpida a las necesidades del negocio gracias a la disponibilidad de software de productividad personal y de

herramientas de desarrollo fciles de usar. Un entorno de utilizacin ms sencillo, que proporciona una mayor productividad. A largo plazo, las interfaces graficas de usuario reducen los costos asociados a educacin y formacin de los usuarios. 2.2.5. Metodologa Descripcin La metodologa propuesta est basada en el ciclo de vida del desarrollo de sistema (SDLC) propuesto por Kendall & Kendall (1999); en donde sostiene que el SDLC en un enfoque por fases del anlisis y diseo que sostiene que los sistemas son desarrollados de mejorar manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.

Identificacin de problemas, oportunidades y objetivos Tiene que ver con la identificaron de problemas, oportunidades y objetivos. Esta etapa es crtica para el xito del resto del proyecto.

Esta fase requiere que el analista observe honestamente lo que est sucediendo en un negocio para posteriormente hacer resaltar los problemas.

Las oportunidades son situaciones que el analista considera que pueden ser mejoradas por medio del uso de sistemas de informacin

21

computarizados. El aprovechar las oportunidades pude permitir que el negocio gane un avance competitivo ponga un estndar de la industria.

La identificacin de objetivos es tambin un componente importante, ya que permite al analista descubrir lo que est tratando de hacer el negocio. Luego ser capaz de ver si algn aspecto de la aplicacin de sistemas de informacin pueden ayudar para que el negocio alcance sus objetivos atacando problemas especficos u oportunidades.

Las

actividades de esta fase consisten en entrevistas a los

administradores, encargados y usuarios, sumarizacin del conocimiento obtenido, estimacin del alcance del proyecto y documentacin de los resultados. La salida de esta fase es un estudio de factibilidad que contiene una definicin del problema y la sumarizacin de los objetivos. Determinacin de los requerimientos de informacin En esta fase el analista determina los requerimientos de informacin que necesitan los usuarios para realizar su trabajo. Esta fase sirve para

formar la imagen que el analista tiene de la organizacin y sus objetivos.

El analista necesita saber los detalles de las funciones actuales del sistema: quien (las personas que estn involucradas), que (la actividad del negocio), donde (el ambiente donde se lleva a cabo el trabajo), cuando (en qu momento) y como (de qu manera se desarrollan los procedimientos actuales) del negocio bajo estudio.

Al trmino de esta fase, el analista debe comprender el porqu de las funciones del negocio y tener informacin completa sobre las personas, objetivos, datos y procedimientos involucrados.

Anlisis de las necesidades del sistema

22

En esta fase se

realiza el anlisis de las necesidades del sistema

empleando herramientas y tcnicas que ayudan al analista para la determinacin de los requerimientos.

Una herramienta de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones del negocio en forma grafica.

En este punto, el analista prepara una propuesta del sistema que sumariza lo que ha sido encontrado, proporciona anlisis de las alternativas y hace recomendaciones sobre lo que debe ser hecho.

Diseo del sistema recomendado En esta fase el analista usa la informacin recolectada anteriormente para realizar el diseo lgico del sistema de informacin. Se disea procedimientos preciosos para la captura de los datos, a fin de que los datos que van a entrar al sistema de informacin sean correctos.

Parte del diseo lgico del sistema de informacin es disear la interfaz de usuario. La interfaz conecta al usuario con el sistema y es, por lo tanto, extremadamente importante. La fase de diseo tambin incluye el diseo de archivos o base de datos que guardaran la mayor parte de los datos necesario para los tomadores de decisiones de la organizacin.

2.2.6. Lenguaje Unificado de Modelado (UML)

a.

Definicin Segn Booch, Rumbaugh y Jacobson (1997, 1999), UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a

23

objetos. Se ha convertido en el estndar de facto de la industria de desarrollo de software.

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. Mientras que ha habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin. 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.

En UML 2.0 hay 13 tipos de diagramas: Diagramas De Estructura Enfatizan en los elementos que deben existir en el sistema modelado: Diagrama de Clases Diagrama de Componentes Diagrama de Objetos Diagrama de Estructura compuesta (UML 2.0) Diagrama de Despliegue Diagrama de Paquetes

Diagramas De Comportamiento

Enfatizan en lo que debe suceder en el sistema modelado: Diagrama de Actividades Diagrama de Casos de Uso Diagrama de Estados

Diagramas De Interaccin

24

Es un Subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: Diagrama de Secuencia Diagrama de Comunicacin Diagrama de Tiempos (UML 2.0) Diagrama de Vista de Interaccin (UML 2.0)

Grfico N 11. Vistas de un Diagrama UML

UML combina notaciones provenientes desde: Modelado orientado a objetos. Modelado de datos. Modelado de componente. Modelado de flujo de trabajo (Workflows)

El mtodo de UML recomienda utilizar los procesos que otras metodologas tienen definidos. Para Liza A C. (2001). UML puede describir cualquier tipo de sistema en trminos de diagramas orientados a objetos. Entre los diferentes tipos tenemos sistemas de informacin, sistemas de tiempo real, sistemas

25

embebidos, sistemas distribuidos, software de sistemas, sistemas de negocios, etc. b. Diagramas UML DIAGRAMA DE CASOS DE USO Muestra un conjunto de casos de uso y actores (un tipo especial de clases) con sus relaciones. Los diagramas da casos de uso cubren la vista de casos de uso esttica de un sistema. Son importantes en el modelado y organizaron del comportamiento de un sistema.

Las relaciones entre casos de uso y actores pueden ser las siguientes: Un actor se comunica con un caso de uso. Un caso de uso extiende otro caso de uso. Un caso de uso usa otro caso de uso. En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas. Sus relaciones son: Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso. Extends: Una relacin de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A. Generalization: Es la tpica relacin de herencia. Actores: se representan por un mueco. Sus relaciones son: Communicates: Comunica un actor con un caso de uso, o con otro actor. Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.

26

DIAGRAMA DE CLASES Son diagramas de estructura esttica que muestran las clases del sistema y sus interrelacione (incluyendo herencia, agregacin, asociacin, etc.). Los diagramas de clases que incluyen clases activas cubre la vista de procesos estticas de un sistema.

Una clase est representada por un rectngulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los mtodos.

Cada clase debe tener un nombre nico, que las diferencie de las otras. Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo, e incluso su valor por defecto.

Grfico N 12. Diagrama de clase

DIAGRAMA DE OBJETOS Muestra un conjunto de objetos y sus relaciones. Los diagramas de objetos representan instantneas de instancias de los diagramas de clases. Estos diagramas cubren la vista de diseo esttica o la vista de procesos esttica de un sistema como lo hacen los diagramas de clases, pero la perspectiva de casos reales o prototipos.

27

Forma parte de la vista esttica del sistema. En este diagrama se modelan las instancias de las clases del diagrama de clases. Muestra a los objetos y sus relaciones, pero en un momento concreto del sistema. Estos diagramas contienen objetos y enlaces. En los diagramas de objetos tambin se pueden incorporar clases, para mostrar la clase de la que es un objeto representado.

Grfico N 13. Diagrama de objetos

DIAGRAMA DE SECUENCIA Muestra una interaccin, que consta de un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos. Los diagramas de interaccin cubren la vista dinmica de un sistema.

El diagrama de secuencia forma parte del modelado dinmico del sistema. Se modelan las llamadas entre clases desde un punto concreto del sistema. Es til para observar la vida de los objetos en sistema, identificar llamadas a realizar o posibles errores del modelado esttico, que imposibiliten el flujo de informacin o de llamadas entre los componentes del sistema.

28

Objetos o Actores Son entidades que participan en la interaccin para lograr una funcionalidad, estas envan o recibe mensajes Lnea de Vida de Un Objeto Indica la vida de un objeto durante la interaccin y se representa mediante una lnea discontinua

Activacin o Foco Control Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando una operacin.

Mensajes Son las invocaciones que enva un objeto a otro para que realice una tarea

Grfico N 14. Elementos del Diagrama de Secuencia

DIAGRAMA DE COLABORACIN Es un diagrama de interaccin, que resalta la ordenacin temporal de los mensajes; un diagrama de colaboracin en un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensajes.

Es un diagrama de clases, excepto que posee enlaces que representan operaciones entre objetos as como el sentido de las mismas. Todo diagrama de colaboraciones debe tener flujo de eventos.

Un diagrama de Colaboracin est compuesto por: objetos, enlaces y flujo de mensajes.

29

FLUJO DEL MENSAJE

OBJETO
ENLACE

OBJETO

Grfico N 15. Elementos del Diagrama de Colaboracin

DIAGRAMA DE ESTADOS Muestra una maquina de estados, que consta de estados, transiciones, eventos y actividades, los diagramas de estado cubren la vista dinmica de un sistema, son especialmente importante en el modelado del comportamiento de una interfaz, una clase o una colaboraron y resaltan el comportamiento dirigido por eventos de un objeto, lo cual es especialmente til en el modelado de sistemas reactivos.

Los elementos de un diagrama de estado son:

Estado: Idntica el periodo de tiempo del objeto (No Instantneo) en el cual el objeto est esperando alguna condicin, operacin u evento, tiene cierto estado caracterstico o puede recibir cierto tipo de estimulo.

Evento: Es una ocurrencia que puede causar la transicin del objeto de un estado otro.

Transicin: es una relacin entre 2 estados que indica que un objeto en un primer estado puede entrar a un segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre, se representa como una lnea slida entre dos estados.

DIAGRAMA DE ACTIVIDADES Caso especial de diagramas de estado en el cual casi todos estados son estados en accin (identifican una accin que se ejecuta estar en el).

30

La interpretacin de un diagrama de actividades depende de la perspectiva considerada: en un diagrama conceptual, la actividad es alguna tarea que debe ser realizada en un diagrama de especificacin o de implementacin, la actividad es un mtodo de una clase. Generalmente se suelen utilizar para modelar los pasos de un algoritmo.

Muestra el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la vista dinmica de un sistema. Son especialmente importantes al modelar el funcionamiento de un sistema y resaltan el flujo de control entre objetos.

Muestra las operaciones que se realizan para conseguir un objeto. Se utilizan para dar detalles a un caso de uso, modelando los flujos de trabajo u operaciones

Un diagrama de estados est compuesto por: Estado de actividad o simplemente actividad Estados de accin o simplemente accin. Transiciones.

DIAGRAMA DE COMPONENTES Muestra la organizacin y las dependencias entre un conjunto de componentes. Los diagramas de componentes cubren la vista de implementacin esttica de un sistema. Se relacionan con los diagramas de clases en que un componente se corresponde, por lo comn, con una o ms clases, interfaces o colaboraciones.

Diagrama de Despliegue Muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos. Los diagramas de despliegue cubren la vista de despliegue esttica de una arquitectura. Se

31

relacionan con los diagramas de componentes en que un nodo incluye, por lo comn uno o ms componentes.

Se utilizan para modelar la vista esttica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

En el situaremos libreras, tablas archivos, ejecutables y documentos que formen parte del sistema.

Los diagramas expresan grficamente partes de un modelo

Grfico N 16. Partes de un modelo

c. Modelado del Negocio Es una tcnica para: Entender el comportamiento de las organizaciones. Modelar los procesos del negocio. Identificar las actividades que se realizan en cada proceso del negocio. Identificar los roles que participan en los procesos del negocio.

32

 Facilitar la realizacin de la documentacin asociada. Mejorar la comunicacin en un proyecto. Porque es necesario modelar el negocio: Los negocios automatizan, cada vez ms, sus procesos.

d. Objetivos del modelado del negocio Comprender la estructura y la dinmica de la organizacin para la que se desarrolla el proyecto. Comprender los problemas actuales de la organizacin e identificar los potenciales. Asegurar que los clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin. Obtener, de forma preliminar, los requerimientos del sistema que necesita la organizacin.

E. Modelo de Caso de Uso del Negocio En el anlisis de un sistema sirve para: 1. 2. 3. 4. 5. 6. 7. Identificar los actores del negocio (business actors). Generar lista de actores del negocio Identificar los trabajadores del negocio (business workers) Generar lista de trabajadores del nengocio Identificar los casos de uso del negocio (business use cases). Generar lista de casos de uso del negocio. Elaborar el diagrama de casos de uso del negocio

Estereotipos ms importantes en el Modelo del Negocio.

Segn Rational Rose 2003

Grfico N 17. Estereotipos en el modelo del negocio Rational

33

Actores del Negocio Un actor del negocio (business actor) representa un rol (alguien o algo) fuera del negocio y que interacta o se relaciona con l. Ejemplo: Cliente. Contribuyente. Gerente general.

Grfico N 18. Actores del negocio

Trabajadores del negocio Un trabajador del negocio (business worker) representa un rol (alguien o algo) dentro del negocio que realiza algn proceso o actividad propios del negocio. Ejemplo: Vendedor. Jefe de Almacn.

Vendedor

34

Grfico N 19. Trabajadores del negocio

2.2.7. Ingeniera de software Segn Pressman R. S. (1997) y Sommerville Ian (2002), el objetivo de la Ingeniera de Software es producir software que se entrega al cliente con la documentacin que describe como instalar y usar el sistema.

Para Pressman R. S. (1997) y Sommerville Ian (2002), la ingeniera de software es una disciplina que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema, hasta el mantenimiento de ste despus de que se utiliza. La ingeniera de software tiene las siguientes metodologas 1983 -> Anlisis Estructurado (DeMarco y Jackson) 1994 -> Orientacin a Objetos (Booch y Rumbaugh) 1999 -> UML Lenguaje de Modelado Unificado (Fowler y Scott 1997; Booch, Rumbaugh y Jacobson 1999)

Todos los mtodos se basan en la idea de modelos grficos de desarrollo de un sistema y en el uso de estos modelos como un sistema de especificacin o diseo. 2.2.8. PHP 5.0 Es un lenguaje de programacin embebido o empotrado, orientado al desarrollo de la programacin Web. Soporta programacin orientada a objetos, incrustacin e interpretacin de otros lenguajes de programacin, tales como Java, Applets de Java, etc.

2.2.9. MySQL Server A. Descripcin MySQL es un sistema de gestin de base de datos relacional, multihilo y multiusuario con ms de seis millones de instalaciones.

35

MySQL, desde enero de 2008 una subsidiaria de Sun MicroSystems y sta a su vez de Oracle Corporation desde abril de 2009, desarrolla MySQL como software libre en un esquema de licenciamiento dual.

Es un sistema de base de datos relacional (RDBMS) que se ejecuta como un servidor que proporciona acceso multiusuario a una serie de bases de datos.

Delgado Albert (1999) que es un Sistema Gestor de Base de Datos (SGBD) totalmente habilitado para Web, que proporciona una

compatibilidad fundamental con el lenguaje de marcado extensible (XML, Extensible Markup Lenguaje) y la capacidad para realizar consultas en Internet y por encima del servidor de seguridad.

MySQL es una de las bases de datos ms populares, desarrolladas bajo la filosofa de cdigo abierto. La desarrolla y mantiene la empresa MySql AB pero puede utilizarse gratuitamente y su cdigo fuente est disponible. Inicialmente, MySQL careca de elementos considerados esenciales en las bases de datos relacionales, tales como integridad referencial y transacciones. A pesar de ello, atrajo a los desarrolladores de pginas web con contenido dinmico, justamente por su simplicidad; aquellos elementos faltantes fueron llenados por la va de las aplicaciones que la utilizan.

Poco a poco los elementos faltantes en MySQL estn siendo incorporados tanto por desarrollos internos, como por

desarrolladores de Software Libre

Caractersticas Entre las caractersticas disponibles en las ltimas versiones se puede destacar las Siguientes:

36

 Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas igualmente. Disponibilidad en gran cantidad de plataformas y sistemas. Diferentes opciones de almacenamiento segn si se desea velocidad en las operaciones o el mayor nmero de operaciones disponibles. Transacciones y Claves forneas. Conectividad segura. Replicacin. Bsqueda e indexacin de campos de texto.

2.2.10. Rational Rose 2000 Enterprise Edition Herramienta de modelado creada por Rational Software para la fcil creacin y desarrollo de los modelos utilizados en el anlisis y diseo del sistema, permite crear paso a paso cada uno de los diagramas utilizados. Este software nos proporciona lo siguiente: Provee una buena estructura de los modelos. Provee un estilo que gua las convenciones y sugerencias de los nombres. Identifica un juego mnimo de diagramas a producir. Provee una base de reportes sofisticados. Generan partes del documento de arquitectura de software Relata las actividades que se desarrollan en los diagramas 2.3. ESTIMACIN DE COSTOS DE PROYECTOS DE

CONSTRUCCIN CIVIL

37

38

CAPTULO III PLANIFICACION DE LA INVESTIGACION 3.1. TIPO DE INVESTIGACIN Aplicada 3.2. DURACIN DE LA EJECUCIN DEL PROYECTO Un ao calendario. Fecha de inicio: 01/10/2012. Termino: 30/09/2013 3.3. RECURSOS DISPONIBLES Lo indicado en presupuesto 3.4. PRESUPUESTO PRECIO COSTO S/. S/. 249.0 1 10 5 5 3 5 1 50 1 1 1 1 3 85 50.0 10.0 5.0 5.0 3.0 15.0 24.90 2901 50 50 50 1 30 30 30 290.0 150.0 150.0 150.0 290.1 1750.0 Global Global 200 150 7.0 150.0 1400.0 150.0

PRODUCTO

DENOMINACION CANTIDAD

4.1.1. MATERIALES DE ESCRITORIO 1 Papel A4 2 Lapiceros 3 Lpiz 4 Borrador 5 Regla 6 corrector 7 Imprevisto Millar Unidad Unidad Unidad Unidad Unidad Global

HERRAMIENTAS DE INVESTIGACIN 1 USB 2 Computadora 3 Impresora 4 Imprevisto 4.1.4. OTROS GASTOS 1 Pasajes y viticos 2 Copias Unidad Unidad Unidad Global

39

3 Varios 4 Imprevistos TOTAL GENERAL

Global Global

1 1

200 400

200.0 175.0 6311.1

3.5.

FINANCIAMIENTO Todo el costo que implica el desarrollo de la presente investigacin se financiar con recursos propios de la investigadora.

3.6.

CRONOGRAMA Las actividades a desarrollar se dividen en: Revisin bibliogrfica, elaboracin del proyecto, ejecucin del proyecto, captacin de datos, procesamiento y anlisis, elaboracin del informe final y publicacin. La siguiente tabla muestra el cronograma en funcin de actividades y meses a realizar cada actividad.

ACTIVIDADES
O Revisin Bibliogrfica Bsqueda y adquisicin bibliografa Elaboracin del Proyecto Antecedentes y formulacin del problema Elaboracin del instrumento Presentacin del proyecto y sustentacin de

MESES / AO 2012-2013
N D E F M A M J J A S

Ejecucin del Proyecto Captacin de datos Aplicacin del instrumento de

40

recoleccin de la informacin Procesamiento y Anlisis Procesamiento de los datos Anlisis e interpretacin Discusin de los resultados Elaboracin del Informe Final Revisin General Resultados de los.

Preparacin del informe final Publicacin Presentacin y del informe final sustentacin

41

BIBLIOGRAFA

01

Randall Geoffrey (2003). Principios de Marketing. Segunda edicin, Thomson Editores Espaa.

02

Kotler Philip, Bloom Paul y Hayes Thomas (2004). El Marketing de Servicios Profesionales. Ediciones Paids Ibrica S.A.

03

Malhotra K. Naresh (1997). Investigacin de Mercados Un Enfoque Practico. Editorial Prentice-Hall Hispanoamericana.

04

Kotler Philip, Cmara Dionicio, Grande Idelfonso y Cruz Ignacio (2005). Direccin de Marketing. Edicin del Milenio Prentice Hall.

05

Fischer Laura y Espejo Jorge (2002). Mercadotecnia. Tercera Edicin. Editorial Mc Graw Hill Arbones, Eduardo (1991). Ingeniera de Sistemas. Marcombo, Espaa. Booch G. Rumbaugh J.. & Jacobson I. (1997). The UML Specification Document. Rational Software Corp

06 07

08

Booch G. Rumbaugh J.. & Jacobson I. (1999). El Lenguaje Unificado de Modelado. Addison Wesley Iberoamericana

09

Chandak Arnes (1999) Aprendiendo UML en 24 Horas. Jhon Wiley & Sons, Inc. Canada. Checkland, Peter (1993) Pensamiento de Sistemas. Prctica de Sistemas. Limusa, Mxico, 1 993.

10

11

Cordova Zamora Manuel (2001). Estadistica descriptiva e Inferencial. Editorial Moshera. S.R.L. Lima Per.

12

Craig Larman (2001). Applying UML and patterns: an introduction to object oriented analysis and design and unified the process. Second edition. Prentice Hall.

13

Fowler Martin (2004). UML Destilled. A Brief guide to the standard object modeling language. Tercera Edicin. Edison wesley

14

Grupo Eidos (2000). Diseo orientado a objetos con UML Versin 1.0.0 citado en www.LaLibreriaDigital.com

15

Grupo Eidos (2000). Diseo orientado a objetos con UML Versin 1.0.0

42

citado en www.LaLibreriaDigital.com. 16 Gustavo Aliaga y Miguel Durand (2004). Diagnstico de la situacin de salud en las comunidades alto andinas del departamento de ncash-Per. Revista Peruana de Epidemiologa Vol 12 No 1 17 Ivar, Jacobson; Booch, Grady & Rumbauch, James (2 000) El Proceso Unificado de Desarrollo de Software UML. Edit. Pearson Educacin S.A. 18 Kendall & Kendall (1999). Anlisis v Diseo de Sistemas.Tercera Edicin Prentice Hall Hispanoamerica S.A. 19 Liza Avila C (2001). Modelando con UML. Principios y Aplicaciones. Editorial Grupo Creadores. Trujillo Per 20 21 Sommerville Ian (2002). Ingeniera de Software, Addison Wesley, 6a edicin. Cesar Bustamante (2005). Desarrollo de Aplicaciones Web con PHP, MySQL y Apache

43

44