ACI491 - U6 - Administracion de Proyectos de Software - Parte3

ACI491: Ingeniera de Software
Unidad 6: Administracin de Proyectos de Software
2008 Universidad de Las Amricas - Ingeniera de Software : Dr. Juan Jos Aranda Aboy
Contenidos
Recursos, productividad y calidad de software. Mtricas como herramientas de software. Tcnicas de estimacin de costos, Planificacin y control de proyectos de Software. Plan de proyectos de software, Organizacin del equipo de Proyecto. El administrador de proyecto y sus roles, El lder de proyecto y sus roles, Seleccin del equipo de proyecto.
Objetivos especficos
Conocer y manejar las diferentes herramientas de administracin. Manejar en forma eficiente los recursos asociados al software. Conformar un equipo de trabajo, siendo capaz de identificar las labores mas adecuadas para cada uno de los integrantes
Administracin: El Proceso de Gestin del Proyecto de Proyectos de software 1. Comienzo del Proyecto de Software
Antes de empezar a planificar un proyecto el desarrollador y el cliente deben ponerse de acuerdo para definir el mbito y los objetivos del proyecto. Los objetivos identifican los fines globales del proyecto sin considerar como se llegar a ellos.
El mbito identifica las funciones primordiales del Software y ms importante an, intenta limitar esas funciones de manera cuantitativa.
Administracin de Proyectos de software

2. Medicin y mtricas
Las mediciones y las mtricas nos ayudan a entender tanto el proceso tcnico que se utiliza para desarrollar un producto, como el propio producto. Frecuentemente en la medicin surgen las siguientes interrogantes: Cules son las mtricas apropiadas para el proceso y para el producto? Cmo se deben utilizar los datos que se recopilan? Es bueno usar medidas para comparar gente, procesos o productos? entre otras.

3. Estimacin
La Planificacin es una de las actividades del proceso de Gestin de Proyectos de Software. Cuando se planifica un proyecto de Software se tiene que obtener estimaciones: Esfuerzo humano requerido. Duracin cronolgica del proyecto (en fechas). Costo.

4. Planificacin Temporal
La planificacin de un proyecto de software no difiere de la planificacin de cualquier proyecto de ingeniera por lo tanto: Se Se Se Se Se Se identifica una serie de tareas del proyecto . establecen interdependencias entre las tareas. estima el esfuerzo asociado con cada tarea. hace la asignacin de personal y de otros recursos. crea una red de tareas. desarrolla una agenda de fechas.

5. Seguimiento y Control
Si una tarea se sale de la agenda se debe determinar el impacto del error sobre los hitos intermedios y sobre la fecha final de entrega. Se pueden reasignar los recursos. Reordenar las tareas o (como ltimo recurso) modificar los compromisos de entrega para resolver el problema no detectado.
De este modo se puede controlar mejor el desarrollo del software.

6. Mtrica para la productividad y calidad del software
La medicin es fundamental para cualquier disciplina de ingeniera. Las mtricas del software se refieren a una amplio rango de medidas para el software de computadoras.
Administracin de Proyectos de software Medicin del software

La medicin se aleja de lo comn en el mundo de la ingeniera de software, aunque sin embargo, existen varias razones para medirlo:
Indicar la calidad del producto. Medir la calidad de la gente que desarrolla el producto. Evaluar los beneficios en trminos de productividad y calidad. Establecer una lnea de base para la estimacin. Ayudar a justificar el uso de nuevas herramientas de formacin adicional.
10

Las mtricas del software se pueden clasificar en:
Mtricas de productividad: Se centran en el rendimiento de procesos de ingeniera de software. Mtricas de calidad: Conveniencia del software para su utilizacin. Mtricas tcnicas: Se centran en las caractersticas del software.
11

Tambin se puede hacer una segunda clasificacin:
Mtricas orientadas al tamao.

Estas son medidas directas del software y el proceso por el cual se desarrolla. Ecuaciones para calcular la productividad y calidad del software.
12

Mtricas orientadas a la funcin:
Son medidas indirectas del software y del proceso por el cual se desarrolla.
Los valores del mbito de la informacin estn definidos de la siguiente manera: Nmero Nmero Nmero Nmero Nmero de de de de de entradas del usuario. salidas del usuario. peticiones del usuario. archivos. interfaces externas.
13

8. Mtrica para la Calidad del Software
Podemos medir la calidad a lo largo del proceso de Ingeniera el Software y una vez que el software se ha distribuido al cliente y a los usuarios.
Las mtricas de calidad de esta categora incluyen:

