10-administración de requisitos

7/31/2019 10-Administracin de Requisitos

1/45

Administracinde

requerimientos

Pilar Stronguil Leturia


2/45

Agenda Introduccin Requerimientos estticos y voltiles Identificac in y a lmacenamiento de

requerimientos Rastreo del estado de los requerimientos Administrac in del cambio

Trazabilidad Requerimientos y administrac in del riesgo


3/45

Introduccin


4/45

Ingeniera de RequisitosIngeniera de Requisitos

Desarrollo Administrac in

Captura Anlisis Espec ific ac in Validac in


5/45

Qu es la Administrac in deRequerimientos? Es el proceso de administrar

los cambios a losrequerimientos del sistema. Este p roceso inc luye

ac tividades para mantener

la integ ridad, exac titud yvigenc ia de losrequerimientos ac ordados a medida queel proyec to vayaprogresando.


6/45

Administrac in derequerimientos

Administrac in deRequerimientos

Controlar

Cambios Proponer

cambios Ana lizar el

impacto

Tomar decisiones Ac tualizar las

especificacionesy doc umentos

Ac tualizar el p lan Med ir la

volatilidad de losrequerimientos

Controlar

Versiones Definir un

esquem a de laversin

Identificar las

versiones de losdocumentos Identificar las

versiones de lasespecificacionesindividuales

Controlar

Estados Definir los

estados posiblesde losrequerimientos

Registrar e lestado de c adarequerimiento

Generar rep ortesde losrequerimientospor estado

Trazar vnc ulos Definir enlaces

entre losrequerimientosdel sistema y

entre otrosprovenientes desistemas externos

Definir enlacescon otroselementos de lsistema


7/45

Cambios en los requerimientos Los requerimientos evoluc ionan y se

ac tualizan por una serie decircunstancias. Los negoc ios son dinmic os y los

proc esos tienden a ser cada vez msautomatizados.

El medio ambiente del sistema puedecambiar.


8/45

Cambios en los requerimientos Durante el desarrollo del proyec to pueden

emerger nuevos requerimientos y los que yaexisten pueden sufrir de c ambios. Esfrec uente que mas del 50% sufran mejoras ocambios antes de ponerse en marcha.

Esto no significa que se hayan empleado lasprc ticas de la ingeniera de requerimientospobremente.

Como esto ocasiona prob lemas a los

desarrolladores es necesario minimizarestas dificultades administrando losrequerimientos para mantenerlosdoc umentados y c ontrolados.


9/45

Problemas que enfrenta laadministrac in de requerimientos

Manejar c ambios a los requerimientos

ac ordados y ac eptados. Manejar las relac iones entre

requerimientos. Manejar las dependenc ias entre la

doc umentac in y la p roduc c in de

requerimientos.


10/45

Requerimientos estticos yvoltiles


11/45

Fac tores de c ambio en losrequerimientos

Este tipo de p rob lema se p resenta durante laimplementac in en donde se desc ubre si unrequerimiento puede tomar muc ho tiempo o c ostarmucho.

Problemastcnicos,c ostos ytiempo

A m ed ida que los requerimientos se desarrollan y elusuario fina l se involuc ra (tanto func ional c omotcnic amente) puede desarrollar una mejorc omprensin de lo que rea lmente necesita.

Involuc rar alcliente/usuariofinal en elconocimientodel sistema

Estos prob lemas pueden surgir durante las etapasde anlisis y validac in o ms tarde en el desarrollodel sistema.

Errores,c onflic tos einconsistencia

DescripcinFac tor de

cambio


12/45

Fac tores de c ambio en losrequerimientos

La organizac in que tiene c omo p ropsito usar elsistema pod ra desea r c ambiar su estruc tura yproc esos y esto da r como resultado nuevosrequerimientos.

Cambiosorganizacionales

El medio ambiente en el c ual el sistema va a serinstalado puede c ambiar y en c onsec uenc iatambin los requerimientos a fin de mantener lacompatibilidad.

Cambiosambientales

Las prioridades de los requerimientos c ambiandurante el desarrollo de los requerimientos c omoresultado de c am bios en el negoc io, losc ompetidores, entre los miembros del personal,

etc.

Cambios en lasprioridades delcliente

DescripcinFac tor de

cambio


13/45

Reconoc imiento de lavolatilidad en los requerimientos Los requerimientos estables estn involuc rados con la esenc ia

del sistema y su dominio. Son los denominados core-

requirem ents . Por ejemplo: Registro de los datos de los estudiantes. Cursos en los que se han matriculado. Rec ord de las notas que han ob tenido.

Los requerimientos voltiles son espec ficos para la instalac in

