SEP SEIT DGIT - CENIDET Martin Gerardo... · felices de mi vida. , A mi madre, por el ejemplo de...

SEP SEIT DGIT

CENTRO NACIONAL DE INVESTIGACI~N Y DESARROLLO TECNOL~GICO

cenidet

PROPUESTA METODOL~GICA PARA LA CAPTURA DE REQUISITOS

T E S I S Que para obtener el Grado de

Maestro en Ciencias de la Computación

presenta MARTÍN GERARDO MARTÍNEZ RANGEL

Director de tesis: DR. JAVIER ORTÍZ HERNÁNDEZ

Cuernavaca, Morelos Noviembre de 2001

Centro Nacional de Investigación y Desarrollo Tecnológico

FORMA C3 REVISION DE TESIS

Cuernavaca, Morelos a 6 de noviembre de 2001

Dr. Raúl Pinto Elías Presidente de la Academia de Ciencias Computacionales Presente

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: PROPUESTA METODOLOGICA PARA LA CAPTURA DE REQUISITOS, realizada por el C. Mart in Gerard0 Martínez Rangel, y habiendo cumplido con todas las correcciones que le fueron indicadas, acoidamus no tener objeción para que se le conceda la autorización de impresión de la tesis.

Sin otro particular, quedamos de usted.

Atentamente

c.c.p. Dr. Ro'dolfo A. Pazoc Rangel/Jefe del Departamento de Ciencias Computacionales

hlERlOR h l E R h A D O P A L M RA S/N C O f R h A V A C A M O R M É X CO A P A R l A D O P O S l A L 5-164 C P o2050 C C L R h A V A C A TELS. (73112 2314.12 7613.18 7741. FAX (731 12 2434 cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico

FORMA C4 AUTORIZACION DE IMPRESIÓN DE TESIS

Cuernavaca, Morelos a 9 de Noviembre de 2001

C. Martin Gerard0 Martinez Rangel Candidato al grado de Maestro en Ciencias de la Computación Presente

De’spués de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: PROPUESTA METODOLOGICA PARA LA CAPTURA DE REQUISITOS, ‘me es grato comunicarle, que conforme a los iineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Atentamente

- Dr. Roddo A. Pazos Rangel

Jefe del Depto. de Ciencias Computacionales

INTERIOR INTERNADO PALMIRA S I N , CUERNAVACA. MOR MEXICO APARTADO POSTAL 5-164 CP 62050, CUERNAVACA. TELS. [73)12 2314.12 7613 ,I8 7741, FAX (73) 12 2434 cenidet

AGRADECIMIENTOS

Primeramente al creador por darme la oportunidad de reencontrarlo en momentos felices de mi vida.

,

A mi madre, por el ejemplo de coraje y determinación por salir adelante mediante

el trabajo en los momentos mas críticos de nuestras vidas, y sobre todo por

respetar siempre nuestras decisiones.

A Tere, mi esposa, por apoyarme siempre y por estar conmigo en todo momento,

y sobre todo por recordarme siempre a Io largo de nuestro matrimonio el

compromiso que tenía con el CENIDET y conmigo mismo de graduarme pronto.

A mis dos preciosas y pequeñitas hijas: Diana Sofía y Alexa Mariana. A ti Diana Sofía por ser el primer motorcito que impulso mi vida profesional y por manifestar

a tu corta edad ese gusto por el estudio y la ciencia. Y a ti Alexa Mariana por venir a confirmar mi sentido de ser en esta vida.

A la Secretaría de Educación Pública y al Centro Nacional de Investigación y

Desarrollo Tecnológico por la beca SEP recibida a traves de la Dirección General de

Institutos Tecnológicos para terminar mis estudios de maestría.

A Javier Ortiz Hernandez. Director de este trabajo de tesis, quien siempre me

motivó y apoyo en todo para seguir adelante con este trabajo de tesis y por la amistad con la que me distingue.

A mis revisores de tesis, Máximo López Sánchez y René Santaolaya Salgado, quienes se dieron a la tarea de leer todas las versiones de este trabajo de tesis y cuyas valiosas observaciones permitieron el. desarrollo y escritura del mismo. No puedo dejar de mencionar en especial a Olivia Fragoso por el apoyo que me brindó para terminar este trabajo de tesis. A los tres gracias por brindarme su amistad.

AI Instituto Tecnológico de Zacatepec, el cual me formó primeramente como Técnico y posteriormente como Ingeniero durante ocho años. Tiempo que

recuerdo con mucha gratitud.

A todos mis compañeros y compañeras, y amigos y amigas que me distinguen con

su amistad y a quienes no menciono para no omitir a ninguno (del CENIDET, del

iTZ, de la UAEM, del IIE, de Telmex, de la Unisol, etc), a todos ustedes gracias.

A los que se encuentran lejos (Manuel Adams, Carlos Astorga y Hugo Estrada y

esposa) también gracias por su amistad y consejos.

A Gerard0 Reyes y esposa por animarme a seguir adelante, a mis suegros por el

apoyo recibido, a mis hermanos y cuñados, a mis compadres Fortunato Solares y esposa por la amistad de siempre, a mis queridos alumnos por darme la

oportunidad de confirmar día a día mis conocimientos ante ustedes.

Este trabajos de tesis fue apoyado por los siguientes proyectos:

1. Proyecto: "Ingeniería de Requerimientos de software: IRIS", proyecto CONACrr clave 28953a

2. Proyecto: "Ingeniería de Requerimientos de software: IRIS", proyecto

COSNET clave 761.99-P.

3. Proyecto apoyado por C O N A M con la clave 32042-A

4. Proyecto apoyado por Cosnet con la clave 759.99P

CONTENIDO

Capítulo 1 Introducción 1.1 Antecedentes .................................................................................................... 1.2 Description del problema ................................................................................... 1.3 Propuesta de solucion ....................................................................................... 1.4 Objetivos ........................................................................................................... 1.6 Beneficios ......................................................................................................... 1.7 Alcances y limitaciones :

2.1 Introduccion .................................................................................................... 2.2 Trabajos relacionados ................................... : ...................................................

2.2.2 Herramienta para la captura de requisitos de los usuarios .............................. 2.2.3 Un método de trabajo para auxiliar la definición de requisitos ........................

2.3 Conclusiones ....................................................................................................

.. ..

. . 1.5 Metodología de solucion .................................................................................... . . . ............................ .........................................................

Capítulo 2 Estado del arte ..

2.2.1 Teoría de la actividad:"ün marco de trabajo para la captura de requisitos .......

Capítulo 3 Marco teórico Capítulo 4 Propuesta metodológica

4.1 Modelo de proceso para la captura de requisitos ........... ; ..................................... 4.2 Componentes de la metodología propuesta ........................................................

4.2.1 Búsqueda de hechos ............................................................................... 4.2.2 Obtencion de requisitos ............................... ; ........................................... 4.2.3 Evaluación y'razonamiento de requisitos ................................................... 4.2.4 Asignacion de prioridades .................... ................................................... 4.2.5 Integracion y validacion ........................................................................... 4.2.6 Representación del conocimiento adquirido .................................................

.. .. . . ..

Capítulo 5 Aplicación de la metodología en un escenario real 5.1 Antecedentes .................................................................................................. 5.2 Búsqueda de hechos ....................................................................................... .. 5.2.1 Analisis operacional .................................................................................

5.2.2 Analisis del problema ............................................................................... 5.2.3 Analisis organizacional ...................................................................... ; ...... 5.2.4 Identificación de la partes afectadas ......................................................... 5.2.5 Resultados obtenidos de la búsqueda de hechos ........................................

. .

. .

. . 5.3 Obtencion de Requisitos .................................................................................. 5.4 Evaluación y Razonamiento de requisitos ......................................................... 5.5 Asignacion de prioridades ................................................................................ 5.6 Integracion y validacion .................................................................................. 5.7 Representación del conocimiento ..................................................................... 6.1 Evaluacion de la metodología ............................................................................. 6.2. Resultados obtenidos ...................................................................................... 7.1 Conclusiones .................................................................................................. ,7.2 Trabajos futuros ..............................................................................................

Referencias Bibliográficas ...............................................................................................

.. . . ..

Capítulo 6 Pruebas y resultados

Capítulo 7 Conclusiones y trabajos futuros

..

Pág . 1 2 3 4 4 5 6 6 7 8 9 9 11 12 13 15 26 27 32 33 35 37 38 39 40 43 44 44 44 46 50 53 53 55 58 65 66 67 70 71 75 77 78 79 80

Lista de figuras

2-1 Proceso de venta ....................................................................................... I 11 I . 3-1 Ingeniería de requisitos como un proceso iterativo ................................... 24

4-1 Modelo de la propuesta rnetodológici para la captura de requisitos ........ 29 4-2 Descripcion de un escenario ............... ! ...................................................... 42

5-2 5 1

. .,

5-1 Análisis organizacional a nivel Gobiemo Federal-IES ............................. 50 Análisis organizacional a nivel IES .... 1 ......................................................

I

Lista de tablas I I I . .

4-1 5-1 Escenario para la actividad de pago de solicitud ....................................... 6-1 requisitos ............................................................ I ....................................................

Tareas que comprende el modelo de proceso para la captura de requisitos

Evaluación de las técnicas de acuerdo

31 69

74 su utilidad en el proceso de captura de

. .

I

Cenidet Cap. 1. Introducción

cdbz'tulo 1 Introducción

Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.1

Cenidet Cap. 1. Introducción

1.1 Antecedentes

Para el éxito en el desarrollo de sistemas de información es esencial tener

una comprensión completa de los deseos y necesidades de los usuarios que deben

satisfacerse. La definición de requisitos es una evaluación cuidadosa de las

necesidades que un sistema debe cubrir, se trata generalmente de un documento

que debe decir porqué un sistema es necesario dadas las condiciones actuales y

anticipadas [Greenspan94]. El reconocimiento de la naturaleza crítica de los

requisitos estableció la ingeniería de requisitos como un sub-campo de la Ingeniería de Software.

La ingenien2 de requ/sitosestá determinada principalmente por: la dificultad

para caracterizar la organización y su medio ambiente inmediato, la dificultad para

modelar las restricciones de la organización que inhiben o controlan su función; la

diversidad de recursos tecnológicos y humanos disponibles para un determinado

contexto; y la flexibilidad, robustez, mantenibilidad y calidad requeridas. El campo

de la ingeniería de requisitos emerge como una sub-área de la ingeniería de

software, ayudando a que la fase de requisitos en el desarrollo de sistemas de

software sea más sistemática y disciplinada [Yu95al.

La ingenien2 de requ/sitos de sohare tiene por objetivo analizar y

documentar los requerimientos de software. Esto involucra crear particiones de los requerimientos del sistema en subsistemas y tareas para permitir mapearlos al

software. En este proceso también se realiza la transformación de requerimientos del sistema en descripciones de requerimientos de software. A traves del análisis, diseño y prototificación se van a conocer qué datos deben ser automatizados o no [Thayeer97], en este sentido el proceso de captura de requisitos dentro de la ingeniería de requisitos presenta una opción que permite satisfacer las demandas de información que se tienen de un sistema en construcción.


Cap. 1. Introducción Cenidet

La ingeniería de requisitos comprende actividades de captura de requisitos,

análisis, especificación y validación. Hoy en día, la mayoría de los métodos, técnicas y herramientas para trabajar con requisitos están enfocadas

especialmente a la parte de especificación, por ejemplo la representación de requisitos, dando por sentado que la captura de requisitos se da de manera natural

y que éstos se encuentran a la mano listos para utilizarse.

La fase de captura de requisitos debe interesarse en las relaciones entre los sistemas y sus ambientes en lugar de colocar los requisitos solamente en términos

de los sistemas de software [Yu95a]. Lo que implica transformar una necesidad

operacional producto del proceso de captura de requisitos en una descripción del sistema (análisis) y en esta descripción se deben de incluir datos acerca del desempeño de este sistema. Esto es logrado en fases posteriores a la captura de

requisitos mediante el uso de un proceso iterativo de análisis, diseño y prototificación [Thayeer97].

El proceso de captura de requisitos se ha convertido así en eje central para

las otras áreas que intervienen en la construcción de un sistema de información, y es el núcleo de los intereses básicos de representación y razonamiento acerca del conocimiento acumulado durante la fase de captura de requisitos [Greenspan94].

1.2 Descripción del Problema.

Existe un termino en inglés, “requirements elicitation”, que hasta ahora se a visto traducido generalmente como recolección de requisitos, captura de requisitos u obtención de requisitos. Últimamente se empieza a utilizar en el medio científico y profesional Iberoamericano la expresión “elicitación de requisitos” [Goguen97, Galvao99, Laguna99, Duran981. Que hace referencia a un proceso de entrevistas,

reuniones o charlas, en las que un experto de una empresa informática intenta ayudar al cliente a aclarar sus ideas y obtener un catálogo de funciones que deben de ejecutar los programas que la empresa informática le va a desarrollar.

Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.3


Los desarrolladores que apoyan el término "elicitación" indican que el significado del verbo "elicit" en inglés es demasiado rico en matices como para limitarlo a "recolectar", "capturar" u "obtener". Sin embargo hasta ahora no se conoce otro significado dentro de la literatura de la ingeniería de requisitos, por Io que a partir de este momento el término "requirement elicitation" se utilizara como

"captura de requisitos", el cual, como ya se mencionó anteriormente hace

referencia al 'broceso de entrevistas, reuniones o charlas en las que un experto de

una empresa informática intenta ayudar al cliente a aclarar sus ideas y obtener un catálogo de funciones que deben de ejecutar los programas que la empresa informática le va a desarrollar". Lo anterior permite describir claramente el

problema que se trata en esta tesis, en cuanto a que los requisitos que se consiguen muchas veces son incompletos, mal entendido y ambiguos.

1.3 Propuesta de solución

Como solución al problema de la captura de requisitos se propone una metodología que haga uso de las herramientas existentes para llevar a cabo

entrevistas, reuniones o charlas, con el objeto de buscar información y recopilar

hechos, así como representar el conocimiento adquirido. Esta metodología está

basada en un modelo de proceso de captura de requisitos de software que se presenta como parte de la misma solución en este trabajo de tesis. Las

herramientas que se integraran en la metodología serán aquellas donde exista referencia de su utilidad y eficacia, incorporando las ventajas que cada una de

ellas tienen y que son Útiles para la recuperación de información, las cuales puedan ser derivadas de acuerdo a los atributos que debe contener el sistema a

desarrollarse.

1.4. Objetivos

A continuación se mencionan los objetivos que se pretenden lograr con este trabajo de tesis:


*',b


1) Proponer una mefodo/ogia para /a aptura de requisitos en la que se pueda apoyar el responsable de la captura de requisitos para esclarecer los deseos y necesidades que tienen los usuarios respecto a un sistema de información durante el proceso de captura de requisitos.

2) Sentar las bases para que se puedan realizar a futuro otros trabajos de investigación que permitan sistematizar la captura de los requisitos dentro

de la ingeniería de requisitos.

1;s Método de solución

La metodologia de solución que se propone a utilizar para el logro de este

trabajo de tesis esta compuesta por varias estrategias las cuales se describen a continuación.

ESTRATEGIAS

1) Describir el estado del arte en el área de la ingeniería de requisitos, en

particular describir los trabajos principales relacionados con el proceso de captura de requisitos.

2) Desarrollar un modelo de proceso para la captura de requisitos como parte

de la metodología que se propone, ubicando las herramientas que son Útiles en la búsqueda de hechos, recuperación de información y representación del conocimiento adquirido a lo largo del proceso según sea el caso.

3) Describir los criterios que se puedan utilizar para evaluar la metodología

para la captura de requisitos propuesta en este trabajo de tesis. 4) Presentar un caso de estudio donde se aplique la metodología para la

