Этап 7. Тестирование и усовершенствование

 

После завершения работ по отдельным компонентам приложения необходимо проверить функционирование приложения в каждом из возможных режимов.

Работу макросов можно проверить, используя пошаговый режим отладки, при котором на каждом шаге будет выполняться одна конкретная микрокоманда.

При использовании Visual Basic можно задействовать разнообразные средства отладки, позволяющие проверить работу приложения и исправить ошибки.

По мере разработки автономных разделов приложения желательно передавать их пользователям для проверки функционирования и получения мнения о необходимости тех или иных изменений. В процессе знакомства с работой приложения у пользователей практически всегда возникают дополнительные предложения по усовершенствованию, какой бы тщательной ни была предварительная проработка проекта. Часто обнаруживается, что некоторые средства, о которых в процессе постановки задачи говорили как об очень важных и необходимых, на самом деле практически не используются. Выявление необходимых изменений на ранних стадиях разработки приложения позволит существенно сократить время на последующие переделки.

Передача приложения в эксплуатацию отнюдь не означает, что процесс усовершенствования завершен. Большинство разработчиков программного обеспечения после окончания работы над очередной версией часто видят возможность дальнейшего улучшения и расширения возможностей программного продукта. При значительных переработках приложения, чтобы оценить воздействие необходимых изменений на приложение в целом и внести дополнения в предыдущую версию наиболее безболезненным способом, вполне возможно вновь придется вернуться к первому этапу.

 

Стратегия разработки проекта приложения

 

При разработке приложений СУБД используются два подхода: проектирование сверху вниз, при котором разработка приложения начинается с определения основных функций и задач, и проектирование снизу вверх, при котором сначала проводится анализ данных и определение их структуры. Рассматриваемый метод включает идеи обоих подходов.

Начнем с определения задач и их группировки, что поможет решить, можно ли ограничиться одной базой данных (подход “сверху вниз”). Базы данных привязываются к решению определенных, связанных между собой групп задач или функций. Для каждой задачи определяется набор необходимых данных. Затем собираются все поля данных для связанных задач, и начинается процесс формирования объектов (элементы подхода “снизу вверх”). Данные каждого объекта являются основой для включения в базу данных отдельной таблицы.

Анализ требований (Needs Analysis) - это процесс формулирования проблемы и перевода ее в ряд более детализированных формулировок. Эти формулировки помогут определить, какую информацию необходимо хранить в базе данных и какие функции должно выполнять приложение.

Например, фраза “Мне нужно знать цвет коллекционной игрушки” означает, что база данных должна хранить цвет каждой игрушки.

Некоторые требования к приложению могут также выражаться в виде действий. Например, фраза “Мне нужно напечатать отчет, включающий все пункты инвентарного списка” является хорошим определением действия, которое должно выполнять приложение.

Рассматриваемый пример основан на учебном приложении Microsoft Press Books, отдельные фрагменты которого можно будет воссоздать при изучении архитектуры и возможностей Microsoft Access.