27/01/09 PROCESOS DE PRODUCCION COMERCIAL

*TRADICIONALES O PESADOS: Son procesos robustos

que exigen demasiada documentación; todo tiene que ser
documentado y soportado, incluso las líneas de código y los
manuales tanto de usuario como del programador. Una gran
ventaja es la de realizar procesos de Re-Ingeniería de forma
rápida y fácil. Existen varios procesos de de producción
tradicionales en los que destacamos los siguientes:
Proceso Unificado de Desarrollo de software (RUP):
Es un proceso de software genérico que puede ser utilizado
para hacer diferentes tipos de software como por ejemplo
área de aplicación, de organizaciones, niveles de
competencia y tamaño, la meta es hacer software de muy
alta calidad para satisfacer las necesidades de los usuarios
dentro de este proceso encontramos a RUP y IBM
M3, Procesos para generar productos con estándares
de calidad: Es una Metodología de Planificación, Desarrollo
y Mantenimiento de Sistemas de Información ofrece a las
Organizaciones un instrumento útil para la sistematización
de las actividades que dan soporte al ciclo de vida del
software.
MSF Microsoft solutions framework: Es un sistema de
modelos, principios y pautas que sirven para dar soluciones
a problemas que se tengan en cuanto al diseño y desarrollo
de los elementos de un proyecto, para que puedan ser
manejados con éxito.

*LIGEROS O EXTREMOS: En este proceso la

documentación es el mismo código; son para software
donde el mismo usuario puede interactuar constantemente
con el programador. Este tipo de proceso esta contemplado
por un manifiesto Ágil que contiene las siguientes normas:
• Nuestra mayor prioridad es satisfacer al cliente a través
de la entrega temprana y continúa de software con valor.
• Aceptamos requisitos cambiantes, incluso en etapas
avanzadas. Los procesos ágiles aprovechan el cambio
para proporcionar ventaja competitiva al cliente.
• Entregamos software frecuentemente, con una
periodicidad desde un par de semanas a un par de
 meses, con preferencia por los periodos más cortos
posibles.
• Los responsables de negocio y los desarrolladores deben
trabajar juntos diariamente a lo largo del proyecto.
• Construimos proyectos con profesionales motivados.
Dándoles el entorno y soporte que necesitan, y confiando
en ellos para que realicen el trabajo.
• El método más eficiente y efectivo de comunicar la
información a un equipo de desarrollo y entre los
miembros del mismo es la conversación cara a cara.
• Software que funciona es la principal medida de
progreso.
• Los procesos ágiles promueven el desarrollo sostenible.
• Esponsores, desarrolladores y usuarios deben ser
capaces de mantener un ritmo constante de forma
indefinida.
• La atención continua a la excelencia técnica y los buenos
diseños mejoran la agilidad.
• Simplicidad, el arte de maximizar la cantidad de trabajo
no realizado, es esencial.
• Las mejores arquitecturas, requisitos y diseños surgen de
equipos que se auto organizan.
• A intervalos regulares el equipo reflexiona sobre cómo
ser más efectivo, entonces mejora y ajusta su
comportamiento de acuerdo a sus conclusiones
También podemos encontrar procesos ligeros tales como:
XP: En esta metodología integra gerentes, clientes y
desarrolladores en la búsqueda de calidad en el software
mejora el proyecto en comunicación, simplicidad,
realimentación y emprendimiento manteniendo el diseño
simple y claro.
MFS Ágil: El proceso MFS ágil se compone de un conjunto
de 14 workstreams. Cada uno gira en torno a un rol
responsable aunque sus actividades constituyentes pueden
involucrar al resto de los miembros
INFOGRAFIA:

• http://iie.fing.edu.uy/~nacho/blandos/seminario/XProg1.h
tml
• http://www.csae.map.es/csi/metrica3/index.html
• http://www.webintenta.com/metrica-3.html
• http://diegumzone.spaces.live.com/blog
• http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
• http://www.softwareguru.com

CAPITULO 4: PROCESOS DEL SOFTWARE

1. Sugiera el modelo del proceso de software genérico que podría

utilizarse para gestionar el desarrollo de los siguientes sistemas, dando
alguna razones basadas en el tipo de sistema a desarrollar.
• Sistema de control anti bloqueo de frenos de un automóvil
Rta. Prototipo evolutivo, es acorde debido a que irán haciendo
sistemas para luego ser probados algo así como prueba y error,
los cuales se irán corrigiendo a medida que evoluciona el sistema
• Sistema de realidad virtual para ayudar al mantenimiento de
software
RTA: Se debe implementar el modelo de Cascada puesto que el
mantenimiento que se le hará al software debe ser explicado de
forma exacta y precisa para corregir los errores y mejorar la
implementación del sistema en cada una de sus faces
• Sistema de contabilidad universitaria que remplace el asistente.
Rta : Debe ser implementado un modelo evolutivo puesto que
partimos de un modelo anterior para implementarlo en un nuevo
y mejorado sistema.
• Sistema interactivo que permita a los pasajeros encontrar los
horarios de los trenes a partir de las terminales instaladas en las
estaciones .
RTA: para este sistema debe ser implementado el modelo
evolutivo debido a que este interactúa directamente con el
usuario para la resolución de dudas
2. Explique porque los programas que se desarrollan utilizando el modelo
evolutivo tienden a ser difíciles de mantener
Rta el modelo evolutivo es difícil de mantener puesto que está en
constante cambio, proporcionarle nuevas herramientas el cual hace
que se actualice concosas mejores cada vez

3. Explique como el modelo en cascada para el proceso de software y el

de la construcción de prototipos pueden encajar en el proceso espiral
Rta:El modelo en cascada es similar en el proceso de espiral ya
que utiliza la misma serie de pasos con una interacción ilimitada
hasta que el producto este completo , el modelo de prototipos de
la misma manera repite las etapas pero el modelo cambia cada vez
que se repite