captura de requisitos.

5) Documentar los resultados obtenidos del caso de estudio.

Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.5.

cap. 1. Introducción Cenidet

1.6 Beneficios

El desarrollo de un modelo de proceso y una metodología para la captura de

requisitos, permitirá a los responsables de la especificación de requisitos de

software, clarificar los deseos y necesidades de los clientes respecto al sistema de información a construir, contribuyendo con esto a que los requisitos encontrados

sean completos y mejor entendidos por todos los actores que participan en la construcción de un sistema de información.

Adicionalmente este proyecto permitirá continuar con una línea de

investigación en modelado de procesos de negocio, dentro del campo de la ingeniería de requisitos. Donde una problemática particular es la búsqueda de

información y de hechos como parte de la tarea de captura de requisitos.

1.7 Alcance y Limitaciones

La propuesto metodológica que se propone está enfocada exclusivamente al

área de problemas que concierne a la búsqueda de hechos, obtención de información, su integración y representación del conocimiento adquirido, en un

orden tal que permitan encontrar soluciones a los problemas encontrados en el

proceso de captura de requisitos como una extensión del trabajo que se presenta en [Mittermeir90 y Christel921.


, . . , ~; .. . . , . ,.,.,, . ,_..~i. ~ .

Cap. 2. Estado del Arte Cenidet

Cupz'tulo 2 Estudo del Arte

En este capitulo, se presenta el contexto en el que se encuentra la tarea de

captura de requisitos para el desarrollo de sistemas de información dentro de la

ingeniería de requisitos.


. . . . . , . - . . . .


2.1 Introducción

Una pregunta fundamental dentro de la ingeniería de requisitos es, cómo

encontrar lo que el usuario realmente necesita. Existen investigaciones donde se

concluye que muchos proyectos fracasan debido a los problemas encontrados

durante el proceso de captura de requisitos de software [GAO 1992, Duran98, Galvao991.

U

Los problemas para la definición precisa de la funcionalidad que un sistema

de información debe tener, se acentúan por el complejo esquema de comunicación

en el que interactúan el usuario y el analista de sistemas o el ingeniero de requisitos durante el proceso de captura de requisitos.

El usuario brinda una concepción de la funcionalidad, aunque podría no estar completamente seguro de ello. El analista por su parte deberá especificar correctamente la funcionalidad a partir de esta primera concepción mediante

aproximaciones sucesivas. Este ambiente de interacción usuario-analista motiva la

búsqueda de estrategias robustas para garantizar que los requisitos del usuario

serán descubiertos con precisión y que además serán expresados en una forma

correcta y sin ambigüedad, además de que sean verificables, trazables y

modificables.

Actualmente existe un creciente reconocimiento de que la tarea de captura de requisitos no es un reto matemático o tecnológico (como Io fue en sus

orígenes), si no que forma parte de un proceso social complejo[Goguen97]. Además de que por lo regular no se trata sino de una aproximación a traves del papel central del analista, quien realiza la recolección de requisitos. Lo anterior ha

provocado que distintos grupos de investigación en el área de la ingeniería de requisitos propongan algunas soluciones o marcos de trabajo que permitan capturar los requisitos. La mayoría de los esfuerzos de investigación señalan el aspecto social, factor central donde se generan las actividades de un proceso y



donde ha de funcionar un sistema de información tal como Io describen Galvao

Martins y Mascia Deltrini [Galvao99] de la Universidad Metodista de Piracicaba, Brasil. Otro trabajo importante dentro de la Ingeniería de requisitos, en donde se concluye que la captura de requisitos esta cada vez más centrada en la parte social que en la parte tecnológica, es el que se describe en [De BortoliZOOO] y que

permite apoyar la definición de requisitos en el proceso de captura de requisitos.

Por otro lado en [Laguna99], se propone un marco para la normalización de la captura de requisitos y su inmediata expresión en forma de activos que sirvan como base para el análisis de los mismos, con el objeto de proveer algún grado de formalización durante este proceso.

2.2. Trabajos relacionados

Dentro de la literatura de la ingeniería de software; mas específicamente dentro de la ingeniería de requisitos se encontraron trabajos relacionados con este tema de tesis. Se describirán aquellos que por su relevancia en cuanto a la captura de requisitos aportan conocimiento al problema a resolver.

2.2.1. Teoría de la actividad: "Un Marco de Trabajo para la Captura de

requisitos"

Entre los trabajos relacionados con este tema de tesis y que sirven como antecedente para el estudio del estado del arte del proceso de captura de requisitos se encuentra Activity Theory: a Framework to Software

Requirements Elicitation, de Galvao Martins y Mascia Deltrini [Galvao 19991 de la Universidad Metodista de Piracicaba, Brazil. Estos autores señalan que la teoría de la actividad fue desarrollada en la sicología y enfocada hacia las practicas

humanas dentro de procesos tanto a nivel individual como a nivel social. Esta teoría se basa en que cualquier acción humana debe ser entendida dentro de un mínimo contexto social establecido por una actividad. De esta forma en [Galvao99] se propone un enfoque para la captura de requisitos dentro de un marco de

Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.9

Cenidet Cap. 2. Estado del Arte

trabajo en donde existen preceptos de la teoría de la actividad, y que constituyen

un conjunto de principios constituidos en un sistema conceptual general.

Los principios básicos de la teoría de la actividad son los siguientes:

1) Principio de actividades entre concesiones.

2) Principio de orientación a objetos.

3) Principio de estructura jerárquica de las actividades

4) Principios de internalización y externalización.

5) Principios de mediación.

6) Principios de desarrollo.

Estos principios no son ideas aisladas, ya que cada uno de ellos está

perfectamente conectado. La naturaleza de la teoría de la actividad esta

manifestada en ese conjunto de principios. De acuerdo a la teoría de la actividad,

una actividad es una forma en la cual un sujeto actúa sobre un objeto, y así mismo

una actividad es descompuesta en acciones, en donde cada acción es

descompuesta a su vez en operaciones. Queda de manifiesto que una actividad es

orientada por una motivación, mientras que una acción es orientada hacia el logro de una o mas metas, así como las operaciones son orientadas por las condiciones.

Esto se puede visualizar en el siguiente ejemplo: en donde se descompone una actividad denominada proceso de venta, tal y como se describe en la fig. 2-1.

Esta forma de representar el conocimiento permite lograr que el analista

responsable de capturar los requisitos de software tenga una idea clara de lo que el sistema ha de realizar. Este enfoque es Útil en tanto no se tenga toda la

información que brota de las fuentes de información dentro de los procesos mismos del negocio. Información que a su vez pueda ser agrupada y

Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Mattínez Rangel Pag.10


caracterizada, para posteriormente aplicar el método que en este trabajo se

propone, lo cual es por demás interesante.

I Actividad

Proceso de venta

Acciones

Emitir la cuenta de la venta

imitir el pago de la venta

Fig. 2-1.Proceso de venta

Operaciones I ~

Llenar los campos del

pago de la venta.

Calcular la tasa de

Imprimir la cuenta de

la venta. I

Dividir la venta en

varios pagos de

acuerdo a las fechas de

vencimiento.

Imprimir los recibos de

pago.

2.2.2. Herramienta para la captura de requisitos de los usuarios

Otro trabajo relacionado con este tema de tesis se describe en [Laguna99], donde se propone un marco de trabajo para la normalización de la captura de requisitos y su inmediata expresión en forma de activos que sirvan como base para

el análisis de los mismos. Esta funcionalidad es expresada inicialmente en términos de casos de uso del negocio y de casos de uso, que luego son traducidos al formato de alguna plantilla en particular. Por ejemplo la plantilla Volere que se describe en [Volere2000], o la que propone Duran Toro en [DurangS].

- - Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.11


