Introducción a la Ingeniería de Software

El software como programa de computador o sistema informático es parte indispensable de nuestro mundo moderno y cada vez más las personas, las organizaciones o empresas están muy dependientes de su uso o aplicación, esto debido a que el software ha permitido agilizar y automatizar muchas tareas logrando incrementar la productividad en las personas y empresas.

Por tanto, los ingenieros de software tenemos la responsabilidad de crear software de calidad y el reto de seguir innovando para incrementar cada vez más la satisfacción de los usuarios y empresas. Sólo aplicando Ingeniería de Software podremos lograr software de calidad.

La Ingeniería de Software es, como lo define la IEEE, la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software.

Esta definición nos da a entender que, para construir o mantener software debemos aplicar principios y técnicas de ingeniería como el análisis, el diseño, las pruebas y un proceso metodológico adecuado que garantice la calidad del producto software. Además, es necesario que se haga una correcta gestión del proyecto aplicando buenas prácticas, es decir: planificando las tareas que permitan cumplir objetivos trazados para un periodo de tiempo corto, esto se debe organizar en Iteraciones; haciendo uso de métricas para cuantificar el esfuerzo, el tiempo de desarrollo y los costos, y que ayude a la planificación de las tareas; asignando los recursos necesarios para cumplir las tareas planificadas; haciendo seguimiento semanal al cumplimiento o avance de las tareas o logro de los artefactos o productos de trabajo planificados; y apoyarse en herramientas tecnológicas que permitan asegurar la productividad y agilidad en la gestión y el desarrollo del software.

Y para completar el concepto, destaco y recomiendo las siguientes buenas prácticas en el desarrollo de proyectos de software:

a) Aplicar un proceso iterativo e incremental. Esto permite dividir el tiempo del proyecto o ciclo de vida en iteraciones cortas con una duración que puede estar entre 2 a 6 semanas. Cada iteración debe ser planificada en detalle y tener los objetivos claros que se desean alcanzar. El resultado de cada iteración es una parte del proyecto y en la medida que se vaya avanzando en las demás iteraciones se va incrementado el producto software que se debe lograr. Lo importante al finalizar cada iteración es que los objetivos se hayan logrado lo cual implica que se han elaborado los artefactos o productos de trabajo requeridos o planificados para la iteración, esto a la vez permite ir asegurando la calidad del producto porque los artefactos elaborados en la iteración han sido verificados y validados por los interesados, clientes o usuarios. Otra estrategia importante es que en las primeras iteraciones debemos enfocarnos en los requisitos de mayor importancia para el negocio, en los requisitos de mayor complejidad y en los requisitos que son más significativos para la arquitectura. Con esto podemos estar resolviendo los riesgos altos a la mitad del proyecto y estar más seguros del éxito del mismo. 

b) Administrar los requisitos. Totalmente necesario para garantizar que los interesados, clientes o usuarios obtengan un producto que satisfaga sus requisitos. Se debe identificar y describir en primera instancia las necesidades de los interesados, luego describir las características del sistema derivado de las necesidades, y por último, a partir de las características identificar y describir los casos de uso y los requisitos suplementarios. Las necesidades, características, casos de uso y requisitos suplementarios son diferentes niveles de requisitos que se deben describir cada uno con un grado de detalle distinto pero todos están relacionados. Tener relacionados todos estos niveles de requisitos permite mejorar la gestión porque será fácil hacer la trazabilidad entre ellos. También es conveniente hacer uso de herramientas software que nos permitan realizar la trazabilidad de los diferentes niveles de requisitos. La gestión de los requisitos también implica hacer constantes revisiones con los interesados para asegurar que lo que se está describiendo o especificando como requisito es lo que el interesado desea. Estás revisiones permitirán ajustar o madurar el requisito lo cual nos asegura que al momento de implementarlo se esté haciendo lo correcto. Sin embargo, debemos tener presente que los requisitos siempre pueden cambiar a lo largo del proyecto o ciclo de vida, por tanto, no debemos descuidar la gestión de los mismos en ningún momento hasta que finalice el proyecto. 

