Si el gremio de los desarrolladores de software no esta de acuedo respecto a cuales son las prioridades, enfoques o que debe hacer un individuo en circunstancias especificas para cumplir con sus labores (
Debates within software engineering) entonces ¿ como se puede diferenciar un proyecto con una mala ejecucion del que a tenido una buena ? ¿ Como 2 respetados autores de textos sobre el desarrollo de software como
Ed Yourdon y
Tom de Marco ofrecen sus servicios como expertos tecnicos en litigios sobre contratos de software y sobre que parámetros ellos definen si un contratista dejo de cumplir o no con sus obligaciones ?
¿ Sera que es tal el estado de la ingeniería de software como área del conocimiento que solo podemos decidir si un proyecto es exitoso o no, por criterios subjetivos ?
O acaso los criterios deben ser exageradamente generales y muy cercanos a la sola revisión sobre si se cumplieron las estimaciones iniciales de:
- Presupuesto
- Tiempo de Desarrollo
- Funcionalidad (Cantidad de cosas hechas)
Todo esto es lo que se me pasa por la cabeza cuando veo a ZettaByte diciendo en twitter:
Necesito documentacion sobre malas practicas de implementacion de proyectos y desarrollo de software por que mirando las cosas desde alguna de las
múltiples y contradictorias metodologías de desarrollo de software uno podría decir que falta o sobra determinado elemento para cumplir con ella, pero difícilmente tendría unas bases teóricas fuertes que sean reconocidas a lo largo de todo el gremio como para decir que el incumplimiento de esa practicas o de varias de ellas hace que el proyecto sea un fracaso.
Personalmente me quedo sin ideas pero el motivo detrás de esta entrada es esperar a que los lectores me den las suyas y/o repuestas contundentes a como hacer estas evaluaciones pues pese a llevar varios años en esto me declaro en la misma inquietud que
ZettaByte
Entradas
1 comentario:
Este tema puede llegar a ser tan complejo; en la vida real llega uno a ver unos casos que realmente sirven hasta para escribir un libro, lo mas curioso ,, es que alguno de esos proyectos logran que el usuario final medianamente haga algo, pero no logran identificar la cantidad de tiempos muertos en diferentes áreas por un software deficiente.
Por estos días hasta se me ocurrió que seria buena idea realizar una especie de conferencias donde todos expongan sus experiencias en este tema, estoy seguro que serán muchas, y de todos esos casos se sacarían buenas conclusiones.
En ultimas el problema no es tanto del Ing. Desarrollador o el Ing de proyectos, todo esta enfocado con la presión que ejercen las empresas para terminar un proyecto sea como sea , para de esta manera poder arrancar otros, todo esto conlleva a que se pierda la metodología y a que nosotros siempre terminemos lo mas rápidamente posible estos proyectos sin medir las consecuencias del resultado final.
Algo bueno que he aprendido de todo esto, es que uno como Ing. debe imponerse frente a alguna mala idea o alguna mala solución o alguna mala metodología, de no hacerlo , terminaremos cayendo en el mismo problema siempre.
Publicar un comentario