SOFTWARE PARA LA GESTIÓN DE CONTROL DE HISTORIAS CLÍNICAS ODONTOLÓGICAS

REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD RAFAEL URDANETA FACULTAD DE INGENIERIA ESCUELA DE COMPUTACIÓN SOFTWARE PARA LA GESTIÓN DE CONTROL DE HISTORIAS CLÍNICAS ODONTOLÓGICAS Trabajo Especial de Grado para optar al Título de Ingeniero en Computación Realizado por: Br. Duque Persad, Karla Patricia C.I.: 18.394.188 Tutor Académico: Prof. Erick Ramos MARACAIBO,ENERO 2009

SOFTWARE PARA LA GESTIÓN DE CONTROL DE HISTORIAS CLÍNICAS ODONTOLÓGICAS

AGRADECIMIENTOS A Dios brindarme la salud e inteligencia para culminar este proyecto, que consolida una de mis metas. Al Ingeniero Erik Ramos por aceptar el compromiso de ser el tutor académico, por su apoyo en todo momento, por toda la orientación que me proporciono hasta lograr mi meta. A mi mamá, novio, tíos, primos, por estar siempre presentes en todos aquellos momentos difíciles con que nos pone a prueba la vida, gracias por su apoyo incondicional y sus orientaciones. A Efraín, por ese gran apoyo, por la compañía, por el estar conmigo cuando lo necesitaba, por darme ánimos para continuar

DEDICATORIA A Dios y a La Virgen, por iluminarme y ser mis mejores guías. A mi Mamá, por estar siempre ahí conmigo, con mis preocupaciones, temores, alegrías y triunfos y darme siempre el apoyo, la comprensión, y el estimulo para poder lograr las metas que me trazo en la vida A toda mi familia, por el apoyo que me brindaron, porque de una u otra manera también me ayudaron a realizar este sueño. A ti Cesar, por apoyarme, entenderme, escucharme y decirme siempre lo que necesitaba escuchar para seguir con ánimo y así lograr esta primera meta en mi vida. Te Amo.

Duque P, Karla P, SOFTWARE PARA LA GESTIÓN DE CONTROL DE HISTORIAS CLÍNICAS ODONTOLÓGICAS Universidad Rafael Urdaneta. Facultad de Ingeniería. Escuela de Computación. Trabajo especial de grado. Maracaibo, 2008. RESUMEN La presente investigación, tuvo como propósito fundamental el desarrollo de software para la gestión de control de historias clínicas odontológicas, con el fin de tener bien resguardada la información y manejarla de mejor manera, con la finalidad de poder satisfacer al usuario en las necesidades de consultar, modificar e ingresar los datos de insumo, proceso y resultado. Utilizo como población a los odontólogos de la Torre de Consultorios Amado, del municipio Maracaibo, Edo. Zulia. Esta investigación se consideró del tipo descriptiva, aplicada y proyecto factible debido a que desarrolla un software permitiendo con esto resolver un problema. En cuanto al diseño de investigación, se considera no experimental y transversal descriptivo, por cuanto se recoge la información en un tiempo y momento único; en la investigación se utilizó como técnicas de recolección de datos la observación directa y la encuesta. La metodología utilizada para el desarrollo del sistema es la de Montilva (2000), el modelo de procesos Watch, la cual consta de ocho fases de las cuales solo se utilizaron seis de ellas: análisis y dominio de la aplicación, descubrimiento de requerimiento, especificación de requerimientos, diseño del sistema, implantación del sistema y prueba del sistema, debido a que dos de las mismas, diseño de componentes y entrega del sistema, no se adaptaban al contexto de la investigación. El lenguaje de programación utilizado fue Python y como manejador de base de datos SQLite. Los objetivos propuestos al inicio de la investigación fueron cumplidos y se obtuvo como conclusión que el sistema de información automatizado facilita y agiliza de una manera eficaz la gestión de control de historias odontológicas. Palabras Claves: Software, Gestión de Control, Historias

Indice General ÍNDICE GENERAL DEDICATORIA --------------------------------------------------------------- III AGRADECIMIENTOS ------------------------------------------------------ IV RESUMEN --------------------------------------------------------------------- V INTRODUCCIÓN ----------------------------------------------------------- VII CAPITULO I. PLANTEAMIENTO Y FORMULACIÓN DEL PROBLEMA -------- 02 OBJETIVOS DE LA INVESTIGACIÓN --------------------------------- 07 Objetivo General ------------------------------------------------------ 07 Objetivos Específicos ------------------------------------------------- 08 JUSTIFICACIÓN E IMPORTANCIA ------------------------------------- 08 DELIMITACIÓN ------------------------------------------------------------- 10 CAPITULO II. ANTECENDENTES DE LA INVESTIGACION ------------------------ 12 FUNDAMENTOS TEORICOS --------------------------------------------- 14 CAPITULO III. MARCO METODOLÓGICO ----------------------------------------------- 37 TIPO DE INVESTIGACIÓN ----------------------------------------------- 37 DISEÑO DE LA INVESTIGACIÓN -------------------------------------- 38

