Capítulo # 2 – Modelo del negocio y modelo del sistema.

2.1 – Introducción.

El modelo del negocio es una técnica que permite comprender los procesos del negocio de la organización, además presenta una descripción detallada de las reglas del negocio que el objeto de automatización debe seguir para asegurar el cumplimiento de las restricciones que existen en el mismo. En el presente capítulo se realiza una descripción del modelo del negocio así como de los procesos, actores, trabajadores, casos de uso y diagramas de clases del modelo de objetos. Se detalla el modelo del sistema a partir de los requerimientos funcionales y no funcionales, la modelación de los casos de uso y actores del mismo, a su vez se lleva a cabo una descripción del diseño a través del diagrama de clases y el modelo lógico y físico de datos. Se definen, el modelo de implementación y los principios de diseño seguidos en la aplicación.

2.2 –  Descripción del modelo del negocio.

 

El modelo del negocio forma parte del flujo de trabajo clave para lograr un desarrollo exitoso del servicio, ya que el mismo describe el curso de los procesos que serán objeto de automatización, y establece una buena comunicación entre los desarrolladores, los clientes y el usuario final.
 Dentro de los pasos del modelo del negocio se encuentran: capturar y definir los procesos de negocio de la organización, realizar el modelo de casos de uso del negocio que identifique los actores y casos de uso asociados y el modelo de objetos del negocio compuesto por trabajadores y entidades de este, todos ellos, bajo el estudio, tarea crucial que define los límites del proceso de modelado posterior.
El proceso de negocio es un grupo de tareas relacionadas de manera lógica que se llevan a cabo en determinada secuencia, y producen o manipulan una colección de datos empleando recursos de la organización para dar resultados que apoyan sus objetivos.
Actualmente en el CENEX las solicitudes de los clientes se hacen de forma manual, el cliente llega a la entidad o se comunica telefónicamente y ahí lo atiende cualquiera del personal de la entidad, se realiza la solicitud del servicio que el cliente desee contratar, después se hace una valoración si es factible o no realizar el trabajo solicitado y si existen los productos disponibles en el almacén. Esto es un trabajo un poco complejo y molesto por lo que constituye una forma de perdida de tiempo a los usuarios de dicha entidad y por parte de los clientes, ya que tienen que esperar a que se apruebe la solicitud y después esperar a que le manden la oferta de acuerdo a su solicitud, para mas tarde si está de acuerdo redactar el contrato y que el mismo lo firme para por último se realice el trabajo solicitado.

1. Solicitar Servicio.
2. Confeccionar Oferta.
3. Confeccionar Contrato.

 

El cliente se presenta ante cualquier usuario de la entidad  de la División de Servicios para solicitar un servicio. Después el Jefe de la División Servicios en conjunto con lo jefes de equipos implicados en el servicio solicitado valoran las posibilidades de realizar el trabajo teniendo en cuenta el personal calificado disponible, equipos a utilizar y los materiales necesarios.
Después de la revisión si no se va a prestar el servicio se le informa al cliente, de lo contrario, si se valora que es posible realizar el servicio se procede al análisis de la magnitud y el tiempo de respuesta al cliente y a su vez comprobar si los datos dados por el mismo son suficientes, de ser así, se procede a realizar la oferta.
La oferta se realizará por el Jefe de la División de Servicios y esto sólo será necesario si es un nuevo cliente, un nuevo servicio o si las especificaciones del servicio han cambiado. Más tarde, se lleva esta oferta a revisión de los aspectos técnicos, económicos y de aseguramiento.
Si se detecta alguna observación o no correspondencia será analizada en el área de División de Servicios que es la responsable de la elaboración de la oferta y así tratar de darle solución a la observación. 
Revisada ya la oferta se le entrega al cliente de forma personal, por correo electrónico o por fax, depende de las facilidades de la empresa, pero en todos los casos el emisor se cerciorará que el cliente la reciba. La misma está archivada de forma digital en el Área de Servicios.
Si el cliente rechaza la oferta se analizarán las causas y se toman decisiones, de no ser así se procede a la elaboración del contrato. 
El contrato se elaborará por el área de la División de Servicios bajo la supervisión  del jefe del mismo. Durante la elaboración se deberá tener en cuenta que cada concentración tiene sus particularidades y características. Pero a su vez las cláusulas deben satisfacer los requerimientos de las partes.
Después de haberlo elaborado se vuelve a revisar en correspondencia con la oferta, aspectos jurídicos y económicos y modificaciones en caso de que existan.
 Si la revisión es satisfactoria y no existe indefinición se llamará al cliente para su revisión y firma, los contratos deben ser revisados y firmados en el año propuesto.

