Implementación de las reglas de negocio en la arquitectura de los sistemas de información

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática, Física y Computación Departamento de Ciencia de la Computación. “Implementación de las reglas de negocio en la arquitectura de los sistemas de información”. Trabajo de Diploma. AUTOR José Luis Díaz Vellón. TUTORES M.Sc. María Elena Martínez Busto M.Sc. Jorge Alberto González Mena. CONSULTANTE Dr. Paulino Hernández Hernández SANTA CLARA – 2012. “Año 54 de la Revolución”.

(2) Dictamen con derechos de autor para MFC. Hago constar que el presente trabajo fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de Ingeniería Informática, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. Firma del autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del tutor. Firma del tutor. Firma del jefe del Seminario.

(3) Dedicatoria. A mis padres A mi abuela A mi hermana y mi cuñado A mi sobrina A todos mis amigos.

(4) Agradecimientos. A mis tutores M.Sc. María Elena Martínez Busto y M.Sc. Jorge Alberto González Mena por su asesoría y orientación en este trabajo. A mi consultante Dr. Paulino Hernández Hernández. A mi hermana por ser mi guía A mis compañeros del grupo de investigación, en especial a Asiel y Félix A todos los profesores que me formaron y enseñaron. A todos los que de una u otra forma me han ayudado y han contribuido a la terminación de esta tesis..

(5) Síntesis. SÍNTESIS Se tiene la necesidad de obtener Sistemas de Información (SI) capaces de reflejar los cambios que se llevan a cabo en los negocios. En los últimos años el manejo de las Reglas de Negocio (RN) ha llegado a ser muy popular en la comunidad de los SI, debido a que permite obtener aplicaciones flexibles y modificables. En el presente trabajo se obtiene un SI para el control de pacientes en el Área de Nefrología (AN) del Hospital Universitario “Arnaldo Milián Castro” siguiendo el enfoque de RN. Las RN son identificadas e implementadas siguiendo lo recomendado en trabajos precedentes (Mena, 2011). Se logran implementar un significativo número de reglas y se realiza un análisis comparativo con sistemas que le anteceden, evidenciando su adaptabilidad. Dicho sistema se complementa con un portal informativo para la publicación de contenidos referentes al área nefrológica, tales como: artículos, imágenes, foros, blog, libros, etc. Se facilita el trabajo con la información guardada en el sistema gracias a las posibilidades que brindan los nuevos generadores automáticos de reportes. Como resultado adicional se conforma un video que sirve como presentación del producto..

(6) Abstract. ABSTRACT There is the need for Information Systems (IS) to reflect those changes taking place in business. In recent years the management of Business Rules (BR) has become very popular in the community of IS, because it allows applications to obtain flexible and changeable. In this paper we obtain an IS to control patients in the Area of Nephrology (AN), University Hospital "Arnaldo Milian Castro" following the approach of BR. Neural networks are identified and implemented following the recommendations in previous work (Mena, 2011). He succeeded in implementing a significant number of rules and performed a comparative analysis with systems that predate, demonstrating its adaptability. This system is complemented by an information portal for the publication of content relating to the nephrology area, such as articles, images, forums, blog, books, etc. It is easy to work with information stored in the system thanks to the possibilities offered by new automatic report generators. As a further result is content that serves as a video presentation of the product..

(7) Tabla de contenidos. TABLA DE CONTENIDOS INTRODUCCIÓN .............................................................................................................. 1 CAPÍTULO I. CONCEPTOS BÁSICOS Y CONTROL DE LOS PACIENTES DEL ÁREA DE NEFROLOGÍA ............................................................................................................ 4 1.1. Enfoque de reglas de negocio ______________________________________ 4 1.1.1. Reglas de negocio ........................................................................................ 4 1.1.2. Definición .................................................................................................... 5 1.1.3. Clasificación ................................................................................................ 6 1.1.4. Práctica de desarrollo ................................................................................... 9 1.1.4.1. Lineamientos para el descubrimiento .......................................................... 9 1.1.4.2. Pasos para el análisis.................................................................................. 11 1.1.4.3. Implementación de las reglas en el sistema sobre el MVC ....................... 14 1.2. Caso de estudio: área de nefrología ________________________________ 16 1.2.1. Control de los pacientes ............................................................................. 16 1.2.2. Caracterización del caso de estudio ........................................................... 19 1.3.. Calidad de software ____________________________________________ 21. 1.4.. Conclusiones parciales __________________________________________ 23. CAPÍTULO II. ADAPTABILIDAD DEL SISTEMA DE INFORMACIÓN ..................... 24 2.1. Implementación de las RN en el SI usando el patrón MVC ______________ 24 2.1.1. Reglas implementadas para el caso de estudio .......................................... 25 2.2. Generadores automáticos de reportes _______________________________ 36 2.2.1. Guardado de la búsqueda mediante la serialización .................................. 37 2.3. Comparación del sistema actual con versiones anteriores _______________ 37 2.3.1. Modificaciones en el sistema de información ............................................ 38 2.3.2. Modificaciones respecto a las reglas de negocio ....................................... 40 2.4.. Conclusiones parciales __________________________________________ 45. CAPÍTULO III. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE NEFROLOGÍA . 47 3.1. Diseño del sistema _____________________________________________ 47 3.1.1. Modelo de casos de uso del sistema .......................................................... 47 3.1.2. Diagrama de actividad ............................................................................... 52 3.1.3. Diagrama de navegación ............................................................................ 52 3.1.4. Cambio en el diseño de la base de datos .................................................... 54 3.2. Estructura de la aplicación _______________________________________ 56 3.2.1. Front-end .................................................................................................... 56.

(8) Tabla de contenidos. 3.2.1.1. 3.2.1.2. 3.2.2. 3.2.2.1. 3.2.2.2. 3.2.2.3. 3.2.2.4. 3.2.2.5. 3.2.2.6. 3.2.2.7. 3.3.. Página principal ......................................................................................... 56 Tipos de contenidos ................................................................................... 57 Back-end .................................................................................................... 58 Inicio de sesión .......................................................................................... 58 Página principal ......................................................................................... 59 Manejo de historias clínicas ....................................................................... 60 Tipos de estudios ....................................................................................... 62 Generadores automáticos de reportes ........................................................ 64 Trabajo con trasplantes .............................................................................. 66 Configuración y nomencladores ................................................................ 67. Conclusiones parciales __________________________________________ 69. CONCLUSIONES ............................................................................................................ 70 RECOMENDACIONES ................................................................................................... 71 REFERENCIAS BIBLIOGRÁFICAS ............................................................................... 72 ANEXOS........................................................................................................................... 74 Anexo1 ____________________________________________________________ 74.

