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

Negocio: Gestin y seguimiento de proyectos de software

Prctico N: 2
Eje temtico: Modelo de Objetos
Temas: Distribucin de responsabilidades entre objetos. Modelado Conceptual.

Objetivos de la ejercitacin
Que el estudiante, junto con su grupo de trabajo y con la gua directa del docente:
Pueda afianzar los conceptos de objetos, adquiridos en materias anteriores (clase e instancia, atributo, relacin, tipo de
relacin) y plasmarlos en un caso concreto.
Reconozca el concepto de estereotipo de clases de anlisis como patrn bsico para la distribucin de
responsabilidades entre objetos.
Vincule el concepto de Modelo del Dominio con el de estereotipo de clases de entidad.
Experimente la evolucin del Modelo del dominio en Diagrama de Clases de entidad.
Pueda afianzar la identificacin de los diferentes tipos de relaciones entre clases, especialmente de los que se utilizan
entre clases que modelan informacin, y que pueda utilizarlas correctamente en el modelado de entidades de un caso
concreto.

Actividades a desarrollar y entregar grupalmente
1. Tomando como base la solucin del Prctico N1 plasmada en los artefactos que componen el mismo, consolidar en
un nico Modelo de Clases de Entidad las clases, con sus atributos y relaciones, con todo los conceptos necesarios
para sostener toda la funcionalidad enmarcada dentro del Modelo de Casos de Uso del Sistema.
2. Considere las siguientes reglas de negocio y modele en un Modelo de Clases aparte los cambios que sufrira el
diagrama del punto 1.
a. Grupos de Trabajo: Se considera que los integrantes de un proyecto establecen un grupo estable, consolidado
y que es conveniente conservar. Se modifica la modalidad de trabajo actual para que exista una gestin y
armado de los grupos de trabajo que es previa a la asignacin de un grupo de trabajo a los proyectos. Es decir
que el grupo debe pre-existir para ser asignado a uno o ms proyectos. Los integrantes de un grupo pueden
variar en el tiempo por licencias, renuncias, urgencias o acuerdos especiales para una correcta gestin del
registro de horas es fundamental conocer en qu fecha ingresa y egresa cada integrante al grupo de trabajo.
Tener en cuenta que, si bien el grupo es una entidad a mantener los roles de cada integrante sern definidos
en cada proyecto que participe. Es decir un integrante de un grupo de trabajo podra desempear diferentes
roles en dos proyectos asignados a su grupo.
b. Particin de Solicitudes de Trabajo: Se haba enfatizado que es ideal que la solicitud asignada sea acotada y
concreta. Si al iniciar el trabajo con una solicitud, el responsable encuentra que es muy amplia, puede decidir
segmentarla en n solicitudes hijas que deben mantener un vnculo con la original, para hacer un seguimiento.
Al particionar una solicitud, su estado pasar a Reemplazada y el estado de las hijas ser creado como
Asignado o En curso, dependiendo del estado en que estuviera la solicitud en ese momento.
c. Reversin de Estados de Solicitud de Trabajo: Compruebe que el diseo planteado permita la reversin
automtica de una Solicitud de Trabajo a su estado anterior.
d. Estados diferentes por Tipo de solicitud: Se estima necesario ajustar el workflow de estados para cada tipo de
Solicitud. Esto significa no slo que los estados habilitados por tipo de solicitud puede variar sino tambin
que la secuencia de modificaciones permitidas puede variar, desde un cierto estado origen hacia n estados
destino permitidos por tipo de solicitud. Esto surge porque se decide trabajar con tipos de solicitud diferentes
Requisitos que no son de Desarrollo propiamente (por ejemplo: Capacitacin, Documentacin). Y esto
llevar a que los estados permitidos sean diferentes dependiendo del tipo de solicitud (los ejemplos citados no
entran al circuito de pruebas). A propsito: Est previsto en el modelado el trabajo de los responsables de
Testing para el registro de estados relevantes de la prueba?
i. Observacin no menor: El conjunto de estados de una solicitud sigue siendo un nomenclador
genrico. Porque los estados conservan su significado sin que vare por tipo de solicitud. Es relevante
conservar esta ventaja dado que, independientemente de las caractersticas especficas del worklfow
de cada tipo de solicitud un estado En ejecucin, Asignada, Terminada tienen una
interpretacin nica y de hecho es relevante consultar dichos estados independientemente del tipo de
solicitud.
e. Clculo de Re-trabajo: Compruebe que el diseo planteado permita el clculo de las horas de Re-trabajo. Se
considera tiempo de Re-Trabajo a la acumulacin de horas a travs del registro de tareas de Tipo
Desarrollo registradas con posterioridad al cambio de estado de la Solicitud a Desarrollada. Ese estado
identifica que el desarrollador ya termin sus pruebas de unidad, las que les corresponden de integracin y
anlisis de impacto y entrega la solicitud a los responsables de Testing.

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


f. Solicitud de Trabajo con datos variables por Cliente: Se estima necesario extender la definicin actual de una
Solicitud de Trabajo, para permitir mantener de manera controlada una serie de atributos que nos van
solicitando algunos clientes en los Reportes de Trabajo Ejecutado, entre otras opciones. Lo que se pide
administrar depende de la naturaleza de la empresa. Explicamos lo que se conoce del problema hasta ahora.
Hemos encontrado dos situaciones claras. Los clientes estatales dan de alta previamente en sus sistemas los
requerimientos y nosotros va WEB Services sincronizamos los pedidos diariamente para poder dar
tratamiento a las solicitudes. Esto implica mantener para ciertas solicitudes un histrico de los eventos de
Sincronizacin, incluyendo Fecha y Hora y cdigo de Transaccin de la Sincronizacin. Por otro lado ellos
requieren la identificacin en cada Solicitud del Nmero de Expediente de Pago que es gestionado siempre
por el Lder de Proyecto. Los clientes privados solicitan el seteo de una Fecha de Alerta en cada Solicitud a
partir de la cual desean recibir reportes de avances va mail. Y tambin una medicin de Nivel de Impacto del
Cambio, en base a un nomenclador, customizado por cliente. Mapea ese tipo de requisitos con el empleo de
algn tipo de relacin especfica dentro del Paradigma Orientado a Objetos?
3. Analice el impacto de cada situacin en el Modelo de Casos de Uso, sin llegar a especificar los artefactos
(Comentarios textuales).


Bibliografa para consultar
Jacobson, Ivar. Booch, Grady. Rumbaugh, James. El proceso unificado de desarrollo de software.
Larman, Craig. UML y Patrones.
Apuntes de la ctedra: Ingeniera Directa, Prof. Ghilardi.