Buenas a todos nuestros seguidores. Como viene siendo habitual en esta entrada explicaremos nuestra experiencia que hemos adquirido después de desarrollar el documento de Estudio de Viabilidad del Sistema o EVS, que forma parte de la metodología que estamos siguiendo: Métrica 3. Este documento trata de dar un primer paso en la adquisición de requisitos y plantear qué solución se seguirá entre todas las alternativas posibles.
Puede resultar extraño el dar alternativas de solución antes de realizar la parte de análisis, pero lo cierto es que antes de entrar de lleno en la parte de análisis, normalmente habrá que dar un presupuesto al cliente y este documento busca una primera aproximación al coste del proyecto. Lo normal sería realizarlo al inicio del proyecto, antes de la oferta. Sin embargo, nuestro profesor nos indicó que lo primero que entregamos es la oferta porque así ocurre en muchos casos reales, en los que primero se presenta la oferta rápidamente y sin tiempo a nada más y luego se ve cómo justificar lo que se puso en la oferta.
Por lo tanto, diferenciaremos dos partes claras: la primera es la identificación requisitos para el software y la segunda el estudio de las alternativas a la solución. En este post, solamente expondremos nuestra experiencia en la parte de identificación de requisitos, para no realizar un post demasiado extenso. Otro día comentaremos el estudio de alternativas de solución.
En el inicio del proceso de captación de requisitos software hemos aprendido lo difícil que puede llegar a ser la identificación de los primeros requisitos. Esto se debe primero a que no estamos en una situación real y no se dispone de un cliente al cual se le puedan realizar preguntas; y después, es difícil responder a la siguiente pregunta: ¿qué problema quiere el cliente resolver? ¿que restricciones impone?
Luego la pregunta del millón es: ¿qué hemos hecho para solucionar este problema? Para enfrentarnos a él, nos hemos apoyado en dos puntos: la experiencia que disponemos en este tipo de documentos pues ya lo hemos realizado en varias asignaturas a lo largo de la carrera y la verdad es que se nota respecto a otros documentos de los cuales no disponíamos ninguna experiencia previa, como por ejemplo gestión de calidad y de configuración. Y el segundo punto, el estudio de la competencia, en nuestro caso como estamos desarrollando un sistema de marcadores sociales, qué mejor que fijarse de las capacidades y restricciones que ofrece del.icio.us para realizar un trabajo de ingeniería inversa y obtener los requisitos para nuestro proyecto.
En este punto, cometimos un error en nuestro trabajo, ya que no incluimos de forma explicita este estudio de la competencia en el documento debido a que la metodología no lo indicaba. Por ello, para que no caigáis en el mismo error, conviene que recordemos que la metodología que se sigue a lo largo del proyecto da una indicación de los pasos a seguir, pero no debe seguirse al pie de la letra. Si hay algo interesante que poner en un documento, aunque no lo indique la metodología, debe incluirse en el trabajo y, al revés, si algo de lo indicado por la metodología no tiene sentido en un proyecto en concreto, no debe realizarse.
En resumen, la conclusión principal que hemos obtenido ha sido la importancia que tiene la detección de todas las fuentes de requisitos, tanto de los usuarios participantes que puedan aportar requisitos como de otras fuentes (trabajos similares, competencia, etc.). Además, será importante poder extraer toda la información de dichas fuentes. Para esto, lograr una relación perfectamente coordinada y totalmente colaborativa por ambas partes con los usuarios participantes y formalizar en la medida de lo posible el resto de fuentes, resultará vital para obtener nuestro objetivo, es decir, un conjunto de requisitos iniciales robustos, con calidad y que reduzcan (¡no eliminen!, ya que esto es imposible) futuras modificaciones debido a las ambigüedades y vacíos que caracterizan este proceso en la ingeniería del software. Para terminar este punto, nos ha parecido curiosa la cita de Pressman sobre este tipo de problemas: "Quién hace una pregunta es un tonto por cinco minutos; quién no la hace es tonto para siempre." Proverbio chino.
Pues esto ha sido todo compañeros, en los próximos días publicaremos más entrevistas, más comentarios, más opiniones, entradas cómicas y... ¡muchas más cosas!. Como vereis, intentamos dedicar cierto tiempo al blog a pesar del trabajo que tenemos en la universidad porque nos sentimos a gusto con esta idea y pensamos que es enriquecedora tanto para vosotros como para nosotros. Un saludo y hasta las próximas entradas.
Puede resultar extraño el dar alternativas de solución antes de realizar la parte de análisis, pero lo cierto es que antes de entrar de lleno en la parte de análisis, normalmente habrá que dar un presupuesto al cliente y este documento busca una primera aproximación al coste del proyecto. Lo normal sería realizarlo al inicio del proyecto, antes de la oferta. Sin embargo, nuestro profesor nos indicó que lo primero que entregamos es la oferta porque así ocurre en muchos casos reales, en los que primero se presenta la oferta rápidamente y sin tiempo a nada más y luego se ve cómo justificar lo que se puso en la oferta.
Por lo tanto, diferenciaremos dos partes claras: la primera es la identificación requisitos para el software y la segunda el estudio de las alternativas a la solución. En este post, solamente expondremos nuestra experiencia en la parte de identificación de requisitos, para no realizar un post demasiado extenso. Otro día comentaremos el estudio de alternativas de solución.
En el inicio del proceso de captación de requisitos software hemos aprendido lo difícil que puede llegar a ser la identificación de los primeros requisitos. Esto se debe primero a que no estamos en una situación real y no se dispone de un cliente al cual se le puedan realizar preguntas; y después, es difícil responder a la siguiente pregunta: ¿qué problema quiere el cliente resolver? ¿que restricciones impone?
Luego la pregunta del millón es: ¿qué hemos hecho para solucionar este problema? Para enfrentarnos a él, nos hemos apoyado en dos puntos: la experiencia que disponemos en este tipo de documentos pues ya lo hemos realizado en varias asignaturas a lo largo de la carrera y la verdad es que se nota respecto a otros documentos de los cuales no disponíamos ninguna experiencia previa, como por ejemplo gestión de calidad y de configuración. Y el segundo punto, el estudio de la competencia, en nuestro caso como estamos desarrollando un sistema de marcadores sociales, qué mejor que fijarse de las capacidades y restricciones que ofrece del.icio.us para realizar un trabajo de ingeniería inversa y obtener los requisitos para nuestro proyecto.
En este punto, cometimos un error en nuestro trabajo, ya que no incluimos de forma explicita este estudio de la competencia en el documento debido a que la metodología no lo indicaba. Por ello, para que no caigáis en el mismo error, conviene que recordemos que la metodología que se sigue a lo largo del proyecto da una indicación de los pasos a seguir, pero no debe seguirse al pie de la letra. Si hay algo interesante que poner en un documento, aunque no lo indique la metodología, debe incluirse en el trabajo y, al revés, si algo de lo indicado por la metodología no tiene sentido en un proyecto en concreto, no debe realizarse.
En resumen, la conclusión principal que hemos obtenido ha sido la importancia que tiene la detección de todas las fuentes de requisitos, tanto de los usuarios participantes que puedan aportar requisitos como de otras fuentes (trabajos similares, competencia, etc.). Además, será importante poder extraer toda la información de dichas fuentes. Para esto, lograr una relación perfectamente coordinada y totalmente colaborativa por ambas partes con los usuarios participantes y formalizar en la medida de lo posible el resto de fuentes, resultará vital para obtener nuestro objetivo, es decir, un conjunto de requisitos iniciales robustos, con calidad y que reduzcan (¡no eliminen!, ya que esto es imposible) futuras modificaciones debido a las ambigüedades y vacíos que caracterizan este proceso en la ingeniería del software. Para terminar este punto, nos ha parecido curiosa la cita de Pressman sobre este tipo de problemas: "Quién hace una pregunta es un tonto por cinco minutos; quién no la hace es tonto para siempre." Proverbio chino.
Pues esto ha sido todo compañeros, en los próximos días publicaremos más entrevistas, más comentarios, más opiniones, entradas cómicas y... ¡muchas más cosas!. Como vereis, intentamos dedicar cierto tiempo al blog a pesar del trabajo que tenemos en la universidad porque nos sentimos a gusto con esta idea y pensamos que es enriquecedora tanto para vosotros como para nosotros. Un saludo y hasta las próximas entradas.
No hay comentarios:
Publicar un comentario