4. Cuáles son las ventajas de proporcionar vistas estáticas y dinámicas del

proceso de software como el proceso unificado de Rational
• Vista dinámica muestra las faces de modelo sobre el tiempo
 • Vista estatica sugiere buenas practicas a utilizar durante el
proceso

Las ventajas son que la facedel proceso de desarrollo no esta

asociados con flujo de trabajo especifico

5. Explique porque es importante hacer distinción entre el desarrollo de

los requerimientos de usuario y de los requerimientos del sistema en el
proceso de reingeniería de requerimientos

6. Describa las principales actividades en el proceso de diseño de software

y las salidas de estas actividades utilizando un diagrama, muestre las
posibles relaciones entre la salida.
Diseño Arquitectura del
arquitectónico
Especificacion de Especificación Especificación del
requerimientos abstracta software

Diseño de interfaz Especificación de la inter

faz
Diseño de
especificación de
componentes
componentes
Diseño de la estructura de Especificación de estructura
datos de datos
Diseño de Especificación de algoritmos
algoritmo
7. Cuáles son los cinco componentes de un método de diseño? Considere
cualquier método que conozca y describa sus componentes. Evalué la
integridad el método elegido
• Un modelo de objetos que muestra las clases de objetos utilizadas
en el sistema y sus dependencias
• Un modelo de secuencias que muestra cómo interactúan los
objetos en el sistema cuando este se ejecuta
• Un modelo de estado de transición que muestra los estados del
sistema y los disparadores de las transiciones desde un estado a
otro
• Un modelo estructural en el cual se documentan los componentes
del sistema y sus agregaciones
• Un modelo de flujo de datos en el que el sistema se modela
utilizando la transformación de datos en que tiene lugar cuando
se procesan. este no se utiliza frecuentemente en el diseño de
sistemas de tiempo real y de negocio

8. Diseñe un modelo de proceso para las pruebas de ejecución y recopile

los resultados
9. Explique porque un sistema de software que se utiliza en un entorno
real debe cambiar o convertirse progresivamente en menos útil
Rta: un sistema de software es menos útil cada vez en un entorno
real puesto que día a día van saliendo casas nuevas y mejores el cual
hace que este quede por decirlo así atrasado a comparación de estos

10.Indique como la escala de clasificación de la tecnología CASE puede ser

utilizada por los administradores encargados de adquirir sistemas CASE
Rta: La escala de clasificación de la tecnología CASE puede ser
utilizada en planificación, edición , gestión de cambio, construcción
de prototipos apoyo a métodos procesamiento de lenguajes análisis
de programas , pruebas, depuración, documentación, reingeniería.

11.Históricamente, la introducción de tecnología acausado varios cambios

en el método laboral y, al menos temporalmente elimina personas de
los puestos de trabajo. Comente si es probable que la introducción de la
tecnología CASE avanzada pueda tener las mismas consecuencias para
los ingenieros de software. Si piensa que no es así, explique porque no.
Si piensa que reducirá las oportunidades de trabajo ¿es ético para los
ingenieros afectados resistirse pasivamente o activamente a la
introducción de esta tecnología ?
Rta: reducirá las oportunidades de trabajo no me parece ético que los
ingenieros afectados se resistan activamente puesto que la
implementación de esta tecnología es buena .

Taller Nº6 REQUERIMIENTOS DEL SOFTWARE

1. Identifique y comente brevemente cuatro tipos de requerimientos que

se pueden definir para un sistema informático
RTA: funcionales: son los que deben cumplir específicamente una
tarea dentro del sistema y lo que debe hacer, no funcionales:
funciones agregadas al sistema mas no fundamentales, de
usuario: son declaraciones en lenguaje natural y del sistema:
explica las funciones y tareas especificas que cumple el sistemas y
las limitaciones del mismo según los requerimientos del usuario y el
software dado por el programador.

2. Comente los problemas de la utilización del lenguaje natural para

definir los requerimientos del usuario y del sistema, y muestre,
utilizando pequeños ejemplos, como el estructurar el lenguaje natural
en formularios puede ayudar a evitar algunas de estas dificultades.
RTA: falta de claridad, confusión de requerimientos,
conjunción de requerimientos

3. Descubra las ambigüedades u omisiones en la siguiente declaración

de requerimientos de una parte de un sistema expendedor de
billetes.
 Un sistema automático de expedición de billetes vende billetes de
tren. Los usuarios seleccionan su destino e introducen una tarjeta de
crédito y un numerode identificación personal. El billete de tren se
expide y se carga a su cuenta de la tarjeta de crédito. Cuando el
usuario presiona el botón de inicio se activa un menú que muestra los
posibles destinos, junto con un mensaje para el usuario que le indica
que seleccione el destino. Se comprueba su validez y entonces se le
pide introducir un identificador personal. Cuando la transacción de
crédito se haya validado, se expide el billete.
RTA: el sistema no verifica si tiene cupos disponibles, no
precisa que numero de identificación (cedula o clave de
tarjeta), si tiene cupo o línea de crédito para la compra,
repite de forma innecesaria el proceso de compra de otra
forma sin precisar con claridad el proceso. La terminología
utilizada no es la adecuada para explicar este tipo de
procesamiento de información y recolección de datos de un
sistema automatizado.
4. Vuelva a redactar la descripción anterior utilizando el enfoque
estructurado descrito en este capitulo. Resuelva de forma apropiada
las ambigüedades identificadas.
RTA: Un sistema automático de expedición de billetes vende
billetes de tren. Los usuarios seleccionan su destino y verifica
si hay cupos disponibles, hora, día y salida al destino,
diligencia los datos personales en el sistema, introducen una
tarjeta de crédito y clave de verificación y el sistema
diligencia la compra y expide el billete y devuelve la tarjeta.