del software en un ambiente y/ o c liente en pa rtic ular. Porejemplo: Atenc in de las c lases (puede ser virtual o p resenc ial

depend iendo de los requerimientos del c liente). Organizac in de los horarios y g rupos (que pueden va riar de

ac uerdo a los c amb ios en la adm inistrac in). Es una buena prc tica rec onoc er cules son los

requerimientos voltiles y tratar de antic ipa r c uando estos vana c ambiar.


14/45

Tipos de requerimientos voltiles

Requerimientosmutables

Estos req uerimientos c ambian en

c onformidad c on su med io amb ienteoperativo. Ejemplo:Calcular el impuesto a las

ventas (vara de ac uerdo a l pas).

Requerimientos

emergentes

Estos requerimientos no se definenc ompletamente durante ladoc umentac in sino q ue surgenc uando el sistema se est diseandoy/ o imp lementando.

Ejemplo:Presentar la informa c in delbalanc e (los usuarios pueden pensaren d iferentes formas de presentar lasc uentas y sus movimientos a d eta lle).


15/45

Tipos de requerimientos voltiles

Requerimientosconsecutivos

Normalmente se estab lecen sobre laba se de suposic iones ac erc a de

c mo el sistema debe ser usado. Ejemplo:Realizar reservas y reg istrar el

pa go (los usuarios pued en c am biarde opinin acerc a de c uando y c omohac er el pago por alojamiento).

Requerimientos

decompatibil idad

Estos son requerimientos quedependen de c iertos equipos oproc esos. Si el equipo c ambia

tambin lo hac e e l requerimiento. Ejemplo:Registrar la asistenc ia del

personal (vara de ac uerdo a l equipoy la tecnologa emp leada).


16/45

Identificac in yalmac enamiento de

requerimientos


17/45

Identificac in y almac enamientode requerimientos La administrac in de requerimientos en un proceso

que maneja una gran cantidad de informac in yque debe asegurarse de que sta llegue a laspersonas c orrec tas en el mom ento adec uado.

Por eso es impresc indib le contar con unaherramienta CASE que permita:

Rec onocer los requerimientos de manera nica yc lasificarlos de acuerdo a su tipo. Almacenarlos en una base de datos. El an lisis y generac in de doc umentos. Manejar cambios y ayudar a que stos se estab lezc an y

costeen aprop iad amente. Efec tuar la trazabilidad; la cual ayudar a que los

ingenieros de requerimientos estab lezcan lasdependenc ias entre los distintos requisitos del sistema.

Administrar versiones


18/45

Identificac in y almac enamientode requerimientos La identificac in de los requerimientos es

esenc ial para la administrac in. Normalmente existe un descuido en

identificar de manera nica los

documentos. Por eso es til contar c on una herramienta que

permita cod ificar los doc umentos de maneraautomtica.

Existen d iferentes aproximac iones paraidentificar requerimientos.


19/45

Identificac in y almac enamientode requerimientos

Los requerimientos son identificados de manerasimblica de ac uerdo a su tipo. Por ejemplo FR01, FR02estarn relac ionados a la funcionalida d, en cambio,SEC01 y SEC02 lo estarn c on la seguridad definida parael sistema.

Identificacinsimblica

Cada vez que se incorpora un requerimiento a la basede da tos, el manejador le asigna un identificador queluego es empleado en todas sus referenc ias.

Identificacinde reg istrosen una BD

Similar a la p roporcionado por un proc esador de textoque genera una numerac in automtic a p ara losprrafos y proporciona fac ilidades de referenc iacruzada.

Numeracindinmica

DescripcinMtodo


20/45

Atributos de los requerimientos Adems de su contenido y

desc ripc in es importante c ontar c onla ac tualizac in de c iertos atributosque permitan c lasific ar y administrarmejor los requerimientos.

El manejo de atributos es

espec ia lmente importante si el sistemaes largo y c omplejo.


21/45

Atributos de los requerimientos Fec ha de c reac in Nmero de versin ac tual. Autor de la espec ificac in. Persona responsable de su

implementacinsatisfactoria.

Propietario y stakeholdersresponsables (que tomarndec isiones ac erca de suscambios).

Estado del requerimiento. Categora.

Fuente o origen delrequerimiento.

El propsito Subsistem a(s) en donde

ser asignado elrequerimiento.

Mtodo de verificac in oc riterio de ac eptac in. Prioridad de

implementacin. Grado de d ificultad . Estabilidad/Volatilidad


22/45


23/45

Rastreo del estado de losrequerimientos Generalmente los analistas y

desarrolladores son optimistas y pocorea listas al momento de proporc ionarinformac in acerca del estado de losrequerimientos. Tpicamente: El requerimiento est al 90%

(durante meses y en d istintas iterac iones).

Es importante rastrear el estado verdadero

del requerimiento en c onformidad con losob jetivos planificados para una iterac in enparticular y para el sistema en general.


