Decisión de tareas a partir del análisis.

El siguiente paso consiste en decidir las estructuras básicas que van a emplearse para llevarlo a cabo.

La estructura de datos del programa podría ser la siguiente:

• Cada dato individual se almacena en un struct. Para que se pueda guardar tantos datos como se desee, los struct individuales se almacenarán en un vector.

Y las funciones en las que se descompondrían podrían ser estas:

• mostrarMenu: muestra la lista de opciones disponibles conforme al prototipo visual.
• nuevaFicha: pide los datos de una nueva persona y los añade a la lista de contactos existentes.
• verFichas: muestra en pantalla la primera ficha. Al pulsar sobre ciertas teclas el usuario podrá elegir consultar la ficha anterior (si existen), la posterior, modificar la actual (función adicional)  o borrar la actual  (otra función).
• modificar(n): pide los campos de la ficha que se indique como parámetro. Si se desea cambiar un dato, se tiene que volver a introducir el texto de los campos que se quieran modificar. En cambio, si no se desea, bastará con pulsar Intro para conservarlo como estaba.
• intentarBorrar(n): solicita confirmación para borrar datos.
• buscarTexto: pide al usuario el texto que desea buscar, cuenta cuántas fichas lo contienen y, finalmente, las muestra de una en una. 
• buscarCumpleMes: muestra las fechas de nacimiento y los nombres y apellidos de las personas que cumplen años en un cierto mes. Si hay más de veinte datos, el programa hace una pausa y espera a que el usuario pulse Intro. 
• guardar: vuelca todos los datos a fichero, reemplazando el contenido anterior de dicho fichero.
• cargar: lee todos los datos desde fichero. Se debe llamar automáticamente al principio del programa.

Creación de clases a partir de análisis.

Se puede optar por separar la parte visual (aplicación principal) de la parte lógica (la lista de personas), de modo que se pudiera reutilizar la mayor cantidad posible de código en caso de que se creara otra versión del programa en un entorno gráfico (por ejemplo, Windows Forms). Para ello podemos crear una clase ListaPersonas que se encargue de cargar y guardar datos de cada persona que pasarían de ser un struct a ser una clase con los mismos campos, pero añadiendo métodos que permitieran obtener y fijar los valores y simplificar las búsquedas de esos campos.

Diagramas de casos de uso.

Un documento de especificación puede resultarle incomprensible a un cliente que no tenga conocimientos de programación informática, por lo tanto, es preferible elaborar diagramas que muestren los principales requisitos de manera más visual. Un Ejemplo es el diagrama de casos de uso.
En ellos el sistema se representa como un rectángulo, las acciones que se pueden realizar dentro de elipses y se dibujan figuras para simbolizar a cada tipo de persona. Ellas pueden interactuar con el sistema.
Por ejemplo, una versión mejorada del programa de la agenda de contactos podría incluir al usuario normal, que podría ver y manipular datos, pero también a un administrador, que consulta y añade datos.
Así quedaría:

Análisis

1.3 REFINAMIENTO.

En las empresas de desarrollo de software suele existir la figura del analista, encargado de hablar con el cliente, observar la forma en que este trabaja y formular las preguntas para que el proceso sea correcto.

No obstante, es posible que en las empresas pequeñas no exista la figura de analista y no tengan experiencia para identificar las necesidades del cliente. En estos casos, una segunda lectura pormenorizada de la especificación puede afinar los detalles.

Y para el programa anterior se podrían detectar las siguientes carencias:

• ¿No se podrán consultar los datos si no se hace una búsqueda?
• ¿Qué datos de cada persona que se encuentre a través de las búsquedas de texto deben mostrarse? ¿Se debe hacer una pauta tras la inserción de n datos o de cada dato? ¿Las búsquedas deben distinguir entre mayúsculas y minúsculas?
• ¿Qué datos de cada persona que cumpla años deben mostrarse?
• ¿Los datos se guardarán automáticamente o deberá seleccionarse para ello, una opción determinada del menú?
• ¿Es necesario guardar los datos en fichero usando algún formato específico o no van a compartirse con ninguna otra aplicación?
• ¿No será necesario modificar ni borrar datos?

Así, en la realización de un proyecto real, es habitual repetir varias veces la secuencia análisis-diseño-implementación-verificación. Un proceso que incluye reuniones con el cliente para que se detecten los errores y carencias del programa cuanto antes. En proyectos duraderos se conciertan reuniones cada dos semanas para evitar retroceder y arreglar esos pasos equivocados.

1.4 PROTOTIPOS VISUALES.

Una herramienta que puede ser útil para ayudar a la detección de errores en la especificación de requisitos son los prototipos visuales. Estos consisten en la creación de "maquetas" de pantalla con las que se muestra al cliente una idea aproximada de cómo va a ser el resultado a nivel visual.

Así, los prototipos visuales permiten al usuario detectar si falta algún detalle o si el vocabulario es incorrecto.

Análisis

1. CARACTERÍSTICAS DEL ANÁLISIS DE REQUISITOS.

Si se desea crear un programa en un tiempo limitado y con unos costes limitados, el primer paso es pensar qué tareas debe realizar. Para un programa por encargo este es un paso de mucha relevancia.

Crear una lista con los requisitos que debe cumplir el programa favorece la determinación de qué tareas son más importantes y de cuáles no deben hacerse.

Este último aspecto es muy importante, pues permite evitar que el programa crezca indefinidamente por el hecho de que el cliente o usuario desee añadir nuevas características cada cierto tiempo.

Cuando ya se ha estimado el tiempo y el presupuesto del proyecto, las características que cliente desee deben ser de una versión posterior, lo que hace volver a calcular el tiempo y los recursos necesarios.

1.2  ESPECIFICACIÓN.

Normalmente para elaborar un un programa se anotan los requisitos que debe cumplir. Pero para una aplicación real, se distingue entre los requisitos funcionales (lo que el programa hará) y los requisitos técnicos (las limitaciones físicas como el sistema operativo de destino, el espacio que ocupará el programa, etc). 

Para un programa que no sea muy complejo se podría basar a partir de la siguiente lista:

• El programa será una agenda de contactos que permitirá guardar datos de personas para poder consultarlos más adelante.
• Deberá almacenar, para cada persona, el nombre, los apellidos, la fecha de nacimiento, el domicilio y el correo electrónico. El dato obligatorio es el nombre, el resto son opcionales.
• Permitirá guardar una cantidad elevada de datos.
• Los datos deberán guardarse en fichero para que se pueda disponer de ellos cada vez que se acceda al programa.
• Permitirá buscar datos a partir de cualquier palabra introducida en la búsqueda. Por ejemplo, si se introduce la palabra "Vicente", aparecerán todas aquellas personas que incluyan esa palabra en su nombre, sus apellidos, su domicilio o su correo electrónico.
• Buscará las personas que cumplan años en los próximos treinta días.
• El programa deberá haberse creado en C++ y permitirá trabajar en modo texto, de forma que se pueda compilar tanto para Windows como para LliureZ o para cualquier otra versión de Linux.