5. Dibuje un diagrama de sugerencias que muestren las acciones

llevadas a cabo en el sistema expendedor de billetes. Puede hacer
algunas suposiciones razonables sobre el sistema. Ponga especial
atención en la especificación de los errores del usuario
6. Utilizando la técnica sugerida aquí, en la que el lenguaje natural se
presenta en una forma estándar redacte requerimientos del usuario
verosímiles para las siguientes funciones:
• La función de expedición de dinero en un cajero automático de
un banco
• La verificación de ortografía y la función de corrección en un
procesador de texto
• Un sistema de auto servicio de bombas de gasolina que incluye
un lector de tarjetas de crédito. El cliente pasa la tarjeta a
través del lector y especifica la cantidad de combustible
requerido. Este se entrega y se hace el cargo a la cuenta del
cliente.
 Utilizando la técnica sugerida aquí en la que el lenguaje natural se
presenta en una forma estándar, redacte requerimientos del usuario
verosímiles para la siguientes funciones:
• La función de expedición de dinero en un cajero automático de
un banco: Elsistema deberá pedir la tarjeta, la clave, monto
de retiro, tipo de cuenta y así mismo finalizar la acción
desembolsando el dinero.
• La verificación de ortografía y la función de corrección en un
proceso de texto: El sistema debe identificar las palabras
equivocadas, avisando al usuario que es incorrecta y así mismo
suministrando la ayuda de corrección por medio de ortografía y
gramática.
• Un sistema de auto servicio de bombas de gasolina que incluye
un lector de tarjetas de crédito. El cliente pasa la tarjeta
atreves del lector y especifica la cantidad de combustible
requerido. Este se entrega y se hace el cargo a la cuenta del
cliente: El usuario deberá deslizar la tarjeta por el lector,
seguido de esto exigirá la clave, digitara el valor del
combustible requerido, para luego la maquina acceda a darle el
servicio.

7. Describa cuatro tipos de requerimientos no funcionales que pueden

existir en un sistema. De ejemplos de cada uno de estos tipos de
requerimientos.
RTA:

requerimientos del producto: especifica el comportamiento del

producto, ejm: rendimiento en ejecución del sistema, fiabilidad,
portabilidad y usabilidad.
Requerimientos organizacionales: estos requerimientos se
derivan de políticas de procedimientos existentes en la organización
del cliente y en la del desarrollador. Eje: estándares en los procesos
que deben utilizase, requerimientos de implementación (lenguajes de
programación o método de diseño a utilizar).
Requerimientos externos: incluye todos los requerimientos que
se derivan de los factores externos al sistema, y en su proceso de
desarrollo. Eje: el sistema no deberá revelar el personal de la
biblioteca que lo utilice ninguna información personal de los usuarios
del sistema aparte de su nombre y numero de referencia con la
biblioteca

8. Redacte un conjunto de requerimientos no funcionales para el

sistema expendedor de billetes especificando su fiabilidad y su
respuesta en el tiempo.
➢ Impresión de los billetes
 ➢ Código de barras asignado por el sistema para evitar la
falsificación
➢ Entrono grafico
➢ Reserva de cupos
9. Sugiera la manera en que un ingeniero responsable de preparar la
especificacion de requerimientos del sistema podría controlar las
relaciones entre los requerimientos funcionales y no funcionales.

10.Ha obtenido un trabajo con usuario de software quien acontactado a

su anterior compañía para desarrollar un sistema. Usted descubre
que la interpretación de la compañía actual de los requerimientos es
diferente de la tomada por su anterior compañía. Comente que haría
en tal situación. Usted sabe que los costos de su compañía actual se
incrementarían si las ambigüedades no se resuelven. También tiene
una responsabilidad de confidencialidad para su anterior compañía

7.1 Estudios de viabilidad

Para todos los sistemas nuevos, el proceso de ingeniería de

requerimientos debería empezar con un estudio de viabilidad. La
entrada de éste es un conjunto de requerimientos de negocio
preliminares, una descripción resumida del sistema y de cómo éste
pretende contribuir a los procesos del negocio. Los resultados del
estudio de viabilidad deberían ser un informe que recomiende si
merece o no la pena seguir con la ingeniería de requerimientos y el
proceso de desarrollo del sistema.

• Estudio de viabilidad: la evaluación del sistema es útil para el

negocio
• Obtención y análisis: el descubrimiento de los requerimientos
• Especificación: la transformación de estos requerimientos en
formularios estándar
• Validación: la verificación de los requerimientos realmente define
el sistema que requiere el cliente

vez que se tiene la información, se redacta e! informe de! estudio de

viabilidad. Debería hacerse una recomendación sobre si debe continuar o
no el desarrollo del sistema. En el informe, se pueden proponer cambios
en el alcance, el presupuesto y la confección de agendas del sistema y
sugerir requerimientos adicionales de alto nivel para éste.

7.2 Obtención y análisis de requerimientos

La obtención y análisis de requerimientos pueden afectar a varías

