• Author / Uploaded
• EL Rey Azul

Citation preview

PROFESORA M.T.I. MONTSERRAT MASDEFIOL SUAREZ

CARRERA ING. EN SISTEMAS COMPUTACIONALES

MATERIA GESTIÓN DE PROYECTOS DE SOFTWARE

TRABAJO APUNTES DE UNIDAD 3

ALUMNO

SERRANO BLAS, EPIFANIO GRUPO 704 “A”

SAN ANDRÉS TUXTLA, VER., 20 DE SEPTIEMBRE DEL 2013

Contenido UNIDAD 3 PLANIFICACIÓN DEL PROYECTO. .................................................................... 4 Objetivo de la unidad: ..................................................................................................... 4 Criterios de evaluación: .................................................................................................. 4 Temario:.......................................................................................................................... 4 Objetivo del proyecto .............................................................................................................. 5 ¿Qué es un proyecto? .................................................................................................... 5 ¿Qué es gestión 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 específicos ................................................................................ 10 ESTIMACIONES DE TIEMPO.............................................................................................. 12 ¿QUIEN LO HACE? ......................................................................................................... 13 CALENDARIZACIÓN DEL PROYECTO .......................................................................... 13 CONSIDERACIONES ...................................................................................................... 14 EJEMPLO DE CALENDARIZACIÓN ............................................................................... 14 REGLA 40-20-40 .............................................................................................................. 15 CRONOGRAMA ............................................................................................................... 16 RUTA CRÍTICA............................................................................................................. 21 Diferencias entre los métodos pert y cpm .................................................................... 22 PERT .................................................................................................................................... 22 CPM ...................................................................................................................................... 22 USOS. ........................................................................................................................... 23 VENTAJAS PERT y CPM ............................................................................................. 23 PROCEDIMIENTO PARA TRAZAR UN MODELO DE RED ........................................... 24 MÉTODO PERT (Program Evaluation and Review Technique) ...................................... 26 PASOS EN EL PROCESO DE PLANEAMIENTO DEL PERT ..................................... 27 VENTAJAS DEL PERT ................................................................................................ 30 LIMITACIONES ............................................................................................................ 31 ESTIMACIONES .................................................................................................................. 32 ESTIMACIÓN PARA PROYECTOS DE SOFTWARE ......................................................... 35

2

OBSERVACIONES ACERCA DE LA ESTIMACIÓN ....................................................... 36 EL PROCESO DE PLANIFICACIÓN DEL PROYECTO ............................................... 37 ÁMBITO DEL SOFTWARE Y FACTIBILIDAD ................................................................. 37 RECURSOS ..................................................................................................................... 39 ESTIMACIÓN DE COSTOS DE SOFTWARE ..................................................................... 42 TÉCNICAS DE DESCOMPOSICIÓN .............................................................................. 43 ANÁLISIS DE RIESGOS ...................................................................................................... 53 ANÁLISIS Y GESTIÓN DE RIESGOS ................................................................................. 53 ESTRATEGIAS DE RIESGO REACTIVAS Y PROACTIVAS .............................................. 53 RIESGOS DEL SOFTWARE ................................................................................................ 54 PRINCIPIOS DE LA GESTIÓN DE RIESGOS ..................................................................... 56 PROCESO DE ANÁLISIS DE RIESGOS ............................................................................. 56 1)

IDENTIFICACIÓN DE RIESGOS .............................................................................. 56 Evaluación del riesgo global del proyecto ........................................................................ 64 Componentes y controladores del riesgo ......................................................................... 65

2)

PROYECCIÓN DE RIESGOS ................................................................................... 66 Desarrollo de una tabla de riesgos ................................................................................... 67 Evaluación del impacto del riesgo .................................................................................... 69

3)

REFINAMIENTO DEL RIESGO ................................................................................ 71

4)

REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO ...................................... 72

EL PLAN RSGR ................................................................................................................... 76 ESQUEMA DEL PLAN RSGR .............................................................................................. 78 ESTUDIO DE FACTIBILIDAD O VIABILIDAD ..................................................................... 79 Definición de factibilidad ................................................................................................... 79 Definición del análisis de la factibilidad del proyecto ....................................................... 79 Tipos de Factibilidad ......................................................................................................... 79 Análisis del sistema .......................................................................................................... 80 Identificación de las necesidades ..................................................................................... 81 ESTUDIO DE FACTIBILIDAD O VIABILIDAD ..................................................................... 82 Análisis Económico .......................................................................................................... 85 Análisis Técnico ................................................................................................................ 92 Análisis Operativa ............................................................................................................. 95 Análisis Legal.................................................................................................................... 96 Análisis Organizacional .................................................................................................... 96

3

UNIDAD 3 PLANIFICACIÓN DEL PROYECTO. Objetivo de la unidad: Planificar un proyecto de software desde la definición del objetivo, la estimación de tiempos, costos y personal requerido, identificando la existencia de riesgos y proponiendo acciones para reducir su impacto en el negocio, hasta el análisis de la viabilidad del mismo.

Criterios de evaluación:  Reporte de investigación

35%

 Exposición

25%

 Avance del proyecto

40%

Temario: 3.1 Objetivo del proyecto 3.2 Estimaciones de tiempo 3.3 Estimaciones de costo 3.4 Estimación de personal requerido 3.5 Análisis de riesgo 3.6 Análisis de la viabilidad del proyecto.

4

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 específicos y a unas restricciones de tiempo costo y recursos. Características básicas:  Temporal, debe estar delimitado entre una fecha de inicio y otra de finalización.  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 intervención 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 planificación.  El producto final tiene que cumplir unas especificaciones.

¿Qué es gestión de un proyecto? Gestionar es aplicar conocimientos, técnicas 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. Básicamente podemos hablar de 4 dimensiones:  Técnica: En la que se busca el resultado vaya acorde a lo que se pidió.  Económica: 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.  Estratégica: Ya que el proyecto permite adquirir experiencia, tecnologías y otros elementos que le permitirán seguir compitiendo en un mercado.

Fases de un proyecto Un proyecto pasa a través de 4 fases identificables: 1. Concepción del proyecto: Es cuando surge una idea nueva, que podría ser un nuevo producto, un nuevo mercado o un nuevo proceso, lo cual muy posiblemente lleve a la investigación, desarrollo, construcción o instalación de nuevos elementos y que al ser considerados viables hacen surgir el proyecto. 2. Desarrollo: Una vez es considerado viable en la fase concepción se pasa a desarrollarlo, que significa hacer la planificación detallada del proyecto y la su programación estableciendo unas fechas de inicio y terminación. 3. Realización: Es la fase en la cual se realiza todo lo referente a la admón y el control del proyecto, tanto la gerencia del proyecto como el cliente están permanentemente informados del progreso del proyecto, costos y gastos, cumplimiento y eventualidades. 6

4. Terminación 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 información importante como son eficiencia de los métodos utilizados, de los equipos de trabajo y calidad de los proveedores si los hubiere.

Definición del problema: Un problema existe cuando hay 3 elementos, cada uno claramente definido.   

Una situación inicial. Una situación final u objetivo a alcanzar. Restricciones o pautas respecto de métodos, actividades, tipos de operaciones, etc., sobre los cuales hay acuerdos previos.

Resolver un problema implica realizar tarea que demandan procesos de razonamientos más o menos complejos y no implemente una actividad asociativa y rutinaria. En todo proceso de decisiones se hace sumamente importante definir muy claramente cuál es el problema de decisión. Es común 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. Realización de prototipos. Documentación cerrada con las especificaciones.

7

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.

Definición

del

objetivo

Evaluación decisión

Que del proyecto

y

Gestión realización

de

la del

proyecto.

El QUE del proyecto. Objetivo: Expresión concreta del resultado a obtener en términos de: alcance, desempeño, tiempo y costo. Que resultado debo lograr concretamente durante la ejecución del proyecto para alcanzar el OBJETIVO GLOBAL. Objetivos específicos: Se debe definir específicamente el que debo lograr con la ejecución del proyecto para alcanzar el objetivo general. Cada objetivo específico que defina consumirá recursos para alcanzarse. 8

Características:  Concreto, no generales.  Verificable objetivamente que se alcanzó el objetivo  Realista y alcanzables.  Consiste con los recursos disponibles o previstos.  Consistentes con los planes, políticas y procedimientos de la empresa.  No excesivamente complejos.

Entregables ¿Cómo alcanzo los objetivos específicos? ¿Qué debo tener al final del proyecto para decir que cada objetivo específico se alcanzó?

Entregables Resultados tangibles y verificables que marcan que uno o varios objetivos se alcanzaron. Están relacionados con el ―como‖ voy a realizar el proyecto. ¿Qué producto voy a entregar para alcanzar el objetivo?

Definición del alcance. Subdivisión de proyecto en entregables más pequeños y manejables tal que: Permita asegurar costo, tiempo y recursos estimados. Definir una línea de base para medir y controlar performance. Facilitar una clara. ¿Que son los objetivos del proyecto? Los objetivos son los propósitos del proyecto. Son los elementos según 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 específicos. Responden a una acción. 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 aplicación del método científico en la resolución 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 relación con el problema resolver y su solución.

10

Objetivos específicos  Generalmente existen muchos objetivos específicos.  Estos objetivos enmarcan todas aquellas acciones, que se convierten en los propósitos específicos que el proyecto debe alcanzar y cuya sumatoria lleva, sin duda alguna, a la obtención del objetivo general y por ende a la solución 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 metodología para alcanzarlos.  Deben ser escogidos cuidadosamente para no saturar la formulación 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 acción  Un producto  Un resultado  Se inicia con un verbo.  Después se describe el fenómeno  Luego a quien para tener una finalidad.

11

ESTIMACIONES DE TIEMPO La realidad de un proyecto técnico, tal como uno de software, es que hay que realizar cientos de tareas pequeñas en un orden determinado antes de poder alcanzar la meta final. Las tareas están interrelacionadas en una secuencia lógica en el sentido de que algunas de ellas no pueden empezar hasta que otras se hayan terminado. Algunas tareas se encontrarán en el camino principal (ruta crítica), de manera que si una de estas tareas críticas se retrasa, la fecha de terminación del proyecto se pone en peligro. El administrador o líder del proyecto debe definir todas las tareas del proyecto, identificar las que son críticas 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 duración prevista del proyecto, asignando el esfuerzo a las tareas específicas de la ingeniería de software. Es crear una red de tareas de ingeniería 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 básicos que guían la calendarización del proceso:  Compartimentación: El proyecto debe dividirse en compartimientos en varias actividades, acciones y tareas manejables.  Interdependencia: Se debe de determinar la acción o tarea compartida, algunas tareas deben ocurrir en secuencia mientras que otras pueden ocurrir en paralelo.

12

 Asignación de tiempo: A cada tarea por calendarizar se le debe asignara cierto

número

de

unidades

de

trabajo

(Persona,

día,

esfuerzo).

Validación de esfuerzo: Todo proyecto tiene un número definido de personas en el equipo de software.  Definición de responsabilidades: Toda tarea calendarizada se le debe asignar a un miembro específico del equipo.  Definición de resultados: Toda tarea calendarizada debe tener un resultado definido.  Definición 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 más 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 están involucrados deben enseñar 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 información solicitada a los ingenieros de software. En el plano individual, los mismos ingenieros de software.

CALENDARIZACIÓN DEL PROYECTO  Primero se selecciona el modelo de proceso apropiado  Identificación de tareas  Estimación 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

CALENDARIZACIÓN

Y

SEGUIMIENTO

DEL

PROYECTO DE SOFTWARE CONSIDERACIONES  Estimar la complejidad del problema y los costos de desarrollo de la solución.  La productividad no es proporcional al número 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 planificación.  La calendarización se revisa cuando se refinan estimaciones, cuando cambian restricciones o cuando se reasignan recursos.

EJEMPLO DE CALENDARIZACIÓN

14