Indice General POBLACIÓN ----------------------------------------------------------------- 38 TÉCNICA DE RECOLECCIÓN DE DATOS ---------------------------- 39 PROCEDIMIENTO DE LA INVESTIGACIÓN ------------------------- 42 METODOLOGÍA ---------------------------------------------------------- 43 CAPITULO IV. ANÁLISIS Y DISCUSIÓN DE RESULTADOS ------------------------- 45 CAPITULO V. MANUAL DEL SISTEMA ------------------------------------------------- 60 CONCLUSIONES ---------------------------------------------------------- 69 RECOMENDACIONES --------------------------------------------------- 72 BIBLIOGRAFÍA ----------------------------------------------------------- 74 ANEXOS -------------------------------------------------------------------- 76

CAPÍTULO I EL PROBLEMA 1.1. PLANTEAMIENTO Y FORMULACIÓN DEL PROBLEMA Los cambios gestados durante el siglo XX en el ámbito de la informática y la comunicación fueron verdaderamente sorprendentes por el impacto generado en los distintos ámbitos de la sociedad, profundizándose estos cada vez más en este tercer milenio donde la tecnología de la información abre puertas y vislumbra un horizonte distinto y sorpresivo ante los beneficios prácticos que le ofrece al hombre para el desarrollo de todas sus actividades. Es así como la tecnología brinda una serie de ventajas competitivas que permiten el desarrollo de la globalización, modernización, e integración donde todos los elementos a nivel internacional, nacional, regional y local, pueden coordinarse para brindar procesos integrados y efectivos en los sectores económicos sociales, culturales y políticos, facilitándole al hombre su mundo y el desenvolvimiento de las operaciones que posiblemente en tiempos pasados eras complejos y en la actualidad son vistos como aspectos sencillos y fáciles de manejar. En ese ámbito de integración, los sistemas de información y los software surgieron como herramientas precisas para condicionar datos importantes no solo para un ambiente 2

si no para generar de forma colectiva conocimientos que pueden ser utilizados en un punto especifico del mundo, de igual manera que en el mas pequeño y recóndito espacio de la tierra, de allí que los niveles de eficiencia y efectividad a través de la internet han progresado desde el punto de vista de rentabilidad y competitividad contribuyendo con el desarrollo personal y organizacional. Es por ello que los sistemas de información según lo plantean Laudon y Laudon (2004) permiten en la actualidad que las organizaciones accesen a los datos ampliando su alcance hasta lugares muy retirados ofreciendo productos y servicios nuevos reforzando empleos y flujos de trabajos que quizás puedan cambiar profundamente la manera de conducir sus negocios, mejorando los procesos técnicos y operativos al integrar cada uno de los elementos requeridos dentro del sistema, siendo según el estándar 729 del IEEE, el software es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados que forman parte de las operaciones de un sistema de computación Al respecto, Chiavenato (2002) plantea que un sistema es un conjunto de elementos interdependientes e interactuantes, un grupo de unidades combinadas que forman un todo organizado y cuyo resultado es mayor que el resultado de las unidades que funcionan independientemente, formando un todo complejo o unitario. Explica el autor que el concepto no es una tecnología en si, si no una resultante de ella, que permite una visión 3

comprensiva, amplia y gestáltica de un conjunto complejo dándole una configuración total. Este concepto determina que todo aquello que funcione de manera articulada con otros elementos va a conformar un sistema donde es tan importante el insumo como el proceso y los resultados, por lo cual, al considerarse tales elementos el procesamiento de los datos va a implicar que la información recibida sea más valiosa y fidedigna al tomar en cuenta cada uno de los elementos del mismo. Es así como Ivancevich y otros (1998) manifiestan que hoy en día casi toda la información se precisa mediante los computadores y por ello, las empresas están utilizándolos para convertir datos en información valiosa para el desarrollo de sus operaciones y como antes se mencionó, optimizan la gestión al combinar la informática con procedimientos regulares y organizados para suministrar a los gerentes de manera oportuna, la información necesaria para la toma de decisiones y el control. En tal sentido, Venezuela en su deseo de desarrollo y crecimiento ha incorporado en sus pequeñas, medianas y grandes empresas, sistemas de información y software que optimizan las operaciones tanto administrativas como operativas siguiendo el esquema de accesar datos para que el hardware conjuntamente con el software incorporado en el computador realice las actividades de organización de manera que el trabajo sea más fácil y organizado. Cabe destacar que pequeñas mediana y grandes empresas poseen software con los cuales pueden organizar información diversa y los resultados obtenidos desde el punto de 4

