Universidad Politcnica de San Luis Potos

Administracin de Proyectos de Software

M.C. Csar Arturo Guerra G.

Presentacin en: Universidad Autnoma de Baja California
1

Objetivos
Comprender las diferencias entre la administracin de proyectos de software y otros tipos de administracin de ingeniera de proyectos. Conocer las tareas principales de los administradores de proyectos de software. Comprender por qu planear proyectos es esencial en todos los proyectos de software. Conocer la forma en que las representaciones grficas (grficos de barras y redes de actividades) son utilizadas por los administradores de proyectos para representar la calendarizacin del proyecto. Conocer el proceso de administracin de riesgos y algunos de los riesgos que surgen en los proyectos de software.

Tpicos
Actividades de la administracin. Planeacin de proyectos. Calendarizacin del proyecto. Administracin de riesgos.

Introduccin
La necesidad de administrar es una distincin importante entre un desarrollo profesional de software y la programacin no profesional. La administracin de proyectos de software es necesaria debido a que la ingeniera de software profesional siempre est sujeta a las restricciones de presupuesto y calendarizacin; a las que debe ajustarse la organizacin que desarrolla el software. El trabajo del Administrador de Proyectos de software es asegurar que stos cumplan dichas restricciones y entregar software que contribuya a las metas de negocios.

Introduccin..
Los administradores de software son responsables de planeacin y calendarizacin del desarrollo de los proyectos. la

Supervisan el trabajo para asegurar que se lleva a cabo acorde a los estndares requeridos. Supervisan el progreso para comprobar que el desarrollo va en tiempo y acorde al presupuesto. Una buena administracin no garantiza el xito del proyecto. Sin embargo, la mala siempre asegura un fracaso del mismo. El software se entrega tarde, cuesta ms de lo estimado originalmente y falla en el cumplimiento de sus requerimientos.
5

Introduccin
Los administradores de software hacen el mismo tipo de trabajo que otros administradores. Sin embargo, la ingeniera de software es diferente en varios aspectos a otros tipos, lo que hace a la administracin de software particularmente difcil. Algunas de estas diferencias son:
El producto es intangible. No existen procesos de software estndar. A menudo los proyectos grandes de software son nicos.

El producto es intangible
El administrador de un proyecto de construccin de un barco, por ejemplo, puede ver el producto mientras se est desarrollando; si hay un desfase en calendario, el efecto en el producto es visible.

El software es intangible.

Los administradores de software no pueden ver el progreso. Confan en otros para producir la documentacin necesaria para revisar el progreso.

No existen procesos de software estndar

No se tiene una comprensin clara de las relaciones entre el proceso del software y los tipos de productos.

La comprensin del proceso del software se ha desarrollado de forma significativa en los ltimos aos.

Sin embargo, an no se puede predecir con certeza cundo un proceso particular tiende a desarrollar problemas.

A menudo los proyectos grandes de software son nicos.

Por lo general, los proyectos grandes de software son diferentes de proyectos previos. En consecuencia, los administradores aun cuando cuenten con una amplia experiencia que pueda ser utilizada para reducir la incertidumbre en los planes, sta no es suficiente para anticipar los problemas. Los rpidos cambios tecnolgicos en las computadoras y las comunicaciones hacen parecer obsoleta la experiencia previa. Las lecciones aprendidas en esas experiencias pueden no ser transferibles a los nuevos proyectos.

Debido a estos problemas, no es sorprendente que algunos proyectos de software se retrasen, sobrepasen el presupuesto y estn fuera de tiempo. La administracin de proyectos de software es un tema amplio, siendo algunas de sus principales actividades:
La planeacin La calendarizacin de proyectos La administracin de riesgos. Tambin cubre otros aspectos importantes como: - Manejo de personal. - Estimacin de costos de software. - Administracin de la calidad.
10

2.1 Actividades de la Administracin

Es imposible redactar una descripcin estndar del trabajo de un administrador de software. El trabajo difiere dependiendo de la organizacin y del producto de software a desarrollar. Sin embargo, en algn momento, muchos administradores son responsables de algunas o todas de las siguientes actividades.
1. 2. 3. 4. 5. 6.