De existir discrepancias se acordará con el cliente una reunión donde participen ambas partes con los documentos que aclaren las mismas a fin de encontrar una solución y se decidirá firmar o no el contrato.

Ya firmado el contrato se entregara una copia al Jefe de Equipo o al Jefe del Servicio implicado.

Durante la prestación de los servicios el nombrado para jefe de servicio debe controlar que se cumpla lo establecido en el contrato durante la ejecución, bajo la supervisión del Jefe de la División de Servicios.

De existir modificaciones al contrato se deberán comunicar 7 días antes de la ejecución y deberá ser aprobada por escrito mediante suplementos al contrato base. Estos serán firmados por el Director General de la Empresa o el personal aprobado por resolución.

Al concluir el servicio se le presentará al cliente las facturas y certificaciones con los cálculos del monto total de la misma sobre la base de los precios pactados en el contrato, se procederá al cobro de los mismo que podrán ser mediante cheques, trasferencias bancarias o letras de cambio.
Las facturas se realizarán una vez concluido el servicio con un tiempo menor a un mes, si el plazo de ejecución es mayor a lo establecido, se realizará mediante cortes mensuales. Estos se realizarán de forma conjunta entre la División de Servicios y el Jefe de Equipo o servicio.
Cuando la factura se realiza por el área de la División de Servicios el Jefe de servicios o de equipo deberá informar a esta los valores físicos de producción ejecutados.
Siempre que sea posible el responsable de servicio realizará el trámite en el departamento económico del cliente, ya sea el cheque o la transferencia bancaria que ampare la factura.

2.3 – Reglas del Negocio.

Después de identificar el proceso de negocio se definen las siguientes reglas del negocio:

• Cualquier usuario de la entidad puede confeccionar la solicitud del cliente.
• Cada Solicitud debe tener un código que se conforma por un consecutivo más el año en curso, siempre reiniciándose con el inicio de un nuevo año.
• Cada registro de revisión de solicitud, oferta y contrato (es una sola planilla) debe tener un número y a su vez el código del contrato al que pertenezca.
• El cliente deberá revisar la oferta realizada por parte de la empresa, si no es de su conveniencia se lo comunica al Jefe de la División de Servicios, se analizarán las causas y se toman decisiones.
• Cuando el Jefe de la División de Servicios realiza cualquier contrato debe confeccionar un documento que es entregado al cliente, quien a su vez lo firma.
• El Jefe de la División de Servicios deberá informar al cliente si se realizará algún cambio en el servicio solicitado.
• Para que el contrato entre en vigor el cliente deberá estar de acuerdo con él y haberlo firmado.
• Para todo contrato de servicio el cliente debe pagar un abonado al terminar el tiempo del contrato.
• El Jefe de la División de Servicios es el encargado de entregar mensualmente a la empresa la información de la prestación de los servicios solicitados.
• El Jefe de la División de Servicios es el encargado de entregar mensualmente a la empresa la información de la prestación de los servicios realizados.

2.4 – Modelo de casos de uso del negocio.

El modelo de Casos de Uso del Negocio (CUN) describe los procesos de una empresa en términos de casos de uso y actores del negocio en correspondencia con los procesos del negocio y los clientes, respectivamente. El modelo de casos de uso presenta un sistema desde la perspectiva de su uso y esquematiza cómo proporciona valor a sus usuarios. Este modelo permite a los modeladores comprender mejor qué valor proporciona el negocio a sus actores [20].
Este modelo se define con tres elementos: el diagrama de casos de uso del negocio, la descripción de los casos de uso del negocio y el diagrama de actividades.

 