La complejidad del programa. La modularidad efectiva. El tamao del programa.
14
Conclusiones
Integracin de las mtricas dentro del proceso de la Ingeniera del Software Porqu es tan importante medir el proceso de Ingeniera de Software?
Permite determinar si estamos mejorando. Proporciona beneficio a nivel estratgico. Proporciona beneficio a nivel de proyecto. Proporciona beneficio a nivel tcnico.
15
Problemtica de la estimacin.
Estimacin
Averiguar lo que costara desarrollar una aplicacin: tiempo, recursos, $, Momento en que se desea conocer el costo. Siempre se quiere muy pronto
16
Problemtica de la estimacin
Estimar lo que costar:
Experiencia de Empresa:
17
Mtodos utilizados para la estimacin de proyectos.
Basados en la experiencia.
Basado exclusivamente en los recursos.
Mtodo basado exclusivamente en el mercado.

Basado en los componentes del producto o en el proceso de desarrollo. Mtodos algortmicos.
18
Juicio experto: Puro
Un experto estudia las especificaciones y hace su estimacin. Se basa fundamentalmente en los conocimientos del experto. Si desaparece el experto, la empresa deja de estimar
19
Estimacin
Medidas del Software
Medidas del Software
Planeacin => estimar tiempos y recursos => estimar Tamao del software => medida del software. Medida Proceso por el cual se asignan nmeros o smbolos a entidades de un set determinado para describir algn atributo de ellas.
20
Estimacin
Medida directa, indirecta o prediccin:

Medida directa: se observa la entidad y se aplica el instrumento de medida directa (peso, estatura). Medida indirecta: se mide en forma directa otra entidad (o ms de una) y luego se usan relaciones conocidas entre ellas (velocidad = distancia/tiempo).
Prediccin: queremos una estimacin de una medida de una entidad que puede no existir en ese momento.
21
Estimacin
Prediccin
Similar a medicin indirecta Establecer una conexin entre las entidades medidas directamente y las entidades cuya medida ser predicha. Refinar la conexin hasta llegar a una o ms frmulas que permitan traducir las medidas directas en medidas aproximadas. La diferencia clave est en que la en la prediccin no es posible establecer una conexin completa => slo se puede aproximar la medida correcta.
22
Estimacin Mediciones de Software

Razones de baja aceptacin en la industria:
Los administradores no saben qu hacer con las mediciones

Falta de validacin necesaria => falta de confianza en las medidas.
23
Estimacin
Ejemplo 1:
El modelo COCOMO simple relaciona el esfuerzo E (meses/hombre) con el tamao S (MLOCS) de acuerdo a: E = a*Sb Donde a y b son parmetros determinados por el tipo de software a ser desarrollado. Para usar este modelo para predecir el esfuerzo en la etapa de captura de requerimientos, necesitamos primero determinar (predecir) los parmetros y luego el tamao del eventual sistema. Estrictamente, COCOMO es ms que un mtodo de estimacin de costos, es un sistema de prediccin de costos.
24
Estimacin Sistemas de Prediccin

Ejemplo 2: Puntos de Funcin (FPs) Los Puntos de Funcin son una mtrica estndar para establecer el tamao del software. Los Puntos de Funcin miden la aplicacin desde una perspectiva del usuario, dejando de lado los detalles de codificacin. Es una tcnica totalmente independiente de todas las consideraciones de lenguaje .
25
Estimacin
Un Punto de Funcin se define como una funcin comercial de usuario final. De esta manera un programa que tenga x PFs entrega x funciones al usuario final. Para calcular los PF se deben realizar dos operaciones: 1. Contar tipos de funciones transaccionales. 2. Contar tipos de funciones de datos. Las Funciones Transaccionales representan la funcionalidad provista al usuario de los procesos de datos de una aplicacin. El conteo de tipos de funciones transaccionales determina la cantidad de Entradas Externas, Salidas Externas y Consultas Externas.
26
Estimacin
Se identifican 5 funciones bsicas: 1. Inputs: pantallas o formularios usados para captura. 2. Outputs: pantallas o reportes que la aplicacin produce. 3. Consultas: usuario interroga o pide informacin. 4. Archivos 5. Interfaz: archivos compartidos de entrada o salida, parmetros, etc.
27
Estimacin
Estimacin Wideband-Delphi La idea fundamental de este mtodo es usar varios expertos que hacen estimaciones independientes y luego hacerlos converger hacia una estimacin nica.
1. Cada experto recibe las especificaciones del programa y un formulario de estimacin. 2. Se renen a conversar sobre suposiciones, dudas, etc. 3. Cada uno hace una lista de las tareas y produce una estimacin.
28
Estimacin
4. Las estimaciones son recogidas por un moderador quien tabula los resultados y los devuelve a los expertos: estimaciones, promedio, media, etc. 5. Se renen nuevamente y discuten las tareas.
La discusin entre los expertos a menudo clarifica aspectos y produce cambios en las estimaciones para etapa siguiente. El mtodo produce estimaciones bastante precisas.
29
Estimacin Estimacin con Lgica Difusa