REGLA 40-20-40 Esta es una regla que usualmente se sigue, en la cual se asigna el 40% del esfuerzo al análisis y diseño de software, el 20% del esfuerzo a la codificación y el ultimo 40% a la realización de pruebas del sistema, esta distribución se utiliza como guía, la distribución final del proceso la dictan las características 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 aplicación  Proyectos de mantenimiento de aplicación  Proyectos de reingeniería 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 representación grafico de flujo de tareas del proyecto

Es importante siempre encontrar la ruta crítica estas son las tareas que se deben completar la calendarización 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 periódicas haciendo evaluaciones de los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniería 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 información solicitada a los ingenieros de software y en el plano individual, los mismos ingenieros de software.

16

En la construcción de un sistema complejo muchas tareas de ingeniería 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 difíciles de comprender sin una calendarización. Al igual que es imposible evaluar el progreso de un proyecto de software moderado y grande sin una calendarización. A cada tarea se le asigna esfuerzo y duración y se crea una red de tareas (También llamada red de actividad) de tal forma que permitirá al equipo de software cumplir con la fecha límite de entrega especificada. La calendarización 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 estén indicadas adecuadamente. 4. Los recursos estén asignados para el trabajo que se realizara. 5. Los hitos estén 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  Subestimación razonable de la cantidad de esfuerzo o de recursos  Riesgos predecibles o impredecibles que no se consideraron  Dificultades técnicas  Dificultades humanas  Falta de comunicación  Falla en la gestión del proyecto Que hacer antes de aceptar un proyecto: Realizar una estimación detallada empleando datos históricos de proyectos previos aplicar un modelo de proceso incremental y documentar el plan Reunirse con el cliente, y con la estimación detallada, explicar porque la fecha límite 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 versión 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 técnico es que cientos de pequeñas tareas deben de realizarse para lograr una meta mayor, algunas de las tareas están fuera de la corriente principal y se pueden completar sin preocuparse acerca de su impacto sobre la fecha de terminación del proyecto, otras tareas se encuentran en la trayectoria crítica y si estas tareas se retrasan en la calendarización se pone en riesgo la fecha de terminación del proyecto. 18

El gestor debe de tener un calendarización que permita supervisar el progreso y controlar el proyecto. La calendarización del proyecto de software es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto al asignar el esfuerzo a tareas específicas. La calendarización evoluciona a lo largo del tiempo:  Calendarización

macroscópica: De

identifican

las

principales

actividades del marco de trabajo del proceso y las funciones de producto a las que se aplican.  Calendarización detallada: Se identifican y calendarizan tareas específicas del software (Requeridas para completar una actividad). Una calendarización demasiado optimista no genera una calendarización real más corta, sino una mayor. Cuando se desarrolle una calendarización, compartiméntese el trabajo, anótense las interdependencias de las tareas, asígnese esfuerzo y tiempo a cada tarea, defínase responsabilidades, resultados e hitos. El desarrollo de una calendarización del proyecto requiere distribuir un conjunto de tareas a lo largo de la línea del tiempo del proyecto. Aunque es difícil desarrollar una taxonomía completa de tipos de proyectos de software, en la mayoría 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 tecnología. Proyectos de nuevas aplicaciones, los cuales se llevan a cabo como secuencia de una solicitud especifica del cliente. Proyectos de mejora de la aplicación, estos ocurren cuando el software existente experimenta grandes modificaciones en la función, el desempeño o las interfaces visibles para el usuario final. 19

Proyectos de mantenimiento de aplicación, los cuales corrigen, adaptan o extienden el existente en forma que no sea obvio inmediatamente para el usuario final. Proyectos de reingeniería, 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 tecnología:  La determinación del ámbito del concepto precisa el ámbito global, la planeación preliminar del concepto establece la habilidad de la organización para cometer el trabajo que entraña el ámbito del proyecto.  La valoración del riesgo de la tecnología evalúa el riesgo asociado que se implementara como parte del ámbito del proyecto y l aprueba del concepto demuestra la viabilidad de una nueva tecnología en el contexto del software, la implementación del concepto pone en práctica la representación del concepto en una forma que pueda revisarla un cliente.  La reacción del cliente solicita retroalimentación acerca de un

concepto de nueva tecnología y se dirige a aplicaciones específicas de los clientes. Una red de tareas o también denominada red de actividad, es una representación gráfica del flujo de tareas en un proyecto y es un mecanismo útil para bosquejar las dependencias entre tareas y determinar la ruta crítica. Se le puede dar seguimiento a la calendarización a través 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 evaluación de resultados de todas las revisiones realizadas a lo largo del proceso de ingeniería del software.

20

En la calendarización de un proyecto de software se utiliza la técnica de evaluación y revisión programada PERT y CPM, técnicas que reciben impulso de la información ya desarrollada en actividades tempranas de la planeación del proyecto.  Estimación del esfuerzo.  Descomposición de la funciones del producto.  Selección del modelo de proceso y conjunto de tareas apropiados  Descomposición de tareas  Cronogramas: También llamado grafica de Gantt, ya sea que se desarrollen para cada actividad o para cada función o para todo el proyecto

RUTA CRÍTICA

RED DE ACTIVIDADES 1

1

4/9/0

1

5

5 T

M 3

1

5/9/0

4

T6

2 O

2 5/10/0 M6

M

1 INICI

9

/10/0

T /9/0

T

4

M 3

1

2

5

0

T2

T

T11

7

2

1 0

1

5/9/0 T4

M

0

T5

2

8/9/0

/11/0

1/10/0

M 8

M 7

1 5

M5 1

5

1

T10

2

T12

5 T8

1 0 FINA 1 L 9/11/0

21

Diferencias entre los métodos pert y cpm La principal diferencia entre los métodos es la manera en que se realizan los estimativos de tiempo.

PERT  Probabilístico.  Considera que la variable de tiempo es una variable desconocida de la cual solo se tienen datos estimativos.  El tiempo esperado de finalización de un proyecto es la suma de todos los tiempos esperados de las actividades sobre la ruta crítica.  Suponiendo que las distribuciones de los tiempos de las actividades son independientes, (una suposición fuertemente cuestionable), la varianza del proyecto es la suma de las varianzas de las actividades en la ruta crítica.  Considera tres estimativos de tiempos: el más probable, tiempo

optimista, tiempo pesimista.

CPM  Determinístico. 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 algún retardo en el proyecto, se hacen esfuerzos por lograr que el proyecto quede de nuevo en programa cambiando la asignación de recursos.  Considera que las actividades son continuas e interdependientes, siguen un orden cronológico y ofrece parámetros del momento oportuno del inicio de la actividad.  Considera tiempos normales y acelerados de una determinada

actividad, según la cantidad de recursos aplicados en la misma. 22

USOS. El campo de acción de este método es muy amplio, dada su gran flexibilidad y adaptabilidad a cualquier proyecto grande o pequeño. Para obtener los mejores resultados debe aplicarse a los proyectos que posean las siguientes características: 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 mínimo, sin variaciones, es decir, en tiempo crítico. Que se desee el costo de operación más bajo posible dentro de un tiempo disponible. Dentro del ámbito aplicación, el método se ha estado usando para la planeación y control de diversas actividades, tales como construcción de presas, apertura de caminos, pavimentación, construcción de casas y edificios, reparación de barcos, investigación de mercados, movimientos de colonización, estudios económicos

regionales, auditorias,

planeación

de

carreras

universitarias,

distribución de tiempos de salas de operaciones, ampliaciones de fábrica, planeación de itinerarios para cobranzas, planes de venta, censos de población, etc.

VENTAJAS PERT y CPM Enseña una disciplina lógica para planificar y organizar un programa detallado de largo alcance. Proporciona una metodología Standard de comunicar los planes del proyecto mediante un cuadro de tres dimensiones (tiempo, personal; costo).

23

Identifica

los

elementos

(segmentos)

más

críticos

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 relación a los plazos de cumplimiento de los programas. Aporta la probabilidad de cumplir exitosamente los plazos propuestos. En otras palabras: CPM es un sistema dinámico, que se mueve con el progreso del proyecto, reflejando en cualquier momento el STATUS presente del plan de acción.

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 representación gráfica, cada actividad es representada como un arco y cada nodo ilustra la culminación de una o varias actividades. ESPECIFIQUE LAS ACTIVIDADES INDIVIDUALES. De la estructura de la interrupción 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 información de la secuencia y de la duración en pasos más últimos.

DETERMINE LA SECUENCIA DE LAS ACTIVIDADES 24

Algunas actividades son dependientes en la terminación 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 TERMINACIÓN 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 variación en el tiempo de la terminación, tan solamente un número se utiliza para la estimación del tiempo de una actividad. IDENTIFIQUE LA TRAYECTORIA CRÍTICA (LA TRAYECTORIA MÁS LARGA A TRAVÉS DE LA RED). La trayectoria crítica es la trayectoria de la largo-duracio'n a través de la red. La significación de la trayectoria crítica 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 análisis de trayectoria crítica es un aspecto Importante del planeamiento del proyecto. La trayectoria crítica puede ser identificada determinando los cuatro parámetros siguientes para cada actividad: 

ES, Principio temprano.



EF, principio tardío.



LS, terminación temprana.



LF, terminación tardía.

25

La época floja para una actividad es el tiempo entre su hora de salida más temprana y más última, o entre su tiempo más temprano y más último del final. La holgura es la cantidad de tiempo que una actividad se puede retrasar más allá de su comienzo más temprano o final más temprano sin delaying el proyecto. La trayectoria crítica es la trayectoria a través 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 crítica retrasa el proyecto. Semejantemente, acelere el proyecto que es necesario reducir el tiempo total requerido para las actividades en la trayectoria crítica. PONGA AL DÍA EL DIAGRAMA DEL CPM Pues progresa el proyecto, los tiempos reales de la terminación de la tarea serán sabidos y el diagrama de la red se puede poner al día para incluir esta información. Una trayectoria crítica 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 mínima en los tiempos de la terminación del proyecto. Para menos proyectos de la rutina hay más incertidumbre en los tiempos de la terminación, y límites 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.

MÉTODO PERT (Program Evaluation and Review Technique) En CPM se asume que la duración de cada actividad es conocida con certeza. Claramente, en muchas ocasiones este supuesto no es válido. PERT intenta corregir este error suponiendo que la duración de cada actividad es una

26

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

a = Tiempo Optimista. Duración de la actividad bajo las condiciones más favorables



b = Tiempo Pesimista. Duración de la actividad bajo las condiciones más desfavorables m = Tiempo Normal. El valor más probable de la duración de la actividad.



PASOS EN EL PROCESO DE PLANEAMIENTO DEL PERT El planeamiento del PERT implica los pasos siguientes: Identifique las actividades y duración específica, determine la secuencia apropiada de las actividades, construya un diagrama de red, determine el tiempo requerido para cada actividad, determine la trayectoria crítica, Ponga al día la carta del PERT según 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 más actividades. Es provechoso enumerar las tareas en una tabla que en pasos más últimos se pueda ampliar para incluir la información sobre secuencia y duración. DETERMINE LA SECUENCIA DE LA ACTIVIDAD Este paso se puede combinar con el paso de la identificación de la actividad puesto que la secuencia de la actividad es evidente para algunas tareas. Otras tareas pueden requerir más análisis para determinar el orden exacto en la cual deben ser realizadas

27

CONSTRUYA EL DIAGRAMA DE RED Usando la información 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 ESTIMACIÓN Para cada activad, se requiere estimar las siguientes cantidades: a = Tiempo Optimista. El que representa el tiempo mínimo posible sin importar el costo o cuantía de elementos materiales y humanos que se requieran; es simplemente la posibilidad física 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 más probable de la duración de la actividad, basado en la experiencia personal del informador Si Tij es la variable aleatoria asociada a la duración de la actividad (i; j), PERT asume que Tij sigue una distribución Beta. Sin entrar en mayores detalles de esta distribución, se puede demostrar que el valor esperado y la varianza de la variable aleatoria Tij quedan definidas por:

En PERT se asume además que la duración de las actividades es independiente. Por lo tanto, el valor esperado y la varianza de una ruta pueden ser estimadas según:

28

= Duración esperada de la ruta

= Variación de la duración de la ruta

DETERMINE LA TRAYECTORIA CRÍTICA La trayectoria crítica es determinada agregando los tiempos para las actividades en cada secuencia y determinando la trayectoria más larga del proyecto. La trayectoria crítica determina el tiempo total del calendario requerido para el proyecto. Si las actividades fuera de la trayectoria cítrica aceleran o retrasaron el tiempo (dentro de los límites), entonces el tiempo total de proyecto no varía, la cantidad del tiempo que una actividad no crítica de la trayectoria sin alterar la duración del proyecto se denomina como tiempo flojo. Si la trayectoria crítica del proyecto no resulta obvia, entonces puede ser provechoso determinar las cuatro cantidades siguientes para cada actividad: ES, Principio temprano. EF, principio tardío. LS, terminación temprana. LF, terminación tardía. Se calculan estos tiempos usando la época prevista para las actividades relevantes. Los tiempos más tempranos del comienzo y del final de cada actividad son determinados trabajando adelante a través de la red y determinando el tiempo más temprano en el cual una actividad puede comenzar y acabar a considerar sus actividades del precursor. Los tiempos más últimos del comienzo y del final son los tiempos más últimos que una actividad puede comenzar y acabar sin variar el proyecto. El LS y el LF son encontrados trabajando al revés a través de la red. La diferencia en el final más último y más temprano de cada actividad es holgura de 29

esa actividad. La trayectoria crítica entonces es la trayectoria a través de la red en la cual ningunas de las actividades tienen holgura. La variación en el tiempo de la terminación del proyecto puede ser calculada sumando las variaciones en los tiempos de la terminación de las actividades en la trayectoria crítica. Dado esta variación, una puede calcular la probabilidad que el proyecto será terminado por cierta fecha si se asume que una distribución normal de la probabilidad para la trayectoria crítica. Sea CP la variable aleatoria asociada a la duración total de las actividades de la ruta crítica determinadas mediante CPM. PERT asume que la ruta crítica encontrada a través de CPM contiene suficientes actividades para emplear el Teorema Central del Límite y concluir que CP se distribuye normalmente.

Puesto que la trayectoria crítica determina la fecha de la terminación del proyecto, el proyecto puede ser acelerado agregando los recursos requeridos para disminuir la época para las actividades en la trayectoria crítica. LA ACTUALIZACIÓN SEGÚN 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 situación.

VENTAJAS DEL PERT El PERT es útil porque proporciona la información siguiente: Tiempo previsto de la terminación del proyecto. Probabilidad de la terminación antes de una fecha especificada. 30

Las actividades de la trayectoria crítica que afectan directamente el tiempo de la terminación. Las actividades que tienen tiempo flojo y que pueden prestar recursos a las actividades de la trayectoria crítica. 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 ejecución de una actividad, los números 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 estimación. Incluso si bien-se estiman los tiempos de la actividad, el PERT asume una distribución beta para éstos las estimaciones del tiempo, pero la distribución real puede ser diferente. Incluso si la asunción beta de la distribución sostiene, el PERT asume que la distribución de la probabilidad del tiempo de la terminación del proyecto es igual que el de la trayectoria crítica. Porque otras trayectorias pueden convertirse en la trayectoria crítica si se retrasan sus actividades asociadas, el PERT subestima constantemente el tiempo previsto de la terminación del proyecto.

31

ESTIMACIONES Estimación ―Apreciar, poner precio, evaluar algo‖ Estimación de proyectos de software ―Actividad de la planificación del proyecto de software que intenta determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto software‖.

¿En qué consiste la estimación de proyectos software? •

Aplicación continúa de técnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una información de gestión significativa y a tiempo. Esta información se utilizará para mejorar esos procesos los productos que se obtienen de ellos. (SYMONS, C., 1998)

32

¿Cuál es el objetivo de la estimación? Predecir las variables involucradas en el proyecto con cierto grado de certeza. Trata de aportar una predicción de algún indicador importante para la gestión de proyectos de software tiempo, esfuerzo, cantidad de defectos esperados entre otros. Es razonable conocer, antes de comenzar a desarrollar el SW, cuánto se va a invertir, qué tareas se deben realizar y cuánto tiempo se necesitará. ¿Quién es y cuál es el objetivo del estimador de un proyecto software?

El estimador debe ser un profesional que no tenga ningún interés, directo o indirecto, en los resultados del proceso de estimación 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 términos de costo y tiempo. Requisitos que debe cumplir un buen estimador… 

Formación y experiencia profesional adecuada.



Una posición en la organización que le permita adoptar un juicio independiente.



Debe basarse en un método que pueda ser explicado, cuestionado, discutido y auditado.



Debe poder describir su experiencia en cada estimación.



Debe documentar su estimación, incluyendo los resultados obtenidos y cualquier información necesaria para hacer el proceso de estimación repetible y verificable.

33

¿Cuándo se debe llevar a cabo? La estimación es un proceso continuo. A medida que el proyecto avanza, más se conoce de él, y por lo tanto más parámetros están disponibles para introducir en un modelo de estimación. La estimación continua nos permite el uso de un único modelo coherente que pueda capturar y utilizar la información sobre el proyecto a medida que éste se conozca.

34

ESTIMACIÓN PARA PROYECTOS DE SOFTWARE La gestión del proyecto de software comienza con un conjunto de actividades que en grupo se denominan planificación 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 requerirán 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 ingeniería 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 guía para "sobrevivir el proyecto de software", Steve McConell presenta una visión del mundo real de la planificación del proyecto: Muchos trabajadores técnicos preferirán realizar el trabajo técnico en lugar de pasar el tiempo en la planificación. Muchos gestores técnicos no tienen suficiente entrenamiento en la gestión técnica para sentirse seguros de que su planificación mejorará el resultado de un proyecto, Puesto que ninguna parte quiere hacer la planificación, con frecuencia no se realiza. Pero las fallas para planificar es uno de los mayores errores que un proyecto pueda cometer... se necesita la planificación eficaz para resolver los problemas corriente arriba [temprano en el proyecto] a bajo cosió, más que corriente abajo [tarde en el proyecto] a alto costo. El proyecto promedio gasta 80 por dentó de su tiempo en reelaboración: 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 pequeño porcentaje del tiempo que se habría gastado en la reelaboración que ocurre debido a que no se planificó.

35

OBSERVACIONES ACERCA DE LA ESTIMACIÓN La planificación requiere que los gestores técnicos 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 automáticamente algún grado de incertidumbre Para citar a Frederick Brooks: Nuestras técnicas de estimación están pobremente desarrolladas. Más seriamente, reflejan una suposición 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 cortés testarudez para hacer que la gente espere un buen producto. Aunque la estimación es tanto un arte como una ciencia, esta importante actividad no necesita realizarse en una forma improvisada. Existen técnicas útiles para la estimación de tiempo y esfuerzo. Las métricas del proceso y del proyecto ofrecen la perspectiva histórica y la energía para la generación de estimaciones cuantitativas. La experiencia (de toda la gente involucrada) puede auxiliar enormemente conforme se desarrollan y revisan las estimaciones. Puesto que la estimación coloca los cimientos para las demás actividades de planificación del proyecto, y ésta proporciona la ruta para la ingeniería del software exitosa, se estaría mal aconsejado si se embarcara sin ella. La estimación de recursos, costo y programa de trabajo para una tarea de ingeniería de software requiere experiencia, acceso a buena información histórica (métricas) y el valor para comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que existe. La estimación implica riesgo inherente, y éste conduce a la incertidumbre. La disponibilidad de información histórica tiene una fuerte influencia en el riesgo de la estimación. Al mirar en retrospectiva, se pueden emular las cosas que funcionaron y mejorar las áreas donde surgieron problemas. Cuando hay disponibles amplias métricas 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 estimación 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 están sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimación se incrementan peligrosamente. El planificador y, en forma más importante, el cliente deben reconocer que la variabilidad en los requisitos del software significa inestabilidad en costo y programa de trabajo.

EL PROCESO DE PLANIFICACIÓN DEL PROYECTO El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Además, 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 planificación. 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 características que se entregarán 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 desempeño, las restricciones, las interfaces y la confiabilidad que acotan el sistema. El ámbito se define al usar una de las dos técnicas siguientes: 1. Después de una comunicación con todos los participantes se desarrolla una descripción 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 evalúan y en algunos casos se refinan para proporcionar más detalles antes de comenzar la estimación. Puesto que las estimaciones de costo y programa de trabajo están funcionalmente orientadas, con frecuencia es útil cierto grado de descomposición. Las consideraciones del desempeño abarcan los requisitos de procesamiento y tiempo de respuesta. Las restricciones identifican los límites colocados en el software por el hardware externo, la memoria disponible u otros sistemas existentes. Una vez identificado el ámbito (con la participación 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), sólo 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 extraños. Por el contrario, la factibilidad del software tiene cuatro dimensiones sólidas: Tecnología: ¿el proyecto es técnicamente factible? ¿Está dentro del terreno de la disciplina? ¿Los defectos se pueden reducir a tal grado que se emparejen con las necesidades de la aplicación? Finanzas: ¿es financieramente factible? ¿Se puede completar e! desarrollo a un costo que La organización de software, su cliente o el mercado puedan enfrentar? Tiempo: ¿el proyecto llegará al mercado antes y vencerá a la competencia? Recursos: ¿la organización 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 líneas arriba. Ésta i una parte crucial, aunque con frecuencia ignorada, del proceso de estimación.

38

RECURSOS La segunda tarea de la planificación es la estimación de los recursos necesarios para completar el esfuerzo de desarrollo del software. La figura muestra las tres grandes categorías de los recursos de ingeniería del software: personal, componentes de software reutilizables y el entorno de desarrollo (hardware y herramientas de software). Cada recurso se especifica con cuatro características: descripción del recurso; un informe de disponibilidad; cuándo se requerirá el recurso; tiempo durante el cual e] recurso se aplicará. Las últimas dos características se pueden ver como una ventana de tiempo. La disponibilidad del recurso para una ventana específica debe establecerse lo más 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 posición organizacional (por ejemplo, gestor, ingeniero de software ejecutivo) como la especialidad (por ejemplo, telecomunicaciones, base de datos, cliente/servidor). En proyectos relativamente pequeños (unos pocos persona39

meses) un solo individuo puede realizar todas las tareas de ingeniería del software y consultar con especialistas conforme se requiera. En proyectos mayores el equipo de software puede estar geográficamente disperso en varios sitios. Aquí se especifica la ubicación de cada recurso humano. El número de personas que requiere un proyecto de software sólo se determina después de que se ha hecho una estimación del esfuerzo de desarrollo (por ejemplo, personas-mes). Las técnicas para estimar el esfuerzo se tratarán más adelante.  Recursos de software reutilizables La ingeniería del software basada en componentes enfatiza la reutilización de bloques de construcción de software. Tales bloques, usualmente llamados componentes, deben catalogarse para consultarlos con facilidad, estandarizarse para facilitar su aplicación y validarse para integrarlos fácilmente. Bennatan sugiere cuatro categorías de recursos de software que deben considerarse conforme avanza la planificación:  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, están listos para emplearlos en el proyecto actual y han sido ampliamente validados  Componentes experimentados. Especificaciones, diseños, código 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 aplicación que representan

dichos componentes. En consecuencia, las

modificaciones que requieran los componentes experimentados serán relativamente de bajo riesgo.  Componentes de experiencia pardal. Especificaciones, diseños, código o datos de prueba existentes que se desarrollaron para proyectos previos 40