vista de procesos y productos han sido verdaderamente efectivos, indicando las bondades que propician tanto a los gerentes o dueños de empresas, como también, a los empleados, clientes, proveedores, competidores y entorno en general, lo cual indica que en este siglo XXI todas las organizaciones no importa su tamaño o rubro, deben contar con estos programas. En otro orden de ideas, es de hacer notar que los médicos, odontólogos, veterinarios, nutricionistas, bioanalistas, entre otros profesionales de la salud, trabajan directamente con clientes que deben ser tratados con el respeto que les corresponde de manera individual, y por ello en la consulta se lleva una historia médica del caso que caracteriza al paciente, tomando en cuenta sus particularidades, de manera que al ser atendidos se lleve un control del pasado, presente para poder el profesional asumir decisiones al respecto de la situación de cada uno de ellos. Tal es el caso de los odontólogos quienes como profesionales de la salud atienden en su consultorio a una cantidad de pacientes, cada uno de ellos con problemas más o menos similares pero particulares en cuanto a las condiciones que presentan, siendo necesario desde el primer día hacer triaje para conocer cuáles son las características que manifiestan y poder seguir tratamiento con el propósito de generar los cambios necesarios en el paciente, de allí que se lleve una historia médica que informa acerca de todas las eventualidades que haya tenido, sirviéndole al doctor de guía para saber cuáles decisiones debe asumir. 5

Para ello se lleva una historia médica por paciente que se archivan en carpetas y deben ser consultadas en cada visita del paciente, ocasionando algunas veces pérdida de tiempo al buscarla, escribirla y llevar el proceso del tratamiento lo cual afecta si se toma en cuenta el tiempo que se debe disponer para cada caso. Es bien cierto que este proceso lo ha llevado a cabo el odontólogo con la ayuda de asistentes o enfermeras (os) siendo verdaderamente efectivo, pero si se toma en cuenta la necesidad de adecuar los procesos a los avances tecnológicos se considera necesario asumir el cambio incorporando sistemas de información que no solo pondrían a la empresa en la palestra en cuanto a los procesos administrativos, organizacionales y tecnológicos, si no que dentro del mercado le permitiría competir por el servicio de calidad he innovación al facilitar las operaciones dentro de la misma. Como situación problemática, los odontólogos comparten la inquietud de tener dificultad para accesar con facilidad a las historias médicas odontológicas por falta de organización del material y por la gran cantidad de historias que ocupan espacio el cual es útil para otras cosas, generando descontrol por parte de la asistente y el mismo odontólogo, necesitándose paciencia y mayor tiempo para la búsqueda de cada carpeta. Esto pudiera ser producto de la falta de preparación organizacional y de control, tanto del odontólogo como asistente o enfermera (ro) para llevar la parte administrativa así como también, porque a veces por los altos costos le es imposible contar con este personal, además que posiblemente comparta el consultorio con otros colegas, limitando 6

el espacio para archivar las historias, lo cual trae como consecuencia desorganización en las historias, descuido, olvidos y por ende trabajos poco satisfactorios; de allí que se dé pérdida de tiempo de dinero y de esfuerzo debiendo generar medidas para disminuir este tipo de problemas. En ese marco de ideas, tomando en cuenta que han surgido diferentes sistemas de aplicación es interesante diseñar y ofrecer un software para registrar, almacenar y organizar las historias médicas para la gestión de control en los consultorios odontológicos tomando en cuenta los criterios o parámetros requeridos en cuanto a las características del paciente y de las actividades que realiza el odontólogo, lo cual traería como consecuencia, facilitar los procesos desarrollados teniendo la oportunidad de brindar un trabajo de mayor calidad y efectividad. Con base en lo antes planteado surge la siguiente interrogante Qué aspectos considerar para diseñar software para la gestión de control de historias clínicas odontológicas? OBJETIVOS DE LA INVESTIGACIÓN 1.1.1. OBJETIVO GENERAL Diseñar un software para la gestión de control de las historias clínicas odontológicas. 1.1.2. OBJETIVOS ESPECÍFICOS 7

Identificar la situación actual de la gestión de control de historias clínicas odontológicas. Analizar los elementos para el desarrollo del software de gestión de control Diseñar el software que permita la gestión de control de las historias clínicas odontológicas. Probar la efectividad del software de gestión de control de historias clínicas odontológicas. 1.2. JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN La presente investigación tiene como objetivo desarrollar un software para la gestión de control de historias clínicas odontológicas, considerando que por ello tiene su relevancia social al brindar alternativas para el trabajo que realiza administrativamente el odontólogo en su consultorio, permitiéndole llevar un proceso organizado en cuanto a la información necesaria de cada uno de sus pacientes con el propósito de brindarle la atención, tomando en cuenta las características de rapidez, objetividad científica e integración. En cuanto a la relevancia práctica, la presente investigación pretende proponer un software para la gestión de control que sirve para todos los odontólogos que laboran en clínicas grandes medianas o pequeñas, por cuanto el programa ofrecido generaliza los datos que pueden ser utilizados según las características de cada uno de estos 8

