ANÁLISIS DE INGENIERÍA DE REQUERIMIENTOS: ALTA DE UNIDADES DE APRENDIZAJE EN LA UAI-UAGRO (MÉXICO)

ANALISIS DE INGENIERIA DE REQUERIMIENTOS: ALTA DE UNIDADES DE APRENDIZAJE EN LA UAI-AGro (MÈXICO)

ANALYSIS REQUIREMENTS ENGINEERING: HIGH OF UNITS OF LEARNING IAU-UAGro MEXICO

Fecha de recepción: 3 de agosto de 2012
Fecha de aceptación: 21 de septiembre de 2012

Juan Carlos Medina Martínez

Universidad Autónoma de Guerrero, Unidad Académica de Ingeniería Av. Lázaro Cárdenas S/N, C. U. Guerrero, México, 01747 4727943. Correo electrónico: jcmedina74@yahoo.com.mx, esolis@hotmail.com

Víctor M. Hernández Alarcón

Instituto Tecnológico de Chilpancingo, Av. José francisco Ruíz Massieu no. 5, Col. Villa moderna. Cp. 39090. Guerrero, México, 017474721014. Correo electróncio: vmanuel.hdez@gmail.com

Lorena Alonso Guzmán

Universidad Autónoma de Guerrero, Centro Estatal de capacitación y Seguimiento, Av. Lázaro Cárdenas S/N, C. U. Guerrero, México. Correo electrónico: alonso@uagro.mx

Edgardo Solís Carmona

Resumen

En la actualidad, para la aplicación de ingeniería de software existen varios procesos de desarrollo de software. En esta investigación una de las etapas importantes del proceso de desarrollo es la ingeniería de requerimientos, etapa en que se definen inicialmente las características y restricciones con las que debe contar el sistema en desarrollo, parte fundamental ya que determina qué funcionalidad debe contener el software. En el caso de uso se aplicará al Sistema de Alta de Unidades de Aprendizaje (SAUA), que les permitirá a los alumnos de la Unidad Académica de Ingeniería (UAI) de la Universidad Autónoma de Guerrero (UAGro) dar de alta la unidad de aprendizaje ofertada (cursos) de manera remota mediante el uso de internet.

Palabras Clave:

unidad de aprendizaje, desarrollo, cliente, desarrollador, diseño, web.

Abstract:

At the present, for the application of software engineering are several the software development processes that exist. In this research one of the important stages in the development process is the requirements engineering. At this stage initially defined features and restrictions must have the system development, a fundamental part as it determines which functionality should contain the software. The case study will be applied the Sistema de Alta de Unidades de Aprendizaje (SAUA), which allow students of Unidad Académica de Ingeniería (UAI) of the Universidad Autónoma de Guerrero (UAGro) record the learning unit offered (courses) so remotely using the Internet.

Key words

Unit learning, development, customer, developer, design, Web.

1. Introducción

El campo de los requerimientos del sistema es un área muy extensa y hay mucho trabajo por hacer; por ejemplo, no existen herramientas de software que realicen automáticamente la validación de los requerimientos mediante los atributos presentados en esta investigación [1], [2]. Al analizar la ingeniería de requerimientos resulta muy pretencioso dada la complejidad del tema.

Con la aplicación de la ingeniería de software se pueden reducir riesgos de fallos en un sistema en desarrollo e incrementar la posibilidad de la entrega del producto en el tiempo estimado, con calidad y dentro de los costos presupuestados. Generalmente las etapas utilizadas en el desarrollo de software son:

• Ingeniería de requerimientos,
• Diseño del sistema,
• Implementación,
• Validación y
• Mantenimiento.

Una etapa muy importante del proceso de ingeniería de software es la ingeniería de requerimientos, la cual define el software que se desea producir y sus especificaciones [3]. Este proceso se realiza mediante la obtención, el análisis, la especificación, la validación y la administración de los requerimientos de software. Los requerimientos de software son las necesidades de los clientes, los servicios que los usuarios desean que proporcione el sistema en desarrollo y las restricciones con las que debe operar. El resultado del proceso de requerimientos es la base para el diseño, la implementación y la evaluación del software. De esta forma, si no se descubren y especifican todos los requerimientos del sistema en desarrollo, podría conducirnos a la entrega de un producto de software incompleto, con alto índice de riesgos y poco funcional [1].