están relacionados con el software que se construirá para el proyecto actual pero requerirán modificaciones sustanciales. Los miembros del equipo de software actual sólo tienen experiencia limitada en el área de aplicación 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 específicamente para las necesidades del proyecto actual.

 Recursos del entorno El entorno que soporta un proyecto de software, con frecuencia denominado entorno de ingeniería 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 práctica de la ingeniería del software. Puesto que la mayor parte de las organizaciones de software tienen múltiples 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 estarán disponibles. Cuando un sistema basado en computadora (que incorpora hardware y software especializados) se someterá a ingeniería, el equipo de software quizá requiera acceso a elementos de hardware que están desarrollando otros equipos de ingeniería. Por ejemplo, el software de un contador numérico (CN) utilizado en un tipo de máquinas-herramienta tal vez requiera una máquina-herramienta específica (por ejemplo, un CN de torno) como parte del paso de prueba de validación; un proyecto de software para plantilla de página avanzada quizá necesite una impresora de alta calidad en algún punto durante el desarrollo. El planificador del proyecto de software debe especificar cada elemento de hardware.

41

ESTIMACIÓN DE COSTOS DE SOFTWARE El software es el elemento más caro de virtualmente todos los sistemas basados e computadora. En sistemas complejos, personalizados, un gran error en la estimación del costo puede hacer la diferencia entre beneficio y pérdida. Rebasar el costo puede ser desastroso para el desarrollador. La estimación del costo y el esfuerzo nunca será una ciencia exacta. Demasiadas variables —humanas, técnicas, ambientales, políticas— pueden afectar el costo final del software y el esfuerzo aplicado a desarrollarlo. Sin embargo, la estimación del proyecto de software se puede transformar de una práctica oscura en una serie de pasos sistemáticos que proporcionan estimaciones con riesgo aceptable. Para lograr estimaciones confiables de costo y esfuerzo se tienen varias opciones: 1. Demorar la estimación hasta más tarde en el proyecto (obviamente, ¡se puede lograr 100 por ciento de estimaciones precisas después de que el proyecto esté terminado!) 2. Basar las estimaciones en proyectos similares que ya hayan sido completados 3. Emplear técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo del proyecto. 4. Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo. Desgraciadamente, la primera opción, aunque atractiva, no es práctica. Las estimaciones de costos se tienen que proporcionar "por adelantado". No obstante, se debe reconocer que, mientras más se espere más se conocerá, y mientras más se conozca menos probable es que se cometan serios errores en las estimaciones. La segunda opción 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

límite) 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 estimación del proyecto de software. Idealmente, las técnicas mencionadas para cada opción deben aplicarse juntas, cada una empleada como una marca de verificación para la otra. Las técnicas de descomposición asumen un enfoque de "divide y vencerás" respecto de la estimación del proyecto de software. Al descomponer un proyecto en funciones principales y actividades de ingeniería del software relacionadas, las estimaciones de costo y esfuerzo se pueden realizar en forma escalonada. Los modelos de estimación empírica son útiles para complementar las

técnicas

de

descomposición

y

ofrecer

un

enfoque

de

estimación

potencialmente valioso por su propio derecho.

TÉCNICAS DE DESCOMPOSICIÓN La estimación del proyecto de software es una forma de resolver problemas; en la mayoría de los casos, el problema que debe resolverse (es decir, el desarrollo de una estimación de costo y esfuerzo para un proyecto de software) es muy complejo como para considerarlo una sola pieza. Por esta razón se descompone el problema, re caracterizándolo como un conjunto de problemas más pequeños (y, esperanzadora-mente, más manejable). Anteriormente se examinó el enfoque de descomposición desde dos diferentes puntos de vista: descomposición del problema y descomposición del proceso. La estimación emplea una o ambas formas de partición. Pero antes de que pueda realizarse una estimación, el planificador del proyecto debe entender el ámbito del software que se construirá y generar una estimación de su "tamaño".

43

Tamaño del software La precisión de la estimación de un proyecto de software se manifiesta en varios factores: 1) el grado con el cual el planificador ha estimado adecuadamente el tamaño del producto que se construirá; 2) la habilidad para traducir la estimación del tamaño en esfuerzo humano, programa de trabajo y dinero (una función de la disponibilidad de las métricas 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: ingeniería del software. Se considera el problema del tamaño del software. Puesto que estimación de un proyecto sólo es tan buena como la estimación del tamaño del ti bajo para realizarlo, el tamaño representa el primer gran desafío del platicador del proyecto. En el contexto de la planificación del proyecto, tamaño se refiere a resultado cuantificable del proyecto de software. Si se asume un enfoque directo tamaño se puede medir en líneas de código (LDC). Si se elige un enfoque indirecto el tamaño se representa como puntos de función (PF). Putnam y Myers sugieren cuatro diferentes enfoques al problema < tamaño: •

Tamaño de "lógica difusa". La aplicación de este enfoque requiere que el planificador identifique el tipo de aplicación, establezca su magnitud en una escala cualitativa y luego retine la magnitud dentro del rango original.

•

Tamaño de punto de función. El planificador desarrolla estimaciones de las características del dominio.

•

Tamaño de componentes estándar. El software se compone de varios "componentes estándar", los cuales son diferentes y genéricos de un área particular de la aplicación. Por ejemplo, los componentes estándar de un sistema de información son subsistemas, módulos, pantallas, reportes, programas Ínter activos, programas por lotes, archivos, LDC e instrucciones al nivel de objeto. El planificador del proyecto estima el número de ocurrencias de

44

cada componente estándar y luego aplica datos de proyectos históricos para determinar el tamaño de entrega por componente estándar. •

Tamaño del cambio. Este enfoque se aplica cuando un proyecto incluye la utilización de software existente que debe modificarse en cierta forma como parte de un proyecto. El planificador estima el número y tipo (por ejemplo, reutilización, código de adición, código de cambio, código de borrado) de las modificaciones que se deben lograr. Putnam y Myers sugieren que los resultados de cada uno de estos

enfoques de tamaño se combinen estadísticamente para crear una estimación de tres puntos o del valor esperado. Esto se logra desarrollando valores optimistas (bajos), más probables y pesimistas (altos) para el tamaño y combinándolos con la ecuación (23Estimación basada en el problema Anteriormente, las líneas de código y los puntos de función se describieron como medidas a partir de las cuales se calculan las métricas 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 estimación para el "tamaño" de cada elemento del software, y 2) como métricas de línea base recolectadas a partir de proyectos previos y utilizados en conjunción con variables de estimación para desarrollar proyecciones de costo y esfuerzo. Las estimaciones de LDC y PF son distintas técnicas de estimación, aunque ambas tienen varias características en común. 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 estimación) para cada función. De manera alternativa, el planificador puede elegir otro componente para tamaño, como clases u objetos, cambios o procesos de negocios afectados.

45

Entonces se aplican las métricas de la línea base de productividad (por ejemplo, LDC/pm o PF/pms) a la variable de estimación apropiada, y se deriva el costo o esfuerzo de la función. Las estimaciones de función se combinan para producir una estimación global del proyecto completo. Sin embargo, es importante notar que con frecuencia existe una dispersión sustancial en las métricas de productividad de una organización, lo que hace sospechoso el uso de una sola métrica de línea 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 tamaño de equipo, área de aplicación, complejidad y otros parámetros 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 estimación. Las técnicas de estimación LDC y PF difieren en cuanto al detalle requerido para descomposición y el objetivo de la partición. Al emplear LDC como variable de estimación la descomposición es absolutamente esencial y con frecuencia se lleva a grados considerables de detalle. Mientras mayor sea el grado de partición es más probable que se desarrolle una estimación razonablemente precisa de LDC. En las estimaciones de PF la descomposición funciona de manera diferente. Más que enfocarse sobre la función, se estima cada una de las cinco características de dominio de información, 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 estimación. Sin importar la variable de estimación que se utilice, el planificador del proyecto comienza estimando una gama de valores para cada función o valor de dominio de información. Al emplear datos históricos o (cuando todo lo demás falla) intuición, el planificador estima un valor de tamaño optimista, más probable, y 46

pesimista para cada función o cuenta para cada valor de dominio de información. Cuando se especifica un rango de valores se proporciona un indicio implícito del grado de incertidumbre. Entonces se puede calcular un valor de tres puntos o uno esperado. El valor esperado para la variable de estimación (tamaño), S, se calcula como un promedio ponderado de las estimaciones optimista (S,,,,,), más probable (Sm) y pesimista (Spe5). Por ejemplo, brinda la credibilidad más fuerte a la estimación "más probable" y sigue una distribución de probabilidad beta. Una vez determinado el valor esperado para la variable de estimación se aplican los datos de productividad histórica de LDC o PF. ¿Son correctas las estimaciones? La única respuesta razonable a esta pregunta es: no se puede estar seguro. Cualquier técnica de estimación, no importa cuán sofisticada sea, debe contrastarse con otro enfoque. Incluso entonces deben prevalecer el sentido común y la experiencia. Un ejemplo de estimación basada en LDC Como ejemplo de técnicas de estimación de LDC y PF basadas en el problema, considérese un paquete de software que será entregado para una aplicación de diseño asistido por computadora (CAD, por sus siglas en inglés) destinado a componentes mecánicos. El software se ejecutará en una estación de trabajo de ingeniería y debe tener interfaz con varios periféricos que incluyen ratón, digitalizador, monitor de color de alta resolución e impresora láser. Se puede elaborar una descripción preliminar del ámbito del software:  El software CAD mecánico aceptará del ingeniero datos geométricos de dos y tres dimensiones. El ingeniero interactuará y controlará el sistema CAD a través de una Interfax del usuario que exhibirá características de buen diseño de interfaz humano-máquina. Todos los datos geométricos y otra información de soporte se conservarán en una base de datos CAD. Se desarrollarán módulos de análisis de diseño para producir la salida requerida, la cual se desplegará en una diversidad de dispositivos gráficos. El software se diseñará para 47

controlar e interactuar con dispositivos periféricos que incluyen ratón, digitalizador, impresora láser y plotter. Esta descripción del ámbito es preliminar, no está acotada. Se tendría que expandir cada oración para ofrecer detalle concreto y acotación cuantitativa. Por ejemplo, antes de que comience la estimación, el planificador debe determinar qué significa "características de buen diseño de interfaz humano-máquina" o cuáles serán el tamaño y la complejidad de la "base de datos CAD". En cuanto a los propósitos actuales, se supone que se ha llevado a cabo más refinamiento y que están identificadas las grandes funciones de software mencionadas en la figura 23.2. Al continuar con la técnica de descomposición para LDC se elabora una tabla de estimación, la cual se muestra en la figura 23.2. En cada función se desarrolla un rango de estimaciones LDC. Por ejemplo, el rango de las estimaciones LDC para la función de análisis geométrico 3D es: optimista, 4 600 LDC; más probable, 6 900 LDC; y pesimista, 8 600 LDC. Al aplicar la ecuación 231 el valor esperado para la función de análisis geométrico 3D es 6 800 LDC. Otras estimaciones se derivan en forma similar. Al sumar verticalmente en la columna de LDC estimadas, se establece una estimación de 33 200 líneas de código para el sistema CAD. Una revisión de \os datos históricos 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 dólares por mes, el costo por línea de código es aproximadamente de 13 dólares. Con base en la estimación de LDC y los datos históricos de productividad, el costo total estimado del proyecto es de 431 000 dólares y el esfuerzo estimado es de 54 personas-mes.

48

Estimación basada en el proceso La técnica más común para estimar un proyecto es basar la estimación en el proceso que se empleará. Esto es, el proceso se descompone en un conjunto relativamente pequeño de tareas y se estima el esfuerzo requerido para lograr cada tarea. Al igual que las técnicas basadas en el problema, la estimación basada en el proceso comienza con un bosquejo de las funciones del software obtenidas a partir del ámbito del proyecto. Cada función 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 función. 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 varíe en cada tarea. El equipo veterano está enormemente involucrado en las actividades tempranas del marco de trabajo y generalmente es más costoso que el equipo menos experimentado involucrado en la construcción y liberación. Los costos y el esfuerzo para cada función y actividad del marco de trabajo se calculan como el último paso. Si la estimación basada en el proceso se realiza independientemente de la estimación 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 razón para creer que las estimaciones son confiables. Si, por otra parte, los resultados de dichas técnicas de descomposición muestran poca concordancia, se debe llevar a cabo mayor investigación y análisis. Estimación 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 estimación con casos de uso es problemático por las siguientes razones: 