personas de la organización. El término stakeholder se utiliza para
referirse a cualquier persona o grupo que se verá afectado por el
sistema, directa o indirectamente. Entre los stakeholders se
encuentran los usuarios finales que interactúan con el sistema y
todos aquellos en la organización que se pueden ver afectados por su
instalación. Otros stakeholders del sistema pueden ser los ingenieros
que desarrollan o dan mantenimiento a otros sistemas relacionados,
los gerentes del negocio, los expertos en el dominio del sistema y los
representantes de los trabajadores.
Obtener y comprender ¡UN requerimientos de os siakehoiders es
difícil por varias razones:
1. Los stakeholders a menudo no conocen lo que desean obtener
del sistema informático excepto en términos muy generales;
puede resultarles difícil expresar lo que quieren que haga el
sistema o pueden hacer demandas irreales debido a que no
conocen el coste de sus peticiones.
2. Los stakeholders expresan los requerimientos con sus propios
términos de forma natural y con un conocimiento implícito de su
propio trabajo. Los ingenieros de requerimientos, sin experiencia
en el dominio del cliente, deben comprender estos
requerimientos.
3. Diferentes stakeholders tienen requerimientos distintos, que
pueden expresar de varias formas. Los ingenieros de
requerimientos tienen que considerar todas las fuentes
potenciales de requerimientos y descubrir las concordancias y
los conflictos.
4. Los factores políticos pueden influir en los requerimientos del
sistema. Por ejemplo, los directivos pueden solicitar
requerimientos específicos del sistema que incrementarán su
influencia en la organización.
5. El entorno económico y de negocios en el que se lleva a cabo el
análisis es dinámico. Inevitablemente, cambia durante el proceso
de análisis. Por lo tanto, la importancia de ciertos requerimientos
puede cambiar. Pueden emerger nuevos requerimientos de
nuevos stakeholders que no habían sido consultados
previamente.
.
Las actividades del proceso son:
1. Descubrimiento de requerimientos, Es el proceso de
interactuar con los stakeholders del sistema para recopilar sus
requerimientos. Los requerimientos del dominio de los
stakeholders y la documentación también se descubren
durante esta actividad.
2. Clasificación y organización de requerimientos. Esta actividad
toma la recopilación no estructurada de requerimientos,
grupos relacionados de requerimientos y los organiza en
grupos coherentes.
3. Ordenación por prioridades y negociación de requerimientos.
Inevitablemente, cuando existen muchos stakeholders
involucrados, los requerimientos entrarán en conflicto. Esta
actividad se refiere a ordenar según las prioridades los
requerimientos, y a encontrar y resolver los requerimientos en
conflicto a través de la negociación.
4. Documentación de requerimientos. Se documentan los
requerimientos y se entra en la siguiente vuelta de la espiral.
 Se pueden producir documentos de requerimientos formales.

7.2.1 Descubrimiento de requerimientos

El descubrimiento de requerimientos es el proceso de recoger

información sobre el sistema propuesto y los existentes y extraer los
requerimientos del usuario y del sistema de esta información. Las
fuentes de información durante la fase del descubrimiento de
requerimientos

Por ejemplo, entre los stakeholders del sistema para un cajero

automático (ATM) de un banco se encuentran:
1. Los clientes actuales del banco quienes reciben los servicios del
sistema
2. Los representantes de otros bancos quienes tienen acuerdos
recíprocos que les permiten utilizar otros ATMs
3. Los directores de las sucursales bancarias quienes obtienen
información del sistema
4. El personal de ventanilla de las sucursales bancarias quienes
están relacionados con el funcionamiento diario del sistema
5. Los administradores de la base de datos quienes son
responsables de integrar el sistema con la base de datos de
clientes del banco
6. Los administradores de seguridad del banco quienes deben
asegurar que el sistema no suponga un riesgo de seguridad
7. Las personas del departamento de marketíng del banco quienes
probablemente están interesadas en utilizar el sistema como un
medio para promocionar al banco
8. Los ingenieros de mantenimiento de hardware y software quienes
son responsables de mantener y actualizar el hardware y el
software
9. Los reguladores de la banca nacional quienes son responsables
de asegurar que el sistema se ajusta a las regulaciones de la
banca

Además de los stakeholders del sistema, ya hemos visto que los

requerimientos pueden venir del dominio de la aplicación y de otros
sistemas que interactúan con el sistema a especificar. Todos éstos se
deben considerar durante el proceso de obtención de requerimientos

Puntos de vista.
Los puntos de vista se pueden utilizar como una forma de clasificar los
stakeholders y otras fuentes de requerimientos. Existen tres tipos
genéricos de puntos de vista:
1. Puntos de vista de los interactuadores: representan a las personas
u otros sistemas que interactúan directamente con el sistema. En
el sistema del ATM del banco, son ejemplos de estos puntos de
 vista los clientes del banco y la base de datos de las cuentas
2. puntos de vista indirectos: representan a los síakehclders que no
utilizan el sistema ellos mismos pero que influyen en los
requerimientos de algún modo. En el sistema del ATM del banco,
son ejemplos de puntos de vista indirectos la gerencia del banco y
el personal de seguridad.
3. Puntos de vista del dominio: representan las características y
restricciones del dominio que influye en los requerimientos del
sistema. En el sistema del ATM del banco, un ejemplo de un punto
de vista del dominio serían los estándares que se han
desarrollado para las comunicaciones interbancarias.
.
La identificación inicial de los puntos de vista que son relevantes a un
sistema a veces puede ser difícil. Para ayudar a este proceso, se debería
intentar identificar tipos de puntos de vista más específicos:
1. Los proveedores de servicios al sistema y los receptores de los
servicios del sistema.
2. Los sistemas que deben interactuar directamente con el sistema a
especificar.
3. Las regulaciones y estándares que se aplican al sistema.
4. Las fuentes de los requerimientos no funcionales y de negocio del
sistema.
5. Los puntos de vista de la ingeniería que reflejan los requerimientos
de las
personas que tienen que desarrollar, administrar y mantener el
sistema.
6. Los puntos de vista del marketing y otros que generan
requerimientos sobre las características del producto esperadas
por los clientes y cómo el sistema debería reflejarla imagen
externa de la organización.

