T 72464

Transcripción

T 72464

PONTIFI
PONTIFICIA
FICIA UNIVERSIDAD CATÓLICA
CATÓLICA DEL ECUADOR
SEDE – IBARRA
ESCUELA DE INGENIERÍA
INGENIERÍA
TEMA:
“DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE
INFORMACIÓN PARA EL CENTRO DE REHABILITACIÓN FÍSICA DE
ANTONIO ANTE”.
LÍNEA DE INVESTIGACIÓN:
INVESTIGACIÓN:
PLATAFORMAS e- (1.7.)
PREVIO LA OBTENCIÓN DEL TÍTULO
TÍTULO DE
INGENIERO EN SISTEMAS
AUTORAS:
Esparza Lima Verónica Karina
Inlago Caiza Fanny Lorena
ASESOR:
Ing. Juan Carlos Armas
Ibarra, Mayo 2011
RESUMEN EJECUTIVO
El presente proyecto nace de la necesidad del Centro de Rehabilitación Física de Antonio
Ante de disponer un Software de Gestión de Información, como una nueva alternativa en
el manejo de la información que satisfaga las necesidades del personal administrativo.
Las empresas se enfrentan a nuevos retos tecnológicos, la competencia es cada vez
mayor, y se convierte en una prioridad buscar soluciones que satisfagan los intereses de
los funcionarios, así como de los pacientes.
Hoy en día el uso de la tecnología desempeña un papel importantísimo en nuestra
sociedad. Permiten cubrir muchas necesidades, generar nuevas alternativas de trabajo y
potenciar el desarrollo de las empresas e instituciones.
La tecnología se ha convertido en una herramienta indispensable para el progreso y
adelanto de los pueblos y sin importar el tipo de negocio o empresa, su uso se hace cada
vez más frecuente.
El Centro de Rehabilitación en la actualidad presenta dificultad en el manejo de la
información ya que este controla los documentos de forma manual y por ende hay un
consumo de tiempo, materiales y recursos económicos, impidiendo brindar un servicio
funcional y dinámico a la comunidad anteña.
Ante este problema el Centro de Rehabilitación ha tenido que proponer una solución en la
parte tecnológica para brindar un mejor servicio a los pacientes.
Por la demanda de los pacientes por las diferentes terapias, el Centro de Rehabilitación
Física ha tenido que contar con profesionales y estar preparados para enfrentar los
nuevos retos y los constantes avances tecnológicos.
2
Este proyecto presenta una propuesta, acorde a las necesidades actuales del Centro de
Rehabilitación Física, permitiéndole estar a la vanguardia tecnológica, obtener mayor
eficiencia en el control de los archivos, obtener mayor rapidez al disponer de la
información de una forma ágil, mejorando así la atención a los pacientes.
Posteriormente se analizan los diferentes impactos prospectivos; Social, Ético y
Tecnológico, que el presente proyecto pueda generar.
Para finalizar se dan a conocer las conclusiones del estudio realizado por los autores y se
listan algunas recomendaciones.
3
AUTORÍA
AUTORÍA
Nosotras, Verónica Karina Esparza Lima con cédula de ciudadanía Nro.
100298910-9 y Fanny Lorena Inlago Caiza con cédula de ciudadanía Nro.
100283462-8, declaramos bajo juramento que la presente investigación es de
total responsabilidad de los autores, y que se ha respetado las diferentes
fuentes de información realizando las citas correspondientes.
-----------------------------
-----------------------------
KARINA ESPARZA
FANY INLAGO
C.C 100298910-9
C.C 100283462-8
4
CESIÓN DE DERECHOS DE AUTOR
Nosotras, Verónica Karina Esparza Lima, y Fanny Lorena Inlago Caiza,
declaramos conocer y aceptar la disposición del Art. 66 Del Instructivo de
Trabajo de Grado de la Pontificia Universidad Católica del Ecuador Sede
Ibarra que en su parte pertinente textualmente dice: “Forman parte del
patrimonio de la Universidad la propiedad intelectual de investigaciones,
trabajo científicos o técnicos y tesis de grado que se realicen a través, o con
el apoyo financiero, académico o institucional(operativo) de la Universidad”.
-----------------------------
-----------------------------
KARINA ESPARZA
FANY INLAGO
5
PRESENTACIÓN
El proyecto de Gestión de Información consta de cuatro capítulos: Fundamentación
Teórica, Ingeniería de la Solución, Referencia Operativa y Análisis Prospectivo de
Impactos.
El Capítulo I contiene la investigación documentada, en la que se han analizado y
sintetizado contenidos que directa o indirectamente se relacionan con el tema del
proyecto.
El Capítulo II se analiza el diseño e implementación del modelo de solución informático, el
cual permitió determinar el entorno de desarrollo y herramientas para elaborar la
solución informática.
El Capítulo III se describe una guía sobre la operatividad del interfaz del sistema, el cual
explica el funcionamiento de las partes que constituye el sistema y la forma de usarlo.
El Capítulo IV se realiza un análisis de los principales impactos del proyecto, para lo cual se
utiliza una serie de indicadores los cuales determinan el grado de incidencia de cada
impacto, para luego determinar el impacto global del proyecto.
Para el final se termina con las conclusiones y recomendaciones que ha emitido el
presente proyecto.
6
AGRADECIMIENTO
A la Pontificia Universidad Católica del Ecuador Sede – Ibarra por abrirnos las puertas y
entregarnos los sabios conocimientos a través de quienes fueron nuestros maestros, los
mismos que nos fortalecieron en nuestra vida universitaria impartiéndonos las bases
necesarias para alcanzar la competitividad en el ámbito profesional.
Un agradecimiento muy especial al Ingeniero Juan Carlos Armas quien con su
conocimiento académico y experiencia supo guiarnos para un buen desarrollo de este
trabajo como Asesor de Tesis.
Un agradecimiento sincero al Centro de Rehabilitación Física de Antonio Ante por abrirnos
las puertas y por el apoyo incondicional que nos han brindado para alcanzar con éxito
nuestros objetivos.
Agradecemos a Dios por las oportunidades que nos ha brindado durante nuestra vida
estudiantil.
7
DEDICATORIA
A nuestros queridos padres, quienes con sus valores de respeto, confianza, junto con su
cariño y amor, han sido el pilar fundamental y ejemplo de responsabilidad, el cual
supieron guiarnos para poder culminar esta importante fase de nuestras vidas.
A todos ellos dedicamos nuestro proyecto que representa el esfuerzo, la dedicación y
constancia.
8
ÍNDICE
RESUMEN EJECUTIVO
2
AUTORÍA
4
CESIÓN DE DERECHOS DE AUTOR
5
PRESENTACIÓN
6
AGRADECIMIENTO
7
DEDICATORIA
8
INTRODUCCIÓN
CAPÍTULO I:
1
1.1
1.1.1
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
1.2.9
1.2.10
1.2.11
1.2.12
1.2.13
1.2.14
1.2.15
1.3
1.3.1
1.3.2
1.3.2.1
15
FUNDAMENTACIÓN TEÓRICA
Fundamentación Teórica
Centro Rehabilitación Física de Antonio Ante
Reseña Histórica
La Medicina Física y Rehabilitación
Visión Histórica
Rehabilitación
Organización Mundial de la Salud
Organización Panamericana de Salud
Representación De la OPS / OMS En El Ecuador
Sociedad Ecuatoriana de Medicina Física y Rehabilitación
Ministerio de Salud Pública
Consejo Nacional de Salud
Conferencia Nacional Sobre Desarrollo Social
Sistema Nacional de Salud
Formulario de Rehabilitación Física en el Ecuador
Formulario de Rehabilitación Física de Antonio Ante
Estructura del Centro de Rehabilitación Física de Antonio Ante
Flujo, Tránsito y Tratamiento de Pacientes en el Centro de
Rehabilitación Física de Antonio Ante
Flujo de Información en el Centro de Rehabilitación Física de
Antonio Ante
Base de Datos
Características de una Base de Datos
Sistema Manejador de Base de Datos(DBMS)
Objetivos de los Sistemas de Base de Datos
9
16
16
16
18
18
19
19
24
25
25
26
29
32
34
36
38
42
43
44
46
46
46
47
1.3.3
1.3.3.1
1.3.4
1.3.4.1
1.3.4.2
1.3.4.3
1.3.4.4
1.3.4.5
1.3.4.6
1.3.4.7
1.3.5
1.3.6
1.3.6.1
1.3.6.2
1.3.6.3
1.3.7
1.3.7.1
1.3.8
1.4
1.4.1
1.4.1.1
1.4.1.2
1.4.2
1.4.2.1
1.4.3
1.4.4
1.4.5
1.5
1.5.1
1.5.2
1.6
1.7
1.7.1
1.7.2
1.8
1.9
1.10
1.10.1
1.10.1.1
1.10.1.2
1.10.2
1.10.3
Base de Datos Relacionales
Diseño de Base de Datos Relacionales
Diseño Lógico de Base de Datos
Integridad de Datos
Tipos de Restricciones de Integridad en Base de Datos
Relacionales
Normalización
Propiedades de una Base de Datos después de la
Normalización
Propiedades de una Relación
Claves
Grados de Normalización
Diseño Físico
Sistema de Base de Datos
Características de DBMS
Esquemas de un DBMS
Programas que Conforman un DBMS
Lenguaje SQL
Comandos SQL
Comparación de Sistemas Administrativas de Base de Datos
Herramientas de Desarrollo
Base de Datos MY SQL
Características
Ventajas como Servidor de Base de Datos
PHP
Características de PHP
Php Runer
Macromedia Dreamweaver
Java Script
Diagrama de Diseño
Diagrama de Casos de Usos
Elementos de un Diagrama de Casos de Usos
Sistema Informático
Arquitectura de la Aplicación
Arquitectura Cliente / Servidor
Modelo de Arquitectura Cliente / Servidor
Ciclo de Vida en V
Metodología XP
Documento de Desarrollo
Declaración de Requisitos
Especificación de Requisitos de Software – IEEE 830
Requisitos del Sistema – IEEE 1362
Diseño Arquitectónico
Diseño E/R
10
47
48
48
49
49
50
51
51
52
53
56
57
57
59
59
60
60
63
64
64
64
64
65
67
68
68
70
71
71
71
73
74
74
74
75
76
83
83
83
95
100
103
1.10.4
1.10.5
1.10.6
1.10.7
Diseño Detallado
Bitácoras de Codificación
Pruebas
Validación y Aceptación
CAPÍTULO II:
2
2.1
2.1.1
2.1.2
2.1.3
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.3
2.3.1
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.6.1
3.4.6.2
3.4.6.3
3.4.7
3.4.8
3.4.9
3.4.10
3.4.11
3.4.12
3.4.13
INGENIERÍA DE LA SOLUCIÓN
Ingeniería de la Solución
Definición de Requisitos
Definición General de Requisitos
Especificación de Requisitos de Software – IEEE 830
Especificación de Requisitos del Sistema – IEEE 1362
Diseño
Convenciones
Diseño Arquitectónico
Diseño de Datos
Diseño Específico
Desarrollo
Bitácoras de Desarrollo
CAPÍTULO III:
3
3.1
3.2
3.3
3.4
107
107
108
110
112
112
112
114
124
132
132
137
139
158
168
168
REFERENCIA OPERATIVA
Referencia Operativa
Inicio
Objetivos
Integración Social
Sistema de Gestión de Información del Centro Rehabilitación
Física
Validación de Usuario
Administrador
Rehabilitación Física
Nuevo Paciente Rehabilitación Física
Mensaje Rehabilitación Física
Historia Clínica Rehabilitación Física
Médico Enviante Rehabilitación Física
Antecedentes Personales Rehabilitación Física
Tratamiento Rehabilitación Física
Datos Pacientes Rehabilitación Física
Búsqueda Rehabilitación Física
Lista Instituciones Rehabilitación Física
Reportes Rehabilitación Física
Rehabilitación de Lenguaje
11
176
176
177
178
179
179
179
180
181
181
182
182
183
184
185
185
186
187
188
188
189
3.4.14
3.4.15
3.4.16
3.4.16.1
3.4.16.2
3.4.16.3
3.4.17
3.4.18
3.4.19
3.4.20
3.4.21
3.4.22
Nuevo Paciente Rehabilitación de Lenguaje
Mensaje Rehabilitación de Lenguaje
Historia Clínica Rehabilitación de Lenguaje
Médico Enviante Rehabilitación de Lenguaje
Antecedentes Personales Rehabilitación de Lenguaje
Tratamiento Rehabilitación de Lenguaje
Datos Pacientes Rehabilitación de Lenguaje
Búsqueda Rehabilitación de Lenguaje
Lista Instituciones Rehabilitación de Lenguaje
Reportes Rehabilitación de Lenguaje
CAPÍTULO IV:
4
4.1
4.2
4.2.1
4.2.2
4.2.3
4.3
4.3.1
4.3.2
4.3.3
4.4
190
190
191
191
192
193
194
195
195
196
197
197
ANÁLISIS PROSPECTIVO DE IMPACTOS
Análisis Prospectivo de Impactos
Introducción
Análisis de Impactos y Posibles Indicadores
Impacto Social
Impacto Ético
Impacto Tecnológico
Evaluación de Impactos
Impacto Social
Impacto Ético
Impacto Tecnológico
Impacto Global del Proyecto
199
199
200
200
200
200
200
200
201
202
203
CONCLUSIONES
204
RECOMENDACIONES
205
FUENTES DE INFORMACIÓN
206
GLOSARIO
211
ANEXOS
213
Anexo 1: Fotografías den Centro de Rehabilitación Física
214
Anexo 2: Fichas del Centro de Rehabilitación Física
218
Anexo 3: Paper IEEE
223
12
ÍNDICE DE GRÁFICOS
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
1.20
2.1
2.2
2.3
2.4
2.5
2.6
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
Mecanismo de Organización y Funcionamiento
Organismos y Niveles que Integran el Sistema
Formulario de Rehabilitación Física en el Ecuador
Formulario de Terapia Física
Formulario de Reportes de Terapia Física
Formulario de Terapia de Lenguaje
Formulario de Reportes de Terapia de Lenguaje
Organigrama del Centro de Rehabilitación Física
Diagrama del Tratamiento de Pacientes del Centro de
Diagrama de Información del Centro de Rehabilitación Física
Los DBMS
Comparación de Base de Datos
Actor
Casos de Usos
Comunicación
Generalización
Inclusión
Extensión
Ciclo de Vida
Modelo Entidad – Relación
Diagrama Arquitectónico SGICRF
Diagrama de Emplazamiento SGICRF
Diagrama de Actividades SGICRF
Diagrama de Paquetes SGICRF
Modelo Conceptual BDD SGICRF
Modelo Físico BDD SGICRF
Inicio
Objetivos
Integración social
Validar usuario
Administrador
Rehabilitación física
Nuevo Paciente Rehabilitación Física
Medico Enviante Rehabilitación Física
Antecedentes Personales Rehabilitación Física
Tratamientos Rehabilitación Física
Datos Pacientes Rehabilitación Física
13
31
31
36
38
39
40
41
42
43
45
59
63
71
71
72
72
72
73
75
104
137
137
138
139
140
141
176
177
178
179
179
180
181
181
182
182
183
184
185
185
186
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.2 9
3.30
3.31
Búsquedas Rehabilitación Física
Lista Instituciones Rehabilitación Física
Reportes Rehabilitación Física
Rehabilitación de Lenguaje
Nuevo Paciente Rehabilitación de Lenguaje
Médico Enviante Rehabilitación de Lenguaje
Antecedentes Personales Rehabilitación de Lenguaje
Tratamiento Rehabilitación de Lenguaje
Datos Pacientes Rehabilitación de Lenguaje
Búsquedas Rehabilitación de Lenguaje
Lista Instituciones Rehabilitación de Lenguaje
Reportes Rehabilitación de Lenguaje
187
188
188
189
190
190
191
191
192
193
194
195
195
196
197
197
ÍNDICE DE TABLAS
1.1
1.2
1.3
1.4
1.5
1.6
1.7
4.1
4.2
4.3
4.4
4.5
Clientes
Eliminación de Datos Repetidos en una Base de Datos
Primera Forma Normal
Eliminación de Dependencias Parciales – Segunda Forma Normal
Eliminación de Datos que no son Claves para la Tercera forma Normal
Tabla de Comandos SQL
Aplicaciones Complejas
Niveles de Impacto
Resultados de Impacto Social
Resultados de Impacto Ético
Resultados de Impacto Tecnológico
Resultados de Impacto Global
14
53
54
54
55
56
61
75
201
202
203
204
205
INTRODUCCIÓN
El presente proyecto propone el desarrollo e implementación de un sistema informático
que permita de una manera fácil el almacenamiento de datos y la identificación de cada
una de las Historias Clínicas.
La implementación del sistema informático en el Centro de Rehabilitación Física de
Antonio Ante permitirá obtener mayor eficiencia en el control de los archivos, mayor
rapidez al disponer de la información de una forma ágil, mejorando así la atención a los
pacientes y a su vez estar a la vanguardia tecnológica.
Para la realización del presente proyecto se hizo un previo análisis, como el estudio del
entorno de desarrollo, herramientas y tecnología tanto de hardware como software el
cual sirvió para el desarrollo del sistema informático con la única finalidad de presentar un
producto que satisfaga las necesidades de la institución.
Los funcionarios del Centro de Rehabilitación Física de Antonio Ante ayudaron a
cuantificar los problemas que abarca el Centro y que la solución propuesta y desarrollada
es de vital importancia.
Se llegó a determinar los principales impactos que el presente proyecto provoca en las
distintas áreas o ámbitos como en lo social, ético y tecnológico determinando así la
importancia de su desarrollo.
Con la sistematización del Centro de Rehabilitación Física mejorará el manejo de la
información ya que se tendrá un registro de los pacientes con todos los datos necesarios
para un control estadístico eficiente.
CAPÍTULO
CAPÍTULO I
15
FUNDAMENTACIÓN TEÓRICA
1.1 CENTRO DE REHABILITACIÓN FÍSICA DE ANTONIO ANTE
1.1.1 RESEÑA HISTÓRICA
El general Gil Alberto Enríquez Gallo, Jefe Supremo de la República del Ecuador, fue quien
expidió el decreto de creación del cantón Antonio Ante, el 12 febrero de 1938, en
homenaje al prócer de la independencia Dr. Ignacio Antonio Ante, nacido en la hacienda
Alobuela, jurisdicción de la entonces parroquia Atuntaqui, provincia de Imbabura. El
Cantón se conformó con las 5 parroquias, según el decreto: urbanas Atuntaqui y su
cabecera, Andrade Marín; rurales San Roque, San Francisco de Natabuela y San José de
Chaltura.
Antonio Ante se encuentra localizado a 12 km al sur oeste de Ibarra, a 105 km al noroeste
de Quito y al noroccidente de Imbabura.
SITUACIÓN ASTRONÓMICA: El cantón se encuentra entre 78° 05' a los 78" 14' longitud
oeste, con referencia al Meridiano de Greenwich y entre los 00° 16' a los 00° 24' latitud
norte, con el referente Línea Equinoccial.
EXTENSIÓN: 7.673.10 equivalente a 83.10 km2.
LÍMITES: Se establecieron así, al norte la quebrada de San Antonio, que le separa del
cantón Ibarra, al sur la Quebrada Oscura que colinda con el cantón Otavalo, al este la
cima del cerro Imbabura y al oeste el río Ambi que marca división natural con el cantón
Cotacachi.1
El Centro de Rehabilitación Física de Antonio Ante inicia con el proyecto del Lic. Fred
Posso Yépez del Departamento de Desarrollo Económico Productivo de la Alcaldía del Eco.
Richard Calderón Saltos, juntamente con la Fundación de Discapacidades “Caminemos
Juntos” a cargo del Sr. Patricio Gabeó, fundada el 9 de junio de 2003.
Con una visión de ser un Centro líder a nivel provincial en Rehabilitación Integral con
tecnología moderna, para todas las edades y condiciones del individuo discapacitado.
Desarrolla servicios innovadores, con equipo humano profesional altamente capacitado,
motivado y comprometido con la población antena.
El 1 de septiembre de 2006 se contrató a la profesional Lic. Janet Andrade, Fisioterapeuta
graduada en la Universidad Central del Ecuador en Tecnología Médica y licenciada en
1
JIMENEZ, Gustavo. “Monografía Contemporánea del Cantón Antonio Ante”
16
Terapia Física. Durante el tiempo de dos meses se implementa el Centro hasta el 31 de
octubre del mismo año.
Se da funcionamiento por primera vez en el edificio del ex-molino donde fue adecuada
una sala para hombres y mujeres y tres salas para los siguientes servicios: Electroterapia,
Mecanoterapia y Crioterapia, además de las terapias se ofreció Medicina Preventiva,
Curativa.
El centro de Rehabilitación Física, siendo por el momento el único Centro en Imbabura
que cuenta con Terapia Deportiva, Cardiaca y Respiratoria.
Desde noviembre de 2007 el Centro de Rehabilitación Física pasó al edificio del Patronato
Municipal donde cuenta con los accesos necesarios para el paciente como son rampas,
ascensores, etc. Ubicado en las calles Río Amazonas y Pérez Muñoz.
En el año 2010 el Centro de Rehabilitación de Física pasa a cargo de la Lic. Pilar Rueda,
graduada en la especialidad de Fisioterapia, quién es la persona encargada del buen
funcionamiento del Centro.
Actualmente el centro brinda los servicios de terapia física y terapia de lenguaje con sus
respectivos tratamientos; atienden 30 pacientes diarios, su horario de atención es de
lunes a viernes de 8:00 a.m. a 4:00 p.m.
Las instalaciones del Centro de Rehabilitación Física se pueden observar en el Anexo 1.
Las fichas del Centro del Rehabilitación son de acuerdo a la terapia que necesita el
paciente:
-
Ficha de Rehabilitación Física
Ficha de Rehabilitación de Lenguaje
Ficha de Reportes de terapia física
Ficha de Reportes de terapia de lenguaje2
Para acceder a estos servicios que brinda el Centro de Rehabilitación:
-
2
3
El paciente debe tener como requisito previo un pedido del especialista.
Solicitar su historia clínica en caso de tenerlo, caso contrario se debe abrir, en las
cuales ingresan sus datos personales.
Luego de esto ingresamos a la ficha de la Historia Clínica del paciente.
Por último tenemos la ficha de Reportes donde llenamos la información de las
historias clínicas o los nombres y apellidos de los pacientes, para tener una
referencia de cuáles son los servicios más requeridos por la sociedad.3
RUEDA, Pilar. “Centro de Rehabilitación Física de Antonio Ante”.
17
En enero del presente año mediante un Convenio Institucional entre el Municipio y la Casa
de Salud Hospitalaria de Antonio, acuerdan que el Municipio donará todo el equipamiento
del Centro de Rehabilitación Física y el Hospital deberá encargarse de los profesionales, y
así poder brindar mejor atención a la comunidad anteña y al norte del país con un servicio
gratuito. 4
1.2 LA MEDICINA FÍSICA Y REHABILITACIÓN
1.2.1 VISIÓN HISTÓRICA
La Palabra Rehabilitación, se aplicó desde muy antiguas épocas en donde había pérdida de
funciones motrices, sensoriales, emocionales, afectivas, sufridas en el individuo como un
ser integral.
La Rehabilitación surgió como especialidad cuando comenzó a aceptarse la importancia de
la Medicina de Rehabilitación y cuyo nacimiento como disciplina científica se relaciona con
el hecho de grandes desgracias humanas originadas por el hombre.
Se inició con carácter de Especialidad Concreta dentro de la Medicina General en 1940
cuando el Dr. Howard A. Rusk organizó el primer servicio de Rehabilitación en Bellevue
Hospital de Nueva York.
En 1958 plantea los siguientes Objetivos:
-
Primero: Eliminar en todo lo posible la invalidez física.
Segundo: Reducir o aliviar la invalidez hasta el grado máximo.
Tercero: Re entrenar a la persona con invalidez física residual a vivir y trabajar en el
límite mínimo de invalidez.
Durante la historia, las personas con discapacidad han sufrido la aversión de la sociedad,
han sido apartadas y marginadas de la actividad social y aún en nuestros días son
relegados y se les niega la posibilidad de practicar en condiciones de igualdad de
oportunidades con los demás seres humanos.
-
LA INVALIDEZ EN LA EDAD ANTIGUA DEL DESPRECIO AL ABANDONO Y LA
MUERTE
A través de los siglos se han producido dos comportamientos básicos y diferentes en las
actitudes sociales hacia las personas con discapacidad (Velázquez 1986):
4
MORAN, Angelita. “Casa de Salud Hospitalaria de Antonio Ante”.
18
•
•
De repulsa frente a un fenómeno extraño y amenazador.
De protección, por considerar que eran incapaces de valerse por sí mismas.
En la India los niños “deformes” eran arrojados al río Ganges y en un libro de la longevidad
ya escriben entre las prescripciones higiénicas, lo ejercicios físicos, los masajes y los baños.
En la China, los tratamientos terapéuticos de acupuntura incluían masajes a fin de aliviar
la introducción de agujas de terapia y como parte de la misma.
Entre los hebreos la consideración hacia los “inválidos” ya tenía otra forma de trato, no
eran marginados en su totalidad, porque participaban en actos o cosas sagradas de la
época.
En el Pentateuco o Thora se describe baño de sol y vendajes ortopédicos como formas de
tratar los defectos físicos.
En Atenas en el siglo V se fundaron centros para atender a personas “desvalidas”, con
medíos físico como los baños en agua (inicio de la hidroterapia podría ser).
En Esparta es conocido el proceder de los espartanos con todo lo que representase algún
tipo de deformidad o invalidez física o mental en la época de Licurgo, quien por medio de
sus leyes y con el fin de conseguir una raza superior, decretó que se arrojase por el monte
Taijeto a los niños que naciesen con alguna deformidad.5
1.2.2 REHABILITACIÓN
Rehabilitación es el conjunto de procedimientos dirigidos a ayudar a una persona a
alcanzar el más completo potencial físico, psicológico, social, vocacional y educacional
compatible con su deficiencia fisiológica o anatómica y limitaciones medios ambientales.
En contraste a la terapéutica médica clásica, la cual enfatiza el diagnóstico y tratamiento
contra un proceso patológico, la rehabilitación produce múltiples intervenciones dirigidas
a ambos: la causa y los efectos secundarios del daño y la enfermedad (Modelo
Biopsicosocial).
La medicina del paciente discapacitado apunta a tres aspectos del proceso mórbido. Un
primer aspecto que se refiere a las secuelas patológicas a nivel de un órgano, como por
ejemplo pérdida de una extremidad o cierto déficit sensorial, es lo que llamamos la
Deficiencia. Un segundo aspecto funcional, la Discapacidad, que es la restricción o
ausencia (secundario a la deficiencia) de la habilidad de una persona para realizar una
tarea o actividad dentro de un rango considerado humanamente normal (discapacidad de
marcha, de vestuario, de traslado, etc.). Un tercer aspecto social, que se refiere a la
pérdida de roles en relación con la discapacidad (por ejemplo el papel laboral).
La meta de los programas de Rehabilitación es obtener el máximo nivel de independencia
de sus pacientes, tomando en cuenta sus capacidades y aspiraciones de vida.
5
http://www.semefir.com.ec/cont_esp/p_nosotros/docs/Historia_Fisiatria.pdf
19
La Fisiatría es la especialidad médica que se ocupa fundamentalmente de la Rehabilitación
de personas con patologías motoras. Para esto trabaja básicamente tres grandes áreas: La
Medicina Física, la Medicina de Rehabilitación y los estudios electros fisiológicos. El
Fisiatra coordina el equipo de rehabilitación, el cual está constituido por múltiples
profesionales que desde cada una de sus especialidades ayuda al paciente a una integral
capacitación, utilizando idealmente el modelo transdisciplinario de atención. Pueden
conformar este equipo entre otros: quinesiólogos, terapeutas ocupacionales,
fonoaudiólogos, psicólogos, asistentes sociales, enfermeras de rehabilitación, auxiliares
entrenados, personal administrativo, médicos especialistas en las patologías de base,
psiquiatra, ortoprotesistas, el paciente, su familia, grupos de autoayuda, etc.
El Fisiatra actúa entre de enfermedades en fase aguda, crónica y secuela, tratando y
evitando complicaciones a nivel del aparato músculo esquelético y visceral,
fundamentalmente aquellos derivados del síndrome de inmovilización y procesos
deformantes músculos esqueléticos.
Los métodos de manejo son los agentes físicos, los métodos de retroalimentación,
infiltraciones, estimulación neuromuscular, ortesis, prótesis, prescripción de ejercicios
terapéuticos, tecnología asistía, farmacoterapia específica, nutrición, otros.
Los grandes problemas en rehabilitación son los cuidados primarios del paciente
discapacitado, la rehabilitación del paciente pediátrico, los adultos y niños con
discapacidades congénitas, la rehabilitación geriátrica, la espasticidad, la inmovilización,
las alteraciones del movimiento, las escaras, la disfunción neurógena vesical e intestinal,
discapacidad y sexualidad, emergencias en rehabilitación, problemas vocacionales.
Los desórdenes específicos más relevantes en rehabilitación son la rehabilitación en
enfermedad cerebro vascular, Post TEC, esclerosis múltiple, lesión medular, pacientes
oncológicos, rehabilitación cardiovascular, dolor crónico, amputados, parálisis cerebral,
dolor lumbar, osteoporosis, artritis, enfermedad vascular periférica, quemados, medicina
del arte y del deporte, desórdenes de trauma acumulativo, rehabilitación de los
reemplazos totales de cadera y rodilla, rehabilitación de mano, etc.6
1.2.3 ORGANIZACIÓN MUNDIAL DE LA SALUD
La Organización Mundial de la Salud, es el organismo de la Organización de las Naciones
Unidas especializado en gestionar políticas de prevención, promoción e intervención en
salud en el mundo. Organizada por iniciativa del Consejo Económico y Social de la ONU
que impulsó la redacción de los primeros estatutos de la OMS. La primera reunión de la
OMS tuvo lugar en Ginebra, en 1948.
6
http://www.angelfire.com/md2/rehabilitacion/
20
Los principales cometidos de la Asamblea Mundial de la Salud son aprobar el programa y
el presupuesto de la OMS para el siguiente bienio y decidir las principales cuestiones
relativas a las políticas sanitarias. Tal y como establece su Constitución, el objetivo de la
OMS es que todos los pueblos del mundo puedan gozar del grado máximo de salud que se
pueda lograr. La Constitución de la OMS define la salud como "un estado de completo
bienestar físico, mental y social", y no solamente como la ausencia de afecciones o
enfermedades.
En 2009, la institución fue galardonada con el Premio Príncipe de Asturias de Cooperación
Internacional
-
ESTRUCTURA
Los Estados miembros de la OMS designan sus delegaciones a la Asamblea Mundial de la
Salud, la cual se reúne generalmente en mayo de cada año, y tiene la capacidad de definir
las políticas financieras de la organización, revisa y aprueba el presupuesto por
programas. La Asamblea elige a 34 miembros, técnicos en el campo de la salud, para un
mandato de tres años, y que forman el Consejo Ejecutivo. Las funciones principales del
Consejo son las de hacer efectivas las decisiones y las políticas de la Asamblea, aconsejarla
y facilitar su trabajo.
La OMS tiene 193 Estados Miembros, incluyendo todos los Estados Miembros de la ONU,
excepto Liechtenstein, y 2 territorios no miembros de la ONU: Niue y las Islas Cook, los
cuales funcionan bajo el estatuto de asociados (con acceso a la información completa pero
con participación y derecho a voto limitados), actualmente, si son aprobados por mayoría
de la asamblea Puerto Rico y Tokelau se convertirán en miembros asociados. Algunas
entidades pueden también tener estatuto de observador, como lo es el Vaticano. Taiwán
se propone como miembro observador, contando con la oposición de China que lo
considera como parte de su territorio.
El trabajo cotidiano de la OMS es realizado por la Secretaría, que está formada por un
personal de 3.500 entre sanitarios, otros expertos y personal de ayuda, trabajando en las
jefaturas, en las seis oficinas regionales, y en los países.
-
OFICINAS REGIONALES
Para ser una agencia especializada de la ONU, las seis oficinas regionales de la OMS tienen
una notable autonomía. Cada oficina regional es dirigida por un director regional. Es raro
que un director regional elegido no sea confirmado. El comité regional de la OMS para
cada región está formado por todos los jefes del servicio de salud de todos los gobiernos
de los países que constituyen la región. Aparte de elegir al director regional, el comité
regional está también a cargo de fijar las pautas para la puesta en práctica de todas las
21
políticas sanitarias y las otras políticas adoptadas por la Asamblea Mundial dentro de su
región. El comité regional también sirve como un comité examinador del progreso de las
acciones de la OMS dentro de la región. El Director Regional es la cabeza de la OMS para
su región particular, y maneja o supervisa al personal sanitario y a los otros expertos, en
las jefaturas regionales y en los centros especializados, también ejerce la autoridad de
supervisión directa, conjuntamente con el Director General de la OMS, de todos los jefes
de las oficinas de los países que componen su región, conocidos como Representantes de
la OMS.
Las seis oficinas regionales son:
•
Oficina Regional para África, con sede en Brazzaville, República de Congo. AFRO
incluye la mayor parte del África sub-sahariana, a excepción de Egipto, Sudán,
Túnez, Libia, Marruecos y Somalia que pertenecen a EMRO.
•
Oficina Regional para Europa, con sede en Copenhague, Dinamarca. Incluye a
todos los países europeos.
•
Oficina Regional para Asia Sur-Oriental, con sede en Nueva Delhi, India. Cubre
todos los países asiáticos no servidos por WPRO y EMRO, incluyendo a Corea del
Norte.
•
Oficina Regional para el Mediterráneo Oriental, con sede en El Cairo, Egipto. EMRO
incluye los países del norte de África, conocidos como el Magreb, más Somalía, que
no se incluyen en AFRO, así como todos los países del Oriente Medio.
•
Oficina Regional para el Pacífico Occidental, con sede en Manila, Filipinas. WPRO
cubre todos los países asiáticos no servidos por SEARO y EMRO, y todos los países
de Oceanía. Incluye a Corea del Sur.
•
Oficina Regional para América, con sede en Washington D.C., Estados Unidos. Es
mejor conocido como la Organización Panamericana de la Salud (OPS) siendo éste
el organismo internacional sanitario más antiguo del mundo.
-
ACTIVIDADES OMS
•
Armonización y codificación: clasificación de todas las enfermedades. La OMS lleva
a cabo la Clasificación Internacional de enfermedades (ICD en inglés, o CIM en
francés) y mantiene al día una lista modelo de los medicamentos esenciales que
los sistemas de salud de todos los países deberían hacer que estuviesen
disponibles a precios abordables para la población general.
22
•
Medidas sanitarias: toma de medidas para detener una epidemia y medidas
sanitarias sobre los viajes internacionales (como la vacunación). La OMS declaró en
1980 que la viruela estaba erradicada, después de dos décadas de esfuerzos contra
ésta. (Es la primera enfermedad de la historia erradicada por el esfuerzo humano).
La OMS esta cerca del éxito en el desarrollo de vacunas contra el paludismo y la
bilharziosa, y tiene por objetivo la erradicación de la poliomielitis en los próximos
años.
•
Asistencia a los Países Menos Avanzados: vacunación contra las grandes
enfermedades infecciosas, aprovisionamiento de agua potable, eliminación de
residuos, protección maternal y erradicación de ciertas enfermedades.
•
Un programa estatal de lucha contra el sida, entre sus objetivos está el acceso a los
tratamientos, investigación, vigilancia epidemiológica, etc. Se denomina Programa
sobre el SIDA (HIV/AIDS Programe)
•
Garantizar el acceso a medicamentos de buena calidad, seguridad y eficacia
mediante el programa de pre-evaluación de medicamentos. La OMS pre-evalúa los
medicamentos de los laboratorios que lo piden para que instituciones como la
UNICEF u otras puedan adquirir estos medicamentos con seguridad cuando se
realizan licitaciones internacionales, en particular para países en vías de desarrollo
que no pueden realizar esas evaluaciones por sus propios medios.
La OMS realiza, además, diversas campañas relacionadas con la salud, como por ejemplo
para el aumento del consumo de frutas y verduras en el mundo, o para reducir el uso del
tabaco.
También se dice que las OMS son de carácter humano.
La OMS define la salud como un estado de completo bienestar físico, mental, y no
solamente como la ausencia de infecciones o enfermedades.7
1.2.4 ORGANIZACIÓN PANAMERICANA DE LA SALUD
La Organización Panamericana de la Salud (OPS) es un organismo internacional de salud
pública con 100 años de experiencia dedicados a mejorar la salud y las condiciones de vida
de los pueblos de América. Goza de reconocimiento internacional como parte del Sistema
de las Naciones Unidas, y actúa como Oficina Regional para América de la Organización
Mundial de la Salud. Dentro del Sistema Interamericano, es el organismo especializado en
salud.
7
http://es.wikipedia.org/wiki/Organizaci%C3%B3n_Mundial_de_la_Salud
23
Las autoridades sanitarias de los Gobiernos Miembros de la OPS fijan las políticas técnicas
y administrativas de la Organización por medio de sus Cuerpos Directivos. Los Gobiernos
Miembros de la OPS son los 35 países de América; Puerto Rico es un Miembro Asociado.
Francia, el Reino de los Países Bajos y el Reino Unido de Gran Bretaña e Irlanda del Norte
son Estados Participantes, y España y Portugal son Estados Observadores.
En sus esfuerzos por mejorar la salud, la OPS orienta sus actividades hacia los grupos más
vulnerables, incluidos las madres y los niños, los trabajadores, los pobres, los ancianos, y
los refugiados y personas desplazadas. Su interés se concentra en los temas relacionados
con la equidad para quienes carecen de recursos para acceder a la atención de salud, y en
un enfoque panamericanista que fomenta el trabajo conjunto de los países sobre asuntos
comunes.
-
MISIÓN
Liderar esfuerzos colaborativos estratégicos entre los Estados Miembros y otros aliados,
para promover la equidad en salud, combatir la enfermedad, mejorar la calidad y
prolongar la duración de la vida de los pueblos de América.
-
VISIÓN
La Oficina Sanitaria Panamericana será el mayor catalizador para asegurar que toda la
población de América goce de una óptima salud y contribuir al bienestar de sus familias y
sus comunidades.
-
VALORES DE LA OPS
•
Equidad: Lucha por la imparcialidad y la justicia mediante la eliminación de las
diferencias que son evitables e innecesarias.
•
Excelencia: Logro de la más alta calidad en lo que hacemos.
•
Solidaridad: Promoción de responsabilidades e intereses compartidos, facilitando
esfuerzos colectivos para alcanzar metas comunes.
•
Respeto: Aceptación de la dignidad y la diversidad de los individuos, grupos y
países.
•
Integridad: Garantía de transparencia, ética y responsabilidad en el desempeño.8
1.2.5 REPRESENTACIÓN DE LA OPS / OMS EN EL ECUADOR
8
http://new.paho.org/ecu/index.php?option=com_content&task=view&id=24&Itemid=122
24
La Representación de la OPS/OMS en el Ecuador fue creada en 1951 y desde entonces
coopera técnicamente, en estrecha coordinación con el Ministerio de Salud, con otras
instituciones del sector de la salud y afines en los sectores públicos y privados.
La cooperación tiene como modalidad de trabajo los siguientes proyectos técnicos, que
trabajan con un enfoque transversal de equidad de género e interculturalidad,
comunicación social y preparativa frente a desastres9.
Representante de la OPS/OMS en Ecuador: Dra. Celia Riera.
Proyectos técnicos:
-
Comunicación social
Desarrollo de recursos humanos para la salud
Desarrollo sostenible y salud ambiental
Inmunizaciones
Oficina subregional para América del Sur del área de preparativos para situaciones
de emergencia y socorro en casos de desastre
Políticas, sistemas y servicios de salud
Preparativos frente a emergencias o desastres.
Programa regional de salud de los pueblos indígenas de América
Proyectos regionales (descentralizados en Ecuador)
Salud familiar y comunitaria
Tecnología y prestación de servicios de salud
Vigilancia sanitaria y atención de las enfermedades
1.2.6 SOCIEDAD ECUATORIANA DE MEDICINA FÍSICA Y REHABILITACIÓN
Los que están en esta Disciplina requieren de una mentalidad eminentemente práctica e
intuitiva. Los Paradigmas de la Rehabilitación Tradicional, basados tan sólo en la
consecución de mejoras de la función física han sido superados, por los que buscan el
logro de la independencia, la autonomía personal y una mejor calidad de vida de las
personas.
Los Fisiatras actúan en todas las fases de la Medicina Clásica: Promoción y Fomento de la
Salud, Prevención de enfermedades, Diagnóstico y Tratamiento así como en la
Rehabilitación Integral.
La Medicina Física y Rehabilitación (Fisiatría) se extiende más allá del diagnóstico y de la
simple técnica terapéutica, no se detiene en el puramente tratamiento tangible, si no que
estudia el inmenso campo de la investigación científica de las patologías.
9
http://new.paho.org/ecu/index.php?option=com_content&task=view&id=24&Itemid=122
25
-
MISIÓN
“Somos una sociedad científica, que contribuye al desarrollo sanitario del país, mejorando
la calidad de vida y los comportamientos saludables, mediante propuestas especificas,
viables y sustentables. Que mantiene a sus afiliados en un nivel académico y profesional
elevado, desarrolla programas y proyectos a favor de los sectores vulnerables con
habilidades diferentes”.
-
VISIÓN
“Seremos una SOCIEDAD reconocida por todos los estamentos gubernamentales o no del
país, lideraremos el CONADES con planificación estratégica y alternativas para la
integración e inclusión de las diversas discapacidades. Desarrollaremos ciencia y
tecnología para mejorar la calidad de vida y la equiparación de oportunidades con
equidad.”10
1.2.7 MINISTERIO DE SALUD PÚBLICA
-
MISIÓN
La salud, definida como un instrumento para el mejoramiento continuo del bienestar
colectivo, implica su continua revisión y actualización de sus instrumentos; así, el proceso
organizativo, adaptado a las condiciones siempre cambiantes de la sociedad, sus
organizaciones locales, provinciales y cantonales, han registrado cambios durante los
últimos cinco años y requieren ser modificados. Definidos los nuevos roles y competencias
del Ministerio de Salud por niveles, impone su necesaria actualización de la relación entre
la organización de las Áreas de Salud con la división cantonal del país, bajo un esquema
que reconozca la diversidad geográfica política y relacione las estructuras técnicas
administrativas y red de servicios disponibles al nivel local, adaptados a los nuevos
procesos de modernización, desconcentración y descentralización del Estado.
-
VISIÓN
Ejercer la Rectoría del Sistema Nacional de Salud a fin de garantizar el derecho a la salud
del pueblo ecuatoriano, por medio de la promoción y protección de la salud, de la
seguridad alimentaria, de la salud ambiental y del acceso permanente e interrumpido a
servicios de salud, conforme a los principios de equidad, universalidad, solidaridad,
calidad y eficiencia. Visión Para el año 2020 el Ministerio de Salud Pública del Ecuador,
ejerce la Rectoría del sistema Nacional de Salud, modelo referencial en Latinoamérica, que
10
http://www.semefir.com.ec/cont_esp/p_index_esp.php
26
garantiza la salud integral de la población y el acceso universal a una red de servicios con
la participación coordinada de Organizaciones públicas, privadas y de la comunidad.
-
LINEAMIENTOS ESTRATÉGICOS
•
•
Protección Social en Salud
•
•
•
Modelos de Atención y
Gestión
•
•
•
•
•
Fortalecimiento de la
Rectoría de la Autoridad
Sanitaria
•
•
•
•
•
Desarrollo del Sistema
Nacional de Salud
•
•
•
Extensión de la protección social y aseguramiento
universal.
Planificación y formulación participativa de planes,
programas y proyectos.
Provisión de servicios en red pública con gestión
participativa.
Garantía de Calidad en la prestación de servicios.
Desarrollo del modelo de atención integral e
integrada con enfoque comunitario, familiar y
pluricultural, basado en Atención Primaria de salud.
Desarrollo del modelo de gestión.
Formulación de políticas de salud.
Conducción y regulación sectorial.
Garantizar la calidad del gasto.
Fortalecimiento de la estructura organizacional del
MSP.
Vigilancia en salud Pública.
Gestión integrada de los recursos de cooperación
nacional e internacional.
Desarrollo del talento humano y gestión de recursos
humanos.
Investigación, ciencia, y desarrollo tecnológico en
salud.
Desarrollo del Sistema Nacional Integrado de
Información.
Desconcentración y descentralización consensuadas.
Participación social y comunitaria en el desarrollo del
Sistema.
Organización de la red de servicios del sector público
27
•
•
•
Posicionamiento Político y
Financiamiento
•
•
-
Declarar a la Salud como estratégica para el
desarrollo nacional.
Lograra que la salud se incorpore a la agenda pública
nacional como prioridad en las acciones del Estado,
del gobierno y de la sociedad.
Asegurar el financiamiento de los servicios de la
salud para las personas y familias sin capacidad de
pago.
Garantizar un modelo de gestión con rectoría y
rendición de cuentas social e institucional.
Garantía de financiamiento para la salud oportuna y
adecuada.
PROGRAMAS E INTERVENCIONES PRIORITARIAS
•
•
•
•
•
•
•
•
•
•
•
•
Extensión de cobertura de la Protección Social en Salud.
Fortalecimiento de la Red de Servicios de Salud.
Gestión oportuna de medicamentos e insumos básicos.
Promoción de la Salud.
Prevención y control de enfermedades trasmisibles y no transmisibles.
Control de enfermedades prevenibles por vacuna.
Disminución de la mortalidad de madres y niños.
Vigilancia y control de riesgos ambientales.
Investigación y desarrollo tecnológico.
Construcción de propuestas de atención integral e integrada de acuerdo
con el ciclo de vida y diversidad.
Prevención, mitigación de desastres.
Seguridad alimentaria y nutricional.11
1.2.8 CONSEJO NACIONAL DE SALUD
El Consejo Nacional de Salud desde su creación en 1980, ha promovido la organización del
Sistema Nacional de Salud, lo cual en la Asamblea Constituyente de 1998 fue establecido
como un mandato expreso para el estado ecuatoriano.
11
http://www.msp.gov.ec/index.php?option=com_content&task=blogcategory&id=17&Itemid=94
28
La Ley Orgánica del Sistema Nacional de Salud aprobada en septiembre 2002 y el
Reglamento a la Ley Orgánica del Sistema Nacional de Salud, fueron el producto del
esfuerzo político, técnico y social de las diferentes instituciones y actores del sector salud.
El Consejo Nacional de Salud, como entidad pública con personería jurídica y autonomía
administrativa y financiera, en el marco de la LOSNS ha desarrollado su Planificación
Estratégica y ha establecido la Organización Institucional por Procesos como eje conductor
de su trabajo, aprobado por la Secretaría Nacional Técnica de Recursos Humanos y
Remuneraciones del Sector Público SENRES, publicado en Registro Oficial Nº 181 del 5 de
Enero del 2006.12
-
MISIÓN
En el año 2010 el Consejo Nacional de Salud se consolidará como una entidad del Sector
Público con autonomía administrativa y financiera, de gestión eficiente; cuyos acuerdos y
resoluciones, resultado de la concertación sectorial y participación social serán aplicado
en todo el sector salud en el proceso de construcción, fortalecimiento y sostenibilidad del
Sistema Nacional de Salud.
La Visión del CONASA está comprometida con el cumplimiento de su Misión.
-
VISIÓN
El Consejo Nacional de Salud es una entidad cuyo propósito fundamental es impulsar la
construcción del Sistema Nacional de Salud; concierta la Política Nacional de Salud;
participa con el Ministerio de Salud Pública en la formulación del Plan Integral de Salud,
coordina con sus integrantes su implementación, promueve la participación social y el
ejercicio de los derechos en salud.13
-
PRESENTACIÓN INSTITUCIONAL
El Consejo Nacional de Salud CONASA es el organismo de representación de los
integrantes del Sistema Nacional de Salud, conformado por entidades públicas, privadas,
autónomas y comunitarias del sector salud, que se articulan funcionalmente sobre la base
de principios, políticas, objetivos y normas comunes.
La Ley publicada en Registro Oficial No. 670 del 25 de septiembre de 2002, crea el Consejo
Nacional de Salud como entidad pública, con personería jurídica propia y autonomía
administrativa y financiera.
12
http://www.conasa.gov.ec/codigo/quienes/quienes.html
13
http://www.conasa.gov.ec/codigo/quienes/valores.html
29
Su Estatuto Orgánico por Procesos fue aprobado por la Secretaria Nacional Técnica de
Desarrollo de Recursos Humanos y Remuneraciones del Sector Público y publicado en
Registro Oficial No. 181 del 5 de Enero del 2006.
-
FUNCIONES DE LA CONASA
•
Apoyar al Ministerio de Salud Pública en el ejercicio de las funciones del Sistema
Nacional de Salud: coordinación, provisión de servicios de salud, financiamiento y
aseguramiento.
•
Promover la participación y control social y el ejercicio de los derechos en salud.
•
Concertar la aplicación de normas y políticas de salud entre los integrantes del
Sistema, mediante proceso de consenso y diálogo entre instituciones,
organizaciones y gremios del sector salud.
-
PROCESO DE APROBACIÓN DE PROPUESTAS EN EL SECTOR DE SALUD
Los delegados institucionales son oficialmente nombrados por la autoridad de cada
entidad y el carácter de su representación es técnico, las actividades cumplidas se
registran formalmente en actas de cada sesión y se orientan sobre la base de planificación
estratégica institucional. El funcionamiento técnico administrativo del CONASA se financia
con el aporte del Presupuesto General del Estado y del Instituto Ecuatoriano de Seguridad
Social y cumple con las regulaciones establecidas para la administración pública.
-
MECANISMOS DE ORGANIZACIÓN Y FUNCIONAMIENTO
El diálogo y la concertación se realizan en dos instancias: el nivel directivo que lo integran
todas las autoridades institucionales y representantes gremiales; un nivel técnico,
integrado por comisiones en las cuales participan los delegados de cada una de las
instituciones del SNS. El mecanismo de trabajo son reuniones periódicas para elaborar y
discutir propuestas en grupos de trabajo denominados Comisiones Técnicas.
30
Figura 1.1: Mecanismo de Organización y Funcionamiento
Fuente: http://www.conasa.gov.ec/codigo/quienes/presentacion.html
Los delegados institucionales son oficialmente nombrados por la autoridad de cada
entidad y el carácter de su representación es técnico, las actividades cumplidas se
registran formalmente en actas de cada sesión. Las actividades de las comisiones se
orientan sobre la base de planificación estratégica institucional.
El funcionamiento técnico administrativo se financia con el aporte del Ministerio de Salud
Pública y el Instituto Ecuatoriano de Seguridad Social, recursos que son manejados a
través del Presupuesto General del Estado y cumplen con las regulaciones pertinentes
para la administración pública.14
Figura 1.2: Organismos y Niveles que Integran el Sistema
Fuente: http://www.conasa.gov.ec/codigo/quienes/presentacion.html
14
http://www.conasa.gov.ec/codigo/quienes/presentacion.html
31
1.2.9 CONFERENCIA NACIONAL SOBRE DESARROLLO SOCIAL
CONADES surge en 1996 por iniciativa de una docena de redes de ONGDs y CEAS, la
comisión Episcopal de Acción Social, con el interés de contribuir a formular una nueva
visión de país y caminos de desarrollo humano, emanadas de procesos de diálogo y la
concentración y orientado por valores de justicia, equidad, verdad, democracia y
participación.
Entre 1996 y la actualidad hemos desarrollado año a año las conferencias Nacionales y
conferencias regionales de desarrollo social (COREDES) y múltiples seminarios y talleres
temáticos. Estos eventos han ido comprometiendo en su organización a una red cada vez
más amplia y variada de organizaciones y movimientos ciudadanos en todo el país en
diálogos con los diversos actores del desarrollo y los diversos enfoques y propuestas sobre
como alcanzado, como lo revela el hecho de que el grupo de iniciativa de CONADES
integra a la fecha más de un centenar de redes, organizaciones y movimientos ciudadanos
de todo el país.
Junto al proceso de descentralización del país y al proceso de desarrollo de CONADES, las
regiones también han sido creado sus espacios de reflexión, denominadas Conferencias
Regionales sobre Desarrollo Social – COREDES o encuentros Regionales. Hoy en día varias
regionales debaten sus problemáticas, definen sus planes desarrollo y preparan su
participación a los eventos nacionales. En el proceso hemos abordado temas de urgente
prioridad en el país como:
-
La elaboración de una visión de país de largo plazo en la cual enmarcamos
nuestra acción conjunta y que siempre está abierta a las críticas y nuevos
desarrollos (I CONADES 1996).
-
Las estrategias para la lucha contra la pobreza y el impacto de fenómenos
naturales como el FEN y otros desastres sufridos por el país (II CANADES 1997).
-
La descentralización y el desarrollo local (III CONADES 1998).
-
Las estrategias de desarrollo para el mediano plazo en el contexto de los
cambios que vive el mundo al entrar al nuevo milenio (IV CONADES 1999).
-
La articulación de los movimientos ciudadanos orientados a producir una
refundación ética, social, política y económica del Perú (V CONADES 2000).
-
La búsqueda de estrategias ciudadanas para la democracia, la descentralización
y el desarrollo (VI CONADES 2001).
-
Ante los procesos de descentralización en curso, la CONADES EXTRAORDINARIA
2001 fue espacio para trabajar iniciativas en materia constitucional, de
descentralización y aportes al foro de acuerdo nacional.
32
-
-
El contexto de inicio de las gestiones de los gobiernos regionales y cambio en
las gestiones municipales (VII CONADES 2002).
-
Un Marco Macroeconómico Multianual alternativo al trabajado por el MEF. En
el que se permitiría pone la economía al servicio de las personas. (VII CONADES
2003, IX CONADES 2004, X CONADES 2005).
-
La necesidad de reorientar la acción del Estado y la dinámica económica para
ponerlas en servicio de las personas, asumiendo un compromiso de las
organizaciones y movimientos ciudadanos (XI CONADES 2006).
-
Desarrollo territorial con Ecuador y Democracia (XII CONADES 2007).
VISIÓN
•
ORIENTACIÓN ESTRATÉGICA
El grupo de iniciativa de CONADES opera con una visión de largo plazo que ha sido
construida de manera colaborativa y en diálogo con diversos actores ya sea en el marco
de los eventos nacionales así como de los eventos regionales y temáticos.
La visión común en que se basa nuestro trabajo:
Es ver al Perú convertido en un país democrático, descentralizado, equitativo, que he
mejorado, con el esfuerzo concurrente y solidario de sus integrantes, el nivel de vida de
toda su población y en todo su territorio, sin discriminaciones ni separaciones de ningún
tipo. Una sociedad en armonía con su entorno natural e inmerso en un proceso de
desarrollo sostenible. En un mundo de paz.
-
ÁMBITOS DE INTERVENCIÓN
El Grupo de Iniciativa de CONADES, en el marco de las prioridades definidas en el plan
estratégico, viene impulsando y trabajando de manera muy activa en diversos espacios de
diálogo y debate sobre el quehacer nacional.15
•
•
•
15
Participación en la MCLCP.
Participación en el Acuerdo Nacional.
Campaña por los Acuerdos de gobernabilidades regionales y locales.
http://www.conades.org.pe/index.php?pg=2
33
1.2.10 SISTEMA NACIONAL DE SALUD
Conjunto de entidades públicas, privadas, autónomas y comunitarias que se articulan
funcionalmente sobre la base de principios, políticas, objetivos y normas comunes.
-
OBJETIVOS DEL SNS
•
•
•
•
•
•
-
PRINCIPIOS DEL SNS
•
•
•
•
•
•
•
•
•
-
Cobertura universal / acceso equitativo
Descentralización / desconcentración
Protección integral
Coordinación sectorial
Participación ciudadana
Entornos saludables
Equidad
Calidad
Eficiencia
Participación
Pluralidad
Solidaridad
Universalidad
Descentralización
Autonomía
INTEGRANTES DEL SNS
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Ministerio de Salud Pública y entidades
Ministerios que participan en el campo de la salud
IESS, ISSFA, ISSPOL
Organizaciones de la Fuerza Pública
AFEME
Junta de Beneficencia de Guayaquil
SOLCA
Cruz Roja Ecuatoriana
CONCOPE, AME, CONAJUPARE
Entidades de salud con fines de lucro
Entidades de salud sin fines de lucro
Servicios comunitarios de salud
Centros de desarrollo de ciencia y tecnología en salud
Organizaciones comunitarias que actúen en promoción y defensa de la salud
34
•
•
•
Organizaciones que trabajan en salud ambiental
Organizaciones gremiales de profesionales y trabajadores de la salud
Otros organismos de carácter público, del régimen dependiente o autónomo y
de carácter privado que actúen en el campo de la salud
-
FUNCIONES DEL SNS
•
Función de coordinación: Coordina el relacionamiento entre las demás funciones y
entre los integrantes del sistema. Competencia del MSP como autoridad sanitaria
nacional apoyado por los Consejos de Salud.
•
Función de provisión de Servicios de Salud: Es plural y se realiza con la
participación coordinada de las Instituciones prestadoras que operarán en redes
que aseguren la calidad, continuidad y complementariedad de la atención.
•
Función de aseguramiento: Garantía de acceso universal y equitativo de la
población al plan integral de salud.
•
Función de financiamiento: Garantía de la disponibilidad y sostenibilidad de los
recursos financieros.
-
OFERTA DE SERVICIOS DE SALUD
El MSP posee la red de servicios más importante del país, en cuanto a número,
complejidad y recursos humanos: la capacidad instalada es de 1863 unidades
operativas: 169 Área de Salud (85 HB, 152 CS, 1127 SCS, 434 PS, 21 UM, 3 UF); 42
hospitales (generales, especializados y de especialidades).
El desafío fundamental que enfrenta el Sistema Nacional de Salud del Ecuador, es el de
garantizar a todos los ciudadanos la Protección Social Universal en materia de salud,
eliminando o reduciendo al máximo las desigualdades evitables en la cobertura, el
acceso y la utilización de servicios de calidad.16
16
http://www.paho.org/spanish/DPM/SHD/HP/ha-nha-satelit2-pres9-naranjo.pdf
35
1.2.11 FORMULARIOS DE REHABILITACIÓN FÍSICA EN EL ECUADOR
HOSPITAL “SAN VICENTE DE PAUL”
TERAPIA FISICA
SERVICIO DE REHABILITACION
Nº DE TARJETA
APELLIDOS Y NOMBRES
EDAD
Nº H. CLÍNICA
Nº DE TARJETA
TARJETA INDIVIDUAL DE TRATAMIENTO
Medico
Solicitante
Diagnostico
Tratamiento
Indicado
Fisioterapi
a
Zona de
Tratamiento
APELLIDOS Y NOMBRES
EDAD
Nº H. CLÍNICA
TARJETA INDIVIDUAL DE TRATAMIENTO
Número
Medico Solicitante Diagnostico
36
Tratamiento
Indicado
Fisioterapi
a
Zona de
Tratamiento
Número
DIAS ENERO FEBRERO MARZO ABRIL MAYO JUNIO JULIO AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE
DIAS ENERO FEBRERO MARZO ABRIL MAYO JUNIO JULIO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
OBSERVACIONES
OBSERVACIONES
17
Figura 1.3: Formulario de Rehabilitación Física en el Ecuador
Fuente: Casa de Salud Hospitalaria de Antonio Ante
17
MORAN, Angelita. “Directora de la Casa de Salud Hospitalaria de Antonio Ante”.
37
AGOSTO SEPTIEMBRE OCTUBRE NOVIEMBRE DICIEMBRE
1.2.12 FORMULARIO DE REHABILITACIÓN FÍSICA DE ANTONIO ANTE
-
FORMULARIO DE TERAPIA FÍSICA
1. DATOS PERSONALES
APELLIDOS
NOMBRES
DIRECCION
OCUPACION
EDAD
TELEFONO
CEDULA
HISTORIA CLINICA
FECHA CONSULTA
MEDICO QUE REFIERE
2. DIAGNOSTICO
3. ANTECEDENTES PERSONALES
INSTITUCION
DIABETES
H.T.A
CARDIOPATÍA
IESS
PUBLICA
PRIVADA
4. TRATAMIENTO
C.Q.C
C.F
Electroestimulación
Ultrasonido
Masaje
Láser
Terapia Respiratoria
Ejercicio Terapéutico
Magnetoterapia
5. OBSERVACIONES
6. EVOLUCIONES
Nº Sesiones
Fisioterapia
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 Termina Abandona
18
Figura 1.4: Formulario de Terapia Física
Fuente: Centro de Rehabilitación Física de Antonio Ante
18
38
-
FORMULARIO DE REPORTE DE TERAPIA FÍSICA
SISTEMA COMÚN DE INFORMACIÓN EN SALUD - REGISTRO DIARIO DE ATENCIONES
DATOS ESTABLECIMIENTO
HOSPITAL DE ATUNTAQUIN
Nº 2
ATUNTAQUI
ANTONIO ANTE
IMBABURA
MES REGISTRADO
ESPECIALIDAD
PROFESIONAL FIRMA
IESS
PRIVADO
PUBLICO
MASAJE
ATENCION
EJECICIO TERAPEUTICO
COMPRESA FRIAS
COMPRESAS CALIENTES
LASER
ULTRASONIDO
DIAGNOSTICO O SÍNDRONE
ELECTROESTIMULACION
65 AÑOS Y MAS
50-64 AÑOS
36-49 AÑOS
20-35 AÑOS
15-19 AÑOS
10-14 AÑOS
1 -4 AÑOS
1 - 11 MESES
TRATAMIENTO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
19
Figura 1.5: Formulario de Reportes de Terapia Física
19
DÍA
AÑO
GRUPO DE EDAD
MENOR DE UN MES
MUJER
NOMBRE Y APELLIDO
HOMBRE
SEXO
Nº
5 - 9 AÑOS
NOMBRE UNIDAD
AREA DE SALUD
PARROQUIA
CANTÓN
PROVINCIA
DATOS PERSONAL
39
-
FORMULARIO DE TERAPIA DE LENGUAJE
1.DATOS PERSONALES
APELLIDOS
FECHA NACIMIENTO
NOMBRES
CEDULA
EDAD
TELEFONO
ESCOLARIDAD
GRADO
DIRECCION
2. DATOS DEL REPRESENTANTE LEGAL
APELLIDOS Y NOMBRES
HISTORIA CLINICA
FECHA CONSULTA
INSTITUCION
RELACION CON EL PACIENTE
IESS
PUBLICA PRIVADA
3. DIAGNOSTICO MEDICO REFERENTE
PRENATALES
NATALES
POSTNATALES
5. DIAGNOSTICO LOGOPEDICO
Retraso de Lenguaje
Retraso de Habla
Afasia
Disfonia
Dislexia
Apraxia
Disglosia
Disfemia
Dislalia
Desarrollo Gramatical
Incremento de Vocabulario
Desarrollo Etimológico
Estimulación Temprana
6. TRATAMIENTO
Desarrollo receptivo
Descripción Auditiva
20
Figura 1.6: Formulario de Terapia de Lenguaje
20
GOVEO, Mirian. “Centro de Rehabilitación Física de Antonio Ante”.
40
-
FORMULARIO DE REPORTE DE TERAPIA DE LENGUAJE
CONSOLIDACION DE PRODCCION DIARIA POR PROFESIONAL
DATOS DE ESTABLECIMIENTO
Nº 2
ATUNTAQUI
ANTONIO ANTE
IMBABURA
MES REGISTRADO
ESPECIALIDAD
IESS
PRIVADO
PUBLICO
ATENCION
ESTIMULACION TEMPRANA
DISCRIMINACION AUDITIVA
DESARROLLO ITNOLOGICO
INCREMENTO DE VOCABULARIO
DESARROLLO GRAMATICAL
DESARROLLO RECEPTIVO
TRATAMIENTO
DISLEXIA
DISLALIA
DISFONIA
DISFEMIA
DISGLOSIA
APRAXIA
AFASIA
RETRASO DEL HABLA
DIAGNOSTICO LOGOPEDICO
RETRASO DEL LENGUAJE
DEF. FISICO
DEF. AMBIENTALES
DEF. EVOLUTIVOS
DEF. SENSORIALES
DEF. NEUROLOGICA
65 AÑOS Y MAS
50-64 AÑOS
36-49 AÑOS
20-35 AÑOS
15-19 AÑOS
10-14 AÑOS
1 -4 AÑOS
1 - 11 MESES
DIAGNOSTICO MEDICO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
21
Figura 1.7: Formulario de Reportes de Terapia de Lenguaje
21
DIA
AÑO
PROFESIONAL FIRMA
GRUPO DE EDAD
MENOR DE UN MES
MUJER
NOMBRE Y APELLIDO
HOMBRE
SEXO
Nº
5 - 9 AÑOS
NOMBRE UNIDAD
AREA DE SALUD
PARROQUIA
CANTÓN
PROVINCIA
DATOS PERSONAL
GOVEO, Mirian. “Centro de Rehabilitación Física de Antonio Ante”.
41
1.2.13 ESTRUCTURA DEL CENTRO DE REHABILITACIÓN FÍSICA DE ANTONIO ANTE
ALCALDE
DIRECCION DE DESARROLLO Y
PARTICPACION LOCAL
DIRECCION DE DESARROLLO
TRABAJO SOCIAL
CASA DE SALUD
HOSPITALARIA
CENTRO DE REHABILITACION FISICA
91
Figura 1.8: Organigrama del Centro de Rehabilitación Física
1.2.14 FLUJO, TRÁNSITO Y TRATAMIENTO DE PACIENTES EN EL CENTRO DE
REHABILITACIÓN FÍSICA DE ANTONIO ANTE
91
ANDRADE, Janeth. “Centro de Rehabilitación Física de Antonio Ante”.
112
-
-
-
-
EVALUACIÓN: El paciente debe asistir a una consulta médica donde se
indicará el tipo de terapia que necesita.
DIAGNÓSTICO: Bajo el pedido del médico el fisioterapeuta debe realizar un
diagnóstico vital, relevante y posterior para poder empezar el tratamiento del
paciente.
TRATAMIENTO: Consiste en 10 sesiones con una duración de 40 minutos cada
sesión, en la cual en cada una de ella existe una evaluación con una tabla del
dolor del 1 al 10, el cual permitirá observar si el paciente ha tenido una mejoría.
CONTINUAR: Si el paciente no presenta síntomas de mejoramiento el
tratamiento debe continuar con 5 sesiones más, en caso de seguir con los
mismos síntomas él debe acudir nuevamente donde el especialista.
ALTA: El paciente se encuentra totalmente recuperado.92
Paciente
Médico
Consulta
Tipo terapia
Evaluación
Diagnóstico
Pedido Médico
Tratamiento
No hay mejoría
Fisioterapeuta
Continuar
Alta
Figura 1.9: Diagrama del Tratamiento de Pacientes del Centro de Rehabilitación Física
1.2.15 FLUJO DE INFORMACIÓN EN EL CENTRO DE REHABILITACIÓN FÍSICA DE
ANTONIO ANTE
-
92
EL paciente debe tener un pedido del especialista.
113
93
-
Solicitar su historia clínica en caso de tenerlo, caso contrario se debe abrir, en
cuales ingresamos sus datos personales.
-
Luego de esto ingresamos a la ficha de historia clínica del paciente.
-
Si el paciente tiene un tratamiento largo para su rehabilitación el centro fija un
horario para ese paciente.
-
Por último tenemos la ficha del reporte donde llenamos la información de las
historias clínica o los nombres y apellidos de los pacientes, para tener una
referencia de cuáles son los servicios más requeridos por la sociedad.93
114
Pedido Médico
Paciente
Obtener Turno
Historia Clínica
Abrir Historia Clínica
Crear Historia Clínica
Enfermera de Rehabilitación
Tomar Signos Vitales
Historial Clínico Modificado
Examinar Paciente
Diagnóstico
Fisioterapeuta
Ingreso Diagnóstico y Tratamiento
Ingreso Editar Eliminar Paciente
Reporte
Ingreso Editar Eliminar Fichas
Historiales
Administrador
Ingreso Editar Eliminar Tarifas
Figura 1.10: Diagrama de Información del Centro de Rehabilitación Física
1.3 BASE DE DATOS
Una base de datos es un “almacén” o conjunto que nos permite guardar grandes
cantidades de información relacionada que se encuentra agrupada o estructurada de
115
forma organizada para luego poder encontrar y utilizar fácilmente, ya que la finalidad
de la base de datos es eliminar la redundancia o al menos minimizarla.
Desde el punto de vista informático, la base de datos es un sistema formado por un
conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un
conjunto de programas que manipulen ese conjunto de datos.
Los tres componentes principales de un sistema de base de datos son el hardware, el
software DBMS y los datos a manejar, así como el personal encargado del manejo del
sistema.94
1.3.1 CARACTERÍSTICAS DE UNA BASE DE DATOS
Entre las principales características de los sistemas de base de datos podemos
mencionar:
-
Independencia lógica y física de los datos.
Redundancia mínima.
Acceso concurrente por parte de múltiples usuarios.
Integridad de los datos.
Consultas complejas optimizadas.
Seguridad de acceso y auditoría.
Respaldo y recuperación.
Acceso a través de lenguajes de programación estándar. 95
1.3.2 SISTEMA MANEJADOR DE BASE DE DATOS (DBMS)
Los Sistemas de Gestión de base de datos (en inglés data base management system
DBMS). Es el de manejar de manera clara, sencilla y ordenada un conjunto de datos
de un tipo de software específico, que posteriormente se convertirán en información
relevante para una organización, en la cual el sistema de gestión de bases de datos
está dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones
que la utilizan. Se compone de un lenguaje de definición de datos, de un lenguaje de
manipulación de datos y de un lenguaje de consulta. 96
1.3.2.1 OBJETIVOS DE LOS SISTEMAS DE BASE DE DATOS
Existen distintos objetivos que deben cumplir los SGBD:
94
http://www.maestrosdelweb.com/principiantes/¿que-son-las-bases-de-datos/
http://www.monografias.com/trabajos7/bada/bada.shtml
96
http://es.wikipedia.org/wiki/Sistema_de_gestión_de_bases_de_datos
95
116
-
Abstracción de la información: Los SGBD ahorran a los usuarios detalles de
almacenamiento físico de los datos. En una base de datos puede ocupar uno o
cientos de archivos, este hecho se hace transparente al usuario.
-
Independencia: La independencia de los datos consiste en la capacidad de
modificar el esquema (físico o lógico) de una base de datos sin tener que
realizar cambios en las aplicaciones.
-
Consistencia: En casos en los que no se ha logrado eliminar la redundancia,
será necesario vigilar que la información que aparece repetida se actualice de
forma coherente.
-
Seguridad: Los SGBD deben garantizar que la información se encuentra segura
de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas
categorías de permisos.
-
Manejo de transacciones: Una Transacción es un programa que se ejecuta
como una sola operación. Los SGBD proveen mecanismos para programar las
modificaciones de los datos de una forma más simple.
-
Tiempo de respuesta: es minimizar el tiempo que el SGBD tarda en darnos la
información solicitada y en almacenar los cambios realizados. 97
1.3.3 BASE DE DATOS RELACIONALES
En una computadora existen diferentes formas de almacenar información. Esto da
lugar a distintos modelos de organización de la base de datos: jerárquico, red,
relacional y orientada a objeto.
Los sistemas relacionales son importantes porque ofrecen muchos tipos
de procesos de datos, como: simplicidad y generalidad, facilidad de uso para el usuario
final, períodos cortos de aprendizaje y las consultas de información se especifican de
forma sencilla.
Las tablas son un medio de representar la información de una forma más compacta y
es posible acceder a la información contenida en dos o más tablas.98
Las bases de datos relacionales están constituidas por una o más tablas que contienen
la
información ordenada de una forma organizada. Cumplen las siguientes leyes básicas:
97
98
Generalmente, contendrán muchas tablas.
Una tabla sólo contiene un número fijo de campos.
http://elies.rediris.es/elies9/4-1-2.htm
http://www.monografias.com/trabajos5/basede/basede.shtml
117
-
El nombre de los campos de una tabla es distinto.
Cada registro de la tabla es único.
El orden de los registros y de los campos no están determinados.
Para cada campo existe un conjunto de valores posible.
1.3.3.1 DISEÑO DE LAS BASES DE DATOS RELACIONALES
El primer paso para crear una base de datos, es planificar el tipo de información que se
quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información
disponible y la información que necesitamos.
La planificación de la estructura de la base de datos, en particular de las tablas, es vital
para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en
una descripción de cada uno de los campos que componen el registro y los valores o
datos que contendrá cada uno de esos campos.
Los campos son los distintos tipos de datos que componen la tabla, por ejemplo:
nombre, apellido, domicilio. La definición de un campo requiere: el nombre del campo,
el tipo de campo, el ancho del campo, etc.
Los registros constituyen la información que va contenida en los campos de la tabla,
por ejemplo: el nombre del paciente, el apellido del paciente y la dirección de este.
Generalmente los diferentes tipos de campos que su pueden almacenar son los
siguientes: Texto (caracteres), Numérico (números), Fecha / Hora, Lógico
(informaciones lógicas si/no, verdadero/falso, etc., imágenes.
En resumen, el principal aspecto a tener en cuenta durante el diseño de una tabla es
determinar claramente los campos necesarios, definirlos en forma adecuada con un
nombre especificando su tipo y su longitud.99
1.3.4 DISEÑO LÓGICO DE BASE DE DATOS
El diseño lógico es el proceso de construir un esquema de la información que utiliza la
empresa, basándose en un modelo de base de datos específico, independiente del
SGBD concreto que se vaya a utilizar y de cualquier otra consideración física.
En esta etapa, se transforma el esquema conceptual en un esquema lógico que
utilizará las estructuras de datos del modelo de base de datos en el que se basa el
SGBD que se va a utilizar, de acuerdo de cómo se va desarrollando el esquema lógico,
éste se va probando y validando con los requisitos de usuario.
El esquema lógico es una fuente de información para el diseño físico. Además, es
importante durante la etapa de mantenimiento del sistema, ya que permite que los
futuros cambios que se realicen sobre los programas de aplicación o sobre los datos, se
representen correctamente en la base de datos.
99
118
El diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un punto
de inicio y se van refinando continuamente; donde las dos etapas son claves para
conseguir un sistema que funcione correctamente.100
1.3.4.1 INTEGRIDAD DE DATOS
Integridad de datos se refiere a la corrección y completitud de los datos en una base
de datos. Cuando los contenidos se modifican con sentencias INSERT, DELETE o
UPDATE, la integridad de los datos almacenados puede perderse de maneras
diferentes.
Pueden añadirse datos no válidos a la base de datos, tales como un pedido que
especifica un producto no existente.
Pueden modificarse datos existentes tomando un valor incorrecto, como por ejemplo
si se reasigna un vendedor a una oficina no existente.
Los cambios en la base de datos pueden perderse debido a un error del sistema o a un
fallo en el suministro de energía.
Una de las funciones importantes de un DBMS relacional es preservar la integridad de
sus datos almacenados en la mayor medida posible.101
1.3.4.2 TIPOS DE RESTRICCIONES DE INTEGRIDAD EN BASE DE DATOS RELACIONALES
-
Datos Requeridos: establece que una columna tenga un valor no NULL. Se
define efectuando la declaración de una columna es NOT NULL cuando la tabla
que contiene las columnas se crea por primera vez, como parte de la sentencia
CREATE TABLE.
-
Chequeó de Validez: cuando se crea una tabla cada columna tiene un tipo de
datos y el DBMS asegura que solamente los datos del tipo especificado sean
ingresados en la tabla.
-
Integridad de entidad: establece que la clave primaria de una tabla debe tener
un valor único para cada fila de la tabla; si no, la base de datos perderá su
integridad.
Integridad referencial: asegura la integridad entre las claves ajenas y primarias
(relaciones padre/hijo). Existen cuatro actualizaciones de la base de datos que
puede corromper la integridad referencial:
-
•
•
100
101
La inserción de una fila hijo es cuando no coincide la clave ajena
con la clave primaria del padre.
La actualización en la clave ajena de la fila hijo, donde se
produce una actualización en la clave ajena de la fila hijo con
http://usuarios.multimania.es/cursosgbd/UD4.htm
http://es.wikipedia.org/wiki/Integridad_de_datos
119
•
•
una sentencia UPDATE y la misma no coincide con ninguna clave
primaria.
La supresión de una fila padre, donde si una fila padre tiene uno
o más hijos se suprime, las filas hijos quedaran huérfanas.
La actualización de la clave primaria de una fila padre, donde si
una fila padre tiene uno o mas hijos se actualiza su clave
primaria, las filas hijos quedaran huérfanas.102
1.3.4.3 NORMALIZACIÓN
Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a
desarrollar un esquema que minimice los problemas de lógica. Donde cada regla está
basada en la que le antecede.
La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo
lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a
errores de lógica cuando se trataba de manipular los datos.
Las bases de datos relacionales se normalizan para:
-
Evitar la redundancia de los datos.
Evitar problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una
tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
-
Cada columna debe tener su nombre único.
No puede haber dos filas iguales.
No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo. 103
1.3.4.4 PROPIEDADES DE UNA BASE DE DATOS DESPUÉS DE LA NORMALIZACIÓN
Una base de datos normalizada debe representar las siguientes propiedades:
- Los requerimientos para almacenamientos de datos se minimizan, dado que el
proceso de normalización sistemáticamente elimina la duplicación de los datos.
-
102
103
Desde que los datos son almacenados en el mínimo número de lugares, las
posibilidades de inconsistencia en la información son reducidas al mínimo.
http://www3.uji.es/~mmarques/f47/apun/node70.html
http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_una_base_de_datos
120
-
Las estructuras normalizadas son óptimas para efectuar actualizaciones de los
datos. Dado que los datos existen en el mínimo número de lugares, una
operación de actualización (UPDATE) necesitará acceder a una mínima cantidad
de datos104.
1.3.4.5 PROPIEDADES DE UNA RELACIÓN
Una tabla debe satisfacer ciertos criterios previos antes de calificar para convertirse en
una relación.
-
No duplicados
No debe haber nunca dos columnas o filas totalmente idénticas. Si dos filas son
totalmente idénticas, entonces hacen falta algunos atributos que las haga diferentes y
distinguibles. Ejemplo: Dos registros de discos compactos en una tienda serían
idénticos si son dos copias del último álbum de Shakira, si no fuera porque cada disco
compacto tiene un número código que los hace diferentes.
-
Clave Única
Cada registro tiene que tener una llave única que lo identifique. Cualquier atributo
puede ser una llave, pero en lo posible trataremos de elegir como llave única al
atributo que tenga una longitud menor y fija, como por ejemplo un número de ID. Si
un atributo es insuficiente para identificar un registro de manera única, entonces más
de un atributo puede conformar la llave única. En tal caso, el número de atributos que
conformen una llave debe ser el mínimo necesario y suficiente.
-
Insignificancia del orden
La secuencia en la cual los atributos son escritos no debe importar. Podemos escribir el
ID del empleado de primero, o el nombre y el apellido de primero, y esto no afectará
las relaciones que establezcamos con otras tablas. Por otro lado, los registros deben
ser totalmente independientes de su secuencia o posición en la base de datos
(dependencia posicional). Esto significa que si intentamos identificar un registro por su
posición dentro de la tabla, estaremos creando una llave inválida.
-
Forma no-normalizada
Los datos, en su forma elemental, no están normalizados. Por lo tanto, lo primero con
lo que debemos comenzar es con los datos elementales o básicos que conformarán el
diccionario de datos. El diccionario de datos es creado a partir de los documentos o
diagramas de flujo de la compañía. Se deben listar los elementos uno debajo del otro.
Así, obtendremos la forma no-normalizada para el ejercicio de ARD (Análisis Relacional
de Datos), con el cual deberemos obtener al final distintos grupos de elementos. Mas
tarde, dichos grupos se combinarán con los grupos de otros documentos al cual
también se les ha hecho el análisis ARD, y se establecerán relaciones entre ellos.
104
http://www.wikilearning.com/tutorial/diseno_de_base_de_datos_en_sql-normalizacion/21129-4
121
1.3.4.6 CLAVES
-
Clave primaria o única: es aquella columna que pueden ser también dos
columnas o más que identifica únicamente a esa fila. La clave primaria es un
identificador que va a ser único para cada fila. Muchas veces la clave primaria
es auto numérico. En una tabla se puede tener más de una clave, en tal caso se
puede escoger una para ser la clave primaria, las demás claves son las claves
candidatas. Además, es la posible clave primaria. Sólo puede existir una clave
primaria por tabla y ningún campo de dicha clave puede contener valores
NULL.
-
Clave foránea o ajena: es aquella columna que existiendo como dependiente
en una tabla, es a su vez clave primaria en otra tabla.
-
Clave alternativa: es aquella clave candidata que no ha sido seleccionada como
clave primaria, pero que también puede identificar de forma única a una fila
dentro de una tabla. Ejemplo: Si en una tabla clientes definimos el número de
documento (id cliente) como clave primaria, el número de seguro social de ese
cliente podría ser una clave alternativa.
-
Clave compuesta: es una clave que está compuesta por más de una columna.
-
Clave externa: Una clave externa es una referencia a una clave en otra tabla.
Las claves externas no necesitan ser claves únicas en la tabla donde están y sí a
donde están referenciadas. Por ejemplo, el código de departamento puede ser
una clave externa en la tabla de empleados, obviamente se permite que haya
varios empleados en un mismo departamento, pero existirá sólo un
departamento.
-
Clave índice: surgen con la necesidad de tener un acceso más rápido a los
datos. Los índices pueden ser creados con cualquier combinación de campos de
una tabla. Las consultas que filtran registros por medio de estos campos,
pueden encontrar los registros de forma no secuencial usando la clave
índice.105
1.3.4.7 GRADOS DE NORMALIZACIÓN
Existen básicamente tres niveles de normalización: Primera Forma Normal (1NF),
Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas
formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se
considera normalizada a esa forma de normalización. Por ejemplo, supongamos que
su base de datos cumple con todas las reglas del segundo nivel de normalización. Se
considera que está en la Segunda Forma Normal. No siempre es una buena idea tener
una base de datos conformada en el nivel más alto de normalización. Puede llevar a un
nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de
normalización.
105
http://es.wikipedia.org/wiki/Base_de_datos_relacional
122
Existen seis niveles más de normalización que no se han discutido aquí. Ellos son
Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o
Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte,
Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio.
Estás formas de normalización pueden llevar las cosas más allá de lo que necesita.
Éstas existen para hacer una base de datos realmente relacional. Tienen que ver
principalmente con dependencias múltiples y claves relacionales.
-
Primera Forma Normal
La regla de la Primera Forma Normal establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas. Ésta es una regla muy fácil de seguir.
Observe el esquema de la tabla Clientes de la base de datos.
Clientes
ID Cliente
Nombre
Apellidos
Nombre_Producto1
Costo_Producto1
Imagen_Producto1
Nombre_Producto2
Costo_Producto2
Imagen_Producto2
Fecha _Pedido
Cantidad _Pedido
Nombre CIA_Envios
Tabla 1.1: Clientes
Fuente: http://www.uazuay.edu.ec/analisis/El%20modelo%20relacional.pdf
La tabla tiene varias columnas repetidas. Éstas se refieren principalmente a los
productos. De acuerdo con la regla, debe eliminar las columnas repetidas y crearles su
propia tabla.
Clientes
ID_Clientes
Nombre
Apellidos
Dirección
Pedidos
Nombre_Productos
Costo_Producto
Imagen_ Producto
Número_ Pedido
Fecha_Pedido
Cantidad_Pedido
Clave_Cia_Envios
Nombre_Ci_ Envios
Tabla 1.2: Eliminación de datos repetidos en una base de datos
123
Ahora tiene dos tablas. Pero todavía hay un problema. No hay forma de relacionar los
datos de la tabla original con los de la nueva tabla. Para hacerlo, debe añadir un campo
clave a la segunda tabla de forma que se establezca la relación. Añada a la tabla
Productos una clave primaria que se llame ID_Producto y añada una clave a la tabla
Clientes que la relacione con la tabla Productos. El campo ID_Producto es el candidato
ideal.
Clientes
Pedidos
ID_Productos
ID_Clientes
Nombre
Apellidos
Dirección
ID_Productos
Nombre_Productos
Costo_Producto
Imagen_Producto
Número_Pedido
Fecha_Pedido
Cantidad_Pedido
Clave_Cia_Envios
Tabla 1.3: Primera Forma Normal
Así, se ha establecido una relación uno a varios. Ésta representa lo que la base de
datos estará haciendo en la vida real. El cliente tendrá muchos productos que podrá
comprar, sin importar cuántos otros clientes quieran comprarlos también. Además, el
cliente necesitará haber pedido un producto para ser un cliente. Usted ya no está
obligado a añadir un cliente cada vez que añade un nuevo producto a su inventario.
Poner la base de datos en la Primera Forma Normal resuelve el problema de los
encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de datos
inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán
columnas que representen los mismos datos. En una empresa de servicios de
electricidad, había una base de datos para el control de refacciones de una planta
nuclear. La tabla de su base de datos, la cual contenía los números de parte de las
refacciones, tenía una columna repetida más de treinta veces. Cada vez que una nueva
parte se tenía que dar de alta, se creaba una nueva columna para almacenar la
información.
La normalización ayuda a clarificar la base de datos a organizarla en partes más
pequeñas y más fáciles de entender. En lugar de tener que entender una tabla
gigantesca y monolítica que tiene muchos diferentes aspectos, usted sólo tiene que
entender objetos pequeños y más tangibles, así como las relaciones que guardan con
otros objetos también pequeños. No es necesario mencionar que un mejor
entendimiento del funcionamiento de su base de datos conducirá aun mejor
aprovechamiento de sus activos.
-
Segunda Forma Normal
La regla de la Segunda Forma Normal establece que todas las dependencias parciales
124
se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es
un término que describe a aquellos datos que no dependen de la clave de la tabla para
identificarlos. En la base de datos se muestra, la información de pedidos está en cada
uno de los registros. Sería mucho más simple utilizar únicamente el número del
pedido. El resto de la información podría residir en su propia tabla. Una vez que haya
organizado la información de pedidos.
Clientes
ID_Productos
ID_Clientes
Nombre
Apellidos
Dirección
Número_Pedido
Nombre_Cia_Envios
Pedidos
ID_Productos
Nombre_Productos
Cantidad_Pedido
Imagen_Producto
Productos
ID_Productos
Fecha_Compra
Costos_Productos
Tabla 1.4: Eliminación de dependencias parciales – Segunda Forma Normal
Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La
mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de
que sus datos están normalizados cuando todo funciona más o menos bien, parece ser
un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo
arreglando una base de datos no normalizada que el que emplearía en una
normalizada.
Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las
ventajas de las bases de datos relacionales. Por ejemplo, puede añadir nuevas
columnas a la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo
aplica para las otras tablas. Alcanzar este nivel de normalización permite que los datos
se acomoden de una manera natural dentro de los límites esperados.
Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la
mayoría de los problemas de lógica. Puede insertar un registro sin un exceso de datos
en la mayoría de las tablas. Observando un poco más de cerca la tabla Clientes, vemos
la columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El siguiente nivel
de normalización explicará cómo solucionar esto.
-
Tercera Forma Normal
La regla de la Tercera Forma Normal señala que hay que eliminar y separar cualquier
dato que no sea clave. El valor de esta columna debe depender de la clave. Todos los
valores deben identificarse únicamente por la clave. En la base de datos se muestra, la
tabla Clientes contiene la columna Nombre_Cia_Envios, la cual no se identifica
únicamente por la clave. Podría separar estos datos de la tabla y ponerlos en una tabla
aparte.
Clientes
Productos
PedidoMaestro
125
PedidoDetallado
Cias_Envios
ID_cliente
ID_Producto
Numero_Pedido
Nombre
Apellidos
Dirección
ID_Producto
Nombre_Producto
Costos_Productos
Foto_Producto
ID_Pedido
Fecha_Pedido
Cantidad_Pedidos
Cantidad_Pedido
ID_PedidoDetallado
ID_Pedido
Fecha_Pedido
ID_Cia_Envios
Nombre_Cia_Envios.
Tabla 1.5: Eliminación de datos que no son claves para la Tercera Forma Normal
Ahora todas sus tablas están en la Tercera Forma Normal. Esto le da más flexibilidad y
previene errores de lógica cuando inserta o borra registros. Cada columna en la tabla
está identificada de manera única por la clave, y no hay datos repetidos. Esto provee
un esquema limpio y elegante, que es fácil de trabajar y expandir106.
1.3.5 DISEÑO FÍSICO
El diseño físico es el proceso de producir la descripción de la implementación de la
base de datos en memoria secundaria, estructuras de almacenamiento y métodos de
acceso que garanticen un acceso eficiente a los datos.
Para llevar a cabo esta etapa, se debe tener el SGBD que se va a utilizar, ya que el
esquema físico se adapta a él. Entre el diseño físico y el diseño lógico hay una
realimentación, ya que las decisiones que se tomen durante el diseño físico para
mejorar las prestaciones, pueden afectar a la estructura del esquema lógico.
El propósito del diseño físico es describir cómo se va a implementar físicamente el
esquema lógico obtenido en la fase anterior (modelo relacional), esto consiste en:
-
Obtener un conjunto de relaciones (tablas) y las restricciones que se deben
cumplir sobre ellas.
-
Determinar las estructuras de almacenamiento y los métodos de acceso que se
van a utilizar para conseguir unas prestaciones óptimas.
-
Diseñar el modelo de seguridad del sistema. 107
1.3.6 SISTEMA DE BASE DE DATOS (DBMS)
Los Sistemas de gestión de base de datos son un tipo de software muy específico,
dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la
utilizan. Se compone de un lenguaje de definición de datos, de un lenguaje de
manipulación de datos y de un lenguaje de consulta. En los textos que tratan este
tema, o temas relacionados, se mencionan los términos SGBD y DBMS, siendo ambos
106
107
http://www.uazuay.edu.ec/analisis/El%20modelo%20relacional.pdf
126
equivalentes, y acrónimos, respectivamente, de sistema de gestor de base de datos y
Data Base Management System, su expresión inglesa108.
1.3.6.1 CARACTERÍSTICAS DE UNA DBMS
-
Control de la redundancia de datos
Este consiste en lograr una mínima cantidad de espacio de almacenamiento para
almacenar los datos evitando la duplicación de la información. De está manera, se
logran ahorros en el tiempo de procesamiento de la información, se tendrán menos
inconsistencias, menores costos operativos y hará el mantenimiento más fácil.
-
Compartimiento de datos
Una de las principales características de las bases de datos, es que los datos pueden
ser compartidos entre muchos usuarios simultáneamente, proveyendo, de esta
manera, máxima eficiencia.
-
Mantenimiento de la integridad
La integridad de los datos es la que garantiza la precisión o exactitud de la información
contenida en una base de datos. Los datos interrelacionados deben siempre
representar información correcta a los usuarios.
-
Soporte para control de transacciones y recuperación de fallas.
Se conoce como transacción toda operación que se haga sobre la base de datos. Las
transacciones deben por lo tanto ser controladas de manera que no alteren la
integridad de la base de datos. La recuperación de fallas tiene que ver con la capacidad
de un sistema DBMS de recuperar la información que se haya perdido durante una
falla en el software o en el hardware.
-
Independencia de los datos.
En las aplicaciones basadas en archivos, el programa de aplicación debe conocer tanto
la organización de los datos como las técnicas que le permiten acceder a los datos. En
los sistemas DBMS los programas de aplicación no necesitan conocer la organización
de los datos en el disco duro. Este totalmente independiente de ello.
-
Seguridad
La disponibilidad de los datos puede ser restringida a ciertos usuarios. Según los
privilegios que posea cada usuario de la base de datos, podrá acceder a mayor
información que otros.
-
Velocidad
Los sistemas DBMS modernos poseen altas velocidades de respuesta y proceso.
108
127
-
Independencia del hardware
La mayoría de los sistemas DBMS están disponibles para ser instalados en múltiples
plataformas de hardware.
Los sistemas de bases de datos relacionales RDBMS (Relational Data base
Management System, por sus siglas en Inglés) tales como Oracle, MySQL, SQL Server,
PostgreSQL, Informix, entre otros, le permiten ejecutar las tareas que se mencionan a
continuación, de una forma entendible y razonablemente sencilla:
•
•
•
•
•
•
Le permiten ingresar datos al sistema.
Le permiten almacenar los datos.
Le permiten recuperar los datos y trabajar con ellos.
Le proveen herramientas para capturar, editar y manipular datos.
Le permiten aplicar seguridad.
Le permiten crear reportes e informes con los datos109.
1.3.6.2 ESQUEMA DE UN DBMS
110
Figura 1.11: Los DBMS
Fuente: http://www.unalmed.edu.co/~mstabare/Dbms.htm
109
http://www.wikilearning.com/tutorial/diseno_de_bases_de_datos_en_sqlcaracteristicas_de_una_dbms_dbms/21129-2
110
http://www.unalmed.edu.co/~mstabare/Dbms.htm
128
1.3.6.3 PROGRAMAS QUE CONFORMAN UN DBMS
El DBMS se compone de una serie de módulos:
El Compilador de DDL (Data Definition Language) sirve para definir estructuras de
almacenamiento, y por tanto para crear esquemas conceptuales.
-
El resultado de compilar todas las instrucciones DDL se va a almacenar en lo
que se conoce como Diccionario de Datos. Este diccionario nos aportará
información acerca de la base de datos. El diccionario de datos depende del
DBMS.
-
El Precompilador DML (Data Management Language). Las instrucciones de
manejo que define van dentro de un lenguaje de alto nivel cualquiera (Lenguaje
Anfitrión) (El DML se llama Lenguaje Huésped). El primer paso del precompilador es traducir las instrucciones del DML al lenguaje anfitrión.
-
El Procesador de Consultas permite al usuario "jugar" con los datos, o sea,
consultarlos sin necesidad de construir un programa de aplicación. Cuenta con
un Optimizador de DML para optimizar esas consultas.
-
El Manejador de bases de datos realiza la traducción entre los diferentes
esquemas de la base de datos. Si un usuario quiere acceder a unos datos, el
manejador comprobará su esquema externo para averiguar a que datos tienen
acceso ese usuario; luego estudia el esquema conceptual completo, a
continuación accede al esquema físico para saber como trabajar con ellos y
finalmente los proporcionará al usuario111.
1.3.7 LENGUAJE SQL
Es un lenguaje declarativo de acceso a base de datos relacional que permite especificar
diversos tipos de operaciones sobre las mismas. Una de sus características es el
manejo del álgebra y el cálculo relacional permitiendo lanzar consultas con el fin de
recuperar de una forma sencilla información de interés de una base de datos, así como
también hacer cambios sobre la misma. Es un lenguaje de cuarta generación (4GL).
El SQL es un lenguaje de acceso a base de datos que explota la flexibilidad y potencia
de los sistemas relacionales permitiendo gran variedad de operaciones sobre los
mismos.
Es un lenguaje declarativo de “alto nivel” o “de no procedimiento”, que gracias a su
fuerte base teórica y su orientación al manejo de conjuntos de registros, y no a
registros individuales, permite una alta productividad en codificación y la orientación a
objetos. De esta forma, una sola sentencia puede equivaler a uno o más programas
que utilizas en un lenguaje de bajo nivel orientado a registro.
111
http://www.wikilearning.com/curso_gratis/sistemas_de_bases_de_datosprogramas_que_conforman_el_dbms/3621-5
129
1.3.7.1 COMANDOS DE SQL
El lenguaje SQL está compuesto por comandos, cláusulas, operadores y funciones de
agregado. Estos elementos se combinan en las instrucciones para crear, actualizar y
manipular las bases de datos. 112
Existen dos tipos de comandos SQL:
-
Los DLL que permiten crear y definir nuevas bases de datos, campos e índices.
-
Los DML que permiten generar consultas para ordenar, filtrar y extraer datos
de la base de datos.
Comandos DLL
Comando
Descripción
CREATE
Utilizado para crear nuevas tablas, campos e índices
DROP
Empleado para eliminar tablas e índices
ALTER
Utilizado para modificar las tablas agregando campos o cambiando la
definición de los campos.
Comandos DML
Comando
Descripción
SELECT
Utilizado para consultar registros de la base de datos que satisfagan un
criterio determinado
INSERT
Utilizado para cargar lotes de datos en la base de datos en una única
operación.
UPDATE
Utilizado para modificar los valores de los campos y registros
especificados
DELETE
Utilizado para eliminar registros de una tabla de una base de datos
Cláusulas: Las cláusulas son condiciones de modificación utilizadas para definir los
datos que desea seleccionar o manipular.
112
http://www.monografias.com/trabajos11/manu/manu.shtml
130
Cláusula
Descripción
FROM
Utilizada para especificar la tabla de la cual se van a seleccionar los
registros
WHERE
Utilizada para especificar las condiciones que deben reunir los registros
que se van a seleccionar
GROUP BY
Utilizada para separar los registros seleccionados en grupos específicos
HAVING
Utilizada para expresar la condición que debe satisfacer cada grupo
ORDER BY
Utilizada para ordenar los registros seleccionados de acuerdo con un
orden específico
Operadores Lógicos
Operador
Uso
AND
Es el "y" lógico. Evalúa dos condiciones y devuelve un valor de verdad
sólo si ambas son ciertas.
OR
Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdad si
alguna de las dos es cierta.
NOT
Negación lógica. Devuelve el valor contrario de la expresión.
Operadores de Comparación
Operador
Uso
<
Menor que
>
Mayor que
<>
Distinto de
<=
Menor ó Igual que
>=
Mayor ó Igual que
=
Igual que
131
BETWEEN
Utilizado para especificar un intervalo de valores.
In
Utilizado para especificar registros de una base de datos
Tabla 1.6: Tabla de Comandos SQL
Fuente: http://www.monografias.com/trabajos11/manu/manu.shtml
1.3.8 COMPARACIÓN DE SISTEMAS ADMINISTRADORES DE BASE DE DATOS
132
MySQL
PostgreSQL
Microsoft
SQL Server
InterBase
PostgreSQL
Global
Development
Microsoft
Borland
Oracle
INFORMACION GENERAL
MySQL AB
Oracle
Corporation
Fecha de la 1ra.
Versión pública
1996
1977
Junio de 1989
1989
1985
Ultima Versión
estable
5.0
11g Release 1
8.2.3
9.00.2047(20
05 SP1)
7.5.1
Licencia BSD
Propietario
Propietario
Creador
Liciencia de
GPL
Propietario
software
SOPORTE DEL SISTEMA OPERATIVO
Si
Si
Windows
Si
Si
Mac OS X
Linux
Si
Si
Si
No
BSD
Si
Si
Unix
CARACTERISTICAS FUNDAMENTALES
ACID
Si
Si
Integridad
Si
Si
referencial
Transacciones
Si
Si
Unicode
Si
Si
TABLAS Y VISTAS
Tabla temporal
Si
Si
Vista
No
Si
materializada
Si
Si
Si
Si
Si
Si
No
No
No
No
Si
No
Si
Si
Si(Solaris)
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Similar
Si
INDICES
Arbol R-R+
Tablas
MyISAM
Tablas HEAP
No
No
No
No
Hash
Expresión
Parcial
Reversa
Mapa de bits
OTROS OBJETOS
No
Dominio
Si
Cursor
Si
Trigger
Si
Función
Procedimiento
Si
Si
Rutina externa
PARTICIONAMIENTO
Rango
Edición EE
Solamente
?
Si
No
Si
Si
Si
Si
Si
Si
No
No
?
?
No
No
No
No
?
?
?
No
No
No
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
No
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
No
Si
No
113
Figura 1.12: Comparación de Base de Datos
Fuente: http://es.wikipedia.org
1.4 HERRAMIENTAS DE DESARROLLO
1.4.1
113
BASE DE DATOS MY-SQL
http://es.wikipedia.org
133
Si
No
MySQL es un sistema de gestión de base de datos relacional, multihilo, multiusuario
sencillo de usar y rápido. También es uno de los motores de base de datos más
usados en Internet, la principal razón de esto es que es gratis para aplicaciones no
comerciales.
MySQL es una idea originaria de la empresa open source MySQL AB establecida en
Suecia en 1995 y cuyos fundadores son David Axmark, Allan Larsson, y Michael
"Monty" Widenius. El objetivo consiste en que MySQL cumpla el estándar SQL, pero
sin sacrificar velocidad, fiabilidad o usabilidad.114
1.4.1.1 CARACTERÍSTICAS
-
Es un gestor de base de datos. Una base de datos es un conjunto de datos y un
gestor de base de datos es una aplicación capaz de manejar este conjunto de
datos de manera eficiente y cómoda.
-
Es una base de datos relacional. es un conjunto de datos que están
almacenados en tablas entre las cuales se establecen unas relaciones para
manejar los datos de una forma eficiente y segura. Para usar y gestionar una
base de datos relacional se usa el lenguaje estándar de programación SQL.
-
Es Open Source. El código fuente de MySQL se puede descargar y está accesible
a cualquiera, por otra parte, usa la licencia GPL para aplicaciones no
comerciales.
-
Es una base de datos muy rápida, segura y fácil de usar. Gracias a la
colaboración de muchos usuarios, la base de datos se ha ido mejorando
optimizándose en velocidad. Por eso es una de las bases de datos más usadas
en
Internet.
1.4.1.2 VENTAJAS COMO SERVIDOR DE BASE DE DATOS
Para acceder a bases de datos es más útil usar un motor o servidor que hace las
funciones de intérprete entre las aplicaciones y usuarios con las bases de datos.
Estas son las siguientes ventajas como servidor de base de datos:
114
-
Acceso: A las bases de datos de forma simultánea por varios usuarios y
aplicaciones.
-
Seguridad: En forma de permisos y privilegios, determinados usuarios tendrán
permiso para consulta o modificación de determinadas tablas. Esto permite
compartir datos sin que peligre la integridad de la base de datos o protegiendo
determinados contenidos.
http://es.wikipedia.org/wiki/MySQL
134
-
Potencia: SQL es un lenguaje muy potente para consulta de bases de datos,
usar un motor nos ahorra una enorme cantidad de trabajo.
-
Portabilidad: SQL es también un lenguaje estandarizado, de modo que las
consultas hechas usando SQL son fácilmente portables a otros sistemas y
plataformas. Esto, unido al uso de C/C++ proporciona una portabilidad muy
grande.
-
Escalabilidad: Es posible manipular bases de datos enormes, entorno de seis
mil tablas y alrededor de cincuenta millones de registros, y hasta 32 índices por
tabla.
-
MySQL: Está escrito en C y C++ y probado con multiples de compiladores y
dispone de APIs para muchas plataformas diferentes.
-
Conectividad: Permite conexiones entre diferentes máquinas con distintos
sistemas operativos. Es corriente que servidores Linux o Unix, usando. MySQL,
sirvan datos para ordenadores con Windows, Linux, Solaris, etc. Para ello se usa
TCP/IP, tuberías, o sockets Unix.
-
Es multihilo: con lo que puede beneficiarse de sistemas multiprocesador.
-
Permite manejar multitud de tipos para columnas.
-
Permite manejar registros de longitud fija o variable.115
1.4.2 PHP
PHP es un lenguaje de programación interpretado, diseñado originalmente para la
creación de páginas web dinámicas. Es usado principalmente en interpretación del
lado del servidor (server-side scripting) pero actualmente puede ser utilizado desde
una interfaz de línea de comandos o en la creación de otros tipos de programas
incluyendo aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+.
PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor (inicialmente
PHP Tools, o, Personal Home Page Tools). Fue creado originalmente por Rasmus
Lerdorf en 1994; sin embargo la implementación principal de PHP es producida ahora
por The PHP Group y sirve como el estándar de facto para PHP al no haber una
especificación formal. Publicado bajo la PHP License, la Free Software Foundation
considera está licencia como software libre.
Puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas
operativos y plataformas sin costo alguno. PHP se encuentra instalado en más de 20
millones de sitios web y en un millón de servidores, el número de sitios en PHP ha
compartido algo de su preponderante sitio con otros nuevos lenguajes no tan
115
http://www-css.fnal.gov/dsg/external/freeware/mysqlInfo.html
135
poderosos desde agosto de 2005. Este mismo sitio web de Wikipedia está desarrollado
en PHP. Es también el módulo Apache más popular entre las computadoras que
utilizan Apache como servidor web. La versión más reciente de PHP es el 5.3.4, del 10
de diciembre de 2010.
El gran parecido que posee PHP con los lenguajes más comunes de programación
estructurada, como C y Perl, permiten a la mayoría de los programadores crear
aplicaciones complejas con una curva de aprendizaje muy corta. También les permite
involucrarse con aplicaciones de contenido dinámico sin tener que aprender todo un
nuevo grupo de funciones.
Aunque todo en su diseño está orientado a facilitar la creación de página web, es
posible crear aplicaciones con una interfaz gráfica para el usuario, utilizando la
extensión PHP-Qt o PHP-GTK. También puede ser usado desde la línea de órdenes, de
la misma manera como Perl o Python pueden hacerlo; a esta versión de PHP se la
llama PHP-CLI (Command Line Interface).
Cuando el cliente hace una petición al servidor para que le envíe una página web, el
servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado que generará el
contenido de manera dinámica (por ejemplo obteniendo información de una base de
datos). El resultado es enviado por el intérprete al servidor, quien a su vez se lo envía
al cliente. Mediante extensiones es también posible la generación de archivos PDF,
Flash, así como imágenes en diferentes formatos.
Permite la conexión a diferentes tipos de servidores de bases de datos tales como
MySQL, Postgres, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite.
XAMPP es un servidor independiente de plataforma, software libre, que consiste
principalmente en la base de datos MySQL, el servidor Web Apache y los intérpretes
para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X (para
cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl. El
programa está liberado bajo la licencia GNU y actúa como un servidor Web libre, fácil
de usar y capaz de interpretar páginas dinámicas. Actualmente XAMPP esta disponible
para Microsoft Windows, GNU/Linux, Solaris, y MacOS X.
PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas
operativos, tales como UNIX (y de ese tipo, como Linux o Mac OS X) y Windows, y
puede interactuar con los servidores de web más populares ya que existe en versión
CGI, módulo para Apache, e ISAPI.
PHP es una alternativa a las tecnologías de Microsoft ASP y ASP.NET (que utiliza C#
VB.NET como lenguajes), a ColdFusion de la compañía Adobe (antes Macromedia), a
JSP/Java de Oracle, y a CGI/Perl. Aunque su creación y desarrollo se da en el ámbito de
los sistemas libres, bajo la licencia GNU, existe además un IDE (entorno de desarrollo
integrado) comercial llamado Zend Studio. Recientemente, CodeGear (la división de
lenguajes de programación de Borland) ha sacado al mercado un entorno integrado de
desarrollo para PHP, denominado Delphi for PHP. También existen al menos un par de
módulos para Eclipse, uno de los IDE más populares.
136
Fue originalmente diseñado en Perl, con base en la escritura de un grupo de CGI
binarios escritos en el lenguaje C por el programador danés-canadiense Rasmus
Lerdorf en el año 1994 para mostrar su currículum vítae y guardar ciertos datos, como
la cantidad de tráfico que su página web recibía. El 8 de junio de 1995 fue publicado
"Personal Home Page Tools" después de que Lerdorf lo combinara con su propio Form
Interpreter para crear PHP/FI.116
1.4.2.1 CARACTERÍSTICAS DE PHP
-
-
-
Es un lenguaje multiplataforma.
Completamente orientado al desarrollo de aplicaciones web dinámicas con
acceso a información almacenada en una base de datos.
El código fuente escrito en PHP es invisible al navegador y al cliente ya que es el
servidor el que se encarga de ejecutar el código y enviar su resultado HTML al
navegador. Esto hace que la programación en PHP sea segura y confiable.
Capacidad de conexión con la mayoría de los motores de base de datos que se
utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL.
Capacidad de expandir su potencial utilizando la enorme cantidad de módulos
(llamados ext's o extensiones).
Posee una amplía documentación en su página oficial, entre la cual se destaca
que todas las funciones del sistema están explicadas y ejemplificadas en un
único archivo de ayuda.
Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.
Permite aplicar técnicas de programación orientada a objetos.
Biblioteca nativa de funciones sumamente amplía e incluida.
No requiere definición de tipos de variables aunque sus variables se pueden
evaluar también por el tipo que estén manejando en tiempo de ejecución.
Tiene manejo de excepciones (desde PHP5).
Si bien PHP no obliga a quien lo usa a seguir una determinada metodología a la
hora de programar (muchos otros lenguajes tampoco lo hacen), aun estando
dirigido a alguna en particular, el programador puede aplicar en su trabajo
cualquier técnica de programación y/o desarrollo que le permita escribir código
ordenado, estructurado y manejable. Un ejemplo de esto son los desarrollos
que en PHP se han hecho del patrón de diseño Modelo Vista Controlador (o
MVC), que permiten separar el tratamiento y acceso a los datos, la lógica de
control y la interfaz de usuario en tres componentes independientes.117
1.4.3 PHP RUNER
PHP Runner es una aplicación capaz de generar automáticamente todo un repertorio
de páginas web para insertar información en los campos de una base de datos
determinada.
El lenguaje empleado en estas páginas es PHP. Las bases de datos que soporta PHP
116
117
http://es.wikipedia.org/wiki/PHP
http://es.wikipedia.org/wiki/PHP
137
Runner son MySQL, SQL Server y Oracle, tanto de forma remota como local.
El proceso de creación de las páginas se realiza completando un asistente. En él hay
que decidir los campos que se mostrarán en las páginas, los usuarios que podrán
añadir contenido, las funciones que estarán disponibles.
La que ofrece el programa es muy avanzada porque permite crear los passwords para
proteger a los usuarios de la BDD.118
1.4.4 DREAMWEAVER
Dreamweaver es una aplicación en forma de estudio (basada en la forma de Adobe
Flash) enfocada a la construcción y edición de sitios y aplicaciones Webs basados en
estándares. Creado inicialmente por Macromedia (actualmente producido por Adobe
Systems). Es el programa de este tipo más utilizado en el sector del diseño y la
programación web, por sus funcionalidades, su integración con otras herramientas
como Adobe Flash y, recientemente, por su soporte de los estándares del World Wide
Web Consortium. Su principal competidor es Microsoft Expression Web y tiene soporte
tanto para edición de imágenes como para animación a través de su integración con
otras. Hasta la versión MX, fue duramente criticado por su escaso soporte de los
estándares de la web, ya que el código que generaba era con frecuencia sólo válido
para Internet Explorer, y no validaba como HTML estándar. Esto se ha ido corrigiendo
en las versiones recientes.
La gran ventaja de este editor sobre otros es su gran poder de ampliación y
personalización del mismo, puesto que en este programa, sus rutinas (como la de
insertar un hipervínculo, una imagen o añadir un comportamiento) están hechas en
Java script C, lo que le ofrece una gran flexibilidad en estas materias. Esto hace que los
archivos del programa no sean instrucciones de C++ sino, rutinas de Java script que
hace que sea un programa muy fluido, que todo ello hace, que programadores y
editores web hagan extensiones para su programa y lo ponga a su gusto.
Las versiones originales de la aplicación se utilizaban como simples editores WYSIWYG.
Sin embargo, versiones más recientes soportan otras tecnologías web como CSS, Java
Script y algunos frameworks del lado servidor.
Dreamweaver ha tenido un gran éxito desde finales de los 90 y actualmente mantiene
el 90% del mercado de editores HTML. Esta aplicación está disponible tanto para la
plataforma MAC como para Windows, aunque también se puede ejecutar en
plataformas basadas en UNIX utilizando programas que implementan las API's de
Windows, tipo Wine.
Como editor WYSIWYG que es, Dreamweaver permite ocultar el código HTML de cara
al usuario, haciendo posible que alguien no entendido pueda crear páginas y sitios web
fácilmente sin necesidad de escribir código.
118
http://php-runner.uptodown.com/
138
Algunos desarrolladores web criticaban está propuesta ya que crean páginas HTML
más largas de lo que solían ser al incluir mucho código inútil, lo cual va en detrimento
de la ejecución de las páginas en el navegador web. Estó puede ser especialmente
cierto ya que la aplicación facilita en exceso el diseño de las páginas mediante tablas.
Además, algunos desarrolladores web han criticado Dreamweaver en el pasado porque
creaba código que no cumplía con los estándares del consorcio Web (W3C).
No obstante, Adobe ha aumentado el soporte CSS y otras maneras de diseñar páginas
sin tablas en versiones posteriores de la aplicación, haciendo que se reduzca el exceso
de código.
Dreamweaver permite al usuario utilizar la mayoría de los navegadores Web instalados
en su ordenador para pre visualizar las páginas web. También dispone de herramientas
de administración de sitios dirigidas a principiantes como, por ejemplo, la habilidad de
encontrar y reemplazar líneas de texto y código por cualquier tipo de parámetro
especificado, hasta el sitio web completo. El panel de comportamientos también
permite crear Java Script básico sin conocimientos de código.
Con la llegada de la versión MX, Macromedia incorporó herramientas de creación de
contenido dinámico en Dreamweaver. En lo fundamental de las herramientas HTML
WYSIWYG, también permite la conexión a bases de datos como MySQL y Microsoft
Access, para filtrar y mostrar el contenido utilizando tecnología de script como, por
ejemplo, ASP (Active Server Pages), ASP.NET, ColdFusion, JSP (JavaServer Pages) y PHP
sin necesidad de tener experiencia previa en programación.
Un aspecto de alta consideración de Dreamweaver es su arquitectura extensible. Es
decir, permite el uso de "Extensiones". Las extensiones, tal y como se conocen, son
pequeños programas, que cualquier desarrollador web puede escribir (normalmente
en HTML y Java script) y que cualquiera puede descargar e instalar, ofreciendo así
funcionalidades añadidas a la aplicación. Dreamweaver goza del apoyo de una gran
comunidad de desarrolladores de extensiones que hacen posible la disponibilidad de
extensiones gratuitas y de pago para la mayoría de las tareas de desarrollo web, que
van desde simples efectos rollover hasta completas cartas de compra.
También podría decirse, que para un diseño más rápido y a la vez fácil podría
complementarse con fireworks en donde podría uno diseñar un menú o para otras
creaciones de imágenes (gif web, gif websnap, gif adaptable, JPEG calidad superior,
JPEG archivo más pequeño, gif animado websnap) para un sitio web y después
exportar la imagen creada y así utilizarla como una sola, en donde ya llevara los
vínculos a un dicho sitio en especifico que uno le haya dado119.
1.4.5 JAVA SCRIPT
Java script es un lenguaje de programación interpretado dialecto del estándar
ECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo,
débilmente tipado y dinámico.
119
http://es.wikipedia.org/wiki/Adobe_Dreamweaver
139
Se utiliza principalmente en su forma del lado del cliente (client-side), implementado
como parte de un navegador web permitiendo mejoras en la interfaz de usuario y
páginas web dinámicas, aunque existe una forma de Java script del lado del servidor
(Server-side Java script o SSJS). Su uso en aplicaciones externas a la web, por ejemplo
en documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) es también
significativo.
Java Script se diseñó con una sintaxis similar al C, aunque adopta nombres y
convenciones del lenguaje de programación Java. Sin embargo Java y Java script no
están relacionados y tienen semánticas y propósitos diferentes.
Todos los navegadores modernos interpretan el código Java Script integrado en las
páginas web. Para interactuar con una página web se provee al lenguaje Java Script de
una implementación del Document Object Model (DOM).
Tradicionalmente se venía utilizando en páginas web HTML para realizar operaciones y
únicamente en el marco de la aplicación cliente, sin acceso a funciones del servidor.
Java Script se interpreta en el agente de usuario, al mismo tiempo que las sentencias
van descargándose junto con el código HTML.120
1.5 DIAGRAMA DE DISEÑO
1.5.1 DIAGRAMA DE CASOS DE USO
Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). Los
Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir,
describen un uso del sistema y cómo este interactúa con el usuario. En los casos de uso
no importantes son los diagramas, sino lo realmente útil de los casos de uso es el
documento que describe el caso de uso, en este documento se explica la forma de
interactuar entre el sistema y el usuario121.
Un Caso de uso es empleado con más frecuencia en alguna de las siguientes etapas:
-
Determinación de Requerimientos: Por lo general nuevos requerimientos de
sistema generan nuevos casos-usos, conforme es analizado y diseñado el
sistema.
-
Comunicación con el Cliente: Debido a la sencillez de este tipo de diagramas,
son fáciles de emplear para comunicarse con el cliente final del proyecto.
120
http://es.wikipedia.org/wiki/JavaScript
http://www.ingenierosoftware.com/analisisydiseno/uml.php
http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso
121
140
-
Generación de pruebas de Sistemas: A través de los diagramas uso-caso se
pueden generar una serie de pruebas de sistema.122
1.5.2 ELEMENTOS DE UN DIAGRAMA DE CASOS DE USO
-
Actor: Un actor representa quién o que inicia una acción dentro del sistema, en
otras palabras, es simplemente un papel que es llevado acabo por una persona
o cosa. Un Actor en un diagrama Caso-Uso es representado por una figura en
forma de persona.
Figura 1.13: Actor
-
Uso-Caso: El uso-caso en sí es representado por un óvalo que describe la
funcionalidad grosso modo que se requiere por el sistema.
Figura 1.14: Caso de Usos
-
Comunicación: Este elemento representa la relación que existe entre un UsoCaso y un Actor, dicho elemento es representado simplemente por una línea
recta que se extiende de la figura del actor hacia el óvalo del caso de uso.
Figura 1.15: Comunicación
-
Límite de Sistema (System Boundry): Empleado para delimitar los límites del
sistema, y representado por un rectángulo con color de fondo distintivo.
-
Generalización: indica que un caso de uso (óvalo) es un caso especial de otro
caso, en otros términos, representa una relación padre-hijo, donde el hijo
puede ser suplido directamente por el padre en cualquier momento. Este
elemento es representado por una línea con flecha que se extiende del usocaso hijo hacia el uso caso
padre (general).
Figura 1.16: Generalización
122
http://www2.uah.es/jcaceres/uploaded/capsulas/DiagramaCasosDeUso.pdf
141
-
Inclusión: es utilizada para indicar que un caso de uso (óvalo) depende de otro
caso, significa que la funcionalidad de determinado caso se requiere para
realizar las tareas de otro. Este elemento es representado por una línea
punteada con flecha y comentario <<include>> que se extiende del uso-caso
base hacia el uso caso de inclusión.
Figura 1.17: Inclusión
-
Extensión: representa una dependencia específica, mientras una generalización
no implica que los casos de uso dependen uno del otro. Este elemento es
representado por una línea punteada con flecha y comentario <<extend>> que
origina el caso de uso con base hacia el caso de uso de extensión. 123
Figura 1.18: Extensión
1.6 SISTEMA INFORMÁTICO
Un Sistema Informático como todo sistema, es el conjunto de partes interrelacionadas,
una computadora que usa dispositivos programables para capturar, almacenar y
procesar datos. La computadora personal o PC, junto con la persona que lo maneja y
los periféricos que los envuelven, resultan de por sí un ejemplo de un sistema
informático.
Incluso la computadora más sencilla se clasifica como un sistema informático, porque
al menos dos componentes (hardware y software) tienen que trabajar unidos. Pero el
123
http://www.osmosislatina.com/lenguajes/uml/casos.htm
142
genuino significado de "sistema informático" viene mediante la interconexión. Muchos
sistemas informáticos pueden interconectarse, esto es, unirse para convertirse un
sistema mayor. La interconexión de sistemas informáticos puede tornarse difícil
debido a incompatibilidades. A veces estas dificultades ocurren sobre el hardware,
mientras que en otras ocasiones se dan entre programas informáticos que no son
compatibles entre sí.
Los diseñadores de sistemas informáticos no necesariamente esperan que sus sistemas
se puedan interconectar con otros sistemas. Por otro lado, técnicamente eruditos a
menudo pueden configurar sistemas diferentes para que se puedan comunicar entre sí
usando un conjunto de reglas y restricciones conocidas como protocolos. Los
protocolos tratan precisamente de definir la comunicación dentro de y entre sistemas
informáticos distintos pero conectados entre sí. Si dos sistemas informáticos usan el
mismo protocolo, entonces podrán ser capaces de interconectarse y formar parte de
un sistema mayor124.
1.7 ARQUITECTURA DE LA APLICACIÓN
1.7.1 ARQUITECTURA CLIENTE / SERVIDOR
Esta arquitectura consiste básicamente en que un programa, el Cliente informático
realiza peticiones a otro programa, el servidor, que les da respuesta.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los
servidores, aunque son más importantes las ventajas de tipo organizativo debido a la
centralización de la gestión de la información y la separación de responsabilidades, lo
que facilita y clarifica el diseño del sistema.
-
-
Front/end
•
•
Es la parte de la aplicación que interactúa con el usuario.
Basados en una interfaz gráfica con el usuario. El Cliente corre la
aplicación que ofrece la interfaz con el usuario.
•
Es la parte no-interactiva de la aplicación. La mayor parte reside
en las bases de datos (relacionales o no)125.
Back/end
1.7.2 MODELO DE ARQUITECTURA CLIENTE / SERVIDOR
124
125
http://es.wikipedia.org/wiki/Sistema_informático
http://www.estudiagratis.com
143
-
Aplicaciones Simples: no requieren una gran base de datos compartida,
pueden ser elaboradas solamente en el Cliente.
-
Aplicaciones Complejas: exigen dos capas, una para la aplicación del usuario
(Cliente) y otra para la base de datos (Servidor).
Eventualmente, el Cliente y el Servidor podrán estar en el mismo equipamiento.
Existen herramientas de amplio uso que presuponen esta estructura por ejemplo
Visual Basic, Access, SQL Server. Estas arquitecturas fueron las primeras en
aprovecharse de la estructura cliente-servidor (aplicaciones en los clientes, base de
datos como servidor). Las desventajas de dos niveles son bien conocidas:
•
•
•
•
El nivel de las aplicaciones se recargan, entremezclando aspectos típicos del
manejo de la interfaz con las reglas del negocio.
Las reglas del negocio quedan dispersas entre el nivel de aplicación y los
“stored procedures” de la base de datos.
La aplicación queda sobrecargada de información de bajo nivel si hay que
extraer los datos de varias bases de datos, posiblemente con estructuras
diferentes.
El nivel de aplicación puede ser demasiado pesado para el cliente.126
NIVEL
Aplicativo del Usuario
Reglas de Negocios
Administración de Datos
CONTENIDO
Aplicaciones de PC e interfaces gráficas
Reglas de Negocio y Procesos de Cálculo
Base de Datos (Relacionales y SQL)
Tabla 1.7: Aplicaciones Complejas
Fuente: http://www.galeon.com/zuloaga/Doc/ArqCapasSI.doc
1.8 CICLO DE VIDA EN V
Este ciclo fue diseñado por Alan Davis. Es un ciclo de vida que admite iteraciones,
después de cada etapa se realiza una o varias revisiones para comprobar si se puede
pasar a la siguiente. Es un modelo rígido, poco flexible y con muchas restricciones, se le
agregaron dos sub etapas de retroalimentación entre las etapas de análisis y
mantenimiento y entre las de diseño y debugging.
126
http://www.galeon.com/zuloaga/Doc/ArqCapasSI.doc
144
Figura 1.19: Ciclo de Vida
Fuente: http://www.ciclo_de_vida_en_v.com
Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si bien son simples
(pequeñas transacciones sobre bases de datos por ejemplo), necesitan una
confiabilidad muy alta. Un ejemplo claro en el que no nos podemos permitir el lujo de
cometer errores es una aplicación de facturación. En la que si bien los procedimientos
vistos individualmente son de codificación e interpretación sencilla, la aplicación en su
conjunto puede tener matices complicados.127
1.9 METODOLOGÍA XP
Esta metodología promueve los siguientes valores:
127
-
Comunicación: El eXtreme Programming se nutre del ancho de banda más
grande que se puede obtener cuando existe algún tipo de comunicación: la
comunicación directa entre personas. Es muy importante entender cuáles son
las ventajas de este medio. Cuando dos (o más) personas se comunican
directamente pueden no solo consumir las palabras formuladas por la otra
persona, sino que también aprecian los gestos, miradas, etc. que hace su
compañero. Sin embargo, en una conversación mediante el correo electrónico,
hay muchos factores que hacen de esta una comunicación, por así decirlo,
mucho menos efectiva.
-
Coraje: El coraje es un valor muy importante dentro de la programación
extrema. Un miembro de un equipo de desarrollo extremo debe de tener el
coraje de exponer sus dudas, miedos, experiencias sin "embellecer" éstas de
ninguna de las maneras. Esto es muy importante ya que un equipo de
http://www.ciclo_de_vida_en_v.com
145
desarrollo extremo se basa en la confianza para con sus miembros. Faltar a esta
confianza es una falta más que grave.
-
Simplicidad: Dado que no se puede predecir cómo va a ser en el futuro, el
software que se está desarrollando; un equipo de programación extrema
intenta mantener el software lo más sencillo posible. Esto quiere decir que no
se va a invertir ningún esfuerzo en hacer un desarrollo que en un futuro pueda
llegar a tener valor. En el XP frases como en un futuro vamos a necesitar o "Haz
un sistema genérico que" no tienen ningún sentido ya que no aportan ningún
valor en el momento.
-
Feedback: La agilidad se define (entre otras cosas) por la capacidad de
respuesta ante los cambios que se van haciendo necesarios a lo largo del
camino. Por este motivo uno de los valores que nos hace más ágiles es el
continuo seguimiento o feedback que recibimos a la hora de desarrollar en un
entorno ágil de desarrollo. Este feedback se toma del cliente, de los miembros
del equipo, en cuestión de todo el entorno en el que se mueve un equipo de
desarrollo ágil.
Para ello se fundamenta en las siguientes doce prácticas:
-
Planificación incremental
La Programación Extrema asume que la planificación nunca será perfecta, y que
variará en función de cómo varíen las necesidades del negocio. Por tanto, el
valor real reside en obtener rápidamente un plan inicial, y contar con
mecanismos de feedback que permitan conocer con precisión dónde estamos.
Como es lógico, la planificación es iterativa: un representante del negocio
decide al comienzo de cada iteración qué características concretas se van a
implementar.
El objetivo de la XP es generar versiones de la aplicación tan pequeñas como
sea posible, pero que proporcionen un valor adicional claro, desde el punto de
vista del negocio. A estas versiones se las denomina releases.
Una release cuenta con un cierto número de historias. La historia es la unidad
de funcionalidad en un proyecto XP, y corresponde a la mínima funcionalidad
posible que tiene valor desde el punto de vista del negocio. Durante cada
iteración se cierran varias historias, lo que hace que toda iteración añada un
valor tangible para el cliente.
Es fundamental en toda esta planificación la presencia de un representante del
cliente, que forma parte del equipo y que decide cuáles son las historias más
valiosas. Estas historias son las que se desarrollarán en la iteración actual.
146
La obtención de feedback que permita llevar a cabo estimaciones precisas es
fundamental. Se hacen estimaciones para cada historia, de modo que en
cuanto se comienzan a tener datos históricos, éstos se utilizan para hacer que
las siguientes estimaciones sean más precisas.
Como se puede ver, y como siempre ocurre con la Programación Extrema, el
enfoque utilizado para llevar a cabo la planificación es eminentemente
pragmático. Gran parte de la eficacia de este modelo de planificación deriva de
una división clara de responsabilidades, que tiene en cuenta las necesidades
del negocio en todo momento. Dentro de esta división, el representante del
cliente tiene las siguientes responsabilidades:
•
•
•
Decidir qué se implementa en cada release o iteración.
Fijar las fechas de fin de la release, recortando unas características o
añadiendo otras.
Priorizar el orden de implementación, en función del valor de negocio.
Las responsabilidades del equipo de desarrollo son las siguientes:
•
•
•
•
•
-
Estimar cuánto tiempo llevará una historia: este feedback es
fundamental para el cliente, y puede llevarle a reconsiderar qué
historias se deben incluir en una iteración.
Proporcionar información sobre el coste de utilizar distintas opciones
tecnológicas.
Organizar el equipo.
Estimar el riesgo de cada historia.
Decidir el orden de desarrollo de historias dentro de la iteración.
Testing
La ejecución automatizada de test es un elemento clave de la XP. Existen tanto
test internos o test de unidad, para garantizar que el mismo es correcto, como
test de aceptación, para garantizar que el código hace lo que debe hacer. El
cliente es el responsable de definir los test de aceptación, no necesariamente
de implementarlos. Él es la persona mejor cualificada para decidir cuál es la
funcionalidad más valiosa.
El hecho de que los test sean automatizados es el único modo de garantizar
que todo funciona: desde el punto de vista de la XP, si no hay test, las cosas
sólo funcionan en apariencia. Aún más, si un test no está automatizado, no se
le puede considerar como tal.
El objetivo de los test no es corregir errores, sino prevenirlos. Por ejemplo, los
test siempre se escriben antes que el código a testear, no después: esto aporta
un gran valor adicional, pues fuerza a los desarrolladores a pensar cómo se va a
usar el código que escriben, poniéndolos en la posición de consumidores del
147
software. Elaborar los test exige pensar por adelantado cuáles son los
problemas más graves que se pueden presentar, y cuáles son los puntos
dudosos. Esto evita muchos problemas y dudas, en lugar de dejar que
aparezcan "sobre la marcha".
Un efecto lateral importante de los test es que dan una gran seguridad a los
desarrolladores: es posible llegar a hacer cambios más o menos importantes sin
miedo a problemas inesperados, dado que proporcionan una red de seguridad.
La existencia de test hace el código muy maleable.
-
Programación en parejas
La XP incluye, como una de sus prácticas estándar, la programación en parejas.
Nadie programa solo, siempre hay dos personas delante del ordenador. Ésta es
una de las características que más se cuestiona al comienzo de la adopción de
la XP dentro de un equipo, pero en la práctica se acepta rápidamente y de
forma entusiasta.
El principal argumento contra la programación en parejas es que es
improductiva. Esta idea se basa en el hecho de que dos programadores
"programan el doble por separado". Esto sería así si no fuera por las siguientes
razones:
•
•
•
•
•
•
El hecho de que todas las decisiones las tomen al menos dos personas
proporciona un mecanismo de seguridad enormemente valioso.
Con dos personas responsabilizándose del código en cada momento, es
menos probable que se caiga en la tentación de dejar de escribir tests,
etc., algo fundamental para mantener el código en buena forma. Es muy
difícil que dos personas se salten tareas por descuido o negligencia.
El hecho de programar en parejas permite la dispersión de know-how
por todo el equipo. Este efecto es difícil de conseguir de otro modo, y
hace que la incorporación de nuevos miembros al equipo sea mucho
más rápida y eficaz.
El código siempre está siendo revisado por otra persona. La revisión de
código es el método más eficaz de conseguir código de calidad, algo
corroborado por numerosos estudios, muchos de los cuales son
anteriores a la Programación Extrema.
En contra de lo que pueda parecer, los dos desarrolladores no hacen lo
mismo: mientras el que tiene el teclado adopta un papel más táctico, el
otro adopta un papel más estratégico, preguntándose constantemente
si lo que se está haciendo tiene sentido desde un punto de vista global.
Los datos indican que la programación en parejas es realmente más
eficiente. Si bien se sacrifica un poco de velocidad al comienzo, luego se
obtiene una velocidad muy superior. Esto contrasta con lo que ocurre
en la mayor parte de los proyectos, en los que se arranca con una
velocidad enorme pero rápidamente se llega a un estado muy parecido
a la parálisis, en el que progresos cada vez más pequeños consumen
148
cantidades de tiempo cada vez más grandes. Todos conocemos
proyectos que se pasan el 50% del tiempo en el estado de "finalizado al
90%".
-
Refactorización
A la hora de la verdad, el código de la mayor parte de las aplicaciones empieza
en un razonable buen estado, para luego deteriorarse de forma progresiva. El
coste desorbitado del mantenimiento, modificación y ampliación de
aplicaciones ya existente se debe en gran parte a este hecho.
Uno de los objetivos de la XP es mantener la curva de costes tan plana como
sea posible, por lo que existen una serie de mecanismos destinados a mantener
el código en buen estado, modificándolo activamente para que conserve
claridad y sencillez. A este proceso básico para mantener el código en buena
forma se le llama refactorización.
La refactorización no sólo sirve para mantener el código legible y sencillo:
también se utiliza cuando resulta conveniente modificar código existente para
hacer más fácil implementar nueva funcionalidad.
-
Diseño simple
Otra práctica fundamental de la Programación Extrema es utilizar diseños tan
simples como sea posible. El principio es "utilizar el diseño más sencillo que
consiga que todo funcione". Se evita diseñar características extra porque a la
hora de la verdad la experiencia indica que raramente se puede anticipar qué
necesidades se convertirán en reales y cuáles no. La XP nos pide que no
vivamos bajo la ilusión de que un diseño puede resolver todas o gran parte de
las situaciones futuras: lo que parece necesario cambia con frecuencia, es difícil
acertar.
Es obvio que, si no vamos a anticipar futuras necesidades, debemos poder
modificar el diseño si alguna de esta se materializa. La XP soporta estas
modificaciones gracias a los tests automatizados. Estos permiten hacer cambios
importantes gracias a la red de protección que proporcionan. La
refactorización, que hace que el código existente sea claro y sencillo, también
ayuda a hacer factibles las modificaciones.
La XP define un "diseño tan simple como sea posible" como aquél que:
•
•
•
•
-
Pasa todos los tests.
No contiene código duplicado.
Deja clara la intención de los programadores (enfatiza el qué, no el
cómo) en cada línea de código.
Contiene el menor número posible de clases y métodos.
Propiedad colectiva del código
149
La XP aboga por la propiedad colectiva del código. En otras palabras, todo el
mundo tiene autoridad para hacer cambios a cualquier código, y es responsable
de ellos. Esto permite no tener que estar esperando a otros cuando todo lo que
hace falta es algún pequeño cambio.
Por supuesto, cada cuál es responsable de las modificaciones que haga. El
principio básico es "tú lo rompes, tú lo arreglas, no importa si está en el código
propio o en el de otros". Por último, vale la pena tener en cuenta que la
existencia de tests automatizados impide que se produzca un desarrollo
anárquico, al ser cada persona responsable de que todos los tests se ejecuten
con éxito al incorporar los cambios que ha introducido al programa.
-
Integración continua
En muchos casos la integración de código produce efectos laterales
imprevistos, y en ocasiones la integración puede llegar a ser realmente
traumática, cuando dejan de funcionar cosas por motivos desconocidos. La
Programación Extrema hace que la integración sea permanente, con lo que
todos los problemas se manifiestan de forma inmediata, en lugar de durante
una fase de integración más o menos remota.
La existencia de una fase de integración separada tiene dos efectos laterales
indeseables: se empieza a hacer codificación yo-yo, en la que todo el mundo
modifica código "sólo para que funcione, ya lo ajustaremos", y hace que se
acumulen defectos. Evitar que se acumulen defectos es muy importante para la
XP, como lo es el conseguir que los defectos que cada programador inyecta los
elimine él mismo.
-
Cliente en el equipo
Algunos de los problemas más graves en el desarrollo son los que se originan
cuando el equipo de desarrollo toma decisiones de negocios críticos. Esto no
debería ocurrir, pero a la hora de la verdad con frecuencia no se obtiene
feedback del cliente con la fluidez necesaria: el resultado es porque se ha de
optar por detener el avance de los proyectos, o por que desarrollo tome una
decisión de negocio. Por otra parte, los representantes del negocio también
suelen encontrarse con problemas inesperados debido a que tampoco reciben
el feedback adecuado por parte de los desarrolladores.
La XP intenta resolver este tipo de problemas integrando un representante del
negocio dentro del equipo de desarrollo. Ésta persona siempre está disponible
para resolver dudas y para decidir qué y qué no se hace en cada momento, en
función de los intereses del negocio. Debido a su inmersión dentro del equipo,
y a que es él quien decide qué y qué no se hace, junto con los tests que
verifican si la funcionalidad es la correcta y deseada, esta persona obtiene un
feedback absolutamente realista del estado del proyecto.
-
Releases pequeñas
150
Siguiendo la política de la XP de dar el máximo valor posible en cada momento,
se intenta liberar nuevas versiones de las aplicaciones con frecuencia. Éstas
deben ser tan pequeñas como sea posible, aunque deben añadir suficiente
valor como para que resulten valiosas para el cliente.
-
Semanas de 40 horas
La Programación Extrema lleva a un modo de trabajo en que el equipo está
siempre al 100%. Una semana de 40 horas en las que se dedica la mayor parte
del tiempo a tareas que suponen un avance puede dar mucho de sí, y hace
innecesario recurrir a sobreesfuerzos -excepto en casos extremos.
Además, el sobreesfuerzo continuado pronto lleva a un rendimiento menor y a
un deterioro de la moral de todo el equipo.
-
Estándares de codificación
Para conseguir que el código se encuentre en buen estado y que cualquier
persona del equipo pueda modificar cualquier parte del código es
imprescindible que el estilo de codificación sea consistente. Un estándar de
codificación es necesario para soportar otras prácticas de la XP.
Sin embargo, la XP también es pragmática en esto, y apuesta por establecer un
número mínimo de reglas: el resto se irán pactando de-facto. Esto evita un
ejercicio inicial más o menos estéril.
-
Uso de Metáforas
La comunicación fluida es uno de los valores más importantes de la
Programación Extrema: la programación en parejas, el hecho de incorporar al
equipo una persona que represente los intereses del negocio y otras prácticas
son valiosas entre otras cosas porque potencian enormemente la
comunicación.
Para conseguir que la comunicación sea fluida es imprescindible, entre otras
cosas, utilizar el vocabulario del negocio. También es fundamental huir de
definiciones abstractas. Dicho de otro modo, la XP no pretende seguir la letra
de la ley, sino su espíritu. Dentro de este enfoque es fundamental buscar
continuamente metáforas que comuniquen intenciones y resulten descriptivas,
enfatizando el qué por delante del cómo.
La metodología XP es una metodología ágil:
•
Los individuos e interacciones son más importantes que los procesos y
herramientas.
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de éxito de un proyecto software.
151
Es más importante construir un buen equipo que construir el entorno. Muchas
veces se comete el error de construir primero el entorno y esperar que el
equipo se adapte automáticamente. Es mejor crear el equipo y que éste
configure su propio entorno de desarrollo sobre la base a sus necesidades.
•
Software que funcione es más importante que documentación exhaustiva.
Desarrollar software que funciona más que conseguir una buena
documentación. La regla a seguir es “no producir documentos a menos que
sean necesarios de forma inmediata para tomar una decisión importante”.
Estos documentos deben ser cortos y centrarse en lo fundamental.
•
La colaboración con el cliente es más importante que la negociación de
contratos. Se propone que exista una interacción constante entre el cliente y el
equipo de desarrollo. Esta colaboración entre ambos será la que marque la
marcha del proyecto y asegure su éxito.
•
La respuesta ante el cambio es más importante que el seguimiento de un plan.
La habilidad de responder a los cambios que puedan surgir a lo largo del
proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.)
determina también el éxito o fracaso del mismo. Por lo tanto, la planificación
no debe ser estricta sino flexible y abierta.128
1.10
DOCUMENTOS DE DESARROLLO
1.10.1 DECLARACIÓN DE REQUISITOS
1.10.1.1
ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE - IEEE 830
Es un documento que ayuda a los clientes o compradores a describir con precisión lo
que quieren obtener, a los suministradores a comprender exactamente lo que el
cliente quiere, a los individuos al cargo de desarrollar una especificación de requisitos
del software (ERS) normalizada para su organización, de definir el formato y contenido
de esas especificaciones, o bien de comprobar su calidad.
Los beneficios de una buena ERS son evidentes:
128
Servir como base para el acuerdo entre cliente y proveedor sobre lo que el
software ha de hacer.
Reducir el esfuerzo de desarrollo
Proporcionar la base para la estimación de costes y plazos
Proporcionar el punto de partida para las actividades de validación y
verificación
Facilitar la transferencia del software, a nuevos usuarios o nuevas máquinas
Servir de base para ampliaciones o mejoras
http://oness.sourceforge.net/proyecto/html/ch05.html
152
La norma está orientada fundamentalmente a la especificación de requisitos para
software cuyo desarrollo se va a contratar, pero puede aplicarse también como ayuda
en la selección de productos software comercial o desarrollado internamente.
Cuando el software está integrado en sistemas más amplios, como por ejemplo
equipos de medicina, es probable que haya que tratar aspectos adicionales a los
contemplados por esta norma.
Esta "práctica recomendada" describe el proceso de creación de un producto (la
especificación de requisitos del software o ERS) y el contenido del producto en sí.
Puede utilizarse directamente o como modelo para una norma más específica129.
-
129
EJEMPLO DE LA PLANTILLA
http://dis.um.es/~lopezquesada/documentos/FIS_0607/recursos/AnexoIIITema2.pdf
153
Especificación de requisitos de software
ERSoftware (basado en plantilla IEEE 830)
Proyecto: [Nombre del proyecto]
Revisión [99.99]
Ficha del documento
Fecha
Revisión
Autor
Verificado dep. calidad.
154
[Fecha]
[Rev]
[Descripción]
[Firma o sello]
Documento validado por las partes en fecha: [Fecha]
Por el cliente
Fdo. D./ Dña [Nombre]
Por la empresa suministradora
Fdo. D./Dña [Nombre]
INTRODUCCIÓN
Este documento presenta los requerimientos específicos funcionales de la
aplicación a construir, se convierte en el referente para la etapa de diseño y
posteriormente se lo utilizará para la validación del producto de software
Propósito
- Determinar los requisitos específicos de la aplicación.
- Determinar las funcionalidades operativas de la aplicación.
155
-
Determinar la operatividad de la aplicación para el proceso de
validación.
Documentar las funcionalidades requeridas para posterior
mantenimiento de la aplicación por parte de los técnicos de
desarrollo
-
Propósito del documento
Audiencia a la que va dirigido
Alcance
- La aplicación a construir se denomina……………, XYZ v1.0 por sus
siglas
- La misma definición y nombre se encuentran determinados en el
documento ERSistema que antecede a este documento.
PERSONAL INVOLUCRADO
Nombre
Rol
Categoría profesional
Responsabilidades
Información de
contacto
Aprobación
Nombre
Rol
Responsabilidades
Información de
contacto
Aprobación
DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS
•
•
•
•
- Acrónimos
CdU: Caso de uso
HdU: Historia de Usuario
TCP/IP, Transport control Protocol Internet Protocol
PDC, Primary domain Controler, Controlador Primario de dominio
-
Definiciones
156
•
•
•
IEEE1326.- Estándar que determina la especificación de requisitos
de sistema para la construcción y puesta en marcha de
aplicaciones de softwareIEEE830.- Especificación de Requisitos de Software.
Administrar.- En informática se refiere a las operaciones de alta,
baja, eliminación, modificación y consulta de datos.
Cambiar estas definiciones si fuera necesario de acuerdo a las definidas en el
proyecto del concurso. Definición de todos los términos, abreviaturas y
acrónimos necesarios para interpretar apropiadamente este documento. En
ella se pueden indicar referencias a uno o más apéndices, o a otros
documentos.
REFERENCIAS
Referencia
Titulo
Ruta
Fecha
Autor
Adicione las referencias utilizadas, siga el ejemplo citado, inclusive ya esta
colocada la primera referencia acerca del ERSistema. Relación completa de
todos los documentos relacionados en la especificación de requisitos de
software, identificando de cada documento el título, referencia (si procede),
fecha y organización que lo proporciona.
RESUMEN
El contenido de este documento consta de: Introducción que induce al
conocimiento específico de la aplicación a construir, descripción general de la
aplicación a construir, definición de los requisitos específicos de la aplicación y
anexos si acaso existieren.
DESCRIPCIÓN GENERAL
Perspectiva del producto
EJEMPLO La aplicación XYZ V1.0 que se desea crear es parte de un
sistema ya existente dentro de los laboratorios de la PUCESI y tiene
relación directa con las listas de restricciones de la aplicación SQUID que
sirve de proxificador y la base de datos del ACTIVE DIRECTORY del
servidor de dominio primario que se encuentra en WINDOWS SERVER
2003.
157
(Incluir un diagrama de bloques de la relación de sistemas)
Diríjase por el ejemplo, cambie solo lo necesario, además, Indicar si es un
producto independiente o parte de un sistema mayor. En el caso de
tratarse de un producto que forma parte de un sistema mayor, un
diagrama que sitúe el producto dentro del sistema e identifique sus
conexiones facilita la comprensión.
FUNCIONALIDAD DEL PRODUCTO
Deben identificarse las prioridades entre funcionalidades y características. Esta
identificación puede realizarse clasificando cada una las funciones,
características y capacidades como esencial, deseado u opcional.
Deben incluirse a medida que lo sea posible: Diagramas, flujos y procesos con
un nivel de detalle suficiente para comprender la función o un conjunto de
funciones del sistema propuesto desde el punto de vista del usuario.
-
Identificación de interacciones entre componentes del sistema.
Descripción del entorno de operación y sus características
Interacción del sistema con otros sistemas externos
Características de rendimiento como velocidad, rendimiento de
trabajo, volumen, frecuencia, etc.
Atributos de calidad como disponibilidad, eficiencia, flexibilidad,
portabilidad, reusabilidad, usabilidad, etc.
Provisiones de seguridad, emergencia, privacidad y continuidad
de las operaciones en circunstancias de emergencia.
Otro tipo de información relevante en la descripción del sistema
como: factores de riesgo, coste de las operaciones, etc.
Resumen de las funcionalidades principales que el producto debe realizar, sin
entrar en información de detalle.
En ocasiones la información de esta sección puede tomarse de un documento
de especificación del sistema de mayor nivel (ej. Requisitos del sistema).
Las funcionalidades deben estar organizadas de manera que el cliente o
cualquier interlocutor puedan entenderlo perfectamente. Para ello se pueden
utilizar métodos textuales o gráficos.
CARACTERÍSTICAS DE LOS USUARIOS
Tipo de usuario
Formación
Habilidades
Actividades
Tipo de usuario
Formación
158
Habilidades
Actividades
Tipo de usuario
Formación
Habilidades
Actividades
Tipo de usuario
Formación
Habilidades
Actividades
Descripción de los usuarios del producto, incluyendo nivel educacional,
experiencia y experiencia técnica.
RESTRICCIONES
Descripción de aquellas limitaciones a tener en cuenta a la hora de diseñar y
desarrollar el sistema, tales como el empleo de determinadas metodologías de
desarrollo, lenguajes de programación, normas particulares, restricciones de
hardware, de sistema operativo etc.
SUPOSICIONES Y DEPENDENCIAS
Descripción de aquellos sobre factores que, si cambian, pueden afectar a los
requisitos. Por ejemplo una asunción puede ser que determinado sistema
operativo está disponible para el hardware requerido. De hecho, si el sistema
operativo no estuviera disponible, la SRS debería modificarse.
REQUISITOS ESPECÍFICOS
Esta es la sección más extensa y más importante del documento.
Debe contener una lista detallada y completa de los requisitos que debe
cumplir el sistema a desarrollar. El nivel de detalle de los requisitos debe ser el
suficiente para que el equipo de desarrollo pueda diseñar un sistema que
satisfaga los requisitos y los encargados de las pruebas puedan determinar si
éstos se satisfacen.
Los requisitos se dispondrán en forma de listas numeradas para su
identificación, seguimiento, trazabilidad y validación (ej. RF 10, RF 10.1, RF
10.2,...).
Para cada requisito debe completarse la siguiente tabla:
Número de requisito
[Inserte aquí el texto]
159
Nombre de requisito
Tipo
Fuente del requisito
Prioridad del requisito
Descripción (CDU)
Requisito
Restricción
Alta/Esencial
Media/Deseado
CdU_XYZ-R.1
Baja/
Opcional
y realizar la descripción del requisito
La distribución de los párrafos que forman este punto puede diferir del
propuesto en esta plantilla, si las características del sistema aconsejan otra
distribución para ofrecer mayor claridad en la exposición.
REQUISITOS COMUNES DE LAS INTERFACES
A continuación se detallan las interfaces de la aplicación:
Descripción detallada de todas las entradas y salidas del sistema de software.
Interfaces de usuario
Describir los requisitos del interfaz de usuario para el producto. Esto
puede estar en la forma de descripciones del texto o pantallas del
interfaz. Por ejemplo posiblemente el cliente ha especificado el estilo y
los colores del producto. Describa exacto cómo el producto aparecerá a
su usuario previsto.
Interfaces de software
Si existieran indicar aquí, caso contrario eliminar este punto
Indicar si hay que integrar el producto con otros productos de software.
Para cada producto de software debe especificarse lo siguiente:
-
Descripción del producto software utilizado
Propósito del interfaz
Definición del interfaz: contiendo y formato
Las interfaces de software son las siguientes:
- Active directory de win Svr 2003; suple los nombres de los
usuarios del PDC, formato establecido para AD (p.e. csv, xlsx)
- Squid v x.y; suple las listas de restricciones del proxy; texto en
columnado
Interfaces de comunicación
Describir los requisitos del interfaces de comunicación si hay
comunicaciones con otros sistemas y cuales son los protocolos de
comunicación.
REQUISITOS FUNCIONALES
160
Definición de acciones fundamentales que debe realizar el software al recibir
información, procesarla y producir resultados.
En ellas se incluye:
-
Comprobación de validez de las entradas
Secuencia exacta de operaciones
Respuesta a situaciones anormales (desbordamientos,
comunicaciones, recuperación de errores)
Parámetros
Generación de salidas
Relaciones entre entradas y salidas (secuencias de entradas y
salidas, formulas para la conversión de información)
Especificación de los requisitos lógicos para la información que
será almacenada en base de datos (tipo de información,
requerido)
Los requisitos funcionales pueden ser divididos en sub-secciones.
Requisito funcional 1
Requisito funcional 2
Requisito funcional n
REQUISITOS NO FUNCIONALES
Requisitos de rendimiento
Se basaran en los subconceptos de calidad que se emiten en la
Norma ISO 9126 acerca de la definición de calidad, algunos se
detallaran en este apartado.
SOLAMENTE INDIQUE LOS QUE SI CUMPLE, CASO CONTRARIO
ELIMINE EL APARTADO, POR EJEMPLO “MANTENIBILIDAD” SI NO ES
NECESARIO DEBE ELIMINAR. Especificación de los requisitos
relacionados con la carga que se espera tenga que soportar el
sistema. Por ejemplo, el número de terminales, el número
esperado de usuarios simultáneamente conectados, número de
transacciones por segundo que deberá soportar el sistema, etc.
Todos estos requisitos deben ser mesurables. Por ejemplo,
indicando “el 95% de las transacciones deben realizarse en menos
de 1 segundo”, en lugar de “los operadores no deben esperar a que
se complete la transacción”.
Seguridad
Especificación de elementos que protegerán al software de
accesos, usos y sabotajes maliciosos, así como de modificaciones o
161
destrucciones maliciosas o accidentales. Los requisitos pueden
especificar:
- Empleo de técnicas criptográficas.
- Registro de ficheros con “logs” de actividad.
- Asignación de determinadas funcionalidades a determinados
módulos.
- Restricciones de comunicación entre determinados módulos.
- Comprobaciones de integridad de información crítica.
Fiabilidad
Especificación de los factores de fiabilidad necesaria del sistema.
Esto se expresa generalmente como el tiempo entre los incidentes
permisibles, o el total de incidentes permisible.
Disponibilidad
Especificación de los factores de disponibilidad final exigidos al
sistema. Normalmente, expresados en % de tiempo en los que el
software tiene que mostrar disponibilidad.
Mantenibilidad
Identificación del tipo de mantenimiento necesario del sistema.
Especificación de quién debe realizar las tareas de mantenimiento,
por ejemplo usuarios, o un desarrollador.
Especificación de cuando debe realizarse las tareas de
mantenimiento. Por ejemplo, generación de estadísticas de acceso
semanal y mensual.
Portabilidad
Especificación de atributos que debe presentar el software para
facilitar su traslado a otras plataformas u entornos. Pueden
incluirse:
•
•
•
•
•
Porcentaje de componentes dependientes del servidor.
Porcentaje de código dependiente del servidor.
Uso de un determinado lenguaje por su portabilidad.
Uso de un determinado compilador o plataforma de desarrollo.
Uso de un determinado sistema operativo.
Apéndices
[Inserte aquí el texto] Si acaso existiera caso contrario elimine este ítem
Pueden contener todo tipo de información relevante para la ERSoftware
pero que, propiamente, no forme parte de la ERSistema130.
130
http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
162
1.10.1.2
REQUISITOS DEL SISTEMA - IEEE 1362
-
EJEMPLO DE LA PLANTILLA
Requisitos del sistema
ERSistema (basado en plantilla IEEE 1362)
Proyecto: [Nombre de Proyecto]
Revisión [99.99]
163
Ficha del documento
Fecha
Revisión
Autor.
Verificado dep. Calidad.
[Fecha]
[Rev]
[Descripción]
[Firma o sello]
Documento validado por las partes en fecha: [Fecha]
Por el cliente
164
Fdo. D./ Dña [Nombre]
Fdo. D./Dña [Nombre]
ALCANCE
El presente documento tiene la finalidad de definir los requisitos de sistema
que serán necesarios y la base fundamental para estructurar la plataforma de
servicios sobre la cual se ejecutara la aplicación de software que se desea
desarrollar.
Este documento antecede a la Especificación de Requisitos de Software
(ERSoftware) mismo que representa la descripción general de la estructura que
soportara dicho software.
La información aquí detallada servirá a los técnicos de desarrollo para
estructurar o configurar la plataforma requerida para el perfecto
funcionamiento de este proyecto de software.
Identificación
Software de Control de Laboratorios, SCL v1.0
Identificación del sistema, proporcionando su nombre y abreviatura (si
procede).
Visión general del documento
El alcance de este documento está marcado por:
-
Describir
los
requisitos
técnicos,
humanos,
materiales,
procedimentales y de software para el perfecto funcionamiento de la
aplicación que se desarrollará, requisitos que deben ser provistos o
cumplidos por el cliente.
-
Está dirigido especialmente a los técnicos de desarrollo y
mantenimiento de software.
Visión general del sistema
165
El software a desarrollar permitirá controlar el acceso, uso, reserva y
mantenimiento del Laboratorio de Computo de la Escuela de Ingeniería
de la PUCESI, entre sus prestaciones destacan las siguientes:
-
Módulo de administración de usuarios
Módulo de administración de maquinas
Módulo de reserva de laboratorios
Módulo de seguimiento de mantenimiento
Módulo de Costos de mantenimiento
Resumen del propósito del sistema o subsistema propuesto (al cual se
aplica la descripción del sistema).
Personal involucrado
Nombre
Rol
Responsabilidades
Información
de
contacto
Nombre
Rol
Responsabilidades
Información
de
contacto
DOCUMENTOS REFERENCIADOS
Nº Título
[Título]
Ruta
[Ruta]
Versión Fecha
[Rev]
[Fecha]
Autor
[Autor]
Relación de los documentos a los que se hace referencia en los requisitos del
sistema, indicando, según proceda: el código del documento, título, ruta,
revisión, fecha y origen.
SISTEMA PROPUESTO
Descripción del sistema propuesto.
166
Debe ceñirse a los conceptos básicos que indican las nuevas capacidades
operacionales sin entrar en especificaciones de diseño, a no ser que sean
restricciones impuestas.
Descripción del problema
Copiar el enunciado del problema
Restricciones operacionales
Relación de políticas o restricciones de cualquier índole aplicables al
sistema propuesto. Algunos ejemplos pueden ser:
- Restricciones sobre el número de usuarios capaces de
utilizar el sistema.
- Restricciones de hardware (uso obligado de determinadas
plataformas, redes telemáticas, etc.)
- Restricciones de seguridad o relativas a protección de
datos.
- Restricciones de software (uso obligado de una
determinada BD, Sistema Operativo, etc.)
- Restricciones de recursos operacionales como espacio
físico.
- etc
Descripción del sistema propuesto
Descripción algo más detallada de la estructura del sistema y su
funcionamiento (basarse en la visión general del proyecto)
Es importante que los requisitos del sistema propuesto sea los más
simples y claros posible, para que todos los lectores del documento
puedan entenderlos completamente. Debe realizarse usando la
terminología del usuario.
Nota: El autor del documento debe organizar la información en este
apartado como considere apropiado para el sistema o situación. Aquellas
partes de la descripción que sean extensas podrán incluirse como
apéndices del documento.
Tipos de usuarios
Tipo de usuario
Responsabilidad
Formación
Habilidades
Actividades
Interacción
con
sistema
el [Inserte aquí el texto]
167
Tipo de usuario
Responsabilidad
Formación
Habilidades
Actividades
Interacción
con
sistema
el [Inserte aquí el texto]
Mantenimiento / soporte
Detallar la frecuencia y la forma acerca de las copias de seguridad de sql
serve 2005
Requisitos de instalación de la solución
Hardware
Software de base
Software de desarrollo de software131
1.10.2 DISEÑO ARQUITECTÓNICO
El diseño arquitectónico representa la estructura de los datos y los componentes del
programa que se requieren para construir un sistema de computadora.
Constituye el estilo arquitectónico que tendrá el sistema, las estructuras de datos y las
propiedades de los componentes y la interrelación que tiene con otros componentes
arquitectónicos del sistema.
Lo puede llevar a cabo el ingeniero de software, aunque se recomienda que el diseño
de la base de datos la lleve a cabo el diseñador de base de datos o almacén de datos y
que el arquitecto del sistema seleccione el estilo de arquitectura a utilizar, según los
requisitos recolectados en el análisis. (Esto tiene que ver con el modelo de desarrollo
de software más conveniente a utilizar).
Es importante ya que proporciona los detalles completos de todo el software que se va
a construir. Se aprecia cada uno de los detalles que conformarán el software. Asegura
que la construcción sea correcta y completa.
El diseño arquitectónico comienza con el diseño de datos y después procede a la
derivación de una o más representaciones de la estructura arquitectónica del sistema.
-
ARQUITECTURA DE SOFTWARE
131
http://www.google.com/search?q=Concepto+b%C3%A1sico+de+IEEE+1362&hl=es&source=hp&lr=lang_
es&aq=f&aqi=&aql=&oq
168
La arquitectura de software de un sistema de programa o computación es la
estructura de las estructuras del sistema, la cual comprende los componentes del
software, las propiedades de esos componentes visibles externamente, y las relaciones
entre ellos.
La arquitectura no es el software operacional, más bien, es la representación que
capacita al ingeniero del software para: Analizar la efectividad del diseño para la
consecución de los requisitos fijados, considerar las alternativas arquitectónicas en una
etapa en la cual hacer cambios en el diseño es relativamente fácil, y reducir los riesgos
asociados a la construcción del software.
En el contexto del diseño arquitectónico, un componente del software puede ser tan
simple como un módulo de programa, pero también puede ser algo tan complicado
como incluir bases de datos y software intermedio que permiten la configuración de
una red de clientes y servidores.
-
PROPIEDADES DE LOS COMPONENTES
Las propiedades de los componentes son aquellas características necesarias para
entender cómo los componentes interactúan con otros componentes.
A nivel arquitectónico, no se especifican las propiedades internas (por ejemplo,
detalles de un algoritmo).
-
RELACIONES ENTRE LOS COMPONENTES
Las relaciones entre los componentes pueden ser tan sencillas como una llamada de
procedimiento de un módulo a otro, o tan complicadas como el protocolo de acceso a
bases de datos.
El diseño de la arquitectura de software tiene en cuenta dos niveles de la pirámide del
diseño: Diseño de Datos y Diseño Arquitectónico.
-
DISEÑO ARQUITECTÓNICO
El diseño arquitectónico se centra en la representación de la estructura de los
componentes del software, sus propiedades e interacciones.
Las representaciones de la arquitectura de software facilitan la comunicación entre
todas las partes (partícipes) interesadas en el desarrollo de un sistema basado en
computadora.
La arquitectura destaca decisiones tempranas de diseño que tendrán un profundo
impacto en todo el trabajo de ingeniería del software que sigue, y es tan importante en
el éxito final del sistema como una entidad operacional, la cual constituye un modelo
relativamente pequeño e intelectualmente comprensible de cómo está estructurado el
sistema y de cómo trabajan juntos sus componentes.
169
El modelo de diseño arquitectónico y los patrones arquitectónicos contenidos dentro
son transferibles. Esto es, los estilos y patrones de arquitectura pueden ser aplicados
en el diseño de otros sistemas y representados a través de un conjunto de
abstracciones que facilitan a los ingenieros del software la descripción de la
arquitectura de un modo predecible.
-
DISEÑO DE DATOS
El diseño de datos (a veces llamado arquitectura de datos) crea un modelo de datos
y/o información que se representa con un alto nivel de Abstracción la visión de datos
del cliente/usuario. Esté modelo de datos, es entonces refinado en progresivas
representaciones específicas de la implementación, que pueden ser procesadas por un
sistema basado en computadora.
En muchas aplicaciones de software, la arquitectura de datos tendrá una gran
influencia sobre la arquitectura del software que debe procesarlo.
La estructura de datos ha sido siempre una parte importante del diseño de software.
Al nivel de los componentes del programa, el diseño de las estructuras de datos y de
los algoritmos asociados requeridos para su manipulación, son la parte esencial en la
creación de aplicaciones de alta calidad.
-
MODELOS DE DATOS
A nivel de aplicación, la traducción de un modelo de datos (derivado como parte de la
ingeniería de requisitos) en una base de datos es el punto clave para alcanzar los
objetivos de negocio del sistema.
A nivel de negocios, el conjunto de información almacenada en las diferentes bases de
datos y reorganizada en el almacén de datos facilita la minería de datos o el
descubrimiento de conocimiento que puede influir en el propio éxito del negocio.
De cualquier modo, el diseño de datos juega un papel muy importante.
-
MODELADO DE DATOS, ESTRUCTURAS DE DATOS, BASE DE DATOS Y
ALMACÉN DE DATOS
Los objetos de datos definidos durante el análisis de Requisitos del software son
modelados utilizando diagramas de entidad-relación y el diccionario de datos.
-
ESTILOS ARQUITECTÓNICOS
•
Arquitecturas centradas de datos
En el centro de esta arquitectura se encuentra un almacén de datos (por ejemplo, un
documento o una base de datos) al que otros componentes acceden con frecuencia
para actualizar, añadir, borrar o bien modificar los datos del almacén.
170
•
Arquitecturas de flujos de datos
Esta arquitectura se aplica cuando los datos de entrada son transformados a través de
una serie de componentes computacionales o manipulativos en los datos de salida.
•
Arquitectura de llamada y retorno
Este estilo arquitectónico permite al diseñador del software (arquitecto del sistema)
construir una estructura de programa relativamente fácil de modificar y ajustar a
escala.
Existen dos sub estilos dentro de esta categoría:
•
arquitecturas de programa principal
arquitecturas de llamada de procedimiento remoto
Arquitecturas orientadas a objetos
Los componentes de un sistema encapsulan los datos y las operaciones que se deben
realizar para manipular los datos.
La comunicación y la coordinación entre componentes se consiguen a través del paso
de mensajes.
•
Arquitecturas estratificadas
Se crean diferentes capas y cada una realiza operaciones que progresivamente se
aproximan más al cuadro de instrucciones de la máquina.
En la capa externa, los componentes sirven a las operaciones de interfaz de usuario.
En la capa interna, los componentes realizan operaciones de interfaz del sistema. Las
capas intermedias proporcionan servicios de utilidad y funciones del software de
aplicaciones132.
1.10.3 DISEÑO E/R
El modelo entidad-relación es el modelo conceptual más utilizado para el diseño
conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo
entidad-relación está formado por un conjunto de conceptos que permiten describir la
realidad mediante un conjunto de representaciones gráficas y lingüísticas.
Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad,
relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos
compuestos y las jerarquías de generalización, en lo que se ha denominado modelo
entidad-relación extendido.
132
http://www.scribd.com/doc/7994185/24DiseNo-de-La-Arquitectura-Del-Software
171
Figura 1.20: Modelo Entidad-Relación
Fuente: http://bd.eui.upm.es/BD/docbd/tema/tema2.pdf
-
ENTIDAD
Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa,
persona, concepto abstracto o suceso. Por ejemplo: coches, casas, empleados,
clientes, empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las
entidades se representan gráficamente mediante rectángulos y su nombre aparece en
el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema
conceptual.
Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una entidad cuya
existencia depende de la existencia de otra entidad. Una entidad fuerte es una entidad
que no es débil.
-
RELACIÓN (INTERRELACIÓN)
Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un
nombre que describe su función. Las relaciones se representan gráficamente mediante
rombos y su nombre aparece en el interior.
Las entidades que están involucradas en una determinada relación se denominan
entidades participantes. El número de participantes en una relación es lo que se
denomina grado de la relación. Por lo tanto, una relación en la que participan dos
entidades es una relación binaria; si son tres las entidades participantes, la relación es
ternaria; etc.
Una relación recursiva es una relación donde la misma entidad participa más de una
vez en la relación con distintos papeles. El nombre de estos papeles es importante
para determinar la función de cada participación.
La cardinalidad con la que una entidad participa en una relación especifica el número
mínimo y el número máximo de correspondencias en las que puede tomar parte cada
ocurrencia de dicha entidad. La participación de una entidad en una relación es
172
obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia
de, al menos, una ocurrencia de la otra entidad participante. Si no, la participación es
opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las reglas
de negocio.
A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos
problemas, denominados trampas, suelen producirse a causa de una mala
interpretación en el significado de alguna relación, por lo que es importante
comprobar que el esquema conceptual carece de dichas trampas. En general, para
encontrar las trampas, hay que asegurarse de que se entiende completamente el
significado de cada relación. Si no se entienden las relaciones, se puede crear un
esquema que no represente fielmente la realidad.
Una de las trampas que pueden encontrarse ocurre cuando el esquema representa
una relación entre entidades, pero el camino entre algunas de sus ocurrencias es
ambiguo. El modo de resolverla es reestructurando el esquema para representar la
asociación entre las entidades correctamente.
Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación
entre entidades, pero el camino entre una y otra no existe para algunas de sus
ocurrencias. En este caso, se produce una pérdida de información que se puede
subsanar introduciendo la relación que sugería el esquema y que no estaba
representada.
-
ATRIBUTO
Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los
atributos representan las propiedades básicas de las entidades y de las relaciones.
Toda la información extensiva es portada por los atributos. Gráficamente, se
representan mediante bolitas que cuelgan de las entidades o relaciones a las que
pertenecen.
Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio
define todos los valores posibles que puede tomar un atributo. Puede haber varios
atributos definidos sobre un mismo dominio.
Los atributos pueden ser simples o compuestos. Un atributo simple es un atributo que
tiene un solo componente, que no se puede dividir en partes más pequeñas que
tengan un significado propio. Un atributo compuesto es un atributo con varios
componentes, cada uno con un significado por sí mismo. Un grupo de atributos se
representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su
significado, o en cuanto a su uso. Un atributo compuesto se representa gráficamente
mediante un óvalo.
Los atributos también pueden clasificarse en monovalentes o polivalentes. Un atributo
monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o
relación a la que pertenece. Un atributo polivalente es aquel que tiene varios valores
para cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos
173
también se les denomina multivaluados, y pueden tener un número máximo y un
número mínimo de valores. La cardinalidad de un atributo indica el número mínimo y
el número máximo de valores que puede tomar para cada ocurrencia de la entidad o
relación a la que pertenece. El valor por omisión es
.
Por último, los atributos pueden ser derivados. Un atributo derivado es aquel que
representa un valor que se puede obtener a partir del valor de uno o varios atributos,
que no necesariamente deben pertenecer a la misma entidad o relación.
-
IDENTIFICADOR
Un identificador de una entidad es un atributo o conjunto de atributos que determina
de modo único cada ocurrencia de esa entidad. Un identificador de una entidad debe
cumplir dos condiciones:
•
•
No pueden existir dos ocurrencias de la entidad con el mismo valor del
identificador.
Si se omite cualquier atributo del identificador, la condición anterior deja de
cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios identificadores
alternativos. Las relaciones no tienen identificadores.
•
JERARQUÍA DE GENERALIZACIÓN
Una entidad E es una generalización de un grupo de entidades E , E , E , si cada
ocurrencia de cada una de esas entidades es también una ocurrencia de E. Todas las
propiedades de la entidad genérica E son heredadas por las sub-entidades.
Cada jerarquía es total o parcial, y exclusiva o superpuesta. Una jerarquía es total si
cada ocurrencia de la entidad genérica corresponde al menos con una ocurrencia de
alguna sub-entidad. Es parcial si existe alguna ocurrencia de la entidad genérica que no
corresponde con ninguna ocurrencia de ninguna sub-entidad. Una jerarquía es
exclusiva si cada ocurrencia de la entidad genérica corresponde, como mucho, con una
ocurrencia de una sola de las sub-entidades. Es superpuesta si existe alguna ocurrencia
de la entidad genérica que corresponde a ocurrencias de dos o más sub-entidades
diferentes.
Un subconjunto es un caso particular de generalización con una sola entidad como
sub-entidad. Un subconjunto siempre es una jerarquía parcial y exclusiva.133
1.10.4 DISEÑO DETALLADO
133
http://bd.eui.upm.es/BD/docbd/tema/tema2.pdf
174
1.10.5 BITÁCORAS DE CODIFICACIÓN
En esta tarea se realiza lo que comúnmente se conocen como programación; que
consiste, en realizar el código fuente, en el lenguaje de programación elegido, todo lo
diseñado en la fase anterior. Esta tarea la realiza el programador, siguiendo por
completo los lineamientos impuestos en el diseño y en consideración siempre a los
requisitos funcionales y no funcionales (ERS) especificados.
La etapa de programación o codificación alguno la llaman implementación es la que
insume la mayor parte del trabajo de desarrollo del software.
Mientras se programa la aplicación, sistema, o software en general, se realizan
también tareas de depuración, esto es la labor de ir liberando al código de los errores
factibles de ser hallados en está fase de semántica, sintáctica y lógica.
En la fase siguiente, para depurar la lógica es necesario realizar pruebas unitarias, con
datos de prueba; no todos los errores serán encontrados sólo en la etapa de
programación, habrá otros que se encontrarán durante las etapas subsiguientes. La
aparición de algún error funcional (mala respuesta a los requerimientos) lo cual puede
llevar a retornar a la fase de diseño antes de continuar la codificación.
-
Código fuente: Contiene el conjunto de instrucciones codificadas en algún
lenguaje de alto nivel. Puede estar distribuido en paquetes, procedimientos,
bibliotecas fuente, etc.
-
Código objeto: es el código binario o intermedio resultante de procesar con un
compilador el código fuente.
El código objeto no es inteligible por el ser humano pero tampoco es
directamente ejecutable por la computadora. Se trata de una representación
intermedia entre el código fuente y el código ejecutable, a los fines de un
enlace final con las rutinas de biblioteca y entre procedimientos o bien para su
uso con un pequeño intérprete intermedio; ejemplos FORTRAN (compilador
puro) MSIL (Microsoft Intermédiate Language) (intérprete).
El código objeto no existe si el programador trabaja con un lenguaje a modo de
intérprete puro, en este caso el mismo intérprete se encarga de traducir y
ejecutar línea por línea el código fuente, en tiempo de ejecución. En este caso
no existen los archivos de código ejecutable. En la cual no favorece el
rendimiento en velocidad de ejecución. Pero una ventaja de la modalidad
intérprete puro, es que la forma de trabajo facilita enormemente la tarea de
depuración del código fuente
-
Código ejecutable: Es el código binario resultado de enlazar uno o más
fragmentos de código objeto con las rutinas y bibliotecas necesarias.
Constituye uno o más archivos binarios con un formato tal que el sistema
operativo es capaz de cargarlo en la memoria RAM y proceder a su ejecución
directa. Por lo anterior se dice que el código ejecutable es directamente
"inteligible por la computadora". El código ejecutable, también conocido como
175
código máquina, no existe si se programa con modalidad de "intérprete puro".
134
1.10.6 PRUEBAS
Consiste en comprobar que el software realice correctamente las tareas indicadas en
la especificación del problema. Para las cuales tenemos las siguientes:
-
PRUEBA UNITARIA
Prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de
código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente
por separado.
Es importante que las pruebas unitarias no descubran todos los errores del código. Por
definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores
de integración, problemas de rendimiento y otros problemas que afectan a todo el
sistema en su conjunto. Las pruebas unitarias sólo son efectivas si se usan en conjunto
con otras pruebas de software.
Características
Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:
•
•
•
•
•
Automatizable: no debería requerirse una intervención manual. Esto es
especialmente útil para integración continúa.
Completas: deben cubrir la mayor cantidad de código.
Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser
ejecutadas una sola vez. También es útil para integración continua.
Independientes: la ejecución de una prueba no debe afectar a la ejecución de
otra.
Profesionales: las pruebas deben ser consideradas igual que el código, con la
misma profesionalidad, documentación, etc.
Ventajas
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las
partes individuales son correctas. Proporcionan un contrato escrito que el trozo de
código debe satisfacer. Estas pruebas aisladas proporcionan ventajas básicas:
•
134
Fomentan el cambio: Las pruebas unitarias facilitan que el programador
cambie el código para mejorar su estructura lo que se ha dado en llamar
refactorización, puesto que permiten hacer pruebas sobre los cambios y así
asegurarse de que los nuevos cambios no han introducido errores.
http://es.wikipedia.org/wiki/Software
176
•
•
•
•
-
Simplifica la integración: permiten llegar a la fase de integración con un grado
alto de seguridad de que el código está funcionando.
Documenta el código: Las propias pruebas son documentación del código
puesto que ahí se puede ver cómo utilizarlo.
Separación de la interfaz y la implementación: Dado que la única interacción
entre los casos de prueba y las unidades bajo prueba son las interfaces de estás
últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces
usando objetos mock (mock object) para simular el comportamiento de objetos
complejos.
Los errores están más acotados y son más fáciles de localizar: dado que
tenemos pruebas unitarias que pueden desenmascararlos. 135
PRUEBAS DE INTEGRACIÓN O PRUEBAS INTEGRALES
Las pruebas de integración se llevan a cabo durante la construcción del sistema,
involucran a un número creciente de módulos y terminan probando el sistema como
conjunto.
Estas pruebas se pueden plantear desde un punto de vista estructural o funcional.
•
Las pruebas estructurales de integración.- son similares a las pruebas de caja
blanca; pero trabajan a un nivel conceptual superior. En lugar de referirnos a
sentencias del lenguaje, nos referiremos a llamadas entre módulos. Se trata
pues de identificar todos los posibles esquemas de llamadas y ejercitarlos para
lograr una buena cobertura de segmentos o de ramas.
•
Las pruebas funcionales de integración.- son similares a las pruebas de caja
negra. Aquí trataremos de encontrar fallos en la respuesta de un módulo
cuando su operación depende de los servicios prestados por otros módulos.
Según nos vamos acercando al sistema total, estas pruebas se van basando más
en la especificación de requisitos del usuario. Las pruebas finales de
integración cubren todo el sistema y pretenden cubrir plenamente la
especificación de requisitos del usuario. En todas estas pruebas funcionales se
siguen utilizando las técnicas de partición en clases de equivalencia y análisis de
casos límite o fronteras. 136
PRUEBA DE SISTEMAS
-
Las pruebas se realizan a lo largo del desarrollo del sistema y no simplemente al final.
Esto significa sacar los problemas no conocidos y no demostrar la perfección de
programas manuales o equipo. Las pruebas se realizan en las interfaces entre
subsistemas, la corrección de la salida, la utilidad y comprensibilidad de la
documentación de la salida del sistema, además, las pruebas están basadas en los
requerimientos generales y abarca todas las partes combinadas sean estas en niveles
diferentes y a diversos intervalos del sistema. Antes de que el sistema sea puesto en
producción, todos los programas deben ser probados en el escritorio, revisados con
datos de prueba y revisados para ver si los módulos trabajan juntos entre ellos.
135
136
http://es.wikipedia.org/wiki/Prueba_unitaria
http://es.wikipedia.org/wiki/Pruebas_de_software
177
Para la cual nos sirven las siguientes pruebas.
•
•
Pruebas de caja negra.está prueba se enfoca en los requerimientos
establecidos y en la funcionalidad del sistema. Además, nos interesará su
forma de interactuar con el medio que le rodea, entendiendo qué es lo que
hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra
deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en
cambio, no se precisa definir ni conocer los detalles internos de su
funcionamiento.
Pruebas de caja blanca.- estas se basan en el conocimiento de la lógica interna
del código del sistema. Así como las pruebas de caja negra ejercitan los
requisitos funcionales desde el exterior del módulo, las de caja blanca están
dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la
cobertura de caminos, pruebas sobre las expresiones lógico-aritméticas,
definición-uso de variables, comprobación de bucles.137
1.10.7 VALIDACIÓN Y ACEPTACIÓN
La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario
realmente quería. Se trata de evaluar el sistema o parte de este durante o al final del
desarrollo para determinar si satisface los requisitos iníciales.
La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?
Pruebas de Aceptación
•
•
•
Pruebas de aceptación: desarrolladas por el cliente.
Pruebas alfa realizadas por el usuario con el desarrollador como observador en
un entorno controlado (simulación de un entorno de producción).
Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin
observadores.
Comprobar que se satisfacen los requisitos
•
•
•
•
•
•
Se usan las mismas técnicas, pero con otro objetivo.
No hay programas de prueba, sino sólo el código final de la aplicación.
Se prueba el programa completo.
Uno o varios casos de prueba por cada requisito o caso de uso especificado.
Se prueba también rendimiento, capacidad, etc. y no sólo resultados correctos.
Pruebas alfa (desarrolladores) y beta (usuarios). 138
137
http://es.wikipedia.org/wiki/Caja_blanca_%28sistemas%29
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-227/paper07.pdf
138
178
CAPÍ
CAPÍTULO II
II
INGENIERÍA DE LA SOLUCIÓN
3.1 DEFINICIÓN DE REQUISITOS
3.1.1 DEFINICIÓN GENERAL DE REQUISITOS
179
-
Requisitos Funcionales / Específicos
Los requisitos funcionales del Sistema de Gestión de Información del Centro de
Rehabilitación Física son los siguientes:
•
El sistema deberá solicitar usuario y contraseña, esto permitirá validar los
datos y acceder el ingreso al formulario principal de cada usuario.
•
El usuario podrá acceder a través del formulario principal a las diferentes
funciones del sistema.
•
Cada opción del sistema que se encuentra en los formularios solicitará una
información específica, ya que el usuario podrá ingresar nuevos datos,
modificar, generar búsquedas y reportes.
•
Toda la información ingresada será almacenada o actualizada en la base de
datos de acuerdo con el tipo de información ingresada correctamente.
•
En caso de tener inconvenientes al ingresar al sistema o ingresar los datos,
entre otros el sistema indicará el error al usuario.
•
El sistema generará reportes dependiendo a las necesidades del usuario,
para lo cual se solicitará el ingreso de parámetros para cada reporte.
Los requisitos antes mencionados están basados en las fichas del Centro de
Rehabilitación Física se pueden observar en el Anexo 2.
-
Requisitos no Funcionales
Se basaran en los siguientes subconceptos de calidad que se emiten en la Norma ISO
9126.
•
•
-
El sistema deberá solicitar usuario y contraseña para el ingreso al formulario
correspondiente.
La velocidad de respuesta entre las transacciones será alta.
Requisitos Comunes a las Interfaces
Las interfaces de la aplicación de software de Gestión de Información del Centro de
Rehabilitación Física de Antonio Ante son las siguientes:
180
•
Interfaces de usuario: Formulario principal de la aplicación y Formularios
modales dependientes del formulario principal.
•
Interfaces de hardware : El computador donde se desarrollará el software
del sistema es un computador de escritorio con Procesador Quad Core de
2.20 GHZ, Memoria Ram de 1Gb y Disco Duro de 120 Gb.
•
Interfaces de software : Para la administración, mantenimiento y desarrollo
de la base de datos del sistema en MySQL se utilizará la herramienta APP
Server.
•
Interfaces de comunicación: Protocolo TCP/IP: La aplicación establecerá una
conexión mediante red con la base de datos.
181
3.1.2
ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE – IEEE 830
Especificación de requisitos de software
ERSoftware (basado en plantilla IEEE 830)
Proyecto: “DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA
DE GESTIÓN DE INFORMACIÓN PARA EL CENTRO DE
REHABILITACIÓN FÍSICA DE ANTONIO ANTE”
182
revisión [1.0]
Ficha del documento
Fecha
11/01/2011
Revisión
Autor
Verónica
Lima
Karina
Esparza
Fanny Lorena Inlago Caiza
183
Documento validado por las partes en fecha: 28/07/2010
Por el cliente
Fdo. D./ Dña [Centro de Rehabilitación Fdo. D./Dña [Verónica Esparza / Fanny
Física]
Inlago]
1 Introducción
Este documento presenta los requerimientos específicos funcionales de la
aplicación a construir, se convierte en el referente para la etapa de diseño y
posteriormente se lo utilizará para la validación del producto de software
1.1
-
Propósito
Determinar los requisitos específicos de la aplicación.
Determinar las funcionalidades operativas de la aplicación.
Determinar la operatividad de la aplicación para el proceso de
validación.
184
Documentar las funcionalidades requeridas para posterior
mantenimiento de la aplicación por parte de los técnicos de
desarrollo.
-
1.2
Alcance
-
La aplicación a construir se denomina “DISEÑO E IMPLEMENTACIÓN
DE UN SISTEMA DE GESTIÓN DE INFORMACIÓN PARA EL CENTRO DE
REHABILITACIÓN FÍSICA DE ANTONIO ANTE” v1.0 por sus siglas
SGICRF.
-
La misma definición y nombre se encuentran determinados en el
documento ERSistema (IEEE 1362).
1.3
Personal involucrado
Nombre
Rol
Responsabilidades
Información
de
contacto
Aprobación
Verónica Karina Esparza Lima
Desarrollador
Egresada de Ingeniería en Sistemas
Diseñar y Desarrollar el Software
Borrero y Olmedo, telf. 062 950 122
[email protected]
Nombre
Rol
Responsabilidades
Información
de
contacto
Aprobación
Desarrollador
Diseñar y Desarrollar el Software
Gonzales Suárez, telf. 062 918 758
[email protected]
1.4
Definiciones, acrónimos y abreviaturas
Acrónimos
-
CdU: Caso de uso
SGICRF: Sistema de Gestión de Información del Centro de
HdU: Historia de Usuario
TCP/IP: Transport control Protocol Internet
Definiciones
185
IEEE1362.- Estándar que determina la especificación de requisitos de
sistema para la construcción y puesta en marcha de aplicaciones de
software.
IEEE830.- Especificación de requisitos de software.
Administrar.- En informática se refiere a las operaciones de alta, baja,
eliminación, modificación y consulta de datos.
-
1.5
Referencias
Referencia
1
1.6
Titulo
Ruta
Definición
C:\Documents and
General de Settings\Kary\Escritorio\Softw
Requisitos are Proyecto de
Tesis\Monografía
Fecha
Autor
Enero2011
Autores
Resumen
El contenido de este documento consta de: Introducción que induce al
conocimiento específico de la aplicación a construir, descripción general de
la aplicación a construir, definición de los requisitos específicos de la
aplicación y anexos si acaso existieren.
2 Descripción general
2.1
Perspectiva del producto
La aplicación SGICRF v1.0, que se desea crear es un nuevo sistema para el
Centro, lo cual será de gran ayuda para el personal que labora en dicha
entidad y a su vez para los pacientes; ya que es un producto
independiente y no forma parte de un sistema mayor.
2.2
Funcionalidad del producto
El SGICRF v1.0 deberá constar de las siguientes funciones:
-
Gestionar usuarios de la aplicación
Gestionar la información de los pacientes
Gestionar la información médica
Gestionar la información de los médicos
Generar reportes a petición de usuarios
El SGICRF v1.0 deberá constar de las siguientes características:
186
-
Autentificación de usuario y contraseña a la Base de Datos
Validación de Información de pacientes y médicos
Aplicación cliente servidor de tres capas (presentación, servicios y
datos)
Aplicación de desarrollo de software con herramientas GNU/GPL.
De distribución libre.
El SGICRF v1.0 estará en capacidad de:
-
Funcionar a través de protocolo TCP/IP
Crear respaldos de la data generada
El SGICRF v1.0 interactúa tal como se muestra en los diagramas:
2.3
Diagrama 1, CDU SGICRF v1.0, usuario
Diagrama 2, CDU SGICRF v1.0,casos de usos
Características de los usuarios
Tipo de usuario
Formación
Habilidades
Actividades
Tipo de usuario
Formación
Habilidades
Actividades
2.4
Administrador
Tecnólogo en informática
Manejo de sistemas operativos, administrar base de
datos y mantenimiento de hardware.
Gestionar: usuarios de la aplicación, información de
paciente y médico, información de médicos, reportes
Fisioterapista
Estudios Superiores
Tener conocimientos básicos de computación
Registrar paciente, realizar diagnóstico, obtener
reportes
Restricciones
-
La documentación se llevará en función de los estándares: IEEE
1362, IEEE 830, plantillas de Lharman, diagramas E/R.
-
La metodología a aplicar será Extreme Programming XP
apoyándose en las mejores prácticas de RUP y los documentos de
UML.
187
2.5
-
Se desarrollara la aplicación sobre la herramienta libre de PHP y
DBMS de distribución libre como MySQL.
-
Se debe considerar las prestaciones de la plataforma del sistema
operativo actual: Windows XP y el DBMS de servidor de base de
datos MySQL.
Suposiciones y dependencias
El sistema de Gestión de Información del Centro de Rehabilitación Física
estará disponible solo para plataformas implementadas con Windows XP.
2.6
Actualización predecible del sistema
El sistema a futuro se podrá implantar en el Centro de Rehabilitación Física
de Antonio Ante, para brindar una mejor atención a los pacientes.
3 Requisitos específicos
Nombre de requisito
Tipo
(HdU)
Descripción (CDU)
Nombre de requisito
Tipo
(HdU)
Descripción (CDU)
Nombre de requisito
Tipo
(HdU)
Descripción (CDU)
R.1
Validar Usuario
X Requisito
Restricción
Cada vez que el usuario quiera ingresar al sistema, deberá
ingresar el usuario y contraseña para validar en la base de
datos y permitir o no el ingreso.
X Alta/Esencial
Media/Deseado
Baja/ Opcional
CdU_SGICRF-R.1
R.2
Acceder al Formulario Principal
Requisito
Restricción
El usuario podrá acceder a todos los componentes de la
aplicación mediante el formulario principal ya que dispondrá
de un menú de opciones.
Alta/Esencial
X Media/Deseado
Baja/ Opcional
CdU_SGICRF-R.2
R.3
Nuevo Paciente
Requisito
Restricción
La fisioterapista tendrá acceso a ingresar los datos de un
nuevo paciente, permitiéndole obtener automáticamente el
número de la Historia Clínica.
Alta/Esencial
X Media/Deseado
Baja/ Opcional
CdU_SGICRF-R.3
188
Nombre de requisito
Tipo
(HdU)
Descripción (CDU)
R.4
Historia Clínica del nuevo paciente
Requisito
Restricción
Una vez ingresado los datos del nuevo paciente, tendrá la
opción de ingresar o no la Historia Clínica; en caso de no
ingresar, los datos del paciente serán guardados en la base de
datos.
Alta/Esencial
X Media/Deseado
Baja/ Opcional
CdU_SGICRF-R.4
Nombre de requisito
Tipo
(HdU)
Descripción (CDU)
R.5
Datos Paciente
Requisito
Restricción
La Fisioterapista podrá visualizar los datos del paciente
existente.
Nombre de requisito
Tipo
(HdU)
Descripción (CDU)
R.6
Historia Clinica
Requisito
Restricción
La Fisioterapista podrá visualizar la historia clínica del
paciente existente.
Nombre de requisito
Tipo
(HdU)
R.7
Búsqueda
Requisito
Restricción
La Fisioterapista podrá buscar a pacientes existentes
dependiendo de los parámetros que ingrese en el formulario
de búsqueda.
Alta/Esencial
X Media/Deseado
Baja/ Opcional
CdU_SGICRF-R.7
Descripción (CDU)
Nombre de requisito
Tipo
(HdU)
Descripción (CDU)
Alta/Esencial
CdU_SGICRF-R.5
Alta/Esencial
CdU_SGICRF-R.6
X
X
Media/Deseado
Media/Deseado
Baja/ Opcional
Baja/ Opcional
R.8
Lista Instituciones
Requisito
Restricción
La Fisioterapista podrá visualizar, ingresar o eliminar los
nombres de las instituciones que requiera.
Alta/Esencial
CdU_SGICRF-R.8
189
X
Media/Deseado
Baja/ Opcional
Nombre de requisito
Tipo
(HdU)
Descripción (CDU)
3.1
R.9
Reportes
Requisito
Restricción
La Fisioterapista podrá generar reportes dependiendo de sus
necesidades.
Alta/Esencial
CdU_SGICRF-R.12
X
Media/Deseado
Baja/ Opcional
Requisitos comunes de los interfaces
A continuación se detallan las interfaces de la aplicación de software que
gestiona la información del Centro de Rehabilitación Física de Antonio
Ante.
3.1.1 Interfaces de usuario
La aplicación se presentara al usuario en función de:
-
Formulario principal de aplicación
Formularios modales dependientes del formulario principal
•
Formulario Principal: Valida al usuario para ingresar a la
aplicación correspondiente.
•
Formulario de Administrador: Ingresar a Rehabilitación
Física o Rehabilitación de Lenguaje.
•
Formulario de Rehabilitación Física: Elegir las diferentes
opciones que el sistema presenta.
Formulario de Rehabilitación Lenguaje: Elegir las
diferentes opciones que el sistema presenta.
•
•
Formulario Nuevo Paciente:
personales del paciente.
•
Formulario Datos Paciente: Visualizar y Modificar los
datos del paciente ya existente.
•
Formulario Historia Clínica: Ingresar, visualizar y
modificar la ficha clínica de cada paciente como el
médico que le envía, los antecedentes personales y su
tratamiento.
•
Formulario Búsqueda: Realiza una búsqueda de la
información del paciente ingresando los diferentes datos.
190
Ingresar
los
datos
•
Formulario Instituciones:
instituciones.
•
Formulario Reportes: El sistema genera los respectivos
reportes correspondientes a la información existente en
la base de datos.
Agregar
y
visualizar
3.1.2 Interfaces de hardware
El computador donde se desarrollará el software del sistema es un
computador de escritorio con las siguientes características:
-
Procesador Quad Core de 2.20 GHZ
Memoria Ram de 1Gb
Disco Duro de 120 Gb
3.1.3 Interfaces de software
Para la administración, mantenimiento y desarrollo de la base de
datos del sistema en MySQL se utilizará la herramienta APP Server.
3.1.4 Interfaces de comunicación
Protocolo TCP/IP: La aplicación establecerá una conexión mediante
red con la base de datos.
3.2
Requisitos funcionales
Los requisitos funcionales del Sistema de Gestión de Información del
Centro de Rehabilitación Física se describirán así:
3.2.1 Requisito funcional 1
El sistema deberá solicitar usuario y contraseña, esto permitirá validar los
datos y acceder el ingreso al formulario principal de cada usuario.
El usuario podrá acceder a través del formulario principal a las diferentes
funciones del sistema.
Cada opción del sistema que se encuentra en los formularios solicitará
una información específica, ya que el usuario podrá ingresar nuevos
datos, modificar, generar búsquedas y reportes.
191
Toda la información ingresada será almacenada o actualizada en la base
de datos de acuerdo con el tipo de información ingresada correctamente.
En caso de tener inconvenientes al ingresar al sistema o ingresar los datos,
entre otros el sistema indicará el error al usuario.
El sistema generará reportes dependiendo a las necesidades del usuario,
para lo cual se solicitará el ingreso de parámetros para cada reporte.
3.3
Requisitos no funcionales
3.3.1 Requisitos de rendimiento
Se basaran en los siguientes subconceptos de calidad que se emiten
en la Norma ISO 9126.
3.3.2 Seguridad
El sistema deberá solicitar usuario y contraseña para el ingreso al
formulario correspondiente.
3.3.3 Fiabilidad
La velocidad de respuesta entre las transacciones será alta.
3.1.3 ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA – IEEE 1362
192
Requisitos del sistema
ERSistema (basado en plantilla IEEE 1362)
Proyecto: “DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA
DE GESTIÓN DE INFORMACIÓN PARA EL CENTRO DE
REHABILITACIÓN FÍSICA DE ANTONIO ANTE”
Revisión [1.0]
193
Ficha del documento
Fecha
11/01/2011
Revisión
Autor
Verónica
Lima
Karina
Esparza
Documento validado por las partes en fecha: 28/07/2010
Por el cliente
194
Fdo. D./ Dña [Centro de Rehabilitación Fdo. D./Dña [Verónica Esparza / Fanny
Física]
Inlago]
1 Alcance
El presente documento tiene la finalidad de definir los requisitos de
sistema que serán necesarios y la base fundamental para el desarrollo de la
aplicación del proyecto a implementar en el Centro de Rehabilitación Física
de Antonio Ante.
Este documento antecede a la Especificación de Requisitos de Software, el
mismo que representa la descripción y análisis general del sistema para un
buen funcionamiento.
La información aquí detallada servirá a los autores y técnicos de desarrollo
del sistema para implementar con eficiencia y eficacia.
1.1 Identificación
Sistema de Gestión de Información para el Centro de Rehabilitación
Física, SGICRF v1.0
1.2 Visión general del documento
El alcance de este documento está marcado por:
-
Describir
los
requisitos
técnicos,
humanos,
materiales,
procedimentales y de software para el perfecto funcionamiento de la
aplicación del sistema que se desarrollará, requisitos que deben ser
cumplidos por el Centro de Rehabilitación Física de la ciudad de
Antonio Ante.
195
-
Está dirigido especialmente a los autores de desarrollo del sistema y
al personal del Centro de Rehabilitación.
1.3 Visión general del sistema
El software a desarrollar permitirá controlar el acceso, uso y gestión de
información de los pacientes del Centro de Rehabilitación Física de
Antonio Ante, entre sus prestaciones se destacan las siguientes:
- Módulo de Administrador de usuarios.
- Módulo de Administrador de información de pacientes.
- Módulo de Administrador de información médica.
- Módulo de Administrador de reportes.
- Módulo de gestión de información médica.
1.4 Personal involucrado
Nombre
Rol
Desarrollador
Responsabilidades
Diseño y Desarrollo del Software
Información
contacto
de Borrero y Olmedo, tel. 2950122
Correo: [email protected]
Nombre
Rol
Desarrollador
Responsabilidades
Diseño y Desarrollo del Sistema
Información
contacto
de Gonzales Suarez, tel. 2918758
Correo: [email protected]
Nombre
Pilar Rueda
Rol
Jefe del Centro de Rehabilitación Física
Licenciada en Fisioterapia Física
Responsabilidades
Manejar el Sistema
Información
contacto
de Antonio Ante, tel. 2908266
196
Nombre
Miriam Goveo
Rol
Trabajadora del Centro de Rehabilitación Física
Licenciada en Fisioterapia de Lenguaje
Responsabilidades
Manejar el Sistema
Información
contacto
de Antonio Ante, tel. 2908266
2 Documentos referenciados
Nº Título
Ruta
Versión Fecha
Autor
1 Definición
General de
Requisitos
2 ERSoftware
C:\Documents and
1.0
Settings\Kary\Escritorio\Software
Proyecto de Tesis\Monografía
C:\Documents
and 1.0
Proyecto
de
Tesis\Monografía\Formularios
Enero2011
Autores
Enero2011
Autores
3 Anteproyecto C:\Documents
and 1.0
Proyecto de Tesis\anteproyecto
Marzo2009
Autores
3 Sistema propuesto
Para el desarrollo de este sistema se propone la implementación de una
aplicación de Software para la Gestión de Información del Centro de
Rehabilitación, mediante la utilización de una base de datos.
3.1
Descripción del problema
En el año 2007 se resolvió construir las nuevas instalaciones, un moderno
edificio, presentado los servicios de Rehabilitación Física y Rehabilitación
de Lenguaje, a cargo de dos especialistas, atendiendo semanalmente
alrededor de 74 pacientes. La información, como por ejemplo:
expedientes y evoluciones están almacenados en carpetas, retardando la
197
búsqueda del Historial Clínico ocasionando que la elaboración de
reportes sea tediosa e inoportuna.
Algunos datos que se tiene que llenar en los documentos mencionados
son redundantes lo que ocasiona inconsistencia y pérdida de tiempo
tanto para los pacientes como para el personal administrativo. Es por eso
que en la actualidad el Centro de Rehabilitación Física de Antonio Ante
por la demanda de sus pacientes, presenta dificultades en el manejo de la
información ya que este controla documentos de forma manual y por
ende hay un consumo de tiempo, materiales y recurso económicos, que
impide brindar un servicio funcional y dinámico a la comunidad anteña.
3.2
Restricciones operacionales
Las restricciones del sistema para la Gestión de Información del Centro
de Rehabilitación Física son:
-
El jefe del Centro de Rehabilitación Física tendrá el control
administrativo total del sistema.
-
El sistema deberá ser implementado preferiblemente en la
plataforma XP.
-
El sistema de base de datos será MySql.
3.3
Descripción del sistema propuesto
El sistema de Gestión de Información para el Centro de Rehabilitación
Física de Antonio Ante se encargara de administrar usuario, pacientes,
sus expedientes médicos y los datos personales de los médicos tratantes,
además permitirá la protección de datos mediante copias de respaldo y
de la administración del espacio de almacenamiento, reduciendo así la
cantidad de datos y el costo de almacenarlos.
La información almacenada ayudara a generar reportes que serán
utilizados por los fisioterapistas del Centro de Rehabilitación Física,
además la información será guardada en un archivo externo a la base de
datos.
Se basara en la descripción de los siguientes módulos:
-
Módulo de Administración de información de pacientes.
• Registrar nuevos pacientes.
198
•
Modificar la información personal de los pacientes ya
existentes.
-
Módulo de Administración de información médica
• Generar ficha clínica para pacientes.
• Actualizar la información de las fichas clínicas de cada
paciente ya existente.
-
Módulo de reportes
• Generar reportes por pacientes ya sea diario o mensual.
Módulo de gestión de información médica.
• Registro de datos personales de los médicos.
Todo esto se lo realizará bajo la seguridad de control de datos mediante la
creación de usuario y contraseña.
-
El software presentará una interfaz de usuario fácil y todos sus formularios
generalizados permitiéndole realizar distintas tareas de interacción con la base
de datos.
3.4
Tipos de usuarios
Tipo de usuario
Administrador
Responsabilidad
Administrar funcionalmente el sistema
Formación
Licenciada en Fisioterapia
Habilidades
Actividades
Conocimiento de Computación
Jefa del Centro de Rehabilitación Física
Interacción
sistema
con
el Controlar la información de los pacientes del Centro
Tipo de usuario
Terapia Física
Responsabilidad
Brindar la terapia respectiva al paciente
Formación
Licenciada en Terapia Física
Habilidades
Conocimientos de Computación
Actividades
Encargada de la Rehabilitación
Interacción
sistema
con
el Crear nuevas Historias Clínicas, modificar y generar
reportes.
Tipo de usuario
Terapia Lenguaje
Responsabilidad
Brindar la terapia respectiva al paciente
199
Formación
Licenciada en Terapia de Lenguaje
Habilidades
Conocimientos de Computación
Actividades
Encargada de la Rehabilitación
Interacción
sistema
3.5
con
el Crear nuevas Historias Clínicas, modificar y generar
reportes.
Mantenimiento / soporte
El mantenimiento de la Base de Datos dependerá del jefe/a del Centro de
Rehabilitación Física.
3.6
Requisitos de instalación de la solución
3.6.1 Hardware
-
1 SERVIDOR: Core2Duo 2.x Ghz, 4 Gb RAM, 120 Gb Disco duro
libres, Red 10/100 mbps
-
1 CLIENTE: Core2Duo 2.x Ghz, 4 Gb RAM, 120 Gb Disco duro
libres, Red 10/100 mbps
-
Infraestructura de red 100/100 mbps
3.6.2 Software de base
-
Sistema Operativo XP Profesional + SP3
Internet information Server.
APP Server
3.6.3 Software de desarrollo de software
-
APP Server
Base de Datos My SQL
PHP
PHP Runner
Power Designer v9
Joombla
Macromedia Dreamweaver
Macromedia Flash
200
3.2 DISEÑO
3.2.1 CONVENCIONES
CONVENCIONES PARA EL DESARROLLO DEL SISTEMA DE GESTIÓN DE INFORMACIÓN
PARA EL CENTRO DE REHABILITACIÓN FÍSICA DE ANTONIO ANTE
1. INTRODUCCIÓN
Es frecuente en el medio escuchar a estudiantes y profesionales de la programación
confesar, no sin cierta preocupación, que no están en capacidad de documentar un
programa, o de siquiera escribirlo bien. Aunque en algunos casos puede que el
interlocutor realmente sea ignorante, en realidad lo que le falta es decorar el
programa sistemáticamente, para que el resultado sea un buen programa. Una manera
de lograrlo es siguiendo las convenciones de programación.
Las convenciones de programación son reglas para hacer la documentación interna
del programa139. El seguirlas no garantiza que todo programa quede correctamente
documentado, pero el programador cuidadoso logrará de ellas gran provecho.
Después de todo representan la experiencia de muchos programadores, que han
contribuido con diversos detalles, que juntos forman un todo bastante armonioso y
útil. Estas convenciones no son las más agradables a primera vista. Sin embargo,
139
http://www.di-mare.com/adolfo/p/convpas.htm
201
después de un tiempo de usarlas, el cerebro se acostumbra a ellas, y las acepta. Al
tiempo, programas que no siguen las convenciones se ven mal.
Adoptar estas convenciones es difícil, pues requiere mucho trabajo, con la desventaja
de tener que sincronizar unos gustos con los de otros. Pero después de un corto
tiempo se logra, y paradójicamente las convenciones se tornan más agradables de lo
que uno quisiera aceptar. Además, si todos las usan, todos estarán más contentos
compartiendo nuestros programas. Este documento contiene normas para el
desarrollo de software en sus aspectos fundamentales: estándares de nomenclatura,
entornos de explotación y desarrollo, uso de las herramientas. Los principales
destinatarios son los analistas y programadores responsables del desarrollo y
mantenimiento de aplicaciones de gestión.
2. OBJETIVOS
-
Estandarizar la forma de programar e interpretar documentos para el
desarrollo de un software.
Mantener en línea la comunicación entre todos los desarrolladores de un
proyecto de software.
Permitir que el mantenimiento de la información sea más efectivo.
3. RESPONSABILIDADES
Cada programador deberá disponer de sus propios directorios de trabajo, así como de
datos independientes para realizar pruebas unitarias de los módulos que vaya
desarrollando.
Es responsabilidad del programador la organización de su directorio de trabajo, así
como el mantenimiento de sus datos de prueba.
Se favorecerá el traspaso de módulos en desarrollo entre programadores con la única
condición que no pueda modificar el trabajo del otro (se sugiere crea una nueva
versión)
4. CONVENCIONES
El proyecto Sistema de Gestión de Información para el Centro de Rehabilitación Física
basado en plataforma WEB está denominado por las siglas SGICRF, el cual nace por la
necesidad que presenta el Centro en almacenar la información, como por ejemplo:
202
datos del paciente, historias clínicas, tratamientos y evoluciones ya que se encuentran
almacenadas en carpetas, retardando la búsqueda del historial médico ocasionando
que la elaboración de reportes sea tediosa e inoportuna. Algunos datos que se tiene
que llenar en los documentos mencionados son redundantes lo que ocasiona
inconsistencia y pérdida de tiempo tanto para los pacientes como para el personal
administrativo. Es por eso por lo que en la actualidad el Centro de Rehabilitación Física
de Antonio Ante por la demanda de sus pacientes, presenta dificultades en el manejo
de la información ya que este controla documentos de forma manual y por ende hay
un consumo de tiempo, materiales y recursos económicos, que impide brindar un
servicio funcional y dinámico a la comunidad anteña.
De esta necesidad surge la idea de crear un Sistema de Gestión de Información para el
Centro de Rehabilitación Física de Antonio Ante basada en plataforma WEB, el SGICRF
es creado con la finalidad de digitalizar todos los documentos (Papeles) y, así eliminar
los problemas presentados en el Centro.
Diseño de datos
a. Objetos de la Base de Datos
Tablas
-
Todas las tablas de la base de datos, iniciarán su nombre anteponiendo la letra
t al nombre de la tabla. Deberá existir como máximo tres palabras por cada
nombre de la tabla, de la siguiente manera:
tNombreDeTabla
ejm:
tPacientesInformacionBasico
Tablas de relación
-
Los nombres de las tablas de relación, empezará con la letra r. No existirá un
número máximo de palabras para el nombre de la tabla de relación, de la
siguiente manera:
RNombreRelacion
ejm:
RUsuariosxUsuarioPaciente
Índices
203
-
Llamaremos índices primarios a aquellos que identifican unívocamente a cada
fila de una tabla (clave primaria o clave candidata140).
Los índices primarios se nombrarán anteponiendo la letra i al nombre del
índice, de la siguiente manera:
iNombreÍndice
ejm:
Icódigo
Vistas
-
Los nombres de las vistas, empezará con la letra v y a continuación el nombre
de la vista, de la siguiente manera:
vNombreVista
ejm: vCedulaxPacientes
A cada tabla, vista o secuencia se le asignará una abreviatura de no más de tres
caracteres que se empleará en la cualificación de campos en sentencias SQL que
involucren a más de una tabla.
Por ejemplo, la abreviatura asignada a la tabla
ejm:
tUsuarios podría ser tus
Atributos o Campos
-
Los atributos o campos pertenecientes a una tabla, deberán escribirse
utilizando las primeras letras del nombre de la tabla y a continuación el
nombre respectivo del atributo. Además, el nombre de los campos no deberá
exceder de 25 caracteres, de la siguiente manera:
tus_código Donde la abreviatura tus viene de la tabla usuarios.
tpaba_código
Donde la abreviatura tpaba viene de la tabla
PacientesInformaciónBásico
Los atributos de las tablas de relación, deben empezar con el prefijo que se forma de
las primeras letras del nombre de la tabla de la relación.
Ejm:
tlogope_código
LogopedicoRL
Donde la abreviatura tlogope viene de la tabla
140
La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus tuplas
de modo único
204
b. Interfaz
Formularios
-
Para la identificación de un formulario se colocará los respectivos nombres, de
la siguiente manera
antecedentes_personalesrf
antecedentes_personalesrl
Donde rf pertenece a Rehabilitación Física y rl pertenece a Rehabilitación de Lenguaje.
Consultas (queries)
-
Las consultas se nombrarán anteponiendo el prefijo c al nombre de la consulta
(identificador) de no más de 20 caracteres. El identificador se derivará de la
tabla sobre la que se realiza la consulta. Para consultas complejas, esto es, joins
de varias tablas, el identificador se derivará de la tabla más significativa. Si la
elección no estuviese clara, se procurará asignar nombres de forma justificada,
de la siguiente manera:
cNombreConsulta
ejm:
cGrupoEdadesxPaciente
Reportes
-
Para identificar los reportes anteponemos la letra r, al nombre del
identificador. Como se muestra a continuación:
rNombreReporte
ejm: rRehabilitación Física
c. Manipulación de datos
Batch
Será utilizado para realizar acciones comunes en procesamientos batch141 (lectura/
escritura de archivo, acceso a base de datos, etc.).
141
Archivo de procesamiento por lotes
205
-
-
Para poder utilizar lotes de información, se creará sentencias transactsql. El
nombre que se le asignará a la información creada (batch), se lo denotará:
Nombre.sql ejm: InsertarPaciente.sql
Cada archivo creado, deberá tener la documentación necesaria para su
utilización (comentarios).
5. COMENTARIOS
Los comentarios serán utilizados para comentar las acciones que se realicen en el
código de la programación, así como en las sentencias sql.
Cometarios de una línea
-
Para comentar el código o sentencia sql, en una sola línea, se utilizará dos
barras inclinadas a la derecha (//).
Ejm: // Esto es un comentario de una línea
Comentarios de más de una línea
-
Para comentar el código o sentencia sql de más de una línea se deberá abrir y
cerrar el comentario, para abrir se utilizarán los símbolos una barra inclinada
hacia la derecha seguida de un asterisco y para cerrar el comentario deberá
utilizar un asterisco y una barra inclinada.
Los comentarios deberán escribirse de acuerdo con la siguiente nomenclatura:
/* fecha_realiza_corrección
Por ejemplo: /* 09-11-21
Nombre_programador
razón
*/
Pedro López Actualizar Usuarios*/
Si en el código existente realizamos una modificación no mayor a diez líneas,
realizamos un comentario en el mismo archivo explicando la función que cumple el
código o también realizando un nuevo comentario si el código ha sido alterado.
Si el código excede a diez líneas pasar al punto 5.
206
6. NOMBRES DE ARCHIVOS
Existirán tres tipos de archivos:
-
Datos
Bitácoras
Interfaz
Datos
Entre los archivos de datos existirán:
Archivos de datos lógicos, archivos de datos físicos, archivos de datos sql y catálogos,
archivos de sql de mantenimiento, archivos de datos sps y para triggers.
-
En los archivos lógicos tendremos archivos tipo cdm y bitácoras.
En los archivos físicos tendremos archivos como pdm.
Además de los archivos antes mencionados tendremos archivos sps y triggers que
están almacenados en un formato txt.
Bitácora
Será utilizada para registrar los cambios en el código de la programación así como en
las sentencias sql de la base de datos. Para registrar cada bitácora creada se deberá
utilizar la siguiente nomenclatura:
nombreArchivo_fecha_version
ejm:
Interfaz
207
bddproyhsvp`_09112009_1.cdm
De acuerdo con el diseño de módulos
3.2.2 DISEÑO ARQUITECTÓNICO
Presentación
Ingresar SGICRF
Usuario
Servicio
Ingresar Modificar Eliminar Información
MySQL
Datos
Figura 2.1: Diagrama Arquitectónico SGICRF
Fuente: Autores
El Sistema está diseñado en la Arquitectura Cliente/Servidor, además en tres capas:
• Presentación
• Servicios
• Datos
-
DIAGRAMA DE EMPLAZAMIENTO
Servidor de BDD
PC con Windows
Base de
TCP / IP
Datos
Aplicación
Sistema SGICRF
P
208
Paquetes
MySQL
Conexión
Figura 2.2: Diagrama de Emplazamiento SGICRF
Fuente: Autores
El Diagrama de Emplazamiento muestra las relaciones físicas entre los componentes
de un Software y Hardware del Sistema SGICRF, la aplicación se conecta mediante una
conexión de red con el servidor de la base de datos.
209
-
DIAGRAMA DE ACTIVIDADES
Inicio
Datos
Incorrectos
Validar
Exito
Menú Principal
Seleccionar Terapia
Rehabilitación Lenguaje
Generar Reportes
Buscar Paciente RL
Nuevo Paciente RL
Generar Reportes RF
Buscar Paciente RF
Nuevo Paciente RF
Historia Clínica RF
Datos Personales RF
Historia
Busqueda General
Historia Clínica RL
Datos Personales RL
Historia RL
Busqueda General RL
Salir
Terminar
Figura 2.3: Diagrama de Actividades SGICRF
Fuente: Autores
210
El Diagrama de Actividades describe el comportamiento de los procedimientos del
Sistema de Gestión de Información para el Centro de Rehabilitación Física, permitiendo
visualizar el orden de las actividades a realizarse.
-
DIAGRAMA DE PAQUETES
PAQUETE DE_INTEFAZ GRAFICA
Frm_TUsuarios
Frm_TPacienteBasico
Frm_TPacienteVariable
Frm_TMedico Referente
Frm_TInstitucionsolicita
Frm_TGrupoedades
Frm_Ttipoantecedetespersonales
PAQUETE DE NEGOCIOS
Paq_TUsuarios
Paq_TPacienteBasico
PAQUETE BDD
Paq_TPacienteVariable
= Registros
Paq _TMedico Referente
Paq _TInstitucionsolicita
Paq _TGrupoedades
Figura 2.4: Diagrama de Paquetes SGICRF
Fuente: Autores
El Diagrama de Paquetes muestra las relaciones entre los paquetes del sistema,
detallando la fragmentación del mismo para mejor comprensión de su
funcionamiento.
3.2.3 DISEÑO DE DATOS
La Base de Datos está desarrollada en MySql.
-
DISEÑO CONCEPTUAL
Para el desarrollo del Diseño Conceptual de la Base de Datos se utilizó Power
Designer versión 9.
211
tUsuarios
tus_usuario
A50
tus_contraseña
A20
tus_codigo
<pi> I
<M>
tus_estado
BL
Identifier_1 <pi>
Rtus_Rtuspa
tUsuarioPaciente
tPacienteInformacionVariablesRL
tuspa_codigo <pi> I <M>
Identifier_1 <pi>
tPacientesInformacionVariablesRF
tpavaRF_codigo
<pi> I
<M>
tpava_ocupacion
A100
tpava_estadocivil
A20
tpava_domicilio
A100
tpava_celular
A10
tpava_telefono
A10
tpava_fechaconsulta
D
tpava_edad
A50
Rtpaba_Rtuspa
Rtpaba_RtpavaRF
Rtpaba_RtpavaRL
tpaba_codigo
<pi> I
<M>
tpaba_nombres
A100
tpaba_apellidos
A100
tpaba_cedula
A10
tpaba_fechanacimiento
D
tpaba_sexo
A2
tpaba_nacionalidad
A100
Identifier_1 <pi>
Rtpaba_RtdiagRL
Identifier_3 <pi>
tDiagnosticoLogopedicoRL
Identifier_1 <pi>
Rtpaba_RtdiagRF
tMedicoReferente
tDiagnosticoRF
tdiagRF_codigo <pi> I
<M>
tdiagRF_medref
LVA500
Rtpaba_RtdiaglopeRL
Rmedref_RtdiagRF
Identifier_1 <pi>
tmedref_codigo
<pi> I
<M>
tmedref_nombres
A100
tmedref_apellidos
A100
tmedref_especialidad
A100
tLogopedicoRL
Rtmedref_RtdiagRL
tdiagRL_codigo <pi> I
<M>
tdiagRL_detalles
LVA500
Rtinstsoli_RtdiagRL
tinstsoli_codigo
<pi> I
<M>
tinstsoli_descripcion
A100
tinstsoli_contador
I
Rtdiagmedref_RtdiagRL
tGruposEdades
Rtgrupeda_RtdiagRL
tDiagnosticoMedicoRefiereRL
tgrupeda_codigo
<pi> I
<M>
tgrupeda_descripcion
A100
tdiagmedref_codigo
<pi> I
<M>
tdiagmedref_descripcion
A100
Identifier_1 <pi>
RtdiagRF_RtdiagtrataRF
Identifier_1 <pi>
Identifier_1 <pi>
Identifier_1 <pi>
Rtgrupeda_RtdiagRF
tlogope_codigo
<pi> I
<M>
tlogope_descripcion
A100
tDiagnosticoRL
tInstitucionSolicita
Rtlogope_RtdiaglogopeRL
tdiaglogope_codigo
N10
tlogope_observaciones LVA500
Rtpaba_RttrataRL
Identifier_1 <pi>
Rtinstsoli_RtdiagRF
tpava_escolariad
A100
tpava_grado
A50
tpava_domicilio
A100
tpava_telefono
A10
tpava_celular
A10
tpava_fechaconsulta
D
tpava_edad
A50
tpava_estado
BL
tpavaRL_codigo
<pi> I
<M>
tpava_nombreinforma
A200
tpava_relacionpaci
A100
Identifier_1 <pi>
tTipoAntecedentesPersonales
ttipoantper_Codigo
<pi> I
<M>
ttipoantper_descripcion
A100
ttipoantper_tipo
I
Rtpaba_RttrataRF
Identifier_1 <pi>
Rttipoantper_Rtantdiag
RtdiagRL_Rtantdiag
tAntecedentesDiagnostico
RtdiagRF_Rtantdiag
tantdiag_codigo <pi> I
<M>
tantdiag_detalles
LVA500
Rtses_RtdiagRF
Identifier_1 <pi>
tDiagnosticoTratamientoRF
tAtenciontTratamiento
RttrataRF_Rtatentrata
tatentrata_codigo <pi> I <M>
Identifier_1 <pi>
Rttipotra_RttrataRL
Rttipotra_RttrataRF
tTipoTratamiento
tTratamientoRL
ttipotra_codigo
<pi> I
<M>
ttipotra_descripcion
A100
RttrataRF_RtdiagtrataRF
ttratarl_observaciones LA500
Identifier_1 <pi>
tTratamientoRF
tFisioterapista
ttrataRF_codigo
<pi> I
<M>
ttrataRF_observaciones
LVA500
ttipotrata_tiporehabilitacion
I
tfisiote_codigo
<pi> I
<M>
tfisiote_nombres
A100
tfisiote_apellidos
A100
Identifier_1 <pi>
Identifier_1 <pi>
Rtfisiote_RttrataRL
Rtfisiote_Rtses
Rtses_RttrataRL
Rtses_RttrataRF
tSesiones
tses_codigo
<pi> I <M>
tses_fecha
D
tses_tipomedico
I
Rtses_RtdiagRL
Identifier_1 <pi>
Rtses_Rttipo
tTipoMedico
ttipo_codigo I
ttipo_detalles LVA500
Rtfintra_RttrataRF
tFinalizacionTratamiento
Rtfintra_RttrataRL
tfintra_codigo
<pi> I
<M>
tfintra_descripcion
A100
Identifier_1 <pi>
Figura 2.5: Modelo Conceptual BDD SGICRF
Fuente: Autores
212
-
DISEÑO FÍSICO
tUsuarios
tus_usuario
tus_contraseña
tus_codigo
tus_estado
char(50)
char(20)
integer <pk>
smallint
Rtus_Rtuspa
tUsuarioPaciente
tPacientesInformacionVariablesRF
tpavaRF_codigo
tpaba_codigo
tpava_ocupacion
tpava_estadocivil
tpava_domicilio
tpava_celular
tpava_telefono
tpava_fechaconsulta
tpava_edad
integer
<pk>
integer
<fk>
char(100)
char(20)
char(100)
char(10)
char(10)
date
char(50)
Rtpaba_Rtuspa
Rtpaba_RtpavaRF
tpaba_codigo
tpaba_nombres
tpaba_apellidos
tpaba_cedula
tpaba_fechanacimiento
tpaba_sexo
tpaba_nacionalidad
Rtpaba_RtdiagRF
integer
<pk>
char(100)
char(100)
char(10)
date
char(2)
char(100)
Rtpaba_RtpavaRL
Rtpaba_RtdiaglopeRL
Rtpaba_RtdiagRL
<pk>
<fk2>
<fk4>
<fk1>
<fk3>
<fk5>
tmedref_codigo
tmedref_nombres
tmedref_apellidos
tmedref_especialidad
Rmedref_RtdiagRF
tInstitucionSolicita
Rtgrupeda_RtdiagRF
integer
<fk1>
integer
<fk2>
numeric(10)
long varchar
RtdiaglogopeRL_RtlogopeRL
tDiagnosticoRL
Rtmedref_RtdiagRL
Rtinstsoli_RtdiagRL
tinstsoli_codigo
integer
<pk>
tinstsoli_descripcion char(100)
tinstsoli_contador
integer
Rtinstsoli_RtdiagRF
Rtpaba_RttrataRF
integer
<pk>
char(100)
char(100)
char(100)
char(100)
char(50)
char(100)
char(10)
char(10)
date
char(50)
smallint
integer
<pk>
integer
<fk>
char(200)
char(100)
tDiagnosticoLogopedicoRL
tMedicoReferente
integer
integer
integer
integer
integer
integer
long varchar
tpava_escolariad
tpava_grado
tpava_domicilio
tpava_telefono
tpava_celular
tpava_fechaconsulta
tpava_edad
tpava_estado
tpavaRL_codigo
tpaba_codigo
tpava_nombreinforma
tpava_relacionpaci
tpaba_codigo
tlogope_codigo
tdiaglogope_codigo
tlogope_observaciones
Rtpaba_RttrataRL
tDiagnosticoRF
tdiagRF_codigo
tinstsoli_codigo
tpaba_codigo
tmedref_codigo
tgrupeda_codigo
tses_codigo
tdiagRF_medref
tPacienteInformacionVariablesRL
tuspa_codigo integer <pk>
tpaba_codigo integer <fk2>
tus_codigo
integer <fk1>
Rtgrupeda_RtdiagRL
tdiagRL_codigo
tpaba_codigo
tdiagmedref_codigo
tmedref_codigo
tinstsoli_codigo
tses_codigo
tgrupeda_codigo
tdiagRL_detalles
integer
integer
integer
integer
integer
integer
integer
long varchar
<pk>
<fk6>
<fk4>
<fk1>
<fk2>
<fk5>
<fk3>
tLogopedicoRL
tlogope_codigo
integer
<pk>
tlogope_descripcion char(100)
tGruposEdades
Rtdiagmedref_RtdiagRL
tgrupeda_codigo
integer
<pk>
tgrupeda_descripcion char(100)
tDiagnosticoMedicoRefiereRL
tTipoAntecedentesPersonales
tdiagmedref_codigo
integer
<pk>
tdiagmedref_descripcion char(100)
ttipoantper_Codigo
integer
<pk>
ttipoantper_descripcion char(100)
ttipoantper_tipo
integer
RtdiagRF_RtdiagtrataRF
Rttipoantper_Rtantdiag
RtdiagRF_Rtantdiag
tantdiag_codigo
tdiagRL_codigo
ttipoantper_Codigo
tdiagRF_codigo
tantdiag_detalles
Rtses_RtdiagRF
integer
integer
integer
integer
long varchar
<pk>
<fk3>
<fk1>
<fk2>
tAtenciontTratamiento
tDiagnosticoTratamientoRF
ttrataRF_codigo integer <fk2>
tdiagRF_codigo integer <fk1>
RttrataRF_Rtatentrata
Rttipotra_RttrataRF
RttrataRF_RtdiagtrataRF
tTratamientoRF
ttrataRF_codigo
tfintra_codigo
tses_codigo
tpaba_codigo
ttipotra_codigo
ttrataRF_observaciones
ttipotrata_tiporehabilitacion
RtdiagRL_Rtantdiag
tAntecedentesDiagnostico
integer
integer
integer
integer
integer
long varchar
integer
tatentrata_codigo integer <pk>
ttrataRF_codigo
integer <fk>
tTipoTratamiento
tTratamientoRL
Rttipotra_RttrataRL
ttipotra_codigo
integer
<pk>
tpaba_codigo
integer
ttipotra_descripcion char(100)
tses_codigo
integer
ttipotra_codigo
integer
tfisiote_codigo
integer
tFisioterapista
tfintra_codigo
integer
ttratarl_observaciones
varchar(500)
tfisiote_codigo
integer
<pk>
tfisiote_nombres char(100)
tfisiote_apellidos char(100)
<pk>
<fk1>
<fk4>
<fk2>
<fk3>
<fk5>
<fk2>
<fk3>
<fk4>
<fk1>
Rtfisiote_RttrataRL
Rtfisiote_Rtses
Rtses_RttrataRL
Rtses_RttrataRF
tSesiones
tses_codigo
tfisiote_codigo
tses_fecha
tses_tipomedico
Rtses_RtdiagRL
integer <pk>
integer <fk>
date
integer
Rtses_Rttipo
tTipoMedico
tses_codigo
integer
<fk>
ttipo_codigo integer
ttipo_detalles long varchar
Rtfintra_RttrataRL
Rtfintra_RttrataRF
tFinalizacionTratamiento
tfintra_codigo
integer
<pk>
tfintra_descripcion char(100)
Figura 2.6: Modelo Físico BDD SGICRF
Fuente: Autores
213
-
SCRIPT
/*==============================================================*/
/* Table: TANTECEDENTESDIAGNOSTICO
*/
/*==============================================================*/
create table TANTECEDENTESDIAGNOSTICO
(
TANTDIAG_CODIGO
TDIAGRL_CODIGO
integer
not null,
integer,
TTIPOANTPER_CODIGO integer,
TDIAGRF_CODIGO
integer,
TANTDIAG_DETALLES long varchar,
primary key (TANTDIAG_CODIGO)
);
/*==============================================================*/
/* Index: RELATIONSHIP_11_FK
*/
/*==============================================================*/
create index RELATIONSHIP_11_FK on TANTECEDENTESDIAGNOSTICO (
TTIPOANTPER_CODIGO ASC
);
/*==============================================================*/
/* Index: RTDIAGRF_RTANTDIAG_FK
*/
/*==============================================================*/
create index RTDIAGRF_RTANTDIAG_FK on TANTECEDENTESDIAGNOSTICO (
214
TDIAGRF_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
create index RELATIONSHIP_30_FK on TANTECEDENTESDIAGNOSTICO (
TDIAGRL_CODIGO ASC
);
/*==============================================================*/
/* Table: TATENCIONTTRATAMIENTO
*/
/*==============================================================*/
create table TATENCIONTTRATAMIENTO
(
TATENTRATA_CODIGO integer
TTRATARF_CODIGO
not null,
integer,
primary key (TATENTRATA_CODIGO)
);
/*==============================================================*/
/* Index: RTTRATARF_RTATENTRATA_FK
*/
/*==============================================================*/
create index RTTRATARF_RTATENTRATA_FK on TATENCIONTTRATAMIENTO (
TTRATARF_CODIGO ASC
);
215
/*==============================================================*/
/* Table: TDIAGNOSTICOLOGOPEDICORL
*/
/*==============================================================*/
create table TDIAGNOSTICOLOGOPEDICORL
(
TPABA_CODIGO
TLOGOPE_CODIGO
integer,
integer,
TDIAGLOGOPE_CODIGO numeric(10),
TLOGOPE_OBSERVACIONES long varchar
);
/*==============================================================*/
*/
/*==============================================================*/
create index RELATIONSHIP_34_FK on TDIAGNOSTICOLOGOPEDICORL (
TPABA_CODIGO ASC
);
/*==============================================================*/
/* Table: TDIAGNOSTICOMEDICOREFIERERL
*/
/*==============================================================*/
create table TDIAGNOSTICOMEDICOREFIERERL
(
TDIAGMEDREF_CODIGO integer
not null,
TDIAGMEDREF_DESCRIPCION char(100),
216
primary key (TDIAGMEDREF_CODIGO)
);
/*==============================================================*/
/* Table: TDIAGNOSTICORF
*/
/*==============================================================*/
create table TDIAGNOSTICORF
(
TDIAGRF_CODIGO
integer
TINSTSOLI_CODIGO
integer,
TPABA_CODIGO
integer,
TMEDREF_CODIGO
integer,
TGRUPEDA_CODIGO
TSES_CODIGO
not null,
integer,
integer,
TDIAGRF_MEDREF
long varchar,
primary key (TDIAGRF_CODIGO)
);
/*==============================================================*/
*/
/*==============================================================*/
create index RELATIONSHIP_26_FK on TDIAGNOSTICORF (
TMEDREF_CODIGO ASC
);
/*==============================================================*/
217
/* Index: RTINSTSOLI_RTDIAGRF_FK
*/
/*==============================================================*/
create index RTINSTSOLI_RTDIAGRF_FK on TDIAGNOSTICORF (
TINSTSOLI_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
TGRUPEDA_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
TPABA_CODIGO ASC
);
/*==============================================================*/
/* Index: RTSES_RTDIAGRF_FK
*/
/*==============================================================*/
create index RTSES_RTDIAGRF_FK on TDIAGNOSTICORF (
TSES_CODIGO ASC
);
218
/*==============================================================*/
/* Table: TDIAGNOSTICORL
*/
/*==============================================================*/
create table TDIAGNOSTICORL
(
TDIAGRL_CODIGO
integer
TPABA_CODIGO
not null,
integer,
TDIAGMEDREF_CODIGO integer,
TMEDREF_CODIGO
integer,
TINSTSOLI_CODIGO
integer,
TSES_CODIGO
integer,
TGRUPEDA_CODIGO
TDIAGRL_DETALLES
integer,
long varchar,
primary key (TDIAGRL_CODIGO)
);
/*==============================================================*/
/* Index: RTMEDREF_RTDIAGRL_FK
*/
/*==============================================================*/
create index RTMEDREF_RTDIAGRL_FK on TDIAGNOSTICORL (
TMEDREF_CODIGO ASC
);
/*==============================================================*/
/* Index: RTINSTSOLI_RTDIAGRL_FK
*/
219
/*==============================================================*/
create index RTINSTSOLI_RTDIAGRL_FK on TDIAGNOSTICORL (
TINSTSOLI_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
create index RELATIONSHIP_28_FK on TDIAGNOSTICORL (
TGRUPEDA_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
TDIAGMEDREF_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
TSES_CODIGO ASC
);
220
/*==============================================================*/
*/
/*==============================================================*/
TPABA_CODIGO ASC
);
/*==============================================================*/
/* Table: TDIAGNOSTICOTRATAMIENTORF
*/
/*==============================================================*/
create table TDIAGNOSTICOTRATAMIENTORF
(
TTRATARF_CODIGO
TDIAGRF_CODIGO
integer,
integer
);
/*==============================================================*/
*/
/*==============================================================*/
create index RELATIONSHIP_39_FK on TDIAGNOSTICOTRATAMIENTORF (
TDIAGRF_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
221
create index RELATIONSHIP_40_FK on TDIAGNOSTICOTRATAMIENTORF (
TTRATARF_CODIGO ASC
);
/*==============================================================*/
/* Table: TFINALIZACIONTRATAMIENTO
*/
/*==============================================================*/
create table TFINALIZACIONTRATAMIENTO
(
TFINTRA_CODIGO
integer
not null,
TFINTRA_DESCRIPCION char(100),
primary key (TFINTRA_CODIGO)
);
/*==============================================================*/
/* Table: TFISIOTERAPISTA
*/
/*==============================================================*/
create table TFISIOTERAPISTA
(
TFISIOTE_CODIGO
TFISIOTE_NOMBRES
integer
not null,
char(100),
TFISIOTE_APELLIDOS char(100),
primary key (TFISIOTE_CODIGO)
);
/*==============================================================*/
222
/* Table: TGRUPOSEDADES
*/
/*==============================================================*/
create table TGRUPOSEDADES
(
TGRUPEDA_CODIGO
integer
not null,
TGRUPEDA_DESCRIPCION char(100),
primary key (TGRUPEDA_CODIGO)
);
/*==============================================================*/
/* Table: TINSTITUCIONSOLICITA
*/
/*==============================================================*/
create table TINSTITUCIONSOLICITA
(
TINSTSOLI_CODIGO
integer
not null,
TINSTSOLI_DESCRIPCION char(100),
TINSTSOLI_CONTADOR integer,
primary key (TINSTSOLI_CODIGO)
);
/*==============================================================*/
/* Table: TLOGOPEDICORL
*/
/*==============================================================*/
create table TLOGOPEDICORL
(
TLOGOPE_CODIGO
integer
not null,
223
TLOGOPE_DESCRIPCION char(100),
primary key (TLOGOPE_CODIGO)
);
/*==============================================================*/
/* Table: TMEDICOREFERENTE
*/
/*==============================================================*/
create table TMEDICOREFERENTE
(
TMEDREF_CODIGO
integer
TMEDREF_NOMBRES
not null,
char(100),
TMEDREF_APELLIDOS char(100),
TMEDREF_ESPECIALIDAD char(100),
primary key (TMEDREF_CODIGO)
);
/*==============================================================*/
/* Table: TPACIENTEINFORMACIONVARIABLESRL
*/
/*==============================================================*/
create table TPACIENTEINFORMACIONVARIABLESRL
(
TPAVA_ESCOLARIAD
TPAVA_GRADO
char(100),
char(50),
TPAVA_DOMICILIO
char(100),
TPAVA_TELEFONO
char(10),
TPAVA_CELULAR
char(10),
224
TPAVA_FECHACONSULTA date,
TPAVA_EDAD
TPAVA_ESTADO
TPAVARL_CODIGO
TPABA_CODIGO
char(50),
smallint,
integer
not null,
integer,
TPAVA_NOMBREINFORMA char(200),
TPAVA_RELACIONPACI char(100),
primary key (TPAVARL_CODIGO)
);
/*==============================================================*/
/* Index: RTPABA_RTPAVARL_FK
*/
/*==============================================================*/
create index RTPABA_RTPAVARL_FK on TPACIENTEINFORMACIONVARIABLESRL (
TPABA_CODIGO ASC
);
/*==============================================================*/
/* Table: TPACIENTESINFORMACIONBASICO
*/
/*==============================================================*/
create table TPACIENTESINFORMACIONBASICO
(
TPABA_CODIGO
integer
TPABA_NOMBRES
char(100),
TPABA_APELLIDOS
char(100),
TPABA_CEDULA
not null,
char(10),
225
TPABA_FECHANACIMIENTO date,
TPABA_SEXO
char(2),
TPABA_NACIONALIDAD char(100),
primary key (TPABA_CODIGO)
);
/*==============================================================*/
/* Table: TPACIENTESINFORMACIONVARIABLESRF
*/
/*==============================================================*/
create table TPACIENTESINFORMACIONVARIABLESRF
(
TPAVARF_CODIGO
integer
TPABA_CODIGO
not null,
integer,
TPAVA_OCUPACION
char(100),
TPAVA_ESTADOCIVIL char(20),
TPAVA_DOMICILIO
TPAVA_CELULAR
TPAVA_TELEFONO
char(100),
char(10),
char(10),
TPAVA_FECHACONSULTA date,
TPAVA_EDAD
char(50),
primary key (TPAVARF_CODIGO)
);
/*==============================================================*/
/* Index: RTPABA_RTPAVARF_FK
*/
/*==============================================================*/
226
create index RTPABA_RTPAVARF_FK on TPACIENTESINFORMACIONVARIABLESRF (
TPABA_CODIGO ASC
);
/*==============================================================*/
/* Table: TSESIONES
*/
/*==============================================================*/
create table TSESIONES
(
TSES_CODIGO
integer
TFISIOTE_CODIGO
TSES_FECHA
not null,
integer,
date,
TSES_TIPOMEDICO
integer,
primary key (TSES_CODIGO)
);
/*==============================================================*/
*/
/*==============================================================*/
create index RELATIONSHIP_36_FK on TSESIONES (
TFISIOTE_CODIGO ASC
);
/*==============================================================*/
/* Table: TTIPOANTECEDENTESPERSONALES
*/
/*==============================================================*/
227
create table TTIPOANTECEDENTESPERSONALES
(
TTIPOANTPER_CODIGO integer
not null,
TTIPOANTPER_DESCRIPCION char(100),
TTIPOANTPER_TIPO
integer,
primary key (TTIPOANTPER_CODIGO)
);
/*==============================================================*/
/* Table: TTIPOMEDICO
*/
/*==============================================================*/
create table TTIPOMEDICO
(
TSES_CODIGO
integer,
TTIPO_CODIGO
integer,
TTIPO_DETALLES
long varchar
);
/*==============================================================*/
/* Index: RTSES_RTTIPO_FK
*/
/*==============================================================*/
create index RTSES_RTTIPO_FK on TTIPOMEDICO (
TSES_CODIGO ASC
);
/*==============================================================*/
228
/* Table: TTIPOTRATAMIENTO
*/
/*==============================================================*/
create table TTIPOTRATAMIENTO
(
TTIPOTRA_CODIGO
integer
not null,
TTIPOTRA_DESCRIPCION char(100),
primary key (TTIPOTRA_CODIGO)
);
/*==============================================================*/
/* Table: TTRATAMIENTORF
*/
/*==============================================================*/
create table TTRATAMIENTORF
(
TTRATARF_CODIGO
TFINTRA_CODIGO
TSES_CODIGO
TPABA_CODIGO
TTIPOTRA_CODIGO
integer
not null,
integer,
integer,
integer,
integer,
TTRATARF_OBSERVACIONES long varchar,
TTIPOTRATA_TIPOREHABILITACION integer,
primary key (TTRATARF_CODIGO)
);
/*==============================================================*/
*/
229
/*==============================================================*/
create index RELATIONSHIP_38_FK on TTRATAMIENTORF (
TFINTRA_CODIGO ASC
);
/*==============================================================*/
/* Index: RTPABA_RTTRATARF_FK
*/
/*==============================================================*/
create index RTPABA_RTTRATARF_FK on TTRATAMIENTORF (
TPABA_CODIGO ASC
);
/*==============================================================*/
/* Index: RTTIPOTRA_RTTRATARF_FK
*/
/*==============================================================*/
create index RTTIPOTRA_RTTRATARF_FK on TTRATAMIENTORF (
TTIPOTRA_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
create index RELATIONSHIP_51_FK on TTRATAMIENTORF (
TSES_CODIGO ASC
);
230
/*==============================================================*/
/* Table: TTRATAMIENTORL
*/
/*==============================================================*/
create table TTRATAMIENTORL
(
TPABA_CODIGO
TSES_CODIGO
integer,
integer,
TTIPOTRA_CODIGO
integer,
TFISIOTE_CODIGO
integer,
TFINTRA_CODIGO
integer,
TTRATARL_OBSERVACIONES varchar(500)
);
/*==============================================================*/
*/
/*==============================================================*/
create index RELATIONSHIP_35_FK on TTRATAMIENTORL (
TFINTRA_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
TSES_CODIGO ASC
);
231
/*==============================================================*/
*/
/*==============================================================*/
TTIPOTRA_CODIGO ASC
);
/*==============================================================*/
/* Index: RTFISIOTE_RTTRATARL_FK
*/
/*==============================================================*/
create index RTFISIOTE_RTTRATARL_FK on TTRATAMIENTORL (
TFISIOTE_CODIGO ASC
);
/*==============================================================*/
*/
/*==============================================================*/
TPABA_CODIGO ASC
);
/*==============================================================*/
/* Table: TUSUARIOPACIENTE
*/
/*==============================================================*/
create table TUSUARIOPACIENTE
232
(
TUSPA_CODIGO
integer
TPABA_CODIGO
integer,
TUS_CODIGO
not null,
integer,
primary key (TUSPA_CODIGO)
);
/*==============================================================*/
/* Index: RTUS_RTUSPA_FK
*/
/*==============================================================*/
create index RTUS_RTUSPA_FK on TUSUARIOPACIENTE (
TUS_CODIGO ASC
);
/*==============================================================*/
/* Index: RTPABA_RTUSPA_FK
*/
/*==============================================================*/
create index RTPABA_RTUSPA_FK on TUSUARIOPACIENTE (
TPABA_CODIGO ASC
);
/*==============================================================*/
/* Table: TUSUARIOS
*/
/*==============================================================*/
create table TUSUARIOS
(
233
TUS_USUARIO
TUS_CONTRASENA
char(50),
char(20),
TUS_CODIGO
integer
TUS_ESTADO
smallint,
not null,
primary key (TUS_CODIGO)
);
alter table TANTECEDENTESDIAGNOSTICO
add foreign key Rttipoantper_Rtantdiag (TTIPOANTPER_CODIGO)
references TTIPOANTECEDENTESPERSONALES (TTIPOANTPER_CODIGO)
on update restrict
on delete restrict;
add foreign key RtdiagRL_Rtantdiag (TDIAGRL_CODIGO)
references TDIAGNOSTICORL (TDIAGRL_CODIGO)
on update restrict
on delete restrict;
add foreign key RtdiagRF_Rtantdiag (TDIAGRF_CODIGO)
references TDIAGNOSTICORF (TDIAGRF_CODIGO)
on update restrict
on delete restrict;
alter table TATENCIONTTRATAMIENTO
234
add foreign key RttrataRF_Rtatentrata (TTRATARF_CODIGO)
references TTRATAMIENTORF (TTRATARF_CODIGO)
on update restrict
on delete restrict;
alter table TDIAGNOSTICOLOGOPEDICORL
add foreign key Rtpaba_RtdiaglopeRL (TPABA_CODIGO)
references TPACIENTESINFORMACIONBASICO (TPABA_CODIGO)
on update restrict
on delete restrict;
alter table TDIAGNOSTICOLOGOPEDICORL
add foreign key RtdiaglogopeRL_RtlogopeRL (TLOGOPE_CODIGO)
references TLOGOPEDICORL (TLOGOPE_CODIGO)
on update restrict
on delete restrict;
alter table TDIAGNOSTICORF
add foreign key Rtgrupeda_RtdiagRF (TGRUPEDA_CODIGO)
references TGRUPOSEDADES (TGRUPEDA_CODIGO)
on update restrict
on delete restrict;
add foreign key Rmedref_RtdiagRF (TMEDREF_CODIGO)
references TMEDICOREFERENTE (TMEDREF_CODIGO)
235
on update restrict
on delete restrict;
add foreign key Rtinstsoli_RtdiagRF (TINSTSOLI_CODIGO)
references TINSTITUCIONSOLICITA (TINSTSOLI_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtpaba_RtdiagRF (TPABA_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtses_RtdiagRF (TSES_CODIGO)
references TSESIONES (TSES_CODIGO)
on update restrict
on delete restrict;
alter table TDIAGNOSTICORL
add foreign key Rtgrupeda_RtdiagRL (TGRUPEDA_CODIGO)
references TGRUPOSEDADES (TGRUPEDA_CODIGO)
on update restrict
on delete restrict;
236
add foreign key Rtdiagmedref_RtdiagRL (TDIAGMEDREF_CODIGO)
references TDIAGNOSTICOMEDICOREFIERERL (TDIAGMEDREF_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtpaba_RtdiagRL (TPABA_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtses_RtdiagRL (TSES_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtinstsoli_RtdiagRL (TINSTSOLI_CODIGO)
references TINSTITUCIONSOLICITA (TINSTSOLI_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtmedref_RtdiagRL (TMEDREF_CODIGO)
237
references TMEDICOREFERENTE (TMEDREF_CODIGO)
on update restrict
on delete restrict;
alter table TDIAGNOSTICOTRATAMIENTORF
add foreign key RtdiagRF_RtdiagtrataRF (TDIAGRF_CODIGO)
references TDIAGNOSTICORF (TDIAGRF_CODIGO)
on update restrict
on delete restrict;
alter table TDIAGNOSTICOTRATAMIENTORF
add foreign key RttrataRF_RtdiagtrataRF (TTRATARF_CODIGO)
references TTRATAMIENTORF (TTRATARF_CODIGO)
on update restrict
on delete restrict;
alter table TPACIENTEINFORMACIONVARIABLESRL
add foreign key Rtpaba_RtpavaRL (TPABA_CODIGO)
on update restrict
on delete restrict;
alter table TPACIENTESINFORMACIONVARIABLESRF
add foreign key Rtpaba_RtpavaRF (TPABA_CODIGO)
on update restrict
238
on delete restrict;
alter table TSESIONES
add foreign key Rtfisiote_Rtses (TFISIOTE_CODIGO)
references TFISIOTERAPISTA (TFISIOTE_CODIGO)
on update restrict
on delete restrict;
alter table TTIPOMEDICO
add foreign key Rtses_Rttipo (TSES_CODIGO)
on update restrict
on delete restrict;
alter table TTRATAMIENTORF
add foreign key Rtfintra_RttrataRF (TFINTRA_CODIGO)
references TFINALIZACIONTRATAMIENTO (TFINTRA_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtses_RttrataRF (TSES_CODIGO)
on update restrict
on delete restrict;
239
add foreign key Rtpaba_RttrataRF (TPABA_CODIGO)
on update restrict
on delete restrict;
add foreign key Rttipotra_RttrataRF (TTIPOTRA_CODIGO)
references TTIPOTRATAMIENTO (TTIPOTRA_CODIGO)
on update restrict
on delete restrict;
alter table TTRATAMIENTORL
add foreign key Rtfintra_RttrataRL (TFINTRA_CODIGO)
references TFINALIZACIONTRATAMIENTO (TFINTRA_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtpaba_RttrataRL (TPABA_CODIGO)
on update restrict
on delete restrict;
add foreign key Rttipotra_RttrataRL (TTIPOTRA_CODIGO)
240
references TTIPOTRATAMIENTO (TTIPOTRA_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtses_RttrataRL (TSES_CODIGO)
on update restrict
on delete restrict;
add foreign key Rtfisiote_RttrataRL (TFISIOTE_CODIGO)
references TFISIOTERAPISTA (TFISIOTE_CODIGO)
on update restrict
on delete restrict;
alter table TUSUARIOPACIENTE
add foreign key Rtpaba_Rtuspa (TPABA_CODIGO)
on update restrict
on delete restrict;
alter table TUSUARIOPACIENTE
add foreign key Rtus_Rtuspa (TUS_CODIGO)
references TUSUARIOS (TUS_CODIGO)
on update restrict
241
on delete restrict;
142
3.2.4 DISEÑO ESPECÍFICO
Casos de Uso
Para
“DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE INFORMACIÓN
PARA EL CENTRO DE REHABILITACIÓN FÍSICA DE ANTONIO ANTE”
(Basado en las plantillas de Lharman para Diseño Detallado)
Versión 1.0
Preparado por:
142
Autores. “C:\Documents and Settings\Kary\Escritorio\Software Proyecto de Tesis\Base de Datos”.
242
26/01/2011
LISTA DE CASOS DE USO
Actor Principal
Caso de Uso
Usuario
Usuario
Usuario
Nuevo Paciente
Usuario
Historia Clínica del Nuevo Paciente
Usuario
Datos Paciente
Usuario
Historia Clínica
Usuario
Búsqueda
243
Usuario
Lista Tratamientos
Usuario
Reportes
CASO DE USO USUARIO
Caso de Uso CDU_Validar_Usuario
ID:
Caso de Uso Validar_Usuario
Nombre:
Creado por:
Karina Esparza
Fanny Inlago
Fecha
Creación:
de 25/01/2011
Ultimo
actualizado por:
Karina Esparza
Fanny Inlago
Fecha
ultima 25/01/2011
actualización:
Actores:
Usuario
Descripción:
Validar el Usuario mediante nombre y contraseña.
Trigger:
Precondiciones:
1. Usuario existente en la Base de Datos
244
Postcondiciones:
Flujo Normal:
Flujo Alternativo:
Excepciones:
1. Ingresar Usuario y Contraseña
2. Clic en el botón Aceptar
3. Ingresa a la página correspondiente
En caso de error debe volver a ingresar el Usuario y
Contraseña
Includes:
1. Mal ingresado Usuario o Contraseña
2. Usuario no existente en la BDD
Ninguna
Prioridad:
Alta
Frecuencia de Uso:
Cada vez que el usuario le necesite
Reglas de Negocios:
Ninguna
Requerimientos
especiales:
Conocimientos del funcionamiento del sistema
Presunciones:
Ninguna
Notas y otros aspectos:
Ninguna
Ingresar Usuario
Ingresar página
Validar Datos
Usuario
Ingresar Contraseña
245
CASO DE USO NUEVO PACIENTE
Caso de Uso CDU_Nuevo_Paciente
ID:
Caso de Uso Nuevo_Paciente
Nombre:
Creado por:
Karina Esparza
Fanny Inlago
Fecha
Creación:
de 25/01/2011
Ultimo
actualizado por:
Karina Esparza
Fanny Inlago
Fecha
ultima 25/01/2011
actualización:
Actores:
Usuario
Descripción:
Generar un nuevo formulario en la que le permitirá ingresará
los datos del paciente.
Trigger:
Precondiciones:
1. Tener un pedido
rehabilitación
de
que
el
paciente
necesita
Postcondiciones:
Flujo Normal:
Flujo Alternativo:
Excepciones:
1. Clic en Archivo y escoger Nuevo paciente
2. Se le desplegará el formulario respectivo
3. Ingresar los datos personales del paciente
4. Clic en el botón Guardar
En caso de error revisar q todos los campos estén
correctamente
Includes:
1. Paciente ya existente
2. Campos en blanco
Ninguna
Prioridad:
Alta
Frecuencia de Uso:
Reglas de Negocios:
Ninguna
Requerimientos
246
especiales:
Presunciones:
Ninguna
Ninguna
Guardar
Ingresar Form Datos Paciente
Ingresar Datos Personales
Usuario
cancelar
CASO DE USO HISTORIA CLÍNICA DEL NUEVO PACIENTE
Caso de Uso CDU_Historia_ Clínica
ID:
Caso de Uso Historia_ Clínica_Nuevo_ Paciente
Nombre:
Creado por:
Karina Esparza
Fanny Inlago
Fecha
Creación:
de 25/01/2011
Ultimo
actualizado por:
Karina Esparza
Fanny Inlago
Fecha
última 25/01/2011
actualización:
Actores:
Usuario
Descripción:
Generar un nuevo formulario en la que le permitirá ingresará
los datos en la historia clínica.
Trigger:
247
Precondiciones:
1. Tener ingresado los datos personales del nuevo paciente
Postcondiciones:
Flujo Normal:
Flujo Alternativo:
Excepciones:
1. Clic en el botón Médico enviante
2. Ingresar los datos
3. Clic en el botón Ant. Personales
5. Clic en el botón Tratamiento
En caso de error revisar que todos los campos estén
correctamente
Includes:
1. Si los datos personales del paciente no existen en la BDD
2. Campos en blanco
Ninguna
Prioridad:
Alta
Frecuencia de Uso:
Reglas de Negocios:
Ninguna
Requerimientos
especiales:
Presunciones:
Ninguna
Ninguna
Guardar
Almacenados Nuevo Paciente
Ingresar Form Historia Clínica
Ingresar Historia Clínica
Usuario
Cancelar
CASO DE USO DATOS PACIENTE
Caso de Uso CDU_Datos_ Paciente
248
ID:
Caso de Uso Datos_Paciente
Nombre:
Creado por:
Karina Esparza
Fanny Inlago
Fecha
Creación:
de 25/01/2011
Ultimo
actualizado por:
Karina Esparza
Fanny Inlago
Fecha
ultima 25/01/2011
actualización:
Actores:
Usuario
Descripción:
Generar un nuevo formulario en la que le permitirá visualizar
los datos de un paciente ya existente
Trigger:
Precondiciones:
1. Buscar al paciente
Postcondiciones:
Flujo Normal:
Flujo Alternativo:
Excepciones:
1. Buscar al paciente ya sea por Apellidos, Nombres o
Historia Clínica
2. Clic en el paciente encontrado
3. Escoger la opción Archivo y Datos Paciente
4. Modificar los campos requeridos
En caso de error realizar una nueva búsqueda o ingresar al
paciente como nuevo
Includes:
1. No buscar al paciente antes de ingresar a datos paciente
2. Campos en blanco
Ninguna
Prioridad:
Alta
Frecuencia de Uso:
Reglas de Negocios:
Ninguna
Requerimientos
especiales:
249
Presunciones:
Ninguna
Ninguna
Guardar
Buscar Paciente
Visualizar Datos Paciente
Modificar Datos Paciente
Usuario
Cancelar
CASO DE USO HISTORIA CLÍNICA
Caso de Uso CDU_Historia_Clínica
ID:
Caso de Uso Historia_Clínica
Nombre:
Creado por:
Karina Esparza
Fanny Inlago
Fecha
Creación:
de 25/01/2011
Ultimo
actualizado por:
Karina Esparza
Fanny Inlago
Fecha
última 25/01/2011
actualización:
Actores:
Usuario
Descripción:
la historia clínica de un paciente ya existente
Trigger:
Precondiciones:
1. Buscar al paciente
Postcondiciones:
Flujo Normal:
1. Buscar al paciente ya sea por Apellidos, Nombres o
Historia Clínica
250
Flujo Alternativo:
Excepciones:
2. Clic en el paciente encontrado
3. Escoger la opción Archivo e Historia Clínica
4. Modificar los campos requeridos
En caso de error realizar una nueva búsqueda o ingresar al
paciente como nuevo
Includes:
1. No buscar al paciente antes de ingresar a datos paciente
2. Campos en blanco
Ninguna
Prioridad:
Alta
Frecuencia de Uso:
Reglas de Negocios:
Ninguna
Requerimientos
especiales:
Presunciones:
Ninguna
Ninguna
Guardar
Buscar Paciente
Visualizar Historia Clínica
Modificar Historia Clínica
Usuario
Cancelar
CASO DE USO BÚSQUEDA
Caso de Uso CDU_Búsqueda
ID:
Caso de Uso Búsqueda
Nombre:
251
Creado por:
Karina Esparza
Fanny Inlago
Fecha
Creación:
de 25/01/2011
Ultimo
actualizado por:
Karina Esparza
Fanny Inlago
Fecha
última 25/01/2011
actualización:
Actores:
Usuario
Descripción:
Generar un nuevo formulario en la que le permitirá buscar
pacientes dependiendo los parámetros ingresados.
Trigger:
Precondiciones:
1. Ingresar los parámetros requeridos
Postcondiciones:
Flujo Normal:
Flujo Alternativo:
1. Escoger la opción Edición y Búsqueda
2. Ingresar los parámetros que requiera el usuario
3. Clic en el botón Buscar
En caso de error revisar que los campos estén correctamente
ingresados y realizar una nueva búsqueda
Excepciones:
1. Ingresar mal los parámetros
Includes:
Ninguna
Prioridad:
Alta
Frecuencia de Uso:
Reglas de Negocios:
Ninguna
Requerimientos
especiales:
Presunciones:
Ninguna
Ninguna
252
Buscar
Ingresar Datos
Ingresar Form Busqueda
Usuario
Cancelar
CASO DE USO LISTA INSTITUCIONES
Caso de Uso CDU_Lista_Instituciones
ID:
Caso de Uso Lista_Instituciones
Nombre:
Creado por:
Karina Esparza
Fanny Inlago
Fecha
Creación:
de 25/01/2011
Ultimo
actualizado por:
Karina Esparza
Fanny Inlago
Fecha
última 25/01/2011
actualización:
Actores:
Usuario
Descripción:
o ingresar nombres de instituciones.
Trigger:
Precondiciones:
1. Que la Institución no exista en la base de datos
Postcondiciones:
Flujo Normal:
INGRESAR
1. Escoger la opción Edición y Lista de Instituciones
2. Ingresar un nombre de una nueva institución
ELIMINAR
253
4. Escoger la opción Edición y Lista de Instituciones
5. Seleccionar el nombre de la Institución
6. Clic en el botón Eliminar
En caso de error revisar que la Institución no exista en la base
de datos
Flujo Alternativo:
Excepciones:
1. Ingresar una institución ya existente
Includes:
Ninguna
Prioridad:
Alta
Frecuencia de Uso:
Reglas de Negocios:
Ninguna
Requerimientos
especiales:
Presunciones:
Ninguna
Ninguna
Ingresar Nombre Institución
Guardar
Ingresar Form Instituciones
Usuario
Seleccionar Institución
Eliminar
CASO DE USO REPORTES
Caso de Uso CDU_Reportes
ID:
Caso de Uso Reportes
Nombre:
Creado por:
Karina Esparza
Ultimo
actualizado por:
254
Karina Esparza
Fanny Inlago
Fecha
Creación:
de 25/01/2011
Fanny Inlago
Fecha
última 25/01/2011
actualización:
Actores:
Usuario
Descripción:
Generar un nuevo formulario en la que le permitirá generar
los reportes.
Trigger:
Precondiciones:
1. Ingresar el campo requerido
Postcondiciones:
Flujo Normal:
Flujo Alternativo:
1. Escoger la opción Herramientas y Reportes
2. Ingresar los campos requeridos
3. Clic en el botón Generar
En caso de error revisar que los campos estén correctamente
ingresados
Excepciones:
2. Ingresar mal los parámetros
Includes:
Ninguna
Prioridad:
Alta
Frecuencia de Uso:
Reglas de Negocios:
Ninguna
Requerimientos
especiales:
Presunciones:
Ninguna
Ninguna
255
Generar Reportes
Ingresar Form Reportes
Ingresar Datos
Usuario
cancelar
256
2.3 DESARROLLO
2.3.1 BITÁCORAS DE DESARROLLO
BITÁCORA DE DESARROLLO DE SOFTWARE BASADO EN EXTREME PROGRAMMING
ORDINAL
AUTOR
COMPONENTE/FUNCIÓN
/PROCEDIMIENTO
validarusuario_30012011_1.php
FECHA
30/01/2011
RAZÓN DE
CAMBIO
Validar usuario
y contraseña
RUTA
NOMBRE
VERSIÓN
C:\AppServ
\www\Sist
emaCRF
Validar
Usuario
1
1
Fanny
Inlago
2
Karina
Esparza
31/01/2011
Ocultar
Contraseña
C:\AppServ
\www\Sist
emaCRF
Validar
Usuario
1.1
3
Fanny
Inlago
02/02/2011
Usuario no
existente
C:\AppServ
\www\Sist
emaCRF
Validar
Usuario
1.2
NOMBRE
VERSIÓN
ORDINAL
AUTOR
COMPONENTE/FUNCIÓN
FECHA
199
RAZÓN DE
RUTA
/PROCEDIMIENTO
nuevopaciente_02022011_1.php
02/02/2011
Fanny
Inlago
02/02/2011
3
Karina
Esparza
03/02/2011
4
Karina
Esparza
03/02/2011
1
Karina
Esparza
2
CAMBIO
Validar que no
ingrese
pacientes ya
existentes
Mostrar edad
correcta
C:\AppServ
\www\Sist
emaCRF
Nuevo
Paciente
1
Nuevo
Paciente
1.1
Actualizar la
Historia
Clínica
C:\AppServ
\www\Sist
emaCRF
C:\AppServ
\www\Sist
emaCRF
Nuevo
Paciente
1.2
Controlar los
campos en
blanco
C:\AppServ
\www\Sist
emaCRF
Nuevo
Paciente
1.3
NOMBRE
VERSIÓN
Historia
Clínica
Nuevo
Paciente
Historia
Clínica
Nuevo
Paciente
Historia
Clínica
Nuevo
Paciente
1
ORDINAL
AUTOR
1
Fanny
Inlago
COMPONENTE/FUNCIÓN
/PROCEDIMIENTO
historiaclinicanuevopaciente_040
22011_1.php
2
Karina
Esparza
22011_2.php
04/02/2011
3
Karina
Esparza
22011_3.php
04/02/2011
200
FECHA
04/02/2011
RAZÓN DE
CAMBIO
Mostrar
nombres e
historia clínica
Mostrar el
diagnóstico de
las visitas
anteriores
Cambiar las
opciones a
seleccionar
RUTA
C:\AppServ
\www\Sist
emaCRF
C:\AppServ
\www\Sist
emaCRF
C:\AppServ
\www\Sist
emaCRF
1.1
1.2
4
Fanny
Inlago
22011_4.php
04/02/2011
Controlar los
campos en
blanco
C:\AppServ
\www\Sist
emaCRF
Historia
Clínica
Nuevo
Paciente
1.3
NOMBRE
VERSIÓN
C:\AppServ
\www\Sist
emaCRF
Datos
Paciente
1
C:\AppServ
\www\Sist
emaCRF
C:\AppServ
\www\Sist
emaCRF
Datos
Paciente
1.2
Datos
Paciente
1.3
ORDINAL
AUTOR
COMPONENTE/FUNCIÓN
/PROCEDIMIENTO
datospaciente_05022011_1.php
1
Karina
Esparza
2
3
05/02/2011
Fanny
Inlago
05/02/2011
Karina
Esparza
05/02/2011
201
FECHA
RAZÓN DE
CAMBIO
Que el
formulario
datos
paciente no se
habrá antes
de buscar al
paciente
Actualizar los
datos
Cambiar el
botón
RUTA
ORDINAL
AUTOR
COMPONENTE/FUNCIÓN
/PROCEDIMIENTO
historiaclínica_07022011_1.php
FECHA
07/02/2011
1
Fanny
Inlago
2
Karina
Esparza
07/02/2011
3
Karina
Esparza
07/02/2011
202
RAZÓN DE
CAMBIO
Cambiar los
iconos
Que el
formulario
historia clínica
no se habrá
antes de
buscar al
paciente
Mostrar el
cuadro de
búsqueda
RUTA
NOMBRE
VERSIÓN
C:\AppServ
\www\Sist
emaCRF
C:\AppServ
\www\Sist
emaCRF
Historia
Clínica
1
Historia
Clínica
1.2
C:\AppServ
\www\Sist
emaCRF
Historia
Clínica
1.3
ORDINAL
AUTOR
COMPONENTE/FUNCIÓN
/PROCEDIMIENTO
búsqueda_07022011_1.php
FECHA
07/02/2011
RAZÓN DE
CAMBIO
Cambiar los
iconos
RUTA
NOMBRE
VERSIÓN
Búsqueda
1
Búsqueda
1.2
Búsqueda
1.3
1
Fanny
Inlago
2
Karina
Esparza
07/02/2011
Quitar
parámetros
no utilizados
C:\AppServ
\www\Sist
emaCRF
C:\AppServ
\www\Sist
emaCRF
3
Fanny
Inlago
07/02/2011
Ocultar el
cuadro de
buscar
C:\AppServ
\www\Sist
emaCRF
203
ORDINAL
AUTOR
COMPONENTE/FUNCIÓN
/PROCEDIMIENTO
listainstituciones_08022011_1.php
FECHA
08/02/2011
1
Fanny
Inlago
2
Karina
Esparza
08/02/2011
3
Karina
Esparza
08/02/2011
RAZÓN DE
CAMBIO
Validar el
ingreso del
nombre de
una
instituciones
Eliminar el
nombre de
una
institución
Actualizar
los campos
RUTA
NOMBRE
VERSIÓN
C:\AppServ
\www\Sist
emaCRF
Lista
institucio
nes
1
C:\AppServ
\www\Sist
emaCRF
Lista
institucio
nes
1.2
C:\AppServ
\www\Sist
emaCRF
Lista
institucio
nes
1.3
204
ORDINAL
AUTOR
COMPONENTE/FUNCIÓN
/PROCEDIMIENTO
reportes_10022011_1.php
FECHA
10/02/2011
1
Fanny
Inlago
2
Fanny
Inlago
10/02/2011
3
Karina
Esparza
10/02/2011
RAZÓN DE
CAMBIO
Corrección
de acuerdo
con la
necesidad
del usuario
Corrección
de
parámetros
Corrección
de diseño
CAPÍTULO
CAPÍTULO III
III
REFERENCIA OPERATIVA
205
RUTA
NOMBRE
VERSIÓN
C:\AppServ
\www\Sist
emaCRF
Reportes
1
C:\AppServ
\www\Sist
emaCRF
Reportes
1.2
C:\AppServ
\www\Sist
emaCRF
Reportes
1.3
El Software presenta una interfaz de usuario muy sencilla de operar, ya que el
funcionamiento de cada interfaz se explicara con la Descripción correspondiente.
6.1 INICIO
Figura 3.1: Inicio
Fuente: Autores
-
Descripción: Es la pantalla principal que aparece al ingresar al Sitio Web del
Centro de Rehabilitación Física.
6.2 OBJETIVOS
206
Figura 3.2: Objetivos
Fuente: Autores
-
Descripción: Es la pantalla que nos muestra los objetivos del Centro de
207
6.3 INTEGRACIÓN SOCIAL
Figura 3.3: Integración Social
208
Fuente: Autores
-
Descripción: Es la pantalla que nos muestra un artículo de la Integración Social
del Centro de Rehabilitación Física.
6.4 SISTEMA DE GESTIÓN DE INFORMACIÓN DEL CENTRO DE REHABILITACIÓN FÍSICA
6.4.1 VALIDACIÓN DE USUARIO
Figura 3.4.: Validar Usuario
Fuente: Autores
-
Descripción: Es la pantalla principal del Sistema de Gestión de Información del
Centro de Rehabilitación Física, en la cual nos permite ingresar Usuario y
Contraseña para conectarse al sistema, ya sea como:
• Administrador
• Rehabilitación Física
• Rehabilitación de Lenguaje
Cada vez que el Usuario lo requiera.
6.4.2 ADMINISTRADOR
209
Figura 3.5: Administrador
Fuente: Autores
-
Descripción: Es la pantalla principal del Administrador donde se puede escoger
las siguientes opciones:
• Rehabilitación Física.
• Rehabilitación de Lenguaje.
En caso de querer cerrar la sesión, hacer clic en la X.
6.4.3 REHABILITACIÓN FÍSICA
Figura 3.6: Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla principal de Rehabilitación Física, en la cual tenemos
el siguiente menú desplegable:
• Archivo: Nuevo Paciente, Datos Pacientes, Historia Clínica y Salir.
• Edición: Búsqueda y Lista de Instituciones.
210
• Herramientas: Reportes.
• Ayuda: Manual de Usuario.
Además, nos muestra una opción que permite Buscar Pacientes existentes, ya
sea por Apellidos, Nombres o Historia Clínica.
6.4.4 NUEVO PACIENTE REHABILITACIÓN FÍSICA
Figura 3.7: Nuevo Paciente Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla de Nuevo Paciente, la cual nos permite ingresar a un
paciente por primera vez, llenando los Datos Personales, tomando en cuenta
que todos los campos deben estar llenos, si ya existe el paciente se mostrará un
mensaje.
6.4.5 MENSAJE REHABILITACIÓN FÍSICA
211
Figura 3.8: Mensaje Rehabilitación Física
Fuente: Autores
-
Descripción: En este mensaje nos indica que los datos se han guardado
correctamente, permitiendo el enlace a la Historia Clínica del Nuevo Paciente.
6.4.6 HISTORIA CLÍNICA REHABILITACIÓN FÍSICA
Figura 3.9: Historia Clínica Rehabilitación Física
Fuente: Autores
212
-
Descripción: Es la pantalla principal de la Historia Clínica, donde se muestra las
siguientes opciones:
• Médico Enviante: Ingresar el Diagnóstico que envía el Médico.
• Ant. Personales: Ingresar los Antecedentes Personales del paciente.
• Tratamiento: Ingresar el Tratamiento del paciente por la Fisioterapista.
6.4.6.1 MÉDICO ENVIANTE REHABILITACIÓN FÍSICA
Figura 3.10: Médico Enviante Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla de Médico Enviante, la cual nos permite ingresar los
siguientes campos:
• Revisar si el Nombre del Médico Enviante existe en el listado, en
caso de no existir hacer clic en el botón Nuevo donde aparecerá
unos cuadros de texto que debe ingresar los Datos del Médico
Enviante y hacer clic en el botón Guardar.
• Buscar al paciente por la Historia Clínica, donde permite visualizar
los Nombres, Apellidos y la Historia Clínica del paciente.
• Seleccionar el nombre del Médico Enviante.
• Ingresar los datos como son:
Institución que Solicita: IESS, Pública, Privada.
Grupo de Edad: Seleccionar al grupo que corresponde.
Diagnostico Médico Enviante: Ingresar el diagnóstico de la visita
actual y hacer clic en el botón Guardar.
213
6.4.6.2 ANTECEDENTES PERSONALES REHABILITACIÓN FÍSICA
Figura 3.11: Antecedentes Personales Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla de Antecedentes Personales, en la cual nos permite
ingresar los siguientes campos:
• Buscar al paciente por la Historia Clínica, donde permite visualizar los
Nombres, Apellidos y la Historia Clínica del paciente.
• Seleccionar el Antecedente Personal e ingresar las Observaciones si la
Fisioterapista lo cree necesario y hacer clic en el botón Guardar.
6.4.6.3 TRATAMIENTO REHABILITACIÓN FÍSICA
214
Figura 3.12: Tratamiento Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla de Tratamiento, la cual nos permite ingresar los
siguientes campos:
• Revisar si el Nombre de la Fisioterapista existe en el listado, en caso
de no existir hacer clic en el botón Nuevo donde aparecerá unos
cuadros de texto que debe ingresar los Datos del Fisioterapista y
hacer clic en el botón Guardar.
• Seleccionar el nombre del Fisioterapista.
Tipo Tratamiento: Seleccionar el tratamiento a seguir.
Diagnostico Fisioterapista: Ingresar el diagnóstico de la visita
actual.
Finalización Tratamiento: Seleccionar si Continua, Abandona o
Termina y hacer clic en el botón Guardar.
215
6.4.7 DATOS PACIENTE REHABILITACIÓN FÍSICA
Figura 3.13: Datos Paciente Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla de Datos Paciente, la cual nos permite visualizar los
datos de pacientes ya existentes:
• Buscar al paciente ya sea por Apellidos, Nombres o por la Historia
Clínica y hacer clic en el botón Buscar.
• Nos muestra todos los campos llenos con la información del
Paciente.
• En caso de modificar la información solo se puede realizar los
cambios a los siguientes campos:
Edad: se actualizara dependiendo de la fecha actual.
Estado Civil, Ocupación, Domicilio, Teléfono, Celular y hacer clic
en el botón Guardar.
6.4.8 MENSAJE REHABILITACIÓN FÍSICA
216
Figura 3.14: Mensaje Rehabilitación Física
Fuente: Autores
-
Descripción: En este mensaje nos indica que los datos modificados en Datos
Paciente se han guardado correctamente.
6.4.9 HISTORIA CLÍNICA REHABILITACIÓN FÍSICA
Figura 3.15: Historia Clínica Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla principal de la Historia Clínica donde se siguen los
siguientes pasos:
Clínica y hacer clic en el botón Buscar, para confirmar que el paciente
existe.
• Ingresar los nuevos diagnósticos en las diferentes opciones:
Médico Enviante: En caso de tener nuevo diagnóstico del
médico.
Ant. Personales: En caso de tener nuevo Antecedente Personal
del paciente.
Tratamiento: Ingresar el Tratamiento del paciente a seguir por la
Fisioterapista.
217
6.4.10 BÚSQUEDA REHABILITACIÓN FÍSICA
Figura 3.16: Búsqueda Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla de Búsqueda, la que nos permite buscar a los
pacientes por los siguientes campos:
• Nombres, Apellidos, Número de Cédula, Fecha de Nacimiento, Sexo,
Nacionalidad, Historia Clínica, Ocupación, Estado Civil, Domicilio,
Celular, Teléfono, Fecha de Consulta, Edad, Nombre del Médico que le
Refiere y hacer clic en Buscar.
• Donde se desplegara una pantalla con las Datos del Paciente o de los
Pacientes a buscar.
218
•
En caso de necesitar un respaldo físico tiene la opción de imprimir o a
su vez exportar los datos a Excel o a Word.
6.4.11 LISTA DE INSTITUCIONES REHABILITACIÓN FÍSICA
Figura 3.17: Lista Instituciones Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla de Lista de Instituciones, la cual nos permite ingresar
y visualizar las instituciones.
• Para Ingresar el nombre de una nueva Institución escribir en el
cuadro de texto y hacer clic en el botón Guardar.
219
•
Para eliminar una Institución seleccionar el nombre de la Institución
en Lista Instituciones y hacer clic en Eliminar.
6.4.12 REPORTES REHABILITACIÓN FÍSICA
Figura 3.18: Reportes Rehabilitación Física
Fuente: Autores
-
Descripción: Es la pantalla de Reportes, la que nos permite buscar a los
• Nombres, Apellidos, Sexo, Edad, Grupo de Edad, Diagnóstico, Tipo
Tratamiento, Institución que Solicita o por la Fecha de cada Sesión y
hacer clic en Buscar.
• Donde se desplegara una pantalla con la información requerida,
permitiéndole imprimir o a su vez exportar los datos a Excel o a Word.
6.4.13 REHABILITACIÓN DE LENGUAJE
220
Figura 3.19: Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: Es la pantalla principal de Rehabilitación de Lenguaje, en la cual
tenemos el siguiente menú desplegable:
• Archivo: Nuevo Paciente, Datos Pacientes, Historia Clínica y Salir.
• Edición: Búsqueda y Lista de Instituciones.
• Herramientas: Reportes.
• Ayuda: Manual de Usuario.
Además, nos muestra una opción que permite Buscar Pacientes existentes, ya
sea por Apellidos, Nombres o Historia Clínica.
6.4.14 NUEVO PACIENTE REHABILITACIÓN DE LENGUAJE
221
Figura 3.20: Nuevo Paciente Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: Es la pantalla de Nuevo Paciente, la cual nos permite ingresar a un
paciente por primera vez, llenando los Datos Personales, tomando en cuenta
que todos los campos deben estar llenos, si ya existe el paciente se mostrará un
mensaje.
6.4.15 MENSAJE REHABILITACIÓN DE LENGUAJE
Figura 3.21: Mensaje Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: En este mensaje nos indica que los datos se han guardado
correctamente, permitiendo el enlace a la Historia Clínica del Nuevo Paciente.
222
6.4.16 HISTORIA CLÍNICA REHABILITACIÓN DE LENGUAJE
Figura 3.22: Historia Clínica Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: Es la pantalla principal de la Historia Clínica, donde se muestra las
siguientes opciones:
• Médico Enviante: Ingresar el Diagnóstico que envía el Médico.
• Ant. Personales: Ingresar los Antecedentes Personales del paciente.
• Tratamiento: Ingresar el Tratamiento del paciente por la Fisioterapista.
6.4.16.1
MÉDICO ENVIANTE REHABILITACIÓN DE LENGUAJE
223
Figura 3.23: Médico Enviante Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: Es la pantalla de Médico Enviante, la cual nos permite ingresar los
siguientes campos:
• Revisar si el Nombre del Médico Enviante existe en el listado, en
caso de no existir hacer clic en el botón Nuevo donde aparecerá
unos cuadros de texto que debe ingresar los Datos del Médico
Enviante y hacer clic en el botón Guardar.
• Seleccionar el nombre del Médico Enviante.
Institución que Solicita: IESS, Pública, Privada.
Grupo de Edad: Seleccionar al grupo que corresponde.
Diagnostico Médico Enviante: Seleccionar el Tipo de diagnóstico
de la visita actual e ingresar alguna observación en caso de existir
y hacer clic en el botón Guardar.
6.4.16.2
ANTECEDENTES PERSONALES REHABILITACIÓN DE LENGUAJE
224
Figura 3.24: Antecedentes Personales Rehabilitación de Lenguaje
Fuente: Autores
Descripción: Es la pantalla de Antecedentes Personales, en la cual nos permite
ingresar los siguientes campos:
• Buscar al paciente por la Historia Clínica, donde permite visualizar los
Nombres, Apellidos y la Historia Clínica del paciente.
• Seleccionar el Antecedente Personal e ingresar las Observaciones si la
Fisioterapista lo cree necesario y hacer clic en el botón Guardar. En
caso de querer cerrar la sesión, hacer clic en la X.
6.4.16.3
TRATAMIENTO REHABILITACIÓN DE LENGUAJE
-
225
Figura 3.25: Tratamiento Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: Es la pantalla de Tratamiento, la cual nos permite ingresar los
siguientes campos:
• Revisar si el Nombre de la Fisioterapista existe en el listado, en caso
de no existir hacer clic en el botón Nuevo donde aparecerá unos
cuadros de texto que debe ingresar los Datos del Fisioterapista y
• Seleccionar el nombre del Fisioterapista.
Diagnóstico Logopédico: Seleccionar el Diagnóstico e ingresar las
Observaciones si la Fisioterapista si lo cree necesario y hacer clic
Diagnostico Fisioterapista: Seleccionar el Tipo de Tratamiento e
ingresar las Observaciones si la Fisioterapista lo cree necesario y
Finalización Tratamiento: Seleccionar si Continua, Abandona o
Termina y hacer clic en el botón Guardar.
226
6.4.17 DATOS PACIENTE REHABILITACIÓN DE LENGUAJE
Figura 3.26: Datos Paciente Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: Es la pantalla de Datos Paciente, la cual nos permite visualizar los
datos de pacientes ya existentes:
Clínica y hacer clic en el botón Buscar.
• Nos muestra todos los campos llenos con la información del
Paciente.
• En caso de modificar la información solo se puede realizar los
cambios a los siguientes campos:
Edad: se actualizara dependiendo de la fecha actual.
Estado Civil, Ocupación, Domicilio, Teléfono, Celular y hacer clic
227
6.4.18 MENSAJE REHABILITACIÓN DE LENGUAJE
Figura 3.27: Mensaje Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: En este mensaje nos indica que los datos modificados en Datos
Paciente se han guardado correctamente.
6.4.19 HISTORIA CLÍNICA REHABILITACIÓN DE LENGUAJE
Figura 3.28: Historia Clínica Rehabilitación de Lenguaje
Fuente: Autores
228
-
Descripción: Es la pantalla principal de la Historia Clínica donde se siguen los
siguientes pasos:
Clínica y hacer clic en el botón Buscar, para confirmar que el paciente
existe.
• Ingresar los nuevos diagnósticos en las diferentes opciones:
Médico Enviante: En caso de tener nuevo diagnóstico del
médico.
Ant. Personales: En caso de tener nuevo Antecedente Personal
del paciente.
Tratamiento: Ingresar el Tratamiento del paciente a seguir por la
Fisioterapista.
6.4.20 BÚSQUEDA REHABILITACIÓN DE LENGUAJE
Figura 3.29: Búsqueda Rehabilitación de Lenguaje
Fuente: Autores
229
Descripción: Es la pantalla de Búsqueda, la que nos permite buscar a los
• Escolaridad, Grado, Domicilio, Teléfono, Celular, Fecha de Consulta,
Edad, Nombre Informante, Relación Paciente, Historia Clínica, Nombres,
Apellidos, Número de Cédula, Fecha de Nacimiento, Sexo, Nacionalidad,
Nombre del Médico que le Refiere y hacer clic en Buscar.
• Donde se desplegara una pantalla con las Datos del Paciente o de los
Pacientes a buscar.
• En caso de necesitar un respaldo físico tiene la opción de imprimir o a
su vez exportar los datos a Excel o a Word.
6.4.21 LISTA DE INSTITUCIONES REHABILITACIÓN DE LENGUAJE
-
Figura 3.30: Lista Instituciones Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: Es la pantalla de Lista de Instituciones, la cual nos permite ingresar
y visualizar las instituciones.
• Para Ingresar el nombre de una nueva Institución escribir en el
cuadro de texto y hacer clic en el botón Guardar.
• Para eliminar una Institución seleccionar el nombre de la Institución
en Lista Instituciones y hacer clic en Eliminar.
6.4.22 REPORTES REHABILITACIÓN DE LENGUAJE
230
Figura 3.31: Reportes Rehabilitación de Lenguaje
Fuente: Autores
-
Descripción: Es la pantalla de Reportes, la que nos permite buscar a los
• Nombres, Apellidos, Sexo, Edad, Grupo de Edad, Diagnóstico, Tipo
Tratamiento, Institución que Solicita o por la Fecha de cada Sesión y
hacer clic en Buscar.
• Donde se desplegara una pantalla con la información requerida,
permitiéndole imprimir o a su vez exportar los datos a Excel o a Word.
CAPÍTULO IV
231
ANÁLISIS PROSPECTIVO DE IMPACTOS
10.1
INTRODUCCIÓN
Para la finalización del presente proyecto se realizará un análisis de los impactos que
generaran en las diferentes áreas.
Para dicho análisis, se seguirá el siguiente procedimiento que a continuación se
detalla:
-
Seleccionamos los niveles de impacto numéricamente de acuerdo con la
siguiente tabla:
NIVEL IMPACTO
INTERPRETACIÓN
-3
-2
-1
0
1
2
3
Impacto Alto Negativo
Impacto Medio Negativo
Impacto Bajo Negativo
No hay Impacto
Impacto Bajo Positivo
Impacto Medio Positivo
Impacto Alto Positivo
Tabla 4.1: Niveles de Impacto
Fuente: Metodología para el Trabajo de Grado
-
Para cada área o aspecto, determinamos o seleccionamos indicadores de
impacto en la respectiva matriz.
-
A cada indicador asignamos un valor numérico de nivel de impacto en la
respectiva matriz.
-
Realizaremos una sumatoria de los niveles de impacto en cada matriz y
dividimos este valor para el número de indicadores, obteniéndose de este
modo el impacto promedio de área o ámbito.
232
-
-
10.2
Hay que señalar que bajo cada matriz se deberá incluir el análisis y argumento
de las razones y las circunstancias por la que asignó el valor correspondiente a
cada indicador.
Y finalmente se ha estructurado una matriz global de impactos en donde se
sustituyen los indicadores por las áreas de influencia de impactos, y con el
procedimiento mencionado anteriormente se determina el nivel de impacto
global del proyecto147.
ANÁLISIS DE IMPACTOS Y POSIBLES INDICADORES
10.2.1 IMPACTO SOCIAL
El Sistema de Gestión de Información permitirá reducir el tiempo de espera a los
pacientes para ser atendidos en la especialidad requerida.
10.2.2 IMPACTO ÉTICO
El Sistema Informático ayudará a todo el personal que labora en dicha institución,
brindar un servicio transparente y veraz a toda la comunidad Anteña y al norte del
país.
10.2.3 IMPACTO TECNOLÓGICO
Permitir el estudio de cómo funciona el programa y adaptarlo a nuevas necesidades. El
acceso al código fuente es una condición necesaria para garantizar esta libertad.
10.3
EVALUACIÓN DE IMPACTOS
10.3.1 IMPACTO SOCIAL
Nivel de Impacto
-3
-2
-1
0
1
2
3
Indicador
X
Imagen Institucional
X
Ahorro de Tiempo
147
POSSO YÉPEZ, Miguel Ángel. “Metodología para el Trabajo de Grado”
233
X
Eficacia
TOTAL
2
6
Tabla 4.2: Resultados Impacto Social.
Fuente: Autores
Sumatoria
= 8
Nivel de Impacto Social
=
8
3
= 2.666
= 3
El proyecto posee un Impacto Social Alto Positivo
ANÁLISIS
-
Imagen Institucional
Con el presente proyecto la imagen de la institución mejorará notablemente, hacia la
comunidad anteña y el norte del país, debido a la implementación del sistema
informático.
-
Ahorro de Tiempo
Con la implementación del sistema informático en el Centro de Rehabilitación Física
los tiempos en los procesos de ingreso, búsqueda y almacenamiento disminuirá
notablemente, generando así seguridad agilidad, lo que permitirá el empleo de tiempo
en otras actividades.
-
Eficacia
234
La tecnología permite la ubicación exacta de la historia clínica del paciente, ya que en
el sistema manual anteriormente utilizado tenía falencias y el control era deficiente.
10.3.2 IMPACTO ÉTICO
Nivel de Impacto
-3
-2
-1
0
1
2
3
Indicador
Seguridad de información
X
Servicio de calidad
X
X
Rendimiento laboral del personal
TOTAL
2
6
Tabla 4.3.: Resultados Impacto Ético.
Fuente: Autores
Sumatoria
= 8
=
8
3
= 2.666
= 3
El proyecto posee un Impacto Ético Alto Positivo
ANÁLISIS
-
Seguridad de Información
Con el presente proyecto las historias clínicas de cada uno de los pacientes y la
información en general contará con mayor resguardo y un buen almacenamiento.
235
-
Servicio de Calidad
Con la implementación del sistema informático el personal que elabora en el Centro
brindará un mejor servicio en la atención a los pacientes y a su vez mejorará la
presentación de los reportes.
-
Rendimiento Laboral del Personal
El sistema permitirá que el personal tenga un mejor rendimiento laboral ya que el
proceso de búsqueda, creación de pacientes y elaboración de reportes no les
ocasionará pérdida de tiempo y así contarán con un ahorro en materiales de oficina.
10.3.3 IMPACTO TECNOLÓGICO
Nivel de Impacto
-3
-2
-1
0
1
2
3
Indicador
Análisis del sistema
X
Permite mejoras
X
Acceso al código fuente
X
TOTAL
9
Tabla 4.4: Resultados Impacto Tecnológico.
Fuente: Autores
Sumatoria
= 9
=
9
3
= 3
El proyecto posee un Impacto Tecnológico Alto Positivo
236
ANÁLISIS
-
Análisis del Sistema
El presente proyecto permite el estudio y análisis del funcionamiento del sistema.
-
Permite Mejoras
El sistema informático está abierto a cualquier mejora que el Centro de Rehabilitación
Física necesite.
-
Acceso al Código Fuente
El código fuente estará disponible para el personal que crea conveniente el Centro de
10.4
IMPACTO GLOBAL DEL PROYECTO
Nivel de Impacto
-3
-2
-1
0
1
2
3
Indicador
SOCIAL
X
ÉTICO
X
TECNOLÓGICO
X
TOTAL
9
Tabla 4.5: Resultados Impacto Global.
Fuente: Autores
Sumatoria
= 9
=
9
3
= 3
El proyecto posee un Impacto Global Alto Positivo
237
CONCLUSIONES
-
Con la sistematización el tiempo para el proceso de administración de la
información disminuirá considerablemente en relación con el proceso manual
que se viene realizando en el ingreso de cada uno de los pacientes, por lo
tanto, disminuirá el tiempo y margen de error con el uso de un proceso de
control adecuado y de fácil mantenimiento.
-
Con la sistematización de la información implementada en el Centro de
Rehabilitación Física de Antonio Ante mejorará la imagen de la institución.
-
En la actualidad es de vital importancia que el Centro de Rehabilitación Física
de Antonio Ante cuente con una herramienta informática que mejore
considerablemente el rendimiento en la gestión de información de los
pacientes.
-
La herramienta informática que se presenta al personal que elabora en el
Centro de Rehabilitación Física ayudará a mejorar su desempeño laboral, en
términos de tiempo, organización y seguridad.
-
Con la implementación del software el Centro de Rehabilitación Física mejorará
el servicio de atención a los pacientes y al personal administrativo.
-
El software permitirá reducir costos en suministros de oficina y licencias
informáticas.
238
RECOMENDACIONES
-
Será indispensable que el Centro de Rehabilitación Física de Antonio Ante en
menor tiempo posible implante el software elaborado en este proyecto y
sustituya definitivamente el actual proceso manual de manejo de información.
-
Este proyecto deja un camino abierto para la posibilidad de la implementación
general de otros procesos operativos y administrativos en el Centro de
Rehabilitación Física de Antonio Ante.
-
Este proyecto es susceptible de ser perfeccionado, mejorado, en función del
desarrollo tecnológico del transcurso del tiempo y la complejidad de las
actividades que se desarrolla en el Centro de Rehabilitación Física de Antonio
Ante en razón de que el sistema es dinámico.
-
Es necesario fomentar relaciones académicas de las universidades con el sector
público-privado con la finalidad de estrechar vínculos de cooperación que
generen sinergias hacia las instituciones.
-
Será indispensable fomentar a las instituciones públicas y privadas utilizar
software libre.
-
En las Universidades para el desarrollo de software promover la utilización de
lenguajes de programación libre.
239
FUENTES DE INFORMACIÓN
-
LIBROS
JIMENEZ, Gustavo
2008, Monografía Contemporánea del Cantón Antonio Ante, Primera
Edición, Antonio Ante, Ecuador.
POSSO, Miguel
2006, Metodología para el Trabajo de Grado (Tesis y Proyecto), Tercera
Edición, Ibarra, Ecuador.
-
PAGINAS WEB
RUEDA, Pilar
240
Reseña Histórica, “Centro de Rehabilitación Física de Antonio Ante”,
FREIDE, Washington
La Medicina Y La Rehabilitación,
http://www.semefir.com.ec/cont_esp/p_nosotros/docs/Historia_Fisiatria.pdf
ANÓNIMO
Rehabilitación, http://www.angelfire.com/md2/rehabilitacion/
WIKIPEDIA
Organización Mundial de la Salud,
http://es.wikipedia.org/wiki/Organizaci%C3%B3n_Mundial_de_la_Salud
OPS
Organización Panamericana de Salud,
http://new.paho.org/ecu/index.php?option=com_content&task=view&id=24&I
temid=122
Representación De La Ops / Oms En El Ecuador,
http://new.paho.org/ecu/index.php?option=com_content&task=view&id=24&I
temid=122
SEMEFIR
Ministerio de Salud Pública,
http://www.semefir.com.ec/cont_esp/p_index_esp.php
241
ANÓNIMO
Sociedad Ecuatoriana de Medicina Física y Rehabilitación,
http://www.msp.gov.ec/index.php?option=com_content&task=blogcategory&i
d=17&Itemid=94
CONASA
Consejo Nacional de Salud,
http://www.conasa.gov.ec/codigo/quienes/quienes.html
CONADES
Conferencia Nacional Sobre Desarrollo Social
http://www.conades.org.pe/index.php?pg=2
ANÓNIMO
Sistema Nacional de Salud,
http://www.paho.org/spanish/DPM/SHD/HP/ha-nha-satelit2-pres9-naranjo.pdf
MORAN, Angelita
Formularios de Rehabilitación Física en el Ecuador,
“Directora de la Casa de Salud Hospitalaria de Antonio Ante”.
RUEDA, Pilar
Formulario de Terapia Física de Antonio Ante, “Centro de Rehabilitación Física
de Antonio Ante”.
Formulario de Reporte de Terapia Física, “Centro de Rehabilitación Física de
Antonio Ante”.
GOVEO, Mirian
242
Formulario de Terapia de Lenguaje, “Centro de Rehabilitación Física de
Antonio Ante”.
Formulario de Reporte deTerapia de Lenguaje, “Centro de Rehabilitación Física
de Antonio Ante”.
ANDRADE, Janeth
Estructura del Centro de Rehabilitación Física, “Centro de Rehabilitación Física
de Antonio Ante”.
ANÓNIMO
Base de Datos,
http://www.maestrosdelweb.com/principiantes/¿que-son-las-bases-de-datos/
MONOGRAFÍAS
Sistema Manejador de Base de Datos,
http://www.monografias.com/trabajos7/bada/bada.shtml
MONOGRAFÍAS
Base de Datos Relacionales, http://elies.rediris.es/elies9/4-1-2.htm
WIKIPEDIA
Diseño de Bases de Datos Relacionales,
http://es.wikipedia.org/wiki/Base_de_datos_relacional
http://usuarios.multimania.es/cursosgbd/UD4.htm
243
WIKIPEDIA
Tipos de Restricciones de Integridad en Base de Datos,
http://es.wikipedia.org/wiki/Integridad_de_datos
WIKIPEDIA
Normalización,
http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_una_base_de_datos
http://www.wikilearning.com/tutorial/diseno_de_base_de_datos_en_sqlnormalizacion/21129-4
ANÓNIMO
Claves, http://www.uazuay.edu.ec/analisis/El%20modelo%20relacional.pdf
ANÓNIMO
Grados de Normalización,
http://www.uazuay.edu.ec/analisis/El%20modelo%20relacional.pdf
WIKILEARNING
Diseño Físico,
http://www.wikilearning.com/tutorial/diseno_de_bases_de_datos_en_sqlcaracteristicas_de_una_dbms_dbms/21129-2
WIKIPEDIA
Características de una DBMS,
244
http://www.wikilearning.com/curso_gratis/sistemas_de_bases_de_datosprogramas_que_conforman_el_dbms/3621-5
MONOGRAFÍAS
Comandos SQL, http://www.monografias.com/trabajos11/manu/manu.shtml
http://es.wikipedia.org
WIKIPEDIA
My SQL, http://es.wikipedia.org/wiki/MySQL
http://www-css.fnal.gov/dsg/external/freeware/mysqlInfo.html
WIKIPEDIA
PHP, http://es.wikipedia.org/wiki/PHP
ANÓNIMO
PHP Runner, http://php-runner.uptodown.com/
WIKIPEDIA
Macromedia Dreamweaver,http://es.wikipedia.org/wiki/Adobe_Dreamweaver
WIKIPEDIA
JavaScript, http://es.wikipedia.org/wiki/JavaScript
ANÓNIMO
Diagrama de Casos de Usos,
http://www.ingenierosoftware.com/analisisydiseno/uml.php
http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso
245
ANÓNIMO
Elementos de un Diagrama de Casos de Uso,
http://www.osmosislatina.com/lenguajes/uml/casos.htm
WIKIPEDIA
Sistema Informático, http://es.wikipedia.org/wiki/Sistema_informático
ANÓNIMO
Arquitectura Cliente / Servidor en dos Capas,
http://www.galeon.com/zuloaga/Doc/ArqCapasSI.doc
http://www.estudiagratis.com
ANÓNIMO
Ciclo de Vida en V, http://www.ciclo_de_vida_en_v.com
http://oness.sourceforge.net/proyecto/html/ch05.html
ANÓNIMO
Metodología XP,
http://dis.um.es/~lopezquesada/documentos/FIS_0607/recursos/AnexoIIITema
2.pdf
ANÓNIMO
Especificación de Requisitos de Software – IEEE 830,
http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
246
ANÓNIMO
Requisitos del Sistema – IEEE 1362
http://www.google.com/search?q=Concepto+b%C3%A1sico+de+IEEE+1362&hl
=es&source=hp&lr=lang_es&aq=f&aqi=&aql=&oq
ANÓNIMO
Diseño Arquitectónico, http://www.scribd.com/doc/7994185/24DiseNo-de-LaArquitectura-Del-Software
ANÓNIMO
Diseño E / R, http://bd.eui.upm.es/BD/docbd/tema/tema2.pdf
WIKIPEDIA
Bitácoras de Codificación, http://es.wikipedia.org/wiki/Software
WIKIPEDIA
Pruebas, http://es.wikipedia.org/wiki/Prueba_unitaria
http://es.wikipedia.org/wiki/Pruebas_de_software
WIKIPEDIA
Validación y Aceptación,
http://es.wikipedia.org/wiki/Caja_blanca_%28sistemas%29
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol227/paper07.pdf
ANÓNIMO
Convenciones, http://www.di-mare.com/adolfo/p/convpas.htm
247
ANÓNIMO
Diseño de Datos, La clave primaria de una relación es aquella clave candidata
que se escoge para identificar sus tuplas de modo único. Archivo de
procesamiento por lotes.
GLOSARIO
-
OMS: Organización Mundial de la Salud.
248
-
ONU: Organización de las Naciones Unidas.
-
OPS: Organización Panamericana de la Salud.
-
CONASA: Consejo Nacional de Salud.
-
CONADES: Conferencia Nacional de Salud.
-
EMRO: Oficina Regional para el Mediterráneo Oriental.
-
WPRO: Oficina Regional para el Pacífico Occidental.
-
LOSNS: Ley Orgánica del Sistema Nacional de Salud.
-
SENRES: Secretaria Nacional Técnica de Recursos Humanos y Remuneraciones
del Sector Público.
-
SNS: Sistema Nacional de Salud.
-
MSP: Ministerio de Salud Pública.
-
ARD: Análisis Relacional de Datos.
-
DML: Administrador de Lenguaje de Datos.
-
PHP: Lenguaje de Programación Interpretado.
-
ISO: Organización Internacional de Normalización.
-
IEEE 1362: Estándar que determina la especificación de requisitos de sistema
para la construcción y puesta en marcha de aplicaciones de software.
-
IEEE 830: Especificación de requisitos de software.
-
CDU: Caso de Uso.
-
SGICRF: Sistema de Gestión de Información del Centro de Rehabilitación Física.
-
TCP/IP: Transport Control Protocol Internet.
249
-
DBMS: Sistema de Manejo de la Base de Datos.
250
251
ANEXOS
252
ANEXO 1
253
-
FOTOGRAFÍAS DEL CENTRO DE REHABILITACIÓN FÍSICA
254
255
256
257
258
ANEXO 2
259
-
FICHAS DEL CENTRO DE REHABILITACIÓN FÍSICA
•
Ficha de Historia Clínica de Terapia Física
1. DATOS PERSONALES
APELLIDOS
NOMBRES
DIRECCION
OCUPACION
EDAD
TELEFONO
CEDULA
HISTORIA CLINICA
FECHA CONSULTA
MEDICO QUE REFIERE
2. DIAGNOSTICO
H.T.A
INSTITUCION
DIABETES
CARDIOPATÍA
IESS
PUBLICA
PRIVADA
4. TRATAMIENTO
Electroestimulación
Ultrasonido
C.Q.C
C.F
Terapia Respiratoria
Ejercicio Terapéutico
Masaje
Láser
Magnetoterapia
5. OBSERVACIONES
6. EVOLUCIONES
Nº Sesiones
Fisioterapia
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 Termina Abandona
260
261
•
Ficha de Reporte de Terapia Física
262
SISTEMA COMÚN DE INFORMACIÓN EN SALUD - REGISTRO DIARIO DE ATENCIONES
DATOS ESTABLECIMIENTO
Nº 2
ATUNTAQUI
ANTONIO ANTE
IMBABURA
MES REGISTRADO
ESPECIALIDAD
DÍA
AÑO
PROFESIONAL FIRMA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
263
IESS
PRIVADO
PUBLICO
MASAJE
ATENCION
EJECICIO TERAPEUTICO
COMPRESA FRIAS
COMPRESAS CALIENTES
LASER
ULTRASONIDO
DIAGNOSTICO O SÍNDRONE
ELECTROESTIMULACION
65 AÑOS Y MAS
50-64 AÑOS
TRATAMIENTO
36-49 AÑOS
20-35 AÑOS
15-19 AÑOS
10-14 AÑOS
1 -4 AÑOS
1 - 11 MESES
GRUPO DE EDAD
MENOR DE UN MES
MUJER
NOMBRE Y APELLIDO
HOMBRE
SEXO
Nº
5 - 9 AÑOS
NOMBRE UNIDAD
AREA DE SALUD
PARROQUIA
CANTÓN
PROVINCIA
DATOS PERSONAL
•
Ficha de Historia Clínica de Terapia de Lenguaje
1.DATOS PERSONALES
APELLIDOS
FECHA NACIMIENTO
TELEFONO
NOMBRES
CEDULA
EDAD
ESCOLARIDAD
GRADO
DIRECCION
2. DATOS DEL REPRESENTANTE LEGAL
APELLIDOS Y NOMBRES
HISTORIA CLINICA
FECHA CONSULTA
INSTITUCION
RELACION CON EL PACIENTE
IESS
PUBLICA PRIVADA
3. DIAGNOSTICO MEDICO REFERENTE
PRENATALES
NATALES
POSTNATALES
5. DIAGNOSTICO LOGOPEDICO
Retraso de Lenguaje
Retraso de Habla
Afasia
Disfonia
Dislexia
Apraxia
Disglosia
Disfemia
Dislalia
Desarrollo Gramatical
Incremento de Vocabulario
Desarrollo Etimológico
Estimulación Temprana
6. TRATAMIENTO
Desarrollo receptivo
Descripción Auditiva
264
•
Ficha de Reporte de Terapia de Lenguaje
265
NOMBRE Y APELLIDO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
266
IESS
PRIVADO
TRATAMIENTO
PUBLICO
ESTIMULACION TEMPRANA
DISCRIMINACION AUDITIVA
DESARROLLO ITNOLOGICO
DIAGNOSTICO LOGOPEDICO
INCREMENTO DE VOCABULARIO
AÑO
DESARROLLO GRAMATICAL
DESARROLLO RECEPTIVO
DISLEXIA
DISLALIA
DISFONIA
MES REGISTRADO
ESPECIALIDAD
DISFEMIA
DISGLOSIA
DATOS DE ESTABLECIMIENTO
APRAXIA
AFASIA
DIAGNOSTICO MEDICO
RETRASO DEL HABLA
RETRASO DEL LENGUAJE
DEF. FISICO
DEF. AMBIENTALES
DEF. EVOLUTIVOS
Nº 2
ATUNTAQUI
ANTONIO ANTE
IMBABURA
DEF. SENSORIALES
GRUPO DE EDAD
DEF. NEUROLOGICA
65 AÑOS Y MAS
50-64 AÑOS
36-49 AÑOS
20-35 AÑOS
15-19 AÑOS
10-14 AÑOS
SEXO
5 - 9 AÑOS
1 -4 AÑOS
1 - 11 MESES
MENOR DE UN MES
Nº
MUJER
NOMBRE UNIDAD
AREA DE SALUD
PARROQUIA
CANTÓN
PROVINCIA
HOMBRE
CONSOLIDACION DE PRODCCION DIARIA POR PROFESIONAL
DATOS PERSONAL
DIA
PROFESIONAL FIRMA
ATENCION
ANEXO 3
267

T 72464

Transcripción

Documentos relacionados

68 Rehabilitación del hombro y del codo 70