SISTEMA DE GESTIÓN DE INFORMACIÓN PARA LA PRESTACIÓN DE SERVICIOS DE LA EMPRESA CENEX DE CIENFUEGOS

Yanirys Montes de Oca Hernández

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:

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.


Nombre del actor

Descripción

Cliente

El cliente es el que inicia todas las acciones que dan comienzo a los proceso del negocio analizados en los casos de uso Solicitar Servicio, Confeccionar Oferta y Confeccionar Contrato, pero al mismo tiempo se beneficia con el resultado del proceso.  

 

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

Cliente

 .

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.


Nombre del trabajador

Descripción

Jefe del área de la División de Servicios

Es el encargado de la confección de los documentos necesarios para realizar posteriormente el contrato, así como también está involucrada en todos los demás pasos hasta la confección final del contrato. No se beneficia de las acciones ejecutadas en el proceso del negocio sino que se limita a ejecutar.

Jefe de Equipo

Es el encargado de aprobar las solicitudes de los servicios en los que estén implicados, haciendo una valoración de las posibilidades de acometer el trabajo teniendo en cuenta la disponibilidad del personal calificado, equipos y materiales necesarios

Revisor de la oferta

Es el encargado después de la confección de la oferta de su  revisión.

Usuario de la entidad

Es el encargado de que si viene algún cliente  llenarle la solicitud del servicio.

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

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


 

Caso de Uso del Negocio

Solicitar Servicio.

Actores

Cliente  (inicia).

Propósito

Permitir al cliente realizar la solicitud de un servicio.

Resumen
El caso de uso de inicia cuando el cliente llega al área de la División de Servicios para realizar la solicitud de un servicio, donde es atendido por algún usuario de la entidad que escucha la misma y hace confección de la solicitud, culminando así el caso de uso. 

Casos de uso asociados

 

Curso Normal de los eventos

Acción del Actor

Respuesta del negocio

1- El cliente llega al CENEX o llama a dicho lugar.
2- El cliente solicita el servicio que desea realizar.

 

 

 
5-El cliente se retira o cuelga.

 

 

3- Cualquier usuario de la Entidad escucha la solicitud del cliente.
4- Luego proceden a realizar la solicitud y le explica los demás pasos a realizar después de haberle hecho la misma.

Curso Alternativo de los eventos

 

 

Prioridad

Alta

Mejoras

Permitirá automatizar la información de forma consistente para su posterior uso.

Caso de Uso del Negocio

Confeccionar Oferta.

Actores

Cliente  (inicia).

Propósito

Permitir al cliente conocer la oferta para el servicio que solicito.

Resumen
El caso de uso de inicia cuando el cliente vuelve a llamar o ir a la entidad para confirmar la solicitud del servicio, donde es atendido por la jefa de la División de Servicio que escucha la misma y comienza a confeccionar la oferta ,culminando así el caso de uso. 

Casos de uso asociados

Solicitar Servicio

Curso Normal de los eventos

Acción del Actor

Respuesta del negocio

1- El cliente llega al CENEX o llama a dicho lugar.
2- El cliente confirma la solicitud el servicio que desea realizar.
4-El cliente se retira o cuelga para esperar una respuesta.
.

 

 

 

8-El cliente recibe la oferta.

 

3- El de la División de Servicios escucha la confirmación de la solicitud del Servicio.
5- Luego proceden a realizar la oferta 6- La oferta se somete a una revisión por el  jefe del área de la División de Servicios y el Revisor de la oferta
7- Revisada la oferta se le entrega al Cliente si fue aceptada.

Curso Alternativo de los eventos

6)

Si alguno de los que revisa no esta de acuerdo por alguna razón se la envía al jefe de la División de Servicios.

7)

Si no se acepto solo se le informa al cliente

Prioridad

Alta

Mejoras

Permitirá automatizar la información de forma consistente para su posterior uso.

Caso de Uso del Negocio

Confeccionar Contrato.

Actores

Cliente  (inicia).

Propósito

Permitir al cliente revisar el contrato y fírmalo para su posterior ejecución.

Resumen
El caso de uso de inicia cuando el cliente le envía a el Jefe del área de la División de Servicios la aceptación de la oferta y este hace confección del contrato, culminando así el caso de uso. 

Casos de uso asociados

 

Curso Normal de los eventos

Acción del Actor

Respuesta del negocio

1-El cliente revisa la oferta y comunica que acepta.

 

 

 

5- Si el cliente está de acuerdo con lo leído en lo enviado procede a  firmar.