La herramienta Propuesta [Laguna991 "A User Requirements Elicitation Tool'' está basada en el uso de flujos de trabajo y redes de Petri para la captura Y normalización de los requisitos funcionales. ' Esta herramienta soporta la

construcción de un sistema de información. Un flujo de trabajo es un modelo de la

logística de los procesos del negocio. Un proceso de flujo de trabajo es realmente

un diagrama que especifica el flujo de tareas que se deben ejecutar en un orden

determinado y bajo condiciones determinadas. Las redes de Petri se han utilizado para expresar la semántica de los flujos de trabajo, donde cada uno de ellos al ser

expresado con una red de Petri se ha denominado un Workflow Net [Van97]. Una

red de Petri permite manipular eventos que son activados bajo condiciones

explícitas. Estas redes han sido ampliamente utilizadas en el modelado de sistemas

cuyo comportamiento es guiado por un patrón de reglas complejas. El marcado de

la red de Petri podría representar la interacción que muestra la secuencia de

estados y no la evolución específica de los casos de uso en conjunto.

2.2.3. Un método de trabajo para auxiliar la definición de requisitos

La captura de requisitos está cada vez mas centrada en la parte social que

en la parte tecnológica, un trabajo importante que viene a sustentar Io antes dicho

es el método de trabajo presentado en [De BortoliZOOO]. El método está

compuesto de tres etapas principales: elicitacion, modelado y validación. La

elicitación o captura de requisitos no es mas que la adquisición de conocimiento

sobre el sistema de información sujeto a estudio. Dicho conocimiento adquirido es

traducido y representado de manera gráfica en la etapa del modelado para que posteriormente sea validado en la Última etapa.

Durante el proceso de captura se utilizan diversas técnicas tales como entrevistas, observaciones y un abordamiento basado en etnográfia, análisis de

protocolos, etc. El método propuesto por De Bortoli y Alencar Price de la Universidad Federal de Rio Grande, Brasil, tiene por objetivo realizar una tarea anterior a la definición de requisitos de software que es precisamente la tarea de



captura de requisitos. En esta tarea se busca la adquisición de conocimiento de las

situaciones y 10s hechos que componen a los sistemas de información dentro de

una organización.

según quienes Proponen el método [De Bortoli2000], el principio básico que deben tener 10s desarrolladores,de software es un conocimiento total sobre el ambiente en el cual ha de funcionar el sistema, y que les permita proponer una

solución automatizada o computarizada. De acuerdo al método propuesto, la

primera actividad dentro del proceso de captura de requisitos consiste en

identificar las fuentes de información utilizando entrevistas estructuradas y

obteniendo como resultado de esta etapa un texto. En la segunda actividad dentro

de la tarea de captura de requisitos se tiene que colectar la información mediante

las observaciones, lectura de documentos, abordamiento etnográfico y entrevistas.

El resultado de estas dos actividades es la representación textual del conocimiento

adquirido, elemento principal y de mucha utilidad para la tarea de modelado que

se realizará utilizando diagrarnas de flujo de trabajo, y cuyo resultado será la

representación gráfica del conocimiento adquirido durante la etapa de captura de

requisitos. Por Último, se presenta la tarea de validación en tres fases: validación individual que consiste en una comprobación informal, la validación general

mediante la técnica de reunión estructurada, y validación del léxico ampliado del

lenguaje utilizado mediante una comprobación informal.

2.2.4. Conclusiones

AI parecer las relaciones sistémicas vistas desde el punto de vista de las actividades, contribuyen a una captura de requisitos más cuidadosa, una vez que la persona responsable de la captura de requisitos o ingeniero de requisitos tenga en cuenta los elementos que son necesarios para la comprensión de un problema. Tales elementos son: el problema mismo a resolver, herramientas de la mediación o herramientas que permitan llegar a acuerdos, objetos y relaciones, comunidades de participantes, reglas del trabajo y división del trabajo. Los trabajos presentados

Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martínez Rangel Pag.13


con antelación permiten identificar a cada uno de esos elementos, Cada uno de ellos aborda la problemática del proceso de captura de requisitos tratando de

aportan conocimientos que permitan de algún modo resolver los problema encontrados en la definición de requisitos. Se percibe que la mayoría de las

propuestas están mas orientadas a la representación y especificación de requisitos que a la captura de los mismos, dando por sentado que estos se encuentran a la mano y listos para utilizarse. Es precisamente en este Último aspecto donde este

trabajo de tesis encuentra su fortaleza, ya que la captura de requisitos es vista

como un proceso evidentemente social donde se recupera información mediante

herramientas ya probadas que permiten trabajar en grupos. Mediante el marco de trabajo o metodología que se propone "Metodología para la Captura de

Requisitos", se puede caracterizar la información colectada a partir de los procesos donde han de funcionar los sistemas de información, poniéndola a disposición del ingeniero de requisitos, responsable de la especificación del sistema a desarrollar.

Esta información se puede registrar en alguna de las plantillas propuestas como lo es la plantilla de Volere [VolereZOOO] o la que Propone Amador Duran Toro de la Universidad de Sevilla[Duran98]. La finalidad de la plantilla es dar formato a la información colectada. Se trata de un trabajo posterior a la captura de requisitos, garantizando que los requisitos del usuario serán descubiertos con precisión y que

además sean expresados en una forma correcta y sin ambigüedad.


Cap. 3. Marco Teórico Cenidet

En este capítulo, se presenta el contexto que involucra la resolución del problema planteado en esta tesis.

Propuesta Metodología para la Captura de Requisitos Ing. Martín G. Martinez Rangel Pag.15

La ingeniería de software es una ramificación de la ingeniería de sistemas

que refiere al desarrollo de los sistemas intensivos de software, lógicos, grandes y

complejos. La ingeniería de software se enfoca hacia las metas del mundo real y a los servicios que proporcionan los sistemas que se desarrollan, así como a la especificación exacta de la estructura y del comportamiento del propio sistema. La puesta en practica de estas especificaciones, también se refiere a los procesos, a

los métodos y a las herramientas para el desarrollo de los sistemas intensivos del

software de una manera lógica, económica y oportuna.

El proceso de desarrollo de software consiste en una serie de pasos bien definidos, que seguidos adecuadamente, conducen a un software mantenible y bien diseñado. Aún así, muchas organizaciones olvidan las fases de captura de requisitos, análisis y diseño a favor de comenzar inmediatamente la implementación de código. Es ma5 positivo pensar en el desarrollo de software, no

como un proceso lineal, sino como un ciclo iterativo. Aunque el paso de una fase a otra se realiza en un sentido, también pueden existir vueltas atrás en determinados momentos, especialmente cuando aparecen requisitos de usuario ocultos en las primeras fases.

La Ingeniería de Requisitos es una area dentro de la Ingeniería de Software, la

cual procura sistematizar el proceso de la definición de requisitos. Este proceso es considerado actualmente como una tarea crítica dentro del ciclo de desarrollo de

software. La sistematización de este proceso es necesaria porque la complejidad de los sistemas actuales exigen que se preste mayor atención al correcto entendimiento del problema antes de comprometer una solución. Para que la definición de requisitos sea lo mas eficaz posible, es necesario que los Ingenieros de Software entiendan el

ambiente en el cual el software funcionará y escoger el modelo o modelos que mejor representen tal ambiente. La etapa de captura de requisitos es considerada como la actividad más importante, decisiva y al mismo tiempo crítica para el desarrollo de software.

Propuesta Metodología para la Captura de Requisitos Ing. Martin G. Martínez Rangel Pag.16

Cenidet Cap. 3. Marco Teórico

Los problemas de captura de requisitos pueden ser agrupados en tres grandes categorías según [McDermid89].

PROBLEMAS DE ALCANCE. En el cual, los requisitos pueden ser encontrados con muy poca o mucha información, y tienen que ver con:

> Los límites del sistema mal entendidos.

9 información de diseño innecesaria proporcionada.

Las técnicas de captura de requisitos, necesariamente deben ser

suficientemente amplias para establecer los límites para el sistema en desarrollo, más aún, deben enfocarse sobre las actividades para la creación de requisitos,

más que a las actividades de diseño, evitando puntos contextuales que puedan conducir a requisitos que sean incompletos, no verificables, innecesarios e inútiles.

El enfoque muy amplio sobre las actividades de diseño impropiamente enfatizadas por los desarrolladores, por encima de las necesidades de los usuarios puede resultar en requisitos muy pobres.

La captura de requisitos debe comenzar con un análisis organizacional y de contexto para determinar los Iímites,del sistema a construir, así como también para determinar los objetivos del sistema dentro del medio ambiente en el cual ha de

desenvolverse. Las metodologías para la captura de requisitos deben aplicarse de

manera correcta sobre a lo que a estas conciernen en cuanto a la búsqueda,

recolección y representación del conocimiento adquirido para que los requisitos capturados se ajusten a las metas de los usuarios y así mismo estas metas se vean reflejadas en el sistema a desarrollar.

PROBLEMAS DE ENTENDIMIENTO o COMPRENSION. Esto se da dentro del contexto de entendimiento entre los participantes, que se ve caracterizado por los distintos lenguajes utilizados durante el proceso de captura de requisitos, los problemas que tienen que ver con esto son:

~~

Propuesta Metodología para la Captura de Requisitos Ing. Martin G. Martinez Rangel Pag.17


9 Los usuarios tienen un incompleto entendimiento o comprensión de sus necesidades.

9 Los usuarios tienen una pobre comprensión de las capacidades y limitaciones acerca de las computadoras.

k Los analistas’tienen un pobre entendimiento del dominio del problema.

9 Los usuarios y los analistas hablan diferentes lenguajes.

9 Es fácil de omitir información.

9 Conflictos de puntos de vista entre los diferentes participantes (usuarios).

k Los requisitos son frecuentemente vagos, casi imposibles de comprobar.

Existen tres aspectos importantes que se tienen que considerar en cuanto a los problemas de entendimiento y comprensión, que son:

Las comunidades involucradas en la captura de requisitos poseen una

variedad de antecedentes y niveles de experiencia, de tal forma que

el conocimiento que tenga un grupo puede ser extraño para otro grupo. Esto representa una dificultad para el analista de requisitos en el momento de interpretar e integrar la información obtenida de

estos diversos grupos.

El lenguaje usado para expresar los requisitos de estas comunidades

de usuarios, puede ser demasiado formal o informal para encontrar las necesidades de cada uno de estos grupos; una vez mas debido a la diversidad de estas comunidades.

Se obtiene una gran cantidad de información durante la captura de

requisitos, lo cual parece normal, pero se requiere que ésta sea estructurada de alguna forma, la comprensión de esta estructura



depende de las características de la organización y de las comunidades participantes dentro del proceso de captura de

requisitos.

Los problemas de comprensión necesariamente resultan de la involucración

de todos los grupos de gentes que participan en la captura de requisitos; ya que estos son producidos e interpretados por la gente con diferentes niveles de experiencias y educación o formación , la forma en que los requisitos son

expresados y el tamaño de los sistemas descritos por los requisitos también afectan la comprensión. Si los participantes en la captura de requisitos no comprenden adecuadamente la salida de los procesos, los requisitos que resulten pueden ser , ambiguos, inconsistentes e incompletos, lo que se traduce en

requisitos incorrectos, no enfocados de una manera adecuada hacia las necesidades de las comunidades de donde se capturaron los requisitos.

PROBLEMAS DE VOLATILIDAD. Se refiere a los cambios naturales en los

requisitos, el principal problema refiere que:

> Los requisitos evolucionan de manera natural a través del tiempo.

El cambio de requisitos durante el tiempo que toma el desarrollar un sistema de información se da de manera natural debido a que las necesidades

de los usuarios pueden madurar a causa de que el conocimiento obtenido sobre el sistema a desarrollar va en aumento, pero también es común que los

requisitos puedan cambiar a un nuevo conjunto de necesidades debido a imprevistos organizacionales o por presiones del medio ambiente. Si tales cambios no son direccionados de manera correcta, el conjunto de requisitos

puede llegar a ser incompleto e inconsistente con la nueva situación, y potencialmente inservibles porque la información capturada ha llegado a ser obsoleta. Una de las causas que generan el problema de la volatilidad de los requisitos es que las necesidades de los usuarios evolucionan con el tiempo [Sage90], Otra causa es que los requisitos son producto de la contribución de



muchos individuos, y estos individuos frecuentemente tienen conflictos entre sus necesidades y metas. Por ejemplo, es usual que haya más de un usuario tenga duda acerca de Io que se quiere, ya que frecuentemente los usuarios

tienen diferentes puntos de vista e intereses contradictorios. [Dubois 881.

La complejidad de la organización, es otra causa de la volatilidad de 10s requisitos, las metas de la organización, políticas, estructuras y roles de trabajo de los usuarios finales pueden cambiar durante el curso del desarrollo de un sistema, especialmente si el número de usuarios afectados por el desarrollo de los sistemas incrementa.

Los procesos de la ingeniería de requisitos para la captura, especificación y validación no deben ejecutarse solamente una vez durante el desarrollo de un

sistema, sino que deberán ejecutarse de una manera iterativa para que los requisitos reflejen el nuevo conocimiento ganado durante la especificación,

validación y subsecuentes actividades-Un proceso interactivo durante la captura de los requisitos puede direccionar de manera adecuada los problemas de volatilidad que se presentan [Dubson 921. Una metodología de requisitos debe ser iterativa

para que las soluciones que se planteen puedan ser retrabajadas a la luz del conocimiento aumentado [Macavlay 90.1

La captura de requisitos debe comenzar con un análisis organizacional y de contexto (modelado del negocio) para determinar los límites del sistema a construir, así como también para determinar los objetivos del sistema dentro del medio ambiente en el cual ha de desenvolverse. Un análisis organizacional y

contextual permite que estas metas sean capturadas y sirvan para verificar que los requisitos sean desde luego, Útiles y correctos,

Existen al menos tres grandes contextos que afectan a los requisitos y a los procesos de la ingeniería de requisitos para un sistema propuesto:

Propuesta Metodología para la Captura de Requisitos Ing. Martín G. Martínez Rangel Pag.20


Contexto Organizacional, se caracteriza porque:

o El interés primario de los clientes no es un sistema basado en computadoras sino, más bien en algunos efectos positivos totales,

que resulten de la introducción de computadoras en su medio ambiente (Dubois 88).

O La captura de requisitos comienza sin una apreciación del contexto

organizacional, lo que provoca que un gran número de restricciones sean asumidas debido a prejuicios , políticas de administración, ignorancia técnica, prácticas añejas ya establecidas, resistencia del personal, etc. (Mittermeir 90).

Contexto del medio ambiente. Los factores del medio ambiente se ven

reflejados cuando:

o Restricciones de Hardware y Software son impuestas sobre el sistema

final.

o El sistema final que se ha de desarrollar, típicamente podrá ser un

componente mas de algún sistema grande y con una organización ya

existente o requerida en el lugar donde ha de funcionar el sistema,

o La madurez del dominio del sistema a desarrollar está en su mejor

nivel.

a Existe una certeza de las interfaces que el sistema a desarrollar deberá tener con el objeto de poder interactuar con él o los sistemas existentes o sistemas más grandes.

Contexto del proyecto. El contexto del proyecto también afecta a los

requisitos y a los procesos de ingeniería de requisitos, los factores que influyen dentro del contexto del proyecto son:



O Los atributos de las diferentes comunidades de gentes involucradas

en el desarrollo de un nuevo sistema, tales como usuarios finales,

patrocinadores, desarrolladores y analistas de requisitos.

O Las restricciones impuestas por la gente involucrada en el proceso de captura, por ejemplo: restricciones administrativas relacionadas con

el costo del tiempo y calidad deseada en el sistema en desarrollo.

La comprensión de la organización, el medio ambiente y el contexto del

proyecto proveen un buen punto de comienzo en la captura de requisitos, y quien o quienes realicen la captura de requisitos no se deben comprometer en otra dirección que no sea la captura, por ejemplo en actividades de diseño. Cuando se tiene una primer versión de la especificación de requisitos, no se deben lanzar las campanas al vuelo, ya que ésta debe ser permanentemente refinada, hasta que la

especificación tenga lugar a partir de los requisitos capturados, aunque en

realidad, las actividades de diseño de alto nivel y las actividades de especificación de requisitos son terminadas de manera simultánea, ya que no se pueden separar los cómo de los qués [Lavi 881.

Se puede considerar como una meta muy loable, el querer separar las actividades de la captura de requisitos de aquellas que tienen que ver con las de

análisis y diseño, pero eso representa una gran dificultad para llevarlo a la práctica, y no es fácil que se pueda lograr esta separación, pero desde luego que

se puede y es muy saludable hacerlo, mas si se hace al comienzo de todo el proceso de construcción del sistema, ya que permite que los requisitos capturados cubran las necesidades de todas las comunidades de usuarios, independientemente del "status" con que éste cuente dentro de la organización.

Durante la captura de requisitos se debe tener especial cuidado, ya que puede ser que los requisitos iniciales puedan ser pobremente especificados, innecesarios e incompletos, o que por Io contrario, que estos sean sobre



especificados, muy completos pero sobrecargados con inútiles restricciones de

diseño.

El análisis de requisitos es un proceso social y las técnicas y métodos que no reconocen este factor, irremediablemente, la gran mayoría fracasan, y tienen

menor oportunidad para obtener toda la información necesaria[Leite97].

Los procesos de la ingeniería de requisitos para la captura, especificación y

validación no deben ejecutarse solamente una vez durante el desarrollo de un sistema, sino que deberán ejecutarse de una manera iterativa para que los requisitos reflejen el nuevo conocimiento ganado durante la especificación,

validación y subsecuentes actividades

La noción tradicional del ciclo de vida del desarrollo de software refiere a que la captura de requisitos debe completarse antes de la etapa de diseño. Ahora la captura de requisitos y la etapa de diseño es vista de manera simbiótica (no se

puede separar). El conjunto inicial de necesidades comienza fuera del proceso de diseño que es gradualmente refinado de una manera sistemática y coherente con los requisitos establecidos.

Debido al problema de comprensión y alcance discutido anteriormente, las necesidades de los usuarios pueden no ser expresados de manera clara en los requisitos, ya que los desarrolladores y el analista de requisitos pueden adoptar

algunas posiciones basadas sobre esas ambigüedades.

Dentro de un proceso interactivo, esas posiciones equivocadas pueden ser detectadas y corregidas rápidamente, por ejemplo, un proceso iteractivo permite que los usuarios reciban retroalimentación mucho más pronto acerca de las interpretaciones por parte del grupo responsable de la captura de los requisitos, Io que permite que los problemas se corrijan tan pronto son encontrados. Muchos acercamientos tradicionales de desarrollo no permiten que ciertas comunidades de participantes, tales como los usuarios reciban retroalimentación de otras

Propuesta Metodología para la Captura de Requisitos Ing. Marth G. Martinez Rangel Pag.23

interpretaciones de otros grupos de participantes, hasta que el sistema esté completo y liberado. Un proceso iterativo de ingeniería de requisitos es ilustrado en la Fig. 3-1.

/ Metas

(entendimiento del contexto) (entendimiento interno)

\ Especificación

Fig. 3-1. Ingeniería de requisitos como un proceso iterativo.

Se ha observado en la norma del IEEE del glosario de la terminología de la ingeniería de software, un incremento de la naturaleza iterativa del desarrollo de requisitos. En el glosario de 1983 “El análisis de requisitos es definido como el

proceso de estudiar las necesidades de los usuarios para llegar a una definición de requisitos del sistema [IEEE83].

Pero esto ha evolucionado en el tiempo, ya que en el glosario de 1990 se ha dado una segunda definición y ha sido añadida al análisis de requisitos: “Es el

proceso de estudiar y refinar sistemas, hardware o requisitos de software”



[IEEEgO]. Esto implica un examen en retrospectiva de los requisitos en pasos de

refinamiento, por ejemplo: un proceso interactivo de ingeniería de requisitos.

Los requisitos no son totalmente conocidos al comienzo del desarrollo de un

sistema, ya que mediante el conocimiento adquirido a Io largo del proceso de captura de requisitos deben evolucionar más allá de la fase de análisis y diseño de

un proyecto. Las comunidades involucradas en la captura de requisitos, incluyendo

usuarios, desarrolladores y clientes, todos ellos pueden aprender y crecer durante

el desarrollo del sistema y durante su mantenimiento. Este incremento de conocimiento obtenido por las comunidades responsables de la captura de

requisitos con respecto al sistema, puede ser utilizado para mejorar el sistema mas que obligar a que los requisitos permanezcan estáticos.


Cenidet Cap. 4. Propuesta metodológica para la captura de requisitos

Capítdo 4 Prqnesta Metodologica para la

En este capítulo, se presenta la propuesta metodológca para la captura de requisitos, tema central de este trabajo de tesis.

Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martinez Range1 Pag.26

Cap. 4. Propuesta metodológica para la captura de requisitos Cenidet

4.1 Modelo del proceso para la captura de requisitos.

El contexto de captura de requisitos dentro del proceso de desarrollo de

sistemas trata de encontrar hechos, obtener información y su integración en un

orden tal que se pueda obtener el conjunto de requisitos que describan un número

de soluciones posibles mediante la representación del conocimiento adquirido.

En este capítulo se describe el modelo en el que se basa la metodología

propuesta para la captura de requisitos y que deberá considerar el analista de

requisitos como una herramienta de apoyo. Los requisitos capturados provienen de

varias comunidades de usuarios, siendo el propio analista el responsable de

comunicar estos requisitos a la comunidad de desarrolladores, adicionalmente a

estas tareas, el analista de requisitos debe asegurarse de que las necesidades de otras comunidades afectadas se vean reflejadas en los requisitos obtenidos y que

una comprensión adecuada o apropiada de estos requisitos sea comunicada a todas las partes involucradas.

El modelo de la metodología propuesta, visto como un proceso, reconoce la importancia de la comunicación entre los diferentes grupos de usuarios, de

acuerdo con el paradigma que subyace en el método IBIS' (Issue Based Information Systems) [Bageman 881.

Aunque reconocer la importancia de la comunicación no es suficiente, las experiencias y motivaciones de los participantes se verán reflejadas en el modelo

para la captura de requisitos mediante la ejecución de actividades que permitiran aprovechar esta diversidad. Un conjunto de estas actividades estará orientado a

El método IBIS, está basado en el principio de que el proceso de diseño para problemas complejos está fundamentado en la conversación entre los participantes (por ejemplo, diseñadores, clientes, e implantadores del sistema) sobre sus respectivas experiencias y puntos de vista para resolver aspectos de diseño que son importantes para que el sistema en desarrollo tenga el éxito deseado.

I

Propuesta Metodológica para la Captura de Requisitos Ing. Marth G. Martínez Rangel Pag.27


los usuarios, mientras que el otro conjunto de actividades estará orientado a los desarrolladores en estrecha comunicación.

Todas las actividades a ejecutarse pueden agruparse en tareas asociadas

para encontrar hechos, obtener requisitos, hacer evaluaciones, razonar sobre los requisitos encontrados, asignar prioridades sobre los requisitos encontrados, lograr

una integración de todo el trabajo desarrollado y su respectiva validación y por Último representar el conocimiento adquirido.

El modelo que sigue la metodología propuesta (fig. 4-1) es muy similar al modelo

de captura de requisitos propuesto por Mittermeir [Mittermeir90] y al propuesto

por Michael G. Christel y Kyo C. Kang [Christel92] pero con dos grandes variantes:

Primero, la asignación de prioridades ocurre después del razonamiento de los requisitos respecto al propuesto por Mittermeir, al igual que en el de Michael G.

Christel y Kyo C. Kang, y segundo, en el modelo que se propone se integr la fase

de representación del conocimiento adquirido y que no se encuentra ni en el

modelo propuesto por Mittermeir ni en el propuesto por Christel y Kyo C. Kang.

Estas variantes obedecen a dos razonamientos lógicos: primero, porque no es

posible asignar prioridades a los requisitos encontrados si antes éstos no son

razonados y evaluados; y segundo, en los modelos propuestos en [Mittermeir90,

Christel921 no se presenta una fase que permita representar el conocimiento

adquirido a Io largo del proceso de captura de requisitos.

Propuesta Metodológica para la Captura de Requisitos Ing. Marth G. Martinez Rangel Pag.28


- requisitos

A

Búsqueda de hechos

Asignación de prioridades

~

I

-

Integración y validación

~~ -

A v

1 del Representación -

conocimiento adquirido

Fig. 4-1. Modelo de la metodología propuesta para la captura de requisitos

Este proceso es primeramente ejecutado durante la fase de exploración dentro del

contexto del problema, con la finalidad de encontrar hechos. Se continúa

posteriormente con las actividades de obtención y clasificación de los requisitos encontrados, el razonamiento y evaluación de los mismos, la asignación de prioridades, la integración y validación de los requisitos, y por Último, se termina con la fase de representación y captura del conocimiento adquirido en el dominio del problema. Hasta aquí termina la fase de captura de requisitos y el primer nivel en la especificación de requisitos es logrado. Durante las subsiguientes fases que componen el desarrollo de un sistema de información, las especificaciones son



validadas y los requisitos inciertos aclarados, identificando requisitos no conocidos y refinando los existentes como sea necesario.

Siempre en base a mecanismos de comunicación (tormenta de ideas, JAD, etc.) empleados durante la captura de requisitos, las tareas a realizar dentro de este

proceso son citadas de manera iterativa, comenzando de nuevo con la reunión de requisitos para detallar y mejorar el documento de requisitos. Recordando que típicamente todos los requisitos en un sistema no son conocidos inmediatamente,

Io cual implica que la fase de integración y validación inicie con requisitos

incompletos, y por Io tanto, puede ser necesario regresar algunos pasos para la captura de requisitos a través de la fase de búsqueda de hechos en un proceso

eminentemente iterativo, tal como se propone en el modelo para la captura de

requisitos.

Las tareas que comprenden el modelo del proceso son listadas en la tabla 4-1. Allí sobresale la búsqueda de hechos, la cual comienza con un análisis operacional

donde se detalla el proceso operativo que dio origen a la necesidad de construir un

sistema de información. Se identifican los objetivos que se persiguen dentro del

proceso que se describe. Se continua dentro de la misma fase con el análisis del

problema que consiste en identificar los factores que deben considerarse para cumplir con los objetivos de la organización, identificando las comunidades

participantes que influyen de manera directa en los resultados. Con los resultados

obtenidos en las dos actividades anteriores, ya se está en condiciones de desarrollar un análisis del contexto organizacional identificando los ambientes principales que permitan visualizar de manera descriptiva el contexto general donde se gesta el problema a resolver, mediante la construcción de un sistema de información.

La fase de búsqueda de hechos termina con la identificación de todas las partes afectadas por el sistema en construcción, incluyendo a las personas estratégicas dentro de la organización que pueden tomar decisiones, y a los usuarios finales.

Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Mattínez Rangel Pag.30

Cap. 4. Propuesta metodológica para la captura de requisitos

Las tareas para encontrar hechos son importantes [Berlín 891 “Estudiar las necesidades de los usuarios es el primer paso para llegar ‘a una solución, conjuntamente, con el entendimiento de la tecnología disponible y de las

herramientas existentes. Sin un entendimiento ‘de la tecnología es casi imposible

llegar a una solución, y sin un entendimiento de las necesidades uno puede

resolver el problema de manera equivocada”.

A continuación se presentan las actividades agrupadas en tareas.

Cenidet . .

. .

hechos

requisitos

razonamiento

prioridades

validación

Representaciór

conocimiento 1 adquirido Tabla 4.1. T,

J Realizar un análisis operacional J Realizar un análisis del problema J Realizar un análisis del contexto organizacional J Identificación de todas las partes afectadas por el sistema en

construcción, incluyendo a las personas estratégicas dentro de la organización que pueden, tomar decisiones, y a . los usuarios finales.

J Identificar los requisitos orientados a las necesidades de los usuarios.

J Agrupar los requisitos expresados de acuerdo .al acto o actores que los expresan.

J Evaluar la consistencia de cada uno de los requisitos expresados respecto a lo expresado en la búsqueda de hechos.

J Evaluar si los requisitos expresados no se contraponen. J Realizar un razonamiento del porque algunas cosas son

‘expresadas como requisitos. J Determinar la importancia relativa de cada uno de los requisitos

expresados. J Determinación de la importancia relativa entre los requisitos de un

actor respecto a los requisitos expresados por los otros actores con el objeto de asignar prioridades.

J Integrar todos los elementos que se utilizaron durante la búsqueda de hechos y que dieron.origen a los requisitos.

J Validar que todos los requisitos establecidos correspondan a las metas originalmente estructuradas durante la búsqueda de hechos.

J Creación de escenarios que permitan representar y capturar el conocimiento adquirido de los episodios mas relevantes que se dan a lo largo del proceso de captura de requisitos.

as que comprende el modelo de proceso para la captura de requisitos.



La comunicación entre las actividades que se desarrollan dentro del proceso para la captura de los requisitos es cíclica, y mejora mediante el conocimiento adquirido a traves del tiempo. El mejoramiento de la comunicación es deseable. La representación de los requisitos apoya al entendimiento y permite que los cambios inevitables y su representación sean introducidos tempranamente para permitir el

mantenimiento y los cambios deseables.

4.2 Componentes de la metodología propuesta

Los componentes para la captura de requisitos que aquí se propone son los siguientes:

Búsqueda de hechos. Normalmente el sistema a ser desarrollado es parte de un

sistema ya existente y mas grande, donde mucha gente puede ser afectada por el

desarrollo. El enfoque socio-técnico para encontrar hechos expuestos, es similar a la metodología ORDIT' donde el sistema es visto como "un todo donde es posible

poner el ambiente operacional con el usuario como una parte integral del sistema",

de acuerdo a Io expuesto en [Dobson92]. Un análisis organizacional directo

permite poner de manifiesto cómo es el conocimiento acerca del sistema destino

en construcción, y cómo puede ser afectado por este conocimiento. Las

consideraciones arquitecturales, así como las restricciones de un proyecto tales como el costo, ayudan a definir el sistema que está siendo construido. Tales

consideraciones dentro de la tarea de búsqueda de hechos se presentan como sigue:

1. Un examen de la organización, en el cual el sistema a desarrollarse deberá funcionar.

* La metodología ORDIT (Definición de Requisitos Organizacionales para Tecnología de Información), reconoce explícitamente que el usuario tiende a trabajar de una manera colaboradora y cooperativa , de manera que se logren todos los objetivos, ya que el lema de la metodología ORDIT es: "producir sistemas de información, los cuales no sólo relacionen las necesidades organizacionales y funcionales de los usuarios finales, sino también de aquellos grupos de usuarios finales y sus requisitos de uso y aceptabilidad asociados. [Dobson 911.

Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martínez.Rangel Pag.32


2. Establecimiento de altos niveles de emisores o papeles que deberá jugar el sistema en desarrollo.

3. Determinación de algunas restricciones sobre la arquitectura.

4. Determinación de la existencia de sistemas similares.

Obtención de requisitos. Captura la información a traves del uso de vistas

multidisciplinarias, tales vistas expresan que es Io que se ha de construir.

Evaluación y razonamiento. Exponen las consistencias en los requisitos

obtenidos. Determinan porqué algunas cosas han sido expresadas como requisitos.

Asignación de prioridades. Determina la importancia relativa de los requisitos, por ejemplo: Pregunta cuándo los requisitos deben ser tratados en relación con

otros.

Integración y validación. Reúne la información colectada desde los primeros

pasos durante la captura y valida que estos requisitos correspondan a las metas

originalmente estructuradas durante la búsqueda de hechos.

Representación del conocimiento adquirido. Mediante la creación de

escenarios se representa y captura el conocimiento adquirido de los episodios mas

relevantes que se dan a lo largo del proceso de captura de requisitos de acuerdo a

la percepción que los clientes y usuarios tienen del dominio del problema.

4.2.1 Búsqueda de hechos.

Refiriéndonos a la tabla 4-l., el primer paso en la captura de requisitos incluye la determinación de que es el problema, de cómo debe este ser tratado y

cómo las comunidades de participantes deben ser involucradas tanto para la toma de decisiones como para la formulación del problema y su posible solución.

La salida para esta actividad incluye:

Propuesta Metodológica para la Captura de Requisitos' Ing. Mattín G. Martinez Rangel Pag.33


J Un análisis operacional

J Un análisis del problema

J Un análisis del contexto organizacional

J Identificación de todas las partes afectadas por el sistema en construcción,

incluyendo a las personas estratégicas dentro de la organización que

pueden tomar decisiones, y a los usuarios finales.

Una vez que se ha entendido el dominio del problema, mucha de esta información puede ya existir de alguna forma y estar fácilmente disponible. En

otros casos la definición del contexto del problema puede hacer más difícil la

actividad de captura de requisitos y quizá puede necesitar de pasos múltiples que

conciernen a la actividad de validación antes de que el contexto del problema se

tenga correctamente. El problema del alcance de las actividades involucradas en

estas tareas, son vagas y abiertas a la interpretación por parte del analista de

sistemas.

Es mejor tener todas las partes participantes afectadas en esta area

incluyendo usuarios, desarrolladores y clientes. Esto resulta en una integración

entre camaradas que representan a las diversas comunidades participantes en el análisis de contexto del proceso para la formulación del problema; lo cual puede

impactar positivamente sobre la volatilidad de los requisitos. Si todas las partes están involucradas en el acuerdo del alcance, se tiene una mejor oportunidad de

corregir directamente el problema, y pueden tratarse mejor los cambios en los requisitos, evitando que éstos ocurran durante el proceso de desarrollo.

Un enfoque efectivo para lograr la comunicación entre las diversas disciplinas para la búsqueda de hechos, es el uso de una técnica de proceso de grupo, tales como el JAD (desarrollo de aplicaciones en conjunto) que se describe en [Zahniser90]. Todas las partes afectadas pueden ser representadas en grupos



que puedan ejecutar de manera anticipada las tareas de búsqueda de hechos. Ésto promociona titularidad compartida, formulación rápida y pronta del problema,

alínea las perspectivas, y logra un entendimiento entre los participantes en el

proceso de captura de requisitos acerca del problema a ser resuelto y del alcance

de los subsecuentes requisitos que deban ser capturados.

Dentro de una técnica estructurada de reunión como 10 es el ]AD, otras técnicas pueden ser usadas para promover la comunicación entre los individuos,

desde muchas disciplinas potenciales. SSM (Metodología para desarrollo de

sistemas de software) proporciona un modelo de .obtención de información

[Checkland901 que puede ser utilizado para identificar los objetivos esenciales de la situación del problema. El método IBIS [Bageman881 puede ser usado para

registrar los diferentes puntos de vista de los. participantes, las posiciones

asociadas, y los argumentos en los que se apoyan estas discusiones entre los

grupos. Esta información puede ser utilizada para soportar las actividades de

generación de consenso, las cuales son parte del proceso JAD. Tal registro es de un valor incalculable durante la búsqueda de hechos y puede ser interactivo

durante todo el proceso de captura de requisitos. En fases posteriores de la

búsqueda de hechos, puede no ser necesaria la estructuración de grupos mediante técnicas tales como el JAD para redefinir los requisitos, pero es posible que sea

necesario utilizar nuevamente estas técnicas en fases que se dan a través de la captura, principalmente cuando una nueva comunidad de usuarios es reconocida y

puede verse afectada por el desarrollo del sistema propuesto.

4.2.2 Obtención de requisitos.

Dependiendo del curso que tome el sistema que comienza a desarrollarse y de

los grupos que pueden ser afectados, la obtención de los requisitos es una combinación entre ambos enfoques: composicional y descomposicional. En la formulación anticipada de un problema, es importante el obtener tanta información como sea posible tanto de los usuarios como de los desarrolladores y clientes.

~

Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Marthez Rangel Pag.35


Alguna o mucha información puede provenir del grupo de técnicas empleadas para

el desarrollo de búsqueda de hechos, tales como el JAD. Otro tipo de información

puede ser obtenida a traves del uso de las intervenciones directas de los usuarios

finales y otras partes afectadas. Cuestionarios, observaciones y simulaciones del

medio ambiente son otras técnicas que pueden ser utilizadas para obtener información de diferentes individuos o grupos [Andriole 901. La salida de esta

actividad incluye:

Objetivos orientados a los clientes y usuarios

Requisitos orientados a las necesidades de los clientes y usuarios.

Estas necesidades y requisitos son verificadas contra todos los objetivos del

sistema propuesto durante la búsqueda de hechos.

Cuando existen muchos clientes y usuarios que contribuyen con requisitos

para ser analizados mediante técnicas tales como intervenciones, un gran número

de conjuntos de necesidades y requisitos o puntos de vistas pueden ser

colectados. Es muy difícil para el analista identificar y resolver inconsistencias entre estos diferentes puntos de vista, si éstos no tienen una estructura adicional para la

información. Una forma de proveer esta estructura y de organizar la información

que proviene de muchos individuos, es a traves del uso del método CORE

(expresión de requisitos controlados) descrito en [Stephens85], el cual permite la extracción de requisitos con estas características. Eventualmente, esas múltiples vistas son compuestas en requisitos para el sistema propuesto o en desarrollo.

Estas vistas son mejor entendidas si son estructuradas en piezas

manejables. Esto es especialmente cierto, dado que el proceso de captura es incremental y se enfrenta con cambios inevitables en los requisitos. Si nosotros tenemos vistas monolíticas de un sistema completo, esto puede hacer muy difícil de comprender vistas muy grandes y también dificulta el encontrar las porciones

de que vistas pueden ser afectadas por un cambio incremental en los requisitos. ~~~ ~



Esto debe ser un proceso descomposicional asociado con la obtención de requisitos, donde las vistas puedan descomponerse en componentes significativos.

Idealmente, es aplicable el uso de modelos de dominio y tecnológicos, como

la descomposición. Por ejemplo: el enfoque de modelos de dominio [Davis90]. Este enfoque permite una mejor comunicación de la parte de captura de la información expresada mediante las vistas. CORE enfatiza el uso de diagramas de flujo de

datos para la descomposición de tales vistas, la representación usada para la

descomposición es muy dependiente del dominio de la aplicación, por ejemplo: la

representación del flujo de datos de CORE puede fallar al momento de adecuar la

captura de formalismo, el cual puede ser necesario en requisitos para sistemas

embebidos [Finkelstein 861.

4.2.3 Evaluación y razonamiento

La evaluación de riesgo debe orientarse hacia Io técnico, hacia el costo y lo que concierne a la planeación. En adición, el razonamiento detrás de la

información obtenida en estados previos debe ser examinada para determinar cuando los verdaderos requisitos están ocultos en este razonamiento, y que deben

expresarse explícitamente. El razonamiento y la evaluación de riesgos son las dos

principales salidas de esta actividad. -

IBIS es una buena técnica para capturar el razonamiento en los puntos

donde se ubican los argumentos en el marco de trabajo de las técnicas de desarrollo en grupo (JAD) y las intervenciones. Los modelos estructurados del dominio y la tecnología son extremadamente Útiles. Por ejemplo, con las características del modelo de dominio; es posible seleccionar ciertas alternativas,

describiendo las decisiones que se tomaron y el razonamiento asociado con la

selección de estas alternativas.

Una vez que el razonamiento ha sido capturado y examinado, las inconsistencias pueden ser idealmente encontradas y tomar las mejores decisiones


Cap. 4. Propuesta metodológica para la captura de requisitos

que permitan resolver estas inconsistencias y que permitan tratar las necesidades reflejadas en el razonamiento.

Cenidet

En deducción, este razonamiento es extremadamente útil durante el proceso de captura de requisitos así como la documentación sobre las decisiones

particulares que se hicieron, en caso de incrementarse los cambios sobre los requisitos capturados, estos cambios deben ser verificados para ver si los nuevos

requisitos corresponden con el razonamiento que se tiene del resto de los requisitos.

4.2.4 Asignación de prioridades

El desarrollo incremental tanto del sistema como el de los requisitos, se acentúan en este modelo de proceso para la captura de requisitos. Si los requisitos

son priorizados, las necesidades mas altas necesitan ser tratadas primeramente y los cambios subsecuentes en los requisitos ya definidos re-examinados, antes de

que las necesidades de baja prioridad (con sus cambios respectivos) sean

implantados, esto puede resultar en un ahorro, tanto en costo como en tiempo cuando se procesan los cambios mencionados en los requisitos durante el desarrollo del sistema.

Los requisitos deben ser priorizados en base al costo, a su relación con otros

requisitos, y a las necesidades de los usuarios. Los modelos de arquitectura pueden ayudar en la determinación sobre cómo el sistema puede ser

incrementalmente desarrollado. El Despliegue de la Función de la Calidad (QFD- Quality Function Deployment) es una técnica ideal para determinar las

características críticas de un sistema y promover las necesidades de los usuarios, esta técnica se describe en [Schubert89].

Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Marthez Rangel Pag.38


4.2.5 Integración y validación

Un avance importante de las técnicas de desarrollo en grupo, tal como es el

JAD, es que promueve la titularidad compartida del desarrollo de los requisitos con una mejor definición del alcance, así como también reduce la oportunidad para

cambios futuros en los requisitos. Estas técnicas acentúan la integración de las múltiples puntos de vista entre los participantes de la construcción de un sistema de información. Lo anterior tanto como sea posible a través de involucrar todas las partes afectadas por el desarrollo del sistema para que la propiedad compartida no

se pierda. Si la integración es llevada a cabo por una sola comunidad durante el

proceso de la captura de requisitos, tales como la búsqueda de hechos, obtención de requisitos y otros estados anteriores, enfocar la integración de esta manera

puede ser vista como una interpretación de los desarrolladores de los requisitos, y

esto puede ser criticado por no incorporar otras interpretaciones importantes de

otras comunidades.

Existen un gran número de maneras para tratar el problema de la integración. Una forma es la de repetir las técnicas de desarrollo en grupo, luego del proceso de captura de requisitos. Lo anterior para que la titularidad compartida

tenga lugar nuevamente. Cuando los gerentes de niveles altos se involucran

frecuentemente en tales grupos de desarrollo, puede ser imposible obtener el

compromiso de todos los participantes durante la búsqueda de hechos cuando esta

contribución es crítica, así como también al final del proceso de captura de

requisitos. El involucrar personal de alto nivel, tanto al comienzo como al final del desarrollo conceptual puede rechazarse a favor de involucrar gentes de otros niveles al comienzo del desarrollo conceptual.

Las tareas de integración deberán ser ejecutadas, y llevadas a cabo por el

analista de sistemas y los resultados obtenidos del proceso de captura de requisitos deberá comunicarlos a las otras partes involucradas en dicho proceso a través de varias estrategias, como la creación de escenarios. Esta comunicación



puede ser vista como el resultado del concepto de exploración y la captura de requisitos, comenzando con las primeras actividades de demostración y validación. Esta validación de requisitos asegura a todas las partes afectadas que sus intereses se encuentran a buen resguardo. e

En los casos donde el analista de requisitos es el responsable de la

integración de la información .que contengan todos los atributos deseables, vistos en el marco de este trabajo de tesis, es posible utilizar algunas técnicas como los

modelo de dominio que proveen de mapas acerca de cómo organizar la información en un documento de requisitos, y cómo debe presentarse dicha

información a todas las partes involucradas en la captura de requisitos.

Cuando el concepto de diversos' puntos de vista es usado, estas vistas pueden ser integradas a través de la técnica del diagrama de concepto descrito en

[Delugach91]. Este es un buen enfoque automático para la integración de puntos

de vista, pero no soporta fácilmente el desarrollo incremental de requisitos. La

técnica QFD puede asimismo, ser usada para la integración y validación mediante

la relación de los puntos de vista .de los usuarios y de los desarrolladores de un sistema. La integración de los puntos de vista de los usuarios y de los desarrolladores puede revelar las deficiencias existentes en las fases iniciales de la metodología de captura de requisitos para que sean revisadas.

4.2.6. Representación del conocimiento adquirido

La tarea principal del análisis de requisitos es generar especificaciones que describan el comportamiento del sistema en forma no ambigua, consistente y

completa. Para que esta tarea sea llevada a cabo en forma adecuada, es necesario

determinar correctamente el contexto, es decir, dónde se efectuarán las tareas de ingeniería, con que recursos se cuenta, y cuales son los límites y los objetivos del producto que se está por desarrollar. Este contexto se denomina Universo de Discurso (UD) y evoluciona a lo largo del proceso de desarrollo y mantenimiento



del soffware. Cuanto mejor se especifique ese UD, mayores serán las posibilidades de obtener un sistema bien definido.

El UD contiene todas las fuentes de información que se van a utilizar. Por medio de la captura de requisitos se intenta descubrir la información necesaria

para conocer el sistema en estudio. En [Leite97, Leonardi971 se propone entre otras cosas, el uso de escenarios como técnicas para representar esa información. Es importante destacar que durante la fase de captura de requisitos puede ser

necesario re-delinear el UD.

Los escenarios son un medio natural para representar y capturar

conocimiento del dominio durante la captura de requisitos y documentación de

requisitos [Zorman95]. Un escenario constituye una descripción de los aspectos

relevantes en cuanto al comportamiento y al ambiente de un sistema, mediante

episodios concretos y específicos, usando generalmente lenguaje natural. Los

escenarios se pueden usar para describir el comportamiento externo del sistema

permitiendo la participación e interacción del usuario durante todo el proceso de

análisis de requisitos. Además, los escenarios pueden ayudar en la validación de la

especificación de requisitos [Hsia94].

Para definir escenarios se requiere un conocimiento detallado que sólo los

expertos del dominio pueden proveer y validar. Los escenarios están más cerca

que otros modelos abstractos de la percepción que los clientes y usuarios tienen

del dominio del problema, ya que se escriben usando el lenguaje específico de ese dominio. Esto facilita la asimilación de descripciones complejas y abstractas que de otra forma se podrían entender mal [Potts95] y permite establecer una buena comunicación con los expertos no técnicos del dominio.

La construcción de escenarios es un proceso que consiste en entender, analizar y describir el comportamiento de un sistema en términos de las diferentes

formas en las que se espera usarlo. El producto final de esta etapa es un

Propuesta Metodológica para la Captura de Requisitos. Ing. Martin G. Marthez Range¡ Pag.41


Contexto

documento que contiene un conjunto de escenarios correctos, completos,

consistentes y validados. Este documento forma parte de la especificación de requisitos del sistema y se usa como guía para el diseño y las pruebas.

Nombre del escenario

Meta a ser alcanzada en el macrosistema

Ubicación geográfica y estado inicial del escenario

Un escenario se puede describir utilizando el esquema propuesto en [Leite97] que se muestra en la Figura 4-2.

11 Excepcidn 11 CitLaciÓn qJe provoca un comportamiento oiferente del escenario I

Recursos

Actores

Episodios

Medios necesarios para la realización del escenario

Personas u organizaciones

Serie de sentencias que muestran el comportamiento del escenario


Cap. 5. Aplicación de la metodología en un escenario real Cenidet

CapítuZo 5 Aplicación de da prquesta metodológica en un escenario real

En este capítulo, se presenta un caso de estudio en un escenario real donde se aplica la propuesta metodológica.


Cenidet Cap. 5. Aplicación de la metodología en un escenario real

5.1. Antecedentes

El modelo de la metodología para la captura de requisitos que se propone

en este trabajo de tesis se aplicó en la construcción de un sistema de información en su fase de captura de requisitos. El sistema apoyara el proceso para administrar los recursos otorgados por el gobierno federal a través del Fondo para Modernizar

la Educación Superior, FOMES, a las instituciones de educación superior públicas del país.

Siguiendo el modelo de proceso de la metodología propuesta se encontró lo

siguiente :

5.2. Búsqueda de hechos

En esta parte del modelo de proceso para la captura de requisitos, las tareas a realizar consistieron en identificar a los actores principales, realizar un

análisis operacional, un análisis del problema, un análisis del contexto

organizacional, así como la identificación de todas las partes afectadas por el sistema en construcción, identificando a las personas que son estratégicas dentro de la organización y que pueden tomar decisiones, así como a los usuarios finales. Lo encontrado se describe a continuación:

5.2.1. Análisis operacional

El FOMES es un programa estratégico creado por el Gobierno Federal a través de la Secretaría de Educación Pública (SEP) para otorgar recursos

extraordinarios, no regularizables, con el propósito de mejorar, modernizar y

complementar la infraestructura de apoyo al trabajo académico de los cuerpos académicos y sus alumnos e impulsar el desarrollo institucional de las Instituciones de Educación Superior (IES).

Propuesta Metodológica para la Captura de Requisitos Ing. Martin G. Martfnez Rangel Pag.44

Cap. 5. Aplicación de la metodologia en un escenario real Cenidet

Los recursos obtenidos, a partir de proyectos institucionales tiene como

objetivo general la realización del Programa de Fortalecimiento Integral en el ámbito que les corresponda y como objetivo específico alguno de los siguientes entre otros:

a) El mejoramiento integral del proceso enseñanza-aprendizaje;

b) La actualización de planes y programas de estudio, y la flexibilización

-curricular;

c) La implantación de programas institucionales de tutoría individualizada O

de seguimiento de egresados siguiendo la metodología de la Asociación

Nacional de Universidades e Instituciones de 'Educación Superior (ANUIES),' así como de .retención, orientación educativa, y conclusión de

estudios, entre otros, que propicien una mejor atención y seguimiento

de los alumnos por parte de las IEC;

d) La consolidación de sistemas de información que apoyen los procesos de

planeación, autoevaluación, acreditación de programas y certificación de

los procesos de gestión y administración institucionales;

e) La adecuación de la normativa para el mejor funcionamiento de la institución;

f) La ampliación y modernización de la infraestructura académica de

laboratorios, aulas, talleres, plantas piloto, centros de lenguas extranjeras y bibliotecas, entre otros, para que los cuerpos académicos de las Instituciones de Educación Superior y sus alumnos cuenten con

condiciones apropiadas para su trabajo académico;

g) Fortalecimiento de proyectos de investigación en desarrollo, que hayan generado resultados y en los que participen estudiantes, como un medio para mejorar la calidad de la educación que reciben;



h) Dotación de equipo de cómputo para actividades académicas en áreas comunes, siempre y cuando atiendan necesidades de equipamiento para docencia y generación o aplicación innovativa del :conocimiento, de los

cuerpos académicos y sus estudiantes;

i) Equipamiento de laboratorios compartidos por cuerpos académicos de una o varias IEC.

5.2.2. análisis del problema

La administración de los recursos federales asignados a los proyectos

FOMES es un proceso complejo debido a que existen muchos factores que deben

tomarse en cuenta para cumplir con los compromisos establecidos mediante

convenio entre una institución de educación superior y la secretaría de educación

pública. Los proyectos del FOMES tienen una duración de un año fiscal. En casos

plenamente justificados podrán continuar más allá de este límite, recibiendo financiamiento para periodos subsecuentes previa solicitud y evaluación de la etapa anterior y en función de la disponibilidad de fondos.

Mediante la construcción de un sistema de información se apoyará al proceso que se sigue para la administración de los fondos aportados por el

gobierno federal, a traves de:

1. Un Fideicomiso con una institución de crédito autorizada para la inversión y

administración con los recursos aportados por la CEP para dar cumplimiento a los objetivos y las metas del FOMEC.

2. La designación de un comité técnico del Fideicomiso formado por tres

personas de la institución, el cual será responsable de:

a) Vigilar el efectivo cumplimiento de todos y cada uno de los fines del

Fideicomiso;


Cap. S. Aplicación de la metodología en un escenario real Cenidet

b) Autorizar la asignación de recursos necesarios para llevar a cabo los fines del Fideicomiso, de acuerdo con los programas e instrucciones