consultorios, respetando las individualidades de los pacientes que asisten a las consultas, resaltando que es práctico el producto brindado por la investigadora al permitirle al profesional distribuir su tiempo adecuadamente en cuanto a la parte administrativa, de atención y la odontológica, trayendo como resultado que el paciente se sienta satisfecho del servicio obtenido, además, estará consciente y seguro de la información que su doctor registra sobre sus casos. La relevancia científica y teórica del estudio consiste en haber partido de un hecho observado y tomando en cuenta la realidad, se desarrolló el software para la gestión de control de historias clínicas odontológicas, con base en la documentación teórica y técnica aportada por los expertos en sistemas, adaptándolo a la situación que se pretende optimizar para lo cual, fue preciso probar el programa y comprobar su efectividad de manera que los resultados y conclusiones den respuesta a la problemática planteada. Desde el punto de vista metodológico el estudio se desarrollo tomando en cuenta el proceso de una investigación positivista, proyecto factible al partir de hechos objetivos y proponer alternativas de solución que son posibles de ejecutar en el ambiente donde se diagnosticó la situación problema que en este caso, es en los consultorios odontológicos de municipio Maracaibo. Además se considera que deja un aporte a futuros investigadores primero porque se elaborara un cuestionario donde se pretende describir las características, los elementos, los pasos y la metodología a seguir del software para la gestión de control de historias clínicas odontológicas, que puede ser utilizado de manera 9

segura al ser válido y confiable. Como segundo aspecto el estudio con sus resultados y conclusiones propicia la aplicabilidad del programa desarrollado generándole los cambios necesarios que se le pudieran incorporar si así lo requiriera de acuerdo con las fallas o debilidades que pudiera presentar. Por último, se considera su relevancia contemporánea no ciertamente por lo novedoso porque ya otros investigadores han desarrollado software, si no porque se adecua a las exigencias que la sociedad del siglo XXI solicita a las empresas sea cual sea su rubro en cuanto a la gestión automatizada que se debe implementar en sus procesos tomando en cuenta las bondades que los avances científicos, tecnológicos y de la información le ofrece al hombre para optimizar su calidad de vida tanto personal como profesional y ocupacional. 1.3. DELIMITACIÓN La presente investigación se enmarca en el área de la ingeniería de computación considerando el desarrollo de un software para la gestión de control de historias clínicas odontológicas, tomando en cuenta como unidad de información a odontólogos y asistentes de consultorios públicos y privados del municipio Maracaibo. El estudio se desarrolla entre mayo y diciembre 2008. 10

CAPÍTULO II. MARCO TEÓRICO 2.1. ANTECEDENTES DE LA INVESTIGACIÓN En relación con la automatización de procesos se han realizado diversos estudios, exponiéndose a continuación algunos de ellos que se consideran pertenecientes con el estudio A, Cáceres (2007) realizó un estudio titulado Sistema de Información Web para el Control de Historias Clínicas, el objetivo del estudio fue resguardar la información y satisfacer al usuario en las necesidades de consultar, ingresar, modificar y eliminar los datos. La investigación fue de tipo descriptiva y el diseño de la investigación fue de tipo No Experimental, es decir, se realizo sin manipular deliberadamente variables. La técnica de recolección de datos utilizada fue la observación directa. La Metodología utilizada para el desarrollo del sistema fue la de Montilva (2000), donde se utilizaron las siguientes fases: Análisis del Dominio de Aplicación, Descubrimiento de Requerimientos, Especificación de Requerimientos, Diseño del Sistema, Implementación de Interfaz Web y por ultimo Pruebas al Sistema. Para el desarrollo de la aplicación se utilizo Windows XP, Macromedia Dreamweaver 8, PHP, Apache y como manejador de base de datos My SQL 12

Los resultados obtenidos abarcan los objetivos planteados al inicio de la investigación, esto permitió aumentar la confiabilidad del usuario por los datos guardados y consultados en la base de datos. Así mismo, Giovanna (2001) realizó un estudio titulado: Sistema de Información Automatizado para el control de Procesos Administrativos caso: Coordinación de investigación de la facultad de ingeniería de la URBE. Para esta investigación se utilizaron técnicas de de observación directa, documental y entrevistas. El diseño de la investigación fue aplicada y de campo. La metodología utilizada fue la establecida por Senn (1996) la cual consta de 6 fases: investigación preliminar, determinación de requerimientos, diseño del sistema, desarrollo del software, prueba e implantación del sistema. En el desarrollo físico del sistema se seleccionó la herramienta de programación Visual Basic 6.0 y la de aplicación de manejo de sistema de base de datos Access 2000. Los objetivos planteados al principio de la investigación fueron cubiertos, los resultados de la investigación facilitaron el control de procesos administrativos. De la misma forma, Hernández y Rincón (2002) desarrollaron un Sistema de información para el control de acceso y registro de personal a las empresas. La fundamentación teórica del proyecto consistió en una amplia documentación referente a las teorías de sistemas de programación y sistemas de control. La metodología utilizada fue la planteada por Laudon y Laudon (2000) y consistió en la aplicación de las siguientes etapas: definición del proyecto, análisis del sistema, diseño, programación y prueba. 13