Redaccin de la propuesta. Planeacin y calendarizacin del proyecto. Costeo del proyecto. Supervisin y revisin del proyecto. Seleccin y evaluacin del personal. Redaccin y presentacin de informes.

11

Redaccin de la propuesta
La primera etapa de un proyecto implica redactar una propuesta para realizar ese proyecto. La propuesta describe los objetivos del proyecto y cmo se llevar a cabo. Por lo general, incluye estimados de costo y calendarizacin. Justifica por qu el contrato del proyecto se le debe de dar a una organizacin o a un equipo en particular.

12

La redaccin de la propuesta es una tarea crtica ya que la existencia de muchas organizaciones de software depende de las propuestas aceptadas y los contratos asignados.

No existen lineamientos para esta tarea; la redaccin de una propuesta es una habilidad que se adquiere por la experiencia.

13

Planeacin y calendarizacin del proyecto

La planeacin de proyectos se refiere a la identificacin de actividades, hitos y entregas producidas por un proyecto.

Por lo tanto, se debe bosquejar un plan para guiar el desarrollo hacia las metas del proyecto.

14

Costeo del proyecto

La estimacin del costo es una actividad relacionada que se refiere al estimado de los recursos requeridos para llevar a cabo el plan del proyecto. La estimacin y la calendarizacin del proyecto se llevan a cabo de forma conjunta. Existen 3 parmetros involucrados en el clculo del costo de un proyecto de desarrollo de software:
Los costos de hardware y software, incluyendo el mantenimiento. Los costos de viajes y capacitacin. Los costos de esfuerzo (pago a los ingenieros de software)

15

Supervisin y revisin del proyecto

La supervisin del proyecto es una actividad continua. El administrador debe tener conocimiento del progreso del proyecto, y comparar los progresos y costos reales con los planeados. Aunque muchas organizaciones tienen mecanismos formales para supervisar, un administrador hbil podra formarse una imagen clara de lo que pasa llevando a cabo una entrevista informal con el personal del proyecto. Con frecuencia, la supervisin informal predice problemas importantes del proyecto, y revela dificultades en su momento.

16

Durante un proyecto, es normal tener varias revisiones formales de su administracin. Se hace la revisin completa del progreso y de los desarrollos tcnicos del proyecto, y se toma en cuenta el estado del proyecto. El tiempo de desarrollo de un proyecto puede llegar a ser bastante grande, durante ese tiempo los objetivos organizacionales pueden llegar a cambiar; lo que significara que el software ya no se requiere ms o que los requerimientos originales del proyecto son inapropiados. La administracin puede decidir parar el desarrollo del software o cambiar el proyecto para adecuarlo a los cambios de los objetivos de la organizacin.

17

Seleccin y evaluacin del personal

Por lo general, los administradores de proyectos tienen que seleccionar a las personas para trabajar en su proyecto. De forma ideal, estar disponible personal con habilidades y experiencia apropiada para trabajar en el proyecto. Sin embargo, en muchos casos los administradores tienen que establecer un equipo ideal mnimo para el proyecto. Las razones para esto son:
El presupuesto del proyecto no cubre la contratacin de personal con sueldos altos. El personal con experiencia apropiada no est disponible dentro o fuera de la organizacin. La organizacin desea desarrollar las habilidades de sus empleados. El personal inexperto puede ser asignado al proyecto para aprender y adquirir experiencia.

18

El administrador del proyecto tiene que trabajar con estas restricciones al seleccionar al personal del proyecto. Sin embargo, todos estos problemas son probables a menos que exista un miembro del proyecto que cuente con algo de experiencia en el tipo de sistema a desarrollar. Sin esta experiencia, probablemente se cometern muchos errores pequeos.

19

Redaccin y presentacin de informes

Por lo general, el administrador del proyecto es responsable de dar informes del mismo tanto al cliente como a las organizaciones contratantes. Dichos administradores deben redactar documentos concisos y coherentes que resuman la informacin crtica de los informes detallados del proyecto. Les debe ser posible presentar esta informacin durante las revisiones de progreso. En consecuencia, comunicarse efectivamente de forma oral y escrita es una habilidad que un administrador de proyectos debe tener.
20

