ASPECTOS METODOLGICOS..........................................................1 MARCO TEORICO..............................................................................28 CAPTURA DE REQUISITOS .............................................................30 ANLISIS............................................................................................41 DISEO...............................................................................................51 IMPLEMENTACIN ...........................................................................

72

Capitulo 1: Aspectos Metodolgicos

ASPECTOS METODOLGICOS
1.1. ANTECEDENTES
En este aspecto entrara en juego la capacidad del investigador, aqu se condensar todo lo relacionado a lo que se ha escrito e investigado sobre el objeto de la investigacin. Hay que diferenciar entre los tericos consultados y los antecedentes del problema, ya que a veces confundimos los dos aspectos. El primero -los tericos- son los planteamientos escritos sobre el tema que se ha de tratar en una investigacin, mientras que los antecedentes del problema, son los estudios que se han hecho sobre el objeto de dicha investigacin. Es oportuno recordar que la cita de los antecedentes se puede elaborar con base en fechas y/o cronogramas de otros proyectos realizados, pero es indispensable citar la fuente de la consulta.

1.1.1. Antecedentes de la Empresa Expresa como hoy se encuentra el problema de estudio, como se origino y su evolucin 1.1.2. Antecedentes del Objeto de Estudio
Estudios, investigaciones y trabajos anteriores.

1.2. El planteamiento del problema.

El planteamiento del problema es una parte fundamental del proceso de investigacin pues determina y encausa todas las acciones que se seguirn posteriormente.

Eleccin y delimitacin del tema.

Eleccin del Tema: Para la eleccin de un tema es necesario que el estudioso est familiarizado con su tema y desarrolle un verdadero inters por l para que pueda realizar con entusiasmo el arduo trabajo que supone toda investigacin. Adems el investigador debe informarse sobre temas afines. Que las fuentes que se requieren para la investigacin sean accesibles, es decir al alcance fsico, econmico, cultural, etc. Identificar y concretar un problema que merezca ser investigado. Al determinar el problema tomar en cuenta consideracin aspectos prcticos: tiempo, personas disponibles para colaborar, accesibilidad de muestra, recursos econmicos, entre otros.

Capitulo 1: Aspectos Metodolgicos

Delimitacin del Tema: Delimitar el tema es ver la viabilidad para su desarrollo. Delimitar el tema quiere decir poner lmite a la investigacin y especificar el alcance de esos lmites. Es preferible sealar, de acuerdo a las propias inclinaciones y preferencias, un tema reducido en extensin. Una limitante es la capacidad del investigador; sta slo se desarrolla con la experiencia obtenida en la elaboracin del trabajo, as que al inicio es preferible que se proponga metas sencillas. Las dificultades que se presenten en la adquisicin o en la interpretacin del material informativo, tambin limitan los avances de la investigacin. Una de las fallas ms comunes en la investigacin consiste en la ausencia de delimitacin del tema; el 80% de las investigaciones fracasan por carecer de delimitacin del tema, es decir, por ambicin del tema. Otro obstculo para la profundidad de la investigacin es el tiempo disponible para su realizacin; una investigacin hecha en seis meses no tiene los mismos alcances que otra que se le ha dedicado 2 aos.

Objeto de estudio
Un objeto de estudio es aquello que se quiere conocer, y quien define el objeto de estudio es el sujeto.Un objeto de estudio no es ms que aquello por estudiar o por conocer Es consecuencia del planteamiento del problema, delimita aquella parte de la realidad que interesa estudiar. La precisin del investigador, en este sentido, se demuestra en la redaccin minuciosa y cuidada con la cual formula el objeto de estudio. Qu parte de esa realidad deseo investigar?

Definicin del problema.

El problema es todo aquello que se convierte en objeto de reflexin y sobre el cual se percibe la necesidad de estudiarlo para darle una solucin. Definir un problema de investigacin consiste en presentar, mostrar y exponer las caractersticas o rasgos del tema, situacin o aspecto de inters que va a estudiarse; describir el estado actual de la situacin.

Capitulo 1: Aspectos Metodolgicos

Para identificar adecuadamente la composicin de la problemtica en un trabajo de investigacin es necesario tomar en cuenta dos aspectos fundamentales; describir la situacin actual y compararlo o contrastarlo con una situacin ideal (AVENDAO Y LUCANA, 2005). Pasos para identificar y definir el problema: 1. Hacer una breve descripcin del problema principal (Elaborar un rbol de problemas). 2. Definir las causas y efectos que generan el problema principal (realizar un anlisis del rbol de problemas). 3. Definir el problema principal. 4. Definir la situacin deseable (opcional). 5. Redactar la pregunta principal (opcional).

rbol de problemas El rbol de problemas es una herramienta que permite analizar un problema a partir de tres criterios bsicos: Identificacin del problema principal, formulacin de las causas y definicin de las consecuencias (ver el cuadro).

Efecto 1

Efecto 1

Efecto 1

Problema Principal

Causa 1

Causa 2

Causa 3

Causa 4

Ejemplos para identificar y definir el problema:

Sub-causa 1 Sub-causa 1 Subcausa 2 Sub-causa 1 Sub-causa 1

Capitulo 1: Aspectos Metodolgicos

Paso 1

EFECTOS EFECTOS

PROBLEMA PROBLEMA PPRINCIPAL PPRINCIPAL

CAUSAS CAUSAS

Capitulo 1: Aspectos Metodolgicos Definicin del Situacin Problemtica problema

Paso 2 El recepcionistas no tiene organizados en un orden sucesivo, los servicios de mantenimiento que los tcnico deben realizar, esto ocasiona prdida de tiempo al recepcionista en buscar los documentos para entregar al tcnico. Cuando el cliente solicita su equipo reparado, el recepcionista no cuenta con un registro eficiente de los equipos con el prdida de tiempo y mantenimiento realizado, esto genera molestias en el cliente. No se cuenta con un reporte de los servicios de

mantenimientos de equipos realizados mensualmente por los tcnicos, esto causa que no se tenga la informacin precisa para la toma de decisiones. De acuerdo al anlisis de los problemas que surgieron se define el problema principal: Paso 3 Carencia de un registro eficiente en el control y seguimiento de la informacin en el proceso de las actividades de recepcin y mantenimiento de equipos. Situacin Deseable Paso 4 Eficiente registro en el control y seguimiento de la informacin en el proceso de las actividades de recepcin y mantenimiento de equipo.

Capitulo 1: Aspectos Metodolgicos

P aso 1

EFECTOS EFECTOS

PROBLEMA PROBLEMA PPRINCIPAL PPRINCIPAL

CAUSAS CAUSAS

Capitulo 1: Aspectos Metodolgicos Definicin del Situacin Problemtica problema

Paso 2 En base a estudios realizados de la informacin que se maneja y genera en almacn de la Clnica San Damian, se identifican los siguientes problemas. La actualizacin peridica de los registros de medicamentos es manual y deficiente, esto ocasiona que la se emplee demasiado tiempo en la busqueda. El registro de compra de medicamentos es de forma manual, ocasioando un control dificultoso de fechas de vencimientos. La elaboracin de informes por sucursales de existencia de abastecimiento de los medicamentos no se proporciona a tiempo, esto ocasiona que La direccin no cuenta con informacin oportuna para una buena toma de decisiones. De acuerdo al anlisis de los problemas que surgieron se define el problema principal: Paso 3 Debido al proceso manual de informacin de los frmacos, recolectados de cada uno de las sucursales, existe mucha retardacin en la elaboracin de informes y reportes, ocasionando que la asignacin, control y supervisin de los frmacos por parte de Almacenes no sea adecuada. Situacin deseable Paso 4 Optimizar el tiempo en la elaboracin de informenes y reportes en cada unas de las sucursales, para que de esta manera la asignacin, control y supervisin de los frmacos por parte de Almacenes sea adecuada.

Capitulo 1: Aspectos Metodolgicos

Paso 1

EFECTOS EFECTOS

PROBLEMA PROBLEMA PPRINCIPAL PPRINCIPAL

CAUSAS CAUSAS

Capitulo 1: Aspectos Metodolgicos Definicin del Situacin Problemtica problema

Paso 2 Escases del material para construccin por no conocer con exactitud el stock en inventario, ocasiona la demora en la entrega de proyectos. Registros inadecuados del movimiento en almacn la consecuencia es la prdida de informacin del movimiento en almacn. Registro de material de construccin de forma manual esto genera demora en bsqueda de informacin confiable y precisa del material.

De acuerdo al anlisis de los problemas que surgieron se define el problema principal: Paso 3 Gestin deficiente de inventario de materiales, herramientas y equipos de construccin debidos a demoras en la entrega de proyectos por no prevenir la escasez de material de construccin, perdida de informacin del movimiento en almacn, mala gestin del registro de prstamos y devolucin de herramientas o equipos de construccin. Situacin deseable Paso 4 Contar con una herramienta que permita el manejo adecuado de la informacin para la gestin de inventario de material de construccin para la empresa contructura, que realice reportes como el nivel de stock de material por almacn.

1.3. Propuesta
Describir en uno o dos parrafos lo que se propono desarrollar Ejemplo:

Capitulo 1: Aspectos Metodolgicos

La propuesta del presente proyecto de grado es brindar un ptimo control de los prstamos de las carpetas del archivo, adems incorporar un agente que pueda informar al usuario de algunas tareas pendientes; tambin se lleg a descentralizar de gran manera el trabajo realizado por el Archivo de la Unidad de Catastro, efectuando el desarrollo mediante la aplicacin de mtodos y utilizacin de tecnologas para su automatizacin.

La propuesta que ofrecera este proyecto sera automatizar sus procesos rutinarios, minimizar y optimizar tiempos de ejecucion generando informacion que coadyuve a la facil y correcta toma de decisiones de la Clinica. El usuario contara con una herramienta de automatizacion a la medida de sus requerimientos, para un ptimo control de las operaciones en el area operativa. Informes y reportes que emite el sistema con informacion acertada y oportuna que ayude al director en la toma de decisiones. El director contara con toda la informacion acerca del movimiento de los farmacos.

10

Capitulo 1: Aspectos Metodolgicos

El modulo de inventario facilitara las tareas de los empleados, permitiendo realizar un control adecuado de los medicamentos: caducidad, forma de almacenaje, medicamentos sin movimiento, calculo automatico del stock, evitando la situacion de tener falta de farmacos. El modulo de seguridad realizara el control y registro de cualquier acceso de usuarios al sistema, ademas de proveer codigo s de acceso y mantenimiento de los mismos, esta informacion es muy valiosa para la clinica para futuras auditorias. En este entendido se muestra a traves de la metodologia RUP y el lenguaje UML el diseno del sistema de control y seguimiento de inventario de farmacos.

1.4. Objetivos de la investigacin.

Los objetivos son las metas a las que se quiere llegar a travs de la investigacin. Sirven para indicar los alcances del trabajo, orientar la ruta del proyecto y evaluar los resultados obtenidos. En trminos generales los objetivos deben responder a la interrogante: Qu es lo que se desea conocer?, es decir que en la formulacin, debe quedar claramente establecido cul es el alcance de la investigacin y cuales son sus metas.

El El objetivo objetivo es es la la formulacin formulacin de de la la finalidad finalidad deseada deseada,, la la pretensin pretensin de de obtener obtener algo, algo, a a donde donde se se quiere quiere llegar, llegar, gua gua o o camino camino para para encontrar, encontrar, o o llegar llegar a a una una meta meta (AVENDAO (AVENDAO Y Y LUCANA LUCANA 2005). 2005).

Los objetivos estn clasificados por generales y especficos:

Objetivo General
Es la idea central del trabajo de investigacin, el cual genera los objetivos especficos (AVENDAO Y LUCANA, 2005).

Objetivos Especficos
Construyen las tareas centrales y son la columna vertebral del trabajo de investigacin y la sumatoria de ellos genera el objetivo general (AVENDAO Y LUCANA, 2005). Los objetivos se describen por orden de importancia y por un orden lgico en las distintas fases de la investigacin. Los objetivos especficos establecen el detalle de lo que se deber investigar haciendo referencia a las variables especificas a estudiar y las actividades que se desarrollaran para lograrlo.

11

Capitulo 1: Aspectos Metodolgicos

Es recomendable que cada objetivo especfico tenga correspondencia con un capitulo del proyecto (WWW-01).

Criterios considerados relevantes para plantear los objetivos:

12

Capitulo 1: Aspectos Metodolgicos

Ejemplo de Objetivos

Objetivo General Desarrollar un sistema de informacin de seguimiento y control del mantenimiento y reparacin de equipos para la empresa FIC- FRIO utilizando las metodologa del Proceso Unificado. Objetivos Especficos Definir el anlisis de negocio hasta el punto necesario para justificar la puesta en marcha del proyecto. Obtener la arquitectura base del sistema. Clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base.

Objetivo General Desarrollar un sistema de informacin de seguimiento y control del mantenimiento y reparacin de equipos para la empresa FIC- FRIO utilizando las metodologa del Proceso Unificado. Objetivos Especficos Recopilar y describir conceptos e informacin acerca del entorno del problema. Elaborar los modelos anlisis y diseo de la herramienta. Incorporar nuevos modelos de diseo y realizar la implementacin de la herramienta.

13

Capitulo 1: Aspectos Metodolgicos

Objetivo General Reducir la retardacin en la elaboracin de informes y reportes desarrollando un sistema de control y seguimiento de inventarios para la Clnica San Damian, que le ayude a mejorar su proceso de negocios. Objetivos Especficos Realizar una investigacin preliminar para el desarrollo del sistema de informacin. Disear un modelo de inventarios para el control de entradas y salidas de los frmacos. Controlar, buscar y registrar todos los movimientos de inventarios. Realizar un listado detallado que contenga informacin de todas las caractersticas de los frmacos.

14

Capitulo 1: Aspectos Metodolgicos

Objetivo General Solucionar las dificultades que ocasiona a las autoridades de la Escuela 21 de Mayo el control de sus procesos de administracin de los registros manuales, desarrollando un sistema informtico. Objetivos Especficos Facilitar al personal de la Escuela el proceso de registros de matriculacin, notas y asistencia del personal docente. Permitir un manejo simple del control de asistencia y otros datos de los docentes de la Escuela. Permitir la obtencin inmediata de reportes de matriculas, notas, asistencia, etc. Proporcionar a travs del sistema el acceso a una informacin ordenada y actualizada del proceso administrativo de la institucin.

Objetivo General Automatizar el control de algunas de las actividades que realizan en la Unidad de Recursos Humanos, para mejorar y agilizar el seguimiento de informacin. Objetivos Especficos Registrar y gestionar la informacin del personal en la Unidad de Recursos Humanos Brindar una herramienta para alcanzar mayor eficiencia administrativa acorde con las necesidades de la institucin. Elaborar e imprimir reportes y cuadros estadsticos de acuerdo a requerimientos del usuario en el momento preciso.

15

Capitulo 1: Aspectos Metodolgicos

Objetivo general Desarrollar un sistema informtico para la administracin y control de expedientes del CRINA que permita la disponibilidad y manipulacin de la informacin en forma rpida y correcta. Objetivos especficos Realizar una investigacin preliminar para el desarrollo del sistema informtico. Realizar un anlisis de requerimientos para el diseo y construccin del sistema informtico. Disear un sistema informtico para la administracin y control de expedientes del CRINA. Programar el sistema informtico para la administracin y control de expedientes del CRINA. Disear y ejecutar las pruebas pertinentes para comprobar el correcto funcionamiento del sistema para la administracin y control de expedientes del CRINA.

16

Capitulo 1: Aspectos Metodolgicos

1.5. Justificacin o importancia del tema.

Motivaciones que llevan al investigador a desarrollar el proyecto. Para ello se debe responder a la pregunta de: Por qu se investiga? Es decir hay que plantear claramente los beneficios que se obtendran, la utilidad del estudio, etc. Se explica la trascendencia del proyecto que se propone, es decir, por qu es relevante el estudio. Se indica porque es conveniente llevar a cabo el proyecto, exponiendo sus razones. Para elaborar la justificacin es necesario responder a las siguientes cuestionan ts: Qu nuevos conocimientos aporta la solucin del problema en estudio? Qu grupos se beneficiarn con el proyecto? Porque es necesario el desarrollo de la investigacin o el proyecto de grado? Qu razones permiten suponer que el producto de la investigacin o el proyecto de grado ha de resultar til, conveniente o necesario? Algunos tipos de justificacin, segn (WWW-01): Econmica. El desarrollo del proyecto de grado o de la Tesis de Grado, De qu manera traer algn beneficio econmico a la organizacin, institucin u otros? Traer tal vez algn ahorro econmico?, Se utilizarn de mejor manera los recursos econmicos disponibles? Debe mencionarse el como se alcanzara un beneficio econmico. Tcnica. Menciona la aplicacin o utilizacin del desarrollo tecnolgico con que se cuenta en el sitio u organizacin donde se desarrollara el proyecto de grado o Tesis de Grado. Si es necesario adquirir nueva tecnologa, se debe justificar con un porque. En otras palabras Se cuentan con los medios tecnolgicos necesarios?, Son realmente necesarios? , Qu beneficios traern consigo? Social. Justifica el beneficio que la sociedad o el medio social en que se desarrollara el trabajo de investigacin o proyecto de grado alcanzara.