Entrevistas
Las entrevistas formales o informales con ios stakeholders del sistema
son parte de la mayoría de los procesos de la ingeniería de
requerimientos. En estas entrevistas, el equipo de la ingeniería de
requerimientos hace preguntas a los stakeholders sobre el sistema
que utilizan y sobre el sistema a desarrollar. Los requerimientos
provienen de las respuestas a estas preguntas. Las entrevistas pueden
ser de dos tipos:
1. Entrevistas cerradas donde los stakeholders responden a un
conjunto predefinido de preguntas.
2. Entrevistas abiertas donde no hay un programa predefinido. El
equipo de la ingeniería de requerimientos examina una seria de
cuestiones con los stakeholders del sistema y, por lo tanto,
desarrolla una mejor comprensión de sus necesidades.
En la práctica, las entrevistas con los stakeholders normalmente
son una mezcla de éstos. Las respuestas a algunas preguntas
pueden conducir a otras cuestiones que se discuten de una forma
menos estructurada. Las discusiones completamente abiertas
raramente salen bien; la mayoría de las entrevistas requieren
 algunas preguntas para empezar y para mantener la entrevista
centrada en el sistema a desarrollar.

Es difícil obtener conocimiento del dominio durante las entrevistas

debido a dos razones:
• Todos los especialistas de la aplicación utilizan terminología y
jerga específica de un dominio. Es imposible para ellos discutir
requerimientos del dominio sin utilizar esta terminología.
Normalmente la utilizan de un modo preciso y sutil, por lo que
es fácil que la malinterpreten los ingenieros de requerimientos.
• Cierto conocimiento del dominio es tan familiar para los
stakehoders que o lo encuentran difícil de explicar o piensan
que es tan básico que no merece la pena mencionarlo, Por
ejemplo, para un bibliotecario, es evidente que todas las
adquisiciones se catalogan antes de agregarlas a la biblioteca.
Sin embargo, esto puede no
ser obvio para el entrevistado^ por lo que no se tiene en
cuenta en los requerimientos.
Las entrevistas no son una técnica eficaz para obtener conocimiento
sobre los requerimientos y restricciones organizacionales debido a que
existen sutiles poderes e influencias entre los stakeholders en la
organización.

Los entrevistadores eficaces tienen dos características:

1. No tienen prejuicios, evitan ideas preconcebidas sobre los
requerimientos y están dispuestos a escuchar a los stakeholders.
Si el stakeholder propone requerimientos sorprendentes, están
dispuestos a cambiar su opinión del sistema.
2. Instan al entrevistado a empezar las discusiones con una
pregunta, una propuesta de requerimientos o sugiriendo trabajar
juntos en un prototipo del sistema. Decir a la gente «dime lo que
quieres» es improbable que cause información de utilidad. La
mayoría de la gente encuentra mucho más fácil hablar en un
contexto definido en vez de en términos generales.
La información de la entrevistas complementa otras informaciones
sobre el sistema de los documentos, observaciones de los usuarios,
etcétera. Algunas veces, aparte de la información de los documentos,
las entrevistas pueden ser la única fuente de información sobre los
requerimientos del sistema. Sin embargo, las entrevistas por sí
mismas tienden a omitir información esencial, por lo que deberían ser
usadas al lado de otras técnicas de obtención de requerimientos,

Escenarios

Los escenarios pueden ser especialmente útiles para agregar detalle a

un esbozo de la descripción de requerimientos. Son descripciones de
ejemplos de las sesiones de interacción. Cada escenario abarca una o
más posibles interacciones. Se han desarrollado varias formas de
escenarios, cada una de las cuales proporciona diferentes tipos de
información en diferentes niveles de detalle sobre el sistema. Utilizar
escenarios para describir requerimientos es una parte fundamental de
los métodos ágiles, como la programación extrema, que se aborda en
el Capítulo 17
El escenario comienza con un esbozo de la interacción y. durante la
obtención, se agregan detalles para crear una descripción completa de
esta interacción. De forma general, un escenario puede incluir:
1. Una descripción de lo que esperan e! sistema y los usuarios
cuando el escenario comienza.
2. Una descripción del flujo normal de eventos en el escenario.
3. Una descripción de lo que puede ir mal y cómo manejarlo.
4. Información de otras actividades que se podrían llevar a cabo al
mismo tiempo.
5. Una descripción del estado del sistema cuando el escenario
termina.

Es posible llevar a cabo de manera informal la obtención de

requerimientos basada en escenarios cuando los ingenieros de
requerimientos trabajan con los stakeholders en la identificación de
escenarios y en la captura de detalles de dichos escenarios. Los
escenarios se pueden redactar como texto, complementados por
diagramas, fotografías de las pantallas, etcétera. De forma alternativa,
se puede adoptar un enfoque más estructurado, como los escenarios de
evento o los casos de uso.

Casos de uso
Los casos de uso son una técnica que se basa en escenarios para la
obtención de requerimientos que se introdujeron por primera vez en el
método Objetory (Jacobsen el ai., 1993). Actualmente se han convertido
en una característica fundamental de la notación de UML, que se utiliza
para describir modelos de sistemas orientados a objetos.
Los casos de uso identifican las interacciones particulares con ei
sistema. Pueden ser documentadas con texto o vinculadas a modelos
UML que desarrollan el escenario en más detalle. Los diagramas de
secuencia (introducidos en el Capítulo 6} se utilizan a menudo para
añadir información a un caso de uso. Éstos muestran los actores
involucrados en la interacción, los objetos con los que interactúan y
las operaciones asociadas con estos objetos.
Los escenarios y los casos de uso son técnicas eficaces para obtener
requerimientos para los puntos de vista de los interactuadores, donde
cada tipo de interacción se puede representar como un caso de uso.
También se pueden utilizar conjuntamente con algunos puntos de vista
indirectos cuando éstos reciben resultados (como un informe de gestión)
del sistema. Sin embargo, debido a que se centran en las interacciones,
no son tan eficaces para obtener restricciones y requerimientos de
negocio y no funcionales de alto nivel de puntos de vista indirectos o
para descubrir requerimientos del dominio.
7.2.2 Etnografía
Los sistemas software no existen de forma aislada: se utilizan en un
contexto social y organi-zacional, y los requerimientos de sistemas
software se pueden derivar y restringir según ese contexto. A menudo,
satisfacer estos requerimientos sociales y organizacionales es crítico
para el éxito del sistema. Una razón de por qué muchos sistemas
software se entregan pero nunca se utilizan es que no se tiene en cuenta
adecuadamente la importancia de este tipo de requerimientos del
sistema,