2.2 Planeacin del Proyecto.

La administracin efectiva de un proyecto de software depende de planear completamente el progreso del proyecto. El administrador del proyecto debe anticiparse a los problemas que podran surgir, as como preparar soluciones tentativas a esos problemas. Un plan, preparado al inicio de un proyecto, debe utilizarse como un conductor para el proyecto. Este plan inicial debe ser el mejor posible de acuerdo con la informacin disponible. ste evolucionar conforme el proyecto progrese y la informacin disponible ser mejor.
21

Adems de un plan del proyecto, los administradores tienen que preparar otros tipos de planes, como:

PLAN
Plan de Calidad Plan de validacin

DESCRIPCIN
Describe los procedimientos y estndares de calidad que se utilizarn en un proyecto. Describe el enfoque, los recursos y la programacin utilizados para la validacin del sistema. Describe los procedimientos de administracin de la configuracin y las estructuras a utilizarse. Predice los requerimientos de mantenimiento del sistema, los costos de mantenimiento y el esfuerzo requerido. Describe cmo se desarrollarn las habilidades y experiencia de los miembros del equipo.
22

Plan de administracin de la configuracin Plan de mantenimiento

Plan de desarrollo del personal

La planeacin es un proceso iterativo que solamente se completa cuando el proyecto mismo se termina. Conforme la informacin se hace disponible, el plan debe revisarse regularmente. Las metas globales del negocio son un factor importante que debe considerarse cuando se formula el plan del proyecto. Conforme esto cambie, los cambios en el proyecto sern necesarios.

23

El proceso de planeacin inicia con una valoracin de las restricciones que afectan el proyecto (fecha de entrega requerida, personal disponible, presupuesto global, etc..) sta se lleva a cabo en conjunto con una estimacin de los parmetros del proyecto como su estructura, tamao y distribucin de funciones. Entonces se definen los hitos de progreso y productos a entregar. En ese momento el proceso entra en un ciclo.
Preparar un calendario para el proyecto y las actividades definidas. Se revisa el proyecto y se sealan las discrepancias. Debido a que las estimaciones iniciales son tentativas, el plan siempre deber actualizarse. Si el proyecto se retrasa, tienen que renegociar con el cliente las restricciones del mismo y los productos a entregar.

24

Planeacin del proyecto

Establecer las restricciones del proyecto Hacer la valoracin inicial de los parmetros del proyecto Definir los hitos del proyecto y productos a entregar mientras el proyecto no se haya completado o cancelado, repetir bosquejar la programacin en el tiempo del proyecto iniciar actividades acorde a la programacin esperar (por un momento) revisar el progreso del proyecto revisar los estimados de los parmetros del proyecto actualizar la programacin del proyecto renegociar las restricciones del proyecto y los productos a entregar si (surgen problemas) entonces iniciar la revisin tcnica y la posible revisin fin de si fin de repetir
25

Por supuesto, los administradores de proyectos inteligentes no suponen que todo ir bien. Durante el proyecto siempre surgen problemas en algunas descripciones. Las suposiciones iniciales y el calendario deben ser pesimistas ms que optimistas. Debe haber suficiente holgura para contingencia en el plan como para que las restricciones del proyecto y los hitos no se necesiten negociar cada vez que se efecta un ciclo en el plan.

26

2.2.1 El plan del proyecto

ste fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo. En algunas organizaciones el plan del proyecto es un nico documento que incluye todos los diferentes tipos de planes mencionados anteriormente. Los detalles de este plan varan dependiendo del tipo de proyecto y de la organizacin. Sin embargo, muchos planes incluyen las siguientes secciones:
1. 2. 3. 4. 5. 6. 7.

Introduccin. Organizacin del proyecto. Anlisis de riesgo. Requerimientos de recursos de hardware y software. Divisin del trabajo. Programa del proyecto. Mecanismos de supervisin e informe.
27

1.

Introduccin. Describe brevemente los objetivos del proyecto y expone las restricciones (por ejemplo, presupuesto, tiempo) que afectan la administracin del proyecto.

