Santiago de Querétaro, Qro. Enero de 2004.

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Santiago de Querétaro, Qro. Enero de 2004."

Transcripción

1 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Voluntad. Conocimiento. Servicio SISTEMA DE CONTROL DE MATERIAL DE EMPAQUE. ALMACENAJE Y DISTRIBUCIÓN STELLOS S.A. DE C.V. Reporte de Estadía para obtener el Título de Técnico Superior Universitario en Telemática. ALVARADO LUAN OMAR OSWALDO. BAEZ CORDOVA PABLO ABEL. CASTRO SALGADO ARMANDO. PAZ OBREGÓN AARON. Santiago de Querétaro, Qro. Enero de 2004.

2 2

3 3

4 4

5 5

6 UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Voluntad. Conocimiento. Servicio NOMBRE DEL ASESOR DE LA EMPRESA: ING. HERIBERTO GUTIÉRREZ FRONTANA. NOMBRE DEL ASESOR DE LA UNIVERSIDAD: ING. SALVADOR HERNÁNDEZ GONZÁLEZ. STELLOS UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO. NOMBRE DEL ALUMNO: PAZ OBREGÓN AARON. BAEZ CORDOVA PABLO ABEL. CASTRO SALGADO ARMANDO. ALVARADO LUNA OMAR OSWALDO. 6

7 PAG. ÍNDICE..7 INTRODUCCIÓN..11 CAPITULO I SISTEMA DE CONTROL DE MATERIAL DE EMPAQUE Almacenaje y Distribución Stellos S.A. de C.V Giro de la Empresa Visión de la Empresa Misión de la Empresa Filosofía de Grupo SID Políticas de Calidad de Grupo SID SID en Números Organigrama Análisis de Necesidades Definición del Proyecto Objetivos Justificación Alternativas de Solución Elección de la Alternativa Óptima Plan de Trabajo Diagrama de Gantt 21 7

8 1.5.2 Especificaciones Decisión del Proyecto Recopilación y Análisis de la Información Recopilación de Datos Fase de Análisis Fase de Diseño Desarrollo de la Fase de Diseño Finalización de la Fase de Diseño 33 CAPITULO II DESARROLLO DEL PROYECTO Descripción detallada del Plan de Trabajo 35 FASE DE ANALISIS Tipos de Casos de Usos y sus Formatos Tipos de Formalidad Identificación de las Clases Conceptuales Estrategias para Identificar Clases Conceptuales Descubrimiento de Clases Conceptuales mediante la Identificación de Frases Nominales Modelo del Dominio del SCME Localización de las Asociaciones Guías para las Asociaciones Asignación de Nombres a las Asociaciones

9 Atributos Conclusión del Modelo del Dominio Contratos Operaciones del Sistema y la Interfaz del Sistema 55 FASE DEL DISEÑO Notación de los Diagramas de Interacción Caso de Uso Real Diagramas de Clases del Diseño.. 67 CAPITULO III CONCLUSIONES Dificultades Logros Obtenidos Recomendaciones Organización Definición de Secuencia Capacitación Aportaciones Mantenimiento Preventivo Limpieza de Equipos Apoyo Logístico y de Gestión Cableado Mantenimiento Correctivo 85 9

10 Instalación de Software Formateo de Equipos Respaldos al Servidor.86 ANEXOS ANEXO A MANUAL DE 4GL ANEXO B PRESENTACIÓN DE VISUAL APPEAL GLOSARIO MATERIAL DE CONSULTA Bibliografía

11 Introducción. La presentación de un Sistema de información siempre es la adecuada cuando la propuesta y el planteamiento de información se sustentan en bases sólidas en su definición, objetivos y alcances pretendiendo con ello lograr una buena adaptación y finalización del Sistema. Las bases fundamentales de cualquier sistema son todas aquellas herramientas en las cuales está basado como tal, y lo respalda una buena administración y control para que su aplicación y desarrollo del sistema pueda llevarse a cabo con los resultados esperados. Por medio del presente documento se propone la elaboración de un proyecto para implementar un Sistema de Control de Material de Empaque que involucra diferentes etapas desde la definición del Proyecto hasta la conclusión del mismo. Dentro de la etapa de desarrollo se dividió en dos fases de acuerdo a las herramientas UML y patrones que son las siguientes: Fase de Análisis Fase de Diseño En estas fases se encuentra toda la información de la Propuesta del Proyecto, teniendo como último paso las conclusiones. 11

12 CAPITULO I SISTEMA DE CONTROL DE MATERIAL DE EMPAQUE 12

13 Sistema de Control de Material de Empaque El presente trabajo consiste en proponer un sistema para lograr un control más exacto del material de empaque, o sea tener un inventario de las bolsas de termo-encogido para que el personal involucrado tenga un fácil acceso al material y tener mayor seguridad en el control del mismo. 1.1 Almacenaje y Distribución Stellos S.A. De C.V Giro de la Empresa Almacenaje y Distribución Visión de la Empresa: Lograr competitividad y crecimiento rentable a través de nuestra gente Misión de la Empresa: Ser la empresa líder en servicios integrales de distribución, almacenaje y transporte más competitiva, confiable y segura a nivel nacional e internacional, con el fin de lograr con excelencia la satisfacción de las necesidades y expectativas de nuestros clientes. 13

14 Filosofía de Grupo SID: Ofrecer servicios de almacenaje y distribución, con los más altos niveles de calidad que van a la par con las exigencias del mercado y con la satisfacción de nuestros clientes Políticas de Calidad de Grupo SID: Es política de Grupo SID cumplir con los requisitos establecidos de nuestros clientes, brindando un servicio de excelencia, innovador y garantizado con el compromiso de mejorar continuamente el sistema de gestión de calidad en los rubros de: competitividad, liderazgo y desarrollo personal de nuestra gente y proveedores. Es política de Grupo SID, S.A. de C.V., División, Almacenaje y Distribución, sobrepasar las expectativas de nuestros clientes, brindando un servicio innovador y de excelencia, garantizando que sus productos se almacenen y/o distribuyan con base en sus necesidades y requerimientos SID en Números: Somos más de personas. Contamos con más de 470 tractocamiones. Tenemos más de remolques. Ofrecemos más de 120 camionetas para Distribución Directa. 14

15 Contamos con más de metros cuadrados de almacén. Tenemos más de 70 montacargas para el manejo de materiales Organigrama (Ver Fig. 1 de 1.1.2) Gerencia Operación Gerencia Gerencia Planeación Recursos Humanos Surtimiento Bulk Pick Facturación Recibo Embarques Acuses Sistemas Fig. 1 de Organigrama El área de sistemas esta involucrado en todas las áreas de la empresa ya que lleva el control de todo lo que se hace en el almacén. El organigrama está constituido por un Gerente Regional, un Gerente de Operaciones y un Gerente de Planeación, quienes coordinan a las demás áreas de: Recibo, Empaque Bulk Calzado, Empaque Bulk Textil, Empaque Bulk Equipo, Embarque, 15

16 Devoluciones, Inventarios, Promocionales, Tráfico, Planeación y Sistemas. Es en el área de sistemas en donde nos vamos a desempeñar como estudiantes de telemática, desarrollaremos un proyecto que utilice las herramientas aprendidas en el trayecto de la carrera. 1.2 Análisis de Necesidades Definición del Proyecto El principal problema que ha presentando en estos momentos la empresa, es el resurtir uno de los materiales que se utilizan para el empaquetamiento; el material son bolsas de termo encogido; un inconveniente que tienen con éste material es que nadie lleva un control específico de la cantidad de bolsas que se tienen, por lo que, en un determinado tiempo el material se termina y se tiene que recurrir a otros planes, como el pedir bolsa prestada o el de no ponerle bolsa a la caja, ocasionando perdida de tiempo. La persona responsable de éstas bolsas de termo-encogido, es el Jefe de Inventarios, quien debe de revisar el presupuesto que se tiene, después contactar con la empresa y/o el proveedor y por último esperar y recibir la mercancía. En conclusión es demasiado el 16

17 tiempo actualmente perdido en todas las maniobras realizadas únicamente en el proceso de la bolsa de termo-encogido. Para conocer más a fondo el problema se tiene programado realizar una serie de entrevistas con los responsables, es decir, todas las personas que están internamente relacionadas con el problema y con los encargados de que el material de termo encogido éste siempre en existencia. De acuerdo a lo obtenido en las mencionadas entrevistas se procederá a analizar la situación más a fondo para iniciar con el trabajo de diseño Objetivos Objetivo General Desarrollar un nuevo sistema de control que facilite el uso, manejo y administración, así como la actualización de la existencia del material de empaque. 17

18 Objetivos Específicos Aplicar las técnicas de UML y Patrones, las cuales nos guiaran durante la elaboración de la propuesta de proyecto desarrollando las siguientes fases de acuerdo a las técnicas anteriores: Desarrollar Fase de Análisis Desarrollar Fase de Diseño. Aplicar módulos de Programación en entornos 4GL (Fourth Generation Language). Los Objetivos mencionados son Específicos por que se habla sobre el qué, cuándo y cómo va a cambiar la situación; se podría decir también que son Medibles ya que se pueden cuantificar los beneficios, por ejemplo, en la fase de Análisis nos podemos dar cuenta de detalles que tal vez pudieran faltar lo cual nos ayudara a realizar una mejor propuesta; estos objetivos son Realizables y Realistas ya que todos son en base a la propuesta y por lo consecuente de todo esto hemos dividido cada uno de estos objetivos en un lapso de tiempo para poder facilitar la aplicación de cada uno y por lo tanto llevar una coordinación satisfactoria. 18

19 1.2.3 Justificación Actualmente se realiza la ampliación del sistema actual, ya que se debe implementar un control sobre todo el material de termoencogido, facilitando así su control desde el sistema, mediante la generación de reportes, puntos de reorden, indicadores, que se realizaran en automático, éste a su vez, actualizará la existencia del producto, en otras palabras, facilitará la generación de resurtimiento de material con el proveedor. 1.3 Alternativas de Solución Se tiene pensado implementar un Sistema de Control de Material de Empaque el cual facilitará la administración y control del material, bolsas de termo-encogido. Se propone desarrollar un sistema de tal manera que le indique al encargado de Jefe de Inventario, cuando se esté terminando el material. El proyecto, basado en indicadores logrará el propósito esperado. Lo que se quiere lograr en el primer paso es poder llevar un mejor control dentro de la bodega y así constar su aplicación para reflejar el funcionamiento que se puede llevar en el almacén, al inventariar el producto total en cada una de las ubicaciones dentro de la 19

20 bodega; teniendo así como resultado final el implementar soluciones de productividad. 1.4 Elección de la Alternativa Óptima La mejor alternativa fué la de interactuar con el personal, de diversas áreas dentro de la bodega y así llegar a la conclusión de que la manera más fácil de poder solucionar patrones o normas, es la de llevar un control de registros de patrones para poder interactuar con los inventarios de un Almacén. Para lograr esto, se empleará 4GL que es un lenguaje de cuarta generación bajo la metodología del Lenguaje de Modelación Unificado (UML) ya que es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo del software. 20

