Глава

Принципы разработки приложений электронных таблиц

Вэтой главе...

♦Этапы разработки приложения

♦Определение потребностей пользователя

♦Проектирование приложения с учетом потребностей пользователя

♦Определение удобного пользовательского интерфейса

♦Работа с конечным пользователем

♦Другие вопросы разработки приложений

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

Этапы разработки приложения

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

Как уже отмечалось в предыдущей главе, разработчики электронных таблиц несут от­ ветственность за соблюдение следующих требований:

•определение потребностей пользователя;

•планирование приложения, которое соответствует этим условиям;

•разработка наиболее подходящего интерфейса пользователя;

•создание электронной таблицы, формул, макросов и пользовательского интерфейса;

•тестирование и отладка приложения;

•изменение приложения с целью повышения его надежности и отказоустойчивости (часто по результатам тестирования);

•эстетическая привлекательность и интуитивная ясность приложения;

•документирование усилий, затраченных на разработку;

•разработка пользовательской документации и справочной системы;

•размещение приложения в компьютере пользователя;

•обновление приложения в случае необходимости.

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

Определение потребностей пользователя

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

впервую очередь.

Вотдельных случаях вы можете быть близко знакомы с конечными пользователями

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

Каким образом можно рпределить потребности пользователей? Если вам необходимо разработать приложение электронной таблицы, встретьтесь с потенциальными пользова­ телями и опросите их. А еще лучше — изложите пользователям свое видение разрабаты­ ваемого приложения в виде печатных документов, создайте блок-схему, уделите внима­ ние мелким деталям и сделайте все, чтобы создать именно такое приложение, какое нужно пользователю.

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

•Не убеждайте себя в том, что уже знаете потребности пользователей. Если на этом этапе основываться на предположениях, в дальнейшем неизбежно возникнуть проблемы.

•Если существует такая возможность, говорите непосредственно с потенциальны­ ми клиентами приложения, а не только с руководителем проекта или управляю­ щим фирмы.

•Узнайте, что уже сделано (если только сделано) для удовлетворения потребностей пользователей. Вы, возможно, сэкономите часть своего времени, переделав суще­ ствующее приложение. В крайнем случае, изучая имеющиеся решения, вы более подробно изучите работу конечных пользователей.

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

•По возможности, определите все типы систем, в которых будет запускаться ваше приложение. В случае, если приложение будет выполняться в низкопроизводи­ тельных системах, примите этот факт к сведению. Для получения дополнительных сведений по этой теме обратитесь к разделу “Быстродействие системы”.

•Узнайте, какая версия (или версии) Excel используется в системе. Компания Microsoft делает все возможное, чтобы убедить пользователей применять послед­ ние версии выпускаемых ею программ. Однако по результатам проведенного оп­ роса последние версии пакета Microsoft Office доступны менее чем половине всех пользователей этого пакета.

•Узнайте уровень квалификации конечных пользователей. Эта информация помо­ жет вам правильно разработать приложение.

•Определите, как долго будет использоваться приложение и нужно ли будет его изме­ нять. Это повлияет на выполняемые операции и поможет спланировать изменения.

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

Проектирование приложения с учетом потребностей пользователя

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

Прежде чем закатать рукава и сесть за клавиатуру, обдумайте разные способы, кото­ рые помогут приблизить решение проблемы. Вот здесь как раз и окупится глубокое по­ знание возможностей Excel! Всегда лучше обойти незнакомые закоулки стороной, чем блуждать в них.

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

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

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

Обучение в процессе разработки

Теперь несколько слов о реальном положении дел. Excel — программа изменчивая. Период между ее обновлениями составляет от 18 до 24 месяцев. Это означает, что в ва­ шем распоряжении менее двух лет, чтобы справиться с текущими инновациями, иначе вам придется бороться не только с ними, но и с другими нововведениями.

Программа Excel 5, которая подарила нам VBA, стала для разработчиков Excel “изменением парадигмы” управления данными. Ранее тысячи людей зарабатывали се­ бе на жизнь, создавая приложения Excel, которые в основном писались на макроязыке XLM, представленном в версиях Excel 2, 3 и 4. Начиная с Excel 5 стали доступными де­ сятки новых инструментов, которые активно используются разработчиками.

С появлением программы Excel 97 разработчики столкнулись с еще одной “сменой парадигмы”. В этой версии появился новый формат файлов, редактор языка Visual Basic Editor (VBE) и пользовательские формы, которые пришли на смену диалоговым листам. В Excel 2000, 2002 и 2003 появилась новые возможности, которые были уже не столь радикальными, как в предыдущих версиях.

Программа Excel 2007 — это огромный шаг вперед по сравнению с предыдущими версиями, и основная проблема связана с появлением нового “ленточного” интерфей­ са пользователя. Ранее создание пользовательских меню и панелей инструментов бы­ лоотносительно простым и могло выполняться исключительно средствами VBA. Теперь же изменение ленты требует дополнительной работы, причем не только с помощью VBA. Кроме того, следует учитывать новые форматы файлов. Исходя из этого, я реко­ мендую создавать две версии приложения: для Excel 2007/2010, а также для Excel 2003 и более ранних версий.

Язык VBA изучить несложно, но потребуется время, чтобы почувствовать себя ком­ фортно: для совершенного овладения этим языком придется приложить немало усилий. Развитие VBA продолжается. Следовательно, не удивительно, что, разрабатывая с помо­ щьюVBA приложения, вы одновременно изучаете этот язык. Более того, изучить VBA не­ возможно, если вплотную не заниматься разработкой приложений. Намного проще изу­ чить VBA, имея проект, для реализации которого требуется исключительно этот язык. Изучение VBA ради “любви к искусству” вряд ли приведет к серьезным результатам.

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