2.3 La fase de diseño

2.3.1 Desarrollo de prototipos

En la mayoría de los proyectos destinados a la construcción de sistemas de

información y/o software, el desarrollo de prototipos es esencial para crear un

software exitoso. Los prototipos aseguran el éxito porque son un medio para

eliminar ambigüedades en la definición de requerimientos, ya que muestran

gráficamente lo que será y hará el sistema. Los prototipos son muy fáciles de

crear, pero sobre todo evitan el mal entendimiento de los planteamientos de los

usuarios por parte de los analistas.

Un prototipo muestra algún aspecto del contenido del software. Por ejemplo, el

prototipo puede mostrar la navegación de un sitio Web o también puede mostrar la

distribución de una ventana o forma de un sistema.

Hacemos prototipos porque nos permiten crear cosas nuevas, refinar

requerimientos, y comunicar ideas complejas con los usuarios que las evalúen.

Existen otros tipos de prototipos: los prototipos de software. A diferencia de los

anteriores, estos prototipos muestran parte del sistema funcionando. Su objetivo

es eliminar los riesgos técnicos, es decir, probar la funcionalidad del sistema, de la

cual no se sepa mucho porque se está utilizando una nueva tecnología o porque

no se ha desarrollado algo similar. También, se usan para mostrar al usuario el

sistema para verificar que se está construyendo lo que él necesita. El riesgo de

estos prototipos radica en que los usuarios piensen que ya se puede ocupar el

sistema, lo cual es muy peligroso porque estos prototipos tienden a desecharse.

En la siguiente figura se ve la distribución de espacios para un sistema de apoyo

académico para alumnos.

Figura 2.22. Prototipo en papel

2.3.2 Productos entregables

Los productos entregables o productos de trabajo de un proceso, son artefactos

necesarios para ejecutar alguna actividad que corresponde con alguna de las

fases del ciclo de vida de sistemas. A su vez, las actividades pueden crear un

nuevo producto de trabajo o actualizarlo. Se recomienda que sólo un rol sea

responsable de la creación y/o actualización los productos de trabajo lo que

requiere tener muy bien definido el proceso de desarrollo. Es válido que un

producto de trabajo sea actualizado, pero hay que asegurar que se tiene el

consentimiento del rol responsable, a fin de que se pueda llevar un control

adecuado del artefacto.

Los productos de trabajo pueden ser:

Documentos.

Modelos y/o diagramas.

Especificaciones.

Software.

Dependiendo de la metodología que se utilicen los productos de trabajo pueden

tener diferentes nombres, algunos de los más conocidos y utilizados son:

Plan de trabajo.

Definición del problema

Lista de requerimientos.

Modelo de casos de uso.

La descripción de un caso de uso.

Modelo conceptual o del dominio.

Modelo de la base de datos.

2.3.3 Modelado de casos de uso

El modelado de casos de uso es parte del workflow de la disciplina de

requerimientos de RUP. Básicamente, es el conjunto de todos los casos de uso;

es un modelo de funcionalidad y entorno del sistema. Los modelos, o diagramas,

de casos de uso se componen de tres elementos: actores.; escenarios y casos de

uso.

“Un actor es algo con comportamiento específico, como una persona (identificada

por un rol), sistema de información u organización.”1

“Un escenario es una secuencia específica de acciones e interacciones entre los

actores y el sistema objeto de estudio; también se denomina instancia de caso de

uso. Es una historia particular del uso de un sistema.”2

1 Craig Larman, UML y patrones. Una introducción al análisis y diseño orientado a objetos y alproceso unificado”, p. 45.2 Idem.

“Un caso de uso es una colección de escenario con éxito y fallos relacionados,

que describe a los actores utilizando un sistema para satisfacer un objetivo.”3

Los casos de uso especifican requerimientos funcionales, aunque se pueden

adaptar para definirr requerimientos no funcionales. Los casos de uso no son

artefactos orientados a objetos y pueden ocuparse en cualquier metodología de

desarrollo de software.

Figura 2.23. Diagrama de casos de uso

2.3.4 Actores

Un actor representa un conjunto coherente de roles que los usuarios de los casos

de uso representan al interactuar con éstos. Por lo regular, un actor representa un

rol que es desempeñado por una persona, hardware, sistemas u organización. Por

ejemplo, si una persona trabaja para una universidad, podría ser un profesor. Si

toma clases en esa universidad, está desempeñando el rol de alumno. Por lo

