Análisis de requerimientos
Extraer los requisitos y
requerimientos 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 requerimientos incompletos, ambiguos o contradictorios. El resultado
del análisis de requerimientos 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 CMMI. 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 requerimientos (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 requerimientos, por ejemplo en dos capítulos del libro de Sommerville "Ingeniería
del software" titulados "Requerimientos del software" y
"Procesos de la Ingeniería de Requerimientos".
La IEEE Std. 830-1998
normaliza la creación de las especificaciones de requerimientos de software
(Software Requirements Specification).
Especificación
La especificación de
requisitos describe el comportamiento esperado en el software una vez
desarrollado. Gran parte del éxito de un proyecto de software radicará en la
identificación de las necesidades del negocio (definidas por la alta
dirección), así como la interacción con los usuarios funcionales para la
recolección, clasificación, identificación, priorización y especificación de
los requisitos del software.
Entre las técnicas
utilizadas para la especificación de requisitos se encuentran:
·
Caso de uso,
Siendo los primeros más
rigurosos y formales, los segundas más ágiles e informales.
La integración de
infraestructura, desarrollo de aplicaciones, bases de datos y herramientas
gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados
y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se
delegan todas estas actividades es el del Arquitecto.
El arquitecto de
software es la persona que añade valor a los procesos de negocios gracias a su
valioso aporte de soluciones tecnológicas.
La arquitectura de
sistemas en general, es una actividad de planeación, ya sea a nivel de
infraestructura de red y hardware, o de software.
La arquitectura de
software consiste en el diseño de componentes de una aplicación (entidades del
negocio), generalmente utilizando patrones de arquitectura. El diseño
arquitectónico debe permitir visualizar la interacción entre las entidades del
negocio y además poder ser validado, por ejemplo por medio de diagramas de
secuencia. Un diseño arquitectónico describe en general el cómo se construirá
una aplicación de software. Para ello se documenta utilizando diagramas, por
ejemplo:
Siendo los dos primeros
los mínimos necesarios para describir la arquitectura de un proyecto que
iniciará a ser codificado. Depende del alcance del proyecto, complejidad y
necesidades, el arquitecto elige qué diagramas elaborar.
Las herramientas para el
diseño y modelado de software se denominan CASE, (Computer Aided Software Engineering) entre las cuales se encuentran:
·
Enterprise
Architect
·
Microsoft
Visio for Enterprise Architects
Reducir un diseño a código puede ser la parte más obvia del trabajo de
ingeniería de software, pero no necesariamente es la que demanda mayor trabajo
y ni la más complicada. La complejidad y la duración de esta etapa está
íntimamente relacionada al o a los lenguajes de programación utilizados, así
como al diseño previamente realizado.
Consiste en comprobar
que el software realice correctamente las tareas indicadas en la especificación
del problema. 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.
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 de casos de
uso, pruebas, manuales de usuario, manuales técnicos, etc. todo con el
propósito de eventuales correcciones, usabilidad, mantenimiento futuro y
ampliaciones al sistema.
Fase dedicada a mantener
y mejorar el software para corregir errores descubiertos e incorporar nuevos
requisitos. Esto puede llevar más tiempo incluso que el desarrollo del software
inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto2 está dedicado a su mantenimiento. Una pequeña parte de este
trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en
extender el sistema para incorporarle nuevas funcionalidades y hacer frente a
su evolución.
No hay comentarios:
Publicar un comentario