2.

Organizacin del proyecto. Describe la forma en que el equipo de desarrollo est organizado, la gente involucrada y sus tareas en el equipo. Anlisis de riesgo. Describe los posibles riesgos del proyecto, la probabilidad de que surjan estos riesgos y las estrategias de reduccin de riesgos propuestas.
28

3.

4.

Requerimientos de recursos de hardware y software. Describe el hardware y la ayuda de software requerida para llevar a cabo el desarrollo. Divisin del trabajo. Describe la divisin del proyecto en actividades e identifica los hitos y productos a entregar asociados con cada actividad. Programa del proyecto. Describe las dependencias entre actividades, el tiempo estimado requerido para alcanzar cada hito y la asignacin de la gente a las actividades. Mecanismos de supervisin e informe. describe la administracin de informes y cundo deben producirse, as como los mecanismos de supervisin del proyecto a utilizar.
29

5.

6.

7.

2.2.2 Hitos y productos a entregar.

Cuando se planea un proyecto, se deben establecer una serie de hitos puntos finales de una actividad del proceso de software. En cada uno debe existir una salida formal, como un informe, que se debe presentar al administrador. Los informes de hitos no deben ser documentos amplios, deben ser informes cortos de los logros en una actividad del proyecto. Los hitos deben representar el fin de una etapa lgica en el proyecto. Los hitos indefinidos (como 80% cdigo imposibles de validar y carecen de utilidad. terminado) son

30

Un producto a entregar es el resultado del proyecto que se entrega al cliente. De forma general, se entrega al final de una fase principal del proyecto como la especificacin, el diseo, etc.. Como regla general, los productos a entregar son hitos, pero stos no necesariamente son productos a entregar. Para establecer los hitos, el proceso del software debe dividirse en actividades bsicas con sus salidas asociadas.

31

Hitos en el proceso de requerimientos

Actividades

Estudio de Factibilidad

Anlisis de Requerimientos

Desarrollo del Prototipo

Estudio del Diseo

Especificacin de Requerimientos

Informe de Factibilidad

Requerimientos de usuarios

Reporte de Evaluacin

Diseo de la Arquitectura

Requerimientos Requerimientos Requerimientos del sistema del sistema

HITOS

32

2.3 Calendarizacin del Proyecto

sta es una tarea demandante para los administradores de software. Consiste en estimar el tiempo y los recursos requeridos para completar las actividades y organizarlas en una sucesin coherente. A menos que el proyecto a calendarizar sea similar a uno previo, las estimaciones previas son una base incierta para la calendarizacin del nuevo proyecto. La calendarizacin se complica ms por el hecho de que proyectos diferentes pueden utilizar mtodos de diseo y lenguajes de implementacin diferentes.
33

Si el proyecto es tcnicamente complejo, las estimaciones iniciales casi siempre son optimistas aun cuando los administradores traten de considerar las eventualidades. La calendarizacin del proyecto implica separar todo el trabajo de un proyecto en actividades complementarias y considerar el tiempo requerido para completar dichas actividades. Por lo general, algunas de stas se llevan a cabo en paralelo. Los que establecen el calendario del proyecto deben coordinar las actividades y organizar el trabajo para que la mano de obra se utilice de forma ptima.

34

Identifica Actividades

Identifica dependencias en las Actividades

Estimar Recursos para las Actividades

Asigna Gente para las Actividades

Requerimientos de software Crea grficos del proyecto

Redes de Actividades y grficos de barras

35

Si una tarea no se ha terminado, deben evitarse situaciones crticas de retraso en la totalidad del proyecto. Normalmente, las actividades del proyecto deben durar por lo menos una semana. Hacer subdivisiones ms finas significa invertir una cantidad desproporcionada de tiempo en la estimacin y revisin. Tambin es til asignar una cantidad de tiempo mxima de 8 a 10 semanas para realizar cualquier actividad. Si se lleva ms que esto, se deben hacer subdivisiones.

36

Al estimar la calendarizacin, los administradores no deben suponer que cada etapa del proyecto estar libre de problemas.

Si el proyecto es nuevo y tcnicamente complejo, ciertas partes podran ser ms complicadas y se llevaran ms tiempo del que se estim originalmente.

Como en los calendarios, los administradores deben estimar los recursos necesarios para completar cada tarea (esfuerzo humano, espacio en disco requerido por un servidor, tiempo requerido de hw especializado, presupuesto para viajes de personal, etc..).
37

Una buena regla prctica es estimar como si nada fuera a salir mal, y entonces incrementar la estimacin para cubrir los problemas previstos. A la estimacin se le debe agregar un factor de contingencia adicional. Este factor extra de contingencia depende del tipo de proyecto, de los parmetros del proceso (fecha de entrega, estndares, etc..) y de la calidad y experiencia de los ingenieros de software que trabajen en el proyecto. Como regla, para los problemas previstos siempre debe agregarse 30% a la estimacin original y otro 20% para cubrir algunas cosas no previstas.

38

Por lo general, el calendario del proyecto se representa como un conjunto de grficos que muestran la divisin del trabajo, las dependencias de las actividades y la asignacin del personal. Por lo general, las herramientas de administracin de software, como Microsoft Project, se utilizan para automatizar la produccin de diagramas.

39

2.3.1 Grficos de barras y redes de actividades

Son notaciones grficas que calendarizacin del proyecto. se utilizan para ilustrar la

Los grficos de barras muestran quin es responsable de cada actividad y cundo debe comenzar y finalizar sta.

Las redes de actividades muestran las dependencias entre las diferentes actividades que conforman un proyecto.

40

Duracin y dependencias de las actividades

Task T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duration (days) 8 15 15 10 10 5 20 25 15 15 7 10 Dependencies

T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)
41

En la figura anterior se muestra que la actividad T3 es dependiente de T1, esto significa que T1 debe completarse antes de que de inicio T3. Dadas las dependencias y la duracin estimada de las actividades, una red de actividades muestra la sucesin de actividades que deben generarse. Muestra que actividades se llevan a cabo en paralelo y cules deben ejecutarse en secuencia debido a la dependencia con una actividad previa. La red se debe de leer de izquierda a derecha y de arriba hacia abajo.
42

Redes de actividades
14/7/99 8 days T1 25/7/99 4/7/99 start 15 days T2 10 days T4 18/7/99 M5 25 days T8 19/9/99 Finish
43

15 days T3 5 days T6 4/8/99 M4 15 days T9 25/8/99 M6 7 days T11 11/8/99 M7 15 days T10 5/9/99 M8 10 days T12

M1

M3 20 days T7 25/7/99 M2 10 days T5

El tiempo mnimo requerido para finalizar el proyecto se estima tomando en cuenta la trayectoria ms larga en la red de actividad (la trayectoria crtica). En este ejemplo 55 das laborales. La trayectoria crtica se muestra rectngulos mas resaltados. como una sucesin de

El calendario completo del proyecto depende de dicha trayectoria. Cualquier aplazamiento al completar una actividad crtica provoca retraso en el proyecto. Sin embargo, los retrasos de las actividades que no estn ligadas a la trayectoria crtica no provocan necesariamente un aplazamiento en todo el proyecto.
44

Los administradores tambin utilizan las redes de actividades para asignar los trabajos en el proyecto. Dichas redes pueden dar una percepcin en la dependencia de las actividades que de forma intuitiva no son obvias. Es posible modificar el diseo del sistema de tal forma que se acorte la trayectoria crtica. El calendario del proyecto se puede acortar debido a que se reduce la cantidad de tiempo de espera para finalizar las actividades. La siguiente figura es una forma alternativa de representar la informacin del calendario. Es un grfico de barras que muestra el calendario de un proyecto y las fechas iniciales y finales de las actividades.

45

Barras de actividad
4/7
T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Finish
46

11/7
Start

18/7

25/7

1/8

8/8

15/8

22/8

29/8

5/9

12/9

19/9

Ejercicio
Tarea
Duracin (das)

Dependencias

T1 T2 T3 T4 Disee una red de actividades y un grfico de barras que muestre la programacin del proyecto. T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16

