Definición de Una Metodología Ágil de Ingeniería de Requerimientos

7/26/2019 Definición de Una Metodología Ágil de Ingeniería de Requerimientos

http://slidepdf.com/reader/full/definicion-de-una-metodologia-agil-de-ingenieria-de-requerimientos 1/15

Revista Científica Guillermo de Ockham

ISSN: 1794-192X

[email protected]

Universidad de San Buenaventura

Colombia

Merchán, Luis; Urrea, Alba; Rebollar, Rubén

Definición de una metodología ágil de ingeniería de requerimientos para empresas emergentes de

desarrollo de software del sur-occidente colombiano

Revista Científica Guillermo de Ockham, vol. 6, núm. 1, enero-junio, 2008, pp. 37-50

Universidad de San Buenaventura

Cali, Colombia

Disponible en: http://www.redalyc.org/articulo.oa?id=105312257003

Cómo citar el artículo

Número completo

Más información del artículo

Página de la revista en redalyc.org

Sistema de Información Científica

Red de Revistas Científicas de América Latina, el Caribe, España y Portugal

Proyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto

http://www.redalyc.org/articulo.oa?id=105312257003

http://www.redalyc.org/comocitar.oa?id=105312257003

http://www.redalyc.org/fasciculo.oa?id=1053&numero=12257


http://www.redalyc.org/revista.oa?id=1053

http://www.redalyc.org/



http://www.redalyc.org/fasciculo.oa?id=1053&numero=12257

http://www.redalyc.org/comocitar.oa?id=105312257003





Revista Científica Guillermo de Ockham. Vol. 6, No. 1. Enero-Junio de 2008 - ISSN: 1794-192X 37

Definición de unametodología ágilde ingenieríade requerimientospara empresas emergentes

de desarrollo de softwaredel sur-occidentecolombiano*

Definition of a responsive methodology of engineering of requirements foremergent software development companies in the southwestern partof Colombia.

Luis Merchán

Alba Urrea

Rubén Rebollar

ResumenComo industria, el software requiere de

productos y servicios de alta calidad, lo cual

se logra mediante la aplicación de modelosy metodologías de calidad reconocidos in-ternacionalmente. Las empresas emergentes

LUIS MERCHÁN. Ingeniero de Sistemas. Especialista en Finanzas. Magíster en Administración. Doctorado en Dirección deproyectos. email: [email protected]

ALBA URREA. Ingeniera de Sistemas. Magíster en Ingeniería de Sistemas y Computación. e-mail: [email protected]

RUBÉN REBOLLAR. Ingeniero Industrial. Doctor en Ingeniería Industrial. e-mail: [email protected]

• Fecha de recepción del artículo: octubre de 2007 • Fecha de aceptación: marzo de 2008.

no logran aplicar estas metodologías pues sugran obstáculo se observa en los altos costosde implementación, el recurso humanorequerido y los estándares exigidos querestringen la creatividad, parte importantede su capital. El Laboratorio de Investiga-ción para el Desarrollo de la Ingeniería de

* Artículo producto del proyecto deinvestigación denominado “Imple-mentación de los modelos livianos degestión de requerimientos y gestiónde la configuración y diseño de unmodelo liviano de apoyo al área deaseguramiento de calidad del procesode desarrollo de software para pequeñasempresas del Valle del Cauca”. Grupode investigación Lidis.



38 Universidad de San Buenaventura, Cali, Colombia

Luis Merchán, Alba Urrea, Rubén Rebollar

Software (LIDIS), siendo consecuente conesta situación, adelantó una investigaciónque propone un modelo liviano de mejo-ramiento de los procesos de desarrollo desoftware partiendo de la caracterización delas empresas emergentes.

Palabras clave: Ingeniería de requeri-mientos, desarrollo de software, empresasemergentes.

Summary As an industry, software requires high

quality products and services, which areobtained by means of the application ofhigh quality models and methodologiesrecognized worldwide. Emergent companiesdo not manage to apply these methodologies,due to the high costs of implementation, therecruitment of a qualified human resourceand the demanded standards that restrictcreativity, which are an important part oftheir capital. e Research Laboratory forthe Development of Software Engineering(LIDIS), as a response to this situation,carried out an investigation that proposes alight model of improvement of the softwaredevelopment processes, starting off from thecharacterization of emergent companies.

Key words: Engineering of require-ments, software development, emergentcompanies.

IntroducciónUn factor estratégico para las empresas

desarrolladoras de software debe ser laaplicación de modelos de mejoramientode procesos, que una vez adoptados en losproyectos de software puedan disminuirlos costos de producción y la inversión de

recursos en el mantenimiento de los res-pectivos productos y servicios. Los modelosy metodologías actuales son extranjeros yajenos a las condiciones y/o característicaspropias, con servicios de capacitación muyformales y servicios de consultoría excesiva-mente costosos y no son fáciles de aplicar enorganizaciones pequeñas.

Si bien la caracterización de las empresasemergentes del sur occidente colombiano

