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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 2/144
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 3/144
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 4/144
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.
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 5/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 6/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 7/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 8/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 9/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 10/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 11/144
122
CONCLUSIONES Y RECOMENDACIONES..........................................................122
REFERENCIAS.......................................................................................................125
GLOSARIO..............................................................................................................126
xi
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 12/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 13/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 14/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 15/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 16/144
Figura 3.55 Confirmación Cerrar Sesión...............................................................122
xvi
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 17/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 18/144
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 19/144
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.
Memoria de Residencia Profesional 2
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 20/144
CAPITULO I
ESPECIFICACIONES GENERALES DELPROYECTO
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 21/144
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.
Memoria de Residencia Profesional 4
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 22/144
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.
Memoria de Residencia Profesional 5
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 23/144
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.
Memoria de Residencia Profesional 6
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 24/144
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
Memoria de Residencia Profesional 7
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 25/144
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
Memoria de Residencia Profesional 8
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 26/144
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
Memoria de Residencia Profesional 9
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 27/144
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.
Memoria de Residencia Profesional 10
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 28/144
• 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
Memoria de Residencia Profesional 11
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 29/144
• 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
Memoria de Residencia Profesional 12
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
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 30/144
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.
Memoria de Residencia Profesional 13
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 31/144
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.
Memoria de Residencia Profesional 14
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 32/144
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.
Memoria de Residencia Profesional 15
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 33/144
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.
Memoria de Residencia Profesional 16
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 34/144
CAPITULO II
FUNDAMENTO TEÓRICO
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 35/144
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
Memoria de Residencia Profesional 18
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 36/144
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
Memoria de Residencia Profesional 19
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 37/144
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
Memoria de Residencia Profesional 20
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 38/144
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.
Memoria de Residencia Profesional 21
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 39/144
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.
Memoria de Residencia Profesional 22
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 40/144
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).
Memoria de Residencia Profesional 23
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 41/144
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.
Memoria de Residencia Profesional 24
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 42/144
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.
Memoria de Residencia Profesional 25
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 43/144
• 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
Memoria de Residencia Profesional 26
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 44/144
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:
Memoria de Residencia Profesional 27
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 45/144
• 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.
Memoria de Residencia Profesional 28
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 46/144
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.
Memoria de Residencia Profesional 29
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 47/144
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
Memoria de Residencia Profesional 30
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 48/144
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,
Memoria de Residencia Profesional 31
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 49/144
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.
Memoria de Residencia Profesional 32
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 50/144
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.
Memoria de Residencia Profesional 33
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 51/144
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”.
Memoria de Residencia Profesional 34
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 52/144
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.
Memoria de Residencia Profesional 35
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 53/144
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.
Memoria de Residencia Profesional 36
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 54/144
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
Memoria de Residencia Profesional 37
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 55/144
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.
Memoria de Residencia Profesional 38
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 56/144
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.
Memoria de Residencia Profesional 39
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 57/144
• 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
Memoria de Residencia Profesional 40
IOrtografia
Figura 2.3 Interfaz.
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 58/144
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()
Memoria de Residencia Profesional 41
Cadena deresponsabili
dad
Realizar
pedido
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 59/144
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.
Memoria de Residencia Profesional 42
orderform.java
Servidor
Figura 2.7 Componente.
Figura 2.8 Nodo Servidor.
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 60/144
• 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.
Memoria de Residencia Profesional 43
dibujar
Esperando
Figura 2.9 Interacción.
Figura 2.10 Máquina de estados.
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 61/144
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
Memoria de Residencia Profesional 44
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.
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 62/144
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.
Memoria de Residencia Profesional 45
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 63/144
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:
Memoria de Residencia Profesional 46
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 64/144
• 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.
Memoria de Residencia Profesional 47
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 65/144
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.
Memoria de Residencia Profesional 48
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 66/144
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.
Memoria de Residencia Profesional 49
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 67/144
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.
Memoria de Residencia Profesional 50
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 68/144
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
Memoria de Residencia Profesional 51
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 69/144
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
Memoria de Residencia Profesional 52
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 70/144
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
Memoria de Residencia Profesional 53
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 71/144
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
Memoria de Residencia Profesional 54
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 72/144
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)
Memoria de Residencia Profesional 55
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 73/144
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
Memoria de Residencia Profesional 56
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 74/144
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.
Memoria de Residencia Profesional 57
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 75/144
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.
Memoria de Residencia Profesional 58
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 76/144
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.
Memoria de Residencia Profesional 59
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 77/144
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.
Memoria de Residencia Profesional 60
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 78/144
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.
Memoria de Residencia Profesional 61
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 79/144
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).
Memoria de Residencia Profesional 62
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 80/144
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)
Memoria de Residencia Profesional 63
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 81/144
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:
Memoria de Residencia Profesional 64
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 82/144
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
Memoria de Residencia Profesional 65
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 83/144
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.
Memoria de Residencia Profesional 66
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 84/144
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
Memoria de Residencia Profesional 67
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 85/144
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
Memoria de Residencia Profesional 68
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 86/144
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.
Memoria de Residencia Profesional 69
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 87/144
CAPITULO III
ANÁLISIS Y DISEÑO DEL SISTEMADE CONTROL PRESUPUESTAL
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 88/144
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.
Memoria de Residencia Profesional 71
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 89/144
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
Memoria de Residencia Profesional 72
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 90/144
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
Memoria de Residencia Profesional 73
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 91/144
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.
Memoria de Residencia Profesional 74
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 92/144
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.
Memoria de Residencia Profesional 75
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 93/144
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.
Memoria de Residencia Profesional 76
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 94/144
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.
Memoria de Residencia Profesional 77
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 95/144
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.
Memoria de Residencia Profesional 78
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 96/144
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
Memoria de Residencia Profesional 79
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 97/144
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.
Memoria de Residencia Profesional 80
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 98/144
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.
Memoria de Residencia Profesional 81
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 99/144
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.
Memoria de Residencia Profesional 82
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 100/144
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
Memoria de Residencia Profesional 83
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 101/144
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.
Memoria de Residencia Profesional 84
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 102/144
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.
Memoria de Residencia Profesional 85
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 103/144
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
Memoria de Residencia Profesional 86
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 104/144
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.
Memoria de Residencia Profesional 87
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 105/144
Figura 3.15 Diagrama de secuencia Modifica Presupuesto
Memoria de Residencia Profesional 88
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 106/144
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
Memoria de Residencia Profesional 89
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 107/144
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.
Memoria de Residencia Profesional 90
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 108/144
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
Memoria de Residencia Profesional 91
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 109/144
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
Memoria de Residencia Profesional 92
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 110/144
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.
Memoria de Residencia Profesional 93
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 111/144
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
Memoria de Residencia Profesional 94
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 112/144
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
Memoria de Residencia Profesional 95
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 113/144
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
Memoria de Residencia Profesional 96
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 114/144
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
Memoria de Residencia Profesional 97
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 115/144
Diagrama de Clases
Figura 3.19 Diagrama de Clases
Memoria de Residencia Profesional 98
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 116/144
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.
Memoria de Residencia Profesional 99
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 117/144
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
Memoria de Residencia Profesional 100
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 118/144
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
jefe
Figura 3.21 Modelo Relacional
3.2.3 Diccionario de Datos
Memoria de Residencia Profesional 101
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 119/144
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
Elemento Dato PK FK Descripción Tipo Longitud Requerido
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
Elemento Dato PK FK Descripción Tipo Longitud Requerido
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
Memoria de Residencia Profesional 102
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 120/144
Elemento Dato PK FK Descripción Tipo Longitud Requerido
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) *
no_cuenta * Número de cuenta int *
id_cc * Número de centro de costo int *
Tabla 3.10 Diccionario de Datos Tabla Techos_Compra
Elemento Dato PK FK Descripción Tipo Longitud Requerido
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
Elemento Dato PK FK Descripción Tipo Longitud Requerido
no_cuenta * Número de cuenta int *
Id_pres *Número de identificación depresupuesto
int *
Tabla 3.12 Diccionario de Datos Tabla Contiene
Elemento Dato PK FK Descripción Tipo Longitud Requerido
Memoria de Residencia Profesional 103
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 121/144
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
Elemento Dato PK FK Descripción Tipo Longitud Requerido
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.
Memoria de Residencia Profesional 104
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 122/144
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.
Memoria de Residencia Profesional 105
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 123/144
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)
Memoria de Residencia Profesional 106
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 124/144
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.
Memoria de Residencia Profesional 107
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 125/144
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).
Memoria de Residencia Profesional 108
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 126/144
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
Memoria de Residencia Profesional 109
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 127/144
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
Memoria de Residencia Profesional 110
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 128/144
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
Memoria de Residencia Profesional 111
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 129/144
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
Memoria de Residencia Profesional 112
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 130/144
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
Memoria de Residencia Profesional 113
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 131/144
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
Memoria de Residencia Profesional 114
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 132/144
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
Memoria de Residencia Profesional 115
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 133/144
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.
Memoria de Residencia Profesional 116
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 134/144
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.
Memoria de Residencia Profesional 117
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 135/144
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
Memoria de Residencia Profesional 118
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 136/144
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).
Memoria de Residencia Profesional 119
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 137/144
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.
Memoria de Residencia Profesional 120
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 138/144
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.
Memoria de Residencia Profesional 121
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 139/144
Figura 3.55 Confirmación Cerrar Sesión
CONCLUSIONES Y RECOMENDACIONES
Memoria de Residencia Profesional 122
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 140/144
“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,
Memoria de Residencia Profesional 123
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 141/144
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.
Memoria de Residencia Profesional 124
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 142/144
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).
Memoria de Residencia Profesional 125
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 143/144
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.
Memoria de Residencia Profesional 126
5/11/2018 52247996-Memoria-Amalia - slidepdf.com
http://slidepdf.com/reader/full/52247996-memoria-amalia 144/144
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.
Top Related