10 15 10 20 10 15 20 35 15 5 10 20 35 10 20 10 T3, T4 T3 T7 T6 T5, T9 T9 T10 T3, T4 T8, T9 T12, T14 T15

47

T1 T1, T2

Asignacin de personas a actividades

Adems de considerar la calendarizacin, los administradores de proyectos tambin deben tomar en cuenta la asignacin de recursos y, en particular, la asignacin de personal a las actividades del proyecto. Tareas T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Ingeniero Jane Anne Jane Fred Mary Anne Jim Fred Jane Anne Fred Fred
48

Asignacin de personal vs diagrama de tiempos

4/7
Fred

11/7

18/7

25/

1/8

8/8

15/8 22/8

29/8

5/9

12/9

19/9

T4
T8
T11
T12

Jane

T1
T3
T9

Anne

T2
T6
T10

Jim Mary

T7
T5
49

El personal no tiene que estar asignado al proyecto todo el tiempo, en los perodos intermedios puede tomar vacaciones, trabajar en otros proyectos, asistir a cursos de capacitacin, etc.. Por lo general, las grandes organizaciones emplean varios especialistas para que trabajen en el proyecto cuando sean requeridos; esto puede provocar problemas en la calendarizacin. Si un proyecto se retrasa mientras que un especialista trabaja en l, puede provocar efectos contundentes en los otros proyectos.

50

2.4 Administracin de Riesgos

Una tarea importante del administrador de proyectos es anticipar los riesgos que podran afectar la programacin del proyecto o la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. Los resultados de este anlisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el anlisis de consecuencias cuando el riesgo ocurra. Identificar stos y crear planes para minimizar sus efectos en el proyecto se llama administracin de riesgos. De forma simple, se puede concebir un riesgo como una probabilidad de que una circunstancia adversa ocurra.
51

Los riesgos son una amenaza para el proyecto, para el software que se est desarrollando y para la organizacin. Categoras de riesgos:
1.

Los riesgos del proyecto, stos afectan la calendarizacin o los recursos del proyecto. Los riesgos del producto, stos que afectan la calidad o desempeo del software que se est desarrollando. Los riesgos del negocio, stos afectan a la organizacin que desarrolla el software.

2.

3.

52

La administracin de riesgos es importante particularmente para los proyectos de software debido a las incertidumbres inherentes que enfrentan muchos proyectos.

Estas incertidumbres son el resultado de:

definir pobremente los requerimientos dificultades en la estimacin de tiempos dificultades en la asignacin de recursos para el proyecto. dependencia en las habilidades individuales cambios en los requerimientos

53

El administrador de proyectos debe:

Anticiparse a los riesgos. Comprender el impacto de stos en el proyecto, en el producto y en el negocio. Considerar los pasos para evitarlos.

En el caso de que ocurran, se deben crear planes de contingencia para que sea posible aplicar planes de recuperacin. Los tipos de riesgos que pueden afectar un proyecto dependen de ste y el entorno organizacional en el que se est desarrollando el mismo. Sin embargo, muchos riesgos son universales.

54

Riesgos posibles en el software

Risk Staff turnover Management change Risk type Project Project Description Experienced staff will leave the project before it is finished. There will be a change of organisational management with different priorities. Hardware which is essential for the project will not be delivered on schedule. There will be a larger number of changes to the requirements than anticipated. Specifications of essential interfaces are not available on schedule The size of the system has been underestimated. CASE tools which support the project do not perform as anticipated The underlying technology on which the system is built is superseded by new technology. A competitive product is marketed before the system is completed.

Hardware unavailability

Project

Requirements change

Project and product Project and product Project and product Product Business

Specification delays Size underestimate CASE tool underperformance Technology change

Product competition

Business

55

El proceso de administracin de riesgos comprende varias etapas:

1.

Identificacin de riesgos. Identificar los posibles riesgos para el proyecto, el producto y los negocios. Anlisis de riesgos. Valorar las probabilidades y consecuencias de estos riesgos. Planeacin de riesgos. Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar sus efectos en el proyecto. Supervisin de riesgos. Valorar los riesgos de forma constante y revisar los planes para la mitigacin de riesgos tan pronto como la informacin de los riesgos est disponible.
56