(9) Introducción. INTRODUCCIÓN La práctica de la medicina de trasplante ha sido adoptada, como primera opción terapéutica, para un número creciente de enfermedades orgánicas durante los últimos 50 años. En la última década del siglo pasado, la mejoría en las técnicas quirúrgicas, cuidados médicos, supervivencia a mediano y largo plazo (90% a los 3 años), calidad de vida y costo beneficio, establecieron la superioridad del Trasplante Renal (TR) (Hernández et al., 2003). El TR es una alternativa que permite a los pacientes que presentan la Enfermedad Renal Crónica (ERC) salir de las listas de espera que se crean para los casos que necesitan tratamiento urgente. El TR no solo es mejor en el orden biológico, sino que también económicamente es más rentable. Por lo que constituye la mejor opción terapéutica para los pacientes con insuficiencia renal crónica terminal en diálisis, ya que les ofrece el mayor potencial para restaurar una vida sana y productiva, mejorando su calidad de vida. En la actualidad, con la aparición de nuevos fármacos inmunosupresores, se está alcanzando una mortalidad mínima, aunque si bien es cierto, el TR es un procedimiento quirúrgico electivo o semi-electivo que se realiza a pacientes que han sido sometidos a una evaluación cuidadosa (Redín et al., 2006). La atención a estos pacientes supone un gran reto para la enfermería, ya que son pacientes sometidos a una cirugía mayor que requieren múltiples cuidados y que además tienen asociado un componente de educación sanitaria muy importante. El proceso de TR no solo supone un reto desde el punto de vista médico y material, sino que precisa un respaldo informativo que en su fase primaria puede ser bastante estándar pero que en la medida que los casos pasan a una atención más especializada, requieren un tratamiento diferenciado y difícilmente se puedan abordar soluciones generales. La organización y coordinación de trasplantes, es una tarea compleja que requiere varias actividades clínicas que involucran numerosas personas y equipos de trabajos; así como un proceso administrativo paralelo a los procesos clínicos. Para la solución del respaldo informativo necesario se requiere el uso de tecnologías que respondan a diferentes paradigmas computacionales para la captación de las políticas, Pág.1.

(10) Introducción. regulaciones o leyes que deben hacerse cumplir en la entidad, lo que nos lleva al uso del enfoque de RN. Las RN representan el enlace necesario entre el negocio y el modelado de la información, estas emergen de los objetivos de la empresa (Rosca et al., 1995) y regulan cómo opera un determinado negocio y cómo el mismo es estructurado (Ross, 2005). En las aplicaciones clásicas de BD las reglas suelen estar dispersas dentro de la lógica de las aplicaciones, lo que hace difícil su modelación y mantenimiento. Dado los continuos avances en la medicina y los constantes cambios en el Área de Nefrología (AN) un sistema de esta índole no resulta una solución al problema. Con el enfoque de RN los usuarios tienen la posibilidad de definir las reglas previo al desarrollo de las aplicaciones, logrando de esta forma una independencia de las aplicaciones que las usan y facilitándose así su mantenimiento; o sea si cambia una regulación, solo hay que reflejarlo en la definición de la regla y no en los múltiples controles que hacen uso de la misma. Con el propósito de lograr la automatización de las actividades necesarias en el Hospital Universitario “Arnaldo Milián Castro”, de Villa Clara, el cual es el objeto de estudio de este trabajo, se han realizado múltiples investigaciones y proyectos, entre los que se destaca la realización de un SI con arquitectura de tres capas y un ambiente web (Mena et al., 2008; Velazco et al., 2010; Mena, 2011) que cumple con las RN propias de la integridad de los datos para automatizar los procesos relacionados con el AN. Para dar continuidad a este trabajo se impone la necesidad de identificar, ubicar e implementar las RN que se obtienen desde los objetivos de los procesos del AN. Lo anteriormente expuesto justifica el planteamiento del siguiente problema de investigación para la presente tesis: Obtener una nueva versión del sistema para el control de pacientes en nefrología, aplicando los resultados de investigaciones relativas al ciclo de vida de las RN, analizando la adaptabilidad del SI respecto a sistemas precedentes. Para el cumplimiento del problema de investigación planteado se proponen los objetivos siguientes:. Pág.2.

(11) Introducción. El objetivo general de la investigación consiste en: Implementar las reglas dentro de la arquitectura del sistema para el control de pacientes en el AN usando el patrón de diseño Modelo Vista Controlador (MVC), para solucionar el problema de adaptabilidad utilizando el enfoque de RN. Este se desglosa en los siguientes objetivos específicos: 1. Estudiar el diseño de la base de datos existente. 2. Aplicar criterios que determinan la ubicación de las RN dentro de los SI e insertarlas en su capa correspondiente para lograr la fácil actualización a las nuevas condiciones del negocio. 3. Obtener una nueva versión de la aplicación del sistema para el control de historias clínicas de pacientes de la sala de nefrología. 4. Validar el software obtenido en al menos un centro hospitalario. Como resultado de la revisión bibliográfica y de la factibilidad del trabajo se define la hipótesis de investigación siguiente: la aplicación de criterios para la ubicación de RN en los SI implementadas utilizando el MVC soluciona el problema de adaptabilidad. El trabajo se ha estructurado en tres capítulos de la siguiente forma: En el Capítulo I se resume el enfoque de RN, la clasificación cercana a la implementación, la práctica de desarrollo, el caso de estudio del AN y se abordarán criterios para la valoración de la calidad de software. Se continúa con un Capítulo II donde se describe las nuevas condiciones para el SI del control hospitalario, se hace el análisis de las nuevas RN identificadas, clasificadas y se determina su ubicación en la arquitectura del SI según las pautas propuestas por otros autores. Además se expondrán las diferencias entre el sistema anterior y el actual. En el Capítulo III del documento se valora la efectividad de los criterios empleados para lograr la adaptabilidad del SI. Finalmente se documentan las principales funcionalidades del sistema para el AN. Este documento culmina con las conclusiones, recomendaciones y referencias bibliográficas.. Pág.3.

(12) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. CAPÍTULO I. CONCEPTOS BÁSICOS Y CONTROL DE LOS PACIENTES DEL ÁREA DE NEFROLOGÍA. 1.1. Enfoque de reglas de negocio Al abordar el enfoque de RN se deben tener claros los conceptos acerca de las RN y su modelación. Este enfoque permite el manejo de las RN independiente de las aplicaciones que las hacen cumplir, dicho término ha sido utilizado por diferentes autores (Layzell et al., 1988; Date, 2000; Bajec et al., 2000; Weiden, 2000; Bajec et al., 2001; Ross, 2003a). Bajec (2001) asegura que tal enfoque “es la combinación de técnicas y tecnologías, nuevas y otras ya existentes”, desde el que se intenta identificar el conocimiento necesario para administrar una empresa, documentarlo, razonar sobre el mismo, hacerlo operacional de una manera consistente, adaptarlo sistemáticamente a cualquier vaivén del mercado y tratar, en la medida de lo posible, de automatizarlo. Es importante discernir, para orientarse en el empeño de la modelación de RN vinculadas a su soporte final por un SI, qué tipos de reglas son relevantes a ambos entornos: universo de discurso y SI. En principio, pudiera afirmarse que todas las reglas que gobiernan una aplicación son RN, sin embargo esto no siempre es cierto de acuerdo al enfoque de RN. En la práctica se pueden encontrar restricciones computacionales que no tienen correlación con el negocio (Morgan, 2002); este tipo de regla no surge del propio negocio y no resulta de interés para el propósito de esta investigación. Los aspectos de los procesos del negocio y la modelación de los SI están estrechamente relacionados con los esfuerzos por lograr la evolución de los negocios. Las RN representan el enlace necesario entre el negocio y el modelado de la información; recibiendo especial atención tanto desde el punto de vista académico como desde el punto de vista de la industria, pero no se tiene una definición aceptada y común. A continuación se presentan varios criterios de definición y clasificación para las RN, así como las herramientas que sostienen el enfoque de RN.. 1.1.1. Reglas de negocio En un artículo escrito por Daniel Appleton (1984) aparece por primera vez en el ámbito computacional la frase “regla de negocio”. El autor plantea que si los usuarios Pág.4.