El lenguaje utilizado fue Visual Basic 6.0, Flash 5.0, y la base de datos se creó bajo Microsoft Access 2000. La técnica de recolección de datos fue la observación directa, a través de la entrevista informal sin formato definido. Como resultado final de la investigación, se determinó que el sistema es aceptable para controlar el acceso y llevar el registro de personal de aquellas empresas interesadas en adquirir el mismo. 2.2. FUNDAMENTACIÓN TEORICA Toda persona para poder realizar una investigación debe apoyarse en conocimientos teóricos. Para un mejor entendimiento del significado de un Software y todo en cuanto a él se refiere o relacione con este medio, se efectuó una búsqueda de los conceptos relevantes en esta área tomando en cuenta las teorías de varios autores. 2.2.1. SOFTWARE Según Montilva, J (2004) es el equipamiento lógico de un computador digital, comprende el conjunto de los componentes lógicos necesarios para hacer posible la realización de una tarea específica. En la actualidad, el software es la tecnología individual más importante en el ámbito mundial. A medida que la importancia del software ha crecido, se ha intentado de manera continua desarrollar tecnologías que hagan más fácil, más rápida y menos cara la construcción y el mantenimiento de programas de computación de alta calidad. 14

Para Pressman (2005), el papel del software ha experimentado un cambio significativo en un periodo de un poco mayor a 50 años. Las mejorías sustanciales en el desempeño del hardware, los cambios profundos en las arquitecturas de cómputo, los enormes incrementos en las capacidades de memoria y almacenamiento, y la amplia variedad de opciones de salida y entrada han propiciado el surgimiento de sistemas más elaborados y complejos basados en computadoras. 2.2.2. CARACTERISTICAS DEL SOFTWARE Las características esenciales del software según Pressman (2005), son las siguientes: El software se desarrolla o construye; no se manufactura en el sentido clásico. A pesar de que existen similitudes entre el desarrollo del software y la manufactura del hardware, las dos actividades son diferentes en lo fundamental. En ambas la alta calidad se alcanza por medio del buen diseño, pero la fase de manufactura del hardware puede incluir problemas de calidad inexistentes en el software. Ambas actividades dependen las personas, pero la relación de la gente utilizada y el trabajo realizado es diferente por completo. Ambas actividades requieren la construcción de un producto, pero los enfoques son diferentes. Los costos del software se concentran en la ingeniería. Esto significa que los proyectos de software no se pueden manejar como si fueran proyectos de manufactura. El Software no se desgasta. El software es inmune a los males ambientales que desgasten el hardware. Por lo tanto la curva de tasas de fallas para el software debería tener la forma de la curva idealizada. Los defectos sin descubrir causan tasas de fallas 15

altas en las primeras etapas de vida de un programa. Sin embargo, los errores se corrigen y la curva se aplana: el software no se desgasta, pero si se deteriora. Un aspecto del desgaste ilustra la diferencia entre el hardware y el software. Cuando un componente del hardware se desgasta se sustituye con un repuesto. Pero en el software no existen repuestos. Cualquier falla del software implica un error en el diseño o el proceso mediante el cual se pasó del diseño al código máquina ejecutable. Por lo tanto, el mantenimiento del software implica de manera considerable una complejidad mayor que el del hardware. A pesar de que la industria tiene una tendencia hacia la construcción por componentes, la mayoría del software aún se construye a la medida. Considérese la forma en que se diseña y construye un hardware de control para un producto de cómputo. El ingeniero de diseño dibuja un esquema simple del sistema de circuitos digital, realiza algunos análisis fundamentales para asegurarse de que el diseño realizará las funciones apropiadas y después busca en los catálogos de componentes digitales cada circuito integrado de acuerdo con un número de parte, una función definida y validada, una interfaz bien definida y un conjunto estandarizado de directrices de integración. Una vez seleccionado cada componente, puede solicitársele para después ensamblarlo. Cuando una disciplina de ingeniería evoluciona se crea una colección de diseños estándar de componentes. Los tornillos y los circuitos integrados son sólo dos ejemplos de los miles de componentes estándar que utilizan los ingenieros mecánicos y eléctricos al diseñar sistemas nuevos. Los componentes reutilizables se han creado para que el ingeniero se pueda concentrar en los elementos que en realidad son innovadores en el diseño; es decir, en las partes que representan algo nuevo. En el mundo del hardware, la 16