La etnografía es una técnica de observación que se puede utilizar para

encender los requerimientos sociales y organizacionales. Un analista se
sumerge por sí solo en el entorno laboral donde se utilizará el sistema.
Observa el trabajo diario y anota las tareas reales en las que los
participantes están involucrados. £1 valor de la etnografía es que ayuda
a los analistas a descubrir los requerimientos implícitos que reflejan los
procesos reales mas que los formales en los que la gente está
involucrada.

La etnografía es especialmente efectiva para descubrir dos tipos de

requerimientos:
1 . Los requerimientos que se derivan de la forma en la que ¡a
gente trabaja realmente más que de la forma en la que las
definiciones de los procesos establecen que debería trabajar. Por
ejemplo, los controladores del tráfico aéreo pueden desconectar
un sistema de alerta de conflictos que detecta aviones que cruzan
las trayectorias de vuelo, aun cuando los procedimientos de
control normales especifican que debe utilizarse. Su estrategia de
control está diseñada para asegurar que estos aviones se
separarán antes de que ocurran problemas y consideran que la
alarma de alerta de conflictos los distrae
de Su trabajo,

2.
Los requerimientos que se derivan de la cooperación y
conocimiento de las actividades de ¡a gente. Por ejemplo, los
controladores del tráfico aéreo pueden utilizar el conocimiento del
trabajo de otros controladores para predecir el número de aviones
que entrara en su sector de control. Después modifican sus
estrategias de control dependiendo del volumen de trabajo
pronosticado. Por lo tanto, un sistema automático de control del
tráfico aéreo debe permitir a los controladores en un sector tener
alguna visibilidad del trabajo en los sectores adyacentes.

7.3 Validación de requerimientos

La validación de requerimientos trata de mostrar que éstos realmente
definen el sistema que el cliente desea. Coincide parcialmente con el
análisis ya que éste implica encontrar problemas con los
requerimientos. La validación de requerimientos es importante debido
a que los errores en el documento de requerimientos pueden conducir
a importantes costes al repetir el trabajo cuando son descubiertos
durante el desarrollo o después de que el sistema esté en uso. El coste
de arreglar un problema en ios requerimientos haciendo un cambio en
el sistema es mucho mayor que reparar ios errores de diseño o ios de
codificación. La razón de esto es que un cambio en ios requerimientos
normalmente significa que el diseño y la implementación del sistema
también deben cambiar y que éste debe probarse nuevamente.
Durante el procese de validación de requerimientos, se deben llevar a
cabo verificaciones sobre requerimientos en el documento de
requerimientos. Estas verificaciones comprenden:
1. Verificaciones de validez. Un usuario puede pensar que se necesita
un sistema para llevar a cabo ciertas funciones. Sin embargo, el
razonamiento y el análisis pueden identificar que se requieren
funciones adicionales o diferentes. Los sistemas tienen diversos
stakeholders con diferentes necesidades, y cualquier conjunto de
requerimientos es inevitablemente un compromiso en el entorno
del stakeholder.
2. Verificaciones de consistencia. Los requerimientos en el documento
no deben contra decirse; Esto es, no debe haber restricciones o
descripciones contradictorias de la misma función del sistema.
3. Verificaciones de completitud. El documento de requerimientos
debe incluir requerimientos que definan todas las funciones y
restricciones propuestas por el usuario del sistema.
4. Verificaciones de realismo. Utilizando el conocimiento de la
tecnología existente, los requerimientos deben verificarse para
asegurar que se pueden implementar. Estas verificaciones también
deben tener en cuenta el presupuesto y la confección de agendas
para el desarrollo del sistema.
5. Verificabilidad. Para reducir la posibilidad de discusiones entre e!
cuente y el contratista, los requerimientos del sistema siempre
deben redactarse de tal forma quesean verificables. Esto significa
que debe poder escribir un conjunto de pruebas que demuestren
que el sistema a entregar cumple cada uno de los requerimientos
especificados.

Pueden utilizarse, en conjunto o de forma individual, varias técnicas

de validación de requerimientos:
1. Revisiones de requerimientos. Los requerimientos son analizados
sistemáticamente por un equipo de revisores.
2. Construcción de prototipos En este enfoque de validación, se
muestra un modelo ejecutable del sistema a los usuarios finales y
a los clientes. Éstos pueden experimentar con este modelo para
ver si cumple sus necesidades reales..
3. Generación de casos de prueba. Los requerimientos deben
poder probarse. Si las pruebas para éstos se conciben como
parte del proceso de validación, a menudo revela los problemas
en los requerimientos. Si una prueba es difícil o imposible de
diseñar, normalmente significa que los requerimientos serán
 difíciles de implementar y deberían ser considerados
nuevamente. Desarrollar pruebas para los requerimientos del
usuario antes de que se escriba código es una parte fundamental
de la programación
extrema.
No deben subestimarse los problemas en la validación de
requerimientos. Es difícil demostrar que un conjunto de
requerimientos cumple las necesidades de! usuario. Los usuarios
deben imaginarse el sistema en funcionamiento y cómo éste encajaría
en su trabajo. Para ios informáticos expertos es difícil llevar a cabo este
tipo de análisis abstracto, pera para los usuarios del sistema es aún
más difícil. Como consecuencia, rara vez se encuentran todos los
problemas en los requerimientos durante el proceso de validación de
éstos. Es inevitable que haya cambios adicionales de requerimientos
para corregir las omisiones y ias malas interpretaciones después de
que el documento de requerimientos haya sido aprobado.