2- Aceptada la oferta se procede a la elaboración del contrato.
3- Luego de elaborado el contrato se pasa a su revisión por el jefe del área de la División de Servicios y el Asesor Jurídico.
4-Después se le enviará al cliente para su aprobación.
6-El jefe de la División de Servicio recibe el contrato  firmado por el cliente.
7-Se les entrega una copia del contrato a los Jefes de los Equipos involucrados en el servicio.

Curso Alternativo de los eventos

1)

Si el cliente no está de acuerdo con lo leído en la oferta del servicio solicitado  se lo informa al Jefe de Servicio.

3)

Si alguno de los que revisa no esta de acuerdo por alguna razón se la envía al jefe de la División de Servicios

5)

Si el cliente no está de acuerdo con lo leído en el contrato del servicio solicitado  se acordara una reunión con ambas partes para aclarar las mismas y para dar soluciones y se decidirá si firma o no.

Prioridad

Alta

Mejoras

Permitirá automatizar la información de forma consistente para su posterior uso.

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:

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.


Nombre del actor

Descripción

Jefe de la División de Servicios.

Es el encargado asesorar al cliente y entre sus obligaciones está la de crear solicitudes, ofertas y contratos desarrollados por el cliente. Responde a los requerimientos funcionales siguientes ().

Administrador

Tiene el control de los usuarios principales  del sistema, es quien crea las cuentas de acceso al mismo y le asigna a cada usuario sus permisos en dependencia al rol a desarrollar en todo el sistema y establece contraseña y a su vez puede también crear una solicitud.
Responde a los requerimientos funcionales siguientes ().  

Usuario

Toda aquella persona que acceda al sistema con previa autenticación, con el fin de gestionar información, según el nivel de acceso que tenga a la misma. Responde a los requerimientos funcionales siguientes ().

Jefe de Equipos

Es el encargado de realizar los reportes de las revisiones y de las producciones ejecutadas por cada uno de sus equipos. Responde a los requerimientos funcionales siguientes ().

Usuario de la Entidad

Toda persona que este registrada en la aplicación y entra  en busca de información general y pueden crear solicitudes. Responde a los requerimientos funcionales siguientes ().

 

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:

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


Casos de Uso del Sistema

Anexo Correspondiente

Autenticarse.

Anexo C.1

Cambiar contraseña.

Anexo C.2

Cerrar sesión.

Anexo C.3

Imprimir documento.

Anexo C.4

Gestionar usuario.

Anexo C.5

Gestionar solicitud.

Anexo C.6

Listar solicitud.

Anexo C.7

Visualizar solicitud.

Anexo C.8

Gestionar Oferta.

Anexo C.9

Listar ofertas.

Anexo C.10

Visualizar oferta.

Anexo C.11

Gestionar contrato.

Anexo C.12

Listar contratos.

Anexo C.13

Gestionar Ficha de Costo

Anexo C.14

Listar Ficha de Costo.

Anexo C.15

Gestionar Entidad.

Anexo C.16

Listar Entidades.

Anexo C.17

Gestionar Servicio.

Anexo C.18

Listar Servicios.

Anexo C.19

Gestionar Equipo de Trabajo.

Anexo C.20

Listar Equipos de Trabajo.

Anexo C.21

Insertar Servicio para un Equipo de Trabajo.

Anexo C.22

Gestionar producciones ejecutadas.

Anexo C.23

Listar producciones ejecutadas.

Anexo C.24

Visualizar producciones ejecutadas.

Anexo C.25

Gestionar Actividad.

Anexo C.26

Listar Actividad.

Anexo C.27

Gestionar Dieta.

Anexo C.28

Listar Dieta.

Anexo C.29

Insertar producción ejecutada para un equipo de trabajo.

Anexo C.30

Visualizar registro general de las solicitudes.

Anexo C.31

Visualizar registro general de las ofertas.

Anexo C.32

Visualizar registro general de contratos.

Anexo C.33

Consultar ayuda.

Anexo C.34

 

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:

 

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:

Volver al índice

Enciclopedia Virtual
Tienda
Libros Recomendados


1647 - Investigaciones socioambientales, educativas y humanísticas para el medio rural
Por: Miguel Ángel Sámano Rentería y Ramón Rivera Espinosa. (Coordinadores)

Este libro es producto del trabajo desarrollado por un grupo interdisciplinario de investigadores integrantes del Instituto de Investigaciones Socioambientales, Educativas y Humanísticas para el Medio Rural (IISEHMER).
Libro gratis
Congresos

4 al 15 de diciembre
V Congreso Virtual Internacional sobre

Transformación e innovación en las organizaciones

11 al 22 de diciembre
I Congreso Virtual Internacional sobre

Economía Social y Desarrollo Local Sostenible

Enlaces Rápidos

Fundación Inca Garcilaso
Enciclopedia y Biblioteca virtual sobre economía
Universidad de Málaga