52247996-memoria-amalia

5/11/2018 52247996-Memoria-Amalia - slidepdf.com

http://slidepdf.com/reader/full/52247996-memoria-amalia 1/144

INSTITUTO TECNOLÓGICOSUPERIOR DE MISANTLA

“SISTEMA DE CONTROLPRESUPUESTAL”

MEMORIA DE RESIDENCIAPROFESIONAL

LÓPEZ GONZÁLEZ ISIS IMELDARIVERA CARRERA AMALIA BEATRIZ

ASESOR: LIC. JOSÉ ANTONIO HIRAM VÁZQUEZLÓPEZ

MISANTLA, VERACRUZ 2009

Q U E P A R A O B T E N E R E L T Í T U L O D E

ING. EN SISTEMAS COMPUTACIONALESP R E S E N T A N



AGRADECIMIENTOS

Isis

A DIOS

Por permitirme terminar mi

carrera profesional, y culminar esta

etapa de mi vida. Por darme unos

padres maravillosos que me han

brindado la oportunidad de ser una

persona con profesión. Por la vida que

A MIS PADRES

Por el apoyo incondicional que me

ofrecieron durante mi carrera profesional y

alentarme con ánimos de superación.

Por brindarme su comprensión

confianza, amor y amistad, por que sin su

apoyo no hubiera sido posible la culminación

de mi carrera profesional. En especial a m

madre por creer en mí y apoyarme en todo

momento, por los esfuerzos y sacrificios que

hizo para lograr que fuera una profesionista,

por lo que se gano en mi una gran admiración.

A MI ABUELA

Por encomendarme siempre a

dios a lo largo de mi carrera, con la

esperanza de que superara lasdificultades que se me presentaron en

mi etapa estudiantil. Por sus consejos

para motivarme a seguir adelante y así

concluir mi carrera.



A Dios.

Por permitirme gozar de este momento,

la culminación de mi carrera profesional.

A Mi Familia.

Por ser unas personas de luz en mi vida.

Que hicieron lo imposible para que yo pudiera terminar mis estudios.

Por su apoyo incondicional.

A Mis Maestros.

En especial a mis asesores de Memoria de Residencia Profesional,

por hacer posible la elaboración de este documento.

Evidentemente a todos mis maestros,

por compartir generosamente su conocimiento y experiencia.

Amalia Beatriz



INDICE

INDICE........................................................................................................................vi

INDICE DE FIGURAS................................................................................................xiiINDICE DE TABLAS...............................................................................................xvii

INTRODUCCIÓN.........................................................................................................1

1.1. PLANTEAMIENTO DEL PROBLEMA..................................................................4

1.2. OBJETIVOS GENERALES Y ESPECIFICOS......................................................6

1.2.1.Objetivo General.........................................................................................6

1.2.2.Objetivos Específicos..................................................................................6

1.3. CARACTERIZACIÓN DEL ÁREA DONDE SE PARTICIPÓ................................7

1.3.1.Antecedentes..............................................................................................7

1.3.2.Misión..........................................................................................................8

1.3.3.Política de Calidad.......................................................................................8

1.3.4.Valores........................................................................................................9

1.3.5.Servicios......................................................................................................9

1.3.6.Situación Geográfica...................................................................................9

1.3.7.Infraestructura..........................................................................................10

1.3.8.Astillero.....................................................................................................11

1.3.9.Equipo.......................................................................................................12

..........................................................................................................................12

1.3.10.Departamento de Planeación Financiera................................................12

1.4. JUSTIFICACIÓN..................................................................................................15

1.5. ALCANCES Y LIMITACIONES...........................................................................16

1.5.1.Alcances....................................................................................................16

1.5.2.Limitaciones..............................................................................................16

vi



2.1. INGENIERÍA DE SOFTWARE............................................................................18

2.1.1Metodología...............................................................................................18

2.1.2Modelos de procesos del software.............................................................21

2.2. INGENIERÍA DE REQUERIMIENTOS................................................................22

2.2.1.Requerimiento..........................................................................................22

2.2.2.Tipos de Requerimientos...........................................................................23

2.2.2.1.Requerimientos de Usuario.................................................................23

2.2.2.1. Requerimientos de Usuario........................................................................23

2.2.2.2.Requerimientos del Sistema...............................................................24

2.2.2.2. Requerimientos del Sistema.......................................................................242.2.3.Características de un Requerimiento........................................................25

2.2.4.Dificultades para definir los requerimientos.............................................25

2.2.5.Actividades de la Ingeniería de Requerimientos.......................................26

2.2.5.1.Extracción de Requisitos.....................................................................26

2.2.5.1. Extracción de Requisitos............................................................................26

2.2.5.2.Análisis y Negociación de Requisitos..................................................28

2.2.5.2. Análisis y Negociación de Requisitos.......................................................28

2.2.5.3.Especificación de Requisitos...............................................................30

2.2.5.3. Especificación de Requisitos.....................................................................30

2.2.5.4.Modelado del sistema.........................................................................30

2.2.5.4. Modelado del sistema..................................................................................30

2.2.5.5.Validación de requisitos......................................................................31

2.2.5.5. Validación de requisitos..............................................................................31

2.2.5.6.Gestión de requisitos..........................................................................32

2.2.5.6. Gestión de requisitos..................................................................................32

2.2.6.Técnicas utilizadas en las actividades de IR..............................................33

vii



2.2.6.1.Entrevistas y Cuestionarios.................................................................34

2.2.6.1. Entrevistas y Cuestionarios.......................................................................34

2.2.6.2.Sistemas existentes............................................................................34

2.2.6.2. Sistemas existentes.....................................................................................34

2.2.6.3.Lluvia de ideas (Brainstorm)...............................................................35

2.2.6.3. Lluvia de ideas (Brainstorm)......................................................................35

2.2.6.4.Prototipos...........................................................................................35

2.2.6.4. Prototipos.....................................................................................................35

2.2.6.5.Casos de Uso......................................................................................36

2.2.6.5. Casos de Uso...............................................................................................36

2.3. MODELADO DE LENGUAJE UNIFICADO (UML).............................................37

2.3.1.Vista General de UML................................................................................37

2.3.2.Elementos.................................................................................................39

2.3.2.1.Elementos estructurales.....................................................................39

2.3.2.1. Elementos estructurales.............................................................................39

2.3.2.2.Elementos de comportamiento...........................................................42

2.3.2.2. Elementos de comportamiento..................................................................42

2.3.2.3.Elementos de agrupación...................................................................43

2.3.2.3. Elementos de agrupación...........................................................................43

2.3.2.4.Elementos de anotación.....................................................................44

2.3.2.4. Elementos de anotación..............................................................................44

2.3.3.Relaciones.................................................................................................44

2.3.4.Diagramas.................................................................................................45

2.3.4.1.Diagramas de Estructura....................................................................46

2.3.4.1. Diagramas de Estructura............................................................................46

2.3.4.2.Diagramas de Comportamiento..........................................................52

viii



2.3.4.2. Diagramas de Comportamiento.................................................................52

2.3.4.3.Diagramas de Interacción...................................................................57

2.3.4.3. Diagramas de Interacción...........................................................................57

2.3.5.Visual Paradigm for UML...........................................................................58

2.4 DISEÑO.................................................................................................................61

2.4.1Diccionario de Datos..................................................................................61

2.4.2Modelo Entidad-Relación............................................................................61

2.4.2.1Base Teórica y Conceptual..................................................................62

2.4.2.1 Base Teórica y Conceptual..........................................................................62

2.4.3Diagramas Extendidos...............................................................................67

3.1 ANÁLISIS.............................................................................................................71

3.1.1Extracción de Requisitos............................................................................71

3.1.2Análisis y Negociación de Requisitos.........................................................73

3.1.3Especificación de Requisitos......................................................................73

3.1.3.1Propósito de los requerimientos..........................................................74

3.1.3.1 Propósito de los requerimientos.................................................................743.1.3.2 Alcance del sistema............................................................................74

3.1.3.2 Alcance del sistema.....................................................................................74

3.1.3.3 Referencias.........................................................................................75

3.1.3.3 Referencias...................................................................................................75

3.1.3.4 Perspectiva del sistema......................................................................75

3.1.3.4 Perspectiva del sistema..............................................................................753.1.3.5 Funciones del sistema........................................................................75

3.1.3.5 Funciones del sistema................................................................................75

3.1.3.6Características del usuario...................................................................76

3.1.3.6 Características del usuario..........................................................................76

ix



3.1.3.7 Requerimientos de Usuario.................................................................76

3.1.3.7 Requerimientos de Usuario........................................................................76

3.1.3.8 Requerimientos Funcionales...............................................................79

3.1.3.8 Requerimientos Funcionales......................................................................79

3.1.3.9 Requerimientos No Funcionales..........................................................81

3.1.3.9 Requerimientos No Funcionales................................................................81

3.1.4Modelado del Sistema................................................................................82

3.1.4.1Visual Paradigm for UML......................................................................82

3.1.4.1 Visual Paradigm for UML.............................................................................82

3.1.5Validación de Requisitos............................................................................99

3.2 DISEÑO..............................................................................................................100

3.2.1Modelo Entidad-Relación..........................................................................100

3.2.2Modelo Relacional....................................................................................101

.........................................................................................................................101

3.2.3Diccionario de Datos................................................................................101

3.2.4Diseño de Pantallas..................................................................................104

112

114

115

116

116

117

117

118

121

121

x



122

CONCLUSIONES Y RECOMENDACIONES..........................................................122

REFERENCIAS.......................................................................................................125

GLOSARIO..............................................................................................................126

xi



INDICE DE FIGURAS

Figura 1.1 Talleres Navales del Golfo........................................................................7

Figura 1.2 Ubicación Geográfica..............................................................................10

Figura 1.3 Infraestructura TNG.................................................................................11

Figura 1.4 Área donde se realizó Residencia Profesional.....................................12

Figura 1.5 Equipo.......................................................................................................12

Figura 2.1 Vista General de UML..............................................................................39

Figura 2.2 Clase Ventana..........................................................................................40

Figura 2.3 Interfaz......................................................................................................40

Figura 2.4 Colaboración Cadena de responsabilidades........................................41

Figura 2.5 Caso de Uso.............................................................................................41

Figura 2.6 Clase activa..............................................................................................42

Figura 2.7 Componente.............................................................................................42

Figura 2.8 Nodo Servidor..........................................................................................42

Figura 2.9 Interacción................................................................................................43Figura 2.10 Máquina de estados...............................................................................43

Figura 2.11 Agrupación reglas del negocio............................................................44

Figura 2.12 Anotación................................................................................................44

Figura 2.13 Jerarquía de los diagramas UML 2.0, mostrados como un diagramade clases.....................................................................................................................46

Figura 2.14 Diagrama de Clases...............................................................................48

Figura 2.15 Diagrama de Componentes..................................................................49

Figura 2.16 Diagrama de Objetos.............................................................................50

Figura 2.17 Diagrama de Despliegue.......................................................................51

Figura 2.18 Diagrama de paquetes...........................................................................52

xii



Figura 2.19 Diagrama de Actividades......................................................................53

Figura 2.20 Diagrama de Casos de Uso..................................................................54

Figura 2.21 Diagrama de estados.............................................................................56

Figura 2.22 Diagrama de secuencia.........................................................................58

Figura 3.1 Estructura actual del Reporte Mensual de Variaciones......................72

Figura 3.2 Justificación de Solicitud de Presupuesto...........................................73

Figura 3.3 Solicitud de Presupuesto........................................................................73

Figura 3.4 Requerimiento BD Presupuestos vs Actuales.....................................78

Figura 3.5 Requerimiento BD Techos de Compra..................................................78

Figura 3.6 Flujo de Información................................................................................79

Figura 3.7 Diagrama de Casos de Usos..................................................................83

Figura 3.8 Diagrama de secuencia Inicio de sesión...............................................84

Figura 3.9 Diagrama de secuencia Consulta de Reporte de Variaciones............84

Figura 3.10 Diagrama de secuencia Consulta de Variaciones paraAdministrador.............................................................................................................85

Figura 3.11 Captura de presupuesto por parte del usuario..................................85

Figura 3.12 Agregar cuenta.......................................................................................86

Figura 3.13 Diagrama de secuencia de consulta de Consolidado Maestro........86

Figura 3.14 Diagrama de secuencia Consulta de Catálogo de cuentas..............87

Figura 3.15 Diagrama de secuencia Modifica Presupuesto..................................88

Figura 3.16 Diagrama de Estado Presupuesto.......................................................89

Figura 3.17 Diagrama de Estado de Variación........................................................90

Figura 3.18 Diagrama de Estado de Cuentas..........................................................91

Tabla 3.1 Caso de Uso Consulta de Reporte de Variaciones................................92

Tabla 3.2 Caso de Uso Captura de Presupuesto....................................................93

Tabla 3.3 Caso de Uso Agregar cuenta...................................................................94

xiii



Tabla 3.4 Caso de Uso Consulta de Consolidado Maestro...................................95

Tabla 3.5 Caso de Uso Consulta de Catálogo de Cuentas....................................96

Tabla 3.6 Caso de Uso Modifica Presupuesto........................................................97

98

Figura 3.19 Diagrama de Clases...............................................................................98

Figura 3.20 Modelo Entidad-Relación....................................................................100

Figura 3.21 Modelo Relacional...............................................................................101

Tabla 3.7 Diccionario de Datos Tabla Usuario......................................................102

Tabla 3.8 Diccionario de Datos Tabla Centro_Costo..........................................102

Tabla 3.9 Diccionario de Datos Tabla Cuentas.....................................................102

Tabla 3.10 Diccionario de Datos Tabla Techos_Compra.....................................103

Tabla 3.11 Diccionario de Datos Tabla Administrador........................................103

Tabla 3.12 Diccionario de Datos Tabla Contiene..................................................103

Tabla 3.13 Diccionario de Datos Tabla Presupuesto...........................................104

Tabla 3.14 Diccionario de Datos Tabla Solicita....................................................104

Figura 3.22 Pantalla de inicio de sesión................................................................105

Figura 3.23 Sesión de Administrador....................................................................106

Figura 3.24 Sesión de usuario común...................................................................107

Figura 3.25 Menú desplegable sesión Usuario.....................................................107

Figura 3.26 Menú desplegable de sesión Administrador....................................108

Figura 3.27 Menú Usuarios de sesión Administrador..........................................108

Figura 3.28 Opciones de Agregar usuario............................................................108

Figura 3.29 Agregar usuario Administrador.........................................................109

Figura 3.30 Mensaje de información Agregar administrador..............................109

Figura 3.31 Registro de usuario de centro de costo............................................109

xiv



Figura 3.32 Eliminar usuario...................................................................................110

Figura 3.33 Menú Catálogos...................................................................................110

Figura 3.34 Opciones para Centros de Costo......................................................111

Figura 3.35 Buscar centro de costo por rubro....................................................111

Figura 3.36 Opciones de Búsqueda para Centros de Costo..............................112

112

Figura 3.37 Agregar Centro de Costo....................................................................112

Figura 3.38 Modificar centro de costo...................................................................113

Figura 3.39 Eliminar centro de costo.....................................................................113

Figura 3.40 Mensaje de confirmación....................................................................114

Figura 3.41 Agregar cuenta.....................................................................................114

Figura 3.42 Modificar, Eliminar cuenta..................................................................115

115

Figura 3.43 Consulta de Catálogo de Cuentas.....................................................115

Figura 3.44 Modifica Presupuesto..........................................................................116

Figura 3.45 Realizar movimiento............................................................................116

Figura 3.46 Reporte de Variaciones.......................................................................117

Figura 3.47 Bitácora de Movimientos....................................................................117

Figura 3.48 Consulta Techos de Compra..............................................................118

Figura 3.49 Solicitud de Presupuesto....................................................................118

Figura 3.50 Agregar cuentas a solicitud de Presupuesto ..................................119

Figura 3.51 Cuentas de Solicitud...........................................................................120

Figura 3.52 Justificación de solicitud....................................................................120

Figura 3.53 Vista previa de solicitud......................................................................121

Figura 3.54 Catálogo de cuentas de Usuario de CC............................................121

xv



Figura 3.55 Confirmación Cerrar Sesión...............................................................122

xvi



INDICE DE TABLAS

Tabla 3.1 Caso de Uso Consulta de Reporte de VariacionesError: Reference source

not found

Tabla 3.2 Caso de Uso Captura de Presupuesto . .Error: Reference source not found

Tabla 3.3 Caso de Uso Agregar cuenta ................Error: Reference source not found

Tabla 3.4 Caso de Uso Consulta de Consolidado Maestro ....Error: Reference source

not found

Tabla 3.5 Caso de Uso Consulta de Catálogo de Cuentas ....Error: Reference source

not found

Tabla 3.6 Caso de Uso Modifica Presupuesto ......Error: Reference source not found

Tabla 3.7 Diccionario de Datos Tabla Usuario .....Error: Reference source not found

Tabla 3.8 Diccionario de Datos Tabla Centro_Costo .....Error: Reference source not

found

Tabla 3.9 Diccionario de Datos Tabla Cuentas ....Error: Reference source not found

Tabla 3.10 Diccionario de Datos Tabla Techos_Compra Error: Reference source not

found

Tabla 3.11 Diccionario de Datos Tabla Administrador ...Error: Reference source not

found

Tabla 3.12 Diccionario de Datos Tabla Contiene . Error: Reference source not found

Tabla 3.13 Diccionario de Datos Tabla Presupuesto ......Error: Reference source not

found