2.4.1 – Actores del negocio.

Un actor del negocio es cualquier individuo, grupo, entidad, organización, máquina o sistema de información externos; con los que el negocio interactúa. Lo que se modela como actor es el rol que se juega cuando se interactúa con el negocio para beneficiarse de sus resultados [20].

Tabla 1. Actores del negocio.

 

2.4.2 – Diagrama de caso de uso del negocio.

El diagrama de casos de uso del negocio se construye para lograr una visión general de los procesos de negocio de la organización o entidad; en éste se representa cada proceso como un caso de uso, el se relaciona con los actores del negocio. [20].

 

Diagrama de Casos de Uso

 .

Figura 2. Diagrama de casos de uso del negocio.

2.4.3 – Trabajadores del negocio.

Un trabajador del negocio es una abstracción de una persona (o grupo de personas), una máquina o un sistema automatizado que actúa en el negocio realizando una o varias actividades, interactuando con otros trabajadores del negocio y manipulando entidades del negocio. Representa un rol. [20].

Tabla 2. Trabajadores del negocio.

2.4.4 – Descripción de los Casos de Uso del negocio. 

 Tabla 3. Descripción de los casos de uso del negocio.

2.5 – Diagramas de actividades.

Ver Anexos A.

 

2.6 – Modelo de objetos del negocio.

El modelo de objetos del negocio es un modelo interno a un negocio. Describe cómo cada caso de uso del negocio, es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades del negocio y unidades de trabajo. [20].
A continuación se muestra el modelo de objetos del negocio del caso de uso “Solicitar Servicio”, “Confeccionar Oferta” y “Confeccionar Contrato”.

Figura 3. Modelo del Objeto del Negocio.

2.7 – Descripción del sistema propuesto.

A partir del análisis realizado a la situación problémica existente en el CENEX de Cienfuegos, esta investigación pretende la obtención de un producto de software propio que informatice la gestión de los procesos relacionados con  la Prestación de los Servicios de la misma y que responda a los objetivos a alcanzar.
Con la implementación del sistema se pretende reducir gasto de tiempo innecesario y de material de oficina, lograr una mayor eficiencia y eficacia en el intercambio de información. El intercambio de conocimiento a través de esta aplicación podrá ser mejor y con una mayor capacidad de portabilidad, ya que se le brindará la posibilidad al usuario de obtener una información más organizada y actualizada. Se ganará rapidez en el flujo de información y disponibilidad de la misma a todos los usuarios.
Desde que se encuentre en explotación el software, el jefe del área de la División  de Servicios del CENEX podrá acceder a la información desde cualquier computadora conectada a la red CENEX, ya que estará disponible en el servidor. Los usuarios tendrán acceso a la información general y a la que su jerarquía o rol le permita.

2.8 – Requerimientos Funcionales.

Requerimientos Funcionales.
Los requerimientos funcionales son declaraciones de los servicios o funciones que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer. [21].
Los requerimientos funcionales del software propuesto son los siguientes:

• Autenticarse.
• Cambiar Contraseña.
• Cerrar Sesión.
• Insertar usuario.
• Modificar usuario.
• Agregar solicitud.
• Modificar solicitud.
• Listar solicitud.
• Visualizar solicitud.
• Imprimir Solicitud.
• Crear Oferta.
• Modificar Oferta.
• Listar Oferta.
• Visualizar Oferta.
• Imprimir Oferta.
• Crear Contrato
• Modificar Contrato
• Listar Contrato.
• Crear una Ficha de Costo.
• Modificar Ficha de Costo.
• Listar Ficha de Costo.
• Crear una nueva Entidad.
• Modificar  Entidad.
• Listar las Entidades.
• Crear un nuevo Servicio.
• Modificar Servicio.
• Listar Servicios.
• Crear un nuevo Equipo de Trabajo.
• Modificar Equipo de Trabajo.
• Listar Equipo de Trabajo.
• Insertar Servicio para un Equipo de Trabajo.
• Crear reporte de producciones ejecutadas.
• Modificar reporte de producciones ejecutadas
• Listar reporte de producciones ejecutadas
• Visualizar reporte de producciones ejecutadas.
• Imprimir producciones ejecutadas.
• Insertar Actividad de una producción ejecutada.
• Listar Actividad de una producción ejecutada.
• Modificar Actividad de una producción ejecutada.
• Insertar Dieta de una producción ejecutada.
• Listar Dieta de una producción ejecutada.
• Modificar Dieta de una producción ejecutada.
• Insertar producción ejecutada para un equipo de trabajo.
• Mostrar un registro general de las solicitudes.
• Imprimir registro general de las solicitudes.
• Mostrar un registro general de las ofertas.
• Imprimir registro general de las ofertas.
• Mostrar un registro general de los contratos.
• Imprimir registro general de los contratos.
• Consultar ayuda.

2.9 – Requerimientos no funcionales.

Los requerimientos no funcionales describen las restricciones del sistema; no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida, en cuanto a prestaciones, atributos de calidad y la representación de datos que se utiliza en la interfaz del sistema. [21].

Requerimientos de apariencia o interfaz externa.

El sistema debe tener una interfaz sencilla, muy legible y simple de usar, el trabajo  debe ser autoritario e interactivo para que los usuarios se sientan confiados .El usuario debe conocer como interactuar con el producto.

Requerimientos de Usabilidad.

El sistema será utilizado solo por personas que sean usuarios del mismo y que previamente se le haya asignado una cuenta dentro de él, por parte del administrador, para posibilitar la navegación. Esta cuenta pertenece a un tipo de usuario y acorde con ello serán otorgados los privilegios de navegación.

 

 

Requerimientos de Rendimiento.

Para un funcionamiento óptimo de la aplicación se seguirán las diferentes técnicas de elaboración en la Web, que faciliten el rápido acceso a sus páginas. La eficiencia del producto estará determinada en gran medida por el aprovechamiento de los recursos que se disponen en el modelo Cliente/Servidor, y la velocidad de las consultas en la Base de Datos. La herramienta propuesta debe ser rápida y el tiempo de respuesta debe ser el mínimo posible, adecuado a la rapidez con que el cliente requiere la respuesta a su acción.
Requerimientos de Soporte.

Para garantizar el soporte a los clientes de esta herramienta, se documentará la aplicación con un manual de ayuda para los usuarios y los administradores, así como la posibilidad de emitir sus quejas y sugerencias a los desarrolladores de la herramienta mediante correo. El administrador tendrá la responsabilidad de mantener actualizada la aplicación. El sistema debe propiciar su mejoramiento y la anexión de otras opciones que se le incorporen en un futuro.
Requerimientos de Portabilidad.

La plataforma seleccionada para desarrollar la aplicación fue Windows, pero puede ser ejecutada desde cualquier plataforma. Las terminales de la empresa sólo requerirán estar conectadas a la red.
Requerimientos de Seguridad.

El sistema debe garantizar la seguridad de los datos almacenados y que viajan a través de la red. Para ello se encriptarán las contraseñas con MD5 y se protegerá contra accesos no autorizados utilizando mecanismos de autenticación y autorización de los usuarios, a través de contraseñas y niveles de acceso. Se configurará el servidor con protocolo SSL para garantizar la seguridad de los datos que viajan por la red y se harán validaciones de la información tanto en el cliente como en el servidor.
Estas medidas no afectarán el rendimiento de la aplicación.

Requerimientos de Ayudas y Documentación en línea.
El sistema contará con una ayuda general y específica. En ella se describirán las funcionalidades de la aplicación, con el fin de garantizar el buen desempeño de los usuarios a la hora de interactuar con el mismo.

Requerimientos de Software.

En la computadora que haga función de servidor, independientemente del sistema operativo, se necesita el lenguaje de programación PHP y el SGBD, MySQL. En las computadoras de los usuarios se requiere del navegador Internet Explorer o Mozilla.