que el mismo establezca;

c) Autorizar la celebración de actos y contratos de los cuales se deriven

derechos y obligaciones para el patrimonio del Fideicomiso;

d) Solicitar a la Dirección General de Educación Superior (DGEC) su

autorización por escrito para emplear los productos financieros

generados en el Fideicomiso, los cuales sólo podrán ser aplicados al

cumplimiento de metas de proyectos FOMEC apoyados originalmente

en forma parcial, o de aquellos que fueron dictaminados

favorablemente pero que no fueron apoyados por insuficiencia presupuestal;

e) Instruir a la Fiduciaria respecto a las políticas de inversión del

patrimonio del fideicomiso; y

f) Cualesquiera otras obligaciones derivadas de la ley.

3. Una coordinación que administre el proceso FOMEC, siendo esta uno de los usuarios principales del sistema de información del cual se capturaran los

requisitos para su construcción, esta coordinación será responsable de:

a) Validar que la solicitud de pago cumpla con todos los requisitos

establecidos para su tramitación.

b) Enviar al comité técnico del Fideicomiso FOMEC mediante un acta la

relación de solicitudes que cumplen con los requisitos establecidos

para su aprobación.

c) Enviar al tesorero de la institución la relación de pagos para su

contabilización y emisión de los cheques correspondientes.