(13) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. utilizaban términos que variaban en significado de un departamento a otro dentro de una misma organización, los analistas del negocio no podían proporcionar soluciones integradoras. Más tarde comienza a manejarse la idea de captar las RN mediante herramientas computacionales tanto por profesionales de negocios como de sistemas. Estas herramientas garantizan el cumplimiento de las reglas dentro del SI y aseguran que los procesos de negocio sean controlados y manejados de acuerdo a estándares, políticas y procedimientos de negocio (Struck, 1999). “Los propietarios del negocio tratan las RN de una manera diferente a los desarrolladores”, según Ross1 (1997). Para los propietarios las RN no son más que directivas que tienden a influenciar o guiar el comportamiento del negocio. Sin embargo para los desarrolladores, las RN no siempre surgen desde las políticas del negocio y son vistas como estructuras dispersas en la lógica del programa. Desde el surgimiento del término RN los autores abordan su definición de forma diferente (Appelton, 1984; Rosca et al., 1995; Youdeowei, 1997; Hay, 1997; Ceri, 1997; BRG, 2000; Bajec et al., 2000; Morgan, 2002; Ross, 2003b, 2010). Aun cuando ya se logra identificar en la literatura un conceso respecto a concepto.. 1.1.2. Definición Varios autores de reconocimiento internacional, como Ross (2003b, 2010), Bajec2 (2000), Morgan3 (2002) y Ceri (1997), se acogen a la definición expuesta en (Hay, 1997) al considerar que:. 1. Reconocido internacionalmente como “el padre de las reglas de negocio”. Ha organizado la Conferencia Fórum de Reglas de Negocio desde 1997, fundador del Grupo de Reglas de Negocio (BRG) en los años 1980, y autor-editor de importantes artículos del BRG, tales como: “The Business Motivación Model: Business Governance in a VolatileWorld” (2007) y “Business Rules Manifesto” (2003). Es también miembro activo de la OMG, donde dirige el desarrollo de estándares para RN y modelos del negocio, incluido SBVR. 2. Profesor asistente de la Universidad de Liubliana, Facultad de Computación y Ciencia de la Información, imparte cursos de: Sistemas de información, Desarrollo de sistemas de información, Bases de datos, entre otros. Sus principales intereses de investigación incluyen metodologías para el desarrollo de los SI y renovación de los procesos de negocio, en los últimos años se ha dedicado fundamentalmente al. Pág.5.

(14) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. “Una RN es: . Una sentencia que define o restringe algunos aspectos del negocio.. . Establece restricciones a la estructura del negocio, controlando o influyendo en el comportamiento del mismo.. . No podrá ser fraccionada o descompuesta en RN más detalladas.. . En caso de ser reducida perdería información importante sobre el negocio.”. Esta forma de definir una RN responde a las preguntas: ¿qué hace una regla?, mostrado en los dos primeros puntos; y ¿qué la caracteriza?, expuesto en los dos últimos -donde se destacan propiedades que deben observarse para las reglas: compactación y atomicidad. El autor de este informe considera como válida esta definición durante el desarrollo del trabajo.. 1.1.3. Clasificación La clasificación de las reglas facilita el descubrimiento, análisis y finalmente su modelación. Esta razón hace que, sin constituir una tarea obligatoria, se recomiende hacerlo para simplificar la formalización de las RN. Además, clasificar las reglas garantiza la consistencia de la descripción y eleva su claridad. El propósito de dicha tarea, como etapa dentro del análisis, es facilitar la identificación y lograr su atomicidad. Varios autores proponen taxonomías de clasificación según el nivel de abstracción, funcionalidad, relación con el SI, entre otros criterios (Schreiber et al., 1999; Kovacic et al., 2001; Weiden et al., 2002; Morgan, 2002; Horrocks et al., 2004). Este epígrafe aborda dos de estas taxonomías por considerarlas relevantes para la presente investigación.. desarrollo de metodologías para el desarrollo ágil y basado en RN de software. Tiene una activa participación en numerosas investigaciones y desarrollo de proyectos. 3. Profesor Distinguido en Ciencia de la Computación en la Universidad de Neumont, donde ha impartido docencia en niveles de pregrado y posgrado, además de investigar en el futuro de los sistemas de información. Tiene una vasta experiencia práctica en relación a la creación y desarrollo de SI. Ha trabajado en compañías tales como EDS y Unisys. Su interés técnico principal está en el uso de manejadores de modelos para construir SI que evidencien el valor de negocios reales. Autor de numerosos artículos y libros que abarcan la temática de las RN.. Pág.6.

(15) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. Clasificación semántica El esquema propuesto por Weiden y colaboradores (2002) puede ser usado para clasificar las RN de acuerdo a sus propiedades semánticas. Dicho autor define tipos de RN agrupados en tres categorías (Weiden, 2000; Weiden et al., 2002): estructurales, de comportamiento o conducta y de administración. Estas categorías representan diferentes visiones del negocio. Las reglas estructurales son las concernientes a la descripción de aspectos estáticos de un negocio. Las de comportamiento definen las condiciones sobre la ejecución de tareas en el negocio. La categoría de reglas de administración define las restricciones de alto nivel sobre el negocio. La distinción entre los puntos de vista: estructural y de comportamiento, es bien conocida y sirve como base a muchos métodos de análisis de sistema, incluyendo UML. Ambos puntos de vista definen la visión interna del proceso de negocio. El punto de vista administrativo agrega una vista externa e introduce nociones tales como: objetivo, valor, recursos necesarios de tareas, actores y procesos del negocio (Weiden, 2000). Este esquema de clasificación asume que se ha creado el modelo de procesos inicial del negocio en términos de los procesos y tareas principales. Cada una de las tres categorías es subdivida en varios tipos de RN: Estructural: estructura de conceptos, persistencia e historia. De Conducta: flujo de información, pre-condición, post-condición, frecuencia, duración, flujo de control y conocimiento de la tarea. Administrativa: organización, objetivo y valor, actitud del actor, responsabilidad del actor y recursos. Este esquema se apoya en la semántica de las reglas, proporciona categorías, que guardan un estrecho vínculo con los elementos del modelo del negocio, por lo que se considera cercano a los propietarios. A diferencia de la taxonomía propuesta por Goedertier4 (2007b), que también se apoya en la semántica de las reglas desde la óptica. 4. Es Dr. en Ciencias Económicas Aplicadas en 2008, el título de su tesis fue: “Declarative Techniques for Modeling and Mining Business Processes” (Goedertier, 2008). Investigador en administración de procesos de negocio. Profesor de numerosos cursos doctorales, tales como: introducción a la. Pág.7.