muestra la necesidad de utilizar modelos demejoramiento de procesos propios, fácilesde entender y aplicar, algunos países comoMéxico ya tiene participación en la norma-lización internacional, mediante el SistemaNormativo Mexicano (NOM-NMX), em-

pleado en MoProSoft (Modelo de Procesosde Software), el cual ha sido fruto de investi-gaciones similares basadas en modelos comoSW-CMM, el estándar ISO 9000 y el reportetécnico ISO/IEC TR 15504; igualmenteBrasil cuenta con MARES (Método de Va-lidación de Proceso de Software en Micro yPequeñas Empresas) (Karim Pickler, et al,2007). Se debe destacar que con la adopciónde un modelo liviano de mejoramiento deprocesos se pretende habilitar, incluso enalgunos casos, la fase inicial de preparaciónpara la obtención de certificados ISO 9000y reducir la brecha para la obtención de unaevaluación CMM o CMMI nivel 2.

Este artículo inicia con una revisión de li-teratura pertinente seguida de un diagnósticopara las empresas emergentes, basándose enla muestra de población y el instrumento derecolección de datos, en seguida se presentaun análisis de los datos para determinar losfactores problema en el proceso de ingenie-ría de requerimientos. Luego, se muestra la

relación de fases y actividades junto con lasdescripciones, las entradas y salidas de cadafase y las buenas prácticas que acompañanla metodología ágil. Se concluye con unadiscusión sobre los hallazgos y cómo estosson suplidos en la metodología.

Revisión de literaturaLa ingeniería de requerimientos cumple

un papel primordial en el proceso de pro-ducción de software, ya que enfoca un área

fundamental: la definición de lo que se deseaproducir. Su principal tarea consiste en lageneración de especificaciones correctas quedescriban con claridad, sin ambigüedades, enforma consistente y compacta, el comporta-miento del sistema. Como disciplina, estable-ce el proceso de definición de requerimientosen una sucesión de actividades mediantelas cuales lo que debe hacerse se “elicita”, semodela y analiza (Choque, 2001).




Definición de una metodología ágil de ingeniería de requerimientos..., pp. 37-50

La obtención de requerimientos tratasobre la comunicación entre los desarrollado-res, clientes y usuarios para definir el nuevosistema que brinde una solución al problema;a esta definición del sistema se le denominaespecificación de requerimientos, que a su

vez sirve como contrato entre el cliente ylos desarrolladores. Tanto la obtención derequerimientos y su análisis se enfoca en lavisión que tiene el usuario del sistema.

Según las investigaciones realizadas (So-merville, 1997), en el proceso de ingenieríade requerimientos son esenciales diversasactividades. En esta propuesta de metodolo-gía ágil dichas actividades serán presentadassecuencialmente, sin embargo, en un procesoefectivo de ingeniería de requerimientos

estas son aplicadas de manera continua y enorden variado.

La metodología ágil de ingeniería derequerimientos que se propone en esta

investigación está basada en el modelo demadurez de capacidades integrado (CMMI,2002), el estándar ISO/IEC 12207 (están-dar para los procesos de ciclo de vida delsoftware de la organización ISO) (ISO,2006) y el referente teórico sobre procesosy procedimientos de ingeniería de requeri-mientos (Beck, 200), (Bennington, 1956),(Boehm, 1998), (Choque, 2001), (Fowler,2001), (Jacobson et al, 1992), (Jeffries et al,2001), (Johnson, 1992), (Moprosoft, 2006),(Newkirk, 2004), (Nielsen, 1994), (Marck,1994), (Paech, 1998). De estos referentes seseleccionaron las mejores prácticas para losprocesos de ingeniería de software con el finde desarrollar la metodología orientando los

esfuerzos a que dichos procesos siempre seandesarrollados de manera óptima y de acuerdocon el contexto de las empresas emergentes(Ver Tabla 1).

Tabla 1 Análisis comparativo mejores prácticas en ingeniería de requerimientos

INGENIERÍA DE

REQUERIMIENTOS MODELOS ESTÁNDARES

METODOLOGÍA

ÁGIL

Procesos yProcedimientos CMMI ISO 12207

Mejores prácticaspara implementar

Elicitación Establecer criterios paradistinguir proveedores derequerimientos apropia-dos.

Alcanzar un entendimientode los requerimientos paraque los integrantes delproyecto se puedan com-prometer con ellos.

Establecer y documen-tar los requerimientos delsoftware.

Establecer crite-rios para distin-guir proveedoresde requerimien-tos.

Especificación Establecer criterios objeti-vos para la aceptación derequerimientos.

Analizar los requerimientospara garantizar que loscriterios establecidos secumplan.

Evaluar los requerimientosdel software.

Llevar a cabo revisionesconjuntas.

Evaluar los re-querimientos delsoftware a partir

de criterios esta-blecidos.

Gestión Obtener un compromisocon los requerimientos.

Administrar los cambios delos requerimientos.

Mantener la trazabilidad delos requerimientos.

Priorizar los re-querimientos.

Administrar cam-bios.

