Глава 2. Основные принципы разработки приложений

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

Процесс организации работы должен отвечать некоторым общим принципам:

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

– превращение компьютера в центральное звено документооборота предприятия, устранение «устаревших» действий и «лишних» шагов (использование «живых» документов, минимизация «бумажного» документооборота).

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

– определение задач;

– определение сценариев для каждой задачи;

– анализ сценариев;

– группировка функциональности по этапам постановки;

– тестирование.

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

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

Цель анализа сценариев состоит в распределении функциональности по компонентам приложения. Приложение должно быть разбито на небольшие компоненты, тога его легче разрабатывать и сопровождать. Код компонентов приложения необходимо комментировать. Если процедура или функция вызывается из других процедур, в комментариях необходимо перечислить их все. Это поможет при внесении изменений.

Если приложения разрабатываются на основе базовых приложений, то их поставку можно осуществлять «по частям». Для этого необходимо распределить работу по этапам так, чтобы обновления версий происходили «гладко», т. е. без переучивания пользователя и повторного ввода информации.

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

Разработка приложения является итерационным процессом, приложения могут дорабатываться и улучшаться постоянно. Лучшие приложения строятся «с прицелом на будущее»: они могут модифицироваться и наращиваться разработчиками, причем нет необходимости все начинать «с нуля».