La ingeniería de requerimientos desempeña un papel fundamental en el proceso de elaboración de software, ya que enfoca un área fundamental: la definición de lo que el software hará [4].

Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera se pretende minimizar los problemas relacionados con el desarrollo de sistemas [5].

1.1. Planteamiento del problema

La Unidad Académica de Ingeniería (UAI) de la Universidad Autónoma de Guerrero (UAGro), en el reciente ciclo escolar 2011-2012, implementó un nuevo plan de estudios trimestral, en el cual los alumnos eligen las unidades de aprendizaje a cursar así como el horario y el docente. El alumno puede cursar cuatro unidades de aprendizaje como máximo. En caso de un adeudo de unidad de aprendizaje, puede cursarse siempre y cuando esté ofertada; tanto el subdirector de control escolar como él área de tutoría, en el caso de que exista algún inconveniente, como saturamiento de alumnos para un docente, tomarán la decisión para asignarlo a otro docente.

1.2. Materiales y métodos

Los requerimientos son una declaración en lenguaje natural en la que se describen las necesidades de los usuarios de la UAI; estos requerimientos se obtuvieron a partir de la definición inicial del cliente y mediante entrevistas y cuestionarios realizados a varios personas involucradas de alguna manera en el sistema y que permiten asegurar el éxito del proyecto; por ejemplo, los usuarios finales y sus administradores, alumnos y profesores, ingenieros de sistemas y programadores (stakeholders) de la UAI.

Los requerimientos básicos para el alta de unidades de aprendizaje en la UAI se obtuvieron de la entrevista inicial que proporcionó el subdirector de administración y control escolar (cliente del sistema), además de otros que fueron propuestos por el equipo de desarrollo considerando la información que se obtuvo de la lectura de documentos relacionados y entrevistas realizadas a los usuarios del sistema.

No existen herramientas que vinculen los requerimientos funcionales con los requerimientos no funcionales, donde se ilustren la importancia y el efecto que tendrán estos vínculos. Aún no existe la manera automatizada de conocer cuándo los requerimientos están completos en el documento de requerimientos; este proceso actualmente se lleva a cabo mediante sesiones en las cuales los usuarios, el cliente y el equipo de desarrollo realizan las revisiones pertinentes.

1.3. Objetivo

El objetivo del Sistema de Alta de Unidades de Aprendizaje (SAUA) es permitirles a los alumnos de la Unidad Académica de Ingeniería de la UAGro dar de alta las unidades de aprendizaje ofertadas por trimestre en el programa educativo elegido por los estudiantes. El SAUA permitirá agilizar el alta de las unidades de aprendizaje que los alumnos elijan del programa educativo al que pertenezcan.

2. Ingeniería de requerimiento

Una de las primeras etapas del proceso de desarrollo de software es la ingeniería de requerimientos; en esta fase se definen y especifican los requerimientos de los clientes y usuarios. Las actividades involucradas en la ingeniería de requerimientos son la obtención, el análisis, la especificación, la validación y la administración de los requerimientos de software [6].

Los requerimientos de software se definen como las necesidades de los clientes, los servicios que el usuario desea que proporcione el sistema y las restricciones sobre las que el software debe operar. El resultado del proceso de requerimientos es la base para el diseño, la implementación y la evaluación del software. De esta forma, si no se descubren y especifican todos los requerimientos del sistema en desarrollo, podría conducirnos a la entrega de un producto de software incompleto, con alto índice de riesgos y poco funcional [1], [5].

A pesar de los avances en la ingeniería de software, existe una gran cantidad de desarrolladores que no hacen uso de procedimientos y actividades que proporciona dicha ingeniería en el desarrollo de sistemas; esto provoca que un gran número de proyectos de software sean abandonados en pleno proceso de desarrollo o que sean entregados con retrasos y a costos mayores que los estimados. A esta problemática se le une el hecho de que existe una gran cantidad de métodos y técnicas que, lejos de ser estándares, confunden más a los desarrolladores y dificultan la definición de los requerimientos [1].

A continuación se presenta la definición que aparece en el glosario del Institute of Electrical and Electronics Engineers (IEEE) [7].