reutilización de componentes es una parte natural del proceso de ingeniería. En el ámbito del software, dicha actividad apenas se ha comenzado a extender. Un componente de software se debe diseñar e implementar de forma que pueda utilizarse en muchos programas diferentes. Los componentes reutilizables modernos encapsulan tanto los datos como el proceso que se aplica a éstos, lo que permite al ingeniero de software crear aplicaciones nuevas a partir de partes reutilizables. Por ejemplo, las interfaces actuales con el usuario se construyen con componentes reutilizables que permiten la creación de ventanas gráficas, menús desplegables y una amplia variedad de mecanismos de interacción. Las estructuras de datos y los detalles de procesamiento requeridos para construir la interfaz están contenidos en una librería de componentes reutilizables para la construcción de la interfaz. 2.2.3. CATEGORIAS DEL SOFTWARE En la actualidad existen siete grandes categorías del software de computadora que presentan retos continuos para los ingenieros de software. Pressman (2005) las clasifica de la siguiente forma. Software de sistemas. El software de sistemas es una colección de programas escritos para servir a otros programas. Algunos programas de sistemas (como los compiladores, editores y utilerías para la administración de archivos) procesan estructuras de información complejas pero determinadas. Otras aplicaciones de sistemas (por ejemplo, componentes del sistema operativo, controladores, software de red, procesadores para telecomunicaciones) procesan datos indeterminados. En cada caso, el área de software de sistemas se caracteriza por una interacción muy intensa con el hardware de la 17

computadora; utilización por múltiples usuarios; operación concurrente que requiere la gestión de itinerarios, de compartición de recursos, y de procesos sofisticados; estructuras de datos complejas y múltiples interfaces externas. Software de aplicación. El software de aplicación consiste en programas independientes que resuelven una necesidad de negocios específica. Las aplicaciones en esta área procesan datos empresariales o técnicos de forma que facilitan las operaciones de negocios o la toma de decisiones técnicas o de gestión. Además del procesamiento de datos convencional, el software de aplicación se utiliza para controlar las funciones de negocios en tiempo real (por ejemplo, el procesamiento de transacciones en los puntos de venta y el control de procesos de manufactura en tiempo real.) Software científico y de ingeniería. El software científico y de ingeniería, que se caracterizaba por algoritmos devoradores de números, abarca desde la astronomía hasta la vulcanología, desde el análisis de la tensión automotriz hasta la dinámica orbital de los transbordadores espaciales, y desde la biología molecular hasta la manufactura automatizada. Sin embargo, las aplicaciones modernas dentro del área científica y de ingeniería se alejan en la actualidad de los algoritmos numéricos convencionales. El diseño asistido por computadora, la simulación de sistemas y otras aplicaciones interactivas han comenzado a tomar características de software en tiempo real e incluso de software de sistemas. Software empotrado. El software empotrado reside dentro de la memoria de sólo lectura del sistema y con él se implementan y controlan características y funciones para el usuario final y el sistema mismo. El software incrustado puede desempeñar funciones limitadas y curiosas (como el control del teclado de un horno de microondas) o proporcionar capacidades de control y funcionamiento significativas (por ejemplo, las 18

funciones digitales de un automóvil, como el control de combustible, el despliegue de datos en el tablero, los sistemas de frenado, etcétera). Software de línea de productos. El software de línea de productos, diseñado para proporcionar una capacidad específica y la utilización de muchos clientes diferentes, se puede enfocar en un nicho de mercado limitado (como en los productos para el control de inventarios) o dirigirse hacia los mercados masivos (por ejemplo, aplicaciones de procesadores de palabras, hojas de cálculo, gráficas por computadora, multimedia, entretenimiento, manejo de bases de datos, administración de personal y finanzas en los negocios). Aplicaciones basadas en Web. Las WebApps engloban un espectro amplio de aplicaciones. En su forma más simple, las WebApps son apenas un poco más que un conjunto de archivos de hipertexto ligados que presenta información mediante texto y algunas gráficas. Sin embargo, a medida que el comercio electrónico y las aplicaciones B2B adquieren mayor importancia, las WebApps evolucionan hacia ambientes computacionales sofisticados que no sólo proporcionan características, funciones de cómputo y contenidos independientes al usuario final, sino que están integradas con bases de datos corporativas y aplicaciones de negocios. Software de inteligencia artificial. Este software utiliza algoritmos no numéricos en la resolución de problemas complejos que es imposible abordar por medio de un análisis directo. Las aplicaciones dentro de esta área incluyen la robótica, los sistemas expertos, el reconocimiento de patrones (imagen y voz), las redes neuronales artificiales, la comprobación de teoremas y los juegos en computadora. 19

2.2.4. MARCO DE TRABAJO Cuando se trabaja para construir un producto o sistema es importante seguir una serie de pasos predecibles: una especie de mapa de carretera que ayude a crear un resultado de alta calidad y a tiempo; aunque el proceso que se adopte depende del software que se está construyendo. En este sentido Pressman. R (2005), nos dice que, un marco de trabajo establece las bases para un proceso de software completo al identificar un número pequeño de actividades del marco de trabajo aplicable a todos los proyectos de software, sin importar su tamaño o su complejidad. El siguiente marco de trabajo se puede aplicar en la inmensa mayoría de los trabajos de software: Comunicación. Esta actividad del marco de trabajo implica una intensa colaboración y comunicación con los clientes; además, abarca la investigación de requisitos y otras actividades relacionadas. Planeación. Esta actividad establece un plan para el trabajo de la ingeniería del software. Describe las tareas técnicas que deben realizarse, los riesgos probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un programa de trabajo. Modelado. Esta actividad abarca la creación de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseño que logrará satisfacerlos. 20