Requerimientos de Hardware.

Se requiere de un servidor de 128 MB de RAM como mínimo y 6 GB de capacidad del disco duro. Todas las computadoras implicadas, tanto para la administración como las de los usuarios, deben estar conectadas a una red y tener al menos 64Kbps.

2.10 – Modelo de casos de uso del sistema.

El modelo de Casos de Uso es la técnica más efectiva y a la vez la más simple que emplean los desarrolladores de software para modelar los requisitos del sistema desde la perspectiva del usuario. El mismo consiste en actores y casos de uso. Los actores representan usuarios y otros sistemas que interaccionan con el sistema y los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estímulo desde un actor. [22]

2.10.1 – Actores del sistema a automatizar.

Un actor es aquel que interactúa con el sistema, sin ser parte de él y puede asumir el rol que juega una o varias personas, un equipo o un sistema automatizado. [21].
Jerarquía de Actores.
Mostrar la jerarquía entre los actores del sistema a través de un diagrama, permite reflejar gráficamente la relación existente entre ellos.

Figura 4. Diagrama de Jerarquía entre Actores.

 

Descripción de los Actores de Sistema.
Tabla 4. Actores del sistema.

 

2.10.2 – Paquetes y sus relaciones.

Con la finalidad de lograr una mejor comprensión, se decide subdividir el diagrama de casos de uso definiendo paquetes. Se muestra un diagrama por cada paquete. Los paquetes de casos de uso son la forma de agrupar a estos últimos respondiendo a algún criterio. En el caso de esta investigación se deciden subdividir los paquetes por funcionalidad.

Figura 5. Paquetes y sus relaciones.

       

2.10.3 – Casos de uso del sistema.

Cada forma en que los actores usan el sistema se representa con un caso de uso. Los casos de uso son “fragmentos” de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. [23].
Los casos de uso que se definen para el sistema propuesto son:

• Autenticarse.
• Cambiar contraseña
• Cerrar sesión.
• Imprimir documento.
• Gestionar usuario.
• Gestionar solicitud.
• Listar solicitud.
• Visualizar solicitud.
• Gestionar Oferta.
• Listar ofertas.
• Visualizar oferta.
• Gestionar contrato.
•  Listar contratos.
• Gestionar Ficha de Costo
• Listar Ficha de Costo.
• Gestionar Entidad.
• Listar Entidades.
• Gestionar Servicio.
• Listar Servicios.
• Gestionar Equipo de Trabajo.
• Listar Equipos de Trabajo.
• Insertar Servicio para un Equipo de Trabajo.
• Gestionar producciones ejecutadas.
• Listar producciones ejecutadas.
• Visualizar producciones ejecutadas.
• Gestionar Actividad.
• Listar Actividad.
• Gestionar Dieta.
• Listar Dieta.
• Insertar Producción Ejecutada para un Equipo de Trabajo.
• Visualizar registro general de las solicitudes.
• Visualizar registro general de las ofertas.
• Visualizar registro general de contratos.
• Consultar ayuda

2.10.4 – Diagrama de casos de uso por paquetes.

Ver Anexos B.

2.11 – Descripción de los casos de uso.

Ver Anexos D.

2.12 – Diagrama de clases del diseño.

El diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. En el caso de las aplicaciones Web, el diagrama de clases representa las colaboraciones que ocurren entre las páginas, donde cada página lógica puede ser representada como una clase. Al tratar de utilizar el diagrama de clases tradicional para modelar aplicaciones Web surgen varios problemas, por lo cual los especialistas del Rational plantearon la creación de una extensión al modelo de análisis y diseño que permitiera representar el nivel de abstracción adecuado y la relación con los restantes artefactos de UML. [24]

Los Diagramas de clases Web de la solución propuesta fueron definidos a partir de los Casos de Uso del Sistema y se muestran en la siguiente tabla:

Tabla 5. Distribución de los diagramas Web por caso de uso del sistema

 