Realizar la traza-bilidad.





Diagnóstico para las empresasemergentes de software

Características de la población

Como marco de desarrollo de la carac-

terización, se tomó al sur occidente colom-biano por tratarse del cluster de desarrollo desoftware más grande y maduro del país. Deltotal de 306 empresas, se trabajó sobre unamuestra de 49 empresas (16%) (Ver Tabla 2).En Merchan, et al (2007), se detalla el trabajode campo y de experimentación seguido pararecolectar y obtener los resultados de caracte-rización de la industria y su diagnóstico.

Instrumento de recolección de datos

Se realizaron entrevistas a los ingenierosinvolucrados en las actividades de desarrollode software de cada una de las empresas dela muestra a través de un cuestionario con-formado por 3 secciones:

1. Información general.

2. Información de los modelos de procesosque la empresa utiliza en las iniciativasde mejoramiento.

3. Información de los procesos para el desa-rrollo de software que realiza la empresaen cuanto a:• Ingeniería de requerimientos.

• Planeación de proyectos.

• Administración de configuración.

• Aseguramiento de calidad en el soft-ware.

Tabla 2Población

REFERENTENÚMERO TOTAL

DE EMPRESAS

ParqueSoft Cali 183

ParqueSoft Palmira 8

ParqueSoft Tulúa 19

ParqueSoft Popayán 34

ParqueSoft Pereira 21

ParqueSoft Manizales 27

ParqueSoft Pasto 14

Análisis de datos

El diagnóstico se fundamentó en la aplica-ción de métodos, técnicas y herramientas enlas fases del proceso de ingeniería de reque-rimientos (de elicitación, de especificación y

de gestión de requerimientos) por parte delas empresas emergentes.

En ingeniería de requerimientos se exa-minaron aspectos como:

• La ejecución de procesos y procedimien-tos de administración de requerimien-tos.

• El uso de herramientas que soportan elproceso de administración de requeri-mientos

De lo anterior, se logran evidenciar los

factores problema presentes en las tres fasesde ingeniería de requerimientos (Ver gráficas1 y 2).

En los resultados obtenidos, se evidenciaque las empresas pertenecientes a la indus-tria emergente de software necesitan demetodologías que soporten las actividadesde sus procesos de desarrollo de software. A pesar que la mayoría de ellas asegure suutilización, las actividades no se realizan de laforma correcta o en otros casos no se aplicancorrectamente.

En el proceso de ingeniería de reque-rimientos que efectúan estas empresas, seencontraron notables problemas en cadauna de sus fases:

• Gran parte de las empresas encuestadas(58.3%) no establecen criterios para laaceptación de proveedores de requeri-mientos, lo que puede traer falenciaspara el desarrollo del proyecto porcuanto las fuentes de los requerimientosno tienen dominio de la problemática

del sistema ni de sus procesos, así comoobtener requerimientos mal interpre-tados e inconsistentes e incluso omitirrequerimientos que pueden ser necesariospara la solución.

• Un alto porcentaje de ellas (48.71%) noestablece criterios para la aceptación derequerimientos, factor que puede ocasio-nar la presencia de errores en el desarrollode los requerimientos que redunden en





Gráfica1Fases elicitación y especificación de requerimientos

No sabe

No se hace

De vez en cuando

Regularmente

Siempre se hace

0 0

105%

90%

75%

60%

45%

30%

15%

0%Criterios

para aceptación

de proveedores.

Criterios

para aceptación

de requerimientos.

Gráfica 2Fase gestión de requerimientos

No sabe

No se hace

De vez en cuando

Regularmente

Siempre se hace

105%

90%

75%

60%

45%

30%

15%

0%

Administración de

trazabilidad de los

requerimientos

Administración

de cambios de los

requerimientos

Historial de

cambios de los

requerimientos





Gráfica 3Estructura de la metodología ágil para el proceso de ingeniería de requerimientos

Metodología ágilpara el proceso de ingeniería

de requerimientos

FASE 1: Elicitaciónde requerimientos

FASE 2: Especificaciónde requerimientos

FASE 3: Gestiónde requerimientos

ACTIVIDAD 1: Evaluar los proveedoresde requerimientos a entrevistar

ACTIVIDAD 2: Definir la estrategiade recolección de requerimientos

ACTIVIDAD 3: Planificar reuniones

de elicitación de requerimientos

ACTIVIDAD 4: Identificar los procesosdel sistema

ACTIVIDAD 5: Identificar requerimientosfuncionales

ACTIVIDAD 6: Identificar losrequerimientos no funcionales

ACTIVIDAD 1: Descrubur los requerimientos

ACTIVIDAD 2: Evaluar los requerimientos

ACTIVIDAD 1: Priorizar los requerimientos

ACTIVIDAD 2: Almacenar los requerimientos enun repositorio central

ACTIVIDAD 3: Asignar al grupo de desarrollo losrequerimientos del software

ACTIVIDAD 4: Administrar los cambiosen los requerimientos

ACTIVIDAD 5: Administrar la trazabilidadde los requerimientos