tanto, una persona puede tener diferentes roles, es decir, actores.

Figura 2.24. Actores

3 Idem.

Alumno Profesor

System

Inscripción

Alumno

Administración de Grupos

Administración EscolarGeneración de Constancias

Actor

Caso de Uso

2.3.5 Propósito de los casos de uso

Ivar Jacobson fue el creador de los casos de uso, desde su creación han tomado

vital importancia en el desarrollo de software ya que son un elemento muy valioso

para cualquier proceso que trate sobre la administración de requerimientos.

Son varios los propósitos de los casos de uso:

Propósito Descripción

Reducir el

riesgo

Todo proyecto de desarrollo de sistemas se desenvuelve en

un ambiente de alta incertidumbre, los cambios no se hacen

esperar por parte de los usuarios, los casos de uso nos

ayudan a comunicarnos con los usuarios y formalizar los

acuerdos tomados sobre la funcionalidad que debe hacer el

sistema.

Enfocarse a

los objetivos

del negocio

Los casos de uso definen procesos del negocio y/o procesos

del sistema. Ambos deben alinearse con los objetivos

negocio. Esto evita que se desarrolle una funcionalidad que

aporta valor a los objetos.

Apoyar a la

planeación

Si se utiliza un ciclo de vida en espiral, estamos hablando de

un desarrollo iterativo. Los casos de uso permiten establecer

los tiempos para el plan de trabajo de cada una de las fases e

iteraciones, a fin de ir entregando el sistema por incrementos.

Involucrar a

los usuarios

La fuente de información para especificar los casos de uso

son los usuarios, son ellos los que realizan las actividades de

los procesos, y son ellos los que deben verificar que los casos

de uso estén bien escritos. Esto ayuda a evitar

inconsistencias, ambigüedades, suposiciones, pero sobre

todo involucra al usuario en el sistema.

Cuadro 2.4. Propósitos de los casos de uso

2.3.6 Granularidad de los casos de uso

En análisis y diseño de sistemas se busca la reutilización del software a fin de

evitar el retrabado y facilitar su mantenimiento. La granuralidad es una técnica que

apoya a este objetivo debido a que se buscan comportamientos similares en las

partes del sistema para agruparlos y posteriormente sea utilizados por

subsistemas del sistema.

Una consideración que se debe tener en cuenta cuando se especifican los casos

de uso, es que encontraremos flujos alternativos (ver punto 2.3.7) que se repiten

en varios casos de uso. Por ejemplo, supongamos que tenemos un caso de uso

que busca un estudiante para generar una constancia de estudios, y tenemos otro

caso de uso que busca un estudiante para actualizar su inscripción. Ambos casos

buscan al estudiante, podemos sacar ese comportamiento de ambos casos de uso

y generar uno nuevo.

Figura 2.25. Separación de casos de uso

2.3.7 Descripciones de casos uso

Existen diversas formas de hacer una descripción o especificación de un caso de

uso, la elección va a depender del nivel de detalle que se requiera:

“Breve: resumen conciso de un párrafo, normalmente del escenario principal con

éxito.

Generación de Constancias

Administración de Inscripciones

Antes

Buscar Alumno

Generación de Constancias

Administración de Inscripciones

<<include>><<include>>

Después

Informal: formato de párrafo en un estilo informal. Múltiples párrafos que

comprenden varios escenarios.

Completo: el más elaborado. Se escriben con detalle todos los pasos y

variaciones, y hay secciones de apoyo como precondiciones y poscondiciones.”4

El formato completo consta de las siguientes partes:

Nombre.- Nombre del caso de uso.

Descripción.- Una breve descripción y/o objetivo del caso de

uso.

Actor(es).- Lista de actores que intervienen en el caso de uso.

Flujo Principal y Alternativos.- Descripción de las actividades y todos de los

posibles caminos a seguir para lograr el objetivo

del caso de uso.

Flujo de Excepciones.- Descripción de aquellos flujos que no aportan

valor y que muestran los problemas que se

pueden presentar en el caso de uso.

Precondiciones.- Son actividades que se tienen que hacer como

obligatorios u optativas antes de iniciar el caso de

uso.

Poscondiciones.- Son actividades que se tienen

que hacer como obligatorios u optativas después

de finalizar el caso de uso.

2.3.8 Los casos de uso en la fase de elaboración

En la fase de concepción de RUP, el objetivo es identificar los casos de uso y los

actores, como su nombre lo indica sólo significa identificar, por lo que una lista con