21 1.5 Plan de Trabajo Diagrama de Gantt ACTIVIDADES DEL MES DE MAYO ID Actividades Inicio Fin Duración May Desicion de proyecto 04/05/ /05/2004 4d 2 Entrevista con el personal 10/05/ /05/2004 5d ID Actividades Inicio Fin Duración May Recopilación de 1 17/05/ /05/ d datos ACTIVIDADES DEL MES DE JUNIO ID Actividades Inicio Fin Duración 1 Inicio de la etapa de análisis 01/06/ /06/2004 9d Jun Jun 2004 ID Actividades Inicio Fin Duración Desarrollo de la fase 1 14/06/ /06/2004 8d de Análisis Finalización del 2 análisis e introducción a la fase 24/06/ /06/2004 5d de diseño 21

22 ACTIVIDADES DEL MES DE JULIO ID Actividades Inicio Fin Duración Jul Inicio de la fase de 1 01/07/ /07/ d diseño ID Actividades Inicio Fin Duración Jul Desarrollo de la fase de 1 19/07/ /07/ d diseño ACTIVIDADES DEL MES DE AGOSTO ID Actividades Inicio Fin Duración Aug Desarrollo de la fase de Diseño 02/08/ /08/2004 7d 2 Finalización de la Fase de Diseño 11/08/ /08/2004 3d ID Actividades Inicio Fin Duración Aug Finalización de la fase de 1 16/08/ /08/ d Diseño 22

23 1.5.2 Especificaciones La propuesta para el plan de trabajo es la siguiente: Trabajar en base a los patrones o normas de seguimiento que nos indican cómo es que se van a realizar las acciones en el desarrollo del sistema; la propuesta es la siguiente: Implementar el tiempo que resta de los 3 meses en periodos de 3 ó 4 semanas los cuales van a ser iguales en cuanto a desarrollo e investigación pero éstos tendrán como meta el poder elaborar un producto ejecutable al final del periodo donde será utilizado por el personal y posteriormente analizado tratando de hacerle mejoras. Con ésto, no se pretende decir que el ejecutable es un prototipo sino una herramienta ejecutable en constante desarrollo. Éste informe considera las actividades que se deben realizar para elaborar un sistema, se explicará cómo se debe organizar y planificar los pasos en cuanto al trabajo en equipo se refiere. En el mismo, daremos a conocer los detalles de disposición de tiempo, inversión de dinero, reuniones y tareas que cada integrante deberá realizar. Aparte de organizar las tareas por equipo también daremos a 23

24 conocer como fué todo el proceso del sistema de control de material de empaque. Planificación en equipo El Qué: Se realizará un proyecto sobre un nuevo sistema de control de material de empaque. Realizaremos el proyecto entre cuatro personas que serán los integrantes del equipo. Cómo: Para realizar el proyecto hemos decidido dividir las tareas en cuatro partes proporcionalmente iguales, en cuanto a tiempo y dinero invertido. Por esta razón trabajaremos con tres grandes bloques: 1. Búsqueda y recolección de datos e información del proyecto. 2. Análisis y redacción del proyecto. 3. Trascripción e impresión del proyecto. Con qué: Para lograr realizar el trabajo con éxito se medirá el tiempo invertido por cada integrante, para dejar el sentir de que todos trabajamos por igual y todos poseemos el conocimiento adecuado sobre el proyecto. 24

25 También compartiremos los gastos proporcionados por el proyecto en partes iguales para que el costo total sea más accesible a cada uno de los integrantes. El Porque: Se planificó de esta manera para poder tener un resultado óptimo del proyecto en cuestión, porque consideramos que dividirlo en tres grandes bloques aligera la carga de información que manejará cada uno de los integrantes y de ésta manera rendirá más al momento de emitir o cuestionar una situación dentro del que hacer de la tarea asignada. Con quien: Para lograr una efectiva planificación del proyecto hemos investigado suficiente información del tema seleccionado, para que el equipo esté preparado y tenga pleno conocimiento de todos los pasos a cumplir en esta planificación y así estar preparados en toda circunstancia al momento de exponer los informes. La definición de cómo se recabará la información, como se mencionó, se sustenta en tres grandes bloques: Búsqueda y recolección de datos e información del proyecto. Análisis y redacción del proyecto. Trascripción e impresión del proyecto. 25

26 Diseño de Presupuesto (Tiempo y Dinero): Tiempo: Búsqueda y recolección de datos e información del proyecto. (5 Horas, búsqueda por Internet y entrevista a personal que labora en empresas polar) Análisis y redacción del proyecto. (5 horas, cada reunión pautada duro aproximadamente dos hora y media) Trascripción e impresión del proyecto. (5 horas, tomando en consideración que la redacción fue modificada para mejoras). Dinero: Con respecto a la estimación del dinero aún no se ha emitido gasto alguno, por lo tanto dejaremos este rubro abierto para los informes futuros. Es importante agregar que se decidió dividir los gastos en cuatro partes iguales que es el número de integrantes del equipo que laborará en el proyecto Decisión del Proyecto En esta primera parte, es donde coordinamos con el Ing. Heriberto Gutiérrez, quién es el asesor de la estadía en la empresa para conocer más a fondo las características del proyecto a realizar. Fueron cuatro días (4 de Mayo al 7 del mismo mes del 2004) los cuales ocupamos para esta actividad. Nos explicaba en lo general, la mecánica y algunos de los problemas que tenían en diferentes 26

27 áreas y uno de los problemas que nos llamo mucho la atención fué que no había un control de las bolsas de termo-encogido que ocupan para el empaque en las cajas. Se nos hizo interesante ya que tienen que ver mucho con el material que se distribuye a diferentes partes; nos comentaba que había días en los que no sabían cuantas bolsas tenían en el almacén y por lo tanto se incrementa el número de pedidos, dando como resultado una pérdida innecesaria de material. Nos comentó que su sistema tienen como plataforma Informix por lo que llegamos a un acuerdo y propusimos un proyecto para que éste se realizara bajo el lenguaje de 4GL (Four Generation Language por su acrónimo en inglés [Lenguaje de Cuarta Generación]) ya que el sistema que ellos usan esta hecho en éste mismo lenguaje y así sería mas fácil el diseño y mantenimiento de nuestro sistema. Para el desarrollo del SISTEMA DE CONTROL DE MATERIAL DE EMPAQUE (SCME) tendremos que realizar la recopilación de información mediante entrevistas a diferente personal que tienen relación con las bolsas de termo-encogido, para conocer más acerca del procedimiento que llevan y saber quienes intervienen en la elaboración los pedidos cuando éstas se agotan. 27

28 Recopilación y Análisis de la Información En ésta actividad estuvimos realizando entrevistas al personal para conocer más a fondo el procedimiento en el uso y manejo de las bolsas de termo-encogido, fuimos a diferentes áreas para conocer el punto de vista individual y no en general, y de ésta manera conocer los detalles importantes, en el proceso. En el área de Pick Textil, entrevistamos al Sr. Felipe Sánchez quién es el encargado de esa área junto con el Sr. Heriberto Gómez y nos comentaban que sí es difícil llevar un control ya que en ésta área pesan las bolsas que reciben y con una fórmula obtienen la cantidad de bolsas que debe de haber en el paquete, pero lo cual a veces causa diferentes problemas por que pueden pesar menos o las bolsas son de diferentes tamaños lo cual produce pérdida de tiempo y por consecuente también de dinero. Nos comentaban que les dan una cantidad de bolsas y estos deben de reportar cuando se estén acabando. Después realizamos una entrevista en Pick Calzado al Sr. Martín Frausto quien nos comentaba exactamente lo mismo e incluso nos dijeron que entre ellos mismos tienen que ir intercalando las bolsas, que luego batallan con las bolsas ya que las que ocupan tienen diferentes tamaños, ya no reciben las que tienen que ser y por 28

29 consiguiente colocan otros tamaños, ajustando, ya que se terminan más rápido unas que otras. La conclusión a la que llegamos después de realizar las entrevistas fué que efectivamente no tienen un control en específico y que lo que sería más factible para ésta situación es la de elaborar un sistema que lleve el control automático de las bolsas e inclusive que genere correos electrónicos cuando las bolsas se estén agotando, tanto como para informar, como también para hacer más pedidos al proveedor Recopilación de Datos La recopilación de datos se planteó de las entrevistas hechas al personal involucrado con el sistema mencionado, dicha información se aplica a las expectativas a cubrir por parte del sistema. Esta información se manipuló de manera consultable en borradores en una primera instancia, seguido a ésto, se archivaron en pequeños documentos de información necesaria para la realización del sistema. El tiempo se dió en base a la consulta de la información conforme la necesidad a cubrir, debido a ello se mantuvo una retroalimentación constante de información durante un período de 2 semanas. 29

30 Fase de Análisis El inicio de esta etapa se da con la recopilación de la información de las entrevistas aplicadas, y con la administración de la información, con ello el análisis planteado es llegar a la realización de un sistema competitivo, adecuado a las necesidades a cubrir por el personal interesado. El tiempo empleado fue el mayor en éste punto, debido a que obtendremos la base del SISTEMA DE CONTROL DE MATERIAL DE EMPAQUE (SCME) encabezado, además de éste, podremos darle forma al primer cuerpo, sabiendo que solo se trata de información obtenida de las entrevistas, y que el fallo ó la mejoría del Sistema esta en la información. Lo anterior resalta que no solo la programación es suficiente, sino la administración, actualización y el desarrollo del Sistema, son necesarias Fase de Diseño El desarrollo de ésta etapa se implementa sobre lo que ya se tiene como base del proyecto, tomando en cuenta la documentación obtenida en los días anteriores, el desarrollo del proyecto lleva en consecuencia con el análisis final, al tener éste, habrá de ser 30

31 implementado además de la documentación, un proceso de desarrollo el cual tiende a cubrir por completo lo referente a los primeros puntos establecidos y a resolver por el proceso lento del Sistema. Culminado el análisis del proyecto iniciamos una nueva etapa, que es el Diseño. Lo primero que se hizo fué el ponernos de acuerdo en como sería la mejor forma de desarrollarlo, decidimos anexar un manual sobre 4GL que como comentamos anteriormente, es el Lenguaje de Programación el cual proponemos, ya que la plataforma del sistema que se tiene en la empresa es Informix. Como ésta Tesis trata de una propuesta, investigamos lo relativo a programación en 4GL, un 95 por ciento de los manuales que se encontraron en Internet están en Inglés e inclusive algunas bibliografías, por lo tanto tratamos de sacar lo más importante de cada Manual para que al traducirlo al Español y fuese más fácil cuidando que la interpretación de términos y algoritmos fuese la correcta. Lo segundo fué definir cómo sería el ambiente gráfico del sistema y qué pantallas llevaría para que al usuario no se le complique el uso y por lo tanto de fácil aplicación, ésta parte puede ser modificada de acuerdo a cómo se considere más conveniente. 31