2.

3.

4.

El proceso de administracin de riesgos

Es un proceso iterativo que se aplica a lo largo de todo el proyecto.

Risk identification

Risk analysis

Risk planning

Risk monitoring

List of potential risks

Prioritised risk list

Risk avoidance and contingency plans

Risk assessment

La prevencin de riesgos y los planes de contingencia se deben modificar tan pronto como surja nueva informacin de los riesgos.
57

2.4.1 Identificacin de riesgos

sta es la primera etapa de la administracin de riesgos. Comprende el descubrimiento de los posibles riesgos del proyecto. En principio, no se les debe valorar o priorizar en esta etapa aunque, en la prctica, por lo general no se consideran los riesgos con consecuencias menores o con baja probabilidad. Esta identificacin se puede llevar a cabo a travs de un proceso de grupo utilizando un enfoque de lluvia de ideas o simplemente puede basarse en la experiencia del administrador. Para ayudar al proceso, se utiliza una lista de posibles tipos de riesgos.
58

Tipos de riesgos
Riesgos de tecnologa.
Estos se derivan de las tecnologas de software o de hardware utilizadas en el sistema que se esta desarrollando.

Riesgos de personas.
Riesgos asociados con las personas en el equipo de desarrollo.

Riesgos organizacionales.
stos se derivan del entorno organizacional.

59

Riesgos de herramientas.
stos se derivan de herramientas CASE y de otro software de apoyo utilizado para desarrollar el sistema.

Riesgos de requerimientos.
stos se derivan de los cambios en los requerimientos del cliente y el proceso de administrar dicho cambio.

Riesgos de estimacin.
stos se derivan de los estimados administrativos de las caractersticas del sistema y los recursos requeridos para construir dicho sistema.

60

Risk type Technology

People

Organisational

Tools Requirements

Estimation

Possible risks The database used in the system cannot process as many transactions per second as expected. Software components which should be reused contain defects which limit their functionality. It is impossible to recruit staff with the skills required. Key staff are ill and unava ilable at critical times. Required training for staff is not available. The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget. The code generated by CASE tools is inefficient. CASE tools cannot be integrated. Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes. The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.
61

2.4.2 Anlisis de riesgos

Durante este proceso, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo. No existe una forma fcil de hacer esto, recae en la opinin y experiencia del administrador del proyecto. No se hace una valoracin con nmeros precisos sino en intervalos:
La probabilidad de que el riesgo se valore como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%). Los efectos del riesgo pueden ser valorados como catastrfico, serio, tolerable o insignificante.

62

El resultado de este proceso se debe colocar en una tabla, la cual debe estar ordenada acorde a la seriedad del riesgo. Obviamente, la valoracin de la probabilidad y seriedad es arbitraria. En la prctica, para hacer esta valoracin se necesita informacin detallada del proyecto, el proceso, el equipo de desarrollo y la organizacin. Tanto la probabilidad y la valoracin de los efectos de un riesgo cambia conforme se disponga de mayor informacin acerca del riesgo y los planes de administracin del mismo se implementen. Por lo tanto esta tabla debe actualizarse durante cada iteracin del proceso de riesgos.

63

Se recomienda identificar y supervisar los 10 riesgos ms altos. Sin embargo, el nmero exacto de riesgos a supervisar depende del proyecto. Pueden ser 5 o 10, no obstante el nmero apropiado debe ser manejable; un nmero muy grande de riesgos requiere obtener mucha informacin. La siguiente tabla muestra algunos ejemplos de riesgos ms comunes:

64

Risk Organ isa tiona l f in anc ial p rob lem s fo rce reduc tions in the projec t budge t. It is im pos sib le to rec ruit st aff with the sk ill s requ ired for the p rojec t. Key staff are ill at c rit ical tim es in the p rojec t. Sof tware co m ponen ts wh ich shou ld be reu sed con tain de fec ts wh ich limit the ir func tiona lit y. Ch anges to requ irem en ts wh ich requ ire m ajor de si gn rewo rk a re propo sed. The o rgan isat ion is restruc tur ed so tha t d iff er ent m anage me nt are respons ible fo r th e p rojec t. The da ta base us ed in the sy st em canno t p roce ss as m any tran sac tions pe r second as expec ted . The tim e requ ired to deve lop the softw ar e is unde res tim ated . CA SE too ls canno t be in teg rated . Cu st om er s fail to unde rstand the im pa ct o f requ irements change s. Requi red train ing fo r staff is no t av aila bl e. The rate of de fec t repa ir is und ere stim ated. The size o f t he sof tware is unde res tim ated . The cod e gen era ted by C ASE too ls is i ne ffi cien t.

