Metodología

Ciertos principios son comunes a todas las metodologías. Es importante que como desarrolladores / integradores / arquitectos entendamos a la perfección estos principios ya que serán constantes en los distintos proyectos, aunque los detalles de su uso puedan variar con las demandas de cada proyecto.

Estos principios son los que hemos aprendido a lo largo de nuestras carreras y tras gran cantidad de proyectos. En un primer vistazo pueden parecer demasiado simples, demasiado obvios o demasiado ingenuos para poder llamarlos 'principios básicos para cualquier desarrollo', pero si pensamos en la práctica real vemos que son tan obvios e ingenuos, y que desde luego no es tan fácil ponerlos en práctica.

1. Comprensión. Tener una visión exacta de las necesidades del cliente es fundamental. Esto incluye una comprensión totalmente exacta del vocabulario del 'alcance del problema', el comportamiento funcional necesitado, cómo debe ser utilizado el desarrollo / integración / arquitectura, etc. Cada metodología correcta debe incluir una fase que implique la obligación del consultor de llegar a esta comprensión y de

percepción complicada ya que la metodología es iterativa y continuamente está en fase de adaptación, lo que implica que todos los requisitos no están terminados necesariamente antes de comenzar el diseño, y el diseño completo no es termina do necesariamente antes de comenzar la puesta en marcha. Pero dentro de los distintos procesos específicos del desarrollo, es esencial respetar el orden necesario para un correcto desarrollo.

4. La última prioridad. Cada aspecto de un proyecto, incluyendo la "metodología" y los "principios" debe ser medido contra los objetivos mencionados anteriormente. Por ejemplo, durante la puesta en marcha, una decisión basada en la conveniencia de un desarrollador puede crear una inconveniencia en el sistema con la que el usuario tendrá que convivir. O una decisión que tiene sentido desde un punto de vista eminentemente técnico puede deteriorar la utilidad, la confiabilidad o la capacidad de mantenimiento de un sistema. Aunque el coste y la duración del proyecto son siempre importantes, las decisiones deben respetar el sistema completo de objetivos, en especial la calidad del producto final desde el punto de vista del usuario.

documentarla de modo que el cliente y el equipo compartan un conocimiento explícito, común del dominio del problema. Este proceso puede llegar antes o más tarde, pero obviamente cuesta mucho menos y conduce a una mayor calidad si la comprensión se gana en la etapa más temprana del proyecto.

2. Verificación. El desarrollador / integrador / arquitecto no debe asumir todas las especificaciones del cliente como correctas directamente. Las especificaciones incorrectas se pueden corregir fácilmente al principio de un proyecto, pero pueden ser realmente costosas si son descubiertas al final. Esto hace referencia a todos los aspectos del proyecto, incluyendo desde metas del proyecto, a funcionamiento del

hardware / network, la eficacia de los componentes de un software de una tercera parte, así como esfuerzo, plazos de tiempo y coste estimados. Todas las preguntas y suposiciones deben ser investigadas, y las conclusiones deben ser parte del sistema escrito en la documentación.

3. Orden. Es a menudo una tentación el comenzar una nueva actividad antes de terminar los requisitos previos. Por ejemplo, diseñar antes de acabar el análisis de requisitos, o implementar antes de terminar una especificación del diseño. En orden de que el código sea correcto, el diseño apropiado debe ser finalizado primero, y en orden de que el diseño sea correcto, los requisitos deben ser entendidos antes. Ésta puede ser una