MODULO 3. Fase Concepcin o Inicio del RUP. 3.1 Plan del proyecto 3.1.

1 Estructura de divisin de trabajo (EDT) Estructura de divisin del trabajo (EDT) [work breakdown structure (WBS)] Agrupacin de elementos de proyecto orientada a entregas que organiza y define el mbito total de trabajo del proyecto. Cada uno de los niveles descendentes representa una definicin cada vez ms detallada del trabajo del proyecto. La estructura de divisin del trabajo (EDT) tambin debera identificar las relaciones de los elementos entre s y las relaciones de stos con el producto final. EDT Estructura de Divisin del Trabajo - (WBS Structure): Definicin de relaciones jerrquicas entre tareas puntuales de un proyecto. - Ofrece una divisin lgica del proyecto en niveles sucesivos con aumento del detalle de informacin. - Una EDT se compone de tareas organizadas de tal manera que cada tarea se asocia solamente a una de mayor nivel (evitando superposicin de objetivos y esfuerzos). - Las tareas pueden ser resumidas progresivamente con el fin de presentar informacin de tiempo, costo y recursos en diferentes niveles e incluso a nivel del proyecto. - La EDT se puede asociar a una EDO Estructura de Divisin de la Organizacin (OBSOrganizational Breakdown Structure) para definir quin ser responsable de cada tarea. Producto: EDT del Proyecto, si es necesario asociado a una EDO. La EDT se visualiza en algn software visualizador. 3.1.2 Matriz de Responsabilidades: La matriz de la asignacin de responsabilidades (RACI por las iniciales de los tipos de responsabilidad) se utiliza generalmente en la gestin de proyectos para relacionar actividades con recursos (individuos o equipos de trabajo). De esta manera se logra asegurar que cada uno de los componentes del alcance est asignado a un individuo o a un equipo. Rol Descripcin Este rol realiza el trabajo y es responsable por su realizacin. Lo ms habitual es que exista slo un R, si existe ms de uno, entonces el trabajo debera ser subdividido a un nivel ms bajo, usando para ello las matrices RASCI. Es quien debe ejecutar las tareas. Este rol se encarga de aprobar el trabajo finalizado y a partir de ese momento, se vuelve responsable por l. Slo puede existir un A por cada tarea. Es quien debe asegurar que se ejecutan las tareas. Este rol posee alguna informacin o capacidad necesaria para terminar el trabajo. Se le informa y se le consulta informacin (comunicacin bidireccional). Este rol debe ser informado sobre el progreso y los resultados del trabajo. A diferencia del Consultado, la comunicacin es unidireccional.

Responsible

Responsable

Accountable

Aprobador

Consulted

Consultado

Informed

Informado

En esta matriz se asigna el rol que el recurso debe jugar para cada actividad dada. No es necesario que en cada actividad se asignen los cuatro roles, pero s por lo menos el de encargado y el de

responsable. Estas matrices se pueden construir en alto nivel (reas generales) o en un nivel detallado (tareas de nivel bajo). Todo esto se hace con ayuda de la EDT. 3.1.3 Estimacion de tiempos: La estimacin del tiempo forma parte del proceso de Gestin del Tiempo de la Administracin de Proyectos. La Gestin del Tiempo del Proyecto incluye los procesos necesarios para lograr la conclusin del proyecto a tiempo. Los procesos de Gestin del Tiempo del Proyecto incluyen lo siguiente: 1 Definicin de las Actividades: identifica las actividades especficas del cronograma que deben ser realizadas para producir los diferentes productos entregables del proyecto. 2 Establecimiento de la Secuencia de las Actividades: identifica y documenta las dependencias entre las actividades del cronograma. 3 Estimacin de Recursos de las Actividades: estima el tipo y las cantidades de recursos necesarios para realizar cada actividad del cronograma. 4 Estimacin de la Duracin de las Actividades: estima la cantidad de perodos laborables que sern necesarios para completar cada actividad del cronograma. 5 Desarrollo del Cronograma: analiza las secuencias de las actividades, la duracin de las actividades, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto. 6 Control del Cronograma: controla los cambios del cronograma del proyecto.

