Ex - Comunidad de Programadores, Nuevo Leon

Existen muchos programas para hacer el tracking de los requerimientos. Estos simplemente llevan una matriz de los requerimientos contra las reglas de negocio del proyecto y de esta forma no se pierden. Yo he leido acerca de ellas pero en lo personal nunca las he utilizado. Casi siempre si utilizas RUP el programa de facto es el Rational Requisite Pro. Existen otras herramientas donde haces el tracking vía web y así los usuarios están viendo el estatus de las reglas de negocios y ven si están implementadas, dadas de baja o por implementar. Vale la pena realizar una pequeña búsqueda por Google para checar ese punto. De todas formas sería bueno que nos dijeras como resolviste tu problema. Saludos!!!

Nose si la gente use lo de las reglas de negocio, yo aplico lo que dice el tao de la programacion:  http://www.cs.mtu.edu/~havillam/tao/libro4.html  (lectura 4.4)

Cuando al principio empecé a programar yo podía ver al programa completo en una masa. Después de tres años ya nunca más vi esa masa. En vez de eso, usé subrutinas. Pero ahora no veo nada. Todo mi ser existe en un vacío sin forma. Mi sentidos estan ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resúmen, mi programa se escribe así mismo. Es verdad, a veces hay problemas y dificultades. Las veo venir, me freno, observo silenciosamente. Entonces cambio una sola linea de código y las dificultades se desvanecen como nubes de humo

Saludos

Gracias a todos por sus respuestas.

Albertux:

Personalmente pienso que es mejor dejar reglas vacias, por que eso de estar volviendo a escribir en orden las reglas que si se van a utilizar quita tiempo ademas como lo mencionas de "Por que ha cambiado la regla #481"

Simplemente se le dice al cliente que se tenian otras reglas previstas que no se van a usar y si surgen nuevas reglas pues puedes usar esos huecos.

Concuerdo totalmente. Pues es mas facil explicar que una regla ya no se necesita (y por lo tanto hay un vacio en la numeracion) que decirle al cliente que su regla favorita cambio de sitio. Aunque en la practica se tenga que recurrir a cualquiera de las dos soluciones, segun el proyecto.

Cuando al principio empecé a programar yo podía ver al programa completo en una masa. Después de tres años ya nunca más vi esa masa. En vez de eso, usé subrutinas. Pero ahora no veo nada. Todo mi ser existe en un vacío sin forma. Mi sentidos estan ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resúmen, mi programa se escribe así mismo. Es verdad, a veces hay problemas y dificultades. Las veo venir, me freno, observo silenciosamente. Entonces cambio una sola linea de código y las dificultades se desvanecen como nubes de humo

Jajaja. Entiendo en parte lo que dices. Los mejores programadores tienen un talento natural, dificil de conjugar con muchas metodologias. Pero estoy seguro que pueden encontrar alguna manera metódica de proceder y todas sus habilidades como programador se veran potenciadas de tal manera que su productividad va a ser mucho mayor.

wiseman:

Existen muchos programas para hacer el tracking de los requerimientos. Estos simplemente llevan una matriz de los requerimientos contra las reglas de negocio del proyecto y de esta forma no se pierden. Yo he leido acerca de ellas pero en lo personal nunca las he utilizado. Casi siempre si utilizas RUP el programa de facto es el Rational Requisite Pro. Existen otras herramientas donde haces el tracking vía web y así los usuarios están viendo el estatus de las reglas de negocios y ven si están implementadas, dadas de baja o por implementar. Vale la pena realizar una pequeña búsqueda por Google para checar ese punto. De todas formas sería bueno que nos dijeras como resolviste tu problema. Saludos!!!

Aunque utilizo Requisite Pro, no me siento todavia del todo suelto con esa herramienta. De todas maneras ayudaria a tapar los vacios en la codificacion en el caso que quisieramos hacerlo. Toda la documentacion involucrada se ve actualizada, pero no podemos evitar que el cliente siga conservando una copia antigua a la cual ha estudiado con tezon (algo muy raro por cierto). Por este motivo debemos ver cada caso por separado. Con respecto al proyecto que fue motivo de mi consulta, decidimos dejar los huecos en la codificacion, lo cual ha sido entendido por el cliente. La clave ha sido conversarlo con el.