retrasos en los cronogramas de trabajo,trabajo repetitivo o hasta rechazo delcliente.

• En la fase de gestión de requerimientos,se observa que las empresas (43.6%) norealizan la administración de la trazabili-

dad de los requerimientos (factor esencialen la fase de gestión de requerimientos),y por ello las dificultades que puedenpresentar en la ubicación de fallas en losrequerimientos desde la documentaciónhasta el producto final. Tanto el historialcomo la administración de cambiosson también factores ignorados. Estasituación conduce al desconocimientodel impacto que los cambios puedangenerar, las razones de ellos, cómo se hi-cieron, cuándo fueron hechos y quién losautorizó, entre otros. Esta informaciónhistórica de los cambios es útil para latoma futura de decisiones.

A partir de este diagnóstico se creó lanecesidad de disponer de una metodologíaágil del proceso de ingeniería de requeri-mientos, ya que por el concepto mismode “metodología ágil” les representará, alas empresas emergentes, una facilidad de

implementación, uso de pocos recursos yun apoyo en la ejecución de sus procesos deingeniería de software.

Metodología ágil para el procesode ingeniería de requerimientos

Basándose en el diagnóstico de la industriade software del sur occidente colombiano, lametodología ágil va dirigida a dos tipos deproyectos: desarrollo a la medida e ideas denegocio. La metodología se ha estructurado

en tres fases (Ver gráfica 3).Elicitación de requerimientos: su pro-

pósito es obtener un óptimo entendimiento





de los requerimientos del software en losparticipantes –los usuarios finales y los desa-rrolladores–, e identificar los requerimientosfuncionales y no funcionales.

Especificación de requerimientos: Su

propósito es describir cada uno de los re-querimientos del software, sus políticas ysus restricciones.

Gestión de requerimientos: Su propósitoes administrar los cambios de los requeri-mientos, mantener las relaciones entre ellose identificar las inconsistencias que puedanocurrir en el transcurso del proyecto.

Cada fase incluye un conjunto de activi-dades a las cuales anteceden unas entradaspropias del tipo de proyecto y les precedenunas salidas:

• Entradas.

• Actividades.

• Salidas.

Elicitación

Esta fase tiene tres entradas (Ver Tabla3) y seis actividades planteadas las cuales sedetallan a continuación:

1. Actividad 1: Evaluar los proveedores

de requerimientos a entrevistarEl objetivo es verificar que las personas

a entrevistar o las fuentes de información

cumplen con los criterios establecidos enla Tabla 3.

En los proyectos de desarrollo a la medida,normalmente es preferible iniciar con loslíderes funcionales, ya que ellos tienen una

visión global de los procesos y comprendenel dominio del problema. Luego se continúacon los futuros usuarios, es decir, usuariosfinales, porque ellos pueden aportar infor-mación más detallada sobre el entorno ope-racional de la organización. En la Tabla 4 sepueden observar los criterios para distinguirlos proveedores de requerimientos.

2. Actividad 2: Definir la estrategia de recolección de requerimientos

Esta actividad tiene como objetivo ve-rificar que la estrategia de recolección derequerimientos sea la recomendada, según eltipo de proyecto a desarrollar. La estrategiaayuda tanto a desarrolladores como a usua-rios a conocer la problemática del entornoa mejorar e identificar las necesidades de laorganización cliente, mientras que para losemprendedores, les permite conocer el entor-no donde aspiran consolidar su negocio.

Para los proyectos de desarrollo a la medi-

da pueden aplicar estrategias tales como lasentrevistas y el desarrollo de aplicaciones deagregación (JAD) (Ver Tabla 5).

Tabla 3Entradas por tipo de proyecto

TIPO DE PROYECTO NOMBRE ENTRADA FUENTE

Proyecto de desarrollo ala medida

• Descripción del sistema actual

• Descripción de la problemáticadel sistema actual

• Diagramas de los procesos actua-les del sistema

Fuentes de información

Proyecto de ideas de ne-gocio

• Condiciones del mercado

• Aplicaciones competencias

• Estudios de mercado

• Personas que trabajan en elmismo negocio

• Posibles consumidores

• Búsquedas en Internet

• Docentes universitarios decarreras afines

• Documentación especializadaen el tema





3. Actividad 3: Planificar reuniones

de elicitación de requerimientosEsta actividad tiene como objetivo:

• Identificar los usuarios del proyecto.

• Conocer los procesos de la organiza-ción cliente.

• Identificar las actividades necesarias.

Después de definir la estrategia de reco-lección de requerimientos, se planificaránreuniones de elicitación de requerimientos.

Tabla 5Estrategias para la recolección de requerimientos

TIPO DE PROYECTO NOMBRE DESCRIPCIÓN

Proyecto de desarrolloa la medida

Entrevistas Es la técnica de elicitación másutilizada por ser una de lasformas de comunicación másnaturales entre las personas

Joint Application Development

(JAD)

En estas reuniones se ayuda a

