Fases del Proceso de Desarrollo del Software

1-Análisis de requisitos
2-Diseño y arquitectura
3-Programación
4-Pruebas
5-Documentación
6-Mantenimiento


Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software. La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aun no está formalizada, ya se habla de la Ingeniería de Requisitos. La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification).

Diseño y arquitectura

Se refiere a determinar como funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.

Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no es necesariamente la porción más larga. La complejidad y la duración de esta etapa está intimamente ligada al o a los lenguajes de programación utilizados.

Pruebas

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral,para así llegar al objetivo. Se considera una buena practica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un area de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un area de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en que condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

Documentación

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento.

Ingenieria de software

En general, la historia de la ingeniería del software está repleta de ejemplos en los cuales una vez aparecida una técnica o buena práctica, ésta ha sido un fracaso al aplicarla, pero un éxito a la hora de ser venerada por el sector (Boehm, 2006), provocando movimientos que (Davis, 2004) describe como similares a los de los “lemmings”, donde alguien crea un concepto y muchos otros le siguen... aunque finalmente todos acaben perdidos.

Recurrentemente nos preguntamos cuál es la aportación real de las diferentes propuestas que van apareciendo, es decir, qué valor aporta una determinada técnica o buena práctica. Este es precisamente el enfoque de una nueva orientación en la ingeniería del software denominada “Ingeniería del Software Basada en Valor”(o ISBV de Value-Based Software Engineering). La ISBV pretende orientar las propuestas y soluciones basándose en la maximización del valor aportado, cualquier decisión de construcción (o reingeniería) de un sistema software, o incluso cualquier decisión de diseño o metodológica debería estar guiada por su “valor”.

En la actualidad, la mayoría de las prácticas de ingeniería del software se basan en un enfoque de valor neutral, es decir, cada requisito, caso de uso, objeto, prueba, etc., se trata con igual importancia, y si bien en los proyectos se hace un seguimiento de los costes no sucede de igual manera con el valor que aporta al negocio cada uno de los elementos del desarrollo software. Tiempo atrás, cuando las decisiones que afectaban al software tenían relativamente poca influencia en costes, planificación y valor, una aproximación de valor neutral podía ser razonable, pero en la actualidad estas decisiones tienen demasiada repercusión (Boehm & Huang, 2003).

La pobre gestión económica en el área de la ingeniería es uno de los aspectos que la ISBV aspira a mejorar. Y de hecho, recientemente se ha abierto un importante debate entorno a los aspectos económicos del software, curiosamente después de tantos años de estudio de la disciplina. Como ejemplo (Harrison, 2005) comenta como en su experiencia: “según pasa el tiempo, estoy más convencido de que hay una necesidad real para el desarrollador de entender y apreciar el contexto económico en el que opera su organización”. En este sentido los profesionales del software se encuentran frecuentemente desorientados, sin poder estimar el valor que aporta cada desarrollo, y careciendo de la visión global necesaria supone el software para la supervivencia de su organización. Esto se une a la inmadurez del software para integrarse con el resto de disciplinas de la empresa, como pueden ser las finanzas, el marketing o los recursos humanos.
1. El concepto de valor en ingeniería del software

El valor que aporta un sistema a sus usuarios no se define ni por su tamaño, ni por el número de funcionalidades que aporta. Fácilmente se puede imaginar un sistema enorme y que facilite una gran cantidad de funcionalidades que no son usadas por nadie, con lo que no aportará ningún valor. Por otro lado, una pequeña funcionalidad puede ahorrar diariamente horas de trabajo a mucha gente. De este modo, un sistema aporta más “valor” a sus usuarios si proporciona mayores beneficios, ya sea en términos de retorno de inversión (ROI), beneficios sociales, disminución en los costes de gestión, ventajas estratégicas, o cualquier otro aspecto. Como puede suponerse, la cuantificación de todos estos tipos de beneficios es algo complejo.
2. Áreas de la Ingeniería del Software Basada en Valor

(Boehm, 2005) introduce una agenda que pretende integrar las consideraciones de “valor” dentro del conjunto de principios y prácticas existentes. Para organizar todas las aportaciones, y procurar que sean compatibles de manera que se potencien entre ellas, se definieron distintas áreas de trabajo que las agrupasen:

* Ingeniería de requisitos basada en valor, para la identificación de principios y prácticas respecto al valor de los requisitos.
* Arquitectura, diseño y desarrollo basado en valor, para reconciliar los objetivos de negocio y del sistema, con la arquitectura y construcción del software.
* Validación y verificación basada en valor, para desarrollar técnicas de verificación y validación del software respecto a objetivos de valor y su priorización.
* Control y planificación basada en valor, para evolucionar las técnicas más tradicionales sobre planificación, coste y control y que incluyan el concepto del valor que aportan.
* Gestión de riesgos basada en valor, para priorizar, mitigar, identificar, y analizar riesgos desde la perspectiva del impacto que pueden tener en el valor.
* Gestión de la calidad basada en valor, para la priorización de los factores de calidad deseables con respecto al valor que aportan.
* Gestión de personal basada en valor, para la gestión del equipo y recursos humanos en pro de valor.

3. Conclusiones

Una nueva orientación de la ingeniería del software está emergiendo. Se basa en que no todos los elementos del desarrollo software tienen el mismo valor relativo, sino que existen partes que aportan más valor que otras. La ingeniería del software basada en valor tiene por objetivo elaborar técnicas y prácticas que formalicen y cuantifiquen cuánto aporta cada elemento a cada uno de los actores del sistema.

La puesta en marcha e impulso de un proyecto software, ya sea su creación, mantenimiento, o reingeniería, está directamente relacionada con la percepción que los actores tienen sobre los beneficios que aportará. Por ejemplo, la inversión en la creación de un sistema software se basa en la creencia de que el producto que se desarrolla aportará beneficios. Un proyecto no se pondrá en marcha si la dirección de las organizaciones no perciben claramente los beneficios que el producto software les aportará.

El concepto de “valor” suele estar fuertemente ligado al beneficio económico. Sin embargo, se trata de un concepto más amplio, que abarca desde ventajas en el mercado a beneficios sociales. El reto que se presenta es el estudio de todas estas variables y su influencia en los diferentes interesados en el sistema.

Como se ha visto a lo largo de este artículo, la ISBV es una rama que está en investigación, joven y a la que aún le queda un largo camino por recorrer para llegar a un nivel de madurez similar al de otras áreas de la ingeniería del software. Sin embargo, ya se ha definido una hoja de ruta, y han aparecido algunas propuestas que van ampliando poco a poco este nuevo enfoque.

Ingenieria en software

Aristide Alba