(16) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. de las personas del negocio y proporciona muchas sub-categorías, alejándose del negocio y dando una visión más cercana al programador. Clasificación cercana a la implementación Reportada por Soliveres (1997), este autor se acerca a la visión del implementador y propone las siguientes categorías de RN: Reglas del modelo de datos: engloba todas aquellas reglas que se encargan de validar la información básica almacenada para cada atributo o propiedad de una entidad u objeto. Reglas de relación: incluye todas aquellas reglas que controlan las relaciones entre los datos. Reglas de restricción: restringen los datos que el sistema puede contener. Nótese que este grupo de reglas se solapa, en cierto modo, con las reglas del modelo de datos, dado que aquellas también impiden la introducción de datos erróneos. La diferencia estriba en que este tipo de regla restringe el valor de los atributos o propiedades de una entidad más allá de las restricciones básicas que sobre las mismas existen. Reglas de derivación: están integradas por aquellas reglas que permiten derivar cierta información a partir de otra, controlan la obtención de información, realización de cálculos, etc. Reglas de flujo: son las que determinan y limitan cómo fluye la información a través de un sistema, indican qué camino recorre la información y obligan a que se sigan solo aquellos que son permitidos. Esta taxonomía se vincula estrechamente con la forma en que las reglas son implementadas en el SI, dando la visión de los desarrolladores. Las tres primeras categorías conforman un grupo que está dirigido a la estructura y validación de los datos. Considerando este grupo como una categoría, y unida a los dos restantes se observa gran. metodología de la investigación, lenguajes y metodologías de la investigación, aprendizaje automático e inferencia inductiva, entre otros. Revisor de numerosas publicaciones, entre las que se encuentra: Information Systems sobre modelación de procesos de negocio. Es miembro del comité del programa del evento “The International RuleML Symposium 2008”, sobre el intercambio y aplicación de reglas. Publica numerosos artículos, entre ellos se destaca el que recibe el reconocimiento como best paper (Goedertier et al., 2007b).. Pág.8.

(17) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. similitud con las clasificaciones propuestas por Kovacic (2001) y Goedertier (2004; 2007a; 2007c), diferenciándose básicamente en que estas dan una visión más cercana al negocio. Las razones antes expuestas hacen que en esta investigación se utilice como guía la clasificación cercana a la implementación propuesta por Soliveres (1997).. 1.1.4. Práctica de desarrollo Es de interés para la comunidad de desarrolladores de software, investigadores y usuarios del negocio encontrar fuentes seguras para la modelación de RN. Al ubicar el presente trabajo dentro de un escenario propio para RN, se pueden definir etapas de tránsito además de actores involucrados. Entre las etapas iniciales y más importantes en el ciclo de vida de las RN están: captura, análisis y clasificación. Es necesario que el descubrimiento y la identificación de las reglas se vinculen fuertemente con la captación de los requisitos del SI. La unión entre los lineamientos y los pasos es llamada Práctica de Desarrollo y debe realizarse de manera integrada, realizando la continuidad con la implementación de las reglas identificadas en la arquitectura del SI acorde a lo recomendado según la alineación entre las clasificaciones de RN descritas en el epígrafe anterior.. 1.1.4.1.. Lineamientos para el descubrimiento. El ambiente de desarrollo de software propuesto por Bajec y Krisper (2005) como un escenario para la administración de RN, integra actividades de modelación del negocio vinculadas al desarrollo de SI. Se destacan las actividades específicas para administrar las RN a través de su ciclo de vida. Entre ellas se encuentra el descubrimiento, descrito dentro de este escenario como el análisis de la información acerca del negocio para el cual se desarrolla el SI; o sea, para el descubrimiento de las RN debe tomarse información de fuentes que permitan derivar los negocios oscuros. En el presente epígrafe se propone seguir cinco lineamientos, formulados en (Weiden et al., 2002), que conforman la estrategia para el descubrimiento de las RN y facilitan la identificación (Martínez Busto et al., 2009). Estos lineamientos, unidos a los pasos propuestos en el siguiente epígrafe, conforman la práctica de desarrollo para la captación Pág.9.

(18) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. de las RN propuesta en la presente investigación. Cada lineamiento y su correspondiente fundamentación se detallan seguidamente. Lineamiento 1: Asegurarse de que es posible hablar con la persona indicada. Fundamento: Es difícil extraer algunos tipos de RN cuando, al realizar la entrevista, no se cuenta con la persona adecuada. Esto sucede, especialmente, con las reglas que pertenecen a la categoría de administración, que con frecuencia son poco conocidas o dominadas por el personal de la organización. Para identificar las reglas que intervienen en la ejecución de tareas es recomendable dialogar con quienes las ejecutan, además de los directivos. Esto se debe a que es posible que existan puntos de vista diferentes sobre las reglas que gobiernan una tarea en particular, que deberán ser analizados. Lineamiento 2: Comenzar obteniendo una vista general sobre el proceso de negocio como un todo e identificar las RN del tipo objetivo y valor. Fundamento: Resulta difícil comenzar la extracción de las reglas cuando no se tiene una visión general de qué pasa en la organización y por qué se hace de esa forma. Especialmente, es mejor disponer del modelo de procesos del negocio cuando se realiza una entrevista para la extracción o reconocimiento de RN, siendo utilizado como un mecanismo estructural. El diagrama de actividades UML es una técnica apropiada para representar el modelo de procesos. Las reglas acerca del objetivo y valor de los procesos pueden ser usadas como punto de partida en la extracción de reglas más específicas sobre los objetivos de tareas. Lineamiento 3: Establecer en etapas tempranas las reglas de estructura de objetos de un dominio. Fundamento: Este tipo de RN abarca la estructura de los objetos del vocabulario de dominio. Es importante que los términos usados para los objetos en el dominio sean identificados previamente, de manera que el riesgo de confusión, en cuanto a la terminología durante la extracción de las reglas, sea el menor posible. Lineamiento 4: Si existen dos vías diferentes de modelar una parte del negocio, escoger la que describa el negocio con términos más claros para la persona entrevistada.. Pág.10.

(19) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. Fundamento: Esta situación se presenta cuando se decide si una regla pertenece a la categoría flujo de información/control o pre/post-condición. Ambos tipos o categorías pueden ser usados para modelar dependencias entre tareas. La mayoría de las personas del negocio prefieren usar las reglas del tipo flujo de información/control. Obviamente, durante una entrevista resulta más fácil hablar acerca de flujos entre tareas que tratar de definir pre y post condiciones de tareas. Luego, si se estima apropiado, las sentencias o reglas obtenidas en lenguaje natural de la entrevista, pueden transformarse al tipo pre/post-condición. Para ello se recomienda optar por la categoría pre/post-condición solo si una regla puede ponerse en términos de una tarea. Por otro lado, mientras que la regla contenga una sentencia referente a más de una tarea se recomienda clasificarla como una regla del tipo flujo de información/control. Lineamiento 5: La categoría conocimiento de la tarea puede ser usada para aquellas reglas que especifican cómo una tarea debe ser ejecutada, aunque la información del modelo del negocio no debe enfocarse en su comportamiento interno. Fundamento: Las reglas del tipo conocimiento de la tarea deben ser detalladas para ser incluidas en un modelo del negocio, pero es conveniente registrarlas aun cuando no lo sean. Estas reglas actúan como base de información utilizada en algún punto posterior del proyecto, y proporcionan entradas importantes para conformar un SI.. 1.1.4.2.. Pasos para el análisis. Los lineamientos propuestos guían el descubrimiento de las RN, pero no constituyen una práctica que establezca la forma en que esto debe hacerse. En este epígrafe se proponen los pasos a seguir como método de trabajo para el análisis de las reglas utilizando la notación UML. A través del análisis de las RN son descompuestos los negocios oscuros en sentencias precisas y atómicas. Esto incluye la clasificación de las reglas, basadas en un esquema predefinido y cuyo objetivo es proveer estructuras donde puedan ser fijadas respecto a su naturaleza o el tipo de información que proporcionan. En este epígrafe se propone continuar los pasos para el análisis y clasificación de las RN desde una perspectiva de la empresa, extrayéndolas desde el modelado del negocio. Dicha propuesta se apoya en el trabajo de García Molina (2004), donde además se emplea la taxonomía de clasificación semántica por su vínculo directo y natural al propio Pág.11.