Tabla 3.14 Diccionario de Datos Tabla Solicita ....Error: Reference source not found

xvii



INTRODUCCIÓN

Este documento se divide en tres capítulos, uno dedicado a la descripción general del

proyecto (caracterización del área donde se participó, planteamiento del problema, objetivos,

justificación, entre otros), en el capitulo dos se detalla el Fundamento Teórico y por último en

el capitulo tres, la realización del Análisis y Diseño del Sistema de “Control Presupuestal”.

Dicho documento tiene como finalidad presentar la labor realizada durante el período

de Residencia Profesional, donde en este caso, se llevo a cabo en un astillero, Talleres

Navales del Golfo S.A. de C.V. (TNG) de la ciudad de Veracruz.

TNG es un astillero que cuenta con infraestructura para proporcionar un servicio

completo para reparación de todo tipo de embarcaciones, fabricación de módulos costa

fuera, así como conversiones de barcos y plataformas autoelevables o semisumergibles.

Dentro de este organismo se encontró una problemática donde se trato de

proporcionar una solución satisfactoria al cliente. En el departamento de Planeación

Financiera se llevaba un control bastante laborioso como es el del presupuesto, donde

también intervienen otros departamentos. Aquí se dio a la tarea de realizar el análisis para la

elaboración del Sistema de “Control Presupuestal”, el cual tendrá múltiples opciones que

facilitarán el trabajo de los contadores que intervienen en ese departamento.

Para llevar a cabo la etapa de Análisis se realizaron una serie de actividades que

sugiere la Ingeniería del Software. En el contenido se encuentran algunos conceptos, como

qué es la Ingeniería de Requerimientos (IR), qué es un requerimiento, los tipos de

requerimiento así como también las actividades de la IR para llevar a cabo la etapa de

análisis, las técnicas utilizadas por la IR para la obtención de datos, entre otros.

En base al fundamento teórico se realizó el Documento de Especificación de

Requerimientos, donde se incluyeron los requisitos del usuario y los requisitos del sistema,

se presentaron los usuarios que podrían interactuar con el sistema de igual forma los

permisos otorgados a cada uno de ellos.

Se llevaron a cabo revisiones en compañía del cliente y el desarrollador, esto para

finalmente llegar a un acuerdo sobre el objetivo del sistema.

Memoria de Residencia Profesional 1



Después de haber obtenido los requerimientos necesarios para el sistema, se

modelaron los requisitos con ayuda del Modelado del Lenguaje Unificado (UML). UML es un

lenguaje estándar que sirve para escribir los planos de lo que va a ser el software, puede

utilizarse para visualizar, especificar, construir y documentar todos los artefactos quecomponen un sistema con gran cantidad de software.

También se construyeron los diferentes diagramas recomendados por UML, por citar

algunos, el diagrama de clases, diagrama de objetos, diagrama de secuencia, de igual forma

se pasaron a un software especializado para el modelado en UML, Visual Paradigm for UML.




CAPITULO I

ESPECIFICACIONES GENERALES DELPROYECTO



1.1. PLANTEAMIENTO DEL PROBLEMA

En la actualidad, el departamento de Finanzas de la empresa “Talleres Navales del

Golfo S.A de C.V” es el encargado de llevar a cabo el control presupuestal de todos los

departamentos, esta actividad se realiza de forma manual, lo que resulta un trabajo laborioso

y tedioso, implicando más tiempo en su elaboración.

En el departamento, se encontró la falta de un registro o control de cada uno de los

egresos de los centros de costo que contribuye la empresa, a lo que se le denomina Techos

de Compra (órdenes de compra, existencias de almacén, etc.), esto podría evitar gastos

innecesarios a la empresa. El registro de los techos de compra se incluirá dentro del sistema

de “Control Presupuestal”, solo para tres centros de costo en particular, Producción,

Mantenimiento y Proyectos, ya que estas áreas por lo regular solicitan una alta cantidad de

presupuesto para las actividades que realizan.

Por otro lado existe el problema del control del presupuesto asignado a cada uno de

los centros de costo, este fue el inconveniente que se trató de resolver en el área de

Planeación Financiera. Este proceso se lleva a cabo al iniciar el año y mensualmente

durante el transcurso del año. Debido a esto se presentan inconvenientes como mayor

tiempo de procesamiento de datos.

Es por ello que el departamento de finanzas ha mostrado interés en la realización de

un sistema informático capaz de llevar el control presupuestal por departamento de la

empresa.

Con el nuevo sistema se evitarán gastos innecesarios, ya que se logró dar

seguimiento a los movimientos realizados para el presupuesto. El sistema servirá de apoyo

en la toma de decisiones para el departamento de Planeación Financiera.

El sistema involucra una serie de etapas o pasos a seguir en su elaboración. La cual

es inicializa con la realización de un análisis del sistema, este debe hacerse de forma

minuciosa para conocer requerimientos, operaciones, procesos y demás actividades de esta

etapa, y así desarrollar un correcto sistema funcional.




El análisis del sistema de “Control Presupuestal” ayudará en el momento de la

implementación del sistema a tener una mejor administración y planificación del presupuesto

con respecto a los ingresos, gastos, ajustes y demás aspectos contables.

Al llevar a cabo el análisis del sistema, sirvió de ayuda al desarrollador, ya quepermitió dar un panorama amplio de lo que se requiere que realice el sistema.




1.2. OBJETIVOS GENERALES Y ESPECIFICOS

1.2.1. Objetivo General

Realizar el análisis del sistema de “Control Presupuestal”, para el departamento dePlaneación Financiera.

1.2.2. Objetivos Específicos

• Proporcionar la base del sistema, a través del planteamiento del análisis, para un mejor

desarrollo de la programación del mismo.

• Evitar la reprogramación.• Considerar o tomar en cuenta todas las necesidades del cliente, a través de la

elaboración del documento de especificación de requerimientos, para que se proporcione

solución a su problemática.

• Facilitar la comprensión del flujo de información de los procesos que involucra llevar el

control presupuestal, mediante el modelado del sistema.




1.3. CARACTERIZACIÓN DEL ÁREA DONDE SE PARTICIPÓ

Talleres Navales del Golfo, S.A. de C.V. (TNG), es un astillero que cuenta con

infraestructura adecuada para proporcionar un servicio completo para reparación de todo tipo

de embarcaciones, fabricación de módulos costa fuera, así como conversiones de barcos y

plataformas autoelevables o semisumergibles.

En el año 2006, fue adquirida por Hutchison Port Holdings (HPH), empresa líder en

inversión, desarrollo y operación portuaria con intereses en más de 23 países a lo largo de

Asia, Medio Oriente, África, Europa y América. Actualmente opera 257 muelles en más de 45

puertos alrededor del mundo.

HPH es una compañía subsidiaria de la diversificada Hutchison Whampoa Limited

(HWL), establecida en 1994 para administrar los puertos del Grupo HWL y los servicios

relacionados con ellos.

Figura 1.1 Talleres Navales del Golfo

1.3.1. Antecedentes




Talleres Navales Del Golfo (TNG) inició operaciones en marzo de 1995, para agosto

de 1996 realizó la reparación de toda la parte habitacional del buque tanque “Bacab”, de

Pemex Refinación, que fue incendiado en la superestructura y cuarto de máquinas.

TNG efectuó la conversión del buque bulkcarrier “Corregidora” a almacén para

empacar cemento, en febrero de 1998, para la empresa CEMEX. Otra conversión fue de

barcaza de carga sobre cubierta a barcaza planta generadora de energía eléctrica, realizada

en diciembre de 1998 fue para Odyssea Power Systems, en diciembre de 1998.

En el negocio de fabricación, TNG entregó completamente terminadas en diciembre

2003, dos plataformas recuperadoras de pozos de cuatro pilotes para Tierra del Fuego,

habiendo sido el cliente final la compañía francesa Total Fina Elf.

Actualmente toda la actividad gira sobre el mercado de la reparación de

embarcaciones, por contar con la infraestructura para ello, en el mercado de la construcción

naval ha reparado alrededor de 456 embarcaciones de diferentes tipos (bulkcarriers,

containeros, tanqueros, barcazas, chalanes, abastecedores, remolcadores, plataformas

semisumergibles y autoelevables), manteniendo hasta la fecha la buena calidad del servicio

y la satisfacción de los clientes tanto mexicanos como extranjeros.

Los servicios que realiza TNG están certificados bajo la norma ISO 9001-2000, asícomo por la certificación de cumplimiento del Código Internacional para la Protección de los

Buques y de las Instalaciones Portuarias (ISPS code).

1.3.2. Misión

Ofrecer las mejores opciones para satisfacer las necesidades de mantenimiento,

reparación y fabricación de embarcaciones así como de estructuras costa-fuera.

1.3.3. Política de Calidad




Alcanzar el liderazgo en nuestro mercado, excediendo las expectativas del cliente, a

través de la entrega oportuna de productos y servicios, con calidad de clase mundial y

precios competitivos.

1.3.4. Valores

• Seguridad: protegiendo a nuestros empleados, el medio ambiente y nuestras

instalaciones.

• Integridad: adhiriéndonos a estándares éticos y sanas reglas de conducta.

• Confianza: honrando nuestras relaciones con los demás.

• Compromiso: cumpliendo cabalmente nuestras obligaciones.

•

Calidad: mejorando continuamente los requerimientos.

1.3.5. Servicios.

• Reparación y mantenimiento de barcos, maquinaria, equipos y motores.

• Reparación y mantenimiento a flote de plataformas autoelevables y semisumergibles.

• Conversiones, mejoras y extensiones de vida de buques y unidades costa fuera.

• Fabricación de módulos y componentes costa fuera.

• Fabricación y ensamble de todo tipo de estructuras metálicas, ligeras y pesadas.

• Inspección y calibración de equipos de navegación, comunicación y control.

• Procedimientos de Garantía y Control de Calidad (QA/QC) incluyendo pruebas de

ultrasonido, inspecciones con líquidos penetrantes, partículas magnéticas, rayos X,

análisis químicos y mecánicos.

• Inspecciones y reparaciones submarinas.

• Todo tipo de sistemas de recubrimiento, incluyendo galvanizado y aluminio.

• Limpieza y recubrimiento de tanques.

1.3.6. Situación Geográfica




TNG se encuentra estratégicamente localizada en el puerto de Veracruz, uno los

principales puertos de México, en la parte media del Golfo de México, ubicado cerca de las

sondas petroleras y gaseras costa fuera, así como de las rutas comerciales de navegación

más importantes, a 19°12’ latitud norte y 96° 8’ longitud oeste, una situación ideal para recibir

a los buques más grandes del mundo.

A través de TNG, se ofrecen servicios a las más prestigiadas empresas navieras

del mundo, cuyos servicios de transporte marítimo se extienden a los principales puertos del

Norte de Europa, Mediterráneo, Estados Unidos, Sudamérica y Caribe.

Figura 1.2 Ubicación Geográfica

Domicilio

Islote San Juan de Ulúa s/n

91 800

Veracruz Ver, México

Apartado Postal 657

TEL: 9 892500/ 2535

www.tnghph.com.mx

1.3.7. Infraestructura

• 34.4 ha de área total.




• 14.3 ha para fabricación y montaje.

• 13.0 ha para alistamiento y reparación

• 7.1 ha para almacenaje y servicios misceláneos.

• Línea de rolado con capacidad nominal de 9000 T.M./año, con sistemas de soldadura

automatizados.• 2 Diques secos (157.0 x 19.5 mts. y 271.0 x 36.0 mts.)

• 2 Muelles Marginales (central y oeste), de 70 y 200 mts. de longitud respectivamente.

• 1 Muelle de Reparación de 235.0 mts. de longitud con dos bandas de atraque.

• 1 Muelle de Alistamiento de 220.0 mts. de longitud con dos bandas de atraque.

Figura 1.3 Infraestructura TNG

1.3.8. Astillero

• Muelle de Reparación

• Muelle de Alistamiento

• Muelle Marginal Oeste

• Muelle Marginal Central

• Dique 5

• Dique 2

• Taller de Maquinado y Mecánico

• Taller de Rolado y Ensamble

• Taller de Corte y Conformado

• Línea de Tratamiento

• Almacenes




• Oficinas Generales

1.3.9. Equipo

• Grúas de auto nivelación

• Grúas hidráulicas y de orugas

• Transportes sobre ruedas para carga de hasta

220 ton. métricas

1.3.10. Departamento de Planeación Financiera.

Este departamento permite realizar una proyección sobre los resultados deseados a

alcanzar por la empresa ya que estudia la relación de proyecciones de ventas, ingresos,

activos o inversiones y financiamiento, tomando como base estrategias alternativas de


Almacenes

Línea de

tratamiento Taller de Rolado yEnsamblaje

Taller de Corte yConformado

Taller deMaquinado y

Mecánico Dique 5

Muelle de

Aislamiento

OficinasGenerales

Oficinas para

clientes

Muelle Marginal Oeste

Dique 2

Muelle MarginalCentral

Muelle deReparación

Figura 1.5 Equipo

Figura 1.4 Área donde se realizó Residencia



producción y mercadotecnia, a fin de decidir, posteriormente, la forma de satisfacer los

requerimientos financieros.

Planeación Financiera interactúa con otros departamentos para recabar información

financiera y realizar los reportes pertinentes para llevar el control del presupuesto.

El proceso de control de presupuestos como ya se había mencionado es llevado de

forma electrónica y manual, este proceso consta de varios subprocesos, ya que este se

realiza al iniciar y en el transcurso del año.

Empezando por la solicitud de presupuesto requerida por cada centro de costo, para

ser revisada por Gerencia General y Planeación Financiera para tomar decisiones

pertinentes (autorización) con respecto a la solicitud de cada centro de costo. En caso de

existir anomalías Planeación Financiera realiza las modificaciones pertinentes autorizadaspor Gerencia General.

Cada mes generan reportes de cada centro de costo para visualizar detalles de los

gastos, de igual forma verificar el porcentaje de presupuesto disponible, el presupuesto

acumulado y las variaciones en el presupuesto conforme avanza el año.

Para poder generar estos reportes el Departamento de Planeación Financiera analiza

la información que les es enviada en archivos electrónicos desde otros departamentos comoson los estados financieros los cuales provienen de un sistema implementado llamado EBIS,

las nóminas provenientes del sistema HUMAN, entre otros.

Por el momento, se realizaban cuatro revisiones al año, donde se generaban reportes

del presupuesto otorgado a cada centro de costo, comparando escenarios (año, mes,

acumulado) para ser analizados y realizar modificaciones al presupuesto de cada centro de

costo de ser necesario.

De igual forma se llevaba el control de los presupuestos de todos los centros decosto, además de que se generaban reportes en base a los gastos y el presupuesto

asignado. Estos reportes podían ser impresos ya sea por mes, año, acumulado, o un periodo

determinado por el usuario.




El análisis del sistema fue desarrollado para este departamento, donde se

descubrieron los usuarios que llevan a cabo este proceso como son el departamento de

Gerencia General, el departamento de Planeación Financiera y usuarios finales de cada

centro de costo. Cada uno tiene diferentes permisos, ya que se trata del área de Finanzas y

ciertos usuarios no se deben implicar en las decisiones del departamento.




1.4. JUSTIFICACIÓN

En la actualidad, la empresa “Talleres Navales del Golfo S.A. de C.V.”, en el

departamento de Planeación Financiera se lleva a cabo el proceso de control de presupuesto

de los centros de costo de la empresa. Dicho proceso se realiza por medio de archivos

electrónicos y de forma manual, lo que conlleva a los encargados facturar un análisis

minucioso de las operaciones monetarias que se realizan en cada uno de los centros de

costo. Debido a esto, el tiempo de realización es tardado para la generación de reportes y

documentos de suma importancia.

Por ello, se opto por desarrollar un sistema que facilitará las tareas que realizan los

encargados del proceso y así mismo optimizar el tiempo de respuesta disminuyendo la carga

de trabajo, además tendrá un alto grado de seguridad ya que se trata de un área de suma

importancia, ya que el sistema contará con una serie de funciones que ayudaran en la

elaboración de reportes, ingreso de presupuestos por parte de los usuarios finales y también

contará con una bitácora de movimientos para un mayor control de la información.




1.5. ALCANCES Y LIMITACIONES

1.5.1. Alcances

Se realizó un análisis detallado de todos los aspectos que competen en el proceso de

control de presupuesto, basado en la Ingeniería de Requerimientos para determinar los

requisitos del cliente y del sistema.

Además se entregó el Documento de Especificación de Requisitos para el cliente y el

desarrollador del sistema. Dicho documento permitió al desarrollador obtener una visión del

sistema, como debe operar y que funciones debe realizar el sistema. Para visualizar las

funciones del sistema se utilizó el Lenguaje Unificado de Modelado.

1.5.2. Limitaciones

• Falta de equipo de cómputo.

• No se tenía asignado el lugar de trabajo.

• Retraso para iniciar el proyecto.

• Apoyo en el área de Soporte, por lo que existió un retraso en la realización del

Documento de Especificación de Requisitos.

• Disponibilidad del cliente para la obtención de requisitos.

• Retraso en la revisión del documento, por lo que no se podía avanzar en el análisis.




CAPITULO II

FUNDAMENTO TEÓRICO



2.1. INGENIERÍA DE SOFTWARE.

El análisis es “el estudio de los límites, las características y las posibles soluciones de

un problema al que se le aplica un tratamiento”. La función del análisis puede ser dar soporte

a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadores hace uso de

seis elementos fundamentales:

• Software.- Son los programas de computadora, con estructuras de datos y su