Mtodo de Lgica Difusa (Fuzzy-Logic): Se basa en comparar (en lneas de cdigo) con informacin histrica de productos anteriores. Se construye una tabla (escala de tipo logartmica) con rangos y subrangos de tamao de proyectos previos.
Por ejemplo si el programa ms pequeo es de 104 LOC y el ms grande de 17.243 LOC ...
30
Estimacin
Estimacin a travs de Componentes Estndares

Este mtodo se basa en mantener una base de datos histrica con informacin de componentes usados en proyectos previos en varios niveles de abstraccin: subsistemas completos, mdulos, interfaz con usuario, etc.
31
Estimacin
Estimacin a travs del Factor de Complejidad
Para calcular el factor de complejidad se consideran 13 aspectos, otorgndosele a cada uno de stos una influencia de 0 a 5, generndose as un puntaje que va de 0 a 70. El factor de complejidad estar dado por: FC = 0.65 + 0.01* Puntaje (rango 0.65 hasta 1.35)
32
Estimacin
Los factores son: comunicaciones objetivos de desempeo tasa de transacciones eficiencia para usuario proceso complejo facilidad de operacin facilidad de mantencin funciones distribuidas configuracin sobrecargada entrada de datos on-line actualizacin en lnea facilidad de instalacin varios sitios
33
Estimacin
Estimacin Probe
El Mtodo PROBE es aplicable en ambientes de OOP (por lo menos durante el diseo).
diseo conceptual identificacin de principales objetos (tipo, tamao) calcular proyeccin de LOC estimar tamao calcular intervalo de prediccin
34
Estimacin
Mtodo basado exclusivamente en el mercado: precio para vender.
Lo importante es conseguir el contrato
El precio se fija en funcin de lo que creemos que esta dispuesto a pagar el cliente.
Si se usa en conjuncin con otros mtodos puede ser aceptable, para ajustar la oferta. Peligro! -si es el nico mtodo utilizado-.
35
Estimacin
Mtodo basado en los componentes del producto o Proceso de desarrollo:
Bottom-up Se descompone el proyecto en las unidades lo menores posibles. Se estima cada unidad y se calcula el costo total. Top-Down Se ve todo el proyecto, se descompone en grandes bloques o fases. Se estima el costo de cada componente.
36
Estimacin Conclusiones
Los modelos tericos sirven, pero tienen muchas limitaciones. Muchas veces el plazo de desarrollo es fijado por gente del rea comercial o por ejecutivos, sin efectuar ningn tipo de clculo serio.
37
Estimacin
Conclusiones
Aunque muchas veces es difcil, el Ingeniero Jefe del Proyecto debe ser muy claro desde un principio y defender enrgicamente los tiempos reales obtenidos cientficamente.
En muchas ocasiones el encargado del proyecto se pone a si mismo la soga al cuello l solo, sin que nadie realmente lo est forzando a un agenda tan ajustada.
38
Administracin de Proyectos
Planificacin del proyecto
Distribuir la estimacin del esfuerzo a lo largo del proyecto.
Establecer los hitos y las actividades para chequear el avance el proyecto. Redefinir la planificacin sobre la marcha, aportando medidas para apalear los desfases respecto a la planificacin inicial. Controlar el proyecto, ejecutando las actividades de revisin previstas en la etapa de planificacin, y comparar los resultados contra lo planificado.
39
Para hacer esto hay que seguir una serie de Principios Bsicos:
Segmentacin El proyecto debe ser separado en un nmero manejable de actividades y tareas. Interdependencia La planificacin debe reflejar la separacin de tareas, y las relaciones entre ellas. Hay algunas tareas cuya ocurrencia es secuencial, otras en paralelo, algunas son requisito de otras, etc.
40
Asignacin de tiempo A cada tarea se le debe asignar un cierto nmero de Unidades de trabajo (personas-das, etc.) y Fechas de inicio y Trmino.
Validacin del esfuerzo Se debe verificar que las personas asignadas a una tarea estn Disponibles, que la cantidad de trabajo requerido no est sobredimensionada, y adems, que sea suficiente.
41
Definicin de responsabilidades Cada tarea debe tener un responsable.
Salida definida Cada tarea debe tener una salida o producto bien definido. Por ejemplo: diseo de un mdulo, plan de pruebas, etc. Definicin de metas Cada grupo de tareas debe estar asociado con una meta.
42
Planificacin de Tareas
Se pueden usar mtodos como PERT o CPM
Cualquiera de estos mtodos provee mecanismos para: determinar la ruta crtica: secuencia de tareas que define la duracin del proyecto. establecer estimaciones probables para tareas individuales.
43
Calcular tiempos lmites que definen ventanas de tiempo para las distintas actividades: lo ms temprano que una actividad puede empezar si todas las precedentes se completan en el mnimo tiempo. lo ms tarde que puede comenzar una tarea sin aumentar el tiempo mnimo del proyecto.
Existen herramientas de software para ello: MicroSoft Project, Planner, Open WorkBench, etc...
44
Administracin de Proyectos Control de Tareas