2.13 – Diseño de la base de datos.

    2.13.1- Modelo lógico de datos.

El diagrama del modelo lógico de datos o diagrama de clases persistentes, muestra las clases capaces de mantener su valor en el espacio y en el tiempo [24].
Ver Anexo E.1.

    2.13.2 – Modelo físico de datos.

Cuando se define correctamente el modelo lógico, se hace mucho menos engorroso llegar al modelo de datos o modelo físico como también se le denomina en la metodología RUP, el modelo de datos representa la estructura o descripción física de las tablas de la base de datos y es obtenido a partir del diagrama de clases persistentes. [24]
Ver Anexo E.2.

2.14 – Diagrama de implementación.

El modelo de implementación denota la implementación del sistema en términos de componentes y subsistemas de implementación. Describe cómo se organizan los componentes de acuerdo con los mecanismos de estructuración, y modulación disponibles en el entorno de la implementación y en el lenguaje o lenguajes de programación utilizados, y como dependen los componentes unos de otros [24].
Ver Anexo E.3.

2.15 – Principios de diseño.

La interfaz gráfica es la portada del sistema al cliente y ha de tener gran consistencia, es decir mantener su coherencia de principio a fin. Por ello se han de mantener las reglas, los criterios en la operatividad, la imagen parcial o total, etc.; pues una incoherencia de diseño puede aportar pérdidas de eficacia del propio contenido que se quiera transmitir.

La interfaz diseñada presente en la solución propuesta tiene las siguientes características:

• Los colores que se utilicen deben ser claros y agradables al usuario para lograr su comodidad y satisfacción mientras interactúa con el sistema.
• Información legible.
• No presenta una alta carga visual.
• Facilidad de aprendizaje, navegabilidad y uso.
• Representación permanente de un contexto de acción, es decir, la estructura y el acceso a los servicios es mantenida para todas las páginas del sistema.
• La entrada de información por parte de los usuarios se realiza a través de los componentes del formulario.
• El objeto de interés siempre es fácil de identificar.
• Las operaciones que se realizan al acceder a la información almacenada en la base de datos y ficheros son rápidas e incrementales con efectos inmediatos.
• La navegabilidad por las páginas debe ser consistente y evitando la ruptura de hipervínculos.
• Uso adecuado de iconos e imágenes relativamente pequeñas facilitará la comprensión de las funcionalidades del sistema.

 

2.15.1 – Tratamiento de errores.

Las situaciones que pueden provocar fallos en la ejecución normal de un programa se denominan excepciones. El sistema propuesto presenta una interfaz diseñada, implementada y dirigida a evitar tales situaciones y errores. El sistema tiene la tarea de detectar problemas en el proceso de autentificación por parte de algún usuario, ser capaz de mantener un nivel de validación que restrinja la introducción de información errónea al mismo y aclare al usuario el tipo de información que debe manipular; controla además, con el uso de las variables de sesión que brinda el lenguaje PHP, el acceso a páginas restringidas. Todo ello a través, de una serie de mensajes de error con textos sencillos de fácil comprensión para los usuarios.

 

2.15.2 – Concepción general de la ayuda.

La ayuda contendrá la explicación funcional y de navegación del sistema, permitiendo que el usuario, además de adquirir conocimientos funcionales de la aplicación, también pueda entender cómo desenvolverse dentro de la misma.

2.16 – Conclusiones del capítulo.

Al concluir el presente capítulo se arriban a las siguientes conclusiones:

• Fue descrito el proceso que tiene lugar en la CENEX perteneciente al MICONS de la provincia de Cienfuegos, identificando a su vez los roles y objetos del negocio, así como su relación en esos procesos.
• Esta descripción fue realizada mediante el modelo del negocio, para lo cual se elaboraron el modelo de casos de uso, el de objeto así como el diagrama de actividades.
• A partir de este análisis fueron definidos los requisitos que conducen a futuras funcionalidades, obteniéndose el modelo de casos de uso del sistema con sus actores, casos de uso y sus descripciones; así como la relación entre estos a través de la organización por paquetes.

Volver al índice