"La parte más dificil de desarrollar un sistema es decidir qué desarrollar... ninguna otra parte hace fallar tanto el sistema resultante si se hace mal. Ninguna otra parte es más difícl de rectificar después".
La experiencia acumulada a lo largo de los años de ejecutar proyectos indica que los proyecto exitosos son aquellos que son administrados siguiendo una serie de procesos que permiten organizar y luego controlar al proyecto. Es sin dudas un objetivo fundamental de los diseñadores de software alcanzar y mantener un nivel técnico en los sistemas, acorde con el desarrollo actual en la automatización de la información para la gestión y la dirección, y es conocida la importancia de la ingeniería de software para elevar la productividad y la calidad en diseños de sistemas automatizados a partir de un examen detallado de las metodologías existentes. La rama de la metodología, dentro de la ingeniería de software, se encarga de elaborar estrategias de desarrollo de software que promuevan prácticas adaptativas en vez de predictivas; centradas en las personas o los equipos, orientadas hacia la funcionalidad y la entrega, de comunicación intensiva y que requieren implicación directa del cliente. Muchos investigadores en sus estudios acerca del tema de las metodologías de desarrollo de software se han detenido a definir el concepto de metodología, algunas de estas definiciones se muestran a continuación. En el trabajo “Una Metodología para el desarrollo de Base de Datos” se dice que una metodología es un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de un producto de software.
Una metodología define:
• Estados, etapas o fases de un desarrollo, junto con los criterios de transición entre ellos.
• Tareas, actividades, etc.
• Roles, con sus skills necesarios y las interacciones entre ellos.
• Artefactos o entregables.
• Herramientas de control, seguimiento, medición y perfeccionamiento.
• Principios, criterios para tomar decisiones, estrategias para manejar distintos tipos de situaciones, herramientas de manejo de riesgos, etc.
La dificultad propia del desarrollo de software, y su impacto en el negocio, han puesto de manifiesto las ventajas, y en muchos casos la necesidad, de aplicar una metodología formal para llevar a cabo los proyectos de este tipo.
El objetivo es convertir el desarrollo de software en un proceso formal, con resultados predecibles, que permitan obtener un producto de alta calidad, que satisfaga las necesidades y expectativas del cliente. Atrás queda el modo de trabajar artesanal, que a menudo requiere grandes esfuerzos para obtener el resultado final, con los consecuentes desfases de fechas y coste, y es más que probable el desgaste personal del equipo de proyecto. Por lo que utilizar las metodologías implica mejoras en los procesos de desarrollo, en el producto y en la satisfacción del cliente.
Mejoras de los procesos de desarrollo
• Todos los integrantes del equipo del proyecto trabajan bajo un marco común.
• Estandarización de conceptos, actividades y nomenclatura.
• Actividades de desarrollo apoyadas por procedimientos y guías.
• Resultados de desarrollo predecibles.
• Uso de herramientas de ingeniería de software.
• Planificación de las actividades en base a un conjunto de tareas definidas y a la experiencia en otros proyectos.
• Recopilación de mejores prácticas para proyectos futuros.
Mejoras de los productos
• Se asegura que los productos cumplen con los objetivos de calidad propuestos.
• Detención temprana de errores.
• Se garantiza la trazabilidad de los productos a lo largo del proceso de desarrollo.
Mejoras en las relaciones con el cliente
• El cliente percibe el orden en los procesos.
• Facilita al cliente el seguimiento de evolución del proyecto.
• Se establecen mecanismos para asegurar que los productos desarrollados cumplan con las expectativas del cliente.
En ocasiones, el diseñador al escoger entre la variedad de lenguajes, técnicas, métodos y otros, prefiere hacer las cosas como mejor le convenga y sacar el diseño lo más pronto posible lo cual resulta ser una decisión nada acertada, que más que ayudar en tener un sistema lo más pronto posible funcionando resulta un sistema poco funcional donde abundará la generación posterior de errores. Una mala práctica en el desarrollo de software, es comenzar a intentar desarrollar sin realizar ningún tipo de análisis, tratando de partir del modelo de datos; esto generalmente tiene drásticas consecuencias ya que no existe un orden para solucionar el problema. Surge la necesidad de seguir un proceso ordenado, esta es la Metodología.
La Metodología es definida como el conjunto de procedimientos basados en principios lógicos que son utilizados para alcanzar un objetivo. Seguir un proceso estructurado que se adapte a una situación específica al momento de desarrollar un software incrementa la probabilidad de éxito, ya que estas metodologías han sido probadas bajo ciertos factores en un contexto específico y han resultado exitosas, por lo que integrarla al proyecto consiste en identificar que metodología se acopla más a la situación y utilizarla. Documentar el software es necesario independientemente de la estrategia de desarrollo que sigamos. Una buena documentación nos va a permitir mantener una visión completa del software, ayudándonos a comprender las características del sistema y a modificarlo en caso de que sea necesario. La documentación no se realiza para uno mismo, sino para los demás, ayudando a eliminar la dependencia de las personas. Por lo tanto, documentar un software siempre será útil, aunque en un principio pueda no parecerlo. Tener una buena documentación, proporcional al tamaño del software desarrollado, puede ser tan importante como tener un buen software. Uno de los grandes problemas que enfrenta el desarrollo de software, es la poca utilización de metodologías, la pequeña y mediana empresa creen que el uso de las metodologías es solo para las grandes, la postura de las empresas ante el mercado, es que se desea el producto completo lo más rápido posible, por lo que no consideran la necesidad de una metodología, como no miran el avance a corto plazo, lo siente una pérdida de tiempo y prefieren empezar a desarrollar lo antes posible sin dedicarle tiempo al análisis y diseño del software. La poca aceptación y la ignorancia es uno de los mayores retos hacia las metodologías ya que no se comprende la importancia fundamental en el desarrollo de software, al no ser utilizadas las consecuencias pueden ser catastróficas, el software en vez de ser una solución al problema, se convierte en otro problema que resolver. Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería. Los proyectos de desarrollo de software, sobre todo aquellos de gran tamaño donde se tardan muchas iteraciones en tener una parte importante del mismo en funcionamiento o más todavía, aquellos que siguen un ciclo de vida en escala, sufren importantes contingencias que pueden provocar que el mismo se vaya de las manos, por mucho empeño que se tenga y por mucho esfuerzo que se invierta.
¿Contingencias? Entre ellas es muy típico encontrarnos con el caso de algunas, como por ejemplo: funcionalidades mal definidas o implementadas, priorización deficiente de los desarrollos, procesos que antes eran de una forma, después son de otras y más tarde se vuelven a modificar, etc… que después nadie quiere hacerse responsable y todavía más si después nos encontramos con responsables funcionales que se van y luego vienen otros con otras ideas o enfoque y a los que le ha tocado continuar con los trabajos. Al final, cuando los plazos se echan encima y/o el presupuesto empieza a agotarse, vienen las prisas y se empiezan a pedir responsabilidades generalmente al lado equivocado, el de los desarrolladores. Llegado a este punto, sobre todo si se piden explicaciones en niveles superiores de la jerarquía, llega la crisis. ¿Esto por qué no está?, ¡me he gastado tanto y no tengo resultados!, yo pensaba que esto estaba más avanzado y todavía le queda mucho, ¡lo necesito para ya!, y todo ese largo etcétera que estamos acostumbrados a escuchar. Las crisis no se arreglan gritando o presionando más, sino que requieren un trabajo ordenado y el mismo empieza asumiendo cada parte que existe un problema y el papel que ha desempeñado en que se produzca. Eso realmente es lo más importante y difícil para solventar la crisis, reconocer que hay un problema y que se ha sido parte de él. No se trata de hacer tabula rasa con lo que ha pasado. Quien se ha equivocado debe asumir las decisiones que ha tomado y el trabajo que ha realizado (o si no ha sido culpa directa suya, hacer como propias las decisiones de sus antecesores en su rol) y asumir las consecuencias de la misma. No obstante, eso es algo que cuando mejor corresponda al proyecto se deberá tener en cuenta. Una vez que se reconoce el problema, se asumen decisiones y errores, ya queda el camino despejado y el esfuerzo liberado para comenzar a realizar las acciones necesarias para reconducir el proyecto, algo que por otra parte tampoco será fácil.
