122122

Análisis de Ingeniería de requerimientos: Alta de Unidades de Aprendizaje en la UAI-UAGro., México

Juan Carlos Medina Martínez1

Víctor M. Hernández Alarcón2

Lorena Alonso Guzmán3

Edgardo Solís Carmona4

Resumen

En la actualidad, para la aplicación de ingeniería de software, son varios losprocesosdedesarrollodesoftwarequeexisten.Enestainves-tigación,unade las etapas importantesdelprocesodedesa-rrollo es la ingeniería de requerimientos, etapa en donde sedefinen inicialmente las característicasy restriccionescon lasquedebecontarelsistema,partefundamental,yaquedetermi-naquéfuncionalidaddebecontenerelsoftware.EnelcasodeusoseaplicaráalSistemadeAltadeUnidadesdeAprendizaje(SAUA),quepermitiráalosalumnosdelaUnidadAcadémicadeIngeniería(UAI)delaUniversidadAutónomadeGuerrero(UAGro)dardealtalaunidaddeaprendizajeofertada(cursos)demaneraremotamedianteelusodeInternet.

Palabras clave: Unidaddeaprendizaje,Desarrollo,cliente,de-

sarrollador,diseño,web.

1 Universidad Autónoma de Guerrero, Unidad Académica de Ingeniería , Av. Lázaro Cárdenas S/N, C. U. Guerrero, México, 01747 4727943. Jcmedina74@yahoo.com.mx

2 InstitutoTecnológicodeChilpancingo,Av.JoséFranciscoRuízMassieu,No.5,Col.VillaModerna.Cp.39090.Gue-rrero,México,017474721014vmanuel.hdez@gmail.com

3 IUniversidadAutónomadeGuerrero,CentroEstataldeCapacitaciónySeguimiento,Av.LázaroCárdenasS/N,C.U.Guerrero,Méxicoalonso@uagro.mx

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

machote final.indd 122 01/11/2012 03:59:20 p.m.

123123

J u a N c a R l o s m e d i N a m a R t í N e z - v í c t o R m . H e R N Á N d e z a l a R c ó N - l o R e N a a l o N s o g u z m Á N - e d g a R d o s o l í s c a R m o N a

Revista viculos vol. # NúmeRo #

l o sE N E R o D E 2 0 1 2V o L U M E N 9 N Ú M E R o 1

ucnív

AbstractToday, forengineeringapplicationsoftwarearevarioussoftwaredevelopmentprocessesthatexist.Inthisresearchoneoftheimpor-tantstagesofthedevelopmentprocessisrequirementsengineering,stagewherethefeaturesareinitiallydefinedandrestrictionsyoumusthavethesystemunderdevelopment,akeypartasitdetermi-neswhatfunctionalityshouldcontainthesoftware.InthecaseofuseshallapplytotheHighSystemofUnitsofLearning(titi),whichwillallowstudentsofEngineeringAcademicUnit(IAU)oftheAu-tonomousUniversityofGuerrero(UAGro)enlistthelearningunitoffered(courses)remotelyusingtheInternet.

Keywords: Learning Unit, Development, customer, developer,design,web.

1. Introducción

El campode los requerimientos del sistemaesunáreamuyextensayhaymuchotrabajoporhacer.Porejemplo,noexistenherramien-tasdesoftwarequerealicenautomáticamentelavalidaciónde los requerimientosmedian-telosatributospresentadosenestainvestiga-ción(Medina,2002;Viller,1998).Alanalizarla ingenieríade requerimientos resultamuypretencioso,dadalacomplejidaddeltema.

Conlaaplicacióndelaingenieríadesoftwaresepuedenreducirriesgosdefallosenunsis-temaendesarrolloeincrementarlaposibili-daddelaentregadelproductoeneltiempoestimado,concalidadydentrodeloscostospresupuestados. Generalmente las etapasutilizadaseneldesarrollodesoftwareson:

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

Unaetapamuyimportantedelprocesodein-genieríadesoftware,eslaingenieríadereque-rimientos,lacualdefineelsoftwarequesede-seaproducirysusespecificaciones(BrueggeyDutoit,2002).Esteprocesoserealizamedian-telaobtención,elanálisis,laespecificación,lavalidaciónylaadministracióndelosrequeri-mientos de software. Esto último se aplica alasnecesidadesdelosclientes,a losserviciosquelosusuariosdeseanqueproporcioneelsis-temaendesarrolloyalasrestriccionesenlasquedebeoperar.El resultadodelprocesoderequerimientoseslabaseparaeldiseño,laim-plementaciónylaevaluacióndelsoftware.Deestaforma,sinosedescubrenyespecificanto-doslosrequerimientosdelsistemaendesarro-llo,podríaconducirnosalaentregadeunpro-ductodesoftwareincompleto,conaltoíndicederiesgosypocofuncional(Medina,2002).

LaIngenieríadeRequerimientosdesempeñaunpapelfundamentalenelprocesodeela-boracióndesoftware,yaqueenfocaunáreafundamental:la definición de lo que el soft-ware hará (Sommerville,1998).Suprincipaltareaconsisteenlageneracióndeespecifica-cionescorrectasquedescribanconclaridad,

