Материал: Программирование на языке Visual Basic для приложений. Подвальный С.Л., Рог А.И

спективна и, как правило, она является признаком некомпетентности разработчика.

С другой стороны, изменения не могут быть совершенно произвольными. Нормальным является изменение ТЗ в форме конкретизации, детализации и дополнений. Если же заказчик то и дело меняет одни неясные пункты на другие, не менее туманные, то это явный признак недобросовестности заказчика.

9.2. Прототип приложения

Из сказанного в предыдущем разделе ясно, что иногда бывает очень трудно исчерпывающим образом определить офисное приложение до начала разработки так, чтобы заказчик, прочитав ТЗ, сказал: "да, это то, что мне нужно" и потом подтвердил свое мнение, глядя на готовое приложение после окончания разработки. Требовать этого от заказчика неразумно, он просто не может предвосхитить все следствия того, что написано или нарисовано в ТЗ.

С другой стороны, если предъявить заказчику некоторое приложение, то он без колебаний может ответить на вопрос: "это то, что нужно, или нет?". Более того, как правило, работая

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

Учитывая эту ситуацию, при разработке офисных приложений используется следующий прием. Получив ТЗ, разработчик как можно быстрее создает некоторую версию приложения, называемую прототипом. Прототип должен быть похож на разрабатываемое приложение, но не обязан им являться. Например, это может быть только интерфейс будущего приложения или интерфейс и несколько ключевых функций. Заказчик знакомится с прототипом и говорит: "Да, это то, что нужно, можно отливать в металле" или "Нет, это не то, здесь, здесь и здесь нужно изменить". После этого, с учетом замечаний заказчика, корректируется ТЗ и начинается работа над основным вариантом приложения. Очень важно, что при работе

спрототипом, в отличие от бумажного ТЗ, заказчик, как правило, может дать точные и детальные поправки к ТЗ.

148

Хотя построение прототипа требует заметных дополнительных затрат, но зато прототип радикально сокращает количество пересмотров ТЗ. Обычно достаточно одной версии прототипа, чтобы выявить все необходимые изменения в постановке задачи. В результате разработка прототипа может даже дать экономию и сократить сроки по сравнению с тем, когда сразу начинается работа над основным приложением.

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

9.3. Интерфейс пользователя

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

Во-первых, с ростом возможностей персональных компьютеров все более широкое распространение получает гра-

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

Фактически в области офисных приложений графический интерфейс вытеснил другие виды интерфейса и все новые офисные приложения снабжаются графическим интерфейсом. Разработчики вынуждены считаться с "избалованностью" пользователей офисных приложений и тратить немалые усилия на программирование графического интерфейса.

Во-вторых, постепенно исчезает (если уже не исчез совсем) особый слой людей, которые во времена господства больших машин (mainframe) стояли между потребителями данных офисных приложений и офисными приложениями. Эти посредники назывались по-разному, в нашей стране была даже

149

такая специальность: "оператор ЭВМ". Суть дела состояла в том, что эти люди специальным образом готовились к работе с офисными (и другими) приложениями, а потому могли легко адаптироваться к особенностям их интерфейса. От оператора ЭВМ можно потребовать, чтобы он нажимал правильные кнопки в правильном порядке, в точности так, как это нужно при работе с данным приложением.

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

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

фактами.

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

9.4. Артефакты офисных приложений

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

150

бочно полагают, что всегда верно и обратное, то есть что если есть код программы (есть формы, есть процедуры, все это запускается и как-то работает), то офисное приложение готово. Иногда это утверждение бывает верным: например, если студенческое упражнение по программированию запускается и выдает более или менее правдоподобные результаты, то преподаватель может поставить удовлетворительную оценку. Но для реального офисного приложения ни в коем случае нельзя считать, что как-то работающего кода достаточно и дело сделано.

Рассмотрим артефакты для офисных приложений масштаба предприятия. Трудозатраты на создание артефактов сопоставимы. Другими словами, кодирование, может быть, и является самой трудоемкой частью разработки, но составляет отнюдь не львиную долю общих трудозатрат — не более 20%.

Техническое задание (ТЗ) — это описание того, что должна делать система для пользователя. Данный артефакт называют по-разному: спецификации, требования (от английского названия данного понятия — requirements). Суть этого артефакта:

ТЗ является техническим (не финансовым и не организационным) документом, описывающим решаемую задачу;

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

ТЗ может принимать разные формы:

обычный текст на естественном языке;

диаграммы использования;

ссылка на уже работающее унаследованное приложение, которое нужно изменить и (или) расширить.

Словарь предметной области — часто упоминаемое, но очень плохо определенное понятие объектно-ориентирован- ного анализа и проектирования. Все теоретики объектноориентированного подхода единодушно утверждают, что словарь предметной области — важнейший артефакт, лежащий в

151

основе анализа и проектирования. Правильный научный подход к любой задаче требует сначала договориться о терминах.

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

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

Прототип — это модель графического интерфейса пользователя. Для современных офисных приложений графический интерфейс является неотъемлемой частью.

Код программы. Мы относим к коду все, что подлежит интерпретации компьютером во время выполнения приложения. Таким образом, кодом является не только текст программ на языке VBA, но и макеты форм и отчетов, запросы к базе данных на языке SQL, значения свойств элементов управления, страницы доступа к данным, даже поля в документах

Word.

Программная документация. Документация к про-

граммам необходима. Недокументированные программы долго не живут — кадровые изменения в организации-разработчике

инеизбежные изменения в требованиях к программе приводят недокументированные программы к быстрой и бесславной гибели. Это досадно и экономически невыгодно.

Понятие программной документации достаточно широ-

ко. Комментарии в программах, пояснительные тексты на естественном языке, схемы и диаграммы, поясняющие структуру

иповедение программ, — все это примеры программной документации.

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

152