c) Definir una arquitectura de software. Antes de implementar es necesario definir qué arquitectura tendrá el sistema. La arquitectura nos muestra la forma en cómo se organizan y relacionan los componentes más importantes. La organización de los componentes puede estar agrupado en diferentes capas y cada capa cumple responsabilidades distintas, lo cual se puede estar ajustando a algún patrón de arquitectura como el patrón N-Capas. Para describir mejor la arquitectura se debe hacer uso de diferentes vistas, donde cada vista mostrará diferentes aspectos importantes del sistema tanto estructural o estática como de comportamiento o dinámica. Así mismo, elaborar la arquitectura implica centrarnos en los requisitos funcionales y no funcionales más importantes, principalmente en los requisitos no funcionales importantes para garantizar el rendimiento, fiabilidad, soportabilidad y usabilidad en el sistema. Todo el trabajo de describir la arquitectura se puede hacer en el artefacto llamado Documento de Arquitectura de Software o DAS. El DAS sirve de guía o referencia para la construcción del software y garantiza que todos los implicados en el diseño y desarrollo sigan los mismos patrones y lineamientos. 

d) Elaborar modelos visuales o diagramas. Los modelos visuales son necesarios para conceptualizar y abstraer el dominio del problema así como para definir el diseño del sistema. Los modelos deben ser elaborados usando un lenguaje gráfico estándar como UML. También es conveniente hacer uso de herramientas software para elaborar los modelos, esto permite automatizar nuestro trabajo porque muchas de las herramientas generan a partir de un modelo otros modelos o también parte del código a desarrollar.

e) Verificar la calidad del software. No podemos entregar un producto software sin que éste haya sido probado. Las pruebas del software nos garantiza que el sistema está funcionando bien y que cumple con los requisitos de los interesados, clientes o usuarios. Es conveniente que las pruebas funcionales y de sistema sean realizados por personal dedicado sólo a este trabajo. Los desarrolladores deben hacer sus pruebas unitarias y corregir sus errores antes de entregar a la gente de pruebas, que son los que harán las pruebas finales antes de entregar el producto a los interesados. La estrategia de pruebas debe estar basado en un plan de pruebas, y las pruebas se deben hacer en función a un diseño de pruebas que se describen en los casos de prueba. Las pruebas de aceptación son las pruebas que hacen los interesados o clientes del producto software, estas pruebas son las que definen al final si el producto entregado satisface las necesidades del cliente. Por lo tanto, debemos asegurar en hacer adecuadas pruebas antes de llegar a las pruebas de aceptación, y de esta forma no tener problemas en las pruebas de aceptación. Sólo cuando todas las pruebas de aceptación han salido con éxito, es cuando podemos asegurar un cierre exitoso del proyecto o ciclo de vida del software. 

f) Controlar los cambios. Es necesario en todo proyecto porque existen muchas versiones de los artefactos provocados por variaciones en los requisitos. Se necesita mantener el versionado de todos los artefactos elaborados que permita hacer una adecuada gestión, seguimiento y trazabilidad de los mismos. 

g) Gestionar el proyecto de forma ágil. Todo proyecto que se gestione de forma ágil será un proyecto en donde se cumplan las metas, los cronogramas de trabajo y disminuya la cantidad de entregables o artefactos que no agreguen valor al proyecto. Es conveniente saber identificar qué artefactos son necesarios para el proyecto que se está desarrollando. Para cada artefacto seleccionado y que será elaborado en el proyecto también es conveniente usarlo de forma ágil, esto quiere decir que se puede elaborar un mismo artefacto en diferentes iteraciones agregándole detalle en cada iteración. No es necesario que un artefacto quede totalmente terminado en una sola iteración. Por otra parte, también se puede seleccionar sólo algunas partes del artefacto a elaborar, esto se da en algunos tipos de artefactos que manejan plantillas con una estructura amplia o compleja, por ejemplo el artefacto Visión, entonces de toda esa estructura se puede seleccionar sólo las partes más importantes o necesarias que se crean convenientes.

Entendiendo y aplicando todas estas buenas prácticas podremos asegurar éxito en nuestros proyectos y la satisfacción de los interesados o clientes al recibir un producto software de calidad. Sin embargo, a pesar de tener presente y aplicar las buenas prácticas, siempre existirán riegos o problemas potenciales en todo proyecto que estemos involucrados. Los riesgos en los proyectos no se pueden obviar o pensar que no nos van a suceder, lo cual sería muy ingenuo pensar así. Por tanto, es muy importante que al inicio de un proyecto se identifiquen los riesgos y se planifique acciones de mitigación lo cual ayudará a que el riesgo no ocurra. Las acciones de mitigación también se basan en las buenas prácticas y gracias a ellas podremos evitar que nuestros proyectos fracasen.

En posteriores publicaciones estaré definiendo un proyecto ejemplo con el cual haré el desarrollo de todo el ciclo de vida siguiendo la metodología RUP.

Muchas gracias.