1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 2. 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. 3. Una representación documentada de una condición o capacidad como en 1 o 2. Un requerimiento de software se puede definir como:

• Una capacidad del software la cual el usuario requiere para resolver un problema o alcanzar un objetivo.
• Una capacidad del software que debe ser reunida o poseída por un sistema o componente del sistema para satisfacer un contrato, especificación, estándar u otra documentación formal.

Las tareas más complejas para los ingenieros o especialistas de software en el proceso de ingeniería de requerimientos son:

1. Tratar con la naturaleza del sistema y comprender su ambiente.
2. Encontrar los componentes y su interacción dentro del sistema.
3. Definir los servicios que el sistema debe ofrecer al usuario.
4. Definir las restricciones o limitantes del sistema.

Estas tareas definen los problemas de la ingeniería de requerimientos que deben enfrentar los desarrolladores y analistas de software. El proceso de descubrir, analizar, documentar y verificar los servicios y restricciones del sistema solo se logra utilizando las técnicas definidas por la ingeniería de requerimientos.

2.1. El proceso de ingeniería de requerimientos

El proceso de ingeniería de requerimientos involucra todas las actividades necesarias para crear y mantener el documento de requerimientos del sistema. Para realizar este proceso es necesario obtener previamente un análisis de factibilidad que indique si es pertinente continuar con el desarrollo del sistema, además de conocer las necesidades del cliente para tener un contexto general del sistema.

Las actividades que se definen en el proceso de la ingeniería de requerimientos son las siguientes:

1. Obtención de los requerimientos.
2. Análisis de requerimientos.
3. Especificación de requerimientos.
4. Validación del documento de especificación.
5. Administración de requerimientos.

En la figura 1 se muestra la interacción entre las actividades del proceso de ingeniería de requerimientos utilizando el paradigma de cascada, tal como el Documento de Definición de Requerimientos (DDR) y el Documento de Especificación de Requerimientos (DER), en el cual cada actividad tiene un regreso a la actividad anterior. Se parte del hecho de que existe una definición general del problema y de un análisis de factibilidad que indica la continuación del desarrollo del software. De esta manera, el proceso de ingeniería de requerimientos inicia con la actividad de la obtención de los requerimientos, mediante la revisión de la información existente en manuales y documentos y entrevistas a los usuarios para descubrir y analizar los requerimientos. La especificación y validación son actividades que pueden repetirse cuantas veces sean necesarias hasta lograr el nivel de refinamiento en que se deseen especificar los requerimientos. Finalmente, cada cambio en los requerimientos se administra en versiones del Documento de Especificación de Requerimientos.

2.2. Actividades del proceso de ingeniería de requerimientos

El objetivo de la ingeniería de requerimientos es obtener un documento formal en el que se especifiquen las características que debe cumplir el sistema que se va a desarrollar. Estas características y restricciones se definen en común acuerdo por el cliente y los usuarios del sistema [1]. La especificación de los requerimientos debe cumplir con características de calidad como:

• Entendibles,
• Necesarios,
• Consistentes,
• No ambiguos,
• Completos,
• Verificables,
• Correctos,
• Reales,
• Rastreables y
• Modificables.

En cada una de las actividades del proceso de la ingeniería de requerimientos se llevan a cabo tareas específicas utilizando técnicas de requerimientos, modelos de especificación y herramientas para la administración del documento de requerimientos.

2.3. Obtención de requerimientos

En esta actividad se determina el dominio de la aplicación, se especifican los servicios que debe proveer el sistema, la funcionalidad requerida del sistema y las restricciones de hardware y software. Es indispensable la participación de los usuarios y clientes para la identificación de los requerimientos del sistema (figura 2).

Se debe obtener, como resultado de esta actividad, un documento de definición de los requerimientos, donde se definen las necesidades inicialmente encontradas, lo que no significa que estos requerimientos sean los definitivos; pueden agregarse nuevos requerimientos conforme se vayan encontrando o incluso los requerimientos establecidos pueden modificarse o eliminarse. Para lograr la obtención de los requerimientos se definieron tareas que seguir, las cuales se mencionan a continuación:

1. Comprender el problema que se está resolviendo; es necesario estudiar el dominio o entorno en el que el sistema va a operar.
2. Buscar y recolectar información de manuales de operación y mantenimiento, de manuales organizacionales y políticas de operación.
3. Definir los límites y restricciones del sistema con el fin de determinar con exactitud qué es lo que el sistema va a hacer y también especificar lo que no va a hacer.
4. Identificar a las personas o usuarios interesados por el sistema, ya que ellos conocen el ambiente en que operará el sistema y pueden ayudar describiendo sus necesidades.
5. Recolectar y clasificar requerimientos; de esta manera los desarrolladores pueden iniciar definiendo un bosquejo del sistema, su funcionamiento básico, y estableciendo el alcance del sistema.

El desarrollo de estas tareas en la obtención de requerimientos se realiza secuencialmente, pero es necesario que cada tarea pueda regresarnos a la anterior, sobre todo si no se descubre la información necesaria en el primer recorrido del diagrama. La figura 3 muestra esta relación. La salida de esta actividad nos conduce hacia el análisis de requerimientos.

2.4. Análisis de requerimientos

Los requerimientos establecidos en el documento de definición son analizados detalladamente por el equipo de desarrollo y negociados con el cliente y usuarios, para decidir los requerimientos que serán aceptados y definirlos de manera conjunta con el fin de homogenizar su interpretación.

El análisis del DDR se lleva a cabo mediante técnicas de revisión y verificación de los criterios de calidad de cada requerimiento definido; este estudio lo realizan los desarrolladores, clientes y usuarios. En el análisis se llevan a cabo las siguientes actividades:

1. Priorizar los requerimientos debido a que pueden existir requerimientos más importantes que otros para los clientes y usuarios, por lo que deben clasificarse e implementarse de acuerdo con su prioridad en el sistema.
2. Encontrar dependencias entre requerimientos y etiquetar los requerimientos con un identificador único, con el fin de poderlos identificar o rastrear en el futuro.
3. Resolver conflictos entre los requerimientos; se pueden encontrar conflictos entre requerimientos mediante la revisión de los criterios de calidad que debe cumplir cada requerimiento del sistema.
4. Negociar con flexibilidad con los demás elementos del equipo que intervienen en el proceso de desarrollo de software, para homogenizar su comprensión, y que de esta forma tanto desarrolladores como usuarios tengan la misma interpretación al momento de leer el documento de requerimientos.

El resultado del análisis es el DDR, en el que se encuentran descritos los requerimientos iniciales del sistema que se va a desarrollar en lenguaje natural; este documento sirve como punto de partida hacia la siguiente actividad del proceso de la ingeniería de requerimientos, por lo que es necesario que no existan requerimientos en conflictos y estén bien escritos. La figura 3 describe este proceso, muestra la interacción de las tareas realizadas y la salida de esta actividad es la entrada a la actividad de especificación de los requerimientos.

2.5. Especificación de requerimientos

En esta actividad se obtiene como resultado el documento de especificación de requerimientos. Este documento contiene la descripción precisa de los requerimientos, incluye modelos de representación que agregan detalles al sistema mostrándolo desde diferentes perspectivas. Para el desarrollo de esta actividad se realizan las siguientes tareas:

1. Especificar los requerimientos funcionales y no funcionales; ambos requerimientos deben describirse con detalles para su mejor comprensión.
2. Determinar el tipo de estándar por utilizar para la definición del DER. Se define el esquema del contenido del DER con base en el estándar definido por la IEEE.
3. Elegir la herramienta de especificación, en caso de utilizar alguna para automatizar el proceso.
4. Utilizar modelos y diagramas para explicar con mayor detalle y diferentes perspectivas el comportamiento del sistema.
5. Usar cualquier información de soporte o guía para etapas posteriores y que amplíen la comprensión del sistema.

Todas estas tareas van encaminadas a obtener el DER, en el que se especifican las funciones, restricciones o características del sistema en desarrollo. Es necesario contar con toda la información disponible para formar un documento completo y que sirva como base de partida hacia las otras etapas del desarrollo del sistema. En la figura 4 se muestran las actividades de la especificación de los requerimientos del sistema.

2.6. Tipos de requerimientos

