Antes de embarcarse en un proyecto de Software es necesario tener desarrollado los procesos de negocios. El documento de procesos del negocio la estructura funcional del negocio y permite determinar que procesos serán automatizados con procesos de sistemas. Muchos proyectos se realizan sin considerar esta premisa y muchos fracasan por no respetarlo.

Para obtener los requerimientos busque un profesional con experiencia en toma de datos, de preferencia con experiencia en desarrollo de software y conocimientos de procesos del negocio y técnicas de formulación (Business Process Model and Notation - BPMN). Esta etapa es clave en el éxito del proyecto, permite dimensionar el proyecto y establecer posteriormente los horizontes de tiempo en su desarrollo.

Siempre desarrolle prototipos del sistema, estos deben ser aprobados por los interesados del Proyecto. Sea flexible en este punto, siempre existirán ajustes mas aún en las pruebas integrales. Los prototipos no requieren un diseño final, puede construir un bosquejo o Wireframe. Existen muchas herramientas libres.

No es necesario tener un diseño final del sistema para iniciar el desarrollo, puede utilizar los Wireframe como interface y comenzar el desarrollo del sistema.

Siempre debe existir un representante que lidere a los interesados del proyecto, éste será la voz del grupo en la formulación y negociación con el analista de campo. El líder de los interesados siempre será que el de la aprobación final al prototipo del sistema, documento de requerimientos funcionales y no funcionales.

Antes de formular el prototipo del sistema, debe existir el análisis de procesos del sistema. El análisis de los procesos será uno de los factores claves en la factibilidad técnica del proyecto. Recuerde el análisis se origina desde el trabajo de campo - Captura de información en las entrevistas - del analista de requerimientos o analista de campo.

Durante la ejecución del proyecto, siempre los requerimientos tienden a tener ajustes que se propagan a los prototipos del sistema.

No es necesario ser formal en diagramar los procesos, estos no siempre se representan de forma gráfica. Es recomendable realizar si existen muchos procesos involucrados con muchos estados de decisión.

Para determinar la herramienta del desarrollo y la infraestructura, debe tomar en cuenta los requerimientos. Un sistema con muchos usuarios externos puede ser una aplicación Web, pero depende de la privacidad de la información. Si es un sistema corporativo con un limitado número de usuarios o el software realiza mucho procesamiento interno, puede tomar la opción de desarrollar un sistema de escritorio o DESKTOP. Si la información es sensible, considere tenerla disponible y protegida, esto se logra con un servidor de datos local o virtual, actualmente los costos de infraestructura para base de datos en la nube han bajado. Los proveedores de servicio en la nube como AZURE, AWS, GOOGLE CLOUD, etc ofrecen servicio de base de datos con FIREWALL y la flexibilidad de adquirir mayor rendimiento de transacciones (DTU).

Cuando seleccione el equipo de desarrollo, este debe contar con la experiencia en el manejo de las herramientas que se han seleccionado. Si es un desarrollo IN HOUSE, tendrá limitación en seleccionar la herramienta de desarrollo adecuada, el costo será muy alto en preparar a un equipo que no la conoce. Evalúe los costos de contratar a un proveedor con experiencia. Si la decisión es contratar a un tercero para el desarrollo, controle los avances del proyecto, existe un alto riesgo en fracasar si lo pierde.

Si el producto a desarrollar depende de información externa proporcionada por un proveedor, asegure que los datos recibidos estén estructurados. Verifique que al menos el proveedor proporcione la información en XML con esquema XSD. Si el proveedor proporciona un servicio Web, mejor.

El líder del proyecto debe exigir el diagrama de clases, es una guía básica a la hora de desarrollar. Sirve a los gestores del proyecto como enlace con el equipo de desarrollo del producto. El analista lo utiliza en parte para determinar los tiempos de desarrollo y la productividad del personal técnico, existen además otros factores que afectan la productividad del equipo técnico.

El tiempo es una factor clave en el desarrollo de un producto de software. Si el plazo es muy largo, es recomendable dividirlo en etapa, en el que cada etapa es un producto con número de versión puesto en producción. El analista de requerimientos es la persona que debe negociar con los interesados del proyecto.

Cuando se realiza el análisis del sistema, deben tener detallado los casos de uso. Es importante en esta fase poder cubrir todos los procesos que el sistema tiene como objetivo.

La experiencia de un buen análisis de sistemas detecta que entidades o procesos quedan sueltos. Recuerde todos los procesos deben ser parte de un engranaje funcional.

