MCPD 70-547: Traducir especificaciones para el desarrollador

El Jefe dice: “Y cuando esta la aplicación funcionando, cuando la vamos a poder usar?”. Y tu dices: “Estamos terminando las especificaciones de la Aplicación”, y te replican: “Lo mismo me dijiste hace dos meses”.

Vamos hablar de proyectos chicos que se deben terminar en menos de un año, con poco recurso humano. Una de las cosas por las cuales te van a contratar para hacer una aplicación es por que la empresa ha visto que ya no pueden más sin un sistema, o por que son precavidos y dentro de su plan estratégico de este año esta automatizar sus procesos usando alguna aplicación, o por que necesitan urgente una aplicación, ya que tiene una aplicación con algunos muertitos que eliminar. Sería ideal trabajar sin presión, pero normalmente necesitan las aplicaciones en dos modos: Urgentes, o SuperExtremadamenteUrgentes.

Estimación es algo que no me atrevería hacer aún, por que, aún el mundo no esta muy de acuerdo en esto (Ref1 y Ref2). Pero hombre, alguna respuesta tienes que dar. A mi parecer lo que se puede hacer es tomar el modelo de Scrum, y tener releases de la aplicación cada 3 meses. Con esto podrías tener hecha la aplicación en la versión 3.2 o 3.3, dependiendo. Y hay algo muy importante de aplicar esto, es que el Cliente va poder recuperar su inversión, si no hay mucho muertito en la aplicación, a fines del tercer mes. De alguna manera va sentir que lo que esta pagando esta dando resultados. Y todos contentos, el Cliente puede empezar a usar la aplicación, y nosotros nos liberamos de presión. Pero si hemos planificado hacer toda la especificación al inicio, y nos tardamos mas de dos meses, vamos a tener tal presión que puede hacer tambalear al proyecto. Con respecto a este tipo de proyectos donde se necesita un desarrollo rápido, usar un enfoque ágil es lo mas adecuado. Ya cada uno de acuerdo a su modelo de negocio, tendría que determinar que features salen en el primero release, y cuales no.

Este capítulo habla sobre las especificaciones, pero comente al inicio de esta serie, a parte de solo hablar de los temas, voy a dejar un poco de mi poca experiencia y como he estado implementándolos, bien o mal, pero implementándolos :). Y en cuanto a las especificaciones hablan de como crear un modelo lógico usando ORM, también habla sobre crear nuestra aplicación en Capas, que por cierto a mi parecer si se hace bien, hace muy fácil el mantenimiento de una aplicación, a parte que le da mucho orden para revisarla. El otro día vi una aplicación sin capas, que para que les cuento, por eso creo que me apure en tener un release, para no tener que darle mantenimiento a esa aplicación :D, pero ese es otro tema. Otra especificación son los modelos físicos de una aplicación: Crear un diagrama de componentes, diagrama de clases, de secuencia, y de actividades. Como he comentado en otros post, creo que el uso de diagramas debería ser de acuerdo al requerimiento y su complejidad del mismo. Por ejemplo, si estas contra el tiempo y tienes 4 mantenimientos de tablas estilo tipo o categoría, hacer todos los diagramas de UML por cada uno, donde sólo cambia el nombre del objeto y el resto es CRUD, como que no lo veo muy productivo, en todo caso se podría hacer uno genérico.

Ojo los requerimientos tienes que hacerlo si o sí, tampoco vas codificar desde el inicio del proyecto sin ningún requerimiento. Pero lo más importante que hacer un requerimiento, es que el Cliente apruebe estos requerimientos, así cuando se tenga el primer release, no habrá sorpresitas en lo que se dijo o no se dijo, y no tendrás que hacer todo dos veces :).

Saludos,

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *