Ingeniería de Requisitos Modelo de ciclo de vida prototipado FINAL

Universidad Nacional de la Matanza Proceso Software Grupo 4

Ingeniería en Informática

Procesos de SoftwareGrupo 4

Proceso SW Prototipado Evolutivo con Ingeniería de requisitos

DOCENTES:

Apellido NombreHadad Graciela

Sanabria Rosa Beatriz

INTEGRANTES:

AlumnosApellido Nombre DNI

Perez Massatti Pablo 31.176.540Napoli Valeria 31.049.256

Página 1 de 23


Índice.

Índice.................................................................................................................................2Ingeniería de Requisitos aplicada a Ciclos de vida prototipados......................................3

1. Introducción:..........................................................................................................32. Ingeniería de requisitos..........................................................................................33. Modelo de ciclo de vida prototipado.....................................................................6

a. ¿Qué es un prototipo?........................................................................................6b. Prototipo como ciclo de vida.............................................................................6Fortalezas:..................................................................................................................6Debilidades:...............................................................................................................7

4. Utilización de la Ingeniería de requisitos en el modelo de ciclo de vida prototipado.....................................................................................................................9

Modelo A.........................................................................................................................11Pasos Modelo A...........................................................................................................11

1. Construcción de la Lista Preliminar de Requisitos..........................................112. Iteración 1 a N del proceso prototipado Evolutivo..........................................123. Finalización del Proceso SW...........................................................................12

Análisis Modelo A.......................................................................................................12Modelo B.........................................................................................................................14

Pasos Modelo B...........................................................................................................141. Construcción de la Lista Preliminar de Requisitos..........................................142. Iteración 1 a N del proceso prototipado Evolutivo..........................................153. Finalización del Proceso SW...........................................................................15

Análisis Modelo B.......................................................................................................15Modelo C.........................................................................................................................17Modelo C.........................................................................................................................18

Pasos Modelo C...........................................................................................................181. Construcción de la Lista Preliminar de Requisitos..........................................182. Iteración 1 a N del proceso prototipado Evolutivo..........................................183. Finalización del Proceso SW...........................................................................19

Análisis Modelo C.......................................................................................................19Conclusión.......................................................................................................................21Bibliografía:.....................................................................................................................22

Página 2 de 23


Ingeniería de Requisitos aplicada a Ciclos de vida prototipados

Página 3 de 23


1. Introducción:Estudios realizados muestran que la

mayoría de proyectos de Software

fracasan por no realizar un estudio

previo de requisitos.

Con este trabajo se pretende:

Resaltar la importancia de la

ingeniería de requisitos dentro del

ciclo de vida de desarrollo.

Mostrar como aplicar la

ingeniería de requisitos al ciclo de

vida prototipado evolutivo.

En primer lugar se presentará un marco

teórico sobre la ingeniería de

requisitos, en segundo lugar se

presentará un marco teórico para el

ciclo de vida de desarrollo prototipado

evolutivo, y por último se relacionarán

ambos conceptos.

2. Ingeniería de requisitos.

“Yo se que usted piensa que entiende

lo que digo, pero lo que usted no

entiende es que lo que digo no es

realmente lo que quiero decir”

Ralph Young.

Todos lo que trabajamos en el

desarrollo software tenemos

dificultades cuando tratamos de

obtener requisitos de nuestros clientes

o usuarios, tenemos problemas para

comprender la información que

adquirimos.

Un enfoque para solucionar estos

problemas es brindado por la

ingeniería de requisitos.

“La ingeniería de requisitos es un

proceso que comprende todas las

actividades requeridas para crear y

mantener un documento de requisitos

del sistema. Existen cuatro actividades

genéricas de alto nivel en este

proceso. Estas son estudio de

factibilidad del sistema, la obtención y

análisis de los requisitos, la

especificación y documentación, y

finalmente la validación”.

Ian Sommerville (1998).

El modelo de ingeniería de requisitos a

utilizar en nuestra propuesta, propone

realizar el proceso de requisitos en

tres etapas, las cuales se encuentran

descriptas en la siguiente figura 2:

Página 4 de 23


Figura 2 – Etapas del proceso de

Ingeniería de requisitos.

La confección del documento LEL

(Léxico extendido del lenguaje) se

realiza para comprender el Universo de

discurso actual del cliente.

El LEL representa los símbolos

(palabras o frases) relevantes del

dominio de la aplicación. Cada uno de