Antes de iniciar el desarrollo debe contar con un diagrama de despliegue, es un punto clave que va acorde con las herramientas de desarrollo y la infraestructura que es necesaria para que el producto pueda funcionar.

En la etapa de pruebas del producto, es recomendable tener una infraestructura para las pruebas del producto. Se aplica en pruebas unitarias e integrales.

Cada modulo del sistema debe estar documentado.

Si ya cuenta con un diagrama de despliegue, debe existir un documento de instalación. Este debe ser usado para la etapa de pruebas unitarias e integrales.

Siempre debe tener como guía el prototipo del sistema, es a lo que queremos llegar. Sin esto, sera mas complejo llegar a un equilibrio en los requerimientos. Recuerde, el proyecto tiene un limite de tiempo.

En el desarrollo del sistema las clases definidas sufrirán cambios, sobre todo en variables que controlan el estado del objeto. Realizando diagramas de estado ayuda mucho en el control de versiones de las clases definidas. Si usa un lenguaje de alto nivel , no se preocupe mucho en definir a sola variables con lectura binaria, eso solo es recomendable en lenguajes de nivel medio o bajo. Es mucho mas didáctico definir tantas variables booleanas como sea necesario, los lenguajes de alto nivel gestionan mas memoria. Si desarrolla sistemas que dependan mucho de los recursos de memoria, si se debe tomar en cuenta optimizar la definición de atributos de una clase.

Siempre que desarrolle sistemas transaccionales, tanto la lectura como la escritura debe tener control de error Try/Catch. Recuerde, siempre debe informar al usuario lo que pasa y siempre debe enviar mensajes de espera en cualquier escenario que necesite procesar o leer datos del servidor de Base de datos. Actualmente se usan motores de base de datos que están en la nube, recuerde , debe protegerse de la caída en la comunicación sobre Internet, su sistema debe poder recuperarse.

Siempre debe manejar hilos de ejecución si su proceso de sistema llama a procedimientos que acceden a recursos externos, al ser externo, esta expuesto a falta de disponibilidad. Esta recomendación evita que el sistema quede colgado en espera de respuesta.

El desarrollo del código fuente debe ser claro, esto es importante porque nunca un solo programador vera su mantenimiento o actualización. Acá toma importancia la experiencia del programador y los estándares de codificación de los módulos.

Sea simple en desarrollar los módulos del sistema. No necesita un código fuente complejo para llegar a una solución simple. Todos los lenguajes de programación ofrecen características en sintaxis y librerías que solo pueden ser recomendadas bajo ciertos escenarios, el que usted lo use donde no corresponda no asegura que sea un excelente programador.

Si está desarrollando un sistema transaccional con procesos que consuman recursos del motor de base de datos, deje que sea un STORE PROCEDURE el que realice este trabajo. Cada llamada al motor de base de datos consume muchos recursos, es mejor hacerlo en una sola llamada en lo posible.

Todo los algoritmos que procesen puntos claves como formulas del negocio, deben tener un pseudo código y debe ser documentado.

Nunca elija herramientas de desarrollo que estén en fase incipiente, es altamente recomendables que elija herramientas con largo periodo de vigencia en el mercado. No todo lo nuevo es mejor, sobre todo que no existen muchos programadores en el mercado para su manejo. Muchos proyectos fracasan por tomar malas decisiones en las herramientas adecuadas.

No todas las soluciones se basan en aplicaciones Web, es un grave error asumir esto. La solución debe considerar los requerimientos funcionales y no funcionales. Estos deben determinar la decisión correcta. Actualmente los sistemas DESKTOP y móviles nativos hacen todo lo que se requiera para trabajar en la nube.

Con la evolución de Internet, se ha masificado el desarrollo de aplicaciones Web. El desarrollo de una aplicación Web será la decisión correcta si espera tener un alto volumen de usuario externos o móviles. Volvemos a los requerimientos funcionales y no funcionales, en los requerimientos verá si es necesario. Actualmente las aplicaciones DESKTOP hacen todo lo de una aplicación Web. Actualmente las aplicaciones Web ofrecen repositorios locales para simular una aplicación DESKTOP , pero es un paso forzado no natural. Como ejemplo podemos ver las aplicaciones Web de Facturación electrónica, ellos dependen de la conexión continua con la Internet, pero están sujetos a pérdida de conexión y varios de ellos dan alternativas de trabajar fuera de linea y luego sincronizan datos.