SOPORTE Y MANTENIMIENTO POR MESA DE AYUDA€¦ · Mantenimiento NO ¿Autoriza el Mantenimiento? 13.1. Notificar la autorización SI 13.2 Notificar el rechazo NO 21. Recibir el Software
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Tabla de Contenido Historia de Versiones .......................................................................................................................... 2
Proceso .............................................................................................................................................. 10
Flujo a Alto Nivel ........................................................................................................................... 10
Diagrama de Flujo a Detalle .......................................................................................................... 11
Descripción de Actividades al detalle ............................................................................................ 12
Glosario de Términos Incidente (Operación del Servicio) Interrupción no planificada de un Servicio de TI o reducción en la Calidad de un Servicio de TI. También lo es el Fallo de un Elemento de Configuración que no ha impactado todavía en el Servicio. Por ejemplo el Fallo de uno de los discos de un “mirror”. Mantenimiento de Software Son todas aquellas modificaciones que se hacen al software después de haber sido liberado, para corregir fallas, mejorar el rendimiento, o para adaptarlo a los cambios del medio ambiente. Mantenimiento no urgente
Esta categoría abarca todas aquellas tareas de mantenimiento que no tienen fuertes restricciones
de tiempo, por lo que pueden planearse antes de iniciarlas.
Mantenimiento urgente
Se definen como mantenimiento correctivo no planeado, realizado para mantener un sistema en
funcionamiento.
Mesa Primer Nivel
En ella solo se delegara el incidente reportado al personal que esté en posibilidad de resolver, o
dará solución al mismo en caso de tratarse de un incidente genérico para cualquier aplicativo.
Mesa Segundo Nivel
En este nivel la mesa atenderá incidentes puntuales de los distintos aplicativos.
Mesa Tercer Nivel
Esta mesa está conformada de ingenieros expertos en soluciones a incidentes de alta complejidad
y que requieran de conocimientos avanzados en los distintos aplicativos hechos a la medida para
la detección de un mantenimiento.
Nivel de Petición (en el caso del presente se manejó Petición en lugar de Servicio) Resultados medidos y reportados frente a uno o más Objetivos de Nivel de Servicio. El término Nivel de Servicio es a veces empleado para referirse a un Objetivo de Nivel de Servicio.
Requerimientos de mantenimiento adaptativo. Serán todos aquellos requerimientos que permitan el mantener el software a la par con los cambios del medio ambiente, como podrían ser los avances tecnológicos, nuevos paradigmas, hardware, equipo y sistemas en general. Incluyendo aquellas funcionalidades no previstas en el momento de su desarrollo, pero que se revelen de interés para un mejor funcionamiento de los aplicativos.
Requerimientos de mantenimiento perfectivo. Serán todos aquellos requerimientos que permitan el mejoramiento del software es decir agregar nuevas características, mejorar las ya existentes. Requerimientos de mantenimiento correctivo. Serán todos aquellos requerimientos que permitan observar anomalías en el funcionamiento previsto de los aplicativos, permitiendo ajustar el funcionamiento, según requerimientos de modificación funcional. Igualmente, el mantenimiento correctivo no incluye optimizaciones, mantenimiento y errores de sistemas ajenos al aplicativo que interactúen con el mismo y/o SGBDs. Requerimientos de mantenimiento preventivo. Serán todos aquellos requerimientos con el propósito de prevenir problemas antes de que ocurran. Incluye la revisión periódica de la consistencia de la información contenida en la Base de Datos.
Módulos Aplicativos (Desarrollos a la medida) APLICACIONES QUE ENTRAN DENTRO DEL ALCANCE DE LA PROPUESTA
1. Sistema Automatizado de Egresos Hospitalarios y Urgencias Médicas (SAEHU) 2. Sistema de Administración de Equipos del Área de Biomédicos 3. Sistema de Adquisiciones 4. Sistema de Brazaletes OPD 5. Sistema de Control de Donativos/Comodato 6. Sistema de Estadísticas (Integración SINAC-SAEH) 7. Sistema de Licitaciones 8. Sistema de Médico de Empleados 9. Sistema de Mezclas y Antibióticos 10. Sistema de Pagos Electrónicos de Donativos 11. Sistema Evaluaciones Psicológicas 12. Captura electrónica directa proveedor 13. Conexión de iSoft a SAEH (Sistema Automatizado de Egresos Hospitalarios y
Defunciones) 14. Conexión de iSoft a SINAC (Subsistema de Información sobre Nacimientos) 15. Cotizador de Proveedores 16. Impresión de Expediente y Tarjetón citas 17. Modificación directa a base de datos de Adquisiciones 18. Pedidos Faltantes Medicamentos en Medico de Empleado 19. Pre-alta de Catálogos 20. Sistema de Incumplimiento de Proveedor y Cancelaciones 21. Sistema de Encuestas para SIDEVOZ** 22. Sistema de Caja** 23. Sistema de Seguro Popular** 24. Sistema de Trabajo Social**
** Sistemas que al momento de elaborar la presente propuesta no están en producción, sin
embargo en cuanto se liberen a producción se contemplan en la misma. Cualquier otra aplicación
NO mencionada se tendrá que evaluar si entra dentro de la misma propuesta, por no estar en
II. Niveles de Servicios (SLA´s) de mantenimiento*
Prioridad Descripción
Nivel de Servicio en la
Atención a la solicitud
Nivel de Servicio en
proveer una solución
Nivel 1
Requerimiento de un Mantenimiento Prioritario.
Alto Impacto.- Detiene parcialmente la operación normal del sistema, y no se disponen de
alternativas de funcionalidad.
48 horas
95% de
apego al estimado que
se dé.**
Nivel 2
Requerimiento de un Mantenimiento Importante.
Baja Impacto.- No detiene la operación normal del sistema, pero se requieren como respuesta a la
necesidad de un cambio en el proceso.
7 Días
90% de
Apego al estimado que
se dé.**
Nivel 3
Requerimiento de un Mantenimiento Deseable. Deseable.- No impacta la operativa de los
aplicativos y responde a una propuesta de mejora o
bien a solicitudes de reportes de baja importancia.
15 Días
90% de Apego al
estimado que
se dé.**
* De acuerdo a matriz de prioridades definida por el OPD HCG (Impacto en número de usuarios, Usuarios VIP, época del reporte del incidente, etc.) ** Una vez finalizado el análisis del requerimiento se ofrecerá una solución alternativa y un estimado de fechas en las cuales estará operativa la solución definitiva.
Atención a la solicitud El tiempo que transcurre desde que el usuario se pone en contacto con CoSoft TI por los medios establecidos, y recibe contestación del técnico. Estimado de solución El tiempo máximo en el que se deberá desarrollar la solución del requerimiento, en función de la prioridad.
INSTRUCCIONES PARA EL LEVANTAMIENTO Y APROBACIÓN DE INCIDENTES
PM–IDP–001 30 – 09 - 2012 PM 4.0
NUEVO INCIDENTE O REPORTAR INCIDENTE
Para enviar una solicitud a la Mesa de Ayuda el usuario deberá pulsar el botón Reportar
Incidente.
El sistema desplegará la siguiente pantalla:
Nombre Completo
El usuario deberá digitar Nombre con todo y apellidos de quien reporta el formulario.
Correo electrónico
El usuario deberá digitar de forma obligatoria el correo del usuario que levanta el incidente en el cual recibirá el número del ticket y la información relacionada con su solicitud es muy importante NO variar el correo del mismo usuario ya que esté servirá para identificarse dentro de la aplicación.
INSTRUCCIONES PARA EL LEVANTAMIENTO Y APROBACIÓN DE INCIDENTES
PM–IDP–001 30 – 09 - 2012 PM 4.0
Teléfono
El usuario podrá capturar un número de teléfono fijo o celular en el cual lo pueda contactar la Mesa de Ayuda, esté no es obligatorio para levantar un incidente.
Ext
El usuario podrá capturar el número de extensión en caso de utilizar una.
Aplicación
En este punto hay que selecciona el modulo aplicativo o el software que adquirió al que se le está designando el incidente, por lo que el usuario deberá hacer clic en el triángulo invertido para desplegar los Aplicativos en los casos en que no se identifique se deberá seleccionar Otro Sistema, y en los comentarios señale cual es la aplicación a la que hace referencia la tarea identificada.
Tarea
Es un breve nombramiento que hacer referencia al incidente que se está reportando.
Comentarios
Es la descripción detallada del incidente en él se le pide proporcione el mayor pormenor posible.
Nivel de Servicio
Se manejan cuatro tipos de niveles: a) Nivel 1 – Critico (System Down) b) Nivel 2 – Alto Impacto c) Nivel 3 – Bajo Impacto d) Nivel 4 – Deseable
Nota: El usuario tiene la obligación de seleccionar un nivel de petición de acuerdo a las instrucciones de la Coordinación General de Informática.
Archivos Adjuntos
El usuario podrá anexar un archivo que facilite a la Mesa de Ayuda solucionar su inquietud. Este archivo podrá ser en el formato .doc, .pdf, .xls, .xlsx, .zip, .rar, .jpg, png en el cual se incluye un pantallazo de la situación detectada en el. Para anexar el archivo el usuario deberá hacer clic en el botón Examinar, el sistema desplegará la pantalla con los directorios. Estos archivos no pueden tener un tamaño mayor a 5 MB.
Texto de Seguridad
El usuario deberá introducir el texto que aparece en la imagen de la izquierda.
INSTRUCCIONES PARA EL LEVANTAMIENTO Y APROBACIÓN DE INCIDENTES
PM–IDP–001 30 – 09 - 2012 PM 4.0
Finalmente el usuario hará clic en el botón Enviar Reporte.
Si el usuario cometió algún error dentro del formulario, el sistema desplegará un mensaje
como se muestra en la siguiente pantalla:
El usuario corregirá el error y nuevamente pulsará el botón Enviar Reporte. Si la creación de la solicitud es exitosa, el sistema desplegará la siguiente pantalla:
Para conocer el número asignado a su solicitud y poder hacerle seguimiento, el usuario
Tabla de contenido Historial de Versiones .................................................................................................................. 4 Descripcion.................................................................................................................................... 6 Antecedentes ................................................................................................................................ 6 Objetivo general ............................................................................................................................ 6 Objetivos específicos ................................................................................................................... 6 Especificacion de requisitos ....................................................................................................... 7 Alcances ........................................................................................................................................ 7 Requerimientos funcionales ........................................................................................................ 8 Detalle del Requerimiento ......................................................................................................................................... 8
Diagrama de Interacción Entre sistemas. ............................................................................................................... 11
Diagrama de Flujo de Proceso. ............................................................................................................................... 12
Requerimientos No funcionales ................................................................................................ 17 diagramas de casos de uso ....................................................................................................... 18 definicion de actores .................................................................................................................. 19 documentacion de los casos de uso ........................................................................................ 19 Modelo Entidad-Relacion ........................................................................................................... 23 Diccionario de datos ................................................................................................................... 24 Diagrama de flujo ........................................................................................................................ 26 Manual de Usuario ...................................................................................................................... 26 Mensajes de Error ....................................................................................................................... 27 Codigo fuente / Store Procedures debidamente documentado (si aplica) ........................... 28 Anexos ......................................................................................................................................... 28 Glosario de Términos y Acrónimos .......................................................................................... 29 Firmas de Autorización: ............................................................................................................. 30
Descripcion
Descripcion clara y concisa, no mayor a un párrafo del sistema y su objetivo
Antecedentes
Explicacion clara y concisa de los eventos o situaciónes que dieron origen al surgimiento de la necesidad del sistema.
El sistema de captura ya existente de pulseras es actualmente utilizado en la Unidad
Hospitalaria de Fray Antonio Alcalde en el O.P.D. del Hospital Civil, como recurso para la
generación de una identificación de hospitalizados.
Es por lo cual se ha generado una propuesta basada en una solución de software a base
de un aplicativo que realice la conexión entre los sistemas internos de la OPD HCG
identificado como iSoft, para la generación de pulseras a nivel O.P.D., dicha aplicación
extraerá la información de la Base de Datos del sistema iSoft para posteriormente imprimir
en formato de pulsera.
Objetivo general
Una explicación del objetivo del sistema y de la funcionalidad del mismo.
Desarrollo de sistema para impresión de brazaletes de identificación para las áreas de
ingreso y neonatología del OPD Hospital Civil de Guadalajara
Objetivos específicos
En esta sección debería aclarar tanto cualquier suposición que haya hecho sobre el
significado de los requisitos, como cualquier extensión o modificación de los mismos.
1. Reducir el recurso humano y el esfuerzo utilizado en la captura manual para
generar la información.
2. Agilizar el proceso operativo.
3. Reutilizar la información contenida en la base de datos de los sistemas internos de
la O.P.D. Hospital Civil de Guadalajara (iSoft).
4. Generar la impresión de pulseras.
Especificacion de requisitos
Deben especificarse todos los elementos o requisitos necesarios para que el sistema
funcione
Requerimientos de Hardware:
o Procesador Pentium 4 o superior.
o 512KB mínimo, 1 GB óptimo en RAM.
Requerimientos de Software
o Java JRE 1.5 o superior.
o Sistema operativo Windows XP o superior.
Alcances
Definición especifica de lo que contempla el sistema y lo que no
Requerimientos funcionales
Detalle del Requerimiento
ID.
Requerimiento
RF-
INTERFAZ
HCG-001
Versión 1.0.1 Fecha
Creación
24-08-2011
Diagrama
Título del
Requerimiento
Extracción de la información general de los
pacientes del sistema del HCG.
Fecha de
VoBo.
Descripción
General
Al capturar una prescripción en los sistemas SAFE (WebSAFE/SISAFE),
deberá obtenerse los datos generales del paciente del sistema del HCG.
Esto por medio del NHC (Número de historia clínica), que en los sistemas
SAFE se denomina cédula o registro.
Esta información, deberá alimentarse en los datos del paciente dentro de
los sistemas SAFE, evitando recaptura y/o errores de captura.
Criterio de Éxito
Transacciones/Funciones/Opciones del Sistema Resultado esperado
1 Extracción de datos generales
del paciente del sistema del
hospital.
De acuerdo al NHC (registro o cédula),
deberá solicitarse los datos generales
del paciente al sistema del hospital. En
caso de no existir la información,
deberá informar de la desviación pero
no impedirá seguir con el proceso.
2 Guardar la información de los
datos generales del paciente,
antes de proceder con la
generación de la prescripción.
Deberá guardarse la información
general del paciente antes que el
pedido, en WebSAFE o SAP, sea
capturando.
Restricciones Clientes:
Nuevo Hospital Civil de Guadalajara (NHCG) – Dr. Juan I.
Menchaca (JIM)
Antiguo Hospital Civil de Guadalajara (AHCG) – Fray Antonio
Alcalde (FAA)
Centro de Mezclas:
Guadalajara
Sistemas:
WebSAFE
SISAFE 2.5
Supuestos El personal de informática de los HCG entregará un servicio
Web que permitirá el acceso a la información del paciente. Por
medio del NHC (cédula o registro), la el servicio Web regresará
los datos generales del paciente.
La regla de negocio del servicio Web para la extracción de la
información será responsabilidad del personal de informática
del Hospital.
Supuestos El personal de informática de los HCG entregará un servicio
Web que permitirá el acceso a la información del paciente. Por
medio del NHC (cédula o registro), la el servicio Web regresará
los datos generales del paciente.
La regla de negocio del servicio Web para la extracción de la
información será responsabilidad del personal de informática
del Hospital.
El Hospital proporcionará las URL de pruebas y productivo
donde estarán publicados los servicios Web.
Diagrama de Interacción Entre sistemas.
Diagrama de flujo de proceso ( requerimiento)
Necesidad
de capturar
un pedido
Ingreso a
pantalla de
datos generales
del paciente.
Crea el paciente y
capturas sus datos.
USUARIO
WebSAFE/SISAFE
FIN
A
¿Cliente
configurado para
extraer datos de
paciente?
A
WebSAFE/SISAFE:
Solicita datos generales
del paciente a sistema
del Hospital, de
acuerdo al NCH y
Hospital.
Sistema HCG:
Obtiene los datos del
paciente de su base de
datos de acuerdo al
NCH y Hospital.
Sistema HCG:
Devuelve estatus
“encontrado” y datos del
paciente o estatus “no
encontrado”.
WebSAFE/SISAFE:
Recibe datos del
paciente o estatus no
encontrado.
¿Estatus
“encontrado”?
WebSAFE/SISAFE:
Envía mensaje:
“NHC no encontrada en
el sistema del Hospital”.
WebSAFE/SISAFE:
Solicita confirmación
para continuar.
¿Confirma captura
sin datos del sistema
del Hospital?
Captura NHC
(Cédula / registro)
USUARIO
WebSAFE/SISAFE
Captura
prescripción.
USUARIO
WebSAFE/SISAFE
Crea el paciente o
modifica sus datos.
USUARIO
WebSAFE/SISAFE
¿Continuar con la
captura de la
prescripción?
V
V
¿NHC existe en
el sistema SAFE?
WebSAFE/SISAFE:
Crea el paciente con
los datos obtenidos del
sistema del hospital.
WebSAFE/SISAFE:
Modifica el paciente
con los datos obtenidos
del sistema del hospital.
Verifica y/o
modifica los datos
del paciente.
USUARIO
WebSAFE/SISAFE
V
SI
NO
NO
SI
NO
SI
SINO
SI
NO
V
¿Sistema del
hospital
disponible?
V
NOSI
Catálogos relacionados (claves genéricas) Se utilizarán claves genéricas para los catálogos requeridos, esto debido a que deberá
cubrir la operación en dos sistemas -- WebSAFE y SISAFE – y en cada uno de los
sistemas deberá realizar la conversión correspondiente de acuerdo a los valores en los
* El contenido del catálogo de servicios puede sufrir modificaciones, una vez que se
revisen los datos maestros estando próximos a la implementación.
UMedica DESCRIPCION
JIM Nuevo Hospital Civil (Juan I. Menchaca)
FAA Antiguo Hospital Civil ( Fray Antonio Alcalde)
Requerimientos No funcionales
1. La solución propuesta deberá apegarse a los lineamientos ya definidos.
2. Parametrizar la aplicación con el fin de configurar mensajes al usuario, etiquetas y
algún comportamiento en específico (por ejemplo el buscador).
Diagramas de casos de uso
Descripción grafica de un caso de uso
Usuario
El Usuario buscar los Incumplimientos por medio de metodos de Búsqueda
del sistema
Sistema
El Sistema muestra todos los incumplimientos deacuerdo a los
parametros de Búsqueda del usuario.
El Usuario Selecciona uno o varios Incumplimientos y aplica la
penalizacion a los Incumplientos.
El Sistema genera los Incumplientos seleccionados por el Usuario,
agrupandos por Proveedor
Caso de Uso de Generación de una Penalización
Definicion de actores
Descripcion de todos los actores que intervienen
Documentacion de los casos de uso
Un caso de uso es un objetivo específico y una lista de acciones que un usuario lleva a
cabo para conseguir dicho objetivo. El usuario debe poder, entre otras cosas, examinar la
lista de acciones para decidir si la interfaz de usuario es aceptable. Si la colección de
casos de uso abarca todos los objetivos deseados por el usuario este puede tener la
seguridad de que el sistema cumplirá con su objetivo.
Modify Invoice Web Function
This chapter describes the changes to this existing sub-functional area being introduced in this release for modifying the details of an existing INVOICE.
Requirements
This section addresses the following Requirements:
Reference Description
PCR-09-SF-001
The INVOICE web application shall record the user ID, and timestamp for all the records that define a INVOICE when they are created, updated, or deleted. [INVOICE Web]
PCR-09-SF-002
The INVOICE web application shall create a new record in history containing the user ID, timestamp, and type of operation performed (insert, update, or delete) for all the records that define a INVOICE when they are created, updated, or deleted. [INVOICE Web]
PCR-09-SF-003
The INVOICE web application shall consistently set the same version for all records associated that define a INVOICE. [INVOICE Web]
The create, update, and copy functions within INVOICE shall no longer conditionally enforce whether the region, country, and business unit fields are required for a INVOICE to be assigned a 'Ready' status based on the value for the accounting year. They will not be required for a INVOICE to be assigned the 'Ready' status. [INVOICE Web]
Use Case: UCINVOICE002 - Modify INVOICE
Brief Description
The user modifies an existing INVOICE.
Actors
The following users:
- INVOICE Admin
- INVOICE Supervisor
Business Rules
The following fields will not be required: region, country, and business unit. If the master data does happen to be populated for those fields, the user will be able to optionally select values for those fields. In addition, a INVOICE will be placed in the 'Ready' status without having values set for the region, country, and business unit fields
INVOICEs that are in the 'Frozen' status can not be modified.
The user's organization must be the same as that assigned to the INVOICE.
Initiating
The user selects the "Modify" link from the INVOICE Details screen of the INVOICE they wish to modify.
Preconditions
- The user has logged into the INVOICE website and been successfully authenticated.
- The user is one of the type of actors described in the actors section.
- The user is currently viewing the INVOICE Details screen of the INVOICE they wish to modify.
- All the INVOICE master data has been defined.
Interactions – Main
1. The user selects the "Modify" link from the INVOICE Details screen of the INVOICE they wish to modify.
2. The INVOICE web application displays the "Modify INVOICE" screen with all the UI controls pre-selected with the values for the INVOICE that is being updated.
3. The user changes whatever information they want on this screen, and the user specifies values for all the required fields on the screen (Plan Year, Geo, Business Unit, and Plan Type). The user presses the "Continue" button.
4. The INVOICE web application displays the "Modify INVOICE Paymix/Weightings" screen.
5. The user selects the incentive element they want to modify.
6. The INVOICE web application displays the "Modify INVOICE Element Details" screen.
7. The user changes whatever information they want to on this screen and presses the "Continue" button.
8. The user has modified the incentive elements they needed to modify and are displayed on the "Modify INVOICE Paymix/Weightings" screen. The user specifies a comment and presses the "Submit" button.
9. The INVOICE web application saves the modifications to the INVOICE in the INVOICE database
11. The INVOICE web application displays the "INVOICE Modify Results" screen indicating the number of the INVOICE that was modified.
Interactions – Alternative
Alternative #1: The user attempts to submit a modification to a INVOICE without first selecting the required fields
3.a. The user presses the "Continue" button without having specified values for the required fields (Year, Geo, Organization).
4.a. ERROR_1 is displayed to the user at the top of the "Modify INVOICE" screen indicating the user must specify values for the required fields.
Alternative #2: The user specifies a non-integer headcount value.
3.a. The user specifies values for the headcounts that are non-numeric and presses the "Continue" button.
4.a. ERROR_3 is displayed to the user at the top of the "Modify INVOICE" screen indicating headcount entries must be in integer format.
Alternative #3: The user specifies headcount values that do not equal the total headcount value. (This should never happen since the web page calculates the total)
3.a. The user specifies values for the regional headcounts and the total headcount is not updated properly before the user presses the "Continue" button.
4.a. ERROR_4 is displayed to the user at the top of the "Modify INVOICE" screen indicating the Total HC value does not equal to the sum of the regional HC values.
Alternative #4: The user specifies a combination of plan year, plan type, and job role that are already in use.
3.a. The user specifies a value for the job role and plan type that are already in use for the selected plan year. The user presses the "Continue" button.
4.a. ERROR_5 is displayed to the user at the top of the "Modify INVOICE" screen indicating the specified plantype and jobrole combinations are already being used.
Post-Conditions – Main
The "INVOICE Modify Results" screen is displayed to the user indicating the number of the newly modified INVOICE.
Post-Conditions – Alternative
Alternative #1: The user attempts to submit a modification to a INVOICE without first selecting the required fields
The "Modify INVOICE" screen is displayed with ERROR_1 at the top.
Alternative #2: The user specifies a non-integer headcount value.
The "Modify INVOICE" screen is displayed with ERROR_3 at the top.
Alternative #3: The user specifies headcount values that do not equal the total headcount value. (This should never happen since the web page calculates the total)
The "Modify INVOICE" screen is displayed with ERROR_4 at the top.
Alternative #4: The user specifies a combination of plan year, plan type, and job role that are already in use.
The "Modify INVOICE" screen is displayed with ERROR_5 at the top.
Alternative #5: The user specifies "Other - Exception Required" paymix/weightings, and updates the weights that don't add up to 100.
The "Modify INVOICE Paymix/Weightings" screen is displayed with ERROR_7 at the top.
Related Message IDs
ERROR_1 -- You did not specify values for the Plan Year, Geo, Organization, and Plan Type fields. Specify values for those fields and re-submit the form.
ERROR_3 -- You specified non-integer values for the Headcounts. Specify integer values for those fields and re-submit the form.
ERROR_4 -- The Total HC value does not equal the sum of the regional HC values. Hit the browser refresh button and re-submit your request. If this problem persists, contact your INVOICE administrator for further assistance.
ERROR_5 -- You specified a combination of Plan Type and Job Role that is already being used by another INVOICE. Select another Job Role.
Logical Flows
The following sections describe the logical flows that will be employed during the use cases that were previously described.
Diagrama donde se muestran las relaciones entre todas las tablas involucradas con el sistema en
particular, incluyendo tanto las internas como las externas, señalando relaciones 1-1 y 1-n,
responsables, ultima modificación.
Diccionario de datos
Catalogo general de todas las tablas incluidas en el sistema tanto internas como externas donde
se especifica a detalle el contenido de cada una. Debe incluir una portada con los generales y el
detalle del contenido.
Diagrama de flujo (general)
Manual de Usuario
Una descripción detallada sobre cómo el usuario puede utilizar el sistema, qué
operaciones puede llevar a cabo, cuáles son los argumentos de la línea de comando, etc.
Las especificaciones detalladas de los formatos deberían relegarse al Apéndice.
Cualquier suposición relativa al entorno debería explicitarse aquí: por ejemplo, observe si
el programa sólo se ejecuta en ciertas plataformas, si supone que la jerarquía de un cierto
directorio está presente, si existen otras aplicaciones, etc. Junto con la visión general,
este manual debería proporcionar toda la información que un usuario del sistema
necesita.
Mensajes de Error Debe incluir todos los posibles mensajes de error tanto para usuarios como para sistema
Error Number
Description User Initiated Action
Type
User Recovery Action
ERROR_1 You did not specify values for the Plan Year, Geo, Organization, and Plan Type fields. Specify values for those fields and re-submit the form.
User Input Exception is thrown in methods.
Loads the same page with the error message.
User has to specify the plan year and geo fields and re submit the form.
ERROR_2 The number of INVOICEs for this Organization has exceeded the maximum limit of 1000. Contact your INVOICE administrator for further assistance
Operation Failed Exception is thrown in methods.
Loads the same page with the error message.
Contact INVOICE administrator Support
ERROR_3 You specified non-integer values for the Headcounts. Specify integer values for those fields and re-submit the form.
User Input Exception is thrown in methods.
Loads the same page with the error message.
User has to specify the integer value and re submit the form.
ERROR_4 The Total HC value does not equal the sum of the regional HC values. Hit the browser refresh button and re-submit your request. If this problem persists, contact your INVOICE administrator for further assistance.
User Input Exception is thrown in methods.
Loads the same page with the error message.
User has to hit the browser refresh button and re-submit the request. If this problem persists, contact INVOICE administrator for further assistance.
ERROR_5 You specified a combination of Plan Type and Job Role that is already being used by another INVOICE. Select another Job Role.
User Input Exception is thrown in methods.
Loads the same page with the error message.
User has to specify a different Job Role and re submit the form.
Codigo fuente / Store Procedures debidamente documentado (si aplica)
Anexos
Glosario de Términos y Acrónimos
Término Descripción
JRE Java Runtime Environment – Entorno en tiempo de ejecución de Java.
Firmas de Autorización: Puesto Nombre Firma Fecha
CONTROL DE CAMBIOS 11 de Agosto del 2011
ANEXO
Formato solicitud control de cambio
CONTROL DE CAMBIOS 11 de Agosto del 2011
GENERALES
Sistema. Adquisiciones V 4.2
Fecha de liberación. 14 de Septiembre del 2010
Persona que libera. Ing. Jorge Flores Montoya
Cel. 04433 xxxxxxxxx
Cliente o área de servicio. Adquisiciones OPD en Hospital Civil de Guadalajara
Nombre de los archivos que se afectan en el release (incluir ruta).
• C:\iSoft\adquisiciones\Adquisiciones.jar
Nombre del servidor en donde se ejecuta el aplicativo (si aplica).
10.2.1.x
Nombre del servidor de la ubicación de la base de datos (si aplica).
10.2.1.x
Descripción general de lo que incluye este cambio.
Cargas masivas.
Prioridad y justificación. URGENTE. Agrega Columna para identificar Tipo de Pedido.
Archivos anexos Query1.sql
Query2.sql
Realizo pruebas de usuario. Mario López
Fecha de pruebas de usuario 10 agosto 2011 11:00 hrs.
INSTRUCCIONES PARA LA INSTALACION
1.- Copiar el archivo C:\HCG\Produccion\Adquisiciones.jar ubicado en el
servidor de desarrollo 10.2.1.x al servidor de producción de aplicaciones 10.2.1.x en la ruta
CONTROL DE CAMBIOS 11 de Agosto del 2011
C:\isoft\adquisiciones\. Antes de hacer la copia favor de respaldar el archivo del servidor
de producción.
2.-ejecutar el archivo Query1.sql
3.-Ejecutar el archivo Query2.sql
CONTROL DE CAMBIOS 11 de Agosto del 2011
PRUEBAS
El sistema fue probado en el servidor de desarrollo 10.2.1.x y demostró resolver el problema descrito. No se observaron errores en pantallas o log de operación. Pantalla muestra: