ASPECTOS CLAVES PARA MINIMIZAR EL RIESGO DE NO TENER XITO EN LOS PROYECTOS DE DESARROLLO DE SOFTWARE

Eje temtico: Desarrollo de software Subtema: Gerencia de proyectos de desarrollo de software Wveimar Lpez Marin, aspirante a Especialista en Gerencia de Proyectos, Universidad Pontificia Bolivariana, XXXX@gmail.com Ingeniero Informtico del Politcnico Colombiano Jaime Isaza Cadavid e ingeniero de desarrollo de software de profesin.

Resumen del artculo

La gerencia de proyectos de desarrollo de software es una disciplina que tiene fundamentos tericos slidos, en la cual gran cantidad de autores y compaas reconocidas en el medio han hecho sus aportes, por medio de textos, cursos y metodologas, siendo stas ltimas la mas aceptadas, dado que sirven de gua para abarcar todo el proceso de desarrollo de software. Desafortunadamente, tanto la teora como dichas metodologas son solamente instrumentos que requieren cierto grado de adaptacin, el cual slo se consigue luego de haberlas utilizado en varias oportunidades, y que an as es difcil saber con precisin si un proyecto determinado tendr xito o no. Dadas las condiciones anteriores, el presente artculo tratar de explicar los aspectos claves que minimizan el riesgo de no tener xito al abordar un proyecto de desarrollo de software.

Palabras clave Gerencia de proyectos de software, metodologas de desarrollo, desarrollo de software

Introduccin El xito en el proceso de desarrollo de software es complejo de medir, dado que en ste influyen varios factores como lo son el costo, el tiempo y el alcance, y que dependiendo del punto de vista son ms importantes ciertos factores que otros. Puede que para los patrocinadores y administradores del proyecto sea ms importante el costo y el tiempo, pero para los programadores y usuarios finales lo sea el alcance, el cul est determinado por la funcionalidad cubierta y la calidad del sistema construido.

Objetivo general :Identificar los factores claves de xito en un proyecto de desarrollo de software.

Objetivos especficos Determinar cules son las causas que hoy en da inciden negativamente en los proyectos de desarrollo de software. Explorar las posibles soluciones a los problemas que se presentan en los proyectos de desarrollo de software.

Teniendo en cuenta que es muy subjetivo medir el xito en los proyectos de desarrollo de software, y que abordar dicha discusin estara por fuera del alcance de esta investigacin, el propsito de este artculo se centra en la discusin de los problemas actuales en la gestin de proyectos de desarrollo de software y en la identificacin de los aspectos claves que permiten alcanzar un mayor grado de xito en dichos proyectos. De acuerdo con lo anterior, en lugar de determinar la forma de identificar si un proyecto de software es exitoso o no, se buscar la forma de establecer cules son los problemas a los cuales se enfrentan dicho tipo de proyectos, para luego a partir de estos discutir sobre cules pueden ser los aspectos claves que permitiran aumentar la probabilidad de tener xito.

Qu es un proyecto de desarrollo de software? Un proyecto de desarrollo de software es una secuencia de tareas encaminadas a producir un producto de software de alta de calidad en el tiempo y presupuesto acordados (Henry, 2004). Una definicin mas personal dira que un proyecto de desarrollo de software es aquel que bajo ciertas restricciones de tiempo y costo, usa un conjunto de recursos (humanos y tcnicos), para transformar un conjunto de requerimientos de usuario, en un sistema de informacin que mejora o automatiza un proceso nuevo o existente.

En comparacin con otros tipos de proyectos, los proyectos de desarrollo de software comparten muchas similitudes: restricciones de tiempo y costo, un conjunto de recursos y unas especificaciones tcnicas y operativas. Lo que hace interesante la administracin de proyectos de software es la incertidumbre que existe sobre la finalizacin de las tareas que tienen por objetivo implementar las caractersticas requeridas por los usuarios finales, dado que el software es un intangible, y a diferencia de por ejemplo, la construccin, no es fcil ver cada uno de los elementos que van constituyendo la solucin final: paredes, puertas, ventanas, techo, etc.

Por qu es importante la gerencia de un proyecto de desarrollo de software? Dado el alto grado de incertidumbre que tienen los proyectos de desarrollo de software en comparacin con otros tipos de proyectos, cobra mayor importancia tener cuidado con todo su proceso de gerencia. Cualquier tipo de proyecto siempre tendr un rol encargado de velar por el cumplimiento de las tareas asignadas dentro del tiempo establecido. En los proyectos de desarrollo de software es de vital importancia cumplir con este rol, y asignarlo a personas con experiencia en el rea. Los problemas comienzan desde el mismo proceso de definicin de requisitos, en el cual es muy difcil tener suficiente claridad al respecto desde el principio. Luego, en el proceso de diseo e implementacin los problemas tcnicos surgen constantemente. Por ltimo, en el proceso de instalacin y despliegue es en donde generalmente se encuentran sorpresas dadas por la arquitectura y la plataforma de la compaa que adquiere el sistema de informacin. De acuerdo con lo anterior, es importante contar con un gerente de proyectos capaz de sortear cualquier cantidad de obstculos, el cual debe asumir una posicin tica y profesional para negociar con el cliente aquellos posibles retrasos y sobrecostos ocasionados por dicha incertidumbre.

Problemas actuales en la gestin de estos proyectos James McDonald (2001), Pankaj Jalote (2002) y Joel Henry (2004) identifican un sinnmero de causas a las cuales se les puede atribuir los problemas en la gestin de proyectos de desarrollo de software. El objetivo aqu es identificar aquellos que son los ms comunes, y a

partir de los cuales se puede hacer un diagnstico general de los que mayormente aquejan a este tipo de proyectos.

Alcance El cumplimiento de los requerimientos del usuario con buena calidad es el criterio ms importante para evaluar el xito de un proyecto de acuerdo con la opinin de las personas que trabajan para ste (Agarwal & Rathod, 2006). de requisitos funcionales y no funcionales1. Respecto al alcance, son varios los tipos de problemas que se presentan. En algunas ocasiones se obvia por completo dicho proceso, mientras que en otras, simplemente no se la da la importancia que se merece. En un estudio sobre la definicin del xito en los proyectos de de desarrollo de software hecho con compaas de software de la India (Agarwal & Rathod, 2006), consideran el costo, el tiempo y el alcance como las factores de xito ms importantes, y por encima de estos, dan mayor importancia al ltimo. Adicionalmente, consideran que el alcance puede ser descompuesto en dos elementos: funcionalidad y calidad. Sobre estas dos, el estudio reseado indica que es ms importante la funcionalidad sobre la calidad. Definir claramente el punto de llegada en la construccin de un sistema de informacin es clave. No obstante, es importante sealar que la mayora de las veces el alcance necesita ser redefinido, sea bien para incrementarlo o disminuirlo, de acuerdo con factores de costo y tiempo que ponen de manifiesto alguna restriccin. Este proceso se realiza mediante lo que comnmente se conoce como levantamiento de requerimientos, y comprende la identificacin

Tiempo

Los requisitos funcionales son aquellos que indican las caractersticas operativas que debe ofrecer la solucin final, mientras que los requisitos no funcionales hablan sobre factores como el rendimiento, la escalabilidad, la disponibilidad, el tiempo de respuesta del sistema, etc.

Igualmente, Agarwal & Rathod (2006) indican que entre el costo y el tiempo, los profesionales del software califican como ms importante el factor tiempo como clave en el logro del xito. En otro estudio sobre la reduccin del tiempo de desarrollo de productos de software (Callagan & Moretton, 2001), los autores referencian otra investigacin en la cual afirman que el nmero de meses dedicados al desarrollo de un producto se incrementa de acuerdo con la complejidad y lo novedoso del mismo. Tambin resaltan que la utilizacin de un proceso formal de desarrollo reduce el tiempo en la construccin de productos complejos. La definicin de tiempos, su posterior materializacin en cronogramas de trabajo (donde se unen recursos, tiempos y tareas para realizar una programacin detallada de actividades), y el seguimiento a los mismos han sido uno de los talones de Aquiles del desarrollo de software. En gran cantidad de proyectos es comn encontrar problemas con el cumplimiento de los cronogramas definidos.