(20) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. modelado. Los pasos son descritos en (Martínez Busto et al., 2009; Machado Padilla, 2009). Paso 1ro: Obtener los roles La definición del conjunto de procesos del negocio es una tarea crucial, debido a que se especifican los límites del proceso de modelado posterior. Teniendo en cuenta que los objetivos estratégicos de la organización son generalmente muy complejos y con un nivel de abstracción elevado, estos serán descompuestos en un conjunto de sub-objetivos más concretos que deberán cumplirse para conseguir dicho objetivo estratégico. Estos sub-objetivos pueden a su vez ser descompuestos en otros de manera que se defina una jerarquía, es suficiente obtener dos o tres niveles de descomposición. Para cada subobjetivo de segundo nivel se define un proceso de negocio que lo soporte. Se propone representar cada proceso de negocio como un caso de uso del negocio. Una vez identificados los procesos de negocio se plantea encontrar los agentes involucrados en su desempeño, donde cada uno de ellos juega un determinado papel (o rol) cuando colabora con otros para llevar a cabo cualquiera de las actividades que conforman un caso de uso del negocio. Dentro de este primer paso en la obtención del modelo del negocio se propone obtener el diagrama de casos de uso del negocio para lograr una visión más clara y general de los procesos del negocio de la organización. Paso 2do: Obtener colaboración entre roles En el segundo paso se propone, primeramente, describir en detalles cada uno de los casos de uso que han sido identificados en el paso anterior. A continuación se determinan los agentes que juegan un rol en cada caso de uso del negocio, para finalmente brindar una especificación detallada de ellos. Por lo que se propone, en este paso, obtener el diagrama de roles (que expresa la colaboración entre roles desde el punto de vista estructural) para desarrollar un caso de uso determinado del negocio. Este diagrama permite expresar el conocimiento que tienen unos roles sobre otros, además de la multiplicidad entre sus relaciones. Paso 3ro: Obtener comportamiento de colaboración Como tercer paso se propone crear escenarios para mostrar el comportamiento de la colaboración entre los roles anteriormente identificados. Para este propósito se. Pág.12.

(21) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. recomienda emplear diagramas de secuencia UML, donde los objetos denotan instancias de roles que intervienen en la interacción para cada caso de uso. Paso 4to: Obtener interacción entre procesos, flujo de información y actores En este paso, para mostrar el flujo de trabajo de determinados objetivos de la organización, se propone utilizar un modelo del negocio representado mediante una vista de proceso basada en el estándar IDEF0. Este diagrama muestra el flujo de trabajo, indicando qué rol realiza cada actividad y cuáles son los datos requeridos y producidos por esta. Además, para ello pueden usarse diagramas de actividad de UML con calles, nombrándolos diagramas de procesos. En cada proceso se puede establecer una distinción entre el flujo básico o normal de la interacción (ejemplo: realización de exámenes de laboratorio) y los posibles flujos alternativos (ejemplo: análisis por sexo). Para mejorar la legibilidad es conveniente asociar varios escenarios a un mismo caso de uso del negocio, en vez de mostrar en una sola secuencia todas las posibilidades. En este diagrama de procesos existe una calle para cada rol participante (caso de uso del negocio), incluyendo las actividades que realiza el mismo, y la información que necesita y produce cada actividad. Paso 5to: Identificar y clasificar reglas a partir del modelo del negocio En este paso se propone identificar las reglas basándose en el modelo del negocio obtenido de acuerdo a los pasos anteriores. Se propone además, clasificar las RN identificadas según el esquema semántico. Cada RN puede ser enmarcada dentro de una de las categorías, algunas se ven identificadas en el diagrama de procesos de diferentes formas, por ejemplo:  Las RN de tipo flujo de información se ven a través de las líneas discontinuas orientadas en el sentido de la flecha, indicando qué información necesita una tarea o actividad.  Otro tipo de reglas, como la de flujo de control, indican el orden entre tareas. Se representan en el diagrama por flechas continuas.. Pág.13.

(22) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”.  Las reglas de tipo responsabilidad del actor dicen qué actor es responsable de una determinada tarea; pueden ser extraídas del diagrama al identificar las actividades encerradas en la calle perteneciente a dicho actor (o rol). Esta taxonomía es útil debido a que las RN pueden ser extraídas desde el propio lugar al que pertenecen, o sea, desde la propia lógica del problema donde juegan un rol en la política de la organización. Es en este quinto paso donde se extraen las reglas de forma natural, a partir del propio modelo del negocio y siguiendo el esquema de clasificación semántico, considerado para esta investigación. Como práctica de desarrollo para lograr rigor y sistematicidad en la captación de las RN desde el enfoque de RN se proponen la guía para el trabajo mediante la asunción de los cinco lineamientos propuestos en el epígrafe 1.1.4.1, el uso de los pasos para el análisis de las RN basado en el modelado del negocio y su clasificación según criterios semánticos. Por otra parte, la idea de lograr mayor independencia en una aplicación o tarea particular debe verse ligada a recurrir siempre al vocabulario del negocio y modelos ontológicos. Es de interés que en la comunidad de RN se reconozcan las reglas como artefactos que, por la naturaleza del problema (o estrategia del negocio), soportan e infieren la estrategia que es aplicada al problema (Gerrits, 2004). Por lo que las RN que resultan ser capturadas en el contexto de una tarea particular serán menos reusables y más específicas.. 1.1.4.3.. Implementación de las reglas en el sistema sobre el MVC. Las RN deben administrarse como un activo independiente de una organización (Ross, 2003b). De estar dispersas y mezcladas con el código de la aplicación se dificulta, entre otras cosas, su localización al momento de modificarlas por algún cambio en el negocio. La motivación para mejorar la ubicación y administración de estas reglas es justamente lograr incrementar el control y el conocimiento en la organización de cómo, por qué, cuándo, dónde y gracias a quién se fortalecen las mismas. Muchos de los sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Pág.14.

(23) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí. Esta arquitectura facilita responder a los cambios, permite reutilizar código, simplifica el mantenimiento y hace más fácil la migración a nuevas plataformas. El patrón MVC básicamente lo que hace es dividir la capa del negocio en dos capas, la capa del modelo y la capa del controlador; lo que permite resolver el problema de la ubicación de las RN dentro de los SI. Ubicar una determinada RN dentro del MVC puede simplificarse mucho si se tiene en cuenta el tipo de regla tratada. La Figura 1.1 muestra la ubicación recomendable para las RN según (Mena et al., 2008; Velazco et al., 2010) utilizando la clasificación dada por Soliveres (1997). 2.. Controlador. 3. 4.. Capa Intermedia. Capa de Cliente. Importación de reglas del modelo. . Reglas de flujo.. 5.. Modelo . Reglas del modelo de datos.. . Reglas de relación.. . Reglas de restricción.. . Reglas de derivación.. Capa de Servidor . Reglas del modelo de datos.. . Reglas de relación.. Figura 1.1 Ubicación de las reglas de negocio dentro del Modelo Vista Controlador.. Pág.15.