24/45

Estados sugeridos

El cd igo que imp lementa el requerimiento hasido diseado, codificado y p robad o.

Implementado

El requerimiento ha sido analizado, su impac toen el proyec to ha sido estimado y ha sido

asignado a una iterac in determinada.Los stakeholders han ac ordado suincorporac in c omo parte del sistema y elgrupo de desarrollo se ha comprometido aimplementarlo.

Aprobado

El requerimiento ha sido presentado por unafuente autorizada del proyec to.Propuesto

DescripcinEstado


25/45

Estados sugeridos

El requerimiento fue p ropuesto pero no se haplanificado su implementac in en las versionesprximas del sistema. Se ha incluido tambin laexplic ac in del por qu y por quin se hatomado la dec isin de rec hazarlo.

Rechazado

Un requerimiento p reviamente aprobado se ha

removido de la lista de requerimientos. Se haincluido una explicac in del por qu y porquin se ha tomado la dec isin de eliminarlo.

Eliminado

Se ha confirmado el correc to func ionamientodel requerimiento como parte del produc tointegrado. Se le considera c ompletado.

Verificado

DescripcinEstado


26/45

Administrac in delcambio


27/45

Administrac in del cambio La administrac in del cambio est vinculada con los

proc ed imientos, proc esos y estndares que son usados para

maneja r cambios a los requerimientos del sistema. Sin una administrac in del cambio formal es imposible que segarantic e que los cambios propuestos estn en c onformidadcon los ob jetivos del negoc io.

Esto invo luc ra:

El proc eso d e requerimiento de c amb io y la informac inproporc ionada para da rle c urso. El proceso usado para analizar el impac to y los c ostos del

cambio, c on la informac in de la trazab ilidad c orrespondiente. La c onformac in y pa rtic ipac in del grupo de usuarios que va a

c onsiderar y eva luar los requerimientos de c ambio. El software que le va a dar soporte.


28/45

Proceso de administrac in del

cambio

Anlisis del prob lema yespec ificac in del c ambio

Imp lementac in de lcambio

An lisis y c osteodel cambio

Problemaidentificado

Requerimientorevisado


29/45

Proceso de administrac in del

cambio1. Anlisis del prob lema y espec ific ac in del cambio

Este puede estar relac ionado c on nuevas nec esidades del

c liente o prob lemas operac ionales. Los requerimientos son analizados usando la informac in

del prob lema y los cambios son p ropuestos. Es dependiente del tipo d e c ambio requerido.

2. Anlisis y c osteo del cambio Aqu se analiza el cambio desde la perspec tiva de c untos

requerimientos estn afec tados y de c uanto tiempo y c ostova a dema ndar efec tuarlo.

Es ms genera l.

3. Imp lementac in del cambio Se dan una serie de c ambios en el texto de ladoc umentac in y se p roduce una nueva versin quedeber ser validada.


30/45

Proceso de anlisis y costeodel cambio

Verificarvalidez de l

cambio

Esvlido?

Rec hazar elpedido de

cambio

Encontrarrequerim.afectados

Encontrarlas depen-

dencias

Proponercambios

Establecerlos costos

del c amb io

Estableceraceptacinde c ostos

NO

SI

ListaReq.

Lista de

Req.X

Cambiar

Esvlida?

Rec hazar lapropuestade cam bio

SI

NO

Prop. deCambio

InfoCostos

InfoClientes

ChangeReq


31/45

Partes de un Pedido de Cambio

(Change Request Spec ific ation)1. Introducc in

Propsito Alcance Definiciones, Ac rnimos y Referenc ia.

2. Roles y responsabilidades.3. Estado del c ambio4. Criterios de inic io5. Tareas

Evaluar el cam bio Dec idir el ca mb io Efec tuar el cam bio Notificar a las pa rtes afec tadas

6. Verificac in Verifica r el cam bio Instalar el produc to mod ificado

7. Criterios d e fin8. Reporte del estado de l ped ido de cambioApndice: Datos almac enados pa ra c ada ped ido.


32/45

Roles en la Administrac in de

cambios

Persona que rec ibe el pedido de c ambio por que le fuedirigido.

Receptor

Persona enc argada de efec tuar las mod ific ac iones

requeridas aprobadas.

Modificador

Persona requerida pa ra ana lizar el impa c to d el camb io.Puede ser un tcnic o o el c liente.

Evaluador

Persona que establec e y enva e l pedido de c am bio.Originador

Persona que determina si el cambio se hizo c orrec tamente.Verificador

Grupo que dec ide si aprobar o rec hazar la p ropuesta opedido de c ambio. Est c ompuesto de l gerente de lproyec to, analistas, desarrolladores, testers, rep resentantesdel c liente, tc nic os en doc umentac in, help desk y

configuraciones.

