PROFESORA M.T.I.

MONTSERRAT MASDEFIOL SUAREZ

CARRERA ING. EN SISTEMAS COMPUTACIONALES

MATERIA GESTIN DE PROYECTOS DE SOFTWARE

TRABAJO APUNTES DE UNIDAD 3

ALUMNO

SERRANO BLAS, EPIFANIO

GRUPO 704 A

SAN ANDRS TUXTLA, VER., 20 DE SEPTIEMBRE DEL 2013

Contenido
UNIDAD 3 PLANIFICACIN DEL PROYECTO. .................................................................... 4 Objetivo de la unidad: ..................................................................................................... 4 Criterios de evaluacin: .................................................................................................. 4 Temario:.......................................................................................................................... 4 Objetivo del proyecto .............................................................................................................. 5 Qu es un proyecto? .................................................................................................... 5 Qu es gestin de un proyecto? .................................................................................. 5 Dimensiones de un proyecto .......................................................................................... 6 Fases de un proyecto ..................................................................................................... 6 Metas y objetivos ............................................................................................................ 8 El QUE del proyecto. ...................................................................................................... 8 Objetivos generales y especficos ................................................................................ 10 ESTIMACIONES DE TIEMPO.............................................................................................. 12 QUIEN LO HACE? ......................................................................................................... 13 CALENDARIZACIN DEL PROYECTO .......................................................................... 13 CONSIDERACIONES ...................................................................................................... 14 EJEMPLO DE CALENDARIZACIN ............................................................................... 14 REGLA 40-20-40 .............................................................................................................. 15 CRONOGRAMA ............................................................................................................... 16 RUTA CRTICA............................................................................................................. 21 Diferencias entre los mtodos pert y cpm .................................................................... 22 PERT .................................................................................................................................... 22 CPM ...................................................................................................................................... 22 USOS. ........................................................................................................................... 23 VENTAJAS PERT y CPM ............................................................................................. 23 PROCEDIMIENTO PARA TRAZAR UN MODELO DE RED ........................................... 24 MTODO PERT (Program Evaluation and Review Technique) ...................................... 26 PASOS EN EL PROCESO DE PLANEAMIENTO DEL PERT ..................................... 27 VENTAJAS DEL PERT ................................................................................................ 30 LIMITACIONES ............................................................................................................ 31 ESTIMACIONES .................................................................................................................. 32 ESTIMACIN PARA PROYECTOS DE SOFTWARE ......................................................... 35

OBSERVACIONES ACERCA DE LA ESTIMACIN ....................................................... 36 EL PROCESO DE PLANIFICACIN DEL PROYECTO ............................................... 37 MBITO DEL SOFTWARE Y FACTIBILIDAD ................................................................. 37 RECURSOS ..................................................................................................................... 39 ESTIMACIN DE COSTOS DE SOFTWARE ..................................................................... 42 TCNICAS DE DESCOMPOSICIN .............................................................................. 43 ANLISIS DE RIESGOS ...................................................................................................... 53 ANLISIS Y GESTIN DE RIESGOS ................................................................................. 53 ESTRATEGIAS DE RIESGO REACTIVAS Y PROACTIVAS .............................................. 53 RIESGOS DEL SOFTWARE ................................................................................................ 54 PRINCIPIOS DE LA GESTIN DE RIESGOS ..................................................................... 56 PROCESO DE ANLISIS DE RIESGOS ............................................................................. 56 1) IDENTIFICACIN DE RIESGOS .............................................................................. 56 Evaluacin del riesgo global del proyecto ........................................................................ 64 Componentes y controladores del riesgo ......................................................................... 65 2) PROYECCIN DE RIESGOS ................................................................................... 66 Desarrollo de una tabla de riesgos ................................................................................... 67 Evaluacin del impacto del riesgo .................................................................................... 69 3) 4) REFINAMIENTO DEL RIESGO ................................................................................ 71 REDUCCIN, SUPERVISIN Y GESTIN DEL RIESGO ...................................... 72

EL PLAN RSGR ................................................................................................................... 76 ESQUEMA DEL PLAN RSGR .............................................................................................. 78 ESTUDIO DE FACTIBILIDAD O VIABILIDAD ..................................................................... 79 Definicin de factibilidad ................................................................................................... 79 Definicin del anlisis de la factibilidad del proyecto ....................................................... 79 Tipos de Factibilidad ......................................................................................................... 79 Anlisis del sistema .......................................................................................................... 80 Identificacin de las necesidades ..................................................................................... 81 ESTUDIO DE FACTIBILIDAD O VIABILIDAD ..................................................................... 82 Anlisis Econmico .......................................................................................................... 85 Anlisis Tcnico ................................................................................................................ 92 Anlisis Operativa ............................................................................................................. 95 Anlisis Legal.................................................................................................................... 96 Anlisis Organizacional .................................................................................................... 96

UNIDAD 3 PLANIFICACIN DEL PROYECTO.

Objetivo de la unidad: Planificar un proyecto de software desde la definicin del objetivo, la estimacin de tiempos, costos y personal requerido, identificando la existencia de riesgos y proponiendo acciones para reducir su impacto en el negocio, hasta el anlisis de la viabilidad del mismo.

Criterios de evaluacin:
Reporte de investigacin Exposicin Avance del proyecto 35% 25% 40%

Temario:
3.1 Objetivo del proyecto 3.2 Estimaciones de tiempo 3.3 Estimaciones de costo 3.4 Estimacin de personal requerido 3.5 Anlisis de riesgo 3.6 Anlisis de la viabilidad del proyecto.

OBJETIVO DEL PROYECTO

Qu es un proyecto?
Proceso nico, consistente en un conjunto de actividades, planificadas, coordinadas, ejecutadas y controladas para alcanzar unos objetivos conforme a unos requerimientos especficos y a unas restricciones de tiempo costo y recursos. Caractersticas bsicas: Temporal, debe estar delimitado entre una fecha de inicio y otra de finalizacin. Se obtiene uno o varios objetivos claros. Existe uno o varios objetivos claros. Se pueden identificar una seria de tareas que necesarias y que no son habituales. El proyecto no es un servicio de la empresa. Las tareas tienen que realizarse de forma ordenada. Es necesaria la intervencin de varias personas. Se utilizan recursos de diversos tipos. Recursos y presupuesto limitados. El objetivo se debe alcanzar en un plazo de tiempo. Requiere una planificacin. El producto final tiene que cumplir unas especificaciones.

Qu es gestin de un proyecto?
Gestionar es aplicar conocimientos, tcnicas y herramientas a un proyecto concreto, con el fin de alcanzar los objetivos del mismo. Abarca 2 mbitos: rea de trabajo rea de conocimientos.
5

Dimensiones de un proyecto.
Bsicamente podemos hablar de 4 dimensiones: Tcnica: En la que se busca el resultado vaya acorde a lo que se pidi. Econmica: Son los aspectos referentes al equilibrio financiero de un proyecto para que sea viable. Comercial: La imagen que se genera en un proyecto afecta los clientes potenciales para futuros proyectos. Estratgica: Ya que el proyecto permite adquirir experiencia, tecnologas y otros elementos que le permitirn seguir compitiendo en un mercado.

Fases de un proyecto
Un proyecto pasa a travs de 4 fases identificables: 1. Concepcin del proyecto: Es cuando surge una idea nueva, que podra ser un nuevo producto, un nuevo mercado o un nuevo proceso, lo cual muy posiblemente lleve a la investigacin, desarrollo, construccin o instalacin de nuevos elementos y que al ser considerados viables hacen surgir el proyecto. 2. Desarrollo: Una vez es considerado viable en la fase concepcin se pasa a desarrollarlo, que significa hacer la planificacin detallada del proyecto y la su programacin estableciendo unas fechas de inicio y terminacin. 3. Realizacin: Es la fase en la cual se realiza todo lo referente a la admn y el control del proyecto, tanto la gerencia del proyecto como el cliente estn permanentemente informados del progreso del proyecto, costos y gastos, cumplimiento y eventualidades.
6

4. Terminacin o puesta en marcha: Es cuando se hacen las pruebas finales, se pone en funcionamiento lo que se estaba desarrollado y concluye el proyecto como tal.

De esta fase se obtiene informacin importante como son eficiencia de los mtodos utilizados, de los equipos de trabajo y calidad de los proveedores si los hubiere.

Definicin del problema: Un problema existe cuando hay 3 elementos, cada uno claramente definido.

Una situacin inicial. Una situacin final u objetivo a alcanzar. Restricciones o pautas respecto de mtodos, actividades, tipos de operaciones, etc., sobre los cuales hay acuerdos previos.

Resolver un problema implica realizar tarea que demandan procesos de razonamientos ms o menos complejos y no implemente una actividad asociativa y rutinaria. En todo proceso de decisiones se hace sumamente importante definir muy claramente cul es el problema de decisin. Es comn que los clientes no sepan que es lo que realmente desean. Ayuda a definir el problema en proyectos de software:

Identificar al respecto del proyecto. Analizar requerimientos con el usuario. Realizacin de prototipos. Documentacin cerrada con las especificaciones.

Metas y objetivos
Es necesario que una vez definido el problema sean definidos unos objetivos a ser alcanzados. Realmente en todo proceso de desarrollo se necesitan objetivos a hacer alcanzados. Puede ser uno o varios objetivos. Una vez establecidos los objetivos se deben definir las metas o pasos a cumplir para llegar a dichos objetivos. Las metas y objetivos ayudan a establecer que actividades han de ser desarrolladas.

Definicin objetivo

del

Evaluacin decisin

Gestin realizacin proyecto.

de

la del

Que del proyecto

El QUE del proyecto.

Objetivo: Expresin concreta del resultado a obtener en trminos de: alcance, desempeo, tiempo y costo. Que resultado debo lograr concretamente durante la ejecucin del proyecto para alcanzar el OBJETIVO GLOBAL. Objetivos especficos: Se debe definir especficamente el que debo lograr con la ejecucin del proyecto para alcanzar el objetivo general. Cada objetivo especfico que defina consumir recursos para alcanzarse.
8

Caractersticas: Concreto, no generales. Verificable objetivamente que se alcanz el objetivo Realista y alcanzables. Consiste con los recursos disponibles o previstos. Consistentes con los planes, polticas y procedimientos de la empresa.
No excesivamente complejos.

Entregables Cmo alcanzo los objetivos especficos? Qu debo tener al final del proyecto para decir que cada objetivo especfico se alcanz?

Entregables Resultados tangibles y verificables que marcan que uno o varios objetivos se alcanzaron. Estn relacionados con el como voy a realizar el proyecto. Qu producto voy a entregar para alcanzar el objetivo?

Definicin del alcance. Subdivisin de proyecto en entregables ms pequeos y manejables tal que: Permita asegurar costo, tiempo y recursos estimados. Definir una lnea de base para medir y controlar performance. Facilitar una clara. Que son los objetivos del proyecto? Los objetivos son los propsitos del proyecto. Son los elementos segn los cuales un proyecto es organizado.
9

Generalidades Un objetivo debe responder claramente la pregunta: Qu es lo que pretende nuestro trabajo? Los objetivos deben estar muy bien definidos. Los objetivos deben expresarse con claridad para evitar posibles desviaciones del proceso de desarrollo. Los objetivos deben ser `posibles de alcanzarse. Los objetivos deben ser de Alta calidad, deben ser finitos. Cada objetivo debe de tener un indicador.

Tipos de objetivos.

Objetivos generales y especficos.

Responden a una accin. Se redacta con un infinitivo. Se refiere a uno o varios objetivos.

Objetivo general Es le impacto directo que se lograra como resultado de la aplicacin del mtodo cientfico en la resolucin de un problema concreto. Responde a la pregunta: Para qu hacer el proyecto? Normalmente este objetivo es individual. Enmarca los alcances del proyecto en forma global. Tiene estrecha relacin con el problema resolver y su solucin.

10

Objetivos especficos Generalmente existen muchos objetivos especficos. Estos objetivos enmarcan todas aquellas acciones, que se convierten en los propsitos especficos que el proyecto debe alcanzar y cuya sumatoria lleva, sin duda alguna, a la obtencin del objetivo general y por ende a la solucin del problema. Responden a la pregunta Qu es lo que el proyecto pretende alcanzar? Deben ser 100% verificables. Deben exponer alta calidad. Deben ser finitos. Debe plantarse una metodologa para alcanzarlos. Deben ser escogidos cuidadosamente para no saturar la formulacin del proyecto con gran cantidad de acciones que no tienen una

importancia trascendental.

No hay que confundir los objetivos con las actividades del proyecto.

Partes de un objetivo

El objetivo est compuesto por: Una accin Un producto Un resultado Se inicia con un verbo. Despus se describe el fenmeno Luego a quien para tener una finalidad.

11

ESTIMACIONES DE TIEMPO
La realidad de un proyecto tcnico, tal como uno de software, es que hay que realizar cientos de tareas pequeas en un orden determinado antes de poder alcanzar la meta final. Las tareas estn interrelacionadas en una secuencia lgica en el sentido de que algunas de ellas no pueden empezar hasta que otras se hayan terminado. Algunas tareas se encontrarn en el camino principal (ruta crtica), de manera que si una de estas tareas crticas se retrasa, la fecha de terminacin del proyecto se pone en peligro. El administrador o lder del proyecto debe definir todas las tareas del proyecto, identificar las que son crticas y hacerles un seguimiento para

asegurarse de que un retraso se pueda reconocer de inmediato. Para conseguir esto el administrador debe hacer un plan calendarizado para supervisar y

controlar el proyecto. Elaborar un plan calendarizado de un proyecto de software es una actividad que distribuye el esfuerzo estimado a lo largo de la duracin prevista del proyecto, asignando el esfuerzo a las tareas especficas de la ingeniera de software. Es crear una red de tareas de ingeniera de software que permitan tener el trabajo justo a tiempo, esta red debe tener responsabilidades asignadas, asegurarse que dichas tareas se realicen y adaptar la red conforme los riesgos se tornen en realidad.

Existen distintos principios bsicos que guan la calendarizacin del proceso: Compartimentacin: El proyecto debe dividirse en compartimientos en varias actividades, acciones y tareas manejables. Interdependencia: Se debe de determinar la accin o tarea compartida, algunas tareas deben ocurrir en secuencia mientras que otras pueden ocurrir en paralelo.

12

 Asignacin de tiempo: A cada tarea por calendarizar se le debe asignara cierto nmero de unidades de trabajo (Persona, da, esfuerzo).

Validacin de esfuerzo: Todo proyecto tiene un nmero definido de personas en el equipo de software. Definicin de responsabilidades: Toda tarea calendarizada se le debe asignar a un miembro especfico del equipo. Definicin de resultados: Toda tarea calendarizada debe tener un resultado definido. Definicin de hitos: Cualquier tarea o grupo de tareas debe estar asociado con un hito del proyecto. Un hito se logra cuando se ha revisado la calidad de uno o ms de los productos de trabajo. Existe el mito que al agregar personas a un proyecto atrasado este puede finalizarse en el tiempo estimado con xito, esto es muchas veces mentira ya que las nuevas personas primero deben ponerse al corriente y los que previamente estn involucrados deben ensear a los nuevos, si se desea agregar personas a un proyecto se debe observar que la tarea sea altamente compartimentada. QUIEN LO HACE? En el mbito del proyecto los gestores del proyecto de software emplean la informacin solicitada a los ingenieros de software. En el plano individual, los mismos ingenieros de software.

CALENDARIZACIN DEL PROYECTO

Primero se selecciona el modelo de proceso apropiado Identificacin de tareas Estimacin de cantidad de trabajo y no PERSONAS Se conoce la fecha limite Se identificaron riesgos Entonces crear una red de trabajo que permita tener el trabajo listo a tiempo. Una vez creada la red se asignan responsabilidades a cada tarea y asegurarse de realizarlas.

13

 Se

le

llama

CALENDARIZACIN

SEGUIMIENTO

DEL

PROYECTO DE SOFTWARE CONSIDERACIONES Estimar la complejidad del problema y los costos de desarrollo de la solucin. La productividad no es proporcional al nmero de personas que trabaja en una tarea. Agregar personas a un proyecto atrasado no soluciona los problemas. Lo inesperado siempre ocurre. Siempre debe considerarse las contingencias en la planificacin. La calendarizacin se revisa cuando se refinan estimaciones, cuando cambian restricciones o cuando se reasignan recursos.

EJEMPLO DE CALENDARIZACIN

14

REGLA 40-20-40
Esta es una regla que usualmente se sigue, en la cual se asigna el 40% del esfuerzo al anlisis y diseo de software, el 20% del esfuerzo a la codificacin y el ultimo 40% a la realizacin de pruebas del sistema, esta distribucin se utiliza como gua, la distribucin final del proceso la dictan las caractersticas del proyecto existen distintos tipos de proyectos de software entre ellos. Proyectos de desarrollo de concepto Proyectos de desarrollo de nuevas aplicaciones Proyectos de mejora de aplicacin Proyectos de mantenimiento de aplicacin Proyectos de reingeniera Dependiendo del tipo de proyecto y actividades dentro del proyecto se pueden seleccionar el tipo de tareas que se realizaran.

Una red de tarea es una representacin grafico de flujo de tareas del proyecto

Es importante siempre encontrar la ruta crtica estas son las tareas que se deben completar la calendarizacin si el proyecto como un todo se debe completar a tiempo.

15

CRONOGRAMA
Un cronograma o grafico de Gantt permite determinar que tareas se realizan en un punto de tiempo dado, es posible crear un cronograma general y luego crear cronogramas para cada actividad o tarea. El seguimiento del calendario puede hacerse de diferentes maneras realizando reuniones peridicas haciendo evaluaciones de los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniera de software Determinando si se han logrado los hitos en las fechas establecidas comprobando la fecha real con la fecha de inicio prevista para cada actividad. En el mbito del proyecto los gestores del proyecto de software emplean la informacin solicitada a los ingenieros de software y en el plano individual, los mismos ingenieros de software.

16

En la construccin de un sistema complejo muchas tareas de ingeniera de software ocurren en paralelo, y el resultado del trabajo realizado durante una tarea puede tener un profundo efecto en el trabajo llevado a cabo en otras tareas. Estas interdependencias son muy difciles de comprender sin una calendarizacin. Al igual que es imposible evaluar el progreso de un proyecto de software moderado y grande sin una calendarizacin. A cada tarea se le asigna esfuerzo y duracin y se crea una red de tareas (Tambin llamada red de actividad) de tal forma que permitir al equipo de software cumplir con la fecha lmite de entrega especificada. La calendarizacin adecuada requiere: 1. Todas las tareas aparezcan en la red. 2. El esfuerzo y el tiempo este asignado de manera inteligente en cada tarea. 3. Las interdependencias entre tareas estn indicadas adecuadamente. 4. Los recursos estn asignados para el trabajo que se realizara. 5. Los hitos estn espaciados de modo cercano para que se pueda seguir el progreso.

17

Razones por las que el software se entrega con retraso: Una fecha limite irrealizable Cambio en los requisitos del cliente Subestimacin razonable de la cantidad de esfuerzo o de recursos Riesgos predecibles o impredecibles que no se consideraron Dificultades tcnicas Dificultades humanas Falta de comunicacin Falla en la gestin del proyecto Que hacer antes de aceptar un proyecto: Realizar una estimacin detallada empleando datos histricos de proyectos previos aplicar un modelo de proceso incremental y documentar el plan Reunirse con el cliente, y con la estimacin detallada, explicar porque la fecha lmite impuesto es irrealizable. Ofrezca la estrategia de desarrollo incremental como alternativa: 1. Aumentar el presupuesto y conseguir recursos adicionales aunque esto aumentara el riesgo de una calidad deficiente debido a la fecha apretada de entrega. 2. Remover varias de las funciones y capacidades del software aunque la versin del producto sea un poco menos funcional. 3. Prescindir de la realidad y esperar que el proyecto se cumpla en la fecha indicada. La realidad de un proyecto tcnico es que cientos de pequeas tareas deben de realizarse para lograr una meta mayor, algunas de las tareas estn fuera de la corriente principal y se pueden completar sin preocuparse acerca de su impacto sobre la fecha de terminacin del proyecto, otras tareas se encuentran en la trayectoria crtica y si estas tareas se retrasan en la calendarizacin se pone en riesgo la fecha de terminacin del proyecto.
18

El gestor debe de tener un calendarizacin que permita supervisar el progreso y controlar el proyecto. La calendarizacin del proyecto de software es una actividad que distribuye estimaciones de esfuerzo a travs de la duracin planificada del proyecto al asignar el esfuerzo a tareas especficas. La calendarizacin evoluciona a lo largo del tiempo: Calendarizacin macroscpica: De identifican las principales

actividades del marco de trabajo del proceso y las funciones de producto a las que se aplican. Calendarizacin detallada: Se identifican y calendarizan tareas especficas del software (Requeridas para completar una actividad). Una calendarizacin demasiado optimista no genera una calendarizacin real ms corta, sino una mayor. Cuando se desarrolle una calendarizacin, compartimntese el trabajo, antense las interdependencias de las tareas, asgnese esfuerzo y tiempo a cada tarea, defnase responsabilidades, resultados e hitos. El desarrollo de una calendarizacin del proyecto requiere distribuir un conjunto de tareas a lo largo de la lnea del tiempo del proyecto. Aunque es difcil desarrollar una taxonoma completa de tipos de proyectos de software, en la mayora de las organizaciones se encuentran las siguientes: Proyectos de desarrollo del concepto, los cuales se inician para explorar algunas aplicaciones o conceptos de negocios de alguna nueva tecnologa. Proyectos de nuevas aplicaciones, los cuales se llevan a cabo como secuencia de una solicitud especifica del cliente. Proyectos de mejora de la aplicacin, estos ocurren cuando el software existente experimenta grandes modificaciones en la funcin, el desempeo o las interfaces visibles para el usuario final.
19

Proyectos de mantenimiento de aplicacin, los cuales corrigen, adaptan o extienden el existente en forma que no sea obvio inmediatamente para el usuario final. Proyectos de reingeniera, estos se llevan a cabo con la finalidad de reconstruir un sistema existente (heredado), en todo o en parte. Los proyectos de desarrollo del concepto se inician cuando se debe explorar el potencial para alguna nueva tecnologa: La determinacin del mbito del concepto precisa el mbito global, la planeacin preliminar del concepto establece la habilidad de la organizacin para cometer el trabajo que entraa el mbito del proyecto. La valoracin del riesgo de la tecnologa evala el riesgo asociado que se implementara como parte del mbito del proyecto y l aprueba del concepto demuestra la viabilidad de una nueva tecnologa en el contexto del software, la implementacin del concepto pone en prctica la representacin del concepto en una forma que pueda revisarla un cliente.
La reaccin del cliente solicita retroalimentacin acerca de un

concepto de nueva tecnologa y se dirige a aplicaciones especficas de los clientes. Una red de tareas o tambin denominada red de actividad, es una representacin grfica del flujo de tareas en un proyecto y es un mecanismo til para bosquejar las dependencias entre tareas y determinar la ruta crtica. Se le puede dar seguimiento a la calendarizacin a travs de reuniones para valorar el estado del proyecto en las cuales cada uno de los miembros del equipo informa del progreso y los problemas o con la evaluacin de resultados de todas las revisiones realizadas a lo largo del proceso de ingeniera del software.

20

En la calendarizacin de un proyecto de software se utiliza la tcnica de evaluacin y revisin programada PERT y CPM, tcnicas que reciben impulso de la informacin ya desarrollada en actividades tempranas de la planeacin del proyecto. Estimacin del esfuerzo. Descomposicin de la funciones del producto. Seleccin del modelo de proceso y conjunto de tareas apropiados Descomposicin de tareas Cronogramas: Tambin llamado grafica de Gantt, ya sea que se desarrollen para cada actividad o para cada funcin o para todo el proyecto

RUTA CRTICA

RED DE ACTIVIDADES
1 4/9/0 M 1 T 1 /9/0 INICI O 5 T2 1 2 5/9/0 3 0 T 7 T11 M 2 T6 4 3 5 T /10/0 M 4 1 5 T 9 2 5/10/0 M6 1

1 0 T4

2 5/9/0 M 2 M5 1 8/9/0 0

1 T5 1/10/0 7

1 M 1 5 2

5 /11/0 8 M

T10 T8 0

T12 1 FINA 1 L 9/11/0

21

Diferencias entre los mtodos pert y cpm

La principal diferencia entre los mtodos es la manera en que se realizan los estimativos de tiempo.

PERT
Probabilstico. Considera que la variable de tiempo es una variable desconocida de la cual solo se tienen datos estimativos. El tiempo esperado de finalizacin de un proyecto es la suma de todos los tiempos esperados de las actividades sobre la ruta crtica. Suponiendo que las distribuciones de los tiempos de las actividades son independientes, (una suposicin fuertemente cuestionable), la varianza del proyecto es la suma de las varianzas de las actividades en la ruta crtica.
Considera tres estimativos de tiempos: el ms probable, tiempo

optimista, tiempo pesimista.

CPM
Determinstico. Ya que considera que los tiempos de las actividades se conocen y se pueden variar cambiando el nivel de recursos utilizados. A medida que el proyecto avanza, estos estimados se utilizan para controlar y monitorear el progreso. Si ocurre algn retardo en el proyecto, se hacen esfuerzos por lograr que el proyecto quede de nuevo en programa cambiando la asignacin de recursos. Considera que las actividades son continuas e interdependientes, siguen un orden cronolgico y ofrece parmetros del momento oportuno del inicio de la actividad.
Considera tiempos normales y acelerados de una determinada

actividad, segn la cantidad de recursos aplicados en la misma.

22

USOS.
El campo de accin de este mtodo es muy amplio, dada su gran flexibilidad y adaptabilidad a cualquier proyecto grande o pequeo. Para obtener los mejores resultados debe aplicarse a los proyectos que posean las siguientes caractersticas: Que el proyecto sea nico, no repetitivo, en algunas partes o en su totalidad. Que se deba ejecutar todo el proyecto o parte de l, en un tiempo mnimo, sin variaciones, es decir, en tiempo crtico. Que se desee el costo de operacin ms bajo posible dentro de un tiempo disponible. Dentro del mbito aplicacin, el mtodo se ha estado usando para la planeacin y control de diversas actividades, tales como construccin de presas, apertura de caminos, pavimentacin, construccin de casas y edificios, reparacin de barcos, investigacin de mercados, movimientos de colonizacin, estudios econmicos regionales, auditorias, planeacin de carreras universitarias,

distribucin de tiempos de salas de operaciones, ampliaciones de fbrica, planeacin de itinerarios para cobranzas, planes de venta, censos de poblacin, etc.

VENTAJAS PERT y CPM

Ensea una disciplina lgica para planificar y organizar un programa detallado de largo alcance. Proporciona una metodologa Standard de comunicar los planes del proyecto mediante un cuadro de tres dimensiones (tiempo, personal; costo).

23

Identifica

los

elementos

(segmentos)

ms

crticos

del plan,

en

que problemas potenciales puedan perjudicar el cumplimiento del programa propuesto. Ofrece la posibilidad de simular los efectos de las decisiones alternativas o situaciones imprevistas y una oportunidad para estudiar sus consecuencias en relacin a los plazos de cumplimiento de los programas. Aporta la probabilidad de cumplir exitosamente los plazos propuestos. En otras palabras: CPM es un sistema dinmico, que se mueve con el progreso del proyecto, reflejando en cualquier momento el STATUS presente del plan de accin.

PROCEDIMIENTO PARA TRAZAR UN MODELO DE RED

Para aplicar CPM o PERT se requiere conocer la lista de actividades que incluye un proyecto. Se considera que el proyecto est terminado cuando todas las actividades han sido completadas. Para cada actividad, puede existir un conjunto de actividades predecesoras que deben ser completadas antes de que comience la nueva actividad. Se construye una malla o red del proyecto para graficar las relaciones de precedencia entre las actividades. En dicha representacin grfica, cada actividad es representada como un arco y cada nodo ilustra la culminacin de una o varias actividades. ESPECIFIQUE LAS ACTIVIDADES INDIVIDUALES. De la estructura de la interrupcin del trabajo, un listado se puede hacer de todas las actividades en el proyecto. Este listado se puede utilizar como la base para agregar la informacin de la secuencia y de la duracin en pasos ms ltimos.

DETERMINE LA SECUENCIA DE LAS ACTIVIDADES

24

Algunas actividades son dependientes en la terminacin de otras. Un listado de los precursores inmediatos de cada actividad es til para construir el diagrama de la red del CPM. DIBUJE EL DIAGRAMA DE LA RED Una vez que se hayan definido las actividades y el su ordenar, el diagrama del CPM puede ser dibujado. El CPM fue desarrollado originalmente como actividad en red del nodo (AON), pero algunos planificadores del proyecto prefieren especificar las actividades en los arcos. ESTIME LA POCA DE LA TERMINACIN PARA CADA ACTIVIDAD. El tiempo requerido para terminar cada actividad se puede estimar usando experiencia previa o las estimaciones de personas bien informadas. El CPM es un modelo determinista que no considera la variacin en el tiempo de la terminacin, tan solamente un nmero se utiliza para la estimacin del tiempo de una actividad. IDENTIFIQUE LA TRAYECTORIA CRTICA (LA TRAYECTORIA MS LARGA A TRAVS DE LA RED). La trayectoria crtica es la trayectoria de la largo-duracio'n a travs de la red. La significacin de la trayectoria crtica es que las actividades que mienten en ella no se pueden retrasar sin delaying el proyecto. Debido a su impacto en el proyecto entero, el anlisis de trayectoria crtica es un aspecto Importante del planeamiento del proyecto. La trayectoria crtica puede ser identificada determinando los cuatro parmetros siguientes para cada actividad:

ES, Principio temprano. EF, principio tardo. LS, terminacin temprana. LF, terminacin tarda.

25

La poca floja para una actividad es el tiempo entre su hora de salida ms temprana y ms ltima, o entre su tiempo ms temprano y ms ltimo del final. La holgura es la cantidad de tiempo que una actividad se puede retrasar ms all de su comienzo ms temprano o final ms temprano sin delaying el proyecto. La trayectoria crtica es la trayectoria a travs de la red del proyecto en la cual ningunas de las actividades tienen holgura, es decir, la trayectoria para la cual ES=LS y EF=LF para todas las actividades en la trayectoria. Retrasa en la trayectoria crtica retrasa el proyecto. Semejantemente, acelere el proyecto que es necesario reducir el tiempo total requerido para las actividades en la trayectoria crtica. PONGA AL DA EL DIAGRAMA DEL CPM Pues progresa el proyecto, los tiempos reales de la terminacin de la tarea sern sabidos y el diagrama de la red se puede poner al da para incluir esta informacin. Una trayectoria crtica nueva puede emerger, y los cambios estructurales se pueden realizar en la red si los requisitos del proyecto cambian. LIMITACIONES DEL CPM El CPM fue desarrollado para el complejo pero los proyectos bastante rutinarios con incertidumbre mnima en los tiempos de la terminacin del proyecto. Para menos proyectos de la rutina hay ms incertidumbre en los tiempos de la terminacin, y lmites de esta incertidumbre la utilidad del modelo determinista del CPM. Una alternativa al CPM es el modelo del planeamiento del proyecto del PERT, que permite que una gama de duraciones sea especificada para cada actividad.

MTODO PERT (Program Evaluation and Review Technique)

En CPM se asume que la duracin de cada actividad es conocida con certeza. Claramente, en muchas ocasiones este supuesto no es vlido. PERT intenta corregir este error suponiendo que la duracin de cada actividad es una

26

variable aleatoria. Para cada activad, se requiere estimar las siguientes cantidades:

a = Tiempo Optimista. Duracin de la actividad bajo las condiciones ms favorables b = Tiempo Pesimista. Duracin de la actividad bajo las condiciones ms desfavorables m = Tiempo Normal. El valor ms probable de la duracin de la actividad.

PASOS EN EL PROCESO DE PLANEAMIENTO DEL PERT

El planeamiento del PERT implica los pasos siguientes: Identifique las actividades y duracin especfica, determine la secuencia apropiada de las actividades, construya un diagrama de red, determine el tiempo requerido para cada actividad, determine la trayectoria crtica, Ponga al da la carta del PERT segn como progresa el proyecto. IDENTIFIQUE LAS ACTIVIDADES Y LOS PRECEDENTES Las actividades son las tareas requeridas para terminar el proyecto. Los precedentes son los acontecimientos que marcan el principio y el final de una o ms actividades. Es provechoso enumerar las tareas en una tabla que en pasos ms ltimos se pueda ampliar para incluir la informacin sobre secuencia y duracin. DETERMINE LA SECUENCIA DE LA ACTIVIDAD Este paso se puede combinar con el paso de la identificacin de la actividad puesto que la secuencia de la actividad es evidente para algunas tareas. Otras tareas pueden requerir ms anlisis para determinar el orden exacto en la cual deben ser realizadas

27

CONSTRUYA EL DIAGRAMA DE RED Usando la informacin de la secuencia de la actividad, un diagrama de la red se puede dibujar demostrando la secuencia de actividades seriales y paralelas. TIEMPOS DE ACTIVIDAD DE ESTIMACIN Para cada activad, se requiere estimar las siguientes cantidades: a = Tiempo Optimista. El que representa el tiempo mnimo posible sin importar el costo o cuanta de elementos materiales y humanos que se requieran; es simplemente la posibilidad fsica de realizar la actividad en el menor tiempo b = Tiempo Pesimista. Es un tiempo excepcionalmente grande que pudiera presentarse ocasionalmente como consecuencia de accidentes, falta de suministros, retardos involuntarios, causas no previstas, etc. m = Tiempo Normal. El valor ms probable de la duracin de la actividad, basado en la experiencia personal del informador Si Tij es la variable aleatoria asociada a la duracin de la actividad (i; j), PERT asume que Tij sigue una distribucin Beta. Sin entrar en mayores detalles de esta distribucin, se puede demostrar que el valor esperado y la varianza de la variable aleatoria Tij quedan definidas por:

En PERT se asume adems que la duracin de las actividades es independiente. Por lo tanto, el valor esperado y la varianza de una ruta pueden ser estimadas segn:

28

= Duracin esperada de la ruta

= Variacin de la duracin de la ruta

DETERMINE LA TRAYECTORIA CRTICA La trayectoria crtica es determinada agregando los tiempos para las actividades en cada secuencia y determinando la trayectoria ms larga del proyecto. La trayectoria crtica determina el tiempo total del calendario requerido para el proyecto. Si las actividades fuera de la trayectoria ctrica aceleran o retrasaron el tiempo (dentro de los lmites), entonces el tiempo total de proyecto no vara, la cantidad del tiempo que una actividad no crtica de la trayectoria sin alterar la duracin del proyecto se denomina como tiempo flojo. Si la trayectoria crtica del proyecto no resulta obvia, entonces puede ser provechoso determinar las cuatro cantidades siguientes para cada actividad: ES, Principio temprano. EF, principio tardo. LS, terminacin temprana. LF, terminacin tarda. Se calculan estos tiempos usando la poca prevista para las actividades relevantes. Los tiempos ms tempranos del comienzo y del final de cada actividad son determinados trabajando adelante a travs de la red y determinando el tiempo ms temprano en el cual una actividad puede comenzar y acabar a considerar sus actividades del precursor. Los tiempos ms ltimos del comienzo y del final son los tiempos ms ltimos que una actividad puede comenzar y acabar sin variar el proyecto. El LS y el LF son encontrados trabajando al revs a travs de la red. La diferencia en el final ms ltimo y ms temprano de cada actividad es holgura de
29

esa actividad. La trayectoria crtica entonces es la trayectoria a travs de la red en la cual ningunas de las actividades tienen holgura. La variacin en el tiempo de la terminacin del proyecto puede ser calculada sumando las variaciones en los tiempos de la terminacin de las actividades en la trayectoria crtica. Dado esta variacin, una puede calcular la probabilidad que el proyecto ser terminado por cierta fecha si se asume que una distribucin normal de la probabilidad para la trayectoria crtica. Sea CP la variable aleatoria asociada a la duracin total de las actividades de la ruta crtica determinadas mediante CPM. PERT asume que la ruta crtica encontrada a travs de CPM contiene suficientes actividades para emplear el Teorema Central del Lmite y concluir que CP se distribuye normalmente.

Puesto que la trayectoria crtica determina la fecha de la terminacin del proyecto, el proyecto puede ser acelerado agregando los recursos requeridos para disminuir la poca para las actividades en la trayectoria crtica. LA ACTUALIZACIN SEGN COMO EL PROYECTO PROGRESA Haga los ajustes en la carta del PERT como progresa el proyecto. Mientras que el proyecto revela, los tiempos estimados se pueden sustituir por pocas reales. En casos donde hay retrasa, los recursos adicionales puede ser necesario permanecer en horario y la carta del PERT se puede modificar para reflejar la nueva situacin.

VENTAJAS DEL PERT

El PERT es til porque proporciona la informacin siguiente: Tiempo previsto de la terminacin del proyecto. Probabilidad de la terminacin antes de una fecha especificada.
30

Las actividades de la trayectoria crtica que afectan directamente el tiempo de la terminacin. Las actividades que tienen tiempo flojo y que pueden prestar recursos a las actividades de la trayectoria crtica. Fechas del comienzo y del extremo de la actividad.

LIMITACIONES
Los siguientes son algunas de las debilidades del PERT: Las estimaciones del tiempo de la actividad son algo subjetivas y dependen del juicio. En casos donde hay poca experiencia en la ejecucin de una actividad, los nmeros pueden ser solamente una conjetura. En otros casos, si la persona o el grupo que realiza la actividad estiman el tiempo puede haber diagonal en la estimacin. Incluso si bien-se estiman los tiempos de la actividad, el PERT asume una distribucin beta para stos las estimaciones del tiempo, pero la distribucin real puede ser diferente. Incluso si la asuncin beta de la distribucin sostiene, el PERT asume que la distribucin de la probabilidad del tiempo de la terminacin del proyecto es igual que el de la trayectoria crtica. Porque otras trayectorias pueden convertirse en la trayectoria crtica si se retrasan sus actividades asociadas, el PERT subestima constantemente el tiempo previsto de la terminacin del proyecto.

31

ESTIMACIONES
Estimacin Apreciar, poner precio, evaluar algo Estimacin de proyectos de software Actividad de la planificacin del proyecto de software que intenta determinar cunto dinero, esfuerzo, recursos y tiempo tomar construir un sistema o producto software.

En qu consiste la estimacin de proyectos software? Aplicacin contina de tcnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una informacin de gestin significativa y a tiempo. Esta informacin se utilizar para mejorar esos procesos los productos que se obtienen de ellos. (SYMONS, C., 1998)

32

Cul es el objetivo de la estimacin? Predecir las variables involucradas en el proyecto con cierto grado de certeza. Trata de aportar una prediccin de algn indicador importante para la gestin de proyectos de software tiempo, esfuerzo, cantidad de defectos esperados entre otros. Es razonable conocer, antes de comenzar a desarrollar el SW, cunto se va a invertir, qu tareas se deben realizar y cunto tiempo se necesitar. Quin es y cul es el objetivo del estimador de un proyecto software?

El estimador debe ser un profesional que no tenga ningn inters, directo o indirecto, en los resultados del proceso de estimacin y que este nicamente guiado por su profesionalismo. El principal objetivo del estimador es obtener estimaciones de calidad, las cuales no tienen siempre por qu coincidir con las expectativas de la empresa en trminos de costo y tiempo. Requisitos que debe cumplir un buen estimador

Formacin y experiencia profesional adecuada. Una posicin en la organizacin que le permita adoptar un juicio independiente. Debe basarse en un mtodo que pueda ser explicado, cuestionado, discutido y auditado. Debe poder describir su experiencia en cada estimacin. Debe documentar su estimacin, incluyendo los resultados obtenidos y cualquier informacin necesaria para hacer el proceso de estimacin repetible y verificable.

33

Cundo se debe llevar a cabo? La estimacin es un proceso continuo. A medida que el proyecto avanza, ms se conoce de l, y por lo tanto ms parmetros estn disponibles para introducir en un modelo de estimacin. La estimacin continua nos permite el uso de un nico modelo coherente que pueda capturar y utilizar la informacin sobre el proyecto a medida que ste se conozca.

34

ESTIMACIN PARA PROYECTOS DE SOFTWARE

La gestin del proyecto de software comienza con un conjunto de actividades que en grupo se denominan planificacin del proyecto. Antes de que el proyecto comience el gestor del proyecto y el equipo de software deben estimar el trabajo que habr de realizarse, los recursos que se requerirn y el tiempo que transcurrir desde el principio hasta el final. Una vez que se completen estas actividades, el equipo de software debe establecer un plan del proyecto que defina las tareas y fechas clave de la ingeniera del software, que identifique quienes responsable de dirigir cada tarea y especifique las dependencias entre tareas que pueden ser determinantes en el progreso. En una excelente gua para "sobrevivir el proyecto de software", Steve McConell presenta una visin del mundo real de la planificacin del proyecto: Muchos trabajadores tcnicos preferirn realizar el trabajo tcnico en lugar de pasar el tiempo en la planificacin. Muchos gestores tcnicos no tienen suficiente entrenamiento en la gestin tcnica para sentirse seguros de que su planificacin mejorar el resultado de un proyecto, Puesto que ninguna parte quiere hacer la planificacin, con frecuencia no se realiza. Pero las fallas para planificar es uno de los mayores errores que un proyecto pueda cometer... se necesita la planificacin eficaz para resolver los problemas corriente arriba [temprano en el proyecto] a bajo cosi, ms que corriente abajo [tarde en el proyecto] a alto costo. El proyecto promedio gasta 80 por dent de su tiempo en reelaboracin: corrigiendo errores que se cometieron en etapas tempranas del proyecto. McConell argumenta que cualquier proyecto puede encontrar el tiempo para planificar (y adaptar el plan a lo largo del proyecto) simplemente tomando un pequeo porcentaje del tiempo que se habra gastado en la reelaboracin que ocurre debido a que no se planific.

35

OBSERVACIONES ACERCA DE LA ESTIMACIN

La planificacin requiere que los gestores tcnicos y los miembros del equipo de software establezcan un compromiso inicial, aun cuando sea probable que este "compromiso" pruebe estar equivocado. Siempre que se realizan estimaciones se atisba al futuro y se acepta automticamente algn grado de incertidumbre Para citar a Frederick Brooks: Nuestras tcnicas de estimacin estn pobremente desarrolladas. Ms seriamente, reflejan una suposicin no expresada que es bastante incierta, es decir: que todo ir bien... Puesto que no estamos seguros de nuestras estimaciones, con frecuencia los gestores de software carecen de la corts testarudez para hacer que la gente espere un buen producto. Aunque la estimacin es tanto un arte como una ciencia, esta importante actividad no necesita realizarse en una forma improvisada. Existen tcnicas tiles para la estimacin de tiempo y esfuerzo. Las mtricas del proceso y del proyecto ofrecen la perspectiva histrica y la energa para la generacin de estimaciones cuantitativas. La experiencia (de toda la gente involucrada) puede auxiliar enormemente conforme se desarrollan y revisan las estimaciones. Puesto que la estimacin coloca los cimientos para las dems actividades de planificacin del proyecto, y sta proporciona la ruta para la ingeniera del software exitosa, se estara mal aconsejado si se embarcara sin ella. La estimacin de recursos, costo y programa de trabajo para una tarea de ingeniera de software requiere experiencia, acceso a buena informacin histrica (mtricas) y el valor para comprometerse con predicciones cuantitativas cuando la informacin cualitativa es todo lo que existe. La estimacin implica riesgo inherente, y ste conduce a la incertidumbre. La disponibilidad de informacin histrica tiene una fuerte influencia en el riesgo de la estimacin. Al mirar en retrospectiva, se pueden emular las cosas que funcionaron y mejorar las reas donde surgieron problemas. Cuando hay disponibles amplias mtricas de software de proyectos previos, las estimaciones
36

se hacen con mayor seguridad, los programas de trabajo se pueden establecer para evitar dificultades pasadas y el riesgo global se reduce. El riesgo de la estimacin se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas para recursos, costos y programa de trabajo. Si el mbito del proyecto se comprende en forma deficiente o los requisitos del proyecto estn sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimacin se incrementan peligrosamente. El planificador y, en forma ms importante, el cliente deben reconocer que la variabilidad en los requisitos del software significa inestabilidad en costo y programa de trabajo.

EL PROCESO DE PLANIFICACIN DEL PROYECTO

El objetivo de la planificacin del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Adems, las estimaciones deben intentar definir los escenarios de mejor \ peor caso de modo que los resultados del proyecto se puedan acotar. Aunque existe un grado inherente de incertidumbre, el equipo de software se embarca en un piar, establecido como consecuencia de las tareas de planificacin. Por lo tanto, el plan se debe adaptar y actualizar conforme avance el proyecto.

MBITO DEL SOFTWARE Y FACTIBILIDAD

El mbito del software describe las funciones y caractersticas que se entregarn a los usuarios finales, los datos que son entrada y salida, el "contenido" que se presenta a los usuarios como consecuencia de emplear el software, as como el desempeo, las restricciones, las interfaces y la confiabilidad que acotan el sistema. El mbito se define al usar una de las dos tcnicas siguientes: 1. Despus de una comunicacin con todos los participantes se desarrolla una descripcin narrativa del mbito del software. 2. Los usuarios finales desarrollan un conjunto de casos de uso.

37

Las funciones descritas en el enunciado del mbito (o dentro de los casos de uso) se evalan y en algunos casos se refinan para proporcionar ms detalles antes de comenzar la estimacin. Puesto que las estimaciones de costo y programa de trabajo estn funcionalmente orientadas, con frecuencia es til cierto grado de descomposicin. Las consideraciones del desempeo abarcan los requisitos de procesamiento y tiempo de respuesta. Las restricciones identifican los lmites colocados en el software por el hardware externo, la memoria disponible u otros sistemas existentes. Una vez identificado el mbito (con la participacin del cliente) es razonable preguntar: es posible construir software para satisfacer este mbito? El proyecto es factible? Con mucha frecuencia los ingenieros de software soslayan estas preguntas (o gestores o clientes impacientes los presionan para hacerlo), slo para verse enredados en un proyecto condenado al fracaso. Putnam y Myers abordan este conflicto cuando escriben: No todo lo imaginable es factible, incluso ni en software, tan evanescente como puede parecer a los extraos. Por el contrario, la factibilidad del software tiene cuatro dimensiones slidas: Tecnologa: el proyecto es tcnicamente factible? Est dentro del terreno de la disciplina? Los defectos se pueden reducir a tal grado que se emparejen con las necesidades de la aplicacin? Finanzas: es financieramente factible? Se puede completar e! desarrollo a un costo que La organizacin de software, su cliente o el mercado puedan enfrentar? Tiempo: el proyecto llegar al mercado antes y vencer a la competencia? Recursos: la organizacin tiene los recursos necesarios para triunfar? Putnam y Myers sugieren, acertadamente, que el mbito no es suficiente. Una vez que el mbito se comprende, el equipo de software y otros deben trabajar para determinar si se puede hacer dentro de las dimensiones anotadas lneas arriba. sta i una parte crucial, aunque con frecuencia ignorada, del proceso de estimacin.

38

RECURSOS
La segunda tarea de la planificacin es la estimacin de los recursos necesarios para completar el esfuerzo de desarrollo del software. La figura muestra las tres grandes categoras de los recursos de ingeniera del software: personal, componentes de software reutilizables y el entorno de desarrollo (hardware y herramientas de software). Cada recurso se especifica con cuatro caractersticas: descripcin del recurso; un informe de disponibilidad; cundo se requerir el recurso; tiempo durante el cual e] recurso se aplicar. Las ltimas dos caractersticas se pueden ver como una ventana de tiempo. La disponibilidad del recurso para una ventana especfica debe establecerse lo ms pronto posible.

Recursos humanos El planificador comienza evaluando el mbito del software y seleccionando las habilidades requeridas para completar el desarrollo. Se especifican tanto la posicin organizacional (por ejemplo, gestor, ingeniero de software ejecutivo) como la especialidad (por ejemplo, telecomunicaciones, base de datos, cliente/servidor). En proyectos relativamente pequeos (unos pocos persona39

meses) un solo individuo puede realizar todas las tareas de ingeniera del software y consultar con especialistas conforme se requiera. En proyectos mayores el equipo de software puede estar geogrficamente disperso en varios sitios. Aqu se especifica la ubicacin de cada recurso humano. El nmero de personas que requiere un proyecto de software slo se determina despus de que se ha hecho una estimacin del esfuerzo de desarrollo (por ejemplo, personas-mes). Las tcnicas para estimar el esfuerzo se tratarn ms adelante. Recursos de software reutilizables La ingeniera del software basada en componentes enfatiza la reutilizacin de bloques de construccin de software. Tales bloques, usualmente llamados componentes, deben catalogarse para consultarlos con facilidad, estandarizarse para facilitar su aplicacin y validarse para integrarlos fcilmente. Bennatan sugiere cuatro categoras de recursos de software que deben considerarse conforme avanza la planificacin: Componentes ya desarrollados. El software existente se puede adquirir de un tercero o se desarroll internamente para un proyecto previo. Los CCYD (componentes comerciales ya desarrollados) se compran de un tercero, estn listos para emplearlos en el proyecto actual y han sido ampliamente validados Componentes experimentados. Especificaciones, diseos, cdigo o datos de prueba existentes que se desarrollaron para proyectos previos son similares al software que se construir para el proyecto actual. Los miembros del equipo de software actual ya tienen experiencia en el rea de aplicacin que representan dichos componentes. En consecuencia, las

modificaciones que requieran los componentes experimentados sern relativamente de bajo riesgo. Componentes de experiencia pardal. Especificaciones, diseos, cdigo o datos de prueba existentes que se desarrollaron para proyectos previos
40

estn relacionados con el software que se construir para el proyecto actual pero requerirn modificaciones sustanciales. Los miembros del equipo de software actual slo tienen experiencia limitada en el rea de aplicacin que representan dichos componentes. Por lo tanto, las modificaciones que requieren los componentes de experiencia parcial tienen un grado considerable de riesgo. Componentes nuevos. El equipo de software debe construir los

componentes de software especficamente para las necesidades del proyecto actual.

Recursos del entorno El entorno que soporta un proyecto de software, con frecuencia denominado entorno de ingeniera del software (EIS), incorpora hardware y software. El hardware proporciona una plataforma que soporta las herramientas (software) con que se producen los productos de trabajo basados en una buena prctica de la ingeniera del software. Puesto que la mayor parte de las organizaciones de software tienen mltiples constituyentes que requieren acceso al EIS, el planificador de proyecto debe prescribir la ventana de tiempo requerida por el hardware y el software, y verificar que estos recursos estarn disponibles. Cuando un sistema basado en computadora (que incorpora hardware y software especializados) se someter a ingeniera, el equipo de software quiz requiera acceso a elementos de hardware que estn desarrollando otros equipos de ingeniera. Por ejemplo, el software de un contador numrico (CN) utilizado en un tipo de mquinas-herramienta tal vez requiera una mquina-herramienta especfica (por ejemplo, un CN de torno) como parte del paso de prueba de validacin; un proyecto de software para plantilla de pgina avanzada quiz necesite una impresora de alta calidad en algn punto durante el desarrollo. El planificador del proyecto de software debe especificar cada elemento de hardware.

41

ESTIMACIN DE COSTOS DE SOFTWARE

El software es el elemento ms caro de virtualmente todos los sistemas basados e computadora. En sistemas complejos, personalizados, un gran error en la estimacin del costo puede hacer la diferencia entre beneficio y prdida. Rebasar el costo puede ser desastroso para el desarrollador. La estimacin del costo y el esfuerzo nunca ser una ciencia exacta. Demasiadas variables humanas, tcnicas, ambientales, polticas pueden afectar el costo final del software y el esfuerzo aplicado a desarrollarlo. Sin embargo, la estimacin del proyecto de software se puede transformar de una prctica oscura en una serie de pasos sistemticos que proporcionan estimaciones con riesgo aceptable. Para lograr estimaciones confiables de costo y esfuerzo se tienen varias opciones: 1. Demorar la estimacin hasta ms tarde en el proyecto (obviamente, se puede lograr 100 por ciento de estimaciones precisas despus de que el proyecto est terminado!) 2. Basar las estimaciones en proyectos similares que ya hayan sido completados 3. Emplear tcnicas de descomposicin relativamente simples para generar estimaciones de costo y esfuerzo del proyecto. 4. Utilizar uno o ms modelos empricos en la estimacin de costo y esfuerzo. Desgraciadamente, la primera opcin, aunque atractiva, no es prctica. Las estimaciones de costos se tienen que proporcionar "por adelantado". No obstante, se debe reconocer que, mientras ms se espere ms se conocer, y mientras ms se conozca menos probable es que se cometan serios errores en las estimaciones. La segunda opcin puede funcionar razonablemente bien si el proyecto en curso es muy similar a los previos y a otras influencias del proyecto (por ejemplo, el equipo de software, el cliente, las condiciones del mercado, el EIS, las fechas

42

lmite) son aproximadamente equivalentes. Por desgracia, la experiencia no siempre ha sido un buen indicador de los resultados futuros. Las opciones restantes son enfoques viables para la estimacin del proyecto de software. Idealmente, las tcnicas mencionadas para cada opcin deben aplicarse juntas, cada una empleada como una marca de verificacin para la otra. Las tcnicas de descomposicin asumen un enfoque de "divide y vencers" respecto de la estimacin del proyecto de software. Al descomponer un proyecto en funciones principales y actividades de ingeniera del software relacionadas, las estimaciones de costo y esfuerzo se pueden realizar en forma escalonada. Los modelos de estimacin emprica son tiles para complementar las tcnicas de descomposicin y ofrecer un enfoque de estimacin

potencialmente valioso por su propio derecho.

TCNICAS DE DESCOMPOSICIN La estimacin del proyecto de software es una forma de resolver problemas; en la mayora de los casos, el problema que debe resolverse (es decir, el desarrollo de una estimacin de costo y esfuerzo para un proyecto de software) es muy complejo como para considerarlo una sola pieza. Por esta razn se descompone el problema, re caracterizndolo como un conjunto de problemas ms pequeos (y, esperanzadora-mente, ms manejable). Anteriormente se examin el enfoque de descomposicin desde dos diferentes puntos de vista: descomposicin del problema y descomposicin del proceso. La estimacin emplea una o ambas formas de particin. Pero antes de que pueda realizarse una estimacin, el planificador del proyecto debe entender el mbito del software que se construir y generar una estimacin de su "tamao".

43

Tamao del software La precisin de la estimacin de un proyecto de software se manifiesta en varios factores: 1) el grado con el cual el planificador ha estimado adecuadamente el tamao del producto que se construir; 2) la habilidad para traducir la estimacin del tamao en esfuerzo humano, programa de trabajo y dinero (una funcin de la disponibilidad de las mtricas de software confiables a partir de proyectos previos); 3) el grado en el cual el plan del proyecto refleja las habilidades del equipo de software; y 4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de: ingeniera del software. Se considera el problema del tamao del software. Puesto que estimacin de un proyecto slo es tan buena como la estimacin del tamao del ti bajo para realizarlo, el tamao representa el primer gran desafo del platicador del proyecto. En el contexto de la planificacin del proyecto, tamao se refiere a resultado cuantificable del proyecto de software. Si se asume un enfoque directo tamao se puede medir en lneas de cdigo (LDC). Si se elige un enfoque indirecto el tamao se representa como puntos de funcin (PF). Putnam y Myers sugieren cuatro diferentes enfoques al problema < tamao: Tamao de "lgica difusa". La aplicacin de este enfoque requiere que el planificador identifique el tipo de aplicacin, establezca su magnitud en una escala cualitativa y luego retine la magnitud dentro del rango original. Tamao de punto de funcin. El planificador desarrolla estimaciones de las caractersticas del dominio. Tamao de componentes estndar. El software se compone de varios "componentes estndar", los cuales son diferentes y genricos de un rea particular de la aplicacin. Por ejemplo, los componentes estndar de un sistema de informacin son subsistemas, mdulos, pantallas, reportes, programas nter activos, programas por lotes, archivos, LDC e instrucciones al nivel de objeto. El planificador del proyecto estima el nmero de ocurrencias de

44

cada componente estndar y luego aplica datos de proyectos histricos para determinar el tamao de entrega por componente estndar. Tamao del cambio. Este enfoque se aplica cuando un proyecto incluye la utilizacin de software existente que debe modificarse en cierta forma como parte de un proyecto. El planificador estima el nmero y tipo (por ejemplo, reutilizacin, cdigo de adicin, cdigo de cambio, cdigo de borrado) de las modificaciones que se deben lograr. Putnam y Myers sugieren que los resultados de cada uno de estos enfoques de tamao se combinen estadsticamente para crear una estimacin de tres puntos o del valor esperado. Esto se logra desarrollando valores optimistas (bajos), ms probables y pesimistas (altos) para el tamao y combinndolos con la ecuacin (23Estimacin basada en el problema Anteriormente, las lneas de cdigo y los puntos de funcin se describieron como medidas a partir de las cuales se calculan las mtricas de productividad. Los datos de las LDC y los PF se utilizan en dos formas al estimar el proyecto de software: I) como una variable de la estimacin para el "tamao" de cada elemento del software, y 2) como mtricas de lnea base recolectadas a partir de proyectos previos y utilizados en conjuncin con variables de estimacin para desarrollar proyecciones de costo y esfuerzo. Las estimaciones de LDC y PF son distintas tcnicas de estimacin, aunque ambas tienen varias caractersticas en comn. El planificador del proyecto comienza con un enfoque acotado del mbito del software y a partir de ah intenta descomponer el software en funciones problema que puedan estimarse individualmente. Entonces se estiman las LDC o PF (las variables de estimacin) para cada funcin. De manera alternativa, el planificador puede elegir otro componente para tamao, como clases u objetos, cambios o procesos de negocios afectados.

45

Entonces se aplican las mtricas de la lnea base de productividad (por ejemplo, LDC/pm o PF/pms) a la variable de estimacin apropiada, y se deriva el costo o esfuerzo de la funcin. Las estimaciones de funcin se combinan para producir una estimacin global del proyecto completo. Sin embargo, es importante notar que con frecuencia existe una dispersin sustancial en las mtricas de productividad de una organizacin, lo que hace sospechoso el uso de una sola mtrica de lnea base de productividad. En general, el dominio del proyecto debe calcular los promedios de LDC/pm o PF/pm. Es decir, los proyectos deben agruparse por tamao de equipo, rea de aplicacin, complejidad y otros parmetros relevantes. Luego se tienen que calcular los promedios de dominio local Cuando se estima un nuevo proyecto primero debe ubicarse en un dominio, y luego aplicar el promedio del dominio apropiado para la productividad y as generar la estimacin. Las tcnicas de estimacin LDC y PF difieren en cuanto al detalle requerido para descomposicin y el objetivo de la particin. Al emplear LDC como variable de estimacin la descomposicin es absolutamente esencial y con frecuencia se lleva a grados considerables de detalle. Mientras mayor sea el grado de particin es ms probable que se desarrolle una estimacin razonablemente precisa de LDC. En las estimaciones de PF la descomposicin funciona de manera diferente. Ms que enfocarse sobre la funcin, se estima cada una de las cinco caractersticas de dominio de informacin, as como los 14 valores de ajuste de complejidad. Entonces se pueden utilizar las estimaciones resultantes para derivar un valor do PF que se pueda ligar a datos previos y empleados para generar una estimacin. Sin importar la variable de estimacin que se utilice, el planificador del proyecto comienza estimando una gama de valores para cada funcin o valor de dominio de informacin. Al emplear datos histricos o (cuando todo lo dems falla) intuicin, el planificador estima un valor de tamao optimista, ms probable, y
46

pesimista para cada funcin o cuenta para cada valor de dominio de informacin. Cuando se especifica un rango de valores se proporciona un indicio implcito del grado de incertidumbre. Entonces se puede calcular un valor de tres puntos o uno esperado. El valor esperado para la variable de estimacin (tamao), S, se calcula como un promedio ponderado de las estimaciones optimista (S,,,,,), ms probable (Sm) y pesimista (Spe5). Por ejemplo, brinda la credibilidad ms fuerte a la estimacin "ms probable" y sigue una distribucin de probabilidad beta. Una vez determinado el valor esperado para la variable de estimacin se aplican los datos de productividad histrica de LDC o PF. Son correctas las estimaciones? La nica respuesta razonable a esta pregunta es: no se puede estar seguro. Cualquier tcnica de estimacin, no importa cun sofisticada sea, debe contrastarse con otro enfoque. Incluso entonces deben prevalecer el sentido comn y la experiencia. Un ejemplo de estimacin basada en LDC Como ejemplo de tcnicas de estimacin de LDC y PF basadas en el problema, considrese un paquete de software que ser entregado para una aplicacin de diseo asistido por computadora (CAD, por sus siglas en ingls) destinado a componentes mecnicos. El software se ejecutar en una estacin de trabajo de ingeniera y debe tener interfaz con varios perifricos que incluyen ratn, digitalizador, monitor de color de alta resolucin e impresora lser. Se puede elaborar una descripcin preliminar del mbito del software: El software CAD mecnico aceptar del ingeniero datos geomtricos de dos y tres dimensiones. El ingeniero interactuar y controlar el sistema CAD a travs de una Interfax del usuario que exhibir caractersticas de buen diseo de interfaz humano-mquina. Todos los datos geomtricos y otra informacin de soporte se conservarn en una base de datos CAD. Se desarrollarn mdulos de anlisis de diseo para producir la salida requerida, la cual se desplegar en una diversidad de dispositivos grficos. El software se disear para
47

controlar e interactuar con dispositivos perifricos que incluyen ratn, digitalizador, impresora lser y plotter. Esta descripcin del mbito es preliminar, no est acotada. Se tendra que expandir cada oracin para ofrecer detalle concreto y acotacin cuantitativa. Por ejemplo, antes de que comience la estimacin, el planificador debe determinar qu significa "caractersticas de buen diseo de interfaz humano-mquina" o cules sern el tamao y la complejidad de la "base de datos CAD". En cuanto a los propsitos actuales, se supone que se ha llevado a cabo ms refinamiento y que estn identificadas las grandes funciones de software mencionadas en la figura 23.2. Al continuar con la tcnica de descomposicin para LDC se elabora una tabla de estimacin, la cual se muestra en la figura 23.2. En cada funcin se desarrolla un rango de estimaciones LDC. Por ejemplo, el rango de las estimaciones LDC para la funcin de anlisis geomtrico 3D es: optimista, 4 600 LDC; ms probable, 6 900 LDC; y pesimista, 8 600 LDC. Al aplicar la ecuacin 231 el valor esperado para la funcin de anlisis geomtrico 3D es 6 800 LDC. Otras estimaciones se derivan en forma similar. Al sumar verticalmente en la columna de LDC estimadas, se establece una estimacin de 33 200 lneas de cdigo para el sistema CAD. Una revisin de \os datos histricos indica que el promedio organizacional de productividad para sistemas de este tipo es de 620 LDC/pm. Con base en una tarifa laboral de 8 000 dlares por mes, el costo por lnea de cdigo es aproximadamente de 13 dlares. Con base en la estimacin de LDC y los datos histricos de productividad, el costo total estimado del proyecto es de 431 000 dlares y el esfuerzo estimado es de 54 personas-mes.

48

Estimacin basada en el proceso La tcnica ms comn para estimar un proyecto es basar la estimacin en el proceso que se emplear. Esto es, el proceso se descompone en un conjunto relativamente pequeo de tareas y se estima el esfuerzo requerido para lograr cada tarea. Al igual que las tcnicas basadas en el problema, la estimacin basada en el proceso comienza con un bosquejo de las funciones del software obtenidas a partir del mbito del proyecto. Cada funcin requiere realizar una serie de actividades del marco de trabajo. Las funciones y actividades del marco de trabajo relacionadas se presentan como parte de una tabla similar a la presentada en la figura.

49

Una vez que se combinan las funciones del problema y las actividades del proceso, el planificador estima el esfuerzo (por ejemplo, personas-mes) que se requerir para lograr cada actividad del proceso de software en cada funcin. Estos datos constituyen la matriz central de la tabla en la figura 23.4. Entonces se aplican las tasas de trabajo promedio (es decir, costo/unidad de esfuerzo) al esfuerzo estimado para cada actividad del proceso. Es muy probable que la tasa de trabajo vare en cada tarea. El equipo veterano est enormemente involucrado en las actividades tempranas del marco de trabajo y generalmente es ms costoso que el equipo menos experimentado involucrado en la construccin y liberacin. Los costos y el esfuerzo para cada funcin y actividad del marco de trabajo se calculan como el ltimo paso. Si la estimacin basada en el proceso se realiza independientemente de la estimacin de LDC o PF, ahora se tienen dos o tres estimaciones para costo y esfuerzo que se pueden comparar y armonizar. Si ambos conjuntos de estimaciones muestran una concordancia razonable, existe una buena razn para creer que las estimaciones son confiables. Si, por otra parte, los resultados de dichas tcnicas de descomposicin muestran poca concordancia, se debe llevar a cabo mayor investigacin y anlisis. Estimacin con casos de uso Los casos de uso permiten que un equipo de software comprenda el mbito del software y los requisitos. Sin embargo, desarrollar un enfoque de estimacin con casos de uso es problemtico por las siguientes razones: Los casos de uso se describen empleando muchos formatos y estilos diferentes; no existe un formato estndar. Los casos de uso representan una visin externa (la visin del usuario) del software y con frecuencia estn escritos con diferentes grados de abstraccin Los casos de uso no abordan la complejidad de las funciones ni de las caractersticas que se describen.

50

Los casos de uso no describen el comportamiento complejo (por ejemplo, interacciones) que involucran muchas funciones y caractersticas.

A diferencia de las LDC o un punto de funcin, el "caso de uso" de una persona tal vez requiera meses de esfuerzo mientras que el de otra quiz se implemente en un da o dos. Aunque varios investigadores han considerado los casos de uso como una entrada a la estimacin, a la fecha no ha surgido ningn mtodo de estimacin probado Smith [SMI99] sugiere el empleo de los casos de uso en la estimacin, pero slo si se consideran dentro del contexto de la "jerarqua estructural" que los casos de uso describen. Smith argumenta que cualquier nivel de esta jerarqua estructural se describe ceno ms de 10 casos de uso. Cada uno de stos abarcara no ms de 30 escenarios distintos. Obviamente, los casos de uso que describen un sistema grande estn escritos con un grado mucho mayor de abstraccin (y representan considerablemente ms esfuerzo de desarrollo) que aquellos que describen un solo subsistema. En consecuencia, antes de que los casos de uso se empleen en la estimacin, se establece el nivel en la estructura jerrquica, se determina la longitud promedio (en pginas de cada caso de uso, se define el tipo de software (por ejemplo, tiempo real, de negocios, de ingeniera/cientfico, anidado) y se considera una arquitectura comn del sistema. Una vez establecidas dichas caractersticas, los datos empricos se aprovechan para establecer el nmero estimado de LDC o de PF por caso de uso (para cada nivel de la jerarqua). Entonces se utilizan los datos histricos para calcular el esfuerzo necesario para desarrollar el sistema. Reconciliacin de estimaciones Las tcnicas de estimacin dan por resultado; mltiples estimaciones que deben reconciliarse para producir una sola estimacin de esfuerzo, duracin del proyecto o costo. Este procedimiento de reconciliacin se ilustra considerando de nuevo el software CAD.
51

El esfuerzo estimado total para el software CAD vara desde un bajo de 46 personas-mes (obtenido empleando el enfoque de la estimacin basada en el proceso) hasta un alto de 68 personas-mes (derivado con la estimacin de caso de uso)- La estimacin promedio (que utiliza los cuatro enfoques) es de 56 personas-mes. La variacin de la estimacin promedio es aproximadamente 18 por ciento en el lado bato y de 21 por ciento en el lado alto. Qu ocurre cuando la concordancia entre as estimaciones es

insuficiente? Responder esta pregunta requiere reevaluar la informacin con que se hicieron tas estimaciones. Las estimaciones ampliamente divergentes con frecuencia pueden rastrearse hasta una de dos causas:
1. El planificador no ha comprendido adecuadamente o ha malinterpretado el mbito del proyecto. 2. Los datos de productividad que utilizan las tcnicas de estimacin basadas en el problema son inapropiados para la aplicacin, obsoletos (pues ya no reflejan con precisin la organizacin de ingeniera de software) o se han aplicado mal.

El planificador debe determinar la causa de la divergencia y luego reconciliar las estimaciones.

52

ANLISIS DE RIESGOS
ANLISIS Y GESTIN DE RIESGOS El anlisis y la gestin del riesgo son una serie de pasos que ayudan a un equipo de software a comprender y manejar la incertidumbre. Muchos problemas pueden desbordar un proyecto de software. Un riesgo es un problema potencial: puede ocurrir o no. Pero, sin importar el resultado, en realidad es uno buena idea identificarlo, evaluar la probabilidad de que ocurra, estimar su impacto y establecer un plan de contingencia en caso de que el problema se presente. Todos los involucrados en el proceso de software (gestores, ingenieros y participantes) intervienen en el anlisis y la gestin del riesgo.

ESTRATEGIAS DE RIESGO REACTIVAS Y PROACTIVAS Las estrategias de riesgo reactivas han sido jocosamente denominadas la "escuela Indiana Jones de gestin del riesgo". En las pelculas de la dcada de 1980 que llevaban su nombre, Indiana Jones, cuando enfrentaba alguna dificultad abrumadora, invariablemente deca: "No te preocupes, pensar en algo!". Al no preocuparse nunca por los problemas, sino hasta que ocurran, Indina reaccionaba en alguna forma heroica. "Si usted no atac activamente los riesgos, ellos lo atacaran activamente.' Tom Gilb. Tristemente, el gestor promedio de proyectos de software no es Indiana Jones, y los miembros del equipo de proyecto de software no son sus confiables compaeros. Ms an, la mayora de los equipos de software se apoyan exclusivamente en las estrategias de riesgo reactivas. Los riesgos se apartan para tratarlos, lo que puede convertirlos en problemas reales. Ms usualmente, el equipo de software no hace nada acerca de los riesgos hasta que algo sale mal. Entonces el equipo se precipita en la accin con la finalidad de corregir el problema rpidamente. Con frecuencia a esto se le llama el modo bombero.

53

Cuando esto falla, la "gestin de crisis" asume el control y el proyecto est en un verdadero peligro. Una estrategia considerablemente ms inteligente para la gestin del riesgo es ser proactivo. Una estrategia proactiva comienza mucho antes de que se inicie el trabajo tcnico. Se identifican los riesgos potenciales, se valoran su probabilidad e impacto, y se les clasifica segn su importancia. Luego, el equipo de software establece un plan para gestionar el riesgo. El objetivo principal es evitar el riesgo, pero debido a que no todos los riesgos pueden evitarse, el equipo trabaja para desarrollar un plan de contingencia que le permitir responder en una forma controlada y efectiva.

RIESGOS DEL SOFTWARE Aunque hay un considerable debate en torno a la definicin propia para el riesgo de software, existe un acuerdo general en que el riesgo siempre involucra dos caractersticas.
Incertidumbre: el riesgo puede o no ocurrir, esto es, no existen riesgos 100% probables. Prdida: si el riesgo se convierte en realidad, ocurrirn consecuencias o prdidas indeseables.

Cuando se analizan los riesgos es importante cuantificar el grado de incertidumbre y el grado de prdida asociado con cada riesgo. Esto se logra considerando diferentes categoras de riesgos. Los riesgos del proyecto amenazan el plan del proyecto. Es decir, si los riesgos del proyecto se vuelven reales es probable que la calendarizacin del proyecto se altere y que los costos aumenten. Los riesgos del proyecto identifican potenciales problemas en presupuesto, calendarizacin, personal (plantillas y organizacin), recursos, participantes y requisitos, y su impacto sobre un proyecto de software. Los riesgos tcnicos amenazan la calidad y actualidad del software que se producir. Si un riesgo tcnico se vuelve real, la implementacin se toma difcil
54

o imposible. Los riesgos tcnicos identifican potenciales problemas en diseo, implementacin, interfaz, verificacin y mantenimiento. Adems, tambin son factores de riesgo la ambigedad de la especificacin, la incertidumbre tcnica, la obsolescencia tcnica y la tecnologa "de punta. Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que en un principio se pens que sera. Los riesgos de negocios amenazan la viabilidad del software que se construir. Estos riesgos con frecuencia ponen en peligro el proyecto o el producto. Los candidatos para los cinco mayores riesgos de negocios son:
1) La construccin de un producto o sistema excelente que en realidad nadie quiere (riesgo de mercado). 2) La construccin de un producto que ya no encaja en la estrategia comercial global de la compaa (riesgo de estrategia). 3) La construccin de un producto que la fuerza de ventas no sabe cmo vender (riesgo de ventas). 4) La prdida del apoyo de los altos ejecutivos debido a un cambio en el enfoque o en el personal (riesgo administrativo). 5) La prdida presupuestaria o del personal asignado (riesgo presupuestal).

Es extremadamente importante destacar que la simple clasificacin de los riesgos no siempre funciona. Algunos riesgos simplemente son impredecibles. Charette ha propuesto otra categorizacin general de los riesgos. Los riesgos conocidos son aquellos susceptibles de descubrirse despus de una evaluacin cuidadosa del plan del proyecto, del entorno de negocios y tcnico dentro de los cuales se desarrollar el proyecto, y otras fuentes de informacin confiables (por ejemplo, fechas de entrega irreales, falta de requisitos documentados o de mbito del software, pobre entorno de desarrollo). Los riesgos predecibles se extrapolan de la experiencia con proyectos previos (por ejemplo, cambios en el personal, mala comunicacin con el cliente, disminucin del esfuerzo del personal conforme se atienden las solicitudes de mantenimiento). Los riesgos impredecibles son el comodn de la baraja. Pueden y de hecho ocurren, pero son extremadamente difciles de identificar con antelacin.
55

PRINCIPIOS DE LA GESTIN DE RIESGOS El Instituto de Ingeniera de Software (SEI) identifica siete principios que ofrecen un marco de trabajo para lograr una gestin de riesgos efectiva. Dichos principios son:
1. Mantenimiento de una perspectiva global: Ver los riesgos de software dentro del contexto del sistema en el que est un componente y el problema de negocios que se intenta resolver. 2. Tener una visin previsora: Pensar en los riesgos que pudieran surgir en lo futuro; establecer planes de contingencia de modo que los eventos futuros sean manejables. 3. Alentar la comunicacin abierta: Si alguien establece un riesgo potencial, no se debe descartar. Si un riesgo se pone de manera informal, se debe considerar. Alentar a todos los participantes y usuarios a sugerir riesgos en cualquier momento. 4. Integracin: En el proceso del software debe estar integrada una consideracin de los riesgos. 5. Enfatizar un proceso continuo: El equipo debe estar atento a lo largo de todo el proceso de software, modificar los riesgos identificados conforme se tenga ms informacin a medida que se logre un mejor criterio. 6. Desarrollo de una visin conjunta del producto: Si todos los participantes comparten la misma visin del software, es probable que ocurra mejor identificacin y evaluacin de riesgos. 7. Alentar el trabajo en equipo: Los talentos, habilidades y conocimientos de los participantes se deben mezclar cuando se lleven a cabo actividades de gestin de riesgos.

PROCESO DE ANLISIS DE RIESGOS 1) IDENTIFICACIN DE RIESGOS La identificacin de los riesgos es un intento sistemtico encaminado a especificar las amenazas al plan del proyecto (estimaciones, calendarizacin,
56

carga de recursos, etc.). Al identificar los riesgos conocidos y predecibles, el gestor del proyecto da un primer paso para evitarlos cuando es posible y a controlarlos cuando es necesario. Existen dos tipos distintos de riesgos para cada una de las categoras de riesgos, estos son los riesgos genricos y los riesgos especficos del producto. Los riesgos genricos son una amenaza potencial para todo el proyecto de software. Los riesgos especficos del producto los pueden identificar slo aquellos con un claro conocimiento de la tecnologa, el personal y el entorno especfico del software que se construir. Los riesgos especficos del producto se identifican examinando el plan del proyecto y la declaracin del mbito del software, as como desarrollando una respuesta para la siguiente pregunta: "Qu caractersticas especiales de este producto podran amenazar el plan del proyecto?". Los proyectos sin riesgos reales son perdedores. Estos proyectos casi siempre estn desprovistos de beneficios; por ello no fueron realizados aos atrs. Tom DeMarco y Tim Lister. Un mtodo para identificar riesgos consiste en crear una lista de verificacin de riesgos. Con sta se pueden identificar riesgos y enfocarse en algn subconjunto de riesgos conocidos y predecibles en las siguientes subcategoras genricas: Tamao del producto: riesgos asociados con el tamao global del software que se construir o modificar. El riesgo del proyecto es directamente proporcional al tamao del producto. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados con el tamao del producto (software):
Tamao estimado del producto. Grado de seguridad en la estimacin del tamao. Tamao estimado del producto en nmero de programas, archivos y transacciones.

57

Porcentaje de desviacin en el tamao del producto respecto a la medida de productos anteriores. Tamao de la base de datos creada o empleada por el producto. Nmero de usuarios del producto. Nmero de cambios previstos a los requisitos del producto. Antes de la entrega?, Despus de la entrega? Cantidad de software reutilizado.

En cada caso, la informacin del producto a desarrollar debe compararse con la experiencia anterior. Si ocurre una gran desviacin del porcentaje o si las magnitudes son similares. Pero si los resultados anteriores fueron poco satisfactorios, el riesgo es grande. Impacto en el negocio: riesgos asociados con las restricciones que impone la gerencia o el mercado. Al departamento de marketing le guan las consideraciones del negocio, y stas entran a veces en conflicto directo con las realidades tcnicas. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados con el impacto en el negocio:
Cul es el efecto de este producto en los ingresos de la compaa? Cul es la viabilidad de este producto para los gestores expertos? Es razonable la fecha lmite de entrega? Nmero de clientes que usarn este producto y la consistencia de sus necesidades relativas al producto. Nmero de otros productos/sistemas con los que este producto debe tener interoperatividad. Sofisticacin del usuario final. Cantidad y calidad de la documentacin del producto que debe ser elaborada y entregada al cliente. Limitaciones gubernamentales en la construccin del producto. Costos asociados por un retraso en la entrega. Costos asociados con un producto defectuoso.

Cada respuesta para el producto a desarrollar debe compararse con la experiencia anterior. Si se obtiene una gran desviacin del porcentaje o si las

58

magnitudes

son

similares,

pero

los

resultados

anteriores

fueron

poco

satisfactorios, el riesgo es grande. Caractersticas del cliente: riesgos asociados con la sofisticacin del cliente y la habilidad del desarrollador para comunicarse con l en una forma oportuna. Los clientes tienen diferentes personalidades. Algunos disfrutan siendo clientes (la tensin, la negociacin, las recompensas psicolgicas de un buen producto). Otros preferiran no ser clientes en absoluto. Algunos aceptaran felizmente cualquier cosa que se les entregara y le sacaran el mejor provecho a un producto pobre. Otros se quejarn amargamente cuando les falte calidad; algunos darn las gracias cuando la calidad es buena; unos pocos se quejarn por todo. Los clientes tambin tienen varios tipos de asociaciones con sus suministradores. Algunos conocen bien a sus proveedores y sus productos; otros no se han visto nunca las caras y se comunican siempre mediante correspondencia escrita y algunas llamadas telefnicas breves. Los clientes se contradicen a menudo. Quieren todo para ayer y gratis. A menudo, el producto se ve cogido entre las propias contraindicaciones del cliente. Un "mal" cliente puede tener un profundo impacto en la habilidad del equipo de software para completar el proyecto a tiempo y dentro de presupuesto. Un mal cliente representa una amenaza significativa al plan del proyecto y un sustancial riesgo para el jefe del proyecto. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados con diferentes clientes:
Ha trabajado con el cliente anteriormente? Tiene el cliente una idea formal de lo que se requiere? Se ha molestado en escribirlo? Aceptar el cliente gastar su tiempo en reuniones formales de requisitos para identificar el mbito del proyecto? Est dispuesto el cliente a establecer una comunicacin fluida con el desarrollador? Est dispuesto el cliente a participar en las revisiones? 59

Es sofisticado tcnicamente el rea del producto? Est dispuesto el cliente a dejar a su personal hacer el trabajo? Es decir, resistir la tentacin de mirar por encima del hombro durante el trabajo tcnico?

Entiende el cliente el proceso del software?

Si la respuesta a alguna de estas preguntas es "no", se debera hacer una investigacin ms profunda para valorar el potencial de riesgo. Definicin del proceso: riesgos asociados con el grado en el que se ha definido el proceso de software y en que le da seguimiento la organizacin que lo desarrolla. Si el proceso del software no est bien definido; si el anlisis, diseo y pruebas se realizan sobre la marcha; si la calidad es un concepto que todo el mundo estima importante, pero por la que nadie acta de manera tangible para alcanzarla, entonces el proyecto est en peligro. Las siguientes preguntas se han extrado sobre la evaluacin de la ingeniera del software desarrollado por R. S. Pressman & Associates Inc. Las preguntas se han adaptado del cuestionario de evaluacin del proceso del software del Instituto de Ingeniera del Software (IIS).

Aspectos del proceso:

Apoyan sus gestores algunas normas escritas que hagan hincapi en la importancia de un proceso estndar para el desarrollo del software? Ha desarrollado su organizacin una descripcin escrita del proceso del software a emplear en este proyecto? Estn de acuerdo los miembros del personal con el proceso del software tal y como est documentado y estn dispuestos a usarlo? Se emplea este proceso del software para otros proyectos? Ha desarrollado o adquirido su organizacin cursos de formacin de ingeniera del software para jefes de proyecto y personal tcnico? Se ha proporcionado una copia de los estndares de ingeniera del software publicados a cada desarrollador y gestor de software?

60

Se han desarrollado diseos de documentos y ejemplos para todas las entregas definidas como parte del proceso del software? Se llevan a cabo regularmente revisiones tcnicas formales de las especificaciones de requisitos, diseo y cdigo? Se llevan a cabo regularmente: revisiones tcnicas de los procedimientos de prueba y de los casos de prueba? Se documentan todos los resultados de las revisiones tcnicas, incluyendo los errores encontrados y recursos empleados? Existe algn mecanismo para asegurarse de que el trabajo realizado en un proyecto se ajusta a los estndares de ingeniera del software? Se emplea una gestin de configuracin para mantener la consistencia entre los requisitos del sistema/software, diseo, cdigo y casos de prueba? Hay algn mecanismo de control de cambios de los requisitos del cliente que impacten en el software? Hay alguna declaracin de trabajo documentada, una especificacin de requisitos software y un plan de desarrollo del software para cada subcontratacin?

Se sigue algn procedimiento para hacer un seguimiento y revisar el rendimiento de las subcontraciones?

Aspectos tcnicos:
Se emplean tcnicas de especificacin de aplicaciones para ayudar en la comunicacin entre el cliente y el desarrollador? Se emplean mtodos especficos para el anlisis del software? Emplea un mtodo especfico para el diseo de datos y arquitectnico? Est escrito su cdigo en ms de un 90 por ciento en lenguaje de alto nivel? Se han definido y empleado reglas especficas para la documentacin del cdigo? Emplea mtodos especficos para el diseo de casos de prueba? Se emplean herramientas de software para apoyar la planificacin y el seguimiento de las actividades? Se emplean herramientas de software de gestin de configuracin para controlar y seguir los cambios a lo largo de todo el proceso del software?

61

Se emplean herramientas de software para apoyar los procesos de anlisis y diseo del software? Se emplean herramientas para crear prototipos software? Se emplean herramientas de software para dar soporte a los procesos de prueba? Se emplean herramientas de software para soportar la produccin y gestin de la documentacin? Se han establecido mtricas de calidad para todos los proyectos de software? Se han establecido mtricas de productividad para todos los proyectos de software?

Si

la

mayora

de

las

cuestiones

anteriores

se

han

respondido

negativamente, el proceso del software es dbil y el riesgo es alto. Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se usarn en la construccin del producto. El entorno de ingeniera del software soporta al equipo del proyecto. Al proceso y al producto. Pero si el entorno es malo. Puede ser una fuente de riesgos significativa. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados con el entorno de desarrollo:
Tenemos disponible una herramienta de gestin de proyectos de software? Tenemos disponible una herramienta de gestin del proceso del software? Existen herramientas de anlisis y diseo disponibles? Proporcionan las herramientas de anlisis y diseo, mtodos apropiados para el producto a construir? Hay disponible, compiladores o generadores de cdigo apropiados para el producto a construir? Hay disponibles herramientas de pruebas apropiadas para el producto a construir? Tenemos disponibles herramientas de gestin de configuracin software? Hace uso el entorno de bases de datos o informacin almacenada? Estn todas las herramientas de software integradas entre s? Se ha formado a los miembros del equipo del proyecto en todas las herramientas?

62

Existen expertos disponibles para responder todas las preguntas que surjan sobre las herramientas? Es adecuada la ayuda en lnea y la documentacin de las herramientas?

Si se ha contestado negativamente a la mayora de las preguntas anteriores, el entorno de desarrollo es dbil y el riesgo es alto. Tecnologa que construir: riesgos asociados con la complejidad del sistema que se construir y la novedad de la tecnologa que est empaquetada en el sistema. Alcanzar los lmites de la tecnologa es un reto excitante. Es el sueo de casi todos los tcnicos, porque fuerza al profesional a emplear su talento al mximo. Pero tambin es muy arriesgado. La ley de Murphy parece mantener su imperio en esta parte del universo del desarrollo, haciendo extremadamente difcil predecir los riesgos, y mucho menos hacer ningn plan sobre ellos. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados con la tcnica a construir:
Es nueva para su organizacin la tecnologa a construir? Demandan los requisitos del cliente la creacin de nuevos algoritmos o tecnologa de entrada o salida? El software interacta con hardware nuevo o no probado? Interacta el software a construir con productos software suministrados por el vendedor que no se hayan probado? Interacta el software a construir con un sistema de base de datos cuyo funcionamiento y rendimiento no se han comprobado en esta rea de aplicacin? Demandan los requisitos del producto una interfaz de usuario especial? Demandan los requisitos del producto la creacin de componentes de programacin distintos de; los que su organizacin haya desarrollado hasta ahora? Demandan los requisitos el empleo de nuevos mtodos de anlisis, diseo o pruebas? Demandan los requisitos el empleo de mtodos de desarrollo del software no convencionales? Imponen excesivas restricciones de rendimiento los requisitos del producto? 63

No est seguro el cliente de que la funcionalidad pedida sea factible?

Si la respuesta a alguna de estas preguntas es afirmativa, se debera realizar una investigacin ms profundidad para valorar el riesgo potencial.
Tamao y experiencia de la plantilla de personal: riesgos asociados con la experiencia global tcnica y en el proyecto de los ingenieros de software que harn el trabajo.

La lista de verificacin de riesgos se puede organizar en diferentes formas. Las preguntas relevantes respecto de cada uno de los tpicos se pueden responder para cada proyecto de software Las respuestas a estas preguntas permiten que el planificador estime el impacto del riesgo. Un formato diferente de lista de verificacin de riesgos simplemente menciona las caractersticas relevantes para cada subcategora genrica. Finalmente, se menciona un conjunto de "componentes y controladores de riesgo" junto con su probabilidad de ocurrencia. Los controladores del desempeo, soporte, costo y calendarizacin se estudian como respuesta a las ltimas preguntas.

Evaluacin del riesgo global del proyecto Las siguientes preguntas se basan en los datos de riesgo obtenidos al entrevistar, en diferentes partes del mundo, a gestores de proyecto de software experimentados. Las preguntas estn ordenadas segn su importancia relativa en el xito de un proyecto.
1) Los altos ejecutivos de software y del cliente se han comprometido formalmente para apoyar el proyecto? 2) Los usuarios finales estn comprometidos con el proyecto y el

sistema/producto que se construir? 3) Los requisitos los han entendido completamente el equipo de ingeniera de software y sus clientes? 4) Los clientes estuvieron completamente involucrados en la definicin de los requisitos? 5) Los usuarios finales tienen expectativas realistas? 64

6) El mbito del proyecto es estable? 7) El equipo de ingeniera del software tiene la mezcla correcta de habilidades? 8) Los requisitos del proyecto son estables? 9) El equipo del proyecto tiene experiencia con la tecnologa que se implementar? 10) El nmero de personas en el equipo de proyecto es adecuado para realizar el trabajo? 11) Todos los votantes del cliente/usuario estn de acuerdo en la importancia del proyecto y en los requisitos para el sistema/producto que se construir?

Si la respuesta a alguna de estas preguntas es negativa se deben instituir sin demora los pasos de reduccin, supervisin y gestin. El grado en el que el proyecto est en riesgo es directamente proporcional al nmero de respuestas negativas a estas preguntas. Componentes y controladores del riesgo La Fuerza Area de Estados Unidos escribi un folleto con excelentes directrices para la identificacin y supresin del riesgo de software. Este enfoque requiere que el gestor del proyecto identifique los controladores del riesgo que afectan los componentes de riesgo del software: desempeo, costo, soporte y calendarizacin. En el contexto de este estudio los componentes de riesgo se definen en la forma siguiente:
Riesgo de desempeo: grado de incertidumbre de que el producto satisfaga los requisitos y se ajuste al uso que se pretende darle. Riesgo de costo: grado de incertidumbre de que se mantenga el presupuesto del proyecto. Riesgo de soporte: grado de incertidumbre de que el software resultante ser fcil de corregir, adaptar y mejorar. Riesgo de calendarizacin: grado de incertidumbre de que se mantenga la calendarizacin del proyecto y de que el producto se entregue a tiempo.

El impacto de cada controlador de riesgo sobre el componente de riesgo se divide en cuatro categoras de impacto: despreciable, marginal, crtico o catastrfico. En la figura 1 se describe una caracterizacin de las consecuencias
65

potenciales de los errores (hileras etiquetadas 1) o una falla que no permite lograr un resultado deseado (hileras etiquetadas 2). La categora de impacto se escoge con base en la caracterizacin que mejor encaje con la descripcin en la tabla. Figura 1. Evaluacin del impacto

2) PROYECCIN DE RIESGOS La proyeccin del riesgo, tambin llamada estimacin de riesgo, intenta clasificar 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. El planificador del proyecto, junto con otros gestores y personal tcnico, realizan cuatro pasos en la proyeccin del riesgo:
1) Establecimiento de una escala que refleje la posibilidad percibida de un riesgo. 66

2) Delineado de las consecuencias del riesgo. 3) Estimacin del impacto del riesgo en el proyecto y el producto. 4) Tomar nota de la precisin global de la proyeccin del riesgo de modo que no haya malas interpretaciones.

La finalidad de estos pasos es considerar los riesgos en tal forma que conduzcan al establecimiento de prioridades. Ningn equipo de software tiene los recursos para enfrentar todos los riesgos potenciales con el mismo grado de rigor. AI priorizar los riesgos el equipo puede asignar los recursos donde tengan el mayor impacto. Figura 2. Ejemplo de la tabla de riesgos antes de la clasificacin

Desarrollo de una tabla de riesgos Una tabla de riesgos ofrece al gestor de un proyecto una tcnica simple para la proyeccin de riesgos. Un equipo de proyecto comienza una lista de todos los riesgos (sin importar cun remotos sean) en la primera columna de la tabla. Esto se logra con la ayuda de la lista de verificacin de riesgos mencionada en la figura 2. Cada riesgo se clasifica en la segunda columna (por ejemplo, TP implica un riesgo de tamao del proyecto, NE implica un riesgo de negocios). En la siguiente columna de la tabla se registra la probabilidad de que ocurra cada riesgo. El valor de la probabilidad de
67

cada riesgo lo pueden estimar individualmente los miembros del equipo. stos se encuestan en una forma de "todos contra todos hasta que su evaluacin de la probabilidad del riesgo comience a convergir. Las categoras para cada uno de los cuatro componentes de riesgo (desempeo, soporte, costo y calendarizacin) se promedian para determinar un valor de impacto global. Una vez completadas las cuatro primeras columnas de la tabla de riesgos, sta se ordena segn la probabilidad y el impacto. Los riesgos de alta probabilidad y alto impacto se filtran hacia lo alto de la tabla, y los riesgos de baja probabilidad caen al fondo. Esto logra una priorizacin del riesgo de primer orden. El gestor del proyecto estudia la tabla ordenada resultante y define una lnea de corte. La lnea de corte (dibujada horizontalmente en algn punto en la tabla) implica que slo los riesgos ubicados sobre la lnea tendrn una atencin posterior. Los riesgos debajo de la lnea se reevalan para lograr una priorizacin de segundo orden. En la figura 3 se muestra el impacto y la probabilidad de riesgo influyen de manera distinta en la gestin. Un factor de riesgo que tiene un alto impacto, pero una probabilidad de que suceda muy baja, no debe absorber una cantidad significativa de tiempo de gestin. Sin embargo, los riesgos de alto impacto con moderada a alta probabilidad y los riesgos de bajo impacto con alta probabilidad deben trasladarse a los pasos de anlisis de riesgo que siguen. Todos los riesgos ubicados sobre la lnea de corte deben gestionarse. La columna rotulada RSGR contiene una referencia que apunta hacia un Plan de reduccin, supervisin y gestin de riesgo o, alternativamente, una coleccin de hojas de informacin de riesgo desarrolladas para todos los riesgos que estn sobre el corte. La probabilidad del riesgo se determina realizando estimaciones

individuales y luego desarrollando un solo valor de consenso. Aunque dicho enfoque es valioso, se han desarrollado tcnicas ms elaboradas con las cuales determinar la probabilidad del riesgo. Los controladores de riesgo se pueden evaluar sobre una escala de probabilidad cualitativa que tiene los siguientes
68

valores: imposible, improbable, probable y frecuente. Entonces se asocia la probabilidad matemtica con cada valor cualitativo (por ejemplo, una probabilidad de 0.7 a 0 95 implica un riesgo enormemente probable). Figura 3. Riesgo y preocupaciones de la gestin

Evaluacin del impacto del riesgo Tres factores afectan las consecuencias que son probables si un riesgo ocurre: su naturaleza, mbito y tiempo. La naturaleza indica los problemas que son probables si ocurre. Por ejemplo, una interfaz externa mal definida hacia el hardware del cliente (un riesgo tcnico) evitar un diserto y prueba tempranos y tal vez genere problemas de integracin de sistema ms tarde. El mbito combina la severidad (Cun seno es?) con su distribucin global (Cunto del proyecto se afectar, o cuntos clientes resultarn daados?). Finalmente, el tiempo de un riesgo considera cundo y durante qu periodo se sentir el impacto. En la mayora de los casos un gestor de proyecto tal vez quiera que ocurran las malas noticias" tan pronto como sea posible, pero en algunos casos, mientras mayor sea la demora, mejor.

69

Regresando una vez ms al enfoque de anlisis de riesgo que propuso la Fuerza Area de Estados Unidos, se recomiendan los siguientes pasos para determinar las consecuencias globales de un riesgo:
1) Determinar el valor promedio de la probabilidad de que ocurra para cada componente de riesgo. 2) Determinar el impacto para cada componente, con base en los criterios establecidos. 3) Completar la tabla de riesgos y analizar los resultados como se describe en las secciones precedentes.

La exposicin al riesgo global, ER. Se determina mediante la siguiente relacin: ER = P x C

Donde P es la probabilidad de que ocurra un riesgo, y C, el costo al proyecto en caso de que ocurra el riesgo. Por ejemplo, suponga que el equipo de software define un riesgo de proyecto en la forma siguiente: Identificacin del riesgo. De hecho, slo 70 por ciento de los componentes de software calendarizados para reutilizacin se integra en la aplicacin. La funcionalidad restante tendr que desarrollarse de modo personalizado. Probabilidad de riesgo. 80 por ciento (quiz). Impacto del riesgo. Se planificaron 60 componentes de software reutilizables. Si slo se puede emplear el 70 por ciento, 18 componentes tendran que desarrollarse desde cero (adems de otro software personalizado que se ha calendarizado para desarrollo) puesto que el componente promedio es 100 LDC y los datos locales indican que el costo de Ingeniera de software para cada uno es de 14.00 dlares, el costo (impacto) global del desarrollo de tas componentes seria 18 x 100 x 14 - 25 200 dlares. Exposicin al riesgo. ER - 0 80 x 25 200 dlares - 20 200 dlares.

70

La exposicin al riesgo se puede calcular para cada riesgo en la tabla de riesgos, una vez que se estime el costo del riesgo. La proyeccin del riesgo y las tcnicas de anlisis descritas en el Desarrollo de una tabla de riesgos y evaluacin del impacto del riesgo se aplican de manera iterativa conforme avanza el proyecto de software. El equipo del proyecto debe revisar de nuevo la tabla de riesgos en intervalos regulares, reevaluar cada riesgo para determinar cundo nuevas circunstancias cambiarn su probabilidad e impacto. Como consecuencia, tal vez sea necesario agregar nuevos riesgos a la tabla, eliminar algunos riesgos que ahora son irrelevantes y cambiar las posiciones relativas de otros. 3) REFINAMIENTO DEL RIESGO Durante las primeras etapas de la planificacin del proyecto se puede establecer un riesgo de manera muy general. Conforme pasa el tiempo y se aprende ms acerca del proyecto y el riesgo, es posible refinar el riesgo en un conjunto de riesgos ms detallados, cada uno un poco ms sencillo de refinar, supervisar y gestionar. Una forma de hacer esto es representar el riesgo en el formato condicintransicin-consecuencia. Es decir, el riesgo se establece en la forma siguiente: Dado que <condicin> entonces existe una preocupacin de que (posiblemente) <consecuencia> Mediante el empleo del formato CTC en lugar del riesgo de reutilizacin se refina en la forma siguiente: Subcondicin 1. Ciertos componentes reutilizables fueron desarrollados por terceras personas sin conocimiento de los estndares de diseo internos. Subcondicin 2. El estndar de diseo para el componente de interfaces no se ha concretado y tal vez no se ajuste con ciertos componentes reutilizables existentes.

71

Subcondicin 3. Ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el entorno destino. Las consecuencias asociadas con estas subcondiciones refinadas siguen siendo las mismas (es decir, 30 por ciento de los componentes de software tienen que someterse a ingeniera personalizada), pero el refinamiento ayuda a aislar los riesgos subyacentes y puede conducir a un anlisis y respuestas ms sencillos. 4) REDUCCIN, SUPERVISIN Y GESTIN DEL RIESGO Todas las actividades del anlisis de riesgo presentadas hasta el momento tienen una sola meta: ayudar al equipo del proyecto a desarrollar una estrategia para luchar con el riesgo. Una estrategia eficaz debe considerar tres temas:
Evitar del riesgo. Supervisar el riesgo. Gestionar el riesgo y los planes de contingencia

Si un equipo de software adopta un enfoque proactivo hacia el riesgo, evitarlo siempre es la mejor estrategia. sta se logra desarrollando un plan para reducir el riesgo. Por ejemplo, supngase que una elevada movilidad en el personal se anota como un riesgo del proyecto, r1. Con base en la historia y la intuicin administrativa, la probabilidad, I1, de una elevada movilidad se estima en 0.70 (70 por ciento, ms bien alto) y el impacto, x1, se proyecta como crtico. Esto es: una tasa elevada de movilidad tendr un impacto crtico en el costo del proyecto y la calendarizacin. Este riesgo se reduce si el gestor del proyecto desarrolla una estrategia para reducir la movilidad. Entre los posibles pasos que se toman se encuentran:
Reunirse con el personal actual para determinar las causas de la movilidad (por ejemplo, limitadas condiciones de trabajo, bajos salarios, mercado laboral competitivo). Reducir aquellas causas que se controlan antes de que comience el proyecto. Una vez iniciado el proyecto, suponer que la movilidad ocurrir y entonces desarrollar tcnicas que aseguren la continuidad cuando la gente se aleje. 72

 Organizar equipos de proyecto de modo que la informacin acerca de cada actividad de desarrollo se disperse con amplitud. Definir estndares de documentacin y establecer mecanismos que aseguren que los documentos se desarrollen en una forma oportuna. Llevar a cabo revisiones por pares de todo el trabajo (de modo que ms de una persona est "en ritmo"). Asignar un miembro de personal de respaldo por cada tecnologa critica.

Conforme avanza el proyecto se inician las actividades de supervisin del riesgo. El gestor del proyecto supervisa los factores que pueden proporcionar un indicio de si el riesgo se est volviendo ms o menos probable. En el caso de la elevada tasa de movilidad del personal, se pueden supervisar los siguientes factores:
Actitud general de los miembros del equipo con base en las presiones del proyecto. El grado en el cual el equipo est cuajado. Las relaciones interpersonales entre los miembros del equipo. Potenciales problemas con las compensaciones y los beneficios. La disponibilidad de empleo dentro y fuera de la compaa.

Adems de supervisar estos factores, un gestor de proyecto debe supervisar la efectividad de los pasos de reduccin del riesgo. El gestor del proyecto debe supervisar los documentos cuidadosamente para asegurarse de que cada uno puede permanecer por s solo y que cada uno contiene informacin que sera necesaria si una nueva persona se viera obligada a unirse al equipo de software en algn momento a la mitad del proyecto. La gestin del riesgo y los planes de contingencia suponen que los esfuerzos de reduccin han fracasado y que el riesgo se ha vuelto una realidad. Si el proyecto ya est bien avanzado y varias personas anuncian que renunciarn. Si se ha seguido la estrategia de reduccin, el respaldo est disponible, la informacin se ha documentado y el conocimiento se ha dispersado entre el equipo. Adems, el gestor del proyecto puede reenfocar temporalmente los recursos (y reajustar la calendarizacin del proyecto) hacia aquellas funciones
73

completamente estructuradas, as permite que los nuevos elementos que deben agregarse al equipo "tomen el ritmo. A los individuos que deciden marcharse se les pide detener todo el trabajo y pasar sus ltimas semanas aprendiendo el modo de transferencia. Esto puede incluir la adquisicin de conocimiento en videos, el desarrollo de documentos comentados o reuniones con otros miembros del equipo que permanecern en el proyecto. Es importante sealar que los pasos de reduccin, supervisin y gestin del riesgo (RSGR) generan costos adicionales en el proyecto. Por ejemplo, utilizar el tiempo para respaldar cualquier tecnologa crtica cuesta dinero. Por lo tanto, parte de la gestin del riesgo consiste en evaluar cundo los beneficios que generan los pasos RSGR se rezagan frente a los costos asociados con su implementacin. En esencia, el planificador del proyecto realiza un clsico anlisis costo-beneficio. Si los pasos con que se evita el riesgo de elevada movilidad de personal aumentaran tanto el costo del proyecto como su duracin en un estimado de 15 por ciento, pero el factor de costo predominante es el respaldo, el gestor puede decidir no implementar este paso. Por otra parte, si los pasos con que se evita el riesgo se proyectan para aumentar los costos en 5 por ciento y la duracin en slo 3 por ciento, el gestor probablemente pondr todo en su lugar. En un proyecto grande es posible definir 30 o 40 riesgos. Si para cada uno se identifican entre tres y siete pasos de gestin del riesgo, esta puede convertirse por s misma en un proyecto!, por esta razn se adapta la regla 80-20 con respecto al riesgo de software. La experiencia indica que 80 por ciento del riesgo del proyecto global (es decir, 80 por ciento del potencial para falla del proyecto) puede explicarse slo con 20 por ciento de los riesgos identificados. El trabajo realizado durante los primeros pasos del anlisis de riesgo ayudar al planificador a determinar cules de los riesgos se encuentran en ese 20 por ciento (por ejemplo, riesgos que conduzcan a la mayor exposicin al riesgo). Por esta razn, algunos de los riesgos identificados, evaluados y proyectados pueden no incitarse en el plan RSGR, ya que no se ubican en el crtico 20 por ciento (los riesgos con la mayor prioridad de proyecto).

74

El anlisis de seguridad y peligros de software son actividades de aseguramiento de la calidad del software que se enfocan en la identificacin y evaluacin de los peligros potenciales que pudieran afectar al software negativamente y provocar una falla en todo el sistema.

75

EL PLAN RSGR En el plan del proyecto de software se puede incluir una estrategia de gestin de riesgo o los pasos de gestin del riesgo organizarse por separado en un Plan de reduccin, supervisin y gestin del riesgo (RSGR). El plan RSGR documenta todo el trabajo realizado como parte del anlisis del riesgo y el gestor del proyecto lo emplea como parte del plan global del proyecto. Algunos equipos de software no elaboran un documento RSGR formal. En su lugar, cada riesgo se documenta individualmente mediante una hoja de informacin de riesgo (HIR). En la mayora de los casos la HIR se mantiene empleando un sistema de base de datos, de modo que la creacin y las entradas de informacin, ordenamiento de prioridades, bsquedas y otros anlisis se logran fcilmente. Una vez documentado el plan RSGR y que el proyecto ha comenzado, se inician los pasos de reduccin y supervisin del riesgo. Como ya se ha comentado, la reduccin del riesgo es una actividad encaminada a evitar el problema. La supervisin del riesgo es una actividad de seguimiento del proyecto con tres objetivos principales:
1) Valorar si los riesgos predichos de hecho ocurren. 2) Asegurar que los pasos para evitar el riesgo definidos para ste se estn aplicando con propiedad. 3) Recopilar informacin que pueda usarse en futuros anlisis de riesgo.

En muchos casos, a los problemas que ocurren durante un proyecto es posible darles seguimiento haca ms de un riesgo. Otra labor de la supervisin del riesgo es intentar ubicar el origen (qu riesgos provocaron qu problemas a travs del proyecto).

76

Hoja de informacin del riesgo

77

ESQUEMA DEL PLAN RSGR I. Introduccin. 1. Alcance y propsito del documento. 2. Visin general de los riesgos principales. 3. Responsabilidades.
a. Gestin. b. Personal tcnico.

II. Tabla de riesgo del proyecto. 1. Descripcin de todos los riesgos por encima de la lnea de corte. 2. Factores que influyen en la probabilidad e impacto. III. Reduccin, supervisin y gestin del riesgo. n. Riesgo # n. a. Reduccin.
i. ii. Estrategia general. Pasos especficos.

b. Supervisin.
i. ii. Factores a supervisar. Enfoque de supervisin.

c. Gestin.
i. Plan de contingencia. ii. Consideraciones especiales.

IV. Planificacin temporal de revisin del Plan RSGR. V. Resumen.

78

ESTUDIO DE FACTIBILIDAD O VIABILIDAD

Definicin de factibilidad
Se define como un proceso que se efecta previo a la ejecucin de un proyecto y el cual tiene como finalidad indicar los objetivos, alcances, restricciones y disponibilidad de los recursos necesarios para lograr dichos objetivos o metas sealados. Cabe mencionar que el trmino factibilidad es sinnimo de viabilidad.

Definicin del anlisis de la factibilidad del proyecto

Se conoce como anlisis de factibilidad al estudio que intenta predecir el eventual xito o fracaso de un proyecto. Para lograr esto parte basa de datos empricos (que pueden ser contrastados) a los que accede a travs de diversos tipos de investigaciones (encuestas, estadsticas, etc.).

Tipos de Factibilidad
Un estudio de factibilidad, por lo general, abarca varios aspectos esenciales en el desarrollo de todo proyecto. Dependiendo de la naturaleza y el ambiente donde ser desarrollado el proyecto, se deber hacer hincapi en uno o ms tipos de factibilidades que se presentan a continuacin: Factibilidad tcnica Factibilidad econmica Factibilidad Operativa Factibilidad Legal Factibilidad Organizacional

79

Anlisis del sistema

El anlisis del sistema es una actividad que engloba la mayora de las tareas que hemos llamado colectivamente ingeniera de sistemas basados en computadora. Algunas veces se incurre en confusin porque el trmino se usa a menudo en un contexto que alude slo a las actividades de anlisis de los requisitos del software. Para el propsito de este estudio, el anlisis del sistema se centra en todos los elementos del sistema, no slo en el software.

El anlisis del sistema se realiza al tener presente los siguientes objetivos:

1. Identificar las necesidades del cliente. 2. Evaluar la viabilidad del sistema. 3. Realizar un anlisis tcnico y econmico. 4. Asignar funciones al software, al hardware, a la gente, a la base de datos y a otros elementos del sistema. 5. Establecer restricciones de costo y tiempo. 6. Crear una definicin del sistema que sea la base para todo el trabajo posterior de ingeniera.

Para alcanzar con xito esos objetivos, se requiere experiencia, tanto en hardware como en software (as como en ingeniera humana y en base de datos). Aunque la mayora de los profesionales de la industria reconocen que el tiempo y el esfuerzo gastado en el anlisis de sistema producen dividendos importantes ms adelante en el proceso de desarrollo del sistema, todava surgen tres preguntas:

Cunto esfuerzo se debe emplear en el anlisis y en la definicin de sistemas y de software? Es difcil establecer unas directrices definitivas para determinar el esfuerzo de anlisis. El tamao del sistema y su complejidad, el rea de aplicacin, el uso final y las obligaciones del contrato son slo unas pocas de las muchas variables que afectan al
80

esfuerzo total dedicado al anlisis. Una regla de andar por casa usada a menudo es que se debe dedicar entre el 10 y el 20 por 100 de todo el fuerzo de desarrollo al anlisis del sistema y aplicar otro 10 o 20 por 100 del esfuerzo de la ingeniera del software del anlisis de los requerimientos del software. Quin lo hace? Todas las tareas han de ser dirigidas por un analista bien formado y con experiencia. El analista trabaja en contacto con el personal tcnico y administrativo, tanto del cliente como del que desarrolla el sistema. Para muchos proyectos grandes, debe crearse un equipo para cada tarea de anlisis.

Por qu es tan difcil? Se trata de una transformacin de un concepto dudoso en un conjunto concreto de elementos tangibles. Debido a que durante el anlisis la comunicacin es excepcionalmente densa, abundan las oportunidades de mal entendimiento, omisiones, inconsistencias y errores. Finalmente, la percepcin del sistema puede cambiar a medida que avanza la actividad, invalidando, de esa manera, el trabajo anterior.

Identificacin de las necesidades

El primer paso del proceso de anlisis del sistema implica la identificacin de las necesidades. El analista (ingeniero de sistema) se entrevista con el cliente o su representante. El cliente puede ser un representante de una compaa externa, del departamento de marketing de la compaa del anlisis (cuando se est definiendo un producto) o de otro departamento tcnico (cuando se va a desarrollar un sistema interno). La identificacin de las necesidades es el punto de partida en la evolucin de un sistema basado en computadora.

La informacin recogida durante la etapa de identificacin de las necesidades se especifica en un documento de conceptos del sistema. A veces, es el cliente el que prepara un documento de conceptos inicial antes de reunirse con el analista. Invariablemente, los resultados de la comunicacin analista-cliente producen modificaciones en el documento.
81

ESTUDIO DE FACTIBILIDAD O VIABILIDAD

Todos los proyectos son realizables con recursos ilimitados y un tiempo infinito. Desafortunadamente, el desarrollo de un sistema basado en computadora se caracteriza por la escasez de recursos y la dificultad (si no imposibilidad) de cumplir los plazos de entrega. Es necesario y prudente evaluar la viabilidad de un proyecto lo antes posible. Se pueden evitar meses o aos de esfuerzo, miles de millones de pesetas y una inversin profesional incalculable, si un sistema mal concebido es reconocido como tal al principio de la etapa de definicin. El anlisis de viabilidad y el anlisis del riesgo estn relacionados de varias maneras. Si el riesgo del proyecto es grande, se reduce la posibilidad de producir software de calidad. Sin embargo, durante la ingeniera del sistema se centra la atencin en cuatro reas de inters bsico:
Factibilidad econmica: Se refiere a una evaluacin del coste de desarrollo frente al beneficio final producido por el sistema desarrollado. Factibilidad tcnica: Un estudio de la funcionalidad, el rendimiento y las restricciones que pueden afectar a la posibilidad de realizacin de un sistema aceptable. Factibilidad Legal: Una determinacin de cualquier infraccin, violacin o ilegalidad que pudiera resultar del desarrollo del sistema. Alternativas: Una evaluacin de los enfoques alternativos para el desarrollo del sistema.

No ser necesario llevar a cabo un estudio de viabilidad para sistemas en los que la justificacin econmica es obvia, el riesgo tcnico es bajo, se esperan pocos problemas legales y no existe una alternativa razonable. Sin embargo, cuando no se da alguna de las anteriores condiciones, debe realizarse el estudio. La justificacin econmica es normalmente la principal consideracin para la mayora de los sistemas (excepciones notables son los sistemas de defensa nacional, los sistemas impuestos por la ley y las aplicaciones de alta tecnologa, como el programa especial). La justificacin econmica comprende un amplio
82

rango de aspectos, entre los que se encuentran el anlisis de costo-beneficio, las estrategias de ingresos a largo plazo, el impacto en otros productos o en centros de explotacin, el costo de los recursos que se necesitan para el desarrollo y el crecimiento potencial del mercado. La viabilidad tcnica es frecuentemente el rea ms difcil de evaluar en esta etapa del proceso de desarrollo del sistema. Debido a que los objetivos, las funciones y el rendimiento son de alguna manera confusos, cualquier cosa puede parecer posible si se hacen las consideraciones adecuadas. Es esencial que el proceso de anlisis y de definicin se realice en paralelo con el anlisis de viabilidad tcnica. De esta forma, se pueden juzgar las especificaciones concretas segn se van determinando. Las consideraciones que van asociadas normalmente a la viabilidad tcnica son: Riesgo del desarrollo. Puede el elemento del sistema ser diseado de

tal forma que las funciones y el rendimiento necesarios se consigan dentro de las restricciones determinadas en el anlisis? Disponibilidad de recursos.

Hay personal cualificado para desarrollar

el element del sistema en cuestin? Estn disponibles para el sistema otros recursos necesarios (de hardware y de software)? Tecnologa. Ha progresado la tecnologa relevante lo suficiente como para poder soportar el sistema?

Los desarrolladores de los sistemas basados en computadora son optimistas por naturaleza. Sin embargo, durante una evaluacin de viabilidad tcnica debera prevalecer una actitud cnica, si no pesimista. Las equivocaciones en esta etapa pueden ser desastrosas.

83

La viabilidad legal comprende un amplio rango de aspectos que incluyen los contratos, la responsabilidad, las infracciones y un millar de otros detalles frecuentemente desconocidos para el personal tcnico. El grado en el que se consideran las alternativas muchas veces est limitado por restricciones de tiempo y de dinero; sin embargo, no se debera descartar cualquier alternativa legtima, aunque no tenga quien la financie. El estudio de viabilidad puede documentarse en un informe separado de los otros documentos importantes de gestin e incluirse como apndice en la especificacin del sistema. Aunque el formato del informe de viabilidad puede variar, el esquema de la tabla 1 que sigue, cubre la mayora de los aspectos importantes. La revisin del estudio de viabilidad ha de llevarla a cabo primero el gestor del proyecto (para asegurar la fiabilidad de su contenido) y luego por el director administrativo (para determinar el estado del proyecto). El estudio debe provocar una decisin de seguir / no seguir. Debe tenerse en cuenta que durante las etapas de planificacin, especificacin y desarrollo de la ingeniera del hardware y del software, se tomarn otras decisiones del tipo seguir / no seguir. Tabla 1.- Esquema del estudio de viabilidad. I.- Introduccin.
a) Declaracin del problema. b) Entorno de implementacin. c) Restricciones.

II.- Resumen y recomendaciones de gestin.

a) Hallazgos importantes. b) Comentarios. c) Recomendaciones. d) Impacto.

III.- Alternativas.
a) Configuraciones del sistema alternativas.

84

b) Criterio utilizado en la seleccin del enfoque definitivo.

IV.- Descripcin del sistema.

a) Declaracin resumida del mbito. b) Viabilidad de los elementos asignados.

V.- Anlisis de coste-beneficio. VI.- Evaluacin del riesgo tcnico. VII.- Consideraciones legales. VIII.- Otros asuntos especficos del proyecto.

Anlisis Econmico
Se refiere a una evaluacin del costo de desarrollo frente al beneficio final producido por el sistema desarrollado. Es decir, se refiere a los recursos econmicos y financieros necesarios para desarrollar o llevar a cabo las actividades o procesos y/o para obtener los recursos bsicos que deben considerarse son el costo del tiempo, el costo de la realizacin y el costo de adquirir nuevos recursos. Los estudios de factibilidad econmica incluyen anlisis de costos y beneficios asociados con cada alternativa del proyecto. Con anlisis de costos/beneficio, todos los costos y beneficios de adquirir y operar cada sistema alternativo se identifican y se hacen una comparacin de ellos.
Tiempo del analista. Costo de estudio. Costo del tiempo del personal. Costo del tiempo. Costo del desarrollo/adquisicin.

Un estudio de factibilidad requiere ser presentado con todas la posibles ventajas para la empresa u organizacin, pero sin descuidar ninguno de los elementos necesarios para que el proyecto funcione. Para esto dentro de los

85

estudios de factibilidad se complementan dos pasos en la presentacin del estudio:

Requisitos ptimos. Requisitos Mnimos.

El primer paso se refiere a presentar un estudio con los requisitos ptimos que el proyecto requiera, estos elementos debern ser los necesarios para que las actividades y resultados del proyecto sean obtenidos con la mxima eficacia. El segundo paso consiste en un estudio de requisitos mnimos, el cual cubre los requisitos mnimos necesarios que el proyecto debe ocupar para obtener las metas y objetivos, este paso trata de hacer uso de los recursos disponibles de la empresa para minimizar cualquier gasto o adquisicin adicional. Entre la informacin ms relevante que contiene el estudio de viabilidad se encuentra el anlisis de costo-beneficio una evaluacin de la justificacin econmica para un proyecto de sistema basado en computadora. El anlisis de costo-beneficio seala los costos del desarrollo del proyecto y los contrasta con los beneficios tangibles (esto es, medibles directamente en pesetas) e intangibles del sistema. El anlisis de costo-beneficio es complicado porque los criterios varan segn las caractersticas del sistema a desarrollar, el tamao relativo del proyecto y la recuperacin esperada de la inversin como parte del plan estratgico de la compaa. Adems, muchos beneficios obtenidos de los sistemas basados en computadora son intangibles (por ejemplo: una mejor calidad del diseo mediante una optimizacin iterativa, una mayor satisfaccin del cliente debida a un control programable y unas mejores decisiones comerciales a partir de datos de ventas con formato previamente analizados). Puede ser difcil lograr comparaciones directas cuantitativas.

86

El anlisis de los beneficios diferir dependiendo de las caractersticas del sistema. Los beneficios de los sistemas de informacin de gestin mostrados en la Tabla 2 que se muestra ms adelante. La mayora de los sistemas de proceso de datos se desarrollan al tener como principal objetivo una mejor cantidad, calidad, rapidez y organizacin de la informacin. As, los beneficios de la Tabla 2 se centran en el acceso a la informacin y su impacto en el entorno del usuario. Los beneficios que se pueden asociar a programas de anlisis cientfico y de ingeniera o a un producto basado en microprocesador pueden diferir substancialmente. Los beneficios de un sistema nuevo siempre se determinan de acuerdo con el modo de trabajo ya existente. Por ejemplo, consideremos un sistema de diseo asistido por computadora (CAD) que vaya a remplazar a elementos del proceso manual de diseo en ingeniera. El analista de sistemas debe definir caractersticas ponderables del sistema existente (diseo manual) y del sistema propuesto (CAD). Seleccionando el tiempo de produccin de un dibujo completo y detallado (t-dibujo) entre las muchas cantidades medibles, el analista llega a la conclusin de que el sistema CAD supondr una reduccin de 4 a 1 en ese tdibujo. Para cuantificar con ms detalle este beneficio, se determina los siguientes datos: t-dibujo, tiempo medio de dibujo = 4 horas. D, coste por hora de dibujo = 2000 ptas. N, nmero de dibujos por ao =8000. p, porcentaje de dibujo que se va a realizar en el sistema CAD= 60 x 100 Conocidos los datos anteriores, puede establecer una estimacin del ahorro anual el beneficio: Ahorro en el costo del tiempo = reduccin x t dibujo x n x c x p = 9 600 000 ptas. por ao

87

Tabla 2.- Posibles beneficios del sistema de informacin. Beneficios de las contribuciones a las tareas de clculo e impresin Reduccin del coste en clculos e impresiones (RC).
Mejora en la exactitud de las tareas de clculo (RE). Posibilidad de cambiar rpidamente las variables y los valores en los programas de clculo (AF). Gran incremento en la velocidad de los clculos y las impresiones (AV).

Beneficios de las contribuciones a las tareas de mantenimiento de registros Posibilidad de recoger y guardar automticamente datos de los registros (RC, AV, RE).
Mantenimiento de registros ms completo y ms sistemtico (RC, RE). Aumento de la capacidad para el mantenimiento de registros en trminos de espacio y coste (RC). Estandarizacin del mantenimiento de registros (RC, AV). Aumento de la cantidad de datos que se pueden guardar por registro (RC, AV). Mejora en la seguridad en el almacenamiento de registros (RE, RC, MG). Mejora en la portabilidad de los registros (AF, RC, AV).

Beneficios de las contribuciones a las tareas de bsqueda de registros Obtencin de registros ms rpida (AV).
Mejores posibilidades de acceso a registros de grandes bases de datos (AF). Mejores posibilidades de cambio de registros en bases de datos (AF, RC). Posibilidad de enlazar lugares que precisan poder efectuar bsquedas a travs de telecomunicaciones (AF, AV). Mejores posibilidades de mantener un registro sobre los accesos a los registros y por quin (RE, MG). Posibilidad de auditar y analizar la actividad de bsqueda de registros (MG, RE).

Beneficios de las contribuciones a la posibilidad de reestructuracin del sistema. Posibilidad de cambiar simultneamente clases enteras de registros (AV, AF, RC). Posibilidad de mover de lugar grandes archivos de datos (AV, AI).
88

Posibilidad de crear nuevos archivos, mezclando partes de otros archivos (AV, AF).

Beneficios de las contribuciones a las posibilidades de anlisis y de simulacin Posibilidad de llevar a cabo rpidamente complejos clculos simultneos (AV, AF, RE).
Posibilidad de crear simulaciones de fenmenos complejos con el fin de responder a preguntas del tipo qu pasa si...? (MG, AF). Posibilidad de agregar grandes cantidades de datos de distintas formas que sean tiles para la planificacin y la toma de decisiones (MG, AF).

Beneficios de las contribuciones al control de procesos y de recursos. Reduccin de la necesidad de trabajo forzado en el control de procesos y de recursos (RC).
Mejores posibilidades de afinar procesos tales como la lnea de ensamblaje (RC, MG, AV, RE). Mejores posibilidades de mantener una continua monitorizacin de los procesos y los recursos disponibles (MG, RE, AF).

Otros beneficios tangibles del sistema CAD seran tratados de una manera similar. A los beneficios intangibles (por ejemplo: mejor calidad de diseo y mayor estmulo para los empleados) se les puede asignar valores en pesetas o usarlos como apoyo de una recomendacin de seguir, si fuese oportuna. En la Tabla 3 se exponen los costos asociados con el desarrollo de un sistema basado en computadora. El analista estima cada costo y luego utiliza los costes del desarrollo y los que surjan sobre la marcha para determinar la recuperacin de la inversin, el punto de igualdad y el perodo de amortizacin. El grfico que se muestra en la figura 5.6 ilustra estas caractersticas para el ejemplo el sistema CAD expuesto anteriormente. Asumimos que el ahorro total por ao ha sido estimado en 9 600 000 ptas., que el coste total del desarrollo se ha estimado en 20 400 000 ptas. y que los costos anuales se han estimado en 3 200 000 ptas.

89

Tabla 3.-Posibles costes del sistema de informacin. Costes de avituallamiento.

Coste de consultara. Coste de la compra o alquiler del equipo actual. Coste de la instalacin del equipo. Coste del acondicionamiento del lugar destinado al equipo (aire acondicionado, seguridad, etc.). Coste del capital. Coste de los gestores y el personal encargados del avituallamiento.

Costes de puesta a punto.

Coste del software del sistema operativo. Coste de la instalacin del equipo de comunicaciones (lneas telefnicas, lneas de datos, etc.) Coste del personal dedicado a la puesta a punto. Coste de las actividades de bsqueda y contratacin de personal. Coste de los trastornos al resto de la organizacin. Coste de la gestin requerida para dirigir la actividad de puesta a punto.

Costes relativos al proyecto.

Coste de la compra de software de aplicacin. Coste de modificaciones del software para ajustarse a los sistemas locales. Coste de personal, generales, etc., del desarrollo interno de aplicaciones. Coste de la formacin del personal en el uso de las aplicaciones. Coste de los procedimientos de recoleccin de datos y de recoleccin de datos de instalacin. Coste de la preparacin de documentacin Coste de la gestin del desarrollo.

Costes continuos.
Coste del mantenimiento del sistema (hardware, software y utilidades). Coste de los alquileres (electricidad, telfono, etc.). Coste de la depreciacin del hardware. 90

Coste de la plantilla involucrada en las actividades de gestin, operacin y planificacin del sistema de informacin.

Otro aspecto del anlisis de costo-beneficio es la consideracin de los costes incrementales asociados con los beneficios aadidos (mayor o mejor funcionalidad y rendimiento). Para los sistemas basados en computadora, la relacin incremental de coste-beneficio se puede representar como en la figura 5.7. En algunos casos (curva AA) los costes se incrementan proporcionalmente a los beneficios hasta un determinado punto. Despus de ese punto, cada beneficio adicional es demasiado caro. Por ejemplo, consideremos una funcin de sondeo en tiempo real que tiene 500 milisegundos de tiempo muerto. Se puede aadir nuevas tareas a un costo relativamente bajo; sin embargo, si la ejecucin total de la tarea se aproxima a los 500 milisegundos, el costo de implementacin aumenta drsticamente, ya que se debe mejorar el rendimiento global.

En otros casos (curva ABCC), los costes aumentan proporcionalmente hasta A y despus se nivelan a favor de los beneficios aadidos (hasta B), antes de aumentar drsticamente (en C) para los posteriores beneficios. Como ejemplo,

91

consideremos un sistema operativo monousuario que se va mejorando hasta soportar finalmente varios usuarios. Una vez que se dispone del soporte multiusuario, la tasa de aumento del coste al aadir funciones multiusuario puede bajar un poco. Sin embargo, una vez que se alcance la capacidad mxima del procesador, las nuevas funciones requerirn un procesador ms potente, con el consiguiente gran incremento en el coste. La siguiente cita caracteriza mejor el anlisis de coste-beneficio: Al igual que se olvida la retrica poltica despus de las elecciones, puede que se olvide el anlisis de coste-beneficio una vez que comienza la implementacin del proyecto. Sin embargo, es extremadamente importante, ya que ha sido el vehculo con el que se ha conseguido la aprobacin por parte de la gestin. Slo gastando el tiempo necesario para evaluar la viabilidad, reducimos las oportunidades de situaciones extremadamente embarazosas (o ms que embarazosas) en etapas posteriores de un proyecto de un sistema. El esfuerzo gastado en el anlisis de viabilidad que resulta en la cancelacin de un proyecto propuesto no es un esfuerzo desaprovechado.

Anlisis Tcnico
Un estudio de la funcionalidad, el rendimiento y las restricciones que pueden afectar a la posibilidad de realizacin de un sistema aceptable. El analista debe averiguar si es posible actualizar o incrementar los recursos tcnicos actuales de tal manera que satisfagan los requerimientos bajo consideracin. Otra de las definiciones es que se refiere a los recursos necesarios como herramientas, conocimientos, habilidades, experiencia, etc., que son necesarios
92

para efectuar las actividades o procesos que requiere el proyecto. Generalmente se refiere a elementos tangibles (medibles). El proyecto debe considerar si los recursos tcnicos actuales son suficientes o deben complementarse. El anlisis de factibilidad tcnica evala si el equipo y software estn disponibles (o, en el caso del software, si puede desarrollarse) y si tienen las capacidades tcnicas requeridas por cada alternativa del diseo que se est considerando. Los estudios de factibilidad tcnica tambin consideran las interfaces entre los sistemas actuales y nuevos.
Mejora del sistema actual. Disponibilidad de tecnologa que satisfaga las necesidades.

Durante el anlisis tcnico, el analista evala los mritos del conocimiento de sistema, mientras que al mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, facilidad de mantenimiento. En algunos casos la etapa de anlisis del sistema tambin incluye una cantidad limitada de investigacin y de diseo. El anlisis tcnico empieza con una definicin de viabilidad tambin del sistema propuesto. Qu tecnologas se requieren para conseguir la funcionalidad y el rendimiento del sistema? Qu nuevos materiales, mtodos, algoritmos o procesos se requieren y cul es el riesgo de su desarrollo? Cmo afectarn al coste estos elementos de tecnologa? Las herramientas de que se puede disponer para el anlisis tcnico en las tcnicas matemticas de modelizacin y optimizacin en la probabilidad y la

estadstica, en la teora de colas y en la teora de control. Sin embargo, es importante tener en cuenta que la evaluacin analtica no es siempre posible. La modelizacin (bien matemtica o fsica es un mecanismo efectivo para el anlisis tcnico de sistemas basados en computadoras. La figura 5.8 ilustra el flujo global de informacin del proceso de modelizacin

93

El modelo se crea a partir de la observacin del mundo real o de una aproximacin basada en los objetivos del sistema. El analista comprueba el comportamiento del modelo y lo compara con el del mundo real o con el del sistema esperado, obteniendo informacin de viabilidad tcnica para el sistema propuesto.

. Blanchard y Fabrycky definen un conjunto de criterios para el uso de modelos durante el anlisis tcnico de sistemas:
El modelo debe representar la dinmica de la configuracin del sistema que est siendo evaluado, de una forma que sea suficientemente simple de comprender y manipular, y tambin que est lo suficientemente cerca de la realidad operativa como para obtener resultados satisfactorios. El modelo debe realzar aquellos factores que sean ms relevantes para el problema en cuestin y suprimir aquellos que no sean importantes. El modelo debe ser amplio, incluyendo todos los factores relevantes, y fiable en cuanto a repeticin de resultados. 94

El diseo del modelo debe ser lo suficientemente simple como para permitir una rpida implementacin de la resolucin del problema. A no ser que la herramienta pueda ser utilizada de una manera rpida y eficiente por el analista o por el gestor, ser de poca utilidad. Si el modelo es grande y muy complejo, puede ser apropiado desarrollar una serie de modelos en los que la salida de uno pueda ser conectada a la entrada de otro. Tambin puede ser deseable evaluar un elemento especfico de un sistema independientemente del resto de los elementos.

El diseo del modelo debe incorporar previsiones para poder modificarlo y/o expandirlo fcilmente y permitir la evaluacin de factores adicionales si se requieren. En un desarrollo satisfactorio del modelo, a menudo se hace una serie de intentos antes de alcanzar el objetivo final. Los intentos iniciales pueden hacer evidentes ciertas lagunas en la informacin que no se hayan detectado a primera vista y, consecuentemente, sugerir cambios beneficiosos.

Los resultados del anlisis tcnico son la base de otra decisin del tipo seguir/ no seguir con el sistema. Si el riesgo tcnico es alto, si los modelos indican que la funcionalidad o el rendimiento deseados no pueden ser alcanzados, o si las piezas no encajan bien.

Anlisis Operativa
Se refiere a todos aquellos recursos donde interviene algn tipo de actividad (procesos), depende de los recursos humanos que participen durante la operacin del proyecto. Durante esta etapa se identifican todas aquellas actividades que son necesarias para lograr el objetivo y se evala y determina todo lo necesario para llevarla a cabo. Comprende una determinacin de la probabilidad de que un nuevo sistema se use como se supone.
Operacin garantizada. Uso garantizado.

95

Anlisis Legal
Una determinacin de cualquier infraccin, violacin o ilegalidad que pudiera resultar del desarrollo del sistema. Lo que Implica revisar si el desarrollo del proyecto implica la violacin de alguna ley, decreto, ordenanza o norma legal, bien sea a nivel nacional, estatal o municipal.
Ley Orgnica de las Telecomunicaciones. Ley de Ciencia, Tecnologa e Innovacin. Ley Especial sobre Delitos Informticos. Decreto con fuerza de Ley de mensaje de Datos y Firmas Electrnicas.

Anlisis Organizacional
Implica el estudio de los efectos que puede generar el proyecto dentro de la organizacin donde ser implementado.

Aspectos donde pueden tener impacto:

Comunicacin organizacional: Mejora la comunicacin? Eficiencia en los procesos: Acelera la produccin? Entra en conflicto con otros procesos de la organizacin? Estructura organizacional: Su impacto afecta la estructura organizacional? 96