БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ОМСКОЙ ОБЛАСТИ
«ОМСКИЙ АВИАЦИОННЫЙ КОЛЛЕДЖ ИМЕНИ Н.Е. ЖУКОВСКОГО»

ЛЕКЦИЯ - БЕСЕДА
преподавателя Мирошниченко В.А.
по теме «Понятие и классификация офисных приложений»

МДК.01.02 Прикладное программирование

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

Оглавление

Понятие офисного приложения

Мы будем рассматривать довольно узкий класс программного обеспечения, а именно офисные приложения, иначе называемые приложениями для бизнеса (business applications), или системами автоматизации делопроизводства, или (самое старое название) автоматизированными системами управления (АСУ).

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

На какие группы можно разделить (классифицировать) программное обеспечение?

Идея разделения программ на прикладные и системные восходит к 60-м годам. В рафинированном виде это разделение впервые было проведено, видимо, в знаменитом проекте IBM OS/360. На первый взгляд способ разделения очень прост: прикладные программы предназначены для решения определенных задач и получения конкретных результатов, а системные программы предназначены для обеспечения работы прикладных программ. Например, операционная система - это системная программа, а программа расчета зарплаты - это прикладная программа, или приложение.

На этих экстремальных примерах различие очевидно, но это не всегда так.

Куда отнести какую-либо систему программирования?

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

В прежние времена такие программы, как трансляторы, было принято считать системными (например, так было в уже упомянутой OS/360), но сейчас чаще действует противоположная тенденция.

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

Что вы знаете о вертикальных и горизонтальных приложениях?

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

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

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

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

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

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

Плохие, хорошие и работающие программы

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

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

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

С этой точки зрения интересно посмотреть на объект нашего обучения - Microsoft Office XP. Являются ли приложения этого пакета наилучшими, не имеющими конкурентов в своих классах? Вопрос спорный, может оказаться, что читатель укажет и более привлекательные (со своей точки зрения) офисные приложения. Почему же Microsoft Office является наиболее широко используемым пакетом офисных приложений? Одна из важнейших причин заключается в том, что корпорация Microsoft постоянно ведет очень последовательное и тщательное исследование практики использования своих продуктов, а потому, разрабатывая новые программы, имеет в распоряжении адекватную информацию о фактических ожиданиях массового пользователя.

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

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

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

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

Отечественная аббревиатура ЭВМ (электронная вычислительная машина), равно как англоязычный эквивалент компьютер (computer), подразумевают, что определяющей является способность компьютера производить вычисления. Возможно, это и было так полвека с лишком тому назад, но сейчас это не так. Считать современный персональный компьютер большим калькулятором - очевидная нелепость.

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

Что же такое информация?

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

Какие формы существования информации можно выделить?

Знания рождаются и функционируют в обществе, проявляются во всех информационно - коммуникативных процессах, знания присущи субъекту и не отделимы от него.

Информация - это знания для других, отчужденные от их первоначального живого носителя и ставшие сообщениями доступными всегда и везде.

Данные - это формализованное и закодированное представление информации.

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

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

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

Что принято считать офисными приложениями для работы с документами, и что не принято? Прочитайте примеры приложений с указанием названий характерных документов, а Вы скажите, какие из них нельзя назвать офисными:

1. Расчет заработной платы (платежная ведомость, табель).

2. Обработка экспериментальных данных, например фотоснимков участков звездного неба, полученных через телескоп.

3. Резервирование билетов (билет).

4. Управление кадрами (личная карточка).

5. Управление автоматизированным производством, например подготовка программ для станков с числовым программным управлением (ЧПУ).

6. Медицинское обслуживание (история болезни).

7. Складской учет (накладная).

8. Операционная система, которая хранит, например, учетные записи пользователей.

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

Важной характеристикой приложений является их масштаб. Масштаб приложения - это качественная оценка размера приложения с точки зрения его использования. Что вы знаете о приложениях масштаба предприятия, групповых и настольных?

Обычно различают следующие градации размеров приложения:

• настольные (desktop);

• групповые (groupware);

• масштаба предприятия (enterprise).

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

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

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

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

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

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

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