los símbolos es descrito mediante

noción e impacto. La noción es la

descripción del símbolo, la cual debe

ser expresada con referencias a otros

símbolos y usando un vocabulario

mínimo. El impacto identifica la relación

con los demás símbolos del LEL.

Los símbolos se clasifican en cuatro

tipos, de acuerdo al uso general del

Universo de discurso, los cuales son:

Objeto – Verbo – Sujeto – Estado.

En la descripción de los símbolos se

deben cumplir dos principios, los cuales

son [1]:

Principio de circularidad: los

símbolos deben definirse

utilizando al máximo otros

símbolos del LEL.

Principio de vocabulario

mínimo: los símbolos deben

definirse utilizando un conjunto

restringido y predeterminado de

términos del lenguaje natural no

pertenecientes al LEL.

Adicionalmente de la confección del

LEL, se desarrollan los Escenarios

Actuales, los cuales se construyen

utilizando el lenguaje natural con un

mínimo de formalismo. Estos

escenarios representan situaciones

que ocurren en el Universo de

Discurso actual.

El proceso de construcción de los

Escenarios Actuales comienza con

una primera versión de los escenarios

que surgen del LEL, para esto se

realizan varias actividades, las cuales

se nombran a continuación [1]:

Identificar Símbolos.

Clasificar Símbolos.

Describir Símbolos, aquí

contaremos con el LEL (Léxico

Extendido del Lenguaje) que

debe verificarse y validarse.

Derivar, se generan los

escenarios candidatos desde la

Página 5 de 23


información que proporciona el

LEL.

Describir, se completan los

escenarios candidatos

agregando información del

Universo de Discurso actual.

Organizar, se generan los

escenarios integradores, con el

propósito de hacer que el

conjunto de escenarios sea más

compresible y manejable.

Verificar, se realizan un proceso

de inspección de escenarios, el

cual se lleva a cabo luego de la

actividad “Derivar” y nuevamente

luego de la actividad

“Organizar”.

Validar, se realizan entrevistas

con el cliente /usuario, para que

valide si los escenarios

obtenidos son correctos.

Los Escenarios Futuros se

confeccionan para comprender el

Universo de discurso futuro, cuya

principal característica es la presencia

del sistema de software como nuevo

actor.

Estos escenarios tienen una relación

muy cercana a los escenarios actuales,

ya que se están refiriendo al mismo

universo de discurso sobre el que se

conjeturan modificaciones como se

muestran en la figura 3 [1]:

Figura 3 – Abstracción y concreción en

la construcción de Escenarios Futuros.

La obtención de los requisitos del

sistema se efectúa en base al

conocimiento adquirido en las dos

etapas anteriores.

El modelo propone una heurística para

partiendo del LEL llegar a una lista de

requisitos donde intervienen los

elementos antes mencionados

(Escenarios actuales y futuros).

Para dar una visión global de la

aplicación suelen organizarse los

escenarios en una jerarquía a través

de escenarios integradores. A esta

actividad se la llama integración de

escenarios, siendo parte del proceso

llamado organizar.

El modelo también propone utilizar una

plantilla para ir incorporando

Página 6 de 23


información extemporánea. Esto es,

información que si bien es útil, al

momento de recibirla no se está en la

fase del proceso en la cual debe

incorporarse a un documento formal del

modelo. [1]

3. Modelo de ciclo de vida

prototipado.

a. ¿Qué es un prototipo?

Un prototipo es un modelo o maqueta del sistema que se construye para comprender mejor el problema y sus posibles soluciones:

Evaluar mejor los requisitos.

Probar opciones de diseño

b. Prototipo como ciclo de

vida.

El modelo de ciclo de vida

prototipado se desarrolla a base de

incrementos de acuerdo a la

realimentación y los requisitos

detectados en sus versiones. El

prototipo es un prototipo evolutivo,

esto implica que no se desecha,

que a diferencia del resto de los

prototipos que solo se utilizan como

herramientas en el ciclo de vida.

El prototipo evolutivo constituye un

modelo de ciclo de vida de software

en si mismo.

Se inicia desarrollando los

aspectos mas visibles del sistema,

puede presentar la parte del

sistema al cliente y entonces

continuar el desarrollo del prototipo

basándose en la realimentación

que recibe.

El prototipado evolutivo se utiliza

especialmente cuando los

requerimientos cambian con

rapidez, cuando el usuario no