machote final.indd 123 01/11/2012 03:59:20 p.m.

124124

A N Á L I S I S D E I N G E N I E R í A D E R E q U E R I M I E N T o S : A L T A D E U N I D A D E S D E A P R E N D I z A J E E N L A U A I - U A G R o . , M é X I C o

Revista viculos vol. # NúmeRo #

I + D

sin ambigüedades, en forma consistente ycompacta, el comportamiento del sistema.De estamanera, se pretendeminimizar losproblemasrelacionadosaldesarrollodesis-temas(Pressman,1998).

1.1 Planteamiento del Problema

La Unidad Académica de Ingeniería (UAI)de la Universidad Autónoma de Guerrero(UAGro), en el reciente ciclo escolar 2011-2012, implementó un nuevo plan de estu-dios, el cual consiste enunplan trimestral,enelquelosalumnoseligenlasunidadesdeaprendizaje a cursar; así como el horario ydocente,elalumnopuedecursarcuatrouni-dadesdeaprendizajecomomáximo.Encasodeunadeudodeunidaddeaprendizajepue-decursarsesiempreycuandoestéofertada.Además, tantoel subdirectordecontroles-colarcomoéláreade tutoría, enel casodeque exista algún inconveniente, como satu-ramientodealumnosparaundocente,toma-ránladecisiónparaasignarloaotrodocente.

1.2 Materiales y Métodos

Los requerimientos son una declaración enlenguaje natural en la que se describen lasnecesidadesdelosusuariosdelaUAI.Estosrequerimientosfueronobtenidosapartirdeladefinicióninicialdelclienteymedianteen-trevistasy cuestionarios realizadosavariaspersonasinvolucradasdealgunamaneraenel sistemayquepermitenasegurarel éxitodelproyecto.Porejemplo:losusuariosfina-lesysusadministradores,alumnosyprofe-sores,ingenierosdesistemasyprogramado-res(stakeholders)delaUAI.

Los requerimientos básicos para elAlta deUnidadesdeAprendizajeenlaUAI,seobtu-vierondelaentrevistainicialqueproporcio-nóelSubdirectordeAdministraciónyCon-trolEscolar(clientedelsistema),ademásde

algunosotrosquefueronpropuestosporelequipodedesarrolloconsiderandola infor-maciónqueseobtuvodelalecturadedocu-mentosrelacionadosyentrevistasrealizadasalosusuariosdelsistema.

No existen herramientas que vinculen losrequerimientos funcionales con los reque-rimientosno funcionales,donde se ilustrenlaimportanciayelefectoquetendránestosvínculos.Aúnnoexistelamaneraautomati-zadadeconocercuando losrequerimientosestáncompletoseneldocumentoderequeri-mientos.Esteprocesoactualmentesellevaacabomediantesesionesdondelosusuarios,elclienteyelequipodedesarrollorealizanlasrevisionespertinentes.

1.3 Objetivo

El objetivo del Sistema de Alta de Unida-desdeAprendizaje(SAUA)espermitiralosalumnosde laUnidadAcadémicade Inge-niería de laUAGro, dar de alta lasUnida-des deAprendizaje ofertadas por trimestreen el programa educativo elegido por losestudiantes. El SAUA, permitirá agilizar elaltadelasUnidadesdeAprendizajequelosalumnos elijan del programa educativo alquepertenezcan.

2. Ingeniería de requerimiento

Unade las primeras etapas del proceso dedesarrollo de Software es la Ingeniería deRequerimientos.Enestafasesedefinenyes-pecificanlosrequerimientosdelosclientesyusuarios.LasactividadesinvolucradasenlaIngenieríadeRequerimientosson:laobten-ción,elanálisis, laespecificación, lavalida-ciónylaadministracióndelosrequerimien-tosdesoftware(Macaulay,1996).

machote final.indd 124 01/11/2012 03:59:21 p.m.

125125

J u a N c a R l o s m e d i N a m a R t í N e z - v í c t o R m . H e R N Á N d e z a l a R c ó N - l o R e N a a l o N s o g u z m Á N - e d g a R d o s o l í s c a R m o N a

Revista viculos vol. # NúmeRo #

l o sE N E R o D E 2 0 1 2V o L U M E N 9 N Ú M E R o 1

ucnív

Los requerimientos de software se definencomolasnecesidadesdelosclientes,losser-viciosqueelusuariodeseaqueproporcioneelsistemaylasrestriccionessobrelasqueelsoftwaredebeoperar.El resultadodelpro-cesoderequerimientoseslabaseparaeldi-seño,laimplementaciónylaevaluacióndelsoftware.Deestaforma,sinosedescubrenyespecificantodoslosrequerimientosdelsis-temaendesarrollo,podríaconducirnosalaentregadeunproductodesoftwareincom-pleto,conaltoíndicederiesgosypocofun-cional(Medina,2002;Pressman,1998).

A pesar de los avances en la Ingeniería deSoftware, existe una gran cantidad de de-sarrolladoresquenohacenusodeprocedi-mientos y actividades que proporciona laIngeniería de Software en el desarrollo desistemas;estoprovocaqueungrannúmerodeproyectosdesoftwareseanabandonadosen pleno proceso de desarrollo o que seanentregadosconretrasosyacostosmayoresalosestimados.Aestaproblemáticaseleuneelhechodequeexisteunagrancantidaddemétodosytécnicas,quelejosdeserestánda-res, confundenmás a los desarrolladores ydificultan la definición de los requerimien-tos (Medina,2002).

AcontinuaciónsepresentaladefiniciónqueapareceenelglosariodelaIEEE,lacualco-rrespondealassiglasdeInstituteofElectri-calandElectronicsEngineers.

1.-Una condiciónonecesidaddeunusua-riopararesolverunproblemaoalcanzarunobjetivo.2.-Unacondiciónocapacidadquedebeestarpresenteenunsistemaocompo-nentesdesistemaparasatisfaceruncontra-to,estándar,especificaciónuotrodocumentoformal.3.-Unarepresentacióndocumentadadeunacondiciónocapacidadcomoen1.o2.Unrequerimientodesoftwarepuedeserde-finidocomo:

• Una capacidad del software necesariaporelusuariopararesolverunproblemaoalcanzarunobjetivo.

• Unacapacidaddelsoftwarequedebeserreunidaoposeídaporunsistemaocom-ponente del sistema para satisfacer uncontrato,especificación,estándar,uotradocumentaciónformal.

LastareasmáscomplejasparalosingenierosoespecialistasdesoftwareenelprocesodeIngenieríadeRequerimientosson:

1.Tratarcon lanaturalezadel sistemaycomprendersuambiente.

2. Encontrar los componentes y su inte-raccióndentrodelsistema.

3.Definirlosserviciosqueelsistemadebeofreceralusuario.

4.Definirlasrestriccionesolimitantesdelsistema.

EstastareasdefinenlosproblemasdelaIn-genieríadeRequerimientosyquedebenen-frentar los desarrolladores y analistas desoftware.Elprocesodedescubrir, analizar,documentar y verificar los servicios y res-triccionesdelsistema,sóloselograutilizan-dolastécnicasdefinidasporlaIngenieríadeRequerimientos.

2.1 El proceso de Ingeniería de Requerimientos

ElprocesodeIngenieríadeRequerimientos,involucra todas las actividades necesariaspara crearymantenereldocumentode re-querimientosdel sistema.Para realizaresteproceso, es necesario previamente obtenerunanálisisdefactibilidadqueindiquesiesfactiblecontinuarconeldesarrollodelsiste-

machote final.indd 125 01/11/2012 03:59:21 p.m.

126126

A N Á L I S I S D E I N G E N I E R í A D E R E q U E R I M I E N T o S : A L T A D E U N I D A D E S D E A P R E N D I z A J E E N L A U A I - U A G R o . , M é X I C o

Revista viculos vol. # NúmeRo #

I + D

ma,ademásdeconocer lasnecesidadesdelcliente para tener un contexto general delsistema.

Lasactividadesque sedefinenenelproce-sodelaIngenieríadeRequerimientossonlassiguientes:

1.Obtencióndelosrequerimientos

2.Análisisderequerimientos

3.Especificaciónderequerimientos

4.Validacióndedocumentodeespecificación

5.Administraciónderequerimientos

EnlaFigura1semuestra la interacciónqueexisteentrelasdiferentesactividadesdelpro-ceso de Ingeniería de Requerimientos, utili-zandoelparadigmade cascada, tal comoelDocumentodeDefinicióndeRequerimientos(DDR)yelDocumentodeEspecificacióndeRequerimientos(DER),endondecadaactivi-dadtieneunregresoalaactividadanterior.Separtedelhechodequeexisteunadefinicióngeneraldelproblemaydeunanálisisdefac-tibilidadqueindicalacontinuacióndeldesa-rrollodelsoftware.Deestamanera,elprocesodeIngenieríadeRequerimientosiniciaconlaactividaddelaobtencióndelosrequerimien-tos, mediante la revisión de la informaciónexistenteenmanualesydocumentosyentre-vistasalosusuariosparadescubriryanalizarlos requerimientos. La especificación y vali-daciónsonactividadesquepuedenserrepeti-dascuantasvecesseannecesariashastalograrelnivelderefinamientoenquesedeseenes-pecificarlosrequerimientos.Finalmentecadacambioenlosrequerimientos,esadministra-doenversionesdelDocumentodeEspecifica-cióndeRequerimientos.

Figura 1. ElprocesodeIngenieríadeRequerimientosenelmodelodecascada.

Figura 2. Elprocesodeobtenciónderequerimientos

2.2 Actividades del Proceso de Ingeniería de Requerimientos

ElobjetivodelaIngenieríadeRequerimien-tosesobtenerundocumento formaldondese especifiquen las características que debe

machote final.indd 126 01/11/2012 03:59:21 p.m.

127127

J u a N c a R l o s m e d i N a m a R t í N e z - v í c t o R m . H e R N Á N d e z a l a R c ó N - l o R e N a a l o N s o g u z m Á N - e d g a R d o s o l í s c a R m o N a

Revista viculos vol. # NúmeRo #

