Proceso de Construcción de Escenarios Futuros

7. Definición del Contexto del Software

7.2. Proceso de Construcción de Escenarios Futuros

Como se observa en la Figura 33, se distinguen dos tipos de objetivos: los objetivos generales del sistema y los objetivos concretos para cada servicio del software, ya sea el software actual o futuro. Estos objetivos concretos responden a los procesos del negocio, pues los escenarios están describiendo situaciones en el contexto organizacional. Además, se debe distinguir entre los objetivos del negocio y los objetivos del software, estos últimos no pueden estar en conflicto con los primeros, pero en algunos casos pueden llegar a alterar sutilmente los objetivos del negocio. Esto dependerá exclusivamente de la aceptación de los clientes. Los objetivos del negocio a veces no están explícitos, pudiendo permanecer ocultos a los desarrolladores y recién aflorar cuando los objetivos expresados del sistema de software entran en conflicto con ellos.

7.2. Proceso de Construcción de Escenarios

Futuros

La primera pregunta que debe contestarse antes de decidir cualquier acción Evolución Refinamiento marco marco Definir Objetivos Generales del Sistema Describir situaciones

observadas concretos Objetivos

Describir situaciones

relativa a los EF es: ¿Qué grado de Reingeniería de los Procesos del Negocio

se espera?

Cuando el proyecto de software está envuelto en una reingeniería del negocio importante, siendo el sistema un factor clave del proyecto, se espera que muchas situaciones actuales se modifiquen durante la implantación del artefacto de software. Como consecuencia también se espera que los EF tengan poco apareo con los EA.

En el otro extremo, existen algunos proyectos de software que tienen el compromiso de mantener el proceso del negocio tan inalterado como sea posible. Esto puede deberse a varias razones, tales como regulaciones gubernamentales, políticas de la casa matriz, estándares industriales o meramente para preservar una forma exitosa de llevar el negocio. Se espera entonces que haya muchos apareos entre los EA y los EF.

Los EF de proyectos de software inmersos en un nivel alto de cambios en el proceso del negocio deben construirse en un modo orientado a los objetivos, prestando menos atención a los aspectos procedurales actuales. Por el contrario, proyectos de software con un marco de trabajo de baja reingeniería de los procesos del negocio deben construir sus EF usando un enfoque dirigido por consideraciones procedurales. Sin embargo, muchos proyectos de software se ubican entre ambos extremos. Para ellos, es necesario combinar ambos enfoques según sus características.

El proceso de construcción de los EF es similar en ciertos aspectos al proceso de construcción de los EA. La Figura 34 muestra el proceso de construcción de los EF, donde las actividades operativas son tres: Seleccionar la estrategia constructiva, Describir los escenarios futuros y Organizar los mismos, mientras que las actividades de análisis corresponden a: Verificar y Validar. Algunas actividades particulares se manifiestan utilizando las mismas heurísticas y siguiendo procedimientos similares a la construcción de EA. Los productos de esta etapa son un conjunto de escenarios futuros y los objetivos del software refinados.

Figura 34. Proceso de construcción de Escenarios Futuros

La actividad Describir se basa en estrategias constructivas de EF consecuentes al grado de reingeniería de procesos requerido, pero aplica las mismas heurísticas de descripción empleadas para construir los EA con adaptaciones menores. Las actividades Organizar y Verificar son casi idénticas a las actividades homónimas del proceso de construcción de escenarios actuales, excepto la verificación sobre el cubrimiento del LEL, que no se realiza, y el refinamiento de los objetivos del sistema, que es una nueva tarea dentro de organizar. En el caso de Validar se recomiendan otras técnicas: la prototipación o el uso de storyboards.

Una vez construidos el LEL y el conjunto de EA, los ingenieros de requisitos cuentan con conocimiento suficiente para comprender el UdeD. Sobre esta base y en función de los objetivos del sistema, comienza la etapa de definición del contexto del sistema de software. Según las características del sistema y el grado de reingeniería de procesos se aplicarán diferentes enfoques para construir los EF.