(24) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. 1.2. Caso de estudio: área de nefrología La necesidad de obtener sistemas informáticos que abarquen los procedimientos durante el seguimiento a pacientes de nefrología hace viable la aplicación de SI basados en RN. Los pacientes son tratados en esta área de la medicina, donde la práctica de trasplante ha sido adoptada en los últimos años como primera opción terapéutica. Cada procedimiento a seguir durante el tratamiento es regido por complejos protocolos de trabajo. El paciente puede pasar por diferentes tipos de consultas según sean sus avances y evolución particular. Médicos y paramédicos deben tomar decisiones importantes ante cada nueva situación según los resultados en los exámenes realizados a sus pacientes y de los protocolos que rigen todo el proceso. Con los avances científicos y los resultados investigativos en este campo de la ciencia, las regulaciones para el seguimiento de los casos en dicha área suelen ser dinámicas, por lo que surge la necesidad de SI capaces de adaptarse, de forma rápida y segura. La informática médica, en particular, es la aplicación de la informática y las telecomunicaciones a la salud, tiene como objetivo principal prestar servicio a los profesionales de la salud para mejorar la calidad en la atención médica; representa la intersección de las ciencias de la información, ciencias de la computación y la atención de la salud. Esta rama de la informática se ocupa de los recursos, los dispositivos y los métodos necesarios para optimizar la adquisición, almacenamiento, recuperación y utilización de la información en salud y biomedicina. Los instrumentos informáticos de la salud incluyen, no sólo los ordenadores, sino también guías de práctica clínica, terminología médica formal y de sistemas de información y comunicación.. 1.2.1. Control de los pacientes En el AN los pacientes reciben atención especializada insertándose en un sistema de atención secundaria y terciaria personalizada. Se requieren registros permanentes que faciliten gestionar los exámenes y la evolución para cada enfermo. Dicha área incluye diversas especialidades que, en dependencia de cada uno estos controles, tiene sus peculiaridades. La atención al paciente se realiza de acuerdo al seguimiento en tres tipos de consultas: Pág.16.

(25) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”.  Consulta de progresión o renal crónica avanzada (externa o evolutiva).  Consulta de hemodiálisis.  Consulta de trasplante. Cada consulta tiene sus propios requerimientos de información, protocolos de trabajo y restricciones, que deben ser consideradas tanto en las prácticas médicas como para los requisitos y funcionalidades que se esperan de los sistemas computacionales de apoyo. Esto resulta de gran importancia, no solo para el personal médico y paramédico, también para pacientes y familiares relacionados con esta área. Los datos de cada paciente deben estar disponibles para los diferentes especialistas que lo atienden. Además, es deseable brindar información para pacientes y personas allegadas, posibilitando que conozcan -no solo del estado actualizado del enfermo- sino que adquieran cultura en cuanto a los cuidados que se deben tener con pacientes con estas características, donde la atención familiar resulta decisiva en el éxito del tratamiento. En cada tipo de consulta se registran parámetros diferentes acerca del estado de un paciente, que puede o no haber sido tratado. Esto sugiere manejar al paciente como entidad abstracta, accesible desde cualquier consulta, con la seguridad de disponer de una vista actualizada del mismo. A la vez, debe responder a leyes y regulaciones dependientes del contexto que ofrece cada consulta en particular. La insuficiencia total o casi total en el funcionamiento del riñón para excretar los desechos, concentrar la orina y regular la electrólisis es considerada como insuficiencia renal crónica (IRC). Cuando esta enfermedad está en una etapa terminal, que se considera el desenlace común a múltiples enfermedades que afectan al riñón, se denomina insuficiencia renal crónica terminal (IRCT). Esta se presenta cuando los riñones ya no pueden funcionar al nivel necesario para la vida diaria, es decir, que la IRC progresa a un punto tal que la función de los riñones es menor del 10% de su capacidad normal. El AN atiende pacientes en los diferentes estadios de esta enfermedad. Determinar el estadio en que se encuentra cada paciente es una tarea fundamental dentro del área y de acuerdo a ello será el tratamiento que reciba.. Pág.17.

(26) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. Los posibles estadios de un paciente se encuentran entre los valores del I al V. De encontrarse el paciente en alguno de los dos primeros es reorientado a su área de salud para ser atendido allí en la consulta de nefrología. Si se encuentra en uno de los estadios III o IV el paciente es atendido en la propia consulta de progresión. Cuando el estadio del paciente es V se considera que la enfermedad se encuentra en estado terminal y el paciente es remitido a uno de los métodos sustitutivos de la función renal: diálisis peritoneal, hemodiálisis o trasplante renal. El recibir terapia con diálisis peritoneal puede representar una opción para salvar la vida de aquellos pacientes con IRCT que no pueden, por alguna razón, recibir tratamiento de trasplante del órgano; este puede provenir de dos fuentes:  Un donante familiar vivo: (genéticamente emparentado con el receptor: padres, hermanos o hijos) (Kasiske et al., 2001).  Un donante muerto o donante con muerte encefálica (persona recientemente fallecida que no ha tenido enfermedad renal crónica) (Ojo et al., 2001). Al decidir el origen del órgano se establecen dos tipos posibles de donantes para conformar la pareja receptor-donante potencial5, considerando que es posible tener: uno o varios donantes potenciales y uno o varios posibles receptores. La pareja constituida es sometida a un protocolo de compatibilidad. En caso de tener un resultado favorable, al finalizar el protocolo de compatibilidad se envían los pacientes a la consulta de TR o consulta multidisciplinaria, o sea al receptor y posibles donadores o donante potencial (se pueden proponer uno o varios donadores candidatos). Esta consulta se integra de varios especialistas, entre ellos: nefrólogo, cirujano y urólogo, y otros; generalmente es dirigida por un nefrólogo (Hernández et al., 2003), y permite evaluar la pareja receptor-donador potencial. El donante juega un papel muy importante dentro de este proceso. Identificar el mejor entre los posibles donadores es una delicada tarea guiada por un complejo protocolo. Cada uno de los exámenes va descartando candidatos para, finalmente, elegir la mejor 5. Se considera “receptor-donante potencial” o “receptor-donador potencial” a la pareja que se integra por un receptor con un posible donante de riñón.. Pág.18.