OBSERVACIN. EL INVESTIGADOR NO ESTA OBLIGADO EN ELABORAR O REDACTAR TODAS LAS JUSTIFICACIONES MENCIONADAS ANTERIORMENTE, DEBERA ANALIZAR QUE TIPO DE JUSTIFICACIN ES LA17 QUE RESPALDA LA REALIZACIN DE SU PROYECTO O TESIS DE GRADO. SERAN SUFICIENTE UNA O DOS PERO QUE DEMUESTREN LA IMPLICITA NECESIDAD DE LLEVAR ADELANTE SU TRABAJO. NO ES IMPERIOSO INVENTAR JUSTIFICACIONES CUANDO NO LAS EXISTEN.

Capitulo 1: Aspectos Metodolgicos

Ejemplos:

Justificacin Con el sistema de informacin se obtendr un mejor control de forma gil, oportuna y eficiente

mejorando el seguimiento de las actividades que se realizan, por ejemplo desde la solicitud de servicio, hasta fechas de entregas de los equipos, pagos que todava deben cancelarse, as de esta manera el sistema ayudara a la empresa a obtener una informacin clara y precisa.

Justificacin Econmica Un sistema de control y seguimiento de inventario de frmacos, permitir que la clnica optimice sus principales tareas, mejorando el tiempo de servicio por el sistema que ser implementado en red, permitiendo al personal de la clnica realizar consultas desde su oficina. Justificacin Social La facilidad de consulta demandada de los frmacos beneficiara tanto al personal operativo como al

18

Capitulo 1: Aspectos Metodolgicos

directivo, el mismo permitir bsquedas de informacin rpida y oportuna al momento que se la requiera. El sistema que controla el inventario de frmacos proporciona informacin rpida y oportuna a la direccin y particularmente a Almacn. Justificacin Tcnica El Proyecto a desarrollar, se realiza por la necesidad que tiene la Clnica, ya que no cuenta con un buen control de los frmacos de almacn, optimizando as los servicios que presta el mismo. El sistema realiza un control de inventarios, utilizando para la metodologa Orientada a Objetos y el mtodo RUP.

Justificacin El proyecto que se llevara a cabo ser de gran beneficio no solamente para el CRINA, sino para los pacientes en general; ya que con ello se har eficiente la manipulacin de los expedientes y la informacin ser mucho ms confiable1. Con la operacin del Sistema Informtico para la Administracin de los expedientes se pretende obtener los siguientes beneficios: Mayor confiabilidad en el registro de datos. Tiempos ptimos para la captura de datos y generacin de reportes. Manejo eficiente de la informacin del paciente. Un registro ms eficiente de nuevos pacientes que ingresan a la institucin. Informacin actualizada y oportuna de los expedientes en las diferentes reas donde son solicitados.

19

Capitulo 1: Aspectos Metodolgicos

Un panorama ms gil de las diferentes actividades realizadas por cada rea de terapias.

1.6. Delimitacin
Consiste en identificar con claridad y precisin los lmites, por lo general se tiene encuenta los siguientes factores: Determinar el mbito de la aplicacin de la investigacin, tanto en espacio y tiempo, y sealar las limitaciones u obstculos que presenta la investigacin. Es pertinente dar al problema una formulacin lgica y adecuada, precisar sus lmites, su alcance, para ello es necesario tener en cuenta los siguientes factores: Lugar o espacio donde se llevar a cabo la investigacin. Tiempo, si el asignado da la cobertura para el estudio o si se debe flexibilizar en caso de imprevistos. Temtico, establece los lmites temticos o alcance temtico de la investigacin: El Objeto de estudio y el campo de accin. Ejemplos:

20

Capitulo 1: Aspectos Metodolgicos

Temtica El alcance de trabajo del presente proyecto se limita al desarrollo de un sistema de informacin para la gestin de inventario, que primordialmente: Gestione el registro de proveedores y proyectos: se registrarn los datos generales del proveedor y proyecto segn corresponda. Gestione el registro de tems de construccin: se realizara una clasificacin del tipo de tem, se registrarn los datos generales del material, herramienta o equipo de construccin. Gestione el movimiento en almacn, segn su tipo: ingreso, egreso, traspaso, prstamo o devolucin. Gestione la solicitud de pedido de reaprovisionamiento por almacn, manteniendo informacin rpida y actualizada. Que genere reportes como el nivel de stock por cada tem, para prevenir la escasez de material y realizar la construccin a un ritmo regular. Que genere reportes como salida de material para un determinado proyecto, prestamos de herramientas con demora en la devolucin y otros. Espacial. El proyecto se desarrollara en la ciudad de santa cruz para la empresa XL. Temporal. El presente proyecto se realizara entre los meses de junio y noviembre del ao 2012.

21

Capitulo 1: Aspectos Metodolgicos

1.7. DISEO METODOLOGICO

1.7.1. Tipo de Investigacin
La Investigacin puede ser exploratoria, descriptiva, explicativa, histrica, experimental u otra que el investigador estime conveniente para el tipo de estudio que pretende realizar. Considerando los niveles en los cuales se enmarcan los tipos de investigacin, los trabajos o proyectos de grado realizados en pregrado se clasifican en un nivel aplicado. De acuerdo al nivel de conocimiento un proyecto puede ser: EXPLORATORIO: son aquellos que se efectan cuando el objetivo es examinar un tema o problema, poco estudiado o que no ha sido abordado antes. DESCRIPTIVO: Buscan especificar las propiedades importantes de personas, grupos,

comunidades o cualquier otro fenmeno que sea sometido a anlisis. Identifica caractersticas de investigacin, sealan forma de conducta, establece comportamientos concretos y descubre y comprueban asociaciones entre variables. EXPLICATIVA: estn dirigidas a responder a las causas de los eventos fsicos o sociales. Su inters se centra en explicar el por qu ocurre un fenmeno y en que condiciones se da este. Considerando las bases con las cuales se soporta el proyecto para su desarrollo, presentar dos situaciones. DOCUMENTAL: Es cuando el proyecto se soporta en documentos existentes (referencias se pueden

bibliogrficas como: leyes, textos, referencias de Internet, revistas especializadas, ponencias, trabajos de grado, publicaciones y acuerdos entre otros) Ejemplos

22

Capitulo 1: Aspectos Metodolgicos

Tipo de Investigacin: Para el desarrollo del proyecto se utilizarn dos tipos de investigacin: la investigacin histrica, que se utilizar para recaudar informacin de experiencias o acontecimientos pasados y la presentes. investigacin descriptiva, que se utilizar para recaudar informacin de hechos

Tipo de Investigacin: El tipo de investigacin es exploratorio y luego descriptivo

23

Capitulo 1: Aspectos Metodolgicos

Tipo de Investigacin: Descriptivo, la cual nos permite definir las variables que se manifiestan en la formulacin del problema y especificar e identificar las propiedades importantes que sern sometidas a anlisis y medicin con mayor precisin posible, esto obliga a predefinir que se a medir, conque y a quienes debe medirse de acuerdo a sus atributos tal y como ocurren en la realidad.

1.7.2. Metodologa
Una metodologa es el conjunto de mtodos por los cuales se regir una investigacin cientfica. Una metodologa es aquella gua, que se sigue a fin realizar las acciones propias de una investigacin. En trminos ms sencillos se trata de la gua que nos va indicando qu hacer y cmo actuar cuando se quiere obtener algn tipo de investigacin.

Ejemplo:

24

Capitulo 1: Aspectos Metodolgicos

Para el desarrollo del presente proyecto se seguir los pasos que plantea el ciclo de vida del Proceso Unificado de Desarrollo de software (PUD) , por considerarse una metodologa de desarrollo evolutiva, que se caracteriza por su naturaleza iterativa e incremental, con sus cuatro etapas: Inicio, Elaboracin, Construccin y transicin.

1.8. PLANIFICACIN
1.8.1. Cronograma de Actividades
Es de vital importancia hacer un cronograma para estimar el tiempo que tomar realizar cada una de las actividades necesarias para la elaboracin del proyecto. El fijar de antemano una agenda de trabajo ayuda al autor asumir un compromiso consigo mismo. Para elaborar el cronograma de actividades se propone el diagrama de GANTT. Ejemplo1:

25

Capitulo 1: Aspectos Metodolgicos

Ejemplo 2

Ejemplo3

26