Los requerimientos de software son las descripciones de los servicios y restricciones del sistema en desarrollo. Existen diferentes maneras de clasificarlos; generalmente se agrupan de acuerdo con la audiencia a que van dirigidos y con las características del sistema.

2.6.1. Tipos de requerimientos de acuerdo con la audiencia

Existen diferentes niveles de descripción de requerimientos, que permiten orientar los requerimientos a diversos usuarios. Es distinto explicar los alcances de un sistema nuevo a clientes usuarios que ni siquiera van a utilizar el sistema, pero que de alguna forma están involucrados en el desarrollo del sistema, que explicárselos a los desarrolladores o arquitectos de software que se encargarán de la implementación del sistema [5]. Como se observa, se requiere distintos niveles de descripción y, por lo tanto, de diversos tipos de descripción de requerimientos:

1. Los requerimientos del usuario. Se expresan en lenguaje natural utilizando diagramas fáciles de comprender de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales el sistema debe funcionar; también se conocen como requerimientos del cliente o requerimientos C.
2. Los requerimientos del sistema. En estos requerimientos se establecen con más detalle los servicios y restricciones del sistema. También se les conoce como especificación funcional, requerimientos del desarrollador o requerimientos D.
3. La especificación del diseño del software. Es una descripción abstracta del diseño del software que se utiliza como una base para un diseño e implementación detallados.

Los distintos niveles de descripción de requerimientos se necesitan debido a que informan de manera clara a diferentes tipos de usuarios [5]. Por ejemplo, los requerimientos de usuario, como están expresados en un lenguaje claro, fácil y sin detalles funcionales, se dirigen a clientes administradores, usuarios finales del sistema, clientes ingenieros, contratistas administradores y arquitectos del sistema. Por otra parte, los requerimientos del sistema se dirigen a usuarios técnicos del sistema, clientes ingenieros, arquitectos del sistema y desarrolladores de software.

Debido a su especificación funcional dentro del sistema, se requiere un cierto grado de conocimiento técnico o especialización en el área. Y, por último, la especificación del diseño de software se dirige a clientes ingenieros, arquitectos del sistema y desarrolladores de software.

2.6.2. Tipos de requerimientos de acuerdo con su característica

Esta clasificación se realiza en función de la naturaleza de las características del sistema que se desarrolla; generalmente los requerimientos de sistemas de software se clasifican en funcionales y no funcionales.

1. Requerimientos funcionales. Son declaraciones de los servicios que proveerá el sistema y comprenden la interacción entre el sistema y su ambiente, la reacción a entradas particulares de datos y su comportamiento en condiciones específicas. En algunos casos también declaran lo que el sistema no debe hacer.
2. Requerimientos no funcionales. Son especificaciones de las restricciones de los servicios o funciones ofrecidas por el sistema; estas restricciones limitan las elecciones en la solución a un problema. Los requerimientos no funcionales no se refieren directamente a las funciones específicas que entrega el sistema, sino a sus propiedades emergentes [4].

3. Caso de uso: alta de unidades de aprendizaje y requerimientos del SAUA

El caso de estudio que se desarrolló para la especificación de los requerimientos es el Sistema de Alta de Unidades de Aprendizaje, que les permitirá a los alumnos de la Unidad Académica de Ingeniería de la UAGro dar de alta sus unidades de aprendizaje de manera eficaz mediante el uso de internet. Se obtuvo el Documento de Especificación de los Requerimientos del SAUA, en el que se encuentran expresadas las características y las restricciones del sistema, mediante la aplicación de las actividades concernientes al proceso de ingeniería de requerimientos.

3.1. Descripción general

En este apartado se describe cómo se desarrolla actualmente el Sistema de Alta de Unidades de Aprendizaje que realizan los alumnos de la UAI; se presenta una propuesta para el SAUA, en la cual se definen el propósito y alcance. Se identifican y definen los posibles usuarios interesados en el SAUA con el fin de trabajar junto con el equipo de desarrollo para especificar sus necesidades.

3.2. Descripción del sistema actual

Es necesario describir el proceso actual que los alumnos realizan al dar de alta las unidades de aprendizaje de la UAI, como un punto de partida y referencial para obtener y especificar los requerimientos, también para tener antecedentes y poder contrastar el sistema actual con respecto al alcance del nuevo sistema (SAUA).