d) Instruir mediante oficio a la institución de crédito autorizada para la inversión y administración para que traspase fondos de la cuenta del Fideicomiso a la cuenta corriente para que se paguen los cheques liberados por la tesorería de la institución de educación superior.

e) Registrar los gastos que genera cada responsable de proyecto con el

objeto de poder informar al comité técnico del Fideicomiso FOMES de

la evolución que tiene cada proyecto y se tomen las acciones que

correspondan en cada caso.

9 Informar de los resultados obtenidos cada cierto periodo de tiempo al responsable de dar seguimiento al desarrollo de los proyectos para

que se realicen los siguientes procesos:

I) De seguimiento académico y financiero de cada uno de los

proyectos.

11) Evalúe los resultados obtenidos.

El seguimiento académico y financiero Io realiza la DGES en dos etapas. La primera, a mitad del año de ejecución y la Última, al finalizar el año, cuando se

concluyen los proyectos, cuyo resultado final se reporta junto con el soporte

documental y los productos alcanzados. Estas etapas se cumplen mediante las acciones siguientes:

1. La institución de educación superior establecerá la apertura del Fideicomiso del año en vigor, conforme al convenio de colaboración, dando evidencia del mismo y remitiendo a la DGES los estados de

cuenta mensuales.

2. AI término del primer semestre de ejecución de proyectos, la

institución de educación superior presentará en la DGES a traves del responsable de dar Seguimiento al desarrollo de los proyectos el



informe del seguimiento intermedio, con los avances académico y financiero de los proyectos, anexando los documentos probatorios del ejercicio presupuestal.

3. La 'DGES realizará el análisis del informe de seguimiento intermedio

para conocer el grado de avance y la consistencia de los datos en

función del convenio signado. En caso de detectarse retrasos notorios o irregularidades en el uso de 105 recursos, la DGES solicitara información complementaria a la Institución de educación superior.