32 Desarrollo de la Fase de Diseño El inicio de la etapa comprende la NOTACIÓN DE LOS DIAGRAMAS DE INTERACCIÓN, comprendiendo la manera de ilustrar el modo en el que los objetos interaccionan por medio de mensajes. Por medio de los mensajes y cuadros de texto se hace la mejor interacción entre los procesos propuestos en el caso de uso y los propuestos por el Sistema. Profundizando más en el tema, encontramos que para el CASO DE USO REAL se presenta un diseño concreto de cómo se realizará éste. Seguido de ello, continuamos con DIAGRAMAS DE CLASE DEL DISEÑO, la descripción de especificaciones de clase de software, y finalmente la creación de los mismos. El desarrollo representa todos los procesos realizados y propuestos por el Sistema, en las diversas interacciones con el personal responsable del uso. Debido a las interacciones, surgieron cambios dentro del proceso del Sistema, teniendo como consecuencia la recuperación de información, además de la corrección de la misma. 32

33 Con los cambios surgidos en el desarrollo, es comprendido aún mejor cómo la interacción del individuo con la mejoría del Sistema Es indispensable para lograr el objetivo principal y objetivos específicos Finalización de la Fase de Diseño En ésta etapa se concluyó la fase de diseño en donde se crearon los diagramas de clases del diseño (DCDs), los cuáles permiten entender bien lo que se quiere hacer en el sistema, ya que es una representación gráfica del software que se realizará. Por lo tanto, los diagramas nos mostrarán en forma gráfica, todo lo que contendrá el Sistema de Control de Material de Empaque. 33

34 CAPITULO II DESARROLLO DEL PROYECTO 34

35 2.1 Descripción Detallada del Plan de Trabajo Dentro de las herramientas metodológicas utilizadas hoy en día, se cuenta con patrones como el siguiente: El Lenguaje de Modelamiento Unificado UML (Unified Modeling Lenguaje) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son los procesos de negocio y funciones de sistema, además de cosas concretas como lo son, escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software re-usables. Es una especificación de notación orientada a objetos. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos, son los que representan la arquitectura del proyecto. UML introduce nuevos diagramas que representan una visión dinámica del sistema. Es decir, gracias al diseño de la parte dinámica del sistema, podemos darnos cuenta en la fase de diseño, de lo problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, así como del estado de cada una de las instancias en cada momento. El diagrama de clases continúa siendo muy importante, pero se debe tener en cuenta que su 35

36 representación es limitada, y que ayuda a diseñar un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagación de mensajes, ni de sincronización o recuperación ante estados de error. En resumen, un sistema debe estar bien diseñado, pero también debe funcionar bien. También intenta solucionar el problema de propiedad de código que se da con los desarrolladores, al implementar un lenguaje de modelado común para todos los desarrollos se crea una documentación también común, que cualquier desarrollador, con conocimientos de UML será capaz de entender, independientemente del lenguaje utilizado para el desarrollo. Es ahora un Standard, no existe otra especificación de diseño orientado a objetos, ya que es el resultado de las tres opciones existentes en el mercado. Su utilización es independiente del lenguaje de programación y de las características de los proyectos, ya que UML ha sido diseñado para modelar cualquier tipo de proyectos, tanto informáticos como de arquitectura, o de cualquier otro ramo. En general, UML permite la modificación de todos sus miembros mediante estereotipos y restricciones. Un estereotipo nos permite indicar especificaciones del lenguaje al que se refiere el diagrama de UML. Una restricción identifica un comportamiento forzado de una clase o relación, es decir mediante la restricción estamos 36

37 forzando el comportamiento que debe tener el objeto al que se le aplica. 37

38 FASE DE ANÁLISIS 38

39 2.1.1 Tipos de Casos de Usos y sus Formatos Los casos de usos de caja negra son la clase más común y recomendada; no describen el funcionamiento intenso del sistema, sus componentes o diseño, sino que se describe el sistema en base a las responsabilidades que tiene, que es una metáfora común y unificadora en el pensamiento orientado a objetos. Los elementos software tienen responsabilidades y colaboran con otros elementos que tienen responsabilidades. A través de la definición de las responsabilidades del sistema con casos de uso, es posible especificar qué debe hacer el sistema (los requisitos funcionales) sin decir cómo lo hará (el diseño). De hecho, la definición de análisis frente al diseño se resume algunas veces como el qué frente al cómo. Este es un tema importante en un buen desarrollo de software, evite durante el análisis de requisitos tomar decisiones acerca del como, y especifique el comportamiento externo del sistema Tipos de Formalidad Los casos de uso se escriben con formatos diferentes, dependiendo de la necesidad. Además del tipo de visibilidad los casos de uso se 39

40 escriben con varios grados de formalidad: breve, informal y completo. El caso de uso de éste sistema es de tipo completo ya que es el más elaborado. Se escriben con detalle todos los pasos y variaciones, hay secciones de apoyo como precondiciones y garantías de éxito. A continuación se presenta el caso de uso de nuestro de sistema: Caso de uso UC1: actualizar la existencia del material. Actor principal: SADS. Personal involucrado e intereses: SADS. Precondiciones: Ninguno. Garantías de éxito (Poscondiciones): se actualizó la existencia del material de empaque. Escenario principal de éxito (o flujo básico): 1.- SADS genera un corte automático de consumo diario en un horario especificado. 40

41 2.- El sistema actualiza las existencias en las ubicaciones del área de pick del material de empaque y genera una entrada en la bitácora. Extensiones (o flujos alternativos): 1.- El supervisor revisa la bitácora y se da cuenta que no se generó el corte, en ese momento genera un corte manual. 2.- El sistema actualiza la existencia del material y genera una entrada a la bitácora. Requisitos especiales El sistema deberá utilizar la tecnología existente la cual se describe como: Servidor SCO Unix INFORMIX como motor de base de datos y lenguaje de programación 4GL-4JS. Lista de tecnología y variaciones de datos: Ninguno. Frecuencia: Continuo. 41

42 Temas abiertos: Ninguno Identificación de las Clases Conceptuales El objetivo es crear un modelo del dominio de clases conceptuales interesantes y significativas del dominio de interés. En el desarrollo interactivo, permite un modelo del dominio a lo largo de varias iteraciones en la fase de elaboración. En cada una, el modelo de dominio se limita a los escenarios anteriores y actuales en estudio, en lugar de un modelo de gran explosión, que en las primeras etapas intenta capturar todas las posibles clases conceptuales y las relaciones. La tarea central es, por tanto, identificar las clases conceptuales relacionadas con el escenario que se ésta diseñando. No excluye una clase conceptual, simplemente porque los requisitos no indican ninguna necesidad obvia para registrar información sobre ella o porque la clase conceptual no tiene atributos. Es válido tener clases conceptuales sin atributos, o clases conceptuales con un rol puramente de comportamiento en el dominio, en lugar de un rol de información. 42

43 2.1.4 Estrategias para Identificar Clases Conceptuales En las siguientes secciones se presentan dos técnicas: Utilización de una lista de categorías de clases conceptuales. Identificación de frases nominales. Otra excelente técnica para el modelado del dominio, es el uso de patrones de análisis, que son modelos de dominios parciales existentes creados por expertos. En la tabla siguiente se muestra la lista de categorías conceptuales del sistema. Categoría de clase conceptual Objetos tangibles o físicos Roles de gente Otros sistemas informáticos o electromecánicos Externos al sistema Transacción Línea de transacción Proceso Ejemplos Bitácora Material de empaque Supervisor Sistema de Almacenaje Distribución Stellos Corte automático Corte manual Entrada de la bitácora Actualización de existencia 43

44 Lugares Contenedores de otras cosas Área de pick Ubicación Descubrimiento de Clases Conceptuales Mediante la Identificación de Frases Nominales Otra técnica útil recomendada, es el análisis lingüístico: identificar los nombres y frases nominales en las descripciones textuales de un dominio y considerarlos como clases conceptuales o atributos candidatos. Se debe tener cuidado con éste método; no es posible realizar una correspondencia mecánica de nombre a clases, y las palabras en lenguaje natural son ambiguas. En cualquier caso, es otra fuente de inspiración. Los casos de uso en formato completo constituyen una descripción excelente a partir de la cual extraer este análisis Modelo del Dominio del SCME La lista de clases conceptuales generadas para el dominio se podría representar gráficamente para mostrar el comienzo del Modelo del dominio. 44

45 Listado de las Clases Conceptuales: Bitácora Supervisor SCME Material de empaque SADS Corte automático Entrada en la bitácora Corte manual Actualización de existencia Ubicación Area de pick Existencias Localización de las Asociaciones En la siguiente tabla se muestran las asociaciones del sistema que vamos a emplear. 45

46 Lista de asociaciones comunes: Categoría (A) está relacionado con una transacción (B) (A) es un evento relacionado con (B) (A) es una línea de una transacción o informe de (B) (A) es una transacción relacionada con otra transacción (B) (A) es una parte física de (B) Ejemplos -Ubicación Actualización de existencia -SADS Corte automático -Material de empaque Actualización de existencia -SCME Entrada en la bitácora SCME Actualización de existencia Entrada en la bitácora bitácora Corte automático actualización de existencia Corte manual actualización de existencia Ubicación Área pick 46

47 2.1.8 Guías para las Asociaciones Céntrese en aquellas asociaciones para las que se necesita conservar el conocimiento de la relación durante algún tiempo. Es más importante identificar clases conceptuales que identificar asociaciones. Demasiadas asociaciones tienden a confundir un modelo del dominio en lugar de aclararlo. Su descubrimiento puede llevar tiempo. Con beneficio marginal. Evite mostrar asociaciones redundantes o derivadas. Roles Cada extremo de una asociación se denomina rol. Los roles pueden tener opcionalmente: Nombre. Expresión. Navegabilidad. 47

48 Multiplicidad La multiplicidad define cuántas instancias de una clase A pueden asociarse con una instancia de una clase B. El valor de la multiplicidad indica cuántas instancias se puede asociar legalmente con otra, en un momento concreto, en lugar de a lo largo de un periodo de tiempo. Estos son los valores de multiplicidad: * T Cero o más muchos 1..* T Uno o más T De uno a 40 5 T Exactamente 5 3,5,8 T Exactamente 3,5 u 8 48

49 2.1.9 Asignación de Nombres a las Asociaciones Los nombres de las asociaciones deben comenzar con una letra mayúscula, puesto que una asociación representa un clasificador de enlace de las instancias; en UML, los clasificadores deben comenzar con una letra mayúscula. Dos formatos típicos e igualmente validos para un nombre de asociación compuesta son: Pagado-mediante. Pagado Mediante. A continuación se muestra el diagrama congruente del Modelo del Dominio (Diagrama 2.1 del Tema 2.1.9). 49