Para la estimacin en un proyecto se deben tomar en cuanta muchos factores, es por ello que se presentan muchos problemas de precisin pues alguno o mejor dicho, ms de alguno no es considerado como debiera o simplemente no se le considera, es por ello que se definen algunas mtricas en los mtodos por mencionar. Algoritmo SLIM. Software Lipe Cycle Management, SLIM fue desarrollado en el ao 1970 por Larry Putman. Depende de una estimacin SLOC para el tamao general del proyecto, se modifica a travs del uso de la curva de Raleigh para producir la estimacin del esfuerzo. El usuario puede influenciar la forma de la curva a travs de dos parmetros, la pendiente inicial de la curva y el factor de productividad. Puesto que estos son nmeros dimensionales el usuario tiene dos maneras de ingresar los datos, en la primera el usuario puede calibrar el modelo de ingreso de datos o bien respondes a las 22 preguntas que el SLIM puede proporcionar recomendando un PF y MBL, el segundo mtodo fue el escogido para esta investigacin debido a la ausencia de un banco de datos que pueda calibrarse, lo que reflejara con precisin la experiencia de los usuarios. Modelo COCOMO. Constructive Cost Model, fu desarrollado por Barry Boehm de TRW, publicado en 1981. Basado en el anlisis de 63 proyectos de software desarrollados. Boehm desarrollo un modelo (de tres niveles: bsico, intermedio y avanzado) fcil de entender que predice la duracin del proyecto, as como el esfuerzo para la realizacin de este. El modelo detallado COCOMO (utilizado en esta evaluacin) es muy similar al modelo intermedio excepto que el proyecto es dividido en cuatro fases: diseo del producto, diseo detallado, codificacin de pruebas, integracin-pruebas. Modelo PUNTOS de FUNCIN. El modelo Puntos de funcin fue realizado por Alam Albrecht y fue publicado en 1979. Albrecht estaba interesado en el problema general de medicin de productividad en sistemas y cre un mtodo como alternativa a la estimacin SLOC. Este mtodo captura los el nmero de transacciones de entrada y el numero de reportes.

El modelo Puntos de Funcin tiene ventajas sobre la cuantificacin de las lneas de cdigo (SLOC) como: es posible estimarlas en el ciclo de vida, alrededor del tiempo de definicin de requerimientos para el documento y pueden ser estimadas por un miembro del proyecto relativamente no tcnico. Existen dos pasos que involucrados para el conteo de puntos de funcin: el primero contar las funciones de usuario (tipos de entradas externas e internas, archivos lgicos internos, de interface externos y tipos externos de encuesta) el segundo, ajustar la complejidad de los procesos. Modelo ESTIMACS. El modelo Estimacs fue desarrollado por Howard Rubin. Este modelo no requiere como entrada el nmero de SLOC, tiene 25 preguntas, cuyas respuestas le sirven de datos de entrada. 3. ACERCA DE LOS DATOS. Base de Datos del Proyecto, los proyectos seleccionados para la evaluacin posean dos atributos en comn: eran de un tamao mediano y el estaban disponibles para completar la recoleccin de datos. METODOLOGA. Formas para recolectar los datos. Se presentaron tres formas para recolectar los datos: Se diseo una Forma para capturas la informacin a fondo a cerca del proyecto (por ej. Fabricante del hardware, modelo), despus del anlisis de requerimientos de cada modelo, se consolidaron dos Formas adicionales para recolectar los datos. Aunque cada uno de los modelos tiene una cantidad de requerimientos, se tomo en cuenta aquellos que tenan en comn, y que fueran relacionados a la productividad. Procedimiento para Recolectar los datos. Para cada proyecto hubo una junta con el manejador de proyectos que tena que llenar las formas especficas. Los propsitos eran: Discutir cada pregunta para asegurarse que se entendiera el concepto y se respondiera consistentemente Resaltar la importancia de la participacin del manejador del proyecto en el trabajo. Procedimiento para Analizar los datos Una vez llenadas las Formas se revis la consistencia del contenido. Se presento redundancia de muchas preguntas en los modelos, a excepcin de las preguntas del modelo Punto de Funcin con relacin a las del modelo ESTIMACS. Lo que significo que era posible asegurar una respuesta acerca del conocimiento del personal del proyecto para el modelo COCOMO, ya que presento consistencia con preguntas similares del modelo SLIM. Anlisis del error Para tener un margen de error entre una estimacin, se clculo el error relativo relacionando el esfuerzo estimado con el esfuerzo verdadero realizado en el proyecto. Usando dos exmenes para evaluar el proyecto: El de clculo de error relativo (MRE). El mtodo de regresin. 3.1.4 Red de Actividades: El Mtodo del Camino Crtico es una parte de la fase administrativa de planeacin que se encarga de la programacin, ejecucin y control de unproyecto que deba realizarse con aprovechamiento ptimo de tiempo y costos destinados al mismo. No solo se denomina Camino Crtico al sistematotal, sino tambin se le llama as a la serie de actividades, a partir de la iniciacin y hasta la terminacin del proyecto que no tienen posibilidad de variacin en su tiempo de ejecucin, ya que si una de ellas retrasara el proyecto total sufrir el mismo efecto. Tambin se entiende por camino crtico a la secuencia de actividades que ocupan el mayor tiempo de ejecucin del proyecto y con lo cual definen la duracin total del mismo. Las actividades se representan mediante flechas las cuales indican el tiempo que se ocupar en su realizacin.