Costo De acuerdo con los enunciados anteriores, entre el alcance, el tiempo y el costo, ste ltimo cobra menor importancia para los profesionales del software, lo cual en cierta medida es una posicin razonable para el agente que presta el servicio, el cual es el que recibe una retribucin econmica directa por el mismo. De otro lado, desde el punto de vista de quien recibe el servicio (cliente), cuando el costo del proyecto es alto, o en el peor de los casos, se incrementa durante la ejecucin del proyecto, su grado de insatisfaccin tiende a aumentar. Las compaas de desarrollo de software en ocasiones se olvidan que debe existir un balance entre las tres variables enunciadas inicialmente, y se debe tener mucha claridad desde el principio sobre el alcance del proyecto de acuerdo con el presupuesto disponible.

Retrasos

Los retrasos en el cronograma de trabajo estn estrechamente relacionados con el tiempo, pero estos surgen a causa de imprevistos y al alto grado de incertidumbre con el cual se hacen las estimaciones iniciales. Es comn encontrar proyectos de desarrollo de software que sufren retrasos por dificultades tcnicas, subestimacin de la complejidad de algunos requerimientos, inexperiencia de algunos integrantes del equipo de trabajo, pobre definicin de alcance, etc.

Gestin de cambios La gestin de cambios est estrechamente relacionada con el alcance. Es normal que durante el proceso de desarrollo del sistema de informacin surjan cambios como consecuencia de mejoras o adiciones solicitadas por el cliente, o a causa de elementos identificados por el mismo equipo de desarrollo. Los cambios como tal no son malos, ni el objetivo es buscar la forma de que no se presenten. Las valoraciones hechas inicialmente para definir el alcance del sistema aunque tratan de cubrir al mximo toda la funcionalidad requerida, generalmente se someten a cambios ocurridos durante el proceso de construccin. El aspecto negativo de los cambios tiene que ver con el sobrecosto que estos representan y la modificacin del cronograma de trabajo. El sobrecosto resulta como consecuencia del esfuerzo adicional requerido para implementar la nueva funcionalidad o para hacer un cambio sobre lo que ya se ha hecho, y el problema estriba en la negociacin con el cliente para trasladar dicho costo al valor total del proyecto. La modificacin al cronograma obliga al gerente del proyecto a acomodar el recurso humano de tal forma que la fecha de finalizacin del proyecto no se vea afectada mayormente.

Desgaste del equipo de trabajo La literatura consultada no ofrece informacin sobre este problema, pero la experiencia indica que los proyectos que tienen problemas de alcance, costo y tiempo, terminan por generar cierto desgaste e inconformidad en los integrantes del equipo, principalmente en los desarrolladores.

Es cierto que el mercado laboral de los profesionales de la informtica se mueve bastante, y esto es generalmente ocasionado por dos factores: la aparicin de mejores oportunidades en trminos econmicos y el desgaste ocasionado por aquellos proyectos que demandan esfuerzos laborales que van en contra del beneficio personal y de la vida social.

Aspectos claves en la gerencia de proyectos de desarrollo de software A continuacin se enumeran los aspectos que de acuerdo con la investigacin realizada, son considerados por Pankaj Jalote (2002), Joel Henry (2004), Nitin Agarwal y Urvashi Rathod (2006) como elementos claves para tener xito en la gestin de proyectos de desarrollo de software. Es posible que existan ms, pero esta recopilacin de los ms importantes sirve como punto de partida para comenzar a obtener proyectos exitosos.

Planeacin La planeacin es quiz el elemento ms importante en la gerencia de proyectos de desarrollo de software. Una buena planeacin se convierte en la carta de navegacin del proyecto y permite a los administradores del mismo tener control sobre la ejecucin. Tempranamente en el proyecto, es importante identificar el modelo de desarrollo a utilizar. Para tal efecto, se cuenta con varias alternativas: el modelo en cascada, el modelo iterativoincremental, el modelo por prototipos y el modelo en espiral (Jalote, 2002). En el primero, el sistema a construir se aborda como un todo y se avanza por cada una de sus fases (planeacin, especificacin, construccin, pruebas y despliegue) de forma secuencial. El problema es que hoy en da esta prctica ha demostrado poca efectividad debido a que hace muy complicado poder devolverse en cada una de las etapas. Es por esto que es ms aconsejable usar un modelo iterativo e incremental, en el cual el proyecto se descompone en varios subproyectos, cada uno de los cuales ofrece un conjunto de funcionalidades bien definidas, y donde es ms fcil devolverse en cada una de las etapas del proceso. Adicionalmente, es vlido afirmar que el uso de metodologas como RUP, la cual usa un modelo iterativo e incremental, ha