El proceso actual de alta de alumnos a las unidades de aprendizaje del programa académico de la UAI se desarrolla tradicionalmente de la siguiente forma:

3.2.1. Selección de unidad de aprendizaje

Se seleccionan las unidades de aprendizaje ofertadas por trimestre, así como los alumnos de mejor promedio, los cuales tienen prioridad de seleccionar y dar de alta sus unidades de aprendizaje.

3.2.2. Cada profesor tiene asignado un número de alumnos

Cuando los alumnos son de nuevo ingreso, se asigna un profesor de base y tiempo completo (a partir de aquí se nombra ““tutor” al profesor asignado) y un número promedio de alumnos que regularmente es de seis. Esta asignación es de acuerdo con el programa educativo (PE) que el alumno pretende seguir, y se lleva a cabo con el fin de que los alumnos tengan una guía y asesoría personalizada en la elección de los cursos en su currículo del programa de licenciatura, es decir, una orientación general del panorama académico. El asesor es el mismo durante el tiempo que dura el programa educativo. Puede haber cambios pero estos se consideran casos especiales.

3.2.3. La academia y la administración de la UAI realizan la programación de cursos de acuerdo con el reglamento y el programa educativo

Según el currículo del PE, la academia de profesores y la administración de la UAI programan los cursos que pueden impartir en el presente trimestre. Esta programación se lleva a cabo con base en un programa educativo y un reglamento de la UAGro.

3.2.4. El tutor apoya sugerir a los alumnos unidades de aprendizaje, de acuerdo con el perfil universitario

Después de tener el currículo de los cursos que se van a impartir en todo el año, el tutor toma como base la formación académica del alumno para guiarlo en su formación académico-profesional. Otro punto que se revisa es que los alumnos cubran las unidades de aprendizaje del programa de licenciatura.

3.2.5. El alumno y el tutor revisan el currículo de los cursos

Los alumnos son llamados a entrevistas personales con sus tutores. El objetivo es programar las unidades de aprendizaje que llevará en el transcurso del trimestre del programa educativo; esta programación se realiza tomando en cuenta también la previa selección; el tutorado recibe la orientación de su tutor con más detalle del panorama de su programa de estudio.

3.2.6. Se integra el currículo al expediente del alumno

El resultado de la entrevista es la integración del documento o formato que contiene las unidades de aprendizaje y es entregado al subdirector de control escolar de la UAI, para su autorización, y después al personal administrativo para que realice la asignación de unidades de aprendizaje correspondientes. Una copia de estas inscripciones se integra al expediente del alumno (ver figura 5).

3.2.7. Se integra la asignación previa al expediente del alumno

Toda la información de los alumnos se controla mediante expedientes; generalmente un expediente consta de documentos de antecedentes referentes a cada alumno, lista de unidades de aprendizaje (kardex), programa educativo y otros más; separados en carpetas que se almacenan en un archivero que controla una secretaría administrativa.

3.2.8. Semana para realizar modificaciones

En caso de realizar algún cambio de unidad de aprendizaje, es necesario notificarlo con el tutor o, en ausencia del tutor, con el subdirector de administración de control escolar para la autorización de dicho cambio. El tiempo en el cual se pueden realizar cambios es de tres días.

3.2.9. La información de cada sección se entrega a Servicios Escolares de la UAGro

Después de este proceso, la información de las inscripciones de todos los alumnos se entrega a Servicios Escolares de la UAGro, para su alta al Sistema de Administración y Seguimiento Escolares (SASE), que ya no corresponde al área de control escolar de la UAI.

3.3. Definición de requisitos funcionales

Otra manera de definir los requisitos encontrados inicialmente para el SAUA es usando formas definidas en lenguaje natural estructurado, en el que se incluya la siguiente información (figura 6):

1. Descripción de la función o la entidad por especificar.
2. Descripción de entradas y de dónde se originan.
3. Descripción de salidas y hacia dónde van.
4. Descripción de qué otras entidades se utilizan.
5. Una precondición y una poscondición.
6. Efectos colaterales de la operación.

Con esta información se pretende detallar aún más los requerimientos con el fin de disminuir las dificultades de interpretación que puedan tener los requerimientos.