puede especificar el conjunto de

requisitos o cuando tanto el equipo

de desarrollo como el usuario no

identifican de forma apropiada el

área de aplicación.

Fortalezas:

Progreso tangible, ya que se

generan signos visibles del

progreso que se pueden

utilizar especialmente

cuando existe una gran

Página 7 de 23


demanda en la velocidad de

desarrollo.

Disminución de los riesgos

debido a la mejor

interpretación de las

funcionalidades requeridas.

Los cambios iniciales durante

el desarrollo de un proyecto

son menos costosos que si

se realizan en etapas tardías,

como el prototipo puede

cambiar varias veces, la

flexibilidad y adaptabilidad

son su esencia, la pauta del

cambio la da la

retroalimentación, la cual

permite al equipo de

desarrollo conocer la opinión

del usuario sobre cambios a

la entrada o salida de un

proceso.

Debilidades:

Al comienzo del proyecto es

imposible conocer lo que se

tardará en crear un producto

aceptable (se puede convertir en

codificar y corregir).

Pueden surgir cambios

imprevistos que retrasan el

progreso del prototipo.

El prototipado evolutivo puede

contribuir a aumentar las

dificultades para el

mantenimiento.

Etapas del proceso Prototipado

Evolutivo:

1. Factibilidad (FAC)

2. Definición de requisitos del sistema

(RES)

3. Especificación de los requisitos del

prototipo (REP)

4. Diseño del prototipo (DPR)

5. Diseño detallado el prototipo (DDP)

6. Desarrollo del prototipo

(codificación) (DEP)

7. Implementación y prueba del

prototipo (IPP) Refinamiento iterativo

de las especificaciones del

prototipo (aumentando el objetivo y/o

el alcance). Luego, se puede volver a

la etapa 2 o continuar

si se logró el objetivo y alcance

deseados. (RIT)

8. Diseño del sistema final (DSF)

9. Implementación del sistema final

(ISF)

10. Operación y mantenimiento (OPM)

11. Retiro (si corresponde) (RET)

Página 8 de 23


Página 9 de 23

Estudio de Factibilidad

Lista Preliminar de Requisitos

Especificación del

Prototipo

Diseño del Prototipo

Diseño detallado

de Prototipo

Construcción y

Prueba del Prototipo

Especificación del Prototipo

Sistema Final


4. Utilización de la Ingeniería de requisitos en el modelo de ciclo de vida prototipado.

INTRODUCCION

Para comenzar el proceso de SW

prototipado evolutivo, necesitamos en

primera instancia una Lista de

Requisitos (seguramente no muy

precisa) para tomar de allí los

requisitos mejor entendidos y luego

comenzar a construir la especificación

de Requisito Prototipado para luego

proseguir con las etapas posteriores de

dicho proceso. Pero para definir

nuestra lista Preliminar de Requisitos,

nos ayudaremos con la Ingeniería de

Requisitos, la cual nos brindará en

primera instancia la nuestra lista

preliminar, para luego acoplarse a

nuestro proceso de Prototipado

evolutivo y obtener así al final del

proyecto, un sistema funcional y una

lista detallada de los requisitos que

cumple dicho sistema (además de los

documentos necesarios en la Ing. De

Requisitos para la construcción de esta

lista) (Ver Figura 2)

PASOS

1- Construcción de la Lista

Preliminar de Requisitos

Luego de utilizar todas nuestras

posibles fuentes de información

(reuniones con los usuarios expertos,

manuales de procedimiento,

formularios de operación, etc)

debemos confeccionar nuestra primera

lista de símbolos, los cuales

clasificaremos y describiremos. Dicha

lista de símbolos, mediante los pasos

que nos provee la Ing. de Requisitos

confeccionaremos la Lista de

Escenarios Actuales.

Junto con la información estratégica

que motiva la construcción del sistema

en cuestión, construiremos la lista de

Escenarios Futuros. La cual nos

derivará en nuestra lista de requisitos

Preliminar, la cuál será el input para el

proceso SW de prototipado Evolutivo.

2- Iteración 1 a N del proceso

prototipado Evolutivo

Una vez que tenemos nuestra lista de

requisitos preliminar, empezamos a

realizar los pasos de construcción que

plantea el proceso en sí, pero al final

de la etapa “Refinamiento del

Prototipo”, debemos ocuparnos del

Página 10 de 23


mantenimiento de nuestra Lista de