Третий пример - установка приложения. Например, чтобы установить Microsoft Office XP на домашний компьютер, достаточно вставить компакт-диск и выполнить несложные инструкции, появляющиеся на экране. Чуть сложнее обстоит дело, если, например, Word 2002 используется как групповое приложение в вашем подразделении. Кроме сетевой установки для экономии места нужно еще позаботиться об обновлении специализированных шаблонов рабочей группы и т. д. Попробуйте на минутку представить себе, что вы будете делать, если вам нужно установить Word 2002 как приложение масштаба предприятия на 500 компьютерах в 10 филиалах, которые расположены в 5 часовых поясах!

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

Существует очень важный класс приложений - так называемые приложения реального времени. Как мы понимаем Реальное и Моделируемое время?

Устоявшееся выражение «программы реального времени» не совсем корректно, но его вполне можно использовать, если понимать, что стоит за этим выражением. Чтобы пояснить, в чем тут дело, рассмотрим несколько примеров из жизни.

Фразу "я гулял в парке 2 часа" все понимают однозначно: от момента начала гуляния до момента окончания гуляния прошло два часа или, что то же самое, процесс гуляния в парке продолжался два часа. Когда же мы говорим "программа работала 10 секунд", не совсем ясно, что имеется в виду. Скорее всего, подразумевается, что от момента запуска программы до момента ее завершения прошло 10 секунд. Но это не значит, что процесс выполнения программы продолжался 10 секунд. Дело в том, что в современных операционных системах применяется режим мультипрограммирования, когда несколько программ выполняются «квазипараллельно», т. е. сначала одна программа выполняется в течение очень короткого промежутка времени (он называется квантом времени), затем другая и т. д. Переключения происходят достаточно быстро, а квант времени достаточно мал, так что пользователю кажется, что программы работают одновременно. Это называется режимом разделения времени. Но при этом может оказаться, что программа, которая «работала 10 секунд» на самом деле занимала процессор компьютера выполнением своих команд 1 секунду.

Другой пример связан с моделированием различных физических процессов в компьютере. Многим, наверное, знакома забавная салонная игра "в мафию", когда ведущий дает команды: "наступил день", "наступила ночь", а играющие послушно открывают и закрывают глаза. Это отличный пример моделирования времени.

Приведите примеры моделирования времени в компьютере

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

Выражение «программа реального времени» подразумевает, что время учитывается в реальном масштабе, т. е. событие «прошла 1 секунда» в программе происходит действительно через 1 секунду после фактического начала ее работы.

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

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

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

Еще один пример. Наверняка на вашем компьютере установлено какое-то программное обеспечение для воспроизведения оцифрованного видео. Воспроизведение цифрового изображения требует значительного быстродействия программ и аппаратуры и должно происходить в реальном масштабе времени для создания иллюзии движущегося изображения. Что происходит, если программно-аппаратные средства воспроизведения видео не успевают обрабатывать кадры в нужном темпе? Да ничего особенного: некоторые кадры просто пропускаются. Качество, конечно, страдает, движение на экране недостаточно плавное, вы морщитесь и подумываете о приобретении более мощного компьютера или специальных аппаратных средств для воспроизведения видео, но вашей жизни, здоровью и имуществу ничто не угрожает, а потому все остается как есть до лучших времен. Сравните этот пример с примером про запуск ракеты - и вам станет ясно, что именно подразумевают, когда говорят, что работа в реальном масштабе времени критически важна для приложения.

Теперь, обсудив значения всех терминов, мы можем сформулировать определение офисного приложе6ния, ответив на вопросы:

• К какому классу ПО относится - прикладное или системное?

• Как разрабатывается - вертикальное или горизонтальное?

• Как оценивается масштаб этого приложения?

• Для чего предназначено?

• Насколько критически связано с реальным временем?

Итак, определение:

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

Классификация офисных приложений

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

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

Так, постепенно, к настоящему моменту выкристаллизовался определенный набор основных средств, наиболее часто используемых в офисных приложениях. Эта кристаллизация происходила не только в головах аналитиков, исследовавших данный вопрос, но обрела вполне конкретное материальное воплощение в форме пакетов офисных приложений, наиболее известным из которых является Microsoft Office.

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

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

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

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

Особенности разработки офисных приложений

Мы обсудили понятие «Офисное приложение» а теперь поговорим о тех особенностях процесса разработки, которые являются следствиями особенностей самих офисных приложений:

• Изменение требований

• Требуют постоянного сопровождения и модификации (т.к. подвержены постоянным изменениям)