l o sE N E R o D E 2 0 1 2V o L U M E N 9 N Ú M E R o 1

ucnív

cumplir el sistema que se va a desarrollar.Estas características y restricciones son de-finidas en común acuerdo por el cliente ylosusuariosdelsistema,(Medina,2002).Laespecificación de los requerimientos debecumplir con ciertas características de cali-dad,comosonlassiguientes:

• Entendibles,• Necesarias,• Consistentes,• Noambiguas,• Completas,• Verificables,• Correctos,• Reales,• Rastreablesy• Modificables.

Encadaunade lasactividadesdelprocesodelaIngenieríadeRequerimientossellevanacabo tareasespecíficasutilizando técnicasde requerimientos, modelos de especifica-ción y herramientas para la administracióndeldocumentoderequerimientos.

2.3 Obtención de Requerimientos

En esta actividad se determina el dominiode laaplicación, seespecifican los serviciosque deben proveer el sistema, la funciona-lidadrequeridadelsistema,ylasrestriccio-nesdehardwareysoftware.Esindispensa-blelaparticipacióndelosusuariosyclientespara la identificaciónde los requerimientosdelsistema.

Sedebeobtenercomoresultadodeestaac-tividad,undocumentodedefiniciónde losrequerimientos, donde se definen las nece-sidadesinicialmenteencontradas,locualnosignifica que estos requerimientos sean losdefinitivos,puespuedenseragregadosnue-vos requerimientos conforme se vayan en-

contrandooinclusolosrequerimientosesta-blecidospuedenmodificarseoeliminarse.

Paralograrlaobtencióndelosrequerimien-tossedefinierontareasaseguirlascualessemencionanacontinuación:

1. Comprenderelproblemaqueseestáresol-viendo,esnecesarioestudiareldominiooentornoenelqueelsistemavaaoperar.

2. Buscar y recolectar informacióndema-nuales de operación y mantenimiento,demanualesorganizacionalesypolíticasdeoperación.

3. Definirloslímitesyrestriccionesdelsis-tema,paradeterminarconexactitudqueesloqueelsistemavahacerytambiénespecificarloquenovaahacer.

4. Identificara laspersonasousuarios in-teresadosporelsistema,yaqueellosco-nocenelmedioambienteenqueoperaráelsistemaypuedenayudardescribiendosusnecesidades.

5. Recolectaryclasificarrequerimientos;deestamanera losdesarrolladorespuedeniniciardefiniendounbosquejodelsiste-ma,sufuncionamientobásicoyestable-ciendoelalcancedelsistema

Eldesarrollodeestastareasenlaobtenciónde requerimientos es realizado secuencial-mente,peroesnecesarioquecadatareapu-ede regresarnos a la anterior, sobretodo sino sedescubre la informaciónnecesaria enel primer recorrido del diagrama. La Figu-ra2,muestraestarelación.Lasalidadeestaactividad nos conduce hacia el análisis derequerimientos.

Figura 3. El proceso de análisis de requerimientos.

machote final.indd 127 01/11/2012 03:59:21 p.m.

128128

A N Á L I S I S D E I N G E N I E R í A D E R E q U E R I M I E N T o S : A L T A D E U N I D A D E S D E A P R E N D I z A J E E N L A U A I - U A G R o . , M é X I C o

Revista viculos vol. # NúmeRo #

I + D

Figura 3.Elprocesodeanálisisderequerimientos.

2.4 Análisis de Requerimientos

Los requerimientos definidos en el docu-mentodedefiniciónsonanalizadosdetalla-damenteporelequipodedesarrolloynego-ciadosconelclienteyusuarios,paradecidirlosrequerimientosqueseránaceptadosyde-finirlosdemaneraconjuntaconelfindeho-mogeneizarsuinterpretación.

Elanálisisdeldocumentodedefinicióndere-querimientossellevaacabomediantetécni-casderevisiónyverificacióndeloscriteriosde calidadde cada requerimientodefinido.Esteestudioesrealizadoporlosdesarrolla-dores, clientes y usuarios. En el análisis sellevanacabolassiguientesactividades:

1. Priorizar los requerimientos debido aque pueden existir requerimientosmásimportantes que otros para los clientesyusuarios,por loquedebenserclasifi-cadoseimplementadosdeacuerdoasuprioridadenelsistema.

2. Encontrar dependencias entre requeri-mientos y etiquetar los requerimientosconun identificadorúnico,conelfindepoderlosidentificarorastrearenelfuturo.

3. Resolver conflictos entre los requeri-mientos; sepuedenencontrar conflictosentre requerimientos mediante la revi-sióndeloscriteriosdecalidadquedebecumplircadarequerimientodelsistema.

4. Negociar con flexibilidad con los de-máselementosdelequipoque intervie-nenenelprocesodedesarrollodesoft-ware,parahomogenizarsucomprensióny de esta forma tanto desarrolladorescomousuariostenganlamismainterpre-taciónalmomentodeleereldocumentoderequerimientos.