Bsicamente, es una estrategia de tipo incremental.
Se define la entrega del primer incremento, y luego se reajustan todas las tareas de acuerdo a este incremento.
Al llegar al lmite de tiempo de la tarea para ese incremento, esa tarea se detiene y comienza la siguiente. Aunque una tarea no est completa, muchas veces es posible postergar la ltima parte para el siguiente incremento.
45
la mayora de las veces el administrador del proyecto marca la diferencia entre el xito o el fracaso de un proyecto la gestin es tan importante como la parte tcnica ... ... es difcil encontrar un buen administrador de proyectos!
la administracin de proyectos es una disciplina que se debe aprender ...
46
Formas de monitoreo
Llevar a cabo reuniones peridicas en las cuales los participantes informan acerca del estado de desarrollo de las tareas, su progreso, o los problemas encontrados. Determinar si las metas estn siendo cumplidas de acuerdo a lo programado (checkpoints). Comparar tiempos planeados contra tiempos reales, para las distintas tareas.
47
Que hacer al detectar problemas con la planificacin?
Asignar ms recursos al rea afectada.

Readecuar el personal en general. Cambiar la programacin del proyecto. Usar tcnicas de time-box.
48
Cmo mejorar la Administracin de Software?
Requiere saber dnde estamos hoy?. Con exactitud!!!

Requiere revisar/redisear: El proceso de administracin de proyectos actual. La ingeniera de requisitos. La planificacin de proyectos. El seguimiento y control de proyectos. El aseguramiento de la calidad. La administracin de la configuracin.
49
Cuales son las Malas Noticias al administrar un proyecto:
Tratar de avanzar ms all de los sistemas legados, hacia tecnologas ms modernas trae su propio conjunto de problemas tcnicos y organizacionales.
La administracin de proyectos de software se hace cada vez ms difcil ...

La competencia obliga a las empresas a mejorar su productividad, manteniendo o mejorando la calidad a travs de desarrollos ms rpidos y econmicos.
50
Adicionalmente, la velocidad de preparacin de personal de desarrollo calificado, es menor que la requerida. Actualmente el personal tiene competencias adicionales a las tradicionales. La construccin y mantencin de software es una tarea difcil y ser an ms difcil. Construir software de una cierta calidad, en forma repetible, es una tarea an ms difcil.
51
Sntomas Comunes
Imprecisin en el entendimiento de las necesidades del usuario final. Falta de habilidad para manejar requisitos cambiantes. Mdulos que no calzan ... Software que es difcil de mantener o extender. Descubrimiento tardo de fallas serias. Problemas ajenos, como el Y2K. Miembros del equipo en muchas cosas, o ausentes, haciendo imposible reconstruir la historia de cambios. Falta (o problemas) de comunicacin entre los miembros del equipo.
52
Deficiencias Comunes
Administracin de requisitos ad-hoc. Comunicacin ambigua e imprecisa. Responsabilidades y roles difusos. Arquitecturas escabrosas. Complejidad muy grande. Falta de segmentacin del problema. Inconsistencias no detectadas en requisitos, diseo e implementacin. Testeo insuficiente. Evaluacin subjetiva del estado del proyecto. Incapacidad de los miembros para trabajar en grupo. Fallas para analizar y atacar los riesgos. Propagacin de cambios no controlada. Automatizacin insuficiente.
53
Buenas Prcticas de Software
Para construir buen software no basta con ser buen programador. Para ello, hay que conocer, planificar y controlar los procesos y recursos asignados a un proyecto.
54
CONCLUSIONES
La planificacin del proyecto provee una definicin de cada macro-tarea, junto con estimaciones de tiempos y recursos requeridos.
La planificacin del proyecto provee adems un marco de referencia para monitoreo y control de estas tareas.
La planificacin del proyecto se desarrolla al comienzo pero continuamente refinada a medida que el trabajo progresa.
55
Salvo raras excepciones, los recursos y tiempos estimados al inicio, difcilmente son alcanzados. Hay que controlar (monitorear) todo ... Pero el monitoreo es un medio, no un fin.
Si el trabajo no coincide con los tiempos y recursos asignados, debe recortarse la tarea, o aumentarse los tiempos y recursos asignados.
56
Administracin de Proyectos Proceso de Direccin de Proyectos