Durante este proceso, se debe comprender lo que los clientes y los usuarios necesitan y desean para el nuevo software. Por otro lado, se realizan

CLIENT-USER Notion:

- Person or group of persons, belonging to UofD, who interacts with the requirements engineer Behavioral Response: - He supplies the documentation or he participates in

the interviews - He participates in the LEL validation - He participates in the scenarios validation

CLIENT-USER Notion:

- Person or group of persons, belonging to UofD, who interacts with the requirements engineer Behavioral Response: - He supplies the documentation or he participates in

the interviews - He participates in the LEL validation - He participates in the scenarios validation

CLIENT-USER Notion:

- Person or group of persons, belonging to UofD, who interacts with the requirements engineer Behavioral Response: - He supplies the documentation or he participates in

the interviews - He participates in the LEL validation - He participates in the scenarios validation

LEL

Escenarios Futuros

T ítu lo : O b te n er la d o cu m e n tac ió n O b jetiv o :O bte n er to d a la in fo rm a c ió n e s crita co n q u e c u e n ta e l c lie n te -u s u a rio p a ra q u e e l in g e n ie ro d e re q u is ito s re a lic e su tra b a jo C o n tex to : S e e fe ctú a e n la s d e p e nd e n c ia s d e l clie n te -u s u a rio D e b e h a b e rs e re aliza d o la id en tific ac ió n d e fu e n te s d e in fo rm a c ió n

A cto re s:In g e n iero d e re qu is ito s C lie n te -u su a rio

R ec u rs o s :d o cu m e n ta c ió n

E p is o d io s :

1 .E l in g e n ie ro d e req u is ito s re cib e to d a la d o cu m e n ta c ió n c o n q u e cu e n ta e l clie n te -u s u a rio . 2 .E l in g e n ie ro d e req u is ito s e n c o n ju n to co n e l c lie n te -u su a rio ev a lú a si la d o cu m e n ta c ió n re c ib id a re s p o n d e a la s e x p e cta tiva s . E x ce p cio n e s : T ítu lo : O b ten e r la d o c u m en tac ió n O b je tiv o :O b te n e r to d a la in fo rm a c ió n es c rita co n q u e c ue n ta e l c lie n te -u su a rio p a ra q u e el in g e n ie ro d e re q u isito s re a lic e su tra b a jo C o n te xto : Se e fe c tú a e n la s d e p e n d e n cia s d e l clien te -u su a rio D e b e h a b erse re a liz a d o la id e n tifica c ió n d e fu e n te s d e in fo rm a ció n

A cto res :In g e nie ro d e re q u isito s C lie n te -u s u a rio R ec u rs o s:d o cu m e n ta ció n E p iso d io s: 1 .El in ge n ie ro d e re q u is ito s re cib e to d a la d o c u m e n ta ció n co n q u e c u en ta el clien te -u su a rio . 2 .El in ge n ie ro d e re q u is ito s e n c o n ju n to co n e l clie n te -u su a rio e va lú a si la d o cu m e n ta ció n rec ib id a re sp o n d e a la s e xp e c ta tiv a s . E x cep cio n e s : T ítu lo : O b te n er la d o cu m e n tac ió n O b jetiv o :O bte n er to d a la in fo rm a c ió n e s crita co n q u e c u e n ta e l c lie n te -u s u a rio p a ra q u e e l in g e n ie ro d e re q u is ito s re a lic e su tra b a jo C o n tex to : S e e fe ctú a e n la s d e p e nd e n c ia s d e l clie n te -u s u a rio D e b e h a b e rs e re aliza d o la id en tific ac ió n d e fu e n te s d e in fo rm a c ió n

A cto re s:In g e n iero d e re qu is ito s C lie n te -u su a rio

R ec u rs o s :d o cu m e n ta c ió n

