Upload
buinga
View
219
Download
0
Embed Size (px)
Citation preview
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.