50 SADS Diagrama 2.1 Genera 1 1 Corte Automático 1 crea Realiza 1 crea Supervisor 1 * Corte manual 1 Depende de 1 1 Actualización de Existencia Material de Empaque 1..* 1..* Se realiza sobre 1 Realiza 1 Existencias SCME 1 Contiene a Registra 1 Contiene a Ubicación 1 1..* Esta contenida en * Entrada en la Bitácora 1..* 1 Área de Pick 1 1 Bitácora * 50

51 Atributos Un atributo es un valor de datos lógico de un objeto. Intuitivamente, la mayoría de los atributos simples son los que, a menudo, se conocen como tipos de datos primitivos, como los números. El tipo de un atributo, normalmente, no debería de ser un concepto de dominio complejo. Los atributos deben ser, generalmente, tipos de datos. Esto es un termino UML que implica un conjunto de valores para los cuales no es significativa una identidad única. Por el contrario, es significativo distinguir (por identidad) entre dos instancias de Persona cuyos nombres son, en los dos casos, Luis García, puesto que las dos instancias pueden representar individuos diferentes con el mismo nombre. En las siguientes tablas muestra los atributos del Modelo del dominio: 51

52 Actualización de Existencia Fecha de actualización Usuario Material de Empaque Serie del producto Clave de producto Descripción Ubicación Almacén Clave del área Descripción del área Posición inicial(de ubicación) Posición final(de ubicación) Área de pick Clave del Almacén Clave del Área Posición inicial Posición final Status Del Area Existencias Existencia del artículo Status del artículo Existencia asignada del artículo Localización del artículo Subinventario de artículo PDF del articulo Almacén Período del artículo Status del artículo Entrada en la Bitácora Tipo de movimiento Folio del movimiento Número consecutivo(entrada) Fecha del movimiento Status del movimiento Artículo Cantidad Subinventario Ubicación Status PDF Período Almacén 52

53 Conclusión del Modelo del Dominio La combinación de las clases conceptuales, asociaciones y atributos, descubiertos en el estudio anterior. Da lugar al modelo que es representado en la página anterior. Se ha creado un modelo del dominio, relativamente útil, para el dominio de una aplicación, no existe un único modelo correcto. Todos los modelos son aproximaciones del dominio que estamos intentando entender. Un buen modelo del dominio, captura las abstracciones y la información esencial para entender el dominio, sus conceptos, terminología y relaciones. Vea el siguiente diagrama (Diagrama 2.2 del Tema ). 53

54 Diagrama 2.2 SADS Supervisor 1 1 Genera Realiza 1 Entrada a la Bitácora Tipo de movimiento Folio de movimiento Numero consecutivo(entrada) Fecha de movimiento Status de movimiento Articulo Cantidad Subinventario Ubicación Status PDF Período Bitácora Esta contenida en SCME 1 1 Registra 1 * Corte Automático Corte Manual Realiza * Material de Empaque Serie del artículo Clave del artículo Descripción Depende de * 1 Actualización de Existencias Fecha de actualización Usuario Se realiza sobre 1..* Existencias Existencia del artículo Status del artículo Existencia asignada del artículo Localización del artículo Subinventario del artículo PDF del artículo Almacén Período del artículo Ubicación Almacén Clave del área Descripción del Área Contiene a Posición inicial(de ubicación) Contiene a Posición final(de 1 1..* ubicación) Status del * producto Área de Pick Clave del Almacén Clave de Área Posición inicial Posición final Status del Área 54

55 Contratos Los contratos de las operaciones pueden ayudar a definir el comportamiento del sistema; describen el resultado de la ejecución de las operaciones del sistema en función de los cambios de estado de los objetos del dominio. Los casos de uso son el principal mecanismo para describir el comportamiento del sistema y, normalmente es suficiente, sin embargo, algunas veces se necesita una descripción más detallada del comportamiento de éste. Ya que los contratos describen el comportamiento detallado del sistema en función de los cambios de estado de los objetos de Modelo del Dominio, después de la ejecución de una operación Operaciones del Sistema y la Interfaz del Sistema Se pueden definir los contratos para las operaciones del sistema, como una caja negra, ofrece su interfaz pública para manejar los eventos del sistema entrantes. Sus operaciones se pueden identificar descubriendo éstos eventos, como se muestra en las tablas siguientes: 55

56 Contrato CO1: Generar Corte Automático Operación: Referencias Cruzadas: Precondiciones: Poscondiciones: Generar Corte Automático() Caso de uso: Actualizar la existencia del material. Ninguno Se creó una instancia de Corte Automático (creación de instancias). Se asoció SADS con Corte Automático (asociación formada). Se creó una instancia de Actualización de Existencia (creación de instancias). Se asoció Corte Automático con Actualización de Existencia (asociación formada). Se creó una instancia de Material de Empaque (creación de instancias). Se asoció Actualización de Existencia con Material de Empaque (creación de instancias). Se creó una instancia de SCME (creación de instancias). Se asoció Actualización de Existencia con SCME (asociación formada). Se creó la instancia de una Entrada a la Bitácora (formación de asociaciones). Se asoció SCME con Entrada a la Bitácora (asociación formada). Se creó la instancia de Bitácora (formación de asociaciones). Se asoció Entrada a la Bitácora con Bitácora (creación de instancias). Se creó la instancia de Existencias 56

57 (formación de asociaciones). Se asoció Actualización de Existencia con Existencias (creación de instancias). Existencia del Artículo pasó a ser Existencia del Artículo (modificación de atributos). Se creó la instancia de Ubicación (formación de asociaciones). Se asoció Existencias con Ubicación (creación de instancias). Se creó la instancia de Area de Pick (formación de asociaciones). Se asoció Ubicación (creación de instancias). Contrato CO2: Imprimir Bitácora Operación: Referencias Cruzadas: Precondiciones: Poscondiciones: Imprimir Bitácora (Fecha) Caso de uso. Actualizar la Existencia del Material No se Generó el Corte Automático Se creó una instancia de Bitácora (creación de instancias). Se creó una instancia de Entrada a la Bitácora (creación de instancias). Se asoció Bitácora con Entrada a la Bitácora (asociación formada). Contrato CO3: Generar Corte Manual Operación: Generar Corte Manual 57

58 Referencias Cruzadas: Precondiciones: Poscondiciones: Caso de uso. Actualizar la Existencia del Material No se Generó el Corte Automático Se creó una instancia de Corte Manual (creación de instancias). Se asoció SADS con Corte Manual (asociación formada). Se creó una instancia de Actualización de Existencia (creación de instancias). Se asoció Corte Manual con Actualización de Existencia (asociación formada). Se creó una instancia de Material de Empaque (creación de instancias). Se asoció Actualización de Existencia con Material de Empaque (creación de instancias). Se creó una instancia de SCME (creación de instancias). Se asoció Actualización de Existencia con SCME (asociación formada). Se creó la instancia de una Entrada a la Bitácora (formación de asociaciones). Se asoció SCME con Entrada a la Bitácora (asociación formada). Se creó la instancia de Bitácora (formación de asociaciones). Se asoció Entrada a la Bitácora con Bitácora (creación de instancias). Se creó la instancia de Existencias (formación de asociaciones). Se asoció Actualización de Existencia con Existencias (creación de instancias). Existencia del Artículo pasó a ser Existencia del Artículo (modificación de atributos). Se creó la instancia de Ubicación (formación de asociaciones). 58

59 Se asoció Existencias con Ubicación (creación de instancias). Se creó la instancia de Área de Pick (formación de asociaciones). Se asoció Ubicación con área de Pick (creación de instancias). 59

60 FASE DEL DISEÑO 60

61 Notación de los Diagramas de Interacción El lenguaje utilizado para ilustrar los diseños es, principalmente, en los diagramas de interacción. UML incluye los diagramas de interacción para ilustrar el modo en el que los objetos interaccionan por medio de mensajes. El término diagrama de interacción es una generalización de los dos tipos de diagramas UML más especializados; ambos pueden utilizarse para representar de forma similar interacciones de mensajes: Diagramas de colaboración Diagramas de secuencia En este caso, utilizaremos los diagramas de colaboración, para remarcar la flexibilidad en la elección. Los diagramas de colaboración ilustran las interacciones entre objetos en un formato de grafo o red, en el cual los objetos se pueden colocar en cualquier lugar de los diagramas, como se muestra a continuación: 61

62 Diagrama de secuencia: Generar Corte Automático Diagrama de secuencia: Imprimir Bitácora 62

63 Diagrama de secuencia: Generar Corte Manual Caso de Uso Real Descripción de los Casos Reales de Uso Los casos reales de uso presentan un diseño concreto de cómo se realizará el caso. 63

64 Un caso de uso real describe el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida, así como su implementación global, por ejemplo, si interviene una interfaz gráfica para el usuario, el caso de uso real incluirá diagramas de las ventanas de cuestión y una explicación de la interacción de bajo nivel con los artefactos de la interfaz. Caso de uso UC1: actualizar la existencia del material Actor principal: SADS Personal involucrado e intereses: SADS Precondiciones: ninguno Garantías de éxito (Poscondiciones): se actualizó la existencia del material de empaque. Escenario principal de éxito(o flujo básico): SADS genéra un corte automático de consumo diario en un horario especificado. 64

65 El sistema actualiza las existencias en las ubicaciones del área de Pick del material de empaque y genéra una entrada en la bitácora. Extensiones(o flujos alternativos): 1.- El supervisor selecciona la opción termoencogible en el menú principal. 2.- El supervisor imprime la bitácora en el menú imprimir (ver imagen 1.1), menú bitácora e introduce en los campos rango de fechas (ver imagen 1.2) el rango de fechas que desea saber y se da cuenta que no se generó el corte. 3.- En ese momento genera un corte manual en el menú corte manual (ver imagen1.3). 1B. El sistema actualiza la existencia del material y genera una entrada a la bitácora. Requisitos especiales El sistema deberá utilizar la tecnología existente la cual se describe como: Servidor SCO Unix 7.1.0, INFORMIX como motor de base de datos y lenguaje de programación 4GL-4JS. Lista de tecnología y variaciones de datos: Ninguno. 65

66 Frecuencia: Continuo. Temas abiertos: Ninguno. Imagen Imagen

67 Imagen Diagramas de Clases del Diseño Describe gráficamente las especificaciones de las clases de software y de las interfaces en una aplicación. Normalmente contiene la siguiente información: Clases, asociaciones y atributos. Interfaces con sus operaciones y constantes. Métodos. Información sobre los tipos de los atributos. 67