los clientes y usuarios a formularproblemas y explorar posiblessoluciones, involucrándolos yhaciéndolos sentirse participesdel desarrollo

Proyecto de ideas de negocio Brainstorming Es una técnica de reuniones engrupo cuyo objetivo es la gene-ración de ideas en un ambientelibre de críticas o juicios

Tabla 4Criterios para la distinción de proveedores de requerimientos

TIPO DE PROYECTO NOMBRE DESCRIPCIÓN

Proyecto de desarrollo ala medida

Usuario líder Son las personas que compren-den el dominio del problema endonde será empleado el softwaredesarrollado

Usuario final Son las personas que usarán elsistema desarrollado. Serán quie-nes utilicen las interfaces y losmanuales de usuario

Proyecto de ideas de ne-gocio

• Personas que trabajen en el mis-mo negocio

• Posibles consumidores

• Documentación especializadaen el tema

• Otras aplicaciones competen-

cias

Implica factores como:

• Condiciones del área paracompetir

• Condiciones del entorno glo-bal

• El sector

En los proyectos de desarrollo de softwarea la medida, esta actividad es fundamentalya que en estas reuniones los desarrolladoresconocen las necesidades de la organizacióncliente e identifican quiénes serán los usua-rios del nuevo sistema.

4. Actividad 4: Identificar los procesosdel sistema

Esta actividad tiene por objetivos:

• Identificar entradas y salidas de losprocesos.





Algunos tipos de requisitos que se suelenincluir en esta sección son los siguientes:

• Los requisitos de comunicaciones delsistema , los cuales son de caráctertécnico relativos a las comunicacio-nes que deberá soportar el software

a desarrollar. Por ejemplo: el sistemadeberá utilizar el protocolo TCP/IPpara las comunicaciones con otrossistemas.

• Los requisitos de interfaz de usuario,que especifican las características quedeberá tener el sistema en su comu-nicación con el usuario.

• Los requisitos de fiabilidad que debenestablecer los factores requeridos parala fiabilidad del software en tiempode explotación. La fiabilidad mide la

probabilidad del sistema de produ-cir una respuesta satisfactoria a lasdemandas del usuario. Por ejemplo:la tasa de fallos del sistema no podráser superior a 2 fallos por semana.

• Los requisitos de entorno de desarrollo,los cuales especifican si el sistemadebe desarrollarse con un productoespecífico.

• Los requisitos de portabilidad , los cua-les definen qué características deberátener el software para que sea fácilutilizarlo en otra máquina o bajo otrosistema operativo.

Ver en la Tabla 6 la salida que tiene la fasede elicitación de requerimientos.

• Identificar las actividades que se rea-lizan en cada proceso del sistema.

• Identificar el personal que intervieneen los procesos del sistema.

• Realizar diagramas de los procesos delsistema.

Una vez se han planificado las reunionesde elicitación y se conocen las necesidadesde la organización cliente, es fundamentalconocer también los procesos del sistemaque necesitan ser mejorados. Asimismo estosprocesos ayudan a proveer información másespecífica para el planteamiento de los reque-rimientos funcionales y no funcionales.

5. Actividad 5: Identificarrequerimientos funcionalesEsta actividad tiene por objetivos:

• Identificar los requerimientos fun-cionales que el software deberá cum-plir.

• Resolver posibles conflictos.En ella se debe identificar o revisar si exis-

ten conflictos y qué debe hacer el sistema adesarrollar con la información registrada enlas actividades 3 y 4. Se toma cada procesoidentificado y se definen requerimientos porcada proceso.

6. Actividad 6: Identificar losrequerimientos no funcionalesEsta actividad tiene por objetivo identi-

ficar los requerimientos no funcionales delsoftware a desarrollar.

Tabla 6Salida de la fase 1 para proyectos de desarrollo de software a la medida e idea de negocio

NOMBRE DESCRIPCIÓN DESTINO

Definición de requeri-mientos del software.

• Introducción: debe contener una brevedescripción de las características del

nuevo software a desarrollar y/o idea denegocio a llevar a cabo.• Procesos: debe contener los procesos del

sistema.• Requerimientos funcionales: se nombran

los requisitos funcionales que se hayanidentificado en dicho proceso.

• Requerimientos no funcionales: se nom-bran los requisitos no funcionales quese hayan identificado en dicho proceso.

Fuentes de información.





Tabla 8Salida fase de especificación de requerimientos

NOMBRE DESCRIPCIÓN DESTINODocumento de Especificaciónde Requerimientos (DER)

• Introducción

• Participante del proyecto

• Requerimientos funcionalesdefinidos

• Definición de actores

• Estrategia de especificaciónde requerimientos

• Requerimientos no funciona-les definidos

Grupo de desarrollo

Especificación

Esta fase, que tiene tres entradas (Ver Ta-bla 7), presenta las siguientes actividades:

1. Actividad 1: Describirlos requerimientos

Esta actividad tiene como objetivo:• Definir los actores que participan en cada

proceso.• Definir la secuencia de interacciones de