7,3.1 Revisiones de requerimientos

Una revisión de requerimientos es un proceso manual que involucra a
personas tanto de la organización del cliente como de la del
contratista. Ellos verificacan el documento de requerimientos en
cuanto a anomalías y omisiones. El proceso de revisión se puede
gestionar de la misma forma que las inspecciones de programas, se
puede organizar como una actividad más amplia con diferentes
personas que verifican diferentes partes del documento.
Los conflictos, contradicciones, errores y omisiones en los requerimientos deben
ser señalados por los revisores y registrarse formalmente en el informe de
revisión. Queda en los usuarios, la persona que adquiere el sistema y el
desarrollador de éste negociar una solución para estos problemas identificados.

7.4 Gestión de requerimientos

Los requerimientos para sistemas software grandes son siempre cambiantes. Una
razón es que estos sistemas normalmente se desarrollan para abordar problemas
«traviesos» (como se vio en el Capítulo 2). Debido a que el problema no puede
definirse completamente, es muy probable que los requerimientos del software
sean incompletos. Durante el proceso del software, la comprensión del problema
por parte de los stakeholders está cambiando constantemente. Estos
requerimientos deben entonces evolucionar para reflejar esta perspectiva
cambiante del problema.

Cuando los usuarios finales tienen experiencia con un sistema, descubren nuevas
necesidades y prioridades:
1. Normalmente, los sistemas grandes tienen una comunidad de usuarios
diversa donde
los usuarios tienen diferentes requerimientos y prioridades. Éstos pueden
contra decirse o estar en conflicto. Los requerimientos finales del sistema
son inevitablemente
un compromiso entre ellos y, con la experiencia, a menudo se descubre que
 la ayuda
suministrada a los diferentes usuarios tiene que cambiarse.
2. Las personas que pagan por e! sistema y los usuarios de éste raramente SOR
la misma
persona. Los clientes del sistema imponen requerimientos debido a las
restricciones organizacionales y de presupuesto. Éstos pueden estar en
conflicto con los requerimientos de los usuarios finales y, después de la
entrega, pueden tener que añadirse nuevas
características de apoyo al usuario si el sistema tiene que cumplir sus
objetivos.
3. El entorno de negocios y técnico del sistema cambia después de la
instalación, y estos
cambios se deben reflejar en el sistema. Se puede introducir nuevo hardware,
puede ser
necesario que el sistema interactúe con otros sistemas, las prioridades de
negocio pue
den cambiar con modificaciones consecuentes en la ayuda al sistema, y puede
haber una
nueva legislación.

7.4.1Requerimientos duraderos y volátiles

La evolución de los requerimientos durante el proceso de ingeniería de
requerimientos y después de que un sistema esté en uso es inevitable.

Desde una perspectiva evolutiva, los requerimientos se dividen en dos

clases:
1. Requerimientos duraderos. Son requerimientos relativamente
estables que se derivan de la actividad principal de la
organización y que están relacionados directamente con el
dominio del sistema. Por ejemplo, en un hospital siempre habrá
requerimientos que se refieren a los pacientes, médicos,
enfermeras. Estos requerimientos se pueden derivar de los
modelos del dominio que muestran las entidades y relaciones que
caracterizan un dominio de aplicación (Easterbrook, 1993; Prieto-
Díaz y Arango,1991).
2. Requerimientos volátiles. Son requerimientos que probablemente
cambian durante el proceso de desarrollo del sistema o después
de que éste se haya puesto en funciona miento. Un ejemplo
serían los requerimientos resultantes de las políticas
gubernamentales sobre sanidad. Harker y otros (Harker eí al.,
1993) han indicado que los requerimientos volátiles se dividen en
cinco clases. Utilizando éstas como base, se ha desarrollado la
clasificación mostrada enlaFigura7.ll.
7.4.2 Planificación de la gestión de requerimientos

La planificación es una primera etapa esencial del proceso de gestión

de requerimientos. La gestión de requerimientos tiene un coste
elevado. Para cada proyecto, la etapa de planificación establece el
nivel de detalle necesario en la gestión de requerimientos. Durante la
etapa de gestión de requerimientos, habrá que decidir sobre:
• La identificación de requerimientos. Cada requerimiento se debe
identificar de forma única de tal forma que puedan ser remitidos
por otros requerimientos de manera que pueda utilizarse en las
evaluaciones de rastreo.

• Un proceso de gestión del cambio, Éste es el conjunto de

actividades que evalúan el impacto y coste de los cambios. Se
traía con mayor detalles

• Políticas de rastreo. Estas políticas definen las relaciones entre

los requerimientos, y entre éstos y el diseño del sistema que se
debe registrar y la manera en que estos registros se deben
mantener.

• Ayuda de herramientas CASE. La gestión de requerimientos

comprende el procesamiento de grandes cantidades de
información sobre los requerimientos. Las herramientas que se
pueden utilizar van desde sistemas de gestión de requerimientos
especializados hasta hojas de cálculo y sistemas sencillos de
bases de datos.

Existen muchas relaciones entre los requerimientos y entre éstos y el

