PUNTO 2.1

DECISIÓN DE TAREAS A PARTIR DEL ANÁLISIS

Después de analizar los requisitos que debe tener el programa, ahora se deben decidir las estructuras básicas que van a emplearse.

La fase de diseño podría reducirse a decidir qué estructuras de datos usar y en qué funciones descomponer el cuerpo del programa. Más adelante se estudiará una versión algo más elaborada del programa.

La estructura de datos del programa podría ser:

• Struct: lugar donde se almacena cada dato individual. Los struct individuales se almacenarán en un vector.

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

• mostrarMenu: muestra la lista de opciones disponibles conforma al prototipo visual.
• nuevaFicha: pide los datos de una nueva persona y los añade a la lista de contactos existentes.
• verFichas: muestra la primera ficha. Al pulsar ciertas teclas, el usuario podrá elegir entre consultar la ficha anterior, la posterior, modificar una actual o borrar la actual.
• modificar(n): pide los campos de la ficha que se indique como parámetro. Si se quiere cambiar un dato, se debe introducir el texto de los campos que se quieran modificar y si no se desea cambiar algún dato, bastará con pulsar Intro.
• intentarBorrar(n): solicita confirmación para borrar datos.
• buscarTexto: pide al usuario el texto que desea buscar, cuenta cuántas fichas lo contienen y las muestra de una en una. Después, da la opción de consultarla con mayor detalle, continuar (que no aparecerá si no existe ninguna ficha) o volver al menú.
• buscarCumplesMes: 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 20 datos, el programa hará una pausa cada 20 datos y esperará a que el usuario pulse Intro. No es necesario que los datos aparezcan ordenados por fecha.
• guardar: vuelca todos los datos a fichero. Para que los datos queden guardados antes de salir del programa, es necesario darle a esta opción. También se puede guardar después de cada modificación.
• cargar: lee todos los datos del fichero. Se debe llamar automáticamente al principio del programa.

PUNTO 1.3

REFINAMIENTO

Para que el proceso de especificación sea lo más correcto posible, en las empresas de desarrollo de software existe una figura del analista, que se encarga de hablar con el cliente, observar la forma en la que se trabaja, etc.

En las empresas pequeñas, se puede dar el caso de que no dispongan de analista y su facilidad para detectar las necesidades del cliente sea menor. Esto se soluciona con una segunda lectura pormenorizada de la especificación para afinar los detalles que inicialmente eran ambiguos. Por ejemplo, para el programa del apartado 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 pausa 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?
• Etc.

De esta forma, al realizar un proyecto real, es cada vez más común repetir la secuencia análisis-diseño-implementación-verificación, incluyendo reuniones con el cliente entre una secuencia y otra para que los errores y carencias del programa puedan ser descubiertos cuanto antes. Son muy necesarias las reuniones cada dos semanas aproximadamente porque evitan que haya que dar costosos paso atrás en caso de descubrir aspectos que no se hubieran entendido correctamente.