E p is o d io s :1 .E l in g e n ie ro d e req u is ito s re cib e to d a la d o cu m e n ta c ió n c o n q u e cu e n ta e l clie n te -u s u a rio . 2 .E l in g e n ie ro d e req u is ito s e n c o n ju n to co n e l c lie n te -u su a rio ev a lú a si la d o cu m e n ta c ió n re c ib id a re s p o n d e a la s e x p e cta tiva s . E x ce p cio n e s : Heurísticas Modelo de Escenario T i t l e : G o a l : C o n t e x t : A c t o r s : R e s o u r c e s : E p i s o d e s : E x c e p t i o n s : T e m p o r a l L o c a t i o n : G e o g r a p h i c a l L o c a t i o n : P r e c o n d i t io n s :

T ítu lo : O b te n er la d o cu m e n tac ió n O b jetiv o :O bte n er to d a la in fo rm a c ió n e s crita co n q u e c u e n ta e l c lie n te -u s u a rio p a ra q u e e l in g e n ie ro d e re q u is ito s re a lic e su tra b a jo C o n tex to : S e e fe ctú a e n la s d e p e nd e n c ia s d e l clie n te -u s u a rio D e b e h a b e rs e re aliza d o la id en tific ac ió n d e fu e n te s d e in fo rm a c ió n

A cto re s:In g e n iero d e re qu is ito s C lie n te -u su a rio

R ec u rs o s :d o cu m e n ta c ió n

E p is o d io s :

1 .E l in g e n ie ro d e req u is ito s re cib e to d a la d o cu m e n ta c ió n c o n q u e cu e n ta e l clie n te -u s u a rio . 2 .E l in g e n ie ro d e req u is ito s e n c o n ju n to co n e l c lie n te -u su a rio ev a lú a si la d o cu m e n ta c ió n re c ib id a re s p o n d e a la s e x p e cta tiva s . E x ce p cio n e s : T ítu lo : O b te n er la d o cu m e n tac ió n O b jetiv o :O bte n er to d a la in fo rm a c ió n e s crita co n q u e c u e n ta e l c lie n te -u s u a rio p a ra q u e e l in g e n ie ro d e re q u is ito s re a lic e su tra b a jo C o n tex to : S e e fe ctú a e n la s d e p e nd e n c ia s d e l clie n te -u s u a rio D e b e h a b e rs e re aliza d o la id en tific ac ió n d e fu e n te s d e in fo rm a c ió n

A cto re s:In g e n iero d e re qu is ito s C lie n te -u su a rio

R ec u rs o s :d o cu m e n ta c ió n

E p is o d io s :

1 . E l in g e n ie ro d e req u is ito s re cib e to d a la d o cu m e n ta c ió n c o n q u e cu e n ta e l clie n te -u s u a rio . 2 . E l in g e n ie ro d e req u is ito s e n c o n ju n to co n e l c lie n te -u su a rio ev a lú a si la d o cu m e n ta c ió n re c ib id a re s p o n d e a la s e x p e cta tiva s . E x ce p cio n e s : T ítu lo : O b te n er la d o cu m e n tac ió n O b jetiv o :O bte n er to d a la in fo rm a c ió n e s crita co n q u e c u e n ta e l c lie n te -u s u a rio p a ra q u e e l in g e n ie ro d e re q u is ito s re a lic e su tra b a jo C o n tex to : S e e fe ctú a e n la s d e p e nd e n c ia s d e l clie n te -u s u a rio D e b e h a b e rs e re aliza d o la id en tific ac ió n d e fu e n te s d e in fo rm a c ió n

A cto re s:In g e n iero d e re qu is ito s C lie n te -u su a rio

R ec u rs o s :d o cu m e n ta c ió n

E p is o d io s :

Verificar

Validar

Organizar

Seleccionar

Describir