Requisitos.

Estas implicancias, pueden ser la

Eliminación/Modificación/Alta de un

Escenarios Futuro y por ende en

nuestra lista de Requisitos. Cabe

destacar que por cada iteración del

Proceso de SW prototipado Evolutivo

obtendremos una nueva versión de

nuestra lista de Requisitos. Puede

ocurrir que una iteración de nuestro

proceso de SW no arroje ninguna

modificación en nuestra lista, dado que

alguna de las versiones anteriores

definió correctamente el grupo de

requisitos que estuvieron involucrados

en esta iteración.

3- Finalización del Proceso SW

Cuando finalicemos el proceso de

construcción de prototipos, nos

encontraremos que el prototipo final

cumple con todos los requisitos que

están detallados en nuestra lista de

Requisitos que fue definida con

Ingeniería de Requisitos (junto con

todos sus artefactos intermedios)

Página 11 de 23


Modelo A

A continuación expondremos la versión más extrema de esta combinación de

procesos, la cual incluye todas las tareas de Ingeniería de Requisitos y todas las

etapas del Prototipado Evolutivo, reflejando el enfoque bottom-up para la

determinación de la lista de requisitos preliminar. (Figura 2)

Pasos Modelo A.

1. Construcción de la Lista Preliminar de Requisitos

Tal como fue explicado en el marco teórico el primer paso en el proceso de

ingeniería de requisitos es definir el ámbito y la naturaleza del problema, y

comenzar con la obtención de la información necesaria para definir las

necesidades de los usuarios / clientes, para ello es necesario identificar y explotar

todas las posibles fuentes de información (reuniones con los usuarios expertos,

manuales de procedimiento, formularios de operación, etc).

Acorde a la metodología presentada en este informe con la información recopilada

se debe confeccionar una primera lista de símbolos, los cuales deberán ser

clasificados y descriptos, dando origen al Léxico Extendido del lenguaje (LEL).

La lista de símbolos obtenida, deberá ser utilizada para confeccionar la Lista de

Escenarios Actuales generando los escenarios candidatos mediante la información

que proporciona el LEL, los escenarios actuales representan la visión del universo

de discurso actual, por ende la información correspondiente a cada escenario se

deberá completar con la información proporcionada por el LEL junto a la

información recopilada de las distintas fuentes de información que hayamos

identificado.

Junto con la información estratégica, que motiva la construcción del sistema en

cuestión, y a partir de los escenarios actuales, construiremos la lista de Escenarios

Futuros. Los escenarios Futuros se derivan de los escenarios actuales y se

construyen con el fin de conocer el universo de discurso futuro.

Página 12 de 23


A partir de los escenarios futuros obtenidos derivaremos en la lista de requisitos

Preliminar. Tal como lo establece el proceso de ingeniería de requisitos formal, esta

lista será el input para el proceso SW de prototipado Evolutivo.

2. Iteración 1 a N del proceso prototipado Evolutivo

Una vez obtenida la lista de requisitos preliminar, el siguiente paso es comenzar

con los pasos para la construcción que plantea el proceso prototipazo evolutivo que

hemos propuesto (Figura 1), al final de la etapa “Refinamiento del Prototipo”, se

deberá realizar una actividad a fines de mantener la Lista de Requisitos, dicho

mantenimiento puede implicar la Eliminación/Modificación/Alta de un símbolo del

LEL y de los Escenarios Futuros y por ende la lista de Requisitos se verá también

afectada.

Cabe destacar que por cada iteración del Proceso de SW prototipado Evolutivo

obtendremos una nueva versión de la lista de Requisitos. Puede ocurrir que una

iteración del proceso de SW no arroje ninguna modificación en la lista, esto se

debe a que alguna de las versiones anteriores definió correctamente el grupo de

requisitos que estuvieron involucrados en esta iteración.

3. Finalización del Proceso SW

Al finalizar el proceso de construcción de prototipos mediante el modelo aquí

expuesto, el prototipo final cumplirá con todos los requisitos detallados en la lista de

Requisitos que fue obtenida mediante el proceso de Ingeniería de Requisitos (junto

con todos sus artefactos intermedios actualizados LEL, Escenarios Futuros, Lista

de Requisitos).

Análisis Modelo A.

Al analizar las etapas que se proponen, podemos extraer las siguientes

conclusiones:

Página 13 de 23


¿Para qué realizar todas las etapas de la Ingeniería de Requisitos para