los casos de uso y actores es suficiente para cubrir este objetivo. Es muy

recomendable que se tenga por cada caso de uso una descripción breve y no

más.

4 Ibidem, p. 47

En cambio, en la fase de elaboración, el objetivo es especificar cada uno de los

casos de uso. La especificación de los casos de uso es fundamental porque sin

ella no se puede elaborar el análisis y diseño correspondiente de cada caso de

uso.

2.3.9 Búsqueda de casos de uso

Lo primero que hay que hacer es identificar quiénes son los actores, de quienes

hay que saber qué entradas proporcionarán al sistema y qué salidas obtendrán

desde el sistema. Esto es un elemento muy valioso porque, con base en la

información requerida, se deben identificar los casos de uso que generaran dicha

información.

Al mismo tiempo, los actores tienen una serie de responsabilidades con el

sistema. Esas responsabilidades son procesos, es decir, casos de uso que

componen el sistema. No existe un método que nos permita identificar todos los

casos de uso en un solo esfuerzo, sólo con la práctica se va adquiriendo la

experiencia y conocimiento para establecer los casos de uso. Y como todo

sistema no es igual a otro, es muy posible que, en un sistema, un caso de uso no

lo sea en otro sistema.

2.3.10 Talleres conjuntos de planeación de requerimientos

Muchas organizaciones están usando la sesión grupal de trabajo como un

sustituto de entrevistas separadas y numerosas. Un ejemplo de sesión grupal de

trabajo es la planeación conjunta de requisitos, en la cual se conducen reuniones

de grupo altamente estructuradas con el objeto de identificar y analizar problemas,

además de definir los requerimientos del sistema. Este taller se está haciendo

cada vez más común en la planeación de sistemas y en el análisis de sistemas

para obtener un consenso de los participantes sobre los problemas, objetivos, y

requerimientos.

Los participantes

Las sesiones de planeación conjunta de requerimientos incluyen una amplia

variedad de participantes y de papeles. Se espera que cada participante asista y

participe activamente en la sesión completa:

Patrocinador.

Facilitador.

Usuarios y gerentes.

Secretario.

Equipo de Tecnologías de Información (TI)

Patrocinador

Normalmente esta persona es un individuo que está en la dirección o gerencia de

la organización, que tiene la autoridad sobre los diferentes departamentos y

usuarios que van a participar en el proyecto del sistema. El patrocinador da todo

su apoyo al proyecto de sistemas al alentar a los usuarios designados a que

participen en forma activa y por su propia voluntad en la sesión. El patrocinador

juega un papel visible durante una sesión, al dar inicio a la junta presentando a los

participantes. Frecuentemente, el patrocinador también hará comentarios finales

sobre la sesión y trabajará íntimamente con el líder de la planeación conjunta de

requerimientos, para planear la sesión al ayudar a identificar a las personas

provenientes de la comunidad de usuarios, que deberán asistir y determinar la

fecha y ubicación de las sesiones.

Facilitador

Es el responsable de conducir todas las sesiones que se celebren para el proyecto

del sistema. Esta persona es alguien que tiene excelentes habilidades de

comunicación, posee la capacidad para negociar y resolver conflictos de grupo,

tiene un buen conocimiento del negocio, buenas habilidades para la organización,

es imparcial con las decisiones que se van a enfrentar y no reporta a ninguno de

los participantes de la sesión.

Algunas veces es difícil encontrar una persona dentro de la compañía que posea

todas estas cualidades. Entonces, con frecuencia, las compañías deben

suministrar una extensa capacitación o contratar un experto externo a la

organización para cumplir con este papel.

El papel del facilitador es planear las sesiones, conducir la sesión y dar

seguimiento a los resultados. Durante la sesión, el facilitador es responsable de

encabezar la discusión, alentando a los asistentes para que participen

activamente, resolviendo los conflictos clave que puedan surgir, y asegurándose

de que se alcancen las metas y los objetivos de la reunión. La responsabilidad del

facilitador es establecer las reglas de campo que se seguirán durante la reunión y

asegurarse de que los participantes se adhieran a estas reglas.

Usuarios y gerentes

La planeación conjunta de requisitos incluye a varios participantes provenientes de

los sectores de usuarios y gerencial de una organización, a los cuales se les

concede tiempo de comisión de sus actividades cotidianas para dedicarse a una

participación activa en las sesiones. Estos participantes son seleccionados por el