(27) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. posibilidad de éxito en la operación. Una vez completado el protocolo para donante potencial, si no se rechazan todos, se pasa a seleccionar el donador. En caso exitoso se conforma la pareja donante-receptor y se da continuidad al protocolo de trasplante. La operación de trasplante asociada a un donante con muerte encefálica sigue un procedimiento muy similar a la que es asociada a donante vivo, difieren básicamente respecto a la operación de extracción del órgano del donante y al tratamiento del donador. Los registros respecto al donante también difieren, pero en cuanto a otras actividades básicas son exactamente iguales: los protocolos y registros para el órgano donado, la operación de extracción e implante del mismo, y el seguimiento postoperatorio para el receptor. Con el fin de evitar el rechazo casi todos los receptores de trasplante de riñón requieren tratamiento de por vida. El éxito de un trasplante de riñón depende, en parte, del seguimiento minucioso y el cumplimiento meticuloso del régimen de medicamentos. Los pacientes deben ser chequeados periódicamente, controlando un conjunto de parámetros que evidencian posibles padecimientos o complicaciones. El seguimiento al que es sometido el paciente posterior a la operación depende de su desarrollo y evolución. Esta consulta es llamada consulta de progresión, externa o evolutiva. Las únicas posibles formas en que un enfermo puede salir del sistema es por la muerte del paciente debido a causas diversas o debido a que cualquier paciente o posible donante abandone el tratamiento en cualquier momento de manera voluntaria.. 1.2.2. Caracterización del caso de estudio De la descripción anterior se puede concluir que: 1.. Durante la atención a un paciente en esta área se tienen que tomar múltiples decisiones que están muy bien reglamentadas en diferentes protocolos.. 2.. Las decisiones están fuertemente interrelacionadas, o sea, unas dependen de otras.. 3.. Cada usuario, médico, paramédico, paciente o familiar tiene requerimientos informativos diferentes. Debe propiciarse el acceso y manejo de la información a cada cual según su rol. Pág.19.

(28) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. 4.. Los tratamientos y procedimientos son susceptibles a cambios, e incluso hasta pueden variar de acuerdo a la región o país. Se rigen por normativas o avances científicos a diferentes niveles.. 5.. Se debe permitir a usuarios avanzados dar mantenimiento a las políticas trazadas en un ambiente flexible, este tipo de usuario puede ser incluso, el propio médico.. Todo lo anterior sugiere que la aplicación del enfoque de RN facilita la obtención de soluciones computacionales para este dominio. Debido, fundamentalmente, a la elevada probabilidad de cambios rápidos y constantes que afectan el ambiente de la aplicación, identificándose la necesidad de renovación y adaptación. El sector de la salud es un área en que los cambios son muy frecuentes dado el vertiginoso desarrollo que tiene la medicina, tanto en nuestro país como a nivel mundial. Estos cambios se originan en la comunidad científica y se canalizan a través del sistema de salud hasta su instrumentación por parte de los especialistas, que incluso pueden aportar, con su experiencia, determinadas variaciones. Lo anterior, refuerza el hecho que deben ser los propios especialistas del negocio, en este caso los médicos, los encargados de crear y dar mantenimiento a sus políticas, expresadas con una terminología que depende en gran medida de cada área o sector. Hay que tener en cuenta las reglamentaciones y normativas que rigen o restringen los diferentes procesos y actividades en un negocio, no solo en la etapa inicial del ciclo de vida de un SI, sino también a lo largo del resto de las diferentes etapas, especialmente en sectores tan sensibles como el de la salud. Ante el imperativo de obtener un sistema de información con estas características se evidencia la necesidad de:  Recopilar información en la etapa de análisis de los requerimientos del software que permita crear y mantener los registros relacionados con la actividad y manejo de pacientes del AN y su seguimiento.  Determinar qué reglamentaciones y normativas permiten la fiscalización de cada etapa en esta área, según los protocolos de trabajo establecidos.. Pág.20.

(29) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”.  Determinar el vocabulario médico utilizado por la comunidad profesional ligada a cada etapa o actividad concreta.. 1.3. Calidad de software ¿Qué es la calidad del software? La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de “cero fallas”; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación. La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software. Definiciones de calidad del software A continuación se refieren algunas definiciones de calidad de software dadas por (Lovelle, 1999).  “Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”.  “El conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas”.. Pág.21.

(30) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. La calidad, al igual que la belleza, está en el ojo de quien lo mira, sin embargo, desde el punto de vista de medición, se debe tener una definición precisa en términos de atributos del software que sean de interés al usuario en general, éstos son atributos externos sin embargo, muchas propuestas miden y analizan atributos internos porque los consideran predictores de aquellos externos, los atributos internos tienen dos ventajas: 1. Están disponibles para medición más temprano. 2. Son más fáciles de medir. Desde los primeros modelos de calidad en el inicio de la ingeniería de software, se observó que la calidad está dada por un amplio conjunto de características, un modelo de calidad describe entonces estas características y sus relaciones, muchos modelos hacen difusa la distinción entre atributos internos y externos, lo que dificulta la comprensión del concepto de calidad, los modelos que se presentarán a continuación son los que han ganado mayor popularidad en la comunidad, pero no tienen sustento científico, extrayendo los factores comunes a todos ellos es posible derivar modelos propios adaptados a usos específicos En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; si la implementación sigue al diseño y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. Adicionalmente se puede seguir los siguientes aspectos para evaluar la calidad del software: . Funcionalidad. . Confiabilidad. . Usabilidad. . Eficiencia. . Mantenibilidad. . Portabilidad. . Escalabilidad Pág.22.

(31) Capítulo I: “Conceptos básicos y control de los pacientes del área de nefrología”. Por lo anteriormente analizado se concluye que no se puede medir la calidad del software de forma correcta debido a su naturaleza, la certificación se da a los procesos, la correcta consecución de los mismos garantizaría un buen software. No se puede medir al software como tal, sino los atributos que lo conforman, tales métodos de medida deben ser exactos. El usuario final mide la calidad del software según lo que tenga o no, es en ese sentido de que la calidad del software depende de quien la juzgue. El hecho de que una empresa tenga certificación en calidad de software no garantiza que su software sea de calidad.  Los requisitos del software son la base de las medidas de calidad.  La falta de concordancia con los requisitos es una falta de calidad.  Los estándares o metodologías definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se sigue ninguna metodología siempre habrá falta de calidad. . Existen algunos requisitos implícitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que también pueden implicar una falta de calidad.. . La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización.. 1.4. Conclusiones parciales Este capítulo expone la definición, clasificación y propiedades de las RN, haciendo un análisis del uso de estas dentro de los SI. Se plantean las características de dos importantes taxonomías de clasificación: semántica y cercana a la implementación, ya que aunque no son necesarias para lograr el manejo adecuado de las RN facilitan su captación. De las clasificaciones mencionadas, la cercana a la implementación es la usada en la presente tesis ya que facilita al desarrollador determinar la ubicación de las RN en la arquitectura del sistema, debido a que la descripción es cercana al código. Se presenta el caso de uso para el AN y finalmente se concluye abordando el tema de calidad de software. Pág.23.