Jarg:
Jajaja. Es en serio!
A veces las metodologias parecen exagerar, pero en este caso, las reglas de negocio ayudan a que nuestro proyecto "no olvide" lo que debemos considerar desde un inicio. Es muy probable que mas adelante esas reglas se vean traducidas en formulas de calculo: "en esta empresa el stock se calcula asi" o en sentencias de desicion "si han pasado mas de 40 dias, anular el pedido". Asi garantizamos en parte que estamos alineados con lo que nuestro objeto de estudio realiza.

Gracias a todos, hasta pronto

La verdad yo creo que todas esas metodologías suckean, solo sirven para tres cosas:

1) Fastidiar a los developers
2) Darle chamba a code monkeys que terminan siendo lideres de proyecto y cuidando que se haga esa doc.
3) Hacerle sentir a tu cliente que si estas haciendo algo.

Pero algo en que Edubezter1 tiene razon es que aun los que no las usamos hemos desarrollado una manera metódica de proceder y para ser sinceros creo que todas esas metodologías tienen algunas buenas ideas que se pueden adoptar y hacernos mas productivos.

Por ejemplo hace tiempo empece a leer sobre RUP y que weba eso de hacer un glosario de términos, pero si me ha servido hacer un documento de vision para siempre tener de una manera clara de que se trata el proyecto e incluso establecer el alcance del mismo con el cliente; también que weba describir cada caso de uso, pero si me ha servido al menos identificarlos, bosquejarlos y apuntar por ahí las consideraciones que se deban hacer.

Aun asi creo que amarrarte a una metodología hace que termines preocupándote mas por seguirla que por que tu softwaresito funcione bien. Y no creo que una cosa te lleve a la otra. Y a fin de cuentas esta demostrado que para desarrollar software exitoso no es necesario aplicar ninguna de esas metodologías, la prueba esta en todo el software libre de calidad que existe.

Yo en lo particular he trabajado sin metodologías (sobre todo al principio de mi carrera). Algunos proyectos desarrollados se completaron y otros definitivamente se extendieron, ya sea por no manejar los requerimientos correctos del cliente, entender mal los requerimientos o trabajar en las partes [divertidas de desarrollar-poco uso del negocio].

En lo particular veo a las metodologías sólo como una receta. Algunas veces la receta te dice como hacer la suculenta comida pero si eres sólo un ayudante del chef y no sabes nada acerca de comidas y salsas aunque uses la receta acabarás con un espantoso platillo. El otro lado de la moneda es cuando eres el chef de la cocina. Usas la receta pero sabes que siempre puedes precindir de ella. Sabes que sólo es una guía y que tu puedes saltarte pasos o agregarle más de acuerdo a tus necesidades específicas.

Ultimamente he trabajado bajo la metodología RUP. En particular mis clientes se sienten muy satisfechos en ver que se está haciendo el software que ellos necesitan. Cuando les muestro algunas pantallas prototipos o les muestro el documento de Visión sienten que son entendidos y que se está trabajando en el mismo canal que ellos. En la parte de nuestro lado actualmente sólo somos dos personas (aquí en PedrazaSoftware), y tener una especificación de requerimientos de software es de mucha ayuda. Además de tener un calendario para evaluar el avance.

Yo digo que las metodologías sirven cuando hay muchas personas involuradas en el proyecto. Si solamente en el equipo de desarrollo hay 3 personas y el proyecto se presenta a un sólo stakeholder no veo la necesidad de crear todos los artefactos que se utilizan en RUP. Sin embargo, cuando estamos hablando de software empresarial, cuando hay mucha gente involucrada en el proyecto, cuando hay outsourcing, o las reglas de negocio cambian constantemente para hacerle frente al mercado AH� S� CREO que DEBE utilizarse una metodología sólida. Si no se sigue la receta simplemente se terminará en un mar de caos y el proyecto fracasará eventualmente.

Espero su retroalimentación y su punto de vista y sobre todo sus experiencias en proyecto pasados. Un saludo a todos!!!

Pues el jarg tiene razón en eso de control sobre los "tecleadores de código" que son controlados por la aplicacion de metodologías como rup, o en cualquier otra donde existe un project manager no. Porque generalmente el project manager es el que dice que hacer, aunque el ambiente de trabajo haga alucinar al de la mera chinga que tiene cierta libertad. Pero bueno, eso solo en las metodologías que se rigen por algo así como la centralización.