documentación que hacen efectivos los controles de los requerimientos del programa.

• Hardware.- Son los dispositivos electrónicos y electromecánicos, que proporcionan

capacidad de cálculos y funciones rápidas, exactas y efectivas que proporcionan una

función externa dentro de los sistemas.

• Personal.- Son los operadores o usuarios directos de las herramientas del sistema.

• Bases de Datos.- Es una gran colección de informaciones organizadas y enlazadas al

sistema a las que se accede por medio del software.

• Documentación, manuales, formularios, u otra información descriptiva que detalla o

da instrucciones sobre el empleo y operación del sistema.

• Procedimientos, o pasos que definen el uso específico de cada uno de los elementos

o componentes del Sistema y las reglas de su manejo y mantenimiento.

El análisis se aplicó para identificar los objetivos o metas que debía alcanzar el

sistema de “Control Presupuestal”, lo que permitió definir las características y funciones del

mismo.

Para llevar a cabo la etapa de Análisis para el sistema de “Control Presupuestal” se

utilizó la Ingeniería del Software como herramienta principal para el desarrollo de software.

Por ello se define primero que es la Ingeniería del Software:

“La Ingeniería del Software es una disciplina de la ingeniería que comprenden todos

los aspectos de la producción de software desde las etapas iniciales de la especificación del

sistema, hasta el mantenimiento de éste después de que se utiliza”. (Sommerville, 2005)

2.1.1 Metodología




Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean

sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la

calidad del producto software.

Etapas del proceso

La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas

como las siguientes:

• Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo.

Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se

requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos

incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente

se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya

estructura puede venir definida por varios estándares. Asimismo, se define un diagrama de

Entidad/Relación, en el que se plasman las principales entidades que participarán en el

desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una

parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han

ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está

formalizada, ya se habla de la Ingeniería de Requisitos.

• Especificación

Es la tarea de describir detalladamente el software a ser escrito, en una forma

matemáticamente rigurosa. En la realidad, la mayoría de las buenas especificaciones han

sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las

especificaciones son más importantes para las interfaces externas, que deben permanecer

estables.

• Diseño y arquitectura




Se refiere a determinar cómo funcionará de forma general sin entrar en detalles.

Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware,

la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizará el sistema, y

se transforman las entidades definidas en el análisis de requisitos en clases de diseño,obteniendo un modelo cercano a la programación orientada a objetos.

• Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de

software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada.

La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes

de programación utilizados, así como al diseño previamente realizado.

• Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en

la especificación del problema. Una técnica de prueba es probar por separado cada módulo

del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una

buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que

la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe

hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de

pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema

de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que

los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace

las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas

conformada por programadores con experiencia, personas que saben sin mayores

indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en

detalles que personal inexperto no consideraría.

• Documentación




Todo lo concerniente a la documentación del propio desarrollo del software y de la

gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de

usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones,

usabilidad, mantenimiento futuro y ampliaciones al sistema.

• Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos

requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software.

Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una

pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste

en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de

toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento.

2.1.2 Modelos de procesos del software

La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los

cuales se puede apoyar para la realización de software, de los cuales podemos destacar a

éstos por ser los más utilizados y los más completos:

• Modelo Lineal Secuencial.

• Modelo de Construcción de Prototipos.

• Modelo DRA.

• Modelos Evolutivos del Proceso de Software.

o Modelo Incremental.

o Modelo Espiral.

o Modelo Espiral Espiral WinWin (Victoria&Victoria).

o Modelo de desarrollo basado (ensamblaje) en componentes.

o Modelo de Desarrollo Concurrente.

o Modelo de métodos formales.




2.2. INGENIERÍA DE REQUERIMIENTOS.

Uno de los puntos importantes de la Ingeniería del Software es la Especificación de

Requisitos o Ingeniería de Requerimientos el cuál es el proceso de descubrir, analizar,

documentar y verificar servicios y restricciones. La Ingeniería de Requerimientos es base

para el proceso de desarrollo de software, por ello se definió lo que es un requerimiento.

La meta de la ingeniería de requerimientos (IR) es entregar una especificación de

requisitos de software correcta y completa. Otros conceptos de ingeniería de requerimientos

que se encontraron son:

“Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el

problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen acomprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente

quiere y cómo interactuarán los usuarios finales con el software”. (Pressman S., 2002).

“La ingeniería de requerimientos es el proceso de desarrollar una especificación de

software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente

a los desarrolladores del sistema”. (Sommerville, 2005).

En síntesis, el proceso de ingeniería de requerimientos se utilizó para definir todas lasactividades involucradas en el descubrimiento, documentación y mantenimiento de los

requerimientos para el sistema de “Control Presupuestal”, donde es muy importante tomar en

cuenta que el aporte de la IR viene a ayudar a determinar la viabilidad de llevar a cabo el

software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de

obtención y análisis de requerimientos, su especificación formal, para finalizar con el

subproceso de validación donde se verifica que los requerimientos definen el sistema que el

cliente requiere.

2.2.1. Requerimiento.




Los requerimientos para un sistema son la descripción de los servicios

proporcionados por el sistema y sus restricciones operativas.

El término requerimiento no se utiliza de una forma constante en la producción desoftware. En algunos casos, “un requerimiento es simplemente una declaración abstracta de

alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste”

(Sommerville, 2005).

En este caso se utilizó el término requerimiento para determinar cuáles serían las

funciones que el sistema debe realizar y satisfacer las necesidades del cliente.

2.2.2. Tipos de Requerimientos.

Algunos de los problemas que surgen durante el proceso de ingeniería de

requerimientos son resultado de no haber hecho una clara separación entre los diferentes

niveles de descripción de los requisitos. Aquí se distinguieron con la denominación

requerimientos del usuario para designar los requerimientos abstractos de alto nivel, y

requerimientos del sistema para designar la descripción detallada de lo que el sistema debe

hacer.

Los requerimientos se dividen en dos categorías: requerimientos de usuario y

requerimientos del sistema.

2.2.2.1. Requerimientos de Usuario

“Son declaraciones, en lenguaje natural y en diagramas, de los servicios que seespera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar”

(Sommerville, 2005).




Para la declaración de las necesidades del cliente dentro del Documento de

Requerimientos se utilizaron los requerimientos del usuario, ya que estos permitieron al

cliente comprender y visualizar el alcance del sistema en un lenguaje común.

2.2.2.2. Requerimientos del Sistema

Los requerimientos del sistema son versiones extendidas de los requerimientos del

usuario que son utilizados por los ingenieros de software como punto de partida para el

diseño del sistema. Agregan detalle y explican como el sistema debe proporcionar los

requerimientos del usuario. Pueden ser utilizados como parte del contrato para la

implementación del sistema y, por lo tanto, deben ser una especificación completa y

consistente del sistema entero.

A menudo se utiliza el lenguaje natural para redactar, además de los requerimientos

del usuario, las especificaciones de requerimientos del sistema. Sin embargo, debido a que

los requerimientos del sistema son más detallados que los requerimientos del usuario, las

especificaciones en lenguaje natural pueden ser confusas y difíciles de entender.

Los requerimientos de sistema de software se clasificaron en funcionales y no

funcionales, o como requerimientos del dominio:

1. Requerimientos funcionales. Son declaraciones de los servicios que debe

proporcionar el sistema, de la manera en que este debe reaccionar a entradas

particulares y de cómo se debe comportar en situaciones particulares. En algunos

casos, los requerimientos funcionales de los sistemas también pueden declarar

explícitamente lo que el sistema debe hacer.

2. Requerimientos no funcionales.- Son restricciones de los servicios o funciones

ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso dedesarrollo y estándares. Normalmente los requerimientos funcionales apenas se

aplican a características o servicios individuales del sistema.

3. Requerimientos del dominio.- Son requerimientos que provienen del dominio de

aplicación del sistema y que reflejan las características y restricciones de ese

dominio. Pueden ser funcionales o no funcionales.




2.2.3. Características de un Requerimiento.

Los requerimientos formulados debían satisfacer varias características. Si no lo

hacían, tenían que ser reformulados hasta hacerlo. Para ello un requerimiento debe ser:

• Necesario: Lo que pida un requerimiento debe ser necesario para el producto.

• No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.

• Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar

de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos

importantes

• Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento

diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos

requerimientos debe ser consistente también.• Completo: Los requerimientos deben contener en sí mismos toda la información

necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.

• Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado

con el dinero, el tiempo y los recursos disponibles.

• Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue

satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis,

demostración o testeo.

2.2.4. Dificultades para definir los requerimientos.

Durante la etapa de especificación de requerimientos (IR) se presentaron

inconvenientes los cuales fueron importantes de identificar, a continuación se presenta un

listado de los problemas más comunes que se dieron durante este proceso:

•

Los requerimientos no eran obvios y provenían de varias fuentes, ya que se tratabade un área financiera.

• Fueron difíciles de expresar en palabras (el lenguaje es confuso).

• La cantidad de requerimientos del proyecto fueron un poco difícil de manejar.

• El usuario no podía explicar lo que hace durante el proceso de control de

presupuesto. Tendía a recordar lo excepcional y olvidar lo rutinario.




• Los usuarios tenían distinto vocabulario que los analistas.

Para resolver estos inconvenientes, se utilizó la Ingeniería de Requerimientos, ya que

aquí se incluyen algunas técnicas de obtención de requisitos que ayudaron en la etapa de

Especificación de Requerimientos.

2.2.5. Actividades de la Ingeniería de Requerimientos

Se identificó que existen cinco actividades básicas que se tienen que llevar a cabo

para completar el proceso de software. Estas actividades ayudaron a reconocer la

importancia que tiene, para el desarrollo de un proyecto de software, realizar una

especificación y administración adecuada de los requerimientos de los clientes o usuarios.

Las cinco actividades identificadas son: Extracción de Requisitos, Análisis y

Negociación de Requisitos, Especificación de Requisitos, Modelado del Sistema, Validación

y Gestión de Requisitos, serán explicadas a continuación cada una de ellas.

2.2.5.1. Extracción de Requisitos.

En principio, parece bastante simple -preguntar al cliente, a los usuarios y a los que

están involucrados en los objetivos del sistema o producto y sean expertos, investigar cómo

el sistema o producto se ajusta a las necesidades del negocio, y finalmente, cómo el sistema

o producto va a ser utilizado en el día a día-.

Esto que parece simple, es muy complicado. Christel y Kang [CRI92] identifican una

serie de problemas que ayudan a comprender por qué la obtención de requisitos es costosa.

• Problemas de alcance. El límite del sistema está mal definido o los detalles técnicos

innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más

que clarificar los objetivos del sistema.

• Problemas de comprensión. Los clientes/usuarios no están completamente seguros

de lo que necesitan, tienen una pobre compresión de las capacidades y limitaciones




de su entorno de computación, no existe un total entendimiento del dominio del

problema, existen dificultades para comunicar las necesidades al ingeniero del

sistema, la omisión de información o por considerar que es «obvia», especificación de

requisitos que están en conflicto con las necesidades de otros clientes/usuarios, o

especificar requisitos ambiguos o poco estables.• Problemas de volatilidad. Los requisitos cambian con el tiempo.

Para ayudar a solucionar estos problemas, los analistas del sistema se pueden

aproximar de manera organizada a través de reuniones con el cliente para definir los

requisitos. Sommerville y Sawyer [SOM97] sugieren un conjunto de actuaciones para la

obtención de requisitos, que están descritos en las tareas siguientes:

• Valorar el impacto en el negocio y la viabilidad técnica del sistema propuesto.• Identificar las personas que ayudarán a especificar requisitos y contrastar su papel en

la organización.

• Definir el entorno técnico (arquitectura de computación, sistema operativo,

necesidades de telecomunicaciones) en el sistema o producto a desarrollar e

integrar.

• Identificar «restricciones de dominio» (características específicas del entorno de

negocio en el dominio de la aplicación) que limiten la funcionalidad y rendimientos del

sistema o producto a construir.• Definir uno o más métodos de obtención de requisitos (entrevistas, grupos de trabajo,

equipos de discusión).

• Solicitar la participación de muchas personas para que los requisitos se definan

desde diferentes puntos de vista, asegurarse de identificar lo fundamental de cada

requisito registrado.

• Identificar requisitos ambiguos como candidatos para el prototipado, y crear

escenarios de uso para ayudar a los clientes/usuarios a identificar mejor los requisitos

fundamentales.

El resultado alcanzado como consecuencia de la identificación de requisitos puede

variar dependiendo del tamaño del sistema o producto a construir. Para grandes sistemas, el

producto obtenido debe incluir:




• Una relación de necesidades y características.

• Un informe conciso del alcance del sistema o producto.

• Una lista de clientes, usuarios y otros intervinientes que deben participar en la

actividad de obtención de requisitos.

• Una descripción del entorno técnico del sistema.

• Una relación de requisitos (perfectamente agrupados por funcionalidad) y las

restricciones del dominio aplicables a cada uno.

• Un conjunto de escenarios que permiten profundizar en el uso del sistema o producto

bajo diferentes condiciones operativas, y cualquier prototipo desarrollado para definir

mejor los requisitos.

Cada uno de los productos obtenidos debe ser revisado por las personas que hayan

participado en la obtención de los requisitos. Es importante, que la extracción de los

requisitos sea efectiva, ya que la aceptación del sistema dependerá de cuán bien éste

satisfaga las necesidades del cliente.

2.2.5.2. Análisis y Negociación de Requisitos.

Sobre la base de la extracción realizada anteriormente, comienza esta fase la cual se

enfocó en descubrir los problemas con los requerimientos del sistema identificados.

Usualmente se hace un análisis luego de haber producido un bosquejo inicial del

documento de requerimientos; en esta etapa se leyeron los requerimientos, se conceptuaron,

se investigaron, se intercambiaron ideas con el resto del equipo, se resaltaron los problemas,

se buscaron alternativas y soluciones, y luego se fijaron reuniones con el cliente para discutir

los requerimientos.

Una vez recopilados los requisitos, se agruparon por categorías y se organizaron en

subconjuntos, se estudió cada requisito en relación con el resto, se examinaron los requisitos

en su consistencia, completitud y ambigüedad (Características de un requerimiento), y se

clasificaron en base a las necesidades de los clientes/usuarios.




Al iniciarse la actividad del análisis de requisitos se plantearon las siguientes

cuestiones:

• ¿Cada requisito es consistente con los objetivos generales del sistema/producto?

• ¿Tienen todos los requisitos especificados el nivel adecuado de abstracción? Es

decir, ¿algunos requisitos tienen un nivel de detalle técnico inapropiado en esta

etapa?

• ¿El requisito es necesario o representa una característica añadida que puede no ser

esencial a la finalidad del sistema?

• ¿Cada requisito está delimitado y sin ambigüedad?

• Cada requisito tiene procedencia. Es decir, ¿existe un origen (general o específico)

conocido para cada requisito?

• ¿Existen requisitos incompatibles con otros requisitos?

• ¿Es posible lograr cada requisito en el entorno técnico donde se integrará el sistema

o producto?

• ¿Se puede probar el requisito una vez implementado?

Es corriente en clientes y usuarios solicitar más de lo que puede realizarse,

asumiendo recursos de negocio limitados. También es relativamente común en clientes y

usuarios el proponer requisitos contradictorios, argumentando que su versión es “esencial

por necesidades especiales” (Pressman S., 2002).

Si los clientes no pueden facilitar los requisitos, el riesgo de errar es muy alto. Los

analistas del sistema pueden resolver estos conflictos a través de un proceso de

negociación. Los clientes, usuarios y el resto de los involucrados discuten los posibles

conflictos según la prioridad de sus requisitos.

Los riesgos asociados con cada requisito son identificados y analizados. Se efectúan

estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada

requisito en el coste del proyecto y en el plazo de entrega. Utilizando un procedimiento

iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir

satisfacer los objetivos planteados.




2.2.5.3. Especificación de Requisitos

En esta fase se documentaron los requerimientos acordados con el cliente. En el

contexto de un sistema basado en computadoras (y software), el término especificación

significa distintas cosas para diferentes personas. Una especificación puede ser undocumento escrito, un modelo gráfico, un modelo matemático formal, una colección de

escenarios de uso, un prototipo o una combinación de lo anteriormente citado.

Algunos sugieren que debe desarrollarse una plantilla y usarse en la especificación

del sistema, argumentando que así se consiguen los requisitos para que sean presentados

de una forma más consistente y más comprensible.

Para este caso se considero como mejor alternativa un documento escrito(Documento de Especificación de Requisitos), combinado con descripciones en lenguaje

natural y modelos gráficos.

La Especificación del Sistema es el producto final sobre los requisitos del sistema

obtenido por el ingeniero. Sirve como fundamento para la ingeniería del hardware, ingeniería

del software, la ingeniería de bases de datos y la ingeniería humana.

La Especificación de Requisitos ayudó a describir la función y las características delsistema así como las restricciones que gobiernan su desarrollo. En sí, la especificación del

sistema describe la información (datos y control) que entra y sale del sistema.

2.2.5.4. Modelado del sistema

Al terminar de especificar el sistema, se modeló cada uno de los requisitos, para unmejor entendimiento del proceso de “Control de Presupuesto”.

Considere por un momento que a usted se le ha requerido para especificar los

requisitos para la construcción de una cocina. Se conocen las dimensiones del lugar, la




localización de las puertas y ventanas y el espacio de pared disponible. Debe especificar

todos los armarios y electrodomésticos e indicar dónde colocarlos.

¿Será una especificación válida? La respuesta es obvia. Para especificar