4. AI término del segundo semestre de ejecución de proyectos, la

institución de educación superior presentará en la DGES el informe

de seguimiento final con la conclusión de los avances académicos y financieros de los proyectos, así como los documentos

comprobatorios del ejercicio presupuestal.

5. Cuando se hayan cumplido las metas académicas según el convenio

con la institución de educación superior, y comprobado el uso

adecuado de los recursos, la DGES remitirá a institución de educación

superior el. oficio de liberación.

6. En caso que una institución no entregue a las DGES la información

que le solicita, y/o no se cumplan las metas académicas según el

convenio, y/o no se utilicen los recursos otorgados para el desarrollo de los proyectos aprobados, la DGES podrá cancelar la participación de la institución de educación superior en el Programa.

La evaluación de los resultados académicos la llevará a cabo la DGES y se realizara una vez por año. Para ello la DGEC solicitara a la institución de educación superior una autoevaluación de los resultados de los proyectos FOMES apoyados y



su impacto académico. La DGES empleará dicha evaluación para retroalimentar los criterios de asignación y las políticas de operación del FOMES.

5.2.3. Análisis organizacional

A partir del análisis operacional y del análisis del problema se extrae el análisis organizacional el cual se presenta a continuación en dos fases, una considerando el contexto donde participa el Gobierno Federal y la institución y que se presenta en la figura 5-1, y la otra fase considerando un contexto local donde

participan todos los actores (personas, dependencias) de la institución de

educación superior en donde se implantará el sistema, lo anterior se presenta en la figura 5-2.

Universidad Estatal Gobierno Federal

Evalúa proyectos y otorga recursos 4

financieros

Evalúa resultados y Administra recursos toma acciones financieros y corresuondientes presenta resultados

Fig. 5-1. Análisis organizacional a nivel Gobierno Federal-Institución de educación

superior Estatal.



5.2.4. Identificación de las partes afectadas

A partir de las tareas de análisis operacional, análisis del problema y análisis organizacional es posible identificar a cada uno de las partes afectadas por la implantación de un sistema de información. Se presenta a continuación la lista de las partes afectadas (se incluyen aquellas que aunque no inciden directamente en el proceso de administración de los recursos FOMES, si tienen que ver con los procesos administrativos dentro de la institución, como es el caso del almacén.

a) Comité técnico de FOMES.

b) Coordinación FOMES

c) Institución de crédito

d) Responsable de dar seguimiento al desarrollo de los proyectos

e) Responsables de proyecto

9 Proveedores

g) Tesorería

h) Departamento de Almacén

i) Departamento de compras

j) Departamento de contabilidad.

5.2.5 Resultados obtenidos en la búsqueda de hechos

Establecimiento del contexto del problema: El problema que se tiene es la administración de los recursos extraordinarios que reciben las instituciones de educación superior de parte del gobierno federal y que tienen que ser erogados

Propuesta Metodoiogtca Para La Capbra De Requisitos Ing. Martin G. Martinez Rangel Pag.53


bajo ciertos lineamientos que permitan lograr las metas establecidas en cada proyecto.

Total de los objetivos a cumplir: a continuación se señalaran aquellos objetivos que deben cumplirse con la implantación de un nuevo sistema de información que apoye a la coordinación FOMES en la administración de los recursos.

a) Llevar un control del gasto que hace cada responsable de proyecto, de

acuerdo al monto establecido para cada uno de ellos.

b) Verificar que los recursus erogados cumplan con las metas que persigue

cada proyecto, y que los bienes adquiridos sean aquellos que fueron especificados en la propuesta del proyecto que fue evaluado por la SEP.

c) Que la coordinación FOMES informe con oportunidad y veracidad al responsable de dar seguimiento al desarrollo de los proyectos de los avances que tiene en materia financiera por proyecto, metas y bienes

adquiridos.

d) Que la coordinación FOMES informe a la SEP de los resultados obtenidos en términos del gasto mediante la emisión de estados de cuenta.

e) Que la coordinación FOMEC sepa en todo momento ia lista de proveedores

que se tienen, cheques emitidos por la tesorería, bienes adquiridos,

traspasos realizados de la cuenta del fideicomiso a la cuenta corriente para

pago de cheques, metas cumplidas por proyecto en termino del gasto rea I izado.

f) Que la coordinación FOMES sepa en todo momento el estado actual que guarda cada documento(so1icitudes atendidas, solicitudes rechazas, cheque emitidos, cheques cobrados, cheques cancelados, solicitudes de compras atendidas, solicitudes de compras rechazadas, etc).

Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.54


5.3. Obtención de requisitos

A partir de la búsqueda de hechos a Io largo de todo el proceso FOMES, es

posible identificar los requisitos orientados a las necesidades de los usuarios.

En esta parte es importante señalar que los requisitos que se obtuvieron

obedecen a las necesidades que tienen los tres actores principales dentro del proceso FOMES, estos actores son el comité técnico, el responsable de dar seguimiento al desarrollo de los proyectos y el responsable de la coordinación

FOMES. A continuación se mencionan los requisitos mas importantes que cada uno de ellos propuso que el sistema debe cubrir.

Comité Técnico:

2) Que el sistema permita identificar en todo momento los movimientos

que tiene el fideicomiso y que los montos erogados correspondan con

los objetivos que se deben cumplir en cada uno de los proyectos.

3) Que de acuerdo a las necesidades de pago que se tengan, permita

identificar mediante el sistema si es factible el autorizar el

movimiento de fondos de la cuenta del fideicomiso a la cuenta

corriente para cubrir los pagos autorizados.

4) Que de acuerdo a los objetivos que se deban cubrir en cada uno de

los proyectos, permita identificar en qué proyectos se requiere

autorizar la celebración de actos y contratos de los cuales se deriven derechos y obligaciones para el patrimonio del Fideicomiso.

5) Obtener información de cada uno de los proyectos que por insuficiencia presupuesta1 no han podido cubrir sus obletivos en su totalidad. Lo anterior con el objeto de pedir autorización a la SEP para emplear los productos financieros generados en el Fideicomiso

para apoyar a estos proyectos.

Propuesta Metodológica Para La Captura De Requisitos Ing. Martín G. Martínez Rangel Pag.55


6) Que el sistema permita obtener información respecto a io5 recursos comprometidos con el objeto de poder instruir a la Fiduciaria respecto a las políticas de inversión del patrimonio del fideicomiso.

Coordinación FOMES:

1) Que el sistema permita mantener los datos de un proyecto, así como de los responsables de cada uno de ellos.

2) Que el sistema permita mantener los datos específicos de cada

proyecto como son sus objetivos, estrategias y metas, así como los conceptos o bienes que podrá adquirir para cumplir cada una de sus metas.

3) En cuanto al manejo de conceptos, es importante que el sistema permita identificar cuáles son susceptibles de ser modificados.

4) Que para el registro de solicitudes de pago permita capturar por

separado aquellas que generan compromisos de aquellas que no

generan compromisos, así como de las solicitudes que generan

retención de impuestos.

5) Que el sistema permita registrar pedidos y en todo momento se

conozca el estado que guarda cada uno de ellos (pedido atendido por

compras, pedido atendido por el proveedor, pedido con bien

adquirido, pedido cancelado etc.).

6) Permitir agrupar solicitudes de pago en actas que deberán ser

analizadas por el comité técnico y en su defecto autorizar o rechazar

aquellos pagos que a juicio del comité deban rechazarse.

7) Registrar cheques y conocer en todo momento cuales ya fueron

cobrados por los proveedores, cuáles cheques fueron cancelados,



qué cheques son para pagos de solicitudes que generan retención de impuestos, etc.

8) Que el sistema permita realizar comprobaciones de pagos hechos con anticipación mediante la presentación de facturas con todos los datos

asociados a ellas.

9) Que el sistema permita en todo momento registrar modificaciones en

todos los rubros ya mencionados.

10) Que el sistema permita realizar transferencias de fondos de la cuenta del fideicomiso a la cuenta corriente para pago de solicitudes.

Rresponsable de dar seguimiento al desarrollo de los proyectos

1) Que el sistema permita identificar los avances que tiene cada uno

de los proyectos en cuanto a su financiamiento.

2) Que el sistema permita generar un informe financiero detallado por

cada proyecto y que dicha información se transfiera al sistema SIFOMEC que es proporcionado por la SEP el cual se utiliza como

instrumento para reportar resultados.



5.4. Evaluación y razonamiento de los requisitos.

En esta parte se evalúo la consistencia de cada uno de los requisitos

expuestos por las partes o actores principales del proceso FOMES y se razonó del porque algunas cosas son expresadas como requisitos, los resultados de estas

tareas se muestran a continuación.

Requisito

No.

1

Descripción

Que el sistema

permita identificar en

todo momento los movimientos que

tiene el fideicomiso y

que los montos erogados

correspondan con los

objetivos que se

deben cumplir en

cada uno de los

proyectos.

Que de acuerdo a las necesidades de pago

que se tengan, permita identificar mediante el sistema si

es factible autorizar

Parte o actor

que lo

expresa

:omité Técnico

:omite Técnico

Evaluación y

Razonamiento

Este requisito está en

correspondencia con el convenio que tiene la institución con la SEP en

cuanto a que se le debe

enterar a la segunda los

movimientos financieros que

se realizan y si tales

movimientos tienen que ver

con los objetivos planteados

en cada uno de los proyectos

Este requisito esta en correspondencia en cuanto

que se debe minimizar el traspaso de recursos que se tienen en el fideicomiso a la cuenta corriente, ya que la



el movimiento de

fondos de la cuenta del fideicomiso a la cuenta corriente para

cubrir los pagos

autorizados.

Que de acuerdo a los

objetivos que se

deban cubrir en cada

uno de los proyectos, permitir identificar en

que proyectos se requiere autorizar la

celebración de actos y

contratos de los cuales se deriven

derechos y

obligaciones para el patrimonio del Fideicomiso.

Obtener información

de cada uno de los

proyectos que por insuficiencia

presupuesta1 no han podio cubrir sus objetivos en su totalidad. Lo anterior

:omite Técnico

:omite Técnico

primera es la que más

intereses genera.

Este requisito esta expresado

de manera adecuada en

cuanto que con ello es

posible reservar en la cuenta

corriente un monto

comprometido, mismo que no generaría intereses. El

sistema deberá por

consiguiente permitir

identificar el número de

pagos que contempla un

compromiso.

Este requisito es expresado

en correspondencia con la posibilidad de que la Institución pueda utilizar los

recursos que provienen de intereses generados en el fideicomiso. Lo anterior tiene sentido en cuanto que

Propuesta Metodológica Para La Captura De Requisitos Ing. Marth G. Martínez Rangel Pag.59


con el objeto de pedir autorización a la SEP

para emplear los productos financieros generados en el

Fideicomiso para

apoyar a estos

proyectos.

Que el sistema

permita obtener

información respecto

a los recursos

comprometidos con el

objeto de poder

instruir a la Fiduciaria respecto a las políticas de inversión

del patrimonio del

fideicomiso.

Que el'sistema permita mantener los datos de un proyecto,

así como de los responsables de cada

:omité Técnico

:oordinaciÓn 'OMES

algunos proyectos fueron apoyados en algunas de sus

metas con muy pocos recursos, entonces el sistema deberá permitir identificar

qué proyectos tienen una

eficiencia en el gasto del

100°/~ y que tengan metas sir cumplir por falta de recursos

financieros

Este requisito tiene relación al

requisito número tres, con la

premisa de que este se esta expresando en que aparte de

tener compromisos derivados

de contratos o convenios con

algunos proveedores es necesario instruir al banco

para que reserve los recursos

que se utilizarán a corto

plazo.

~

Este requisito es expresado desde el punto de vista operativo, y tiene que ver con

el mantenimiento de la

información expresada en las



uno de ellos.

Que el sistema

permita mantener los datos específicos de

cada proyecto como

son sus objetivos,

estrategias y metas,

así como los

conceptos o bienes

que podrá adquirir

para cumplir cada una

de sus metas

En cuanto al manejo

de conceptos, es

importante que el

sistema permita

identificar cuales son

susceptibles de ser

modificados.

:oordinación

'OMES

:oordinaciÓn

:OMES

propuestas de los proyectos de los montos con que fueror

apoyados en cada una de sus metas.

~ ~~

Este requisito está expresado

en correlación con el requisitc

número siete, pero

considerando que en esta parte el cisterna deberá permitir identificar los rubros

o bienes que podrá adquirir

un responsable de proyecto

en cada una de sus metas.


en cuanto a que no todos 10s conceptos pueden ser

susceptibles de ser modificados, en el caso de

conceptos muy generales es

posible modificarlos y de acuerdo al criterio de costo adquirir otros conceptos que tengan relación con el

