Resumen La Ingeniera de Requerimientos es un proceso

muy importante en la elaboracin de cualquier proyecto de

software, pues es a travs de ste que obtendremos todas las
especificaciones y caractersticas que debe presentar el
producto final. ste proceso es muy !til, porque nos permite
establecer un comprensible y consistente con"unto de
especificaciones, para que durante las diferentes fases del
desarrollo de software se presenten menos problemas y la
calidad del producto sea me"or.
#alabras $lave% Requerimientos, Calidad, Desarrollo,
Comunicacin, Equipo.
&bstract '(e Requirements ngineering is a process very
important in t(e elaboration of any software pro"ect, because
is t(roug( t(is t(at we going to get t(e w(ole of t(e
specifications and c(aracteristics t(at must (ave t(e final
product. '(is process is very useful because it let us to
establis( an understandable and consistent set of
specifications, in order t(at we (ave less problems and t(e
quality of t(e product would be better, during t(e several
p(ases of t(e software development.
)eywords% Requirements, Quality, Development,
Communication, Team.
I. INTRODUCCIN
L desarrollo de cualquier proyecto de software implica
que el producto final sea de alta calidad, que sea correcto,
confiale y rousto. !s por eso, que se "ace necesario saer
real y claramente lo que dee desarrollarse con el fin de e#itar
m$s adelante una reconstrucci%n de todo lo que se "a "ec"o y
por consi&uiente no perder esfuer'o tanto de tiempo como de
recursos.
!
La In&enier(a de Requerimientos se encar&a precisamente de
eso, de &enerar una serie de especificaciones que descrian en
una forma clara, concisa y consistente, el comportamiento que
el sistema dee presentar. )e reali'a a tra#*s de m*todos y
"erramientas que nos permitir$n capturar desde diferentes
puntos de #ista los requisitos que deer$ cumplir el sistema, y
que se documentaran con el fin de que tanto los usuarios como
los desarrolladores entiendan la definici%n de requerimientos.
II. CO+UNIC,CIN !N L, IN-!NI!R., D!
R!/U!RI+I!NTO)
La comunicaci%n entre cliente e in&eniero es muy importante
sore todo en este proceso, pues es ac$ donde tendremos que
comprender que es lo que el cliente espera del funcionamiento
0
del producto o el sistema final, y para ello deemos saer
entender el len&ua1e del cliente y poder lle#arlo a un len&ua1e
que el desarrollador pueda entender. )in emar&o, es m$s
dif(cil crear un len&ua1e que tanto el cliente como el
desarrollador entienda, con el fin de que los requerimientos
que se definan sean entendiles para amas partes. !sto nos
conlle#ar$, a unificar la perspecti#a del prolema y reducir los
prolemas de concordancia entre lo que el cliente desea y lo
que el desarrollador quiere "acer. Una mala comunicaci%n, se
puede presentar cuando no estamos escuc"ando atentamente lo
que se esta diciendo, cuando se esta usando terminolo&(a que
no es entendile por nin&una de las dos partes, cuando
mandamos a terceros para escuc"ar los requerimientos del
cliente, cuando suponemos que no e2iste diferencias entre lo
que amas partes quieren.
Deido a esto, se dee contar con una uena "ailidad
comunicati#a que nos permita lle#ar a caalidad y de la
manera m$s optima el proceso de in&enier(a de
requerimientos. Contar con un dialo&o sencillo, con una
escuc"a acti#a, con una planificaci%n de pre&untas tanto
aiertas como cerradas, con la idea de que pueden e2istir
diferencias entre amas partes, con el uso de un &losario de
t*rminos y de t*cnicas comprensiles para el cliente, son
medios por los cuales lle#aremos de una me1or forma la
captura de requerimientos.
Como #emos, la comunicaci%n es astante dif(cil entre cliente
y desarrollador, pues amos tienen diferentes perspecti#as del
prolema3 mientras que los usuarios no conocen el proceso de
In&enier(a de )oftware y no saen "asta donde pueden pedir,
los desarrolladores no saen como funcionan las
or&ani'aciones, no tienen e2periencia como usuarios finales,
solo ofrecen soluciones &uiadas por tecnolo&(as. !s por eso,
que dee e2istir de por medio una ne&ociaci%n que incluya los
puntos cla#e del desarrollo de software con el fin de &aranti'ar
que nin&una de las dos partes se #ea afectada. !ntre las
m4ltiples metodolo&(as de ne&ociaci%n conocidas y
desarrolladas por administradores, sic%lo&os, entre otros,
e2iste una que es llamada 5IN 6 5IN 7-ana 6-ana8, la cual
supone lle&ar a un termino medio en el que tanto el cliente
como el desarrollador aporten y desarrollen ideas que
contriuyen a la elaoraci%n de un acuerdo que eneficie a
amas partes.
!sta metodolo&(a de ne&ocios es tami*n llamada suma
#ariale, "a sido recomendada por el 9:ar#ard Ne&ociation
;ro1ect<, y como se di1o anteriormente es aquellas en la que
las posiilidades de que amas partes sal&an &anando3 como
por e1emplo, un acuerdo en el que los empleados consi&an un
incremento salarial y la empresa un aumento en su
producti#idad. Los o1eti#os principales de 5IN 6 5IN, es
ma2imi'ar los eneficios propios sin ausar de la parte
contraria y preser#ar las uenas relaciones. !s recomendale
utili'arlo, cuando se esta interesado en aumentar los eneficios
In&enier(a de Requerimientos
,nderson +osquera =elasco
,nderson +osquera =elasco >o"ann ;e?alo'a
Uni#ersidad Distrital @rancisco >os* de Caldas Uni#ersidad Distrital @rancisco >os* de Caldas
@acultad de In&enier(a @acultad de In&enier(a
andres.&nrABC&mail.com in&D1o"annC"otmail.com
totales tanto para una parte como para la otra parte, y cuando
las relaciones personales primen sore los posiles eneficios.
!l procedimiento para traa1ar con esta metodolo&(a es el
si&uienteE
Crear un amiente de colaoraci%n y
entendimiento.
Listar las posiles soluciones y e#itar pensar que
"ay una 4nica soluci%n y que es la propuesta por
nosotros.
,nali'ar cada una de las soluciones posiles
mediante un criterio o1eti#o para encontrar
incon#enientes y el efecto que produce sore los
intereses de cada una de las partes.
I. >,D7>OINT ,;;LIC,TION D!=!LO;+!NT8
!l desarrollo con1unto de aplicaciones 7>,D8 JAD fue
definida en 1978 por Chuck Morris de IBM. !s una t*cnica
e2ploratoria muy popular que incluye a usuarios en el proceso
del desarrollo como participantes acti#os. !l proceso de >,D
se asa en cuatro ideas simplesE
F. Las personas qui*nes "acen un traa1o tienen la me1or
comprensi%n de ese traa1o.
A. La &ente que se entrena en tecnolo&(a de informaci%n tiene
la me1or comprensi%n de las posiilidades de esa tecnolo&(a.
B. Los sistemas de informaci%n y los procesos del ne&ocio
e2isten raramente en el aislamiento GG superan los l(mites de
cualquier sistema u oficina y afectan el traa1o de
departamentos relacionados. La &ente que traa1a en estas
$reas relacionadas tiene penetraci%n #aliosa en el papel de un
sistema dentro de una comunidad m$s &rande.
H. Los me1ores sistemas de informaci%n se dise?an cuando
todos los &rupos traa1an 1untos en un proyecto como
compa?eros i&uales.
!l proceso de >,D "ace para el desarrollo de los sistemas
inform$ticos lo qu* :enrio @ord "i'o para la faricaci%n de
los autom%#iles 7un m*todo de or&ani'ar la maquinaria, los
materiales, y el traa1o de modo que un coc"e pudiera ser
puesto 1unto muc"o m$s r$pido y m$s arato que nunca antes
I la l(nea de ensamla1e8. La meta en el desarrollo de los
sistemas es identificar realmente lo que los usuarios necesitan
y despu*s fi1an un sistema o un proceso que los proporcionen.
Los m*todos tradicionales tienen #arios factores incorporados
que consi&uen retrasar y empeorar el desarrollo a medida que
m$s &ente se in#olucra.
,&enda t(pica de la sesi%nE L(der de proyectoE
F. Introducir a todos los miemros del equipo de >,D
A. Discutir los principios de ase, las metas, y los o1eti#os
para las sesiones de >,D.
B. !2plicar los m*todos de documentaci%n y el uso de las
"erramientas C,)!, si las "ay.
H. ,lta -erencia 7a #eces llamada el due?o o el patrocinador
del proyecto8E !2plicar la ra'%n del proyecto y la autori'aci%n
superior de la &erencia y el apoyo.
L(der de proyectoE
F. ;roporcionar la descripci%n del sistema actual y el alcance y
los apremios propuestos del proyecto actual
A. ;resentar el contorno de temas espec(ficos y de prolemas
que se in#esti&ar$n.
,rir la sesi%n de discusi%n, moderada por el l(der de
proyectoE
F. Repasar los procesos del ne&ocio, las tareas, los
papeles del usuario, la entrada, y la salida
principales
A. Identificar las $reas espec(ficas del acuerdo o del
desacuerdo
B. Romper el equipo en &rupos m$s peque?os para
estudiar prolemas espec(ficos y para asi&nar a
l(deres del &rupo.
+iemros del equipo de >,D que traa1an en sesiones m$s
peque?as del &rupo, apoyadas por JL personalE
F. Discutir y documentar todos los requisitos del sistema.
A. Desarrollar los modelos y los prototipos.
L(deres del &rupoE
F. Di#ul&ar sore resultados y las tareas y los asuntos
asi&nados
A. ;resentar los prolemas que se deen tratar por el
equipo total de >,D
,rir la sesi%n de la discusi%n, modera l(der de proyectoE
F. Re#isa informes de sesiones peque?as del &rupo
A. Lo&rar Consenso en puntos principales
B Documentar todos los asuntos
L(der de proyectoE
F. ;resentar recapitulaci%n total de la sesi%n de >,D
A. ;reparar el informe que ser$ en#iado a los miemros
del equipo de >,D
Las Ventajas y Desventajas.
Comparado con m*todos tradicionales, >,D puede parecer
m$s costoso y puede ser inc%modo si el &rupo es demasiado
&rande comparado al tama?o del proyecto. +uc"as compa?(as
encuentran, sin emar&o, que >,D permite que los usuarios
dominantes participen con eficacia en los requisitos que
modelan el proceso. Cuando los usuarios participan en el
proceso del desarrollo de los sistemas, es mas proale sentir
un sentido de pertenencia en los resultados para el nue#o
sistema. Cuando est$ utili'ado correctamente, >,D puede dar
lu&ar a una declaraci%n m$s e2acta de los requisitos del
sistema, a una comprensi%n me1or de metas comunes, y a una
comisi%n m$s fuerte al *2ito del nue#o sistema.
R!@!R!NCI,)
KFL 7@uente Internet8 T"e Uni#ersity of Te2as at ,ustin. >,D. Disponile en
"ttpEMMwww.ute2as.eduMecsMtrecsM"risMpuM1ad.p"p
KAL 7;aperacN8 >oint ,pplication De#elopment y >ane 5ood, Denise
)il#er.
KBL 7;aperOacN8 T"e )e#en :aits of :i&"ly !ffecti#e ;eople ny )tep"en
R. Co#ey. FPQP.