completamente lo que se va a desarrollar, se necesita un modelo de la cocina con toda lainformación necesaria, esto es, un anteproyecto o una representación en tres dimensiones

que muestre las posiciones de los armarios y electrodomésticos, y sus relaciones.

Con el modelo será relativamente fácil asegurar la eficiencia del trabajo (un requisito

de todas las cocinas), la estética visual de la sala (es un requisito personal, aunque muy

importante).

Se construyeron modelos del sistema por la misma razón que se desarrollo para unacocina un anteproyecto o una representación en 3D. Fue importante evaluar los

componentes que integrarían el sistema y sus relaciones entre sí; determinar cómo están

reflejados los requisitos, y valorar como se ha concebido la estética en el sistema.

2.2.5.5. Validación de requisitos

La validación se considera por muchos autores como la actividad final de la IR. Suobjetivo es, ratificar los requerimientos, es decir, se verifican todos los requerimientos que

aparecen en el documento especificado (Documento de Requerimientos) para asegurarse

que se representó una descripción, por lo menos, aceptable del sistema que se desea

implementar. Esto implica que se verifique que los requerimientos fueran consistentes y

estuvieran completos.

Es necesario recalcar que no existe un proceso único que sea válido de aplicar en

todas las organizaciones. Cada organización desarrolla su propio proceso de acuerdo al tipode producto que se está desarrollando, a la cultura organizacional, y al nivel de experiencia y

habilidad de las personas involucradas en la ingeniería de requerimientos.

El mecanismo que se utilizó para la validación de los requisitos fue la revisión técnica

formal. En el equipo de revisión se incluyeron los ingenieros del sistema, clientes y usuarios,




para que examinaran las especificaciones del sistema buscando errores en el contenido o en

la interpretación, áreas donde se necesitaban aclaraciones, información incompleta,

inconsistencias, requisitos contradictorios o requisitos inalcanzables.

Aunque la validación de requisitos puede guiarse de manera que se descubranerrores, en ocasiones es útil chequear cada requisito con un cuestionario. Las siguientes

cuestiones representan un pequeño subconjunto de las preguntas que pueden plantearse

(Pressman S., 2002):

• ¿Está el requisito claramente definido? ¿Puede interpretarse mal?

• ¿Está identificado el origen del requisito (por ejemplo: persona, norma, documento)?

¿El planteamiento final del requisito ha sido contrastado con la fuente original?

• ¿El requisito está delimitado en términos cuantitativos?

• ¿Qué otros requisitos hacen referencia al requisito estudiado? ¿Están claramente

identificados por medio de una matriz de referencias cruzadas o por cualquier otro

mecanismo?

• ¿El requisito incumple alguna restricción definida?

• ¿El requisito es verificable? Si es así, ¿podemos efectuar pruebas (algunas veces

llamadas criterios de validación) para verificar el requisito?

• ¿Se puede seguir el requisito en el modelo del sistema que hemos desarrollado?

• ¿Se puede localizar el requisito en el conjunto de objetivos del sistema/producto?

• ¿Está el requisito asociado con los rendimientos del sistema o con su

comportamiento y han sido establecidas claramente sus características

operacionales?

• ¿El requisito está implícitamente definido?

2.2.5.6. Gestión de requisitos

Los requisitos del sistema pueden cambiar y el deseo de cambiar los requisitos

persiste a lo largo de la vida del sistema. Por ello se documentan cada uno de los requisitos

que sufren cambios durante el proceso de análisis.




La gestión de requisitos es “un conjunto de actividades que ayudan al equipo de

trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento”.

Es esencial planear posibles cambios a los requerimientos cuando el sistema sea

desarrollado y utilizado. Por tanto la gestión de los requisitos del software, de su evolución esun proceso externo que ocurre a lo largo del ciclo de vida del proyecto.

Los cambios que se dan a los requerimientos fueron por diversas razones como:

• Cambios tecnológicos.

• Porque al analizar el problema, no se hicieron las preguntas correctas a las personas

correctas.

• Porque cambió el problema que se estaba resolviendo.

• Porque los usuarios cambiaron su forma de pensar o sus percepciones.

• Porque cambió el ambiente de negocios.

La gestión de requisitos ayudó a llevar el control de los cambios de los

requerimientos que se registraron en el Documento de Especificación de Requisitos ya

que es aquí donde posteriormente se seguirán realizando los cambios, creando nuevas

versiones del documento.

2.2.6. Técnicas utilizadas en las actividades de IR

Existen varias técnicas para la IR propuestas para ingeniería de requerimientos de las

cuales solo se abarcaron cinco de ellas.

Es importante resaltar que estas técnicas pueden ser aplicables a las distintas fases

del proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las

características propias del proyecto en particular que se esté desarrollando para aprovechar

al máximo su utilidad.




2.2.6.1. Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información proveniente de

personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el

cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de unsistema.

Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en

potencia del sistema propuesto. En algunos casos, son gerentes o empleados que

proporcionan datos para el sistema propuesto o que serán afectados por él. El éxito de esta

técnica, depende de la habilidad del entrevistador y de su preparación para la misma.

Para el proyecto se utilizo la entrevista, ya que de esta forma se pudo establecer contacto con el cliente y sobre todo los usuarios, los cuales fueron parte importante en el

proceso de recolección de requerimientos.

2.2.6.2. Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén

relacionados con el sistema a ser construido. Por un lado, se puede analizar las interfaces deusuario, observando el tipo de información que se maneja y cómo es manejada, por otro lado

también es útil analizar las distintas salidas que los sistemas producen (listados, consultas,

etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas.

Debido a que en la empresa existen más sistemas, y estos a su vez se relacionan

con el propósito del proyecto, se analizaron los datos que arrojaban así como las consultasque se pueden generar, sobre todo para verificar si alguno de esos sistemas podía ser de

ayuda para cumplir con el objetivo del sistema “Control Presupuestal”.




2.2.6.3. Lluvia de ideas (Brainstorm)

Este es un modelo que se usa para generar ideas. La intención en su aplicación es la

de generar la máxima cantidad posible de requerimientos para el sistema. No hay que

detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio esgenerar, en una primera instancia, muchas ideas.

Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro",

"impracticable", "imposible", etc. Las reglas básicas a seguir son:

• Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben

tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de

ideas creativas.

• Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de

las ideas, porque si no se crea un ambiente hostil que no alienta la generación de

ideas.

• Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar,

porque luego de maduradas probablemente se tornen en un requerimiento

sumamente útil.

• A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar

varias ideas para generar una nueva.

2.2.6.4. Prototipos

Durante la actividad de extracción de requerimientos, puede ocurrir que algunos

requerimientos no estén demasiado claros o que no se esté muy seguro de haber entendido

correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un

desarrollo no eficaz del sistema final.Entonces, para validar los requerimientos hallados, se construyen prototipos. Los

prototipos son simulaciones del posible producto, que luego son utilizados por el usuario

final, permitiendo conseguir una importante retroalimentación en cuanto a si el sistema

diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo

de manera eficiente y efectiva.




El desarrollo del prototipo comienza con la captura de requerimientos.

Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican

todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la

profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseñorápido se centra en una representación de aquellos aspectos del software que serán visibles

al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la

construcción de un prototipo.

2.2.6.5. Casos de Uso

Definiendo los casos de uso, “son una técnica que se basa en escenarios para laobtención de requerimientos” (Sommerville, 2005). Una de las técnicas utilizadas para llevar

a cabo el análisis del sistema “Control Presupuestal” fueron los casos de uso, los cuales

permitieron describir las posibles secuencias de interacciones entre el sistema y los actores,

se realizó la descripción de los escenarios, cada uno de ellos comenzado con un evento

inicial desde un actor hacia el sistema.

La mayoría de los requerimientos funcionales que se especificaron en el Documento

de Requerimientos, se expresaron con casos de uso. Actualmente, se han convertido en unacaracterística fundamental de la notación UML (Lenguaje de modelado unificado), que se

utiliza para describir modelos de sistemas orientados a objetos.




2.3. MODELADO DE LENGUAJE UNIFICADO (UML)

Como se mencionó anteriormente los casos de uso son una característica

fundamental de UML. Para ello se define lo que es UML, así como sus características,

elementos, relaciones y simbología para desarrollar cada uno de los diagramas que lo

integran.

UML es un lenguaje estándar que sirve para escribir los planos del software, puede

utilizarse para visualizar, especificar, construir y documentar todos los artefactos que

componen un sistema con gran cantidad de software. UML puede usarse para modelar

desde sistemas de información hasta aplicaciones distribuidas basadas en Web, pasando

por sistemas empotrados de tiempo real.

UML es solamente un lenguaje por lo que es sólo una parte de un método de

desarrollo de software, es independiente del proceso aunque para que sea optimo debe

usarse en un proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e

incremental.

UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante gráficos

o mediante texto obteniendo modelos explícitos que ayudan a la comunicación durante el

desarrollo ya que al ser estándar, los modelos podrán ser interpretados por personas que noparticiparon en su diseño (e incluso por herramientas) sin ninguna ambigüedad. En este

contexto, UML sirve para especificar, modelos concretos, no ambiguos y completos.

UML sirvió para modelar las actividades que el sistema podía realizar, también para

visualizar, especificar y construir, cada uno de todos sus detalles. Mediante este lenguaje se

obtiene una documentación que es válida durante todo el ciclo de vida de un proyecto.

2.3.1. Vista General de UML




El lenguaje UML se compone de tres elementos básicos, los bloques de construcción,

las reglas y algunos mecanismos comunes. Estos elementos interaccionan entre sí para dar

a UML el carácter de completitud y no-ambigüedad. Los bloques de construcción se dividen

en tres partes: Elementos, que son las abstracciones de primer nivel, Relaciones, que unen alos elementos entre sí, y los Diagramas, que son agrupaciones interesantes de elementos.

Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de

ellos: elementos estructurales, elementos de comportamiento, elementos de agrupación y

elementos de anotación.

Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre

elementos que se nos pueden presentar a la hora de modelar usando UML, estas son:relaciones de dependencia, relaciones de asociación, relaciones de generalización y

relaciones de realización. Se utilizan diferentes diagramas dependiendo de qué, nos interese

representar en cada momento, para dar diferentes perspectivas de un mismo problema, para

ajustar el nivel de detalle, por esta razón UML soporta un gran número de diagramas

diferentes aunque, en la práctica, sólo se utilicen un pequeño número de combinaciones.




Figura 2.1 Vista General de UML.

UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar

asociaciones entre objetos para poder obtener modelos bien formados, estas son reglas

semánticas que afectan a los nombres, al alcance de dichos nombres, a la visibilidad de

estos nombres por otros, a la integridad de unos elementos con otros y a la ejecución, o sea

la vista dinámica del sistema.

2.3.2. Elementos

2.3.2.1. Elementos estructurales

Los elementos estructurales en UML, es su mayoría, son las partes estáticas del

modelo y representan cosas que son conceptuales o materiales.




• Clases

Una clase es una descripción de un conjunto de objetos que comparten los mismos

atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces.

Gráficamente se representa como un rectángulo que incluye su nombre, sus atributos y susoperaciones.

Ventana

origen

tamaño

abrir()

cerrar()

mover()

dibujar()Figura 2.2 Clase Ventana.

• Interfaz

Una interfaz es una colección de operaciones que especifican un servicio de una

determinada clase o componente. Una interfaz describe el comportamiento visible

externamente de ese elemento, puede mostrar el comportamiento completo o sólo una parte

del mismo.

Una interfaz describe un conjunto de especificaciones de operaciones (o sea su

signatura) pero nunca su implementación. Se representa con un círculo, como podemos ver

en la figura 2.3, y rara vez se encuentra aislada sino que más bien conectada a la clase o

componente que realiza.

• Colaboración


IOrtografia

Figura 2.3 Interfaz.



Define una interacción y es una sociedad de roles y otros elementos que colaboran

para proporcionar un comportamiento cooperativo mayor que la suma de los

comportamientos de sus elementos. Por lo tanto las colaboraciones tienen dimensión tanto

estructural como de comportamiento. Una clase dada puede participar en varias

colaboraciones.

Figura 2.4 Colaboración Cadena de responsabilidades

• Caso de uso

Es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta

y que produce un resultado observable de interés para un actor particular. Un caso de uso se

utiliza para estructurar los aspectos de comportamiento en un modelo. Un caso de uso es

realizado por una colaboración.

Figura 2.5 Caso de Uso

• Clase activa

Es una clase cuyos objetos tienen uno o más procesos, constituyen flujos de control

independientes pero concurrentes con otros flujos de control (con los que muy

probablemente se deberán sincronizar). Una clase activa es igual que una clase, excepto en

que sus objetos representan elementos cuyo comportamiento es concurrente con otros

elementos.

Gestor de Eventos

suspender()


Cadena deresponsabili

dad

Realizar

pedido



vaciarCola()Figura 2.6 Clase activa.

• Componente

Un componente es una parte física de un sistema que ofrece un conjunto de

interfaces y proporciona la implementación de dicho conjunto. En un sistema, se pueden

encontrar diferentes tipos de componentes de despliegue, tales como componentes COM+,

JavaBeans, así como componentes que sean artefactos del proceso de desarrollo, tales

como archivos de código fuente. Un componente representa típicamente el

empaquetamiento físico de diferentes elementos lógico, como clases interfaces y

colaboraciones.

• Nodo

Un nodo es un elemento físico que existe en tiempo de ejecución, representando un

recurso computacional que, por lo general, dispone de algo de memoria y con frecuenciacapacidad de procesamiento. Un conjunto de componentes puede residir en un nodo y

puede también migrar de un nodo a otro.

2.3.2.2. Elementos de comportamiento

Los elementos de comportamiento son las partes dinámicas de un modelo. Se podría

decir que son los verbos de un modelo y representan el comportamiento en el tiempo y en el

espacio. Los principales elementos son los dos que siguen.


orderform.java

Servidor

Figura 2.7 Componente.

Figura 2.8 Nodo Servidor.



• Interacción

Es un comportamiento que comprende un conjunto de mensajes intercambiados

entre un conjunto de objetos, dentro de un contexto particular para conseguir un propósito

específico. Una interacción involucra otros muchos elementos, incluyendo mensajes,

secuencias de acción (comportamiento invocado por un objeto) y enlaces (conexiones entre

objetos). La representación de un mensaje es una flecha dirigida que normalmente con el

nombre de la operación.

• Maquinas de estados

Es un comportamiento que especifica las secuencias de estados por las que van

pasando los objetos o las interacciones durante su vida en respuesta a eventos, junto con las

respuestas a esos eventos.

Una maquina de estados involucra otros elementos como son estados, transiciones

(flujo de un estado a otro), eventos (que disparan una transición) y actividades (respuesta deuna transición).

2.3.2.3. Elementos de agrupación

Forman la parte organizativa de los modelos UML. El principal elemento de

agrupación es el paquete, que es un mecanismo de propósito general para organizar

elementos en grupos. Los elementos estructurales, los elementos de comportamiento,

incluso los propios elementos de agrupación se pueden incluir en un paquete.


dibujar

Esperando

Figura 2.9 Interacción.

Figura 2.10 Máquina de estados.



Un paquete es puramente conceptual (sólo existe en tiempo de desarrollo).

Gráficamente se representa como una carpeta conteniendo normalmente su nombre y, a

veces, su contenido.

Figura 2.11 Agrupación reglas del negocio.

2.3.2.4. Elementos de anotación

Los elementos de anotación son las partes explicativas de los modelos UML. Son

comentarios que se pueden aplicar para describir, clasificar y hacer observaciones sobre

cualquier elemento de un modelo. El tipo principal de anotación es la nota que simplemente

es un símbolo para mostrar restricciones y comentarios junto a un elemento o un conjunto de

elementos.

2.3.3. Relaciones

Existen cuatro tipos de relaciones entre los elementos de un modelo UML.

Dependencia, asociación, generalización y realización, estas se describen a continuación:

• Dependencia

Es una relación semántica entre dos elementos en la cual un cambio a un elemento

(el elemento independiente) puede afectar a la semántica del otro elemento (elemento

dependiente). Se representa como una línea discontinua, posiblemente dirigida, que a veces

incluye una etiqueta.

• Asociación


Reglas

delnegocio

O b t i e n e u n a

c o p i a d e l

o b j e t o

Figura 2.12Anotación.



Es una relación estructural que describe un conjunto de enlaces, los cuales son

conexiones entre objetos. La agregación es un tipo especial de asociación y representa una

relación estructural entre un todo y sus partes. La asociación se representa con una línea

continua, posiblemente dirigida, que a veces incluye una etiqueta. A menudo se incluyenotros adornos para indicar la multiplicidad y roles de los objetos involucrados.

• Generalización

Es una relación de especialización / generalización en la cual los objetos del

elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el

padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre.

Gráficamente, la generalización se representa con una línea con punta de flecha vacía.

• Realización

Es una relación semántica entre clasificadores, donde un clasificador especifica un

contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de

realización en dos sitios: entre interfaces y las clases y componentes que las realizan, y

entre los casos de uso y las colaboraciones que los realizan. La realización se representa

como una mezcla entre la generalización y la dependencia, esto es, una línea discontinuacon una punta de flecha vacía.

2.3.4. Diagramas

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de maneraconcreta, es útil categorizarlos jerárquicamente, como se muestra en la figura.




Figura 2.13 Jerarquía de los diagramas UML 2.0, mostrados como un diagramade clases.

2.3.4.1. Diagramas de Estructura

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el

sistema modelado:

1. Diagrama de clases

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de

un sistema mostrando sus clases, atributos y las relaciones entre ellos.Los diagramas de clases fueron utilizados durante el proceso de análisis del sistema,

para crear el diseño conceptual de la información que se manejó en el sistema, y los

componentes que se encargaron del funcionamiento y la relación entre uno y otro. Dentro de

las características de los diagramas de clases se encuentran:


http://es.wikipedia.org/wiki/Sistema

http://es.wikipedia.org/wiki/Sistema



• Propiedades también llamados atributos o características, son valores que

corresponden a un objeto, como color, material, cantidad, ubicación. Suponiendo que

el objeto es una Cuenta, sus propiedades serían: el número de cuenta, la descripción

de la misma y el rubro al que pertenece.

• Operaciones son aquellas actividades o verbos que se pueden realizar con/para este

objeto, como por ejemplo abrir, cerrar, buscar, cancelar, agregar, eliminar. De la

misma manera que el nombre de un atributo, el nombre de una operación se escribe

con minúsculas si consta de una sola palabra. Por ejemplo: abrirPuerta, cerrarPuerta,

buscarPuerta, etc.

• Interfaz es un conjunto de operaciones y/o propiedades que permiten a un objeto

comportarse de cierta manera, por lo que define los requerimientos mínimos del

objeto.

• Herencia se define como la reutilización de un objeto padre ya definido para poder

extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las

operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede

subdividirse en Proveedores, Acreedores, Accionistas, Empleados; todos comparten

datos básicos como una persona, pero además tendrá información adicional que

depende del tipo de persona, como saldo del cliente, total de inversión del accionista,

salario del empleado, etc.

Durante el proceso del diseño de las clases se toman las propiedades que identifican

como único al objeto y otras propiedades adicionales como datos que corresponden al

objeto.

En el diagrama de clases se incluye información como la relación entre un objeto y

otro, la herencia de propiedades de otro objeto y el conjunto de operaciones/propiedades.




Figura 2.14 Diagrama de Clases.

2. Diagrama de componentes

Un diagrama de componentes representa como un sistema de software es dividido encomponentes y muestra las dependencias entre estos componentes. Los componentes

físicos incluyen archivos, cabeceras, librerías compartidas, módulos, ejecutables, o

paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de

software pero pueden ser usados para modelar y documentar cualquier arquitectura de

sistema.

Debido a que estos diagramas son más parecidos a los diagramas de casos de usos

estos son utilizados para modelar la vista estática de un sistema. Muestra la organización ylas dependencias entre un conjunto de componentes. No es necesario que un diagrama

incluya todos los componentes del sistema, normalmente se realizan por partes. Cada

diagrama describe un apartado del sistema.


http://es.wikipedia.org/wiki/Diagrama_de_componentes

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Componentes_de_software

http://es.wikipedia.org/w/index.php?title=Dependencia_(UML)&action=edit&redlink=1

http://es.wikipedia.org/wiki/Archivo_(computaci%C3%B3n)

http://es.wikipedia.org/wiki/Biblioteca_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/M%C3%B3dulo_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/Ejecutable

http://es.wikipedia.org/wiki/Paquete_de_software

http://es.wikipedia.org/wiki/Arquitectura_de_software


http://es.wikipedia.org/wiki/Diagrama_de_componentes

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Componentes_de_software

http://es.wikipedia.org/w/index.php?title=Dependencia_(UML)&action=edit&redlink=1

http://es.wikipedia.org/wiki/Archivo_(computaci%C3%B3n)

http://es.wikipedia.org/wiki/Biblioteca_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/M%C3%B3dulo_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/Ejecutable

http://es.wikipedia.org/wiki/Paquete_de_software





En él situaremos librerías, tablas, archivos, ejecutables y documentos que formen

parte del sistema. Uno de los usos principales es que puede servir para ver qué

componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Figura 2.15 Diagrama de Componentes.

3. Diagrama de objetos

Se puede considerar un caso especial de un diagrama de clases en el que se

muestran instancias específicas de clases (objetos) en un momento particular del sistema.

Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase.

En los diagramas de objetos no se muestra la multiplicidad ni los roles, aunque su notación

es similar a los diagramas de clase.

Una diferencia con los diagramas de clase es que el compartimiento de los diagramas

de clase va en la forma, Nombre de objeto: Nombre de clase.

Por ejemplo, Miguel: Persona.


http://es.wikipedia.org/wiki/Diagrama_de_objetos

http://es.wikipedia.org/wiki/Diagrama_de_clases

http://es.wikipedia.org/wiki/Clase_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/Objeto_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/Multiplicidad

http://es.wikipedia.org/wiki/Rol

http://es.wikipedia.org/wiki/Diagrama_de_objetos

http://es.wikipedia.org/wiki/Diagrama_de_clases

http://es.wikipedia.org/wiki/Clase_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/Objeto_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/Multiplicidad

http://es.wikipedia.org/wiki/Rol



Figura 2.16 Diagrama de Objetos.

4. Diagrama de despliegue

Estos diagramas se utilizan para modelar el hardware utilizado en la implementación

de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de

diagrama son nodos (representados como un prisma), componentes (representados como

una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede

haber artefactos u otros nodos dentro de un nodo.

Un artefacto puede ser un archivo, un programa, una biblioteca, o una base de datos

construida o modificada en un proyecto. Estos artefactos implementan colecciones de

componentes.


http://es.wikipedia.org/wiki/Diagrama_de_despliegue

http://es.wikipedia.org/wiki/Diagrama_de_despliegue



La mayoría de las veces el modelado de la vista de despliegue implica modelar la

topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje

de especificación hardware de propósito general, se ha diseñado para modelar muchos de

los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero de software

pueda especificar la plataforma sobre la que se ejecuta el software del sistema. Algunos delos usos que se les da a los diagramas de despliegue son para modelar:

• Sistemas empotrados: Un sistema empotrado es una colección de hardware con una

gran cantidad de software que interactúa con el mundo físico.

• Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro

de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red

de los clientes a los servidores y sobre la distribución física de los componentes

software del sistema a través de nodos.• Sistemas completamente distribuidos: En el otro extremo encontramos aquellos

sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen

varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de

componentes software, alguno de los cuales pueden incluso migrar de un nodo a

otro.

Figura 2.17 Diagrama de Despliegue.

5. Diagrama de paquetes


http://es.wikipedia.org/wiki/Diagrama_de_paquetes

http://es.wikipedia.org/wiki/Diagrama_de_paquetes



Un diagrama de paquetes muestra como un sistema está dividido en agrupaciones

lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un

paquete está pensado como un directorio, los diagramas de paquetes suministran una

descomposición de la jerarquía lógica de un sistema.

Los Paquetes están normalmente organizados para maximizar la coherencia interna

dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas

líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada

paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos

pueden indicar el orden de desarrollo requerido.

Figura 2.18 Diagrama de paquetes.

2.3.4.2. Diagramas de Comportamiento

Los Diagramas de Comportamiento se utilizaron para enfatizar en lo que debe

suceder en el sistema modelado:

1. Diagrama de actividades


http://es.wikipedia.org/wiki/Diagrama_de_actividades

http://es.wikipedia.org/wiki/Diagrama_de_actividades



Un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y

operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el

flujo de control general.

El propósito del diagrama de actividad es modelar un proceso de flujo de trabajo(workflow) y/o modelar operaciones. Una Operación es un servicio proporcionado por un

objeto, que está disponible a través de una interfaz. Una Interfaz es un grupo de operaciones

relacionadas con la semántica.

Figura 2.19 Diagrama de Actividades.2. Diagrama de casos de uso


http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso




El estándar de Lenguaje de Modelado Unificado define una notación gráfica para

realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha

gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su

descripción). Mientras la notación gráfica y las descripciones son importantes, ellos forman

parte de la documentación de un caso de uso, un propósito para que el actor pueda usar elsistema.

El valor verdadero de un caso de uso reposa en dos áreas:

• La descripción escrita del comportamiento del sistema al afrontar una tarea de

negocio o un requisito de negocio. Esta descripción se enfoca en el valor

suministrado por el sistema a entidades externas tales como usuarios humanos u

otros sistemas.

• La posición o contexto del caso de uso entre otros casos de uso. Dado que es un

mecanismo de organización, un conjunto de casos de uso coherentes, consistentes,

promueve una imagen fácil del comportamiento del sistema, un entendimiento común

entre el cliente/propietario/usuario y el equipo de desarrollo.

Figura 2.20 Diagrama de Casos de Uso.

El diagrama de arriba describe la funcionalidad de un Sistema Restaurante muy

simple. Los casos de uso están representados por elipses y los actores están representados


http://es.wikipedia.org/wiki/UML

http://es.wikipedia.org/wiki/Casos_de_uso

http://es.wikipedia.org/w/index.php?title=Comportamiento_del_sistema&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Tarea_de_negocio&action=edit&redlink=1


http://es.wikipedia.org/w/index.php?title=Requisito_de_negocio&action=edit&redlink=1

http://es.wikipedia.org/wiki/Actor

http://es.wikipedia.org/wiki/UML

http://es.wikipedia.org/wiki/Casos_de_uso

http://es.wikipedia.org/w/index.php?title=Comportamiento_del_sistema&action=edit&redlink=1



http://es.wikipedia.org/w/index.php?title=Requisito_de_negocio&action=edit&redlink=1

http://es.wikipedia.org/wiki/Actor



por las figuras humanas. El actor Crítico de comidas puede Probar la comida, Pagar la

comida, o Beber vino. Sólo el actor Chef puede Preparar la comida. Podría ser que ambos

Patrón y Cajero estén involucrados en el caso de uso Pagar la comida. El marco define los

límites del sistema Restaurante, por ejemplo, los casos de uso se muestran como parte del

sistema que está siendo modelado, los actores no.

La interacción entre actores no se ve en el diagrama de casos de uso. Si esta

interacción es esencial para una descripción coherente del comportamiento deseado, quizás

los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la

interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin

embargo, darse cuenta que los actores son una especie de rol, un usuario humano u otra

entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser

realmente la misma persona.

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar

UML, el cual describe notación gráfica para esas relaciones.

• Inclusión (Include) o (use)

Es una forma de interacción, un caso de uso dado puede "incluir" otro. El primer caso

de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer

comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción

individual, desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta

"include". Este uso se asemeja a una expansión de una macro, donde el comportamiento del

caso incluido es colocado dentro del comportamiento del caso de uso base. No hay

parámetros o valores de retorno.

• Extensión (Extend)




Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a

otro. Esta relación indica que el comportamiento del caso de uso extensión puede ser

insertado en el caso de uso extendido bajo ciertas condiciones. La notación es una flecha

rayada desde el caso de uso extensión al caso de uso extendido, con la etiqueta “extend”.

Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitosdurante el mantenimiento del sistema y su extensión. La extensión se utiliza en casos de

uso, un caso de uso a otro caso siempre debe tener extensión o inclusión.

• Generalización

En la tercera forma de relaciones entre casos de uso, existe una relación

generalización/especialización. Un caso de uso dado puede estar en una forma

especializada de un caso de uso existente. La notación es una línea solida terminada en un

triángulo dibujado desde el caso de uso especializado al caso de uso general.

3. Diagrama de estados

Los Diagramas de Estados se usan para representar gráficamente máquinas de

estados finitos. Las Tablas de Transiciones son otra posible representación. Hay muchas

formas de diagramas de estados que difieren levemente y tienen semánticas diferentes.

Figura 2.21 Diagrama de estados.

Lenguaje Unificado de Modelado (UML) especifica una notación estandarizada para

diagramas de estado que puede utilizarse para describir clases, sistemas, subsistemas o


http://es.wikipedia.org/wiki/Diagrama_de_estados

http://es.wikipedia.org/wiki/Aut%C3%B3mata_finito


http://es.wikipedia.org/wiki/Tabla_de_transici%C3%B3n_de_estados

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

http://es.wikipedia.org/wiki/Diagrama_de_estados



http://es.wikipedia.org/wiki/Tabla_de_transici%C3%B3n_de_estados

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado



incluso procesos de negocio. Los elementos básicos de notación que se ocuparon para

componer un diagrama de estado son:

• Círculo lleno, apuntando a un estado inicial

•

Círculo hueco que contiene un círculo lleno más pequeño en el interior, indicando elestado final (si existiera)

• Rectángulo redondeado, denotando un estado. En la parte superior del rectángulo

está el nombre del estado. Puede contener una línea horizontal en la mitad, debajo

de la cual se indican las actividades que se hacen en el estado

• Flecha, denotando transición. El nombre del evento (si existiera) que causa esta

transición etiqueta el cuerpo de la flecha. Se puede añadir una expresión de Guarda,

encerrada en corchetes( [] ) denotando que esta expresión debe ser cierta para que

la transición tenga lugar. Si se realiza una acción durante la transición, se añade a laetiqueta después de "/". NombreDeEvento[ExpresiónGuarda]/acción

• Línea horizontal gruesa con x>1 líneas entrando y 1 línea saliendo o 1 línea entrando

y x>1 líneas saliendo. Estas denotan Unión/Separación, respectivamente.

2.3.4.3. Diagramas de Interacción

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, queenfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

1. Diagrama de secuencia

El diagrama de secuencia es uno de los diagramas más efectivos para modelar

interacción entre objetos en un sistema. En estos diagramas se muestra la interacción de un

conjunto de objetos en una aplicación a través del tiempo y el modelado para cada método

de la clase. Mientras que el diagrama de casos de uso permite el modelado de una vistabusiness del escenario, el diagrama de secuencia contiene detalles de implementación del

escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y

mensajes pasados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué

objetos son necesarios para la implementación del escenario.


http://es.wikipedia.org/wiki/Diagrama_de_secuencia


http://es.wikipedia.org/wiki/Caso_de_uso

http://es.wikipedia.org/wiki/Diagrama_de_secuencia





Si tienes modelada la descripción de cada caso de uso como una secuencia de varios

pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son

necesarios para que se puedan seguir los pasos.

En el diagrama de secuencia se mostraron los objetos que intervienen en elescenario, por medio de líneas discontinuas verticales, y los mensajes pasados entre los

objetos fueron representados con flechas horizontales.

Figura 2.22 Diagrama de secuencia.

Existen dos tipos de mensajes: síncronos y asíncronos. Los mensajes síncronos se

corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía

el mensaje queda bloqueado hasta que termina la llamada. Para este tipo de mensajes se

utilizaron flechas con la cabeza llena. Los mensajes asíncronos terminan inmediatamente, y

crean un nuevo hilo de ejecución dentro de la secuencia. Estos se representaron mediante

flechas con la cabeza abierta y las respuestas a un mensaje con una flecha discontinua.

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la

parte inferior; la distribución horizontal de los objetos es arbitraria.

2.3.5. Visual Paradigm for UML.



http://es.wikipedia.org/wiki/Archivo:Sequencia.png




Visual Paradigm for UML es una herramienta UML profesional que soporta el ciclo de

vida completo del desarrollo de software: análisis y diseño orientados a objetos,

construcción, pruebas y despliegue.

El software de modelado UML ayuda a una rápida construcción de aplicaciones decalidad, mejores y a un menor coste. Permite dibujar todos los tipos de diagramas de clases,

código inverso, generar código desde diagramas y generar documentación.

Lista de características:

• Soporte de UML versión 2.1.

• Diagramas de Procesos de Negocio - Proceso, Decisión, Actor de negocio,

Documento.

• Ingeniería inversa - Código a modelo, código a diagrama.

• Ingeniería inversa Java, C++, Esquemas XML, XML,.NET exe/dll, CORBA IDL.

• Generación de código - Modelo a código, diagrama a código.

• Editor de Detalles de Casos de Uso - Entorno todo-en-uno para la especificación de

los detalles de los casos de uso, incluyendo la especificación del modelo general y de

las descripciones de los casos de uso.

• Diagramas EJB - Visualización de sistemas EJB.

• Generación de código y despliegue de EJB´s - Generación de beans para el

desarrollo y despliegue de aplicaciones.

• Diagramas de flujo de datos.

• Soporte ORM - Generación de objetos Java desde la base de datos.

• Generación de bases de datos - Transformación de diagramas de Entidad-Relación

en tablas de base de datos.

• Ingeniería inversa de bases de datos - Desde Sistemas Gestores de Bases de Datos

(DBMS) existentes a diagramas de Entidad-Relación.

•

Generador de informes para generación de documentación.• Distribución automática de diagramas - Reorganización de las figuras y conectores de

los diagramas UML.

• Importación y exportación de ficheros XMI.

• Integración con Visio - Dibujo de diagramas UML con plantillas (stencils) de MS Visio.

• Editor de figuras.




Otras herramientas y plugins de modelado UML:

Plataforma Java (Windows/Linux/Mac OS X):• SDE para Eclipse.

• SDE para NetBeans.

• SDE para Sun ONE.

• SDE para Oracle JDeveloper.

• SDE para JBuilder.

• SDE para IntelliJ IDEA.

• SDE para WebLogic Workshop.

Plataforma Windows:

• SDE para Microsoft Visual Studio.

Requerimientos del sistema:

• Intel Pentium III Compatible Procesador a 1.0 GHz o superior.

• Mínimo 512MB RAM, pero se recomienda 1.0 GB.

• Mínimo 400MB de espacio en el disco duro.




2.4DISEÑO

2.4.1 Diccionario de Datos

Un diccionario de datos es un conjunto de metadatos que contiene las características

lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre,

descripción, alias, contenido y organización.

Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los

analistas que participan en la determinación de los requerimientos del sistema, su contenido

también se emplea durante el diseño del proyecto.

Identifica los procesos donde se emplean los datos y los sitios donde se necesita el

acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia

a los analistas que participan en la determinación de los requerimientos del sistema, su

contenido también se emplea durante el diseño.

En un diccionario de datos se encuentra la lista de todos los elementos que forman

parte del flujo de datos de todo el sistema. Los elementos más importantes son flujos de

datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y

descripción de todos estos elementos.

2.4.2 Modelo Entidad-Relación

El modelado entidad-relación es una técnica para el modelado de datos utilizando

diagramas entidad relación. No es la única técnica pero sí la más utilizada. Brevemente

consiste en los siguientes pasos:

1. Se parte de una descripción textual del problema o sistema de información a

automatizar (los requisitos).

2. Se hace una lista de los sustantivos y verbos que aparecen.

3. Los sustantivos son posibles entidades o atributos.

4. Los verbos son posibles relaciones.




5. Analizando las frases se determina la cardinalidad de las relaciones y otros detalles.

6. Se elabora el diagrama (o diagramas) entidad-relación.

7. Se completa el modelo con listas de atributos y una descripción de otras restricciones

que no se pueden reflejar en el diagrama.

Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia

para lograr buenos modelos de datos.

El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras

técnicas para lograr un modelo directamente implementable en una base de datos.

• Transformación de relaciones múltiples en binarias.

• Normalización de una base de datos de relaciones (algunas relaciones puedentransformarse en atributos y viceversa).

• Conversión en tablas (en caso de utilizar una base de datos relacional).

2.4.2.1 Base Teórica y Conceptual

El modelo entidad-relación se basa en los conceptos descritos a continuación para

representar un modelo de la vida real.

Entidad

Representa una “cosa” u "objeto" del mundo real con existencia independiente, es

decir, se diferencia unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo

tipo.

Ejemplos:

• Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).

• Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán

atributos diferentes, por ejemplo, el número de motor).

• Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).




Una entidad puede ser un objeto con existencia física como: una persona, un animal,

un casa, etc. (entidad concreta), o un objeto con existencia conceptual como: un puesto de

trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta).

Una entidad está descrita y se representa por sus características o atributos. Por

ejemplo, la entidad Persona puede llevar consigo las características: Nombre, Apellido,

Sexo, Estatura, Peso, Fecha de nacimiento, etc.

• Conjunto de Entidades

Es una colección de entidades que comparten los mismos atributos o características.

Ejemplos:

• Todos los atletas que participan en los Juegos Olímpicos, comparten sus atributos:

nombre, número de identificación, edad, peso, categoría...

• Todos los países del mundo, comparten las características: nombre, continente, área,

lengua principal, lengua secundaria, moneda, etc.

Atributos

Los atributos son las propiedades que describen a cada entidad en un conjunto de

entidades. Un conjunto de entidades dentro de una entidad, tiene valores específicos

asignados para cada uno de sus atributos, de esta forma, es posible su identificación

unívoca.

Ejemplos:

A la colección de entidades Alumnos, con el siguiente conjunto de atributos en

común, (id, nombre, edad, semestre), pertenecen las entidades:

• (1, Sophie, 18 años, 2)

• (2, Penny, 19 años, 5)

• (3, Sophie, 20 años, 2)




Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás

por el valor de sus atributos. Nótese que dos o más entidades diferentes pueden tener los

mismos valores para algunos de sus atributos, pero nunca para todos.

En particular, los atributos identificativos son aquellos que permiten diferenciar a unainstancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a

un alumno de otro es su número de id.

Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos

que será almacenado o a restricciones en los valores que el atributo puede tomar (Cadenas

de caracteres, números, solo dos letras, solo números mayores que cero, solo números

enteros). Cuando una entidad no tiene un valor para un atributo dado, este toma el valor

nulo, bien sea que no se conoce, que no existe o que no se sabe nada al respecto delmismo.

Relación

Describe cierta dependencia entre entidades o permite la asociación de las mismas.

Ejemplo:

Dadas dos entidades "Habitación 502" y "Mark", es posible relacionar que la

habitación 502 se encuentra ocupada por el huésped de nombre Mark.

Una relación tiene sentido al expresar las entidades que relaciona. En el ejemplo

anterior, Un Huésped (entidad), se aloja (relación) en una habitación (entidad).

• Conjunto de Relaciones

Consiste en una colección de relaciones de la misma naturaleza.

Ejemplo:




Dados los conjuntos de entidades "Habitación" y "Huésped", todas las relaciones de

la forma habitación-huésped, permiten obtener la información de los huéspedes y sus

respectivas habitaciones.

La dependencia o asociación entre los conjuntos de entidades es llamadaparticipación. En el ejemplo anterior los conjuntos de entidades "Habitación" y "Huésped"

participan en el conjunto de relaciones habitación-huésped. Se llama grado del conjunto de

relaciones a la cantidad de conjuntos de entidades participantes en la relación.

Restricciones

Son reglas que deben mantener los datos almacenados en la base de datos.

• Correspondencia de Cardinalidades

Dado un conjunto de relaciones en el que participan dos o más conjuntos de

entidades, la correspondencia de cardinalidad indica el número de entidades con las que

puede estar relacionada una entidad dada.

Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, lacorrespondencia de cardinalidades puede ser:

• Uno a uno: Una entidad de A se relaciona únicamente con una entidad en B y

viceversa.

• Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B.

Pero una entidad en B se relaciona con una única entidad en A.

• Varios a uno: Una entidad en A se relaciona exclusivamente con una entidad en B.

Pero una entidad en B se puede relacionar con 0 o muchas entidades en A.• Varios a varios: Una entidad en A se puede relacionar con 0 o muchas entidades en

B y viceversa.

• Restricciones de Participación




Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A,

dicha participación puede ser de dos tipos:

Total: Cuando cada entidad en A participa en al menos una relación de R.Parcial: Cuando al menos una entidad en A NO participa en alguna relación de R.

Claves

Es un subconjunto del conjunto de atributos comunes en una colección de entidades,

que permite identificar unívocamente cada una de las entidades pertenecientes a dicha

colección. Asimismo, permiten distinguir entre sí las relaciones de un conjunto de relaciones.

Dentro de los conjuntos de entidades existen los siguientes tipos de claves:

• Superclave: Es un subconjunto de atributos que permite distinguir unívocamente

cada una de las entidades de un conjunto de entidades. Si otro atributo unido al

anterior subconjunto, el resultado seguirá siendo una superclave.

• Clave candidata: Dada una superclave, si ésta deja de serlo removiendo únicamente

uno de los atributos que la componen, entonces ésta es una clave candidata.

• Clave primaria: Es una clave candidata, elegida por el diseñador de la base de

datos, para identificar unívocamente las entidades en un conjunto de entidades.

Los valores de los atributos de una clave, no pueden ser todos iguales para dos o

más entidades. Para poder distinguir unívocamente las relaciones en un conjunto de

relaciones R, se deben considerar dos casos:

• R NO tiene atributos asociados: En este caso, se usa como clave primaria de R launión de las claves primarias de todos los conjuntos de entidades participantes.

• R tiene atributos asociados: En este caso, se usa como clave primaria de R la

unión de los atributos asociados y las claves primarias de todos los conjuntos de

entidades participantes.




Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave

primaria está compuesto de relaciones binarias, con los conjuntos de entidades participantes

A y B, se consideran los siguientes casos, según sus cardinalidades:

• R es de muchos a uno de A a B entonces sólo se toma la clave primaria de A, comoclave primaria de R.

• R es de uno a muchos de A a B entonces se toma sólo la clave primaria de B, como

clave primaria de R.

• R es de uno a uno de A a B entonces se toma cualquiera de las dos claves

primarias, como clave primaria de R.

2.4.3 Diagramas Extendidos

Los diagramas Entidad-Relación no cumplen su propósito con eficacia debido a que

tienen limitaciones semánticas. Por ese motivo se suelen utilizar los diagramas Entidad-

Relación extendidos que incorporan algunos elementos más al lenguaje.

Entidades Fuertes y Débiles

Cuando una entidad participa en una relación puede adquirir un papel fuerte o débil.

Una entidad débil es aquella que no puede existir sin participar en la relación, es decir,

aquella que no puede ser unívocamente identificada solamente por sus atributos. Una

entidad fuerte (también conocida como entidad regular) es aquella que sí puede ser

identificada unívocamente. En los casos en que se requiera, se puede dar que una entidad

fuerte "preste" algunos de sus atributos a una entidad débil para que, esta última, se pueda

identificar.

Las entidades débiles se representan mediante un doble rectángulo, es decir, un

rectángulo con doble línea.

• Cardinalidad de las relaciones




El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la

relación, respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del lenguaje

utilizado, la que más se usa actualmente es el unificado. Otra forma de expresar la

cardinalidad es situando un símbolo cerca de la línea que conecta una entidad con una

relación:

"0" si cada instancia de la entidad no está obligada a participar en la relación.

"1" si toda instancia de la entidad está obligada a participar en la relación y, además,

solamente participa una vez.

"N" , "M", ó "*" si cada instancia de la entidad no está obligada a participar en la

relación y puede hacerlo cualquier número de veces.

Ejemplos de relaciones que expresan cardinalidad:

Cada esposo (entidad) está casado (relación) con una única esposa (entidad) y

viceversa. Es una relación 1:1.

Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una, pero una

persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a

nombre de alguien. Es una relación 1:N.

Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un artículo

puede ser comprado por varios clientes distintos. Es una relación N:M.

• Atributos en relaciones

Las relaciones también pueden tener atributos asociados. Se representan igual que

los atributos de las entidades. Un ejemplo típico son las relaciones de tipo "histórico" donde

debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer

constar la fecha de emisión de una factura a un cliente, y que es posible emitir duplicados de




la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisión" de la factura

debería colocarse en la relación "se emite".

• Herencia

La herencia es un intento de adaptación de estos diagramas al paradigma orientado a

objetos. La herencia es un tipo de relación entre una entidad "padre" y una entidad "hijo". La

entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no

necesitan ser representadas dos veces en el diagrama. La relación de herencia se

representa mediante un triángulo interconectado por líneas a las entidades. La entidad

conectada por el vértice superior del triángulo es la entidad "padre". Solamente puede existir

una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del

triángulo.




CAPITULO III

ANÁLISIS Y DISEÑO DEL SISTEMADE CONTROL PRESUPUESTAL



3.1 ANÁLISIS

Esta etapa consistió en analizar los requerimientos del sistema, además conseguir

una comprensión más precisa de los requisitos y una descripción de los mismos, y así tener

una visión correcta acerca del funcionamiento del sistema, y poder alcanzar los objetivos

propuestos y evaluar sus consecuencias.

Dentro de esta etapa se realizaron las siguientes actividades de la Ingeniería de

Requerimientos.

3.1.1 Extracción de Requisitos

En esta actividad se descubrieron los requerimientos del sistema. Aquí se trabajo

junto con el cliente y los usuarios, mediante técnicas para la obtención de los requerimientos

como son reuniones de trabajo, sistemas existentes, esto para descubrir el problema que el

sistema debía resolver, los servicios que el sistema debía prestar, las restricciones que se

podían presentar, las personas que utilizarían el sistema, entre otros aspectos.

Para los requerimientos del usuario, únicamente se especificó el comportamiento

externo del sistema, tanto como fue posible, las características de diseño del sistema. Por

consiguiente, en la redacción de los requisitos del usuario, no se utilizó jerga del software,

notaciones estructuradas o formales, o describir los requerimientos por la descripción de la

implementación del sistema. Estos fueron redactados en lenguaje sencillo, con formularios

sencillos y diagramas intuitivos.

En el caso de los requerimientos de sistema, se establecieron con detalle las

funciones, servicios y restricciones operativas del sistema. Aquí se elaboro el documento de

requerimientos del sistema (algunas veces denominado especificación funcional), el cual se

detalla más adelante. Ya que se definió exactamente qué es lo que se iba a implementar.

Como se menciona anteriormente, para el desarrollo del proyecto fue parte del contrato con

el cliente.




En teoría, los requerimientos del sistema simplemente describen el comportamiento

externo del sistema y sus restricciones operativas. No tratan de cómo se debe diseñar o

implementar el sistema. Sin embargo, en el nivel de detalle requerido para especificar

completamente un sistema software complejo, es imposible, en la práctica, excluir toda la

información de diseño.

Uno de los requerimientos encontrados fue el Reporte Mensual de Variaciones

(Figura 3.1) el cuál se lleva a gran rubro, y para fines del sistema deberá ser mas especifico.

Figura 3.1 Estructura actual del Reporte Mensual de Variaciones




Otro de los formatos identificados fue el formato de Solicitud de Presupuesto, que

aplicaban a los usuarios de cada centro de costo de forma manual en hojas de cálculo. Son

dos hojas que estaban enlazadas, en la figura 3.4 solo se muestran las cuentas generales y

la figura 3.3 los detalles de cada una.

Figura 3.2 Justificación de Solicitud de Presupuesto

Figura 3.3 Solicitud de Presupuesto

3.1.2 Análisis y Negociación de Requisitos

Durante esta apartado se realizó un análisis de los requisitos identificados en la etapa

anterior, se evaluaron para constatar que cumplieran con las características que debe

cumplir un requerimiento, necesario, no ambiguo, conciso, consistente, completo,

alcanzable, verificable.

Se verifico si existían requerimientos que se pudieran unir con otro, o deducir si era

innecesario.

3.1.3 Especificación de Requisitos




Se realizó la Especificación de Requisitos, según el estándar de IEEE/ANSI 830-

1998(IEEE, 1998) donde se sugiere describir los requerimientos del sistema de “Control

Presupuestal”, basándose en las reuniones con los involucrados en el proceso, la

información recabada es parte fundamental para el desarrollo del proyecto.

3.1.3.1 Propósito de los requerimientos.

La finalidad es detallar de manera clara y precisa los requerimientos solicitados por el

usuario. Además de llegar a un punto en común para la determinación de esos requisitos.

El objetivo principal del proyecto es desarrollar un software que permita a losresponsables llevar el control y registro del proceso presupuestal, donde se involucran

diferentes actividades y recursos como son: “Budget”, reportes, usuarios, EBIS, entre otros.

3.1.3.2 Alcance del sistema.

Este documento tiene como alcance, especificar los requerimientos del software a

desarrollar. Así como proporcionar a los clientes y desarrolladores un panorama más ampliode lo que se desea realizar.

El sistema podrá realizar modificaciones al presupuesto inicializado por el usuario de

cada centro de costo, agregar presupuesto de un determinado centro de costo, generar

reportes, entre otros.

Los reportes serán visualizados en pantalla o un formato como puede ser pdf.




3.1.3.3 Referencias.

• ANSI/IEEE Std. 830-1984. Guía del IEEE para la Especificación de Requerimientos

Software.

• Anexo 1. Requerimiento Presupuesto TNG. Requerimiento 1.ppt

• Anexo 2. Mapeo General. Base de Datos.xls

• Anexo 3. Instructivo para el llenado de los formatos. Instructivo _ formatos 2009.ppt.

3.1.3.4 Perspectiva del sistema.

El sistema de Control Presupuestal debe llevar el control y registro del presupuesto

por departamento. El sistema ayudará a tener una mejor administración y planificación delpresupuesto con respecto a los ingresos, gastos, ajustes y demás aspectos contables.

3.1.3.5 Funciones del sistema.

a) Almacenamiento de datos

o Almacenamiento de datos del cliente

Almacena presupuesto anual, detallado por mes, y justificado en lascuentas procedentes de un catalogo (COA). Además de la información

personal del usuario.

o Almacenamiento de datos de EBIS

Almacena datos de la balanza EBIS para la generación de reportes de

control de gastos. Algunos de los datos son: número de centro de

costo, cuenta, descripción del ítem, el presupuesto actual, entre otros.

o Almacenamiento de datos de DataStream

Almacena datos provenientes de los techos de compra (existencias en

almacén, monto de órdenes de compra pendientes, calculo de techos

de compra remanentes, etc.), para la realización de reportes de las

compras que se realizan por departamento.




b) Generación de reportes

o Generación de reporte para el usuario

El sistema debe generar un reporte mensual de variaciones de su

centro de costo.

o Generación de reportes para el Administrador

El sistema debe elaborar los siguientes reportes para ser consultados

por el administrador: reporte de presupuesto anual y mensual,

consolidado de los centros de costo y reportes personalizados.

o Generación de reportes para el Gerente Gral.

El sistema debe realizar el reporte con concentrado de variaciones y el

resumen ejecutivo mensual.

3.1.3.6 Características del usuario.

El sistema de “Control Presupuestal” solo será utilizado por personas de la empresa

Talleres Navales del Golfo, que se involucran en el proceso de control de presupuestos.

El usuario podrá usar el sistema una vez que esté dado de alta y tenga conocimientos

sobre su uso. Las funciones del sistema estarán limitadas de acuerdo al tipo de usuario, por

ejemplo administrador, gerente de departamento o gerente general.

3.1.3.7 Requerimientos de Usuario

1. El sistema de “Control Presupuestal” dará acceso a 2 administradores, un gerente

que es el que autorizará el presupuesto y usuarios finales. El sistema permitirá

asignar más de un centro de costo a un usuario y más de un usuario a un centro de

costo.

2. Dicho sistema deberá contener un catalogo de cuentas (COA) utilizado en el mapeo

de cuentas que se hace dentro del área de finanzas, y de utilidad para el usuario a la

hora de llenar el formato de Solicitud de Presupuesto mensual y anual.