llegar a una lista preliminar de Requisitos? El procedimiento detallado para

la construcción de la lista de Requisitos da origen a una lista mucho más que

preliminar.

¿Por qué construir una lista de escenarios actuales? si luego la desecharé.

¿Para qué mantener actualizado el LEL? si lo único que me interesa es

tener una completa y detallada lista de Requisitos al final del Proceso.

Consideramos que este modelo tiene como principal desventaja el tiempo que se

necesita insumir en la ingeniería de requisitos ya que utilizando este procedimiento

formal la ingeniería de requisitos llevará muchísimo más tiempo que el que se

utilizaría para desarrollar el sistema solo con Prototipado Evolutivo, si utilizamos

este procedimiento no sería necesario utilizar un prototipado y que seria mas

conveniente utilizar un proceso que se base en una mejor definición de requisitos.

Estas cuestiones enunciadas son válidas, lo que nos lleva a pensar que tal vez no

sea la mejor opción práctica para llevar esta combinación, pero servirá como base

para presentar una serie de variantes que resuelven en parte alguna de las

problemáticas enunciadas.

Página 14 de 23

Primera Lista de Símbolos


Primer LEL

Clasificar y describir

Primeras Reuniones con los usuarios, documentos, manuales de procedimientos, etc

Describir

Verificar y Validar


Agregado/Modif. Eliminación de Símbolos

Mantenimiento del LEL

Actualización/Creación de

Escenarios Futuros

Construcción Escenarios Actuales

Construcción Escenarios Futuros

Identificar Símbolos


Diseño detallado

del Prototipo

Construcción y Prueba

del Prototipo

Refinamiento del prototipo

Sistema Final LEL Completo y actualizado

Lista de Requisitos Final

Actualizar Lista de

Requisitos


Derivar Escenario

s

Derivar

Modelo B

A continuación expondremos una versión que deriva de la alternativa A, la cual

elimina alguna de las tareas que propone la Ing. de Requisitos y cuenta con todas

las etapas del Prototipado Evolutivo.

En esta propuesta utilizaremos el enfoque Top-Down para la determinación de la

lista de requisitos preliminar. (Figura 3)

Pasos Modelo B.

1. Construcción de la Lista Preliminar de Requisitos

Luego del análisis de las diferentes fuentes de información confeccionaremos

nuestra primera lista de símbolos, los cuales clasificaremos y describiremos, dando

origen al primer LEL.

El LEL describe el universo de discurso actual y será utilizado por los

desarrolladores para construir una visión global del problema, materializándolo en

uno o más escenarios actuales generales, los cuales ayudarán a tener una primera

idea del macrosistema a desarrollar.

Construiremos los escenarios actuales generales con un enfoque top down,

armando uno o pocos escenarios que representen todo el sistema, estos

escenarios actuales generales se derivarán desde el LEL, sin ahondar en cada

detalle de la funcionalidad del sistema, puesto que son generales, sino basandose

en las ideas generales al conocimiento detallado en el LEL.

Utilizar los escenarios actuales generales permite tener una visión global del

sistema, y un estado de la situación actual.

Para la construcción de los escenarios futuros generales utilizaremos un enfoque

middle – out en bloque, este enfoque proporciona una independencia de los

escenarios actuales generales para la construcción de los escenarios futuros

generales, no realizando el proceso de derivación entre ambos.

A partir de la elicitación de situaciones futuras el ingeniero de requisitos tendrá la

libertad de explotar su creatividad, experiencia y conocimientos dando un valor

agregado al desarrollo.

De cada uno de los episodios mencionados en los escenarios futuros generales

construiremos nuestra lista de requisitos preliminares.


Una vez obtenida la lista de requisitos preliminar, el siguiente paso es comenzar

con los pasos para la construcción que plantea el proceso prototipazo evolutivo que

hemos propuesto (Figura 2), al final de la etapa “Refinamiento del Prototipo”,

debemos ocuparnos del mantenimiento de nuestra Lista de Requisitos.

Dicho mantenimiento puede implicar la Eliminación/Modificación/Alta de la lista de

Requisitos. Cabe destacar que por cada iteración del Proceso de SW prototipado

Evolutivo obtendremos una nueva versión de nuestra lista de Requisitos. Puede

ocurrir que una iteración de nuestro proceso de SW no arroje ninguna modificación

en la lista, esto se debe a que alguna de las versiones anteriores definió