modificado (es decir un concepto puede modificarse

siempre y cuando el concepto



10

11

12

Para el registro de solicitudes de pago,

permitir capturar por

separado aquellas que

generan compromisos

de aquellas que no

generan

compromisos, así

como de las

solicitudes que

generan retención de

impuestos.

Que el sistema

permita registrar

pedidos y en todo momento se conozca

el estado que guarda

cada uno de ellos

(pedido atendido por

compras, pedido atendido por el proveedor, pedido con bien adquirido, pedido cancelado etc.).

Permitir agrupar

Loordinación 'OMES

:oordinaciÓn

:OMES

:oordinaciÓn

sea del mismo genero

(acervo-acervo)

Este requisito es expresado :on el objeto de poder :umplir el requisito número

seis expresado por el comité

:étnico.

fste requisito es expresado

:om0 una necesidad a todo el

xoceso, ya que es necesario dentificar en todo momento

!I estado que guarda un ledido en cuanto a que

iermite saber el total de los

'ecurso que deben :ransferirse de la cuenta del

Ideicomiso a la cuenta

:orriente para cubrir los :ompromisos.

Iste requisito es expresado

Propuesta Metodológica Para La Captura De Requisitos Ing. Martin G. Martínez Rangel Pag.62


L3

14

solicitudes de pago en

actas que deberán ser analizadas por el

comité técnico y en su defecto autorizar o rechazar aquellos

pagos que a juicio del

comité deban

rechazarse.

Registrar cheques y

conocer en todo

momento cuáles ya

fueron cobrados por los proveedores,

cuáles cheques fueron

cancelados, que

cheques son para

pagos de solicitudes

que generan retención de

impuestos, etc.

Que el sistema permita realizar

comprobaciones de pagoshechoscon anticipación mediante

'OMES

:oordinación

'OMES

,

:oordinaciÓn

'OMES

como parte del convenio que

'a institución de educación

juperior tiene con la sep en ruanto a que debe existir un :omité que verifique que 10s 3astos que se realizan 3ermiten cumplir las metas

?stablecidas en cada uno de os proyectos.

3 t e requisito es expresado

:on el objeto de validar los

;aldos de cada proyecto para dentificar los avances que se

:¡enen en cuanto a Io inanciero.

3 t e requisito es expresado

?n el sentido de que es iosible que en algunos casos ;e liberen pagos anticipados :on el compromiso de que en

Propuesta Metodológica Para La Captura De Requisitos Ing. Martín G. Martinez Rangel Pag.63


.5

la presentación de

facturas con todos los datos asociados a ellas.

Que el sistema

permita en todo

momento registrar

modificaciones en

todos los rubros ya

mencionados.

6

Coordinación

FOMES

Coordinación

FOMES

Que el sistema

permita realizar

transferencias de

fondos de la cuenta

del fideicomiso a la

cuenta corriente para

pago de solicitudes.

un determinado momento deberá ser comprobado el gasto mediante factura

Este requisito es expresado como parte de las necesidades de un sistema de

información y no visto como

parte de cumplir alguna

necesidad especifica de algún

actor o parte participante.


como una necesidad que

tiene tanto el comité técnico

como la coordinación FOMES

en cuanto a el control que debe existir en el fideicomiso.

7

L

Que el s/stema

permita identificar los avances que tiene

cada uno de los

proyectos en cuanto a

su financiamiento.

Responsable

de dar seguimiento al

desarrollo de

los proyectos

Este requisito es expresado como parte del convenio que

existe entre la institución de

educación superior y la SEP

en cuanto a que ésta última deberá evaluar los resultados en base al gasto erogado en cada proyecto.



18 Que el sistema Responsable Este requisito es expresado

permita generar un de dar para cumplir una necesidad informe financiero seguimiento al como parte de un convenio

detallado por cada desarrollo de existente entre la propia

proyecto y que dicha los proyectos . institución de educación

información se

transfiera al sistema

SIFOMES, mismo que

es proporcionado por

la SEP, y el cual se

utiliza como

instrumento para

reportar resultados.

superior y la SEP.

5.5. Asignación de prioridades

En esta parte se determinó la importancia relativa de cada uno de los requisitos de un actor respecto a los requisitos que son expuestos por los otros

actores. Se concluyó que en orden de importancia los requisitos expresados por la coordinación FOMES tienen mayor prioridad sobre los requisitos expresados por el

comité técnico y por el responsable de dar seguimiento al desarrollo de los

proyectos, en el orden que se menciona, y que los requisitos expresado por el comité técnico tienen mayor prioridad sobre los requisitos expresados por el responsable de dar seguimiento al desarrollo de los proyectos. Lo anterior aunque

en el orden de jerarquía en cuanto a la toma de decisiones se encuentra el comité técnico en primer lugar, seguido por el responsable de dar seguimiento al

desarrollo de los proyectos.



5.6. Integración y validación.

En esta parte se reunió la información colectada desde los primeros pasos que componen el proceso de captura de requisitos como parte de la metodología

que se está aplicando al proceso FOMEC y validando que los requisitos obtenidos

corresponden a las metas originalmente estructuradas durante la búsqueda de

hechos.

La información colectada se basó en entrevistas con cada uno de los actores

,los cuales describieron de manera detallada cada una de las funciones que les

toca realizar dentro del proceso FOMEC, así como documentación que hace

referencia al convenio que realiza la propia institución de educación superior con la

SEP. En dicho convenio la institución de educación superior se compromete

textualmente a abrir un fideicomiso con una institución de crédito, y así mismo se

compromete a informar en todo momento mediante estados de cuenta, el estado

que guarda' el financiamiento, además de comprometerse a utilizar los recursos

únicamente para 10s. fines para 10s que le fueron proporcionados a la institución Y

que ya fueron mencionados al inicio de este documento. Otro documento

importante fue el diario oficial de la federacion, en donde el gobierno federal.

convoca a través de la SEP a todas las institución de educación superiores públicas

a participar en la presentación de proyectos, con el objeto de obtener recursos

extraordinarios, bajo ciertas bases establecidas por la subsecretaria de Educación

Superior e Investigación Científica (CECIC).

En cuanto a la validación de los requisitos, se identificó que cada uno de los

requisitos propuestos corresponden efectivamente a cubrir los objetivos que la propia institución de educación superior se compromete a cumplir mediante

convenio con el gobierno federal, como Io es un control sobre el fideicomiso, un

control de los recursos aportados por el gobierno federal y con un compromiso fundamental en cuanto a que los recursos sean gastados exclusivamente para

Propuesta Metodológica Para La Captura De Requisitos Ing. Martín G. Martinez Rangel Pag.66


TiTULO

3BJETiVO

ZONTEXTO

cumplir las metas propuestas en cada uno de los proyectos que se presentaron

para evaluación y que fueron apoyados con recursos financieros.

Pago de solicitud

Pago de solicitud al proveedor de bienes adquiridos

Mediante solicitud de compra el proveedor ha entregado un bien al responsable del proyecto, el cual debe hacer los trámites correspondientes para que sea

liberado el pago que cubra el bien adquirido.

5.7. Representación del conocimiento.

4CTORES

Esta parte del modelo del proceso que se sigue en la metodología

propuesta, tiene que ver con la creación de escenarios que permitan representar y

capturar el conocimiento del dominio durante la captura de requisitos. Como ya se

mencionó, un escenario constituye una descripción de los aspectos relevantes de

comportamiento y del ambiente de un sistema, mediante episodios concretos y

específicos usando generalmente lenguaje natural. A continuación se presenta en la tabla 5-1 un ejemplo de escenario 'que permite capturar el COnOCimientO

adquirido como parte del modelo de la metodología para la captura de requisitos

que se propone en este trabajo de tesis.

Coordinador de FOMES,

Proveedor,

Responsable de proyecto,

El uso de escenarios se aplicó al proceso que se sigue para administrar los

recursos otorgados por el gobierno federal a través del Fondo para Modernizar la Educación Superior en lo que corresponde al pago de solicitudes. En la tabla 5-1 se

presenta el escenario respectivo.

Propuesta Metodológica Para La Captura De Requisitos Ing. Mar th G. Martinez Rangel Pag.67


.ECURCOC

PISODIOC

Tesorero,

Zomité técnico,

Departamento de compra,

lepartamento de almacén,

[nstitución de crédito.

lisponibilidad del bien adquirido,

'ormato de solicitud de compra,

'ormato de solicitud de pago firmado por el responsable del proyecto, proveedor

I avalado por el comité técnico.

1.

2.

3.

4.

5.

6.

El responsable del proyecto solicita al coordinador de FOMES solicitud

de compra del bien requerido.

El coordinador de FOMES solicita al departamento de compras que

cotice y a su vez seleccione al proveedor que ofrezca mayores

beneficios.

El proveedor entrega el bien adquirido con factura que ampara el costo

al responsable del proyecto.

El responsable del proyecto solicita mediante solicitud de pago y

factura correspondiente la liberación de fondos que cubran el bien

adquirido.

El coordinador de FOMEC realiza los trámites para que la tesorería

genere el cheque por el monto que ampara la factura.

El coordinador de FOMEC mediante oficio instruye a la institución de

crédito la liberación de fondos para el pago de cheques.



EXCEPCION

7. El proveedor recoge cheque en la tesorería y se presenta ante la institución de crédito para el cobro correspondiente mediante la

presentación de cheque.

a) Si el proveedor no entrega el bien adquirido en el plazo establecido, se podrá prescindir de sus servicios.

b) Si la tesorería no libera el pago en el plazo establecido, el proveedor recibirá un monto extra por concepto de moratoria.

c) Si el proveedor no recoge cheque en la tesorería en un plazo

determinado, se cancelará su cheque y deberá iniciarse nuevamente todo

el proceso para pago.

Tabla 5-1. Escenario para la actividad de pago de solicitud.


Cap. 6. Evaluación y Resultados de la Metodología Cenidet

Capítulo 6 E valuacióay resultados de la propuesta metodo lógica

En este capítulo, se presenta la evaluación de la propuesta metodológrca y los resultados obtenidos de su aplicación en el caso de estudio.

Propuesta Metodológica para la Captura.de Requisitos Ing. Martin G. Martinez Rangel Pag.70

http://Captura.de


6.1 Criterios de evaluación

Es necesario llevar a cabo una evaluación cuando se propone una nueva metodología para la captura de requisitos. El objetivo es determinar los beneficios

que aporta sobre la practica actual. Los estudios o referencias que se tienen en

cuanto a la evaluación de otras metodologías similares indican que las formas o métodos existentes para tal fin están plagados de dificultades, ya que no existe

una forma de controlar su uso o aplicación por parte de los desarrolladores

experimentados y novatos, además de que no existe una forma de medir los

niveles de creatividad que éstos tengan. Por Io que se sabe, no existen desarrollos

comerciales que permitan comparar las metodologías existentes entre una y otra y

la Única forma de saber si una es buena o mala es aplicándola a un caso real que

permita identificar si los resultados obtenidos corresponden a lo que indica la

metodología o no.

En cuanto a las herramientas o técnicas utilizadas por la metodología

propuesta, mas adelante se hace una evaluación de cada una de ellas, se identifica

en qué aspectos son de utilidad, y su relativa madurez en cuanto a su aplicación para obtener información, expresión de requisitos y validación de los mismos.

En general, la evaluación de la metodología puede resultar buena en tanto

el analista experimentado, como el analista novato responsables de la captura de

requisitos, tengan conocimiento de la metodología que se propone. En [Fowler901

se indica que en el análisis final de una metodología para la captura de requisitos, ésta tiene valor si el producto final es considerado como bueno

Como se describe en [Winokur90], es esencial proveer de un entrenamiento

completo para la metodologia a evaluar y para todas las herramientas de soporte antes de que ésta sea aplicada a un sistema real para su evaluación, de Io

contrario, sin un entrenamiento propio de la metodología y las herramientas de soporte, el método puede emplearse mal y la evaluación puede estropearse.

Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel' Pag.71


Dado que esta Propuesta surge de dos metodologías desarrolladas para la captura de requisitos [Mittermeir90, Christel921, y que en su momento fueron

validadas por los autores, resulta necesario comentar que el modelo para la

captura de requisitos que aquí se presenta es muy similar a las metodologías antes

mencionadas. Con la salvedad de que en este modelo que se propone se integra la

fase de representación del conocimiento adquirido y se aclaran con mayor

precisión los beneficios que trae consigo el utilizar herramientas y técnicas, cuya

efectividad ya ha sido probada en otros casos de estudio en cuanto a que permiten

recuperar, organizar y representar la información adquirida

En este sentido es importante señalar que los criterios de evaluación de la metodología que se propone en este trabajo de tesis fueron tomados con base al

logro de las tareas que se deben realizar en cada uno de los pasos que contempla

la metodología y al beneficio que trae el uso de las herramientas mencionadas.

A continuación se presentan los puntos a evaluar en cada una de las

técnicas o herramientas y que son de gran utilidad en el proceso de captura de

requisitos, y utilizadas por la metodología.

Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Marthez Rangel Pag.72


I.

11.

111.

IV.

V.

VI.

VII.

VI11

IX.

La técnica es Útil en aspectos organizacionales o de análisis del contexto.

La técnica es Útil para evitar el diseño prematuro.

La técnica es Útil cuando existen varios colaboradores.

La técnica es Útil cuando existen varias disciplinas en la colaboración.

La técnica es Útil cuando el tamaño del problema es grande.

La técnica es útil cuando existen expresiones múltiples de requisitos.

La técnica es Útil cuando existe una gran volatilidad.

Cuando la técnica tiene ya una madurez reconocida.

Cuando la técnica se prescribe (resulta indispensable) de manera definida.

En la tabla 6-1 se presenta la evaluación de las técnicas que son de utilidad

en los aspectos de recuperación de información, expresión de requisitos y

validación de los mismos. En cada uno de esos aspectos es posible trabajar con

mas de una herramienta. Respecto a la columna VIII, donde se indica la relativa madurez de estas técnicas, es importante señalar que algunas de ellas son muy

maduras, ya que han sido probadas y usadas en la captura de requisitos por una década o mas. Otras son propuestas muy recientes que en el esfuerzo por

investigar se han presentado, pero no han sido muy usadas en el area de la


Si una técnica no esta clasificada en la columna de madurez (VIII) eso no

significa que no produzca buenos resultados, si no mas bien que no existe registro alguno que muestre su aplicabilidad en la captura de requisitos, pero se sugiere su

uso en este proceso.

Para calificar a cada una de las técnicas que se proponen, se utiliza la marca y, esta calificación pueden ser: dos marcas(qy) que significa que ya es reconocida


Cenidet Cap. 6. Evaluación y Resultados de la Metodología

CORE

Vistas múltiples de Delugach

SSM

su utilidad y que posee la calidad deseada, una marca (v) significa que es útil en

el aspecto donde se señala, pero que no es tan fuerte como otras técnicas y que posee la calidad deseada pero con un alcance limitado, sin marca o nada significa que la técnica no puede enfocarse a un aspecto dado, o que provee un pequeño

soporte.

w Y w w ww ww

y~ ww ww ww

iv w w

Aspectos I1 I11 I V V V I VI1 VI11 I X

QFD

Concepto de Prototificación

I I I I I I I . . . . .

REUNIÓN I DE INFORMACIÓN " ' '

- r - i i - i i - T -

w w w ww

w w w

I I I I I I I . , , J , . . . .

. . . . , . . ,: 7

I

4 EXPRESION DE REQUISTTOS . ,

I--- r,'-I17-- 77

Propuesta Metodológica para la Captura de Requisitos Ing. Martín G. Martinez Rangel ' Pag.74


En cuanto a la evaluación de la metodología aquí propuesta, se considera

Útil en cuanto a que los resultados obtenidos al aplicarla en el entorno real fueron buenos. Se concluyó que la metodología es Útil tanto para el analista novato como

para el analista experimentado. El único requisito que se indicó para poder

aplicarla es que quien la utilice debe tener un pleno conocimiento de la

metodología, identificar los pasos que debe seguir, tomar en cuenta las tareas a

realizar en cada uno de ellos, saber utilizar las herramientas y técnicas sugeridas, y

principalmente saber identificar los resultados que debe obtener en cada fase de la

metodología.

6.2 Resultados obtenidos

El modelo de la metodología para la captura de requisitos que se propone

en este trabajo de tesis se aplicó a la fase de captura de requisitos del proceso

para administrar los recursos otorgados por el gobierno federal a través del Fondo

para Modernizar la Educación Superior, FOMEC, a una institución de educación

superior, con el objetivo de construir un sistema de información.

Dado que la metodología propuesta consta de un modelo que indica

claramente los pasos a seguir para la captura de requisitos, así como las tareas a realizar en cada paso y los resultados que deben obtenerse producto de la

ejecución de esas tareas, resultó de mucha utilidad saber que esta metodología puede utilizarse para resolver el problema de búsqueda, recolección y organización de información dentro de las organizaciones con el objeto de capturar los

requisitos que deben cumplirse al construir un sistema de información.

Todas las actividades que se ejecutaron se agruparon en tareas asociadas

para encontrar hechos, obtener requisitos, evaluar y razonar los requisitos encontrados, asignar prioridades. Los resultado que se lograron se pueden resumir de la siguiente manera:


Cenidet Cap. 6. Evaluación y Resultados de la Metodología

a) Se logró tener una visión clara en un periodo muy corto acerca del contexto

del problema.

b) Se identificaron a los actores que intervienen en el proceso de captura de

requisitos.

c) Se identificaron sus deseos y necesidades, mismos que resultan en los

requisitos para la construcción del sistema requerido.

d) Se representó el conocimiento adquirido en cuanto a la actividad de pago

de solicitudes mediante la construcción de un escenario.

Propuesta Metodológica para la Captura de Requisitos Ing. Mattín G. Martinez Rangel Pag.76

Cap. VIL Conclusiones y trabajos futuros Cenidet

CaDziuZo 7 Conclusiones y trabajos futztros


Cap. VII. Conclusiones y trabajos futuros Cenidet

7.1 Conclusiones.

La capfura de requisitos ha recibido poca atención de la comunidad de la

ingeniería de software en el pasado, quizá por que es un area donde se tiene

que llegar a acuerdos de una manera informal, en vez de buscar etiquetas que

tengan que ver con requisitos, usualmente se negocia con la especificación y esta es la razón principal del porqué las definiciones del análisis de requisitos y la

especificación de requisitos de los sistemas de información, la mayoría de las

veces resultan en desacuerdo con Io que realmente se espera que haga el

sistema en desarrollo. De esa observación se ha aprendido que el análisis de

requisitos, en particular la captura de requisitos, es una tarea difícil, que es

cuidadosamente evadida por la mayoría de los responsables de la especificación

