1. 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 aún 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).
2. Diseño
y arquitectura
Se
refiere a determinar cómo 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.
3. 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á íntimamente ligada al o a los lenguajes de
programación utilizados.
4. 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 práctica 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 área 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 área de pruebas conformada por programadores con experiencia, personas que
saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y
que pueden poner atención en detalles que personal inexperto no consideraría.
5. 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.
6. 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.
No hay comentarios:
Publicar un comentario