Estas flechas pueden ser rectas, curvas, quebradas, etc., segn las necesidades en el trazo de la red, ejemplos:

En algunos casos , al trazar la red, es necesario indicar la relacin de una actividad con otro u oras, para lo cual es necesario dibujar flechas que indiquen dicha relacin; este tipo de flechas, al no representar consumo de tiempo y/o recursos, se dibujan en forma punteada, ejemplos:

A estas actividades se les conoce con los nombres de actividades ficticias o "ligas". Todas las se dibujarn de izquierda a derecha (a excepcin de aquellas actividades reales que por ser muy breve su duracin se represente con cero de tiempo y por lo tanto se dibujarn en forma ascendente o descendiente), y tanto al inicio como al trmino de cada una de ellas es necesario dibujar un pequeo crculo (o) el cual se denomina como "evento" o "nodo", los que sealarn el principio o fin de la actividad, ejemplos:

Al evento de iniciacin se le conoce como evento "i" y al de la finalizacin como evento "j", el evento final de una actividad ser el inicial de la actividad siguiente. De un evento pueden iniciar o terminar varias actividades, ejemplo:

Al dibujar la Red es conveniente evitar: 1) Que dos o ms actividades que inicien de un mismo evento terminen, tambin, en un mismo evento, ejemplo:

Ya que puede provocar error al interpretarla, por lo que se recomienda el uso de luna "liga" o actividad ficticia para relacionarlos, ejemplo:

2) No puede iniciar una actividad a la mitad de la otra.

Y para evitarlo es necesario dividir en dos la actividad en donde se origine el problema.

3) No se deben tener al iniciar la red, varios eventos que parten de actividades distintas sin relacionarlos entre s, mediante ligas, ejemplo:

4) El mismo cuidado se debe tener al finalizar la red, ejemplo:

Cuando existe alguna actividad con duracin de cero, se dibuja as:

Para trazar la red se utiliza, preferentemente, papel cuadriculado dibujando primero una escala de tiempos que represente la divisin utilizada al calcular la matriz (horas, das semanas, meses, etc.)

3.2 Lista de riesgos: El propsito del documento de lista de riesgos es identificar y evaluar riesgos: con base a la visin del proyecto inicial; identificar, analizar y dar prioridad a los riesgos del proyecto para determinar las estrategias de gestin de riesgos apropiadas. El equipo de desarrollo se junta para crear una lista de todos los posibles riesgos que en algn momento pudieran afectar al proyecto. Esta lista nace a partir de un anlisis del proyecto, tanto general como por cada paquete de trabajo, y as localizar las principales fuentes generadoras de riesgo. En RUP existen dos tipos de riesgos:

Directos: el personal tiene cierto control sobre ellos. Indirectos: no pueden ser controlados. Adems se cuenta con los riesgos generados a partir de los recursos del proyecto:

Organizacin Falta de compromiso del personal hacia el proyecto. Falta de planeacin y definicin en el proceso de ingeniera de software. El proyecto es el ms largo antes intentado.

Recursos Falta de recursos para completar el proyecto. Limitaciones de presupuesto: el sistema debe ser entregado en un costo fijo o se va a cancelar. Los estimados de costos sean inexactos. Personal Falta de personal disponible para el proyecto. El personal no tiene las habilidades y experiencia necesarias. El personal no cree en el proyecto. -no hay expertos en el rea disponibles. Tiempo La agenda no es realista. No hay tiempo para hacerlo bien. Otros de los riesgos que pueden aparecer en el proyecto son los tcnicos, dentro de ellos encontramos:

Alcance. El xito no puede ser medido. Los requerimientos no son estables ni entendibles. Los tiempos de desarrollo son inflexibles y limitados. Tecnolgicos. El xito del proyecto dependa de productos, servicios, tecnologas nuevos que no hayan sido probados antes. Dependencias del sistema con otros sistemas externos, y que estos fallen. Requerimientos de disponibilidad y seguridad inflexibles. El proyecto es inalcanzable (muy complejo o enorme como para trabajar apropiadamente). Dependencia externa. El proyecto depende de proyectos en desarrollo paralelo. El xito depende de la integracin de herramientas de desarrollo (compiladores, herramientas de diseo, etc.), tecnologas de implementacin (sistema operativo, bases de datos, etc.).

3.3 Modelado del negocio: Business Use Case Model. Se enfoca en obtener un modelo de la forma en la que los clientes actualmente trabajan, se conoce como visin del Negocio, y permite identificar los verdaderos problemas que existen en la organizacin, cmo y qu informacin estn intercambiando los diversos involucrados, y se utilizan para elaborar los Use Case Model descritos a continuacin. Adems ayudan a capturar requisitos no funcionales. Con esta disciplina se pretende llegar a un mejor entendimiento de la organizacin donde se va a implantar el sistema de software. Los principales motivos para ejecutar esta disciplina son los siguientes: asegurarse de que el producto ser algo til y no un obstculo; conseguir que se ajuste de la mejor forma posible en la organizacin donde se va a implantar; y tener un marco comn para el equipo de proyecto, los clientes y los usuarios finales. Esta disciplina no ser siempre necesaria. Si slo se aaden funcionalidades que no vern los usuarios directamente, no har falta. Los objetivos especficos del modelado de negocio son: Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Derivar los requerimientos del sistema necesarios para apoyar a la organizacin objetivo en su mejora. Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Entender la estructura y la dinmica de la organizacin para la cual el sistema va a ser desarrollado (organizacin objetivo). Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visin de la nueva organizacin, basado en esta visin se definen procesos, roles y responsabilidades de la organizacin por medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para la definicin de los requerimientos del sistema. La importancia de esta disciplina radica en que sin el panorama completo del alcance del negocio y sin el entendimiento de sus procesos no podrn identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas informticos, que son el producto final del desarrollo.

REFERENCIAS:

http://clases3gingsof.wetpaint.com/page/Proceso+de+Administraci%C3%B3n+de+Proyectos+de+R UP http://es.wikipedia.org/wiki/Estructura_de_descomposici%C3%B3n_del_trabajo http://www.mitecnologico.com/Main/LaEstructuraDeLaDivisionDelTrabajo http://sabanet.unisabana.edu.co/postgrados/gerencia_servicio/ciclo_ii/gerencia_proyectos/WBS.pdf http://www.mendeley.com/research/estimacin-tiempo-en-rup-tcnicas-formales-o-informales/ http://es.wikipedia.org/wiki/Matriz_de_Asignaci%C3%B3n_de_Responsabilidades http://www.mitecnologico.com/Main/RedesDeActividades http://www.mitecnologico.com/Main/EstimacionDeTiemposCostosYRecursos http://www.monografias.com/trabajos31/ruta-critica/ruta-critica.shtml