FICHA DE REQUISITO CANDIDATO ESPONTANEO Proyecto: ____________________ Fecha: __/__/____ Ingeniero de Requisitos: ________ Descripción:___________________ ______________________________ ______________________________ Prioridad: Obligatorio Deseado Tipo: RF RNF: ____________ Fuente de Información: ____________ Etapa del Proyecto: _______________ Observación: ____________________ Plant Supervisor Personal Chief Contract Truck Dispatcher Enterprise Documents Legal Documentation Lista de Fuentes de Información Objetivos del Sistema y tener informción fehaciente de los cajeros que venden y conocer los tiempos en cada paso de la gestión y llevar un seguimiento de los servicios brindados a clientes UdeD y tener informción fehaciente de los cajeros que venden y conocer los tiempos en cada paso de la gestión y llevar un seguimiento de los servicios brindados a clientes Fichas Información Anticipada F I C H A D E R E Q U I S I T O C AN D ID AT O E S PO N T AN E O P ro y ec to : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ F e c h a : _ _ /__ /_ _ _ _ I n g en ie ro d e R eq u is ito s: _ _ _ _ _ _ _ _ D e s c rip c ió n :_ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ P r io r id ad : O b lig a to rio D es ea d o T ip o : R F R N F: _ _ _ _ _ _ _ _ _ _ _ _ F u en te d e In fo rm a c ió n : _ __ __ _ _ _ _ _ _ _ Etap a d e l P ro y e c to : _ _ _ __ _ _ _ _ _ _ _ _ _ _ O b s erv ac ió n : _ _ _ _ _ _ __ __ _ _ _ _ _ _ _ _ _ _ F I C H A D E R EQ U I SI T O C AN D ID AT O E S PO N T AN E O P ro y e c to : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ F e c h a : _ _ /_ _ /_ _ _ _ I n g e n ie ro d e R eq u is ito s : _ _ _ _ _ _ _ _ D e s c r ip c ió n :_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ P r io r id ad : O b lig a to r io D e s ea d o T ip o : R F R N F : _ _ _ _ _ _ _ _ _ _ _ _ F u en te d e In fo rm a c ió n : _ _ _ _ _ _ _ _ _ _ _ _ Eta p a d e l P ro y e c to : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ O b serv a c ió n : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ F I C H A D E R E Q U I S I T O C AN D ID AT O E S PO N T AN E O P ro y ec to : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ F e c h a : _ _ /__ /_ _ _ _ I n g en ie ro d e R eq u is ito s: _ _ _ _ _ _ _ _ D e s c rip c ió n :_ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ P r io r id ad : O b lig a to rio D es ea d o T ip o : R F R N F: _ _ _ _ _ _ _ _ _ _ _ _ F u en te d e In fo rm a c ió n : _ __ __ _ _ _ _ _ _ _ Etap a d e l P ro y e c to : _ _ _ __ _ _ _ _ _ _ _ _ _ _ O b s erv ac ió n : _ _ _ _ _ _ __ __ _ _ _ _ _ _ _ _ _ _ Objetivos Preliminares del Sistema Escenarios Actuales

actividades paralelas, como generar propuestas de requisitos, analizar requisitos candidatos elicitados en etapas previas, negociar requisitos y generar soluciones alternativas.

Después de describir los EF, éstos son verificados, corregidos de ser necesario, y luego, organizados. A partir de esta última actividad, se obtienen los escenarios futuros integradores, que dan una visión global del sistema de software y su contexto. Con los escenarios futuros y los escenarios futuros integradores se construye un prototipo o storyboards, que se utilizan para validar dicho conjunto de escenarios.

7.3. Actividades del Proceso

A continuación se detallan las actividades graficadas en la Figura 34, que son 1) Seleccionar, 2) Describir, 3) Organizar, 4) Verificar y 5) Validar.

(1) Seleccionar Estrategia

El objetivo de esta actividad es seleccionar la estrategia de construcción de los EF. Para ello, se revisan y precisan los objetivos del sistema y se determina el grado de reingeniería de procesos esperado. En base a ello, se opta por un enfoque orientado a los procedimientos, un enfoque dirigido por objetivos o un enfoque híbrido.