diseño del sistema. También existen vínculos entre los requerimientos y
las razones fundamentales por las que éstos se propusieron. Cuando se
proponen cambios, se debe rastrear el impacto de estos cambios en los
otros requerimientos y en el diseño del sistema. El rastreo es una
propiedad de la especificación de requerimientos que refleja la facilidad
de encontrar requerimientos relacionados.
Existen tres tipos de información de rastreo que pueden ser
mantenidos:
• La información de rastreo de la fuente vincula los requerimientos
con los stakeholders que propusieron los requerimientos y la
razón de éstos. Cuando se propone un cambio, esta información
se utiliza para encontrar y consultar a los stakeholders sobre el
cambio.
• La información de rastreo de los requerimientos vincula los
requerimientos dependientes en el documento de
requerimientos. Esta información se utiliza para evaluar cómo
es probable que muchos requerimientos se vean afectados por
un cambio propuesto y la magnitud de los cambios
consecuentes en los requerimientos
• La información de rastreo del diseño vincula los requerimientos
a los módulos del diseño en los cuales son implementados. Esta
información se utiliza para evaluar el impacto de los cambios de
los requerimientos propuestos en e! diseño e irnplementación del
sistema.
La gestión de requerimientos necesita ayuda automatizada; las
herramientas CASE para esto deben elegirse durante la fase de
planificación. Se precisan herramientas de ayuda para:
• . Almacenar requerimientos. Los requerimientos deben
mantenerse en un almacén de datos seguro y administrado que
sea accesible a todos los que estén implicados en el proceso de
ingeniería de requerimientos.
• Gestionar el cambio. Este proceso se simplifica si está
disponible una herramienta de ayuda.
• Gestionar el rastreo. Como se indicó anteriormente, las
herramientas de ayuda para el rastreo permiten que se
descubran requerimientos relacionados. Algunas herramientas
utilizan técnicas de procesamiento del lenguaje natural para
ayudarle a descubrir posibles relaciones entre los requerimientos.

7.4.3 Gestión del cambio de los requerimientos

La gestión del cambio de los requerimientos se debe aplicar a todos los

cambios propuestos en los requerimientos. La ventaja de utilizar un
proceso formal para gestionar el cambio es que todos los cambios
propuestos son tratados de forma consistente y que los cambios en el
documento de requerimientos se hacen de forma controlada. Existen
tres etapas principales en un proceso de gestión de cambio:
1. Análisis del problema y especificación del cambio.
El proceso empieza con la identificación de un
problema en los requerimientos o, algunas veces,
con una propuesta de cambio especifica. Durante
esta etapa, el problema o la propuesta de cambio
se analiza para verificar que ésta es válida. Los
resultados del análisis se pasan al solicitante del
cambio, y algunas veces se hace una propuesta de
cambio de requerimientos más específica.
2. Análisis del cambio y cálculo de costes. El efecto
de un cambio propuesto se valora utilizando la
información de rastreo y el conocimiento general
de ¡os requerimientos del sistema. El coste de
hacer un cambio se estima en términos de
modificaciones al documento de requerimientos y,
si es apropiado, al diseño e implementación del
sistema. Una vez que este análisis se completa, se
toma una decisión sobre si se continúa con el
cambio de requerimientos.
3. Implementación del cambio. Se modifica el
documento de requerimientos y, en su caso, el
diseño e implementación del sistema. Debe
organizar el documento de requerimientos de modo
que pueda hacer cambios en él sin tener que hacer
grandes reorganizaciones o redactar nuevamente
gran cantidad del mismo. Como sucede con los
programas, los cambios en los documentos se
llevan a cabo minimizando las referencias externas
y haciendo las secciones del documento tan
modulares como sea posible. De esta manera, se
pueden cambiar y reemplazar secciones
individuales sin afectar a otras partes del
documento.

TALLER # 7
1. Mencione quienes podrían ser los stakeholders en un sistema
de registros de estudiantes universitarios explique porque es
casi inevitable que los requerimientos de los diferente
stakeholders entren en conflicto de alguna forma.
RTA:Los stakeholders en esta clase de sistema pueden ser:

 Los estudiantes
 Oficina de registro
 Director
 Directores de las facultades
 Administradores de la base de datos
 Desarrolladores del software
Es casi inevitable que las opiniones de los stakeholders entren
en conflicto debido a las diferentes responsabilidades y aportes
que tengan que hacer al sistema

2. Un sistema de software se desarrolla para gestionar los

registros de los pacientes que ingresan a una clínica para
tratamiento. Los registros se incluyen anotaciones de todos los
controles habituales a los pacientes (temperatura, tención
arterial etc), los tratamientos dados las reacciones de los
pacientes, etc. Después del tratamiento los registros de su
estancia se envían al doctor del paciente quien mantiene su
historial clínico completo. Identifique los puntos de vista
principales que se pueden tener en cuenta en la especificación
del sistema y organícelos utilizando un diagrama de jerarquía
del punto de vista
HOSPITAL

P.INDIRECTO P.INTERACTUADORE P.DOMINI

ADMINISTRADORES
DE

MEDICOS JEFE REGISTRO

PACIENTES DE

MEDICOS MEDICOS
 COMUNICACIÓN CON
ENFERMERO OTRAS CLINICAS

PERSONAL PROVEDORES
LOGISTICO
PERSONAL
LOGISTICO

3. Para tres de los puntos de vista identificados en el sistema de

biblioteca, LIBSYS, mencione tres requerimientos que podrían
ser sugeridos por los stakeholders relacionados con ese punto
de vista.
RTA:

 Puntos de vista: requerimientos que el sistema pasa, las

personas que van frecuentemente se les rebaje el precio
 Personal de biblioteca: el sistema portable facilite a demás
de las cuentas la información de usuario
 Sistemas de clasificación: el sistema contable representa la
clasificación que lleva la biblioteca o que la mejore
4. El sistema LIBSYS, tiene que incluir soporte para la catalogación
de nuevos documentos donde el catalogo del sistema puede ser
distribuido a través de varias maquinas. Cuales son
probablemente los tipos mas importantes de requerimientos no
funcionales relacionados con los servicios de catalogación?
RTA: es