ElresultadodelanálisiseselDocumentodeDefinicióndeRequerimientos(DDR),dondese encuentran descritos los requerimientosinicialesdelsistemaquesevaadesarrollaren lenguaje natural. Este documento sirvecomopuntodepartidahacialasiguienteac-tividaddel procesode la IngenieríadeRe-querimientos,porloqueesnecesariodequenoexistanrequerimientosenconflictosyes-tén bien escritos. La Figura 3 describe esteproceso,muestralainteraccióndelastareasrealizadasylasalidadeestaactividadeslaentrada a la actividad de especificación delosrequerimientos.

2.5 Especificación de Requerimientos

Enestaactividadseobtienecomoresultadoel documento de especificación de requeri-mientos.Estedocumentocontieneladescrip-ción precisa de los requerimientos, incluyemodelosderepresentaciónqueagregande-tallesalsistemamostrándolodesdediferen-

machote final.indd 128 01/11/2012 03:59:21 p.m.

129129

J u a N c a R l o s m e d i N a m a R t í N e z - v í c t o R m . H e R N Á N d e z a l a R c ó N - l o R e N a a l o N s o g u z m Á N - e d g a R d o s o l í s c a R m o N a

Revista viculos vol. # NúmeRo #

l o sE N E R o D E 2 0 1 2V o L U M E N 9 N Ú M E R o 1

ucnív

tes perspectivas. Para el desarrollo de estaactividadserealizanlassiguientestareas:

1. Especificar los requerimientos funcio-nales y no funcionales.Ambos requeri-mientos deben ser descritos en detalleparasumejorcomprensión.

2. DeterminareltipodeestándarautilizarparaladefinicióndelDocumentodeEs-pecificación de Requerimientos (DER).Sedefine el esquemadel contenidodelDERenbasealestándardefinidoporlaIEEE.

3. Elegir la herramienta de especificación,encasodeutilizaralgunaparaautoma-tizarelproceso.

4. Utilizarmodelosydiagramasparaexpli-carconmayordetalleydiferentespers-pectivaselcomportamientodelsistema.

5. Utilizarcualquierinformacióndesopor-te o guía para etapasposteriores y queamplíenlacomprensióndelsistema.

Todasestastareasvanencaminadasaobte-ner elDocumentodeEspecificacióndeRe-querimientos, en donde se especifican lasfunciones, restricciones o característicasdelsistemaendesarrollo.Esnecesariocon-tarcontodala informacióndisponibleparaformarundocumentocompletoyquesirvacomobasedepartidahacia lasotrasetapasdeldesarrollodelsistema.EnlaFigura4semuestranlasactividadesdelaespecificacióndelosrequerimientosdelsistema.

Figura 4.Lasactividadesdelaespecificaciónderequerimientos.

2.6 Tipos de Requerimientos

Losrequerimientosdesoftwaresonlasdes-cripciones de los servicios y restriccionesdel sistema en desarrollo. Existen diferen-tesmanerasdeclasificarlos,generalmenteseleagrupandeacuerdoalaaudienciaaquie-nes vandirigidos y a las característicasdelsistema.

2.6.1 Tipos de Requerimientos de acuerdo a la audiencia

Existendiferentesnivelesdedescripciónderequerimientosquepermitenorientarlosre-querimientosadiversosusuarios.Esdistin-to explicar los alcances de un sistemanue-voaclientesusuariosquenisiquieravanautilizar el sistema, pero quede alguna for-ma están involucrados en el desarrollo delsistema, que explicárselos a los desarrolla-dores o arquitectos de software que se en-cargaran de la implementación del sistema(Pressman, 1998). Como se observa, se re-quieredediferentesnivelesdedescripciónypor lo tantodediferentes tiposdedescrip-ciónderequerimientos:

machote final.indd 129 01/11/2012 03:59:21 p.m.

130130

A N Á L I S I S D E I N G E N I E R í A D E R E q U E R I M I E N T o S : A L T A D E U N I D A D E S D E A P R E N D I z A J E E N L A U A I - U A G R o . , M é X I C o

Revista viculos vol. # NúmeRo #

I + D

1. LosRequerimientosdelUsuario.Sonex-presados en lenguaje natural utilizan-dodiagramasfácilesdecomprender,delosserviciosqueseesperaqueelsistemaproveaydelasrestriccionesbajolascua-les el sistema debe funcionar, tambiénsonconocidoscomoRequerimientosdelClienteoRequerimientosC.

2. LosRequerimientosdel Sistema.En es-tosrequerimientosseestablecenconmásdetalle los servicios y restricciones delsistema.Tambiénselesconocecomoes-pecificación funcional, RequerimientosdelDesarrolladoroRequerimientosD.

3. La Especificación del Diseño del soft-ware. Es una descripción abstracta deldiseñodelsoftwarequeseutilizacomouna base para un diseño e implement-acióndetallados.

Los distintos niveles de descripción de re-querimientossonnecesariosdebidoaquein-formandemaneraclaraadiferentestiposdeusuarios (Pressman, 1998).Por ejemplo, losrequerimientos de usuario, como están ex-presadosenunlenguajeclaro,fácilysinde-talles funcionales, estándirigidos a clientesadministradores, usuarios finales del siste-ma, clientes ingenieros, contratistas, admi-nistradores y arquitectos del sistema. Porotrolado,losrequerimientosdelsistemaes-tándirigidosausuariostécnicosdelsistema,clientesingenieros,arquitectosdelsistemaydesarrolladoresdesoftware.

