Bases de documentacion

3.6 Bases de documentación

Ya desde los primeros pasos del desarrollo del software es necesario comenzar a organizar toda la documentación. En primer lugar se han de gestionar los formatos en los que se va a escribir la documentación. Preferiblemente se deben utilizar herramientas de ayuda que semi-automatizan la recopilación de la documentación durante el desarrollo. Evidentemente, tanto lasespecificaciones iniciales del problema (en lenguaje natural probablemente) como las especificaciones finales de los requisitos (en un lenguaje formal), pasando por los estados intermedios de análisis y modelado y las diferentes pruebas de validación se deben guardar como parte inicial de la documentación.

El documento de especificación de requisitos SRS (Software Requirements Specification) esalgo así como el contrato oficial que se establece entre los desarrolladores y los clientes. Incluye tanto los requisitos funcionales como los no funcionales. Una recolección correcta y completa es crucial para el desarrollo de un sistema de información exitoso. Para alcanzar el mayor grado de calidad es esencial que el SRS sea desarrollado de un modo sistemático e inteligible, en cuyo casoreflejará las necesidades del usuario y será útil para todos. Lo que sigue es una plantilla del SRS según el estándar IEEE 830.

En la portada se indican: Nombre de la empresa, Nombre del proyecto, Número de versión y Fecha.

El índice debe constar de las siguientes secciones: Introducción, Descripción general, Requisitos específicos, Gestión del cambio del proceso, Aprobación del documento eInformación de soporte. El desarrollo del índice anterior debe contener la siguiente información:

Introducción. Las siguientes subsecciones dan una visión general del documento.

Propósito: Identifica el propósito del documento y el perfil de usuario al que está dirigido.
Alcance. En esta subsección:

Se identifica el nombre de los productos software que se van adesarrollar.
Se explica lo que hacen los productos y lo que no hacen.
Se describen las aplicaciones del software especificado, incluyendo beneficios y objetivos.
Se debe ser consistente con especificaciones similares de más alto nivel si existen, es decir, en el caso de que estas sean las especificaciones de un subsistema.
Definiciones, acrónimos yabreviaturas: Es un listado de las definiciones de todos los términos, acrónimos y abreviaturas necesarios para interpretar correctamente el SRS. La información puede ser proporcionada con referencias a apéndices.
Referencias:

Se da la lista completa de todos los documentos referenciados en cualquier lugar de la SRS.
Se identifica cada documento por título,versión, fecha y responsable de su redacción.
Se especifican las fuentes desde las que se pueden obtener las referencias.
Visión de conjunto: Describe la organización general de la SRS.
Descripción general: Describe los factores generales que afectan al producto y sus requisitos. No se definen requisitos específicos (sección 3), sólo su contexto.

Perspectiva delproducto: Relación del producto con otros similares. Si el producto es independiente y autocontenido se debe decir aquí. Si es un componente de un sistema mayor aquí deben estar los requisitos para que el sistema mayor lo pueda utilizar e identifica las interfaces entre el sistema y el software. Se puede poner un diagrama de bloques para mostrar las interconexiones del sistema con otros einterfaces externas.
Interfaces del sistema: Identifica la funcionalidad del software y la descripción de la interfaz. Especifica:

Características lógicas de cada interfaz entre el producto y sus usuarios.
Todos los aspectos relativos a la optimización de la interfaz con los usuarios.
Interfaces hardware: Se especifican las características de cada...