PROBLEMAS, NECESIDADES O INTERESES DEL CONTEXTO
Luego de conocer la institución donde se llevara a cabo el proyecto, se abordó a la comunidad utilizando como técnica de recolección de datos la observación directa, tomando notas de lo observado y registrando para su posterior análisis. También se utilizo la técnica de entrevista directamente con la directora del plantel, y con el personal administrativo para así conocer por parte de ellos lo que está afectando a la institución y los intereses de la comunidad, siendo esto un punto clave para el desarrollo del proyecto.
Una vez aplicados los instrumentos de recolección de información, los resultados obtenidos son una serie de problemas que afectan distintas áreas de la institución, pero abarcando ciertamente los de interés para el grupo son los relacionados con la parte de informática de los cuales se encontraron que no poseen un sistema de red interno que los ayude a optimizar sus operaciones, los procesos de inscripción se lleva a cabo manualmente generando pérdida de tiempo, no cuenta con sistema automatizado para el control de pagos de los estudiantes, ni para las constancias de estudios y notas, los profesores tienen poco conocimiento sobre software libre, existen equipos en mal estado, debido a la falta de mantenimiento, y por último se puede señalar que no cuentan con un sitio web que ofrezca información sobre el liceo y proporcione servicios tanto al alumnado como a los docentes.
Cuadro 1.
CRITERIO | ALTERNATIVA Nª 1 | ALTERNATIVA Nª 2 | ALTERNATIVA Nª 3 | ALTERNATIVA Nª 4 |
Soporte Técnico | Capacitación | Instalación de Red | Sistema de Información Web | |
Costo | 2 | 2 | 3 | 1 |
Tiempo | 2 | 3 | 3 | 2 |
Habilidades Y Destrezas | 3 | 3 | 3 | 3 |
Posibilidad de alcanzar los objetivos | 3 | 3 | 3 | 3 |
Prioridad de desarrollo | 1 | 1 | 1 | 3 |
Disposición de los recursos existentes | 2 | 1 | 1 | 3 |
Matriz Multicriterio. Fuente: Mejia (2013)
Luego de analizar la figura 1 se establece que la mejor alternativa de solución es la creación de un sistema de información web para el proceso de inscripciones y solicitud de constancias de estudio y notas así como muchos más servicios para la institución, alumnos y docentes.
Metodología Seleccionada:
Para el desarrollo de la presente investigación se utilizó como metodología de desarrollo RUP que según (Jacobson, Ivar ,2000) tiene como propósito asegurar la producción de software de alta calidad, que se ajuste a las necesidades de sus usuarios finales con unos costos y calendario predecibles.
Arquitectura Tecnológica
Es un proceso de ingeniería de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible.
Ciclo de Vida (RUP) Fase de inicio
Se abordó a la comunidad (U.E Nuestra Señora de Coromoto), con el fin de conocer sus necesidades, y así obtener los requisitos funcionales con los que se va a trabajar. En esta fase se identificaron los principales casos de usos, actores así como los riesgos, se concretó la idea elaborando el modelado del negocio.
Según Somerville ("Requirements Engineering", Wiley, 1997), el Proceso de Ingeniería de Requerimientos implica los siguientes pasos: Identificación o Extracción de Requerimientos: Los usuarios descubren, revelan, articulan y comprenden los requerimientos que desean; Análisis y Negociación de Requerimientos: Razonamiento sobre los requerimientos anteriores, detectando y resolviendo inconsistencias o conflictos, coordinando requerimientos entre otros.; Especificación de Requerimientos: Redacción o registro de los requerimientos.; Validación de Requerimientos: Confirmación, por parte del usuario, de la validez de los requerimientos; Gestión de Requerimientos: Control de altas, bajas, modificaciones y consultas de los requerimientos.
Negociación:
Una vez analizados los requerimientos en base al estándar IEEE830-1984, se obtuvo un listados de requerimientos, que cumplen completamente con dicho estándar. En base a esto se procedió a realizar la negociación con el cliente donde no se realizaron modificaciones ni eliminaciones de requerimientos pertenecientes al listado antes analizado quedando de la siguiente manera.
Requerimiento | ID | ||
Registrar Usuario | CU01 | ||
Iniciar Sesión | CU02 | ||
Inscribir Alumno | CU03 | ||
Modificar Alumno | CU04 | ||
Validar Inscripción | CU05 | ||
Solicitar constancia de estudio | CU06 | ||
Solicitar constancia de notas | CU07 | ||
Generar Reportes | CU08 |
Fase de elaboración
En esta fase se completaron los casos de usos, y se definió la arquitectura base del sistema utilizando la arquitectura de 3 capas, que son la capa de presentación, la capa de negocio y la capa de datos.
El modelo "4+1" de Kruchten, es un modelo de vistas diseñado por el profesor Philippe Kruchten y que encaja con el estándar "IEEE 1471-2000" (Recommended Practice for Architecture Description of Software-Intensive Systems) que se utiliza para describir la arquitectura de un sistema software
intensivo basado en el uso de múltiples puntos de vista. Describe la arquitectura del software usando cinco vistas concurrentes..
Los diseñadores de software pueden organizar la descripción de sus decisiones de arquitectura en estas cuatro vistas, y luego ilustrarlas con un conjunto reducido de casos de uso o escenarios, los cuales constituyen la quinta vista.
Caso de uso N° 01: Registrar Usuario. Caso de uso N° 02: Iniciar Sesión
Caso de uso N° 03: Inscribir Alumnos
Cuadro Nº: 01 Escenario: Registrar Usuario
Nombre del caso de uso Registrar Usuario | Id del caso de uso CU01 |
Prioridad/Frecuencia Media | Tipo de caso de uso Sistema Propuesto |
Resumen El Administrador registra un nuevo usuario en el sistema para uso de un representante. | |
Actores Principales Administrador. | Personas involucradas e Intereses Representante |
Precondiciones | |
Escenario Principal | |
Usuario 1.- El Administrador solicita registrar un nuevo usuario. 3.- El Administrador introduce y envía los datos de usuario. | Sistema 2.- Presenta formulario de registro de nuevo usuario. 4.- Verifica que los tipos de datos sean válidos. 5.- Verifica que el usuario no existe. 6.- Registra los datos del usuario. 7.- Presenta informe de que el registro de usuario fue exitoso. |
Extensiones | |
Usuario 3.- El Administrador introduce y envía los datos de usuario erróneos. | Sistema 4.- Verifica que los tipos de datos sean válidos. 5.- Verifica que el usuario no existe. 6.- No registra los datos del usuario. 7.- Presenta informe de que el registro de usuario no fue exitoso. |
Postcondiciones | |
Requisitos especiales Computador con navegador WEB actualizado y acceso a internet |
Fuente: Mejía (2013)
Cuadro Nº 2 Escenario: Iniciar sesión
Nombre del caso de uso Iniciar Sesión | Id del caso de uso CU02 | |||||||||||||||||||||||
Prioridad/Frecuencia Alta | Tipo de caso de uso Sistema Propuesto | |||||||||||||||||||||||
Resumen El usuario inicia sesión con su cuenta y su Contraseña | ||||||||||||||||||||||||
Actores Principales Representante | Personas involucradas e Intereses | |||||||||||||||||||||||
Precondiciones Ya debe estar registrado | ||||||||||||||||||||||||
Escenario Principal | ||||||||||||||||||||||||
Usuario | Sistema | |||||||||||||||||||||||
1.- El Representante solicita iniciar sesión. 3.- El Representante introduce y envía los datos de usuario. | 2.- Presenta sesión. | interfaz | de | inicio | de | |||||||||||||||||||
4.- Verifica que todos los tipos de | ||||||||||||||||||||||||
datos sean válidos. | ||||||||||||||||||||||||
5.- Inicia sesión en el sistema. | ||||||||||||||||||||||||
Extensiones | ||||||||||||||||||||||||
Usuario | Sistema | |||||||||||||||||||||||
3.- El Representante usuario erróneos. | introduce | los | datos | de | 4.- Verifica que todos los tipos de datos sean válidos. | |||||||||||||||||||
5.- No inicia sesión en el sistema. | ||||||||||||||||||||||||
Postcondiciones | ||||||||||||||||||||||||
Requisitos especiales Computador con navegador WEB actualizado y acceso a internet. |
Fuente: Mejía (2013)
Cuadro Nº 3 Escenario: Inscribir Alumno
Nombre del caso de uso Inscribir Alumno | Id del caso de uso CU03 |
Prioridad/Frecuencia Media | Tipo de caso de uso Sistema Propuesto |
Resumen El Representante registra un alumno nuevo al sistema | |
Actores Principales Representante | Personas involucradas e Intereses Alumno |
Precondiciones El Representante debe haber iniciado sesión con su cuenta de usuario. | |
Escenario Principal | |
Usuario | Sistema |
1.- El Representante solicita inscribir un nuevo | 2.- Presenta formulario para la inscripción. |
alumno. | 4.- Verifica que todos los tipos de datos sean |
3.- El Representante introduce y envía los datos | válidos. |
del alumno. | 5.- Verifica que el alumno no esté Inscrito en el |
mismo periodo escolar | |
6.- Registra los datos del alumno | |
7.- Presenta informe de que el registro de alumno | |
fue exitoso. | |
Extensiones | |
Usuario | Sistema |
3.- El Representante introduce y envía los datos | 4.- Verifica que todos los tipos de datos sean |
del alumno de manera erróneos. | válidos. |
5.- Verifica que el alumno no exista anteriormente | |
dentro del sistema. | |
6.- No registra los datos del alumno. | |
7.- Presenta informe de que el registro de usuario | |
no fue exitoso. | |
Postcondiciones | |
Requisitos especiales Computador con navegador WEB actualizado y acceso a internet |
Fuente: Mejía (2013)
Fase de construcción
En esta fase se llevo a cabo la construcción del sistema por medio de una serie herramientas, se seleccionan algunos casos de uso, se redefine su análisis y diseño, se procede a su implantación en la institución seguidamente de sus pruebas las cuales fueron realizadas correctamente y sin ninguna novedad.
CONCLUSIONES
Para el desarrollo del sistema de información web se utilizaron herramientas como: HTML, PHPMYADMIN, APPSERV, XAMPP, WORD, NOTEPAD, resultando
eficiente para su desarrollo.
La institución educativa obtiene un gran beneficio con el desarrollo del sistema de información ya que podrán publicar información y agilizar todo el proceso de inscripción y constancias de estudios y notas, de igual forma, esto constituye un avance tecnológico para la casa de estudio. Cumpliendo con la expectativa para el cual se formuló el proyecto, de esta manera logrando el objetivo principal, el desarrollo de un Sistema de Información Web para el control de inscripciones, constancias de estudios y notas en la Unidad Educativa Nuestra Señora de Coromoto.
REFERENCIAS BIBLIOGRAFÍCAS
BENNETT, SIMON; STEVE mcrobb y RAY FARMER. (2007). Análisis y diseño de sistemas orientado a objetos usando UML. Tercera Edición. McGraw Hill. Madrid.
COHEN y ASIN. (2000). Sistemas de Información un enfoque de toma de decisiones. 3ª Edición. Mc Graw Hill.
EDWARDS, CHRIS; JOHN WARD y ANDY BYTHEWAY. (1998). Fundamentos
de Sistemas de Información. 2da. Edición. Prentice Hall. España.
LAUDON y LAUDON. (2000). "Administración de los Sistemas de Información.
Organización y Tecnología". 3ª Edición. Prentice Hall. México.
PRESSMAN, ROGER. (2006). "Ingeniería del Software. Un enfoque práctico".
Sexta Edición. McGrawHill. México.
Aplicación web para el control de eventos academicos organizados por la sociedad venezolana de puericultura y pediatría filial Trujillo
WEB APPLICATION FOR THE CONTROL OF ACADEMIC EVENTS ORGANIZED BY THE VENEZUELAN SOCIETY OF CHILDCARE AND PEDIATRICS FILIAL TRUJILLO
Arturo J. Valera
Universidad Politécnica Territorial del Estado Trujillo "Mario Briceño Iragorry" [email protected]
Trujillo – Venezuela
José R. Alarcón S.
Universidad Politécnica Territorial del Estado Trujillo "Mario Briceño Iragorry" [email protected]
Trujillo – Venezuela
Ronald J. Lozada V002E
Universidad Politécnica Territorial del Estado Trujillo "Mario Briceño Iragorry"
Trujillo – Venezuela
RESUMEN
El propósito de la investigación fue desarrollar una aplicación web para el control de los eventos académicos organizados por Sociedad Venezolana de Puericultura y Pediatría filial Trujillo. La aplicación permitirá agilizar todas la actividades administrativas que incurren en la organización de los eventos avalados por la sociedad con el fin de agilizarlos, proporcionar, brindar niveles de seguridad y confiabilidad en el tratamiento de la información, disminuir la carga de trabajo y centralizando la base de datos para organizar la información en un servidor de tal manera que esté accesible la información a todos los actores involucrados desde cualquier punto con acceso a internet. El desarrollo de esta aplicación estuvo orientado por el método watch del Dr. Jonas Montilva Se concluye con las principales ventajas que ofrece la aplicación en diferentes tópicos: administrativo, organizativos, de seguridad, calidad y tiempo.
Palabras clave: Aplicación Web, Sociedad, Internet, Eventos
ABSTRACT
The purpose of the research was to develop a Web Application for the control of academic events organized by the Venezuelan Society of Childcare and Pediatrics Filial Trujillo. The application will streamline all the administrative activities incurred in organizing the events supported by the company in order to speed them up, provide levels of security and reliability in data processing, reduce workload and centralized database to organize information in a server so that the information is accessible to all stakeholders from anywhere with internet access. The development of this application was guided by the WATCH method by Jonás Montilva, Ph.D. We conclude with the main advantages of the application on different topics: administrative, organizational, safety, quality and time.
Keywords: Web Application, Society, Internet, Events
INTRODUCCION
En la actualidad con el exponencial crecimiento y desarrollo de nuevas tecnologías, el computador tiene tantas aplicaciones que prácticamente es inconcebible pensar que exista una organización o área donde no esté presente, por lo tanto, surge la necesidad de manipular información rápida, clara y sencilla como elemento clave que pueda determinar el éxito o fracaso de cualquier organización.
Al respecto la mayoría de las organizaciones utilizan el Internet para realizar todas sus transacciones administrativas y financieras, por lo cual es de vital importancia el uso de esta herramienta y los sistemas automatizados como complemento de sus actividades para el mejor control de sus funciones y el logro de sus objetivos y metas planteadas.
Es por ello que surgen las aplicaciones y sistemas Web que permiten obtener información de una manera más rápida, sencilla y agradable para el usuario, cuyo beneficio final para el mismo podría resumirse en una reducción sustancial de tiempo y una mejor organización y control de sus actividades.
En base a lo anteriormente expuesto, se puede decir que todo organismo para alcanzar sus objetivos, debe realizar un conjunto de actividades o tareas en forma coordinada, utilizando para ello aplicaciones informáticas que pueden ser de tipo Web para mejorar el funcionamiento de las mismas. Es por ello que la Sociedad Venezolana de Puericultura y Pediatría Filial Trujillo (S.V.P.P. Filial Trujillo) no debe quedarse atrás en cuanto a los avances de la tecnología y el manejo de información.
Descripción del Contexto
La Sociedad Venezolana de Puericultura y Pediatría, Filial Trujillo (S.V.P.P. Filial Trujillo) es una organización sin fines de lucro ubicada en el Hospital Universitario "Dr. Pedro Emilio Carrillo, Piso 5, Departamento de Pediatría, Parroquia Mercedes Díaz, Municipio Valera, Estado Trujillo.
PROPÓSITOS DE LA INVESTIGACIÓN GENERAL
Desarrollar una aplicación Web para el registro y control de eventos y jornadas organizados por la Sociedad Venezolana de Puericultura y Pediatría S.V.P.P. Filial Trujillo.
ESPECÍFICOS
1. Realizar el levantamiento de información, en base a las entrevistas del personal y la recopilación de documentos de la situación actual.
2. Analizar la factibilidad operativa, técnica y económica, basándose en el levantamiento de información.
3. Determinar los requisitos para el desarrollo de la aplicación Web
4. Diseñar la propuesta de la aplicación Web en base a los requisitos especificados por los usuarios.
5. Codificar la aplicación, utilizando las diferentes herramientas para el desarrollo web orientado a objetos.
6. Comprobar que la aplicación funcione correctamente aplicando diversos casos de prueba
METODOS
De acuerdo con los objetivos planteados se determino que la metodología watch es la óptima para realización de exitosa de los objetivos planteados; este método fue desarrollado por Jonás Montilva en 2004 y está enfocada en el desarrollo de aplicaciones empresariales y consta de 8 fases.
Fase 1 Modelado del Negocio
En esta fase se lleva a cabo el levantamiento de la información en la S.V.P.P. Filial Trujillo especialmente haciendo uso de entrevistas con los expertos del dominio, permitiendo determinar él o los problemas existentes, objetivos, recursos, estructura, entre otros.
Fase 2 Ingeniería de Requisitos
El objetivo de esta fase se fundamenta en determinar las necesidades de información y automatización de los procesos del Sociedad Venezolana de Puericultura y Pediatría, Filial Trujillo, que tienen los usuarios de la aplicación en desarrollo, mediante la definición y especificación de sus requisitos, con el fin de Obtener el Documento de Definición de Requisitos (DDR)y el Documento de Especificación de Requisitos(DER) mediante la matriz de interacciones entre los requisitos basándose en los estándar de documentación de requisitos IEEE 830- 1998 [IEEE98].
Documento de Especificación de Requisitos(DER) está organizado de una manera completa, abarcando todos los requisitos planteado en el documento, estando cada uno de ellos manera consistente ya que no entran en conflicto, lo que garantizan que están de manera correcta al no presentar errores que afecten el diseño, no son ambiguos, poseen una sola interpretación y a su vez modificables debido a que sus cambios se pueden agregar de manera consistente y completa siendo los mismos verificados técnicamente, facilitando así el rastreo ó seguimiento de los requisitos hasta el código probado.
Esta aplicación web deberá ser capaz de apoyar todos los procesos y actividades referentes a todos los eventos académicos organizados por la S.V.P.P Filial Trujillo entre ellos: debe verificar los pagos registrados por los participantes, la aplicación deberá almacenar la información registrada en una base de datos centralizada, debe asegurar que la información personal nunca se haga disponible sin autorización, controlar el acceso del personal y determinar a qué usuarios se les puede permitir el uso de los distintos recursos y a cuáles se les debe restringir.
Así como también: registrar eventos, registrar epónimos, registrar participantes, registrar conferencistas, registrar artículos de información, registrar patrocinantes, registrar inscripción, confirmar participante, activar participante, generar certificados, generar constancias, generar credenciales, registrar compras y gastos, generar reportes.
Fase 3 Diseño Arquitectónico
En esta fase se elaboro un diseño de la arquitectura de la aplicación apropiado para los requisitos especificados y que establezca los subsistemas de la aplicación, los componentes de cada subsistema, las conexiones entre estos componentes y las restricciones que regulan la arquitectura.
Metas del diseño
Con los requisitos requeridos por los usuarios y la organización en cuanto a la seguridad y funcionabilidad de la aplicación se genero una serie de metas u objetivos para el diseño de la aplicación:
La aplicación deberá almacenar la información registrada en una base de datos centralizada.
Debe asegurar que la información personal nunca se haga disponible sin autorización.
Controlar el acceso del personal y determinar a qué usuarios se les puede permitir el uso de los distintos recursos y a cuáles se les debe restringir.
Niveles de seguridad para el acceso restringido a ciertas partes de la aplicación dependiendo del tipo de usuario.
La aplicación debe ser diseñada y construida con los mayores niveles de flexibilidad en cuanto a la parametrización de los tipos de datos.
La aplicación deberá permitir ser manipulada remotamente por su administrador.
El acceso a la aplicación debe estar restringido por el uso de claves asignadas a cada uno de los usuarios.
La solución debe tener interfaces gráficas de administración y de operación en idioma español y en ambiente 100% Web, para permitir su utilización a través de exploradores o navegadores de Internet.
La solución debe ser 100% Web Based y toda la parametrización y administración debe realizarse desde un navegador
Descripción de la arquitectura
Las aplicaciones webs modernas siguen un patrón o estilo arquitectónico similar, denominado arquitectura de 3 o más capas (n-tier). En este estilo arquitectónico, la lógica del negocio se instala y ejecuta separadamente del manejo de los datos y de la interfaz usuario/sistema de la aplicación.
Fase 4: Diseño de Componentes
Diseño de la Interfaz Usuario/Sistema
Aunque las personas que tienen contacto directo con las computadoras pueden ser definidas colectivamente como usuarios, de forma individual tienen numerosas diferencias (edad, sexo, conocimientos previos, motivación). Es por ello que al desarrollar una buena interfaz de usuario se debe tomar en consideración dichas diferencias como: la experiencia y la edad
Identificación de Componentes
Las características de cada sistema y componente varían de una localidad a otra, y para cada caso debe hacerse una descripción detallada de cada componente y sus elementos. La interacción de componentes trabajó en función de una interfaz que define el conjunto de operaciones que un componente puede realizar; estas operaciones son llamadas también servicios o responsabilidades. Las interfaces proveen un mecanismo para interconectar componentes y controlar las dependencias entre ellos.
Diseño de la Base de Datos
Sirve para almacenar la información que se utiliza en un sistema de información determinado. Las necesidades y los requisitos de los futuros usuarios del sistema de información se deben tener en cuenta para poder tomar adecuadamente las decisiones anteriores.
Diseño Conceptual de la Base de Datos
Se detalló cada uno de los tipos de entidades, se definieron los atributos, dominios y operaciones y se resolvieron los conflictos estructurales y de semántica de relaciones y atributos presentes en los esquemas parciales.
Los esquemas parciales fueron luego integrados, de acuerdo a un orden preestablecido, hasta lograr finalmente un esquema conceptual integrado de la base de datos del sistema. Finalmente, se verificó que los elementos contenidos en el esquema integrado permitieran dar respuesta a los requerimientos especificados por los actores del sistema.
Diseño Implementable de la Base de Datos
Esta fase se estructuró en tres subfases. En la primera se convirtió el esquema conceptual integrado a un esquema implementable, en la segunda se diseñaron las interfaces, y en la tercera se implementó el prototipo. El esquema conceptual fue convertido a un esquema relacional implementable, es decir, un esquema que pudiera incorporarse en un SMBD. Esta transformación consistió en la especificación de atributos claves para identificar cada una de las entidades del esquema conceptual. A partir de esto se generó un nuevo esquema que representa el modelo físico de la base de datos.
Diseño Físico de la Base de Datos
En la ejecución del diseño físico de la base de datos, se usó como herramienta el manejador de base de datos MySQL, ésta fue elaborada utilizando tablas y campos, según el modelo Entidad-Relación, con el fin de alcanzar la coherencia de los datos.
Planificación de Pruebas
El proceso de pruebas dentro del ciclo de vida de desarrollo de software es un factor clave para favorecer la calidad de todos los productos derivados de la construcción de aplicaciones, mediante el empleo de metodologías y técnicas que permiten hallar y prevenir defectos en el software.
Es por esto que las pruebas de software deben apoyarse en estándares que revisan los aspectos fundamentales que debe considerar todo proceso de pruebas. Ante estos problemas, el estándar ISO/IEC 29119 para pruebas de software es un referente internacional en el ámbito de las pruebas software y permite eliminar las inconsistencias existentes entre las normas actuales.
Fase 5: Aprovisionamiento de Componentes
Esta fase tiene como objetivo la búsqueda y adaptación de componentes de software reutilizables que cumplan con las especificaciones de componentes, así como el desarrollo de aquellos componentes que no puedan ser localizados o que no satisfagan adecuadamente las especificaciones de componentes de este modo obtenemos una colección de componentes asociados a cada una de las tres capas de la aplicación empresarial
Depuración de Errores
Los mecanismos de depuración son muy potentes, permitiendo la ejecución de un ciclo completo de programa, inclusión de puntos de ruptura o la ejecución instrucción a instrucción. Al tratarse del Sistema Web para el Registro y control de eventos de la Sociedad Venezolana de Puericultura y pediatría Filial Trujillo se realizan diferentes pruebas de depuración de software, el cual se realiza con la finalidad de encontrar errores dentro del funcionamiento.
Fueron muchos los errores encontrados y que debían arreglar. Esta depuración se realizo con la finalidad de ayudar al programador en las tareas de perfeccionamiento del software, por ello fue factor determinante para la efectividad y eficiencia del proceso de depuración.
Fase 6: Integración de Componentes
Ésta fase tiene como objetivo ensamblar la aplicación web desarrollada con los componentes que la integran.
Al integrar los componentes se debe realizar una serie de pruebas. Las pruebas tienen como objetivo fundamental conseguir las diferencias entre la manera esperada de la aplicación y la forma observada en el sistema.
Se realizaron las siguientes pruebas:
Pruebas funcionales: encargada de comprobar que el SW cumple con las funciones establecida en los contratos de uso y de realización.
Pruebas no funcionales: realiza la comparación de la aplicación con los requisitos no funcionales, estos incluyen seguridad, velocidad, confiabilidad, entre otros.
Pruebas de aceptación: consiste en revisión de los requisitos contra el contrato de uso; esta prueba debe ser realizada por el cliente o usuario.
Pruebas de aceptación: consiste en revisión de los requisitos contra el contrato de uso; esta prueba debe ser realizada por el cliente o usuario.
Fase 7 Pruebas de la Aplicación Pruebas del sistema
Las pruebas del sistema buscan detectar y corregir el mayor número de errores posibles y con una cantidad razonable de tiempo y esfuerzo. En el caso del de la Aplicación Web para el Registro y Control de Eventos y Jornadas Organizados por la Sociedad Venezolana de Puericultura y Pediatría Filial Trujillo, las pruebas permiten verificar que la aplicación funciona correctamente en condiciones típicas de operación y que satisface los requisitos funcionales y no funcionales determinados previamente.
Pruebas de caja negra del sistema
El enfoque funcional o de caja negra consiste en estudiar la especificación de las funciones, la entrada y la salida con el fin de verificar que los componentes se comportan de la manera esperada. Aquí, la prueba ideal del software, consistirá en probar todas las posibles entradas y salidas del programa. Sin embargo, se puede generalizar un conjunto de valores que abarque el mayor número de casos de entrada posibles y de ese modo cubrir varios escenarios a la vez.
Pruebas funcionales
Para verificar que el sistema satisface los requisitos funcionales definidos en la fase de ingeniería de requisitos, se desarrolla un conjunto de pruebas en las que los componentes que intervienen en cada caso de uso son probados de manera general, en condiciones que simulan las condiciones normales de operación del sistema.
En estas pruebas también se revisa que los componentes se integran de manera adecuada, cumpliendo con las especificaciones hechas en la fase de diseño.
Fase 8: Entrega de la Aplicación Empresarial Planificación de la Instalación
La instalación del software es el proceso por el cual los programas desarrollados son transferidos apropiadamente al computador destino, inicializados, y, eventualmente, configurados; todo ello con el propósito de ser ya utilizados por el usuario final. Constituye la etapa final en el desarrollo propiamente dicho del software. Luego de ésta el producto entrará en la fase de funcionamiento y producción, para el que fuera diseñado.
CONCLUSIONES
El desarrollo de aplicaciones Web son importantes en toda organización, puesto que se caracterizan por registrar información, y permiten realizar de forma automática todas sus funciones, la aplicación sirve de apoyo a la correcta toma de decisiones, e indica la acción que se debe tomar para mantener a la organización dentro de las condiciones normales de funcionamiento.
Una aplicación Web, es un medio de transmitir información, los usuarios lo pueden utilizar accediendo a un Servidor Web de Internet o de una Intranet mediante un navegador; para ello, se utilizan lenguajes de programación soportados por los navegadores de la plataforma web, garantizando así una eficiente ejecución de la aplicación. La comunicación con el cliente representó una clave fundamental para poder validar los requisitos y cumplir con sus necesidades o requerimientos. La comunicación se da a partir de cada una de las iteraciones a lo largo del proceso de desarrollo.
La metodología WATCH resultó ser una técnica favorable en el proceso de desarrollo de software, brindando una serie de técnicas y procedimientos que ayudaron a desarrollar la aplicación y cumplir con los objetivos planteados.
No existe una forma única de modelar sistemas, todo depende de la perspectiva del analista y del grado de detalle que desee implementar para dicha labor.
El desarrollo de un sistema de información, no hace referencia exclusivamente a la tarea de codificación, se refiere a una serie de pasos o procedimientos para la
creación de un producto, incluyendo también aspectos como el modelado del negocio y las tareas de análisis y diseño.
REFERENCIAS BIBLIOGRÁFICAS
ARCHILA R. (2009).Historia de la Sociedad Venezolana de Puericultura y Pediatría. Caracas – Venezuela.
MONTILVA C, JONÁS. (2004). Desarrollo de Aplicaciones Empresariales, El Método WATCH. Versión 2004 Mérida – Venezuela.
MONTILVA C, JONÁS (2009) Ingeniería de Requisitos. Programa de actualización profesional en ingeniería de software. Versión 5.0. Mérida -Venezuela.
BELL, DOUGLAS (2007).Diagramas de clases para elaborar sistemas [Documento en línea]. Disponible en http://www.monografias.com/diagramas de clase/lenguaje-modelado-sistemas.
BARRIENTOS, ENRÍQUEZ (2005). El desarrollo de sistemas de información empleando el lenguaje de modelado unificado UML. Documento en línea. Disponible en http://www.monografias.com/trabajos16/lenguaje-modelado- unificado/lenguaje-modelado-unificado#PRINCIP
Especificación de Requisitos según el estándar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008
GUTIÉRREZ, JAMES GILDARDO (2009) Definición arquitectura cliente servidor. [Documento en línea]. Disponible en C:Documents and SettingspersonalMis documentosSistemas de Información. [Consulta: 2009, Noviembre 23]
JAMES A. SENN (2008), Análisis y Diseño de Sistemas de Información. Editorial Mc Graw Hill. Segunda edición. Colombia.
REQUIREMENTS ANALYSIS FROM INTEGRAL SYSTEM FOR THE CONTROL OF PERSONAL RECORDS OF THE GOVERNORATE OF TRUJILLO STATE (RECONRH)
Oscar Ángeles
Universidad Politécnica Territorial del Estado Trujillo "Mario Briceño Iragorry"
Trujillo – Venezuela
Moraima Mora
Universidad Politécnica Territorial del Estado Trujillo "Mario Briceño Iragorry"
Trujillo – Venezuela
RESUMEN
El propósito principal de la presente investigación tiene como finalidad el de utilizar el modelo orientado a Objetos de B, Bruegge y A, Dutoit 2000 para el levantamiento del análisis de requisitos del sistema RECONRH de la Gobernación del Estado Trujillo. El sistema Integral para el Registro y Control de los Trabajadores de la Gobernación Socialista del Estado Trujillo, establecerá la automatización del control del proceso de actualización de los Expedientes y solicitudes de constancias y permisos por parte de los trabajadores, así mismo exportar reportes confiables solicitados por la Dependencia de Recursos Humanos, alcanzando satisfacer las necesidades de los Trabajadores y Gerencia solicitantes en la obtención de una respuesta oportuna y eficaz por parte del Departamento de Registro y Control de la Gobernación Socialista del Estado Trujillo..
Palabras Claves: Requisitos, Software, Expedientes, Sistema, Personal.
ABSTRACT
The main purpose of this research is aimed at using the Object-oriented B, and A Bruegge, Dutoit 2000 for lifting the requirements analysis system RECONRH the Governorate of Trujillo state model. The comprehensive system for the registration and control of the Socialist Workers of Trujillo State Government, establish control automation process of updating records and requests for certificates and permits from workers and export same reliable reports requested by the Human Resources, reaching the needs of Workers and Management applicants in obtaining timely and effective response by the Department of Registration and Control of the Socialist Government of Trujillo state..
Key words: Requirements, Software, Records, System, Staff.
INTRODUCCIÓN
Esta probado que los requerimientos o requisitos son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeación, básicamente en lo que se refiere a las estimaciones de tiempos y costos, así como la definición de recursos necesarios y la elaboración de cronogramas que será uno de los principales mecanismos de control con los que se contará durante la etapa de desarrollo.
Es muy frecuente escuchar entre los conocedores del desarrollo de software (programas de computadoras), que un gran número de los proyectos de software fracasan por no realizar una adecuada definición, especificación, y administración de los requerimientos. Dentro de esa mala administración se pueden encontrar factores como la falta de participación del usuario, requerimientos incompletos y el mal manejo del cambio a los requerimientos.
La Ingeniería de Requerimientos (IR) cumple un papel primordial en el proceso de producción de software, ya que se enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, las necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los problemas relacionados por la mala gestión de los requerimientos en el desarrollo de sistemas.
Ingeniería de requerimientos: conceptos y características
Como se menciono anteriormente, la ingeniería de requerimientos sirve como una base sólida en el proceso de desarrollo de software, por lo que antes de pasar a tratar los aspectos referentes a la administración adecuada de los requerimientos, es importante primero definir lo que es un requerimiento y cuáles serían las características deseables que deberían de tener.
¿Qué son Requerimientos?
Se presenta a continuación la definición existente en el glosario de la IEEE de lo que es un "Requerimiento":
"Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo". (Std 610.12-1900, IEEE: 62)
"Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal". (Std 610.12-1900, IEEE: 62)
Tipos de Requerimientos
Los requerimientos funcionales son los que definen las funciones que el sistema será capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el ¿Qué? y no el ¿Cómo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte del código del sistema.
Por otra parte los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Ingeniería de requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa. Algunos otros conceptos de ingeniería de requerimientos son: "La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema". (Sommerville, 1997)
En síntesis, el proceso de ingeniería de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendrá a ayudar a determinar la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtención y análisis de requerimientos, su especificación formal, para finalizar con el subproceso de validación donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.
Importancia de la ingeniería de requerimientos
Según la autora (Lizka Johany Herrera, 2003) en su documento de la ingeniería de requerimientos, los principales beneficios que se obtienen de la Ingeniería de Requerimientos son:
Permite gestionar las necesidades del proyecto en forma estructurada
Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados
Disminuye los costos y retrasos del proyecto
Mejora la calidad del software
Mejora la comunicación entre equipos
Evita rechazos de usuarios finales
Actividades de la ingeniería de requerimientos
Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice que dentro de la IR existen cuatro actividades básicas que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene para el desarrollo de un proyecto de software realizar una especificación y administración adecuada de los requerimientos de los clientes o usuarios. Las cuatro actividades son: extracción, análisis, especificación y validación, y serán explicadas a continuación cada una de ellas.
Extracción (Descubrimiento de Requisitos)
Figura 3. Proceso de Identificación, Registro y Entendimiento de Requisitos de la Aplicación por Clientes/Usuarios/Desarrolladores. Fuente: Jonás Montilva (2009)
Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar
junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar. Es importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuán bien éste satisfaga las necesidades del cliente.
Análisis
Figura 4. Proceso de análisis de los requisitos identificados y clasificación para implementación. Fuente Jonás Montilva (2009)
Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.
Especificación
En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de
requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientos.
Figura 5. Proceso de análisis de los requisitos identificados y clasificación para implementación. Fuente: Jonás Montilva (2009)
Validación
Figura 6. Proceso Verificación de los Requisitos a implementar.
Fuente: Jonás Montilva (2009).
La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.
Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificación de requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso.
Técnicas y herramientas utilizadas en la ingeniería de requerimientos
Técnicas utilizadas en las actividades de IR
Existen varias técnicas para la IR propuestas para ingeniería de requerimientos (Herrera, 2003: 12), y de las cuales en este artículo solo se abarcarán cinco de ellas. Es importante resaltar que estas técnicas pueden ser aplicables a las distintas fases del proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las características propias del proyecto en particular que se esté desarrollándose para aprovechar al máximo su utilidad.
Entrevistas y Cuestionarios
Sistemas existentes
Lluvia de ideas (Brainstorm)
3.1.4 Casos de Uso
Los casos de uso son una técnica para especificar el comportamiento de un sistema. Según el autor Sommerville, los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos. Actualmente, se han convertido en una característica fundamental de la notación UML (Lenguaje de modelado unificado), que se utiliza para describir modelos de sistemas orientados a objetos.
Contexto de estudio y Metodología
Los sistemas de información han alcanzado un nivel de desarrollo en todos los ámbitos que conforman la nueva sociedad automatizada, con la integración de una herramienta tan poderosa como el computador ya que han contribuido a la consolidación y progreso del mundo empresarial.
Hoy en día la rama de la informática utiliza los sistemas de información para dar soluciones a las incógnitas que se presentan al momento de convertir una serie de datos en información que sea de fácil aceptación para el usuario. Motivado por esta situación, se planteó su mejora, lo cual se quiere demostrar mediante este Proyecto, en el que un sistema automatizado puede ayudar a obtener un mejor control de las actividades que se llevan a cabo en este departamento de la Institución Regional, y lograr así; una mejor calidad de los procesos que se realicen mediante su utilización.
Para este proyecto se hicieron observaciones directas en el Departamento de Recursos Humanos y se estructuro el Documento de Requisitos mediante el modelo OO con fines académicos de B. Bruegge y A. Dutoit 2000. Dicho modelo de análisis puede considerarse como una primera aproximación al modelo de diseño y es, por tanto, una entrada fundamental cuando se da forma al sistema en el diseño y en la implementación.
Capítulo I "Introducción" se desglosará el propósito y alcance del sistema además de los Objetivos (general, específicos), definiciones de términos y acrónimos. Capítulo II "Descripción del sistema Actual" de describirá la estructura y funcionamiento de la aplicación existente en la actualidad. Capítulo III "Sistema Propuesto" donde se ubicarán la visión General del Sistema, se detallaran los
requisitos funcionales RF (Negocio, Usuario, Sistema, Comportamiento) y los no funcionales RNF con las planillas Volere. Capítulo final IV "Glosario de términos"
RESULTADOS
- Diagrama de Casos de Uso General y Específicos
- Requerimientos Funcionales
Id Requisito | Nombre de Registro | Usuario | Proceso Asociado | ||
RF-01 | Gestionar Comisión de Servicio | Admtd ExpdtAC-2 | RF-02, RF-03,RF-04, RF-05, RF-06 | ||
RF-02 | Registrar Comisión de Servicio | Admtd ExpdtAC-2 | RF-01, RF-03,RF-04, RF-05, RF-06 | ||
RF-03 | Modificar Comisión de Servicio | Admtd ExpdtAC-2 | RF-01, RF-02,RF-04, RF-05, RF-06 | ||
RF-04 | Eliminar Comisión de Servicio | Admtd ExpdtAC-2 | RF-01, RF-02,RF-03, RF-05, RF-06 | ||
RF-05 | Consultar Comisión de Servicio | Admtd ExpdtAC-2 | RF-01, RF-02,RF-03, RF-05, RF-06 | ||
RF-06 | Anular Comisión de Servicio | Admtd ExpdtAC-2 | RF-01, RF-02,RF-03, RF-04, RF-05 | ||
RF-07 | Gestionar Anticipo de Prestaciones | Admtd ExpdtAC-2 | RF-08, RF-09,RF-10, RF-11, RF-12 | ||
RF-08 | Registrar Anticipo de Prestaciones | Admtd ExpdtAC-2 | RF-07, RF-09,RF-10, RF-11, RF-12 | ||
RF-09 | Modificar Anticipo de Prestaciones | Admtd ExpdtAC-2 | RF-07, RF-08, RF-10, RF-11, RF- 12 | ||
RF-10 | Eliminar Anticipo de Prestaciones | Admtd ExpdtAC-2 | RF-07, RF-08, RF-09, RF-11, RF- 12 | ||
RF-11 | Consultar Anticipo de Prestaciones | Admtd ExpdtAC-2 | RF-07, RF-08, RF-09, RF-10, RF- 12 | ||
RF-12 | Anular Anticipo de Prestaciones | Admtd ExpdtAC-2 | RF-07, RF-08, RF-09, RF-10, RF- 11 | ||
RF-13 | Imprimir Listado de Comisiones de Servicio | Admtd ExpdtAC-2 | RF-01 | ||
RF-14 | Imprimir Listado de Anticipos de Prestaciones | Admtd ExpdtAC-2 | RF-07 |
Requerimientos No Funcionales
Id. Requisito | Descripción del Requisito | ||||
RNF-01 | El sistema debe ser diseñado para trabajar en plataformas de software libre, desarrollado bajo ambiente Web, utilizando el lenguaje de programación PHP. | ||||
RNF-03 | El sistema debe seguir el criterio de identificación (Imagen Corporativa) de la Gobernación del Estado Trujillo. | ||||
RNF-04 | El sistema deberá tener una interfaz gráfica sencilla y amigable, basada en menús, ventanas, listas desplegables y botones de acción. | ||||
RNF-05 | El sistema permitirá a los usuarios iniciar sesión mediante la cedula y la clave, siendo validado por el sistema para su acceso. | ||||
RNF-06 | Cada usuario del sistema tendrá asignado un determinado perfil, usado para activar los servicios o opciones que él pueda realizar dentro del sistema. |
Especificación de requisitos mediante aplicación de Planilla Volere.
Figura 7. Aplicación de las Planillas VOLERE. Fuente: Robertson (2003)
Figura 8. Aplicación de las Planillas de Descripción textual.
Fuente: Robertson (2003)
CONCLUSIONES
El sistema Integral para el Registro y Control de los Trabajadores de la Gobernación Socialista del Estado Trujillo, establecerá la automatización del control del proceso de actualización de los Expedientes y solicitudes de constancias y permisos por parte de los trabajadores, así mismo exportar reportes confiables solicitados por la Dependencia de Recursos Humanos, alcanzando satisfacer las necesidades de los Trabajadores y Gerencia solicitantes en la obtención de una respuesta oportuna y eficaz por parte del Departamento de Registro y Control de la Gobernación Socialista del Estado Trujillo.
Con la implantación del sistema no solo se automatizaran los procesos de registro y control de los empleados, sino que se evitara la pérdida de documentación permanentemente debido a que se contara con un respaldo electrónico de esta información, adicionalmente la tramitación y entrega con celeridad de la documentación solicitada y procesada por el sistema elevaran el nivel de eficiencia del departamento de Recursos humanos. En otro sentido la actualización tecnológica de la Gobernación Socialista del Estado Trujillo tendrá una acogida satisfactoria y elevara el sentido de pertenecía por parte de los empleados de la institución.
BIBLOGRAFIA
Kotonya, G., Sommerville, P. (1997). Requirements Engineering: Processes and Techniques. John Wiley & sons
Sommerville, I., Sawyer, P. (1997). Requirements Engineering: A Good Practice Guide. John Wiley & sons
DESIGN OF ARCHITECTURE OF SOFTWARE APPLIED TO THE INTEGRAL SYSTEM FOR THE CONTROL OF STAFF FILES OF
GOVERNMENT TRUJILLO STATE
Daniela D. Romero G.
Universidad Politécnica Territorial del Estado Trujillo "Mario Briceño Iragorry"
Trujillo – Venezuela
Katiuska Villegas.
Universidad Politécnica Territorial del Estado Trujillo "Mario Briceño Iragorry"
Trujillo – Venezuela
José G. Fernández
Universidad Politécnica Territorial del Estado Trujillo "Mario Briceño Iragorry"
Trujillo – Venezuela
RESUMEN
El presente artículo tiene como propósito fundamental dar a conocer el diseño de arquitectura aplicada para el desarrollo del Proyecto Socio Tecnológico, titulado Sistema Integral para el Control de Expedientes del Personal de la Gobernación del Estado Trujillo, utilizando como patrón de diseño Modelo-Vista-Controlador, siendo uno de los estándares establecidos por la Oficina de Organización y Sistemas para el desarrollo de software, con la finalidad de mantener una misma estructura e integrar eficientemente los módulos realizados por los programadores.
Palabras Claves: Diseño, Software, Patrón, Sistema, Arquitectura.
ABSTRACT
This article has as main purpose to present architectural design applied to the development of the socio technological project, titled integral system for the Control of records of the staff of the Government of Trujillo State, as architectural style using the model-view – controller design pattern is one of the standards set by the Office of organization and systems for software development in order to maintain the same structure and efficiently integrate modules made by programmers.
Key words: Design, Software, Patron, System, Architecture.
INTRODUCCIÓN
Las aplicaciones web se han convertido en pocos años en complejos sistemas con interfaces de usuario cada vez más parecidas a las aplicaciones de escritorio, dando servicio a procesos de negocio de considerable envergadura y estableciéndose sobre ellas requisitos estrictos de accesibilidad y respuesta. Esto ha exigido reflexiones sobre la mejor arquitectura y las técnicas de diseño más adecuadas.
En los últimos años, la rápida expansión de Internet y del uso de intranets corporativas ha supuesto una transformación en las necesidades de información de las organizaciones, es por esta razón que la Gobernación del Estado Trujillo ha venido automatizando los procesos llevados a cabo para el desarrollo y avance de las actividades de esta institución, con la finalidad agilizar los resultados que permitan realizar una toma de decisiones de manera más eficiente.
De allí nace la necesidad de desarrollar e implantar el Sistema Integral para el Control de los Expedientes del Personal de la Gobernación del Estado Trujillo, siendo unos de los requerimientos principales del departamento de Registro y Control de esta institución, permitiendo de esta manera, involucrar a los estudiantes del Instituto Universitario de Tecnología del estado Trujillo (IUTET) del Programa de Formación Nacional (PNF) en Informática.
El siguiente artículo pretende dar a conocer el diseño arquitectónico aplicado en el desarrollo del software planteado anteriormente, definido como un proceso creativo que organiza el sistema para satisfacer los requerimientos funcionales y no funcionales, permitiendo establecer un marco estructural básico para identificar los principales componentes del sistema y las comunicaciones entre estos componentes, para el cual se utilizo el patrón MVC (Modelo-Vista-Controlador), desarrollado en el Centro de Investigaciones Xerox Palo Alto a finales de los años setenta, siendo un modelo de abstracción de desarrollo de software que separa los datos de una aplicación, la interfaz de usuario y la lógica de negocio en tres componentes distintos, establecido por la Oficina de Organización y Sistemas de la Gobernación del Estado Trujillo, como un estándar único para el desarrollo de las aplicaciones web desarrolladas para el Sistema Integral Institucional.
Arquitectura del Software
La arquitectura del software proporciona una visión global del sistema a construir, marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistemas alternativos, permitiendo a los programadores, analistas y todo el conjunto de desarrolladores del software compartir una misma línea de trabajo y cubrir todos los objetivos y restricciones de la aplicación. Según autor:
…es la forma en la que se organizan los componentes de un sistema, interactúan y se relacionan entre sí y con el contexto, aplicando normas y principios de diseño y calidad, que fortalezcan y fomenten la usabilidad a la vez que dejan preparado el sistema, para su propia evolución. (Bahit, 2011:33)
El desarrollo de la arquitectura de software es una de las etapas fundamentales y, en muchos casos, la más importante en el desarrollo de software, pues es aquí donde los profesionales aportan todos sus conocimientos, creatividad y experiencia para crear la mejor propuesta de solución que se dará al cliente que cumpla con los requerimientos funcionales y no funcionales establecidos para el sistema en desarrollo, así como sus preocupaciones principales de lo que esperan del sistema.
Diseño de Software
El diseño no sólo se refiere a la interfaz gráfica del software, como muchas veces se suele pensar cuando se escucha la palabra diseño, sino que implica un proceso en el cual se deben satisfacer los requisitos del sistema a desarrollar.
El diseño de software se divide en dos partes importantes: diseño arquitectónico y diseño detallado. El diseño de la arquitectura de software ocurre inmediatamente después de la especificación de los requerimientos de software y considera como elementos principales los siguientes: componentes de software, propiedades de dichos componentes y la comunicación entre ellos. El diseño detallado se lleva a cabo justo antes de la codificación, y forma parte de las primeras tareas del desarrollador; describe la lógica, el control jerárquico, estructura de datos, empacado de componentes, entre otros.
Luego de realizar un documento de especificación de requerimientos de software, se debe elaborar un documento de la arquitectura de software del sistema deseado, que servirá para generar el diseño detallado de dicho sistema. Un vez generada y documentada la arquitectura de software, ésta se evaluó para verificar que cumpla con todos los requerimientos; específicamente con los atributos de calidad establecidos.
Patrones Arquitectónicos
La rama de la ingeniería del software se preocupa por crear procesos que aseguren calidad en los programas que se realizan y esa calidad atiende a diversos parámetros que son deseables para todo desarrollo, como la estructuración de los programas o reutilización del código, lo que debe influir positivamente en la facilidad de desarrollo y el mantenimiento del software.
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces, para que una solución sea considerada un patrón debe poseer ciertas características, una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores, otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias, además garantiza la calidad del desarrollo de los proyectos.
En este sentido Christopher (1979) plantea:
..Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a este problema, de tal ,modo que esta solución se pueda aplicar esta solución un millón de veces, sin hacer lo mismo dos veces.(Pag:23)
La selección de un patrón arquitectónico es, por tanto, una decisión fundamental de diseño en el desarrollo de un sistema de software, una de las arquitecturas de desarrollo más utilizadas hoy en día es la arquitectura de tres capas: la capa de interfaz, la capa de la aplicación y la capa de almacenamiento, entre los más utilizados para el desarrollo de aplicaciones web el patrón Modelo- Vista-Controlador, conocido como patrón arquitectónico MVC.
PATRÓN ARQUITECTÓNICO MVC
MVC, son las siglas Modelo-Vista-Control, es un patrón de la arquitectura del software descrito por primera vez en 1979 por el Noruego TrygveReenskaug, trabajador de Smalltalk, en unos laboratorios de gran investigación de Xerox.
Este patrón permite establecer una clara separación de la aplicación entre los componentes, para aumentar la flexibilidad y reutilización, el cual se basa en la estructura de tres (3) capas: la interfaz de usuario (vistas), el modelo de negocio y la lógica de control, con el propósito de reutilizar el código ya implementado. La separación permite a los desarrolladores hacer cambios en una parte del la aplicación sin afectar a los demás.
Ha sido uno de los patrones que ha demostrado ser fundamental a la hora de diseñar aplicaciones web, en donde las vistas serían las páginas HTML que el usuario visualiza en el navegador. A través de estas páginas el usuario interactúa con la aplicación, enviando eventos al servidor a través de peticiones HTTP. En el servidor se encuentra el código de control para estos eventos, que en función del evento concreto actúa sobre el modelo convenientemente. Los resultados de la acción se devuelven al usuario en forma de página HTML.
La idea básica detrás de esto es separar el código, de tal manera que si necesitamos hacer un cambio en la base de datos, esto no afecte a la lógica del programa, ahora la función del controlador solo es controlar la interacción entre la capa del modelo y la vista.
Para entender cómo funciona el patrón MVC, se debe entender la división a través del conjunto de estos tres elementos y como estos componentes se comunican unos con los otros y con otras vistas y controladores externos al modelo principal. Para ello, es importante describir cada uno de estos elementos:
Página anterior | Volver al principio del trabajo | Página siguiente |