Los casos de uso se describen empleando muchos formatos y estilos diferentes; no existe un formato estándar.



Los casos de uso representan una visión externa (la visión del usuario) del software y con frecuencia están escritos con diferentes grados de abstracción



Los casos de uso no abordan la complejidad de las funciones ni de las características que se describen.

50



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

A diferencia de las LDC o un punto de función, el "caso de uso" de una persona tal vez requiera meses de esfuerzo mientras que el de otra quizá se implemente en un día o dos. Aunque varios investigadores han considerado los casos de uso como una entrada a la estimación, a la fecha no ha surgido ningún método de estimación probado Smith [SMI99] sugiere el empleo de los casos de uso en la estimación, pero sólo si se consideran dentro del contexto de la "jerarquía estructural" que los casos de uso describen. Smith argumenta que cualquier nivel de esta jerarquía estructural se describe ceno más de 10 casos de uso. Cada uno de éstos abarcaría no más de 30 escenarios distintos. Obviamente, los casos de uso que describen un sistema grande están escritos con un grado mucho mayor de abstracción (y representan considerablemente más esfuerzo de desarrollo) que aquellos que describen un solo subsistema. En consecuencia, antes de que los casos de uso se empleen en la estimación, se establece el nivel en la estructura jerárquica, se determina la longitud promedio (en páginas de cada caso de uso, se define el tipo de software (por ejemplo, tiempo real, de negocios, de ingeniería/científico, anidado) y se considera una arquitectura común del sistema. Una vez establecidas dichas características, los datos empíricos se aprovechan para establecer el número estimado de LDC o de PF por caso de uso (para cada nivel de la jerarquía). Entonces se utilizan los datos históricos para calcular el esfuerzo necesario para desarrollar el sistema. Reconciliación de estimaciones Las técnicas de estimación dan por resultado; múltiples estimaciones que deben reconciliarse para producir una sola estimación de esfuerzo, duración del proyecto o costo. Este procedimiento de reconciliación se ilustra considerando de nuevo el software CAD. 51

El esfuerzo estimado total para el software CAD varía desde un bajo de 46 personas-mes (obtenido empleando el enfoque de la estimación basada en el proceso) hasta un alto de 68 personas-mes (derivado con la estimación de caso de uso)- La estimación promedio (que utiliza los cuatro enfoques) es de 56 personas-mes. La variación de la estimación 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 información 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 técnicas de estimación basadas en el problema son inapropiados para la aplicación, obsoletos (pues ya no reflejan con precisión la organización de ingeniería de software) o se han aplicado mal.

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

52

ANÁLISIS DE RIESGOS ANÁLISIS Y GESTIÓN DE RIESGOS El análisis y la gestión 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 análisis y la gestión del riesgo.

ESTRATEGIAS DE RIESGO REACTIVAS Y PROACTIVAS Las estrategias de riesgo reactivas han sido jocosamente denominadas la "escuela Indiana Jones de gestión del riesgo". En las películas de la década de 1980 que llevaban su nombre, Indiana Jones, cuando enfrentaba alguna dificultad abrumadora, invariablemente decía: "¡No te preocupes, pensaré en algo!". Al no preocuparse nunca por los problemas, sino hasta que ocurrían, 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 compañeros. Más aún, la mayoría 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. Más usualmente, el equipo de software no hace nada acerca de los riesgos hasta que algo sale mal. Entonces el equipo se precipita en la acción con la finalidad de corregir el problema rápidamente. Con frecuencia a esto se le llama el modo bombero.

53

Cuando esto falla, la "gestión de crisis" asume el control y el proyecto está en un verdadero peligro. Una estrategia considerablemente más inteligente para la gestión del riesgo es ser proactivo. Una estrategia proactiva comienza mucho antes de que se inicie el trabajo técnico. Se identifican los riesgos potenciales, se valoran su probabilidad e impacto, y se les clasifica según 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 definición propia para el riesgo de software, existe un acuerdo general en que el riesgo siempre involucra dos características.  Incertidumbre: el riesgo puede o no ocurrir, esto es, no existen riesgos 100% probables.  Pérdida: si el riesgo se convierte en realidad, ocurrirán consecuencias o pérdidas indeseables.

Cuando se analizan los riesgos es importante cuantificar el grado de incertidumbre y el grado de pérdida asociado con cada riesgo. Esto se logra considerando diferentes categorías 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 calendarización del proyecto se altere y que los costos aumenten. Los riesgos del proyecto identifican potenciales problemas en presupuesto, calendarización, personal (plantillas y organización), recursos, participantes y requisitos, y su impacto sobre un proyecto de software. Los riesgos técnicos amenazan la calidad y actualidad del software que se producirá. Si un riesgo técnico se vuelve real, la implementación se toma difícil 54

o imposible. Los riesgos técnicos identifican potenciales problemas en diseño, implementación, interfaz, verificación y mantenimiento. Además, también son factores de riesgo la ambigüedad de la especificación, la incertidumbre técnica, la obsolescencia técnica y la tecnología "de punta‖. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que en un principio se pensó que sería. 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 construcción de un producto o sistema excelente que en realidad nadie quiere (riesgo de mercado). 2) La construcción de un producto que ya no encaja en la estrategia comercial global de la compañía (riesgo de estrategia). 3) La construcción de un producto que la fuerza de ventas no sabe cómo vender (riesgo de ventas). 4) La pérdida del apoyo de los altos ejecutivos debido a un cambio en el enfoque o en el personal (riesgo administrativo). 5) La pérdida presupuestaria o del personal asignado (riesgo presupuestal).

Es extremadamente importante destacar que la simple clasificación de los riesgos no siempre funciona. Algunos riesgos simplemente son impredecibles. Charette ha propuesto otra categorización general de los riesgos. Los riesgos conocidos son aquellos susceptibles de descubrirse después de una evaluación cuidadosa del plan del proyecto, del entorno de negocios y técnico dentro de los cuales se desarrollará el proyecto, y otras fuentes de información 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 comunicación con el cliente, disminución del esfuerzo del personal conforme se atienden las solicitudes de mantenimiento). Los riesgos impredecibles son el comodín de la baraja. Pueden y de hecho ocurren, pero son extremadamente difíciles de identificar con antelación. 55

PRINCIPIOS DE LA GESTIÓN DE RIESGOS El Instituto de Ingeniería de Software (SEI) identifica siete principios que ofrecen un marco de trabajo para lograr una gestión 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 visión 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 comunicación 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. Integración: En el proceso del software debe estar integrada una consideración 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 más información a medida que se logre un mejor criterio. 6. Desarrollo de una visión conjunta del producto: Si todos los participantes comparten la misma visión del software, es probable que ocurra mejor identificación y evaluación 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 gestión de riesgos.

PROCESO DE ANÁLISIS DE RIESGOS 1) IDENTIFICACIÓN DE RIESGOS La identificación de los riesgos es un intento sistemático encaminado a especificar las amenazas al plan del proyecto (estimaciones, calendarización, 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 categorías de riesgos, estos son los riesgos genéricos y los riesgos específicos del producto. Los riesgos genéricos son una amenaza potencial para todo el proyecto de software. Los riesgos específicos del producto los pueden identificar sólo aquellos con un claro conocimiento de la tecnología, el personal y el entorno específico del software que se construirá. Los riesgos específicos del producto se identifican examinando el plan del proyecto y la declaración del ámbito del software, así como desarrollando una respuesta para la siguiente pregunta: "¿Qué características especiales de este producto podrían amenazar el plan del proyecto?". ―Los proyectos sin riesgos reales son perdedores. Estos proyectos casi siempre están desprovistos de beneficios; por ello no fueron realizados años atrás.‖ Tom DeMarco y Tim Lister. Un método para identificar riesgos consiste en crear una lista de verificación de riesgos. Con ésta se pueden identificar riesgos y enfocarse en algún subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas: Tamaño del producto: riesgos asociados con el tamaño global del software que se construirá o modificará. El riesgo del proyecto es directamente proporcional al tamaño del producto. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con el tamaño del producto (software): 

Tamaño estimado del producto.



Grado de seguridad en la estimación del tamaño.



Tamaño estimado del producto en número de programas, archivos y transacciones.

57



Porcentaje de desviación en el tamaño del producto respecto a la medida de productos anteriores.



Tamaño de la base de datos creada o empleada por el producto.



Número de usuarios del producto.



Número de cambios previstos a los requisitos del producto. ¿Antes de la entrega?, ¿Después de la entrega?



Cantidad de software reutilizado.

En cada caso, la información del producto a desarrollar debe compararse con la experiencia anterior. Si ocurre una gran desviación 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 guían las consideraciones del negocio, y éstas entran a veces en conflicto directo con las realidades técnicas. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con el impacto en el negocio: 

¿Cuál es el efecto de este producto en los ingresos de la compañía?



¿Cuál es la viabilidad de este producto para los gestores expertos?



¿Es razonable la fecha límite de entrega?



Número de clientes que usarán este producto y la consistencia de sus necesidades relativas al producto.



Número de otros productos/sistemas con los que este producto debe tener interoperatividad.



Sofisticación del usuario final.



Cantidad y calidad de la documentación del producto que debe ser elaborada y entregada al cliente.



Limitaciones gubernamentales en la construcción 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 desviación del porcentaje o si las

58

magnitudes

son

similares,

pero

los

resultados

anteriores

fueron

poco

satisfactorios, el riesgo es grande. Características del cliente: riesgos asociados con la sofisticación 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 tensión, la negociación, las recompensas psicológicas de un buen producto). Otros preferirían no ser clientes en absoluto. Algunos aceptarían felizmente cualquier cosa que se les entregara y le sacarían el mejor provecho a un producto pobre. Otros se quejarán amargamente cuando les falte calidad; algunos darán las gracias cuando la calidad es buena; unos pocos se quejarán por todo. Los clientes también 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 telefónicas 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 comprobación de elementos de riesgo identifica riesgos genéricos 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 comunicación fluida con el desarrollador?



¿Está dispuesto el cliente a participar en las revisiones? 59



¿Es sofisticado técnicamente el área del producto?



¿Está dispuesto el cliente a dejar a su personal hacer el trabajo? Es decir, ¿resistirá la tentación de mirar por encima del hombro durante el trabajo técnico?



¿Entiende el cliente el proceso del software?

Si la respuesta a alguna de estas preguntas es "no", se debería hacer una investigación más profunda para valorar el potencial de riesgo. Definición del proceso: riesgos asociados con el grado en el que se ha definido el proceso de software y en que le da seguimiento la organización que lo desarrolla. Si el proceso del software no está bien definido; si el análisis, diseño y pruebas se realizan sobre la marcha; si la calidad es un concepto que todo el mundo estima importante, pero por la que nadie actúa de manera tangible para alcanzarla, entonces el proyecto está en peligro. Las siguientes preguntas se han extraído sobre la evaluación de la ingeniería del software desarrollado por R. S. Pressman & Associates Inc. Las preguntas se han adaptado del cuestionario de evaluación del proceso del software del Instituto de Ingeniería del Software (IIS).

Aspectos del proceso: 

¿Apoyan sus gestores algunas normas escritas que hagan hincapié en la importancia de un proceso estándar para el desarrollo del software?



¿Ha desarrollado su organización una descripción escrita del proceso del software a emplear en este proyecto?



¿Están de acuerdo los miembros del personal con el proceso del software tal y como está documentado y están dispuestos a usarlo?



¿Se emplea este proceso del software para otros proyectos?



¿Ha desarrollado o adquirido su organización cursos de formación de ingeniería del software para jefes de proyecto y personal técnico?



¿Se ha proporcionado una copia de los estándares de ingeniería del software publicados a cada desarrollador y gestor de software?

60



¿Se han desarrollado diseños de documentos y ejemplos para todas las entregas definidas como parte del proceso del software?



