2.2 CREACIÓN DE CLASES A PARTIR DE ANÁLISIS
Para algunos programas, una descomposición de clases estaría forzada ya que su nivel de complejidad no es tan elevado como para justificarla.
Se puede optar por separar la parte visual de la parte lógica de modo que se pueda reutilizar la mayor cantidad de posible de código en caso de que más adelante se creara otra versión del programa del entorno gráfico.
Para ello es posible, crear una clase de ListaPersonas que se encargue de cargar y guardar datos. D esta manera, los datos de cada persona pasarían de ser un struct a ser una clase que tendriía los mismo campos, pero añadiría métodos que permitieran obtener y fijar os valores de esos campos.

2.DISEÑO

2.1 DECISIÓN DE TAREAS A PARTIR DEL ANÁLISIS 
Una vez analizados los requisitos que debe cumplir el programa, el siguiente paso consiste en decidir las estructuras básicas que se van a emplear.

La estructura de datos del programa podría ser:
-Cada dato individual se almacena en un struct. Para guardar tantos datos como se desee, los struct individuales se almacenan en un vector.

Y las funciones en las que se descompondría serían:
-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.
-modificar(n): pide los campos de la ficha que se indique como parámetro.
-intentarBorrar(n): solicita confirmación para borrar los datos.
-buscarTexto: pide al usuario el texto que desee buscar, cuenta cuántas fichas lo contienen, y finalmente se las muestra de una en una.
-buscarCumpleMes: muestra las fechas de nacimientos y los nombres y apellidos de las personas que cumplas años en un cierto mes. También se le proporciona los daos opcionales que esa persona haya querido incluir.
-guardar: vuelva todos los datos al fichero, reemplazando el contenido anterior de dicho fichero.
-cargar: lee todos los datos desde fichero.

1.5 DIAGRAMAS DE CASOS DE USO.
Es frecuente la elaboración de diagramas que muestren los principales requisitos del programa de una forma más visual. El más habitual es el diagrama de casos de uso.
En estos diagramas, el sistema se representa como un rectángulo, las acciones se incluyen dentro de elipses con figuras que simbolizan cada tipo de personas, que reciben el nombre de "actores".

1.3 REFINAMIENTO.
En las empresas de desarrollo de software, existe la figura del analista, experto encargado de hablar con el cliente, observar en que este trabaja y formular las preguntas adecuadas para que el proceso de especificación sea lo más correcto posible.
En empresas pequeñas es posible que no exista la figura del analista. Por ejemplo, para el programa anterior, se podrían detectar las siguiente carencias: ¿No se podrán consultar  los datos si no se hace la búsqueda?, ¿Que datos de cada persona que cumpla años deben mostrarse?,etc.
En la realización del proyecto es cada vez más habitual repetir la secuencia análisis-diseño-implementación-verificación.

1.4 PROTOTIPOS VISUALES.
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.
Los prototipos visuales permiten al usuario detectar si falta algún detalle o si el vocabulario es incorecto.

Prototipo visual interactivo

TEMA 7: ANÁLISIS, DESARROLLO Y PRUEBA DE APLICACIONES.

1.1 CARACTERÍSTICAS DEL ANÁLISIS DE REQUISITOS.
Si desea crear un programa en un tiempo limitado y con unos costes limitados, el primer paso es pensar, que tareas se debe realizar.
Crear una lista con los requisitos que se deben cumplir el programa, para determinar las tareas importantes y las que no debemos hacer. Este aspecto es muy importante en un proyecto.
Una vez que se ha estimado el tiempo necesario y se ha aprobado el presupuesto del proyecto, se anotan las características del cliente y comienza a realizarse.

1.2 ESPECIFICACIÓN
Es habitual elaborar un documento en el que se recopilen los requisitos que debe cumplir el programa. Para una app real es habitual distinguir los requisitos funcionales.

Por ejemplo, para un programa no muy complejo se pueden distinguir:

-El programa será una agenda de contactos que permitirá guardar datos de personas para poder consultarlos.
-Deberá almacenar el nombre, apellidos, fecha de nacimiento, domicilio y correo electrónico.
-Permitirá guardar una cantidad elevada de datos.
-Los datos deberán guardarse en el fichero para que se pueda disponer de ellos cada vez que el programa quiera acceder.