Directrices de un Jefe de Proyectos No confundir la direccin de un proyecto con su ejecucin.
Hacer todo lo posible por tener usuarios activos y comprometidos.

Convertir los productos y tareas en proyectos tangibles.
57
Directrices de un Jefe de Proyectos Pondrs por escrito la definicin del proyecto, los planes, la carta Gantt, los controles y los cambios. El tema del perfeccin. sistema se debe conocer a la
Aceptar el cambio como algo inevitable y natural y se debe administrar adecuadamente. Aprovechar la experiencia pasada.
58
Administracin de Proyectos Directrices de un Jefe de Proyectos

Utilizar los mejores recursos disponibles en el contexto de la organizacin. Gastar muy bien todas tus energas. Nunca asumir una lucha contra el destino. El proyecto es de todos, para todos y por todos. El equipo de trabajo estar siempre informado.
59
Dirigir v/s Ejecutar
Tareas de direccin.
Planificar, Controlar, Obtener y Asignar recursos, Coordinar, Manejar cambios, Negociar, Educar, Liderar, Evaluar ( calidad ).
Tareas de ejecucin.
Analizar, Disear, Documentar, Programar, Probar, Mantener, Capacitar, Investigar, Aprender y Evaluar.
60
Administracin de Proyectos Dirigir v/s Ejecutar

Todas son acciones necesarias. Ninguna accin es eludible. Las personas no son profesionalmente mejores o peores por la accin que realizan, sino por la calidad y oportunidad de su resultado. La direccin es, a ratos, inseparable de la ejecucin, pero sus naturalezas son diferentes.
61
Participacin y participantes El personal de informtica no siempre es experto en el rea de aplicacin.
El personal de informtica no vive los problemas cotidianos de los usuarios y viceversa.

El usuario es el mejor asignador de valores de beneficio relativo a diferentes opciones de diseo.
62
El usuario es el ms calificado para determinar cuales son los aspectos ms importantes de la zona de efecto de la solucin o del producto. La administracin superior no puede perder de vista el proceso y sus esfuerzos, en caso contrario slo se concentrarn en los resultados. La seguridad debe estar presente desde el inicio del proyecto: es ms barato modificar el diseo que el producto.
63
Las unidades de contralora de las organizaciones deben estar siempre presente: exigir controles, no esperar el trmino del proyecto para tenerlos. Hacer que todos participen: No discriminar.
64
Administracin de Proyectos Hacer Tangibles los Resultados y Productos Eventos y Objetos Tangibles : Son aquellos cuya realidad puede ser apreciada objetivamente por personas distintas a quienes las causaron o produjeron. Eventos u Objetos intangibles: No contribuyen a la visibilidad del avance, se prestan para manipular maliciosamente la informacin y entorpecen las comunicaciones.
65
Para una tarea cuya meta es intangible, es muy difcil de planificar y estimar el tiempo y los recursos necesarios para efectuarlas. Una manera de lograrla es escribiendo y comunicndolo, incluso los supuestos.
66
Administracin de Proyectos Algunas frases clebres:
Yo cre que... Yo nunca dije eso, lo que .... No recuerdo haber dicho... Me pareca obvio que s Recuerdo que te habas comprometido... Disculpen, pero como yo no vine a la reunin anterior, me pueden poner al da...
67
Administracin de Proyectos Administracin del Cambio

El cambio es inherente al ciclo de vida de un proyecto. El entender sto distingue a los Jefes de Proyectos felices de los estresados. En el estado del arte en que se encuentra la dinmica de definiciones de requerimientos y la tecnologa hoy en da, la probabilidad de que un proyecto sufra cambios es 1.
68
Administracin de Proyectos Administracin del Cambio