¿Se llevan a cabo regularmente revisiones técnicas formales de las especificaciones de requisitos, diseño y código?



¿Se llevan a cabo regularmente: revisiones técnicas de los procedimientos de prueba y de los casos de prueba?



¿Se documentan todos los resultados de las revisiones técnicas, incluyendo los errores encontrados y recursos empleados?



¿Existe algún mecanismo para asegurarse de que el trabajo realizado en un proyecto se ajusta a los estándares de ingeniería del software?



¿Se emplea una gestión de configuración para mantener la consistencia entre los requisitos del sistema/software, diseño, código y casos de prueba?



¿Hay algún mecanismo de control de cambios de los requisitos del cliente que impacten en el software?



¿Hay alguna declaración de trabajo documentada, una especificación de requisitos software y un plan de desarrollo del software para cada subcontratación?



¿Se sigue algún procedimiento para hacer un seguimiento y revisar el rendimiento de las subcontraciones?

Aspectos técnicos: 

¿Se emplean técnicas de especificación de aplicaciones para ayudar en la comunicación entre el cliente y el desarrollador?



¿Se emplean métodos específicos para el análisis del software?



¿Emplea un método específico para el diseño de datos y arquitectónico?



¿Está escrito su código en más de un 90 por ciento en lenguaje de alto nivel?



¿Se han definido y empleado reglas específicas para la documentación del código?



¿Emplea métodos específicos para el diseño de casos de prueba?



¿Se emplean herramientas de software para apoyar la planificación y el seguimiento de las actividades?



¿Se emplean herramientas de software de gestión de configuración 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 análisis y diseño 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 producción y gestión de la documentación?



¿Se han establecido métricas de calidad para todos los proyectos de software?



¿Se han establecido métricas de productividad para todos los proyectos de software?

Si

la

mayoría

de

las

cuestiones

anteriores

se

han

respondido

negativamente, el proceso del software es débil y el riesgo es alto. Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se usarán en la construcción del producto. El entorno de ingeniería 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 comprobación de elementos de riesgo identifica riesgos genéricos asociados con el entorno de desarrollo: 

¿Tenemos disponible una herramienta de gestión de proyectos de software?



¿Tenemos disponible una herramienta de gestión del proceso del software?



¿Existen herramientas de análisis y diseño disponibles?



¿Proporcionan las herramientas de análisis y diseño, métodos apropiados para el producto a construir?



¿Hay disponible, compiladores o generadores de código apropiados para el producto a construir?



¿Hay disponibles herramientas de pruebas apropiadas para el producto a construir?



¿Tenemos disponibles herramientas de gestión de configuración software?



¿Hace uso el entorno de bases de datos o información almacenada?



¿Están 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 línea y la documentación de las herramientas?

Si se ha contestado negativamente a la mayoría de las preguntas anteriores, el entorno de desarrollo es débil y el riesgo es alto. Tecnología que construir: riesgos asociados con la complejidad del sistema que se construirá y la novedad de la tecnología que está empaquetada en el sistema. Alcanzar los límites de la tecnología es un reto excitante. Es el sueño de casi todos los técnicos, porque fuerza al profesional a emplear su talento al máximo. Pero también es muy arriesgado. La ley de Murphy parece mantener su imperio en esta parte del universo del desarrollo, haciendo extremadamente difícil predecir los riesgos, y mucho menos hacer ningún plan sobre ellos. La siguiente lista de comprobación de elementos de riesgo identifica riesgos genéricos asociados con la técnica a construir: 

¿Es nueva para su organización la tecnología a construir?



¿Demandan los requisitos del cliente la creación de nuevos algoritmos o tecnología de entrada o salida?



¿El software interactúa con hardware nuevo o no probado?



¿Interactúa el software a construir con productos software suministrados por el vendedor que no se hayan probado?



¿Interactúa el software a construir con un sistema de base de datos cuyo funcionamiento y rendimiento no se han comprobado en esta área de aplicación?



¿Demandan los requisitos del producto una interfaz de usuario especial?



¿Demandan los requisitos del producto la creación de componentes de programación distintos de; los que su organización haya desarrollado hasta ahora?



¿Demandan los requisitos el empleo de nuevos métodos de análisis, diseño o pruebas?



¿Demandan los requisitos el empleo de métodos 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 debería realizar una investigación más profundidad para valorar el riesgo potencial.  Tamaño y experiencia de la plantilla de personal: riesgos asociados con la experiencia global técnica y en el proyecto de los ingenieros de software que harán el trabajo.

La lista de verificación de riesgos se puede organizar en diferentes formas. Las preguntas relevantes respecto de cada uno de los tópicos 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 verificación de riesgos simplemente menciona las características relevantes para cada subcategoría genérica. Finalmente, se menciona un conjunto de "componentes y controladores de riesgo" junto con su probabilidad de ocurrencia. Los controladores del desempeño, soporte, costo y calendarización se estudian como respuesta a las últimas preguntas.

Evaluación 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 están ordenadas según 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

están

comprometidos

con

el

proyecto

y

el

sistema/producto que se construirá? 3) ¿Los requisitos los han entendido completamente el equipo de ingeniería de software y sus clientes? 4) ¿Los clientes estuvieron completamente involucrados en la definición de los requisitos? 5) ¿Los usuarios finales tienen expectativas realistas? 64

6) ¿El ámbito del proyecto es estable? 7) ¿El equipo de ingeniería del software tiene la mezcla correcta de habilidades? 8) ¿Los requisitos del proyecto son estables? 9) ¿El equipo del proyecto tiene experiencia con la tecnología que se implementará? 10) ¿El número de personas en el equipo de proyecto es adecuado para realizar el trabajo? 11) ¿Todos los votantes del cliente/usuario están 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 reducción, supervisión y gestión. El grado en el que el proyecto está en riesgo es directamente proporcional al número de respuestas negativas a estas preguntas. Componentes y controladores del riesgo La Fuerza Aérea de Estados Unidos escribió un folleto con excelentes directrices para la identificación y supresión 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: desempeño, costo, soporte y calendarización. En el contexto de este estudio los componentes de riesgo se definen en la forma siguiente:  Riesgo de desempeño: 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á fácil de corregir, adaptar y mejorar.  Riesgo de calendarización: grado de incertidumbre de que se mantenga la calendarización 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 categorías de impacto: despreciable, marginal, crítico o catastrófico. En la figura 1 se describe una caracterización 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 categoría de impacto se escoge con base en la caracterización que mejor encaje con la descripción en la tabla. Figura 1. Evaluación del impacto

2) PROYECCIÓN DE RIESGOS La proyección del riesgo, también llamada estimación 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 técnico, realizan cuatro pasos en la proyección del riesgo: 1) Establecimiento de una escala que refleje la posibilidad percibida de un riesgo. 66

2) Delineado de las consecuencias del riesgo. 3) Estimación del impacto del riesgo en el proyecto y el producto. 4) Tomar nota de la precisión global de la proyección 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. Ningún 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 clasificación

Desarrollo de una tabla de riesgos Una tabla de riesgos ofrece al gestor de un proyecto una técnica simple para la proyección de riesgos. Un equipo de proyecto comienza una lista de todos los riesgos (sin importar cuán remotos sean) en la primera columna de la tabla. Esto se logra con la ayuda de la lista de verificación de riesgos mencionada en la figura 2. Cada riesgo se clasifica en la segunda columna (por ejemplo, TP implica un riesgo de tamaño 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 evaluación de la probabilidad del riesgo comience a convergir. Las categorías para cada uno de los cuatro componentes de riesgo (desempeño, soporte, costo y calendarización) se promedian para determinar un valor de impacto global. Una vez completadas las cuatro primeras columnas de la tabla de riesgos, ésta se ordena según 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 priorización del riesgo de primer orden. El gestor del proyecto estudia la tabla ordenada resultante y define una línea de corte. La línea de corte (dibujada horizontalmente en algún punto en la tabla) implica que sólo los riesgos ubicados sobre la línea tendrán una atención posterior. Los riesgos debajo de la línea se reevalúan para lograr una priorización de segundo orden. En la figura 3 se muestra el impacto y la probabilidad de riesgo influyen de manera distinta en la gestión. 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 gestión. 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 análisis de riesgo que siguen. Todos los riesgos ubicados sobre la línea de corte deben gestionarse. La columna rotulada RSGR contiene una referencia que apunta hacia un Plan de reducción, supervisión y gestión de riesgo o, alternativamente, una colección de hojas de información de riesgo desarrolladas para todos los riesgos que están 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 técnicas más 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 matemática 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 gestión

Evaluación 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 técnico) evitará un diserto y prueba tempranos y tal vez genere problemas de integración de sistema más tarde. El ámbito combina la severidad (¿Cuán seno es?) con su distribución global (¿Cuánto del proyecto se afectará, o cuántos clientes resultarán dañados?). Finalmente, el tiempo de un riesgo considera cuándo y durante qué periodo se sentirá el impacto. En la mayoría 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 más al enfoque de análisis de riesgo que propuso la Fuerza Aérea 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 exposición al riesgo global, ER. Se determina mediante la siguiente relación:

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: Identificación del riesgo. De hecho, sólo 70 por ciento de los componentes de software calendarizados para reutilización se integra en la aplicación. 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 sólo se puede emplear el 70 por ciento, 18 componentes tendrían que desarrollarse desde cero (además 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 Ingeniería de software para cada uno es de 14.00 dólares, el costo (impacto) global del desarrollo de tas componentes seria 18 x 100 x 14 - 25 200 dólares. Exposición al riesgo. ER - 0 80 x 25 200 dólares - 20 200 dólares.

70

La exposición al riesgo se puede calcular para cada riesgo en la tabla de riesgos, una vez que se estime el costo del riesgo. La proyección del riesgo y las técnicas de análisis descritas en el Desarrollo de una tabla de riesgos y evaluación 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 cuándo nuevas circunstancias cambiarán 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 planificación del proyecto se puede establecer un riesgo de manera muy general. Conforme pasa el tiempo y se aprende más acerca del proyecto y el riesgo, es posible refinar el riesgo en un conjunto de riesgos más detallados, cada uno un poco más sencillo de refinar, supervisar y gestionar. Una forma de hacer esto es representar el riesgo en el formato condicióntransición-consecuencia. Es decir, el riesgo se establece en la forma siguiente: Dado que entonces existe una preocupación de que (posiblemente) Mediante el empleo del formato CTC en lugar del riesgo de reutilización se refina en la forma siguiente: Subcondición 1. Ciertos componentes reutilizables fueron desarrollados por terceras personas sin conocimiento de los estándares de diseño internos. Subcondición 2. El estándar de diseño para el componente de interfaces no se ha concretado y tal vez no se ajuste con ciertos componentes reutilizables existentes.

71

Subcondición 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 ingeniería personalizada), pero el refinamiento ayuda a aislar los riesgos subyacentes y puede conducir a un análisis y respuestas más sencillos. 4) REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO Todas las actividades del análisis 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, supóngase que una elevada movilidad en el personal se anota como un riesgo del proyecto, r1. Con base en la historia y la intuición administrativa, la probabilidad, I1, de una elevada movilidad se estima en 0.70 (70 por ciento, más bien alto) y el impacto, x1, se proyecta como crítico. Esto es: una tasa elevada de movilidad tendrá un impacto crítico en el costo del proyecto y la calendarización. 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 técnicas que aseguren la continuidad cuando la gente se aleje. 72

 Organizar equipos de proyecto de modo que la información acerca de cada actividad de desarrollo se disperse con amplitud.  Definir estándares de documentación 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 más de una persona esté "en ritmo").  Asignar un miembro de personal de respaldo por cada tecnología critica.

Conforme avanza el proyecto se inician las actividades de supervisión del riesgo. El gestor del proyecto supervisa los factores que pueden proporcionar un indicio de si el riesgo se está volviendo más 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 compañía.