4. Implementación

Datos de la unidad de aprendizaje que pueden modificarse:

Título de la unidad de aprendizaje, nombre del profesor titular, nombre del profesor auxiliar, horario, días en que se imparte, si es afín a otros programas de estudio, número de alumnos inscritos, edificio y nivel donde se va a impartir.

Datos del profesor que pueden modificarse:

Función, fecha de ingreso, si es permanente o temporal, número de empleado, cubículo donde labora, teléfono de cubículo, extensión, domicilio particular, teléfono particular y las unidades de aprendizaje asignadas.

Datos del alumno que pueden modificarse: nombre, edad, identificación, domicilio actual, colonia, delegación o municipio, código postal, país, estado y teléfono actual. Además, las unidades de aprendizaje en las que está inscrito en el trimestre actual.

Datos que puede modificar de la unidad de aprendizaje: temas de la unidad de aprendizaje, objetivo que cubre el tema, tiempo de duración y temas con los que se relaciona.

4.1. Contexto del SAUA

El sistema SAUA debe permitirles a los alumnos realizar el alta de las unidades de aprendizaje que se imparten en la UAI de la UAGro de manera virtual, es decir que cualquier alumno inscrito en la UAI pueda dar de alta sus unidades de aprendizaje mediante el acceso al SAUA desde cualquier lugar usando internet. Se pretende que el SAUA proporcione un servicio de calidad y se optimicen los tiempos que requiere el alta de manera tradicional, además de reducir la tasa de errores. En las figuras 6 y 7 se presenta una descripción general del funcionamiento del sistema propuesto para el SAUA. Se puede observar la relación general de los componentes del sistema trabajando en conjunto. Se puede apreciar el flujo de información de una manera general. El esquema de interconexión entre el usuario y el servidor se realiza mediante internet.

5. Conclusiones

La ingeniería de requerimientos, como parte del proceso de desarrollo de software, es un puente importante hacia otras etapas, por ejemplo el diseño, la implementación, la validación y el mantenimiento. Esto significa que una descripción completa de los requerimientos garantiza el desarrollo de un buen producto final. Sin embargo, la obtención y especificación de los requerimientos son dos situaciones problemáticas que todo ingeniero de software enfrenta. Por un lado, se busca resolver las diferencias de comunicación, culturales y técnicas que enfrentan los usuarios y los desarrolladores, en el afán de lograr obtener las necesidades y restricciones que definirán el sistema; y, por el otro, la búsqueda de técnicas, métodos, metodologías y herramientas que permitan obtener una especificación de los requerimientos entendible tanto para los clientes y usuarios como para los ingenieros involucrados en el diseño.

La ingeniería de requerimientos se utilizó para el análisis en el desarrollo del caso de estudio SAUA. Cabe mencionar que al aplicarla en este proyecto se logró mejorar el procedimiento de alta de unidades de aprendizaje que hasta la fecha se realizaba de manera manual, con lo cual se logró una forma más eficiente para su elección y alta de unidades de aprendizaje. Así mismo se pretende que para el siguiente ciclo escolar (2012-2013) esta investigación se esté llevando a cabo en la Unidad Académica de Ingeniería de la Universidad Autónoma de Guerrero, en México.

6. Referencias

[1] J. C. Medina, Análisis comparativo de técnicas, metodologías y herramientas de ingeniería de requerimientos. Tesis para obtener el grado de Maestría en Ciencias en la especialidad de Ingeniería Eléctrica, Opción Computación. México, D. F.: Centro de Investigación y de Estudios Avanzados del IPN, 2002.

[2] S. Viller, Analysis for Software Engineering, Technical Report, 1998. Disponible en www.comp.lancs.ac.uk/computing/ research/cseg/98_rep.html

[3] B. Bruegge y A. Dutoit, Ingeniería de software orientada a objetos. Prentice Hall, 2002.

[4] I. Sommerville, Software Engineering, Wiley, 1998.

[5] S. R. Pressman, Ingeniería del software, un enfoque práctico, 4a ed. McGraw Hill, 1998.

[6] L. A. Macaulay, Requirements Engineering. Springer-Verlag, 1996.

[7] IEEE, Definición de Ingeniería de Software. Disponible en http://www.ieee.org.com