Diseo de Sistemas. 3 ao. 2014. UTN. Reg. Mendoza.

Negocio: Gestin y seguimiento de proyectos de software

Prctico N: 1
Eje temtico: Modelo de Requisitos
Temas: Modelado de Casos de Uso. Especificacin detallada de Casos de Uso. Refinamiento del modelo.

Objetivos de la ejercitacin
Que el estudiante, junto con su grupo de trabajo y con la gua directa del docente:
Experimente la construccin de un circuito de informacin usando como base el concepto de caso de uso.
Comprenda el concepto de estado del sistema y comprenda cmo se modifica el mismo a travs de los casos de uso.
Entienda la importancia que tiene lograr una especificacin de requerimientos detallada, a travs de la documentacin
adecuada de los casos de uso y logre ejercitarla en un caso concreto.
Integre artefactos estudiados en materias anteriores, como apoyo a la actividad de especificacin detallada del modelo
de casos de uso (modelo del dominio, diseo de interfaz de usuario, descripcin de flujo de sucesos a nivel de casos
de uso, diagrama de transicin de estados) y los aplique a un caso concreto.
Distinga en situaciones concretas la diferencia entre requisitos funcionales y requisitos no funcionales, que entienda
cul es el momento oportuno para dar tratamiento aunos y a otros.
Entienda los diferentes tipos de relaciones entre casos de uso, propias de una actividad derefinamiento del modelo de
casos de usos y que interprete cul es el momento adecuado para encarar esta actividad y que pueda experimentar
contextos concretos para la aplicacin de estos conceptos.
Se inicie en el desarrollo de criterios de comparacin de diseos alternativos, distinguiendo aquellos que no resuelven
el problema de aquellos que s lo resuelven, encontrando ventajas, restricciones y desventajas de cada uno.

Actividades a desarrollar y entregar grupalmente
1. Construir el modelo de casos de uso necesario para poder implementar la aplicacin que se ha detallado, documentar
en una lista sus definiciones relevantes y entregar el Modelo del Dominio utilizado en el diseo.
Pasosguaquenodeben ser documentados
a. Encontrar los actores y analizar los objetivos que persigue y las funcionalidades del sistema que van a estar a
su cargo.
b. Definir con claridad, los casos de uso a medida que vayan surgiendo candidatos para evaluar su inclusin o
no en el modelo de casos de usos resultante.
c. Confeccionar una lista con las definiciones ms importantes de cada caso de uso que vaya quedando en firme
Nombre del Caso de Uso:
Tipo:
Actor:
Breve descripcin:
Prioridad:
Parmetros de entrada:
Estado inicial:
Estado final:
Pre-condiciones:
d. Hacer un primer borrador del modelo del dominio que resulta de incluir y relacionar los conceptos que se
han detectado hasta el momento. (Este paso es un trabajo iterativo y que se desarrolla junto con el c., este
modelo se depura al ir definiendo parmetros de entrada, estado inicial, estado final)
e. Disear prototipos de interfaces de usuario para todos aquellos casos de uso en donde encontremos
dificultad para identificar parmetros de entrada, estado inicial y final. (Este paso es iterativo y se desarrolla
en conjunto con c. y d.)
f. Agregar los casos de uso que no han sido nombrados en el texto, pero que son necesarios para definir
completamente el sistema y cerrar los circuitos de informacin (y repetir los pasos c., d. y e.).
g. Encontrar en el texto situaciones claras y concretas para el empleo de extensiones, inclusiones y
generalizaciones, adecuadas al contexto del negocio planteado. (Si no resultan casos claros y oportunos no
incluir en esta etapa).
2. Realizar la descripcin del flujo de sucesos a nivel de casos de uso (usando la plantilla gua adjunta o la utilizada en
Anlisis de Sistemas), el diseo de interfaz de usuario y el Modelo del dominio correspondiente al caso de uso Poner
en ejecucin solicitud, segn el enunciado del negocio de referencia
3. Realizar la descripcin del flujo de sucesos a nivel de casos de uso (usando la plantilla gua adjunta o la utilizada en
Anlisis de Sistemas), el diseo de interfaz de usuario y el Modelo del dominio correspondiente al caso de uso
Registrar Tarea, segn el enunciado del negocio de referencia
4. Realizar la descripcin del flujo de sucesos a nivel de casos de uso (usando la plantilla gua adjunta o la utilizada en
Anlisis de Sistemas), el diseo de interfaz de usuario y el Modelo del dominio correspondiente al caso de uso Cerrar
solicitud de trabajo, segn el enunciado del negocio de referencia
Diseo de Sistemas. 3 ao. 2014. UTN. Reg. Mendoza.