Además de supervisar estos factores, un gestor de proyecto debe supervisar la efectividad de los pasos de reducción 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 información que sería necesaria si una nueva persona se viera obligada a unirse al equipo de software en algún momento a la mitad del proyecto. La gestión del riesgo y los planes de contingencia suponen que los esfuerzos de reducción han fracasado y que el riesgo se ha vuelto una realidad. Si el proyecto ya está bien avanzado y varias personas anuncian que renunciarán. Si se ha seguido la estrategia de reducción, el respaldo está disponible, la información se ha documentado y el conocimiento se ha dispersado entre el equipo. Además, el gestor del proyecto puede reenfocar temporalmente los recursos (y reajustar la calendarización 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 adquisición de conocimiento en videos, el desarrollo de ―documentos comentados‖ o reuniones con otros miembros del equipo que permanecerán en el proyecto. Es importante señalar que los pasos de reducción, supervisión y gestión del riesgo (RSGR) generan costos adicionales en el proyecto. Por ejemplo, utilizar el tiempo para ―respaldar‖ cualquier tecnología crítica cuesta dinero. Por lo tanto, parte de la gestión del riesgo consiste en evaluar cuándo los beneficios que generan los pasos RSGR se rezagan frente a los costos asociados con su implementación. En esencia, el planificador del proyecto realiza un clásico análisis costo-beneficio. Si los pasos con que se evita el riesgo de elevada movilidad de personal aumentaran tanto el costo del proyecto como su duración 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 duración en sólo 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 gestión del riesgo, ¡esta puede convertirse por sí misma en un proyecto!, por esta razón 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 sólo con 20 por ciento de los riesgos identificados. El trabajo realizado durante los primeros pasos del análisis de riesgo ayudará al planificador a determinar cuáles de los riesgos se encuentran en ese 20 por ciento (por ejemplo, riesgos que conduzcan a la mayor exposición al riesgo). Por esta razón, algunos de los riesgos identificados, evaluados y proyectados pueden no incitarse en el plan RSGR, ya que no se ubican en el crítico 20 por ciento (los riesgos con la mayor prioridad de proyecto).

74

El análisis de seguridad y peligros de software son actividades de aseguramiento de la calidad del software que se enfocan en la identificación y evaluación 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 gestión de riesgo o los pasos de gestión del riesgo organizarse por separado en un Plan de reducción, supervisión y gestión del riesgo (RSGR). El plan RSGR documenta todo el trabajo realizado como parte del análisis 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 información de riesgo (HIR). En la mayoría de los casos la HIR se mantiene empleando un sistema de base de datos, de modo que la creación y las entradas de información, ordenamiento de prioridades, búsquedas y otros análisis se logran fácilmente. Una vez documentado el plan RSGR y que el proyecto ha comenzado, se inician los pasos de reducción y supervisión del riesgo. Como ya se ha comentado, la reducción del riesgo es una actividad encaminada a evitar el problema. La supervisión 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 están aplicando con propiedad. 3) Recopilar información que pueda usarse en futuros análisis de riesgo.

En muchos casos, a los problemas que ocurren durante un proyecto es posible darles seguimiento hacía más de un riesgo. Otra labor de la supervisión del riesgo es intentar ubicar el origen (qué riesgos provocaron qué problemas a través del proyecto).

76

Hoja de información del riesgo

77

ESQUEMA DEL PLAN RSGR I. Introducción. 1. Alcance y propósito del documento. 2. Visión general de los riesgos principales. 3. Responsabilidades. a. Gestión. b. Personal técnico.

II. Tabla de riesgo del proyecto. 1. Descripción de todos los riesgos por encima de la línea de corte. 2. Factores que influyen en la probabilidad e impacto. III. Reducción, supervisión y gestión del riesgo. n. Riesgo # n. a. Reducción. i.

Estrategia general.

ii.

Pasos específicos.

b. Supervisión. i.

Factores a supervisar.

ii.

Enfoque de supervisión.

c. Gestión. i. Plan de contingencia. ii. Consideraciones especiales.

IV. Planificación temporal de revisión del Plan RSGR. V. Resumen.

78

ESTUDIO DE FACTIBILIDAD O VIABILIDAD Definición de factibilidad Se define como un proceso que se efectúa previo a la ejecución 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 señalados. Cabe mencionar que el término factibilidad es sinónimo de viabilidad.

Definición del análisis de la factibilidad del proyecto Se conoce como análisis de factibilidad al estudio que intenta predecir el eventual éxito o fracaso de un proyecto. Para lograr esto parte basa de datos empíricos (que pueden ser contrastados) a los que accede a través de diversos tipos de investigaciones (encuestas, estadísticas, 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 más tipos de factibilidades que se presentan a continuación: 

Factibilidad técnica



Factibilidad económica



Factibilidad Operativa



Factibilidad Legal



Factibilidad Organizacional

79

Análisis del sistema El análisis del sistema es una actividad que engloba la mayoría de las tareas que hemos llamado colectivamente ingeniería de sistemas basados en computadora. Algunas veces se incurre en confusión porque el término se usa a menudo en un contexto que alude sólo a las actividades de análisis de los requisitos del software. Para el propósito de este estudio, el análisis del sistema se centra en todos los elementos del sistema, no sólo en el software.

El análisis 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 análisis técnico y económico. 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 definición del sistema que sea la base para todo el trabajo posterior de ingeniería.

Para alcanzar con éxito esos objetivos, se requiere experiencia, tanto en hardware como en software (así como en ingeniería humana y en base de datos). Aunque la mayoría de los profesionales de la industria reconocen que el tiempo y el esfuerzo gastado en el análisis de sistema producen dividendos importantes más adelante en el proceso de desarrollo del sistema, todavía surgen tres preguntas: 

¿Cuánto esfuerzo se debe emplear en el análisis y en la definición de sistemas y de software? Es difícil establecer unas directrices definitivas para determinar el esfuerzo de análisis. El tamaño del sistema y su complejidad, el área de aplicación, el uso final y las obligaciones del contrato son sólo unas pocas de las muchas variables que afectan al 80

esfuerzo total dedicado al análisis. 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 análisis del sistema y aplicar otro 10 o 20 por 100 del esfuerzo de la ingeniería del software del análisis de los requerimientos del software. 

¿Quién 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 técnico y administrativo, tanto del cliente como del que desarrolla el sistema. Para muchos proyectos grandes, debe crearse un equipo para cada tarea de análisis.



¿Por qué es tan difícil? Se trata de una transformación de un concepto dudoso en un conjunto concreto de elementos tangibles. Debido a que durante el análisis la comunicación es excepcionalmente densa, abundan las oportunidades de mal entendimiento, omisiones, inconsistencias y errores. Finalmente, la percepción del sistema puede cambiar a medida que avanza la actividad, invalidando, de esa manera, el trabajo anterior.

Identificación de las necesidades El primer paso del proceso de análisis del sistema implica la identificación de las necesidades. El analista (ingeniero de sistema) se entrevista con el cliente o su representante. El cliente puede ser un representante de una compañía externa, del departamento de marketing de la compañía del análisis (cuando se está definiendo un producto) o de otro departamento técnico (cuando se va a desarrollar un sistema interno). La identificación de las necesidades es el punto de partida en la evolución de un sistema basado en computadora.

La información recogida durante la etapa de identificación 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 comunicación 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 años de esfuerzo, miles de millones de pesetas y una inversión profesional incalculable, si un sistema mal concebido es reconocido como tal al principio de la etapa de definición. El análisis de viabilidad y el análisis del riesgo están relacionados de varias maneras. Si el riesgo del proyecto es grande, se reduce la posibilidad de producir software de calidad. Sin embargo, durante la ingeniería del sistema se centra la atención en cuatro áreas de interés básico: 

Factibilidad económica: Se refiere a una evaluación del coste de desarrollo frente al beneficio final producido por el sistema desarrollado.



Factibilidad técnica: Un estudio de la funcionalidad, el rendimiento y las restricciones que pueden afectar a la posibilidad de realización de un sistema aceptable.



Factibilidad Legal: Una determinación de cualquier infracción, violación o ilegalidad que pudiera resultar del desarrollo del sistema.



Alternativas: Una evaluación 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 justificación económica es obvia, el riesgo técnico 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 justificación económica es normalmente la principal consideración para la mayoría de los sistemas (excepciones notables son los sistemas de defensa nacional, los sistemas impuestos por la ley y las aplicaciones de alta tecnología, como el programa especial). La justificación económica comprende un amplio 82

rango de aspectos, entre los que se encuentran el análisis de costo-beneficio, las estrategias de ingresos a largo plazo, el impacto en otros productos o en centros de explotación, el costo de los recursos que se necesitan para el desarrollo y el crecimiento potencial del mercado. La viabilidad técnica es frecuentemente el área más difícil 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 análisis y de definición se realice en paralelo con el análisis de viabilidad técnica. De esta forma, se pueden juzgar las especificaciones concretas según se van determinando. Las consideraciones que van asociadas normalmente a la viabilidad técnica son: 

Riesgo del desarrollo.

¿Puede el elemento del sistema ser diseñado de

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

¿Hay personal cualificado para desarrollar

el elementó del sistema en cuestión? ¿Están disponibles para el sistema otros recursos necesarios (de hardware y de software)?  Tecnología. ¿Ha progresado la tecnología 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 evaluación de viabilidad técnica debería prevalecer una actitud cínica, 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 técnico. El grado en el que se consideran las alternativas muchas veces está limitado por restricciones de tiempo y de dinero; sin embargo, no se debería descartar cualquier alternativa legítima, aunque no tenga quien ―la financie‖. El estudio de viabilidad puede documentarse en un informe separado de los otros documentos importantes de gestión e incluirse como apéndice en la especificación del sistema. Aunque el formato del informe de viabilidad puede variar, el esquema de la tabla 1 que sigue, cubre la mayoría de los aspectos importantes. La revisión 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 decisión de ―seguir / no seguir‖. Debe tenerse en cuenta que durante las etapas de planificación, especificación y desarrollo de la ingeniería del hardware y del software, se tomarán otras decisiones del tipo seguir / no seguir. Tabla 1.- Esquema del estudio de viabilidad. I.- Introducción. a) Declaración del problema. b) Entorno de implementación. c) Restricciones.

II.- Resumen y recomendaciones de gestión. a) Hallazgos importantes. b) Comentarios. c) Recomendaciones. d) Impacto.

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

84

b) Criterio utilizado en la selección del enfoque definitivo.

IV.- Descripción del sistema. a) Declaración resumida del ámbito. b) Viabilidad de los elementos asignados.

V.- Análisis de coste-beneficio. VI.- Evaluación del riesgo técnico. VII.- Consideraciones legales. VIII.- Otros asuntos específicos del proyecto.

Análisis Económico Se refiere a una evaluación del costo de desarrollo frente al beneficio final producido por el sistema desarrollado. Es decir, se refiere a los recursos económicos y financieros necesarios para desarrollar o llevar a cabo las actividades o procesos y/o para obtener los recursos básicos que deben considerarse son el costo del tiempo, el costo de la realización y el costo de adquirir nuevos recursos. Los estudios de factibilidad económica incluyen análisis de costos y beneficios asociados con cada alternativa del proyecto. Con análisis de costos/beneficio, todos los costos y beneficios de adquirir y operar cada sistema alternativo se identifican y se hacen una comparación de ellos. 

Tiempo del analista.



Costo de estudio.



Costo del tiempo del personal.



Costo del tiempo.



Costo del desarrollo/adquisición.

Un estudio de factibilidad requiere ser presentado con todas la posibles ventajas para la empresa u organización, 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 presentación del estudio: 

Requisitos Óptimos.



Requisitos Mínimos.