Capitulo 1: Aspectos Metodolgicos 1.8.2. Recursos Ejemplo: `

Los recursos o herramientas que se utilizaran en el desarrollo e implementacin del proyecto harn uso de los siguientes elementos tanto del software como hardware;

Hardware
Para realizar la implementacin y prueba se recomienda las siguientes caractersticas mnimas de equipo:

Pentium IV - 3.8 Ghz Memoria de 1 GB Disco Duro de 80 GB Lector de DVD Impresora

Software Sistema Operativo Microsoft Windows XP Profesional Visual Basic. Net 2005 SQL Server 2000 Microsoft Project 2003 MindManager X5

27

Capitulo 2: Marco Terico

MARCO TEORICO

Cmo se elabora el MARCO TERICO de investigacin?

El marco terico no es otra cosa que la abstraccin de las propiedades ms fundamentales del objeto de estudio y de sus interrelaciones. Basndose en esta composicin, el investigador est en condiciones de efectuar la composicin del marco terico y adems de plantear su hiptesis. El marco terico conserva entre sus funciones principales: Prevenir errores que se han cometido en otras investigaciones, ampliar la perspectiva del estudio, Delimitar el rea de la investigacin, Establecer los antecedentes del problema, Suministrar un punto de referencia para interpretar los resultados de la investigacin.

28

Capitulo 2: Marco Terico

Al construir el marco terico, debemos concentrarnos en el problema de la investigacin y no divagar, es recomendable no saltar de una idea a otra, toda la informacin debe estar relacionada. Ejemplo de marco teorico: METODOLOGA PARA EL DESARROLLO DEL SOFTWARE Proceso Unificado de Desarrollo de Software Lenguaje Unificado de Modelado ARQUITECTURA DEL SOFTWARE HERRAMIENTAS DE DESARROLLO Lenguaje de Programacin Gestor de Base de Datos

29

Capitulo 3: Captura de Requisitos

CAPTURA DE REQUISITOS
1.9. MODELO DE NEGOCIO
Durante el proceso de modelado del negocio, se examina la estructura de la organizacin y se observan los roles en la compaa y como estos se relacionan. Un modelado del negocio es una tcnica para comprender los procesos de negocio de la organizacin. Para nuestro objeto de estudio del modelado del negocio utilizaremos diagramas de actividades. Un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema.

1.9.1. Identificacin de los Proceso del Negocio Proceso de Negocio Descripcin Realizacin de una venta Actividades que realiza el encargado de la venta, desde que un cliente solicita un producto hasta que se le entrega.

Realizacin compra

de

una Actividades que realiza el encargado de la compra, desde que un cliente solicita un producto al proveedor hasta que ingresa el producto al almacn.

1.9.2. Identificacin de los Usuarios que Realizan el Proceso Usuario Funcin Cliente Encargado de Venta Encargado de Caja Encargado de Almacn Encargado de comprar productos Encargado de verificar si existe el producto y registrar la venta Encargado de recibir el dinero de la venta Encargado de entregar el producto

30

Capitulo 3: Captura de Requisitos

1.9.3. Descripcin de los Procesos de Negocio 1.9.3.1. Proceso de Negocio: Realiazacin de una venta a) Diagrama de Actividad

Cliente

Encargado de Venta

Encargado de Caj a

Encaragado de Almacen

Solicita un producto

Verifica si exite el producto

Decide comprar si

si Emite el precio

Emite orden de pago

Recibe la orden de pago

Recibe la orden recibe el dinero no Emite la orden de prepar el producto Prepara el producto

no

Cancela el dinero

Recibe el producto

Entrega el producto

b) Regla de negocio
Las Reglas del Negocio o Conjunto de Reglas de Negocio Describe las polticas, normas, operaciones, definiciones y restricciones presentes en una organizacin y que son de vital importancia para alcanzar los objetivos de negocio. Una regla de negocio indica que est permitido condicionalmente. Ejemplo:

31

Capitulo 3: Captura de Requisitos

http://everac99.wordpress.com/2010/04/10/modelado-de-reglas-de-negocio-un-enfoque-practico/ http://msaffirio.wordpress.com/2011/08/20/reglas-de-negocio-business-rules/

1.10. MODELO DE DOMINIO

Describe los conceptos importantes del contexto como objetos del dominio relacionados entres s. El objetivo del modelado del dominio es comprender y describir las clases ms importantes dentro del contexto del sistema. Un modelo del dominio es una representacin de las clases conceptuales del mundo real. El modelo de dominio se representa fundamentalmente por diagramas de clases. Un diagrama de clases del modelo de dominio sirve para visualizar las relaciones entre las clases que involucran el sistema. Ejemplo de un modelo de dominio para un inventario de productos:

Marca 0..1 Cliente

1

Proveedor 1 suministrado 0..1 1..*

tiene

0..1 Producto 0..*

tiene 1..*

0..*

Venta

tiene 1 Categoria

Diagrama de clases del dominio

El modelo de dominio proporciona una perspectiva conceptual:

32

Capitulo 3: Captura de Requisitos

Objetos del dominio o clases conceptuales Asociaciones entre clases conceptuales Atributos de las clases conceptuales

1.11. REQUISITOS FUNCIONALES

Los requisitos funcionales expresan los servicios que el sistema debe proporcionar, es decir lo que el sistema har. Ejemplos: El sistema deber almacenar productos El sistema permitir modificar el stock de productos. El sistema permitir eliminar productos del stock. El sistema permitir verificar disponibilidad de productos del stock. El sistema deber entregar reportes de inventario. El sistema debe generar una orden de trabajo, a travs de la cual se ingresarn la informacin de las ventas. El sistema debe poder modificar una orden de trabajo El sistema debe poder eliminar una orden de trabajo El sistema debe generar Cotizaciones.

1.12. REQUISITOS NO FUNCIONALES

Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementacin, rendimiento, facilidad de mantenimiento, fiabilidad, etc. Ejemplos: El desarrollo del sistema debe seguir un estndar de codificacin del lenguaje de programacin elegido. La arquitectura del sistema deber ser de tres capas. El sistema deber ser ejecutarse en el sistema de Windows XP en adelante. El sistema deber disponer de una herramienta de ayuda o tutor para el manejo del mismo. El sistema deber ser de fcil manejo. El software debe soportar una gran cantidad de datos.

33

Capitulo 3: Captura de Requisitos

34

Capitulo 3: Captura de Requisitos

1.13. ENCONTRAR ACTORES Y CASOS DE USO

Identificamos actores y casos de uso para: Delimitar el sistema de su entorno Esbozar quin y qu (actores) interactuarn con el sistema, y que funcionalidad (casos de uso) se espera del sistema Capturar y definir un glosario de trminos comunes esenciales para la creacin de descripciones detalladas de las funcionalidades del sistema. Esta actividad consta de cuatro pasos: Encontrar los actores Encontrar los casos de uso Describir brevemente cada caso de uso Estos pasos no tienen que ser ejecutados en un orden determinado, y a menudo se hacen simultneamente.

1.13.1. Encontrar los Actores

Ejemplo:

Actor

Descripcin
El vendedor podr: realizar cotizaciones de precios de productos, realizar las ventas, modificar las ventas, dar de baja a las ventas, registrar a los clientes,

Vendedor

modificar los datos de los clientes, elaborar reportes de las ventas por das, por mes, podr buscar los datos de los clientes y ver informacin asociada a estos

Cajero

El cajero podr: registrar los pagos de las ventas, emitir facturas, buscar las ventas, etc. de El encargado de almacn ser: registre las comprar, modifique las compras, genere, registre las entregas de los productos. Elabore las solicitudes de comprar, etc. El administrador: ser quien genere todo tipo de reportes. El tendr acceso a todo el sistema. El cliente: ser quien emita informacin de sus datos al vendedor, solicite una venta, etc.

Encargado almacn

Administrador Cliente

35

Capitulo 3: Captura de Requisitos 1.13.2. Encontrar Casos de Uso

Ejemplo:

Codigo
CU01

Caso de Uso
Registrar cliente

Descripcin
El sistema permitir registrar los datos nuevos de los clientes que realicen una compra.

CU02

Modificar cliente

El sistema permitir modificar los datos de un cliente.

Realizar venta CU03

El sistema permitir crear un detalle de los productos que se estn vendiendo al cliente y actualizar el stock.

CU04

Registrar producto

El sistema permitir registrar el los datos de un nuevo producto que ingresa al alancen.

Generar CU05 venta

reporte

de

El sistema permitir generar los reportes por da, por mes y por ao de las ventas realizadas.

36

Capitulo 3: Captura de Requisitos

Encontrar casos de uso

1.13.3. Diagrama General de Casos de Uso

Generar reporte de venta Realizar venta

Usuario

<<extend>>

<<extend>> Generar plan de pago Vendedor <<include>>

Bodeguero

Administrador Pagar venta al credito cliente

Registrar producto Registrar cliente Gestionar us uarios Registrar categoria

Modificar cliente

Registrar proveedor

Modelo de Casos de uso para el sistema Gestin de Venta

1.13.4. Priorizar Casos de Uso

El propsito de esta actividad es priorizar cuales son los casos de uso ms importantes para abordar en las primeras iteraciones. Ejemplo:

Codi go
CU01 CU02

Caso de Uso
Registrar cliente Modificar datos de los cliente

Actores
Vendedor, Cliente Vendedor, Cliente

Prioridad
Crtico Secundario

37

Capitulo 3: Captura de Requisitos

CU03 CU04 CU05

Realizar venta Registrar producto

Vendedor, Cliente Encargado almacn de

Crtico Crtico Crtico

Generar reporte de venta por da

Vendedor

Priorizar casos de uso 1.14. DETALLAR CASOS DE USO (opcional)

El objetivo principal de detallar cada caso de uso es describir su flujo de sucesos en detalle, incluyendo como comienza, termina, e interactan con los actores . Descripciones textuales (Especificacin). Diagrama de casos de uso, documentan el comportamiento de un sistema desde el punto de vista del usuario. Diagramas de transicin de estados para describir los estados de los casos de uso y las transiciones entre esos estados. Diagramas de actividad para describir transiciones entre estados con ms detalle como secuencias de acciones. Diagramas de interaccin para describir cmo interacta una instancia de caso de uso con la instancia de un actor. Los diagramas de interaccin muestran el caso de uso y el actor o actores participantes. Para nuestro estudio de caso aplicaremos un diagrama de casos de uso: para describir las acciones que realiza un actor sistema desde el punto de vista del usuario. Y para mejor entendimiento elaboremos una especificacin por cada caso de uso utilizando la plantilla usecases.org propuesta por [ Larman- 2002]. Caso de uso: Nombre del caso de uso Actor principal: objetivo. Personal involucrado e intereses: Actores que participan en el caso de uso Precondiciones: Las precondiciones declaran lo que DEBE ser siempre verdadero antes de iniciar el escenario en el cado de uso. Las precondiciones no son probadas dentro del caso de uso, son condiciones que se asumen verdaderas. Normalmente, una precondicin implica un El actor principal que recurre a los servicios del sistema para cumplir un

38

Capitulo 3: Captura de Requisitos

escenario de otro caso de uso que se ha completado. Las precondiciones son un conjunto de condiciones que deben ser ciertas antes de iniciar el caso de uso. Es muy comn que la precondicin sea el resultado exitoso de un caso de uso anterior. Postcondiciones: Las garantias de exito o poscondiciones declaran que DEBE ser verdadero cuando se completa exitosamente el caso de uso, sea a travs de su escenario principal o a travs de un flujo alternativo. Las poscondiciones indican el estado final de las cosas despus de que el caso de uso termine exitosamente a travs de cualquiera de sus flujos. Escenario principal de xito (o Flujo Bsico): Describe una serie pasos para llegar a cumplir con el objetivo del caso de uso. Describe el camino de xito tpico que satisface los intereses del personal involucrado. Extensiones (o Flujos Alternativos): Describen las acciones que pueden desviar al flujo bsico. Son tiles para capturar las acciones excepciones funcionales de un sistema as como escenarios alternos de xito.

Ejemplos: Caso de uso: Registrar Cliente Caso de uso: Registrar cliente Actor principal: Vendedor Personal involucrado e intereses: Vendedor, Cliente Precondiciones: El vendedor se identifica y autentica Postcondiciones: Registrar una venta Escenario principal de xito (o Flujo Bsico):
El vendedor solicita sus datos personales al cliente El vendedor ingresa los datos en el formulario registrar paciente El vendedor da la opcin da la opcin guardar. El sistema valida y verifica los datos. El sistema guardar los datos del cliente en la base de datos

39

Capitulo 3: Captura de Requisitos Extensiones (o Flujos Alternativos): 4.a Si los datos del cliente son incorrectos o existe en la base de datos el sistema muestra un mensaje de error.

Especificacin del caso de uso: Registrar cliente

Caso de uso: Realizar Venta Caso de uso: Realizar venta Actor principal: Vendedor Personal involucrado e intereses: Vendedor, Cliente Precondiciones: El vendedor se identifica y autentica Postcondiciones: Generar reporte de venta. Escenario principal de xito (o Flujo Bsico):
1. 2. 3. 4. 5. El cliente venta de productos El vendedor busca el producto en el sistema El sistema muestra los productos buscados El vendedor selecciona el producto El vendedor busca los datos del cliente y guarda la venta en la base de datos

Extensiones (o Flujos Alternativos): 3.a Si los el producto solicitado no existe, el sistema muestra un mensaje de error. 5.a Si el cliente es nuevo el vendedor registrar los datos del cliente. 5.b Si existe error al guardar la venta el sistema muestra un mensaje de error.

40

Capitulo 4: Anlisis

ANLISIS
Durante el anlisis, analizamos los requisitos que se describieron en la captura de requisitos, refinndolos y estructurndolos. El objetivo de hacerlo es conseguir una comprensin ms precisa de los requisitos y una descripcin de los mismos que sea fcil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.

1.15. Anlisis de la Arquitectura

El propsito de anlisis de la arquitectura es esbozar el modelo de anlisis y la arquitectura mediante la identificacin de paquetes del anlisis, clases anlisis evidente, y requisitos especiales comunes.

1.15.1. Identificacin de paquetes del anlisis

Los paquetes proporcionan un medio para organizar el modelo de anlisis en piezas ms pequeas y manejables. Pueden identificarse inicialmente como forma de dividir el anlisis o encontrarse a medida que se avanza en el anlisis. Una identificacin inicial se hace de manera natural basndonos en los requisitos funcionales y en el dominio de problema, agrupando un cierto nmero de casos de uso en un paquete concreto, y realizando la funcionalidad correspondiente dentro de dicho paquete. Algunos criterios para agrupar casos de uso son: Casos de uso para dar soporte a un determinado proceso de negocio. Casos de uso para dar soporte a un determinado actor del sistema. Casos de uso relacionados mediante relaciones de generalizacin y de extensin.

Cuando dos paquetes necesitan compartir una misma clase, es conveniente ubicar dicha clase en su propio paquete. Para nuestro caso de estudio seguimiento y control de inventario identificamos los siguientes paquetes, a partir de los casos de usos: Gestin de ventas: Los casos de uso realizar venta, generar plan de pago, pagar venta al crdito y registrar cliente estn implicados en el mismo proceso del negocio, por tanto pueden incluirse en el mismo paquete.

41

Capitulo 4: Anlisis

Realizar venta

Generar plan de pago <<trace>> <<trace>> <<trace>> Registrar cliente

Gestin de venta Pagar venta al credito <<trace>>

Paquete del anlisis: Gestin de venta

Gestin de producto: Los casos de uso registrar producto, registrar proveedor y registrar categora estn implicados en el mismo proceso del negocio, por tanto pueden incluirse en el mismo paquete.

Registrar producto

Registrar proveedor

<<trace>>

<<trace>>

Registrar categoria <<trace>>

Gestin de producto

Paquete del anlisis: Gestin de producto

42

Capitulo 4: Anlisis 1.15.2. Identificacin de paquetes de servicio

La identificacin de paquetes de servicio se suele hacer cuando el trabajo de anlisis est avanzado, cuando se comprenden bien los requisitos funcionales, y existen la mayora de las clases del anlisis. Para identificar paquetes de servicio debemos: Identificar un paquete de servicio por cada servicio opcional. Identificar un paquete de servicio por cada servicio que podra hacerse opcional, incluso aunque todos los clientes siempre lo quieran.

Ejemplo: para nuestro caso de estudio:

Podemos identificar un paquete en el cual contengan las clases y archivos para

mostrar ayuda cuando los usuarios del sistema lo requieran. Adems podemos identificar otro paquete para conectar a la bases de datos.

Gestin de servicios

gestion de ayuda

Gestion de base de datos

Paquete del anlisis: Gestin de servicios

1.15.3. Definicin de dependencias entre paquetes del anlisis

Deben definirse dependencias entre los paquetes del anlisis si sus contenidos estn relacionados. La direccin de la dependencia debera ser la misma (navegabilidad) direccin de la relacin. Buscamos definir paquete que sean dbilmente acoplados y altamente cohesivos con respecto a las clases que contienen. Para hacer ms claras las dependencias puede ser til estratificar el modelo de anlisis haciendo que los paquetes especficos de la aplicacin queden en una capa de nivel superior y los paquetes generales queden en una capa inferior.

43

Capitulo 4: Anlisis

1.16. Anlisis de Casos de Uso

Analizamos un caso de uso para: Identificar las clases del anlisis cuyos objetos son necesarios para llevar a cabo el flujo de suceso del caso de uso. Distribuir el comportamiento del caso de uso entre objetos del anlisis que interactan. Capturar requisitos especiales sobre la realizacin del caso de uso.

1.16.1. Identificacin de clases del anlisis Clase de interfaz (Boundary)

Las Clases Interfaz (Boundary) se usan para modelar la interaccin entre el sistema y los actores. Esta interaccin involucra recibir (y presentar) informacin y peticiones desde usuarios y sistemas externos. Representan la abstraccin de de ventanas, formularios, paneles, interfaces de comunicacin, impresoras, sensores, terminales o dispositivos.

Clase de entidad (Entity)

Refleja el mundo real o se crean para tareas internas. No dependen del entorno del sistema. Pueden ser independientes de la aplicacin. Se obtiene examinando las responsabilidades del sistema en los casos de uso. Las Clases Entidad (Entity) son usadas para modelar la informacin que tiene permanencia en el tiempo y es persistente.

Clase control (Control)

Coordinan los eventos necesarios para implementar el comportamiento especificado en el caso de uso. Tambin se usan para representar clculos y derivaciones complejas, como la lgica del negocio que no se puede relacionar con ninguna entidad. La dinmica del sistema se modela en una clase controladora, que se encarga de delegar trabajo a otras clases.

44

Capitulo 4: Anlisis

Buscamos clases de entidad, control, e interfaz y esbozamos sus nombres, responsabilidades, atributos, y relaciones. Podemos utilizar las siguientes guas para identificar clases: Identificar una clase de interfaz para cada actor humano, y dejar que esta clase represente la ventana principal de la interfaz de usuario con la cual interacta el actor. Identificar una clase de control responsable del tratamiento del control y de la coordinacin de la realizacin del caso de uso, y despus refinar esta clase de control de acuerdo a los requisitos del caso de uso. Identificar clases entidad a partir de considerarse que informacin debe utilizarse y manipularse para realizar el caso de uso.

1.16.2. Descripcin de las interacciones entre objetos del anlisis

Se utiliza un diagrama de colaboracin para describir como interactan los objetos encontrados para realizar el caso de uso. Podemos observar lo siguiente: Un caso de uso se inicia mediante un mensaje proveniente de una instancia de un actor. Cada clase identificada en el paso anterior debe tener una instancia en esta colaboracin. Los mensajes no se asocian con operaciones, ya que las clases de anlisis se definen en trmino de responsabilidades no en operaciones atmicas. Los enlaces del diagrama son instancias de las asociaciones entre clases del anlisis. Por cada Caso de Uso identificar las clases del anlisis y luego elaboramos el diagrama de colaboracin. Ejemplos:

45

Capitulo 4: Anlisis Caso de uso: Registrar Cliente

2: Limpia y habiliata controles 6: Adiciona el nuevo cliente 4: Gestiona la adicion del cliente 5: Verifica si existe el cliente

3: Ingresa los datos y da la opcin guardar : IUCliente 1: Da la opcin nuevo

: ControlCliente

: Cliente

: Vendedor

Diagrama de colaboracin: registrar cliente

Caso de uso: Registrar cliente Actor principal: Vendedor Personal involucrado e intereses: Vendedor, Cliente Precondiciones: El vendedor se identifica y autentica Postcondiciones: Registrar una venta Escenario principal de xito (o Flujo Bsico): El vendedor da la opcion nuevo El sistema limpia y habilita controles El vendedor da la opcin da la opcin guardar. El sitema por medio de la clase Control cliente gestiona la adicin del cliente El sistema antes de adicionar los datos verifica si existe el cliente en la base de datos El sistema adiciona los datos del nuevo cliente en la base de datos. Extensiones (o Flujos Alternativos): 4.a Si los datos del cliente son incorrectos 4 b. Si el cliente existe en la base de datos el sistema muestra un mensaje de error a vendedor.

46

Capitulo 4: Anlisis Cuadro: Especificacin del diagrama de colaboracin: Registrar cliente Caso de uso: ingresar al sistema

1: ingresa su nombre de usuario, su clave y da la opion ingresar

2: verifica usuario

3: obtiene datos

: IU:Inicio Seccion

: Control:Inicio Seccion

: Entidad:Usuario

4: mostrar la interfaz principal : usuario

si el usuario es correcto, ingresa al sistema

: IU:Sistema

Diagrama de colaboracin: Ingresar al sistema

Caso de uso: registrar un producto:

2: nueva interfaz producto

: IU: Gestionar Producto

: Control:Gestionar Producto 3: crear interfaz producto 10: verificar datos

4: obtener marca

: Entidad:Marca

1: da la opcin nuevo 5: obtener categoria

7: mostrar los datos 8: selecciona marca, categoria, proveedor, ingresa los datos y da la opcin guardar 9: guardar producto : Interzas:Producto : Control: Producto

: vendedor

: Entidad: Categoria

6: obtener proveedor 11: crear producto nuevo

: Entidad: Producto

: Entidad: Proveedor

Diagrama de colaboracin: Registrar producto

47

Capitulo 4: Anlisis

1.17. Anlisis de Clases

Los objetivos de analizar una clase son: Identificar y mantener las responsabilidades de una clase del anlisis, basado en su papel en la realizacin de Casos de Uso. Identificar y mantener los atributos y relaciones de la clase del anlisis.

1.17.1. Identificacin de Responsabilidades

Las responsabilidades de una clase pueden recopilarse combinando todos los roles que cumple en diferentes realizaciones de Casos de Uso. Las responsabilidades de una clase definen la funcionalidad de esa clase, y estn basadas en el estudio de los papeles que desempean sus objetos dentro de los distintos casos de uso. A partir de estas responsabilidades, se puede comenzar a encontrar las operaciones que van a pertenecer a la clase. Estas deben ser relevantes, simples, y participar en la descripcin de la responsabilidad.

1.17.2. Atributos de atributos

Los atributos de una clase especifican propiedades de la clase, y se identifican por estar implicados en sus responsabilidades. Los tipos de estos atributos deberan ser conceptuales. Ejemplo de Identificacin de responsabilidades y atributos de una clase del anlisis, para nuestro caso de estudio:

1.17.3. Identificar asociaciones

En esta tarea se estudian los mensajes establecidos entre los objetos del diagrama de interaccin para determinar qu asociaciones existen entre las clases correspondientes. Estas asociaciones suelen corresponderse con expresiones verbales incluidas en las especificaciones. Las relaciones surgen como respuesta a las demandas en los distintos casos de uso, y para ello puede existir la necesidad de definir agregaciones y herencia entre objetos. Una asociacin esta caracterizada por: Los papeles que desempea. Su direccionalidad, que representa el sentido en el que se debe interpretar. Su cardinalidad, que representa el nmero de instancias implicadas en la asociacin. Dichas caractersticas pueden obtenerse a partir de la especificacin de los casos de uso.

48

Capitulo 4: Anlisis
Ejemplos Identificacin de Responsabilidades A continuacin, en la tabla, se muestran las distintas clases del sistema junto con sus responsabilidades. Clase IUCliente <<Clase interfaz>> Responsabilidad Permite introducir datos de los clientes, un registro. Gestionar las operaciones que se realizan para adicionar los datos ControlCliente <<Clase Control>> de nuevo cliente, modificar, eliminar, buscar los datos y verificar si estn correcta la informacin que se le envan desde el formulario. Cliente <<Clase Entidad>> ObtenerDatos <<Clase Control>> Almacenar de datos. Permite obtener datos de la base de datos de una consulta dada. los datos del para adicionar, modificar, dar de baja y buscar

personal de atencin en la base

Identificacin de los atributos y Asociaciones A continuacin, en la figura, se trata el tema de agregaciones y asociaciones para las clases de entidad.

49

Capitulo 4: Anlisis

Proveedor codigo nombre contacto direccion localidad pais telefono fax email web observacion estado 1

Marca codigo nombre estado 0..1

Persona codigo ci expedido nombre ap am fecha_nac sexo estado_civil direccion telefono email estado Cliente nit nombre_nit

Empleado login password tipo 1 1 * Compra codigo fecha precio_total estado 1..*

1..* Producto codigo nombre cantidad cantidad_min precio_compra precio 1..* ganacia promocion foto descripcion estado 1..*

1..* Venta codigo fecha precio_total estado

1..*

0..*

1..*

1 Categoria codigo nombre estado

Detalle_Venta precio_vendido cantidad_vendido

Detalle_Compra precio_comprado cantidad_comprado

Figura Diagrama de Clases del analisis

Las clases de control, por su parte, son responsables de administrar los flujos de trabajo necesarios para implementar un caso de uso. Por lo general, utilizan a las clases de entidad como materia prima y resultado de su operacin.

50

UNIDAD 4: Diseo

DISEO
En el diseo modelamos el sistema y encontramos su forma para que soporte los requisitos funcionales y no funcionales. Los propsitos del diseo son: Adquirir una compresin en profundidad de los aspectos relacionados con los requisitos no funcionales y restricciones relacionales con los lenguajes de programacin, componentes reutilizables, sistemas operativos y tecnologas de distribucin. Crear una entrada apropiada y un punto de partida para actividades de implementacin subsiguientes capturado los requisitos o subsistemas individuales, interfaces y clases. Ser capaces de descomponer los trabajos de implementacin en partes ms manejables que puedan ser llevadas a cabo por diferentes equipos de desarrollo. Flujo de trabajo:

51

UNIDAD 4: Diseo

Flujo de trabajo del diseo

1.18. Diseo de la Arquitectura

El objetivo del diseo de la arquitectura es esbozar los modelos de diseo identificando: Nodos y configuraciones de red. Subsistemas e interfaces.

1.18.1. Identificacin de nodos y configuraciones de red

Entre los aspectos de configuraciones de red podemos resaltar: Qu nodos se necesitan, que capacidad deben tener? Qu tipo de conexiones debe haber entre los nodos, que protocolos de comunicaciones? Qu caractersticas deben tener los nodos, ancho de banda, disponibilidad, calidad, etc? Para identificar los nodos y configuraciones de red, se utiliza un diagrama de despliegue Diagrama de despliegue Un Diagrama de Despliegue es un diagrama que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Los Diagramas de Despliegue muestran las relaciones fsicas de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. Un diagrama de despliegue modela: Aspectos fsicos de un sistema. La vista de despliegue esttica de un sistema. Una configuracin de nodos y los componentes que residen en ellos. Los elementos usados por este tipo de diagrama son: NODO: Elemento de hardware o software que representa un recurso computacional. Este elemento es donde se ejecutan los componentes COMPONENTES: Participan en la ejecucin de un sistema RELACIONES: Dependencia, generalizacin y asociacin.

Ejemplo para nuestro caso de estudio:

52

UNIDAD 4: Diseo

<<Terminal>> Ventas <<Servidor>> Servidor de Base de Datos <<cable de red>>

<<cable de red>>

<<Switch>>

<<Impresora>>

<<cable de red>>

<<Terminal>> Almacen

Diagrama de despliegue para el sistema inventario

1.18.2. Identificacin de subsistemas y de sus interfaces

Los subsistemas constituyen un medio para organizar el modelo de diseo en piezas manejables. Pueden identificarse inicialmente como forma de dividir el trabajo de diseo, o bien pueden irse encontrando a medida que el modelo de diseo evoluciona. Para nuestro caso de estudio identificamos los siguientes subsistemas:

53

UNIDAD 4: Diseo

<<subsystem>> Gestin de Ventas

<<subsystem>> Usuarios

<<subsystem>> Gestin de Productos

<<subsystem>> Gestin de Clientes

<<subsystem>> Servicios <<subsystem >> Reportes <<subsystem>> Acceso a Datos

Identificacin de Subsistemas de la aplicacin

1.19. Diseo de Casos de Uso

Los objetivos del diseo de un caso de uso son: Identificar clases y/o subsistemas necesarios para llevar a cabo el caso de uso. Distribuir el comportamiento del caso de uso entre los objetos del diseo que interactan y/o entre los subsistemas participantes. Definir los requisitos sobre las operaciones de las clases del diseo y/o sobre los subsistemas y sus interfaces. Para el disear un de casos de uso se puede utiliza un diagrama de secuencia o diagrama de colaboracin

Diagrama de secuencia
El diagrama de secuencia describe las interacciones entre un grupo de objetos mostrando de forma secuencial los envos de mensajes entre objetos. Elementos

54

UNIDAD 4: Diseo

Los componentes de un diagrama de interaccin son: Lnea de vida de un objeto Un objeto (o actor) se representa como una lnea vertical punteada con un rectngulo de encabezado y con rectngulos a travs de la lnea principal que denotan la ejecucin de mtodos (activacin). El rectngulo de encabezado contiene el nombre del objeto y el de su clase. Activacin Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operacin, bien sea por s mismo o por medio de delegacin a alguno de sus atributos. Se denota como un rectngulo delgado sobre la lnea de vida del objeto. Mensajes El envo de mensajes entre objetos se denota mediante una lnea slida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta. Representa la llamada de un mtodo (operacin) de un objeto en particular. Ejemplos 1: Diagrama de secuencia para calcular los valores de un cubo mgico, mostrando el resultado al usuario por medio del formulario.

Interfaz de usuario

CuboMagico : Usuario

1: [Da clic a la opcion ejecutar] Ejecutar() 2: [Muestra la matriz con el cubo mgico]

Diagrama de secuencia: calculo de cubo mgico

Public Class CuboMagico Private Sub Ejecutar() End Sub End Class Ejercicio 2: Diagrama de secuencia para realizar la suma entre dos nmeros:

55

UNIDAD 4: Diseo

IU : Aritmetica : Usuario cs : ClaseSuma

1: [ingresa valores y da opcion sumar] Sumar()

2: calcular(valor1 int, valor2 int) 3: [muestra el resultado]

Diagrama de secuencia: realizar suma

El cdigo fuente de este diagrama de secuencia es el siguiente: Public Class Aritmetica Private Sub Sumar(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnSuma.Click Dim cs As New ClaseSuma txtresultado.Text = cs.calcular(txtvalor1.Text, txtvalor2.Text) End Sub End Class Public Class ClaseSuma Sub claseSuma() End Sub Public Function calcular(ByVal valor1 As Integer, ByVal valor2 As Integer) Return valor1 + valor2 End Function End Class

Ejercicio 3a: Diagrama de secuencia para registrar un cliente nuevo.

56

UNIDAD 4: Diseo

: Vendedor 1: [da la opcin] Nuevo()

frmCliente : IUCliente

objControlCliente : ControlCliente

objCliente : Cliente

2: LimpiarControles() 3: HabilitarControles() Si no existe el cliente se adiciona

4: [ingresa datos y da la opcin] Guardar() 5: AdicionarCliente() Si se adiciono el cliente, obtiene la lista con los clientes y limpia controles y deshabilita controles

6: VerificarExiste() 7: validarControles() 8: Adicionar()

9: obtenerClientes() 10: LimpiarControles() 11: DeshabilitarControles()

Diagrama de secuencia: Registrar cliente

57

UNIDAD 4: Diseo

Ejercicio 3b: Diagrama de secuencia para registrar un cliente nuevo.

: Vendedor 1: [da la opcin] Nuevo()

frmCliente : IUCliente

objControlCliente : ControlCliente

objCliente : Cliente

2: LimpiarControles() 3: HabilitarControles()

4: [ingresa datos]

5: [da la opcin] Guardar() 6: respAdiCli= AdicionarCliente() 7: existe=VerificarExiste() 8: [Muestra mensaje segn existe] 9: validarControles() 10: [Muestra mensaje si algun control esta incorrecto] 11: [si no existe] respAdicionar =Adicionar() 12: [ si respAdicionar es true, muestra mensaje] 13: [Si respAdiCli es true] obtenerClientes() 14: [muestra lista de clientes] 15: [Si respAdiCli es true] LimpiarControles() 16: [Si respAdiCli es true] DeshabilitarControles()

Diagrama de secuencia: Registrar cliente

58

UNIDAD 4: Diseo

Ejercicio 4: Diagrama de colaboracin para registrar un cliente nuevo.

2: LimpiarControles() 3: HabilitarControles() 10: LimpiarControles() 11: DeshabilitarControles()

1: [da la opcin] Nuevo() 4: [ingresa datos y da la opcin] Guardar() frmCliente : IUCliente : Vendedor 7: validarControles() 5: AdicionarCliente() 9: obtenerClientes() 6: VerificarExiste() 8: Adicionar() objControlCliente : ControlCliente objCliente : Cliente

Diagrama de colaboracin: Registrar cliente

Ejercicio 5: Diagrama de secuencia para registrar un producto nuevo.

59

UNIDAD 4: Diseo

IU:Producto : vendedor [da nuevo]

:GestionarProducto

IU:Adicionar Producto

:AdicionarProd ucto

:Categoria

:Marca

:Proveedor

:Producto

nuevo() new AdicionarProducto() CargarCategoria()

obtenerCategoria() CargarMarca() obtenerMarcar() CargarProveedor() obtenerProveedor()

show()

[ingresa datos y da guardar] guardar() VerificarCampos()

False:ExisteProducto() [mensaje de error]

True:AdicionarProducto() [mensaje de exito]

60

UNIDAD 5: Implementacin

Diseo de la base de datos

1.19.1. Diseo Conceptual

Es una descripcin de la estructura de la base de datos, independiente del SGBD (Sistema de Gestin de Base de Datos) que se vaya a utilizar para manipularla. Para representar el diseo conceptual se utilizara un diagrama de clases. Un diagrama de clases es un tipo de diagrama que describe la estructura de un SISTEMA mostrando sus clases, atributos y las relaciones entre ellos. Ejemplo:

61

UNIDAD 5: Implementacin

Proveedor codigo nombre contacto direccion localidad pais telefono fax email web observacion estado 1 1..* 1..* Producto codigo nombre cantidad cantidad_min fecha_compra precio_compra precio 1..* ganacia iva promocion foto descripcion estado 1..*

Marca codigo nombre estado 0..1

Modelo codigo nombre estado

0..1 Cliente nit nombre_nit 1

Persona codigo ci expedido nombre ap am fecha_nac sexo estado_civil direccion telefono email estado

Empleado login password tipo 1 1 * Compra codigo fecha precio_total estado 1..*

1..* Venta codigo fecha precio_total estado

1..*

1..*

0..*

1 Categoria codigo nombre estado

Detalle_Venta precio_vendido cantidad_vendido

Detalle_Compra precio_comprado cantidad_comprado

Diagrama de clases de la base de datos

62

UNIDAD 5: Implementacin

1.19.2. Diseo Lgico

Una vez establecido el modelo conceptual del problema o situacin, el diseo lgico de los datos permite que estos se puedan representar usando de manera eficiente posibles recursos para estructurar datos y modelar restricciones disponibles en el modelo lgico. El objetivo es convertir el esquema conceptual de datos en un esquema lgico que se ajuste al gestor de la base de datos que va a ser utilizado (el DBMS). Para escenificar esta situacin se tomar el Modelo Relacional cuyo esquema relacional es trabajado por muchos DBMS comerciales. Ejemplo:

MODELO RELACIONAL DE LA BASE DE DATOS Proveedor codigo pk Marca codigo pk Modelo codigo pk Categoria codigo pk 63 nombre estado nombre estado nombre estado nombre contact o direccio n localida d pais telefon o fax email web observaci on estado

UNIDAD 5: Implementacin Producto codi go pk codigo_proveedo r fk Cliente codig o pk Empleado codi go pk Venta codigo pk fecha precio_total estado codigo_clien te fk codigo_emple ado fk c i expedi do nomb re a p a m Fecha_n ac sex o Estado_ci vil direcci on telefo no ema il logi n passwo rd tip o estad o ci expedi do nomb re ap am Fecha_n ac sex o Estado_ci vil direcci on telefo no ema il nit Nombre_ nit estad o codigo_marca fk codigo_modelo codigo_categoria fk fk nomb re cantid ad Cantidad_ min Fecha_com pra Precio_com pra prec io gana cia iv a promoci on fot o descripci on esta do

Detalle_Venta 64

UNIDAD 5: Implementacin codigo_venta pk Compra Codigo pk Detalle_Compra codigo_compra pk codigo_producto pk precio_comprado cantidad_compra do fecha precio_total estado codigo_emple ado fk codigo_producto pk precio_vendido cantidad_vendido

65

UNIDAD 4: Diseo

1.19.3. Diseo Fsico En el diseo fsico se especifican las caractersticas fsicas de las base de datos donde se implementaran las mismas. Ejemplo: DISEO FISICO DE LA BASE DE DATOS

Proveedor ATRIBUTOS TIPO DATO codigo nombre contacto direccion localidad pais telefono fax email web observacio n estado Marca ATRIBUTOS int varchar varchar varchar varchar varchar varchar varchar varchar varchar varchar bolean

DE AMPLITUD 4 bytes 50 50 100 50 50 15 15 30 200 200 1

LLAVE pk

PERMITE NULO No Si No No No No No Si Si Si Si No

TIPO DE DATO

AMPLITUD

LLAVE

PERMI TE NULO No No No

codigo nombre estado Modelo ATRIBUTOS

int varchar bolean

4 bytes 50 1

pk

TIPO DE DATO

AMPLITUD

LLAVE

PERMI TE NULO No No No

codigo nombre estado

int varchar bolean

4 bytes 50 1

pk

66

UNIDAD 4: Diseo

Categoria ATRIBUTOS

TIPO DE DATO

AMPLITUD

LLAVE

PERMI TE NULO No No No PERMI TE NULO No No No No No No No No No Si Si No No No No No

codigo nombre estado Producto ATRIBUTOS

int varchar bolean TIPO DE DATO

4 bytes 50 1 AMPLITUD

pk

LLAVE

codigo nombre cantidad cantidad_min fecha_compra precio_compra precio ganancia promocion foto descripcion estado codigo_provee dor codigo_marca codigo_model o codigo_catego ria

int varchar tinyint tinyint date float float float bolean varchar varchar bolean int int int int

4 bytes 50 2 bytes 2 bytes 8 bytes 4 bytes 4 bytes 4 bytes 1 100 200 1 4 bytes 4 bytes 4 bytes 4 bytes

pk

fk Fk Fk fk

67

UNIDAD 4: Diseo

Cliente ATRIBUTOS

TIPO DE DATO

AMPLITUD

LLAVE

PERMI TE NULO No Si Si No No Si No No No No Si Si Si Si No

codigo ci expedido nombre ap am fecha_nac sexo estado_civil direccion telefono email nit nombre_nit estado

int varchar varchar varchar varchar varchar date varchar varchar varchar varchar varchar varchar varchar bolean

4 bytes 7 5 20 15 15 8 bytes 1 10 50 10 50 10 50 1

pk

Empleado

68

UNIDAD 4: Diseo

ATRIBUTOS

TIPO DE DATO

AMPLITUD

LLAVE

PERMI TE NULO No No No No No Si No No No No Si Si Si Si No No

codigo ci expedido nombre ap am fecha_nac sexo estado_civil direccion telefono email Login password tipo estado

int varchar varchar varchar varchar varchar date varchar varchar varchar varchar varchar varchar varchar varchar bolean

4 bytes 7 5 20 15 15 8 bytes 1 10 50 10 50 15 15 10 1

pk

Venta ATRIBUTOS

TIPO DE DATO

AMPLITUD

LLAVE

PERMI TE NULO No No

codigo fecha

int varchar

4 bytes 50 69

pk

UNIDAD 4: Diseo

precio_total float estado bolean codigo_cliente int codigo_emple int ado Detalle_Venta ATRIBUTOS TIPO DE DATO

4 bytes 1 4 bytes 4 bytes

fk fk

No No No No

AMPLITUD

LLAVE

PERMI TE NULO No No No No

codigo_venta int codigo_produc int to precio_vendid float o cantidad_ven tinyint dido Compra ATRIBUTOS TIPO DE DATO

4 bytes 4 bytes 4 bytes 2 bytes

pk pk

AMPLITUD

LLAVE

PERMI TE NULO No No No No No

codigo int fecha varchar precio_total float estado bolean codigo_emple int ado Detalle_Compra ATRIBUTOS TIPO DE DATO

4 bytes 50 4 bytes 1 4 bytes

pk

fk

AMPLITUD

LLAVE

PERMI TE NULO No No No No

codigo_compra int codigo_product int o precio_comprad float o cantidad_compr tinyint ado

4 bytes 4 bytes 4 bytes 2 bytes

pk pk

70

UNIDAD 4: Diseo

Proceso de Diseo

71

Capitulo 6: Implementacin

IMPLEMENTACIN
En la implementacin empezamos con el resultado del diseo e implementamos el sistema en trmino de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigo binario, ejecutables, y similares. Flujo de Trabajo

Flujo de trabajo de implementacin

1.20. Implementacin de la arquitectura

El propsito de la implementacin de la arquitectura es esbozar el modelo de implementacin y su arquitectura mediante: Identificacin de componentes significativos arquitectnicamente tales como componentes ejecutables. Para representar identificar los componentes se usa un diagrama de componentes.

72

Capitulo 6: Implementacin

Un diagrama de componentes muestra las organizaciones y dependencias lgicas entre componentes software, sean stos componentes de cdigo fuente, binarios o ejecutables.
Los elementos usados por este tipo de diagrama son: COMPONENTES: Es una parte fsica de un sistema. Ejemplos de componentes son tablas, archivos de datos, ejecutables, bibliotecas de vnculos dinmicos, documentos y cosas por el estilo. RELACIONES: Dependencia, generalizacin y asociacin. Ejemplo:

73

Capitulo 6: Implementacin
Modelo de Implementacin

Diagrama de despliegue

74

Capitulo 6: Implementacin

Ejemplo para nuestro caso de estudio:

<<ejecutable>> Inventario.exe

<<aplicacin>> IUPrincipal.vb <<subsystem>> Venta

<<subsystem>> Producto

<<file>> CrystalReport. rpt

<<file>> MySQLData.dll

<<libreria>> MySQLConector-ODBC

MySQL

Diagrama de despliegue para el sistema inventario

75