La técnica de la cascada se divide en etapas. Los líderes de proyecto deben incluir estimaciones de la cantidad de tiempo (y por lo tanto dinero) requerido para cada paso en sus planes de proyecto. Hemos establecido previamente que las estimaciones de tiempo son intrínsecamente problemáticas para cualquier proyecto, mucho más cuando deben establecerse al principio de la vida del proyecto. Simplemente no es factible para proyectos de software. Considere la posibilidad de que se compile una lista de capacidades cualitativamente aceptable durante la fase de definición. En principio, esto debería permitir al equipo del proyecto dar una estimación realista del tiempo necesario para desarrollar cada característica. Sin embargo, en realidad, existen demasiadas incertidumbres para proporcionar una aproximación justa:
Sin embargo, en realidad, existen demasiadas incertidumbres para proporcionar una aproximación justa:
- Con frecuencia, después de que se desarrolla una función, se descubre que el cliente no la necesita. Por lo tanto, las horas dedicadas a desarrollar esta función pueden considerarse en vano.
- Durante el transcurso del proyecto, los requisitos pueden cambiar.
- ¿Debería proporcionarse la capacidad a un costo elevado oa un costo reducido? Hay muchas técnicas de implementación y realización.
- ¿Cómo se diseñará técnicamente la funcionalidad? El diseño influye en gran medida en la cantidad de tiempo necesario para crearlo.
- ¿Hasta qué punto el funcionamiento debe ser de alto nivel? Por ejemplo, ¿una aplicación web debería ser totalmente accesible en todo momento o debería dejarse inactiva durante algunas horas al año?
- El tiempo necesario para detectar y corregir problemas de software varía de minutos a semanas.
- ¿Cuánto tiempo tardará el nuevo software en instalarse e integrarse con los sistemas actuales del cliente?
- La falta de información sobre posibles soluciones afecta aún más las estimaciones de tiempo. Además, calcular el tiempo necesario para adquirir la experiencia necesaria es un desafío.
La lista anterior demuestra que una variedad de variables pueden influir en el tiempo necesario para desarrollar una nueva pieza de software. Las estimaciones del tiempo necesario para desarrollar una función al inicio de un proyecto suelen ser cuatro veces más bajas o cuatro veces más altas. Esto implica que el tiempo requerido puede ser cuatro veces más o cuatro veces menor que una estimación errónea. A medida que se desarrolla el proyecto, estas estimaciones se vuelven más precisas. Después de completar el diseño funcional, el margen se reduce al 25% demasiado o demasiado poco. Solo cuando se ha desarrollado la característica es posible dar una estimación con un alto grado de confianza.
Riesgos de software #
Software de gestión de proyectos nunca estará completamente libre de errores. Incluso para programas conocidos que se utilizan ampliamente (por ejemplo, Word, Excel, Explorer, OS X, PHP y Flash), Internet tiene listas de fallas conocidas. De forma regular, se ponen a disposición en el mercado nuevas versiones que corrigen errores de software. Los clientes a veces exigen que el software esté libre de errores. En realidad, sin embargo, tal objetivo haría inviable completar una pieza de software. Además, las fallas de software a menudo no son inherentes al programa.
Se utilizó Flash para crear un juego instructivo. El cliente acordó obtener el juego como un archivo e instalarlo en su propio servidor. Durante el transcurso del proyecto, el cliente solicitó que se agregara una característica de puntaje alto al juego para mejorar la competitividad del jugador. Esto necesitaría algún código de secuencia de comandos PHP. Los desarrolladores del juego desarrollaron y probaron el código del script en su propio servidor con Linux. Fue un exito. El cliente recibió el juego y el código del script. Sin embargo, el cliente usó un servidor de Windows y, por alguna razón, el script dejó de funcionar correctamente. No se retuvieron las mejores calificaciones. En última instancia, el programador necesita una semana para solucionar el problema. Resulta que PHP y Windows no siempre funcionan bien juntos. ¡El guión en su totalidad no tuvo errores en absoluto! Pudo hacerlo funcionar mediante el uso de un truco, y todos estaban contentos, pero ¿quién debería pagar esa semana adicional de trabajo?
Otro proyecto de desarrollo de software también incluyó la creación de aplicaciones de instrucción. El problema era que el software funcionaba muy bien para los desarrolladores, pero no para el cliente. Después de agotar todas las demás posibilidades, el programador decidió visitar al cliente. Resultó que el cliente estaba ejecutando una máquina Pentium III de principios de la década de 1990. La lentitud de la computadora contribuyó al bajo rendimiento del software. Además, los programadores probaron el software en un Pentium III y funcionó bien. Un examen más detallado mostró que la PC del cliente funcionaba lentamente debido a una infección de virus y software espía.
Gestión de incertidumbres en el desarrollo de proyectos #
La incertidumbre mostrada por los casos anteriores complica el proceso de desarrollar planes de proyecto . Además, complica las negociaciones entre las partes. Alguien debe asumir los riesgos asociados con el trabajo adicional que se debe realizar. Si el pago se realiza por horas, el cliente corre con todos los riesgos. Cuando se acuerda una tarifa fija (como es el caso de los proyectos financiados con subvenciones), el desarrollador de software asume el riesgo. Cuando hay más de dos personas involucradas, la situación se vuelve más compleja. En este escenario, ¿quién debería asumir el costo de las horas adicionales trabajadas en el proyecto?
A menudo surgen disputas sobre quién debe rendir cuentas por los retrasos. A menudo, es difícil identificar a la persona responsable. Es bastante concebible que ninguna de las partes involucradas tenga la culpa, ya que el ‘retraso’ fue causado por una estimación inicial incorrecta del número de horas requeridas. Las horas excesivas de los proyectos y la cuestión de quién debe pagar son causas comunes de controversia en la industria de la tecnología de la información.