los procesos.• Definir las excepciones asociadas a los

procesos.En esta actividad se pueden revisar las es-

trategias de especificación de requerimientoscon el fin de describir los requerimientos encuanto a sus actores, escenarios y excepcio-

nes, advirtiendo que ninguna estrategia deespecificación de requerimientos existente esexcluyente en esta fase de la metodología.

2. Actividad 2: Evaluarlos requerimientosEsta actividad tiene por objetivo verificar

que los casos de uso, historias de usuarios o

prototipos cumplan con los criterios esta-blecidos. La práctica consiste en examinar laespecificación para asegurarse que todos losrequerimientos de software han sido escritossin ambigüedades, sin inconsistencias, sin

omisiones y errores, han sido detectadosy corregidos; que los productos de trabajosean conformes a los estándares establecidospara el proceso, para el proyecto y para elproducto. Esta práctica de evaluación derequerimientos es indispensable en la fasede especificación de los mismos, ya queuna vez el requerimiento cumpla o no conlos criterios establecidos de evaluación, esaceptado o no; finalmente esto conduce a

corregir inconsistencias y a tomar decisionesinmediatas sin tener que esperar a la fase finaldel proyecto. Generalmente no se realizapara todos los requerimientos sino para unamuestra de ellos.

Ver en la Tabla 8 la salida que provee lafase de especificación de requerimientos.

Tabla 7Entradas para la fase de especificación de requerimientos

NOMBRE FUENTE

Documento de definición de requerimientos Analista Fuentes de información

Documento de priorización de requerimientos Analista Fuentes de información

Definición de la versión Analista Fuentes de información





Gestión

Esta fase, que tiene tres entradas indi-cadas en la Tabla 9, plantea las siguientesactividades:

1. Actividad 1: Priorizar losrequerimientos

Esta actividad tiene como objetivo:

• Asignar categorías los requerimientosen función de su criticidad, impor-tancia, complejidad y riesgo.

• Definir las versiones entregables delproyecto.

Esta práctica permite realizar una or-ganización de la construcción o desarrollode los requerimientos de acuerdo con lasnecesidades del cliente o la importancia quetienen los requerimientos para él.

Es importante realizar el proceso de prio-rización de requerimientos debido a que seobtendrán claros objetivos de desarrollo, sedefinirá la entrada y salida de cada una delas etapas del proyecto, se podrá hacer unaorganización y distribución de actividadespara el desarrollo incremental que permitirápor tanto negociar el cómo se liberará elproducto.

2. Actividad 2: Almacenarlos requerimientosen un repositorio central

Esta práctica tiene por objetivo almacenarlos requerimientos definidos en un reposito-rio central (herramienta informática), puesconservarlos en plantillas no es muy reco-mendable por la facilidad de pérdida, ademásde un proceso desordenado de desarrollo yotros factores negativos que pueden afectar

el progreso de este proceso.

3. Actividad 3: Asignar al grupode desarrollo los requerimientosdel software


• Asignar un responsable al desarrollode cada requerimiento.

• Realizar chequeos a las actividadesdesignadas a los integrantes del grupode desarrollo.

• Reasignar actividades a nuevosresponsables cuando la situación loconsidere necesario.

El jefe del proyecto debe determinar losrequerimientos establecidos a cada uno delos integrantes del grupo de desarrollo paraejecutar el proyecto, además es necesario

llevar el control del proceso de desarrollo dedichos requerimientos a través de chequeosque permitirán asegurar que tal desarrolloestará a la fecha de entrega establecida porel jefe de proyecto evitando retrasos en elproyecto.

4. Actividad 4: Administrar los cambiosen los requerimientos


• Verificar que el cambio haya sidoautorizado.

• Evaluar el impacto del cambio delrequerimiento con los usuarios rele-vantes del software.

• Mantener historial de los cambios enlos requerimientos.

Los cambios siempre tienen un precio,incluso un cambio rechazado consume re-cursos que han sido requeridos para evaluary decidir el rechazo. Cuando se evalúa cadacambio está latente la necesidad de cumplircon los objetivos del negocio, la visión del

producto y el alcance del proyecto.

Tabla 9Entradas fase de gestión de requerimientos

NOMBRE FUENTE

Documento de especificación de requerimientos Analista

Definición de requerimientos Analista

Asignación de las actividades para el grupo de desarrollo Jefe del proyecto





Tabla 10Salida fase de gestión de requerimientos

NOMBRE DESCRIPCIÓN DESTINO

Priorización de requerimientos. Permite mostrar una organi-zación para el desarrollo de losrequerimientos de acuerdo alas necesidades del cliente o ala importancia que tienen losrequerimientos para él.

Grupo de desarrollo.

Se debe asignar quién puede cambiar losrequisitos, quién debe revisarlos o aprobar-los. Se debe garantizar el conocimiento dequiénes son los responsables de los cambiospropuestos para controlar los cambios de unamanera disciplinada.

5. Actividad 5: Administrarla trazabilidad de los requerimientos

Esta fase tiene por objetivo:

• Identificar la relación del reque-rimiento con otros elementos delsistema.

• Identificar la relación del requeri-miento con otros procesos del siste-ma.

• Realizar seguimiento del estado de losrequerimientos.

En esta práctica también es importanteresaltar el estado en el que se encuentra elrequerimiento, por lo tanto se propone unciclo de vida del requerimiento representadopor los posibles estados en el que él se puedeencontrar.

Esta fase tiene la salida mostrada en laTabla 10.

Control en la metodologíade ingeniería de requerimientosdel software

Esta etapa de la metodología tiene comopropósito describir los pasos para asegurarque las actividades son ejecutadas conformeal proceso que ha sido establecido.

En las fases de elicitación y especificaciónde requerimientos, el proceso de controlcontempla las siguientes tareas:

• Realizar revisión de las próximas activi-dades y sus objetivos.

• Elaboración de actas de reuniones deelicitación y especificación.

• Realizar revisión de los requerimientos.

• Resolver actividades pendientes.En la fase de gestión, el proceso de control

contempla las siguientes tareas:

• Realizar revisión sobre los requerimientosdel software, es decir, revisiones periódi-cas hechas por el jefe del proyecto para:

– Identificar los integrantes de la ta-rea.

– Informar a los integrantes de las revi-siones a realizar.

– Realizar revisiones de diseño de re-querimientos.

– Almacenar los resultados de la tarea.

– Comunicar los resultados.

• Revisar las actividades:

– Verificar que las tareas se estén llevan-do a cabo según lo planeado.

– Tomar medidas si se está desviandode lo planeado.

– Generar informes con los resulta-dos.

– Realizar auditorías del proceso.

ConclusionesSe revisó el proceso de ingeniería de

requerimientos en las empresas emergentesde desarrollo de software del sur occidentecolombiano dándose a conocer la necesidadque ellas tienen de implementar metodolo-





gías que soporten estas actividades. La granmayoría de empresas asegura que empleanmetodologías de desarrollo pero realmenteno realizan estas actividades de la formacorrecta, o en otros casos no las realizan,lo que ocasiona problemáticas en cuanto a

criterios para la aceptación de proveedores derequerimientos, criterios para la aceptaciónde requerimientos y ausencia de administra-ción de la trazabilidad y de los cambios delos requerimientos. Para ofrecer una alter-nativa viable de mejoramiento de procesosse definió y documentó una metodologíaágil de ingeniería de requerimientos para lasempresas emergentes la cual comprende tresfases: elicitación, especificación y gestión derequerimientos. Cada fase define las activi-

dades necesarias y los objetivos para realizarestas actividades teniendo en cuenta dos tiposde proyectos: desarrollo a la medida e ideasde negocio.

Reconocimientos

Se reconoce a las empresas encuestadasla participación en la presente investiga-ción. Igualmente a los estudiantes KarinaHernández y Ángela Lerma y la profesoraPatricia Hoyos por el trabajo de consolida-

ción y análisis de los resultados del trabajode campo.

Limitaciones y futuras investigaciones

La metodología ágil de ingeniería de re-querimientos está en la etapa de aplicación enempresas piloto ––empresas pertenecientesal contexto de la industria emergente– bus-cando que dicha metodología sea retroali-mentada en el ambiente real con la adiciónde más actividades u objetivos en cada fase y

evaluando el impacto de su implementaciónen estas empresas.

Es conveniente el desarrollo de una herra-mienta informática dirigida a las empresaspertenecientes a la industria emergente quesoporte en su totalidad la etapa de ingenieríade requerimientos del software, de tal formaque se puedan agregar más funcionalidades alas herramientas ya existentes para hacer másóptimo este proceso.

BibliografíaBECK, K. (2000). Extreme ProgrammingExplained. Embrace Change , Pearson Educa-tion, 1999. Traducido al español como: Unaexplicación de la programación extrema. Aceptarel cambio. Addison Wesley.

BENNINGTON. (1956). Agile requirementsmethod . [en línea]. [Consulta: Mayo 2006].Disponible en: <http://www.therationaledge.com/content/agileRequirements>

BOEHM, Barry. (1998). Spiral model ofsoftware development and enhancement , IEEEcomputer, Vol. 21.

CMMI. (2002). Capability Maturity Mo-del® Integration (CMMISM), Version 1.1MMI/SE/SW/IPPD/SE, V1.1; [en línea].[Consulta: Agosto 2006]. Disponible en:<http://www.sei.cmu.edu/cmmi/>

COCKBURN, Alistair. (1999). Metodologíaságiles y tradicionales en el desarrollo de software .Patricio Letelier y Mª Carmen Penadés, Uni-versidad Politécnica de Valencia.

CHOQUE ASPIAZU, Guillermo. (2001).Ingeniería de requerimientos . [en línea].[Consulta: Julio 2006]. Disponible en:<http://www.umsanet.edu.bo/docentes/gcho-que/Art_IngRequerim.pdf>

FOWLER, Martin. (2001). e new Me-thodology .

