SOTECHCO BLOG

Las fallas en el software son 3 veces más costosas en etapas finales

arquitectura de software

¿Por qué se generan errores al desarrollar software?, ¿Que ocurre en la realidad?.

Mayo 6 de 2016 por SoTechCo

Existen muchas variables que se pueden analizar para generar resultados a estas preguntas, pero creemos que se pueden responder si se revisan determinadas actividades.

Falta de tiempo

No se cuenta con el tiempo suficiente para hacer una planeación eficiente para las diferentes etapas y por lo tanto se trabaja muchas veces en ambientes de producción generando un alto riesgo de error.

Falta de conocimiento

Muchas veces hay que contratar ingenieros, arquitectos o analistas que no cuentan con el conocimiento en detalle de las herramientas además de los procesos o desarrollo del software que se está adelantando, generando altos riesgos de error.

Fallos en las etapas iniciales

Muchos de los problemas de mantenimiento pueden ser debido a la mala planeación de los proyectos, que se traduce en la pobre información generada, en malos análisis de requisitos o en malas implementaciones, generando desgaste en los stakeholders además de altos los costos y un complicado proceso para el mantenimiento del software.

“La calidad debe ser evidente a los ojos del usuario, quien es la persona que va a usar el sistema, quien se convertirá en el influenciador para cambiarlo o continuar con él. Por lo tanto es necesario crear o adoptar ventajas competitivas que reflejen esa calidad en el software.”


Por ello, una posible solución es adoptar “Las buenas prácticas” que se generan en el sector y que entendemos como las actividades que se han realizado en el desarrollo de software y que han generado una serie de beneficios y resultados muy valiosos, que se espera que en determinados ambientes entreguen los mismos beneficios y resultados.

Hay modelos que permiten a las organizaciones adoptar buenas prácticas, sus propósitos entregar guías para el mejoramiento de los procesos y sus habilidades, sin embargo, las principales que recomendamos son estas seis mejores practicas.

• Administración de Requerimientos.
• Modelar visualmente el software.
• Usar Arquitecturas basadas en Componentes.
• Verificación continua de la calidad.
• Desarrollo Iterativo.
• Controlar los cambios hechos al software.


Administración de Requerimientos

Un requisito se puede entender como una “condición” que el software debe cumplir.

La administración de requerimientos es una fase delicada en el desarrollo del software ya que de esta dependerá lo que desea el cliente realizar y los posibles problemas que se puedan generar a futuro. Por ello el Project Management Institute (PMI) generó un capitulo completo para esta fase.

Los requerimientos pueden ser:

• No siempre obvios y pueden venir de fuentes variadas
• No siempre fácilmente expresables
• De distintos niveles de detalle
• Pueden crecer causando problemas de alcance.

Por otro lado, para manejar la fase de requisitos exitosamente algunas de las mejores practicas comprenden.

• Analizar el o los problemas en detalle.
• Entender las necesidades de los stakeholders en profundidad.
• Generar un alcance de proyecto y control de cambios si es necesario.

Modelar visualmente el software

Para esta practica es necesario contar con una herramienta que permita modelar, entender y visualizar el software de forma fácil, permitiendo mejorar la comunicación del equipo que crea, revisa y comparte el diseño de la aplicación. De esta forma, entender el sistema en construcción y con precisión.

El modelado es un requisito que muestra las particularidades del sistema desde una representación única y confiable ocultando los detalles no relevantes. Los modelos en general, pueden ayudar a:

• Entender sistemas complejos
• Explorar y comparar alternativas de diseño
• Formar una base sólida para la implementación
• Capturar los requisitos con precisión
• Comunicar decisiones inequívocamente

Herramientas como Lattix Architect permiten crear un modelo de dependencias de su sistema, incluyendo aplicaciones, bases de datos, servicios y archivos de configuración. Con Lattix puede analizar la arquitectura en detalle, editar la estructura y crear un que pasa si y debería ser. Crear reglas de diseño que formalizan y comunican la arquitectura al equipo de desarrollo

Con Lattix Architect usted puede:

• Comprender la dependencia detallada de cada elemento de bajo nivel.
• Jerarquía de descomposición que permite una escalabilidad masiva.
• Sistemas de reingeniería y generar listas de trabajo.
• Reglas de diseño que permiten especificación precisa de estratificación y componentización.
• Controlar como las librerías de terceros son usadas.
• Conocer las métricas para medir la complejidad, la estabilidad, la ciclicidad, acoplamiento y otras medidas.


Usar Arquitecturas basadas en Componentes

Una analogía importante acerca de este proceso es “divide y vencerás”, piensa en Lego un montón de piezas que puedes armar de cualquier manera y que su resultado siempre va a ser el que deseas por que son piezas intercambiables y ajustables cada una para lograr un solo objetivo.

En ingeniería de software pasa lo mismo, si hacemos pequeñas piezas de software que podemos ajustar unas con otras con interfaces y comportamientos definidos lograremos mayor cohesión de los elementos, menor acoplamiento, una baja complejidad, un menor tamaño de la solución; todos estos beneficios se enfocan a un software fácilmente escalable, mantenible y de bajo costo.

Las plataformas de desarrollo nos dan referencias de diseño arquitectónico para realizar la arquitectura basada en componentes. De forma similar, herramientas como Lattix Architect nos permiten visualizar todos los componentes y así analizar los comportamientos e interfaces para tomar decisiones rápidas acerca de las posibles desviaciones que se pueden generar. Además, permite obtener métricas de sensibilidad de los componentes a un cambio, acoplamiento, ciclos, complejidad, etc.


Verificación continua de la calidad

La calidad es una propiedad inherente a lo que desarrollamos y que los stakeholders pueden percibir de diferentes maneras.

En cada entrega de los componentes de software deben realizarse las pruebas correspondientes de los posibles eventos a lo que pueda estar expuestos, y así minimizar los impactos negativos y corregir errores, sin embargo, esta etapa, muchas veces se termina consumiendo altos costos, debido a que los componentes que se prueban contienen errores que fácilmente pudieran verse corregidos en la etapa de desarrollo.

El equipo de pruebas o Quality Assurance (QA) por sus siglas en ingles, hacen pruebas funcionales, pero, y ¿las de arquitectura?. Aquí existe un bache en el desarrollo del software y que afecta de forma directa las pruebas y el resultado final que se le entrega al cliente. La entrega de un componente debería contener indicadores mínimos de ciclos, complejidad, cohesión, sensibilidad de un cambio, etc. Ello permitirá aumentar la calidad en la arquitectura y por ende la del desarrollo que afectara positivamente el mantenimiento y escabilidad que realizara al software a futuro.

En esta etapa y con la finalidad de aumentar la productividad del equipo y disminuir los costos en las pruebas. Lattix es un complemento perfecto, ya que permite obtener la cantidad elementos exactos y sus dependencias para toda la cadena permitiendo conocer de manera eficaz a que se le hará pruebas y no se desperdiciara el tiempo en pruebas innecesarias a componentes o elementos que no se encuentran impactados.

Por otro lado, Lattix Web proporciona una manera conveniente y de gran alcance para publicar y realizar un seguimiento a la evolución de los proyectos. Lattix Web incluye un almacenamiento, que se actualiza de forma manual utilizando Lattix Architect o automáticamente por el sistema de compilación, y se accede desde un navegador web. El equipo puede utilizar el navegador para ver los proyectos y con ayuda de los Snapshots comparar las tendencias de los cambios arquitectónicos, violaciones, métricas y una variedad de otros datos. Ahora es más fácil que nunca comunicar esta información crítica a toda la organización.


Desarrollo Iterativo

El objetivo principal del desarrollo iterativo es iniciar con un proyecto con requisitos mínimos viables que puedan ser desarrollados con un mínimo esfuerzo y evaluados rápidamente por el usuario final. El problema de los desarrollos clásicos es que hasta el final de desarrollo se probaba por el usuario y posiblemente serán muchos cambios, los costos y tiempo se podrían volver inmanejables. Con el desarrollo iterativo se hace un mini proyecto donde se genera la retroalimentación del usuario final muy rápido y se vuelva a realizar una nueva iteración con la experiencia de la anterior, entendiendo de una manera eficaz los nuevos requerimientos o mejoras que se deben hacer a la iteración del proyecto evaluada.

Las ventajas de esta practica son:

• Se recibe la retroalimentación de los usuarios rápidamente.
• La complejidad del proyecto puede ser menor debido a la simplicidad de cada iteración.
• El desarrollo es sólido y puntual.
• Los desarrollos tienen una menor probabilidad de fallar, debido a la retroalimentación del usuario.
• Existe un aprendizaje continuo que se aplica para cada iteración.

Lattix es una herramienta que brinda el soporte perfecto para esta buena practica debido a que permite visualizar completamente el proyecto, comparar las diferentes iteraciones con métricas de arquitectura permitiendo controlar las desviaciones que se puedan generar, además de conocer la complejidad de cada una de las iteraciones.

Es un soporte perfecto para que las nuevas iteraciones se generen con mayor velocidad al conocer la arquitectura y el impacto que se genere por los nuevos requerimientos o las mejoras que se detectaron por la retroalimentación del usuario. Un punto importante es el desarrollo sólido y puntual. Aquí Lattix puede cerrar aún más la brecha ya que este viene dado por las iteraciones pero si además se conoce específicamente como va a encajar el desarrollo el riesgo se ve disminuido.


Controlar los cambios hechos al software

Los controles de cambios son totalmente normales en proyectos de software, el problema es cuando la etapa de requisitos ya fue firmada, porque dependiendo la etapa donde se soliciten pueden tener cambios violentos impactando todo el software.

En muchas ocasiones, estos cambios pueden venir por dos situaciones, cambios por el cliente o cambios por una mejora que se desea realizar. Ambos es necesario evaluarlos con total calma. La idea primordial es no ingresarlos a la fuerza al proyecto ya que podrían integrarse en una etapa posterior y generar un mejor impacto y un menor riesgo en costos y productividad. Pero en muchas ocasiones es necesario ingresarlos antes de terminar el proyecto. El desarrollo iterativo y la arquitectura basada en componentes permiten minimizar los riesgos en este tipo de cambios. Pero uno de los mayores problemas que se tiene al desarrollar cambios en cualquier etapa es el desconocimiento de los elementos que se pueden impactar. En muchas ocasiones las compañías se aferran a los ingenieros sénior que llevan mucho tiempo trabajando con la compañía y con el proyecto, pero esto no es garantía que no se genere un fallo o error que impacte al usuario final.

Por otro lado, el ingeniero sénior puede no estar disponible por muchas razones y el tiempo de entrega puede ser muy corto como para esperar. Lattix permite además de visualizar la estructura del software, ver el impacto de un cambio en un componente o componentes y en sus elementos relacionados directa e indirectamente. Obtener esta lista de componentes con sus dependencias permitirá planear mejor el cambio y estimar tiempo muy cercanos a la realidad, entregando un parte de tranquilidad a los stakeholders.


Conclusión

Finalmente, para terminar, el problema más común es la comunicación entre las personas que intervienen en el proyecto. La comunicación entre arquitectos, desarrolladores y equipo de calidad debe ser por naturaleza fluida, pero la realidad es otra, ya que en las compañías se encuentran que se pueden llegar a generarse perdidas deliberadas de tiempo impactando el desarrollo del proyecto. Una solución optima es tener sistemas que permitan soportar una comunicación eficiente, no solo a nivel personal, sino, además a nivel de actividades que muchas veces pueden llegar a ser difíciles tanto comunicar como en su seguimiento, el ejemplo clásico es la arquitectura de software, debido que para un arquitecto y desarrollador se puede tener un modelo UML pero al iniciar con código es difícil hacerle seguimiento a ese código con respecto a la arquitectura. Lattix soporta muy bien este proceso, ya que con cada nueva iteración se puede revisar el código directamente y revisar las desviaciones que pueden presentarse asegurando el control de la arquitectura y sus objetivos de escalabilidad, complejidad y mantenibilidad.

Es importante dentro del proceso de crear competitividad adaptar metodologías y buenas practicas que permitan generar valor para el cliente, sin embargo, es necesario que estas metodologías y actividades este acompañadas de herramientas tecnológicas que permitan que el tiempo sea disminuido y la productividad aumentada.

La innovación es una palabra de moda que debe convertirse en la religión que deben profesar las compañías con la finalidad de siempre estar trabajando con metodologías, y herramientas que lo mantengan como un líder en el sector.

Para mayor información visita www.sotechco/lattix.html.