Construcción. Esta actividad combina la generación del código (ya sea manual o automatizado) y la realización de pruebas necesarias para descubrir errores en el código. Despliegue. El software (como una entidad completa o un incremento completado de manera parcial) se entrega al cliente, quien evalúa el producto recibido proporciona información basada en su evaluación. Estas cinco actividades genéricas del marco de trabajo son útiles durante el desarrollo de programas pequeños, la creación de grandes aplicaciones en la red, y en la ingeniería de sistemas basados en computadoras grandes y complejas. Los detalles é proceso del software serán muy diferentes en cada caso, pero las actividades dentro del marco permanecerán iguales. 2.2.5. MODELOS PRESCRIPTIVOS DE PROCESO Para cada una las fases o pasos del marco de trabajo, existen sub-etapas. Los modelos prescriptivos de proceso utilizados para el desarrollo definen el orden para las tareas o actividades involucradas, también definen la coordinación entre ellas, enlace y realimentación entre las mencionadas etapas. Los modelos prescriptivos no son perfectos, pero proporcionan una guía útil para el desarrollo de software de alta calidad. Pressman, R. (2005) señala que, se les llama prescriptivos porque prescriben un conjunto de elementos del proceso: actividades del marco de trabajo, acciones de ingeniería del software, tareas, productos del trabajo, aseguramiento de la calidad, y mecanismos de control del cambio para cada proyecto. Cada modelo de proceso prescribe 21

también un flujo de trabajo; esto es, la forma en la cual los elementos del proceso se interrelacionan entre sí. Todos los modelos de proceso del software se ajustan a las actividades genéricas del marco de trabajo, pero cada uno aplica una importancia diferente a estas actividades y define un flujo de trabajo que invoca cada actividad del marco de trabajo (así como acciones y tareas de la ingeniería del software) de una manera diferente. 2.2.5.1. Modelo de Cascada, algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. El modelo en cascada es el paradigma más antiguo; sin embargo, en las décadas pasadas, las críticas a este modelo de proceso han ocasionado que aún sus más fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada están: 1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa. 2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 22

3. El cliente debe tener paciencia. Una versión que funcione de los programas estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se detecta antes de la revisión del programa. En un análisis interesante de proyectos reales, Bradac (1994) concluyo que la naturaleza lineal del modelo en cascada conduce a estados de bloqueo en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser más común al principio y al final del proceso secuencial. En la actualidad, el trabajo del software está acelerado y sujeto a una cadena infinita de cambios (de características, funciones y contenido de la información). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en situaciones donde los requerimientos están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal. 2.2.5.2. Modelos de Proceso Incremental, En muchas situaciones los requisitos iníciales del software están bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar de manera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseñado para producir el software en forma incremental. Modelo Incremental, este modelo combina elementos del modelo en cascada aplicado en forma iterativa. El modelo incremental aplica secuencias lineales de manera 23

escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce incrementos del software. A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir se incorporan los requisitos básicos, pero muchas características suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluación detallada). Como resultado de la evaluación se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento mientras no se haya elaborado el producto completo. El modelo de proceso incremental, al igual que la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. El desarrollo incremental es útil sobre todo cuando el personal necesario para una implementación completa no está disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se requiere) más personal para implementar el incremento siguiente. Además, los incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande podría requerir la disponibilidad de un hardware nuevo que está en desarrollo y cuya fecha de entrega es incierta. Sería posible planear los primeros incrementos de forma 24

que se evite el uso de este hardware, lo que permitiría la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados. Modelo DRA, el desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a alta velocidad del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción basado en componentes. Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un sistema completamente funcional dentro de un periodo muy corto (por ejemplo, de 60 a 90 días). Como otros modelos de proceso, el enfoque DRA cumple con las actividades genéricas del marco de trabajo que ya se han presentado. La comunicación trabaja para entender el problema de negocios y las características de información que debe incluir el software. La planeación es esencial porque varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases modelado de negocios, modelado de datos y modelado del proceso y establece representaciones del diseño que sirven como base para la actividad de construcción del modelo DRA. La construcción resalta el empleo de componentes de software existente y la aplicación de la generación automática de código. Por último, el despliegue establece una base para las iteraciones subsecuentes, si éstas son necesarias. Como todos los modelos de proceso, el enfoque DRA tiene inconvenientes: 1) para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear el número correcto de equipos DRA; 2) si los desarrolladores y clientes no se comprometen con las actividades rápidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos de DRA fallarán; 3) si un sistema no se puede 25