Equipo CCB

Persona a c argo de l equipo de c ontrol de c ambios

(Change Control Board) y q ue tiene la dec isin final.

Jefe del CCB

Descripcin y responsabilidadesRol


33/45

Razones para rec hazar un

pedido de cambio El doc umento de ped ido de c ambio es

invlido. Normalmente sucede c uando el c liente tiene

una mala comprensin del requerimiento ypropone un cambio innec esario.

Los resultados del cambio traen otrasmodificac iones consecutivas que soninaceptables.

Los costos de implementac in del cambioson muy a ltos o toma mucho tiempo.


34/45

Trazabilidad


35/45

Trazabilidad Una parte c rtic a de la administrac in

de requerimientos es establec er elimpac to del c ambio en el resto delsistema.

Para poder hac erlo es nec esariomantener la informac in de la

trazabilidad de los requerimientos.


36/45

Formas de Trazabilidad Backward- from trac eability

Enlaza los requerimientos con sus fuentes en otros

doc umentos o personas. Forward-from traceability

Enlaza los requerimientos con los componentes de d iseoe implementac in.

Backward-to trac eability Enlaza c omponentes de d iseo e implementac in con sus

requerimientos inic iales.

Forward-to trac eability Enlaza otros doc umentos (que p rec eden las

espec ificac iones o SRS) c on otros requerimientosimportantes.


37/45

Formas de Trazabilidad

Forward totraceability

Plan de Negoc ios

Forward fromtraceability

Bac kward fromtraceability

Especificacin deRequerimientos

Bac kward totraceability

Especificacin deDiseo


38/45

Tipos de trazabilidad

Enlaza requerimientos con otros queson de c ierta manera dependientes deellos.

Requerimientos-Requerimientos

Enlaza un requerimiento c on la

desc ripc in del por qu fueespec ificado. sta puede ser unadoc umentac in resumida y ob jetiva devarias fuentes.

Requerimientos-

Propsitos

Enlaza un requerimiento c on las

personas o doc umentos que los hanespecificado.

Requerimientos-

Fuentes

DescripcinTipo


39/45

Tipos de trazabilidad

Enlaza requerimientos con lossubsistemas en donde sernimplementados.

Requerimientos-arquitectura

Enlaza requerimientos con

componente espec ficos de hardwarey software.

Requerimientos-

diseo

Enlaza requerimientos con las

interfac es de sistem as externos.

Requerimientos-

interfaz

DescripcinTipo


40/45

Requerimientos yadministrac in del riesgo


41/45

Elementos de la administrac in

del riesgo

Administracindel riesgo

Establecer

Evitar

Controlar

Identificacin

Anlisis

Priorizacin

Plan de admin.

Resolucin

Monitoreo


42/45

Riesgos relac ionados c on los

requerimientos En la captura de requerimientos:

Estab lec imiento de la visin y el a lcance. Tiempo ded icado al desarrollo de los requerimientos Trmino y c orrec c in de las espec ificac iones de

requerimientos. Requerimientos de produc tos con a lta innovac in. Definic in de requerimientos no func ionales. Ac eptac in de los c lientes acerca de los requerimientos

de l producto. Requerimientos que no se han estab lec ido. Uso de un produc to existente como fuente de c aptac in

de req uerimientos. Soluc iones propuestas por el usuario que oc ultan

necesidades.


43/45


requerimientos En el an lisis de requerimientos:

Priorizacin Fac ilidades tcnicamente difc iles. Uso de tec nologas, mtodos, lenguajes,

herramientas o hardware poc o c onoc idos.

En la espec ificac in de requerimientos Comprensin de la doc umentac in. Presin de tiempo por comenzar el desarrollo sin

haber ac larado puntos por determinar. Terminolog a con ambigedades. Diseo inc luido en los requerimientos.

Ri l i d l


44/45


requerimientos En la va lidac in de requerimientos:

Requerimientos no verificados. Experienc ia y habilidades de los

inspectores.

En la administrac in de requerimientos Requerimientos cambiantes. Proceso de requerimientos de c ambio. Requerimientos no implementados. Expansin del alcance del proyec to.


45/45

Conclusiones La administrac in de requerimientos es importante

desde que es inevitable que sufran cambios. Los requerimientos que forman parte del corazndel sistema son ms estab les que aquellos que

estn direc tamente relac ionados c on la forma encomo ser el sistema implementado.

Es importante contar con herramientas de softwareque permitan administrar tanto los requerimientoscomo los pedidos de cambio.

La trazabilidad es importante para establecer lasdependenc ias entre requerimientos y sus fuentes.

La administrac in de riesgos es un aliado de losgerentes de proyec tos para tomar c onsc ienc ia detodo aquello que puede a fec tar a l proyec to.

10-administración de requisitos

Documents