Introducción
La mayoría de los proyectos de software fracasan, casi como en la crisis de software. De hecho, el grupo Standish informa que más del 80% de los proyectos no tienen éxito, ya sea porque están por encima del presupuesto, tiempos estimados, no se usan nunca, por funcionalidad, o una combinación de estos factores. Por otra parte, según el informe, el 30% de los proyectos de software están tan mal ejecutados que se cancelan antes de su finalización. Los proyectos de software que se desarrollan usando tecnologías modernas, tales como Java, J2EE, XML y Servicios Web no son una excepción a esta regla.
Mejores prácticas (Software Best Practice)
El fin del marco de desarrollo de Bootstrap (1933), marca el comienzo de la creación de un subdominio específico dedicado a la mejora del proceso de software, conocido como Software Best Practice que constituye un grupo de acciones destinadas a promover mejoras en el desarrollo de Software en las organizaciones de todos los sectores industriales.
*Es importante señalar que se está hablando del modelo de calidad Bootstrap desarrollado y mantenido por la organización “European Strategic Programme for Research in Information Technology” y no del Framework desarrollado originalmente por Twitter en 2011. *
Cubren la estimación y planificación; análisis de requerimientos; control de cambios; control de calidad; progreso y especificación de costes; y el mantenimiento y soporte después de la entrega del producto. El desarrollo ágil, programación extrema, diseño de la aplicación conjunta (JAD), seis paradigmas principales para el desarrollo de software, y otros métodos.
Requisitos
La recolección correcta de los requisitos es fundamental para el éxito del proyecto. Esto no implica necesariamente que todos los requisitos necesitan ser fijados antes de cualquier arquitectura, el diseño y la codificación se hacen, pero es importante para que el equipo de desarrollo pueda entender lo que necesita ser construido. Los requisitos se dividen en dos tipos: funcionales y no funcionales. Una buena manera de documentar los requisitos funcionales está utilizando casos de uso. Los requisitos no funcionales describen las características de funcionamiento del sistema y de la aplicación. Es importante reunirlos, porque tienen un impacto importante en la arquitectura de la aplicación, diseño y rendimiento.
Proceso de Desarrollo
Es importante elegir el ciclo de vida del proceso de desarrollo apropiado para el proyecto en cuestión, porque todas las demás actividades se derivan del proceso. Para la mayoría de los proyectos de desarrollo de software modernos, algún tipo de metodología basada en espiral se utiliza más de un proceso en cascada. Hay varias opciones, incluyendo el Rational Unified Process (RUP), IBM Global Services Method, eXtreme Programming (XP) y SCRUM.
Arquitectura
Muchos proyectos fracasan (como se explica en la introducción). El estudio de estos fracasos ha dado lugar al concepto de anti patrones. Son valiosos porque proporcionan conocimientos útiles de lo que no funciona, y por qué.
La arquitectura de un sistema de software se diseña para satisfacer los requerimientos funcionales y no funcionales establecidos por los interesados en el sistema. Por lo que, una arquitectura bien diseñada es clave para que las empresas puedan evolucionar con el dinamismo que las economías actuales exigen. Retomando el ejemplo de la compañía de comercio electrónico, si la arquitectura del sistema no ha sido diseñada con base en prácticas correctas de ingeniería de software, es posible que el sistema se convierta en un obstáculo para la evolución requerida por el negocio.
Diseño
Incluso con una buena arquitectura todavía es posible tener un mal diseño. Muchas aplicaciones están bien diseñadas encima o por debajo de diseño personalizado. Para muchos proyectos, es importante llevar a cabo el análisis orientado a objetos y el diseñado usando UML. La reutilización es una de las técnicas más usadas, por el ahorro de tiempo y recursos que conlleva, pero a menudo no se aprovecha debido al esfuerzo adicional requerido para crear activos reutilizables. La reutilización de código no es sino una forma de reutilización y hay otros tipos de reutilización que pueden proporcionar mejores ganancias de productividad.
Codificación
Construcción del código es solo una fracción del esfuerzo total del proyecto, pero a menudo es la más visible, ya que es lo que va a usar el cliente. Sin embargo, los requisitos, arquitectura, análisis, diseño y pruebas definirán todo el éxito o fracaso del proyecto. En los proyectos sin algún proceso de desarrollo (los llamados "programa y corrige"), estas tareas también están sucediendo, pero bajo la apariencia de la programación, lo que en grandes proyectos resulta fatal por la falta de organización y/o estándares en los requerimientos, se requiere extremadamente de una buena comunicación para que estos tengan alguna remota posibilidad de tener éxito.
Una buena práctica para la construcción de código incluye la construcción y la prueba de humo diariamente. Martin Fowler, va un paso más allá y sugiere la integración continua que también se integra el concepto de pruebas unitarias y código de auto-prueba. Hay que tener en cuenta que a pesar de que las pruebas de integración y de unidad continua han ganado popularidad a través de XP, puede utilizar estas mejores prácticas en todo tipo de proyectos. Existen marcos estándar para automatizar la construcción y la elaboración de las pruebas, como los son Ant, Graddle y JUnit.
* Martin Fowler es un ingeniero de software británico, autor y orador internacional sobre desarrollo de software, especializado en análisis y diseño orientado a objetos, UML, patrones de diseño, y metodologías de desarrollo ágil, incluyendo programación extrema. *
Pruebas
No es un elemento secundario o de recorte cuando el calendario se estrecha, o al menos no debe serlo, si se quiere calidad. Es una parte integral del desarrollo de software que necesita ser planificada. También es importante que las pruebas se realicen de forma proactiva; lo que significa que se han de prever los casos de prueba antes de que comience la codificación, y se desarrollan casos de prueba mientras el proyecto está siendo diseñado y codificado, lo que significa que los requerimientos ya se han obtenido.
Gestión de Configuración
Implica conocer el estado de todos los artefactos que componen el sistema o proyecto, la gestión del estado de los artefactos, y la liberación de versiones distintas de un sistema.
Implementación
El despliegue es la etapa final de la liberación de un sistema o aplicación para los usuarios. Sin embargo, todavía hay cosas que pueden salir mal. Es necesario planificar la implementación y se puede utilizar una lista de recomendaciones de “CxOne”.
*CxOne es un framework orientado al desarrollo por métodos agiles, cuenta con listas de verificación, plantillas, patrones y otras herramientas que facilitan el desarrollo de Software*
Referencias:
- Capers Jones. (2010). Overview of 50 Software Best Practices. En Software Engineering Best Practices(660). New York, NY, USA: McGraw-Hill, Inc..
- Mike Perks. (2003). Best practices for software development projects. 05/04/2017, de developerWorks® IBM Sitio web: https://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html
- Javier Tuya, Isabel Ramos Román, Javier Dolado Cosín. (2007). Técnicas cuantitativas para la gestión en la ingeniería de software. Sta. Cristina 15172 oleiros (La Coruña), España: Netbiblo, S.L.
- IAN SOMMERVILLE. (2005). INGENIERIA DEL SOFTWARE. Ribera del Loira, 28, 28042 Madrid España: PEARSONS ECUCACIÓN, S.A.
- SOFTWARE BUILDERS, Servicios desarrollo software, En el texto: (Software Builders), Bibliografía: Software Builders,. Servicios Desarrollo Software. 2015. Web. 5 Apr. 2017.