CARROL, J.M. (1995). Scenario-BasedDesign: Envisioning Work and Technology inSystem Development . Wiley. New York.

GRUDIN, J. (1990). Obstacles to user in-volvement in interface design in large productdevelopment organization, Proceeding IFIPINTERACT’90 ird International Con-ference on Human-Computer Interaction,Cambridge, Inglaterra.

ISO 9000, 9002, 9003. [en línea]. [Consulta: Agosto 2006]. Disponible en: <http://www.iso.org/iso/en/iso9000-14000/index.html>

JACOBSON, I.; CHRISTERSON, M.; JONSSON, P. y OVERGAARD, G. (1992).Object-Oriented Software Enginering – A UseCase Driven Approach. Addison – Wesley,Reading, MA.

JEFFRIES, R., ANDERSON, A., HENDRICKSON, C. (2001). Extreme Program-ming Installed . Addison-Wesley.

HIGHSMITH, Jim. (2000). Metodologíaságiles y tradicionales en el desarrollo de software. Patricio Letelier y Mª Carmen Penadés. Uni-

–

–

–

–

–

–

–

–

–

–

–

–

–





versidad Politécnica de Valencia. [en línea].[Consulta: septiembre 2006]. Disponible en:<http://www.willydev.net>

JOHNSON, P. (1992). Human Computer In-teraction: Psychology. Task Analysis and SoftwareEngineering . Londres: McGraw Hill Int.

MACAULAY, M. (1996). Requirements engi-neering . Springer Verlag, Londres.

Mc CONNELL, Agile. (1996). R equirements Methods . [en línea]. [Consulta: julio 2006].Disponible en:

<http://www.therationaledge.com/content/agileRequirements>

MERCHAN, L., URREA, A. (2007). Ca-racterización de las Empresas Pertenecientesa la Industria Emergente de Software del SurOccidente Colombiano Caso Red de ParquesPARQUESOFT . Congreso Colombiano de

Computación - CCC 2007. Pontificia Uni-versidad Javeriana, Bogotá D.C.

KARIM PICKLER, Kênia. GRESSE VON WANGENHEIM, Christiane. SALVIANO,Clenio F. Projeto 4.05 Propondo um métodode avaliação de processo de software em microempresas incubadas . [en línea]. [Consulta:febrero de 2007]. Disponible en: <www.mct.gov.br/upd_blob/5011.pdf>

MOPROSOFT. Modelo de Procesos para laIndustria de Software. MoProSoft Versión 1.1

Mayo 2003. [en línea]. [Consulta: julio de

2006]. Disponible en: <http://www.lania.mx/biblioteca/manuales/moprosoft>

NEWKIRK, J.; MARTIN, R.C. (2004).Extreme Programming in Practice . Addison-

Wesley.

NIELSEN J. y R. L. MACK (eds.), UsabilityInspection Methods . Wiley. New York, 1994.

MARKC C.; PAULK. A. (1994). Comparisonof ISO 9001 and the Capability Maturity Model

for Software. Pittsburgh, PA: Software Engi-

–

–

–

–

–

–

–

–

–

–

neering Institute, Carnegie Mellon University.Technical Report CMU/SEI 94-TR-12.

PAECH, B. (1998). e four levels of use casedescription, 4th Int. Workshop on Require-ments Engineering: Foundations for SoftwareQuality, Pisa.

PIATTINI, M., – DARYANANI, Rama.(1995). Elementos y Herramientas en el Desa-rrollo de los Sistemas de Información.

PRESSMAN, R. (2005) Software engineering .6a edición. McGraw hill.

RUBIN, J. (1994). Handbook of usabilitytesting . Wiley. New York.

RATIONAL UNIFIED PROCESS. RUP.(1998). [en línea]. [Consulta: julio de 2006].Disponible en: <http://www.therationaledge.com/content/jan_01/t_rup_ge.html>

WIRFS-BROCK, R. & WILKERSON, B.

& WIENER, L. (1990). Designing Object-Oriented Software , Prentice Hall.

SAIEDIAN H. DALE, R. (1999). Requi-rements Engineering: Making the connectionbetween the software developer and customer .Department of Computer Science – Univer-sity of Nebraska.

SCHWABER . Agile requirements methods .[en línea]. [Consulta: febrero de 2006].Disponible en: <http://www.therationaledge.com/content/agileRequirements>

SOMMERVILLE, I. Integrated Requirements

Engineering: A Tutorial . [en línea]. [Consulta:marzo de 2006]. Disponible en: <http://www.computer.org/software>

SWEBOK. Guide to the Software Engineering.Body of Knowledge . Version 2004. [en línea].[Consulta: febrero de 2006]. Disponible en:<http://www.swebok.org/ironman/pdf/SWE-BOK_Guide_2004.pdf>

WAKE, W.C. (2002). Extreme ProgrammingExplored . Addison-Wesley.

–

–

–

–

–

–

–

–

–

–

–

Documents

Definición de Una Metodología Ágil de Ingeniería de Requerimientos