El primer paso se refiere a presentar un estudio con los requisitos óptimos que el proyecto requiera, estos elementos deberán ser los necesarios para que las actividades y resultados del proyecto sean obtenidos con la máxima eficacia. El segundo paso consiste en un estudio de requisitos mínimos, el cual cubre los requisitos mínimos 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 adquisición adicional. Entre la información más relevante que contiene el estudio de viabilidad se encuentra el análisis de costo-beneficio una evaluación de la justificación económica para un proyecto de sistema basado en computadora. El análisis de costo-beneficio señala los costos del desarrollo del proyecto y los contrasta con los beneficios tangibles (esto es, medibles directamente en pesetas) e intangibles del sistema. El análisis de costo-beneficio es complicado porque los criterios varían según las características del sistema a desarrollar, el tamaño relativo del proyecto y la recuperación esperada de la inversión como parte del plan estratégico de la compañía. Además, muchos beneficios obtenidos de los sistemas basados en computadora son intangibles (por ejemplo: una mejor calidad del diseño mediante una optimización iterativa, una mayor satisfacción del cliente debida a un control programable y unas mejores decisiones comerciales a partir de datos de ventas con formato previamente analizados). Puede ser difícil lograr comparaciones directas cuantitativas.

86

El análisis de los beneficios diferirá dependiendo de las características del sistema. Los beneficios de los sistemas de información de gestión mostrados en la Tabla 2 que se muestra más adelante. La mayoría de los sistemas de proceso de datos se desarrollan al tener como principal objetivo una mejor cantidad, calidad, rapidez y organización de la información. Así, los beneficios de la Tabla 2 se centran en el acceso a la información y su impacto en el entorno del usuario. Los beneficios que se pueden asociar a programas de análisis científico y de ingeniería 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 diseño asistido por computadora (CAD) que vaya a remplazar a elementos del proceso manual de diseño en ingeniería. El analista de sistemas debe definir características ponderables del sistema existente (diseño manual) y del sistema propuesto (CAD). Seleccionando el tiempo de producción de un dibujo completo y detallado (t-dibujo) entre las muchas cantidades medibles, el analista llega a la conclusión de que el sistema CAD supondrá una reducción de 4 a 1 en ese tdibujo. Para cuantificar con más 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, número de dibujos por año =8000. p, porcentaje de dibujo que se va a realizar en el sistema CAD= 60 x 100 Conocidos los datos anteriores, puede establecer una estimación del ahorro anual el beneficio: Ahorro en el costo del tiempo = reducción x t – dibujo x n x c x p = 9 600 000 ptas. por año

87

Tabla 2.- Posibles beneficios del sistema de información. Beneficios de las contribuciones a las tareas de cálculo e impresión Reducción del coste en cálculos e impresiones (RC). 

Mejora en la exactitud de las tareas de cálculo (RE).



Posibilidad de cambiar rápidamente las variables y los valores en los programas de cálculo (AF).



Gran incremento en la velocidad de los cálculos y las impresiones (AV).

Beneficios de las contribuciones a las tareas de mantenimiento de registros Posibilidad de recoger y guardar “automáticamente” datos de los registros (RC, AV, RE). 

Mantenimiento de registros más completo y más sistemático (RC, RE).



Aumento de la capacidad para el mantenimiento de registros en términos de espacio y coste (RC).



Estandarización 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 búsqueda de registros Obtención de registros más rápida (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 búsquedas a través de telecomunicaciones (AF, AV).



Mejores posibilidades de mantener un registro sobre los accesos a los registros y por quién (RE, MG).



Posibilidad de auditar y analizar la actividad de búsqueda de registros (MG, RE).

Beneficios de las contribuciones a la posibilidad de reestructuración del sistema. Posibilidad de cambiar simultáneamente 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 análisis y de simulación Posibilidad de llevar a cabo rápidamente complejos cálculos simultáneos (AV, AF, RE). 

Posibilidad de crear simulaciones de fenómenos 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 planificación y la toma de decisiones (MG, AF).

Beneficios de las contribuciones al control de procesos y de recursos. Reducción de la necesidad de trabajo forzado en el control de procesos y de recursos (RC). 

Mejores posibilidades de ―afinar‖ procesos tales como la línea de ensamblaje (RC, MG, AV, RE).



Mejores posibilidades de mantener una continua monitorización de los procesos y los recursos disponibles (MG, RE, AF).

Otros beneficios tangibles del sistema CAD serían tratados de una manera similar. A los beneficios intangibles (por ejemplo: mejor calidad de diseño y mayor estímulo para los empleados) se les puede asignar valores en pesetas o usarlos como apoyo de una recomendación 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 recuperación de la inversión, el punto de igualdad y el período de amortización. El gráfico que se muestra en la figura 5.6 ilustra estas características para el ejemplo el sistema CAD expuesto anteriormente. Asumimos que el ahorro total por año 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 información. Costes de avituallamiento. 

Coste de consultaría.



Coste de la compra o alquiler del equipo actual.



Coste de la instalación 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 instalación del equipo de comunicaciones (líneas telefónicas, líneas de datos, etc.)



Coste del personal dedicado a la puesta a punto.



Coste de las actividades de búsqueda y contratación de personal.



Coste de los trastornos al resto de la organización.



Coste de la gestión requerida para dirigir la actividad de puesta a punto.

Costes relativos al proyecto. 

Coste de la compra de software de aplicación.



Coste de modificaciones del software para ajustarse a los sistemas locales.



Coste de personal, generales, etc., del desarrollo interno de aplicaciones.



Coste de la formación del personal en el uso de las aplicaciones.



Coste de los procedimientos de recolección de datos y de recolección de datos de instalación.



Coste de la preparación de documentación



Coste de la gestión del desarrollo.

Costes continuos. 

Coste del mantenimiento del sistema (hardware, software y utilidades).



Coste de los alquileres (electricidad, teléfono, etc.).



Coste de la depreciación del hardware. 90



Coste de la plantilla involucrada en las actividades de gestión, operación y planificación del sistema de información.

Otro aspecto del análisis de costo-beneficio es la consideración de los costes incrementales asociados con los beneficios añadidos (mayor o mejor funcionalidad y rendimiento). Para los sistemas basados en computadora, la relación 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. Después de ese punto, cada beneficio adicional es demasiado caro. Por ejemplo, consideremos una función de sondeo en tiempo real que tiene 500 milisegundos de tiempo muerto. Se puede añadir nuevas tareas a un costo relativamente bajo; sin embargo, si la ejecución total de la tarea se aproxima a los 500 milisegundos, el costo de implementación aumenta drásticamente, ya que se debe mejorar el rendimiento global.

En otros casos (curva ABCC’), los costes aumentan proporcionalmente hasta A y después se nivelan a favor de los beneficios añadidos (hasta B), antes de aumentar drásticamente (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 añadir funciones multiusuario puede bajar un poco. Sin embargo, una vez que se alcance la capacidad máxima del procesador, las nuevas funciones requerirán un procesador más potente, con el consiguiente gran incremento en el coste. La siguiente cita caracteriza mejor el análisis de coste-beneficio: Al igual que se olvida la retórica política después de las elecciones, puede que se olvide el análisis de coste-beneficio una vez que comienza la implementación del proyecto. Sin embargo, es extremadamente importante, ya que ha sido el vehículo con el que se ha conseguido la aprobación por parte de la gestión. Sólo gastando el tiempo necesario para evaluar la viabilidad, reducimos las oportunidades de situaciones extremadamente embarazosas (o más que embarazosas) en etapas posteriores de un proyecto de un sistema. El esfuerzo gastado en el análisis de viabilidad que resulta en la cancelación de un proyecto propuesto no es un esfuerzo desaprovechado.

Análisis Técnico Un estudio de la funcionalidad, el rendimiento y las restricciones que pueden afectar a la posibilidad de realización de un sistema aceptable. El analista debe averiguar si es posible actualizar o incrementar los recursos técnicos actuales de tal manera que satisfagan los requerimientos bajo consideración. 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 técnicos actuales son suficientes o deben complementarse. El análisis de factibilidad técnica evalúa si el equipo y software están disponibles (o, en el caso del software, si puede desarrollarse) y si tienen las capacidades técnicas requeridas por cada alternativa del diseño que se esté considerando. Los estudios de factibilidad técnica también consideran las interfaces entre los sistemas actuales y nuevos. 

Mejora del sistema actual.



Disponibilidad de tecnología que satisfaga las necesidades.

Durante el análisis técnico, el analista evalúa los méritos del conocimiento de sistema, mientras que al mismo tiempo recoge información adicional sobre el rendimiento, fiabilidad, facilidad de mantenimiento. En algunos casos la etapa de análisis del sistema también incluye una cantidad limitada de investigación y de diseño. El análisis técnico empieza con una definición de viabilidad también del sistema propuesto. ¿Qué tecnologías se requieren para conseguir la funcionalidad y el rendimiento del sistema? ¿Qué nuevos materiales, métodos, algoritmos o procesos se requieren y cuál es el riesgo de su desarrollo? ¿Cómo afectarán al coste estos elementos de tecnología? Las herramientas de que se puede disponer para el análisis técnico en las técnicas matemáticas de modelización y optimización

en la probabilidad y la

estadística, en la teoría de colas y en la teoría de control. Sin embargo, es importante tener en cuenta que la evaluación analítica no es siempre posible. La modelización (bien matemática o física es un mecanismo efectivo para el análisis técnico de sistemas basados en computadoras. La figura 5.8 ilustra el flujo global de información del proceso de modelización

93

El modelo se crea a partir de la observación del mundo real o de una aproximación 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 información de viabilidad técnica para el sistema propuesto.

. Blanchard y Fabrycky definen un conjunto de criterios para el uso de modelos durante el análisis técnico de sistemas: 

El modelo debe representar la dinámica de la configuración del sistema que está siendo evaluado, de una forma que sea suficientemente simple de comprender y manipular, y también que esté lo suficientemente cerca de la realidad operativa como para obtener resultados satisfactorios.



El modelo debe realzar aquellos factores que sean más relevantes para el problema en cuestión y suprimir aquellos que no sean importantes.



El modelo debe ser amplio, incluyendo todos los factores relevantes, y fiable en cuanto a repetición de resultados. 94



El diseño del modelo debe ser lo suficientemente simple como para permitir una rápida implementación de la resolución del problema. A no ser que la herramienta pueda ser utilizada de una manera rápida 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. También puede ser deseable evaluar un elemento específico de un sistema independientemente del resto de los elementos.



El diseño del modelo debe incorporar previsiones para poder modificarlo y/o expandirlo fácilmente y permitir la evaluación 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 información que no se hayan detectado a primera vista y, consecuentemente, sugerir cambios beneficiosos.

Los resultados del análisis técnico son la base de otra decisión del tipo ―seguir/ no seguir‖ con el sistema. Si el riesgo técnico es alto, si los modelos indican que la funcionalidad o el rendimiento deseados no pueden ser alcanzados, o si las piezas no encajan bien.

Análisis Operativa Se refiere a todos aquellos recursos donde interviene algún tipo de actividad (procesos), depende de los recursos humanos que participen durante la operación del proyecto. Durante esta etapa se identifican todas aquellas actividades que son necesarias para lograr el objetivo y se evalúa y determina todo lo necesario para llevarla a cabo. Comprende una determinación de la probabilidad de que un nuevo sistema se use como se supone. 

Operación garantizada.



Uso garantizado.

95

Análisis Legal Una determinación de cualquier infracción, violación o ilegalidad que pudiera resultar del desarrollo del sistema. Lo que Implica revisar si el desarrollo del proyecto implica la violación de alguna ley, decreto, ordenanza o norma legal, bien sea a nivel nacional, estatal o municipal. 

Ley Orgánica de las Telecomunicaciones.



Ley de Ciencia, Tecnología e Innovación.



Ley Especial sobre Delitos Informáticos.



Decreto con fuerza de Ley de mensaje de Datos y Firmas Electrónicas.

Análisis Organizacional Implica el estudio de los efectos que puede generar el proyecto dentro de la organización donde será implementado.

Aspectos donde pueden tener impacto: 

Comunicación organizacional: ¿Mejora la comunicación?



Eficiencia en los procesos: ¿Acelera la producción? ¿Entra en conflicto con otros procesos de la organización?



Estructura organizacional: ¿Su impacto afecta la estructura organizacional? 96