Debidoasuespecificaciónfuncionaldentrodelsistema,esnecesariounciertogradodeconocimientotécnicooespecializaciónenelárea.Yporúltimo,laespecificacióndeldise-ñodesoftwareestádirigidaaclientesinge-nieros,arquitectosdelsistemaydesarrolla-doresdesoftware.

2.6.2 Tipos de Requerimientos de acuerdo a su característica

Estaclasificaciónserealizaenfuncióndelanaturalezade lascaracterísticasdel sistemaquesedesarrolla.Generalmente,losrequeri-mientosdesistemasdesoftwareseclasificanenfuncionalesynofuncionales.

1. Requerimientos funcionales.Losreque-rimientos funcionales sondeclaracionesdelosserviciosqueproveeráelsistemaycomprendenlainteracciónentreelsis-temaysuambiente,lareacciónaentra-das particulares dedatos y su compor-tamiento en condiciones específicas. Enalgunoscasostambiéndeclaranloqueelsistemanodebehacer.

2. Requerimientos no funcionales.Losre-querimientos no funcionales, son espe-cificaciones de las restricciones de losserviciosofuncionesofrecidasporelsis-tema, restricciones sobre el sistemaquelimitannuestraseleccionesenlasoluciónaunproblema.

Losrequerimientosnofuncionalesnosere-fierendirectamentealasfuncionesespecífi-casqueentregaelsistema,sinoasuspropie-dadesemergentes,(Sommerville,1998).

3. CASO DE USO: Alta de Unidades de Aprendizaje y requerimientos del SAUA

El caso de estudio que se desarrolló, parala Especificación de los Requerimientos, esel Sistema deAlta deUnidades deApren-dizaje (SAUA), que permitirá a los alum-nos de la Unidad Académica de Ingenie-ríade laUAGro.,dardealta susUnidadesdeAprendizaje demanera eficazmedianteelusodeInternet.SeobtuvoelDocumento

machote final.indd 130 01/11/2012 03:59:22 p.m.

131131

J u a N c a R l o s m e d i N a m a R t í N e z - v í c t o R m . H e R N Á N d e z a l a R c ó N - l o R e N a a l o N s o g u z m Á N - e d g a R d o s o l í s c a R m o N a

Revista viculos vol. # NúmeRo #

l o sE N E R o D E 2 0 1 2V o L U M E N 9 N Ú M E R o 1

ucnív

deEspecificacióndelosRequerimientosdelSAUA,dondeseencuentranexpresadaslascaracterísticas y las restricciones del siste-ma,mediantelaaplicacióndelasactividadesconcernientesalprocesodeIngenieríadeRe-querimientosplanteadasenlasección2.

3.1 Descripción General

Enesteapartadosedescribecomosedesa-rrollaactualmenteelSistemadealtadeuni-dadesdeaprendizajequerealizanlosalum-nos de la UAI, se presenta una propuestaparaelSAUA,definiendoelpropósitoyal-cance.Seidentificanydefiniránlosposiblesusuarios interesadosenel SAUAconelfindetrabajarconjuntamenteconelequipodedesarrolloparaespecificarsusnecesidades..

3.2 Descripción del sistema actual

Esnecesariodescribirelprocesoactualquedelosalumnosrealizanaldardealtalasuni-dades de aprendizaje de la UAI, como unpuntodepartidayreferencialparaobteneryespecificarlosrequerimientos,tambiénparatenerantecedentesypodercontrastarelsis-temaactualconrespectoalalcancedelnue-vosistema(SAUA).

El proceso actual de alta de alumnos a lasunidadesdeaprendizajedelprogramaaca-démicode laUAI sedesarrolla tradicional-mentedelasiguienteforma:

1. Selección de Unidad de Aprendizaje

Se seleccionan las unidades de aprendizajeofertadasportrimestre,asícomoalosalum-nos de mejor promedio los cuales tienenprioridad de seleccionar y dar de alta susunidadesdeaprendizaje.

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

Cuandolosalumnossondenuevoingreso,seasignaaunprofesordebasey tiempocom-pleto(apartirdeaquíselenombraTutoralprofesorasignado),unnúmeropromediodealumnos que regularmente es de seis. EstaasignaciónesdeacuerdoalProgramaEduca-tivo(PE)queelalumnopretendeseguir,yse

Figura 5. Papeleta de alta de unidad de aprendizaje

machote final.indd 131 01/11/2012 03:59:22 p.m.

132132

A N Á L I S I S D E I N G E N I E R í A D E R E q U E R I M I E N T o S : A L T A D E U N I D A D E S D E A P R E N D I z A J E E N L A U A I - U A G R o . , M é X I C o

Revista viculos vol. # NúmeRo #

I + D

llevaacaboconelfindequelosalumnosten-ganunaguíayasesoríapersonalizadaen laeleccióndeloscursosensucurriculadelpro-gramade licenciatura, esdecir,unaorienta-cióngeneraldelpanoramaacadémico.Elase-soreselmismoduranteel tiempoqueduraelprogramaeducativo.Puedehabercambios,peroéstosseconsiderancasosespeciales.