3. Se requieren 6 escenarios de presupuesto: solicitud de presupuesto, presupuesto

autorizado, presupuesto 1qf (Quater Forecast), presupuesto 2qf, presupuesto 3qf,

presupuesto 4qf. Estos 4 últimos son las revisiones que se llevan a cabo durante el

año, donde se pueden realizar ajustes al presupuesto autorizado.

4. El usuario del centro de costo deberá llenar el formato de Solicitud de Presupuesto

anual, por medio de una pantalla de captura de datos, fácil de operar e identificar su

centro(s) de costo(s) y cuentas a utilizar, posteriormente el sistema podrá exportar

dicha información para las actividades de consolidación, monitoreo y evaluación de

contenido.

5. Un apartado de ajustes donde se permita registrar los movimientos que se realizan al

presupuesto autorizado por centro de costo, en caso de ser solicitado por elcorporativo y/o gerente general.

6. El sistema podrá consolidar los centros de costo en base a la carga de presupuesto y

el reporte de EBIS. La balanza EBIS refleja el presupuesto ejercido en cada centro de

costo y cuentas, los niveles de comparación se realizan por mes, año y acumulado a

una fecha.

7. El sistema deberá generar un reporte de variaciones mensual por centro de costo elcual será consultado por el usuario, donde este mostrara el presupuesto autorizado,

la variación del presupuesto, el presupuesto acumulado y el porcentaje de

presupuesto disponible, por cada fecha de corte. De igual forma generar un reporte

para los administradores donde se muestren las variaciones de los centros de costo.

La variación que presenta el reporte deberá ser en Mxp y en %; primeramente

comparará los montos autorizados y ejercidos en el mes, posteriormente el

acumulado a la fecha de cierre contra el autorizado acumulado a la fecha de cierre y

por ultimo en acumulado a la fecha de cierre contra el presupuesto anual autorizado.

8. Generación de resumen ejecutivo mensual exclusivo para Gerencia General como

son el concentrado de variaciones de todos los centros de costo (Acumulado y % de

variación), comparativo de presupuesto de horas-hombre y gastos (moneda nacional

y dólares), observaciones a cada centro de costo por parte de planeación financiera.




El resumen tiene como finalidad dar a conocer de manera general el comportamiento

del presupuesto de la empresa ante la gerencia general.

9. El sistema tendrá una base de datos general, la cual contendrá los siguientes datos:

Figura 3.4 Requerimiento BD Presupuestos vs Actuales

10. El sistema llevara el control de techos de compra de 3 áreas en específico:

Producción, Mantenimiento y Proyectos.

11. Creación de una base de datos para los techos de compra.

Figura 3.5 Requerimiento BD Techos de Compra

12. Manejo de moneda nacional y dólares. Con la disposición de introducir cambios

indicados por el corporativo para efecto del cierre del mes.




Para el flujo de información se llevaron a cabo los reportes de estado Financiero,

Variaciones, Presupuesto y Estados Financieros mensual, acumulado y actual. Estos extraen

información del Sistema EBIS en Oracle, el cual incluye Cuentas por pagar, Activo Fijo,

Provisiones Movimientos Manuales, así sistemas relacionados (PSR y DataStream).

De los techos de compra se obtiene el proceso de órdenes de compra, existencias,

presupuesto, provisiones, gastos/Balanza. Gracias al Sistema EBIS se obtiene las

variaciones (Presupuesto vs Balanza) mensual, acumulado, actual.

Figura 3.6 Flujo de Información

3.1.3.8 Requerimientos Funcionales




Definen las tareas o funciones que el sistema de “Control Presupuestal” será capaz

de realizar, para ello se tienen los siguientes requerimientos.

1. Validación de acceso al sistema. Una pantalla de bienvenida solicitando el inicio de

sesión por medio de un nombre de usuario y su password.

2. El sistema contara con diferentes perfiles de usuario para restringir el acceso a ciertas

opciones del sistema. Cada usuario de centro de costo podrá visualizar su(s) centro(s)

de costo, por lo cual cuando se generen las cuentas de los usuarios se deberá

especificar los centros de costo a los que tendrá acceso.

3. Existirán catálogos en el sistema que se mostraran en pantalla como son: un catalogo de

los perfiles de los usuarios, un catalogo de cuentas, un catalogo de los centros de costo,un catalogo con el mapeo de las cuentas por cada centro de costo.

4. El administrador podrá agregar una cuenta en el catalogo de cuentas, considerando el

número de cuenta, descripción de la cuenta y el rubro al que pertenece.

5. Permitir el ingreso de presupuesto a cada usuario de centro de costo, por medio de una

pantalla de captura. El monto será capturado según lo indique el Corporativo.

6. El usuario podrá buscar una cuenta dentro del catalogo de cuentas, mostrando los

detalles como son el nombre de la cuenta y el rubro al que pertenece.

7. En el momento de captura de presupuesto, los usuarios pertenecientes a los centros de

costo operativos, podrán utilizar las cuentas que se encuentren dentro del Cost of Sales,

y para el caso de los usuarios pertenecientes a los centros de costo administrativos

únicamente las cuentas que se encuentran dentro del Overhead. Para ello el catálogo de

cuentas estará divido en dos categorías: Cost of Sales y Overhead.

8. Los administradores podrán realizar las modificaciones necesarias a los presupuestos

autorizados de cada centro de costo. Cuando se realice un ajuste al presupuesto

autorizado, el sistema lo guardara en la bitácora de movimientos.




9. El gerente y administradores podrán visualizar un reporte de la consolidación del

presupuesto solicitado/autorizado de los centros de costo, mostrando los totales de

presupuesto para el año, así como las variaciones de los montos ejercidos a la fecha, ya

sea en moneda nacional o dólares.

10. El sistema generará un reporte que mostrara las variaciones por mes, año y acumulado

del año. De igual forma el usuario final visualizara el reporte en base a sus permisos.

11. Consultar, exportar, migrar y/o actualizar datos de los sistemas EBIS y Datastream, los

cuales servirán para generar los reportes.

12. Los administradores podrán generar de reportes personalizados de la base de datos

general y de la base de datos de techos de compra.

13. La generación de los reportes se harán de un determinado periodo, mes o año, según lo

solicite el usuario.

3.1.3.9 Requerimientos No Funcionales

Los requerimientos no funcionales especifican propiedades del sistema comorestricciones de ambiente y desarrollo, dependencias de plataformas, actividades de

mantenimiento y confiabilidad.

Para este apartado se contemplan los siguientes requisitos para el sistema:

1. Se entregara un manual de usuario a cada uno de los usuarios finales, donde se

describirá el sistema y principalmente las operaciones que el usuario puede ejecutar.

A los administradores se les brindará un curso para mostrar la totalidad de funcionesque puede realizar el sistema.

2. Al existir un fallo en el sistema, el tiempo de restauración máximo será de 5 minutos

(en estado aceptable) para ponerse en marcha. Se limitara a 3 intentos de inicio de

sesión, en caso de falla, la cuenta será bloqueada y se deberá notificar a los

administradores para desbloquear.




3. Se implantaran funciones de teclado para aumentar la practicidad del sistema, estas

se mostraran en las pantallas del sistema de forma dinámica.

4. Para el usuario final la pantalla de Solicitud de Presupuesto será sencilla de manejar,ya que le permitirá identificar fácilmente los datos necesarios para la elaboración de

su solicitud.

5. Se mostrara al usuario la interfaz como página Web.

6. La aplicación deberá funcionar bajo el sistema operativo Windows.

7. El sistema se debe implementar bajo la infraestructura de las computadorasexistentes en las oficinas de la empresa TNG.

8. Para que un usuario tenga acceso al sistema deberá ser dado de alta.

9. El usuario deberá introducir su equipo al dominio de tnghph.net.mx, además de

contar con una cuenta de acceso a la red de TNG.

3.1.4 Modelado del Sistema

Después de haber analizado y captado cada uno de los requisitos que contienen el

Documento de Especificación de Requisitos, se prosiguió a esta actividad.

Utilizando el Modelado de Lenguaje Unificado se construyeron los diagramas de

clases, objetos, casos de uso, interacción, estado, según lo requirió el sistema.

3.1.4.1 Visual Paradigm for UML.

El software Visual Paradigm for UML se utilizó para diseñar los diagramas realizados

en el modelado del sistema.




Diagrama de Casos de Usos

El siguiente diagrama describe el comportamiento del sistema “Control Presupuestal”,muestra los casos de uso (funciones) que pueden realizar los actores (gerente, usuario y

administrador) sobre el sistema.

Figura 3.7 Diagrama de Casos de Usos

Diagramas de Secuencia




El siguiente diagrama de secuencia, muestra el acceso al sistema, mediante un inicio

de sesión. Por tal motivo, el usuario será dado de alta asignándole un nombre de usuario y

contraseña, manteniendo así el acceso restringido al sistema.

Figura 3.8 Diagrama de secuencia Inicio de sesión

El siguiente diagrama de secuencia, detalla el caso de uso consulta reporte de

variaciones por parte del usuario.

Figura 3.9 Diagrama de secuencia Consulta de Reporte de Variaciones

A continuación se muestra el diagrama de secuencia, que da detalle al caso de uso

consulta de variaciones para administrador.




Figura 3.10 Diagrama de secuencia Consulta de Variaciones para Administrador

El siguiente diagrama de secuencia, detalla el caso de uso captura de presupuesto por parte

del usuario.

Figura 3.11 Captura de presupuesto por parte del usuarioEl diagrama de secuencia que a continuación se muestra corresponde al caso de uso

agregar cuenta.




Figura 3.12 Agregar cuenta

El siguiente diagrama muestra la consulta al consolidado maestro, el cual esta

restringido para ser consultado solo por el administrador, mostrándole todos los Budgets de

cada centro de costo, en fusión con criterios de mapeo EBIS; del cual se extraen los centros

de costo, rubro y descripción del presupuesto en pesos y dólares.

Figura 3.13 Diagrama de secuencia de consulta de Consolidado Maestro




El siguiente diagrama de secuencia detalla el caso de uso consulta catalogo de

cuentas.

Figura 3.14 Diagrama de secuencia Consulta de Catálogo de cuentas

En el diagrama de secuencia siguiente se muestra el caso de uso modifica

presupuesto. Esta actividad es realizada solo por el administrador.




Figura 3.15 Diagrama de secuencia Modifica Presupuesto




Diagramas de Estado

El siguiente diagrama de estados muestra una serie de objetos (validación, solicitud,

autorizado, comparación, bitácora de movimientos, ajustando) y transiciones, que se llevan a

cabo en el ajuste del presupuesto. El diagrama engloba los mensajes que un objeto puederecibir (entry) o hacer (do).

Figura 3.16 Diagrama de Estado Presupuesto




El siguiente diagrama muestra el estado “Consultado” el cual recibe como entrada el

presupuesto, generando el presupuesto actual, autorizado e inicial, este resultado es tomado

como entrada para el estado “Determinado” , este calcula el total de presupuesto,

variaciones, % disponible, acumulado, a partir de estos cálculos el estado “Generado”

genera el reporte de variaciones de determinado centro de costo.

Figura 3.17 Diagrama de Estado de Variación.




Este diagrama muestra el registro de una cuenta, la cual es aprobada por el estado

“Validación”, si los datos son correctos se guardan y son agregados al catalogo de cuentas.

Si los datos no son correctos se vuelve al estado “Captura”.

Figura 3.18 Diagrama de Estado de Cuentas.

Casos de Uso




Nombre: Consulta Reporte de Variaciones

Descripción:Permite generar un reporte con las variaciones del año, mes y acumulado del año.

Actores:Usuario, Administradores, Gerente

Precondiciones:El usuario debe haber elegido un centro de costo y debe haberse logueado en el

sistema.El administrador y gerente deben haberse logueado.

Flujo Normal:

1. El usuario elige en el menú contextual Reporte de Variaciones.2. Consulta balanza del sistema EBIS.3. El sistema realiza internamente las operaciones para determinar el % disponible, la

variación, total acumulado.4. Elige el tipo de moneda (nacional o dólares) para visualizar el reporte.5. El sistema muestra en pantalla:

Para usuario:

Las cuentas para el centro de costo al que pertenece, el monto autorizado para cadacuenta, el ajuste al presupuesto, presupuesto actual y acumulado hasta la fecha,variación, el porcentaje disponible.

Para Administradores y gerente:

Elige los escenarios a comparar, para generar el reporte de variaciones, mostrando losajustes del presupuesto, cuentas, acumulado a la fecha, porcentaje disponible.

Un reporte de variaciones de los montos ejercidos a la fecha.

Flujo Alternativo:Ninguno.

Poscondiciones:El reporte de variaciones se mostrara en pantalla dependiendo de los permisos del

usuario, permitiendo, imprimir o guardar dicho reporte.

Tabla 3.1 Caso de Uso Consulta de Reporte de Variaciones

Nombre: Captura de Presupuesto




Descripción:Permite capturar el presupuesto inicial.

Actores:Usuario, Administradores

Precondiciones:Administradores y usuarios logueados.

Flujo Normal:

1. El usuario elige en el menú contextual2. El usuario elige el centro de costo para el cual va a capturar el presupuesto.3. El sistema muestra en lista las cuentas para dicho centro de costo. A lado de

cada cuenta una caja de chequeo, que será activada en caso de que elusuario haga uso de esa cuenta. Al pasar el curso sobre esa cuenta,mostrará un pequeño mensaje que describa la cuenta que quiere utilizar.

4. El usuario ingresa los datos para cada cuenta.5. Elige el botón guardar.

6. El sistema valida los datos para almacenarlos en la base de datos.

7. El administrador realiza el mismo procedimiento.

Flujo Alternativo:El usuario puede cancelar la operación por medio de un botón cancelar.

Poscondiciones:El presupuesto inicial o solicitado es guardado en la base de datos.

Tabla 3.2 Caso de Uso Captura de Presupuesto

Nombre: Agregar Cuenta

Descripción:Permite agregar una cuenta al catalogo de cuentas del sistema.




Actores:Administradores

Precondiciones:Administradores logueados.

Flujo Normal:1. El administrador elige agregar cuenta del menú contextual.2. El sistema muestra una pantalla de captura, solicitando los campos: numero

de cuenta, descripción de la cuenta y rubro al que pertenece dicha cuenta.3. Da clic en el botón agregar o guardar.4. El sistema valida los datos y almacena.

Flujo Alternativo:El administrador puede cancelar la operación por medio de un botón cancelar.

Poscondiciones:La cuenta se ha almacenado en el sistema y será mostrada en el catalogo de

cuentas.

Tabla 3.3 Caso de Uso Agregar cuenta

Nombre: Consulta Consolidado Maestro

Descripción:Permite generar un reporte del presupuesto solicitado/autorizado.

Actores:Administradores, Gerente




Precondiciones:El administrador y gerente deben haberse logueado.

Flujo Normal:

1. El usuario elige en el menú contextual Consolidado Maestro.

2. Consulta en la base de datos el presupuesto autorizado y solicitado por elusuario.

3. Genera el reporte.

Flujo Alternativo:El sistema no podrá generar reporte sino existe presupuesto inicial o solicitado.

Emitirá un mensaje dando a conocer que aun no hay presupuesto inicial.

Poscondiciones:El sistema muestra en pantalla un reporte del presupuesto solicitado/autorizado de

todos los centros de costo.

Tabla 3.4 Caso de Uso Consulta de Consolidado Maestro




Nombre: Consulta Catalogo de Cuentas

Descripción:Permite consultar las cuentas del catalogo de cuentas.

Actores:Usuario, Administradores, Gerente

Precondiciones:El administrador y gerente deben haberse logueado.

Flujo Normal:

1. El usuario elige del menú contextual la opción catalogo de cuentas.2. El usuario, administrador o gerente introduce el número de cuenta, en caso de ser

conocido, o introduce una parte de la descripción de la cuenta, o si esdesconocido consulta todas las cuentas.

3. El sistema muestra en pantalla los detalles de la cuenta.

Flujo Alternativo:El sistema verifica la existencia de la cuenta, sino muestra un mensaje de error

permitiéndole introducir de nuevo la cuenta en cualquiera de las opciones de búsqueda.

Poscondiciones:Se visualiza el catalogo de cuentas.

Tabla 3.5 Caso de Uso Consulta de Catálogo de Cuentas




Nombre: Modifica Presupuesto

Descripción:Permite a planeación financiera realizar ajustes a los presupuestos autorizados de

todos los centros de costos, en diferentes periodos para sus revisiones.

Actores:Administradores.

Precondiciones:El administrador debe haberse logueado.

Flujo Normal:1. El administrador elige de menú contextual Modificar presupuesto.2. El administrador introduce el centro de costo a modificar.3. El administrador elige el escenario (periodo para ajuste)4. El sistema muestra en pantalla el presupuesto autorizado de dicho centro de

costo.

5. Da clic en el botón ajustar o modificar.6. Ingresa el nuevo presupuesto.7. Da clic en botón guardar.8. El sistema valida los datos y los almacena.

Flujo Alternativo:El sistema comprueba la validez de los datos y de lo contrario mandara un mensaje

al administrador para que notifique su error.

Poscondiciones:Se guarda el ajuste en la bitácora de movimientos.

Tabla 3.6 Caso de Uso Modifica Presupuesto




Diagrama de Clases

Figura 3.19 Diagrama de Clases




3.1.5 Validación de Requisitos

Se llevo a cabo la primera revisión del Documento de Especificación de

Requerimientos, se realizo una reunión con el cliente y el Ingeniero de sistemas, para