correctamente el grupo de requisitos que estuvieron involucrados en esta iteración.


Cuando finalicemos el proceso de construcción de prototipos, el prototipo final

cumplirá con todos los requisitos del sistema.

Análisis Modelo B.

Utilizando este modelo es posible obtener una lista preliminar de requisitos

suficiente para comenzar el proceso de software prototipado evolutivo.

Realizar el procedimiento de la ingeniería de requisitos es importante porque es la

herramienta que brinda al equipo de desarrollo la posibilidad de entender lo que el

cliente / usuario quiere, ayudará a comprender mejor el problema que sobre cuya

solución se trabajará.

Este modelo implica mantener la lista de requisitos actualizada, esto es de suma

importancia ya que los requisitos de un sistema no son aislados entre si y es

necesario tener actualizados los cambios y modificaciones a fines de

documentación y mantenimiento de la rastreabilidad que permitirá entender como

un cambio en un requisito afectará a distintos aspectos del sistema, esta

rastreabilidad se puede mantener a través de una tabla que muestre la manera en

que los requisitos se relacionan con las distintas características del sistema

observables para el cliente.

Como principal ventaja de este modelo para la obtención de la lista preliminar de

requisitos destacamos la no derivación propuesta de los escenarios actuales

generales a los escenarios futuros generales ya que consideramos que proporciona

la ventaja de no influenciar negativamente la construcción del nuevo sistema con el

sistema actual, dando la posibilidad de que la experiencia del equipo de desarrollo

pueda mejorar el proceso de negocio tratado.

La principal desventaja de esta metodología propuesta para la obtención de la lista

preliminar de requisitos es que la técnica middle - out basa en la construcción inicial

de escenarios futuros a un nivel medio de especificidad, que en nuestra propuesta

no continuamos refinando, esto seguramente producirá una lista preliminar de

requisitos menos rica que la obtenida en comparación al proceso formal expuesto

en el modelo A, pero consideramos que dado que el modelo de proceso SW que

estamos utilizando es el prototipado evolutivo, esta falencia se ve atenuada porque

en las distintas iteraciones de la construcción del prototipo iremos refinando los

requisitos y actualizando la lista.

Primeras Reuniones con los usuarios, documentos, manuales de procedimientos, etc

Primer LEL


Construcción Escenarios actuales

Generales


Primera Lista de Símbolos



Generales



Diseño detallado del

Prototipo


del Prototipo


Sistema Final Lista de Requisitos

Final

Actualizar Lista de

Requisitos


Modelo CA continuación expondremos una versión que deriva de la alternativa A, la cual

elimina alguna de las tareas que propone la Ing. de Requisitos y algunas de las

etapas del Prototipado Evolutivo. (Figura 4)

En esta propuesta utilizaremos el enfoque Middle-Out para la especificación del

Prototipo. (Figura 3)

Pasos Modelo C.

1. Construcción de la Especificación de Prototipo

Luego de explotar todas nuestras posibles fuentes de información (reuniones con

los usuarios expertos, manuales de procedimiento, formularios de operación, etc)

debemos confeccionar la primer lista de símbolos, los cuales deberán clasificarse y

describirse, dando origen al primer LEL.

El LEL describe el universo de discurso actual y será utilizado por los

desarrolladores para construir una visión global del problema, materializándolo en

uno o más escenarios actuales, los cuales ayudarán a tener una visión del universo

de discurso actual y una idea del sistema a desarrollar.

A partir de los escenarios actuales obtenidos, mediante una estrategia incremental

proponemos la construcción de los escenarios futuros, esta estrategia consiste en

transformaciones sucesivas de los escenarios actuales hacia los escenarios

futuros, así como lo propone el proceso de Ing. de Requisitos.

Tomaremos los escenarios futuros como input al modelo de proceso SW

prototipado evolutivo construyendo los prototipos en base a los escenarios futuros.

Entonces cada prototipo a desarrollar deberá representar una o más

funcionalidades descriptas en cada uno de los Episodios de los escenarios futuros

realizados.


A partir de los escenarios futuros se ejecutarán los pasos de construcción que

plantea el proceso de prototipado evolutivo (Figura 1).

Al final de la etapa “Refinamiento del Prototipo”, se deberá realizar el

mantenimiento de los escenarios futuros. Dicho mantenimiento puede implicar la

Eliminación/Modificación/Alta del / los escenarios que han dado origen al prototipo.