Plantillagua


Nombre del Caso de Uso:
Actor:
Objetivos del actor:
Breve descripcin:
Prioridad:
Parmetros de entrada:
Estado Inicial:
Estado Final:
Pre-condiciones:

CAMINO BASICO
Actor: Nombre del actor Nombre del sistema
1.
2.
Camino alternativo 1 - paso 2: Nombre claro para el cami no alternativo


2.1
2.2 Ir paso 1 del camino bsico.

TEMAS ABIERTOS
REGLAS DEL NEGOCIO
REQUISITOS ESPECIALES


Gestin de proyectos y registro de avance

Una empresa que se dedica al desarrollo de software necesita desarrollar una herramienta que le permita administrar
los proyectos en curso, facilitando el registro de las tareas que realiza cada empleado sobre cada proyecto en los que
interviene y de acuerdo a la planificacin de solicitudes de trabajo creadas por los coordinadores. Producto de la
carga detallada y de un adecuado circuito de estados de las solicitudes de trabajo, los interesados podrn acceder a
informacin como qu % detrabajos planificados estn cumplidos y qu % estn pendientes, cuntos proyectos
estn en curso, qu proyectos consumen mayor cantidad de recursos, etc.

Los proyectos se gestionan a travs del grupo de empleados que son asignados al mismo cuando se pone en
marcha. La cantidad de personal asignado vara de acuerdo a la prioridad y complejidad del proyecto. Pero
bsicamente en un proyecto de desarrollo de software deben cubrirse algunos roles: lder de proyecto (quien
conduce la planificacin global del proyecto y el trato formal con el cliente), analista funcional (quien realiza tareas
de captura de requisitos, testing de integracin, documentacin y capacitacin, eventualmente diseo conceptual) y
desarrollador (quien baja a diseo fsico el diseo conceptual que recibe y realiza la codificacin-programacin, y
prueba unitaria) y coordinador de desarrollo (quien gestiona el avance en lo tcnico, coordina el trabajo del resto,
especifica solicitudes de desarrollo concretas, realiza diseo conceptual). Un mismo empleado puede participar en
varios proyectos sin restriccin ya sea cumpliendo los mismos roles o diferentes. Tambin puede ocurrir en
proyectos pequeos que una misma persona cumpla ms de un rol.

El coordinador de desarrollo de cada proyecto crea, al iniciar el proyecto y varias veces durante su desarrollo,
solicitudes detrabajo a cargo de un responsable que es integrante del proyecto en cuestin. Tambin puede crearlas
autoasignadas. Cada solicitud de trabajo es de un tipo, ej.: desarrollo, tratamiento de error, mejora, cambio de
requisitos, etc. Tambin se define al momento de la creacin de la misma: la versin a la que pertenece la solicitud
(en relacin con la fecha estimada de entrega de la versin, el dato refleja la planificacin de entregas). Esta
asignacin puede ser editada durante la vida de la solicitud, cuando el coordinador replanifique las versiones como
comentaremos ms adelante.
Diseo de Sistemas. 3 ao. 2014. UTN. Reg. Mendoza.