verificar cada uno de los requerimientos, y así asegurar que se estaba definiendo el sistemaque el cliente esperaba.

En base a lo acordado, se efectuaron las modificaciones pertinentes a los requisitos,

para posteriormente ser entregado.




3.2 DISEÑO

3.2.1 Modelo Entidad-Relación

Se construyó el diagrama entidad-relación de acuerdo a los requerimientos del

cliente.

Figura 3.20 Modelo Entidad-Relación




3.2.2 Modelo Relacional

Administrador

id_admin

nombre

ap_paterno

ap_materno

username

password

CentroCosto

id_cc

area_funcional

rubro

usuario

Conti

eneno_cuenta

id_pres

Cuenta

no_cuenta

item

cuenta

rubro

Mod

ificaid_pres

id_admin

fecha_modifica

cargo

abono

mes

Presupuesto

id_pres

enero

febrero

marzo

abril

mayo

junio

julio

agosto

septiembre

octubre

noviembre

diciembre

justificacion

Sol

icita

id_pres

id_cc

usuario

fecha_solicitud

Tech

osCompraid_techo

carga_inicial

existencias

num_oc

monto_oc

no_cuenta

id_cc

Usuari

o

id_user

nombre

ap_paterno

ap_materno

username

password

departamento

email

jefe

Figura 3.21 Modelo Relacional

3.2.3 Diccionario de Datos




Elemento Dato PK FK Descripción Tipo Longitud Requerido

id_user * Identificación del usuario Int *

nombre Nombre del usuario varchar 20 *

ap_paterno Apellido Paterno varchar 25 *

ap_materno Apellido Materno varchar 25 *

usernameNombre de usuarioasignado

varchar 15 *

password Contraseña del usuario varchar 9 *

departamentoDepartamento al quepertenece

varchar 20 *

email Email varchar 20 *

jefe Jefe del usuario varchar 15 *

Tabla 3.7 Diccionario de Datos Tabla Usuario


id_cc * Número de centro de costo int *

area_funcional Área funcional varchar 30 *

rubro Rubro al que pertenece varchar 13 *

usuario * Identificación del usuario int *

Tabla 3.8 Diccionario de Datos Tabla Centro_Costo


no_cuenta * Número de cuenta int *

item Descripción de la cuenta varchar 45 *

cuenta Nombre de la cuenta varchar 45 *

rubro Rubro al que pertenece varchar 13 *

Tabla 3.9 Diccionario de Datos Tabla Cuentas





id_techo * Número de techo de compra int *

carga_inicialMonto inicial del techo decompras

decimal (18,2) *

existencias Existencias en almacén decimal (18,2) *

num_oc Número de orden de compra decimal (18,2) *

monto_oc Monto de orden de compra decimal (18,2) *


id_cc * Número de centro de costo int *

Tabla 3.10 Diccionario de Datos Tabla Techos_Compra


id_admin * Número de administrador int *

nombre Nombre del administrador varchar 20 *

ap_paterno Apellido paterno varchar 25 *

ap_materno Apellido materno varchar 25 *

username Nombre de usuario varchar 15 *

password Contraseña del usuario varchar 9 *

Tabla 3.11 Diccionario de Datos Tabla Administrador



Id_pres *Número de identificación depresupuesto

int *

Tabla 3.12 Diccionario de Datos Tabla Contiene





id_pres *Número de identificación depresupuesto

int *

eneroPresupuesto inicial para elmes de enero

decimal (18,2) *

febreroPresupuesto inicial para elmes de febrero

decimal (18,2) *

marzo Presupuesto inicial para elmes de marzo

decimal (18,2) *

abrilPresupuesto inicial para elmes de abril

decimal(18,2) *

mayoPresupuesto inicial para elmes de mayo

decimal(18,2) *

junioPresupuesto inicial para elmes de junio

decimal(18,2) *

julioPresupuesto inicial para elmes de julio

decimal(18,2) *

agostoPresupuesto inicial para elmes de agosto

decimal(18,2) *

septiembre Presupuesto inicial para elmes de septiembre decimal (18,2) *

octubrePresupuesto inicial para elmes de octubre

date *

noviembrePresupuesto inicial para elmes de noviembre

decimal(18,2) *

diciembrePresupuesto inicial para elmes de diciembre

decimal(18,2) *

justificacionJustificación de la solicitud delpresupuesto

varchar 550 *

Tabla 3.13 Diccionario de Datos Tabla Presupuesto


id_pres *Número deidentificación depresupuesto

Int *

id_cc *Número de centro decosto

Int *

usuario *Identificación delusuario

Int *

fecha_solicitaFecha en que sesolicita el presupuesto

smalldatetime 25 *

Tabla 3.14 Diccionario de Datos Tabla Solicita

3.2.4 Diseño de Pantallas

La figura 3.22 muestra la pantalla de inicio del Sistema de “Control Presupuestal”,

observando que exige el nombre de usuario y la contraseña del usuario, con estos datos se

determinan los permisos para el uso del sistema.




Figura 3.22 Pantalla de inicio de sesión

El inicio de sesión se encuentra validado para evitar infiltraciones que puedan

perjudicar los datos del sistema. Una vez iniciada la sesión con datos reconocidos por el

sistema, se mostrará la siguiente pantalla según el usuario logueado, en este caso el

Administrador.




Figura 3.23 Sesión de Administrador

Para los usuarios comunes la pantalla correspondiente a sus permisos se muestra en

la figura 3.24, el menú contiene pocas opciones, ya que no realizarán muchas operaciones

en el sistema (fig. 3.25)




Figura 3.24 Sesión de usuario común

Figura 3.25 Menú desplegable sesión Usuario

Las opciones de la sesión del Administrador se encuentran en un menú contextual

como se muestra en la figura 3.26, como Usuarios, Catálogos, Presupuesto, Techos de

Compra y Cerrar sesión.




Figura 3.26 Menú desplegable de sesión Administrador

Para la opción Usuarios del menú del Administrador encontramos la siguiente

pantalla (fig. 3.27). Se pueden realizar actividades como agregar, modificar y eliminar

usuarios.

Figura 3.27 Menú Usuarios de sesión Administrador

Figura 3.28 Opciones de Agregar usuario

La siguiente pantalla muestra el formulario para agregar un usuario de tipo

Administrador, donde se valida el número de administradores, en caso de sobrepasar el

número permitido que son 2, el sistema puede mandar un mensaje de información (figura

3.30) indicando que no puede ingresar otro usuario de este tipo. De igual forma podemos

agregar un usuario de centro de costo (figura 3.31).




Figura 3.29 Agregar usuario Administrador

Figura 3.30 Mensaje de información Agregar administrador

Figura 3.31 Registro de usuario de centro de costo




Otra de las opciones que se encuentran en el menú Usuarios es Eliminar un usuario

(figura 3.32), esta operación se realiza por medio de la búsqueda del nombre del usuario.

Figura 3.32 Eliminar usuario

En el menú de Catálogos (figura 3.33) encontramos las opciones Cuentas, Centros

de Costo, Mapeo de Cuentas, si damos clic en Centros de Costo, encontramos que podemos

buscar, agregar, modificar y eliminar centros de costo, como se muestra en la figura 3.34.

Figura 3.33 Menú Catálogos




Figura 3.34 Opciones para Centros de Costo

La búsqueda de Centros de Costo se puede realizar mediante varios criterios, por Rubro

(figura 3.35), Número de Centro de Costo, Nombre del Centro de o mostrar todos los Centros

de Costo existentes como se muestra en la figura 3.36.

Figura 3.35 Buscar centro de costo por rubro




Figura 3.36 Opciones de Búsqueda para Centros de Costo

En la opción agregar (fig. 3.37) permite al Administrador añadir los centros de costo al

sistema exigiendo datos como número del centro de costo, nombre y rubro al que pertenece

(Overhead o Cost of Sales).

Figura 3.37 Agregar Centro de Costo




Para la opción de Modificar encontramos la siguiente pantalla donde puede buscar

por Centro de Costo y realizar la modificación pertinente.

Figura 3.38 Modificar centro de costo

Para el caso de eliminar se realiza el mismo proceso, primero realiza una búsqueda

para mostrar los datos a eliminar como se muestra en la siguiente pantalla:

Figura 3.39 Eliminar centro de costo




Existirán mensajes de confirmación (figura 3.40) de cada una de las operaciones a

realizar, ya que se trata de un sistema que almacena datos importantes.

Figura 3.40 Mensaje de confirmación

Para el menú Catalogo, Cuentas, se derivan cuatro opciones, agregar (figura 3.41),

modificar, eliminar y consultar cuentas. Cada una de estas opciones se puede visualizar en

las siguientes pantallas.

Figura 3.41 Agregar cuenta




Figura 3.42 Modificar, Eliminar cuenta

De la misma forma se encuentran las consultas del catálogo de cuentas, ya sea por

Overhead, Costs of sales o visualizando todas las cuentas.

Figura 3.43 Consulta de Catálogo de Cuentas

La siguiente pantalla (figura 3.44) muestra Modificar presupuesto del menú

Presupuesto. Una vez seleccionado el rubro y el centro de costo se mostrará una tabla con




la solicitud de presupuesto de dicho centro de costo. Al dar doble clic sobre la fila deseada

abrirá una ventana que permitirá realizar la modificación del presupuesto (figura 3.45).

Figura 3.44 Modifica Presupuesto

Figura 3.45 Realizar movimiento

Para el submenú Consultar (figura 3.26) se tiene la opción Reporte de Variaciones

Personalizado (figura 3.46). El cuál permitirá hacer los mapeos por mes, año y periodo, por

rubro y centro de costo. Una parte de la información es extraída del Sistema EBIS.




Figura 3.46 Reporte de Variaciones

Un apartado importante dentro del sistema es la Bitácora de Movimientos (figura

3.47), donde se registran los cambios al presupuesto autorizado para cada uno de los

centros de costo.

Figura 3.47 Bitácora de Movimientos

Otro de los requisitos del cliente fue que pudiera consultar los techos de compra

(figura 3.48) contenidos en el sistema D7 (DataStream), donde contiene la carga inicial de

cada techo de compra, órdenes de compra y los montos de cada una de las órdenes, por

cada centro de costo.




Figura 3.48 Consulta Techos de Compra

En el caso de la sesión del usuario de centro de costo, se tiene primero la opción

presupuesto de la cual se despliega Solicitud de presupuesto (figura 3.24). Como se muestraen la siguiente pantalla.

Figura 3.49 Solicitud de Presupuesto

En la figura anterior el usuario elige el Centro de Costo para el que desea hacer la

solicitud y el mes a llenar. Existe el botón “Agregar”, el cuál abre una ventana independiente




que muestra el catálogo con las cuentas respectivas al centro de costo donde permitirá

marcar las cuentas que necesite el usuario para hacer la solicitud. Como se muestra en la

siguiente figura:

Figura 3.50 Agregar cuentas a solicitud de Presupuesto

Al dar clic en el botón agregar de la pantalla (figura 3.50), las cuentas se anexarán

automáticamente a la solicitud colocando una caja de texto para ingresar la cantidad asolicitar y un botón “Justificar”, para añadir la razón de la solicitud (figura 3.52).




Figura 3.51 Cuentas de Solicitud

Figura 3.52 Justificación de solicitud

Al finalizar la solicitud del presupuesto, muestra una vista preliminar de la solicitud(figura 3.53) donde aparecen las cuentas y meses solicitados.




Figura 3.53 Vista previa de solicitud

Otra opción del menú del Usuario de centro de costo es la Consulta del Catálogo de

Cuentas, donde se muestra una ventana con todas las cuentas pertenecientes a los centros

de costo que administra. Como se muestra a continuación.

Figura 3.54 Catálogo de cuentas de Usuario de CC

Para cerrar sesión se da clic en la opción Cerrar sesión del menú desplegable del

usuario de centro de costo. Le mostrará un mensaje confirmando su salida. De la misma

forma para el Administrador.




Figura 3.55 Confirmación Cerrar Sesión

CONCLUSIONES Y RECOMENDACIONES




“Analizar bien es una virtud. No programar hasta que tengas completamente desarrollado el

análisis es un grado superior de virtuosismo.” (Velneo, 2007)

En la actualidad, existen diversos organismos que ya están implementando sistemas

informáticos, esto para facilitar las actividades que se puedan manipular por medio de unaaplicación, por ello para construir un nuevo sistema se deben tomar en cuenta diversos

factores que menciona la Ingeniería del Software.

Durante el periodo de Residencia Profesional se llevo a cabo el Análisis, una de las etapas

de la Ingeniería del Software, culminando con la entrega del Documento de Especificación

de Requerimientos. Este documento fue de ayuda para el desarrollador del sistema, ya que

dentro de este se incluyeron las herramientas necesarias para tener un panorama de lo que

en verdad debe realizar el sistema, además de que contiene diagramas que permitieronobservar la secuencia de cada una de las tareas que se realizan en el departamento de

Planeación Financiera en cuanto al control del presupuesto.

En la etapa de Análisis se notaron aspectos que pudieran ayudar en el desarrollo del

“Sistema de Control de Presupuesto”, se hizo la recomendación al desarrollador de la

aplicación sobre la forma en que se presentaría el sistema a los usuarios. Además de

recalcar que los usuarios antes de interactuar con el sistema se les debe proporcionar

capacitación para conocer las funciones del sistema.

Además de que es un sistema importante para el departamento, porque se trata de un

departamento de ámbito financiero, para ello debe tener en cuenta el aspecto de seguridad

para evitar cualquier intrusión.

El aprendizaje obtenido fue todo el proceso de la etapa de Análisis ya que nunca se dejo de

analizar, estudiar, investigar, razonar y sobre todo comprender ya que se trata de un

departamento donde se llevan a cabo operaciones financieras.

Por lo que era difícil pasar por alto cada uno de los detalles que se presentan durante el

proceso del control del presupuesto.

El análisis es una etapa que no se debe tomar a la ligera, ya que es aquí donde empieza el

proceso de desarrollo de software, tomando en cuenta cada una de las características,




funciones y demás que debe contener el sistema a desarrollar, ya que de esta etapa

depende el éxito del sistema. Por ello se debe recurrir a la Ingeniería del Software para

utilizar cada una de las herramientas que aquí se proporciona de igual forma la Ingeniería de

Requerimientos que también es base para todo análisis, todo ello para no obtener resultados

no requeridos para el cliente.




REFERENCIAS

• Alarcón, R. (2000). UML. Diseño Orientado a Objetos con UML. Madrid. España:Grupo EIDOS.

• Pressman S., R. (2002). Ingeniería del Software. Un enfoque práctico. (Quintaed.). Madrid: McGraw-Hill.

• Sommerville, I. (2005). Ingeniería del Software (Séptima ed.). Madrid: PearsonAddison Wesley.

• (Fernández Vilas, Ana), “Diagramas UML” (Html), 2001,”http://tvdi.det.uvigo.es/~avilas/UML/node22.html, (26/11/2008).

• (Wikipedia, La enciclopedia libre), “Ingeniería de requerimientos” , (Html),

http://es.wikipedia.org/wiki/An%C3%A1lisis_de_requerimientos, (18/11/2008).

• (Wikipedia, La enciclopedia libre),”Lenguaje Unificado de Modelado” ,

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado, (20/11/2008).

• (Velneo 7), “La importancia de un buen análisis”, (Html),

http://jarboleya.com/2007/05/14/la-importancia-de-un-buen-analisis/,

(14/05/2007).




GLOSARIO

Account 6 dígitos numéricos que identifican la partida dentro del catálogo decuentas de EBIS.

Ajuste (Check Up)

Dentro de esta columna se registran los ajustes sugeridos por partede la Gerencia General, estos pueden ser aumentos odisminuciones. (está formulado para ser disminuciones)

Balanza EBIS Es un reporte que refleja los gastos de cada centro de costo.

Bud Vs ActualEs el porcentaje que representa el consumo de un periododeterminado con respecto al presupuesto autorizado en el mismo

periodo.

Budget (Bud.)

Formato de Presupuesto anual llenado por el usuario de cadacentro de costo. Información enviada por el corporativo, reflejamovimientos que provienen de los distintos sistemas, convertida enmoneda nacional. Presupuesto autorizado.

Catalogo de cuentasEs la consolidación de todas las cuentas utilizadas por los centrosde costo.

Denominación del centro decosto.

Nombre con el que se identifica al centro de costo.

Description Account Nombre con el que se identifica la partida.

Description Item Nombre del rubro al que pertenece la partida, bajo el esquema demapeo del formato R01.

DominioEs la red de la empresa. Se tiene acceso a recursos de la empresay servidores (intranet).

Existencias almacén Valor de la existencia de almacén (en unidades de monetarias).

Número de centro de costo 4 dígitos numéricos que identifican al c.c. dentro del sistema.




OC pendientes Numero de Órdenes de Compra (OC).

OC pendientes Monto Monto pendiente de la O.C antes de IVA.

Presupuesto acumulado(Acum.)

Es el consumo de presupuesto, contabilizado desde el primer meshasta el periodo actual.

Resumen ejecutivo mensual

Son una serie de reportes que muestran el concentrado devariaciones, comportamiento del presupuesto y observaciones delos centros de costo.

Techo de compra

Carga inicial para compras que define Planeación Financiera al

inicio del ejercicio.

Techos de compra remanenteResultado de Techo de compra - Presupuesto acum. - OCpendientes - Existencia.

Var (variación)

Es la diferencia que existe entre la columna del Bud – Check Up –Actual y está expresada en pesos. Se considera como elpresupuesto disponible.

52247996-memoria-amalia

Documents