68 Navegabilidad. Dependencias. A diferencia del modelo conceptual, un diagrama de este tipo contiene las definiciones de las entidades del software en vez de conceptos del mundo real. El UML no define concretamente un elemento denominado diagrama clases del diseño, sino que sirve de un termino más genérico diagramas de clases. Cómo elaborar un diagrama de clases del diseño? 1.- Identificar todas las clases que participan en la solución del software. 2.- Dibujarlas en un diagráma de clases. 3.- Duplicar los atributos provenientes de los conceptos asociados del modelo conceptual. 4.- Agregar los nombres de los métodos analizando los diagramas de interacción. 68

69 5.- Incorporar la información sobre los tipos de los atributos a los métodos. 6.- Agregar las asociaciones necesarias para dar soporte a la visibilidad requerida de los atributos. 7.- Agregar las flechas de navegabilidad a las asociaciones para indicar la dirección de la visibilidad de los atributos. 8.- Agregar las líneas de relaciones de dependencia para indicar la visibilidad no relacionada con los atributos. 69

70 Creación de los Diagramas de Clases del Diseño (DCDs) Pagina 1 Generar Corte Automático Corte Automático SADS GenerarCorte(fecha inicial, fecha final) SolicitarInfomacion (fecha, usuario) SCME RealizarEntrada() Actualización de Existencias Fecha de Actualización Usuario ObtenerExistencias() Entrada a la Bitácora Tipo de movimiento Folio de movimiento Numero consecutivo Fecha de movimiento Status de movimiento Articulo Cantidad Subinventario Ubicación Status PDF Periodo Almacén 70

71 GenerarRegistro(fecha, usuario) Creación de los Diagramas de Clases del Diseño (DCDs) Pagina 2 Generar Corte Automático Material de Empaque Serie del articulo Clave del articulo Descripción SolicitarTiposdeMaterial Bitácora Área de Pick Clave del almacén Clave del área Posición inical Posición final Status del area PedirArea() RegistraEntrada Existencias Existencia del articulo Status del articulo Existencia asignada del articulo Localización del articulo Subinventario del articulo PDF del articulo Almacén Periodo del articulo Status del producto GenerarActualizacion (articulo, existencia) Ubicación Almacén Clave del área Descripción del área Posición inicial(de ubicación) Posición final(de ubicación) PedirUbicacion() 71

72 Creación de los Diagramas de Clases del Diseño (DCDs) Pagina 1 Imprimir Bitácora Bitácora Registrar(Fecha Entrada) Entrada a la Bitácora Tipo de movimiento Folio de Movimiento Numero consecutivo(entrada) Fecha de Movimiento Status de movimiento Articulo Cantidad Subinventario Ubicación Status PDF Período Almacén ImprimirBitácora(RangoFecha) 72

73 Creación de los Diagramas de Clases del Diseño (DCDs) Pagina 1 Generar Corte Manual Corte Manual SADS GenerarCorte(fecha inicial, fecha final) SolicitarInfomacion (fecha, usuario) SCME RealizarEntrada() Actualización de Existencias Fecha de Actualización Usuario ObtenerExistencias() Entrada a la Bitácora Tipo de movimiento Folio de movimiento Numero consecutivo Fecha de movimiento Status de movimiento Articulo Cantidad Subinventario Ubicación Status PDF Periodo Almacén 73

74 GenerarRegistro(fecha, usuario) Creación de los Diagramas de Clases del Diseño (DCDs) Pagina 2 Generar Corte Manual Material de Empaque Serie del articulo Clave del articulo Descripción SolicitarTiposdeMaterial Bitácora Área de Pick Clave del almacén Clave del área Posición inicial Posición final Status del area PedirArea() RegistraEntrada Existencias Existencia del articulo Status del articulo Existencia asignada del articulo Localización del articulo Subinventario del articulo PDF del articulo Almacén Periodo del articulo Status del producto Generar actualización (articulo, existencia) Ubicación Almacén Clave del área Descripción del área Posición inicial(de ubicación) Posición final(de ubicación) PedirUbicacion() 74

75 CAPITULO III CONCLUSIONES 75

76 3.1 Dificultades Conforme al programa y calendarización que se explicaron en el Capitulo I, específicamente en el diagrama de Gantt, se describe a continuación un listado de problemas, a los cuales nos enfrentamos y la solución propuesta a cada uno de ellos: Problema 1: la introducción a un lenguaje de modelado unificado dirigido a la programación orientada a objetos, requirió investigar sobre esta alternativa, es decir, tener que desarrollar las capacidades sobre UML y patrones, ya que era la primera vez que utilizamos éste tipo de patrones para el desarrollo de la propuesta de proyecto. Problema 2: introducción a la programación de un nuevo lenguaje, que se maneja sobre Informix, el cual se llama 4GL. Este lenguaje de cuarta generación también fué nuevo en cuanto a su aplicación ya que no se había tenido la oportunidad de trabajar con el dentro de las clases normales en la Universidad. Además de que el proyecto necesariamente tendría que desarrollarse sobre éste lenguaje, ya que en vez de la propuesta de proyecto se ampliaría el sistema actual, más adelante se explica el porqué el cambio de ampliación del sistema actual en relación a la propuesta de proyecto. 76

Diagramas De Casos De Uso

Diagramas De Casos De Uso Estáticos Diagramas De Casos De Uso Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario.. Por lo tanto los casos de uso determinan los requisitos

Más detalles

1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque:

1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque: Análisis y Diseño O.O. Preguntas del diseño : Cómo podrían asignarse responsabilidades a las clases de los objetos? Cómo podrían interactuar los objetos? Qué deberían hacer las clases? Patrones : Ciertas

Más detalles

Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Modelado - Vocabulario del Sistema

Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Modelado - Vocabulario del Sistema Modelado Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Vocabulario del Sistema Distribución de Responsabilidades Semántica de una Clase

Más detalles

Lenguaje de Modelamiento Unificado.

Lenguaje de Modelamiento Unificado. Lenguaje de Modelamiento Unificado. Pontificia Universidad Javeriana What can you Model with UML? 1. Structure Diagrams include: The Class Diagram Object Diagram Component Diagram Composite Structure Diagram

Más detalles

TEMA 4. PROCESO UNIFICADO

TEMA 4. PROCESO UNIFICADO TEMA 4. PROCESO UNIFICADO Definición El Proceso Unificado de Desarrollo Software es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura

Más detalles

CIDE, SA. RIF: J NIT: MODELO FUNCIONAL

CIDE, SA. RIF: J NIT: MODELO FUNCIONAL MODELO FUNCIONAL SIGA C O NTE NlD O Introducción Aspectos Conceptuales Definición de modelo Requisitos de un Modelo Funcional Modelando la Funcionalidad del Sistema: Diagrama de Casos de Uso Definición

Más detalles

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 1

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 1 Unidad II Metodología para resolver problemas aplicando la POO Parte 1 1 Metodología para resolver problemas aplicando la POO Fases I.Definición de requisitos II.Análisis del problema III.Diseño de solución

Más detalles

Descripción del Curso

Descripción del Curso Curso Práctico de Modelado de Negocios BPMN con UML Descripción del Curso Durante este curso aprenderás de forma práctica el estándar BPMN (Business Process Management Notation) y las extensiones de UML

Más detalles

Cristian Blanco

Cristian Blanco UNIDAD DIDÁCTICA 8. ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS. DIAGRAMAS DE COMPORTAMIENTO En el siguiente enlace tienes una descripción y algunos ejemplos de todos los diagramas UML.: http://jms32.eresmas.net/tacticos/uml/umlindex.html

Más detalles

Capítulo 16. Diagrama de Clases UML

Capítulo 16. Diagrama de Clases UML Capítulo 16. Diagrama de Clases UML Florentino TORRES M. CINVESTAV-Tamaulipas 15 de Oct del 2012 Florentino TORRES M. (CINVESTAV) 15 de Oct del 2012 1 / 70 1 Capítulo 16. Diagrama de Clases UML Aplicando

Más detalles

SERVICIO NACIONAL DE APRENDIZAJE SENA SISTEMA INTEGRADO DE GESTIÓN Procedimiento Ejecución de la Formación Profesional Integral GUÍA DE APRENDIZAJE

SERVICIO NACIONAL DE APRENDIZAJE SENA SISTEMA INTEGRADO DE GESTIÓN Procedimiento Ejecución de la Formación Profesional Integral GUÍA DE APRENDIZAJE Nº 1 1. IDENTIFICACIÓN DE LA GUIA DE APRENDIZAJE Programa de Formación: Técnico en programación de software Nombre del Proyecto: Sistema de información para la gestión empresarial Fase del proyecto: FASE

Más detalles

Tema: Herramientas UML, Análisis y diseño UML

Tema: Herramientas UML, Análisis y diseño UML Programación II. Guía 2 1 Facultad: Ingeniería Escuela: Computación Asignatura: Programación II Tema: Herramientas UML, Análisis y diseño UML Objetivo Conocer una herramienta de modelado para la solución

Más detalles

De Desempeño De Conocimiento SABERES ESENCIALES CONTENIDOS RUTA FORMATIVA Saber Conocer Nociones, Proposiciones, Conceptos Categorías

De Desempeño De Conocimiento SABERES ESENCIALES CONTENIDOS RUTA FORMATIVA Saber Conocer Nociones, Proposiciones, Conceptos Categorías Facultad Programa Académico Nombre Del Curso Administración e Ingenierias Ingenieria De Sistemas ANÁLISIS DE SISTEMAS Problema? Competencia específica Criterios de Desempeño Saber conocer Saber Ser Saber

Más detalles

TEMA 4. PROCESO UNIFICADO

TEMA 4. PROCESO UNIFICADO TEMA 4. PROCESO UNIFICADO Diseño El objetivo final del diseño es producir un Modelo Lógico del sistema a implementar. Diferencia entre Análisis y Diseño del Proceso Unificado Modelo de Análisis Modelo

Más detalles

El Lenguaje Unificado de Modelado (UML)

El Lenguaje Unificado de Modelado (UML) El Lenguaje Unificado de Modelado (UML) Enrique Hernández Orallo(ehernandez@disca.upv.es) Cualquier rama de ingeniería o arquitectura ha encontrado útil desde hace mucho tiempo la representación de los

Más detalles

Prof. Mariano Mancuso. Sistemas de información y control diagrama de clases

Prof. Mariano Mancuso. Sistemas de información y control diagrama de clases Prof. Mariano Mancuso Sistemas de información y control diagrama de clases UML Qué son los modelos? Para qué sirven los modelos? Cuáles son los modelos de UML? Se usan todos...? Qué son los modelos? Un

Más detalles

FORMACIÓN EN BUENAS PRÁCTICAS DE PROGRAMACIÓN CON PERSONAL SOFTWARE PROCESS (PSP)