3. La academia y la administración de la UAI realizan la programación de cursos de acuerdo al reglamento y al programa educativo.

DeacuerdoalacurriculadelPE,laacademiadeprofesoresylosdelaadministracióndelaUAI programan los cursos que pueden im-partir en el presente trimestre. Esta progra-maciónsellevaacaboenbasedeunprogra-maeducativoyaunreglamentodelaUAGro.

4. El tutor apoya a sugerir a los alumnos Unidades de Aprendizaje, de acuerdo al perfil universitario.

Despuésde tener la curriculade los cursosquesevanaimpartirentodoelaño,eltutortomacomobaselaformaciónacadémicadelalumnoparaguiarloensuformaciónacadé-mico-profesional.Otropuntoqueserevisa,esque losalumnoscubran lasunidadesdeaprendizajedelprogramadelicenciatura.

5. El alumno y el tutor revisan la curricula de los cursos para el alumno.

Losalumnossonllamadosaentrevistasper-sonalesconsustutores.Elobjetivoesprogra-mar lasunidadesdeaprendizajeque lleva-rá a caboenel transcursodel trimestredelprograma educativo. Esta programación serealizatomandoencuentatambiénlapreviaselección,mencionada en el punto 3: el tu-toradorecibe laorientacióndesututorcon

másdetalledelpanoramadesuprogramadeestudio.

6. Se integra la curricula al expediente del alumno

El resultado de la entrevista es la integra-cióndeldocumentoo formatoque contienelasunidadesdeaprendizajeyesentregadoalsubdirectordecontrolescolardelaUAI,parasuautorizaciónydespuésalpersonaladmi-nistrativo para que realice la asignación deunidades de aprendizaje correspondientes.Unacopiadeestasinscripcionesesintegradaalexpedientedelalumno(VerFigura5).

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

Todalainformacióndelosalumnosescon-troladamedianteexpedientes.Generalmen-te,unexpedienteconstadedocumentosdeantecedentes referente a cada alumno, listade unidades de aprendizaje (Kardex), pro-gramaeducativoyotrosmás;separadosencarpetasquesonalmacenadasenunarchive-roquecontrolaunasecretaríaadministrativa.

8 Transcurre una semana en el cual se pueden realizar modificaciones por parte del alumno o el tutor y en último caso, por el subdirector de administración de control escolar.

Encasoderealizaralgúncambiodeunidadde aprendizaje, es necesario notificarlo coneltutor,oenausenciadeltutor,conelsub-director de administración de control esco-larparalaautorizacióndedichocambio.Eltiempoenelcualsepuedenrealizarcambiosesdetres(3)días.

machote final.indd 132 01/11/2012 03:59:22 p.m.

133133

J u a N c a R l o s m e d i N a m a R t í N e z - v í c t o R m . H e R N Á N d e z a l a R c ó N - l o R e N a a l o N s o g u z m Á N - e d g a R d o s o l í s c a R m o N a

Revista viculos vol. # NúmeRo #

l o sE N E R o D E 2 0 1 2V o L U M E N 9 N Ú M E R o 1

ucnív

9. La información de cada sección es entregada a Servicios Escolares de la UAGro.

Despuésdeesteproceso,lainformacióndelasinscripcionesde todos losalumnosesentre-gadaaServiciosEscolaresdelaUAGro.,parasualtaalSistemadeAdministraciónySegui-mientoEscolares(SASE),yqueyanocorres-pondealáreadecontrolescolardelaUAI.

3.3 Definición de Requisitos Funcionales

Otramaneradedefinirlosrequisitosencon-trados inicialmenteparaelSAUA,esusan-doformasdefinidasen lenguajenaturales-tructurado, donde se incluya la siguienteinformación:

1. Unadescripcióndelafunciónolaenti-dadaespecificar.

2. Descripción de entradas y de dónde seoriginan.

3. Descripcióndesalidasyhaciadóndevan.

4. Unadescripcióndequeotrasentidadesseutilizan.

5. Unaprecondiciónyunapostcondición.

6. Efectoscolateralesdelaoperación.

Con esta información se pretende detallaraúnmáslosrequerimientosconelfindedis-minuirlasdificultadesdeinterpretaciónquepuedantenerdichosrequerimientos.

4. Implementación

Datos de la unidad de aprendizaje que pueden modificarse:

Título de la unidad de aprendizaje, nom-bredelprofesortitular,nombredelprofesorauxiliar,horario,díasenqueseimparte,siesafín a otrosprogramasde estudio, númerodealumnosinscritos,edificioyniveldondesevaaimpartir.

Datos del profesor que pueden modificarse:

Función, fecha de ingreso, si es permanen-teotemporal,númerodeempleado,cubícu-lodondelabora,teléfonodecubículo,exten-sión,domicilioparticular,teléfonoparticularylasunidadesdeaprendizajeasignadas.

Datos del alumno que pueden modificarse:

Nombre, edad, identificación, domicilio ac-tual, colonia, delegaciónomunicipio, códi-gopostal,país,estadoyteléfonoactual.Ade-másdelasunidadesdeaprendizajealosqueestáinscritoeneltrimestreactual.