(32) Capítulo II: “Adaptabilidad del sistema de información”. CAPÍTULO II. ADAPTABILIDAD DEL SISTEMA DE INFORMACIÓN Este capítulo se enfoca a la aplicación de los criterios que determinan la ubicación de las RN dentro del SI y su inserción en su capa correspondiente, para lograr la fácil actualización a las nuevas condiciones del negocio, haciendo uso del patrón de diseño MVC. Se presentan las RN implementadas, se argumentan sus ubicaciones y se muestran ejemplos de cómo quedan embebidas en el código del sistema. Se exponen las nuevas características de la versión propuesta centrándose en las herramientas incorporadas, en especial los generadores automáticos de reportes para la extracción y exportación de los datos. Por último se explica el método aplicado en la evaluación del software.. 2.1. Implementación de las RN en el SI usando el patrón MVC En el sistema se recomienda que la mayor parte de las reglas sean ubicadas en el modelo, lugar ampliamente recomendado en la arquitectura MVC para su localización. Esto se debe a que en este se encuentra la representación específica de la información con la cual el sistema opera. Como excepción están las reglas de flujo que son excelentes candidatas a ser implementadas en el controlador debido a que su complejidad suele ser, por lo general, bastante elevada y su comportamiento se ajusta al objetivo del controlador. Para una mejor comprensión del tema tratado en esta sección es necesario referirse a un método muy utilizado en la aplicación. Este método es beforesave () declarado en el modelo. Dicho método se ejecuta inmediatamente después de que los datos del modelo han sido satisfactoriamente validados, pero justo antes de que los datos sean guardados. Esta función debe devolver un valor true si se desea que continúe la operación de grabado. Este callback es especialmente útil para cualquier lógica de tratamiento de datos que necesita ocurrir antes de que los datos sean almacenados, por tal motivo es el lugar recomendado, por el autor de la presente tesis, para insertar funciones de validación dadas por las RN.. Pág.24.

(33) Capítulo II: “Adaptabilidad del sistema de información”. 2.1.1. Reglas implementadas para el caso de estudio A continuación se refieren RN implementadas en el sistema para el AN. Se ejemplifican agrupándolas según la clasificación dada por Soliveres (1997). . Reglas del modelo de datos:. Con un correcto diseño de la BD quedan automáticamente implementadas muchas de las reglas del sistema en la capa del servidor, esto se hace, en primer lugar, escogiendo correctamente el tipo de los campos de cada tabla, pero es muy importante que estas se refuercen en la capa intermedia (modelo) para una mayor independencia del gestor de BD y brindar mayor robustez a la aplicación. Estas reglas se insertan en el modelo (ubicado en la capa intermedia) en forma de una matriz de condiciones. A continuación se muestran algunos ejemplos de RN, las cuales se implementan en el modelo de historia clínica (clinical_history) del paciente. R1:. El número de carné de identidad de un paciente debe cumplir con ciertas. condiciones básicas, como que es de tipo entero con una longitud de 11 dígitos. var $validate = array( 'ci'=> array( 'isUnique'=> array( 'rule'=> 'isUnique', 'required'=> true, 'message'=> 'Número de carnet repetido' ), 'custom' => array( 'rule' => array('custom', '/^\d{11}$/'), 'required' => true, 'message' => 'Debe introducir un número de 11 dígitos' ), ) );. Pág.25.

(34) Capítulo II: “Adaptabilidad del sistema de información”. R2:. La fecha de ingreso al programa de un paciente debe ser del tipo fecha.. var $validate = array( 'fecha_de_ingreso_al_programa' => array( 'date' => array( 'rule' => 'date', 'message' => 'Ingrese una fecha válida usando el formato AAAAMM-DD', ) ) ); Para evitar envíos erróneos de información y esperas innecesarias por parte del usuario se deben implementar estas validaciones en la capa del cliente. Esto se logra importando del modelo a la vista, las reglas del modelo de datos, haciéndose en la misma gran parte de los controles necesarios para garantizar la validez de la información introducida por el usuario, no es difícil, dado que son chequeos relativamente sencillos, al afectar solo a un campo, y de hecho algunos plug-in para el framework CakePHP implementan esta funcionalidad. . Reglas de relación:. La validación de estas reglas se puede conseguir en la capa del servidor ya que la mayoría de los gestores de BD proporcionan integridad referencial y los mecanismos necesarios para implementar fácilmente estas reglas, lo que proporciona mayor robustez a la BD. Esto se logra utilizando el motor de almacenamiento InnoDB que es una tecnología de almacenamiento de datos de código abierto para MySQL, incluido como formato de tabla estándar en todas las distribuciones de MySQL AB a partir de las versiones 4.0. Su característica principal es que soporta transacciones de tipo ACID y bloqueo de registros e integridad referencial. InnoDB ofrece una fiabilidad y consistencia muy superior a MyISAM, la anterior tecnología de tablas de MySQL. No obstante estas reglas se implementan en los modelos en forma de una matriz de relaciones permitiendo la comprobación de estas en un lenguaje de alto nivel como lo es. Pág.26.

(35) Capítulo II: “Adaptabilidad del sistema de información”. PHP, independizando la aplicación del gestor de BD. A continuación se muestran algunos ejemplos: R3:. Un posible receptor puede ser asociado al menos a un donante potencial.. Esta regla asegura que un receptor se tenga que asociar a una serie de donantes potenciales (candidatos a donar al realizar el trasplante de donante vivo) antes de la realización del trasplante. Este paso intermedio es importante, pues de la relación de estos se debe insertar, en caso de existir, el parentesco y además el receptor tiene sus datos relacionados como son: Causa de la IRC, Terapia Sustitutiva y Tiempo en Terapia Sustitutiva. Para definir esta regla se incluye la siguiente relación en el modelo donante (clinical_history_of_donor): public $belongsTo = array( 'ClinicalHistoryOfReceptor' => array( 'className' => 'ClinicalHistoryOfReceptor', 'foreignKey' => 'clinical_history_of_receptor_id' )); En el modelo receptor (clinical_history_of_receptor) la relación inversa se representaría como sigue: public $hasMany = array( 'ClinicalHistoryOfDonor'=> array( 'className' => 'ClinicalHistoryOfDonor', 'foreignKey' => 'clinical_history_of_receptor_id' )); R4:. Un posible receptor puede ser asociado al menos a un trasplante de donante vivo.. Para la implementación de esta regla en el modelo trasplante de donante vivo se inserta la siguiente relación: var $belongsTo = array( 'ClinicalHistoryOfReceptor' => array( 'className' => 'ClinicalHistoryOfReceptor', 'foreignKey' => 'clinical_history_of_receptor_id', )); Pág.27.

(36) Capítulo II: “Adaptabilidad del sistema de información”. En el modelo receptor (clinical_history_of_receptor) la relación inversa se representaría como sigue: var $hasMany = array( 'TrasplantOfDonorAlife' => array( 'className' => 'TrasplantOfDonorAlife', 'foreignKey' => 'clinical_history_of_receptor_id', )); R5:. Todo análisis realizado puede ser asociado a un paciente.. Esta regla establece la relación existente entre el paciente y los análisis realizados a este. Su implementación se realiza en el modelo análisis realizado insertando la siguiente relación: var $belongsTo = array( 'ClinicalHistory' => array( 'className' => 'ClinicalHistory', 'foreignKey' => 'clinical_history_id', )); En el modelo historia clínica la relación inversa se representaría como sigue: var $hasMany = array( 'AnalisyRealize' => array( 'className' => 'AnalisyRealize', 'foreignKey' => 'clinical_history_id', )); . Reglas de derivación:. En casos sencillos pueden implementarse en la capa de usuario debido a que no se requiere información adicional y en general toda la información de un registro viaja al mismo tiempo al cliente. En casos complejos es recomendable implementarlas en la capa servidor. En la aplicación al tratarse de una fórmula en donde sus valores no precisan de interacción entre varias tablas puesto que es bastante sencilla se implementa. Pág.28.