demostrado ser efectivo, pero exige cierto grado de adaptacin el cual toma tiempo al principio. La determinacin del modelo a utilizar es un aspecto crucial porque gran parte del trabajo de ingeniera ser gobernado por esta decisin (Jalote 2002). Aunque es muy importante decidir el tipo de proceso, tambin lo es afirmar que la experiencia personal en proyectos pasados es un buen punto de apoyo para tomar esta decisin, y para saber que ceirse estrictamente a un proceso o metodologa no es lo ms recomendado. Ms bien, una adaptacin propia de estas de acuerdo con las circunstancias particulares y la experiencia pasada es la combinacin que puede dar mejores resultados.

Estimacin de esfuerzos: cronograma La estimacin de esfuerzos es una de las actividades de la gerencia del proyecto que con mayor cuidado y seriedad se deben abordar. Muy temprano en el proyecto se comienzan a hacer estimaciones, las cuales tienen por objetivo determinar esfuerzos, recursos y costos. Es normal hacer estimaciones iniciales basadas en informacin superficial sobre el alcance del proyecto, pero dejando claro que es algo tentativo. Luego, cuando el alcance est claramente definido y los requisitos funcionales y no funcionales hayan sido acordados, se debe elaborar una estimacin de esfuerzos definitiva. El problema que se presenta con las estimaciones es la diferencia que generalmente se presenta entre lo estimado y la realidad. Es claro que es muy difcil hacer una estimacin que sea precisa, y siempre existira cierto grado de incertidumbre en esta a causa de tareas complejas o de ciertos supuestos hechos durante su elaboracin. El objetivo de un administrador de proyectos es obtener estimaciones razonables de tal forma que las metas puedan ser cumplidas y el personal del proyecto no sea quemado (Jalote, 2002).

El uso de modelos de estimacin ayuda a crear planes de trabajo donde la incertidumbre disminuye en la medida en que se tenga mayor informacin sobre el proyecto. Un ejemplo de tales modelos es el conocido con el nombre de Use Case Points2, el cual permite, a partir de la identificacin de los casos de uso del sistema y de la determinacin de su complejidad, asignar ciertos valores numricos que luego permiten establecer el tiempo que podr llevar a cabo cada una de las actividades del proyecto. Una vez obtenido el esfuerzo total requerido, el cual generalmente es dado en unidades de horas/hombre, se debe establecer un balance entre el tiempo y la cantidad de recurso humano requerido. As pues, si la estimacin arroja un valor de 1600 horas/hombre, se podra decir que se requieren un total de 200 das/hombre (asumiendo das de 8 horas laborales). Dado este valor, es posible afirmar que con 5 personas es posible alcanzar el objetivo propuesto en un total de 40 das laborales, o con 4 personas en 50 das. Esta distribucin de tiempo y recurso humano debe ser razonable. As, por ejemplo, no es viable alcanzar el objetivo usando 10 personas pretendiendo terminar en tan slo 20 das, o por el contrario, terminar en 100 das usando slo 2 personas. Esto es como afirmar que si una madre puede gestar un beb en 9 meses, entonces 9 madres lo pueden hacer en uno solo. Una forma acertada de determinar la cantidad de recurso humano requerido en un proyecto, consiste en hallar la raz cuadrada del esfuerzo total medido en unidades de meses/hombre (Jalote, 2002). Esta medida es conocida con el nombre de square root check (chequeo de raz cuadrada), y permite establecer la duracin del cronograma para proyectos pequeos y medianos. As, por ejemplo, si la estimacin de esfuerzo da como resultado un valor de 50 meses/hombre, un cronograma de aproximadamente 7 u 8 meses se ajusta con aproximadamente 7 u 8 recursos asignados tiempo completo.

Gestin y entrenamiento del recurso humano

Informacin detallada sobre el modelo Use Case Points puede ser encontrada fcilmente por medio de los motores de bsqueda disponibles en Internet.

Joel Henry (2004) enuncia los cuatro componentes que estructuran la base de un proyecto: gente, procesos, herramientas y mediciones, y dice que ignorar alguna de estas puede gravemente impactar o incluso mortalmente lisiar un proyecto. De acuerdo con lo anterior, uno de los elementos ms importantes en los proyectos de desarrollo de software es el recurso humano. La gerencia de proyectos debe ser consciente que en este tipo de proyectos generalmente se cuenta con personas talentosas e inteligentes las cuales requieren un tratamiento especial. Son personas que requieren cierto grado de autonoma para hacer sus cosas, y a las cuales no les gusta sentirse presionados u obligados a seguir ciertos lineamientos estrictos. Son conscientes de que se debe seguir un proceso, pero tambin les gusta tener cierta libertad para hacer su trabajo. Igualmente, tambin es importante proporcionar al equipo de trabajo las herramientas adecuadas con el propsito de buscar la mejor forma de explotar sus habilidades y aumentar su productividad. Los ingenieros de desarrollo de software tienen la habilidad de poder trabajar con la herramienta que les proporcionen, pero la calidad de la herramienta entregada es un condicionante importante de la calidad del trabajo y del tiempo requerido para llevarlo a cabo. Adicionalmente, una apropiada gestin del recurso humano tambin es responsable de tareas como proporcionar una herramienta para registrar el tiempo invertido en cada una de las actividades, guardar sus apuntes sobre problemas resueltos, o recordar cmo el equipo invirti su tiempo. Esto permite hacer seguimiento a la ejecucin del proyecto, y se convierte en informacin valiosa para el futuro, permitiendo as afinar los procesos de estimacin de tiempos y consiguiendo mejores ganancias en el futuro. El gerente de proyectos debe tener muy presente que su equipo de trabajo no est trabajando para l, sino que por el contrario, l est trabajando con ellos para alcanzar el mismo objetivo. Aunque la posicin de su rol pone de manifiesto cierta autoridad y poder de mando, el gerente de proyectos debe ser capaz de manejar estas facultades haciendo que el equipo no sienta que tiene un jefe que en todo momento asume la posicin de un supervisor o un capataz. El gerente de proyectos debe ser un aliado del resto del equipo y debe hacer sentir a ste que

todos estn al mismo nivel, y que la responsabilidad del trabajo asignado es cuestin de todos, no de unos cuantos solamente. De otro lado, proporcionar un conjunto de herramientas al equipo de trabajo no es suficiente De qu sirve tener las mejores herramientas si no se sabe cmo usarlas? El entrenamiento se hace necesario cuando el equipo no conoce la forma correcta de usar las herramientas. Hay quienes argumentan que los ingenieros son muy autnomos y capaces para aprender las cosas por s mismos. Esto es cierto, pero dedicar cierto tiempo del cronograma de actividades a capacitar los involucrados en el uso de ciertas herramientas aumenta la productividad y reduce el tiempo requerido en aplicar correctamente al proyecto el uso de estas. Es importante hacer nfasis en la necesidad de capacitar el equipo en el momento adecuado. De nada sirve enviar a los involucrados a un curso dos meses antes de comenzar a usar las herramientas. El paso del tiempo se encarga de hacer olvidar aquello que no se usa, y ms an, aquello que nunca antes se ha usado. Tambin es importante aclarar que capacitacin no quiere decir entregar un manual al equipo para que lo lea y aprenda. Lo ideal es tomar un curso guiado por un experto en la materia, acordando previamente con el instructor acerca del contenido requerido por el equipo de acuerdo con las necesidades particulares del proyecto que van a enfrentar (Henry, 2004). El reto del gerente de proyectos est en verificar que las herramientas aprendidas se usen correctamente, y que no ocurra que el equipo haya vuelto a usar las herramientas tradicionales por temor a cambiar de manera de pensar y trabajar.

Proceso de revisin de calidad Pankaj Jalote (2002) define las pruebas como el proceso de ejecutar un software (o parte de el) en un intento por identificar defectos. Esta definicin simple pero precisa conlleva a pensar sobre la importancia que ha adquirido durante los ltimos aos en la industria del desarrollo de software la definicin de un rol encargado de hacer lo que popularmente se conoce como testing.