Dado el conocimiento adquirido por los ingenieros de requisitos, éstos pueden junto con los clientes y ciertos usuarios de niveles gerenciales mejorar los objetivos del sistema bosquejados durante el planeamiento del proyecto. El grado de mejoras a implementar puede evidenciarse en los objetivos del sistema, aunque es una información que concierne a los objetivos del negocio y deben ser planteados por los clientes. Es decir, en este paso hay una actividad de elicitación que básicamente utiliza la técnica de reuniones.

(2) Describir

El objetivo de esta actividad es elicitar y modelar conocimiento sobre las necesidades, demandas, deseos de los clientes y usuarios para el nuevo sistema de software, y/o sobre los problemas, oportunidades y normas no cumplimentadas que se detectan actualmente para solucionar en el futuro. En esta actividad, se realiza la descripción de los EF siguiendo la estrategia seleccionada en el paso previo (se detalla en la sub-sección siguiente), utilizando como información: los objetivos del sistema de software, los EA, las Fichas de Información Anticipada y la nueva información elicitada sobre el futuro, escribiéndolos haciendo uso del LEL. Durante el modelado de los EF, se realizan varias actividades en paralelo:

Evaluar los requisitos candidatos que figuran en las Fichas de Información Anticipada para determinar su incorporación a los EF. Estos requerimientos o “requisitos potenciales” se capturaron en etapas previas (durante la Comprensión del Vocabulario del UdeD y la Comprensión del UdeD Actual) y se registraron individualmente en fichas específicas para tal fin.

La información volcada en estas fichas será incompleta, parcial, no verificada, respondiendo posiblemente al punto de vista o intereses de ciertos clientes o usuarios. Es por ello, que en esta etapa, dicha información debe ser evaluada y chequeada para determinar su relevancia y oportunidad frente a los objetivos del software y en función del conocimiento adquirido del negocio.

Elicitar información sobre lo futuro: necesidades, deseos y dificultades actuales de los clientes y usuarios. Se utiliza como principales técnicas de elicitación: entrevistas estructuradas, cuestionarios y lectura de documentación. Las preguntas básicas se pueden resumir en:

¿Qué espera? ¿Por qué? ¿Qué necesita? ¿Por qué? ¿Qué desearía? ¿Por qué?

¿Qué problemas / dificultades advierte?

Esta información elicitada puede volcarse en las Fichas de Información Anticipada para tener la información más organizada y facilitar su uso, o puede modelarse directamente en los EF.

Elaborar propuestas de requisitos que los ingenieros de requisitos presentan a los clientes y usuarios. Dependiendo de la complejidad o alcance de la propuesta, ésta puede presentarse directamente a los clientes y usuarios, o puede exhibirse a través de uno o más EF. En esta actividad se emplea la introspección como técnica de elicitación.

Revisar el LEL buscando oraciones tanto en las nociones como en los impactos de los símbolos que presenten un punto de vista formal. Retornando al UdeD, se debe determinar si dichas sentencias deben cumplirse en el futuro. En tal caso debe incluirse dicha información en los EF.

Negociar ciertos aspectos del software cuyas decisiones son incorporadas a los EF. La negociación permite discutir y resolver conflictos de requisitos y establecer compromisos entre los involucrados. Durante la evaluación de la información contenida en las Fichas de Información Anticipada, los ingenieros de requisitos detectan contradicciones, las que deben presentarse a los involucrados para su discusión y resolución; en otros casos, la información contenida en dichas fichas debe ser confirmada mediante acuerdo. En la mayoría de los casos, la detección de contradicciones, omisiones u otros inconvenientes ocurre al describir los EF. Entonces, la negociación ocurre frente a descripciones de situaciones que son más fáciles de visualizar por los usuarios y, por lo tanto, se facilita la discusión.

