Escolar Documentos
Profissional Documentos
Cultura Documentos
Unidad 3
Planificación De Proyecto
ALUMNOS:
1
3.1 OBJETIVO DEL PROYECTO
La clave para empezar con éxito un proyecto es que tengamos los términos de
referencia bien establecidos. Para ello, debemos conocer a los usuarios (autoridad
y el patrocinador), los objetivos, el ámbito, las restricciones, los costes y /o
presupuesto, los recursos, las entregas, las fases del proyecto, las estrategias,
riesgos, hipótesis, roles y responsabilidades.
2
que afectan el proyecto (fecha de entrega requerida, personal disponible,
presupuesto global, etc.). Ésta se lleva a cabo con una estimación de los parámetros
del proyecto como su estructura, tamaño y distribución de funciones. Después de
algún tiempo (por lo general 2 o 3 semanas), se revisa el proyecto y señalan las
discrepancias. Debido a que las estimaciones iniciales de los parámetros del
proyecto son tentativas, el plan siempre deberá actualizarse.
Las estimaciones están asociadas con el esfuerzo y el tiempo con las actividades
identificadas del proyecto. Los administradores del proyecto deben estimar las
respuestas a las siguientes preguntas:
3
proyecto. Las organizaciones calculan los costos de esfuerzo en función de los
costos de sobrecarga donde se toma en cuenta el costo total de hacer funcionar la
organización y dividen éste entre el número de personas productivas. Por lo tanto,
los siguientes costos son parte de los costos de esfuerzo totales:
Dentro de la información que es necesario analizar para poder hacer una buena
estimación del tiempo se deben tomar en cuenta los siguientes aspectos:
1. Lista de actividades. La lista de actividades debe incluir todas las actividades que
serán ejecutadas en el proyecto. Deberá ser organizada como una extensión de la
estructura de la división de trabajo para ayudar a asegurar que está completo y que
no incluye actividades que no son requeridas como parte del alcance del proyecto.
Así como con la estructura de la división de trabajo; la lista de actividades debe
incluir descripciones de cada actividad para asegurar que los miembros del equipo
del proyecto entenderán como se deberá de ejecutar el trabajo.
2. Restricciones. Las restricciones son todos aquellos factores que van a limitar las
opciones del equipo del proyecto.
4
suposiciones generalmente involucran algún grado de riesgo y serán
normalmente una salida del proceso de identificación de riesgos.
5
cuánto se demora un agente gubernamental para responder a ciertas
requisiciones).
Pero fallar en la planificación es uno de los errores más cruciales que un proyecto
puede tener... la planificación efectiva es necesaria para resolver problemas
corrientes arriba [tempranamente en el proyecto] a bajo costo, en lugar de corriente
abajo [tardíamente en el proyecto] a alto costo. El proyecto promedio emplea 80 por
ciento de su tiempo en “poner al día”: corregir errores que se cometieron
anteriormente en el proyecto.
La estimación de costo y esfuerzo del software nunca será una ciencia exacta.
Demasiadas variables (humanas, técnicas, ambientales, políticas) pueden afectar
6
el costo final del software y el esfuerzo aplicado para su desarrollo. Sin embargo, la
estimación del proyecto de software puede transformarse de un arte oscuro a una
serie de pasos sistemáticos que proporcionen estimaciones con riesgo aceptable.
Para lograr estimaciones confiables de costo y esfuerzo, surgen algunas opciones:
¿Qué es? Se establece una necesidad real para el software; los participantes están
a bordo, los ingenieros de software están listos para comenzar y el proyecto está a
punto de iniciar. Pero, ¿cómo se procede? La planificación de proyectos de software
abarca cinco grandes actividades: estimación, calendarización, análisis de riesgos,
planificación de gestión de la calidad y planificación de gestión del cambio. En el
contexto de este capítulo, sólo se considera la estimación, el intento por determinar
cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto
específico basado en software.
¿Por qué es importante? ¿Construiría una casa sin saber más o menos cuánto
gastará, las tareas que necesita realizar y el cronograma para el trabajo que se va
a realizar? Desde luego que no y, dado que la mayoría de los sistemas y productos
basados en computadora cuestan considerablemente más que construir una gran
casa, parece razonable realizar una estimación antes de comenzar a crear el
software.
¿Cuáles son los pasos? La estimación comienza con una descripción del ámbito
del problema. Luego éste se descompone en un conjunto de problemas más
pequeños y cada uno de éstos se estima, usando como guías datos históricos y
experiencia. La complejidad y el riesgo del problema se consideran antes de realizar
una estimación final.
7
¿Cuál es el producto final? La generación de una tabla simple que delinea las
tareas que se van a realizar, las funciones por implementar y el costo, esfuerzo y
tiempo involucrados para cada tarea.
8
El número de personas requeridas para un proyecto de software puede
determinarse sólo después de hacer una estimación del esfuerzo de desarrollo (por
ejemplo, persona-meses). Véase Figura 1 recursos del proyecto.
9
3.5 ANALISIS DE RIESGOS
¿Qué es? El análisis y la administración del riesgo son acciones que ayudan al
equipo de software a entender y manejar la incertidumbre. Muchos problemas
pueden plagar un proyecto de software. Un riesgo es un problema potencial: puede
ocurrir, puede no ocurrir. Pero, sin importar el resultado, realmente es una buena
idea identificarlo, valorar su probabilidad de ocurrencia, estimar su impacto y
establecer un plan de contingencia para el caso de que el problema realmente
ocurra.
10
¿Por qué es importante? Piense en la consigna de los boy scouts: “estar
preparados”. El software es una empresa difícil. Muchas cosas pueden salir mal y,
francamente, muchas con frecuencia lo hacen. Por esta razón es que estar
preparado, comprender los riesgos y tomar medidas proactivas para evitarlos o
manejarlos son elementos clave de una buena administración de proyecto de
software.
¿Cuáles son los pasos? Reconocer qué puede salir mal es el primer paso, llamado
“identificación de riesgos”. A continuación, cada riesgo se analiza para determinar
la probabilidad de que ocurra y el daño que causará si ocurre. Una vez establecida
esta información se clasifican los riesgos, por probabilidad e impacto. Finalmente,
se desarrolla un plan para manejar aquellos que tengan alta probabilidad y alto
impacto.
11
realidad, la implementación puede volverse difícil o imposible. Los riesgos técnicos
identifican potenciales problemas de diseño, implementación, interfaz, verificación
y mantenimiento. Además, la ambigüedad en la especificación, la incertidumbre
técnica, la obsolescencia técnica y la tecnología “de punta” también son factores de
riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver
de lo que se creía. Los riesgos empresariales amenazan la viabilidad del software
que se va a construir y con frecuencia ponen en peligro el proyecto o el producto.
Los candidatos para los cinco principales riesgos empresariales son: 1) construir un
producto o sistema excelente que realmente no se quiere (riesgo de mercado), 2)
construir un producto que ya no encaje en la estrategia empresarial global de la
compañía (riesgo estratégico), 3) construir un producto que el equipo de ventas no
sabe cómo vender (riesgo de ventas), 4) perder el apoyo de los administradores
debido a un cambio en el enfoque o en el personal (riesgo administrativo) y 5) perder
apoyo presupuestal o de personal (riesgos presupuestales). Es extremadamente
importante observar que la categorización simple de riesgos no siempre funciona.
Algunos de ellos son simplemente impredecibles por adelantado. Otra
categorización general de los riesgos es la propuesta por Charette [Cha89]. Los
riesgos conocidos son aquellos que pueden descubrirse después de una evaluación
cuidadosa del plan del proyecto, del entorno empresarial o técnico donde se
desarrolla el proyecto y de otras fuentes de información confiables (por ejemplo,
fecha de entrega irreal, falta de requisitos documentados o ámbito de software,
pobre entorno de desarrollo). Los riesgos predecibles se extrapolan de la
experiencia en proyectos anteriores (por ejemplo, rotación de personal, pobre
comunicación con el cliente, disolución del esfuerzo del personal conforme se
atienden las solicitudes de mantenimiento). Los riesgos impredecibles son el
comodín en la baraja. Pueden ocurrir y lo hacen, pero son extremadamente difíciles
de identificar por adelantado.
12
específicos del producto pueden identificarse solamente por quienes tienen clara
comprensión de la tecnología, el personal y el entorno específico del software que
se construye. Para identificar los riesgos específicos del producto, examine el plan
del proyecto y el enunciado de ámbito del software, y desarrolle una respuesta a la
siguiente pregunta: ¿qué características especiales de este producto pueden
amenazar el plan del proyecto? Un método para identificar riesgos es crear una lista
de verificación de ítem de riesgo. La lista de verificación puede usarse para
identificación del riesgo y así enfocarse sobre algún subconjunto de riesgos
conocidos y predecibles en las siguientes subcategorías genéricas:
1. Tamaño del producto: riesgos asociados con el tamaño global del software
que se va a construir o a modificar.
2. Impacto empresarial: riesgos asociados con restricciones impuestas por la
administración o por el mercado.
3. Características de los participantes: riesgos asociados con la sofisticación de
los participantes y con la habilidad de los desarrolladores para comunicarse
con los participantes en forma oportuna.
4. Definición del proceso: riesgos asociados con el grado en el que se definió el
proceso de software y la manera como se sigue por parte de la organización
desarrolladora.
5. Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de
las herramientas por usar para construir el producto.
6. Tecnología por construir: riesgos asociados con la complejidad del sistema
que se va a construir y con lo “novedoso” de la tecnología que se incluye en el
sistema.
7. Tamaño y experiencia del personal: riesgos asociados con la experiencia
técnica y de proyecto global de los ingenieros de software que harán el trabajo.
13
Puede usar dichas listas de verificación para comprender los riesgos genéricos para
proyectos de software.
La proyección del riesgo, también llamada estimación del riesgo, intenta calificar
cada riesgo en dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real
y 2) las consecuencias de los problemas asociados con el riesgo, en caso de que
ocurra. Usted trabaja junto con otros gerentes y personal técnico para realizar cuatro
pasos de proyección de riesgo:
14
Figura 2 valoración de impacto
Nota:
15
3.5.3 EVALUACIÓN DEL RIESGO
El proceso de evaluación de los riesgos considera cada uno de los riesgos clave
que han sido identificados, así como las estrategias para gestionarlos. Otra vez, no
existe un proceso sencillo que nos permita establecer las evaluaciones de gestión
de riesgos. Depende del juicio y de la experiencia del gestor del proyecto
Los límites entre las regiones de la Figura 3 triangulo de riesgo tienden a moverse
a lo largo del tiempo, debido a expectativas públicas de seguridad y a
consideraciones políticas. Si bien los costes financieros de aceptar los riesgos y de
pagar cualquier accidente que pueda tener lugar pueden ser menores que los costes
de prevención de accidentes. La opinión pública puede demandar que dichos costes
16
adicionales sean aceptados. Por ejemplo, puede ser más barato para una empresa
tratar el problema de la polución en las raras ocasiones en las que ocurra, que
instalar sistemas para prevenir la polución. Esto hubiera sido aceptable en los años
60 y 70, pero probablemente hoy en día no es aceptable pública o políticamente.
En este caso. El límite entre la región intolerable y la región ALARP se ha movido
hacia abajo para que los riesgos que hubieran sido aceptados en el pasado sean
ahora intolerables. La valoración del riesgo comprende la estimación de la
probabilidad y severidad del riesgo. Normalmente éste es muy difícil de llevar a cabo
de forma exacta y generalmente depende de valoraciones de ingeniería. Las
probabilidades y severidades de los riesgos se asignan utilizando términos relativos
tales como probable. Improbable, y raro y alto, medio y bajo. La experiencia previa
en el sistema puede permitir asociar algún valor numérico a estos términos. Sin
embargo, debido a que los accidentes son relativamente poco comunes, es muy
difícil validar la exactitud de este valor
18
2. No existen procesos del software estándar. En las disciplinas de ingeniería
con larga historia, el proceso se prueba y verifica. Para tipos particulares
de sistemas, como puentes o edificios, el proceso de ingeniería se
comprende bien. Sin embargo, los procesos de software varían
notablemente de una organización a otra. A pesar de que la comprensión
del proceso del software se ha desarrollado de forma significativa en los
últimos años, aún no se puede predecir con certeza cuándo un proceso
particular tiende a desarrollar problemas. Esto es especialmente cierto
cuando el proyecto software es parte un proyecto de ingeniería de un
sistema grande.
19
BIBLIOGRAFIA
Pressman, R. (2011). Ingeniería del sofware. Un Enfoque Práctico. 7th ed. Mexico: McGRAW-HILL
INTERAMERICANA EDITORES, S.A. DE C.V.
20