En un principio esta labor o no se haca, o se dejaba como algo que se deba hacer al final del proceso de desarrollo. Luego de tener problemas al liberar productos al mercado con gran cantidad de defectos, las compaas de desarrollo de software entendieron que dicho rol deba ser involucrado desde fases muy tempranas del proyecto, con el objetivo de que ste no recibiera un producto ya hecho para probar, sino que desde el mismo levantamiento de requerimientos se tuviera informacin sobre lo que se deseaba construir, para con base en sta elaborar un plan de pruebas que luego se pondra en marcha una vez terminada una parte o todo el sistema. En el prrafo anterior se hizo una descripcin muy breve de lo que hoy en da se hace en muchas compaas como parte del proceso de pruebas al software. Un proceso ms elaborado puede ser ilustrado en la siguiente grfica:
Grfico 1: proceso de pruebas de desarrollo de software

De acuerdo con la ilustracin anterior, tanto el proceso de inyeccin de defectos como el proceso de solucin de los mismos comienzan desde etapas muy tempranas del proceso. Desde la toma de requerimientos y el diseo del sistema es posible identificar posibles defectos, algo que no es muy comn en nuestro medio. Esto se puede lograr haciendo revisiones en cada una de estas etapas buscando focos a posibles problemas. El momento en el cual se introducen ms defectos al software es sin lugar a dudas en la fase de codificacin, luego de la cual es importante hacer pruebas de desarrollo para remover la

mayor cantidad de defectos posible, y crear las pruebas unitarias necesarias para ir asegurando que un ajuste hecho en una parte del sistema no desestabilice otra. Como se enunci anteriormente, el equipo de pruebas desde fases muy tempranas del proyecto debe trabajar en la construccin de su plan de pruebas con base en la informacin disponible en su momento: documento de requerimientos, diseo, cronograma, etc. Luego de terminar la fase de desarrollo entra a desempear su papel de verdugo, tratando de encontrar la mayor cantidad de defectos posibles, buscando producir software de alta calidad. Es all donde se hacen las pruebas de integracin, de sistema y de aceptacin. Es importante aclarar que es prcticamente imposible construir un producto con cero defectos. Nadie puede dar fe de que por mejor que sea el mtodo usado para probar un software, los defectos no seguirn presentes en el sistema. De todas formas, el objetivo de hacer las pruebas est en identificar y remover aquellos errores que de no corregirse daran mala calidad al producto final. Tambin es importante recalcar sobre la importancia del uso de herramientas para la gestin de errores, las cuales permiten registrar las incidencias encontradas, hacer seguimiento a su evolucin en el proceso de correccin, y usar la informacin recopilada en experiencias pasadas para ir afinando continuamente el proceso de pruebas.

Administracin de riesgos La administracin del riesgo es un intento para minimizar las posibilidades de fallar causadas por eventos no planeados (Jalote, 2002). El objetivo de la administracin del riesgo no es el de evitar que los riesgos existan en los proyectos, sino por el contrario, saberlos controlar y establecer planes de accin para evitar que se convierten en verdaderos problemas. Tal y como lo define la Real Academia Espaola, un riesgo no es ms que la contingencia o proximidad de un dao. de ocurrencia, y priorizarlos. Es por esto que es responsabilidad del gerente de proyectos identificar los posibles riesgos que se pueden presentar, medirlos, determinar su probabilidad

As, por ejemplo, cuando el desarrollo de un nuevo sistema espera integrarse con otro sistema desarrollado por un tercero, es importante identificar los riesgos que pueden surgir como consecuencia del proceso de integracin: entrega a destiempo por parte del otro equipo de desarrollo, incompatibilidad de las interfaces definidas, plataformas de desarrollo incompatibles, etc. Uno de los principales objetivos de la gestin del riesgo es reducir el costo en el cual se puede incurrir en caso de que el riesgo se haga realidad. Si por ejemplo es necesario contar con un sistema de informacin de alta disponibilidad, y si ante una eventual cada del sistema por pocos minutos la prdida en trminos monetarios es alta, entonces es de vital importancia contar con un mecanismo de contingencia que entre en accin ante tal cada. Si se trata de un problema de fluido elctrico temporal, el riesgo se puede mitigar adquiriendo una UPS3; si se trata de un problema de mayor duracin, el riesgo se puede controlar creando un sistema de reserva que entre en accin cuando el sistema principal falle. Es por esto que es importante medir el riesgo en trminos del costo ocasionado en caso tal de que se presente, para as determinar si es necesario establecer mecanismos claros de contingencia. Una vez realizada la identificacin de los riesgos es importante priorizarlos. Es posible identificar un sinnmero de riesgos, pero no todos estos interesa controlarlos. La priorizacin consiste en determinar aquellos que tienen mayor probabilidad de ocurrencia y aquellos que tienen un costo alto o una consecuencia funesta en caso de que se hagan realidad. De acuerdo con lo anterior, de la lista original de riesgos es normal que slo queden unos pocos, teniendo la certeza que aquellos que no se descartaron son los que cobran real importancia dentro del proyecto. Todo el proceso de administracin de riesgos se puede dividir en dos etapas: identificacin y control (Jalote, 2002). Una vez identificados y priorizados los riesgos ms importantes, el gerente de proyectos tiene la responsabilidad de establecer el plan de accin para controlarlos,

