Metodología

El desarrollo de un sistema de información es un proceso complejo, dada la alta probabilidad de que al menos alguna de las tres variables principales que lo caracterizan, que son alcance, tiempo, y recursos, se salga de control.

En el mercado es común encontrar distintas metodologías y procesos de desarrollo que intentan ser la solución ideal para la construcción de sistemas. La realidad es que cada proyecto está sujeto a distintas fuerzas de negocios que obligan a tomar una actitud flexible y practica durante su desarrollo. La estrategia que seguimos en PCtodo se basa en una serie de planteamientos prácticos, que nos mantienen en estrecha comunicación con nuestros clientes, ya que hemos comprobado que de esta forma obtenemos los mejores resultados.

La construcción de un sistema generalmente incluye los siguientes puntos:

Identificación de los requerimientos. Se trata de identificar junto con usted cuales son las funciones principales del sistema mediante casos de uso y asignarles una prioridad. Los casos de uso son narrativas en que se describe desde el punto de vista del usuario una parte del sistema que se utilizara para ejecutar una tarea específica.

Definición de la arquitectura general. Se debe plantear cual es la plataforma sobre la que debe correr el sistema, las características de la base de datos, las herramientas de desarrollo que serán utilizadas, si se accesará la información a través de una red local o a través de Internet, si es factible utilizar componentes de software propios de PCtodo o de terceros, que agilicen y disminuyan los costos asociados a la construcción del sistema, etc.

Ciclo de desarrollo. Se seleccionan uno o varios casos de uso, los que se encuentren más altos en la lista de prioridades, y que impliquen un tiempo estimado de desarrollo de 1 mes aproximadamente. Cuando la funcionalidad requerida está asociada a cálculos o transacciones, entonces definimos una serie de casos de prueba antes de comenzar la programación. Estos casos de prueba son ejemplos concretos con resultados que debe arrojar el sistema. Con estos elementos se comienza la programación de los componentes de software que cubran los casos de prueba al 100% . Cuando la funcionalidad está orientada a la captura y consulta de información, entonces trabajamos en un prototipo que vamos refinando iterativamente hasta que cubra los requerimientos de uso completamente.

Depuración del diseño. En cada iteración aplicamos una serie de principios que nos permiten obtener un diseño flexible a los cambios. Por ejemplo, no duplicamos código, utilizamos patrones de diseño con los que hemos resuelto problemas similares con anterioridad, de entre varias opciones seleccionamos la más simple, nos concentramos en cubrir el requerimiento que estamos programando en esa iteración (es imposible predecir los cambios que se van a dar en las reglas de negocios de la siguiente iteración), expresamos el diseño a través del código haciéndolo mas claro.

Documentación. Procuramos producir únicamente la documentación que sea necesaria, para poder enfocar la mayor parte de nuestros esfuerzos al desarrollo de la aplicación, nuestro negocio no es producir papel. Para el diseño de los programas utilizamos diagramas basados en UML para comunicar y discutir dentro del equipo de desarrollo una solución a un problema de programación específico. Para el diseño de bases de datos relacionales utilizamos herramientas CASE que nos permite automatizar los scripts para la creación y mantenimiento de tablas, índices y otros elementos de la base de datos.

Construimos aplicaciones fáciles de utilizar y con ayuda en línea, de forma que los manuales de usuario sean documentos de referencia simple, que pocas veces necesiten consultarse. Solamente en casos en que cierta documentación especifica es necesaria por reglamentación interna del cliente, consideramos como parte del programa de trabajo el tiempo necesario para producirla.

Este proceso se repite en iteraciones sucesivas hasta completar los casos de uso que se hubieran definido.

En cada iteración se libera una versión del producto que en muchos casos se puede poner en producción.

Esto nos permite obtener una rápida retroalimentación para refinar el producto, de forma que al final del proyecto se tenga un sistema que en verdad cubra sus necesidades y se encuentre funcionando.