FORMACIÓN EN BUENAS PRÁCTICAS DE PROGRAMACIÓN CON PERSONAL SOFTWARE PROCESS (PSP) DIPLOMADO: FORMACIÓN EN BUENAS PRÁCTICAS DE PROGRAMACIÓN CON PERSONAL SOFTWARE PROCESS (PSP) MODALIDAD DE TITULACIÓN MEDIANTE LA OPCIÓN VI : EXAMEN GLOBAL POR ÁREAS DE CONOCIMIENTO INTRODUCCIÓN La Ingeniería

Más detalles

SISTEMA DE VENTAS Y COMPRA DE TIENDA DE VESTIR SIVECO VISION. Versión 1.0 MANUEL PABLO GUERRA MARTÍNEZ.

SISTEMA DE VENTAS Y COMPRA DE TIENDA DE VESTIR SIVECO VISION. Versión 1.0 MANUEL PABLO GUERRA MARTÍNEZ. SISTEMA DE VENTAS Y COMPRA DE TIENDA DE VESTIR SIVECO VISION Versión 1.0 MANUEL PABLO GUERRA MARTÍNEZ paulo987@hotmail.com grupo S8 SIVECO,2012 Pág. 1 Tabla de Contenidos 1. Introducción 3 1.1 1.2 Propósito

Más detalles

Ingeniería a de Software CC51A

Ingeniería a de Software CC51A Ingeniería a de Software CC51A Clase Auxiliar Auxiliar: Andrés s Neyem Oficina 418 de Doctorado aneyem@dcc.uchile.cl 19 de Marzo de 2007 Aspectos Generales Grupo CC51A Diseño Cliente Requisitos Usuario

Más detalles

CLASE 4: CASOS DE USO REQUERIMIENTOS. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Martínez

CLASE 4: CASOS DE USO REQUERIMIENTOS. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Martínez CLASE 4: CASOS DE USO REQUERIMIENTOS Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Martínez Casos de Uso Un caso de uso es una descripción de las posibles secuencias de interacción entre el

Más detalles

Proceso Unificado (Iterativo e incremental)

Proceso Unificado (Iterativo e incremental) Proceso Unificado (Iterativo e incremental) Proceso Unificado de Desarrollo de Software, I. Jacobson, J. Rumbaugh y G. Booch, Addison-Wesley, 1999 Fases y Flujos de trabajo de los ciclos de vida. Disciplinas

Más detalles

FICHA PÚBLICA DEL PROYECTO

FICHA PÚBLICA DEL PROYECTO NUMERO DE PROYECTO: 218824 EMPRESA BENEFICIADA: MICROCALLI DEL GOLFO S.A DE C.V TÍTULO DEL PROYECTO: LÍNEA DE PRODUCTOS DE SOFTWARE PARA DOMÓTICA OBJETIVO DEL PROYECTO: Incorporar el paradigma de LPS como

Más detalles

Masters: Experto en Direccion y Gestion de Proyectos. Project Management

Masters: Experto en Direccion y Gestion de Proyectos. Project Management Masters: Experto en Direccion y Gestion de Proyectos. Project Management Objetivos Describir la naturaleza de un proyecto y los ciclos de vida del mismo. Presentar las fases del proceso de planificación

Más detalles

Diplomado Programación orientada a objetos con C++ y UML. Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

El Ciclo de Vida del Software

El Ciclo de Vida del Software 26/09/2013 El Ciclo de Vida del Software Grupo de Ingeniería del Software y Bases de Datos Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla septiembre 2013 Objetivos de este tema

Más detalles

Grado en Ingeniería Informática. Plan de proyecto. Desarrollo de Sistemas de Información Corporativos. Departamento de Informática

Grado en Ingeniería Informática. Plan de proyecto. Desarrollo de Sistemas de Información Corporativos. Departamento de Informática Grado en Ingeniería Informática Plan de proyecto Desarrollo de Sistemas de Información Corporativos Departamento de Informática Propósito El plan del proyecto software abarca todas las herramientas de

Más detalles

Capítulo III: MARCO METODOLÓGICO

Capítulo III: MARCO METODOLÓGICO Capítulo III: MARCO METODOLÓGICO Tipo de Investigación El presente trabajo de investigación, tuvo como propósito el desarrollo de una aplicación experimental que permitió evaluar la operatividad y funcionalidad

Más detalles

Contenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo

Contenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo Tutorial Contenido 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo 1. El proceso Fases soportadas por UML Análisis de requisitos de usuario Análisis de requisitos de software Diseño de la plataforma

Más detalles

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS 1. Nombre de la asignatura Introducción al análisis y diseño de sistemas.

Más detalles

Diplomado Logística y Administración de la Cadena de Suministro: Estrategia, Diseño y Operaciones

Diplomado Logística y Administración de la Cadena de Suministro: Estrategia, Diseño y Operaciones Diplomado Logística y Administración de la Cadena de Suministro: Estrategia, Diseño y Operaciones Duración 120 horas Objetivo general: Proporcionar al participante los conocimientos y herramientas necesarios

Más detalles

Algoritmos. Diagramas de Flujo. Informática IV. L. S. C. Heriberto Sánchez Costeira

Algoritmos. Diagramas de Flujo. Informática IV. L. S. C. Heriberto Sánchez Costeira Informática IV Algoritmos Diagramas de Flujo L. S. C. Heriberto Sánchez Costeira Algoritmos 1 Definición Es una serie finita de pasos o instrucciones que deben seguirse para resolver un problema. Es un

Más detalles

Desarrollo Orientado a Objetos en Métrica v. 3

Desarrollo Orientado a Objetos en Métrica v. 3 Desarrollo Orientado a Objetos en Métrica v. 3 Carlos Rossi Jiménez c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.1/45 Estructura del curso 1. Estructura de Métrica v. 3 2. Técnicas orientadas a

Más detalles

Requerimientos de Software

Requerimientos de Software Requerimientos de Software Ingeniería de Requerimientos Se define como el proceso de establecer los servicios que el consumidor requiere de un sistema y las restricciones sobre las cuales de funcionar

Más detalles

Diagramas de interacción

Diagramas de interacción Tema 6: Diagramas de Interacción Diagramas de interacción Los diagramas de interacción son diagramas que describen cómo grupos de objetos colaboran para conseguir algún fin. Estos diagramas muestran objetos,

Más detalles

Procedimiento para Mantenimiento de Centrales de Generación

Procedimiento para Mantenimiento de Centrales de Generación Procedimiento para Mantenimiento de Centrales de Generación Objetivo: Establecer los lineamientos para realizar las actividades necesarias para asegurar la funcionalidad de los equipos e infraestructura

Más detalles

Revisión Fecha Revisor Aprobador Descripción de los cambios M.L. J.R. Primera emisión del documento

Revisión Fecha Revisor Aprobador Descripción de los cambios M.L. J.R. Primera emisión del documento 6. GESTIÓN DEL TIEMPO Revisión Fecha Revisor Aprobador Descripción de los cambios 1 0 04 013 M.L. J.R. Primera emisión del documento 4 04 013 D.R. J.R. Revisión del documento 3 Entrega final del documento

Más detalles

ELECTIVA III. Entregables Minimos

ELECTIVA III. Entregables Minimos ELECTIVA III Entregables Minimos Entregable Descripción Sugerencias Requerido El software de trabajo, el hardware y la documentación para ser Hay más en su sistema que sólo el software que se Sistema liberada

Más detalles

Caso de uso y procedimiento para generación de cadena para factura electrónica. Febrero de 2012

Caso de uso y procedimiento para generación de cadena para factura electrónica. Febrero de 2012 Caso de uso y procedimiento para generación de cadena para factura electrónica Febrero de 2012 Tabla de Contenido Introducción 3 Definiciones 4 Simbología 5 Objetivo, alcance y políticas 6 Documentos que

Más detalles

Elementos Diagramas de Clases Clase:

Elementos Diagramas de Clases Clase: Diagramas de Clases Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes que forman parte de un sistema, junto con las relaciones existentes entre clases y objetos.

Más detalles

CAPÍTULO III ETAPA DE APLICACIÓN. La presente etapa de este trabajo de grado, describe la organización

CAPÍTULO III ETAPA DE APLICACIÓN. La presente etapa de este trabajo de grado, describe la organización CAPÍTULO III ETAPA DE APLICACIÓN 1. PLAN DE ACTIVIDADES La presente etapa de este trabajo de grado, describe la organización necesaria para proponer un laboratorio de energías alternativas para una institución

Más detalles

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 11 INGENIERÍA DEL SOFTWARE 1 Nombre: Estereotipos y valores etiquetados de los paquetes Contextualización Los estereotipos dentro de los medios de programación son más

Más detalles

4. DIAGRAMAS DE INTERACCIÓN INTRODUCCIÓN DIAGRAMAS DE SECUENCIA Objetos Mensajes

4. DIAGRAMAS DE INTERACCIÓN INTRODUCCIÓN DIAGRAMAS DE SECUENCIA Objetos Mensajes 4. DIAGRAMAS DE INTERACCIÓN...37 4.1. INTRODUCCIÓN... 37 4.2. DIAGRAMAS DE SECUENCIA... 37 4.2.1. Objetos...37 4.2.2. Mensajes...38 4.2.3. Creación y destrucción de un objeto...39 4.3. DIAGRAMAS DE COLABORACIÓN...

Más detalles

Procedimiento de Solicitud y Control de Cambios a los Sistemas Informáticos Institucionales.

Procedimiento de Solicitud y Control de Cambios a los Sistemas Informáticos Institucionales. Página 1 de 7 1. Propósito. Proveer los mecanismos necesarios para la solicitud de cambios y control de versiones a la funcionalidad de los sistemas informáticos institucionales. 2. Alcance. Aplica a los

Más detalles

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 6 Modelo de Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] 1er. CUATRIMESTRE 2006

Más detalles

Crear gráficos en Excel Un gráfico es la representación gráfica de los datos de una hoja de cálculo y facilita su interpretación.

Crear gráficos en Excel Un gráfico es la representación gráfica de los datos de una hoja de cálculo y facilita su interpretación. CREACIÓN DE GRÁFICOS EN MICROSOFT OFFICE EXCEL Vamos a ver cómo crear gráficos a partir de unos datos introducidos en una hoja de cálculo. Así resultará más sencilla la interpretación de los datos. Terminología

Más detalles

Aseguramiento de Calidad en el Desarrollo de Software Libre

Aseguramiento de Calidad en el Desarrollo de Software Libre Aseguramiento de Calidad en el Desarrollo de Software Libre Marzo, 2014 N. Baez, V. Bravo y J. Alvarez Contenido de la Presentación Segunda versión de la Metodología de Desarrollo de Software Libre. Segunda

Más detalles

Documentación de Requisitos con Casos de Uso

Documentación de Requisitos con Casos de Uso de Documentación de Requisitos con Casos de Grupo de Ingeniería del Software y Bases de Datos Universidad de Sevilla octubre 2012 de Los son historias que describen interacciones entre: Actores: personas

Más detalles

DIPLOMADO EN SISTEMAS DE GESTIÓN EN SEGURIDAD Y SALUD OCUPACIONAL OHSAS 18001

DIPLOMADO EN SISTEMAS DE GESTIÓN EN SEGURIDAD Y SALUD OCUPACIONAL OHSAS 18001 SIS DE GESTIÓN EN SEGURIDAD Y S.O. DIPLOMADO EN SIS DE GESTIÓN EN SEGURIDAD Y SALUD OCUPACIONAL OHSAS 18001 1- PRESENTACIÓN Las empresas hoy, deben responder al mercado internacional con estrategias de

Más detalles

DIAGRAMAS DE UML DIAGRAMAS DE CASO DE USO

DIAGRAMAS DE UML DIAGRAMAS DE CASO DE USO DIAGRAMAS DE UML DIAGRAMAS DE CASO DE USO Un diagrama de casos de uso es una especie de diagrama de comportamiento. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras

Más detalles

Departamento Administrativo Nacional de Estadística

Departamento Administrativo Nacional de Estadística Departamento Administrativo Nacional de Estadística Informático Oficina de Sistemas OFISIS Caracterización Informático Septiembre de 2015 CÓDIGO: -000-CP-01 PÁGINA: 1 PROCESO: Informático Descripcion del

Más detalles

Universidad Autónoma Metropolitana Unidad Azcapotzalco. División de Ciencias Básicas e Ingeniería. Licenciatura en Ingeniería en Computación

Universidad Autónoma Metropolitana Unidad Azcapotzalco. División de Ciencias Básicas e Ingeniería. Licenciatura en Ingeniería en Computación Universidad Autónoma Metropolitana Unidad Azcapotzalco División de Ciencias Básicas e Ingeniería Licenciatura en Ingeniería en Computación Propuesta de Proyecto Terminal Clasificación de servicios web

Más detalles

PMP Test C05_ El sistema de codificación de la Estructura de Desglose de Trabajo permite al equipo de proyecto:

PMP Test C05_ El sistema de codificación de la Estructura de Desglose de Trabajo permite al equipo de proyecto: PMP Test C05_01 01. El sistema de codificación de la Estructura de Desglose de Trabajo permite al equipo de proyecto: A. Estimar sistemáticamente los costes de los elementos de la Estructura de Desglose

Más detalles

Optimización del cálculo de recursos productivos para cotización en una empresa de confecciones. Sánchez Asparrín, Yván Santiago.

Optimización del cálculo de recursos productivos para cotización en una empresa de confecciones. Sánchez Asparrín, Yván Santiago. CAPITULO V 5. SOLUCION PLANTEADA 5.1 Justificación La principal idea es organizar todos los datos y tablas que se utilizan en el cálculo de consumos y además formalizar la información recibida por otras

Más detalles

Principios de Análisis Informático. Tema 3: Fase de inicio

Principios de Análisis Informático. Tema 3: Fase de inicio Principios de Análisis Informático Tema 3: Fase de inicio Eduardo Mosqueira Rey LIDIA Laboratorio de Investigación y desarrollo en Inteligencia Artificial Departamento de Computación Universidade da Coruña,

Más detalles

Procesos de la Dirección de Proyectos para un proyecto

Procesos de la Dirección de Proyectos para un proyecto Procesos de la Dirección de Proyectos para un proyecto Fuentes: Kathy Schwalbe, Information Technology Project Management, Seventh Edition, A Guide to the Project Management Body of Knowledge (PMBOK Guide),

Más detalles

Examinar y tomar acciones sobre los problemas operativos Reducir gastos y aumentar la eficiencia operativa.

Examinar y tomar acciones sobre los problemas operativos Reducir gastos y aumentar la eficiencia operativa. INDICADORES LOGÍSTICOS OBJETIVOS DE LOS INDICADORES LOGÍSTICOS Examinar y tomar acciones sobre los problemas operativos Reducir gastos y aumentar la eficiencia operativa. Evaluar el grado de competitividad

Más detalles

DISEÑO DEL SISTEMA DE INFORMACION (DSI)

DISEÑO DEL SISTEMA DE INFORMACION (DSI) DISEÑO DEL SISTEMA DE INFORMACION (DSI) El objetivo del proceso de Diseño del Sistema de Información (DSI) es la definición de la arquitectura del y del entrono tecnológico que le va a dar soporte, junto

Más detalles

MANUAL M-SGC SISTEMA DE GESTIÓN DE CALIDAD CONTROL DE CAMBIOS Y MEJORAS DESCRIPCIÓN DE LA MODIFICACIÓN Y MEJORA

MANUAL M-SGC SISTEMA DE GESTIÓN DE CALIDAD CONTROL DE CAMBIOS Y MEJORAS DESCRIPCIÓN DE LA MODIFICACIÓN Y MEJORA Hoja: 1 de 10 CONTROL DE CAMBIOS Y MEJORAS NIVEL DE REVISIÓN SECCIÓN Y PÁGINA DESCRIPCIÓN DE LA MODIFICACIÓN Y MEJORA FECHA DE MODIFICACIÓN A Todo el documento Revisión y actualización del manual 01/12/15

Más detalles

Procesos de la Dirección de Proyectos para un proyecto

Procesos de la Dirección de Proyectos para un proyecto Procesos de la Dirección de Proyectos para un proyecto Fuentes: Kathy Schwalbe, Information Technology Project Management, Seventh Edition, A Guide to the Project Management Body of Knowledge (PMBOK Guide),

Más detalles

Algoritmos y solución de problemas. Fundamentos de Programación Otoño 2008 Mtro. Luis Eduardo Pérez Bernal

Algoritmos y solución de problemas. Fundamentos de Programación Otoño 2008 Mtro. Luis Eduardo Pérez Bernal Algoritmos y solución de problemas Fundamentos de Programación Otoño 2008 Mtro. Luis Eduardo Pérez Bernal Introducción Departamento de Electrónica, Sistemas e Informática En las ciencias de la computación

Más detalles

Capítulos 2 y 5: Modelación con UML y Modelo Objeto

Capítulos 2 y 5: Modelación con UML y Modelo Objeto Capítulos 2 y 5: Modelación con UML y Modelo Objeto Agenda Recordar: Modelo de Sistema: modelo objeto + modelo funcional + modelo dinámico Ultima Clase: Modelo Objeto Definir el concepto de Modelo de Clases

Más detalles

CAPITULO V CONCLUSIONES Y RECOMENDACIONES. Índice Verificación de hipótesis Conclusiones Recomendaciones.

CAPITULO V CONCLUSIONES Y RECOMENDACIONES. Índice Verificación de hipótesis Conclusiones Recomendaciones. CAPITULO V CONCLUSIONES Y RECOMENDACIONES Índice 5.1.- Verificación de hipótesis. 5.2.- Conclusiones. 5.3.- Recomendaciones. 5.1.- Verificación de hipótesis. Hipótesis.- El diseño de un sistema de información

Más detalles

Anexo 10. Pruebas verificadas

Anexo 10. Pruebas verificadas 1 Anexo 10. Pruebas verificadas Introducción El proceso de pruebas inició con una revisión conceptual para la identificación de las pruebas por realizar, a partir de las características del proyecto. En

Más detalles

6.6 DESARROLLAR EL CRONOGRAMA

6.6 DESARROLLAR EL CRONOGRAMA Dante Guerrero-Chanduví Piura, 2015 FACULTAD DE INGENIERÍA Área departamental de Ingeniería Industrial y de Sistemas Esta obra está bajo una licencia Creative Commons Atribución- NoComercial-SinDerivadas

Más detalles

CAPÍTULO V LA PROPUESTA

CAPÍTULO V LA PROPUESTA 107 CAPÍTULO V LA PROPUESTA Modelo de control y seguimiento para la construcción de localizaciones de pozos exploratorios en la industria petrolera del occidente de Venezuela 1. Conceptualizacion El modelo

Más detalles

Procedimiento para la Gestión del Clima Laboral

Procedimiento para la Gestión del Clima Laboral Procedimiento para la Gestión del Clima Laboral Objetivo: Establecer los lineamientos para identificar los factores de observación, la definición de encuestas, recopilación, procesamiento, análisis y planes

Más detalles

Nombre de la asignatura: Simulación. Créditos: Aportación al perfil

Nombre de la asignatura: Simulación. Créditos: Aportación al perfil Nombre de la asignatura: Simulación Créditos: 2-4-6 Aportación al perfil Analizar, diseñar y gestionar sistemas productivos desde la provisión de insumos hasta la entrega de bienes y servicios, integrándolos

Más detalles

PROCESO DE MANTENIMIENTO PREVENTIVO OPERACIONES

PROCESO DE MANTENIMIENTO PREVENTIVO OPERACIONES 1. PROPÓSITO. Describir los procesos de de infraestructura, periféricos y equipos dentro de las estaciones y en el carril confinado, especificando también los procedimientos de control que le competen.

Más detalles

Acta de Constitución del Proyecto. Desarrollo de un Sistema de gestión para la seccional del UETD Liceo Caracas

Acta de Constitución del Proyecto. Desarrollo de un Sistema de gestión para la seccional del UETD Liceo Caracas Acta de Constitución del Desarrollo de un Sistema de gestión para la seccional del UETD Liceo Caracas Versión 2.0 Profesor: Elías Oswaldo Cisneros Arocha Trayecto III Trimestre I Unidad Curricular: Sociotecnológico

Más detalles

Casos de Uso. Introducción. Actores

Casos de Uso. Introducción. Actores Casos de Uso Introducción Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Representan las funciones que un sistema puede ejecutar. Por tanto

Más detalles

Universidad Técnica del Norte FACULTAD DE INGENIERIA EN CIENCIAS APLICADAS CARRERA DE INGENIERIA EN MECATRÓNICA

Universidad Técnica del Norte FACULTAD DE INGENIERIA EN CIENCIAS APLICADAS CARRERA DE INGENIERIA EN MECATRÓNICA Universidad Técnica del Norte FACULTAD DE INGENIERIA EN CIENCIAS APLICADAS CARRERA DE INGENIERIA EN MECATRÓNICA DATOS GENERALES 1. TEMA: ANTEPROYECTO DE TRABAJO DE GRADO 2. AREA/LINEA DE INVESTIGACION:

Más detalles

PRONÓSTICO DE VENTAS CORTO PLAZO MÓDULO COLABORATIVO DE CONTROL DE METAS DE VENTAS

PRONÓSTICO DE VENTAS CORTO PLAZO MÓDULO COLABORATIVO DE CONTROL DE METAS DE VENTAS PRONÓSTICO DE VENTAS CORTO PLAZO MÓDULO COLABORATIVO DE CONTROL DE METAS DE VENTAS Aunque se trabaje con un proceso de Presupuesto de Ventas para un periodo determinado, es necesario validar con la fuerza

