Existen mucho métodos, metodologías, técnicas que nos sirven para mediar, diferenciar y estimar el tamaño de software, también mucho se ha escrito al respecto; en Google, si busca por estimación tamaño de software, encuentra mucha información de diferentes paginas, sitios y blogs.
Pero, cumplir una estimación, hay está el problema y mas cuando se ha realizado únicamente por cumplir una etapa de la Ingeniería de software. Y veces no se dimensiona el problema, o no se estudia detenidamente y al detalle requerimientos o cuando más delicado aun no hay requerimientos formales ni detallados.
Difícilmente se puede dar una estimación de un proyecto de software. La experiencia aunque es muy útil en estos casos, no debería de ser la única herramienta para calcular las estimaciones.
Después de que compensamos diseñar, programar, desarrollar, etc, no damos cuenta de que la programación se puede tardar un poco mas de lo presupuestado, eso pasa muy a menudo cuando el equipo de desarrolladores lo conforma una sola persona. Aquí empiezan los problemas y las disculpas. Qué hacer? Y se ha ya cuantificado el proyecto y ya se tiene la cifra a cobrar al cliente. Qué hacer? Es claro que se ha cometido un error. Un proyecto que posiblemente se estimo como fácil, pequeño, rápido de hacer, se vuelve un proyecto grande. Si se es trabajador independiente se va tener problemas con el cliente, y si se forma parte o es el programador de una empresa y le asignaros desarrollar determinado producto, se va a tener problemas con el jefe.
Pongamos otro esenario, que pasa cuando despues de haber empesado el desarrollo, el cliente cambia o agrega requerimientos, Que hacer?
Hay un documento publicado en el sitio http://www.mitecnologico.com/ .que me parece muy interesante entre los muchos que se encuentran: Actividades Seguimiento Proyecto y una presnetacion de una charla del ingeniero Guillermo caro Murillo; El error humano y los proyectos de software
Así dentro del rol no se es director de proyectos, si se monitores contantemente el proyecto y se encuentra un técnica para hacerlo, las desviaciones se pueden informar y justificar a tiempo.
Pero, cumplir una estimación, hay está el problema y mas cuando se ha realizado únicamente por cumplir una etapa de la Ingeniería de software. Y veces no se dimensiona el problema, o no se estudia detenidamente y al detalle requerimientos o cuando más delicado aun no hay requerimientos formales ni detallados.
Difícilmente se puede dar una estimación de un proyecto de software. La experiencia aunque es muy útil en estos casos, no debería de ser la única herramienta para calcular las estimaciones.
Después de que compensamos diseñar, programar, desarrollar, etc, no damos cuenta de que la programación se puede tardar un poco mas de lo presupuestado, eso pasa muy a menudo cuando el equipo de desarrolladores lo conforma una sola persona. Aquí empiezan los problemas y las disculpas. Qué hacer? Y se ha ya cuantificado el proyecto y ya se tiene la cifra a cobrar al cliente. Qué hacer? Es claro que se ha cometido un error. Un proyecto que posiblemente se estimo como fácil, pequeño, rápido de hacer, se vuelve un proyecto grande. Si se es trabajador independiente se va tener problemas con el cliente, y si se forma parte o es el programador de una empresa y le asignaros desarrollar determinado producto, se va a tener problemas con el jefe.
Pongamos otro esenario, que pasa cuando despues de haber empesado el desarrollo, el cliente cambia o agrega requerimientos, Que hacer?
Hay un documento publicado en el sitio http://www.mitecnologico.com/ .que me parece muy interesante entre los muchos que se encuentran: Actividades Seguimiento Proyecto y una presnetacion de una charla del ingeniero Guillermo caro Murillo; El error humano y los proyectos de software
Así dentro del rol no se es director de proyectos, si se monitores contantemente el proyecto y se encuentra un técnica para hacerlo, las desviaciones se pueden informar y justificar a tiempo.
Proyectos pequeños, Proyectos grandes
No hay comentarios.:
Publicar un comentario