¿Estás apunto de iniciar un proyecto de desarrollo de software?

Y ¿no cuentas con una metodología CMMi, moprosoft, ISO, etc, que te ayude a lograrlo?. ¿Estás preocupado porque tu proyecto de desarrollo arroje resultados positivos en términos financieros?¿Tu meta es entregar un producto en forma, tiempo y sobre todo con calidad que tu cliente esta esperando?
Te ofrezco estos útiles consejos que te ayudarán como base para lograr el éxito en tus próximos proyectos de desarrollo, anteponiendo la calidad del mismo ante cualquier otra cosa.
Como punto de arranque, deberás de realizar un plan de trabajo donde especifiques (dependiendo del ciclo de vida que hayas elegido) todas las actividades de las que se compone tu proyecto; asígnalas a los recursos que las ejecutarán, determina el esfuerzo que tendrá cada una de las actividades y sobre todo dale el seguimiento periódico de acuerdo al tamaño de tu proyecto, después:

1. Realiza y presenta a tu cliente un documento formal de inicio de proyecto “Kick Off” donde en una forma clara expongas los siguientes puntos:

• Los objetivos y el alcance del proyecto
• Presentes a:
  • Los integrantes que ejecutarán el proyecto
  • Los stakeholders involucrados que estarán apoyando la iniciativa de desarrollo (Champions internos)
• Hitos importantes de cada fase del proyecto

NOTA Durante esta presentación, dale a tu cliente la oportunidad de aclarar todas las dudas y asegúrate que pueda revisar su agenda de acuerdo a los hitos que le hayas presentado.

2. Realiza entrevistas para la captación de los requerimientos.

Es muy importante que en el transcurso de las entrevistas mantengas una escucha activa y en la medida que puedas usa el parafraseo, pues lo anterior le dará confianza a tu cliente de que estas entendiendo y analizando las necesidades que se plasmarán en la ingeniería de software que le ofrecerás como solución. Para las entrevistas puedes auxiliarte de:

• Grabadoras
• Story Boards
• Micro prototipos
• Diagramas UML

3. Una vez realizadas las entrevistas, es indispensable que te auxilies de una buena minuta

Donde especifiques de una manera clara lo revisado en la entrevista y se la hagas llegar a tu cliente para que estén de acuerdo con lo que allí se especifica. La minuta cuando menos se recomienda que tenga los siguientes puntos:

• Participantes (nombre, correo y cargo)
• Lugar y fecha de la reunión (hora y duración)
• Objetivos de la reunión
• Contenido
• Pendientes por parte del cliente
• Pendientes por parte del proveedor (consultora it, terceras partes, etc.)

4. Ya con todas las entrevistas y minutas en mano, pasaremos a realizar el análisis de sistemas.

Para realizar esto, un buen punto de partida es generar un documento de Especificación de Requerimientos de Software (ERS). Este documento debe de ser lo suficientemente claro y entendible sin llegar a tener tecnicismos que puedan confundir al cliente. La ERS deberá de ser el punto de partida para realizar la “Especificación de Casos de Uso” y posteriormente continuar con el Diseño y Construcción.

5. Por mas entendible o “digeribles” que resulte la ERS, genera unprototipo que refleje como sería el sistema.

Es decir, las pantallas (menú, colores, botones, cajas de texto, etc) que cumplirán con los requerimientos solicitados. Este prototipo no tiene que ser funcional para esta fase pues no es necesario que se ejecuten acciones. Pero si necesita mostrar como el cliente verá las pantallas que estará utilizando. Para realizar el prototipo puedes auxiliarte de (fire works, photo shop, power point, ilustrator, corel draw, adobe catalyst, expression design, etc.), tú serás el mejor juez de acuerdo a las capacidades que tengas a la mano.

6. Teniendo la ERS, los casos de uso y el prototipo autorizados por tu cliente, has logrado tener las bases seguras para pasar al desarrollo de los requerimientos.

Estos, serán de gran ayuda para tus ingenieros de software pues serán la guía para que se mantengan dentro de los límites de interacción del sistema/usuario y así lograr que se enfoquen en lo que se debe de desarrollar. La idea aquí es no dejar “huecos” o “suposiciones” de lo que deben de programar.