UPS (Universal Power Supply): equipo que est en capacidad de proporcionar fluido elctrico ante el evento de un corte del mismo en el sistema convencional.

y en la medida de lo posible irlos mitigando. Una revisin continua de la lista de riesgos identificados, y la ejecucin a tiempo de los planes de accin creados para controlarlos permitirn que los riesgos disminuyan su probabilidad de ocurrencia, o en el mejor de los casos, dejen de percibirsen como tal. La tarea de priorizar los riesgos se debe realizar estableciendo medidas cuantitativas sobre los mismos. Para lograr esto es comn utilizar una medida conocida como exposicin del riesgo, la cual es posible establecer a partir de dos mediciones numricas: el nivel de probabilidad del riesgo y el nivel de la consecuencia (impacto) del riesgo. La probabilidad de riesgo se puede establecer dndole valores numricos a tres clasificaciones cualitativas, tal y como se pude apreciar en la siguiente tabla:

Tabla 1: Categoras de riesgos

Probabilidad Baja Media Alta

Rango 0.0 0.3 0.3 0.7 0.7 1.0

Fuente: Software Project Management in Practice (Jalote, 2002)

Igualmente, el impacto del riesgo se puede establecer de la siguiente manera:

Tabla 2: Categoras de impactos

Probabilidad Baja Media Alta Muy alta

Rango 0.0 3.0 3.0 7.0 7.0 9.0 9.0 10.0

Fuente: Software Project Management in Practice (Jalote, 2002)

Haciendo uso de la informacin anterior, a cada riesgo se le debe asignar una probabilidad de ocurrencia y su posible impacto. Aquellos riesgos cuyo producto de los valores de probabilidad e impacto sean ms altos son los que deben ser considerados como ms importantes de mitigar y controlar. El valor resultante es lo que se conoce como exposicin del riesgo.

Herramientas Al hablar de herramientas es posible pensar en una gran variedad de estas: de seguimiento, de desarrollo, de pruebas, etc. Es cierto que el desarrollo de software requiere de todo tipo de herramientas, y que sin estas no es posible hacer el trabajo. Tambin es cierto que en el mercado existen gran variedad estas, algunas muy costosas y sofisticadas, otras ms accesibles y otras gratuitas. Algunos piensan que una compaa de desarrollo de software es ms grande de acuerdo con el tipo de herramientas que usa, y esto muchas veces es falso. Es posible conformar un gran equipo, usando gran variedad de herramientas a un costo muy razonable, y siguiendo un proceso derivado de una metodologa conocida (RUP4 o MSF5), y de la experiencia de sus integrantes. Algunas compaas cometen el error de querer usar una metodologa al pie de la letra, y terminan siguiendo unos lineamientos estrictos que desgastan el recurso humano y que no dan los resultados esperados. Las metodologas en definicin son excelentes, pero requieren cierto grado de adaptacin, el cual con el paso del tiempo se puede ir afinando. La siguiente tabla muestra algunas herramientas que pueden ser usadas en el proceso de desarrollo de software, las cuales son gratuitas o su costo es muy bajo:

RUP (Rational Unified Process): metodologa de desarrollo propuesta por IBM, y la cual ha tenido gran aceptacin dado que ofrece todo un marco terico y el conjunto de herramientas para llevar a cabo todo el proceso. Ms informacin al respecto se puede encontrar en http://www.ibm.com 5 MSF (Microsoft Solutions Framework): metodologa de desarrollo propuesta por Microsoft. Ms informacin al respecto se puede encontrar en http://www.microsoft.com

Tabla 3: Herramientas que apoyan el proceso de desarrollo de software

Categora versiones Pruebas unitarias

Herramienta CVS (Java) NUnit (.Net) JUnit (Java)

Repositorio de cdigo fuente y controlador de Microsoft Source Safe (.Net)

Sistema de seguimiento y gestin de errores Mantis (bugs) Sistemas de integracin de cdigo Bugzilla Jira CruiseControl

Fuente: elaboracin propia

Conclusiones El desarrollo de software y ms an, la administracin de proyectos de software es una disciplina que comparte muchas similitudes con la gestin de otros tipos de proyectos, pero tiene el problema de tratar con intangibles, lo cual hace mucho ms difcil tener control sobre la ejecucin y el cumplimiento de sus metas, y en donde la incertidumbre es un elemento que aade mayor complejidad a su gestin. Igualmente, es vlido afirmar que el desarrollo de software es una ciencia muy reciente y la cual evoluciona constantemente, lo cual la hace an ms compleja de administrar. Pensar que en la gerencia de proyectos de desarrollo de software se encontrar dentro de poco tiempo una solucin definitiva a los problemas que actualmente presenta es una posicin demasiado optimista. Lo que s es posible hacer, es ir ajustando las tuercas a medida que se vayan encontrado nuevas maneras de hacer las cosas y usar la experiencia pasada para no volver a cometer los mismos errores. No es casual que incluso grandes compaas como Microsoft tengan retrasos en la liberacin de sus

nuevos productos. La incertidumbre sobre la construccin de algo intangible siempre estar ah presente. La adaptacin simplificada de metodologas de desarrollo conocidas y la utilizacin de herramientas como las mencionadas en el apartado que lleva el mismo nombre, sumado a la experiencia de los miembros del equipo, son elementos fundamentales que aportan gran valor para lograr el xito en los proyectos de desarrollo de software.

Recomendaciones Cuando un proyecto de desarrollo de software es exitoso se da la situacin de que al no haber problemas no se trata de averiguar las razones por las cuales las cosas salieron bien. Slo en aquellos proyectos que presentan problemas se trata de determinar qu es lo que se est haciendo mal. En los proyectos exitosos se debera hacer lo mismo que se hace con proyectos que tienen problemas: saber por qu las cosas salieron bien o mal y aprender de estas experiencias para aplicar el aprendizaje adquirido y no cometer los mismos errores en futuros proyectos. La utilizacin de una metodologa de desarrollo de software es un aspecto importante en el proceso de construccin de sistemas de informacin. Estas son el producto de aos de investigacin de compaas importantes y de expertos en el tema. Adaptar una metodologa en particular, o tomar elementos de varias de estas son un punto de partida importante para estructurar un proceso que puede producir software de alta calidad.

Bibliografa Agarwal N., Rathod U. (2006). Defining success for sotftware projects: An exploratory revelation. International Journal of Project Management, 24 (4), 358-370. Recuperado el 14 de abril de 2007 desde la base de datos Science Direct en Internet: http://www.sciencedirect.com

Callahan, J. y Moretton, B. (2001). Reducing software product development time. International journal of project management, 19 (1), 59-70. Recuperado el 14 de abril de 2007 desde la base de datos Science Direct en Internet: http://www.sciencedirect.com Henry, J. (2004). Software Project Management. Boston: Pearson Addison-Wesley Jalote, P. (2002). Software Project Management in Pracice. Boston: Addison-Wesley Joyce, J. (2006). Software Project Management, Simplified. Scientific Computing, 23(9), 1640. Recuperado el 28 de abril de 2007 desde la base de datos EBSCO (Academic Search Premier) en Internet: http://www.ebsco.com McDonald, J. (2001). Why Is Software Project Management Difficult? And What That Implies for Teaching Software Project Management. Computer Science Education, 11(1), 55-71. Recuperado el 28 de abril de 2007 desde la base de datos EBSCO (Academic Search Elite) en Internet: http://www.ebsco.com