К началу 80-х гг. XX в. сложилась схема проектирования (рис. 9.1), которую сейчас называют каскадной. Каскадная схема предполагает переход к следующему этапу после полного окончания работ по предыдущему этапу.
Этапы проектирования распределенных систем
Процесс проектирования систем распределенной обработки данных (СРОД) включает следующие этапы:
1) выявление информационных потребностей конечных пользователей;
2) концептуальное проектирование;
3) разработка архитектуры СРОД;
4) логическое проектирование;
5) отладка и тестирование прикладных программ;
6) сопровождение.
На первом этапе на основе анализа ПО строится функциональный граф, связывающий функции будущей системы с входными и выходными данными. Выходные данные одной функции могут служить входными для других.
Большинство универсальных компьютеров имеют архитектуру фон Неймана, предполагающую разделение процессов и данных. Это вынуждает разработчиков систем уже после первого этапа проектирования отделять данные от функций. Далее работы по проектированию схем данных и процессов (задач) выполняются как бы параллельно, что является источником многих противоречий.
На втором этапе данные структурируются в КС БД, а функции объединяются в задачи будущей системы. При разработке КС БД проектировщик руководствуется следующими абстракциями: агрегацией, обобщением, ассоциацией. Концептуальная схема БД изображается ERD-диаграммами (диаграммы Чена или Баркера). На этом этапе также разрабатываются спецификации будущей системы, т.е. определяются входные и выходные данные и алгоритмы связей между ними. Концептуальный проект не зависит от реализации и отражает содержательную сторону будущей системы.
|
|
На этапе разработки архитектуры СРОД решаются следующие задачи:
Рис. 9.1. Этапы проектирования распределенной системы
• осуществляется выбор структуры комплекса технических средств
(КТС);
• определяется состав общесистемных пакетов (ОС, СУБД и др.);
• выполняется распределение задач по машинам СРОД.
На этапе логического проектирования выполняется отображение КС БД и спецификаций прикладных задач в СУБД-ориентированную среду. При этом КС БД преобразуется в логическую схему БД, а спецификации задач – в ПП на конкретном языке. Проектирование систем распределенной обработки данных по рассмотренной схеме довольно часто приводило к неутешительным результатам: сразу после внедрения они признавались морально устаревшими.
Кризис проектирования
В начале 80-х гг. XX в. Дж. Мартином были проведены исследования причин кризисной ситуации, которая сложилась к этому моменту в области проектирования ИС. Им было проанализировано большое число разработок и построены диаграммы распределения ошибок по этапам цикла проектирования систем и затрат на их устранение. Это показало, что больше всего ошибок (56%) допускается при выявлении информационных потребностей пользователей и на этапе концептуального проектирования, т.е. еще до реализации проекта. На их устранение требуется 82% затрат от общего объема издержек на устранение ошибок проектирования. Эта тенденция носила довольно устойчивый характер.
На основании этих результатов Дж. Мартин сформулировал принцип неопределенности в информатике: процесс автоматизации задач, которые пользователь хочет решать с помощью системы обработки данных, изменяет его представление об этих задачах. Другими словами, процесс внедрения информационной системы корректирует требования к этой системе. Этот принцип указывает на обратное влияние информационных технологий (Information Technology – IT) на реконструкцию бизнес-процессов (Business Process Reengineering – BPR), т.е. средствами вычислительной техники пользователь решает свои задачи иначе, чем без их использования. В 1995 г. В.П. Меллинг сформулировал выводы о взаимосвязи IT и BPR, которые, по существу, являются обобщением принципа неопределенности Мартина:
|
|
1) существует двунаправленное воздействие бизнес- и ИТ-платформы предприятия;
2) если бизнес- или ИТ-платформа меняется, то маловероятно, что соответствующая наследуемая ИТ-архитектура предприятия сохранится;
3) соответствие между бизнес- и ИТ-архитектурой является решающим фактором успеха, но это требует значительного времени.
В середине 90-х г. XX в. была разработана новая схема (модель) проектирования СРОД, учитывающая выводы Меллинга, – спиральная.
Макетирование системы
На разработку новой модели проектирования СРОД повлияли следующие три феномена.
Феномен персональных вычислений, основанный на постоянной доступности сотрудников к персональным компьютерам. Феномен состоит в том, что во многих видах информационных, проектных и управленческих работ исчезла необходимость в работниках-исполнителях (машинистках, чертежниках, делопроизводителях и др.), являющихся посредниками между постановкой задачи и ее решением.
|
|
Феномен кооперативных технологий,состоящий в компьютерной поддержке совместной согласованной работы группы разработчиков над одним проектом. Этот феномен возник на основе совокупности методов, обеспечивающих управление доступом членов группы к разным частям проекта, управление версиями и редакциями проектной документации и согласованным выполнением работ в последовательной процедуре работ, управление параллельным конструированием и др.
Феномен компьютерных коммуникаций,состоящий в резком увеличении возможностей обмена любой информацией. Он появился, в частности, на основе стандартизованных протоколов обмена данными прикладного уровня в локальных и глобальных сетях. Это позволило исключить необходимость передачи бумажных документов для получения согласия или содержательных замечаний, ненужные переезды для проведения совещаний, обеспечить постоянную готовность работника получить и отослать сообщение или информационные записи данных вне зависимости от места его географического расположения и др.
Влияние первого феномена проявилось в широком использовании текстовых и графических редакторов, электронных таблиц, СУБД для настольных систем и других специализированных пакетов. При решении задач проектирования систем распределенной обработки данных (СРОД) стали использовать CASE-продукты, для работы с которыми не требуются навыки в программировании. При этом следует соблюдать следующие правила.
1. Важно с самого начала правильно выбрать общесистемное программное обеспечение (ОС, СУБД, CASE-продукты и др.). Использование на предприятии единой платформы общесистемных средств существенно облегчает модификацию и стыковку приложений на следующих этапах разработки.
2. Нельзя затягивать процесс выявления информационных потребностей по следующим причинам:
• часто пользователь видит только свою ПО и многие подразделения пытаются обособиться (мой сервер, моя сеть, мне больше ничего не надо),
• многие сотрудники инертны, не инициативны и пытаются использовать только простые средства (текстовый редактор).
3. После выявления информационных потребностей доработка проекта должна вестись централизованно профессиональными разработчиками в контакте с конечными пользователями.
Влияние второго феномена при проектировании СРОД проявляется в параллельной разработке нескольких подсистем. Причем разработка каждой подсистемы носит спиралевидный характер (рис. 9.2). Следует отметить, что здесь разделение работ на этапы 1–6 (см. рис. 9.1) является условным. Схема организации работ должна планироваться как адаптивная, а не как каскадная, т.е. все работы могут входить в глобальные проектные итерации, а также выполняться параллельно.
Рис. 9.2. Спиральная параллельная модель разработки информационной системы
Контрольные вопросы
1. Назовите основные этапы проектирования распределенных систем и охарактеризуйте их.
2. Какие задачи решаются на этапе разработки архитектуры СРОД?
3. Какие правила должны соблюдаться при проектировании с использованием CASE-продуктов?