Universidad de Talca Mdulo: Metodologas de desarrollo de software

FACTORES QUE INFLUYEN EN EL FRACASO DE PROYECTOS Y SU REPERCUSIN

Sebastin Fuentes Darlyn Gonzlez Mauricio Orellana Yorch Seplveda

Curic Chile 15 de mayo de 2012

INTRODUCCIN En el mundo de la computacin, y especficamente en el rea del desarrollo de software, solamente un 17% de los proyectos son terminados correctamente, vale decir, dentro del tiempo y del costo estimado inicialmente. Para todo proyecto debe existir una gestin antes de su desarrollo, esto es, estudiar todos los posibles casos en el que el software se vea perjudicado ya sea por cambio de requisitos o cualquier otro tipo de factor que se mencionarn mas tarde. Aun as la tendencia a que un proyecto fracase debido a distintos factores se encuentra en una mayor probabilidad de que este sea exitoso, siempre y cuando no sepa hacerse el procedimiento antes mencionado. Cabe destacar que una buena gestin en los proyectos, puede aminorar en gran parte la posibilidad de fracaso que stos tengan.

EL FRACASO EN LOS PROYECTOS Si bien los causas que pueden llevar a que un proyecto de software falle resultan variadas, la mayora de los autores coinciden en muchas de ellas, haciendo posible as, determinar los principales factores que actan a lo largo del desarrollo de un proyecto. Aunque el tema del fracaso en los proyectos ha sido ya muy estudiado, sigue habiendo una gran cantidad de proyectos que fracasan por los mismos factores.

FACTORES QUE INTERFIEREN EN EL FRACASO Entre las principales causas de fracaso en las que los autores coinciden podemos encontrar las siguientes: PROGRAMADORES SOMETIDOS A ESTRS El estrs al cual se ven sometidos los programadores no es menor, es por esto que se han realizado diversos estudios en las industrias de software japonesas referidos a la tensin que enfrenta un programador, la cual es sumamente comn pero conlleva a grandes problemticas mas tarde. Uno de estos estudios nombrados por Glass fue el de Fujigaki(1993), el cual nos da a conocer la medicin del grado de estrs presente en las diferentes tareas de programacin intentando identificar la causa de este en cada fase del desarrollo del proyecto de software, arrojando los siguientes resultados:

Estudio sobre proyectos de software, CHAOS 2004

Fig 1: resultados de 50.000 proyectos comerciales y gubernamentales del ao 2004.

En la fase de definicin de requisitos y el diseo, el estrs se observa en forma de ansiedad y depresin, siendo la posible causa el hecho de anticipar las necesidades

de los usuarios, los cuales fueron presentados a menudo de forma ambigua cambiando contantemente teniendo requisitos poco claros. Durante la codificacin, la investigacin mostro que el estrs se presento en forma de irritabilidad y baja moral, teniendo como causa el poder moldear una solucin de los innumerables detalles que se presentaban poco sustentables. Mientras que en la fase de pruebas, se encontr que la tensin de todas las categoras corri desenfrenadamente, la causa observada fue la lucha por atar todos los cabos sueltos de las fases anteriores para lograr un buen funcionamiento. Glass fue claro en nombrar que el autor del estudio Fujigaki, daba como causante del estrs existente en los programadores a la mala eleccin del modelo de gestin utilizado. El segundo estudio midi el impacto del estrs en el nmero de errores que posea el producto de software de los programadores estresados, deduciendo que estos cometen mucho ms errores bajo este que en circunstancias normales, la investigacin arrojo que en la fase diseo se presenta la mayor vulnerabilidad de los errores causados por el estrs. Los resultados fueron especficos al examinar los defectos del software, los investigadores encontraron que el 37% se pudieron evitar por una buena planificacin sin tensin sobre los programadores, 34 % de aquellos defectos fue atribuido por los investigadores a la naturaleza humana " ms bien que a dificultades tcnicas, concluyendo adems que el 71 % de todos los defectos son la responsabilidad del jefe de proyecto, el director de garanta de calidad, y la direccin(siendo todos defectos por factores humanos), esto puede generar un resultado donde los programadores objetan que la responsabilidad cabe sobre los directores

conllevando a la reduccin de sus esfuerzos conduciendo a mas errores. El tercer estudio realizado por Robert A. Zawacki y su colega Dan Couger, fue enfocado a las necesidades y caractersticas del programador encontrando algunas diferencias interesantes entre los programadores y el resto de la sociedad, ya que los programadores que tenan una alta necesidad de lograr los objetivos, tenan una baja necesidad de socializar con otras personas. La principal causa que Zawacki encontr a este problema fue la necesidad de una mejor gestin sugerido que estos cambios en el estilo: 1. Encontrar formas de mejorar la motivacin de los programadores. 2. Mejorar el intercambio de informacin entre los administradores y programadores. 3. Aadir a ms personas a la mezcla de contribucin individual con necesidades sociales ms altas (para que coincida con los planteamientos orientado a equipo, centrado en el enfoque de usuario de la dcada de 1990).