Por cada iteración del Proceso de SW prototipado Evolutivo podremos obtener una

nueva versión de los escenarios futuros especificados, o por el contrario puede

ocurrir que una iteración de nuestro proceso de SW no arroje ninguna modificación,

esto se debe a que alguna de las versiones anteriores definió correctamente el

grupo de funcionalidades abarcadas en cada uno de los escenarios.


Cuando finalicemos el proceso de construcción de prototipos, nos encontraremos

que el prototipo final cumple con todos las funcionalidades del sistema

representadas en los escenarios futuros.

Análisis Modelo C.

La alternativa expuesta en el presente modelo, elimina el paso en el que se obtiene

la lista preliminar de requisitos a partir de los escenarios futuros, y propone

comenzar con la especificación de los prototipos a partir de los escenarios futuros.

Consideramos que la elaboración y evolución del prototipo a partir de los

escenarios futuros presenta la ventaja de construir un prototipo inicial con toda la

información contenida en el escenario futuro, que generalmente abarca mas de un

requisito y que generará como resultado un prototipo inicial que abarque mas

funcionalidades que el que se obtendría de un único requisito, derivado a partir del

escenario futuro.

La desventaja que encontramos en esta propuesta es que es más compleja la

mantenibilidad de los escenarios luego de cada iteración, en comparación al

mantenimiento de la lista de requisitos.

Primeras Reuniones con los usuarios, documentos, manuales de procedimientos, etc Primer LEL


Lista Preliminar

de RequisitosPrimera Lista de Símbolos




Diseño detallado del

Prototipo


del Prototipo


Sistema Final

Actualizar Escenarios futuros


Construcción Escenarios Actuales

Derivar Escenarios


Conclusión.

Cabe destacar que realizar un profundo análisis de requisitos va en

contrapartida a la utilización de un proceso prototipado evolutivo, dado que si

estuviesen detallados todos los requisitos del sistema, nos convendría la

utilización de un proceso en cascada/ cascada en V u otro que se base en una

lista mas firme de requisitos, sin embargo la obtención de los requisitos es la

base del desarrollo del SW por lo cual no se puede eliminar completamente

este proceso, por ello lo que intenta establecer este documento, es una

alternativa de aplicación acotada de Ingeniería de Requisitos aplicada a un

modelo SW Prototipado Evolutivo para obtener una base más firme para el

desarrollo con dicho proceso a un costo / beneficio positivo.

Al utilizar Ingeniería de Requisitos podemos tener una perspectiva mucho más

clara de los requerimientos del sistema, pudiendo realizar iteraciones más

cortas e involucrar mayor cantidad de requisitos por cada una. Llegando a la

reducción significativa de los tiempos de desarrollo.

Bibliografía:Ingeniería del software. Un enfoque práctico. Pressman sexta edición.

http://members.fortunecity.es/hotdug/index2.htm

Centro de Investigación para la Sociedad de la Información - Quito-Ecuador

http://www.imaginar.org/iicd/tus_archivos/LLL/docs/5_laboratorios.pdf

Grupo Web de Agentes Inteligentes - Universidad de Vigo - España

http://dellgwai.ei.uvigo.es/~jcmoreno/AR-BOT/002_2.html

Departamento de Ingeniería Informática y Ciencias de la Computación –

Universidad de Concepción - Chile

http://www.inf.udec.cl/~revista/ediciones/edicion13/articulo%2013-4.pdf

Enfoque Middle-Out en la Construcción e Integración de

Escenarios. Graciela D. S. Hadad1 , Jorge H. Doorn2 , Gladys N. Kaplan3 ,

Julio Cesar Sampaio do Prado Leite.

Comprendiendo el Universo de Discurso Futuro con

Escenarios. Jorge H. Doorn, Graciela D.S. Hadad, Gladys N. Kaplan.

http://www.inf.udec.cl/~revista/ediciones/edicion13/articulo%2013-4.pdf

http://dellgwai.ei.uvigo.es/~jcmoreno/AR-BOT/002_2.html

http://www.imaginar.org/iicd/tus_archivos/LLL/docs/5_laboratorios.pdf

http://members.fortunecity.es/hotdug/index2.htm

Ingeniería de Requisitos Modelo de ciclo de vida prototipado FINAL

Documents

Transcript of Ingeniería de Requisitos Modelo de ciclo de vida prototipado FINAL