Más detalles

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS.

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS. TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS. HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS 1. Nombre de la asignatura Ingeniería de

Más detalles

BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA

BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA Contenido Una metodología para el desarrollo de software debe ser un instrumento que permita gestionar un proceso dado, existen hoy

Más detalles

Taller: Planificación con Matriz de Marco Lógico. Vólker Gutiérrez Aravena Presidente Cultura Mapocho

Taller: Planificación con Matriz de Marco Lógico. Vólker Gutiérrez Aravena Presidente Cultura Mapocho Taller: Planificación con Matriz de Marco Lógico Vólker Gutiérrez Aravena Presidente Cultura Mapocho Elementos centrales de la Planificación Estratégica Qué es? Una poderosa herramienta de diagnóstico,

Más detalles

CAL Todo el temario está organizado de acuerdo a la secuencia de los contenidos tanto conceptuales como prácticos de la asignatura.

CAL Todo el temario está organizado de acuerdo a la secuencia de los contenidos tanto conceptuales como prácticos de la asignatura. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos) SATCA 1 Planeación Estratégica. Ingeniería Industrial CAL-1302 4 1 5 2.- PRESENTACIÓN Caracterización de

Más detalles

El Análisis de Correspondencias tiene dos objetivos básicos:

El Análisis de Correspondencias tiene dos objetivos básicos: Tema 8 Análisis de correspondencias El Análisis de Correspondencias es una técnica de reducción de dimensión y elaboración de mapas percentuales. Los mapas percentuales se basan en la asociación entre

Más detalles

INGENIERÍA DEL SOFTWARE I Práctica 5 Modelado de Diseño

INGENIERÍA DEL SOFTWARE I Práctica 5 Modelado de Diseño INGENIERÍA DEL SOFTWARE I Práctica 5 Modelado de Diseño Univ. Cantabria Fac. de Ciencias Patricia López Introducción al Diseño Modelamos la estructura software del sistema (incluida la arquitectura) para

Más detalles

PROCEDIMIENTO PARA LA INSTAURACION DEL PROCESO DE MEJORA CONTINUA

PROCEDIMIENTO PARA LA INSTAURACION DEL PROCESO DE MEJORA CONTINUA S I S T E M A D E G E S T I Ó N D E C A L I D A D CODIGO EDICION NIVEL DE REVISION FECHA DE EMISION 0 FEBRERO 010 NIVEL DE REVISION CONTROL DE MODIFICACIONES ACTUALIZACIONES Y MEJORAS CAUSA DE LA DESCRIPCION

Más detalles

L/O/G/O Tema: Integrantes:

L/O/G/O Tema: Integrantes: L/O/G/O Tema: FORMULACIÓN DE UN SISTEMA DE GESTIÓN DE SERVICIOS DE TI SIGUIENDO LA METODOLOGÍA ITIL Integrantes: TASAYCO REYES FREDY ATACHAGUA AQUIJE DIANA INDICE Resumen Ejecutivo Introducción 1. Planteamiento

Más detalles

En GSG Petroleum le brindamos soluciones tecnológicas personalizadas. de toma de decisiones.

En GSG Petroleum le brindamos soluciones tecnológicas personalizadas. de toma de decisiones. En GSG Petroleum le brindamos soluciones tecnológicas personalizadas que le ayudarán en el proceso de toma de decisiones. Somos una firma que le ofrece soluciones en el área de Tecnologías de la Información

Más detalles

Diagramas de secuencia

Diagramas de secuencia Facultad de Ingeniería Departamento de Ingeniería de Sistemas y Computación Diagramas de secuencia Interacciones básicas 1 Para qué sirven los diagramas de secuencia? 2 Para qué sirven los diagramas de

Más detalles

INDUSTRIAL DE ALIMENTOS FLÓREZ Y CÍA. S.A.S. INDUCCIÓN ESPECÍFICA DEL PERSONAL ADMINISTRATIVO

INDUSTRIAL DE ALIMENTOS FLÓREZ Y CÍA. S.A.S. INDUCCIÓN ESPECÍFICA DEL PERSONAL ADMINISTRATIVO Página 1 de 8 1. OBJETIVO Dar las pautas para la inducción específica del personal administrativo, con el fin de orientar al colaborador y de realizar su entrenamiento en el puesto de trabajo. 2. ALCANCE

Más detalles

Estructuras Administrativas

Estructuras Administrativas Estructuras Administrativas ESTRUCTURAS ADMINISTRATIVAS 1 Sesión No. 7 Nombre: Diagramas de Flujo Objetivo: El estudiante desarrollará la propuesta de un diagrama de flujo para la especificación de la

Más detalles

GUÍA PARA INICIATIVAS DE EVALUACIÓN ESTRATÉGICA DE INTERVENCIONES (POLÍTICAS, PLANES, PROGRAMAS Y PROYECTOS) EN EL SECTOR PÚBLICO 1

GUÍA PARA INICIATIVAS DE EVALUACIÓN ESTRATÉGICA DE INTERVENCIONES (POLÍTICAS, PLANES, PROGRAMAS Y PROYECTOS) EN EL SECTOR PÚBLICO 1 GUÍA PARA INICIATIVAS DE EVALUACIÓN ESTRATÉGICA DE INTERVENCIONES (POLÍTICAS, PLANES, PROGRAMAS Y PROYECTOS) EN EL SECTOR PÚBLICO 1 La Guía para iniciativas de evaluación estratégica de intervenciones

Más detalles

Diseño del proceso de lubricación - (LPD)

Diseño del proceso de lubricación - (LPD) Diseño del proceso de lubricación - (LPD) Fase II - Diseño detallado Definición: La fase II del LPD consiste en el diseño detallado de las mejoras y de las modificaciones de cada una de las máquinas de

Más detalles

GUÍA PARA LA PRESENTACIÓN DE PROPUESTAS DE TESIS Y PROYECTOS DE GRADO

GUÍA PARA LA PRESENTACIÓN DE PROPUESTAS DE TESIS Y PROYECTOS DE GRADO UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA GUÍA PARA LA PRESENTACIÓN DE PROPUESTAS DE TESIS Y PROYECTOS DE GRADO CONTENIDO Apartes del documento

Más detalles

Introducción a la Estrategia

Introducción a la Estrategia 1. Planeación estratégica Pet & Beyond 1.1. Giro de la empresa Pet & Beyond es una empresa que se dedica a: Ofrecer una experiencia integral (salud, diversión, alimentación, etc) para las mascotas y sus

Más detalles

ELABORACIÓN DE DOCUMENTOS

ELABORACIÓN DE DOCUMENTOS 1. PROPÓSITO. Establecer las directrices para elaborar los s del Sistema Gestión de la Calidad del Sistema DIF Sinaloa, su estructura y formato, con el fin de estandarizar su edición de acuerdo a los requerimientos

Más detalles

FUNCIONES DE LA JEFATURA

FUNCIONES DE LA JEFATURA FUNCIONES DE LA JEFATURA Coordinar el desarrollo general de URBANÍSTICA -Taller del Espacio Público. 2 Definir y establecer las metas propuestas dentro del Taller. 3 Realizar la toma de decisión relacionadas

Más detalles

DESCRIPCIÓN PROJECT PRO FOR OFFICE 365

DESCRIPCIÓN PROJECT PRO FOR OFFICE 365 DESCRIPCIÓN PROJECT PRO FOR OFFICE 365 Project para Office 365 Obtén el control y las capacidades de Project Professional 2016 desde prácticamente cualquier lugar en forma de suscripción de escritorio

Más detalles

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 10 Modelo Dinámico Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] 1er. CUATRIMESTRE

Más detalles

Diseño. Diseño. Interacción. Aspectos comunes en interacción. Diagramas de Interacción. Curso de Arquitecturas de Software

Diseño. Diseño. Interacción. Aspectos comunes en interacción. Diagramas de Interacción. Curso de Arquitecturas de Software Curso de Arquitecturas de Software Programación Orientada a Objetos Diagramas de Interacción Diseño En la fase de diseño se hace refinamiento estructural, se modifica y completa el diagrama de clases del

Más detalles

- Interpretar los requisitos a cumplir de las BPM con el aporte de otros modelos que se han venido desarrollando para alcanzar la excelencia.

- Interpretar los requisitos a cumplir de las BPM con el aporte de otros modelos que se han venido desarrollando para alcanzar la excelencia. SISTEMAS INTEGRADOS DE GESTIÓN ISO 9001, ISO 14001, OSHAS 18001 E ISO 17025 PARA LA INDUSTRIA FARMACEÚTICA Y AFINES 1- PRESENTACIÓN El desarrollo de modelos de los sistemas integrados de gestión en las

Más detalles

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES SYLLABUS DE INGENERIA DE SOFTWARE I

CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES SYLLABUS DE INGENERIA DE SOFTWARE I Facultad de Ingeniería en Ciencias Aplicadas pag. 1 CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES SYLLABUS DE INGENERIA DE SOFTWARE I 1. Misión: (de la carrera) La Carrera de Ingeniería en Sistemas

Más detalles

MODELADO DE CASOS DE USO (Libro UML 2-Arlow & Neustad)

MODELADO DE CASOS DE USO (Libro UML 2-Arlow & Neustad) MODELADO DE CASOS DE USO (Libro UML 2-Arlow & Neustad) Determinar el límite de un sistema: en primer lugar se necesita decidir que es parte del sistema (dentro de los límites del sistema) y que es externo

Más detalles

Planificación de la Evaluación. Dirección General de Salud de las Personas Dirección de Calidad en Salud

Planificación de la Evaluación. Dirección General de Salud de las Personas Dirección de Calidad en Salud Planificación de la Evaluación Dirección General de Salud de las Personas Dirección de Calidad en Salud Evaluación de la Calidad La evaluación de la calidad, es un proceso fundamental del componente de

Más detalles

Ingeniería de Requerimientos. requiere de un Sistema de Software.

Ingeniería de Requerimientos. requiere de un Sistema de Software. Ingeniería de uestableciendo lo que el cliente requiere de un Sistema de Software. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 1 Objetivos u Introducción a la Noción

Más detalles

Soluciones Tecnológicas Integrales

Soluciones Tecnológicas Integrales Soluciones Tecnológicas Integrales OBJETIVO Ofrecer soluciones Integrales de Tecnología, en los ámbitos de Sistemas, electricidad, seguridad y telecomunicaciones para satisfacer las necesidades empresariales

Más detalles

Objetivos. Plan. Cambios de grupos Prof. sustituto: Alicia Villanueva

Objetivos. Plan. Cambios de grupos Prof. sustituto: Alicia Villanueva Ingeniería de Requerimientos Prácticas Curso 2007/08 Objetivos Aprender el manejo de una herramienta avanzada para el desarrollo rápido de prototipos: Visual Prolog Plan Semana 1: Recomendaciones IEEE

Más detalles