La imagen superior puede resultar divertida para algunos, y para otros... una realidad. Mi experiencia en "Mega Proyectos" no es muy amplia, he tenido el privilegio de trabajar en proyectos de gran envergadura y que por lo general, la puesta en marcha (implementación) de estos, cuesta más que el desarrollo en sí.
Análisis y especificación de requerimientos
Lo esencial es poder entender lo que realmente quiere el cliente, o en este caso, el usuario final. Para esto se pueden aplicar diferentes técnicas o métodos de captura de información, como por ejemplo, los formularios, encuestas y/o entrevistas.
Para realizar bien el desarrollo de software es esencial realizar una especificación completa de los requerimientos de los mismos. Independientemente de lo bien diseñado o codificado que esté, un programa pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.
...
El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. Puesto que el contenido de comunicación es muy alto, abundan los cambios por mala interpretación o falta de información. El dilema con el que se enfrenta un ingeniero de software puede ser comprendido repitiendo la sentencia de un cliente anónimo: "Sé que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creíste oír sea lo que yo quise decir".
En la práctica, esta etapa (análisis y especificación de requerimientos) tiene que tener una connotación elevada dentro del desarrollo de un sistema, porque no falta el cambio a última hora, o mejor dicho, la típica respuesta...
"bueno sí, se parece a lo que yo pedí en un comienzo, pero le falta esto !!!".
1 comentario:
Buena tu referencia a los proyecto de SW amor ,yo tambien te aportare con mi granito de arena.
Para todos los cambios q el usuario requiera ,a veces un buena metodología de desarrollo de sw puede ayudar a eso ya q una
buena eleccion de ella hace q en sí el proyecto no esté ni mal enfocado ni con malos entendidos.
HAy metodologias que son para empresas con harto personal y para empresas cn poco personal.
Cuando se sabe q el proyecto
puede tener muchos cambios,escoger un modelo por fases (a,d,i) y pruebas...puede resultar largo pero es lo mas conveniente para
proyectos de esas envergaduras.
Como por ejemplo esta RUP,que esta dividido en 4 fases y es incremental e iterativo,pero es una metodologia para graaandes proyectos y mucho personal.Como tb existen las metodologias àgiles,que cada una se adapta al tipo de proyecto y tipo de personal.
Lo otro, hay que tener en cuenta que el cliente y usuario final no neceariamente es la misma persona...el cliente puede ser un representante de la Empresa "xxx" y el usuario
que interactúa con el sistema ..ése es el usuario final.
......
--> Besitos para ti mi cielo..muaackk!!
Publicar un comentario