Se pueden hacer solo tres cosas ante un cambio:
1. Ignorar el cambio producto inservible. 2. Aceptar todos los cambios Proyecto infinito. 3. Administrar el Cambio proyecto exitoso.
69
Qu hacer entonces?: Evaluar el cambio costo/beneficio. Simlar la Carta Gantt. Propnerlo al grupo de proyecto. Aplique o deseche el cambio.
en
trminos
de
70
Administracin de Proyectos Recomendaciones Personales
Aplique su experiencia y resuelva ciertos cambios sin tanta burocracia. Para eso, dejar holguras en la carta Gantt. No estar todo el da pensando que hacer con el cambio, porque lo nico que se estar haciendo es perder el tiempo. Tome decisiones. Evale.
71
Actitudes personales Utilizar una metodologa. No usarla, porque no se conoce, puede ser peor.
La administracin de proyectos como una actividad bohemia, artstica y libre es un mito del pasado. Cambiar Artesana por Ingeniera.
El buen aprovechamiento de la metodologa puede ser determinante en aspectos tales como plazo, costo y tamao de un proyecto.
72
Organizacin del equipo de Proyecto

Motivacin
Por qu necesitamos trabajar en equipos?
La mayora de los productos son demasiado grandes para ser construidos por una sola persona. Cada vez son ms necesarios los especialistas, y los grupos interdisciplinarios. Es vital para poder competir. Es vital para mejorar (evolucionar). Es vital para poder asumir desafos ms grandes.
73
Funcionamiento de Grupos
El funcionamiento de los grupos puede responder a un enfoque: Jerrquico Supervisado Democrtico
74
Enfoque Democrtico
El grupo toma las decisiones a travs del acuerdo de la mayora de sus miembros. No existe un lder del grupo: Generalmente deciden por votacin. Se promueve la identificacin de errores, problemas, riesgos, etc. No se presentan los vicios tpicos producto de la jerarqua, sumisin, inhibicin, etc.
75

Ventajas
Muestran actitudes positivas frente a la identificacin de errores encuentran las fallas en forma temprana. Funcionan bien para atacar problemas difciles. El xito no depende de una sola persona. ... todos son parte de la solucin.
76

Desventajas
Difcil de implantar. A menudo cuesta ms llegar a una decisin. Las reuniones tienden a ser ms extensas y menos productivas ... No es muy bueno para proyectos grandes.
77
Enfoque Jerrquico
Project Mgr.
Analis.Chief
Design.Chief
Prog.Chief
SQA Chief
Analyst 1
Analyst 2
Elicitator
Hay un responsable por nivel y por rol. La comunicacin se lleva a cabo a travs de canales bien definidos.
78

Todas las comunicaciones se realizan a travs del jefe.
ste acta como administrador (manager) y responsable tcnico (technical leader). Hay otros miembros del equipo que actan como especialistas.
79

Ventajas
Existen pocos canales de comunicacin :

Se facilita la toma de decisiones Estamos acostumbrados a trabajar as.
80

Desventajas
Los jefes se transforman en cuellos de botella, especialmente el jefe de proyecto.

Aparecen vicios propios de los escenarios jerrquicos, sumisin, inhibicin, obsesin, etc. El jefe tiene que estar en tantas cosas, que al final no hace nada bien.
81

Desventajas
Es inaplicable en proyectos grandes. Demasiada dependencia de unas pocas personas. Cuando alguien jerrquico se enferma, se va de vacaciones, o se retira de la empresa, puede aparecer el caos.
82

Enfoque de Supervisin
El grupo es administrado por 2 personas El jefe tcnico es responsable de las decisiones tcnicas. El manager es responsable del presupuesto, planificacin, y seguimiento del proyecto (decisiones polticas).
83
Ventajas
Tanto el jefe tcnico como el manager pueden especializarse.

Uno puede asumir responsabilidades del otro, en caso de ser necesario (por ejemplo, frente al retiro de uno de stos). Funciona bien, si la gente involucrada tiene mucha experiencia, y profesionalismo. Puede mezclarse con el jerrquico, generando un modelo ms slido.
84

Desventajas
Hay decisiones que pertenecen tanto al rea tcnica, como a la gerencial. Requiere un muy buen entendimiento entre el jefe tcnico, y el manager. ... adems de un gran compromiso, y profesionalismo.
85

Sincronizacin y Estabilizacin de Equipos
Cada equipo debe estar formado por pequeos grupos (de 3-4 personas) Los miembros trabajarn en forma individual, diseando o implementando una parte de la especificacin del sistema
86
Esto estimula la creatividad. Evita la sincronizacin diaria. Alienta la segmentacin de los problemas.
87

Temas Crticos ...
Existen 5 temas crticos, que deben ser considerados dentro de un equipo de trabajo:
1. 2. 3. 4. 5. Clarificar la Visin Compartida del Proyecto. Construir la Cooperacin y la Confianza. Establecer Responsabilidades y Atribuciones. Establecer la organizacin y Utilizacin de los Recursos. Definir las actividades de supervisin.
88
Resumen
La gestin de proyectos de software es una actividad protectora dentro de la ingeniera del software. Empieza antes de iniciar cualquier actividad tcnica y contina a lo largo de la definicin, del desarrollo y del mantenimiento del software. Hay cuatro Ps que tienen una influencia sustancial en la gestin de proyectos de software: 1. personal, 2. producto, 3. proceso y 4. proyecto.
89
El personal debe organizarse en equipos eficaces, motivados para hacer un software de alta calidad y coordinados para alcanzar una comunicacin efectiva. Los requisitos del producto deben comunicarse desde el cliente al desarrollador, dividirse (descomponerse) en las partes que lo constituyen y distribuirse para que trabaje el equipo de software. El proceso debe adaptarse al personal y al problema. Se selecciona una estructura comn de proceso, se aplica un paradigma apropiado de ingeniera del software y se elige un conjunto de tareas para completar el trabajo. Finalmente, el proyecto debe organizarse de una manera que permita al equipo de software tener xito.
90
El elemento fundamental en todos los proyectos de software es el personal. Los ingenieros del software pueden organizarse en diferentes organigramas de equipo que van desde las jerarquas de control tradicionales a los equipos de paradigma abierto. Se pueden aplicar varias tcnicas de coordinacin y comunicacin para apoyar el trabajo del equipo. En general, las revisiones formales y las comunicaciones informales persona a persona son las ms valiosas para los profesionales. La actividad de gestin del proyecto comprende medicin y mtricas, estimacin, anlisis de riesgos, planificacin del programa, seguimiento y control.
91
El planificador del proyecto de software tiene que estimar tres cosas antes de que comience el proyecto: 1. cunto durar, 2. cunto esfuerzo requerir, y 3. cunta gente estar implicada. Adems, el planificador debe predecir los recursos de hardware y de software que va a requerir, y el riesgo implicado. El enunciado del mbito ayuda a desarrollar estimaciones mediante una o varias de las tcnicas siguientes: descomposicin, modelos empricos y herramientas automticas.
92
Las tcnicas de descomposicin requieren un esbozo de las principales funciones del software, seguido de estimaciones: (1) del nmero de LOC's, (2) de los valores seleccionados dentro del dominio de la informacin, (3) del nmero de personas/mes requeridas para implementar cada funcin, o (4) del nmero de personas/mes requeridas para cada actividad de ingeniera del software.
93
Las tcnicas empricas usan expresiones obtenidas de la experiencia de algunas organizaciones para el esfuerzo y para el tiempo, con las que se predicen esas magnitudes del proyecto. Las herramientas automticas implementan un determinado modelo emprico.
94
Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres tcnicas referidas anteriormente. Mediante la comparacin y la conciliacin de las estimaciones obtenidas con las diferentes tcnicas, el planificador puede obtener una estimacin ms exacta. La estimacin del proyecto de software nunca ser una ciencia exacta, pero la combinacin de buenos datos histricos y de tcnicas sistemticas pueden mejorar la precisin de la estimacin.
95
Ejercicio 1
1. Se le ha nombrado gestor de proyecto dentro de una organizacin de sistemas de informacin. Su trabajo es construir una aplicacin que es bastante similar a otras que ha construido su equipo, aunque sta es mayor y ms compleja. Los requisitos han sido detalladamente documentados por el cliente. Qu estructura de equipo elegira y por qu? Qu modelo(s) de proceso de software elegira y por qu?
96
Ejercicio 2
2. Se le ha nombrado gestor de proyecto de una pequea compaa de productos software. Su trabajo consiste en construir un producto innovador que combine hardware de realidad virtual con software innovador. Puesto que la competencia por el mercado de entretenimiento casero es intensa, hay cierta presin para terminar el trabajo rpidamente.
Qu estructura de equipo elegira y por qu? Qu modelo(s) de proceso de software elegira y por qu?
97
Ejercicio 3
3. Se le ha nombrado gestor de proyecto de una gran compaa de productos software. Su trabajo consiste en dirigir la versin de la siguiente generacin de su famoso procesador de textos. Como la competencia es intensa, se han establecido y anunciado fechas lmite rgidas. Qu estructura de equipo elegira y por qu? Qu modelo(s) de proceso de software elegira y por qu?
98
Ejercicio 4
4. Se le ha nombrado gestor de proyecto de software de una compaa que trabaja en el mundo de la ingeniera gentica. Su trabajo es dirigir el desarrollo de un nuevo producto de software que acelere el ritmo de impresin de genes. El trabajo est orientado a I+D, pero la meta es fabricar el producto dentro del siguiente ao.
Qu estructura de equipo elegira y por qu? Qu modelo(s) de proceso de software elegira y por qu?
99
Ejercicio 5
5. Suponga que es el gestor de proyectos de una compaa que construye software para productos de consumo y ha contratado la construccin de software para un sistema de seguridad del hogar. Escriba una especificacin del mbito que describa el software. Asegrese de que su enunciado del mbito sea limitado.
NOTA: Si no est familiarizado con sistemas de seguridad del hogar, investigue un poco antes de comenzar a escribir su especificacin.
100
Ejercicio 5 (continuacin - 1)
Desarrolle una lista de las caractersticas de software (por ejemplo: operacin concurrente, salida grfica, etc.), que afectan a la complejidad del proyecto. Establezca prioridades en dicha lista. Haga una descomposicin de las funciones software para el sistema de seguridad del hogar. Estime el tamao de cada funcin en LOC. Asumiendo que su organizacin produce 450 LOC/pm con una tarifa laboral de $700.000 por persona-mes, estime el esfuerzo y el coste requerido para construir el software utilizando la tcnica de estimacin basada en LOC.
101
Ejercicio 5 (continuacin - 2)
Utilizando las medidas de punto de funcin de tres dimensiones, calcule el nmero de PF para el software de este sistema de seguridad del hogar, y extraiga las estimaciones del esfuerzo y del coste mediante la tcnica de estimacin basada en PF.
102
Ejercicio de reflexin final