modelar en forma apropiada, la construcción de los componentes necesarios para el DRA será problemática; 4) si el alto rendimiento es un aspecto importante, y se alcanzará al convertir interfaces en componentes del sistema, el enfoque DRA podría no funcionar; y 5) el DRA sería inapropiado cuando los riesgos técnicos son altos. 2.2.5.3. Modelos de Procesos Evolutivos El software, como todos los sistemas complejos, evoluciona con el tiempo. Los requisitos de los negocios y productos a menudo cambian conforme se realiza el desarrollo; por lo tanto, la ruta lineal que conduce a un producto final no será real; las estrictas fechas tope del mercado imposibilitan la conclusión de un producto completo, por lo que se debe presentar una versión limitada para liberar la presión competitiva y de negocios; se tiene claro un conjunto de requisitos del producto o sistema esencial, pero todavía se deben definir los detalles de las extensiones del producto o sistemas. En éstas y otras situaciones similares, los ingenieros de software necesitan un modelo de proceso que haya sido diseñado de manera explícita para incluir un producto que evolucione con el tiempo. Construcción de Prototipos, a menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. En éstas, y en muchas otras situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. A pesar de que la construcción de prototipos se puede utilizar como un modelo de proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos de proceso. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al 26

ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. El Modelo en Espiral, Propuesto originalmente por Boehm en 1976, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal y secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado. El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas, cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado conjunto de tareas que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección. Este método está basado en dos importantes principios: 1. la práctica de diseño profesional es caracterizar en términos de conocer, actuar en situaciones, conversación con la situación y reflexión en acción. Hay un distinto medio de proceso - orientación en esta aproximación al diseño. Es raro que el diseñador tenga el diseño en su cabeza por adelantado y que después lo transcriba. Gran parte del tiempo del diseñador está inmiscuido en una progresiva relación con su entorno. Una buena metáfora para describirlo es "la conversación con el 27

material", como un escultor, quien está ocupado en una conversación con el medio. El escultor modela arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser. 2. la necesidad para diseñadores de tomar la práctica de trabajo seriamente, de supervisar las formas en las que el trabajo se está haciendo, en el sentido de una solución abierta y desplegada para aumentar la complejidad de una situación que el diseñador solo entiende parcialmente. El hecho por el cual se está tratando con "actores humanos". Los sistemas necesitan tratar o estar en contacto con las preocupaciones del usuario. Es definitiva, el reconocimiento de que el trabajo es fundamentalmente social, envolviendo cooperación y comunicación. Modelo de desarrollo Concurrente, Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso de software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente. Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los 28

requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo. Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes. En algunos proyectos, múltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras que se está haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5. En todos estos casos, diversas actividades están ocurriendo simultáneamente. Eligiendo seguir un proyecto usando técnicas de modelación concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto Por otra parte, Montilva (2000), describe las metodologías para satisfacer los requerimientos del Sistema de Información Web, que se nombraran a continuación, según el Modelo de Procesos WATCH, comprende 8 fases de desarrollo. Estas fases son ejecutadas secuencialmente en el sentido de las agujas del reloj, comenzando por la fase de análisis del dominio y finalizando en la fase de entrega del sistema. Sin embargo, existe una fuerte iteración entre las fases, ya que de cualquier fase es siempre posible regresar a la anterior, con el fin de: 29

a. Modificar un producto intermedio o final tal como, un requerimiento, o una especificación de diseño, un documento, un componente o un subsistema. b. Reparar un error detectado en un producto intermedio o final. c. Revisar y elaborar una tarea o actividad de la fase previa Fase 1. Análisis del dominio de Aplicación. Esta fase identifica y describe en detalle el ambiente del sistema, llamado dominio de aplicación, en el cual el software operará. El objetivo de esta fase es que el grupo de desarrollo adquiera un conocimiento adecuado del dominio de aplicación (el contexto del sistema). El producto de esta fase es el modelo del dominio de aplicación. Esta fase comienza por definir el dominio de aplicación, definiendo los límites y objetivos del sistema, luego, se identifican los procesos y actores del dominio, los cuales deben ser modelados posteriormente. Fase 2. Descubrimiento de Requerimientos. El objetivo de esta fase es descubrir y definir informalmente los requerimientos de los usuarios del sistema. Los principales productos de esta fase son el documento de definición de requerimientos (DDR) y los prototipos de la interfaz Usuario / Sistema (U/S). Fase 3. Especificación de requerimientos. Esta fase tiene como objetivo expresar los requerimientos de los usuarios de una manera formal o técnica que pueda ser entendida, sin ambigüedad, por los diseñadores del sistema. La estructura y comportamiento del sistema es especificada usando tres modelos: a. Funcional: Se construye utilizando el diagrama de casos de uso de UML. b. Estructural: Se representa a través del diagrama de clases de UML. c. Dinámico: Se representa a través del diagrama de secuencia de UML. 30