de sistemas de información y que no la enfrentan por no tener a la mano los

elementos suficientes que les permitan capturar el conocimiento necesario que

los lleve a los requisitos.

Se reconoce que el trabajo desarrollado aquí es difícil de encajar dentro de

las ciencias, ya que el rigor científico marca que todo trabajo que se desarrolle

dentro de cualquier disciplina de la ingeniería de software, en especial dentro de

la ingeniería de requisitos, este debe tener una buena dosis de formalismo, que

permita sistematizar el proceso de que se trate, en este caso el proceso de


Es evidente que este trabajo no es el eslabón perdido dentro de la

ingeniería de requisitos, pero si representa un esfuerzo por responder de una

manera mas clara a los problemas que se tienen en la captura de requisitos y

apoyar con ello el trabajo que debe realizar el analista de sistemas dentro de una realidad que existe y que esta dentro de las organizaciones que esperan que las


Cenidet Cap. VII. Conclusiones y trabajos futuros

soluciones que se proponga este de acuerdo con los deseos y necesidades de los

usuarios.

7.2 Trabajos futuros.

Uno de los trabajos que se proponen como continuación de esta tesis, es la

sistematización de la captura de requisitos, con el objeto de poder entregar los

resultados a la persona responsable de hacer el análisis del sistema en

construcción. La solución que se proponga debe apoyar al analista de requisitos

identificar que deseos y necesidades de un usuario o grupo de usuarios se

contraponen con los deseos y necesidades de otro usuario o grupo de usuario de

manera sistemática.

Propuesta Metodológica Para La Captura De Requisitos Ing. Marth G. Martínez Rangel Pag.79

Referencias bibliográficas Cenidet

[Congress 901

[Christel92]

[ DoD 911

[IEEE 831

[IEEE 901

[SEI 911

[Adriole 901

REFERENCIAS BIBLIOGRAFICAS

US. Congressinal Subcommittee on Investigations and Oversight.

Bugs in the Program: Problems in Federal Government Computer software Development and Regulation. Technical Report 4/90

Staff Study, U.S. 101 St Congress, Washington, DC, April 1990.

Software Engineering Institute Requirements Engineering Project.

Issues I n Requirements Elicitation. Technical Report CMU/SEI-92- TR-12, Software Engineering Institute, Carnegie Mellon

University, Pittsburgh, P.

US. Department of Defense. Software technology Plan: Volume I1

Plan of Action (Technical Report Draft 5, 8/15/91), U.S. Department of Defense, August 1991.

Institute of Electrical and Electronics Engineers. IEEE Standard

Glossary of Software Engineering Terminology. ANSI/IEEE

Standard 729-1983, Institute of Electrical and Electronics Engineers, New York, 1983.

Institute of Electrical and Electronics Engineers. IEEE Standard Glossary of Software Engineering Terminology. IEEE Standard

610.12-1990 (revision and redesignation of IEEE Std. 729-1983),

Institute of Electrical and Electronics Engineers, New York, 1983.

Software Engineering Institute Requirements Engineering Project. Requirements Engineering and Analysis Workshop Proceedings Technical Report CMU/SEI-91-TR-91-30, Software Engineering Institute, Pittsburgh, PA, December 1991.

Andriole, Stephen I. Command and Control Information Systems Engineering: Progress and Prospects. Advances in Computers

Metodología Para La Captura De Requisitos Ing. Martin G. Martínez Rangel Pag.80

Cenidet Referencias bibliográficas

[Begeman 881

[Berlin 891

[Cameron 861

[Cameron 891

[Checkland 901

[Conklin 88 ]

[Conklin 911

[Cordes 891

[Duran981

[Davis 901

31:l-98, 1990.

Begeman, Michael L., and Conklin, Jeff. The Right TOO! for the Job. BYTE 13(10):255-266, October 1988.

Berlin, Lucy M. User-Centered Application Definition: A

Methodology and Case Study. Hewlett-Packard Journal 40(5):90-

97, October 1989.

Cameron, John R. An Overview of JSD. IEEE Transactions on

Software Engineering SE-12(2):222-240, February 1986.

Cameron, John R. Prototyping Core Functionality Using JSD. I n

IEE Colloquium on “Requirements Capture and Specification for

Critical Systems” (Digest No. 138), 2/1-2/2. Institution of Electrical

Engineers, November 1989.

Checkland, Peter & Scholes, Jim. Soft Systems Methodology in

Action. New York:John Wiley & Sons, 1990.

Conklin, Jeff, and Begeman, Michael L. g1BIS:A Hypertext Tool

for Exploratory Policy Discussion. ACM Transactions on Office Information Systems 6(4):303-331, October 1988.

Conklin, Jeff, and Yakemovic, K.C. Burgess. A Process-Oriented

Approach to Design Rationale. Human-Computer Interaction

6(3/4):357-391, 1991.

Cordes, D.W., and Carver, D.L. Evaluation Method for User Requirements Documents. Information and Software Technology.

Duran, A. et ai., “Una propuesta metodológica para la recolección

de requisitos de un sistema software”, 111 Jornadas de Trabajo MENHIR, 1998.

Davis, Alan M. Software Requirements: Analysis and Specification. Prentice Hall: Englewood Cliffs, NJ, 1990.

Metodología Para La Captura De Requisitos Ing. Martin G. Martinez Rangel Pag.81


[De Bortol~2000]. Lis Angela de Bortoli, Ana María de Alencar Price "Un Método de

[Delugach 911

[Dobson 911

[Dobson 921

[Dubois 881

[Finkelstein 861

[Fowler 901

Trabajo Para Auxiliar la Definción de Requisitos". Memorias. Jornadas Iberoamericanas de Ingeniería de Requisitos y

Ambientes de Software. Cancún, México, abril del 2000.

Delugach, Harry S. A Multiple Viewed Approach to Software

Requirements. Ph.D. thesis, University of Virginia, 1991.

Dobson, J.E., Martin, M.J., Olphert, C.W., and Powrie, S.E. Determining Requirements for CSCW: the ORDIT Approach. IFIP

Conference on Collaborative Work, Social Communications and

Information Systems (COSCIS91):333-35. Elsevier Science

Publishers B.V. (North-Holland), 1991.

Dobson, J.E., Blyth, A.J.C., Chudge, J., and Strens, M.R. The

ORDIT Approach to Requirements Identification. Proceedings of

the Sixteenth Annual International Computer Software &

Applications Conference. IEEE Computer Society, September

1992.

Dubois, E., Hagelstein, J., and Rifaut, A. formal Requirements

Engineering with ERAE. Philips Journal of Research 43(3/4):393-

414, 1998.

Finkelstein, Anthony, and Potts, Colin. Structured Common Sense:

The Elicitation and Formalization of System Requirements. Software Engineering 86. London: Peter Peregrinus, Chapter 16, 1986.

Fowler, C.I.H., Kirby, M.A.R., and Macaulay, L.A. Historical Analysis:A Method for Evaluating Requirements Capture Methodologies. Interacting with Computers 2(2):190-204, August

1990.

Metodología Para La Captura De Requisitos Ing. Martín G. Martínez Rangel Pag.82


[Greenspan941

[Goguen97]

[ GA0921.

CGalvao991

[Goodrich 901

[Hsia94]

[Holbrook 901

[Jokela 901

[Jordan 901

S. Greenspan, 3. Mylopoulos, and A. Borgida. "On Formal Requirements Modelling Languages: RML Revisited." Proc. idh ht. Cant: Sohare €ng. Pp. 135-148, Sorrento, Italy, May 1994.

Goguen, J. A. and C. Linde, 'Techniques for Requirements

Elicitation", Software Requirements Engineering, 2"d. Ed., IEEE CS

Press, 1997, pp 110-122.

US General Accounting Office, Mission CFitical Systems: Defense

Attempting to Address Major Sohare Challenges, GAOIIMTEC-

93-13, December 1992.

Galvao Martins L.E, Mascia Deltrini B. "Activity Theory: a

Framework to Software Requirements Elicitation" I1 Jornadas

Iberoamericanas de Ingeniería de Requisitos. Buenos Aires,

Argentina, Septiembre de 1999.

Goodrich, Victoria, and Olfman, Lorne. An Experimental Evaluation

of Task and Methodology Variables for Requirements Definition Phase Success. In Bruce O. Shriver (editor), Proceedings of the Twenty-Third Annual Hawaii International Conference on System

Sciences, 201-209. IEEE Computer Society, January 1990.

Hsia Pei et. al, Formal Approach to Scenario Analysis, IEEE

Software, March 1994.

Holbrook, Capt. Hilliard 111. A Scenario-Based Methodology for

Conducting Requirements Elicitation. ACM SIGSOFT Software Engineering Notes 15(1):95-104, January 1990.

Jokela, Timo, and Lindbergh, Kal. Statecharts Based Requirements Analysis: Deriving User Oriented Models. Microprocessing and Microprogramming 30( 1-5):289-296, August 1990.

Jordan, Pamela W., Seller, Karl S., Tucker, Richard W., and Vogel,

Metodología Para La Captura De Requisitos Ing. Martín G. Martinez Rangel Pag.83


[Kang 901

[Kean 911

[Leite97]

[Laguna991

[Macaulay 901

[McDermid 891

[Mittermeir 901

David. software Storming: Combining. Rapid Prototyping and .

Knowledge Engineering. IEEE Computer, 39-48, May 1989.

Kang, KYo c., Cohen, Sholom G., Hess, James A., Novak, William E., and Peterson, A. Spencer. Feature-Oriented Domain Analysis

(FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21,

‘ADA235785, Software Engineering Institute, Pittsburgh, PA,

November 1990.

Kean. Elizabeth C. An Informal Approach to Developing an

Environment for Requirements Capture and Refinement. In Proceedings of the Requirements Engineering and Analysis

Workshop Held 3/91.

Leite J.C.S.P., Rossi G.,et al, Enhancing a Requirements Baselíne

with Scenarios, Proceedings of RE 97’: International Symposium

on Requeriments Engineering, IEEE, January 1997.

Laguna, M.A., Marqués, J.M., García, F;J., “A user requirements

elicitation tool”. I V Jornadas de Trabajo. MENHIR, Sedano, 1999.

Macaulay, Linda, Fowler, Chris, Kirby, Mark, and Hutt, Andrew. USTM: A New Approach to Requirements Specification. Interacting

with Computers 2(1):92-118, April 1990.

McDermid, J.A. Requirements Analysis: Problems and the STARTS Approach. I n IEE Colloquium on “Requirements Capture and Specification for Critica¡ Systems” .(Digest No. 138), 4/1-4/4.

Institution of Electrical Engineers, November 1989,

Mittermeir, Roland T., Roussopolus, Nicholas, Yeh, Raymnd T.,

and Ng, Peter A. An Integrated Approach to Requirements Analysis. Modern Software Engineering: Fundations and Current Perspectives. New York: Van Nostrand Reinhold, 119-164, Chapter

. .



Metodología Para La Captura De Requisitos Ing. Martin G. Marthez Rangel Pag.85

[Potts 911

[Porn951

[Ramesh 911

[Rzepka 891

[Sage 901

[Schouwen 901

[Schubett 891

5, 1990.

porn, Colin., Seven (Plus or Minus Two) Challenges for Requirements Analysis Research. I n Proceedings of the Requirements Engineering and Analysis Workshop Held 3/91

(CMU/SEI-9-1-TR-30). Software Engineering Institute. December

1991.

Potts C., Using Schematic Scenarios to Understand User Needs,

DIS95.

Ramesh, B. & Dhar, V. Representation and Maintenance of

Process Knowledge for Large Scale systems Development. I n

Proceedings of the Sixth Anual Knowledge-Based Software

Engineering Conference, 288-299. Rome Laboratory, Griffis AFB,

NY, September 1991.

Rzepka, William E. A Requirements Engineering Tested: Concept,

Status, and First Results. I n Bruce D. Shriver (editor), Proceedints

of the Twenty-Second Annual Hawaii International Conference on

System Sciences, 339-347. IEEE Computer Society, 1989.

Sage, Andrew P., and Palmer, James D. Software Systems Engineering. New York: John Wiley &Sons, 1990.

Van Schowen, A. John. The A-7 Requirements Model: Re-

Examination Real Time Systems and an Application to Monitoring

Systems. Technical Report 90-276, Queen’s University, May 1990.

Schubert, M.A. Quality Function Deployment: “A Comprehensive Tool for Planning and Development. I n Proceedings of the IEEE

1989 National Aerospace and Electronics Conference NAECON 1989 (Cat. No. 89CH2759-9), 1498-1503. IEEE Dayton Section

Aerospace and Electronic Systems Society, IEEE, New York, May


[Silva851

[Stair 911

[STEP 911

[Stephens 851

[Thayeer97]

[Va n9 71

[Volere20001

[Winokur 901

1989.

Silva, M., "Las redes de Petri en la automática y la informática",

Madrid, 1985.

Stair, Ralph M. Jr., and LaMothe, Richard S. The Use of Systems

Planning Methodologies. Journal of Computer Information

Systems 318(2):34-37, Winter, 1990-1991.

Software Test & Evaluation Panel (STEP), Requirements Definition

Implementation Team. Operational Requirements for Automated Capabilities, Draft Pamphlet (Draft PAM), April 23, 1991.

Stephens, M., and Whitehead, K. The Analyst-A Workstation for

Analysis and Design. I n Proceedings of the Eight IEEE

International Conference on Software Engineering. IEEE Computer

Society Press, 1985.

Thayeer H. Richard [y] Dorfman Morlin, Software Requirements

Engineering. (segunda edición, IIE, computer Society Press, Los

Alamitos California, 1997).

Van der Aalst, W.M.P., "The application of Petri Nets to Workflow

Managment", Eindhoven University of Technology, Netherland, 1997. URL: wwwis.win.tue.nl/-wsinwa/jcsc/jcsc.html

"Requirements Specification Template". Edition 6.1 James & Suzanne Robertson Principals of the Atlantic Systems Guild.

London, Aachen & New York,2000

Winokur, M., Lavi, J.Z., Lavi, I., and Oz, R. Requirements Analysis and Specification of Embedded Systems Using ESCAM-A Case Study. I n Proceedings of the 1990 IEEE International Conference on Computer Systems and Software Engineering (Cat. No.

90CH2867-0), 80-89. IEEE Computer Society Press, May 1990.



[Yakernovic901 Yakemovic, K.C. Burgess, and Conklin, E. Jeffrey. Report on a Development Project Use of an Issue-Based Information System.

I n CSCW '90 Proceedings. ACM, October 1990.

[Yu95a] Yu, E. S. K, "Modelling Strategic Relationships for Process ReEngineering", Ph.D. Thesis. Department of Computer Science,

University of Toronto, 1995

Zahniser, Richard A. How to Speed Development with Group Sessions. IEEE Software, 109-110, May 1990.

Zorman L., The Content and Compositkm of Scenarios, OOPSLA Workshop, Requirements Engineering: Use cases and more, 1995.

Zucconi, Lin. Techniques and Experiences Capturing Requirements

for Several Real-Time Applications. ACM SIGSOFT Software

Engineering Notes 14(6):51-55, October 1989.

[Zahniser 901

[Zorman95]

[Zucconi 891

[Fomes 20011 http://sesic.sep.gob.mx/fomes/index. htm

Metodología Para La Captura De Requisitos Ing. Martín G. Martínez Rangel Pag.87

http://sesic.sep.gob.mx/fomes/index

SEP SEIT DGIT - CENIDET Martin Gerardo... · felices de mi vida. , A mi madre, por el ejemplo de...

Documents

Transcript of SEP SEIT DGIT - CENIDET Martin Gerardo... · felices de mi vida. , A mi madre, por el ejemplo de...