Como se observa los tres investigadores que han identificado estos problemas estn de acuerdo. Es por esto que se invita a cambiar las formas de gestin de los programadores. Y sugieren algunos detalles de cmo podra hacerse.

CAMBIOS EN LOS REQUISITOS La comunicacin usuario/desarrolladores es esencial para la obtencin de requisitos, si un proyecto parte teniendo requisitos nebulosos lo ms seguro que a lo largo del desarrollo se produzcan cambios no menores, generando problemas que pueden significar el fracaso del proyecto.

Explcitamente hemos observado conductas determinantes cuando se realizan cambios de requisitos, como por ejemplo lo comentado por Mariea Datiz, en el artculo de Lorin J. May "No se puede disear un proceso que asume requerimientos estables ", si fuera as, esto traera consigo consecuencias como lo comentado por Glass, quien nos da a conocer a travs de estudios expuestos que el estrs de los programadores tambin es causado por la captura de requisitos, el cual est en constante cambio, o simplemente lo expuesto por May donde el hecho de no tener requisitos concretos puede producir una posible desaprobacin por partes de los usuarios, ya que no representara su realidad misma.

regularizacin gubernamental y los asuntos de garanta del producto. Riesgos de Personal: personal no capacitado, falta de experiencia, problemas en la productividad. Otros Riesgos: incluye problemas con la disponibilidad de recursos, no contar con las herramientas adecuadas, tiempos de respuesta lentos, etc.

Para enfrentar los riesgos, es conveniente identificarlos y listarlos, para luego priorizarlos y analizarlos; y as, a partir de esto, elaborar un plan para la gestin de los riesgos, que contenga las acciones necesarias para reducir el impacto que stos podran causar.

MANEJO DE RIESGOS Todo proyecto que se precie de serio e importante, debe contar un plan para manejar los riesgos a los que est expuesto. En general, los riesgos son simplemente los posibles problemas. Un proyecto de software puede verse afectado por diversos riesgos (Westfall, 2001): Riesgos Tcnicos: problemas con el lenguaje, tamao del proyecto, funcionalidades, plataformas. Riesgos de Gestin: escasez en la planificacin, problemas de comunicacin, problemas de control. Riesgos de Financiamiento: incluyen el capital y el retorno de las restricciones de inversin. Riesgos Legales y de Contrato: cambio en los requisitos, la

ESTIMACIN INCORRECTA DE TIEMPO Y COSTO. La diferencia entre un proyecto exitoso y otro fallido, es que primeramente se deben tomar en cuenta (antes de comenzar el proyecto) todos aquellos riesgos que puedan presentarse durante el camino, o se vea enfrentado a un cambio. Uno de los ms frecuentes es que se hace una pobre estimacin de tiempo y costo al no hacer el procedimiento antes mencionado, esto hace que se salga del presupuesto y tiempo estimado, provocando en el usuario un posible disgusto y termine finalmente por no querer el software pedido. LIDER NO CAPACITADO La experiencia es un factor decisivo en el desarrollo de un proyecto de software, ya que permite enfocar correctamente los pasos a seguir evitando errores. Es por esto que el equipo desarrollador del proyecto debe ser dirigido por alguien que posea la

experiencia necesaria para anteponerse a los posibles escenarios adversos. Los proyectos que poseen la alta tecnologa necesitan a directores con destreza slida ", dicho comentario de Latta expuesto en el artculo de Lorin J. May, nos da a conocer la importancia de lo ya mencionado. Si un lder no tiene las capacidades de planificacin, supervisin, organizacin y habilidades de comunicacin, difcilmente se lograr el xito del proyecto.
.

caos que concluye simplemente con el fracaso.

EL IMPACTO DEL FRACASO La mayora de los expertos en informtica, concuerdan que los fallos de software se producen con frecuencia, en todos los pases, en grandes y pequeas empresas, etc. Los costos empresariales y sociales de estos fracasos contribuyen de millones de dlares cada ao. Un documento publicado por Charette dice que la gran parte de las fallas de software son previsibles y evitables, pero desafortunadamente, las organizaciones no ven la prevencin del fracaso con un asunto urgente, a pesar de que esto puede daar la reputacin de la organizacin e incluso destruirla. Uno de los grandes consumidores de software son los gobiernos. En el 2003, el Reino Unido tena ms de 100 importantes proyectos informticos en marcha, lo que totaliz en 20,3 billones de dlares. En el 2004, el gobierno de los E.E.U.U. catalog 1200 proyectos civiles de informtica, que costaron ms de 60 billones de dlares, ms otros 16 billones para programas militares. Pero no slo hay software exitoso, un ejemplo de ello es lo que pas con Sydney Water Corp., el mayor proveedor de agua en Australia, cuando se trat de introducir un sistema de informacin cliente automatizado y un sistema de facturacin en el ao 2002. Segn una investigacin realizada por el Auditor General de Australia segn menciona Charette, uno de los factores que conden el proyecto fue la mala planificacin y especificaciones, que a su vez dieron lugar a numerosas peticiones, cambios significativos y costos adicionales por demoras. Sydney Water abort el proyecto a mitad de camino, despus de gastar $ 61 millones (de dlares EE.UU. 33,2 millones).