Los datos que puede modificar de la unidad de aprendizaje son:

Temasdelaunidaddeaprendizaje,objetivoquecubreeltema,tiempodeduraciónylostemasconlosqueserelaciona.

4.2 Contexto del SAUA

ElsistemaSAUAdebepermitiralosalumnosrealizarelaltadelasunidadesdeaprendiza-jequeseimpartenenlaUAIdelaUAGrodemaneravirtual,esdecir,quecualquieralum-noinscritoenlaUAIpuedandardealtasusUnidades de Aprendizaje mediante el ac-

Figura 7. Modelo de Flujo de Datos del SAUA

machote final.indd 133 01/11/2012 03:59:22 p.m.

134134

A N Á L I S I S D E I N G E N I E R í A D E R E q U E R I M I E N T o S : A L T A D E U N I D A D E S D E A P R E N D I z A J E E N L A U A I - U A G R o . , M é X I C o

Revista viculos vol. # NúmeRo #

I + D

cesoalSAUAdesdecualquierlugarusandoInternet. Sepretendeque el SAUApropor-cioneunserviciodecalidadyseoptimicenlos tiempos que requiere el alta demaneratradicional,ademásdereducirlatasadeer-rores. En las figuras 6 y 7, se presentaunadescripcióngeneraldel funcionamientodelsistemapropuestoparaelSAUA.Sepuedeobservar la relación general de los compo-nentesdelsistematrabajandoenconjunto.

Puedeapreciarseelflujodeinformacióndeunamanerageneral.Elesquemadeintercon-exión entre el usuario y servidor se realizamediantelaredInternet.

Figura 6.DescripcióngeneraldelSAUA

Figura 7.ModelodeFlujodeDatosdelSAUA

5. Conclusiones

LaIngenieríadeRequerimientoscomopartedelprocesodedesarrollodesoftware,esunpuenteimportantehaciaotrasetapas,comosoneldiseño, la implementación, lavalida-cióny elmantenimiento.Esto significaqueuna descripción completa de los requeri-mientosgarantiza eldesarrollodeunbuenproductofinal.Sinembargo, laobtenciónyespecificacióndelosrequerimientossondossituacionesproblemáticasquetodoingenie-rodesoftwareenfrenta.Porunlado,sebus-caresolverlasdiferenciasdecomunicación,culturalesytécnicasqueenfrentanlosusua-riosylosdesarrolladoresenelafándelograrobtener las necesidades y restricciones quedefiniránelsistema;yporelotro,labúsque-dadetécnicas,métodos,metodologíasyhe-rramientasquepermitanobtenerunaespe-cificación de los requerimientos entendibletantopara losclientesyusuariocomoparalosingenierosinvolucradoseneldiseño.

machote final.indd 134 01/11/2012 03:59:23 p.m.

135135

J u a N c a R l o s m e d i N a m a R t í N e z - v í c t o R m . H e R N Á N d e z a l a R c ó N - l o R e N a a l o N s o g u z m Á N - e d g a R d o s o l í s c a R m o N a

Revista viculos vol. # NúmeRo #

l o sE N E R o D E 2 0 1 2V o L U M E N 9 N Ú M E R o 1

ucnív

La Ingeniería deRequerimientos, se utilizóparaelanálisiseneldesarrollodel casodeestudioSAUA,cabemencionarquealapli-car la ingeniería de requerimientos en esteproyecto se logrómejorar elprocedimientodealtadeunidadesdeaprendizajequehastalafechaserealizademaneramanual,logran-doconestounaformamáseficienteparasuelecciónyaltadeunidadesdeaprendizaje.Asímismosepretendequeparaelsiguientecicloescolar(2012-2013)estainvestigaciónseestéllevandoacaboenlaUnidadAcadémi-cadeIngenieríadelaUniversidadAutóno-madeGuerrero,enMéxico.

6. Referencias

[1] Bruegge, Bernd, Dutoit H., (2002). Allen, Ingeniería de Software Orientada a Objetos,primeraedición,PrenticeHall.

[2] Macaulay L. A.(1996).Requirements En-gineering,Springer-Verlag.

[3] Medina, J.C. (2002).Análisis comparati-vo de técnicas, metodologías y herramientas de ingeniería de requerimientos.Tesisparaobtener elgradodeMaestría enCien-cias en la especialidad de IngenieríaEléctrica Opción Computación, Méxi-co,D.F.: Centro de Investigación y deEstudiosAvanzadosdelIPN.

[4] Pressman, S. Roger, (1998). Ingeniería del software, un enfoque práctico,CuartaEdición,McGrawHill.

[5] Sommerville, Ian, (1998).Software En-gineering,Wiley.

[6] Viller, S. Social, (1998). Analysis forSoftware Engineering, Technical Re-port, http://www.comp.lancs.ac.uk/computing/research/cseg/98_rep.html

[7] Templeton J.F., (1994).The Focus Group: A strategic Guide to Organizing, Conduc-ting and Analyzing the Focus Group Inter-view,ProbuspublishingCo.

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

machote final.indd 135 01/11/2012 03:59:23 p.m.