• Использование библиотек объектов

• Быстрая разработка

• Экономия средств при внедрении приложений

Изменение требований

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

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

Разработчик обязан принимать во внимание три толкования ТЗ:

• То, которое предполагает разработчик.

• То, которое имеет в виду заказчик.

• То, которое отражает объективную потребность заказчика.

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

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

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

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

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

О формальных спецификациях

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

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

а ≠ 0 & Ь² - 4ас > 0 вместе с постусловием ах² + Ьх + с = 0 является исчерпывающим ТЗ на разработку приложения «Решение квадратного уравнения» (входные данные а, Ь, с, выходное данное х).

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

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

• Шутка:

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

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

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

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

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

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

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

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

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

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

Быстрая разработка

Офисные средства разработки поддерживают процесс быстрой разработки приложений (Rapid Application Development - RAD). Когда говорят о быстрой разработке приложений, имеют в виду отнюдь не язык программирования. На самом деле быстрая разработка приложений подразумевает быструю разработку прототипа приложения, причем таким образом, что в дальнейшем прототип приложения может быть преобразован в само приложение, а не выброшен безвозвратно.

Почему для офисных приложений так важна быстрая разработка прототипа?

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

Использование библиотек объектов

Как мы уже отметили, сам по себе язык программирования мало влияет на разработку, и утверждать, что VBA как-то необыкновенно хорош для программирования офисных приложений, а, скажем, C++ или Java как-то особенно плохи, было бы явно неверно. При решении общих вопросов программирования, таких как обработка исключительных ситуаций, проверка корректности вводимых пользователем данных, обеспечение надежного хранения данных и т. д., все распространенные языки примерно одинаковы, и предпочтение определяется субъективными вкусами программиста, а не объективными особенностями языка.

Но кроме собственно языка, в систему программирования входит и такая компонента, как библиотеки готовых объектов. С этой точки зрения Microsoft Office XP и VBA имеют подавляющее преимущество перед, скажем, Visual C++. Вместе с Microsoft Office XP и VBA разработчик получает в свое распоряжение огромное количество готовых программных компонентов, которые наилучшим образом приспособлены для решения именно офисных задач. Благодаря использованию технологий OLE и Automation разработчик может легко встраивать в свои приложения мощнейшие средства базовых приложений, причем с гарантированным успехом.

Например, общепризнано, что сводные таблицы Excel являются непревзойденным средством представления и анализа данных, а их программирование занимает всего несколько строк на VBA.

Экономия средств при внедрении приложений

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

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

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

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

• Загрузка данных. Это один из болезненных процессов при внедрении офисных приложений, и разработчики часто не учитывают его сложность. Мало проверить приложение на тестовых данных в среде разработки. Нужно обеспечить правильную работу на реальных данных пользователя. А здесь могут быть разные неожиданности. Дело в том, что офисные приложения очень редко начинают эксплуатироваться «с чистого листа». Как правило, какие-то приложения эксплуатировались до начала внедрения вашего приложения, данные обрабатывались и накапливались, и все эти данные требуется загрузить в новое приложение и использовать. Между тем в старых данных могут быть пропуски и ошибки, которые не сказывались на работе старого приложения, но немедленно проявят себя самым неприятным образом в новом приложении. Другая проблема связана с форматами данных. Если старое приложение было разработано не в среде офисного средства разработки, то вполне мог быть использован собственный «хитрый» формат данных (а описание этого формата утеряно). Разработчикам офисного приложения приходится создавать в таких случаях соответствующие конверторы для преобразования форматов. Если же используется офисное средство разработки, то большей части этих проблем не возникает. Нам неизвестны случаи, чтобы при использовании офисного средства разработки выдумывались бы собственные форматы данных - всегда используются стандартные форматы базовых приложений. Офисные средства обычно совместимы по данным сверху вниз, т. е. новая версия офисного средства разработки либо умеет работать непосредственно с данными в старом формате, либо содержит надежные средства преобразования старых данных в новый формат. Microsoft Office XP является прямо-таки образцово-показательным примером в этом отношении.

Проверь себя:

1. Офисное приложение относится к вертикальным или горизонтальным?

2. Должно ли офисное приложение работать в режиме реального времени?

3. Зачем разрабатываются прототипы?

4. Какие средства эффективнее всего применять для разработки офисных приложений?

2014 г.