patrocinador, quien debe ser cuidadoso para asegurarse de que cada persona

tenga el conocimiento del negocio para contribuir durante las sesiones de

exploración. El patrocinador del proyecto debe ejercer su autoridad y estímulo

para asegurarse de que estas personas se dedicarán a una participación activa.

Una sesión típica puede incluir cualquier número de personas, desde un número

relativamente pequeño de usuarios/gerentes hasta una docena o más. El papel de

los usuarios durante la sesión es comunicar con efectividad las reglas y los

requerimientos de negocios, revisar los prototipos de diseño, y tomar decisiones

aceptables. El papel de los gerentes durante una sesión es aprobar los objetivos

del proyecto, establecer las prioridades del mismo, aprobar los calendarios y los

costos. En general, se confía en que tanto los usuarios como los gerentes van a

asegurarse de que sus factores críticos de éxito están siendo considerados.

Secretario(s)

Una sesión incluye uno o más secretarios, quienes son responsables de llevar el

registro relativo a todo lo que se discuta en la reunión. Estos registros se publican

y se distribuyen a los asistentes inmediatamente después de la reunión, con

objetivo de conservar el impulso que ha sido establecido en la sesión por los

miembros.

Equipo de Tecnologías de Información(TI)

Una sesión puede incluir varias personas de TI, quienes principalmente escuchan

y toman notas en relación con los aspectos y los requerimientos expresados por

los usuarios y los gerentes. Normalmente, el personal de TI no hace comentarios a

menos que se les invite. En vez de ello, las preguntas o inquietudes que tengan en

general son canalizadas al facilitador inmediatamente, antes o después de la

sesión. Es el facilitador quien inicia y promueve la discusión de los aspectos por

los usuarios y los gerentes.

Cómo planear las sesiones. La mayoría de las sesiones abarcan de tres a cinco

días, ocasionalmente duran hasta dos semanas. El éxito de cualquier sesión

depende de la planeación y su ejecución. Antes de planear una sesión, el analista

debe trabajar estrechamente con el patrocinador para determinar el alcance del

proyecto que se va a abordar a través de las sesiones. También, es importante

que se determinen los requerimientos de alto nivel y las expectativas de cada

sesión. En general, esto implica entrevistar a personas seleccionadas que son

responsables de los departamentos o de las funciones que deben ser abordadas

en el proyecto. Finalmente, antes de planear la sesión, se debe asegurar que el

patrocinador tenga deseos de dedicar gente, tiempo y otros recursos a la sesión.

La planeación de una sesión implica tres pasos:

1. Selección de una ubicación para la sesión.

2. Selección de los participantes.

3. Preparación de una agenda que deberá seguirse durante la sesión.

2.3.11 Comentarios sobre la tormenta de ideas

La tormenta de Ideas es una actividad muy usada en reuniones de negocio para

resolver problemas, con nuevas ideas de innovación o solución. Se anima a los

miembros del grupo que propongan ideas sobre un problema y sus posibles

soluciones, con el fin de generar tantas ideas como sea posible, aunque no sean

siempre alternativas útiles. El propósito, detrás de la reunión, es que un grupo de

personas pueda lograr un nivel más alto (de la sinergia) de la creatividad que la

suma de los participantes por separado.

Reglas:

Animar a los participantes que expresen la mayor cantidad de ideas como sea

posible, por lo que no hay malas ideas.

No hacer juicio alguno sobre las ideas.

Animar a los participantes a que deben que construir nuevas ideas con las

ideas ya expresadas por los demás participantes.

Consejos:

Utilizar un facilitador experimentado.

Designar a una persona para anotar todas las ideas que salgan de la sesión

de la lluvia de ideas.

Utilizar un pizarrón o rotafolio para hacer las notas. Esto permite un estudio y

una evaluación al final de la sesión.

Identificar el asunto exacto que se discutirá.

Mantener la sesión centrada en el problema.

Incluir entre 8 y 10 personas en una sesión. Si hay más participantes, divida la

sesión de la lluvia de ideas y divulgue los resultados de un grupo a otro.

Asegurar de que nadie critique o evalúe ideas durante la sesión. La crítica

introduce un elemento de riesgo para los miembros del grupo al proponer una

idea. Esto sofoca creatividad.

Animar una actitud motivante.

Involucrar a todos los miembros del grupo, aun los más reservados

Mantener un ambiente ameno en la reunión.

Animar a las personas a que expresen tantas ideas como sea posible.