Pro bab ilit y Eff ec ts Low Catastroph ic High Mod era te Mod era te Mod era te High Mod era te High High Mod era te Mod era te Mod era te High Mod era te Catastroph ic Serious Serious Serious Serious Serious Serious Tol erab le Tol erab le Tol erab le Tol erab le Tol erab le Ins ign ifican t
65

2.4.3 Planeacin de riesgos

Este proceso considera cada uno de los riesgos identificados y las estrategias para administrarlo. clave No existe un proceso sencillo a seguir para establecer los planes de administracin de riesgos; recae en el juicio y experiencia del administrador del proyecto. Posibles estrategias identificadas para los riesgos:
1. 2. 3.

Estrategias de anulacin. Estrategias de disminucin. Planes de contingencia.

66

Estrategias de riesgos
Estrategias de anulacin. Seguir stas significa reducir la probabilidad de que ese riesgo surja. Un ejemplo es la estrategia para abordar los componentes defectuosos como: componentes defectuosos, problemas de reclutamiento, etc.. Estrategias de disminucin. Seguir stas significa reducir el impacto del riesgo. Por ejemplo, formular una estrategia para abordar las enfermedades del personal. Planes de contingencia. seguir stas significa que, si sucede lo peor, se est preparado para ello y se cuenta con una estrategia para abordarlo. Un ejemplo es la estrategia para los problemas de organizacin financiera.
67

Riesgo
Problemas financieros de la organizacin Problemas de reclutamiento Enfermedad del personal Componentes defectuosos Cambios en los requerimientos Reestructuracin organizacional Desempeo de las bases de datos. Tiempo de desarrollo subestimado.

Estrategia
Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio. Alertar al cliente de las dificultades potenciales y las posibilidades de retraso. Reorganizar el equipo de tal forma que haya traslape en el trabajo y las personas comprendan el de los dems. Reemplazar los componentes defectuosos con los comprados de fiabilidad conocida. Rastrear la informacin para valorar el impacto de los requerimientos, maximizar la informacin oculta en ellos. Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio. Investigar la posibilidad de comprar una base de datos con alto desempeo. Investigar los componentes comprados y la utilizacin de un generador de programas. 68

2.4.4 Supervisin de riesgos

sta normalmente valora cada uno de los riesgos identificados para decidir si ste es ms o menos probable y cundo los efectos del mismo han cambiado. Esto no se puede observar de forma directa, por lo que se tienen que buscar otros factores para dar indicios de la probabilidad del riesgo y sus efectos. La supervisin de riesgos debe ser un proceso continuo y, en cada revisin del progreso de la administracin, cada uno de los riesgos clave debe ser considerado por separado y discutido. Algunos ejemplos de los factores que ayudan en la valoracin de estos tipos de riesgos se muestran enseguida.
69

Tipo de Riesgo
Tecnologa

Indicadores Potenciales
Entrega retrasada del hardware o de la ayuda al software, muchos problemas tecnolgicos reportados.

Personas

Baja moral del personal, malas relaciones entre los miembros del equipo, disponibilidad de empleo.

Organizacional

Chismorreo organizacional, falta de acciones por el administrador principal.

Herramientas

Rechazo de los miembros del equipo para utilizar herramientas, quejas acerca de las herramientas CASE, peticiones de estaciones de trabajo mas potentes. Peticiones de muchos cambios en los requerimientos, quejas del cliente.

Requerimientos

Estimacin

Fracaso en el cumplimiento de los tiempos acordados, y en la eliminacin de defectos reportados.

70

Gracias !
Contacto:
guerra@upslp.edu.mx

71