Scribd Logo
Carica

Benvenuto in Scribd!

  • CAP7

    Caricato da

    JoséA.Yáñez
    9 visualizzazioni36 pagine
    INGENIERIA DEL SOFTWARE

    Copyright

    © © All Rights Reserved

    Formati disponibili

    PDF o leggi online da Scribd

    Hai trovato utile questo documento?

    Questo contenuto è inappropriato?

    Segnala questo documento
    INGENIERIA DEL SOFTWARE

    Copyright:

    © All Rights Reserved
    Scarica in formato PDF o leggi online su Scribd
    Segnala contenuti inappropriati
    9 visualizzazioni36 pagine

    CAP7

    Caricato da

    JoséA.Yáñez
    INGENIERIA DEL SOFTWARE

    Copyright:

    © All Rights Reserved
    Scarica in formato PDF o leggi online su Scribd
    Segnala contenuti inappropriati
    di 36
    INGENIERIA | DE REQUISITOS — 3 a comprension de los requisitos de un problema éstd entre las tareas mas difiiles que enfrenta un ingeniero de software. Cuando se piensa por pri- mera vez acerca de ello, la ingenieria de requisitos no parece tan dificil. Después de todo, zl cliente no sabe lo que se requiere? Los usuarios finales no. ‘deberian entender bien las caracteristicas y funciones que les proporcionarén un ‘beneficio? Es sorprendente, pero en muchas ocasiones la respuesta a estas pre- ‘guntas es; “no”. ¥ aun silos clientes y usuarios finales son explicitos en sus ne cesidades, estos requisitos pueden cambiar durante el proyecto, La ingenieria de requisitos es diff En el prologo a un libro de Ralph Young [YOUO!] sobre las practicas efectivas. fen los requisitos, el autor de este libro escribi: Es tupeorpesadilla. Un cliente entra entucficina, se sient, te mira directo alos oos, 1 dice: "Yo sé que usted piensa que entiende lo que digo, pero lo que usted no en tiene €s que toque digo no es realmente lo que quiero decir. Esto sucede de ma~ ‘era invariable cuando el proyecto esta avanzado, después de que se han realizado Jos compromisos relativos al tempo de entrega, las eputaciones estan en juego y el dinero esta en seri peligro. ‘Todos los que hemos trabajado en el negocio dees sistemas ye! somware por mas ‘de unos cuantos aftos hemos vivide esta pesadilla,y solo unos pocos de nosotros he- ‘mos aprendido a continuar aun con esta circunstancia, Nosotros tenemos dificulta- ‘des cuando tratamos de obtener requisitos de nvestios clientes. Tenemos problemas al comprender a informacion que adquitimos. Con frecuencia, registranos Jos Te- ‘uisitos de una manera desorganizada ¢ invertimos muy poco tiempo en verificar lo que registramos. Permitimos que e! cambio nos controle en lugar de establecer mecanismos para controlario. En resumen, fllamos al establecer un cimiento sido para el sistema o software, Cada uno de estos problemas representa un reto. Cuando éstos se combina, la lmagen es desalentadora incluso para los gerentes y profesionales del sofware mas expe- rimentados. Pero existen soluciones. Seria deshonesto decir que la ingenieria de requisitos es la “solucion” para los retos que se han enunciado, Pero proporciona un enfoque sélido para abordar dichos desafios, Las actividades de disefto y construccion de software de computadora son desafian- tes, creativas y hasta divertidas. De hecho, la construccion es tan irresistible que ‘muchos desarrolladores de software quieren entrar en ella antes de comprendet con laridad de qué es lo que se necesita. Ellos argumentan que las cosas se aclararén mientras construyen; que los interesados en el software serdn capaces de entender ‘mejor las necesidades s6lo después de examinar las primeras iteraciones del soft ‘ware; que las cosas cambian tan rapido que la ingenierla de requisitos es una pérdi- da de tiempo; que la linea de base produce un programa que funciona y todo lo demas es secundario. Lo que hace seductores a estos argumentos es que contienen elementos de verdad.' Pero cada uno de ellos es imperfecto y puede conducir a un proyecto de software falido. 1 Enparticular, esto es cierto para los proyectos chicos menos de un mes) que impican un esfuerzo telativamente pequeno, Conform el software crece en amano ycomplejdad, estos argumentesco- rmienzan a derrumbarse. CAPITULO 7 nicovania pe meamses 187 La ingenieria de requisitos, como todas las demas actividades de la ingenieria del software, debe adaptarse a las necesidades del proceso, el proyecto, el producto y las Personas que realizan el trabajo. Desde la perspectiva del proceso del software, la Ingenieria de requisitos (IR) es una accién de la ingenieria del software que comien. za durante la actividad de comunicacién y continda en la actividad de modelado. En algunos casos se elige un enfoque abreviado, En otros, cada una de las tareas on freciencia esta il excminar code © gE requ se puede probs? Se x pueden rein frente ne seri de preguncs en expecta es prborllgunor veces kana eis de lista de verfcacién. Enseguida se presenta un de volidecién) pore ejercior ol requiio? en RR © El requiso ot radreble para cvlauier models de requisios extén estblecdos de manera coro? “20s pueden malinerpretorset he het del rust [or ejemplo, uno persona, una ‘ep ocion oun replant) ext idenficedat sl “ererciodo final del equisto ha sido exarinado or ka ‘Lente original ocomporéndolo con ola? revises eskingido en eminos cuontitvon? Lets ors rusts estén relacionados con état | 8en registrados de manera cor por medio de uno Jmotiz de relerencis erzzodosvctro mecarismot aE rewisito volo alguna resect del dominio del sone? sistema que haye sido creado? El requtto oc rosreable pore loz objetos generals del sistema 0 producot * 21a especificacén ests esructrade de une forme que conduzco a su eomprensn,rafrenciay naduccisn fecil en productos de trabajo més tecnicos? © {Se ho creado olgin indice para la especificacén’® * dos requisites arciodos con el rendimiem, desempeto las coraterisicas operocionales se hon ‘estblecido de monera clara? sCvslesreqvislos parecen ser implica? 7.2.7 Gestién de requisitos En el capitulo 6 se estabieci6 que los requisitos para los sistemas basados en compu tadoras cambian y que el deseo de cambiarlos persiste durante la vida del sistema, La gestion de requisitos es un conjunto de actividades que ayudan al equipo de pro- yecto a identificar, controlar y rastrear los requisites y los cambios a éstos en cual 162 ow sites gas yong ome dee conse bs ‘xc Secondo ise hiss deste ihe po oa xa. PARTE DOS rRActcA neta nvGEmRIA DL SOPTWARE quter momento mientras se desarrolia el proyecto.* Muchas de estas actividades: idénticas a las actividades de la gestion de la configuraciOn del software (GCS) se tratan en el capitulo 27, La gestion de requisitos comienza con la identificacion. Cada requerimiento asigna a un solo identificador. Una ve7 identificados los requisitos se desarrollan tablas de rastreabilidad. En la figura 7.1 se muestra de manera esquematica tabla de rastreabilidad, cada una de ellas relaciona los requisitos con uno 0 aspectos del sistema o de su ambiente. Entre las muchas tablas de rastreabili osibles estén las siguientes: Tabla de rastreabilidad de las caracteristicas. Muestra la manera en que requisites se relacionan con las caracteristicas del sistema/producto observabi para el cliente Tabla de rastreabilidad de la fuente. identifica la fuente de cada requisito ‘Tabla de rastreabilidad de dependencia. indica la forma en que los requisites estan relacionados entre si ‘Tabla de rastreabilidad del subsistema. Establece categorias entre los requi- sitos de acuerdo con elios) subsistema(s) que gobiema(n). ‘Tabla de rastreabilidad de la interfaz. Muestra la forma en que los requisites se relacionan con las interfases internas y externas del sistema, En muchos casos, estas tablas de rastreabilidad se mantienen como parte de la base de datos de los requisitos de forma que pueda buscarseles con rapidez para) entender cémo el cambio en un requisito afectara diferentes aspectos del sistema’ ‘que se construira. DX. Aspecio especifico dal sistema o su ambiente i ie So be 5 Lagestion formal de requsitos se inca slo para proyectos grandes; ls cuales tienen cientos dere {uistosidenteables. En ls proyectos pequetios esta funcion de la ingenieria de requisitos es bas ‘ante menos fermal - Ingenieria de requisitos cata inertial Soe peat ee piaeemicdsis koetseoritae Reeerreer seiner se srernee hire ae Ries ea, ee eee ee Ss. eam yAidontic Systems Guide, Inc. ha preparade uno listo Beemer econ pacegs rtpeatonsana Sear: fel 5! modelado de requisitos se estudia en el copitulo 8. Been ne oten cas -desorrollode por Cybernetic Intelligence GMBH ecrcler een enttenimenn versaciones si CAPITULO 7 mcosesia ve mausres En un escenario ideal, los clientes y los ingenieros de software trabajan juntos en el ‘mismo equipo” En tales casos, la ingen Een expectico del proyecto que contione desriciones y ributos dtollodos de ls requitioe. (OniYourMerk Pro, desarellodo por Omn-Visto {seew.omni-vist. com), consruye una bose de datos de los requis, establecerelaciones entre étos, y permite «los usuarios analizar la relocin ene los requists y los calendarios/costos Rotional RequistePr, deserollado por Rational Software {ww rtonal cam), permite @ los usveroe desarolor ‘une bose de dots dels requisios, representa los telociones entre és y ls organiza, priorza y rosea. RIM, desorollado por Integrated Chipwore (sew chipware.com), es une herramienta para la descripcisn y rotreobildad de requistos que tombién soporia cir aspects del corral dl cambio y gestion de los prusbas, Se debe hacer notar que muchas tara de la get de ‘requisites se pueden realizar con una simple hoje de célcle © un sistome poquste pore ol menejo de bases de doves. ja de requisitos se trata s6lo de guiar con ificativas con colegas que son miembros bien conacidos del equipo. ‘Sin embargo, en la realidad a menudo es bastante diferente. Los clientes pueden estar en una ciudad o pais diferente, pueden tener 3610 una idea vaga de lo que se requiere, tal vez tengan opiniones conflictivas acerca del siste ‘ma que se construira, quiza su conocimiento técnico sea limitado y tengan un tiempo limitado para interactuar con el ingeniero de requisites, Ninguna de estas situaciones es deseable, pero son muy comunes, yel equipo de software con frecuencia se ve obli gado a trabajar dentro de las restricciones que tmpone esta situacion. En las secciones siguientes se cxaminan los pasos requeridos para iniciar la inge nieria de requisitos; es decir, para comenzar un proyecto de forma que se mantenga en movimiento hacia una solucién exitosa, nencionadas aq son una muestra dentro de esta categoria En la mayoria de los ‘asos los nomires estin registrados por sus respetivos deserolladores 7 Este enfoque se recomienda para todos los proyectos es esarollo i de software 12 parte integra dela filosofa pars el 164 CLAVE Un ited es kon we arpa forma oa onl sstne ‘qe s2ve9 dsr ‘brn enfics d ts PARTE DOS reicnca oe 1a nora om. sorrware, 7.3.1 Identificacién de los interesados ‘Sommerville y Sawyer [SOM97} definen a los interesadas como “todas aquellos q se benefician en una forma directa o indirecta del sistema que esta en desarrollo Ya se ha identificado a los sospechosos usuales: gerentes de operaciones de clos, gerentes de producto, gente de mercadotecnia, clientes internos y exter usuarios finales, consultores, ingenieros de producto, ingenieros de software; in; nieros de soporte y mantenimiento y otros. Cada interesado tiene una vision dif Tente del sistema, obtiene beneficios diferentes cuando éste se desarrolla de mane exitosa, y esta abierto a diferentes riesgos si el esfuerzo de desarrolio legara a fal En el inicio el ingeniero de requisitos puede crear una lista de personas que con {ribuirén durante la obtencién de requisitos (seccién 7.4). La lista inicial crecer4 cot forme se establezca contacto con los interesados, ya que a cada uno de ellos se preguntara: “zCon quién mas piensa que deberia hablar?” 7.3.2 Reconocimiento de miiltiples puntos de vista Debido a que existen muchos clientes diferentes, 1oS requisitos del sistema Se raran desde diversos puntos de vista. Por ejemplo, el grupo de mercadotecnia interesado en funciones y caracteristicas que estimulen al mercado potencial, que hhagan que el nuevo sistema sea facil de vender. Los gerentes de negocios estan int resados en un grupo de caracteristicas que se puedan construir sin rebasar un pr supuesto y que estén listas para llegar a nichos de mercado definidos. Los usuarios finales pueden desear caracteristicas con las que estén familiarizados y sean fécil de aprender y utilizar. Los ingenieros de software quizé estén interesados en fun= iones que den el soporte de la infraestructura y caracteristicas més accesibles al ‘mercado. Los ingenieros de soporte se pueden enfocar en la facilidad de manteni- rmiento del software Cada uno de estos componentes (y otros) proporcionaran informacion al proceso de la ingenietia de requisitos. Conforme se recopila informacion desde miltiples Puntos de vista, los requisitos que surjan pueden ser inconsistentes 0 entrar en con- flicto con algin otro. EI trabajo del ingeniero de requisitos es categorizar toda la informacién de los interesados (incluidos los requisitos inconsistentes y conilictivos) en una forma que permita a quienes tomen la decisiones elegir un conjunto de requi- sitos para el sistema que sean consistentes de manera interna. 7.3.3. Trabajo con respecto a la colaboracién En los capitulos previos se ha mencionado que los clientes (y otros interesados) deberian colaborar entre si evitando peleas insignificantes) y con los profesionales CAPITULO 7. ncaa oe mnausnos 165 de la ingenieria del software si se desea obtener un sistema exitoso. Pero, gcomo se ogra esta colaboracion? El trabajo del ingeniero de requisitos es identificar areas en comtin (es decir, los requisitos en los que todos los interesados estén de acuerdo) y areas de conflicto 0 inconsistencia (esto es, los requisitos solicitados por un interesado que entran en conflcto con las necesidades de otro). Esta es, por supuesto, la ilima categoria que presenta un desatio. Peston Utilizacién de los “puntos de prioridad” requisites, ol mismo lempo que se eniende ertoncia relative de tod, esl ulzacién de de “votocién” bosodo en puntos de prioridad, smseresodosreciben la mismo cantidad de puntos gee pueden “gostorse” en cuclauir némero de (desde su punto de visto} ol arignrle uno 0 més puntos de provided. Los puntos eignodos no se pusden reuilzar Una vez que les puntos de prorided del intretado se hon cogotedo, dicha persona ne puede reclzor ningun oro ceccién sobre los requisites. Las puntos totals que asgnen © cade requitio todos lo intrerodos indican lo Se presenta una liste de requisites y los ‘edicon la impononco relative de cade uno Jimportancia goneral de coda requis, La colaboracién no significa, necesariamente, que los requisitos se definan por consenso. En muchos casos, los interesados colaboran al proporcionar su vision de Jos requisitas, pero un fuerte “campedn de proyecto" (por ejemplo, un gerente de nego: cios 0 un técnico importante) puede tomar la decision final acerca de cuales requi sitos se aceptan, 7.34 Formulacién de las primeras preguntas En este capitulo se ha destacado que las preguntas formuladas al inicio del proyec- to deben ser “libres de contexto” [GAU89]. El primer conjunto de preguntas libres de ontexto se enfoca en e! cliente y otros intercsados, metas generales y cn los bene ficios. Por ejemplo, el ingeniero de requisitos podria preguntar: opreizeie del ore de lo negococién hhablondo, Es necesrio escuchar. Fs posible que se cect es uno acvidod que sve o raves de cbfenge un conacimieno que ayudar a negocar de sécrice y personal. La consideocign de los mejor manera la poscion propio dlreckices puede osultar muy vaso Erfocorse en ls infress de a os porte, Sse Reconocer que no es wre compelerci, Para ser eran evita es confdis nose debe tomar una ‘eitoro,ombos laos daben leer el sertimianto de posi inflenble haber ganado @logrado algo, Los dos partes 5. No dejar que se whe personal. Enfocore an terdeen que legar 2 un verde, probleme que debe ser reel, Diseor una estatgio. Decidir que es lo que se 4. Ser creative. Cuando exisn sitaciones do eseare logror que lo quel otra porte quiere ‘estoncaminto no e debe tener miedo de pensar ‘leanzer,y qué elo que se vec hocer pore que fuera de los canones. i once sondon 7 Gerba te pte ara gn oh tg Excuchar de manera activo. Nose debe pensor en Speco cin pape eaS da SSE ormulor unc respuesto mientras la ofa porte ests dicho comenio y seguir odelono, Cuando se rvisan las requisites, genes preguntas debea Inacerse? Alctear cada elemento del modelo de andlisis,éste se examina para conocer su sistencia, sus omisiones y ambigiiedades. A los requisitos que representa el mod i cliente Tes da jerarquia y se agrupan en paquetes de requisitos que se imp tan como incrementos de software y se le entregan. Una revision del modelo de lisis se enfoca en las siguientes preguntas: © Cada requisito es consistente con el objetivo general del sistema /producto # Todos los requisitos han sido especificados con el grado apropiado de abstraccion? Esto es, calgunos requisitos proporcionan un grado de detalle tenico que sea inapropiado en esta etapa? © Zl requisito es necesario en realidad o representa una caracteristica _agregada irrelevante para el objetivo del sistema? eCada requisito esta limitado y no es ambiguo? + «Cada requisito tiene una atribucidn? Esto es, gexste una fuente (por lo general especifica, individual) determinada para cada requisito? + eAlgunos requisites eniran en contficto con otros? ‘+ eCada requisito es alcanzable en el ambiente técnico que recibiré al sist producto? +

    Potrebbero piacerti anche