Las versiones son planificadas en conjunto por el coordinador de desarrollo del proyecto y el lder del proyecto, en
funcin delos compromisos de entrega pactados con el cliente. Duranteel avance del desarrollo esas versiones son
completadas a travs de las solicitudes que la conforman. En ocasiones, se abren nuevas versiones intermedias y se
van ajustando las fechas estimadas de entrega de las mismas y re-definiendo el contenido o funcionalidad
comprometida en cada una (mediante el detalle de solicitudes de trabajo). Por un tema de responsabilidades dado
que la versin est atada a la gestin del producto de software la administracin de las versiones es realizada por el
coordinador de desarrollo del proyecto. El aval del lder del proyecto, slo es requerido en el sistema al intentar el
cierre de una versin terminada.

Al momento de la asignacin de una solicitud, la misma queda en estado Asignada. Cuando el responsable se
pone a trabajar sobre la misma, lo indica al sistema mediante un cambio de estado, colocndola en estado En
curso.

El trabajo realizado sobre una solicitud se refleja atravs del registro de sus tareas. Existe un conjunto finito de
tipos de tarea (diseo, desarrollo, capacitacin interna, prueba, documentacin, etc.). Estos tipos de tarea son
habilitados segn los roles existentes. Por ejemplo un analista funcional puede realizar tareas del tipo Prueba de
Integracin, pero un desarrollador no puede. Un coordinador de desarrollo puede realizar tareas del tipo
Coordinacin o Planificacin, pero otros roles no pueden, etc. Para que la tarea refleje una accin concreta de un
tipo determinado sobre una solicitud determinada la misma siempre identifica una fecha y un lapso horario de inicio
y finalizacin de la tarea (lo que permite calcular el tiempo de ejecucin de la tarea). Tambin se registra un detalle
en texto de lo realizado. Para que el registro de tareas sea til tambin el alcance de la solicitud de trabajo debe ser
acotado y concreto.

El responsable de una solicitud en cualquier momento mientras la tiene a cargo, registra la fecha estimada de
entrega. Generalmente lo hace cuando habiendo trabajado un poco sobre la misma, registrando varias tareas ya
tiene el dimensionamiento de la complejidad y caractersticas concretas del alcance para hacer dicha estimacin.
Debe validarse que la fecha no debe superar la fecha planificada de entrega de la versin.

Una solicitud puede ser pasada a otro responsable para que contine el registro y la realizacin de tareas. Es
importante reflejar los momentos en que se realizan los cambios de responsables, para poder controlar el registro de
tareas. Esta reasignacin puede realizarla tanto el coordinador como el responsable actual de la solicitud. Slo el
responsable en un momento dado es quien puede registrar tareas sobre la solicitud. Cuando el coordinador,
considere que se han realizado todas las tareas necesarias, pondr a la solicitud estado Terminada. Cuando todas
las solicitudes de una misma versin tienen dicho estado la versin pasa a estado Lista (en este caso el estado es
administrado por el sistema).

Debe considerarse en el diseo que el registro de tareas es considerado el ncleo del control que se busca. El
responsable busca registrar sin demora el trabajo realizado, aunque con posterioridad re-asigne ese registro a una
solicitud diferente. Esto ocurre con frecuencia en la gestin porque el trabajo de desarrollo es creativo, iterativo y
complejo. Imaginemos esta situacin: el responsable encuentra un bug de un mdulo que ni siquiera est a su cargo
y que se consideraba terminado, primero registra sus horas en sobre la solicitud abierta que lo llev al hallazgo,
luego el coordinador crea otra referencia y entonces mueve su registro a la solicitud especfico.

As como el coordinador usa el estado Terminada puede utilizar otros estados de acuerdo a su criterio, para
reflejar otras situaciones relevantes como Suspendida, Cancelada, etc. Podran existir otros estados y esto debe
preverse para hacer extensible el diseo.

Bibliografa para consultar
Jacobson, Ivar. Booch, Grady. Rumbaugh, James. El procesounificadodedesarrollodesoftware. (Modelo de Casos de Uso. Flujo
captura de requisitos)
Jacobson, Ivar. Object-Oriented Software Engineering. 1992 (Actores)
Larman, Craig. UML yPatrones. (Modelo de Casos de Usos Relaciones entre caso de uso)
Apuntes realizados por alumnos de aos anteriores parael tema de actores.(2010 )