En muchas ocasiones, los proyectos de software no salen como debieran porque se han hecho malas previsiones o  malas ejecuciones del desarrollo o simplemente porque se han definido sus funcionalidades de forma inapropiada.

“Si no sabes a donde vas, no llegarás a ningún sitio.” Lo primero es tener un propósito y, lo siguiente, marcar una hoja de ruta para llegar a él. Una adecuada planificación resulta imprescindible si queremos el mejor final para nuestro proyecto.

Los beneficios de trazar un Buen Plan

 

Nadie puede predecir el futuro y es posible que algunos de los parámetros sobre los que se base el proyecto puedan cambiar. Pero en definitiva, la planificación consiste en organizar y documentar aquello que queremos hacer con el objetivo último de agregar el máximo valor a nuestro proyecto.

  • Estabilizar los requerimientos del proyecto
  • Seguir de forma realista su estado en cada fase.
  • Evitar trabajo y costes innecesarios.
  • Medir el impacto de los cambios
  • Obtener un software desarrollado y probado, con absoluta trazabilidad y dotado de independencia del desarrollador.

La planificación como eje central del éxito de un proyecto de desarrollo de software

Un buen Arquitecto de Software planifica al detalle

 

Un buen arquitecto de software es aquel que define una estructura del sistema teniendo en cuenta los requisitos del proyecto así como sus limitaciones o restricciones sin dejar nada al azar, acompañado de un buen equipo de desarrolladores.

Llegar a buen puerto y con ciertas garantías requiere dividir el proyecto en diferentes fases, asignando a los responsables encargados de ejecutar las tareas, evaluando cada etapa de forma individual y documentándola:

  • Fase de Inicio del Proyecto

Elaborar un Plan de Proyecto que recoja todos los puntos imprescindibles para conseguir los objetivos marcados. El Plan del Proyecto es un documento que debe proporcionar un resumen de alto nivel, que permita supervisar el progreso y cumplimiento de objetivos del proyecto, siendo una referencia desde el principio hasta el cierre del mismo.

  • Fase de Requisitos de Usuario

Obtener un catálogo bien definido de los requisitos funcionales del proyecto y que será consensuado y aprobado por el usuario para no dejar lugar a la improvisación.

  • Fase de Análisis del Sistema de Información

Documentación de todos los requisitos del sistema para dar comienzo a la programación de forma organizada y calculada.

  • Fase de Construcción y Pruebas

Desarrollo de la aplicación y, paralelamente, realización de pruebas para la detección y corrección de posibles errores. El objetivo de esta fase es el de obtener un producto de software consensuado y aprobado por el usuario.

  • Fase de Implantación y Soporte

El sistema desarrollado debe estar activo y plenamente operativo en el entorno del cliente, facilitando un período de soporte y mantenimiento para la corrección de vicios ocultos no detectados con anterioridad. Se trata de una fase en la que se demuestra la garantía del software con apoyo y consultas sobre la aplicación.

 Alboka Soft aglutina un equipo de grandes arquitectos de software

Nos encanta que los planes salgan bien

Procedimientos de calidad

Asimismo, toda la documentación, tanto interna como externa, tiene que estar sujeta a unas normas y procedimientos de calidad definidos, utilizando para ello registros de calidad que engloben el Plan de Proyecto (establecido en la fase de inicio), las comunicaciones con el cliente y un Plan de Gestión de Configuración, donde se programe el control de los elementos surgidos en el proyecto:

  • Configuración: de elementos, estructura de carpetas y bibliotecas asociadas; tipos de accesos y asociación de los mismos a los elementos y finalmente guía de uso de la configuración anteriormente definida.
  • Copias de seguridad: definición de las copias de seguridad necesarias. También se deben especificar tipos de copias (de cada integrante del equipo de trabajo, del conjunto de elementos ya generados o en desarrollo, copias de seguridad externas para su almacenamiento en un lugar diferente al de desarrollo,...).
  • Control de revisiones y versiones: definir los criterios para identificar y definir revisiones y versiones de los elementos. También se define que elementos deben de tener revisiones o versiones.
  • Control de cambios: se especifica el modo de identificar los cambios sobre productos, lugar de almacenamiento y manera de abordar dichos cambios. En toda resolución de cambio aprobada se realiza un análisis de los elementos afectados para asegurar que los cambios a realizar sean ejecutados en todos los elementos necesarios.

 

 

Utilizamos cookies propias con finalidad técnica, las estrictamente necesarias para permitir la funcionalidad básica de la página. De ese modo, no es posible inhabilitarlas. No recaba ni cede datos de carácter personal de los usuarios sin su conocimiento. Encontrarás más información en nuestra política de Cookies. Saber más.

  Acepto las cookies de este sitio web.
Política de Cookies