La negociación no sólo ocurre por conflictos en los requisitos sino también para evaluar las propuestas de los ingenieros de requisitos frente a determinadas situaciones. Estas propuestas pueden o no estar en conflicto con los requerimientos de los usuarios.

Las reuniones son el modo más efectivo para negociar requisitos y resolver conflictos acerca de los mismos.

Los ingenieros de requisitos encuentran contradicciones, omisiones y superposiciones, y llevan a cabo reuniones con clientes y usuarios que pueden ayudar a resolverlos.

La reunión se suele dividir en tres etapas y consiste en:

i) Una etapa informativa: se explican los problemas asociados con un EF.

ii) Una etapa de discusión: los involucrados discuten cómo resolver el

conflicto. En esta etapa se pueden dar prioridades a los EF3_{. Esto ayuda}

a decidir qué requerimientos serán eliminados (no serán requisitos del software) y cuáles se incluirán en la especificación del sistema, es decir, serán parte del EF.

iii) Una etapa de resolución: se acuerdan acciones a tomar sobre los EF. Las acciones pueden ser:

Ö eliminar un EF,

Ö sugerir modificaciones específicas a un EF, o Ö elicitar más información acerca del EF.

Generar distintas soluciones alternativas, es decir, se construyen distintos conjuntos de EF, o dentro de un único conjunto de EF se presentan alternativas para una o más situaciones particulares. Para ello se basan en distintas propuestas realizadas por ellos mismos, o distintos puntos de vista presentados por los usuarios. Entre las alternativas que se pueden presentar, están por ejemplos distintas maneras de operacionalizar RNF. Durante la descripción de los EF se aplican las mismas heurísticas de descripción indicadas para los EA, haciendo la siguiente salvedad respecto al uso del vocabulario descripto en el LEL:

9 Escribir las oraciones maximizando el uso de símbolos del léxico

siempre que esto sea posible.

9 Los Actores y Recursos deben ser preferentemente símbolos del

léxico, de ser posible.

3_{Se pueden dar prioridades a los EF o posteriormente priorizar por requisito individual}

Esta salvedad se debe a que en la descripción de los EF pueden surgir términos nuevos debido a nuevas actividades, nuevas acciones, nuevos recursos, nuevos roles, nuevas condiciones; o pueden no usarse símbolos del LEL por ser obsoletos o carentes de sentido en el contexto una vez que éste haya evolucionado. También puede ocurrir que un término permanezca pero con la noción ligeramente actualizada y probablemente el impacto totalmente alterado, pero manteniendo el significado conceptual. En base a estas consideraciones, debemos hacer notar, que es casi inevitable que el vocabulario del UdeD evolucione junto con la evolución del UdeD mismo.

Por otro lado, se adicionan las siguientes recomendaciones:

9 Describir el qué se deberá hacer, evitar al máximo el cómo se deberá

hacer.

9 Evitar incorporar aspectos de diseño, salvo preferencias explícitas de

los clientes y usuarios.

Durante esta actividad deben elicitarse RNF del software. Inicialmente, se determinará aquellos RNF que pueden y deben convertirse en acciones del sistema, convirtiéndose en uno o varios RF (operacionalizaciones). Los RNF que persisten como tales se incorporarán como restricciones en los episodios donde interviene el actor sistema de software, y aquellos de carácter más general (no aplicables a un escenario o episodio de escenario) se podrán incorporar a las Fichas de Información Anticipada para ser tenidos en cuenta en la cuarta etapa de la estrategia. Si se hubiese optado por no realizar la cuarta etapa, se sugiere describir estos RNF como un agregado en el escenario integrador de mayor nivel, o en aquel escenario integrador que tuviera relación directa con cada RNF. Básicamente debe cuestionarse en los

In document Ingeniería de Software V Ingeniería de requerimientos Estrategia en la Ingeniería de Requisitos PARTE 2 (página 46-60)