PROBLEMAS DE COMUNICACIN Hay un viejo refrn, "nunca des nada por hecho", Duncan Haughey nos hace alusin a ste ya que es especialmente cierto para los proyectos de software. La buena comunicacin con el cliente, los usuarios y especialmente con el equipo de desarrollo es de suma importancia para lograr el xito de un proyecto. Simples preguntas como Todos entienden?, Saben exactamente lo que se esperan ellos o han asumido que saben?, Existe comunicacin efectiva con el cliente y con los dems departamentos?, estas preguntas son fundamentales para un buen desenvolvimiento , pero Qu sucede si no existe una buena comunicacin?, es aqu donde los conflictos comienzan y se empiezan a ver los posibles agentes de riesgos que conllevaran al fracaso del proyecto, como son la mala captura de requisitos, y los conflictos internos en el equipo, creando ms problemas, ya que se sumara el estrs de los programadores hablado por Glass y la sobrestimacin de tiempo y costo dicha por el Dr. Poul Dorsey, creando un

Con frecuencia, los directores de proyectos deseosos de obtener recursos, valoran en exceso lo que su proyecto har, subestimando el costo y el tiempo en que se realizar. La mayora de los proyectos de software comienzan con presupuestos que son pequeos. Cuando eso sucede, los desarrolladores tienen que compensar el dficit de alguna manera, por lo general, tratan de aumentar la productividad, y reducen el esfuerzo para tomar atajos riesgosos en la revisin y fases de prueba. Todo esto aumenta la probabilidad de error y, en ltima instancia, de fracaso. Todos los sistemas de TI son intrnsecamente frgiles. En un edificio por ejemplo, se tendran que remover cientos de ladrillos estratgicamente para que este colapse. Sin embargo, en un programa de software de 100.000 lneas, basta con slo una o dos lneas mal escrita para producir problemas graves. Charette menciona adems, que una de las funciones ms importantes del gerente de proyecto de TI, es asignar recursos a las diversas actividades. Incluso, el director del proyecto es responsable de la planificacin del proyecto, la estimacin, el control, la organizacin, la gestin de contratos, la gestin de la calidad, la gestin de riesgos, las comunicaciones y la gestin de recursos humanos. La Pobre gestin tcnica, por el contrario, puede conducir a errores tcnicos, pero por lo general se puede aislar y fijar. Sin embargo, una decisin sobre un proyecto es el mal manejo - tales como la contratacin de muy pocos programadores o escoger el tipo incorrecto de contrato esto puede causar estragos. Por ejemplo, los desarrolladores del sistema de reserva de viajes afirman que fueron abrumados en parte por el uso de un contrato fijo. Ese contrato se supone que el trabajo sera de rutina; pero lamentablemente el sistema de reserva result todo lo contrario.

Charette dice que a nivel mundial, es difcil decir cuntos proyectos de software fracasan o cunto dinero se pierde. Si se define el fracaso como el abandono total de un proyecto antes o poco despus de la entrega, y, si acepta una tasa de fracaso conservador de un 5 por ciento, se pierden millones de dlares al ao tan solo por un software mal diseado. Al igual que las piezas de electricidad, agua, transporte, y otros crticos de nuestra infraestructura, se est convirtiendo rpidamente nuestra existencia diaria. En unas pocas dcadas, una falla de TI a gran escala se convertir en algo ms que un inconveniente caro: pondr a nuestra forma de vida en riesgo. (Charette, 2005)

CONCLUSIN El desarrollo de software es un proceso complejo, en el que se ve involucrada una serie de factores. Dichos factores determinan de manera directa si el proyecto en cuestin alcanza el xito o el fracaso. Sin embargo, la gestin y evaluacin de proyectos, debe ser de la misma forma para todos; esto es, sin importar su tamao, puesto que todo proyecto se encuentra expuesto a mltiples factores que han sido ya estudiados por una gran cantidad de autores -, que pueden afectar su desarrollo. Llevando un buen control de aquello que condiciona el xito en los proyectos, es posible estar preparados para enfrentar los obstculos que se puedan presentar. Esto tambin ayudar a

que el proyecto est organizado de una forma que le brinde una mayor flexibilidad, a la hora que se le deban realizar cambios, ya sea referente a los requisitos o al diseo.

Verner, J., Sampson, J., Cerpa, N. What factors lead to software project failure? Oracle. "Why Projects Fail: Avoiding the Classic Pitfalls". (octubre, 2011). Westfall, L. Software Risk Management. (2001). Charette, R. Why Software Fails. (septiembre, 2005).

REFERENCIAS
Charette, R. Why Software Fails. (septiembre, 2005). Dorsey, P. Top 10 Reasons Why Systems Projects Fail. (2000). Glass, R. The Ups and Downs of Programmer Stress. (abril, 1997). Glass, R. The Standish Report: Does It Really Describe a Software Crisis? (agosto, 2006). Haughey, D. Why Software Projects Fail and How to Make Them Succeed. (diciembre, 2009). May, L. Major Causes of Software Project Failures. Masticola, S. A Simple Estimate of the Cost of Software Project Failures and the Breakeven Effectiveness of Project Risk Management. (2007).