6. Parece extrao que las estimaciones de costes y planificaciones temporales se desarrollen durante la planificacin del proyecto de software -antes de haber realizado un anlisis de requisitos o un diseo detallado-. Por qu cree que se hace as? Existen circunstancias en las que no deba procederse de esta manera?
103
Fuentes de informacin
Sommerville, I. Ingeniera de Software 7ma edicin. Pressman, R. Ingeniera de Software: Un enfoque prctico 5ta edicin
cap 3 18p cap 4 24p cap 5 22p
Kendall, K.E. y Kendall, J.E. Anlisis y diseo de sistemas 6ta edicin. Software Productivity Research
104

ACI491 - U6 - Administracion de Proyectos de Software - Parte3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ACI491 - U6 - Administracion de Proyectos de Software - Parte3

Uploaded by

Copyright:

Available Formats

ACI491: Ingeniera de Software

Unidad 6: Administracin de Proyectos de Software

Administracin de Proyectos de software

Administracin de Proyectos de software

Administracin de Proyectos de software

Administracin de Proyectos de software

Administracin de Proyectos de software

Administracin de Proyectos de software Medicin del software

Administracin de Proyectos de software

Administracin de Proyectos de software

Mtricas orientadas al tamao.

Administracin de Proyectos de software

Administracin de Proyectos de software

Las mtricas de calidad de esta categora incluyen:

Administracin de Proyectos de software

Estimar lo que costar:

Mtodo basado exclusivamente en el mercado.

Medida directa, indirecta o prediccin:

Estimacin Mediciones de Software

Los administradores no saben qu hacer con las mediciones

Estimacin Sistemas de Prediccin

Estimacin Estimacin con Lgica Difusa

Estimacin a travs de Componentes Estndares

Estimacin a travs del Factor de Complejidad

Se pueden usar mtodos como PERT o CPM

Administracin de Proyectos Control de Tareas

Asignar ms recursos al rea afectada.

Requiere saber dnde estamos hoy?. Con exactitud!!!

La administracin de proyectos de software se hace cada vez ms difcil ...

Administracin de Proyectos Proceso de Direccin de Proyectos

Hacer todo lo posible por tener usuarios activos y comprometidos.

Administracin de Proyectos Directrices de un Jefe de Proyectos

Administracin de Proyectos Dirigir v/s Ejecutar

El personal de informtica no vive los problemas cotidianos de los usuarios y viceversa.

Administracin de Proyectos Algunas frases clebres:

Administracin de Proyectos Administracin del Cambio

Administracin de Proyectos Administracin del Cambio

Administracin de Proyectos Recomendaciones Personales

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

El funcionamiento de los grupos puede responder a un enfoque: Jerrquico Supervisado Democrtico

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Existen pocos canales de comunicacin :

Organizacin del equipo de Proyecto

Los jefes se transforman en cuellos de botella, especialmente el jefe de proyecto.

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Tanto el jefe tcnico como el manager pueden especializarse.

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Organizacin del equipo de Proyecto

Ejercicio de reflexin final

You might also like