Серия
• Высшее образование •
Т.В. Гвоздева, Б.А. Баллод
ПРОЕКТИРОВАНИЕ
ИНФОРМАЦИОННЫХ
СИСТЕМ
Рекомендовано Учебно-методическим объединением вузов Российской Федерации по образованию в области прикладной информатики в качестве учебного пособия для студентов высших учебных заведений, обучающихся по специальности «Прикладная информатика»
БИБЛИОТЕК *
Волгодонский институт сервис' ЮРГУЭС
Ростов-на-Дону «Феникс» 2009
УДК 004(075.8)
ББК32.973я73
КТК21
Г25
Научный редактор
доктор физико-математических наук, профессор
Ф.Н. Ясинский
Рецензенты:
доктор экономических наук, профессор В.Н. Щуков (ГОУВПО «Ивановский государственный университет»);
доктор технических наук, профессор С. П. Бобков
(ГОУВПО «Ивановский государственный химико-технологический университет»)
Гвоздева Т.В.
•^5 Проектирование информационных систем: учеб, пособие / Т.В. Гвоздева, Б.А. Баллод. — Ростов н/Д : Феникс, 2009. — 508 с. : ил. — (Высшее образование).
ISBN 978-5-222-14075-8
В учебном пособии представлены этапы разработки информационной системы в соответствии с ГОСТами; различные подходы к проектированию информационных систем; современные технологии и методологии проектирования; методы и средства проектирования систем; характеристика применяемых технологий проектирования; методики планирования и управления проектами на каждой стадии проектирования; CASE-технологии автоматизированного проектирования; архитектуры информационных систем. Рассмотрены практические примеры используемых методологий в средах BPwin, ERwin, Ration Rose и MS Project.
Предназначено для студентов специальности «Прикладная информатика», изучающих одноименную дисциплину. Может быть полезно специалистам, занимающимся проектированием и эксплуатацией информационных систем.
ISBN 978-5-222-14075-8	УДК 004(075.8)
ББК 32.973я73
© Гвоздева Т.В., Баллод Б.А., 2009
© ООО «Феникс», оформление, 2009
Предисловие |
Современный этап развития цивилизации характеризуется необычайным динамизмом смены всех основных ее параметров, от целевых установок и до инструментария их достижения. На каждом эволюционном этапе человечеством осознавалась та или иная проблема как наиболее значимая. В настоящее время к наиболее актуальной можно отнести проблему разработки технологии крупномасштабных систем автоматизированного хранения и обработки информационных ресурсов.
В связи с увеличением масштабов и структурной сложности систем управления процессы алгоритмизации обработки данных сталкиваются со значительными трудностями. В пособии исследуется проблема структурного и объектного проектирования информационных систем. Сложность данной задачи заключается в построении информационных систем в слабоструктурированных и динамично изменяющихся предметных областях, характеризующихся большими объемами информационных потоков и их неполнотой. При этом, как правило, количественные характеристики предметных областей значительно превосходят ресурсы современного программно-аппаратного обеспечения. К этому классу относят геофизические, биологические, социально-экономические и многие другие предметные области. Следующий аспект проблемы крупномасштабной автоматизации обработки информации — это становление информационного ресурса как ведущего ресурса в социально-экономических процессах, открывающего принципиально новые перспективы развития цивилизации. Информационное общество, в которое стихийно входят экономически развитые страны, целиком базируется на эксплуатации информационного ресурса. Если оперирование понятиями «вещество» и «энергия» без их конструктивного определения на предыдущих вещественно-энергетических этапах развития
4
Проектирование информационных систем
человечества не было столь катастрофически сдерживающим, то активное использование всепроникающего понятия «информация» без должной его формализации уже в течение более полувека становится серьезным камнем преткновения на пути осознанного прогресса. Соответственно фундаментальное исследование общенаучной категории информация, информационный ресурс сегодня стало чрезвычайно актуальным.
Актуальность данного аспекта проблемы в значительной мере объясняется большими изменениями, которые произошли в компьютерном моделировании за последние несколько десятилетий. В процессе научно-технического прогресса материальная ресурсоемкость вычислительной техники для равномощных устройств уменьшилась на несколько порядков. Вследствие этого происходит компенсирующее замещение материальных ресурсов информационными. Материальным ресурсом называется количество составляющих элементов информационной системы, а информационным ресурсом — мощность множества ее состояний.
При всем этом сам процесс разработки и моделирования открытых информационных систем весьма сложен и трудоемок. Поэтому для эффективного использования ограниченных научно-технических ресурсов представляется целесообразным оптимизировать этот процесс. Таким образом, возникает задача поиска и описания важнейших характеристик процесса моделирования информационных систем, а также построения критериев для оценки эффективности этого процесса.
Совокупность вышеназванных особенностей и составляет сущность проблемы построения концепции проектирования информационных систем, способных к самоорганизации, в сверхбольших, слабоструктурированных, неполных, открытых и динамично изменяющихся предметных областях.
0
Введение
В ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Главная особенность индустрии систем автоматизации различных предприятий и учреждений, характеризующихся широкой номенклатурой входных данных с различными маршрутами обработки этих данных, состоит в концентрации сложности на начальных этапах анализа требований и проектирования спецификаций системы при относительно невысокой сложности и трудоемкости последующих этапов. Фактически здесь и происходит понимание того, что будет делать будущая система и каким образом она будет работать, чтобы удовлетворить предъявленные к ней требования. Именно нечеткость и неполнота системных требований, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и в итоге приводят к неуспеху работы в целом.
С другой стороны, не существует двух одинаковых организаций, а следовательно, простое тиражирование даже очень хорошей системы управления предприятием никогда не устроит заказчика полностью, поскольку нс может учесть его специфики. Более того, в данном случае возникает проблема выбора именно той системы, которая наиболее подходит для конкретного предприятия. Эта проблема осложняется еще и тем, что ключевые слова, характеризующие различные информационные системы, практически одни и те же: единая информационная среда предприятия; режим реального времени; независимость от законодательства; интеграция с другими приложениями (в том числе с уже работающими на предприятии системами); поэтапное внедрение и т.п.
6
Проектирование информационных систем
Фактически проблема комплексной ав томатизации стала актуальной для каждого предприятия, а чтобы заниматься комплексной автоматизацией, необходимы структурированные знания в этой области.
1.1.	Основы создания и функционирования информационной системы
Информационная система (ИС) — коммуникационная система по сбору, передаче и обработке информации об объекте, снабжающая работников различного ранга информацией для реализации функций управления. В общем виде система охватывает комплекс взаимосвязанных элементов, действующих как единое целое в интересах цели. Система включает следующие компоненты: структуру системы — множество элементов системы и взаимосвязи между ними; функцию каждого элемента системы; цели и ограничения системы и ее отдельных элементов (материальные и информационные потоки, поступающие в систему или вводимые ею); вход и выход каждого элемента системы. Каждая система обладает свойствами делимости и целостности. Свойство делимости представляет систему в виде относительно самостоятельных частей (подсистем), каждая из которых может рассматриваться как система. Это упрощает анализ, разработку, внедрение и эксплуатацию. Свойство целостности указывает на согласование целей функционирования всей системы с целями функций ее подсистем и элементов. ИС создается для конкретного объекта. Эффективная ИС принимает во внимание различие между уровнями управления, сферами действий, а также внешними обстоятельствами и дает каждому уровню управления только ту информацию, которая ему необходима для эффективной реализации функций управления. Внедрение ИС производится в целях повышения эффек тивности производственно-хозяйственной деятельности за счет не только обработки и хранения информации,
глава 1	_
х ^ведение в проектирование информационных систем_
но и за счет применения новых методов управления, основанных на моделировании действий специалиста фирмы при принятии решения с использованием методов искусственного интеллекта, экспертных систем, средств телекоммуникаций, глобальных и локальных сетей и т.д.
В процессе декомпозиции компонентов ИС выделяют: функциональные и обеспечивающие части. Функциональная часть — эго ряд подсистем, которые зависят от особенностей той или иной ИС. Эти подсистемы разделяются по определенному признаку (функциональному или структурному) и объединяют соответствующие комплексы задач управления. Обеспечивающая часть ИС состоит из информационной, программной, математической, технической, правовой, лингвистической, эргономической и метрологической частей. В состав информационного обеспечения входит внема-шиннос и внутримашинное обеспечение. Внсмашинное обеспечение составляют классификаторы технико-экономической информации, нормативно-справочная информация, методические материалы по организации и использованию перечисленных компонентов. Внутримашинное информационное обеспечение — это информационная база и СУБД. Программное обеспечение — совокупность программ, реализующих цели и задачи ИС. В состав программных средств включены: общесистемное, прикладное обеспечение, инструктивно-методические материалы по применению средств программного обеспечения. Математическое обеспечение состоит из совокупности методов решения задач управления, моделей, алгоритмов обработки информации. Техническое обеспечение включает весь комплекс технических средств, обеспечивающих работу системы, т.с. технические средства сбора, регистрации, передачи, обработки, отображения, размножения информации. Организационно-методическое обеспечение представляет собой совокупность документов, определяющих организационную структуру документа, и систем автоматизации для выполнения конк-ретно-автоматизируемых функций. Правовое обеспечение
8
Проектирование информационных систем
представлено системой нормативно-правовых документов, которые должны четко определять права и обязанности специалистов в условиях функционирования ИС, а также комплексом документов, которые регламентируют порядок хранения и защиты информации, правила ревизии данных, юридическую подлинность совершаемых операций. Лингвистическое обеспечение представляет собой совокупность языковых средств для формализации естественного языка. Эргономическое обеспечение — совокупность методов и средств для создания оптимальных условий деятельности человека при разработке ИС. Метрологическое обеспечение — метрологические средства и инструкции по их применению.
К потребительским свойствам информационных систем относятся:
►	функциональная полнота — система должна обеспечивать получение любой необходимой пользователю информации на некотором заданном интервале времени;
►	временная обеспеченность — возможность получения нужной информации в требуемое время;
►	функциональная надежность — получение безошибочной информации в заданные сроки;
►	эффективность — система должна приносить пользу;
►	адаптивность—система должна обладать способностью приспосабливаться к частично изменившимся условиям объекта и обеспечивать устойчивое функционирование на большом интервале времени;
►	иерархичность — возможность быть составной частью системы более высокого уровня.
Проектирование информационных систем — логически сложная, трудоемкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов. Однако до настоящего времени проектирование ИС нередко выполняется на интуитивном уровне неформализованными методами, включающими в себя элементы искусства, практический опыт, экспертные оценки и дорогостоящие
рлава 1	_
^ведение в проектирование информационных систем
экспериментальные проверки качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей постоянно изменяются или уточняются, что еще более усложняет разработку и сопровождение таких систем.
Тенденции развития современных информационных технологий определяют постоянное возрастание сложности ИС, создаваемых в различных областях экономики. Для современных крупных проектов ИС характерны, как правило, следующие особенности [4]:
►	сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
►	наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих не-регламентированные запросы к данным);
►	отсутствие полных аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
►	необходимость интеграции существующих и вновь разрабатываемых приложений;
►	функционирование в неоднородной среде на нескольких аппаратных платформах;
►	разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
►	значительная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны,
Ю Проектирование информационных систем
масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Усложнение архитектуры современных информационных систем предопределяет разработку и применение эффективных технологий проектирования, обеспечивающих ускорение создания, внедрения и развития проектов ИС, повышение их функциональной и адаптивной надежности.
Во многих аспектах системный анализ является наиболее трудной частью разработки. Проблемы, с которыми сталкивается системный аналитик, взаимосвязаны (и это является одной из главных причин их трудноразрешимости) [11]: ► аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;
►	заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, а что — невыполнимым;
►	аналитик сталкивается с чрезмерным количеством подробных сведений о предметной области и о новой системе;
►	спецификация системы из-за объема технических терминов часто непонятна для заказчика.
Эти проблемы могут быть существенно облегчены за счет применения современных структурных методов, среди которых центральное место занимают методологии структурного анализа.
Проектирование имеет целью обеспечить успешное функционирование ИС и взаимодействие информационных технологий со специалистами. Именно качественное проектирование обеспечивает создание такой системы, которая способна функционировать при постоянном совершенствовании ее технических, программных, информационных составляющих, т.е. ее технологической основы, и расширять спектр реализуемых управленческих функций и объектов взаимодействия.
рлава 1
л ^ведение в проектирование информационных систем_
В процессе проектирования совершенствуется как организация основной деятельности объекта (производственной, хозяйственной), так и организация управленческих процедур.
Массовое проектирование ИС потребовало разработки единых теоретических положений, методических подходов к их созданию и функционированию, без чего невозможно взаимодействие различных экономических объектов и их нормальное функционирование в сложном многоуровневом народнохозяйственном комплексе.
Сформулированные академиком В.М. Глушковым научно-методические положения и практические рекомендации по проек тированию автоматизированных систем в настоящее время представляют собой основополагающие принципы создания ИС [78].
Принцип системности является важнейшим при создании, функционировании и развитии ИС. Он позволяет подойти к исследуемому объекту как единому целому; выявить на этой основе многообразные типы связей между структурными элементами, обеспечивающими целостность системы; установить направление производственно-хозяйственной деятельности системы и реализуемые ею конкретные функции. Системный подход предполагает проведение двухаспектного анализа, получившего название микро- и макроподхода.
При макроанализе система и ее элемент рассматриваются как часть системы более высокого порядка. Особое внимание уделяется информационным связям: устанавливается их число, выделяются и анализируются те связи, которые обусловлены целью изучения системы, а затем выбираются наиболее предпочтительные, реализующие заданную целевую функцию.
При микроанализе изучается структура объекта, анализируются составляющие ее элементы с точки зрения их функциональных характеристик, проявляющихся через связи с другими элементами и внешней средой. В процессе проек
12
Проектирование информационных систем
тирования ИС системный подход позволяет использовать математическое описание функционирования, исследования различных свойств отдельных элементов и системы в целом, а также моделировать изучаемые процессы для анализа работы вновь создаваемых систем.
Практическое значение системного подхода и моделирования состоит в том, что они позволяют в доступной для анализа форме не только отразить все существенное, интересующее создателя системы, но и использовать ЭВМ для исследования поведения системы в заданных экспериментатором условиях. Поэтому в основе создания ИС в настоящее время лежит метод моделирования на базе системного подхода, позволяющего находить оптимальный вариант структуры системы и тем самым обеспечивать наибольшую эффективность ее функционирования.
Принцип развития заключается в том, что ИС создается с учетом возможности постоянного пополнения и обновления функции системы и видов ее обеспечений. Предусматривается, что автоматизированная система должна наращивать свои вычислительные мощности, оснащаться новыми техническими и программными средствами, быть способной постоянно расширять и обновлять круг задач и информационный фонд, создаваемый в виде системы баз данных.
Принцип комплексности требует, чтобы в процессе проектирования ИС была обеспечена связность проектирования отдельных элементов и всего объекта в целом на всех стадиях. Для этого в подсистемах должны предусматриваться компоненты ИС, осуществляющие комплексное согласование и контроль характеристик элементов и объекта в целом. Принцип предполагает связь всех работ, проводимых в производстве, управлении, в том числе и работ по автоматизации. Эффективность автоматизации достигается только при едином планировании всего комплекса мероприятий, направляемых на интенсификацию деятельности с использованием единой методической основы. Кроме того, системы, автоматизирующие не только функцию или зада
глава 1
Л ^ведение в проектирование информационных систем
13
чу, а их взаимосвязанный комплекс, являются более эффективными.
Принцип совместимости обеспечивает способность взаимодействия ИС различных видов, уровней в процессе их совместного функционирования. Реализация принципа совместимости позволяет обеспечить нормальное функционирование экономических объектов, повысить эффективность управления народным хозяйством и его звеньями.
Принцип стандартизации и унификации предполагает применение типовых, унифицированных и стандартизированных элементов функционирования ИС. Внедрение в практику создания и развития ИС этого принципа позволяет сократить временные, трудовые и стоимостные затраты на создание ИС при максимально возможном использовании накопленного опыта в формировании проектных решений и внедрении автоматизации проектировочных работ.
Принцип эффективности заключается в достижении рационального соотношения между затратами на создание ИС и целевым эффектом, получаемым при ее функционировании.
Как правило, кроме основополагающих принципов для эффективного осуществления управления выделяют также ряд частных принципов, детализирующих общие. Соблюдение каждого из частных принципов позволяет получить определенный экономический эффект. Один из них — принцип декомпозиции — используется при изучении особенностей, свойств элементов и системы в целом. Он основан на разделении системы на части, выделении отдельных комплексов работ и создает условия для более эффективного ее анализа и проектирования.
Принцип первого руководителя предполагает закрепление ответственности при создании системы за заказчиком — руководителем предприятия, организации, т.е. будущим пользователем, который отвечает за ввод в действие и функционирование ИС.
Принцип новых задач — поиск постоянного расширения возможностей системы, совершенствование процесса управ
14
Проектирование информационных систем
ления, получение дополнительных результатных показателей с целью оптимизировать управленческие решения. Это может сопровождаться постановкой и реализацией при использовании ЭВМ и других технических средств новых задач управления.
Принцип автоматизаг)ии информационных потоков и документооборота предусматривает комплексное использование технических средств на всех стадиях прохождения информации, от момента ее регистрации до получения результатных показателей, и формирования управленческих решений.
Принцип автоматизации проектирования имеет целью повысить эффективность самого процесса проектирования и создания ИС на всех уровнях народного хозяйства, обеспечивая при этом сокращение временных, трудовых и стоимостных затрат за счет внедрения индустриальных методов. Современный уровень разработки и внедрения систем позволяет широко использовать типизацию проектных решений, унификацию методов и средств при подготовке проектных материалов, стандартизацию подходов при проектировании отдельных элементов систем и подсистем, методы автоматизации ведения проектных работ с использованием ПЭВМ и организованных на их базе АРМ проектировщика.
Рассмотренные базовые принципы дополняются не менее важными организационно-технологическими, без которых невозможна разработка новых ИТ. Раскроем наиболее применяемые организационно-технологические принципы создания ИС.
Принцип абстрагирования заключается в выделении существенных (с конкретной позиции рассмотрения) аспектов системы и отвлечении от несущественных в целях представления проблемы в более простом общем виде, удобном для анализа и проектирования.
Принцип формализации определяет необходимость использования строгого методического подхода к решению
рлава 1	1С
^ведение в проектирование информационных систем
проблемы, формализованных методов описания и моделирования изучаемых и проектируемых процессов, включая бизнес-процессы, функционирования системы.
Принцип концептуальной общности требует неукоснительного следования единой методологии на всех этапах проектирования автоматизированной системы и всех ее составляющих.
Принцип непротиворечивости и полноты заключается в наличии всех необходимых элементов во вновь создаваемой системе и согласованном их взаимодействии.
Принцип независимости данных предполагает, что модели данных должны быть проанализированы и спроектированы независимо от процессов их обработки, а также от их физической структуры и распределения в технической среде.
Принцип структурирования данных предусматривает необходимость структурирования и иерархической организации элементов информационной базы системы.
Принцип доступа конечного пользователя заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
Соблюдение приведенных принципов необходимо при выполнении работ на всех стадиях функционирования ИС и ИТ, т.е. в течение всего их жизненного цикла.
1.2.	Общая схема проектирования информационных систем
(систем информационного обеспечения)
Существуют три группы основных принципов создания информационных систем:
►	управленческие, включающие принципы системности, комплексности, эффективности (рассмотрены в п. 1.1);
►	технические;
►	организационные.
16
Проектирование информационных систем
Технические принципы — комплексное использование вычислительной техники и программных средств, создание единой информационной базы системы, организация непосредственного общения пользователя с системой (их соблюдение обязательно).
Поскольку создание интегральной информационной системы является весьма сложным и трудоемким процессом, проведение соответствующих работ требует координации деятельности всех специалистов-разработчиков {организационный принцип), которая достигается путем назначения ведущего специалиста по информационному обеспечению (ИО). Основными функциями специалиста по ИО являются: ► организация работ по проектированию, сопровождению и развитию базы данных; изучение информационных потребностей в рамках организации; обобщение опыта создания эффективных ИС;
►	совершенствование и внедрение классификаторов и кодификаторов;
►	организация работ, направленных на создание систем интеграции неоднородных баз данных и совершенствование систем управления распределенными базами данных;
►	обеспечение надежного функционирования систем ИО.
Сложилось два подхода к проектированию ИО: дедуктивный (от общей задачи к частным задачам управления) и индуктивный (от конкретных функций к общей задаче управления). Общую схему проектирования ИО можно представить в такой последовательности:
1)	анализ системы принятия решений. Процесс начинается с определения всех типов решений, для принятия которых требуется информация. Должны быть учтены потребности каждого уровня и функциональной сферы;
2)	анализ информационных запросов, т.е. необходимость определения типа информации, которая требуется для принятия каждого решения;
глава 1
* ^ведение в проектирование информационных систем
17
3)	агрегирование решений. Если бы для принятия каждого решения требовалась специальная информационная система, то система ИО была бы безнадежно сложной. Решения, по которым требуется одна и та же информация, необходимо сгруппировать в одну задачу управления. Система ИО должна быть скоординирована и интегрирована с организационной структурой;
4)	проектирование процесса обработки информации. Разрабатывается реальная система для сбора, передачи, хранения и модификации информации;
5)	создание и воплощение системы, цель которой оценивать выдаваемую информацию и распознавать ошибки. Распространенным исследовательским приемом в осуществлении работ по проектированию является анализ решений, принимаемых в каждом звене, на каждом уровне, каждым руководителем.
1.2.1. Структура процесса проектирования ИС
Проектирование и сопровождение ИС невозможны без системного подхода. Интерпретация и конкретизация системного подхода имеют место в ряде известных подходов с другими названиями, которые также можно рассматривать как компоненты системотехники. Таковы структурный, блочноиерархический, объектно-ориентированный подходы [79].
При структурном подходе как разновидности системного, требуется синтезировать варианты системы из компонентов (блоков) и оценивать варианты при их частичном переборе с предварительным прогнозированием характеристик компонентов.
Блочно-иерархический подход к проектированию использует идеи декомпозиции сложных описаний объектов и соответственно средств их создания на иерархические уровни и аспекты, вводит понятие стиля проектирования (восходящее и нисходящее), устанавливает связь между параметрами соседних иерархических уровней.
БИБЛИОТЕКА
ВоЛГи/^41- -ЯП» ' Г '
Проектирование информационных систем
Составными частями процесса создания ИС являются следующие основные разделы:
►	иерархическая структура систем, организация их проектирования;
►	анализ и моделирование систем;
►	синтез и оптимизация систем.
Моделирование имеет две четко различимые задачи: создание моделей сложных систем; анализ свойств систем на основе исследования их моделей.
Синтез также подразделяют на две задачи: синтез структуры проектируемых систем (структурный синтез) и выбор численных значений параметров элементов систем (параметрический синтез). Эти задачи относятся к области принятия проектных решений.
Моделирование и оптимизацию желательно выполнять с учетом статистической природы систем. Детерминированность — лишь частный случай. При проектировании характерны нехватка достоверных исходных данных, неопределенность условий принятия решений. Учет статистического характера данных при моделировании в значительной мере основан на методе статистических испытаний, а принятие решений — на использовании нечетких множеств, экспертных систем, эволюционных вычислений.
В зависимости от последовательности решения задач иерархических уровней различают нисходящее, восходящее и смешанное проектирование (стили проектирования) [79]. Последовательность решения задач от нижних уровней к верхним характеризует восходящее проектирование, обратная последовательность приводит к нисходящему проектированию, в сметанном стиле имеются элементы как восходящего, так и нисходящего проектирования. В большинстве случаев для сложных систем предпочитают нисходящее проектирование. При наличии заранее спроектированных составных блоков можно говорить о смешанном проектировании.
Неопределенность и нечеткость исходных данных при нисходящем проектировании (так как еще не спросктиро-
глава 1	1О
*- ^ведение в проектирование информационных систем_
ваны компоненты) или исходных требований при восходящем проектировании (поскольку ТЗ имеется на всю систему, а не на ее части) обусловливают необходимость прогнозирования недостающих данных с последующим их уточнением, т.е. последовательного приближения к окончательному решению (итерационностъ проектирования).
Наряду с декомпозицией описаний на иерархические уровни применяют разделение представлений о проектируемых объектах на аспекты
Аспект описания (страта) — описание системы или ее части с некоторой оговоренной точки зрения, определяемой функциональными, физическими или иного типа отношениями между свойствами и элементами.
Различают аспекты функциональный, информационный, структурный и поведенческий (процессный) [79]. Функциональное описание относят к функциям системы и чаще всего представляют его функциональными схемами. Информационное описание включает в себя основные понятия предме с-ной области (сущности), словесное пояснение или числовые значения характеристик (атрибутов) используемых объектов, а также описание связей между этими понятиями и характеристиками. Информационные модели можно представлять графически (графы, диаграммы сущность-отношение), в виде таблиц или списков. Структурное описание относится к морфологии системы, характеризует составные части системы и их межсоединения и может быть представлено структурными схемами, а также различного рода конструкторской документацией. Процессное описание характеризует процессы функционирования (алгоритмы) системы и (или) технологические процессы создания системы.
Иногда аспекты описаний связывают с подсистемами, функционирование которых основано на различных физических процессах.
В общем случае выделение страт может быть неоднозначным. Так, помимо указанного подхода, очевидна целесообразность выделения таких аспектов, как функциональное
20
Проектирование информационных систем
(разработка принципов действия структурных, функциональных, принципиальных схем), конструкторское (определение форм и пространственного расположения компонентов изделий), алгоритмическое (разработка алгоритмов и программного обеспечения) и технологическое (разработка технологических процессов) проектирование систем.
1.2.2.	Стадии проектирования ИС
Опыт проектирования и разработки ИС нашел отражение в ГОСТах, в которых представлены основные рекомендации и требования, прошедшие проверку временем.
В соответствии с ГОСТ 34.201 можно выделить следующие стадии проектирования автоматизированной информационной системы (АИС):
►	предпроектную стадию;
►	стадию проектирования;
I- внедрение.
Предпроектная стадия включает в себя предпроектное обследование и разработку технического задания на АИС. Важнейшими результатами этого этапа являются: описание целей и задач информационной системы, выработка общих требований к ее созданию, разработка программы проведения обследования, в рамках которого изучаются и уточняются информационная модель управления, структура и функции организации, перечень задач, подлежащих автоматизации, ориентировочный состав технических средств, технико-экономические характеристики системы ИО.
Этап проектирования связан с разработкой технического и рабочего проектов. Разработка технического задания включает проведение обследования действующего объекта (организации или подразделения) и его систем управления или ближайшего объекта (аналога нового объекта). Для решения задач ИО анализируются потоки информации, системы классификации и кодирования, формы документации, а также исследуются СУБД, структуры имеющихся баз дан
удава 1
* ^ведение в проектирование информационных систем
21
ных, методы их интеграции. Результаты этих работ включаются в состав исходных технологических требований и оформляются в соответствии с РД 50-34.698-90.
При разработке технического проекта необходимо подробно остановиться на анализе всей используемой информации с точки зрения ее полноты, непротиворечивости, отсутствия избыточности и дублирования, а также на разработке форм выходных документов. Результаты такого исследования оформляются документом «Описание информационного обеспечения», в котором конкретизируются требования к организации ИО. Документация технологического характера должна соответствовать требованиям ГОСТ 34-201-89 с учетом РД 50-34.698-90.
На стадии рабочего проектирования в качестве одного из основных этапов выделяется разработка рабочей документации на ИО информационной системы, целью которой являются: создание необходимого программного обеспечения, подготовка на машинных носителях нормативносправочной и производственной информации для первичной загрузки информационной базы, выпуск необходимой рабочей документации, включая инструкции пользователям и инструкции по эксплуатации. Состав документации должен включать: технический проект ИС; описание организации информационной базы; описание систем классификации и кодирования; перечень исходных данных; перечень выходных документов; описание локальных баз данных; формы выходных документов.
Этап внедрения системы включает реализацию основных мероприятий по внедрению, подбор и обучение персонала, подготовку помещений и технических средств. Осуществляется также эксплуатация системы путем решения конкретных задач и анализа результатов испытаний.
Проведение работ по созданию АИС регламентируется ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [53]. Общие требования и совокупность работ на всех стадиях и этапах определяются ГОСТ 34-201-89 «Виды,
22
Проектирование информационных систем
комплектность и обозначение документов при создании автоматизированных систем».
В работах по проектированию ИО необходимо выделить:
► стадию концептуального проектирования, когда на основе анализа и структурирования информационного пространства осуществляются построение информационной модели организации, формирование локальных информационных структур и их интеграция, концептуальное проектирование алгоритмов обработки информации. Информационная модель отражает в различных формах реальные процессы формирования информационных массивов, передачи, преобразования данных, прохождение информационных потоков. Они могут быть представлены в виде
’ словесного описания, схемы, матрицы, графов и т.д.;
►	организационную стадию, в рамках которой разрабатывается план-схема всех операций и действий по проектированию и внедрению АИС с указанием стоимости каждого этапа, сроков выполнения, ответственных лиц и результатов.
По содержанию создание системы ИО включает три раздела:
►	организацию массивов информации;
►	разработку технологий поиска, сбора, хранения, обновления, обработки и передачи информации;
►	организацию потоков информации.
Конечная цель ИО как информационной системы заключается в удовлетворении информационных потребностей, они становятся определяющим фактором при формировании базы данных. Организация информационного массива строится в соответствии с конкретными условиями и задачами управления.
Степень детализации и форма представления информации различаются в зависимости от получателя. Чем выше его пост, тем более общая информация ему требуется.
глава 1
* ^ведение в проектирование информационных систем
«I
При анализе информационных потребностей нужно различать:
►	фактически удовлетворяемые потребности в информации, т.е. ту информацию, которая поступает к менеджеру — периодичность, состав, качество сведений;
►	реальные потребности, т.е. объем информации, необходимый для успешного решения задачи в конкретный момент;
►	абсолютные потребности, отражающие всю потребность в информации при наиболее полном и квалифицированном решении задач. Абсолютные потребности — перспектива развития ИО.
Для изучения информационных потребностей и запросов используют следующие методы.
1.	Анализ управленческой документации и документообо рота применительно к каждому уровню управления и рабочему месту специалиста. Функционирующая в организации система документооборота позволяет получить достаточно полную картину о содержании, форме представления, периодичности сведений, поступающих к конкретному специалисту и создаваемых им. Анализ документов дает возможность выделить сквозные показатели и определить алгоритм их агрегирования. Управленческие документы составляют основу для анализа фактически удовлетворяемых потребностей, т.е. того уровня ИО, который обеспечивает определенный минимум сведений, необходимый для управления. Традиционные методы изучения документооборота можно дополнить формализованными, например контент-анализом. Метод на основе частотного подсчета смысловых единиц позволяет более полно и подробно охарактеризовать параметры, в т.ч. состав информационного массива системы.
Кроме изучения рабочих документов и специальных систем документации интерес вызывают нормативно-справочные виды документов, которые в совокупности с должностными инструкциями, положениями о деятельности
24
Проектирование информационных систем
подразделений дают возможность выяснить и оценить уровень ИО, достаточный для удовлетворения реальных потребностей.
2.	Проведение социологического обследования среди потенциальных пользователей системы ИО. Может быть проведено в форме анкетирования, интервью, применимы методы наблюдения и эксперимента. Социологический опрос обязательно должен быть сплошным. Анкеты разрабатываются для каждой категории потребителей информации, подробно — для руководителей и специалистов. Основная часть вопросов анкеты, как правило, формулируется в открытом виде, что позволяет получить более полный и развернутый ответ.
3.	Анализ существующих информационных связей. Заключается в построении дерева целей и в применении методов опроса. Суть метода, основанного на построении дерева целей системы управления, состоит в следующем. Формулируется генеральная цель деятельности системы управления. Успех всей дальнейшей работы по выявлению параметров информационного фонда определяется тщательностью и корректностью формулировки генеральной цели. Потом цель декомпозируется, т.е. разбивается на ряд более узких частных целей, выполнение которых необходимо для достижения нужного уровня. Процесс продолжается до тех пор, пока не будут выявлены решаемые будущими пользователями подсистемы задачи.
Метод дерева целей позволяет выявить полный перечень задач, решение которых необходимо на определенном уровне управления для достижения генеральной цели деятельности.
Для ввода АИС нужно собрать огромный объем детализированных данных. Базы данных разрабатываются на этапе детального построения системы. Предварительно нужно составить контрольный перечень объектов БД, определить тип, формат данных, классификаторы и ключи для облегчения поиска. В целях организации информационного
рлава 1
К Введение в проектирование информационных систем
25
массива необходимо продумать соответствующий классификатор. Содержащаяся в массиве информация классифицируется по признакам: направлению движения (входящая, исходящая, внутренняя), способу получения, периодичности поступления (непрерывно поступающая, ежедневная, еженедельная и т.д.), характеру применения в процессе управления (нормативная, справочная, плановая, аналитическая).
Таким образом, банк данных представляет собой хранилище директивных, плановых, нормативных, справочных, учетных и других сведений, необходимых для выработки управленческого решения. Он служит для формирования основных показателей и документов, создаваемых в аппарате управления, может функционировать наряду с традиционными справочно-информационными фондами.
Основные требования к банку данных:
►	достаточный объем и достоверность сведений;
►	возможность дополнения, корректировки массивов информации;
►	быстрый поиск;
►	возможность многоцелевого использования данных для составления отчетов, формирования планов и т.д.
Для создания БД необходимо:
►	определить объем и характер информации;
►	классифицировать ее массив;
►	определить структуру БД;
►	выбрать вид носителей информации, систему поисковых признаков;
►	разработать типовые процедуры формирования основных документов и показателей;
►	порядок корректировки и пополнения БД.
Основной информационный массив содержит сведения постоянного характера, т.е. медленно меняющиеся показатели, характеристики.
По структуре БД может быть централизованным (создается центр хранения информации, куда стекаются все сведения
Проектирование информационных систем
26 а»
и обращаются пользователи) и децентрализованным (несколько автономных массивов информации, которые формируются в подразделениях организации).
Для классификации объектов необходимо определить набор классификационных признаков. Для ряда информационных объектов разработаны отдельные ГОСТы и ОСТы. Системы классификации являются основой построения информационно-поисковых языков информационной системы, от которых зависит полнота и точность поиска информации.
При проектировании информационных систем могут использоваться как глобальные, так и локальные системы кодирования и классификации, например ЕСКК. В ее состав входят комплекс общесоюзных классификаторов технико-экономической информации (ОКТЭИ) и автоматизированная система ведения общесоюзных классификаторов. В системы ОКТЭИ включено более 20 общесоюзных классификаторов, таких как общесоюзный классификатор промышленной и сельскохозяйственной продукции (ОКПП), классификатор министерств, ведомств и отраслей народного хозяйства (ОКОНХ), классификатор технико-экономических показателей (ОКТЭП), классификатор профессий рабочих (ОКПР), должностей служащих (ОКДС) и т.д.
Для постановки и решения многих задач в управлении используется информация, представленная в нескольких массивах. Центральным звеном в организации потоков информации является определение маршрутов ее движения и периодичность циркуляции.
Анализ информационных потоков осуществляется в два этапа: обследование; построение и анализ информационной модели организации.
Основу проектирования ИС составляют результаты обследований информационных потоков и документооборота. В настоящее время отсутствуют ГОСТы, нормативные материалы, регламентирующие проведение обследования и анализа информационных потоков при проектировании ИС. Но эти вопросы нашли отражение в нормативных ма
глава 1
'Введение в проектирование информационных систем_иш
териалах по АИС (РД 50-34.698-90), которые могут быть использованы для организации работ.
При анализе информационных потоков нужно учитывать движение информации в следующих направлениях.
1. По вертикали (по иерархическим уровням). Данный анализ позволяет выявить преемственность, уплотнение, усреднение выхода информации. Анализ преемственности информации высвечивает сквозные показатели, проходящие через все уровни управления, и выделяет из них те, которые характерны для одного и того же явления на разных уровнях. Появляется возможность для унификации информации. Выводы этого анализа становятся базой для определения ИО на различных иерархических ступенях. Анализ степени уплотнения информации характеризует правильность отсева несущественных показателей и агрегирование частных в обобщающие.
2. Горизонтальное движение. Основная направленность состоит в сопоставлении схемы разработки и принятия решений и схем движения информации, так как ее маршруты определяются процессами разработки решений. Наиболее приемлемым методом анализа маршрутов является сетевой анализ, где событиями является принятие конкретных решений, а путями — поток информации. В ходе анализа отыскиваются наиболее короткие пути для обеспечения всех необходимых решений. Графический анализ дает достаточно полное представление о рациональности информационных потоков. При этом необходимо учитывать прямоточ-ность движения, ритмичность, специализацию потоков информации, плотность, параллельность движения потоков.
Структура информационных потоков выявляется путем анализа строения организации, структуры документооборота и движения недокументированной информации.
В целях более полного анализа документацию можно поделить на нормативно-справочную (постоянную) и оперативную (переменную).
28
Проектирование информационных систем
К нормативно-справочной документации относят: прейскуранты, ГОСТы, нормы, нормативы, справочники, классификаторы, кодификаторы, постоянную конструкторскую документацию, справочные данные по предметным областям, постоянную технологическую документацию, планы производства, снабжения, реализации. Оперативная документация представлена всеми видами документов, отражающих оперативные планы, результаты производственных процессов.
Для каждого документа в результате обследования должны быть определены: назначение, источник, потребители, состав, размерность каждого показателя, периодичность составления, алгоритмы формирования показателей. Результаты обследования маршрутов каждого вида документа могут быть оформлены в специальных формах.
Одним из методов моделирования информационных связей является матричное моделирование. Матричная модель — это таблица, отражающая взаимосвязи анализируемых данных, документов подразделений организации, формирующих и получающих информацию. Результаты исследования матрицы могут быть положены в основу унификации групп документов, уточнения функций подразделений.
Другой метод моделирования информационных связей— метод формального описания информационных потоков. Суть этого метода состоит в том, что на основе анализа информационных потоков строится граф, вершинам которого соответствуют источники информации и ее потребители, а дугам — информационные потоки.
1.2.3- Документирование процесса проектирования ИС
Важным вопросом является документирование системы, т.е. подготовка описания баз данных, целей системы, потоков информации, порядка осуществления ввода и вывода информации. Вся документация, формируемая в процессе
рлава 1
* ^ведение в проектирование информационных систем
29
с оздания ИС, может быть разделена на четыре типа: пред-проектную, техническую, проектно-сметную, организационно-распорядительную.
Предпроектная документация включает технико-экономическое обоснование и техническое задание. Технико-экономическое обоснование оформляется в виде пояснительной записки, содержащей результаты изучения и анализа объекта управления, состава управленческих решений, концепцию информационной базы ИС, предварительный расчет затрат и экономической эффективности системы, ожидаемой в результате автоматизации, основные цели и направления создания ИС, предложения по организации разработки и по внедрению ИС. Часть предпроектной документации формируется в ходе научно-исследовательских работ и представлена в виде отчета по НИР.
Техническое задание на ИС разрабатывается согласно ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Техническое задание включает комплекты документов технического и рабочего проектов. К ним относится инструктивная документация, регламентирующая деятельность персонала — технологические и должностные инструкции; документация, описывающая экономико-математические модели управления; документация обеспечивающего характера (например, система классификации и кодирования, описание технологических процессов обработки данных, описание организации массивов).
Проектно-сметная документация ИС должна включать пояснительную записку, кратко излагающую содержание проекта; документацию по описанию комплекса технических средств; план мероприятий по подготовке объекта к внедрению; описание структуры системы, программного обеспечения, информационной базы, системы классификации и кодирования, чертежи форм документации.
зо
Проектирование информационных систем
1.3. Понятие консалтинга в области информационных технологий
Консалтинг — это деятельность специалиста или целой фирмы, занимающихся стратегическим планированием проекта, анализом и формализацией требований к информационной системе, созданием системного проекта, иногда проектированием приложений, но все это до этапа собственно программирования или настройки каких-то уже имеющихся комплексных систем управления предприятием, выбор которых и осуществляется на основе системного проекта [69]. В это понятие не входит системная интеграция.
В целом, консультантом выполняются два вида работ.
1. Бизнес-консалтинг. Это элементарное наведение порядка в организации: бизнес-анализ и реструктуризация (реинжиниринг бизнес-процессов). Деятельность, направленная на то, чтобы разобраться в функционировании таких организмов, построить соответствующие модели и на их основе выдвинуть предложения по поводу улучшения работы некоторых звеньев, а еще лучше — бизнес-процессов (деятельностей, имеющих ценность для клиента), считается бизнес-консалтингом.
2. Системный анализ и проектирование. Выявление и согласование требований заказчика приводит к пониманию того, что действительно необходимо сделать. За этим следует проектирование или выбор готовой системы, удовлетворяющей требованиям заказчика в наиболее полном объеме.
Кроме того, важный элемент консалтинга — формирование и обучение рабочих групп. Здесь идет речь не только о традиционной учебе, любые проекты, модели должны в итоге кем-то сопровождаться. Поэтому сотрудники предприятия с самого начала участвуют в проекте, обучаясь поддерживать систему. По окончании проекта они способны анализировать и улучшать бизнес-процессы в рамках собственной отдельно взятой организации.
рлава 1
* ^ведение в проектирование информационных систем_
Основные цели разработки консалтинговых проектов [69]: ► представление деятельности предприятия и принятых в нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту отображения;
►	формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;
►	упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;
►	выработка рекомендаций по построению рациональных технологий работы подразделений предприятия и его взаимодействию с внешним миром;
>	анализ требований и проектирование спецификаций корпоративных информационных систем;
►	рекомендации и предложения по применению и внедрению существующих систем управления предприятиями. Основные этапы разработки консалтинговых проектов [Н,69].
1.	Анализ первичных требований и планирование работ. Данный этап предваряет инициацию работ над проектом. Его основными задачами являются: анализ первичных биз-нес-требований, предварительная экономическая оценка проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы.
2.	Проведение обследования деятельности предприятия. В рамках этого этапа осуществляются:
►	предварительное выявление требований, предъявляемых к будущей системе;
►	определение организационно-штатной и топологической структур предприятия;
►	определение перечня целевых задач (функций) предприятия;
►	анализ распределения функций между подразделениями и сотрудниками;
►	определение перечня применяемых на предприятии средств автоматизации.
32
Проектирование информационных систем
При этом выявляются функциональные виды деятельности каждого из подразделений предприятия и функциональные взаимодействия между ними, информационные потоки внутри подразделений и между ними, внешние по отношению к предприятию объекты и внешние информационные взаимодействия.
В качестве исходной информации при проведении обследования и выполнении дальнейших этапов служат:
►	данные по организационно-штатной структуре предприятия;
►	информация о принятых технологиях деятельности;
►	стратегические цели и перспективы развития;
►	результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);
►	предложения сотрудников по усовершенствованию биз-нес-процессов предприятия;
►	нормативно-справочная документация;
►	опыт системных аналитиков в области использования ими типовых решений.
Длительность этапа 1-2 недели. По окончании обследования строится и согласуется с заказчиком предварительный вариант функционирования модели предприятия, включающей идентификацию внешних объектов и информационных взаимодействий с ними, а также детализацию до уровня основных функций предприятия и информационных связей между ними.
3.	Построение моделей деятельности предприятия. На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих типов:
— модели «как есть», представляющей собой «снимок» положения дел на предприятии (организационно-штатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнсс-процессы и т.д.) на момент обследования и позволяющей понять, как функционирует предприятие с пози
рлава 1	,,
^ведение в проектирование информационных систем_
ций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации;
— модели «как должно быть», интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия.
Переход от модели «как есть» к модели «как должно быть» осуществляется следующими способами:
► совершенствованием технологий на основе оценки их эффективности; при этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников {«легкий» реинжиниринг)'.
► радикальным изменением технологий и переосмыслением бизнес-процессов {«жесткий» реинжиниринг)', например, вместо попыток улучшения бизнес-процесса, проверки кредитоспособности клиента, может, следует задуматься: а нужна ли вообще такая проверка? Возможно, затраты на такие проверки каждого из клиентов во много раз превышают убытки, которые может понести компания в отдельных случаях (например, когда клиентов много, а закупок мало).
4.	Разработка системного проекта. Данный этап является первой фазой разработки собственно системы автоматизации (точнее, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?» Именно здесь лежит ключ к успеху всего проекта автоматизации.
На этом этапе определяются:
► архитектура системы, ее функции, внешние условия ее функционирования, распределение аппаратной и программной частей;
2. Зак. 1035
34 Проектирование информационных систем
►	интерфейсы и распределение функций между человеком и системой;
►	требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонентов системы, их интерфейсы;
►	состав людей и работ, имеющих отношения к системе;
►	ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
Системный проект строится на основе модели «как должно быть» и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEF0 или IDEF3), информационную модель (например, в соответствии со стандартом IDEF1X), а также техническое задание на создание автоматизированной системы.
5.	Разработка предложений по автоматизации. На основании системного проекта осуществляются:
►	составление перечня автоматизированных рабочих мест (АРМ) и способов взаимодействия между ними;
►	анализ применимости существующих систем управления предприятиями для решения требуемых задач и формирование рекомендаций по выбору готовой системы;
►	совместное с заказчиком принятие решения о выборе конкретной системы или разработке собственной системы;
►	разработка требований к техническим и программным средствам;
►	разработка предложений по этапам и срокам реализации.
6.	Разработка технического проекта. На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Этот этап подразделяется на два подэтапа:
► проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонентов, опре-
Глава 1
* 'Дведение в проектирование информационных систем 35
деление информационных потоков между основными компонентами, связей между ними;
► детальное проектирование каждого компонента, включающее разработку спецификаций каждого компонента, разработку требований к тестам и плана интеграции компонентов, а также построение моделей иерархии программных модулей и проектирование внутренней структуры модулей.
При этом происходит расширение системного проекта за счет его уточнения, за счет построения моделей автоматизированных рабочих мест.
7.	Разработка новой системы или настройка существующей системы. В случае разработки собственной системы последующие этапы являются традиционными: по спецификациям технического проекта осуществляется программирование модулей, их тестирование и отладка.
Настройка существующей системы осуществляется по этапам, таким как:
►	наполнение системы фактическими данными;
►	построение процедур их обработки;
►	интеграция процедур внутри автоматизированных рабочих мест;
►	интеграция автоматизированных рабочих мест в систему.
1.4.	CASE-технологии — методологическая и инструментальная база консалтинга
CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанных комплексом взаимосвязанных средств автоматизации. CASE — это инструментарий для системных аналитиков, разработчиков и программистов, который позволяет описывать бизнес-процсссы на компьютере, используя полученные схемы при разработке или настройке системы [11].
2*
36
Проектирование информационных систем
В большинстве современных CASE-систем применяются методологии структурного анализа и проектирования, основанные на наглядных диаграммных техниках, при этом для описания модели проектируемой системы используются графы, диаграммы, таблицы и схемы. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней.
Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии CASE обладают следующими достоинствами [11]:
►	улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего, контроля проекта);
►	позволяют за короткое время создать прототип будущей системы, что дает возможность на ранних этапах оценить ожидаемый результат;
►	ускоряют процесс проектирования и разработки;
►	поддерживают развитие и сопровождение разработки;
►	поддерживают технологии повторного использования компонент разработки.
Большинство CASE-средств основано на парадигме методология — метод — нотация — средство. Методология определяет руководящие указания для оценки и выбора проекта разрабатываемого ПО, шаги работы и их последовательность, а также правила распределения и назначения методов. Метод —это систематическая процедура или техника генерации описаний компонент ПО (например, проектирование потоков и структур данных). Нотации предназначены для описания структуры системы, элементов данных, этапов обработки и включают графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки. Средства—инструментарий для поддержки и усиления методов [11]. Эти инструменты поддерживают работу пользователей при создании и редактировании графического про
глава 1
ж ^ведение в проектирование информационных систем____ми
екта в интерактивном режиме, они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонент.
Контрольные вопросы
1.	Дать определение понятию «проектирование информационных систем».
2.	Указать место и роль системного анализа в проектировании информационных систем.
3.	Раскрыть основополагающие принципы проектирования информационных систем.
4.	В чем заключаются организационно-технические принципы проектирования?
5.	Перечислить стадии и этапы разработки систем по ГОСТ 34.201.
6.	Какие основные этапы включает схема анализа информационного обеспечения ИС?
7.	Дать характеристику основным этапам проектирования информационного обеспечения системы.
8.	В чем заключаются методы изучения информационных потребностей пользователей ИС?
9.	Каковы основные цели разработки консалтинговых проектов?
10.	Охарактеризовать основные этапы разработки консалтинговых проектов.
11.	Дать определения понятиям «методология», «метод», «нотация», «средство».
Основы МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла (ЖЦ).
2.1.	Жизненный цикл программного обеспечения ИС
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО — это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПС и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO — Международная организация по стандартизации, IEC — Международная комиссия по электротехнике) [18]. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:
►	основных процессах ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
►	вспомогательных процессах, обеспечивающих выполнение основных процессов (документирование, управле
Глава 2	X	39
0 сновы методологии проектирования информационных систем
ние конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
►	организационных процессах (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка проекта включает в себя все работы по созданию ПО и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т.д. В разработку ПО входят, как правило, анализ, проектирование и реализация (программирование).
Эксплуатация содержит работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование базы данных и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля над сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта предусматривает выбор методов и инструментальных средств реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО. Верификация — это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа. Проверка позволяет оценить соответствие параметров
40
Проектирование информационных систем
разработки исходным требованиям. Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место отводится вопросам идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [18].
Каждый процесс характеризуется определенными задачами и методами их решения [5], исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
2.2.	Модели жизненного цикла ПО
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ понимается структура, определяющая последовательность
глава 2	лл
* Основы методологии проектирования информационных систем
выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО,.но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы [5].
К настоящему времени наибольшее распространение получили следующие основные модели ЖЦ:
►	каскадная модель;
►	спиральная модель;
►	итерационная модель.
Каскадная модель. В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (см. рис. 2.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Достоинства каскадной модели [8]:
►	на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах также разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения информационной системы: организационное, методическое, информационное, программное, аппаратное;
►	выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты.
42
Проектирование информационных систем
Несмотря на все свои достоинства, каскадная модель имеет ряд недостатков, ограничивающих ее применение при разработке информационных систем. Причем эти недостатки делают ее либо полностью неприемлемой, либо приводят к увеличению сроков разработки и стоимости проекта. В настоящее время многие неудачи программных проектов объясняются именно применением последовательного процесса разработки.
Недостатки каскадной модели:
► задержка получения результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие последовательного подхода к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ. Поэтому может оказаться, что разрабатываемая информационная система не соответствует требованиям пользователей. Причем такие несоответствия могут возникать на любом этапе разработки — искажения могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они не обязательно хорошо разбираются в тех предметных областях, для которых производится разработка информационной системы;
► возврат на предыдущую стадию. Данный недостаток является одним из проявлений предыдущего. Поэтапная и последовательная работа над проектом может быть следствием того, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на следующих стадиях работы над проектом. Поэтому, после того как ошибки проявятся, проект возвращается на предыдущий этап, перерабатывается и снова передается на последующую стадию. Это может служить причиной срыва графика работ;
► сложность параллельного ведения работ. Сложности параллельного ведения работ связаны с необходимостью
глава 2	/2
1 Основы методологии проектирования информационных систем
постоянного согласования различных частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее зависимы друг от друга группы разработчиков. Поэтому преимущества параллельного ведения работ просто теряются;
►	информационная перенасыщенность. Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков. Данная проблема заключается в том, что при внесении изменений в одну из частей проекта необходимо оповещать всех разработчиков, которые использовали или могли использовать эту часть в своей работе;
►	сложность управления проектом при использовании каскадной схемы в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта. Последовательность разработки проекта приводит к тому, что одни группы разработчиков должны ожидать результатов работы других команд. Поэтому требуется административное вмешательство для того, чтобы согласовать сроки работы и состав передаваемой документации.
Рис. 2.1. Каскадная схема разработки ПО

Проектирование информационных систем
В результате реальный процесс создания ПО принимает вид, изображенный на рисунке 2.2.
Рис. 2.2. Реальный процесс разработки ПО по каскадной схеме
' Спиральная модель. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [36] (рис. 2.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации [5].
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, при этом необязательно ждать полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
глава 2	4ч
х(2)сновы методологии проектирования информационных систем
Достоинства спиральной модели [8]:
►	итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;
►	при использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40% всех затрат в конце I проекта);
►	уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый риск уменьшается;
►	итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие.
46
Проектирование информационных систем
Например, можно сократить сроки разработки за счет уменьшения функциональности системы или использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок;
► спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации.
Недостаток спиральной модели -— это определение момента перехода на следующий этап. Для решения этой проблемы необходимо ввести временные ограничения на каждый из этапов жизненного цикла ИС. Иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного. Поэтому завершение итерации должно производиться строго в соответствии с планом, даже если не вся запланированная работа закончена.
Одним из примеров реализации спиральной модели является метод быстрой разработки приложений RAD {Rapid Application Development), который более подробно рассмотрен в п. 10.3.2.
Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональное сочетание этих моделей.
Итерационная модель. Создание ИС предполагает проведение увязки проектных решений, получаемых при реализации отдельных задач. Подход к проектированию снизу-вверх обусловливает необходимость таких итерационных возвратов, когда проектные решения по отдельным задачам комплектуются в общие системные решения, и при этом возникает потребность в пересмотре ранее сформулированных требований. Как правило, вследствие большого числа итераций возникают рассогласования в выполненных проектных решениях и документации. Запутанность функциональной и системной архитектуры созданной ИС, трудность в использовании проектной документации вызывают
глава 2	.47
х Основы методологии проектирования информационных систем
на стадиях внедрения и эксплуатации сразу необходимость перепроектирования всей системы. Длительный жизненный цикл разработки ИС заканчивается этапом внедрения, за которым начинается жизненный цикл создания новой ИС.
Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF) и Extreme Programming (XP).
RUP предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует тс же фазы [51]. Суть работы в рамках RUP — это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (UML), также конкретной технологии проектирования и разработки (объектно-ориентированный анализ, объектно-ориентированное программирование). Методология разработки программного обеспечения RUP более подробно будет представлена в п. 6.3 учебного пособия.
MSF сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования [11]. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
Экстремальное программирование (ХР) является самым новым среди рассматриваемых методологий, сформировалось в 1996 году. В основе методологии лежит командная работа, эффективная коммуникация между заказчиком и
48
Проектирование информационных систем
исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
2.3-	Содержание и организация
проектирования
Под проектированием автоматизированных информационных систем понимается процесс разработки технической документации, связанный с организацией системы получения и преобразования исходной информации в результатную, т.е. с организацией автоматизированной информационной технологии.
Документ, полученный в результате проектирования, носит название проект.
Целью проектирования является подбор технического и формирование информационного, математического, программного и организационно-правового обеспечения.
Подбор технического обеспечения должен быть таким, чтобы обеспечить своевременный сбор, регистрацию, передачу, хранение, наполнение и обработку информации.
Информационное обеспечение должно предусматривать создание и функционирование единого информационного фонда системы, представленного множеством информационных массивов, набором данных или базой данных.
Формирование математического обеспечения систем включает комплектацию методов и алгоритмов решения функциональных задач. При формировании программного обеспечения систем особое внимание обращается на создание комплекса программ и инструкций пользователя и выбор эффективных программных продуктов.
Основными задачами проектирования являются:
►	оказание влияния на улучшение организации учетной, плановой и аналитической работы;
►	выбор оборудования и разработка рациональной технологии решения задач и получения результатной информации;
Глава 2	.49
х0 сновы методологии проектирования информационных систем
►	составление графиков прохождения информации как внутри производственных и функциональных подразделений, так и между ними;
►	создание БД, обеспечивающей оптимальное использование информации, касающейся планирования, учета и анализа хозяйственной деятельности;
►	создание нормативно-справочной информации.
Разработка и внедрение системы автоматизированной обработки информации осуществляются в очередности, установленной техническим заданием. Содержание первой очереди системы определяется составом задач учета, анализа, планирования и оперативного управления, наиболее поддающихся автоматизации и имеющих существенное значение для принятия управленческих решений в предприятии. В процессе разработки последующих очередей системы происходит наращивание исходного комплекса функциональных задач, расширение и интеграция информационного и математического обеспечения, модернизация комплекса технических средств. При создании первой очереди ИС техническое задание разрабатывается на всю систему, а технический и рабочий проекты — на задачи и подсистемы, входящие в состав первой очереди системы.
2.3-1- Каноническое проектирование ИС
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в ГОСТ 34.601-90 [53].
В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей.
Проектирование информационных систем
Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ..
Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
►	обследование объекта и обоснование необходимости создания ИС;
►	формирование требований пользователей к ИС;
►	оформление отчета о выполненной работе и тактико-технического задания на разработку.
Стадия 2. Разработка концепции ИС:
►	изучение объекта автоматизации;
►	проведение необходимых научно-исследовательских работ;
►	разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
►	оформление отчета и утверждение концепции.
Стадия 3. Техническое задание:
►	разработка и утверждение технического задания на создание ИС.
Стадия 4. Эскизный проект:
►	разработка предварительных проектных решений по си- ‘ стеме и ее частям;
►	разработка эскизной документации на ИС и ее части.
Стадия 5. Технический проект:
►	разработка проектных решений по системе и ее частям;
►	разработка документации на ИС и ее части;
►	разработка и оформление документации на поставку комплектующих изделий;
►	разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация:
►	разработка рабочей документации на ИС и ее части;
►	разработка и адаптация программ.
Стадия 7. Ввод в действие:
►	подготовка объекта автоматизации;
глава 2
* Основы методологии проектирования информационных систем
►	подготовка персонала;
►	комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
►	строительно-монтажные и пусконаладочные работы;
►	предварительные испытания;
►	опытная эксплуатация;
►	приемочные испытания.
Стадия 8. Сопровождение ИС:
►	выполнение работ в соответствии с гарантийными обязательствами;
►	послегарантийное обслуживание.
Обследование — это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются:
— для обоснования разработки и поэтапного внедрения систем;
— составления технического задания на разработку систем; — разработки технического и рабочего проектов систем.
На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.
Основная задача первого этапа обследования — оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес-экспсртами. Основная задача взаимодействия — получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.
52
Проектирование информационных систем
По завершении этой стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты ца ее реализацию (затраты на аппаратное обеспечение, закупаемое программное обеспечение и разработку нового программного обеспечения).
Результатом этапа определения стратегии является документ (технико-экономическое обоснование проекта), в котором четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты на проект, но и выгоду от его реализации, например, время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
Ориентировочное содержание этого документа: t ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
►	совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы;
►	сроки завершения отдельных этапов, форма приемки-сдачи работ, привлекаемые ресурсы, меры по защите информации;
►	описание выполняемых системой функций;
►	возможности развития системы;
►	информационные объекты системы;
►	интерфейсы и распределение функций между человеком и системой;
►	требования к программным и информационным компонентам ПО, требования к СУБД.
На этапе детального анализа деятельности организации изучаются задачи, обеспечивающие реализацию функций
глава 2	с,
*• Р)сновы методологии проектирования информационных систем
управления, организационная структура, штаты предприятия, содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. На этом этапе должны быть выявлены:
— инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;
— возможности применения новых методов решения задач.
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
►	функции — информация о событиях и процессах, которые происходят в бизнесе;
►	сущности — информация о вещах, имеющих значение для организации и о которых что-то известно.
При изучении каждой функциональной задачи управления определяются:
—	наименование задачи; сроки и периодичность ее решения;
—	степень формализуемости задачи;
—	источники информации, необходимые для решения задачи;
—	показатели и их количественные характеристики;
—	порядок корректировки информации;
—	действующие алгоритмы расчета показателей и возможные методы контроля;
—	действующие средства сбора, передачи и обработки информации;
—	действующие средства связи;
—	принятая точность решения задачи;
—	трудоемкость решения задачи;
—	действующие формы представления исходных данных и результатов их обработки в виде документов;
—	потребители результатной информации по задаче.
Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа является описание документооборота организации. При обследовании документооборота
54
Проектирование информационных систем
составляется схема маршрута движения документов, которая должна отразить:
—	количество документов;
—	место формирования показателей документа;
—	взаимосвязь документов при их формировании;
—	маршрут и длительность движения документа;
—	место использования и хранения данного документа;
—	внутренние и внешние информационные связи;
—	объем документа в знаках.
По результатам обследования устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки.
На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации — MuSCoW.
Эта аббревиатура расшифровывается так: Must have — необходимые функции; Should have — желательные функции; Could have—возможные функции; Won’t have—отсутствующие функции.
Функции первой категории обеспечивают критичные для успешной работы системы возможности.
Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками: разрабатывается то, что необходимо, а также максимально возможное в порядке приоритета число функций второй и третьей категорий.
Последняя категория функций особенно важна, поскольку необходимо четко представлять границы проекта и набор функций, которые будут отсутствовать в системе.
Модели деятельности организации создаются в двух видах:
►	модель «как есть» («as-is») — отражает существующие в организации бизнес-процессы;
►	модель «как должно быть» («to-be») — отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.
I T
глава 2	с-
* QCH0BbI методологии проектирования информационных систем
На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач:
►	получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;
►	разработки плана работ по обеспечению надежности информационной системы и ее тестирования.
Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Если проектное решение оказалось неудачным и это обнаружено слишком поздно (на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию), то исправление ошибки проектирования обходится очень дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования.
Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.
Результаты обследования представляют объективную основу для формирования технического задания на информационную систему.
Техническое задание — это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
При разработке технического задания необходимо решить следующие задачи:
Проектирование информационных систем
56
м
►	установить общую цель создания ИС, определить состав подсистем и функциональных задач;
►	разработать и обосновать требования, предъявляемые к подсистемам;
►	разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);
►	установить общие требования к проектируемой системе;
►	определить перечень задач создания системы и исполнителей;
►	определить этапы создания системы и сроки их выполнения;
►	провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.
Типовые требования к составу и содержанию технического задания приведены в таблице 2.1 [53].
Таблица 2.1
Состав и содержание технического задания (ГОСТ 34.602- 89)
Раздел	Содержание
1	2
Общие сведения	Полное наименование системы и ее условное обозначение Шифр темы или шифр (номер) договора Наименование предприятий разработчика и заказчика системы Перечень документов, на основании которых создается ИС Плановые сроки начала и окончания работ Сведения об источниках и порядке финансирования работ Порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств
глава 2
1 Р)сновы методологии проектирования информационных систем
Продолжение табл. 2.1
1	2
Назначение и цели создания (развития) системы	Вид автоматизируемой деятельности Перечень объектов, на которых предполагается использование системы Наименования и требуемые значения технических, технологических, производственноэкономических и других показателей объекта, которые должны быть достигнуты при внедрении ИС
Характеристика объектов автома- тизации	Краткие сведения об объекте автоматизации Сведения об условиях эксплуатации и характеристиках окружающей среды
Требования к системе	Требования к системе в целом: —	требования к структуре и функционированию системы (перечень подсистем, уровни иерархии, степень централизации, способы информационного обмена, режимы функционирования, взаимодействие со смежными системами, перспективы развития системы); —	требования к персоналу (численность пользователей, квалификация, режим работы, порядок подготовки); —	показатели назначения (степень приспособляемости системы к изменениям процессов управления и значений параметров); —	требования к надежности, безопасности, эргономике, транспортабельности, эксплуатации, техническому обслуживанию и ремонту, защите и сохранности информации, защите от внешних воздействий, к патентной чистоте, по стандартизации и унификации Требования к функциям (по подсистемам): —	перечень подлежащих автоматизации задач; —	временной регламент реализации каждой функции;
58 Проектирование информационных систем
Продолжение табл. 2.1
1	2
	— требования к качеству реализации каждой функции, к форме представления выходной информации, характеристике точности, достоверности выдачи результатов; —	перечень и критерии отказов Требования к видам обеспечения: —	математическому (состав и область применения математических моделей и методов, типовых и разрабатываемых алгоритмов); —	информационному (состав, структура и организация данных, обмен данными между компонентами системы, информационная совместимость со смежными системами, используемые классификаторы, СУБД, контроль данных и ведение информационных массивов, процедуры придания юридической силы выходным документам); —	лингвистическому (языки программирования, языки взаимодействия пользователей с системой, системы кодирования, языки ввода-вывода); —	программному (независимость программных средств от платформы, качество программных средств и способы его контроля, использование фондов алгоритмов и программ); —	техническому; —	метрологическому; —	организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала); —	методическому (состав нормативно- технической документации)
Состав и содержание работ по созданию системы	Перечень стадий и этапов работ Сроки исполнения Состав организаций — исполнителей работ
глава 2
xf)cHOBM методологии проектирования информационных систем
Окончание табл. 2.1
1	2
	Вид и порядок экспертизы технической документации Программа обеспечения надежности Программа метрологического обеспечения
Порядок контроля и приемки системы	Виды, состав, объем и методы испытаний системы Общие требования к приемке работ по стадиям Статус приемной комиссии
Требования к составу и содержанию работ по подготовке АИС к вводу	Преобразование входной информации к машиночитаемому виду Изменения в объекте автоматизации Сроки и порядок комплектования и обучения персонала
Требования к документированию	Перечень подлежащих разработке документов Перечень документов на машинных носителях
Источники разработки	Документы и информационные материалы, на основании которых разрабатывается ТЗ и система
Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям.
Выполнение стадии эскизного проектирования не является строго обязательным. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.
Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:
►	функции ИС;
►	функции подсистем, их цели и ожидаемый эффект от внедрения;
Проектирование информационных систем
60
к
►	состав комплексов задач и отдельных задач;
►	концепция информационной базы и ее укрупненная структура;
►	функции системы управления базой данных;
►	состав вычислительной системы и других технических средств;
►	функции и параметры основных программных средств.
По результатам проделанной работы оформляется, согласовывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию системы.
На основе технического задания (и эскизного проекта) разрабатывается технический проект ИС. Технический проект ИС — это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятий по подготовке объекта к внедрению.
На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.
Состав и содержание технического проекта приведены в таблице 2.2 [53].
Таблица 2.2
Содержание технического проекта
Раздел	Содержание
1	2
Пояснительная записка	Основания для разработки системы Перечень организаций разработчиков Краткая характеристика объекта с указанием основных технико-экономических показателей его функционирования и связей с другими объектами
’лава 2
Q сновы методологии проектирования информационных систем
Продолжение табл. 2.2
1	2
	Краткие сведения об основных проектных решениях по функциональной и обеспечивающим частям системы
Функциональная н организационная структура системы	Обоснование выделяемых подсистем, их перечень и назначение Перечень задач, решаемых в каждой подсистеме, с краткой характеристикой их содержания Схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы
11 остановка задач и алгоритмы решения	Организационно-экономическая сущность задачи (наименование, цель решения, краткое содержание, метод, периодичность и время решения задачи, способы сбора и передачи данных, связь задачи с другими задачами, характер использования результатов решения, в которых они используются) Экономико-математическая модель задачи (структурная и развернутая форма представления) Входная оперативная информация (характеристика показателей, диапазон изменения, формы представления) Нормативно-справочная информация (НСИ) Информация, хранимая для связи с другими задачами Информация, накапливаемая для последующих решений данной задачи Информация по внесению изменений (система внесения изменений и перечень информации, подвергающейся изменениям) Алгоритм решения задачи (последовательность этапов расчета, схема, расчетные формулы) Контрольный пример (набор заполненных данными форм входных документов, условные документы с накапливаемой и хранимой
Проектирование информационных систем
62
в-
Продолжение табл. 2.2
1	2
	информацией, формы выходных документов, заполненные по результатам решения экономико-технической задачи и в соответствии с разработанным алгоритмом расчета)
Организация информационной базы	Источники поступления информации и способы ее передачи Совокупность показателей, используемых в системе Состав документов, сроки и периодичность их поступления Основные проектные решения по организации фонда НСИ Состав НСИ, включая перечень реквизитов, их определение, диапазон изменения и перечень документов НСИ Перечень массивов НСИ, их объем, порядок и частота корректировки информации Структура фонда НСИ с описанием связи между его элементами; требования к технологии создания и ведения фонда Методы хранения, поиска, внесения изменений и контроля Определение объемов и потоков информации НСИ Контрольный пример по внесению изменений в НСИ Предложения по унификации документации
Альбом форм документов	
Система математического обеспечения	Обоснование структуры математического обеспечения Обоснование выбора системы программирования Перечень стандартных программ
Принцип построения комплекса технических средств	Описание и обоснование схемы технологического процесса обработки данных Обоснование и выбор структуры комплекса технических средств и его функциональных групп
'лава 2	,	6л
Q сновы методологии проектирования информационных систем
Окончание табл. 2.2
1	2
	Обоснование требований к разработке нестандартного оборудования Комплекс мероприятий по обеспечению надежности функционирования технических средств
Расчет экономической эффективности системы	Сводная смета затрат, связанных с эксплуатацией систем Расчет годовой экономической эффективности, источниками которой являются оптимизация производственной структуры хозяйства (объединения), снижение себестоимости продукции за счет рационального использования производственных ресурсов и уменьшения потерь, улучшения принимаемых управленческих решений
Мероприятия по подготовке объекта к внедрению системы	Перечень организационных мероприятий по совершенствованию бизнес-процессов Перечень работ по внедрению системы, которые необходимо выполнить на стадии рабочего проектирования, с указанием сроков и ответственных лиц
Ведомость документов	
В завершение стадии технического проектирования производится разработка документации на поставку серийно выпускаемых изделий для комплектования ИС, а также определяются технические требования и составляются ТЗ на разработку изделий, не изготовляемых серийно.
На стадии рабочей документации осуществляется создание программного продукта и разработка всей сопровождающей документации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы. Разработанная документация
64
Проектирование информационных систем
должна быть соответствующим образом оформлена, согласована и утверждена.
Для ИС, которые являются разновидностью автоматизированных систем, устанавливают следующие основные виды испытаний: предварительные, опытная эксплуатация и приемочные. При необходимости допускается дополнительно проведение других видов испытаний системы и ее частей.
В зависимости от взаимосвязей частей ИС и объекта автоматизации испытания могут быть автономные или комплексные. Автономные испытания охватывают части системы. Их проводят по мере готовности частей системы к сдаче в опытную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных частей или для системы в целом.
. Для планирования проведения всех видов испытаний разрабатывается документ «Программа и методика испытаний». Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.
Предварительные испытания проводят для определения работоспособности системы и решения вопроса о возможности ее приемки в опытную эксплуатацию. Предварительные испытания следует выполнять после проведения разработчиком отладки и тестирования поставляемых программных и технических средств системы и представления соответствующих документов об их готовности к испытаниям, а также после ознакомления персонала ИС с эксплуатационной документацией.
Опытную эксплуатацию системы проводят в целях определения фактических значений количественных и качественных характеристик системы и готовности персонала к работе в условиях ее функционирования, а также определения фактической эффективности и корректировки при необходимости документации.
Приемочные испытания проводят для определения соответствия системы техническому заданию, оценки качества
глава 2
* Основы методологии проектирования информационных систем опытной эксплуатации и решения вопроса о возможности приемки системы в постоянную эксплуатацию.
2.3.2. Типовое проектирование ИС
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов [27]. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР) — это тиражируемое (пригодное к многократному использованию) проектное решение.
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР [23]:
►	элементные ТПР — типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
►	подсистемные ТПР — в качестве элементов типизации выступаю! отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
►	объектные ТПР — типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.
Каждое типовое решение предполагает наличие, помимо собственно функциональных элементов (программных или аппаратных), еще и документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.
Основные особенности различных классов ТПР приведены в таблице 2.3 [27].
3. Зак. 1035
Проектирование информационных систем
Таблица 2.3
Достоинства и недостатки ТПР
Класс ТПР. Реализация ТПР	Достоинства	Недостатки
1	2	3
Элементные ТПР. Библиотеки методо-ориентированных программ	Обеспечивается применение модульного подхода к проектированию и документированию ИС	Большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости и доработку ТПР отдельных элементов
Подсистемные ТПР. Пакеты прикладных программ	Достигается высокая степень интеграции элементов ИС Позволяют осуществлять модульное проектирование; параметрическую настройку программных компонентов на различные объекты управления	Адаптивность ТПР недостаточна с позиции непрерывного инжиниринга деловых процессов
Подсистемные ТПР. Пакеты прикладных программ	Обеспечивают сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки информации	Возникают проблемы в комплексировании разных функциональных подсистем, особенно в случае использования решений нескольких производителей программного обеспечения
Объектные ТПР. Отраслевые проекты ИС	Комплексирование всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости |	Проблемы привязки типового проекта к конкретному объекту управления, что вызывает в некоторых случаях даже необхо-
,ва 2	Л.	67
основы методологии проектирования информационных систем
Окончание табл. 2.3
1	2	3
	Открытость архитектуры — позволяет устанавливать ТПР на разных программно-технических платформах Масштабируемость — допускает конфигурацию ИС для переменного числа рабочих мест Конфигурируемость — позволяет выбирать необходимое подмножество компонентов	димость изменения организационно-экономической структуры объекта автоматизации
Для реализации типового проектирования используются два подхода [27]: параметрически-ориентированное проектирование и модельно-ориентированное проектирование.
Параметрически-ориентированное проектирование включает следующие этапы: определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач, анализ и оценка доступных ППП по сформулированным критериям, выбор и закупка наиболее подходящего пакета, настройка параметров (доработка) закупленного ППП.
Критерии оценки ППП делятся на следующие группы:
►	назначение и возможности пакета;
►	отличительные признаки и свойства пакета;
►	требования к техническим и программным средствам;
►	документация пакета;
►	факторы финансового порядка;
►	особенности установки пакета;
►	особенности эксплуатации пакета;
►	помощь поставщика по внедрению и поддержанию пакета;
►	оценка качества пакета и опыт его использования;
►	перспективы развития пакета.
з
68
Проектирование информационных систем
Внутри каждой группы критериев выделяется некоторое подмножество частных показателей, детализирующих каждый из десяти выделенных аспектов анализа выбираемых ППП.
Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок (например, 10-балльной). На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты также получаются экспертным путем.
Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.
Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия.
Типовая ИС в специальной базе метаинформации — репозитории — содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.
Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий.
Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС.
Qchobm методологии проектирования информационных систем ^9
Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.
Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих‘моделей в результате экспертного опроса (SAP Business Engineering Workbench).
Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы.
Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.
Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия.
Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе «Спецификация функциональных требований к ИС»). Для отображения процессов используется модель управления событиями (ЕРС — Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей —приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.
Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение различных бизнес-процессов.
Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала.
Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС, которые выявляются
70
Проектирование информационных систем
на основе результатов предпросктного обследования объекта автоматизации. Для оценки соответствия этим требованиям программных продуктов может использоваться описанная выше методика оценки ППП. После выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная модель ИС, в которой отражаются все особенности реализации ИС для конкретного предприятия. Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, АВАР в SAP, Tools в BAAN).
Реализация типового проекта предусматривает выполнение следующих операций:
►	установку глобальных параметров системы;
►	задание структуры объекта автоматизации;
►	определение структуры основных данных;
►	задание перечня реализуемых функций и процессов;
►	описание интерфейсов;
►	описание отчетов;
►	настройку авторизации доступа;
►	настройку системы архивирования.
а
Контрольные вопросы
1.	Дать определение понятию «жизненный цикл программного обеспечения». Каковы основные этапы жизненного цикла?
2.	Охарактеризовать модели жизненного цикла.
3.	Перечислить основные задачи проектирования.
4.	Основные этапы разработки технического проекта.
5.	Перечислить основные документы, разрабатываемые на каждом этапе проектирования информационных систем.
6.	В чем заключается сущность каскадного проектирования ИС?
7.	Какие подходы используются в реализации типового проектирования?
Организация ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ систем
В процессе проектирования и разработки ИС значительную роль играет решение вопросов декомпозиции ИС в виде полииерархической структуры — совокупности вертикальных и горизонтальных срезов (профилей), формирования типовых технологических решений. Типовые технологические решения невозможны без последовательной реализации технологической и системной интеграции.
3.1.	Полииерархическая структура информационной системы
и типовые технологические решения
ИС наглядно можно представить в виде полииерархической структуры — совокупности вертикальных и горизонтальных срезов, которые часто называют профилями (табл. 3.1). Профиль — это совокупность нескольких (или подмножество одного) базовых стандартов (и нормативных документов) с четко определенными и интегрированными подмножествами обязательных и факультативных возможностей, предназначенная для реализации заданной функции или группы функций. Вертикальную структуру образуют два среза — организационно-технологический и функциональнотехнологический, а горизонтальную три среза — организационно-функциональный, технологический и системно-технический [23].
В первом вертикальном профиле (организационно-технологическом) отражается взаимосвязь поддерживаемых системой функций организационного управления и информационных технологий, обеспечивающих их реализацию.
К*
Проектирование информационных систем
Таблица 3.1
Структура профилей информационной системы
Профили	1. Организационнотехнологический	2. Функциональнотехнологический
1. Организационно-функциональный	Функции организационного управления	Системно- организационная структура прикладных задач
2. Технологический	Информационные технологии	Программные средства и системы
3. Системнотехнический		Системно-технологическая среда
Во втором вертикальном профиле (функционально-технологическом) отражается взаимосвязь системно-организа-циойной структуры функциональных (прикладных) задач, программных средств, из которых они создаются, и системно-технических средств.
В верхнем (горизонтальном) профиле структуры сосредоточены функции организационного управления, поддерживаемые системой, составляющие их управленческие функции, а также управленческие задачи, на которые распадаются управленческие функции. Системный аналитик как бы создает иерархию автоматизируемых функций и задач, определяемую как декомпозиция автоматизируемого процесса организационного управления.
Чтобы верхний профиль системы не рассыпался, иерархию функций организационного управления в ИС «связывают» соответствующим прикладным уровнем, который представляет собой совокупность специального программного обеспечения следующей подчиненности:
1)	управленческие задачи —> функциональные задачи;
2)	управленческие функции функциональные комплексы задач;
3)	организационные функции управляющие функциональные комплексы.
глава 3
х (Организация проектирования информационных систем
73
Процессы обработки, накопления, хранения и передачи информации в ИС производятся в соответствии с определенными информационными технологиями: предметными, проблемными, функциональными. В ИС эти технологии образуют второй профиль. А для того чтобы и этот профиль был «устойчивым» в структуре системы, его поддерживают программные решения в следующей подчиненности: 1) предметные технологии —> технологические решения;
2)	проблемные технологии программно-технические решения;
3)	функциональные технологии —> операции обработки информации.
Оба рассмотренных выше профиля ИС «покоятся» на последнем, нижнем профиле — системно-технической среде.
Разработка и ввод в эксплуатацию ИС могут быть ускорены, если разработчик уже располагает набором типовых технологических подсистем, которые могут быть реально продемонстрированы заказчику (пользователю), и разработчик имеет реальную возможность квалифицированно помочь ему в практическом выборе соответствующих про-граммно-технических средств. Иными словами, заказчик и разработчик совместными усилиями формируют разумные функциональные требования к будущей ИС, удовлетворяющие обоих.
Обобщение и унификация осуществляются на функциональном уровне. Отсюда следует, что унификация (типо-вость) обеспечивается на уровне типовых технологических решений и уровне типовых программных продуктов. Системные программные средства и программные интерфейсы рассматриваются как средства обеспечения совместимости с технической средой, которая, кстати, уже может быть сформирована у заказчика.
Проектирование информационных систем
3.2.	Формирование и применение профилей информационных систем
Области применения современных информационных систем, таких как корпоративные ИС крупных предприятий, ИС органов государственного управления, ИС учреждений науки и образования, предъявляют к ним весьма высокие требования. Эти требования носят противоречивый характер, поскольку, с одной стороны, требуется обеспечить возможность изменений состава и функциональных свойств прикладных ИС, адекватных непрерывным изменениям в деятельности различных категорий пользователей ИС в условиях рыночной экономики и росту потребностей в информационном обеспечении предприятий и населения, а с другой — необходимо следовать международным и национальным стандартам ИТ, а эти стандарты носят долгосрочный характер и закрепляют консервативность стандартизованных проектных решений ИС.
Компромисс этих противоречивых требований достигается применением принципов открытых систем. Открытые системы определены как системы, в которых реализован исчерпывающий и согласованный набор международных стандартов информационных технологий и профилей функциональных стандартов, которые специфицируют интерфейсы, службы и поддерживающие форматы, чтобы обеспечить интероперабельность и мобильность приложений, данных и персонала. Исходя из этого определения сформированы общие положения функциональной стандартизации ИТ [42], связанные с выделением функций ИС и их компонентов, фиксируемых как объекты функциональных стандартов. Это позволяет иметь стандартизованные проектные решения ИС с тем, чтобы снизить затраты и сократить сроки создания ИС в условиях роста их сложности и наращивания функций. Введенное понятие профиль определяет их как подмножества и(или) комбинации базовых стандартов ИТ, необходимые для реализации заданных наборов функций [42].
глава 3
х (Организация проектирования информационных систем
75
Каждую сложную ИС (уникальную, интегрированную, корпоративную и типовую, тиражируемую для определенных областей применения) предлагается сопровождать ее профилем, включающим в себя совокупность базовых стандартов ИТ и спецификаций, которым должны отвечать ИС в целом и ее компоненты. В качестве методики формирования и применения профилей ИС рассматривается подход, предложенный Филйновым Е.Н. и Бойченко А.В. [45].
Категории и виды профилей ИС. В зависимости от сферы распространения профилей ИС рассматриваются следующие их категории:
►	профили конкретных ИС, определяющие стандартизованные проектные решения в пределах проекта данной ИС и имеющие статус документации проекта в части нормативных требований или статус стандарта предприятия, для которого создается эта ИС;
►	профили группы типовых, тиражируемых ИС, предназначенных для определенной области применения, имеющие статус отраслевого (ведомственного) стандарта для этой области или статус стандарта организации, разрабатывающей и поставляющей такие ИС (системного интегратора);
►	стратегические профили для определенной области применения ИС, определяющие ориентацию информатизации этой области на долгосрочный период, например, профили переносимости приложений между разными ИС в этой области.
Принципы построения и структура профиля ИС. Структура профиля ИС тесно связана со структурой самой ИС, которая определяется в результате декомпозиции заданных для ИС функций и разбиения ее на взаимодействующие компоненты. Для каждого компонента, выделяемого в структуре ИС, конкретизируется состав выполняемых им функций и его взаимосвязи с другими компонентами. Разбиение ИС на взаимодействующие компоненты имеет иерархический характер и дает многоуровневую структуру построения ИС.
^7^Проектирование информационных систем
Этому же принципу должна соответствовать иерархия профилей компонентов, предусматривающая вложенность в профили крупных узлов ИС профилей, специфицирующих отдельные компоненты каждого’ узла.
В крупном плане концептуальная модель предусматривает разбиение ИС на приложения (прикладные программные комплексы), реализующие заданные функции ИС, и среду, обеспечивающую подготовку и выполнение приложений. Между ними определяются стандартизованные интерфейсы прикладного программирования.
Кроме того, определяются стандартизованные интерфейсы взаимодействия данной ИС с внешней для нее средой — другими ИС и сетью Интернет и(или) корпоративными сетями.
Спецификации функций компонентов ИС рассматриваются по четырем функциональным группам:
►	функции, обслуживающие интерфейс ИС с пользователями;
►	функции организации процессов обработки данных (системные функции среды);
►	функции представления и хранения данных;
►	коммуникационные функции.
Эти функции могут быть реализованы как приложениями, так и компонентами среды ИС. Их спецификации составляют плоскость основных функций ИС.
Функции системного и сетевого администрирования распределены между компонентами среды и приложений. Они образуют вторую плоскость концептуальной модели, в которую включаются управление приложениями, управление средствами пользовательского интерфейса, управление базами данных, управление процессами, обеспечиваемое операционными системами, управление коммуникационной сетью или отдельными узлами сети, управление средствами защиты информации.
Функции средств защиты информации в ИС также распределены между разными компонентами ИС. Часть из них
рлава 3
1 Организация проектирования информационных систем
Ml
реализуется штатными средствами, встроенными в операционные системы, СУБД, ПО промежуточного слоя (например, в мониторы транзакций), а часть обеспечивается специальными средствами защиты. Поэтому в концептуальную модель введена третья плоскость — функции защиты информации.
Наконец, четвертую плоскость составляют функции инструментальных средств, встроенных в ИС для поддержки ее эксплуатации и сопровождения.
Структура полного профиля ИС включает в себя следующие функциональные профили:
►	профиль приложений ИС, содержащий спецификации архитектуры и структуры подсистем ИС, программных интерфейсов взаимодействия между ними, форматов обмена данными и общих требований к прикладному ПО;
►	профиль среды ИС, содержащий спецификации интерфейсов прикладного программирования, функций ПО промежуточного слоя, СУБД, пользовательских интерфейсов, операционных систем и требований к техническим средствам, а также протоколов телекоммуникационной среды;
►	профиль средств системного и сетевого администрирования;
►	профиль средств защиты информации;
►	профиль инструментальных средств, встроенных в ИС.
Кроме того, в полный профиль ИС следует включать вспомогательные профили, регламентирующие процессы создания, сопровождения и развития ИС и нормы на средства поддержки этих процессов. К ним относятся:
►	профили процессов жизненного цикла прикладного ПО ИС (по стандарту ISO 12207 [43]);
►	профили обеспечения качества прикладных программных средств ИС;
►	профили инфраструктуры проекта данной ИС.
В этих профилях должны быть указаны стандарты:
►	для описания методологии и технологии создания, сопровождения и развития прикладного ПО ИС;
78
Проектирование информационных систем
►	описания требований и регламентов тестирования прикладных программных средств;
►	регламентов документирования прикладного ПО;
►	регламентов управления конфигурацией прикладного ПО (контроля используемых версий приложений, внесения в них изменений и т.д.).
Под средствами EAI понимается комбинация процессов, программных средств, стандартов и аппаратуры, благодаря которой обеспечивается «бесшовная» интеграция приложений в пределах одной ИС или двух и более ИС уровня предприятия, позволяющая им функционировать как единой системе. Хотя средства EAI, как правило, рассматриваются применительно к построению ИС для какого-либо одного предприятия, в настоящее время эти средства требуются и для интеграции ИС, принадлежащих нескольким предприятиям. Например, они нужны при создании систем класса В2В (Business-to-Business), когда необходимо обеспечить единые бизнес-транзакции в виде цепочек приложений, выполняемых в нескольких системах.
Применение средств EAI рассматривается для всех уровней структуры интегрированных ИС. В рамках реализации EAI для ИС обычно рассматриваются следующие способы интеграции приложений, каждый из которых опирается на соответствующие стандарты «де-юре» и «де-факто».
1.	Интеграция бизнес-процессов предприятия. Здесь необходимо обеспечить непосредственное взаимодействие приложений, которые поддерживают бизнес-объекты и бизнес-функции, свойственные определенным бизнес-процессам. Программные интерфейсы взаимодействия этих приложений определяются с учетом функций управления процессами, модели бизнес-процессов, построенной с помощью инструментальных средств инжиниринга (реинжиниринга) бизнес-процессов, и требуемой входной (выходной) информации этих процессов.
2.	Интеграция приложений. Интеграция осуществляется на основе предоставления функций или данных, свойствен
Глава 3		79
* Организация проектирования информационных систем_
ных одному какому-либо приложению, в распоряжение другого приложения с тем, чтобы их взаимодействие на стадии исполнения обеспечило бы выполнение определенной прикладной функции ИС. Как правило, средствами интеграции приложений в данной группе средств выступают службы программного обеспечения промежуточного слоя. Такие службы иногда, называют связующим программным обеспечением. Они обеспечивают прозрачную работу приложений в неоднородной сетевой среде, предоставляя им услуги в виде интерфейсов прикладного программирования (API), чтобы обеспечить взаимодействие частей приложений, распределенных по разным узлам корпоративной сети. К службам middleware, прежде всего, относятся службы вызова удаленных процедур, обмена сообщениями, посредники (брокеры) запросов к объектам, мониторы транзакций. В качестве этих средств далее рассматриваются серверы приложений.
3.	Интеграция данных. Успешная реализация интеграции бизнес-процессов и приложений на двух предыдущих уровнях зависит от того, как будут интегрированы в системе данные, принадлежащие разным источникам данных, и базы данных. На этом уровне в целях интеграции данные должны быть идентифицированы (указано их местоположение в распределенной системе), каталогизированы, должна быть построена модель метаданных (описание данных о данных).
4.	Интеграция платформ. Системотехническая структура современных ИС уровня предприятия отражает их построение на основе распределенной клиент-серверной архитектуры — в решениях последних лет трехзвенной или многозвенной. Такая структура представляет собой совокупность рабочих мест пользователей ИС (клиентов) и серверов, объединенных корпоративной сетью. Узлы этой сети — клиенты и серверы — могут быть реализованы на базе неоднородных аппаратно-программных платформ, то есть могут опираться на разные машинные архитектуры и операционные системы. Это определяет необходимость иметь средства
80
Проектирование информационных систем
интеграции неоднородных платформ, предоставляемые их поставщиками, например средства интеграции систем, базирующихся на Windows NT или Windows 2000 и на Unix.
5.	Интеграции компонентов в составе приложений. Модульная структура приложений ИС является одним из основных способов обеспечения свойств их открытости. В процессе проектирования ИС заданный состав ее прикладных функций декомпозируется в виде функциональных подсистем, объединяющих родственные группы функций, затем подсистемы разбиваются на взаимодействующие между собой задачи и комплексы задач, а программы, реализующие каждую из задач, разбиваются на программные модули вплоть до простейших неделимых элементов программной системы. Результатом процесса проектирования ИС является ее иерархическая структура, представленная на нижнем уровне в виде программных модулей, которые подлежат программированию или выбору из состава уже существующих для повторного использования в создаваемой системе. В последние 5-7 лет серьезное развитие и применение получила компонентная разработка приложений, главной особенностью которой является создание унифицированных интерфейсов программных модулей. Компонентом считается программный модуль и его унифицированный интерфейс, посредством которого к нему могут подключаться другие компоненты и поддерживать взаимодействие с ним.
В крупном плане концептуальная модель предусматривает разбиение ИС на приложения (прикладные программные комплексы), реализующие заданные функции ИС, и среду, обеспечивающую подготовку и выполнение приложений. Между ними определяются стандартизованные интерфейсы прикладного программирования (API).
Кроме того, определяются стандартизованные интерфейсы взаимодействия данной ИС с внешней для нее средой — другими ИС и сетью Интернет и(или) корпоративными сетями (EEI).
глава 3
'•(Организация проектирования информационных систем
81
Спецификации функций компонентов ИС рассматриваются по четырем функциональным группам:
►	функции, обслуживающие интерфейс ИС с пользователями;
►	функции организации процессов обработки данных (системные функции среды);
►	функции представления и хранения данных;
►	коммуникационные функции.
Эти функции могут быть реализованы как приложениями, так и компонентами среды ИС. Их спецификации составляют плоскость основных функций ИС.
Функции системного и сетевого администрирования распределены между компонентами среды и приложений. Они образуют вторую плоскость концептуальной модели, в которую включаются управление приложениями, управление средствами пользовательского интерфейса, управление базами данных, управление процессами, обеспечиваемое операционными системами, управление коммуникационной сетью или отдельными узлами сети, управление средствами защиты информации.
Функции средств защиты информации в ИС также распределены между разными компонентами ИС. Часть из них реализуется штатными средствами, встроенными в операционные системы, СУБД, ПО промежуточного слоя (например, в мониторы транзакций), а часть обеспечивается специальными средствами защиты. Поэтому в концептуальную модель введена третья плоскость — функции защиты информации.
Наконец, четвертую плоскость составляют функции инструментальных средств, встроенных в ИС для поддержки се эксплуатации и сопровождения.
Формирование и применение профиля ИС как органическая часть процессов жизненного цикла. В процессы системного анализа, проектирования и разработки сложных ИС, их сопровождения и развития рекомендуется включать, как
82
Проектирование информационных систем
их органическую часть, работы, связанные с формированием и применением профилей ИС; эти работы следует так же . планировать и документировать, как и основные работы указанных процессов. Предлагаемая методика [45] формирования профиля ИС включает следующие виды работ:
►	выбор состава прикладных функций ИС, сведений о ее архитектуре и структуре на основе результатов предпро-ектного анализа;
►	выбор и конкретизацию концептуальной модели ИС на базе OSE/RM применительно к рассматриваемой на стадии системного проекта архитектуре, например, архитектуре «клиент-сервер»;
►	параметризацию компонентов приложений и среды ИС на стадии детального проектирования с определением  функциональных параметров (состава сервисов и услуг) для каждого компонента и интерфейсных параметров (характеристик взаимодействия данного компонента с другими компонентами среды и приложениями);
►	наполнение профиля ИС базовыми стандартами ИТ путем выбора их из номенклатуры международных стандартов «де-юре» и «де-факто»;
►	уточнение концептуальной модели ИС и параметров компонентов;
►	гармонизацию базовых стандартов, включаемых в профиль, с формированием ограничительных спецификаций их обязательных и факультативных возможностей, для того чтобы обеспечить совместимость компонентов ИС;
►	разработку спецификаций интерфейсов и протоколов взаимодействия компонентов, которые не обеспечены базовыми стандартами ИТ, по возможности с использованием формальных языков спецификаций, таких как RSL, IDL, SDL, ADL [44];
►	формирование требований соответствия профилю ИС и ссылок на соответствующие методы тестирования и тесты;
►	оформление профиля ИС;
►	согласование и утверждение профиля ИС.
глава 3
л-()РганизаЦия проектирования информационных систем_
Полученный в результате этих работ профиль представляет собой выбранный набор базовых стандартов с их ограничительными спецификациями и дополнительные спецификации для требований, не обеспеченных базовыми стандартами. Кроме того, для удобства модификации разработанного профиля в процессе жизненного цикла ИС документируются вышеперечисленные стадии проектирования профиля, и для определения места работы каждого базового стандарта и спецификаций, относящихся к профилю среды, документируется конкретизированная применительно к данной ИС модель OSE/RM.
Методика является ориентировочной и может варьироваться в зависимости от сложности проектируемой ИС, глубины и ширины придания ей свойств открытости, используемых формализмов при проектировании ИС и ее профиля и др.
3.3.	Информационное обеспечение процесса проектирования
В комплекс средств проектирования входит информационное обеспечение, которое представляет собой совокупность документов, описывающих стандартные проектные процедуры, типовые проектные решения, типовые элементы и комплектующие изделия, материалы и другие данные. Главной целью создания информационного обеспечения процесса проектирования является разработка информационной системы, позволяющей правильно и быстро решать проектные задачи. Это может быть достигнуто своевременной выдачей источнику запроса полной и достоверной информации для выполнения определенной части процесса проектирования систем.
Основные требования к информационному обеспечению'.
►	наличие необходимой информации для обеспечения как автоматизированных, так и ручных процессов проектирования;
84
Проектирование информационных систем
►	возможность хранения и поиска информации, представляющей результат ручных и автоматизированных процессов проектирования;
►	достаточный объем хранилищ информации (структура системы должна допускать возможность наращивания емкости памяти вместе с ростом объема информации, подлежащей хранению); одновременно необходимо обеспечить компактность хранимой информации и минимальное изнашивание носителей информации;
►	достаточное быстродействие системы информационного обеспечения;
►	возможность быстрого внесения изменений и корректировки информации, доведения этих изменений до потребителя.
. При создании информационного обеспечения проектирования основная проблема заключается в преобразовании информации, необходимой для выполнения проектных работ над определенным классом объектов, в форму, приемлемую и наиболее рациональную для обработки. Множество данных, которые потенциально могут использоваться при проектировании или служить запоминаемым результатом ее работы, образуют информационную базу данных системы. Типовыми группами данных информационного обеспечения проектирования являются классификаторы и таблицы соответствия для них, научно-техническая и расчетно-проектная (оперативная) информация.
Взаимодействие информационной базы и информационной системы осуществляется через специально организуемый интерфейс, который защищает проектные модули от влияния специфики информационной системы, поддерживая тем самым независимость проектных операций от вида представления информации в базе данных. В функции этого интерфейса входит также согласование и сопряжение информационной системы и проектных модулей по форматам записей (информационный аспект), по обозначениям данных (содержательный аспект) и по программным сред
рлава 3
А Организация проектирования информационных систем
85
ствам, языкам программирования и т.п. (программный аспект).
Информация, используемая при проектировании, может быть разделена на статическую и динамическую.
Статическая информация характеризуется сравнительно редкими изменениями. К этой информации следует отнести данные ТЗ на проектирование и справочные данные, имеющие большой объем. Объем данных ТЗ на проектируемый объект значительно меньше объема справочных данных, но круг лиц, имеющих право вносить изменения в ТЗ, должен быть еще более ограничен, чем круг лиц, имеющих право корректировать справочные данные.
Динамическая информация состоит из данных, накапливаемых для выполнения определенных операций проектирования (промежуточные данные), и данных, представляющих собой результат проектирования при выполнении данных операций. Промежуточные данные постоянно меняются.
Информация, используемая при проектировании, по виду ее представления может быть подразделена на документальную, иконографическую и фактографическую.
Документальная информация—это метаинформация. Она представляет собой поисковый образ документа, находящегося в базе данных. При необходимости может быть выдана совокупность документов, удовлетворяющих поисковому образу. Информация такого вида широко используется для нахождения сведений об аналогах объекта проектирования, о патентах и авторских свидетельствах, методике проектирования и расчетов, результатах испытания и т.п.
Информация, которая содержится в изображениях документов (чертежи, фотографии и т.д.), в идентичной форме представления называется иконографической. Этот вид информации служит для хранения больших объемов графической информации, поиск которой может осуществляться с помощью сопровождающей ее документальной информации.
86
Проектирование информационных систем
Основу базы данных составляет фактографическая информация. Она представляет собой числовые и буквенные справочные данные о материалах, ценах, комплектующих изделиях, о спроектированных объектах и т.п. Сюда же относятся данные, необходимые для выполнения расчетов: коэффициенты, таблицы, аппроксимированные графические зависимости и т.д.
В настоящее время различают два вида автоматизированных информационных систем — банки данных и информационно-поисковые системы (ИПС). Эти системы различаются видом хранимой и обрабатываемой информации и информационным языком, с помощью которого осуществляется описание данных и манипуляции с ними. Эти различия накладывают определенные ограничения на организацию информации в системе (структуры данных, форматы, связи, доступ и т.д.) и на программную реализацию.
3-4. Подходы к организации и планированию разработки информационной системы
Процесс проектирования ИС (внедрения ИС) всегда преследует конкретные цели — такие, как, например, повышение прозрачности бизнеса, сокращение сроков обработки информации, экономия накладных расходов и т.д. Современные информационные системы — это крупные программные системы, содержащие в себе множество модулей, функциональных, интерфейсных элементов, отчетов и т.д. Применение принципов абстракции и декомпозиции позволяет осуществлять моделирование сложных объектов (сложность которых обусловлена целями, преследуемыми заинтересованными в проектировании ИС лицами) за счет разделения требований по уровням. Требования — это исходные данные, на основании которых проектируются и создаются информационные системы. Причем уровни требований свя
глава 3
д (Организация проектирования информационных систем
87
заны, с одной стороны, с уровнем абстракции системы, с другой — с уровнем управления на предприятии.
Основным источником требований к информационной системе являются соображения, высказанные представителями заказчика. Проблема состоит в том, что требования формулируются к создаваемой, еще не существующей системе, т.е., по сути, решается начальная подзадача задачи проектирования ИС, а' представители заказчика далеко не всегда бывают компетентны в данном вопросе. Поэтому, наряду с требованиями, высказанными заказчиком, целесообразно собирать и требования от других совладельцев системы: сотрудников аналитической группы исполнителя, внешних экспертов и т.д. Совокупность требований может быть рассмотрена как модель проектируемой системы. В качестве методов выделения данных требований (сбора информации) могут быть использованы методы, применяемые в социологических исследованиях: опрос (анкетирование, интервьюирование), наблюдение, анализ документов.
Авторы [82] выделяют три уровня требований:
►	на верхнем уровне представлены бизнес-требования (business requirements). Бизнес-требования обычно формулируются топ-менеджерами либо акционерами предприятия;
►	следующий уровень — уровень требований пользователей (user requirements). Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований;
►	третий уровень — функциональные требования (functional requirements).
Разработанные требования используются следующей группой пользователей:
►	специалистами по проектированию ИС (анализу требований) — постановка задачи, определение рамок проекта;
88 Проектирование информационных систем
►	представитями заказчика — постановка задачи, определение рамок проекта, контроль работы исполнителя, приемка результатов работы;
►	группой проектировщиков :— разработка архитектуры, проектирование подсистем;
►	программистами — разработка программного кода;
►	тестировщиками — составление тест-плана, тестовых сценариев;
►	менеджером проекта—планирование и контроль исполнения работ.
Начальная стадия проектирования ИС направлена на анализ всех уровней требований. Анализ требований — это процесс (бизнес-процесс) и, следовательно, к нему подходят методы и средства процессного подхода к управлению. Он направлен на моделирование воображаемого, еще не существующего объекта (ИС), т.е. сначала создается модель, а затем, на ее основании, синтезируется объект. Результаты анализа требований влияют на эффективность всего процесса проектирования ИС. Кроме процесса анализа требований авторами [82] выделяются бизнес-анализ и бизнес-моделирование проектируемого объекта. В качестве подхода к бизнес-моделированию проектируемого объекта в учебном пособии представлена методология, предложенная С.Д. Па-ронджановым [48] (см. глава 5, п. 5.2).
Методологии бизнес-анализа можно разделить на три категории по типам моделей:
►	модели, преследующие цель анализа и улучшения организационной системы (например, SWOT, VCM, BPR, ISA);
►	модели общего назначения (подробно будут рассмотрены в главе 6);
►	модели, специально разработанные для использования при автоматизации (будут рассмотрены в главе 7, п. 7.2.2). Подход SWOT. SWOT — Strengths, Weaknesses, Opportunities, Threats (сильные стороны, слабые стороны, возможности, угрозы). Это подход «сверху-вниз».
глава 3	eo
л Организация проектирования информационных систем_
Этапы SWOT:
►	определяется уникальный характер организации и ее са-мовидение (так называемая миссия организации), другими словами — это цели, которые организация перед собой ставит. Фирма, нацеленная на стабильное существование и развитие, на первое место ставит потребности клиентов;
►	определяются внутренние сильные и слабые стороны организации — отдельно в таких областях, как управление, производственный процесс, кадры, финансы, маркетинг, исследования. На основе рассмотрения выделяются приоритеты. Важно для определения бизнес-стратегий;
►	определяются внешние возможности и угрозы — неуправляемые внешние экономические, социальные, политические и технологические факторы. Они воспринимаются как ограничения на деятельность организации. Возможности и угрозы также рассматриваются с точки зрения составляющих. Часть угроз можно блокировать, к другим — приспосабливаться;
► определяются практические приоритетные цели на среднесрочный период. Целей должно быть немного. Типичные цели: рост уровня удовлетворения потребителей; введение новых видов услуг; усиление конкурентоспособности; усиление контроля за поставщиками. Проводится SWOT-контроль целей.
Подход VCM. VCM — Value Chain Model, модель цепочек ценностей [80]. В определенном смысле конкурирующий с SWOT подход. Цель анализа цепочки — найти слабые звенья. В первую очередь выделяется основная производственная цепочка: входящее снабжение — обработка (производство) — исходящее снабжение (складирование, упаковка, транспорт) — сбыт и маркетинг — учет и контроль. Из других цепочек выделим поддерживающую деятельность: инфраструктура — администрация — управление кадрами — анализ деятельности — исследования и разработки. Эти направления могут существенным образом
Проектирование информационных систем
способствовать эффективности основного вида деятельности. В «исследования и разработки» входит создание ИС.
Модель VCM так же, как и SWOT, является фоном для разработки ИС. На практике ликвидация слабых мест сейчас в значительной степени связана с внедрением ИТ. Однако значение ИТ (и соответственно подхода VCM) оказывается еще шире, так как внедрение ИТ и ИС, в частности, способно преобразовывать ценностные цепочки и даже изменять способы ведения бизнеса. Этот факт может быть истолкован как положительная обратная связь ИТ и производственного процесса.
Приведем концептуальные этапы внедрения ИТ:
►	оценить информационную емкость процессов и продуктов;
►	понять, как ИТ создает конкурентное преимущество, ранжировать эти способы;
►	оценить роль ИТ в отраслевой структуре;
►	разработать план, направленный на извлечение выгод от использования ИТ;
►	исследовать, как ИТ может создать новые направления в бизнесе и в деятельности организации.
Подход BPR. BPR (Business Process Reengineering, реинжиниринг (реконструкция) бизнес-процессов) — подход к организации производства [59], основанный на отрицании системы, сложившейся еще со времен Адама Смита (XVII).
Подходом отрицаются следующие принципы:
►	жесткое разделение труда (в этом случае размыта ответственность за конечный результат);
►	иерархическая система управления (не работают горизонтальные производственные связи, система плохо воспринимает любую перестройку и новые технологии);
►	стремление к крупномасштабному производству (в целом получается дешевле, но большая система не способна отслеживать быстрые изменения рынка и требования потребителя, она долго «разворачивается» при изменении условий конкуренции, и в совокупности получается не выигрыш, а проигрыш).
рлава 3
* Организация проектирования информационных систем
91
-мм
Системы «по Смиту» являются слишком «жесткими», они нс способны быстро адаптироваться, развиваться, рисковать и выигрывать.
Основные идеи BPR: фирма должна сосредоточиться на бизнес-процессах как таковых. Иерархичность строения должна быть резко уменьшена, горизонтальные связи не просто расширены, а созданы в привязке к конечному результату на основе производственных цепочек. То есть необходимо создавать команды и ключевые должности, отвечающие за результат, а не цеха и отделы с собственным начальством, направлениями работы и отчетами за выполнение отдельных функций, а не за сбыт конечной продукции. Объединение созданного отдельными людьми и автоматами в единое целое должно иметь высший приоритет, за это должны отвечать отдельные люди с высокими полномочиями, ответственностью и оплатой труда.
Переход на такой режим и назван реинжинирингом (BPR). Выполнение последовательных цепочек операций, их «склейку» и всевозможные проверки удобно понимать как поток работ (workflow, work diagrams). Потоки включают в себя события, документы и другую информацию; по ним удобно рассчитывать требуемое время, материальные ресурсы, финансовые средства, информационные ресурсы. Под них необходимо формировать бригады работников и рассматривать их как основные организационные единицы, определять требуемое оборудование, площади, техническое обслуживание.
С теоретической точки зрения, во главу угла ставятся горизонтальные связи при минимальном сохранении вертикальных. Место ИС в этом случае состоит в осуществлении и поддержке групп процессов.
Реинжиниринг представляет собой схему модернизации, которая может улучшить такие, считавшиеся несовместимыми параметры, как качество, скорость, себестоимость, гибкость, удобство работы. При этом сфера воздействия ИС охватывает не только собственно производство, но и снаб-
Проектирование информационных систем жение, сбыт, маркетинг, управление внешними финансовыми потоками. Однако радикальные изменения менее эффективны для отлаженного однородного (не сложного по своей структуре) производства. Радикальные шаги по реинжинирингу могут встретить внутреннее сопротивление, что также приводит к неуспеху. Поэтому общей рекомендацией считается тезис о продуманной оценке возможностей реинжиниринга для данной организации и необходимости специальной подготовки к ее проведению.
Подход ISA. ISA — Information Systems Architecture, архитектура информационных систем. Этот подход представляет собой начальный этап проектирования именно ИС, а не бизнес-процессов в целом. Его особенностью является использование принципа «снизу-вверх», в отличие от традиционной схемы, когда начинают с общей цели и далее делят ее на отдельные подцели и операции. Практическое содержание подхода ISA также достаточно своеобразно. Оно заключается в обращении с шестью одинаковыми по форме (но не по содержанию) вопросами к пяти основным участникам разработки ИС. Поэтому ISA-подход также известен как подход «5 х 6».
Перечислим тех, кому задаются вопросы:
►	ответственный за ИТ у заказчика ИС (планировщик) — определяет границы ИС;
►	представитель высшего руководства заказчика ИС (владелец) — определяет соответствие ИС задачам данной организации (что хотелось бы иметь и для чего), в частности, финансовые затраты и сроки;
►	ответственный представитель исполнителя (проектировщик) — определяет физическую модель системы, ее основные компоненты (hard, soft и др.);
►	представитель исполнителя (конструктор) — обеспечивает предложения по детализации технологических решений (представитель исполнителя);
►	поставщик (субподрядчик) — поставляет компоненты системы.
рлава 3
х Организация проектирования информационных систем
93
Перечислим задаваемые вопросы.
► Что составляет сущность (с какими данными будет работать ИС)?
► Как сущность функционирует (каковы здесь бизнес-про-цессы, какие задачи будут решаться)?
► Где сущность расположена (компоненты ИС и их размещение)?
► Кто работает с сущностью (кто будут пользователи)?
► Когда с сущностью что-то происходит (изменение данных, распределение событий и состояний во времени)?
► Почему сущность существует (мотивация организации)?
Ответы сводятся в таблицу. Ее размер будет 5 х п за счет того, что некоторых разработчиков будет больше, чем один.
Очевидно, что ответы у перечисленных участников разработки будут различны и, возможно, противоречивы. Различен будет и уровень детализации. Но считается, что комбинация точек зрения и описаний, представленных в ячейках таблицы ISA, дает важный материал для сведения мнений к единому, для систематизации задач и предложений относительно согласованной архитектуры ИС. Участники заполнения таблицы, скорее всего, будут иметь различные взгляды и использовать различные модели. Выявление этого на начальной стадии работы считается залогом дальнейшего продвижения к согласованности, а не к конфликтам на стадии разработки и сдачи ИС.
С таблицей ответов работают аналитики. Они указывают на несоответствия и обычно представляют вопросы для повторного ответа с учетом замечаний. Методом итераций согласуются позиции всех участников. Залогом этого считается желание всех участников создать эффективную ИС. Именно поэтому, скажем, руководитель организации заказчика будет пытаться понять, почему его мнение не соответствует мнению рядового программиста-исполнителя.
Каждая рассмотренная методика работает на своем уровне проектирования ИС. Например, подход BPR направлен на осуществление перехода проектируемого объекта
Проектирование информационных систем
из одного состояния в другое (реинжиниринг). Метод SWOT (маркетинговый аналитический инструмент) работает именно с требованиями бизнеса и потребителей, а также с контекстом объекта проектирования. Подход ISA ориентирован на изучение уровня функциональных требований, a VCM — на выявление требований пользователей ИС, так как ориентирован на анализ сети процессов системы.
L-J Контрольные вопросы
1. Дать определение понятию «полииерархическая структура информационной системы».
2. Охарактеризовать структуру профилей информационной системы.
3'. Перечислить основные виды и категории профилей информационных систем.
4.	Каковы основные принципы построения структуры профилей ИС?
5.	Определить роль и место системы профилей ИС в моделях жизненного цикла ИС.
6.	Какие предъявляются требования к информационному обеспечению процесса проектирования?
7.	Перечислить подходы к организации и планированию процесса проектирования ИС.
8.	В чем заключается сущность рассматриваемых подходов к организации и планированию проектов?
Планирование и УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМИ ПРОЕКТАМИ
Планирование и управление информационными проектами во многом определяют эффективность создаваемой ИС как в плане достижения и реализации заданных функций, так и в экономическом плане. На самом деле, оценка стоимости ИС позволяет связать экономические и функционально-технологические аспекты проектирования и разработки. Неумение приемлемо точно оценивать затраты на проект часто приводит к негативным последствиям. Организация финансового планирования и достижения целей управления достигается упорядочением работ, выполняемых на всех фазах жизненного цикла ИС.
Оценка стоимости информационной системы определяется в целях:
►	принятия решения о целесообразности проекта;
►	сравнения вариантов автоматизации в процессе выбора;
►	планирования расходов на проект автоматизации;
►	контроля фактических расходов на проект автоматизации.
Немаловажное значение имеют оценки сложности и объема информационного проекта. Формирование оценок проекта во многом связано с умением квалифицированно осуществлять декомпозицию системы и правильно выбирать атрибуты сложности проекта.
4.1. Оценка стоимости информационной системы
Оценку стоимости ИС осуществляют с помощью так называемых моделей (рис. 4.1). Модель считается хорошей, если с ее помощью можно оценить затраты на разработку ИС с точностью до 20% в 70% случаев.
96
Проектирование информационных систем
Число месяцев, прошедших после заключения контракта на разработку
Рис. 4.1. Пример изменения затрат на проект
Для оценки стоимости ИС используются следующие методы [23].
Алгоритмические модели. В этих моделях применяются алгоритмы вычисления оценок стоимости ИС в виде функций некоторого числа параметров, представляющих основные стоимостные факторы.
По сравнению с другими методами оценивания алгоритмические модели имеют ряд преимуществ. Они объективны и не подвержены влиянию таких факторов, как стремление к победе, желание лучше выглядеть в условиях конкуренции или отвращение к проекту. Эти модели эффективны и обеспечивают анализ чувствительности. Они накапливают и концентрируют в себе предыдущий опыт.
Недостатки алгоритмических моделей в том, что они построены на основе данных предыдущих проектов; остается открытым вопрос о правомерности переноса опыта на новые проекты, которые используют новые методы и системную архитектуру или применяются в новых областях. Эти методы также не учитывают конкретных условий, характеристик исполнителей и соответствия разработчиков
глава 4	о7
* |~f панирование и управление информационными проектами
планам работ. Кроме того, невозможно предусмотреть точность входных данных для расчетов оценок.
Экспертные оценки. Этот метод предполагает обсуждение с одним или группой экспертов факторов и оценок стоимости информационной системы, возможно с привлечением механизма экспертного согласия, например, метода «Дельфи».
Эти методы дополняют алгоритмические. Из достоинств экспертных оценок следует отметить возможность указать зависимость использования опыта прошлых разработок от новых методов, архитектуры ЭВМ, областей применения, предусмотренных в будущих проектах. Эксперт может учесть также индивидуальные возможности и взаимодействие разработчиков или другие уникальные стоимости проекта.
К недостаткам экспертной оценки следует отнести зависимость ее от компетенции и объективности эксперта, который может оказаться пристрастным, оптимистичным, пессимистичным или незнакомым с основными аспектами проекта. Непросто выбрать золотую середину между быстро полученной оценкой одного эксперта (своевременной, эффективной, но трудно проверяемой) и строгой, хорошо документированной оценкой в методе группового согласия (тщательно обоснованной и проанализированной, но требующей длительной проработки, а также трудноповторимой через некоторое время, особенно когда спецификации проекта отчасти изменены).
Метод аналогий. В этом методе используется оценка разработки одного или нескольких завершенных проектов. По аналогии с фактическими затратами на их разработку оценивается стоимость нового сходного проекта.
Оценивание по аналогии может быть проведено либо на уровне всего проекта, либо на уровне компонентов. Оценка на уровне проекта имеет то преимущество, что рассматриваются все стоимостные факторы (в том числе стоимость комп-лексирования компонентов), а преимущество оценивания
4. Зак. 1035
98
Проектирование информационных систем
на уровне компонентов заключается в более подробном рассмотрении сходства и различия нового и завершенных проектов.
Главным достоинством оценки по аналогии служит то, что она основывается на реальном опыте проектирования. Этот опыт может быть изучен для выделения специфических отличий в новом проекте и их вероятного влияния на стоимость. Главный недостаток заключается в неясности того, в какой мере предыдущие проекты являются образцами ограничений, методов, штатов исполнителей и выполняемых функций для нового проекта.
Оценивание методом «сверху-вниз». Полная оценка стоимости проекта выводится по глобальным характеристикам ИС. Эта оценка затем распределяется между различными компонентами.
Главное преимущество метода состоит в возможности концентрации внимания на общесистемном уровне. Оценка основывается на опыте полност ью завершенных проектов, поэтому фактически не будут упущены из вида оценки работ системного уровня, например, комплексирование, разработка документации для пользователя, управление конфигурацией и т.п.
Главные недостатки оценивания по этому методу:
►	невозможность выявления сложных технических проблем на нижних уровнях, что может привести к повышению стоимости;
►	невозможность учета всех необходимых для разработки компонентов ИС;
►	меньшая стабильность оценки по сравнению с многокомпонентной оценкой, в которой отдельные ошибки могут компенсировать друг друга.
Оценивание методом «снизу-вверх». Вначале оценивается работа по каждому компоненту информационной системы, а результаты суммируются для получения оценки всей работы.
глава 4	qq
АПланирование и управление информационными проектами у?
По сравнению с оцениванием методом «сверху-вниз» этот метод требует больших усилий, но это является и его преимуществом. В частности, оценивание каждой части работы ответственным за ее выполнение лицом полезно по двум соображениям:
►	каждая оценка будет основана на более точном понимании деталей требуемой работы;
►	каждая оценка будет подтверждена обязательствами исполнителя работы.
Более того, оценка «снизу-вверх» устойчива, так как ошибки в оценках компонентов могут компенсировать друг друга.
Самым эффективным способом учета общесистемного уровня при получении оценки «снизу-вверх» является представление задания на ИС в виде СПР, которое содержит не только компоненты, но и общесистемные работы. Неточность оценок работ общесистемного уровня может быть вызвана недооценкой необходимости знания размеров и природы элементов, которые требуется оценивать одновременно с общесистемными работами.
Краткое сравнение методов оценки стоимости. В таблице 4.1 сконцентрированы относительные достоинства и недостатки методов оценивания стоимости.
На основании таблицы можно сделать следующие выводы:
►	ни один из методов не может быть признан лучшим во всех отношениях;
►	достоинства одних методов восполняют недостатки других, и наоборот (в особенности это относится к алгоритмической модели и экспертной оценке, оценкам «сверху-вниз» и «снизу-вверх»).
Важно, таким образом, применять комбинацию методов, сравнивать результаты оценивания и находить последовательное приближение к достоверной оценке. Конкретная комбинация методов зависит от целей оценивания (например, оценка «сверху-вниз» полезна для грубого
4*
100
Проектирование информационных систем
.<з
Достоинства и недостатки оценивания стоимости программных систем
Недостатки	Субъективность исходных данных, включение в оценку уникальных факторов, ориентировка на прошлый опыт	3 0" S с С о г с: с tt о cd С ►С о с 5 и S И cd Г"	тенденциозность, некоторая несогласованность оценок	Отсутствие прошлого опыта	Менее детальное обоснование, малая устойчивость	Упущение общесистемного уровня, требуются большие затраты
Достоинства	Объективность, повторяемость, анализи-руемость формул, эффективность, удобство для анализа чувствительности, объективность проверки на основе прошлого опыта	S F О С S ►а ь-5 са cd & п CJ С с са с tr иС t а к * с г С CQ	группы, взаимодействий, уникальных факторов	Основано на прошлом опыте	Внимание обращено на общесистемный уровень, эффективность	Более детальное обоснование, большая устойчивость, поощрение индивидуальных обязательств
Метод	Алгоритмическая модель	w rd К С О е о о	оценка	Оценивание по аналогии	Оценивание «сверху-вниз»	Оценивание «снизу-вверх» 1
рлава 4
х Планирование и управление информационными проектами
прогностического оценивания, оценка «снизу-вверх»—для детального оценивания при планировании). Эффективной комбинацией методов является:
►	оценивание методом «сверху-вниз» с использованием мнения нескольких экспертов и оценки по аналогии, когда имеются данные по завершенным проектам;
►	оценивание методом «снизу-вверх» с использованием алгоритмических моделей, для которых оценки на уровне компонентов предоставляются разработчиками.
Модели оценки трудоемкости разработки информационных систем. Кроме условных методов, рассмотренных выше, существует четыре основные модели оценки трудоемкости разработки информационных систем, основанные на функциональных требованиях и/или продукте [52]: IFPUG FPA, FPA mkll, СОСОМО II, модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году.
Одной из наиболее известных моделей данного рода является конструктивная модель стоимости (Constructive Cost Model — СОСОМО), разработанная в конце 70-х годов Барри Боэмом. Она устанавливает соответствие между размером системы в тысячах условных строк кода и «классом» проекта, с одной стороны, и трудоемкостью разработки системы, с другой.
Базовый тип модели СОСОМО учитывает только класс проекта — естественный, полуинтегрированный, «встроенных систем». Естественные проекты — относительно маленькие и разрабатываются командами, знакомыми с прикладной областью. Полуинтегрированные проекты — системы среднего размера и сложности, разрабатываются группами разработчиков с различным опытом. Проекты «встроенных систем» выполняются при значительных аппаратных, программных и организационных ограничениях.
Промежуточный тип модели вводит 15 поправочных факторов, принадлежащих к одной из четырех категорий: атрибуты продукта, такие, как его сложность и требования к его
102
Проектирование информационных систем
надежности; атрибуты системы, такие, как ограничения на оперативную память и время выполнения; атрибуты команды, такие, как опыт в прикладной области; и атрибуты проекта, такие, как используемые средства разработки. Продвинутый тип модели дополнительно вводит разбиение по стадиям жизненного цикла.
Существенным недостатком данной модели является использование метрики размера программного комплекса. В 1979 году Аланом Альбрехтом был опубликован метод функциональных точек с целью разработки механизм^ предсказания усилий, сопряженных с разработкой программных систем (IFPUG), позволяющий отойти от данной метрики размера ПО.
Чарльз Саймон разработал другой, аналогичный, но несколько более логичный и использующий более современную терминологию, метод функциональных точек Mark II. В отличие от FPA IFPUG, МК II FPA использует единое понятие транзакции, имеющей вход, обработку и выход. Другими аналогичными методами являются Feature Points, разработанный Кэйперсом Джонсом, и 3D Points, разработанный в компании Боинг.
Со временем модель СОСОМО оказалась устаревшей, поэтому на ее основе была разработана модель СОСОМО II, опубликованная в 1999 году. Она усовершенствует оригинальную модель в следующих основных направлениях: ► использование входных данных, доступных на ранних этапах жизненного цикла системы для оценки ее сложности (в частности, использование функциональных точек); ► новые — циклические и обобщенные — модели процессов разработки;
►	подходы, основанные на повторном использовании, включая интеграцию коммерческих продуктов, реинжиниринг, генерацию приложений;
►	объектно-ориентированные подходы, поддерживаемые распределенным ПО промежуточного слоя;
►	влияние зрелости процессов разработки.
глава 4	1Q2
* J~f панирование и управление информационными проектами
В течение восьмидесятых годов в СССР также на основе СОСОМО были разработаны собственные модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году. В них по-своему была решена задача оценки функционального размера программной системы и получения количества тысяч условных машинных команд.
Главными факторами при выборе модели должны являться:
►	тип модели и доступность репозиториев;
►	время применения;
►	учет факторов размера системы;
►	непрерывная зависимость от сложности проекта;
►	учет функциональной сложности;
►	учет нефункциональных требований к системе;
►	поддержка различных жизненных циклов и разбиения по стадиям жизненного цикла и др.
Оценка проекта автоматизации требует согласованной оценки различных видов затрат, и в каждом случае требуется использование специальных методов. Должен быть согласован уровень точности оценок затрат разного вида, рисков, а также и параметры, используемые в расчетах, например, сроки внедрения и эксплуатации системы. Качество полученной оценки зависит от полноты учета существенных затрат проекта, учета рисков, а также от качества оценки каждой составляющей.
4.2. Проектное управление:
модели и методы принятия решений
Процесс проектирования ИС по существу является проектом. Поэтому целесообразно для планирования и оперативного управления этим процессом использовать методы управления проектами. Все методы управления проектами базируются на таких базовых принципах, как [81]:
104
Проектирование информационных систем
*	согласование целей проекта со всеми заинтересованными сторонами;
►	тщательный подбор команды проекта. Управляющий проектом должен иметь все полномочия для работ по проекту, а члены команды должны знать, перед кем они отчитываются;
►	распределение ответственности между руководителями отдельных направлений;
►	планирование основных совещаний и их целей;
►	регулярная рассыпка достоверной информации об ответственности участников проекта, о результатах совещаний, действиях и изменениях;
►	четкий контроль хода выполнения проекта;
►	регулярная проверка управляющим проектом выполнения сметы и выдача предупреждений в случае опасности перерасхода средств;
►	отклонение нецелесообразных изменений проекта при сохранении необходимой гибкости;
►	открытое обсуждение проблем участниками проекта;
►	безотлагательное решение проблем сегодня (так как завтра могут возникнуть новые проблемы).
Основными процессами управления проектами в соответствии с требованиями международной ассоциации PMI (Project manager institute) являются:
►	инициация проекта;
►	планирование проекта;
►	исполнение проекта;
►	управление изменениями;
►	завершение проекта.
При инициации проекта выполняются следующие работы: определяются потребности проекта, дается анализ целесообразности проекта, составляется описание результатов проекта (продуктов или услуг), определяются обязанности и ответственности управления, составляется первоначальное описание проекта, назначается менеджер проекта.
В процессе планирования проекта осуществляются: планирование целей, декомпозиция целей, определение опера
"лава 4
f уланирование и управление информационными проектами
105
ций проекта, определение взаимосвязей операций, планирование ресурсов, оценка длительности операций, стоимостные оценки проекта, составление расписания работ, планирование взаимодействия, планирование качества, планирование организации, планирование управления рисками, планирование контрактов, разработка плана проекта.
В процессе исполнения проекта обеспечиваются: исполнение плана проекта,'подтверждение целей, подтверждение качества, развитие команды проекта, распределение информации, выбор поставщиков, управление контрактами.
В процессе управления изменениями обеспечиваются: общий контроль изменений, управление изменениями целей, сроков, стоимости, управление качеством, отчетность о выполнении, управление рисками.
На этапе завершения проекта осуществляются административное завершение проекта, закрытие контрактов.
Остановимся более подробно на процессе планирования проекта, который является основой для управления процессом проектирования ИС.
4.2.1.	Объект проектного управления
Термин проект, как известно, происходит от латинского слова, projectus, что в буквальном переводе означает брошенный вперед. Таким образом, сразу становится ясно, что объект управления, который можно представить в виде проекта, отличает возможность его перспективного развертывания, т.е. возможность предусмотреть его состояния в будущем. Хотя различные официальные источники трактуют понятие проекта по-разному, во всех определениях четко просматриваются особенности проекта как объекта управления, обусловленные комплексностью задач и работ, четкой ориентацией этого комплекса на достижение определенных целей и ограничениями по времени, бюджету, материальным и трудовым ресурсам.
Однако любая деятельность, в том числе и та, которую никто не собирается называть проектом, выполняется в
106
Проектирование информационных систем
течение определенного периода времени и связана с затратами определенных финансовых, материальных и трудовых ресурсов. Кроме того, любая разумная деятельность, как правило, целесообразна, т.е. направлена на достижение определенного результата. И тем не менее в одних случаях к управлению деятельностью подходят как к управлению проектом, а в других случаях — нет.
Деятельность как объект управления рассматривается в виде проекта в следующих случаях [6]:
►	объективно имеет комплексный характер, для ее эффективного управления важен анализ внутренней структуры всего комплекса работ (операций, процедур и т.п.);
►	переходы от одной работы к другой определяют основное содержание всей деятельности;
►	достижение целей деятельности связано с последовательно-параллельным выполнением всех элементов этой деятельности;
►	ограничения по времени, финансовым, материальным и трудовым ресурсам имеют особое значение в процессе выполнения комплекса работ;
►	продолжительность и стоимость деятельности явно зависит от организации всего комплекса работ.
Поэтому объектом проектного управления принято считать особым образом организованный комплекс работ, направленный на решение определенной задачи или достижение определенной цели, выполнение которого ограничено во времени, а также связано с потреблением конкретных финансовых, материальных и трудовых ресурсов. При этом под «работой» понимается элементарная, неделимая часть данного комплекса действий.
Элементарность работы — понятие условное и относительное. То, что нецелесообразно делить в одной системе действий, полезно разукрупнять в другой. Например, если за элемент комплекса работ по сборке автомобиля принимается технологическая операция, то одной из «работ» может считаться установка сборщиком фары. Эта «работа» в
рлава 4
* Цианирование и управление информационными проектами
данном случае неделима, так как остаются неизменными ее (факторы — исполнитель, предмет и объект действия. Но как только мы начинаем рассматривать исполнение этой работы как отдельную задачу, она сама превращается в комплекс.
Однако если задача возникает регулярно, а ее решение превращается в рутинную деятельность, доведенную до автоматизма, то нет никакого особого смысла каждый раз, приступая к ее решению, рассматривать и моделировать ее сложную структуру. Результат известен заранее и время, потраченное на планирование, будет просто потеряно. Поэтому объектом проектного управления является, как правило, комплекс взаимосвязанных работ, направленных на решение некоторой оригинальной задачи. В современной деловой среде, при стремительном развитии техники, технологии и организации производства, при смене видов и разновидностей товаров и услуг на рынках, появление перед менеджером оригинальных задач стало фактически обычной ситуацией. Если в конце 50-х годов, на заре зарождения проектного управления, в качестве объектов такого управления выступали исключительно научно-исследовательские и опытно-конструкторские программы, то в наши дни уже мало кого можно удивить техническими, организационными, экономическими и даже социальными проектами. Уже в самом определении типа проекта заложена характеристика области его приложения.
4.2.2.	Основы проектного управления
Сетевое планирование и управление — это комплекс графических и расчетных методов, организационных мероприятий, обеспечивающих моделирование, анализ и динамическую перестройку плана выполнения сложных проектов и разработок [6]. Характерной особенностью таких проектов является то, что они состоят из ряда отдельных, элементарных работ. Они обусловливают друг друга — выполнение некоторых работ не может быть начато раньше, чем завершены некоторые другие.
108
Проектирование информационных систем
Существует множество методов планирования и управления проектами, наиболее известные — метод критического пути (critical path method, сокращенно СРМ), а также система планирования и руководства программами разработок (program evaluation and review technique, сокращенно PERT) [54]. В этих сетевых методах проект рассматривается как совокупность некоторых взаимосвязанных процессов (видов деятельности, работ), каждый из которых требует определенных временных и других ресурсов, и проводится анализ проекта для составления временных графиков распределения работ проекта.
Основные этапы выполнения этих методов обобщенно можно представить следующим образом. На первом этапе определяются отдельные процессы, составляющие проект, их отношения предшествования (т.е. какой процесс должен предшествовать следующему) и их длительность. Далее проект представляется в виде сети, показывающей отношения предшествования среди процессов, составляющих проект. На третьем этапе на основе построенной сети выполняются вычисления, в результате которых составляется временной график реализации проекта.
Методы СРМ и PERT, которые разрабатывались независимо друг от друга, отличаются тем, что в методе критического пути длительность каждого этапа проекта является детерминированной, тогда как в системе планирования PERT — стохастической.
Сетевое планирование и управление включают три основных этапа [25]:
►	структурное планирование;
►	календарное планирование;
►	оперативное управление.
Структурное планирование начинается с разбиения проекта на четко определенные операции, для которых определяется продолжительность. Затем строится сетевой график, который представляет взаимосвязи работ проекта. Это по
^Цианирование и управление информационными проектами
зволяет детально анализировать все работы и вносить улучшения в структуру проекта еще до начала его реализации.
Календарное планирование предусматривает построение календарного графика, определяющего моменты начала и окончания каждой работы и другие временные характеристики сетевого графика. Это позволяет, в частности, выявлять критические операции, которым необходимо уделять особое внимание, чтобы закончить проект в директивный срок. Во время календарного планирования определяются временные характеристики всех работ в целях проведения в дальнейшем оптимизации сетевой модели, которая позволит улучшить эффективность использования какого-либо ресурса.
В ходе оперативного управления применяются сетевой и календарный графики для составления периодических отчетов о ходе выполнения проекта. При этом сетевая модель может подвергаться оперативной корректировке, вследствие чего будет разрабатываться новый календарный план остальной части проекта.
Основные понятия и определения. Основными понятиями сетевых моделей являются понятия события и работы.
Работа — это некоторый процесс, приводящий к достижению определенного результата, требующий затрат каких-либо ресурсов и имеющий протяженность во времени.
По физической ее природе, работу можно рассматривать: ► как действие -— разработка чертежа, изготовление детали, заливка фундамента бетоном, изучение конъюнктуры рынка;
►	процесс — старение отливок, выдерживание вина, травление плат;
►	ожидание — ожидание поставки комплектующих, про-леживанис детали в очереди к станку.
По количеству затрачиваемого времени работа может быть:
►	действительной, т.е. требующей затрат времени;
►	фиктивной, т.е. формально не требующей затрат времени и представляющей связь между какими-либо работами,
110
Проектирование информационных систем
например: передача измененных чертежей от конструкторов к технологам; сдача отчета о технико-экономических показателях работы цеха вышестоящему подразделению.
Событие—это момент времени, когда завершаются одни работы и начинаются другие. Например, фундамент залит бетоном, старение отливок завершено, комплектующие поставлены, отчеты сданы и т.д. Событие представляет собой результат проведенных работ и в отличие от работ нс i имеет протяженности во времени.
На этапе структурного планирования взаимосвязь работ и событий, необходимых для достижения конечной цели ! проекта, изображается с помощью сетевого графика (сете- | вой модели). На сетевом графике работы изображаются стрелками, которые соединяют вершины, изображающие события. Начало и окончание любой работы описываются парой событий, которые называются начальным и конечным событиями. Поэтому для идентификации конкретной работы используют код работы (z, j), состоящий из номеров начального (z-го) и конечного (/-го) событий (рис. 4.2).
Работа ((j)
Начальное событие
Конечное событие
Рис. 4.2. Кодирование работы
Любое событие может считаться наступившим только тогда, когда закончатся все входящие в него работы. Поэтому работы, выходящие из некоторого события, не могут начаться, пока не будут завершены все работы, входящие в это событие.
Событие, не имеющее предшествующих ему событий, т.е. событие, с которого начинается проект, называют исходным.
рлава 4	ill
х |~f лакирование и управление информационными проектами
Событие, которое нс имеет последующих событий и отражает конечную цель проекта, называется завершающим.
Важное значение для анализа сетевых моделей имеет понятие пути. Путь — это любая последовательность работ в сетевом графике (в частном случае это одна работа), в которой конечное событие одной работы совпадает с начальным событием следующей за ней работы. Различают следующие виды путей.
Полный путь — это путь от исходного до завершающего события. Критический путь — максимальный по продолжительности полный путь. Работы, лежащие на критическом пути, называют критическими. Подкритический путь — полный путь, ближайший по длительности к критическому пути.
Построение сети является лишь первым шагом на пути к построению календарного плана. Второй шаг — расчет сетевой модели, который выполняют прямо на сетевом графике, пользуясь простыми правилами.
Временные параметры событий. К временным параметрам событий относятся:
►	Тр(1) — ранний срок наступления события I. Это время, которое необходимо для выполнения всех работ, предшествующих данному событию I. Оно равно наибольшей из продолжительности путей, предшествующих данному событию;
►	Г (i) — поздний срок наступления события /. Это такое время наступления события /, превышение которого вызовет аналогичную задержку наступления завершающего события сети. Поздний срок наступления любого события i равен разности между продолжительностью критического пути и наибольшей из продолжительностей путей, следующих за событием I;
►	R(i) — резерв времени наступления события i. Это такой промежуток времени, на который может быть отсрочено наступление события i без нарушения сроков завершения проекта в целом. Начальные и конечные события критических работ имеют нулевые резервы событий.
112
Проектирование информационных систем
Рассчитанные численные значения временных параметров записываются прямо в вершины сетевого графика (рис. 4.3).
Рис. 4.3. Отображение временных параметров событий в вершинах сетевого графика
Расчет ранних сроков свершения событий Тр(1) ведется от исходного (И) события к завершающему (3).
Примечание. Поскольку длительность работы может быть как нормальной Ти, так и ускоренной Т (см. п. 4.2.4), то для общности изложения будем в дальнейшем обозначать текущую длительность работы буквой t с соответствующим кодом работы, например	и т.д.
►	для исходного события И Тр(О = 0;
►	для всех остальных событий i Tp(i) = шах[7^(&) + t(k, z)], где максимум берется по всем работам (k, I), входящим в событие I;
►	поздние сроки свершения событий Т (i) рассчитываются от завершающего к исходному событию;
►	для завершающего события 3 Tn(i) = T (i);
►	для всех остальных событий Тп (i) - min [Ги (у) - Z(z, у)], где минимум берется по всем работам (z, j), выходящим из события z;
►	R(i) = Tn(i) - Tp(i).
Временные параметры работ и путей. К наиболее важным временным параметрам работ относятся:
►	Tpn(i,j)— ранний срок начала работы;
глава 4	л.	114
панирование и управление информационными проектами
>	TnH(i, j) — поздний срок начала работы;
►	Tpo(i,j) — ранний срок окончания работы;
►	Tno(i,j) — поздний срок окончания работы.
Для критических работ TpH(i,j) = Tmi{i,j) и T^iJ) - TJiJY, ► Rn(i, j) — полный резерв работы — показывает максимальное время, на которое может быть увеличена продолжительность работы (z, у) или отсрочено ее начало, чтобы продолжительность проходящего через нес максимального пути не превысила продолжительности критического пути. Важнейшее свойство полного резерва работы (/, у) заключается в том, что его частичное или полное использование уменьшает полный резерв у работ, лежащих с работой (z’,y) на одном пути [25]. Таким образом, полный резерв принадлежит не одной данной работе (z, у), а всем работам, лежащим на путях, проходящих через эту работу;
►	Rc(i,j) — свободный резерв работы — показывает максимальное время, на которое можно увеличить продолжительность работы О’,у) или отсрочить се начало, нс меняя ранних сроков начала последующих работ. Использование свободного резерва одной из работ не меняет величины свободных резервов остальных работ сети.
Временные параметры работ сети определяются на основе ранних и поздних сроков событий:
Tpll(i,J) = тра\
троал = ТР^ + или V’7) = rPn^j) +
Tno(i,j)- Тп0У,
= T„(J) - ИЛИ Tnn(i,j) = Tno(i,j) - t(jjy
Временные параметры работ вносятся в таблицу (см. табл. 4.2) При этом коды работ записывают в определенном порядке: сначала записываются все работы, выходящие из исходного, т.е. первого, события, затем — выходящие из второго события, потом — из третьего, и т.д.
114
Проектирование информационных систем
Резервами времени, кроме работ и событий, обладают полные пути сетевой модели. Разность между продолжительностью критического пути T(L^ и продолжительностью любого другого полного пути T(Ln) называется полным резервом времени пути Ln, т.е. = T(LKp) - T(LH). Этот резерв показывает, на сколько в сумме может быть увеличена продолжительность всех работ данного пути L, чтобы при этом не изменился общий срок окончания всех работ.
Пример построения и расчета сетевой модели
Исходные данные для расчета сетевой модели представлены в таблице 4.2 и включают название и продолжительность каждой работы, а также описание упорядочения работ.
На рисунке 4.4 представлена сетевая модель, соответству--ющая данному упорядочению работ [49]. Каждому событию присвоен номер, что позволяет в дальнейшем использовать нс названия работ, а их коды (табл. 4.3). Численные значения временных параметров событий сети вписаны в соответствующие секторы вершин сетевого графика, а временные параметры работ сети представлены в таблице 4.4.
Таблица 4.2
Исходные данные для расчета сетевой модели
Название работы	Продолжительность работы
А	10
В	8
С	4
D	12
Е	7
F	1 1
G	5
Н	8
1	3
J	9
К	10
^Планирование и управление информационными проектами
Таблица 4.3
Описание сетевой модели с помощью кодирования работ
Номера событий		Код работы	Продолжительность работы
начального	конечного		
1	2	(1, 2)	4
1	3	(1,3)	3
1	4	(1,4)	5
2	5	(2, 5)	7
2	6	(2, 6)	10
3	6	(3,6)	8
4	6	(4, 6)	12
4	7	(4, 7)	9
5	8	(5, 8)	8
6	8	(6, 8)	10
7	8	(7, 8)	11	
Рис. 4.4. Сетевая модель
116
Проектирование информационных систем
Таблица 4.4
Временные параметры работ
О		Tpa&j)	Tpo(i,j).				ЛД6Л
1,2	4	0	4	3	7	3	0
1,3	3	0	3	6	9	6	0
1,4	5	0	5	0	5	0	0
2,5	7	4	И	12	19	8	0
2,6	10	4	14	7	17	3	3
3,6	8	3	11	9	17	6	6
4,6	12	5	17	5	17	0	0
4,7	9	5	14	7	16	2	0
5,8	8	11	19	19	27	8	8
6,8	10	17	27	17	27	0	0
7,8	И	14	25	16	27	2	2
4.2.	J. Методика оптимизации загрузки сетевых моделей
При оптимизации использования ресурса рабочей силы чаще всего сетевые работы стремятся организовать при следующих действиях [55]:
►	количество одновременно занятых исполнителей должно быть минимальным;
►	потребность в людских ресурсах на протяжении срока выполнения проекта должна быть распределена равномерно.
Суть оптимизации загрузки сетевых моделей по критерию «минимум исполнителей» заключается в следующем [49]: необходимо таким образом организовать выполнение сетевых работ, чтобы количество одновременно работающих исполнителей было минимальным. Для проведения подобных видов оптимизации необходимо построить и проанализировать график привязки и график загрузки.
График привязки отображает взаимосвязь выполняемых работ во времени и строится на основе данных либо о про-
рлава 4
х Планирование и управление информационными проектами
должитсльности работ (Г ), либо о ранних сроках начала и окончания работ [55]. При первом способе построения необходимо помнить, что работа (/, j) может начать выполняться только после того, как будут выполнены все предшествующие ей работы По вертикальной оси графика привязки откладываются коды работ, по горизонтальной оси —- длительность работ (раннее начало и раннее окончание работ).
На графике загрузки по горизонтальной оси откладывается время, например, в днях, по вертикальной — количество человек, занятых работой в каждый конкретный день. Для построения графика за1рузки необходимо:
►	на графике привязки над каждой работой написать количество ее исполнителей;
►	подсчитать количество работающих в каждый день исполнителей и отложить на графике загрузки.
Для удобства построения и анализа графики загрузки и привязки следует располагать один над другим.
Описанные виды оптимизации загрузки выполняются за счет сдвига во времени некритических работ, т.е. работ, имеющих полный и(или) свободный резервы времени. Полный и свободный резервы любой работы можно определить без специальных расчетов, анализируя только график привязки. Сдвиг работы означает, что она будет выполняться уже в другие дни (т.е. изменится время ее начала и окончания), что в свою очередь приведет к изменению количества исполнителей, работающих одновременно (т.е. уровня ежедневной загрузки сети).
Пример проведения оптимизации сетевой модели по критерию «минимум исполнителей»
Графики привязки и загрузки для исходных данных из таблицы 4.5 представлены на рисунке 4.5 [49].
118
Проектирование информационных систем
Таблица 4.5
Исходные данные для оптимизации загрузки
Код работ	П родолжительность работ	Количество исполнителен
0,2)	4	6
(1, 3)	3	1
(1,4)	5	5
(2, 5)	7	3
(2, 6)	10	1
(3, 6)	8	8
(4, 6)	12	4
(4, 7)	9	2
(5, 8)	8	6
(6,8)	10	1
' (7,8)	1 1	3
Допустим, что организация, выполняющая проект, имеет в распоряжении только N = 15 исполнителей. Но в соответствии с графиком загрузки (рис. 4.5), в течение интервала времени с 3 по 11 день для выполнения проекта требуется работа одновременно 19, 17 и затем 18 человек. Таким образом, возникает необходимость снижения максимального количества одновременно занятых исполнителей с 19 до 15 человек. Для лучшего понимания последующего описания процесса оптимизации загрузки либо используйте компьютерную программу, либо вручную вносите изменения в графики привязки и загрузки работ (рис. 4.6).
Проанализируем возможность уменьшения загрузки (19 человек) в течение 4-го дня. Используя Rc(3, 6) = 6, сдвинем работу (3, 6) на 1 день, что снизит загрузку 4-го дня до 11 человек, но при этом в 12-й день появится пик — 21 исполнитель. Для его устранения достаточно сдвинуть работу (5, 8) на 1 день, используя Rc(5, 8) = 8.
Проанализируем возможность уменьшения загрузки (18 человек) с 6-го по 11 -й день, т.е. в течение интервала врс-
Глава 4	что
* Планирование и управление информационными проектами
Рис. 4.5. Графики загрузки (а) и привязки (б) до оптимизации
мени в 6 дней. Тут работа (2, 5) является единственной, которую можно сдвинуть таким образом, чтобы она нс выполнялась в указанные 6 дней с 6-го по 11-й день. Для этого, используя /?„(2, 5) = 8, сдвинем работу (2, 5) на 8 дней, после чего она будет начинаться уже не в 4-й, а в 12-й день, к чему мы и стремились. Но поскольку Rc(2, 5) = 0 и для сдвига работы (2, 5) был использован полный резерв, то это влечет за собой обязательный сдвиг на 7 дней работы (5, 8), следующей за работой (2, 5).
120
Проектирование информационных систем
В результате произведенных сдвигов максимальная загрузка сетевой модели уменьшилась с 19 до 15 человек, что и являлось целью проводимой оптимизации. Окончательные изменения в графиках привязки и загрузки показаны на рисунке 4.6 пунктирной линией.
Рис. 4.6. Графики загрузки (а) и привязки (б) после оптимизации
Проведенная оптимизация продемонстрировала следующее различие использования свободных и полных резервов работ. Так, сдвиг работы на время в пределах се свободного резерва не меняет моменты начала последующих
Глава. 4	-i
ж]~[ланирование и управление информационными проектами
за ней работ. В то же время сдвиг работы на время, которое находится в пределах ее полного резерва, но превышает ее свободный резерв, влечет сдвиг последующих за ней работ.
4.2.4.	Методика оптимизации сетевых моделей по критерию «время — затраты»
Целью оптимизации по критерию «время — затраты» является сокращение времени выполнения проекта в целом. Эта оптимизация имеет смысл только в том случае, когда время выполнения работ может быть уменьшено за счет использования дополнительных ресурсов, что приводит к повышению затрат на выполнение работ (рис. 4.7) [49]. Для оценки величины дополнительных затрат, связанных с ускорением выполнения той или иной работы, используются либо нормативы, либо данные о выполнении аналогичных работ в прошлом. Под параметрами работ С„(г, у) и Cn(i, у) понимаются так называемые прямые затраты, непосредственно связанные с выполнением конкретной работы. Таким образом, косвенные затраты типа административно-управленческих в процессе сокращения длительности проекта во внимание не принимаются, однако их влияние учитывается при выборе окончательного календарного плана проекта.
Важными параметрами работы (/, у) при проведении данного вида оптимизации являются [55]: ► коэффициент нарастания затрат:
который показывает затраты денежных средств, необходимые для сокращения длительности работы (z, у) на один день;
► запас времени для сокращения длительности работы в текущий момент времени
Zm{i,j) =	Ту(^’
122
Проектирование информационных систем
где tm(i, j) — длительность работы (/, у) на текущий момент времени, максимально возможное значение запаса времени работы Zmax = TH(i, j) - Ty(i,j).
Эта ситуация имеет место, когда длительность работы (;,у) еще ни разу не сокращали, т.е. = Т
Рис. 4.7. Зависимость прямых затрат на работу ат времени ее выполнения
Общая схема проведения оптимизации
«время — затраты» [49]
1.	Исходя из нормальных длительностей работ TJi, j) определяются критические^ и п од критические Ln пути сетевой модели и их длительности Т и Тп.
2.	Определяет ся сумма прямых затрат на выполнение всего проекта С„р при нормальной продолжительности работ.
3.	Рассматривается возможность сокращения продолжительности проекта, для чего анализируются параметры критических работ проекта.
3.1.	Для сокращения выбирается критическая работа с минимальным коэффициентом нарастания затрат Л(/, у), имеющая ненулевой запас времени сокращения Z (i, j).
глава 4
* фланирование и управление информационными проектами
3.2.	Время At(i, j), на которое необходимо сжать длительность работы определяется как
Ar(z, J) = min [Zm(i, j),LT],
где \Т~Ткр- Тп— разность между длительностью критического и подкритического путей в сетевой модели. Необходимость учета параметра Д Т вызвана нецелесообразностью сокращения критического пути более чем на Д Т единиц времени. В этом случае критический путь перестанет быть таковым, а подкритический путь, наоборот, станет критическим, т.е. длительность проекта в целом принципиально не может быть сокращена больше чем на Д Т.
4.	В результате сжатия критической работы временные параметры сетевой модели изменяются, что может привести к появлению других критических и подкритических путей. Вследствие удорожания ускоренной работы общая стоимость проекта увеличивается на величину Д С = k(i, j) Д /(/, у).
5.	Для измененной сетевой модели определяются новые критические и подкритические пути и их длительности, после чего необходимо продолжить оптимизацию с шага 3. При наличии ограничения в денежных средствах, их исчерпание является причиной окончания оптимизации. Если не учитывать подобное ограничение, то оптимизацию можно продолжать до тех пор, пока у работ, которые могли бы быть выбраны для сокращения, не будет исчерпан запас времени сокращения.
Примечание. Рассмотренная общая схема оптимизации предполагает наличие одного критического пути в сетевой модели. В случае существования нескольких критических путей необходимо либо сокращать общую для них всех работу, либо одновременно сокращать несколько различных работ, принадлежащих различным критическим путям. Возможна комбинация этих двух вариантов. В каждом случае критерием выбора работы или работ для сокращения должен служить минимум затрат на их общее сокращение.
124
Проектирование информационных систем
Пример проведения оптимизации сетевой модели по критерию «время — затраты»
Проведем максимально возможное уменьшение сроков выполнения проекта при минимально возможных дополнительных затратах для следующих исходных данных (см. табл. 4.6, рис. 4.8) [49].
Таблица 4.6
Исходные данные для оптимизации «время — затраты»
(АУ)	Нормальный режим			Ускоренный режим	
					
(1,2)	5	5		3	19
(1,4)	6	6		4	12
(2, 3)	3	8		1	15
(2, 4)	7	10		3	18
(3, 5)	6	6		1	9
(4, 5)	4	9		1	12
Ск = 1,50 руб./день			Со = 73,00 руб.		
Исходя из нормальных длительностей работ, получаем следующие характеристики сетевой модели:
►	общие затраты на проект:
СпР= X Q О’, У) = 44,00 руб.;
V(i.y)
►	длительность проекта Т*р = 16 дней;
Глава 4	-| ос
* Планирование и управление информационными проектами
►	критический путь 1?кр = 1, 2, 4, 5, или [9кр = (1, 2); (2, 4);
(4, 5);
►	подкритический путь 1?кр = 1, 2, 3, 5, или lPKp = (1,2); (2, 3);
(3, 5), Г„° = 14дней.
Кроме того, вычислим коэффициенты нарастания затрат и максимальные запасы времени сокращения работ сетевой модели (табл. 4.7). •
Таблица 4.7
Коэффициенты нарастания затрат работ сети
(i,j)	^.пахО’Л ДНИ	А(», Л руб/день
(1,2)	2	7,00
(1,4)	2	3,00
(2,3)	2	3,50
(2,4)	4	2,00
(3, 5)	5	0,60
(4, 5)	3	1,00
1 шаг. Для сокращения выбираем критическую работу (4,5) с минимальным коэффициентом &(4,5) = 1,00 руб./день. Текущий запас сокращения времени работы (4,5) на данном шаге Z° (4,5) = Zniax(4, 5) = 3 дня. Разность между продолжительностью критического и подкритического путей АТ0 _^о	= 2 дня Поэтому согласно п.3.2 описанной
выше общей схемы оптимизации сокращаем работу (4, 5) на A/1 = min[3,2] = 2 дня. Новая текущая длительность работы t}„(4,5) = 4-2 = 2 дня, а запас ее дальнейшего сокращения сокращается до z'„(4,5) = 1 дня. Измененный сетевой график представлен на рисунке 4.9.
После ускорения работы (4, 5) возникли следующие изменения:
► затраты на работу (4, 5) возросли на 1,00 руб./день • 2 дня = = 2,00 руб., и общие затраты на проект составили
С„р = 44,00 + 2,00 = 46,00 руб.;
Рис. 4.9. Сетевая модель после первого шага оптимизации
►	длительность проекта Т'р = 14 дней;
►	критические пути 1}кр = 1,2,3,5 и = 1,2,4,5;
►	подкритический путь z{; = 1, 4,5 , TjJ = 8 дней.
IIшаг. Одновременное сокращение двух критических путей можно провести, либо ускорив работу (1, 2), принадлежащую обоим лутям, либо одновременно ускорив различные работы из каждого пути. Наиболее дешевым вариантом является ускорение работ (3, 5) и (4, 5) — 1,60 руб./день за обе работы, тогда как ускорение работы (1,2) обошлось бы в 7 руб./день. Поскольку ДГ1 = Т^р - 7j* - 6, то сокращаем работы (3, 5) и (4, 5) на Дг = min[5,1,6] = 1 день. Запасы дальнейшего сокращения времени работ сокращаются до Z~(3,5) = 4 и Z2(4,5) = 0 дней. Измененный сетевой график представлен на рисунке 4.10.
Рис. 4.10. Сетевая модель после второго шага оптимизации
г
Глава 4	177
* Планирование и управление информационными проектами
После ускорения работ (3, 5) и (4, 5) возникли следующие изменения:
►	общие затраты на проект составили
CJ, =46,00 + 0,60-1 + 1,00-1 =47,60 руб.;
►	длительность проекта Т^р = 13 дней;
►	два критических пути I?Kp = 1, 2,3,5 и 12кр = 1, 2, 4,5;
►	подкритический путь = 1,4,5 , Т2 = 7 дней.
III шаг. Поскольку на данном шаге работа (4, 5) исчерпала свой запас ускорения, то наиболее дешевым вариантом сокращения обоих критических путей является ускорение работ (3, 5) и (2, 4) — 2,60 руб./день за обе работы. Сокращаем работы (3, 5) и (2,4) на Дг3 = min [4, 4,6] = 4 дня. Запасы дальнейшего сокращения времени работ (3, 5) и (2, 4) обнуляются. Измененный сетевой график представлен на рисунке 4.11.
Рис. 4.11. Сетевая модель после третьего шага оптимизации
После ускорения работ (3, 5) и (2, 4) возникли следующие изменения:
►	общие затраты на проект составили
С3р = 47,60 + 0,60-4 + 2,00-4 = 58,00 руб.;
►	длительность проекта Тк3 = 9 дней;
►	два критических пути £3р = 1,2,3,5 и £3р = 1, 2,4,5;
►	подкритический путь £3 = 1, 4,5 , Т„ = 7 дней.
128
Проектирование информационных систем
IV шаг. Поскольку кроме работы (1,2) все остальные работы критического пути 1?кр = 1, 2,4,5 исчерпали свой запас времени ускорения, то единственно возможным вариантом сокращения обоих критических путей является ускорение работы (1, 2). Сокращаем работу (1,2) на Az4 = min[2, 2] = 2 дня. Запас дальнейшего сокращения времени работы (1, 2) обнуляется. Измененный сетевой график представлен на рисунке 4.12.
Рис. 4.12. Сетевая модель после четвертого шага оптимизации
После ускорения работы(1,2) возникли следующие изменения:
►	общие затраты на проект составили 4=58,00 + 7,00-2 = 72,00 руб.;
►	длительность проекта Т^р = 7 дней;
►	три критических пути 4 = 1, 2,3, 5,
4=1, 2,4,5 и 4=1,4,5;
►	подкритические пути отсутствуют.
Дальнейшая оптимизация стала невозможной, поскольку все работы критического пути 4 — t 2,4,5 исчерпали свой запас времени ускорения, а значит, проект не может быть выполнен меньше чем за Т^р = 7 дней.
Таким образом, при отсутствии ограничений на затраты минимально возможная длительность проекта составляет 7 дней. Сокращение длительности проекта с 16 до 7 дней потребовало 28,00 руб. прямых затрат. В отличие от пря
глава 4	129
* Планирование и управление информационными проектами
мых затрат при уменьшении продолжительности проекта косвенные затраты (Ск = 150 руб./день) убывают, что показано на графике (рис. 4.13). Минимум общих затрат (точка А) соответствует продолжительности проекта в 14 дней (см. рис. 4.13). Если же учитывать ограничение по средствам, выделенным на выполнение проекта, Со = 73,00 руб., то оптимальным является выполнение проекта за 9 дней (точка В).
5. Зак. 1035
130
Проектирование информационных систем
4.3. Планирование и управление проектами средствами MS Project
Любая целенаправленная деятельность связана с планированием. План есть технология достижения цели. Деятельность по достижению цели должна быть управляемой. Планирование является основой управления. Управление позволяет осуществить план наиболее эффективным образом, обеспечивая реализацию плана с наименьшими отклонениями от него. Деятельность любого предприятия осуществляется в двух режимах: регулярного функционирования и работ проектного характера.
В самое последнее время расширяется новый раздел знаний —проектное управление (Project Management). Значительное развитие получили различные средства программной •поддержки планирования и управления проектами, одним из наиболее распространенных является MS Project [68].
Все достижения в этой сфере связаны с поддержкой процедуры планирования и практически никак не затронули содержательной стороны этой качественной работы. Очевидно пересечение предметов двух информационных технологий: теории и практики планирования, функционального моделирования систем. Как в процессе планирования, так и в процессе функционального моделирования разрабатываются некоторые массивы функций, составляющих в комплексе технологию достижения той или иной цели. Как в том, так и в другом случае формируется некоторый комплекс перерабатываемых и неперерабатываемых ресурсов, предназначенных для поддержания осуществления этих функций, а также формируется управление процессом достижения цели. В одном случае документ называется планом, а в другом — функциональной моделью.
Одной из наиболее распространенных до настоящего времени форм является матричный план, основанный на консервативной форме матрицы, имеющей практический неизмененный состав столбцов. При таком представлении плана в явном и неформализованном виде стараются ско-
’лава 4
уТланирование и управление информационными проектами
ординировать проведение работ по срокам, в еще менее убедительном виде — по ресурсам.
Технология функционального моделирования систем позволяет существенно повысить качество рассматриваемого списка функций, генерируемого эвристически в процессе традиционного планирования. Использование моделирования в методике IDEF0 р сочетании с методикой функционально-стоимостного анализа АВС позволяет обоснованно генерировать следующую информацию: функции, результаты осуществления функций, механизмы осуществления функций, длительность осуществления функций, стоимость осуществления функций, взаимную структурную увязку осуществления функций за счет создания корректной топологии связей.
Рассмотрим работу в MS Project 2002 на примере проектирования маркетинговой деятельности предприятия общественного питания [66].
Предприятие общественного питания является одним из многих представителей рынка общественного питания. Конкуренция в данной области достаточно велика. Поэтому для дальнейшего развития предприятия и для повышения его конкурентоспособности необходимо правильно управлять деятельностью предприятия. Но для принятия эффективных управленческих решений нужна информация о рынке. Для этого необходимо проводить активную маркетинговую деятельность. Причем нужно изучать как внешнюю среду (рынок, конкурентов), так и внутреннюю (клиентов).
Важнейшим основанием для любого маркетингового действия является информация. Поэтому нужно уделять особое внимание маркетинговым исследованиям. Маркетинговые исследования — это системный сбор, упорядочивание и анализ данных о различных маркетинговых проблемах, позволяющих лучше изучить рынок, удержать существующих клиентов и привлечь потенциальных. Под внешней средой информационной системы понимают целевые рынки, конкурентов. К внутренней среде относится само предприятие и его клиенты.
5*
132
Проектирование информационных систем
Конечной целью любого маркетингового исследования является формирование оптимальной стратегии и тактики действий с учетом реально сложившихся и вероятных в перспективе, с одной стороны, комплекса условий и факторов рынка, а с другой -— возможностей, потенциала и претензий фирмы.
Процесс маркетинговых исследований включает в себя следующие этапы и процедуры:
►	определение проблемы и целей исследования (определение потребности в проведении исследований, определение проблемы, формулировка целей исследования);
►	разработку плана исследования (выбор методов исследования, определение типа требуемой информации и источников, определение методов сбора данных, разработка форм сбора данных, определение бюджета и сметы исследования);
►	реализацию плана исследования (сбор данных, обработка данных, анализ полученных результатов);
►	подготовку и презентацию заключительного отчета (интерпретация полученных результатов (желательно в виде графиков, таблиц, схем и т.д.), оформление результатов и их доведение до руководства).
Система маркетинговых исследований входит в состав отдела маркетинга предприятия. Организационная структура представлена следующими звеньями: директор по маркетингу, менеджер по маркетингу, специалист по маркетинговым исследованиям, менеджер по рекламе, корреспонденты.
Планирование проекта должно включать следующие этапы:
►	определение проекта;
►	определение рабочего времени проекта;
►	ввод задач проекта;
►	организация этапов задач и планирование задач;
►	установка крайних сроков и ограничений.
Планирование ресурсной базы проекта:
►	выбор людей и оборудования для проекта;
►	определение рабочих часов ресурсов;
т^лава 4	- 22
панирование и управление информационными проектами
►	назначение людей и оборудования задачам;
►	определение затрат, необходимых для выполнения проекта;
►	создание отчетов, отражающих задачи, ресурсы, затраты, требуемые для выполнения проекта.
Порядок планирования проекта представлен на рисунке 4.14.
1 этап. Планирование проекта
Определение задач и рабочего времени проекта. Болес подробно в системе управления маркетингом рассмотрим задачи организации внутренних маркетинговых исследований. Основные задачи (бизнес-процессы) и их длительность приведены в таблице 4.8.
Таблица 4.8
Основные бизнес-процессы
Номер	Описание бизнес-процесса	Длительность
1	Изучение мнений и вкусов клиентов; их состав	
1.1	Определение целей исследования	1 день
1.2	Определение плана исследования	1 день
1.3	Разработка форм фиксирования	3 дня
1.4	Выбор корреспондентов	4 дня
1.5	Реализация разработанного метода сбора информации	10 дней
1.6	Обработка данных	3 дня
1.7	Организация хранения информации	2 дня
1.8	Предоставление информации	1 день
2	Исследование заполняемости зала	
2.1	Составление плана наблюдения	1 день
2.2	Разработка форм фиксирования	2 дня
2.3	Сбор информации	7 дней
2.4	Обработка данных	1 день
2.5	Организация хранения информации о заполняемости	2 дня
2.6	Предоставление информации	1 день
134
Проектирование информационных систем
глава 4	ч<-
*Pf лакирование и управление информационными проектами
Организация этапов задач в средстве MS Project 2002 представлена на рисунке 4.15.
Рис. 4.15. Организация этапов задач
Планирование задач. На данном этапе определяется путь, по которому проходит деятельность маркетинговых исследований (рис. 4.16). Возможны варианты создания связей между задачами:
►	если по окончании одной задачи начинается другая, выделите их и щелкните «Создать связь окончание — начало»;
►	если задачи начинаются синхронно, то выделите их и щелкните «Создать связь начало — начало»;
►	если две задачи должны закончиться одновременно, то выделите их и щелкните «Создать связь окончание — окончание»;
►	если вы что-то сделали не так, щелкните ссылку «Разорвать связь между объектами» и начните заново.
Изучение мнений и вкусов клиентов и их состав: определение целей исследования и определение плана исследова
пб
Проектирование информационных систем
ния —> разработка форм фиксирования и выбор корреспондентов одновременно (связь «начало-начало») —> реализация разработанного метода сбора информации—» обработка данных —> организация хранения информации —> предоставление информации. После задачи «Обработка данных» может начаться задача «Предоставление информации», по
этому следует увязать и эти задачи связью «окончание —
начало».
Исследование заполняемости зала: составление плана
наблюдения —> разработка форм фиксирования —> сбор информации —> обработка данных —> организация хранения информации о наполняемости —> предоставление информации. Здесь также свяжем задачи «Обработка данных» и «Предоставление информации» связью «окончание — на-
чало».
Рис. 4.16. Результат выполнения планирования задач
т^лава А	-
г фланирование и управление информационными проектами
2 этап. Планирование ресурсной базы проекта
Выбор трудовых и материальных ресурсов. Используемые трудовые ресурсы представлены в таблице 4.9. Требуемые материальные ресурсы для функционирования системы представлены в таблице 4.10, результат — на рисунке 4.17.
Таблица 4.9
Описание трудовых ресурсов
Название ресурса	Адрес эл. почты	Учетная запись Windows	Группа	Стандартная ставка	Ставка сверхурочных
Смирнов В.А.	sm@mail.ru	1	Спец, по маркетинг. иссл.	70 р/ч	80 р/ч
Николаев Н.Р.	nikolaeff@ mail.ru	2	Менеджер	70 р/ч	80 р/ч
Иванов И.П.	ivanoff@ mail.ru	3	Корреспондент	50 р/ч	60 р/ч
Романов В.В.	romanoff@ mail.ru	3	Корреспондент	50 р/ч	60 р/ч
Сидоров А.А.	cid@mail.ru	3	Корреспондент	50 р/ч	60 р/ч
Таблица 4.10
Описание материальных ресурсов
Название ресурса	Тип	Единица измерения материалов
Компьютер	Материальный	шт.
Копировальный аппарат	Материальный	шт.
Принтер	Материальный	шт.
Канцтовары	Материальный	комплект
Бумага (формы)	Материальный	пачка
138
Проектирование информационных систем
<фскк,оК
C^.-.Tjjr, taj«. 8->„1КЛ» тви.
/С С».В.;(а	< ♦ ~ * Itatatif.к*»> '	«I» »• j'K 3 |Ж|Ж
' JwwwjPe^pCMjOrewiwwxMa Оъег Г(1г1 li С/йдееегие uianr и e^rirfce деЛсгтме"- >' .'. .	, ~ ?
Используйте расположенные ниже ссылки для создания группы проекта и назначения задачам необходимых ресурсов. При щелчке ссылки отображаются средства для завершения шага и соответствующие инструкции.
Выбор людей и оборудование для проекта
Определение рабочих часов ресурсов
Николаев HP Иванов ИЛ. Романов В.6 Сидоров АА. Компьютер Колировапьный алпарет Принтер
Канцтовары Бумага (формы)
± Единицы j измерений 'Wepwarto*
Адрес ,;ЗЛекТрСн«&й
ПОЧТЫ
7чеп,«,. запись Window
Трудовой Трудовой Трудовой Трудовой Трудовой Материальный Материальней Материальный Материальный Материальный
sm@mail ru nifcolae1f@mail.ru Ivanof 1@mail.ru romanotf@mail.ru
CM@mail.ru
комплект
Назначение людей и оборудования задачам
Добавление дополнительных сведений о ресурсе или ссылки на них
Добавление столбцов для особых сведений
Публикация данных проекта на сервере
Рис. 4.17. Результат планирования ресурсов
Назначение ресурсов задачам. Назначение ресурсов каждой задаче рассмотрено в таблице 4.11, результат выполнения — на рисунке 4.18.
Назначение ресурсов задачам
Таблица 4.11
Номер	Описание бизнес-процесса	Ресурсы
1	2	3
]	Изучение мнений и вкусов клиентов и их состав	
1.1	Определение целей исследования	Смирнов
1.2	Определение плана исследования	Смирнов
1.3	Разработка форм фиксирования	Смирнов, компьютер, копировальный аппарат, принтер, канцтовары, бумага (формы)
глава 4	1 эп
х уу лакирование и управление информационными проектами
Окончание табл. 4.11
1	2	3
1.4	Выбор корреспондентов	Николаев
1.5	Реализация разработанного метода сбора информации	Романов В.В., Сидоров А. А., канцтовары, бумага (формы)
1.6	Обработка данных	Николаев, компьютер
1.7	Организация хранения информации	Николаев, компьютер
1.8	Предоставление информации	Николаев, компьютер, бумага (формы), принтер
2	Исследование наполняемости зала	
2.1	Составление плана наблюдения	Смирнов
2.2	Разработка форм фиксирования	Смирнов, компьютер, копировальный аппарат, принтер, канцтовары, бумага (формы)
2.3	Сбор информации	Иванов, канцтовары, бумага (формы)
2.4	Обработка данных	Николаев, компьютер
2.5	Организация хранения информации о наполняемости	Николаев, компьютер
2.6	Предоставление информации	Николаев, компьютер, бумага (формы), принтер
Определение затрат. Для трудовых ресурсов в столбце указывается фактическая заработная плата за все время работы (время выполнения проекта) исходя из установленного календаря для каждого ресурса и почасовой ставки (стандартная ставка). Для материальных ресурсов необходимо задать стоимость ресурсов, оцененную исходя из количества задач, в которых используется данный вид ресурсов (табл. 4.12). Например, один и тот же компьютер используется в 8 задачах, значит, разделим стоимость компьютера на 8, получим: стандартная ставка — 16000 : 8 = 2000 руб.
140
Проектирование информационных систем
Таблица 4.12
Стоимости материальных ресурсов
Ресурс	Количество задач	Стоимость, руб.	Ставка (стоимость на задачу), руб.
Компьютер	8	16 000	2000
Копиров, аппарат	2	14 000	7000
Принтер	4	6000	1500
Канцтовары	4	440	110
Бумага (формы)	6	480	80
Выбор корреспонден=
Реализация рвэрабоз
-Смирнов В.А.
И'Смирнов В-А.;Бумм> (формы)[1 пвчх»);Канцтов»ры(1
Разработка форм фи Сбор имформоми Обработке данных Организация хранен Предоставление
1) Диалоговое окно
4) Проверка сведений Проверьте следующие
2) Выбор задачи
В настоящее время выбрана задача:
16: Предоставление информации
^Смирнов в А.
‘ jfag| .Смирнов ВАхмата (фермер пачкаДОанцтовары!! комлпе!
3) Назначение ресурсов____________
В отображаемом справа диалоговом окне Назначение ресурсов выберите ресурсы, которые требуется назначить задаче. Затем махните кнопку Назначить
1 ресурсов»_____________
j Чтобы начать, щелкните следующую ссылку для вызова диалогового окиа Назначение ресурсов.
Назначить ресурсы...
И.П.;Бумма (формы)Г> п«чка];Км Имкогава Н.РцКомпъютерр пн] ЗДИ. Нико наев Н.РлКомпьютерИ в Николаев Н.Р.зКомПьмзерГ
Рис. 4.18. Назначение ресурсов задачам
Результат оценки затрат для каждой работы представлен на рисунке 4.19.
Общие затраты на проект (суммарные трудозатраты и единовременные затраты на покупку материальных ресурсов) представлены на рисунке 4.20.
Глава 4	141
жГГланиРование и управление информационными проектами *2“
Рис. 4.19. Затраты на проект (оценки)
1 Выберите нужное действие.
Г; Добавить ресурсы из адресной книги организации
Г Добавить ресурсы из каталога организации
q. Добавить ресурсы с сервера Microsoft Project Server
(t Ввести ресурсы вручную
Б представлении справа введите имена людей, которые будут работать над проектом.
Укажите адреса электронной
Рис. 4.20. Затраты на проект (статистика)
Для определения текущих затрат необходимо задать стоимость часа использования как трудовых, так и материальных ресурсов. Стоимость трудовых ресурсов определяется заработной платой сотрудников за время проекта. Для определения стоимости использования материальных ресурсов
142
Проектирование информационных систем
необходимо представить их как трудовые ресурсы. Стандартная ставка будет складываться из стоимости энергии, потребленной оборудованием, и стоимости оборудования, разнесенного на срок окупаемости оборудования (табл. 4.13). Мощности аппаратуры: компьютер — 300 Вт, принтер — 3 Вт, копировальный аппарат — 50 Вт. Тариф оплаты электроэнергии— 1 руб. 15 коп. (ориентировочно). Исходя из этого стоимость электроэнергии, израсходованной за 1 час работы, составит: компьютер — 0,35 руб., принтер — 0,035 руб., копир — 0,07 руб.
Таблица 4.13
Определение ставки
Ресурс	Стоимость1	Срок окупаемости	Количество дней работы в году	Количество часов работы в день	Стоимость часа работы	Стоимость электроэнергии, руб./ч	Стандартная ставка, руб./ч
Компьютер	16 000	1 год	256	8	7,8	0,35	8,15
Принтер	6000	1 ГОД	256	8	2,93	0,035	2,97
Копир	14 000	1 год	256	8	6,84	0,07	6,91
Результат выполнения представлен на рисунке 4.21.
Составление отчетов. Для просмотра состояния дел проекта средствами MS Project предусмотрена функция «Выбрать представление для просмотра или анализа сведений о проекте», включающая список диаграмм и графиков, которые можно использовать для анализа планирования проекта, а также краткое описание данного средства представления. Возможные отчеты анализа хода проекта, ресурсной базы, рабочего времени проекта и т.д. представлены на рисунках 4.22-4.26.
1 В стоимость входят затраты на расходные материалы.
глава 4	ix,
ж f~f панирование и управление информационными проектами ££
Рис. 4.21. Стоимость использования ресурсов
Рис. 4.22. Отчет «Календарь»
144
Проектирование информационных систем
Рис. 4.23. Подробная диаграмма Ганта
Рис. 4.24. Сетевой график
Глава 4	л.	145
ху~Глакирование и управление информационными проектами
Нис. 4.26. Сравнение хода проекта с базовым планом
__________________Проектирование информационных систем
VI
• | Контрольные вопросы
1.	Какие модели используются при оценке стоимости информационной системы? Дать характеристику каждому методу.
2.	Каковы основные достоинства и недостатки методов оценки стоимости?
3.	Указать место и роль проектного управления в процессе проектирования информационных систем.
4.	Что является объектом проектного управления?
5.	Перечислить основные составляющие сетевых моделей.
6.	Как осуществляется расчет временных параметров событий, работ и путей?
7.	Каковы основные этапы оптимизации загрузки сетевых моделей?
8.	Каковы основные этапы оптимизации сетевых моделей по кри-
• терию «время — затраты»?
9.	Перечислить основные этапы планирования проекта в среде MS Project.
Технологии и МЕТОДЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ
Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов.
Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне, с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
Традиционные способы организации и проектирования ИС всегда подчеркивали различия между данными и процессами. Способы, ориентированные на данные, вначале специфицируют данные, а затем описывают процессы, которые используют эти данные. Способы, ориентированные на процесс, первыми выделяют процессы, затем специфицируются потоки данных между процессами. Порядок спецификации процессов и данных информационной системы определяется методом проектирования.
148
Проектирование информационных систем
5-1. Методы проектирования информационных систем
Методология построения информационных систем содержит три основных компонента [56]:
►	набор моделей (типов моделей, если строго) для описания требований к ИС, проектных и программных решений. Каждая модель обычно содержит как определение конструкций (нотацию), так и правила их использования (синтаксис). Более подробно данный вопрос будет рассмотрен в главе 6 учебного пособия;
►	метод применения набора моделей для построения информационной системы. Метод обычно использует фиксированный набор моделей и определяет последовательность их построения для описания различных аспектов ' создаваемой системы;
►	процесс организации проектных работ, который включает различные технологии — планирования, управления проектом и т.д. Процесс планирования проектной деятельности рассмотрен в главе 4.
Каждый проект можно рассматривать как реализацию конкретного процесса применения метода. В зависимости от ограничений по срокам и стоимости, в конкретную реализацию могут быть включены лишь отдельные части полного метода и процесса. Кроме последовательности этапов методы проектирования отличаются объектами исследования и синтеза.
Методы проектирования информационных систем обычно относят к одному из двух видов — структурному или объектному. Правильнее было бы говорить о структурном и объектном наборах моделей, так как существуют методы построения одних и тех же моделей с несовместимыми синтаксическими правилами. Чтобы сохранить корректность терминологии, далее используется термин «подход».
Структурный подход обычно ассоциируется с раздельным построением модели функций (чаще всего диаграммы
рлава
* Технологии и методы проектирования информационных систем
потоков данных) и модели данных (чаще всего диаграммы «сущность — связь»).
Объектный подход содержит набор моделей, связанных с понятием класса/объекта, объединяющего данные (состояние) и поведение.
Сами по себе наборы моделей ни в коей мере не должны навязывать принципов построения систем. Тем не менее, нередко такие принципы считаются неотъемлемой характеристикой самих моделей. Структурный и объектный подходы успешно применяются как в спиральном, так и в каскадном жизненном цикле.
Существуют и другие подходы к определению методов проектирования ИС.
Подход, предложенный Клещевым Н. Т. и Романовым А. А. [23], в котором методы условно сгруппированы как: структурно-функциональные; виртуальные (универсальные); функционально-технологические; объектные. Очевидно, что таким образом выделенные группы сильно взаимосвязаны и существенно пересекаются по содержанию. Однако структурно-функциональный анализ является методологическим стержнем практически во всех методах проектирования ИС.
Виртуальные (универсальные) методы позволяют описывать абстрактный набор структур вычислительных процессов и каналов взаимодействия, которые отражают оргструктуру автоматизируемого объекта (рис. 5.1). Описание процессов на виртуальном уровне определяет внутреннюю структуру систем, но не учитывает программных и информационных взаимосвязей между процессами, реализуемыми ими задачами и объектами автоматизации.
Виртуальный уровень проектирования получил широкое распространение для ИС, ориентированных на решение простых задач или на операции обработки типовых данных. Для ИС, реализующих постоянно изменяющиеся функции организационного управления, как сама совокупность решаемых задач, так и, особенно, их параметры в значительной степени характеризуются неопределенностью не
150
Проектирование информационных систем
Рис. 5.1. Структура виртуальных методов
только на начальной стадии проектирования, но и в процессе эксплуатации. В течение всего периода создания и развития таких ИС, а он может длиться десятки лет, как организационная структура самого объекта автоматизации, так и решаемые в ИС функционально-технологические задачи находятся в процессе развития.
Структурно-функциональные методы проектирования и разработки заключаются в декомпозиции структуры ИС на отдельные подсистемы и модули в целях анализа их технического, системного и прикладного состава и последующего синтеза структуры системы для реализации заданных потребительских функций (рис. 5.2).
Организационные функции
Структура системы
Анализ
Программные модули
Управленческие функции
Управленческие задачи
Рис. 5.2. Структурно-функциональные методы
Синтез
Глава 5	-.с,
* Технологии и методы проектирования информационных систем
Эти методы широко используют уже отработанные алгоритмы и промоделированные задачи и хорошо себя зарекомендовали при проектировании универсальных и специализированных систем, отдельных машин и устройств. Если текущие изменения и появление новых функций незначительно отражаются на структуре этих устройств, машин и систем, то их адаптация к новым условиям функционирования не вызывает слишком больших финансовых затрат.
Функционально-технологические методы проектирования ИС обеспечивают анализ непрерывно изменяющегося спектра организационных, управленческих функций и опережающих технологий их решения в целях синтеза системной архитектуры системы, удовлетворяющей ее функциональному назначению и заданным показателям качества.
Функционально-технологические методы характеризуются:
►	целостным подходом к анализу и синтезу системной архитектуры ИС и реализуемых в этой архитектуре организационных и управленческих функций;
►	учетом динамики организационных и управленческих функций и обеспечивающих их программно-технических решений и системных архитектур;
►	учетом взаимосвязей организационных и управленческих функций, а также обеспечивающих их информационных технологий и системной архитектуры ИС при определяющей роли функций и технологий по отношению к структуре;
►	учетом физических и информационных связей между элементами ИС;
►	учетом взаимосвязей создаваемой ИС с внешней средой.
Существенным достоинством функционально-технологических методов является формирование и применение динамичных типовых конструкторских решений при создании ИС: типовых прикладных решений, типовых технологических подсистем и типовых операций по обработке информации, а также связанных с ними программно-технических решений.
^5^Проектирование информационных систем
Формирование и использование типовых конструкторских решений в соответствии с функционально-технологическими методами обеспечивают высокую динамику проработки технических решений для всех видов процессов и взаимосвязь их по трем уровням проектирования (поли-иерархическая модель):
►	концептуальному уровню (общесистемных проблем), на котором осуществляется анализ и синтез системных архитектур;
►	уровню функционирующих объектов ИС, где формируются решения по созданию и совершенствованию ИС;
►	уровню элементов ИС — создание программно-технической инфраструктуры функционирующих объектов.
Информационные системы, решающие аналитические и в особенности аналитико-логические задачи, часто оперируют неточной и неопределенной информацией. Такие задачи возникают, например, на валютных рынках, на фондовых биржах, при оценке риска инвестиций, при прогнозах спроса и предложений на рынках ценных бумаг и т.д. Проектирование подобных систем требует усиления функционально-технологических методов объектными методами.
Объектные методы обеспечивают единую концепцию (рис. 5.3) для прсдпросктного анализа (объектный анализ), проектирования (объектное проектирование), программирования функциональных задач (объектное программирование).
Рис. 5.3. Объектные методы
jpJiciBci 5	-«со
ж Технологии и методы проектирования информационных систем
Концептуальное единство объектных методов обеспечивается за счет использования базовых элементов: объектов, классов и свойств наследования. Абстрактный объект состоит из трех частей: имени объекта, состояния (переменных состояния) и методов (операций).
Интерфейс объекта с его окружением полностью определен методами, так как к состоянию объекта нет другого доступа извне, кроме как через методы.
Объекты с одинаковыми свойствами, т.е. с одинаковыми наборами переменных состояния и методов, образуют класс. Каждый класс задается своим описанием. Описание класса в объектной системе может быть представлено, в свою очередь, в виде объекта. В описании класса могут храниться также значения некоторых переменных состояний объектов. Это такие значения, которые должны быть всегда одинаковы для всех объектов одного класса. Соответствующие переменные образуют переменные класса.
Объектный анализ представляет собой метод анализа предметной области, основанный на преимущественном выявлении объектов этой предметной области и установлении взаимных связей между ними.
Объектное проектирование представляет собой метод проектирования, соединяющий в себе процесс объектной декомпозиции, приемы представления моделей проектируемой ИС как на логическом и физическом уровнях, так и в статической и динамической формах. В целом концепция объектных методов опирается на декомпозицию объекта, декларативное описание объектов классами, а также пошаговое программирование с использованием механизма наследования.
Под объектным программированием понимается метод программирования, основанный на представлении программы в виде совокупности объектов, каждый из которых является реализацией определенного класса, а классы, в свою очередь, образуют иерархию на основе принципов наследования.
154
Проектирование информационных систем
Типовые технологические подсистемы, созданные с помощью объектных методов, являются в принципе распределенными системами вычислений, так как память распределена между объектами и каждая операция выполняется только в памяти данного объекта.
Естественным образом возникает возможность параллельных вычислений (а значит, возникает и возможность создания ИС на принципах воспроизведения естественных рассуждений человека) путем одновременного выполнения операций разных объектов.
Объектные методы характеризуются следующими свойствами:
►	объединением в одном программном модуле данных и процедур их обработки, что позволяет более адекватно моделировать объекты реального мира (свойство инкап-' суляции). Инкапсуляция обеспечивает понижение уровня сложности программ, повторное использование кода программ без модификаций, изменение кода программ без разрушения отлаженных фрагментов и др.;
►	заимствованием и преемственностью атрибутов данных и переменных состояния от объекта к объекту (свойство наследования), что дает дополнительные преимущества, связанные с расширением функциональных возможностей и переменных состояния объектов, а также связанные с увеличением гибкости в применении общих исходных кодов программ благодаря использованию множественности наследования;
►	уникальностью реакции объекта на единообразные (конформные) обращения к нему в программе (полиморфизм). Наличие полиморфизма обеспечивает более естественный переход к компоновке программ на этапе исполнения, а также упрощает исходный код, облегчает повторное использование кодов программ, обеспечивает расширяемость кода программ благодаря введению новых переменных (методов их обработки).
Достоинством объектных методов является их ориентация на задачи анализа, проектирования и программирова
глава 5
*'Технологии и методы проектирования информационных систем
ния ИС с учетом динамики информационных потребностей пользователей, реализация которой традиционными методами крайне затруднительна.
Подход, предложенный Прозоровым А.А. [50], классификация методов в котором осуществляется на основании понятия жизненного цикла ИС, подходов к сущностной и объектной декомпозиции и сокрытии (локализации) ИС. Он представлен следующими методами: метод ОМТ (Object Modeling Technique), методы семейства (Icam DEFinition) и метод COMET (Concurrent Object Modeling and Architectural Design Method).
В методе ОМТпроектируемая ИС представляется в виде трех взаимосвязанных моделей [50]:
►	объектной модели, которая определяет статические аспекты системы, в основном связанные с данными (статическая структура);
►	динамической модели, которая описывает работу отдельных частей системы (динамическая структура);
►	функциональной модели, которая описывает взаимодействие отдельных частей системы, возникающее в процессе ее работы (взаимодействие описывается как в разрезе данных, так и в разрезе управления).
Эти три модели позволяют получить три ортогональных представления проектируемой системы в одной нотации. Совокупность моделей системы может быть проинтерпретирована на компьютере (с помощью инструментального ПО), что позволяет продемонстрировать характер работы с будущей системой и существенно упрощает согласование предварительного проекта системы.
На основе метода ОМТ построена технология проектирования, опирающаяся на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании. При этом, как
156
Проектирование информационных систем
только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. В настоящее время OMTTool входит в состав системы Paradigm+.
Метод ОМТ ограничивается двумя фазами жизненного цикла ПО (ИС): анализом требований совместно с построением объектной модели и реализацией программной системы.
Семейство методов проектирования и нотаций IDEF базируется на методологии ICAM (Integrated Computer Aided Manufacturing) и состоит из следующих представителей: ► IDEF0 — метод и нотация описания бизнес-процессов; ► IDEF1 — метод и нотация описания взаимосвязей между информационными потоками;
►	IDEFIX — метод и нотация разработки реляционных баз данных;
►	IDEF3 — метод и нотация описания технологических процессов;
►	IDEF5 — метод и нотация описания онтологических исследований.
Метод COMET основан на методе COMADM (Concurrent Object Modeling and Architectural Design Method), имея c ним незначительные отличия, обусловленные используемой в методе COMET нотацией UML. Указанные два метода разработаны профессором кафедры программотехники университета Джорджа Мэйсона Хассаном Гома (Hassan Gomaa), авторитетным идеологом в области проектирования распределенных приложений и приложений реального времени.
В общем виде метод COMET представляет собой метод объектного моделирования и архитектурного проектирования параллельных систем, в основе которого лежит создание объектно-ориентированного ПО. Жизненный цикл данного метода характеризуется значительным числом итераций.
Основными этапами метода COMET являются:
►	этап моделирования функциональных требований. На данном этапе основное внимание уделяется сбору и класси
рлава 5	-
Технологии и методы проектирования информационных систем 2^
фикации требований к системе, в то время как сама система рассматривается как черный ящик;
► этап аналитического моделирования, которое выполняется в терминах сущностной модели. На данном этапе основное внимание уделяется предметной области, при этом структура сущностной модели описывается с помощью статического представления модели, а характер поведения — с помощью динамического представления модели. Статическое представление модели выполняется в терминах классов (объектов) предметной области и отношений между ними, в то время как динамическое представление модели выполняется в терминах взаимодействия между объектами;
► этап архитектурного (имитационного) моделирования, которое выполняется в терминах структуры имитационной модели (классы и отношения между ними). На данном этапе основное внимание уделяется объектной и временной декомпозиции сущностной модели, формулируются базовые критерии разбиения системы на составные части (подсистемы, модули и проч.);
► этап программного моделирования, которое выполняется в терминах программной модели (атрибуты и операции классов). На данном этапе особое внимание уделяется программной реализации имитационной модели. В частности, статическое представление имитационной модели детализируется до атрибутов и операций классов, а также до законченных иерархий и других отношений между классами. Динамическое представление модели детализируется до полного описания активных составляющих, какими являются задачи, а также проектируются интерфейсы для обмена сообщениями и рассматриваются синхронные, асинхронные, групповые и брокерские коммуникации.
^8 Проектирование информационных систем
5-2. Методология создания информационных систем
Цель методологии создания информационных систем заключается в организации процесса построения ИС и обеспечении управления этим процессом, для того чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки. Основными задачами, решение которых должна обеспечивать методология создания корпоративных ИС (вместе с соответствующим набором инструментальных средств), являются:
►	обеспечение создания ИС, отвечающих предъявляемым к ним требованиям по автоматизации деловых процессов и целям и задачам организации;
►	гарантирование создания системы с заданным качеством в заданные сроки и в рамках бюджета;
►	поддержание удобной дисциплины сопровождения, модификации и наращивания системы, чтобы ИС могла отвечать быстро изменяющимся требованиям работы компании;
►	обеспечение создания ИС, отвечающих требованиям открытости, переносимости и масштабируемости;
►	обеспечение использования в разрабатываемой ИС задела в области информационных технологий, существующего в организации (ПО, баз данных, средств вычислительной техники, телекоммуникаций, технологий). Методология должна обеспечивать снижение сложности процесса создания ИС за счет полного и точного описания этого процесса и применения современных методов и технологий создания ИС на всем жизненном цикле ИС — от замысла до реализации.
В 90-е годы в мире произошли кардинальные изменения как на рынках товаров и услуг, так и в информационных технологиях (ИТ). ИС становятся основным фактором успешной работы корпораций на рынке. Для выполнения своего назначения они должны решать значительно более слож
Глава 5	- _Q
Технологии и методы проектирования информационных систем
ные задачи, чем решаемые раньше. В соответствии с высокой динамикой изменения ситуации на рынке становятся очень жесткими требования как к функциям, выполняемым ИС, так и к процессу создания ИС. Резко ужесточились требования к времени разработки отдельных приложений и системы в целом. Появилась необходимость в изменении требований в процессе разработки с тем, чтобы система отвечала требованиям организации на момент конца разработки, а не на момент начала.
Достижения в области ИТ позволили преодолеть принципиальные технические и программно-инструментальные проблемы создания корпоративных ИС. Появились современные аппаратно-программные платформы архитектуры клиент-сервер, средства для проведения распределенных параллельных вычислений и управления вычислительным процессом в гетерогенных сетях, методы и средства разработки программ и баз данных, обеспечивающие возможности создания открытых, переносимых, масштабируемых приложений и баз данных, возможности быстрой разработки и т.д.
Мощные импульсы развитию методологий дало появление двух принципиально новых подходов к созданию ИС: информационного инжиниринга и реинжиниринга бизнес-процессов (BPR). Предлагаемые в них методы позволили описывать, анализировать и проектировать структуру и деятельность корпораций подобно техническим системам. Каждый из этих подходов породил свой класс методологий, обладающих общими характеристиками. В настоящее время продолжается активный процесс развития и совершенствования методологий создания ИС.
В настоящее время не существует общепринятых подходов и методологий проектирования информационных систем. Методологии построения ИС условно можно разбить на два класса. Первый класс включает в себя методологии, основой которых является использование набора стандартных решений при построении ИС. ИС, построенные с
160
Проектирование информационных систем
использованием методологий второго класса, содержат помимо стандартных решений еще и уникальные разработки, которые позволяют максимально адаптировать ИС к структуре бизнес-процессов предприятия. В п. 5.3 приведено описание методологии, принадлежащей ко второму классу. Методология, обеспечивающая создание ИС, отвечающих целям и задачам организации, предъявляемым к ним требованиям по автоматизации деловых процессов, и обеспечивающая выполнение основных требований к процессу разработки, предложена Паронджановым С.Д. [48].
5-3- Основные составляющие методологии
Методология создания ИС состоит из двух основных .взаимосвязанных частей [48]: методологии анализа ИС, включающей описание деятельности организации и формирование требований к ИС на основе бизнес-процессов, и методологии проектирования от данных, предназначенной для проектирования и быстрой разработки программного и информационного обеспечения ИС. Методология строится на основе итерационной спиральной модели жизненного цикла ИС. Принципиальной особенностью этой методологии является то, что, охватывая все этапы жизненного цикла ИС, она делает основной упор на поддержку начальных этапов создания ИС, главной задачей которых является формирование требований к ИС, точно отвечающих целям и задачам организации. В соответствии с подходом информационного инжиниринга, который Джеймс Мартин определяет как «применение взаимосвязанного набора формальных технологий (моделей) для планирования, анализа, проектирования и создания информационных систем на уровне корпораций или отдельных ее частей ...», процесс создания ИС строится как процесс построения и развития моделей. Реализация методологии базируется на применении комплекса согласованных между собой инструментальных средств, обеспечивающих высокий уровень автоматизации всех про-
* 'Технологии и методы проектирования информационных систем цессов, выполняемых в соответствии с методологией на протяжении жизненного цикла ИС.
Таким образом, фундамент предлагаемой методологии составляют [48]:
►	итерационная спиральная модель жизненного цикла ИС; ► комплекс развивающихся систем согласованных моделей; ► методология анализа ИС на основе бизнес-процессов;
►	методология проектирования от данных.
5.31. Итерационная спиральная модель
жизненного цикла ИС
Методология описывает процесс создания и сопровождения информационных систем как жизненный цикл ИС, представляя его в виде последовательности стадий, каждая из которых разбита на этапы, и выполняемых на них процессов. Для каждого этапа определяются последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роль и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Жизненный цикл ИС, определяемый методологией, включает стадии анализа, проектирования, разработки, тестирования и интеграции, внедрения, сопровождения и дальнейшего развития ИС. В таблице 5.1 приведены также перечень основных этапов для каждой стадии ЖЦ и процессы, выполняемые на протяжении всего ЖЦ — процессы управления и интегральные процессы. Эти процессы в той или иной степени присутствуют на каждом из этапов.
Процесс создания ИС представляет собой процесс построения и последовательного преобразования согласованных моделей на всех этапах ЖЦ. Эти модели сохраняются и накапливаются в репозитории проекта. С помощью CASE-средств модели создаются, преобразуются и контролируются.
6. Зак. 1035
162
Проектирование информационных систем
Основными результатами на каждом этапе ЖЦ являются модели определяемых на данном этапе объектов (организации, требований к ИС, проекта ИС, требований к приложениям и т.д.).
Таблица 5.1
Жизненный цикл ИС
Стадии	Процессы организации и управления проектом: планирование, управление, контроль
Анализ	Обследование и создание моделей деятельности организации Анализ (моделей) существующих ИС Анализ моделей и формирование требований к ИС Разработка плана создания ИС
Проектирование	Концептуальное проектирование Разработка архитектуры ИС Проектирование общей модели данных Формирование требований к приложениям
Разработка	Разработка, прототипирование и тестирование приложений Разработка интеграционных тестов Разработка пользовательской документации
Интеграция и тестирование	Интеграция и тестирование приложений в составе системы Оптимизация приложений и баз данных Подготовка эксплуатационной документации Тестирование системы
Внедрение	Обучение пользователей Развертывание системы на месте эксплуатации Инсталляция баз данных Эксплуатация Проведение ПСИ
Сопровождение	Регистрация, диагностика и локализация ошибок Внесение изменений и тестирование Управление режимами работы ИС
глава b		16,4
* Технологии и методы проектирования информационных систем
5.3-	2. Комплекс развивающихся систем согласованных моделей
Методология определяет процесс создания информационных систем как процесс построения и последовательного развития систем согласованных моделей, начиная от системы моделей, описывающих деятельность организации, и заканчивая готовой информационной системой [48]. Модели должны создаваться, преобразовываться и контролироваться с помощью соответствующих CASE-средств и сохраняться в репозитории.
Отправной точкой процесса создания ИС являются модели бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Если построена компьютерная модель организации, описанная в терминах бизнес-процессов и бизнес-функций, то из этой модели может быть получено большинство важнейших требований к информационной системе. Это фундаментальное положение методологии позволяет абсолютно объективно подойти к выработке требований и проектированию информационной системы. Создается система моделей описания требований к ИС, которая затем преобразуется в систему моделей, описывающих проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.
5.3-	3- Методология анализа ИС
на основе бизнес-процессов
Целью начальных этапов создания ИС, выполняемых на стадии анализа, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации. Чтобы описать процесс создания ИС, отвечающей целям и
6
164
Проектирование информационных систем
задачам организации, нужно определить, в чем заключаются эти цели и задачи. Нужно выяснить требования заказчиков к ИС и преобразовать их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.
Современные средства позволяют достаточно быстро создавать ИС по готовым требованиям. Но, как отмечалось выше, очень часто оказывается, что эти системы не удовлетворяют заказчиков. Их приходится постоянно дорабатывать, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС. Как правило, заказчики не могут правильно и точно сформулировать требования к ИС. Более того, они часто не могут точно определить основные цели и ’задачи своей организации. Задача разработчиков заключается в том, чтобы получить эту информацию от заказчиков. Проблема формирования требований к ИС остается до настоящего времени одной из наиболее трудноформализуе-мых и наиболее дорогих и тяжелых для исправления в случае ошибки. Именно поэтому столь велика роль начальных этапов ЖЦ создания ИС, когда эти требования должны быть выявлены и формализованы, в получении конечного результата. Предлагаемая методология определяет, какие виды данных должны собираться в организации в процессе обследования и какие модели строиться для того, чтобы сформировать требования к ИС.
Основу деятельности любой организации составляют се деловые процессы, или бизнес-процессы, которые определяются целями и задачами организации. Процессы обеспечивают реализацию всех видов деятельности организации, связанных с производством товаров и(или) услуг, которые корпорация либо производит, либо продает и поставляет, либо делает все это в совокупности. Каждый бизнес-процесс характеризуется четко определенными во времени началом и концом, внешними интерфейсами, которые либо
^Технологии и методы проектирования информационных систем
связывают его с другими бизнес-процессами внутри организации, либо описывают выход во внешнее окружение последовательностью выполняемых работ и правилами их выполнения (бизнсс-правилами). Для каждой работы, входящей в бизнес-процесс, определены временные характеристики, определяющие ее место в общей последовательности работ, условия инициации и время выполнения. В отличие от описания организации на основе иерархической функциональной структуры, которую невозможно объективно оценить, описание на основе процессов позволяет точно представить цели, характеристики (в том числе динамические) и конечный результат каждого вида деятельности организации.
Исходя из того, что основные бизнес-процессы реализуют по своей природе цели и задачи организации, методология предлагает строить описание деятельности организации как процесс создания и развития систем согласованных моделей, основанных на моделях бизнес-процессов. В процессе детализации моделей и их последующей интеграции должно обеспечиваться сохранение всех функциональных свойств, отражающих цели и задачи организации, и согласованности моделей. Такая согласованность обеспечивается методологией и поддерживающими ее современными CASE-средствами.
В процессе описания организации и ее деятельности формируются три основные системы моделей организации: стратегическая, укрупненная и детальная. Все эти системы моделей, описывая основные аспекты организации и ее деятельности, базируются на бизнес-процессах. В систему моделей описания организации добавлена также дополнительная система моделей, для того чтобы можно было учесть аспекты, не связанные с бизнес-процессами, но необходимые при создании ИС.
Стратегическая система моделей организации. Процесс создания и развития систем согласованных моделей, описывающих деятельность организации, начинается с построения
166
Проектирование информационных систем
стратегической системы моделей организации, которая описывает основные аспекты деятельности организации на стратегическом уровне. Главное назначение стратегической системы моделей заключается, во-первых, в определении основных целей и задач организации и, во-вторых, в формировании моделей бизнес-процессов, описывающих основные виды деятельности организации и реализующих ее стратегические цели и задачи.
При построении моделей бизнес-процессов на стратегическом уровне не рассматривается иерархическая структура организации, описывающая «вертикальное» представление организации и устанавливающая функциональные и административные границы между подразделениями. Бизнес-процессы определяют прохождение потоков работ независимо от иерархии и границ подразделений и организаций, которые их выполняют, и показывают взаимодействие как внутренних, так и внешних (т.е. взаимодействующих с внешним окружением) бизнес-процессов. Модели, входящие в стратегическую систему моделей, строятся при обследовании организации путем опроса экспертов на уровне высшего руководящего персонала, определяющего стратегию организации, а также на базе основных документов организации. Эти модели хранятся в репозитории проекта.
Все создаваемые далее модели организации строятся на базе построенных бизнес-процессов по результатам обследования деятельности организации, проводимого на уровне подразделений. Модели строятся с помощью CASE-средств и сохраняются в репозитории проекта. Построение этих моделей допускает распараллеливание работ при проведении обследования и при построении моделей.
Дальнейшее развитие систем согласованных моделей происходит на базе схемы преобразования моделей (табл. 5.2), которая описывает развитие согласованных моделей по основным аспектам, определяющим деятельность организации (данные, функции, люди, сеть, время, правила). Каждая строка таблицы соответствует системе согласованных
глава 5	,	j 67
‘'Технологии и методы проектирования информационных систем
« S щ X
168
мт
Проектирование информационных систем
**уехнологии и методы проектирования информационных систем
моделей данного уровня и раскрывается в виде частных моделей по каждой группе характеристик. Переход от строки к строке показывает развитие системы моделей в процессе описания организации, а правила перехода определяются методологией и обеспечивают полноту и согласованность при построении моделей.
Укрупненная система моделей организации. Основными задачами описания организации на уровне укрупненной системы моделей являются: отображение основных бизнес-процессов, которые описаны на стратегическом уровне, исходя из основных целей и задач организации (без привязки к ее структуре), на реальную иерархически-функциональ-ную структуру организации, выделение основных функций подразделений, уточнение состава и характеристик бизнес-процессов.
На этом этапе проводится обследование подразделений, в результате которого выявляются выполняемые в них основные функции, их вход и выход. Эти функции распределяются по бизнес-процессам, проходящим через каждое подразделение. В результате формируются и уточняются общие списки бизнес-процессов и функций по подразделениям, списки входных и выходных документов и другие характеристики, и вся эта информация наполняет каждый бизнес-процесс конкретным содержанием. Таким образом, бизнес-процессы становятся путеводителями через иерархи-чески-функциональную структуру организации, определяющими функциональные и информационные связи между различными подразделениями. В процессе отображения бизнес-процессов по уровням организационной иерархии формируется и уточняется общий список бизнес-процессов и могут появиться новые бизнес-процессы.
Детальная система моделей организации. Главной целью создания детальной системы моделей является построение концептуальной модели данных и функциональной модели организации. Для достижения этой цели проводится детализация описания деятельности организации от уровня
170
Проектирование информационных систем
описания реализации общих бизнес-процессов в организации и списковых моделей в подразделениях до уровня детальных моделей подразделений, позволяющих выделить все функции подразделений, обрабатываемые документы, основные данные, описать регламент работы персонала и создать в итоге функциональную модель организации и концептуальную модель данных.
Выявленные в процессе обследования подразделения функции распределяются по бизнес-процессам этого подразделения, наполняя их конкретными работами данного подразделения. При этом описания бизнес-процессов могут дополняться и уточняться. В моделях описываются и детализируются бизнес-процессы, функции, информационные потоки, входные и выходные документы, взаимодействие внутри организации и с внешними объектами, данные, бизнес-правила, роли персонала и регламент, их взаимосвязи, временные и прочие характеристики.
Описание деятельности организации с помощью бизнес-процессов и бизнес-правил позволяет определить, где, когда и кем выполняется каждая функция, какие данные, информационные и функциональные взаимосвязи для этого нужны и откуда эти данные поступают. Построенная система моделей организации может использоваться для трех целей. Во-первых, построенные модели могут быть использованы для формирования требований к ИС. Во-вторых, система моделей может быть использована для анализа деятельности организации в целях ее улучшения путем проведения инжиниринга или реинжиниринга организации, в зависимости от результатов анализа. И, наконец, на основании анализа построенных систем моделей, а также существующих в организации ИС формируется стратегический план создания, развертывания, сопровождения и развития информационной системы.
Система моделей описания требований к ИС. Главной целью формирования системы моделей описания требований к ИС является обеспечение корректного перехода от
глава 5	1-71
А'Технологии и методы проектирования информационных систем
моделей описания организации к системе моделей ИС, определяющих конкретные компоненты проекта, такие, как приложения, базы данных, общесистемное ПО, средства вычислительной техники и телекоммуникации. Переход обеспечивает отображение целей и задач организации (выраженных через ее бизнес-процессы, данные, функции и другие модели) в функции и компоненты ИС.
Для перехода от системы моделей организации к системе моделей ИС необходимо сформировать систему моделей, описывающих требования к ИС, и связать эти требования с проектируемыми компонентами. Система моделей, описывающих требования к ИС, формируется путем отображения системы моделей организации, построенных на этапе обследования. Отображение задается матрицей преобразования, определяемой схемой преобразования моделей. В результате итерационного уточнения формируются основные модели требований к ИС, отражающие цели и задачи организации и включающие требования к архитектуре ИС, к данным, к интерфейсу, к регламенту работы пользователей, к реализуемым функциям и к управлению системой.
В системе моделей требований к ИС могут быть отражены также требования, связанные с необходимостью полной или частичной интеграции существующих информационных систем и(или) баз данных в новую систему. По итогам анализа построенных моделей должен быть окончательно сформирован план создания, развертывания, сопровождения и развития информационной системы, соответствующий целям, задачам и стратегии развития организации. Из полного набора требований к ИС для дальнейшего анализа и проектирования мы выделим требования к программному и информационному обеспечению и к интерфейсу с пользователями, оставляя в стороне требования к архитектуре и средствам вычислительной техники и телекоммуникаций.
172
Проектирование информационных систем
5-3.4. Методология проектирования от данных
Поскольку данные составляют основу деятельности любой организации и являются наиболее стабильной ее составляющей (функции и структура организации меняются гораздо чаще), то при построении корпоративной ИС наиболее адекватным решаемым задачам является подход к проектированию, основанный на данных. Такой подход обеспечивает наилучшее архитектурное решение при разбиении системы на приложения, а также простоту и согласованность при интеграции приложений. В основу процессов проектирования и разработки ПО и ИО положены методологии проектирования от данных для проектирования и быстрой разработки программного и информационного обеспечения переносимых распределенных ИС в архитектуре «клиент-сервер». Эти возможности основаны на использовании современных инструментальных средств моделирования, быстрого прототипирования и разработки.
Процесс проектирования основан на извлечении всех данных из моделей бизнес-процессов^ построении и развитии моделей данных (концептуальной модели данных, модели архитектуры ИС, полной реляционной модели данных и т.д., вплоть до моделей, определяющих приложения). Эти модели взаимосвязаны и интегрированы друг с другом и определяют множество уровней спецификаций для каждого этапа разработки. В процессе проектирования модели данных развиваются от простой начальной версии в законченную спецификацию приложения, используемую для генерации. При этом полная реляционная модель данных может быть разделена на подмодели (подсхемы), представляющие разные части системы, которые могут быть распределены по сети в окружении клиент — сервер в соответствии с архитектурой ИС.
Методология выполнения стадий сопровождения и развития ИС базируется на тех же основных принципах, что и описанные методологии. Эти шаги продолжают рассмот
глава 5		174
>грехнологии и методы проектирования информационных систем
ренный выше процесс развития систем моделей, представленных в комплексе развивающихся систем согласованных моделей.
5.4.	Методы и средства организации метаинформации проекта системы
Эффективность информационных систем в значительной степени зависит от ее обеспеченности качественными информационными ресурсами (ИР). Для обеспеченности потребителей информационными ресурсами требуется не только фактическое существование ресурсов, но и механизмы, позволяющие находить нужные ИР и получать доступ к ним. К таким механизмам относятся средства формирования и публикации метаданных ИС, каталогизации ИР, ведения хранилищ (репозиториев) метаданных и ИР, поиска ИР по метаданным, управления доступом к ИР и др. [58]. Создание перечисленных средств связано с решением общей проблемы систематизации ИР.
Под систематизацией ИР понимается многообразная деятельность, направленная на обеспечение условий для эффективного управления ИР. Управление ИР нс сводится только лишь к управлению контентом. Оно охватывает процессы учета ИР. публикации ИР и их описаний (метаданных), поиска, выбора, интеграции и распространения ИР, оценивания качества ИР, формирования заказов на разработку ИР и др.
Систематизация предполагает создание многоуровневой инфраструктуры управления ИР, являющейся областью взаимодействия всех участников процессов создания, распространения и применения ИР. Решение большинства задач систематизации ИР связано с использованием метаданных. Под метаданными понимается информация, характеризующая какую-либо другую информацию. В рассматриваемом контексте экземпляр метаданных представляет собой описание ИР для ИС.
174
Проектирование информационных систем
На самом высоком уровне метаданные могут быть разделены на две категории: общие метаданные и уникальные (специфические) метаданные.
Метаданные могут быть классифицированы и по другим параметрам:
►	метаданные бизнеса;
►	технические метаданные; .
►	метаданные процессов.
Метаданные бизнеса включают определения объектов, относящихся к корпоративным пользователям, логическим картам данных и словарям хранилищ данных. Технические метаданные включают данные о физических объектах: названия таблиц и столбцов, ограничения и правила физического преобразования между различными зонами. В метаданных процессов отражается статистическая информация о различных процессах: статистика загруженности, информация о календарном планировании и обработка исключений.
Метаданные определяют как описательную информацию о структуре и смысле данных, а также приложений и процессов, которые манипулируют данными. Метаданные могут характеризовать сущности, относящиеся не только к виртуальному (информационному) пространству, но и к реальному миру (персоналии, организации, события и др.). Метаданные могут являться частью ИР, но возможно и их отдельное хранение.
Система метаданных выступает в качестве центрального звена любой информационной системы. Как и в технологиях баз данных, для метаданных определяются два уровня представления:
— ипфологичсский, фиксируемый схемой метаданных, которая отражает состав и структуру элементов данных (полей) в экземпляре метаданных, их семантику, типы значений (включая словари и классификаторы) и ограничения целостности;
— даталогический, фиксируемый форматом метаданных, который отражает способ представления (кодирования) информации.
глава 5	i-7c
Технологии и методы проектирования информационных систем
К числу основных требований к системе метаданных относятся [58]:
►	универсальность в рамках установленного понимания ИР как объекта систематизации;
►	структурированность и формализованность метаданных, необходимые для их автоматической обработки;
►	достаточная выразительность для обеспечения эффективного решения задач, требующих наличия метаданных; совместимость с международными стандартами и протоколами в области метаданных и информационного поиска (создание условий для интероперабельности);
►	возможность задания ограничений целостности, отражающих взаимосвязи полей описания ИР;
►	обеспечение возможности хранения метаданных как совместно с ИР, так и отдельно от него;
►	возможность представления в метаданных сведений о создателях, правообладателях и распространителях ИР, а также отношений между ИР.
Широта применения метаданных подчеркивает важность обеспечения их интероперабельности, что требует для разработки ИС единого набора открытых спецификаций, охватывающих различные виды ИР и варианты использования метаданных, совместимых с международными стандартами и спецификациями в этой области.
Совместимость отечественной системы метаданных с международными стандартами и спецификациями обеспечивает:
—	взаимную «прозрачность» метаданных в российских и зарубежных каталогах и репозиториях для поисковых средств (программных агентов, СУУП и др.), что создает условия для обмена ИР;
—	упрощение создания ИР, ориентированных на зарубежный рынок;
—	- возможность обмена метаданными между российскими и зарубежными каталогами и репозиториями;
—	возможность формирования и использования метаданных, предназначенных для размещения в российских
Проектирование информационных систем
каталогах и репозиториях, в зарубежных инструментальных средствах (СУУП, системах управления контентом, авторских системах).
Существуют три подхода к построению схемы метаданных:
►	выбор одной из международных схем метаданных;
►	выбор одной из международных схем метаданных и ее расширение;
►	построение оригинальной схемы метаданных.
С точки зрения ориентации на виды ИР и сферы использования, системы метаданных подразделяются на универсальные и специализированные. ИР для ИС обладают спецификой, которая требует обеспечения возможности отражения в метаданных следующих компонентов [58]: — логической и физической структур ИР;
'—- информации для взаимодействия ИР с пользователем; — правил, определяющих методику работы с ИР;
— информации для построения интегрального ресурса на основе множества ИР.
Процесс проектирования ИС предполагает разработку документов [58]:
►	информационной модели, определяющей на инфологи-ческом уровне структуру экземпляра метаданных об ИР;
►	набора словарей и классификаторов, используемых в метаданных;
►	привязки информационной модели (формат метаданных); руководства по применению информационной модели метаданных, содержащего описания ограничений целостности, профили метаданных и др.;
►	прототипов программных средств для формирования метаданных.
Определение и использование общей информационной модели метаданных для ИР способствует:
—	обеспечению высокой степени семантической интероперабельности метаданных;
—	повышению эффективности поиска ИР;
"лава 5	177
Технологии и методы проектирования информационных систем
расширению применимости ИР и сокращению затрат на их создание за счет многократного применения одних и тех же ИР в разных приложениях.
Информационная модель, представляющая форму описания ИС, состоит из совокупности элементов данных, образующих иерархическую структуру. Элементы данных подразделяются на неделимые и составные. Первые соответствуют листьям иерархии, вторые — транзитным узлам.
Составной элемент включает один или несколько элементов данных, среди которых могут быть как неделимые, так и составные элементы. Составной элемент не имеет интегрального значения. Его значение выражается через значения входящих в него элементов. В рассматриваемой информационной модели составные элементы соответствуют типу данных «контейнер» и называются контейнерами.
Неделимый элемент данных не имеет подчиненных элементов. Он может обладать самостоятельным значением, соответствующим множеству допустимых значений, которое определяется ассоциируемым с элементом типом данных.
На верхнем уровне иерархии информационная модель может содержать следующие контейнеры (в скобках указаны их имена):
►	общие сведения об ИР;
►	жизненный цикл ИР — сведения о текущем состоянии
ИР и субъектах, внесших вклад в его создание и развитие; ► метаданные — характеристики описания ИР (экземпляра метаданных);
►	технические характеристики ИР;
►	права интеллектуальной собственности на ИР — сведения о правах интеллектуальной собственности на ИР и связанных с ними условиях его использования;
►	отношение — сведения об отношениях между описываемым ИР и другим ИР;
►	аннотация — комментарии по применению ИР и сведения о том, кто и когда их составил;
►	классификационные признаки — классификационные признаки ИР в рамках различных классификаторов.
178
Проектирование информационных систем
Элемент данных в информационной модели характеризуется следующими атрибутами: индексом, именем, описанием, повторяемостью, упорядоченностью значений, типом данных, предельным объемом, предельной повторяемостью.
Атрибут повторяемости отражает обязательный или необязательный статус элемента в рамках родительского контейнера в экземпляре метаданных, а также допустимость наличия в экземпляре метаданных нескольких экземпляров элемента (т.е. допустимость указания нескольких его значений).
Атрибут упорядоченности значений определяется для элементов, экземпляры которых могут повторяться. Множество значений такого элемента может быть неупорядоченным или упорядоченным. В первом случае порядок значений в экземпляре метаданных является несущественным. Во втором случае порядок, в котором приведены значения, имеет определенный смысл.
Для неделимых элементов алии данных определяет область допустимых значений и форму их представления. В качестве типов данных также выступают несколько стандартных контейнеров, многократно используемых для выражения значений элементов, являющихся листьями в иерархии базовой информационной модели.
Под классификатором понимается множество значений, образующих иерархическую (древовидную) структуру. В такой интерпретации словарь можно рассматривать как одноуровневый классификатор.
Некоторые классификаторы допускают возможность выбора из них значений любого уровня, другие — только листьев. Для представления характеристик, выражаемых значениями из классификаторов, в информационной модели служит контейнер. В его рамках классификационный признак ИР может быть специфицирован в краткой или полной форме. Краткая форма аналогична представлению значения словарного типа. В полной форме вместо единственно
глава 5	170
* Технологии и методы проектирования информационных систем
го экземпляра, представляющего вершину из классификатора, приводится последовательность его экземпляров, соответствующая пути в классификаторе, т.е. цепочке вершин от корня до выбранной вершины.
Пример решения для работы с метаданными [58]
В качестве примера рассмотрим розничную компанию, имеющую несколько хранилищ данных для обеспечения различных видов бизнес-отчетности. Компания имеет хранилище для составления отчетов по каналам поставок, хранилище для CRM, хранилище для данных о продажах и отдельное хранилище для финансовой информации. Компания хочет создать единое корпоративное хранилище данных с помощью консолидации информации в масштабах всей организации. Это хранилище будет центральным репозиторием для всех корпоративных данных, а отдельные подразделения будут создавать себе витрины данных на его основе. В процессе реализации этого проекта пришло п э-нимание того, что также необходимо выработать стратегию консолидации метаданных.
Для этого можно использовать подход, описанный выше, который включает четыре основных действия. Первое действие — определение требований к метаданным. Этот процесс включает идентификацию заинтересованных сторон и классификацию метаданных. Поскольку это проект консолидации хранилища данных, то типы метаданных будут достаточно простыми. Основные элементы — это некоторые корпоративные измерения, которые должны быть определены, и корпоративные факты. Оба этих элемента связаны с одними и теми же метаданными бизнеса. Следующий набор метаданных — это список таблиц и граф, использующих данные измерения и факты, т.е. это технические метаданные. Наконец, для документирования процессов ETL (извлечение, преобразование и загрузка) и создания витрин данных необходима информация о тех шагах, из которых они состоят, т.е. это метаданные о процессах.
180
Проектирование информационных систем
Для этих метаданных заинтересованными сторонами являются те, кто занимается моделированием данных, а также разработчики ETL, витрин данных и отчетов. Помимо этого, такие метаданные нужны для работы с инструментами ETL и отчетности. Для консолидации метаданных требуются все элементы метаданных, их классификация, а также информация о том, кто и какие именно данные использует.
Следующий шаг — моделирование решения для работы с метаданными.
После создания метамодели необходимо определить общую архитектуру. Было решено создать единый репозиторий для метаданных и определить процесс, который обеспечит его наполнение из всех систем. Например, после определения измерений и фактов метаданные экспортируются из инструментов моделирования данных и сохраняются в репозитории. Информация о процессах ETL создается вручную и также сохраняется в репозитории. Репозиторий инструментов отчетности наполняется с помощью заранее определенной технологии. Для выполнения требований отчетности, предъявляемых к метаданным, была создана система отчетности на основе Интернета, которая создает запросы к репозиторию для получения информации.
После создания такого решения консолидация метаданных может считаться практически законченной. Следующая проблема — обеспечение долговременной работы данного решения. Например, как должен обрабатываться новый элемент или измерение, созданные в модели данных? Как вносится информация о новом процессе ETL или новом отчете? Все это определяется процессом поддержки метаданных. Для моделей данных периодически используется процесс синхронизации репозиториев инструментов и метаданных. Для ETL и отчетности существуют аналогичные процессы.
'•лава 5
Технологии и методы проектирования информационных систем**”
У| Контрольные вопросы
1.	Перечислить основные методы проектирования информационных систем. В чем заключается сущность каждого метода?
2.	Какова основная цель методологии проектирования информационных систем?
3.	Перечислить основное составляющие методологии. Дать характеристику каждой из составляющих. Определить цели ее применения.
4.	Какие системы моделей организации формируются в процессе ее описания? Каковы их задачи?
5.	Что понимается под метаинформацией проекта? Какова цель создания системы метаданных?
6.	Перечислить основные требования к системе метаданных. Какие существуют основные подходы к ее построению?
К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ
В настоящее время проектирование информационных систем превратилось в сложную и трудоемкую работу, с выполнением которой под силу справиться лишь высококвалифицированным специалистам. Под понятием «проектирование» понимается, прежде всего, грамотный анализ требований заказчика, понимание функциональных требований к будущей системе, определение различных вариантов конфигурации и выбор оптимального из них, выбор аппаратной и программной платформ для работы приложений. Крайне важно также по возможности максимально точное планирование как временных, так и материальных ресурсов, необходимых для разработки, в частности, необходимое число разработчиков и уровень их квалификации. Только после завершения всех этих этапов можно приступать непосредственно к созданию прикладного программного обеспечения и базы данных. Нет необходимости говорить о важности ошибок, допущенных на начальных этапах проектирования, представим ситуацию, когда группа программистов продолжительное время разрабатывала систему, которая, как оказалось впоследствии, реализует не те функции, которые подразумевал заказчик.
Несколько десятков отечественных и зарубежных производителей программного обеспечения выпускают свои программные продукты, так называемые CASE-средства, для упрощения и формализации задач проектирования и разработки. Все они относятся к одной из двух групп по методу декомпозиции задач — структурные и объектно-ориентированные. Перед выбором конкретного CASE-срсд-ства предстоит сделать выбор одной из этих методологий.
рлава б	-g
* Подходы к проектированию информационных систем_
6.1.	Анализ и проектирование информационных систем
Анализ и проектирование — два достаточно близких и тесно связанных процесса. Они выполняют общую задачу, результатом которой должно стать четкое представление о системе, на основе которого будет создан программный код. Следовательно, необходимо их рассматривать совместно, проводя разделение по методологиям — анализ и проектирование на основе структурной методологии и на основе объектно-ориентированной методологии [86].
Анализ требований — процесс жизненного цикла программы, во время которого требования заказчика уточняются, формализуются и документируются. Основной вопрос, который решается в это время: «что должна делать будущая система?».
Проектирование — процесс жизненного цикла программы, во время которого исследуется ее структура и взаимосвязи элементов. Проектирование, как правило, является итерационным процессом. Проектирование должно проводиться на двух уровнях [86]:
►	проектирование архитектуры (проектирование системы, проектирование «в большом»);
►	детальное проектирование (проектирование модулей (подсистем), проектирование «в малом»).
Результатом анализа и проектирования должен стать проект, содержащий достаточное количество информации для реализации системы на его основе.
На сегодняшний день применяются две основные методологии — структурная и объектно-ориентированная. На этапе анализа и проектирования важно принципиальное различие между этими методологиями, заключающееся в разных способах декомпозиции систем. Структурная (функциональная) декомпозиция рассматривает структуру системы в терминах иерархии функций и передачи информации; объектная декомпозиция рассматривает структуру
184
Проектирование информационных систем
объектов и связей между ними, а также поведение системы в терминах обмена сообщений между объектами.
Далее перечислим основные методы структурного и объектно-ориентированного анализа и проектирования. Необходимо отметить, что в основе многих объектно-ориентированных методов лежит структурный подход.
6.1.1.	Методы проектирования архитектур информационных систем
Проектирование архитектуры (проектирование «в большом»)
Структурная методология. Проектирование архитектуры (проектирование «в большом») для структурной методологии включает следующие основные методы [86]:
	► метод нисходящего проектирования;
►	метод восходящего проектирования;
►	метод расширения ядра.
В случае структурной методологии в качестве модульной структуры программы принято использовать древовидную структуру. В узлах такого дерева размещаются подсистемы информационной системы, а направленные дуги показывают статическую подчиненность подсистем.
Методы нисходящего и восходящего проектирования имеют достаточно большое количество разновидностей и модификаций.
Метод нисходящего проектирования представляет собой подход функциональной декомпозиции на основе двух стратегий:
—	пошагового уточнения, при котором на каждом следующем этапе декомпозиции определяются подсистемы очередного, более низкого уровня;
—	анализа сообщений, при котором анализируются потоки данных, обрабатываемые подсистемами.
Метод восходящего проектирования — подход, при котором в первую очередь определяются вспомогательные подсистемы, требующиеся для проектируемой системы.
'пава б
Подходы к проектированию информационных систем
185
Метод расширения ядра — подход, при котором основное внимание уделяется выявлению множества вспомогательных подсистем, а не определению функции всей системы в целом.
Объектно-ориентированная методология. Проектирование архитектуры для объектно-ориентированной методологии включает следующие основные методы [31]:
►	метод проектирования предметных областей;
►	метод наведения мостов.
Метод проектирования предметных областей заключается в выделении предметной области системы с точки зрения пользователя. Предметная область — это отдельный реальный, гипотетический или абстрактный мир, населенный отчетливым набором объектов, которые ведут себя в соответствии с характерными для домена правилами и линиями поведения.
Метод наведения мостов заключается в том, что одна предметная область использует механизмы и возможности, обеспечиваемые другой предметной областью. Мост между двумя предметными областями представляет собой набор предложений (с точки зрения пользователя) и набор требований (с точки зрения исполнителя).
Проектирование подсистем (проектирование «в малом»)
Структурная методология включает следующие основные методы проектирования модулей:
►	диаграммы «сущность — связь»;
►	структурные карты;
►	диаграммы деятельности;
►	диаграммы Варнье-Орра;
►	диаграммы переходов состояний;
►	блок-схемы;
►	схемы экранов;
►	псевдокод.
186
Проектирование информационных систем
Объектно-ориентированная методология включает следующие основные методы проектирования модулей: — диаграммы кооперации;
— диаграммы компонентов;"
— диаграммы развертывания.
Методы анализа и построения спецификаций
Структурная методология включает следующие методы ведения структурного анализа:
►	диаграммы потоков данных;
►	диаграммы потоков управления;
►	таблицы решений;
►	сети Петри;
►	диаграммы зависимости;
►	диаграммы декомпозиции;
►	диаграммы функционального моделирования.
Объектно-ориентированная методология включает следующие методы ведения объектно-ориентированного анализа: — КОК-карты (класс — ответственность — кооперация); — диаграммы вариантов использования;
—	диаграммы классов;
—	диаграммы состояний;
—	диаграммы деятельности;
—	диаграммы последовательности.
6.1.2.	Подходы к ведению анализа
и проектирования
Структурная методология. Комбинации структурных методов образуют структурные подходы. Можно выделить три группы структурных подходов на основе порядка построения модели [11]:
1)	процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов;
2)	подходы, ориентированные на данные. Для таких подходов первичны входные и выходные данные, а функциональные (процедурные) компоненты вторичны;
’пава б
Подходы к проектированию информационных систем
187
3)	информационно-ориентированные подходы. Эта группа близка к предыдущей, но отличается тем, что работа ведется с нсиерархическими структурами данных.
Можно выделить два класса целевых систем — информационные системы (управляемые данными) и системы реального времени (управляемые событиями). Информационные системы работают с большим объемом входных данных сложной структуры. Системы реального времени работают с малым количеством входных данных простой структуры. Как правило, для проектирования систем реального времени применяются подходы, базирующиеся на подходах для информационных систем с расширением их дополнительными диаграммными техниками.
Подходы используют две основные группы средств моделирования:
►	диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между функциями, например, диаграммы потоков данных и функционального моделирования;
►	диаграммы, моделирующие данные и их отношения, например, диаграммы «сущность — связь».
Для анализа и проектирования экономических информационных систем в условиях российской действительности более подходят диаграммы потоков данных. Диаграммы функционального моделирования неплохо работают только при описании хорошо стандартизированных процессов.
Объектно-ориентированная методология. Перечислим основные подходы к ведению объектно-ориентированного анализа и проектирования и рассмотрим подробно некоторые из них:
►	подход на основе языка UML;
►	подход Шлеер-Меллора;
►	подход Г рад и Буча;
►	подход Джеймса Рамбо;
►	подход Ивара Якобсона.
188
Проектирование информационных систем
Подход на основе языка UML состоит из четырех основных фаз разработки, причем работа с диаграммами ведется в основном на второй и третьей фазах. Во время второй фазы — фазы исследования-—должна быть создана модель предметной области. На третьей фазе — построения — продолжается итеративная работа с диаграммами классов и деятельности. К ним добавляются типы диаграмм, которые определяют взаимодействие: диаграммы последовательности; диаграммы кооперации.
В случае сложного поведения системы разрабатывается еще одна группа диаграмм — диаграммы состояний.
Подход Шлеер-Меллора использует три группы средств для создания модели предметной области [31]:
1)	информационное моделирование — для определения отношений между данными (информацией). При этом используется один тип диаграмм — диаграммы классов;
2)	моделирование состояний — для определения зависящего от времени поведения системы. Используются диаграммы состояний;
3)	моделирование процессов — для определения функций, которые система должна выполнить. Используются диаграммы деятельности и диаграммы последовательности.
Для анализа больших предметных областей используются диаграммы, по смыслу близкие к следующим диаграммам языка UML:
►	диаграммы кооперации;
►	диаграммы компонентов;
►	диаграммы развертывания.
Подход предлагает механизм поддержки моделей состояний. Для этого вводятся четыре архитектурных класса:
1)	переход, описывающий каждый переход для всех моделей состояний в программе;
2)	конечная модель состояний, связывающая все экземпляры перехода, которые составляют одну модель состояний;
3)	активный экземпляр. Это абстрактный класс, из которого все экземпляры, имеющие модель состояний, наследуют их текущее состояние;
’лава б
ууодходы к проектированию информационных систем
189
гэ
4)	таймер, обеспечивающий механизм функционирования таймеров на основе аппаратных средств, доступных для хранения следа времени.
6.2. Структурный подход
к проектированию ИС
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, подразделяемые на задачи, и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей сист еме целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
6.2.1.	Структурный анализ в проектировании ИС
Анализ требований разрабатываемой системы является важнейшим среди всех этапов ЖЦ. Он оказывает существенное влияние на все последующие этапы, являясь в то же время наименее изученным и понятным процессом. На этом этапе, во-первых, необходимо понять, что предполагается сделать, а во-вторых, задокументировать, так как если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть достаточно прост и понятен заказчику.
Во многих аспектах системный анализ является наиболее трудной частью разработки. Проблемы, с которыми сталкивается системный аналитик, взаимосвязаны (и это
190
Проектирование информационных систем
является одной из главных причин их трудноразрешимос-ти) [69]:
►	аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;
►	заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, а что — нет;
►	аналит! ik сталкивается с чрезмерным количеством подробных сведений о предметной области и о новой системе;
►	спецификация системы из-за объема и технических терминов часто непонятна для заказчика;
►	в случае понятности спецификации для заказчика она будет являться недостаточной для проектировщиков и программистов, создающих систему.
Применение известных аналитических методов снимает некоторые из перечисленных проблем анализа, однако эти проблемы могу г быть существенно облегчены за счет применения современных структурных методов, среди которых центральное место занимают методологии структурного анализа.
Структурным анализом принято называть метод исследования системы, который начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7); ограниченный контекст, включающий лишь существенные на каждом уровне детали; дуальность данных и операций над ними; использование строгих формальных правил записи; последовательное приближение к конечному результату.
Все методологии структурного анализа базируются на ряде общих принципов, часть из которых регламентирует организацию работ на начальных этапах ЖЦ, а часть используется при выработке рекомендаций по организации работ [10]. В качестве двух базовых принципов [11] применяют следующие: принцип «разделяй и властвуй» и прин
экша 6
Подходы к проектированию информационных систем
191
цип иерархического упорядочивания. Первый является принципом решения трудных проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения. Второй принцип декларирует, что устройство этих частей также существенно для понимания. Понимаемость проблемы резко повышается при организации се частей! в древовидные иерархические структуры, т.е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта). Отметим основные из таких принципов [12, 69]:
►	принцип абстрагирования — заключается в выделении существенных с некоторых позиций аспектов системы и отвлечении от несущественных в целях представления проблемы в простом общем виде;
►	принцип формализации— определяет необходимость строгого методического подхода к решению проблемы; принцип «упрятывания» — исключает несущественную на конкретном этапе информацию: каждая часть «знает» только необходимую ей информацию;
►	принцип концептуальной общности — заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ — структурное проектирование — структурное программирование—структурное тестирование);
►	принцип полноты — направлен на контроль присутствия лишних элементов;
►	принцип непротиворечивости — требует обоснованности и согласованности элементов;
►	принцип логической независимости — концентрирует внимание на логическом проектировании для обеспечения независимости от физического проектирования;
►	принцип независимости данных—заключается в том, что модели данных должны быть проанализированы и спроектированы независимо от процессов их логической
192 Проектирование информационных систем
обработки, а также от их физической структуры и распределения;
►	принцип структурирования данных — определяет необходимость в структурировании и иерархической организации данных;
►	принцип доступа конечного пользователя — заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
Соблюдение указанных принципов необходимо при организации работ на начальных этапах ЖЦ независимо от типа разрабатываемого ПО и используемых при этом методологий. Руководствуясь всеми принципами в комплексе, можно на более ранних стадиях разработки понять, что будет представлять собой создаваемая система, обнаружить промахи и недоработки, это облегчит работы на последующих этапах ЖЦ и снизит стоимость разработки.
Для целей моделирования систем вообще и структурного анализа в частности используются три группы средств, иллюстрирующие функции, которые система должна выполнять; отношения между данными; зависящее от времени поведение системы (аспекты реального времени).
В структурном анализе применяются в основном две группы средств, отражающие функции, выполняемые системой, и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
►	SADT-модели (Structured Analysis and Design Technique) и соответствующие функциональные диаграммы;
►	DFD-диаграммы (Data Flow Diagrams) потоков данных;
►	ERD-диаграммы (Entity-Relationship Diagrams) «сущность-связь».
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
лава 6
ууодходы к проектированию информационных систем
193
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей, или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
6.2.2. Классификация структурных методологий
Современные структурные методологии анализа и проектирования классифицируются по следующим признакам [69]:
►	отношению к школам — Software Engineering (SE) и Information Engineering (IE);
►	порядку построения модели — процедурно-ориентированные, ориентированные на данные и информационноориентированные;
►	типу целевых систем — для систем реального времени (СРВ) и для информационных систем (ИС).
SE является нисходящим поэтапным подходом к разработке ПО, начинающейся с общего взгляда на его функционирование. Затем производится декомпозиция на подфункции, и процесс повторяется для подфункций до тех пор, пока они не станут достаточно малы для реализации кодированием. В результате получается иерархическая, структурированная, модульная программа. SE является универсальной дисциплиной разработки ПО, успешно применяющейся как при разработке систем реального времени, так и при разработке информационных сист ем. IE — новая дисциплина. С одной стороны, она имеет более широкую область применения, чем SE: IE является дисциплиной построения систем вообще, а не только систем ПО и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны, IE — узкая дисциплина, так как IE используется только для построения информационных систем, a SE — для всех типов систем.
7. Зак. 1035
194
Проектирование информационных систем
Разработка ПО основана на модели ВХОД — ОБРАБОТКА — ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонентов по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными — структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход как часть IE-дисциплины отличается от подхода, ориентированного на данные, тем, что позволяет работать с иерархическими структурами данных.
Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реагирование на эти события во времени — основная и первоочередная функция таких систем. Информационные системы отличаются от систем реального времени средствами поддержки этих особенностей, и различаются соответствующие структурные методологии (табл. 6.1) [69].
Таблица 6.1
Отличия информационных систем от систем реального времени
Информационные системы	Системы реального времени
Управляемые данными	Управляемые событиями
Сложные структуры данных	Простые структуры данных
Большой объем входных данных	Малое количество входных данных
Интенсивный ввод/вывод	Интенсивные вычисления
Машинная независимость	Машинная зависимость
глава б	1оч
^ТТодходы к проектированию информационных систем___
В таблице 6.2 классифицируются наиболее часто используемые методологии в соответствии с перечисленными признаками (данные по частоте использования получены на основе анализа информации по 127 CASE-пакетам) [69].
Таблица 6.2
Классификация применяемых методологий
Методология	Частота	Признаки классификации	
Йодан Де Марко	36,5%	SE	Процедурно-ориентированная ИС, СРВ
Гейн-Сарсон	20,2%	SE	Процедурно-ориентированная ИС, СРВ
Константами	10,6%	SE	Процедурно-ориентированная ИС, СРВ
Джексон	7,7%	SE	Ориентированная на данные ИС, СРВ
Варнье-Орр	5,8%	SE	Ориентированная на данные ИС
Мартин	22,1%	IE	Информационно-ориентированная ИС
SADT	3,3%	IE	Варианты использования ИС: - процедурно-ориентированная; - ориентированная на данные
Stradis	1,9 %	IE	Процедурно-ориентированная ИС
Во всех перечисленных методологиях проектирования информационных систем в различных комбинациях используются техники структурных диаграмм, приведенные в таблице 6.2. Необходимо отметить, что для проектирования систем реального времени используются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, контекстные графы, матрицы состояний (событий), таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм
7’
196
Проектирование информационных систем
для проектирования информационных систем. Более того, известные методологии проектирования систем реального времени (в частности, методологии Хатли и Уорда-Меллора) базируются на перечисленных методологиях проектирования информационных систем, расширяя их соответствующими диаграммными техниками.
6.2.3- Методология функционального
моделирования
Методология SADT разработана Дугласом [15]. На ее основе разработана, в частности, известная методология IDEFO (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях.
1. Графическое представление блочного моделирования. График блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа (выхода) представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются.
2. Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика.
рлава 6
Цодходы к проектированию информационных систем
197
Правила SADT включают:
►	ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
►	связность диаграмм (номера блоков);
уникальность меток и наименований (отсутствие повторяющихся имен);
1 синтаксические правила для графики (блоков и дуг);
разделение входов и управлений (правило определения роли данных);
► отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Состав функциональной модели. Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода — с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 6.1).
Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
198
Проектирование информационных систем
Управление
____I	I
Входы--------► Функция -------------► Выходы
L_ t	f
Механизм
Рис. 6.1. Функциональный блок и интерфейсные дуги
На рисунке 6.2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме.
Иерархия диаграмм. Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты — одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг — они также представляют полный набор внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют собой основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его
лава б
ууодходы к проектированию информационных систем
199
Рис. 6.2. Структура SADT-модели. Декомпозиция диаграмм
200
Проектирование информационных систем
интерфейсы обеспечивают контекст. К нему нельзя ничего добавить и из него не может быть ничего удалено.
Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно такими же, как и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и туже часть системы.
На рисунках 6.3-6.5 представлены различные варианты выполнения функций и соединения дуг с блоками.
Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоеди-ненным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.
передаются
Рис. 6.3. Одновременное выполнение
'лава 6
Цодходы к проектированию информационных систем
201
на родительской диаграмме
А12
Рис. 6.4. Пример полного и непротиворечивого соответствия
На SADT-диаграммах явно не указаны ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рис. 6.5).
спецификация
Рис. 6.5. Пример обратной связи
202
Проектирование информационных систем
Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рис. 6.6).
Заявка клиента
Порядок подачи Рыночные заявки условия
___L. -Ч______
Оформление заявки для биржи
I
Брокер
Контракт
Рис. 6.б. Пример механизма
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.
АО Разработать компьютерную систему
А1 Планировать процесс
А2 Разработать график работ
АЗ Построить модель системы
АН Принять структуру и метод изготовления системы
А12 Рассчитать требования, затраты, время на разработку
А13 Уточнить план сопутствующих мероприятий
Рис. 6.7. Иерархия диаграмм
глава б
* Подходы к проектированию информационных систем
203
Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично А2 детализирует блок 2 на диаграмме АО, которая является самой верхней диаграммой модели. На рисунке 6.7 показано типичное дерево диаграмм.
Типы связей между функциями. Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мерс семь типов связывания (табл. 6.3).
Таблица 6.3
Типы связей между функциями
Тип связи	Относительная значимость
Случайная	0
Логическая	1
Временная	2
Процедурная	3
Коммуникационная	4
П оследов ательная	5
Функциональная	6
Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.
(0) Тип случайной связности: наименее желательный. Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом. Крайний вариант этого случая показан на рисунке 6.8.
(1)	Тип логической связности. Логическое связывание происходит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или
204
Проектирование информационных систем
Рис. 6.8. Случайная связность
набор элементов, но необходимых функциональных отношений между ними не обнаруживается.
(2)	Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
(3)	Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке 6.9.
Рис. 6.9. Процедурная связность
(4)	Тип коммуникационной связности. Диаграммы демонстрируют коммуникационные связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные и (или) производят одни и те же выходные данные (рис. 6.10).
(5)	Тип последовательной связности. На диаграммах, имеющих последовательные связи, выход одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку моделируются причинно-следственные зависимости (рис. 6.11).
Рис. 6.11. Последовательная связность
(6)	Тип функциональной связности. Диаграмма отражает полную функциональную связность, при наличии полной зависимости одной функции от другой. Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связности. Одним из способов определения функционально-связанных диаграмм является рассмотрение двух блоков, связанных через управляющие дуги, как показано на рисунке 6.12.
В математических терминах необходимое условие для простейшего типа функциональной связности, показанной на рисунке 6.12, имеет следующий вид: С = g(B) =
206
Проектирование информационных систем
Рис. 6.12. Функциональная связность
В таблице 6.4 представлены все типы связей, рассмотренные выше. Важно отметить, что уровни 4-6 устанавливают типы связностей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.
Вхождение дуг в тоннель. Прием «вхождение дуги в тоннель» применяется, чтобы показать дуги, которые более детально или полно раскрывают содержание текущей диаграммы, но не являются существенными для диаграмм других уровней, например, диаграмм декомпозиции функциональных блоков.
Дуга «входит в тоннель» при следующих условиях:
►	когда является внешней дугой, которая отсутствует на родительской диаграмме (имеет скрытый источник);
►	касается стороны блока, но не появляется на диаграмме, которая его декомпозирует (имеет скрытый приемник). Тоннельные дуги от скрытого источника начинаются скобками, чтобы указать, что эти дуги идут из другой части или извне модели. Тоннельные дуги, имеющие скрытый приемник, кончаются скобками, чтобы отразить тот факт, что такая дуга либо идет к другой диаграмме, либо выходит из модели, либо не будет более в данной модели рассматриваться.
Этот прием может также использоваться для упрощения диаграмм.
"’лава 6	207
]~[одходы к проектированию информационных систем______________
X 5 я 03 « £	Случайная	Данные одного и того же множества или типа	Данные, используемые в каком-либо временном интервале	Данные, используемые во время одной и той же фазы или итерации	Данные, на которые воздействует одна и та же деятельность	Данные, преобразуемые последовательными функциями	Данные, связанные с одной функцией
Для функций	Случайная	Функции одного и того же множества или типа (например, «редактировать все входы»)	Функции одного и того же периода времени (например, «операции инициализации»)	Функции, работающие в одной и той же фазе или итерации (например,«первый проход компилятора»)	Функции, использующие одни и те же данные	I	Функции, выполняющие последовательные преобразования одних и тех же данных		Функции, объединяемые для выполнения одной функции
Тип связности	Случайная	Логическая	Временная 		Процедурная	Коммуникационнная 			1	П оследовательн ая	Функциональная
Значимость	О		Г']		тГ		40
208
Проектирование информационных систем
6.2.4. Методология описания и моделирования процессов
Метод описания процессов IDEF3. Стандарт IDEF3 — это методология описания процессов, рассматривающая последовательность их выполнения и причинно-следственные связи между ситуациями и событиями для структурного представления знаний о системе, а также описания изменения состояний объектов, являющихся составной частью описываемых процессов. Моделирование в стандарте IDEF3 производится с использованием графического представления процесса, материальных и информационных потоков в этом процессе, взаимоотношений между операциями и объектами в процессе. При помощи IDEF3 описывают логику выполнения работ, очередность их запуска и завершения, т.е. IDEF3 предоставляет инструмент моделирования сценариев действий сотрудников организации, отделов, цехов и т.п., например порядок обработки заказа или события, на которые необходимо реагировать за конечное время, выполнение действий по производству товара и т.д. Метод IDEF3 использует категорию сценариев для упрощения структуры описаний сложного многоэтапного процесса. Сценарии определяют граничные условия описания. Здесь под сценарием (Scenario) понимают повторяющуюся последовательность ситуаций или действий, которые описывают типичный класс проблем, присутствующих в организации или системе, описание последовательности изменений свойств объекта в рамках рассматриваемого процесса (например, описание последовательности обработки менеджером заявки). IDEF3 предоставляет инструментарий для наглядного исследования и моделирования сценариев выполнения процессов. Метод позволяет проводить описание с необходимой степенью подробности посредством использования декомпозиции. IDEF3 как инструмент моделирования фиксирует следующую информацию о процессе [60]: ► объекты, которые участвуют при выполнении сценария; ► роли, которые выполняют эти объекты (например, агент, транспорт и т.д.);
^Подходы к проектированию информационных систем_—иии
►	отношения между работами в ходе выполнения сценария процесса;
►	состояния и изменения, которым подвергаются объекты; ► время выполнения и контрольные точки синхронизации работ;
►	ресурсы, которые необходимы для выполнения работ.
Описание IDEF3. IDEF3 — уникальная методология, способная фиксировать и структурировать описание работы системы. При этом сбор сведений может производиться из многих источников, что позволяет зафиксировать информацию от экспертов о поведении системы, а не наоборот — строить модель, чтобы приблизить поведение системы. Эта особенность IDEF3 как инструмента моделирования выделяется среди основных характеристик, отличающих IDEF3 от альтернативных предложений. В стандарте IDEF3 существуют два типа диаграмм, представляющих описание одного и того же сценария технологического процесса в разных ракурсах [61]. Диаграммы, относящиеся к первому типу, называются диаграммами описания последовательности выполнения процесса (Process Flow Description Diagrams, PFDD}. Второй тип диаграмм описывает состояния объекта и трансформаций в процессе и называется сетью изменений объектных состояний (Object State Transition Network, OSTN}. Если диаграммы PFDD описывают процесс, то другой класс диаграмм IDEF3 OSTN используется для иллюстрации трансформаций объекта, которые происходят на каждой стадии выполнения соответствующих работ («с точки зрения объекта»).
Объектные сети изменений состояния (OSTN) фиксируют центрированные объектом представления процессов, суммируя допустимые изменения состояния, которым объекты могут подвергнуться повсюду во время специфического технологического маршрута. Ключевыми понятиями диаграммы описания последовательности действий являются понятия, процесс и логика процесса. Состояния объекта и изменение состояния являются ключевыми понятиями OSTN-диаграммы.
Проектирование информационных систем
210
мг
Основные элементы диаграмм описания последовательности процессов [59]. Диаграммы процесса (наиболее распространенные) обеспечивают механизм визуализации для центрированных процессов описаний сценария. Графические элементы, которые включают диаграммы процесса, включают модуль полей (UOB) поведения, связей старшинства, перекрестков, объектов ссылки и примечаний. Объекты ссылки и примечания — конструкции, которые являются общими для диаграмм процесса и объектов. Каждый из графических элементов, используемых для разработки диаграмм процесса, представлен ниже. Первым рассматривается наиболее фундаментальный из этих стандартных блоков — UOB-функциональный элемент.
Функциональный элемент (UOB). Описание процесса представляет всевозможные ситуации (процессы, функции, действия, акты, события, сценарии, процедуры, операции или решения), которые могут происходить в моделируемой системе в логических и временных отношениях. Каждый процесс представлен полем, отображающим название процесса (рис. 6.13). Номер идентификатора процесса назначается последовательно. В правом нижнем углу UOB-элемента располагается ссылка (IDEFO/USER или другие), которая используется для указания ссылок либо на элементы из функциональной модели IDEF0, либо на отделы или
Рис. 6.13. Синтаксис UOB-элемента
рлава б
ТТОДХОДЬГ к проектированию информационных систем
211
конкретных исполнителей, которые будут выполнять указанную работу.
Основная цель этапа: преобразование требований в детальные спецификации ИС.
Элемент связи. ГОЕЕЗ-элемент диаграммы описания процесса связи необходим для связи элементов диаграммы и описания динамики, происходящих процессов. Связи используются, прежде всего, для обозначения отношений между функциональными элементами UOB. Для отображения временной последовательности выполнения сценариев в диаграммах описания процесса используются два основных типа связей: связи старшинства и относительные связи. Для описания специфических отношений между элементами предназначены четыре дополнительных типа связей — сдерживаемых связей старшинства. Использование в IDEF3-диаграммах описания процесса различных типов связей дает возможность пользователям метода фиксировать дополнительную информацию о специфике отношений между элементами диаграммы. Символы, которые представляют каждый тип связей, изображены на рисунке 6.14.
Простая связь старшинства
Сдерживаемые связи старшинства
Относительная связь
Рис. 6.14. Типы связей в диаграммах описания процесса
Подобно процессам, нумерация стрелок производится последовательно, согласно порядку, в котором они добавлены. Номера стрелок содержат префикс «L» и назначенного, последовательного номера.
Связи старшинства. Связи старшинства выражают временные отношения старшинства между элементами диаграммы. При этом первый элемент должен завершиться
212
Проектирование информационных систем
прежде, чем начнет выполняться следующий. Графически связь предшествования (старшинства) отображается сплошной линией с одиночной стрелкой (рис. 6.15).
Рис. 6.15. Семантика использования связи старшинства
Сдерживаемые связи старшинства. Данные виды связей не представлены ни в одном из CASE-продуктов, поддерживающих методологию IDEF3. Сдерживаемые связи старшинства указывают (в дополнение к семантике запуска связей простого старшинства):
►	' элементу А должен предшествовать элемент В;
►	элементу В должен предшествовать элемент А;
►	нижняя диаграмма указывает, что любой элемент должен сопровождаться элементом В и что элементу В должен предшествовать элемент А. Эти связи добавляют дополнительные условия к системе (рис. 6.16). Эти дополнительные условия не только выражают то, как система работает, но и устанавливают требования к тому, как система должна себя вести.
Существует также обобщенное представление сдерживаемых связей предшествования, когда в процессе разработки модели неясно, какая именно связь предшествования должна использоваться, но понятно, что должна использоваться именно сдерживаемая связь предшествования.
Рис. 6.16. Обобщенное представление сдерживаемых связей предшествования
г’ла.вй 6	2
А|~[одходы к проектированию информационных систем____
Относительные связи. Использование относительной связи указывает на тот факт, что между взаимодействующими элементами диаграммы описания процесса существуют отношения неопределенного типа. Относительные связи графически показываются как пунктирные линии.
Связь «поток объектов». Тип связи «поток объектов» предложен разработчиками CASE-средств, поддерживающих моделирование в стандарте IDEF3. Графически эта связь показывается как сплошная линия с двойной стрелкой (рис. 6.17). Этот тип связи выражает перенос одного или нескольких объектов от одного функционального элемента к другому, а также наследует все свойства простой связи старшинства. Таким образом, значение связи «поток объектов» таково: между UOB-элементами происходит передача объекта(ов), причем первый элемент UOB должен завершиться прежде, чем начнет выполняться следующий.
Рис. 6.17. Представление связи «поток объектов»
Перекресток. Перекрестки используются для отображения логики отношений между множеством событий и временной синхронизации активизации элементов диаграмм IDEF3. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок (рис. 6.18).
Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Тип перекрестка определяет логику и временные параметры отношений между элементами диаграммы. Все перекрестки в PFDD-диаграмме нумеруются, каждый номер имеет префикс «J».
214
Проектирование информационных систем
Рис. 6.18. Перекрестки разветвления и слияния
Типы перекрестков. Тип перекрестка обозначается на элементе следующим образом:
►	' & — логический И;
►	О — логический ИЛИ;
►	X—логический перекресток НЕЭКВИВАЛЕНТНОСТИ.
Стандарт IDEF3 предусматривает разделение перекрестков типа & и О на синхронные и асинхронные (рис. 6.19). Это разделение позволяет учитывать в диаграммах описания процессов синхронизацию времени активизации.
ТИП
ТИП
Асинхронный
Синхронный
Рис. 6.19. Пример обозначения синхронности и асинхронности перекрестков
Для последующего изложения материала необходимо ввести понятие график запуска. График запуска — это визуальное отображение временной последовательности выполнения UOB-элементов. Возможный график запуска для ситуации представлен на рисунке 6.20, семантика использования связи старшинства была приведена на рисунке 6.15.
глава 6
*• Подходы к проектированию информационных систем
215
Время
Рис. 6.20. Пример графика запуска
Визуальное отображение на графике запуска временной последовательности выполнения UOB-элементов поможет правильно понять, как перекрестки описывают логику отношений между элементами диаграммы описания процессов и каким образом перекрестки позволяют синхронизировать по времени выполнение UOB-элементов.
Методология IDEF3 использует пять логических типов для моделирования возможных последовательностей действий процесса в сценарии (табл. 6.5).
Использование комбинаций перекрестков (рис. 6.21,6.23, 6.25, 6.26, 6.28, 6.30) и соответственно графиков запуска (рис. 6.22, 6.24, 6.27, 6.29) представлено на схемах ниже.
Рис. 6.21. Использование перекрестка «асинхронный AND»
Логические типы
ю
Os
Таблица 6.5
Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
Synchronous AND	Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно
Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены
Synchronous OR	Один или несколько предшествующих процессов завершаются одновременно	Один или несколько следующих процессов запускаются одновременно
XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий процесс запускается
д
as
О Й и»
IS
218
Проектирование информационных систем
Рис. 6.25. Использование перекрестка «асинхронный OR»
Рис. 6.26. Использование перекрестка «синхронный OR»
Рис. 6.27. Возможный график запуска для рис. 6.25 и рис. 6.26
глава 6
д Подходы к проектированию информационных систем
219
Рис. 6.28. Использование «асинхронного AND» перекрестка разветвления и «асинхронного OR» перекрестка слияния
Рис. 6.29. Возможный график запуска для рис. 6.28
220
Проектирование информационных систем
Рис. б.ЗО. Невозможное совместное использование перекрестков
Элемент «референт». Элемент «референт» — это элемент ссылки. Референты расширяют границы понимания диаграммы и упрощают конструкцию описания (тем самым исключают неоднозначность). Референты используются как в ГОЕЕЗ-диаграммах описания процесса, так и в объектных диаграммах OSTN (табл. 6.6). Референты предназначены для:
►	обращения к предварительно определенному функциональному элементу UOB без дублирования его определения;
Таблица 6.6
Использование референтов в диаграмме
Тип референта	Обозначение референта	Locator
иов	Имя функционального элементаИОВ	Номер (JOB
SCENARIO	Название сценария	Номер Scenario
TS (Transition Schematic)	Название диаграммы перехода состояний	Номер диаграммы перехода
GO-TO используется только в IDEFS-диаграм-мах описания процесса	Имя функционального элемента UOB	Номер сценария или декомпозиции, в котором находится номер UOB
глава 6
* Подходы к проектированию информационных систем
221
►	передачи управления или организации возвратных циклов;
►	организации связи между ГОЕРЗ-диаграммами описания процесса и OSTN-объектными диаграммами.
Каждый тип референта может использоваться как в IDEFS-диаграмме описания процесса, так и в объектной диаграмме OSTN. Однако наиболее продуктивно референты используются в IDEFS-диаграммах описания процесса.
Виды референтов. Помимо деления на виды, методология IDEF3 определяет два вида референтов по способу запуска (рис. 6.31).
РЕФЕРЕНТ
«Запустить и Продолжить»
	Тип референта/ Имя референта
Locator	
РЕФЕРЕНТ «Запустить и Ждать»
	Тип референта/ Имя референта
Locator	
Рис. 6.31. Синтаксис референта
Разделение на референты «запустить и продолжить» и «запустить и ждать» позволяет описать временные границы выполнения референта. Так, использование референта «запустить и продолжить» указывает, что упомянутый элемент «референт» должен лишь инициализироваться (активизироваться) раньше, чем выполнение элемента IDEF3, вызывающего элемент «референт», будет завершено. Для такой ситуации возможное развитие событий представлено на рисунке 6.32.
Использование референта «запустить и ждать» указывает, что упомянутый референт должен активизироваться и завершиться прежде, чем элемент, его вызвавший, завершит свое выполнение, как это показано на рисунке 6.33.
222
Проектирование информационных систем
Рис. 6.32. Использование референта «запустить и продолжить» и возможный график запуска
Реф
UOB
Время
Рис. б.33. Использование референта «запустить и ждать» и возможный график запуска
Использование референта «запустить и продолжить». Если используется референт «запустить и продолжить», который имеет тип UOB, SCENARIO или GO-ТО, то на выходе такого элемента не может использоваться стрелка старшинства. Это утверждение становится очевидным, если посмотреть график запуска на рисунке 6.34.
При использовании после референта «запустить и продолжить» стрелки старшинства получаем неопределенную, непоследовательную и противоречивую ситуацию. Существует противоречие в совместном использовании референта «запустить и продолжить» и стрелки старшинства.
•лава б
уу од ходы к проектированию информационных систем
223
Рис. 6.34. Невозможное использование референта «запустить и продолжить»
UOB-референт. Если тип референта UOB, то наименование этого референта должно быть идентично наименованию элемента UOB, который предварительно определен. Если референт UOB используется в диаграмме описания процесса и приложен к элементу диаграммы, то во время выполнения вызывающего UOB-элемента осуществляется активизация соответствующего UOB-элемента (причем временных ограничений по завершению вызываемого UOB-элемента нет). Если UOB-референт приложен к стрелке, которая связывает элементы состояния объекта в диаграмме объекта, то выполнение упомянутого в референте UOB должно начаться прежде, чем начнет изменяться состояние объекта. Если UOB-референт приложен к элементу состояния объекта в объектной диаграмме OSTN, то это указывает, что упомянутый UOB содержит объект в соответствующем состоянии.
SCENARIO-референт. Если используется референт типа Scenario, то его название соответственно должно совпадать с названием сценария, на который ссылается вышеуказанный референт. При использовании Scenario-референта в диаграмме описания процесса во время выполнения вызы
224
Проектирование информационных систем
вающего UOB-элемента осуществляется активизация вызванного сценария (причем временных ограничений по завершению вызываемого сценария нет). Вызываемый сценарий выполняется на всю «глубину» декомпозиции. Если Scenario-референт приложен к стрелке, которая связывает элементы состояния объекта в диаграмме объекта, то выполнение упомянутого в референте Scenario должно начаться прежде, чем начнет изменяться состояние объекта.
Использование референта «запустить и ждать». Если тип референта UOB или SCENARIO, то такой элемент может являться источником для связи старшинства. Другой особенностью референта «запустить и ждать» является невозможность использования GO-TO-референта.
Элемент «примечание». Элемент «примечание» может использоваться как в диаграммах описания процесса, так и в объектных диаграммах OSTN. Этот элемент может быть приложен к функциональному элементу UOB, перекрестку, связи, объекту или референту. Элемент «примечание» предназначен для:
►	идентификации и подчеркивания участия специфических объектов или отношений, связанных с функциональным элементом UOB, связью или переходом;
►	присоединения примеров, объектов и т.п. (например, экранных форм);
►	отображения специальных условий, уточнений соединения или ограничений, связанных с элементами диаграмм. Примечания могут использоваться для обеспечения дополнительной информации в процессе моделирования, для присоединения к диаграммам иллюстраций, текста, экранных форм, комментариев и т.д. Примечания предоставляют возможность выразить идеи или концепции вместо использования относительных связей.
На рисунке 6.35 показана семантика использования элемента «примечание».
Поле примечания разделено на две части. Верхняя часть элемента используется для идентификации примечания и
глава б
х ПОДХОДЫ к проектированию информационных систем
225
#Вызывающего Элемента/ ^Примечания
Описание предмета примечания
Рис. 6.35. Семантика элемента «примечание»
содержит идентификатор примечания, составленный из номера элемента, для которого делается примечание, и номера примечания с префиксом N (например, J1/N1). Нижняя часть примечания называется полем примечания и предназначена непосредственно для текста, рисунка й т.п. Стандартом IDEF3 не определены какие-либо ограничения на форму и состав содержания поля примечания, хотя группой разработчиков модели могут быть оговорены некоторые соглашения для решения каких-либо целей.
Декомпозиция процесса. Методология IDEF3 дает возможность представлять процесс в виде иерархически организованной совокупности диаграмм. Диаграммы состоят из нескольких элементов описания процесса IDEF3, причем каждый функциональный элемент UOB потенциально может быть детализирован на другой диаграмме. Такое разделение сложных комплексных процессов на их структурные части называется декомпозицией. Декомпозиция формирует границы для описания процесса, и каждый UOB-элемент рассматривается как формальная граница некоторой части целой системы, которая описывает весь процесс. Декомпозированная диаграмма, называемая диаграммой-потомком, более детально описывает процесс. Декомпозируемый UOB-элемент называется родительским, а содержащая его диаграмма, соответственно, родительской диаграммой. Итак, декомпозиция — это процесс создания диаграммы,
8. Зак. 1035
226
Проектирование информационных систем
детализирующей определенный UOB-элемент. Результатом ее является описание, которое представляет собой дробление родительского UOB-элемента на меньшие и более частные операции или функции. Кроме того, само слово «анализ» означает разложение на составляющие. Но декомпозиция — это больше, чем разложение на части. Она включает также синтез. Подлинная декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание (рис. 6.36). Применяя принцип декомпозиции неоднократно, возможно структурировать описание процесса до любого уровня подробности. Декомпозиция обеспечивает средства организации более детального описания UOB-элементов. Каждый UOB-элемент может иметь любое число различных декомпозиций на том же самом уровне детализации в целях представления различных точек зрения или обеспечения большей подробности при описании исходного процесса.
Нумерация элементов диаграммы описания процесса приведена на рисунке 6.36.
Рис. 6.36. Пример нумерации UOB-элементов
тлпава6
х Додходы к проектированию информационных систем_
6.2.5.	Моделирование потоков данных (процессов)
В основе данной методологии (методологии Gane/Sar-son [34]) лежит построение модели анализируемой ИС — проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных, или внешним сущностям — потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются: внешние сущности, системы (подсистемы), процессы, накопители данных, потоки данных.
Внешние сущности. Внешняя сущность — материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы ана
8*
228
Проектирование информационных систем
лизируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом (рис. 6.37), расположенным как бы над диаграммой и бросающим на нее тень, для того чтобы можно было выделить этот символ среди других обозначений.
ЗАКАЗЧИК
Рис. 6.37. Внешняя сущность
Системы и подсистемы. При построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть декомпозиро
вана на ряд подсистем.
Подсистема (или система) на контекстной диаграмме изображена на рисунке 6.38.
Поле номера 	>-	( 1 \
Поле имени 	>	Подсистема обслуживания клиентов
Поле имени проектировщика
Рис. 6.38. Подсистема
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
•лава 6
ууодходы к проектированию информационных систем
229
Процессы. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов; программа; аппаратно реализованное логическое устройство, и т.д.
Процесс на диаграмме потоков данных изображен на рисунке 6.39.
Поле номера
1.1
Поле имени
Рассчитать остаток средств
Поле физической реализации
Рис. 6.39. Процесс на диаграмме потоков
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже. Использование таких глаголов, как обработать, модернизировать или отредактировать, означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа. Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняют данный процесс.
Накопители данных. Накопитель данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде ящика в картотеке, таблицы в оперативной памяти,
230
Проектирование информационных систем
файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображен на рисунке 6.40.
D 1	Получаемые счета
Рис. 6.40. Накопитель данных
Он идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображений наибольшей информативности для проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно быть увязано с информационной моделью.
Потоки данных. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т.д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рис. 6.41). Каждый поток данных имеет имя, отражающее его содержание.
Рис. 6.41. Поток данных
глава 6
‘ Подходы к проектированию информационных систем
231
зам
Иерархия диаграмм потоков данных (ДПД). Первым шагом при построении иерархии ДПД является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.
Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и, кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть: ► наличие большого количества внешних сущностей (де-
сять и более);
►	распределенная природа системы;
►	многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.
Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на
232
Проектирование информационных систем
самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные организации и коллективы разработчиков.
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и на изолированность объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь, может быть детализирован при помощи ДПД или миниспецификации. При детализации должны выполняться следующие правила: ► правило балансировки —- означает, что при детализации подсистемы или процесса детализирующая диаграмма в 'качестве внешних источников (приемников) данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
►	правило нумерации — означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог их выполнить или разработать соответствующую программу.
Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:
►	наличие у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); возможности описания преобразования данных процессом в виде последовательного алгоритма;
глава 6
Цодходы к проектированию информационных систем
233
►	выполнение процессом единственной логической функции преобразования входной информации в выходную; возможность описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).
При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные); для непрерывных данных — единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования; для дискретных данных — таблица допустимых значений.
После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
Естественно, это весьма грубое описание предметной области. Уточнение модели производится путем детализации необходимых функций на DFD-диаграмме следующего уровня. Так, мы можем разбить функцию «Определение
Проектирование информационных систем потребностей и обеспечение материалами» на подфункции «Определение потребностей», «Поиск поставщиков», «Заключение и анализ договоров на поставку», «Контроль платежей», «Контроль поставок», связанные собственными потоками данных, которые будут представлены на отдельной диаграмме. Детализация модели должна производиться до тех пор, пока она не будет содержать всю информацию, необходимую для построения информационной системы.
Как отмечалось ранее, диаграммы потоков данных строятся по иерархическому принципу. Структура иерархии DFD-диаграмм показана на рисунке 6.42.
Рис. 6.42. Структура иерархии DFD-диаграмм
’лава б
ТГодходы к проектированию информационных систем
235
Контекстная диаграмма верхнего уровня определяет границы модели. Как правило, она имеет звездообразную топологию, в центре которой находится главный процесс, соединенный с приемниками и источниками информации, являющимися внешним окружением моделируемой информационной системы (рис. 6.43).
Для каждого процесса диаграммы первого уровня может быть произведена декомпозиция, которая, в свою очередь, также может быть раскрыта более подробно. Декомпозиция процессов заканчивается, когда достигнута требуемая степень детализации или отображаемые на очередном уровне диаграмм процессы являются элементарными и не могут быть разбиты на более мелкие.
Рис. 6.43. Контекстная диаграмма потоков данных
Проектирование информационных систем
6.2.6.	Спецификации управления
Спецификации управления предназначены для моделирования и документирования аспектов систем, зависящих от времени совершения события или реакции на событие (нажатая клавиша, дата отчетного периода и т.д.) [69]. Они позволяют осуществлять декомпозицию управляющих процессов и описывают отношения между входными и выходными управляющими потоками на управляющем процессе-предке. Для этой цели обычно используются диаграммы переходов состояний (STD).
С помощью STD можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования. Моделируемая система в любой заданный момент времени находится точно в одном из конечного множества состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть четко определены. На рисунке 6.44 представлены символы STD в различных нотациях.
STD состоит из следующих объектов [69].
Состояние — может рассматриваться как условие устойчивости для системы. При ее определенном состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отражать реальную ситуацию, в которой находится система, например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.п.
Начальное состояние — узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет только одно начальное состояние, соответствующее состоянию системы после ее инсталляции, но перед началом реальной обработки, а также любое (конечное) число завершающих состояний.
Переход — определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управ-
глава 6
Подходы к проектированию информационных систем
237
MWJ
Объект	Гейна-Сарсона	Йодана			SAG			SADT
Состояние (processing step)								Нет
	Имя состояния		Имя			Имя		
						—		
Начальное состояние	—	—				1 (•) 1 L _____ J		Нет
Переход	Условие перехода Действие перехода	Условие перехода Действие перехода			6) 1 Имя 1 а)условие по данным 6)условие по времени			Нет
Рис. 6.44. Символы STD в различных нотациях
ляющего потока (сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия (например, СЧЁТЧИК = 999 или КНОПКА НАЖАТА). Следует отметить, что не все события вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние.
Таким образом, условие представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например [69],
«ПАРОЛЬ» = 777,
где ПАРОЛЬ — входной поток.
238
Проектирование информационных систем
Кроме условия, с переходом может быть связано действие или ряд действий, выполняющихся, когда переход имеет место. То есть действие—это операция, которая может иметь место при выполнении перехода. Если действие необходимо для выбора выходного управляющего потока, то имя этого потока должно заключаться в кавычки, например:
«ВВЕДЕННАЯ КАРТА» = TRUE , где ВВЕДЕННАЯ КАРТА — выходной поток.
Кроме того, для спецификации А-, Т-, Е/D-потоков имя запускаемого или переключаемого процесса также должно заключаться в кавычки, например:
А: «ПОЛУЧИТЬ ПАРОЛЬ» -активировать процесс ПОЛУЧИТЬ ПАРОЛЬ.
Фактически условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагировать определенным образом, изменяя свое состояние. При изменении состояния система обычно выполняет одно или более действий (производит вывод, выдает сообщение на терминал, выполняет вычисления). Таким образом, действие представляет собой отклик, посылаемый во внешнее окружение, или вычисление, результаты которого запоминаются в системе (обычно в хранилищах данных на DFD), для того чтобы обеспечить реакцию на некоторые из планируемых в будущем событий.
Условия (по-другому называемые стимулирующими событиями) идентифицируются именем перехода и возбуждают выполнение перехода. Действия или отклики на события соединены с переходами. Начальное состояние на диаграмме должно иметь входной переход, запускаемый потоком из подразумеваемого стартового узла (иногда этот стартовый узел изображается небольшим квадратом и присоединяется к входному состоянию).
Диаграмма переходов состояний для примера банковской задачи приведена на рисунке 6.45. Она содержит состо
E^JlcUBcL 6
ТТ°ДХ°ДЫ к пР°ектированию информационных систем________
яния — ОЖИДАНИЕ и ОБРАБОТКА. Переход из состояния ОЖИДАНИЕ в состояние ОБРАБОТКА осуществляется при условии ввода кредитной карты (ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА). При этом выполняется действие по запуску процесса. Отметим, что для запуска используется A-поток, обеспечивающий непрерывность процесса, т.е. возможность повторного ввода пароля. Переход из состояния ОБРАБОТКА в состояние ОЖИДАНИЕ осуществляется двумя различными способами. При условии трехкратного ввода неверного пароля кредитная карта удаляется из системы, при этом она переходит в режим ожидания очередного клиента. При условии КОРРЕКТНЫЙ ПАРОЛЬ выполняются действия по обеспечению требуемого сервиса и удалению кредитной карты и затем переход в режим ожидания очередного клиента.
При построении STD рекомендуется следовать правилам: ► строить STD на как можно более высоком уровне детализации DFD;
► строить как можно более простые STD;
I
Активизируется каждый раз
«Введенная кредитная карта»
А: «получить пароль»
«Корректный пароль»
Т: обеспечить требуемый сервис, удалить кредитную карту
«Некорректный пароль»
Удалить кредитную карту
ОБРАБОТКА
Рис. 6.45. STD для банковской задачи
240
Проектирование информационных систем
► по возможности детализировать STD;
► использовать те же принципы именования состояний, событий и действий, что и при именовании процессов и потоков.
Применяются два способа построения STD. Первый способ заключается в идентификации всех возможных состояний и дальнейшем исследовании всех небессмысленных связей (переходов) между ними. По второму способу сначала строится начальное состояние, потом следующие за ним и т.д. Результат (оба способа) — предварительная STD, для которой затем осуществляется контроль состоятельности, заключающийся в ответе на следующие вопросы:
► все ли состояния определены и имеют уникальное имя? ► все ли состояния достижимы?
► все ли состояния имеют выход?
► реагирует ли система (для каждого состояния) соответствующим образом на все возможные условия (особенно на не нормальные)?
► все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD?
В ситуации, когда число состояний и (или) переходов велико, для проектирования спецификаций управления используются таблицы и матрицы переходов состояний. Обе эти нотации позволяют зафиксировать ту же самую информацию, что и диаграммы переходов состояний, но в другом формате. В качестве примера таблицы переходов состояний приведена таблица 6.7, соответствующая рассмотренной диаграмме переходов состояний (см. рис. 6.45). Первая колонка таблицы содержит список всех состояний проектируемой системы, во второй колонке каждого состояния приведены все условия, вызывающие переходы в другие состояния, а в третьей колонке — совершаемые при этих переходах действия. Четвертая колонка содержит соответствующие имена состояний, в которые осуществляется переход из рассматриваемого состояния при выполнении определенного условия.
Глава 6	241
ТТОДХОДЫ к проектированию информационных систем_________
Матрица переходов состояний содержит по вертикали перечень состояний системы, а по горизонтали — список условий. Каждый ее элемент содержит список действий, а также имя состояния, в которое осуществляется переход. Используется и другой вариант данной нотации: по вертикали указываются состояния, из которых осуществляется переход, а по горизонтали — состояния, в которые осуществляется переход. При этом каждый элемент матрицы содержит соответствующие условия и действия, обеспечивающие переход из «вертикального» состояния в «горизонтальное».
Таблица 6.7
Пример таблицы переходов состояний
Текущее состояние	Условие	Действие	Следующее состояние
Начальное состояние	Активизируется каждый раз		ОЖИДАНИЕ
ОЖИДАНИЕ	Введенная кредитная карта	Получить пароль	ОБРАБОТКА
ОБРАБОТКА	Некорректный пароль	Удалить кредитную карту	ОЖИДАНИЕ
ОБРАБОТКА	Корректный пароль	Обеспечить требуемый сервис, удалить кредитную карту	ОЖИДАНИЕ
6.2.7. Моделирование данных
Case-метод Баркера. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
242
Проектирование информационных систем
Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD) [35]. С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных.
Первый шаг моделирования — извлечение информации и выделение сущностей.
Сущность (Entity) — реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению (рис. 6.46).
<имя сущности>
Рис. 6.46. Графическое изображение сущности
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
►	уникальным именем, к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
►	одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
►	одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности;
►	любым количеством связей с другими сущностями модели.
Следующим шагом моделирования является идентификация связей.
глава б
г]"|одходы к проектированию информационных систем
243
Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя.
Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что предложение может быть образовано соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка.
Например, связь продавца с контрактом может быть выражена следующим образом:
►	продавец может получить вознаграждение за 1 или более контракт;
►	контракт должен быть инициирован ровно одним продавцом.
Степень связи и обязательность графически изображена на рисунке 6.47.
--------Много	-----------Необязательная
---------- Один	----------- Обязательная
Рис. 6.47. Графическое обозначение связей
Последним шагом моделирования является идентификация атрибутов.
244
Проектирование информационных систем
Атрибут — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет собой тип характеристик или свойств, ассоциированных со множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, пар предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
Атрибут может быть либо обязательным, либо необязательным (рис. 6.48). Обязательность означает, что атрибут н< может принимать неопределенных значений (null values). Атрибут может быть описательным (т.е. обычным дескриптором сущности) и может входить в состав уникального идентификатора (первичного ключа).
<имя сущности> * <атрибут-1>
* — обязательный атрибут
о — необязательный атрибут
Рис. 6.48. Виды атрибутов
Уникальный идентификатор — это атрибут или совокупность атрибутов и(или) связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В случае полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя (рис. 6.49).
глава б
хр|одходы к проектированию информационных систем
245
полная идентификация
идентификация посредством другой сущности
Рис. 6.49. Идентификация экземпляра сущности
Каждый атрибут идентифицируется уникальным именем, выражаемым грамматическим оборотом существительного, описывающим представляемую атрибутом характеристику. Атрибуты изображаются в виде списка имен внутри блока ассоциированной сущности, причем каждый атрибут занимает отдельную строку. Атрибуты, определяющие первичный ключ, размещаются наверху списка и выделяются знаком «#».
Каждая сущность должна обладать хотя бы одним возможным ключом. Возможный ключ сущности — это один или несколько атрибутов, чьи значения однозначно определяют каждый экземпляр сущности. При существовании нескольких возможных ключей один из них обозначается в качестве первичного ключа, а остальные — как альтернативные ключи.
Пример подтипов и супертипов, когда одна сущность является обобщающим понятием для группы подобных сущностей, представлен на рисунке 6.50.
На рисунке 6.51 представлены взаимно исключающие связи, определяющие участие каждого экземпляра сущности только в одной связи из группы взаимно исключающих связей.
Рекурсивная связь предполагает, что сущность может быть связана сама с собой, как показано на рисунке 6.52.
Обозначение неперемещаемой (non-transferrahle) связи, когда экземпляр сущности не может быть перенесен из одного экземпляра связи в другой, показано на рисунке 6.53.
246
Проектирование информационных систем
Рис. 6.50. Подтипы и супертипы
Рис. 6.52. Рекурсивная связь
глава 6
1 Подходы к проектированию информационных систем
247

Рис. 6.53. Неперемещаемая связь
Метод моделирования данных IDEF1. Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме [61]. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEFIX-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).
Сущность в методологии IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 6.54).
Независимые от идентификатора сущности
Имя сущности/Номер сущности	Служащий/44
Зависимые от идентификатора сущности
Имя сущности/Номер сущности	Проектное задание/56
Рис. 6.54. Сущности
Проектирование информационных систем
Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой «/» и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). ВIDEF1X могут быть выражены следующие мощности связей:
►	каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;
►	каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
►	каждый экземпляр сущности-родителя должен иметь не  более одного связанного с ним экземпляра сущности-потомка;
►	каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае — неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком сточкой на конце линии у сущности-потомка. Мощность связи обозначается, как показано на рисунке 6.55 (мощность по умолчанию — N).
Ноли или один
Z
Один и более
Ноли, один и более
Р
N
Рис. 6.55. Мощность связи
’лава 6
у~|одходы к проектированию информационных систем
249
Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией (рис. 6.56). Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).
Сущность-А/1
Сущность-родитель
Сущность-потомок
Рис. 6.56. Идентифицирующая связь
Пунктирная линия изображает неидентифицирующую связь (рис. 6.57). Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рис. 6.58).
Сущности могут иметь такжевиешиие ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний
250
Проектирование информационных систем
Сущность-А/1
Сущность-родитель
Сущность-потомок
Рис. 6.57. Неидентифицирующая связь
Имя_Сущности/Номер_Сущности
имя-атрибута [имя-атрибута]
Атрибуты первичного ключа
[имя-атрибута] [имя-атрибута] [имя-атрибута]
Рис. 6.58. Атрибуты и первичные ключи
Брокер/12
номер брокера
номер отдела (FK)
Рис. 6.59. Пример внешнего ключа — неключевого атрибута
глава 6
* Подходи к проектированию информационных систем
Заявка-на-покупку/2
номер заказа (FK) номер номер товара
Рис. 6.60. Пример внешнего ключа — атрибута первичного ключа
ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках (рис. 6.59-6.60).
6.2.8.	Сравнительный анализ структурных методологий
Главная особенность индустрии современных корпоративных систем состоит в концентрации сложности на начальных этапах анализа требований и проектирования спецификаций системы при относительно невысокой сложности и трудоемкости последующих этапов. Фактически здесь и приходит понимание того, что будет делать будущая система и каким образом она будет функционировать, чтобы удовлетворить предъявленным к ней требованиям. А именно, нечеткость и неполнота системных требований, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и в конечном счете приводят к неуспеху всей работы в целом [62].
В настоящее время известно порядка 90 разновидностей структурного системного анализа, которые могут быть классифицированы по отношению к школам (для моделирования программных систем или систем вообще), по порядку построения модели (декларирующие первичность функционального или информационного моделирования), по типу целевых систем (информационные системы или системы реального времени). Несмотря на такое обилие методов,
252
Проектирование информационных систем
практически во всех из них используются группы средств, рассмотренные ранее.
Кроме этих моделей, на этапе структурного проектирования используются техники структурных карт, предназначенные для описания отношений между модулями (структурные карты Константайна) и внутренней структурой модулей (структурные карты Джексона).
Поскольку в настоящее время практически нет альтернативы ERD и STD для соответственно информационного и поведенческого моделирования, интерес представляет сравнительный анализ средств функционального моделирования, а именно DFD- и SADT-диаграмм.
Сравнительный анализ этих двух разновидностей методологий проведем по следующим параметрам [62]:
►	адекватность средств рассматриваемой проблеме;
►	согласованность с другими средствами структурного анализа;
►	интеграция с последующими этапами разработки (и прежде всего с этапом проектирования).
Адекватность. Выбор той или иной структурной методологии напрямую зависит от задач, для решения которых создается модель. Традиционно выделяются две разновидности таких задач: задачи, связанные с реорганизацией деятельности предприятий (бизнес-консалтинг), и задачи, связанные с анализом требований к системам и проектированием корпоративных систем (информационно-технологический консалтинг). Предметом бизнес-консалтинга являются организационные системы (точнее, функционирование или деятельность таких систем). Для моделирования таких систем традиционно используется методология SADT (точнее, ее подмножество IDEF0). Однако статическая SADT-модель не обеспечивает полного решения задач бизнес-консалтинга, необходимо иметь возможность исследования динамических характеристик бизнес-процессов. Одним из решений является использование методологии и средств динамического моделирования, основанных, например, на цветных
глава б
* Подходы к проектированию информационных систем
253
-ШШЕ
(раскрашенных) сетях Петри CPN (Color Petri Nets). Фактически SADT и CPN служат компонентами интегрированной методологии бизнес-консалтинга: SADT-диаграммы автоматически преобразуются в прообраз CPN-модели, которая затем дорабатывается и исполняется в различных режимах, чтобы получить соответствующие оценки.
Следует отметить, что не существует принципиальных ограничений в использовании DFD в качестве средства построения статических моделей деятельностей. Более того, в настоящий момент доступен ряд методологий и продуктов динамического моделирования (INCOME Mobile, CPN-AMI и др.), базирующихся на сетях Петри различного вида и интегрируемых с DFD-моделью, которые позволяют успешно решать задачи бизнес-консалтинга.
Методология SADT успешно работает только для реорганизации хорошо специфицированных и стандартизованных западных бизнес-процессов, поэтому она и принята в некоторых организациях на Западе в качестве типовой. Например, в Министерстве обороны США десятки лет существуют четкие должностные инструкции и методики, которые жестко регламентируют деятельность, делают ее высокотехнологичной и ориентированной на бизнес-процесс. В российской действительности с ее слабой типизацией бизнес-процессов, их стихийным появлением и развитием разумнее ориентироваться на методологию организации и/или реорганизации потоков информации и отношений; для таких задач методологии, основанные на потоковых диаграммах, не просто допустимы, а являются единственно возможными.
Если же речь идет об информационно-технологическом консалтинге, где методологии применяются к системам обработки информации, а не к системам вообще, как это предполагается в SADT, то здесь DFD вне конкуренции. Практически любой класс систем успешно моделируется при помощи DFD-ориентированных методов: в этом случае вместо реальных объектов рассматриваются отношения,
254
Проектирование информационных систем
описывающие свойства этих объектов и правила их поведения. Примерами таких систем служат системы документооборота, управления и другие системы, богатые разнообразными отношениями.	।
SADT-диаграммы значительно менее выразительны и . удобны для моделирования систем обработки информации. , Так, дуги в SADT жестко типизированы (вход, выход, управление, исполнитель). В то же время применительно к системам обработки информации стирается смысловое различие между входами-выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы и управления являются потоками данных и(или) управления и правилами их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.
 Более того, в SADT вообще отсутствуют выразительные средства для моделирования особенностей систем обработки информаци. г DFD с самого начала создавались как средство проектирования информационных систем (тогда как SADT — как средство проектирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
Наличие миниспецификаций DFD-процессов нижнего уровня позволяет преодолеть логическую незавершенность j SADT (обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и построить полную функциональную спецификацию разрабатываемой системы. Это позволит расширить возможности применения созданной модели (например, ее можно будет использовать для автоматизированного и быстрого обучения новых работников конкретному направлению деятельности).
Ограничения SADT, запрещающие использовать более 5-7 блоков на диаграмме, в ряде случаев вынуждают искус
улава б
А |~|одходы к проектированию информационных систем
^55
ственно детализировать систему, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и как следствие ведет к неадекватности модели реальной картине. В качестве примера здесь достаточно рассмотреть моделирование работы с банковскими вкладами физических лиц. Типов таких вкладов имеется несколько десятков, все они различаются лишь механизмом начисления процентов, при этом соответствующие модели на входе/выходе имеют одни и те же документы: приходный ордер, расходный ордер, сберкнижка. Такую деятельность целесообразно моделировать одной диаграммой, а не строить искусственную иерархию.
Согласованность. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами информационного и событийного (временного) моделирования. Согласование SADT-модели с ERD и (или) STD практически невозможно или носит тривиальный характер. В свою очередь, DFD, ERD и STD взаимно дополняют друг друга и по сути являются согласованными представлениями различных аспектов одной и той же модели. Таблица 6.8 отражает возможность такой интеграции для DFD- и SADT-моделей.
Таблица 6.8
Согласование моделей
Функциональные модели	Информационные модели		
	ERD	STD	Структурные карты
DFD	+	+	+
SADT	+		-
Отметим, что интеграция DFD-STD осуществляется за счет расширения классической DFD специальными средствами проектирования систем реального времени (управляющими процессами, потоками, хранилищами данных) и STD является детализацией управляющего процесса, согласованной по управляющим потокам и хранилищам.
^56 Проектирование информационных систем
Интеграция DFD-ERD осуществляется с использованием отсутствующего в SADT объекта — хранилища данных, структура которого описывается с помощью ERD и согласуется по соответствующим потокам и другим хранилищам на DFD.
Интеграция с последующими этапами. Важная характеристика методологии — ее совместимость с последующими этапами применения результатов анализа (и прежде всего, с этапом проектирования, непосредственно следующим за анализом и опирающимся на его результаты).
DFD могут быть легко преобразованы в модели проектирования (структурные карты) — это близкие модели. Более того, известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных •видов, что обеспечивает логичный и безболезненный переход от этапа анализа требований к проектированию системы. С другой стороны, авторам неизвестны формальные методы преобразования SADT-диаграмм в проектные решения системы обработки информации.
В заключение необходимо отметить, что методология SADT (точнее, ее подмножество IDEF0) является в настоящее время одной из наиболее известных и популярных в России — можно только приветствовать ориентацию отечественных специалистов на современные технологии. По материалам наиболее авторитетной в данной области на Западе аналитической группы CASE Consulting Group, методология SADT поддерживается лишь 10% существующих CASE-пакетов, оставшиеся 90% поддерживают методологии, базирующиеся на различных разновидностях диаграмм потоков данных. Представляется очевидным, что соотношение такого же порядка справедливо и для цифр распространенности перечисленных методологий на практике. Косвенно это подтверждается и следующими двумя фактами:
►	разработкой стандарта IDEF3 (функциональное моделирование с использованием диаграмм потоков данных);
глава 6
* Подходы к проектированию информационных систем
257
►	включением средств работы с DFD в пакеты, ориентированные на SADT (например, один из лидеров мирового рынка CASE-средств фирма Logic Works, осуществившая соответствующие расширения пакета BPwin).
Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в методах и средствах функционального моделирования. Тем не менее рассмотренные разновидности структурного анализа по сути — два языка для передачи понимания. И одним из основных критериев выбора является следующий: насколько хорошо каждым из этих языков владеет консультант или аналитик, насколько грамотно он может на этом языке выражать свои мысли [62].
6.3. Объектно-ориентированные методологии
Жизненный цикл ИС в объектно-ориентированном подходе разбит на циклы, результатом каждого из которых является собственная версия программной системы (рис. 6.61) [63]. Каждый цикл состоит из четырех фаз, таких как: ► начало (Inception);
►	совершенствование (Elaboration);
►	построение (Construction);
►	переход (Transition).
Время
Действия
Рис. 6.61. Модель жизненного цикла UML
9. зак. Ю35
258
Проектирование информационных систем
На рисунке 6.62 представлены основные модели UML в виде прямоугольников.
Рис. 6.62. Основные модели UML
В настоящее время объектно-ориентированный подход является одним из быстро развивающихся направлений в проектировании систем. Примером могут являться объектно-ориентированный анализ — методология разработки систем, предложенная Йорденом, объектно-ориентированное проектирование, объектно-ориентированное программирование, реализованное в многочисленных компиляторах C++, Object Pascal, Borland Pascal, Smalltalk.
Несмотря на различия, существующие в конкретных вариантах объектно-ориентированного подхода, все эти варианты объединяются несколькими основополагающими принципами. Это [2]:
►	инкапсуляция — свойство, при котором объекты содержат описание атрибутов и действий одновременно;
►	наследование — метод определения объектов, при котором производные объекты (потомки) наследуют свойства (атрибуты и действия) от своих родителей;
►	полиморфизм—свойство объектов, при котором действия с одинаковыми именами вызывают различное поведение для различных объектов.
"лава б
ууодходы к проектированию информационных систем
259
Основное преимущество объектно-ориентированного подхода состоит в том, что задача решается новым способом. Вместо формирования набора процедур, предназначенных для решения конкретной задачи, формируется набор объектов, свойственных данной предметной области. Если такой набор составляется грамотно, то не только может быть решена конкретная задача, но и потенциально закладывается фундамент для решения всех задач в данной предметной области. Конечно, при структурном программировании такой подход стихийно складывался при разработке программ в виде библиотек подпрограмм по темам. Но объектно-ориентированный подход дает новые механизмы, перечисленные выше (3 основных свойства объектно-ориентированного подхода), которые позволяют создавать действительно не зависимые от задачи описания предметной области в виде набора объектов.
6.3.1.	Объектно-ориентированный анализ
Методология объектно-ориентированного анализа (ООА) предложена Йорденом для проектирования больших систем. Данная методология позволяет более адекватно отобразить предметную область в системе и обеспечить более надежный и перестраиваемый проект за счет основных свойств: инкапсуляции и наследования, полиморфизма.
ООА состоит из пяти главных шагов [63]:
►	определения предметной области;
►	определения объектов предметной области;
►	определения структуры объектов за счет создания отношений «состоит из» и «является»;
►	определения атрибутов объектов;
►	определения сервиса объектов (методов поведения) и взаимодействий за счет посылки сообщений между объектами.
Соответственно ООА-модель состоит из пяти основных компонентов: схемы предметной области, схемы объектов, схемы структуры, схемы атрибутов, схемы методов [63].
9*
260
Проектирование информационных систем
Схема предметной области. Схема предметной области содержит описание ее отдельных частей и взаимодействий между ними. Такая схема позволяет разделить предметную область на такие части, в которых должны содержаться однотипные объекты. Разделение предоставляет возможность разделения задачи на мелкие, относительно независимые части. Это упрощает работу и позволяет проводить одновременное проектирование нескольким разработчикам. На рисунке 6.63 представлена схема предметной области контроля дорожного движения (примеры, связанные с дорожным движением).
Каждая часть предметной области пронумерована, и далее на каждой схеме номерами обозначаются части предметной области, к которым принадлежат те или иные объекты.
Рис. 6.63. Схема предметной области управления дорожным движением
Между частями предметной области устанавливаются связи, которые обозначают возможность взаимодействия объектов из этих частей друг с другом. В частности, на рисунке 6.63 объекты, относящиеся к пользователям, не могут общаться непосредственно с объектами персонала.
Схема объектов. Каждому объекту на схемах соответствует графический элемент, показанный на рисунке 6.64. В верхней части указывается имя, в средней — атрибуты, в нижней — методы.
Схема объектов содержит их простое перечисление, с обозначением того, к какой части предметной области
Глава 6
Подходы к проектированию информационных систем
261
Имя
Атрибуты		
	Методы	—Л
Рис. 6.64. Графическое обозначение объекта
объект относится. Перечисление объектов является вторым по порядку действием, и при этом достаточно ответственным. На этой схеме не предполагается перечисления всех объектов, относящихся к данной части предметной области. Но для каждой части должны быть обязательно перечислены все базовые объекты, от которых в дальнейшем будет проводиться наследование. Выбор набора базовых объектов во многом определяет структуру и качество всего проекта. Неудачный выбор может перечеркнуть все достоинства объектно-ориентированного подхода. Ниже представлен пример выбора базовых объектов (рис. 6.65).
Организация
Служащий
-------------,2
Владелец
	1 3| 1 1 1 1 1	4
Событие		Транспортное средство
		
		»	/
Рис. 6.65. Схема объектов управления дорожным движением
Схема структуры. Описание структуры предполагает определение отношений наследования двух видов. Отношения вида «является» обозначаются простыми соединительными линиями. Отношения вида «состоит из» обозначаются линиями со стрелками. На рисунке 6.66 изображена схема структуры, где пассажир, мотоцикл и автомобиль являются
262
Проектирование информационных систем
видами транспортного средства, в то время как организация состоит из служащих.
Организация	Служащий
Рис. 6.66. Схеме структуры управления дорожным движением
Схема атрибутов. Графически схема атрибутов повторяет схему структуры, но для каждого объекта указываются его атрибуты.
Для данной задачи и данного набора объектов можно было бы определить такие атрибуты:
►	организация (наименование, адрес, руководитель, телефон);
►	владелец (имя, адрес, телефон);
►	событие (дата, время);
►	регистрация (дата, время, начало, конец).
Схема методов. Графически схема методов повторяет схему атрибутов, но для каждого объекта указываются его методы поведения.
6.3.2. Универсальный язык моделирования
UML — это универсальный язык моделирования [51], разработанный в фирме Rational Software при участии других партнеров. Ниже рассматривается незначительно сокращенный вариант графического синтаксиса языка UML [63].
глава 6
Подходы к проектированию информационных систем
263
Пакеты как средство работы с большими проектами. Пакеты представляют собой универсальное средство для группирования элементов моделей. Пакеты могут вкладываться друг в друга и могут содержать пакеты или элементы моделей. Проект в целом может рассматриваться как один пакет верхнего уровня, в который вложены все остальные составляющие части проекта. Пакет может иметь два графических обозначения (рис. 6.67 6.68) — полное и сокращенное.
Рис. б.67. Обозначение
Рис. 6.68. Полное обозначение
пакета
пакета
В рамке «содержимое пакета» находится графическое изображение, представляющее другие пакеты или модели. Отношения между пакетами отображаются линиями и обозначают отношения между элементами пакета. Если разные элементы двух пакетов имеют разные отношения друг с другом, то нет четких рекомендаций, какие отношения показывать между самими пакетами. Таким образом, наличие отношения X между двумя пакетами говорит только о том, что в пакетах присутствуют элементы, связанные между собой этим отношением.
Пакеты обеспечивают более высокий уровень абстракции по сравнению с классами. Типичный большой проект содержит несколько иерархий наследования для классов. Возьмем в качестве примера многооконный графический редактор диаграмм. Набор пакетов для этой задачи можно было бы представить, как показано на рисунке 6.69.
Пакет «геометрические фигуры» содержит определение иерархии наследования для классов всех геометрических
264
Проектирование информационных систем
Рис. 6.69. Набор пакетов проекта «графический редактор»
фигур. Эти классы должны быть независимы от контекста, в который они включаются (например, диаграмма), а также от устройства, на котором они отображаются. Базовый класс этого пакета может выглядеть так, как показано на рисунке 6.69.
Пакет «графические диаграммы» содержит определение всех классов для диаграмм. Например, все диаграммы, рассматриваемые здесь, могут быть представлены в этом пакете. Диаграмма не должна зависеть от способа создания (например, она может быть создана не в диаграммере, а автоматически). Тем более диаграмма не должна зависеть от устройства отображения.
Пакет «диаграммер» отвечает за отображение диаграмм в некотором контексте и за ввод этих диаграмм с помощью некоторых виртуальных команд пользователя, независимых от контекста отображения.
глава 6
*|~[одходы к проектированию информационных систем
265
Пакет «устройство отображения диаграмм» содержит классы, описывающие однооконный интерфейс конкретного диаграммера и способ создания виртуальных команд пользователя с помощью конкретных устройств ввода (например, мыши и клавиатуры).
Пакет «ЮЕ» содержит средства, необходимые для включения одного диаграммера в интегрированную среду разработки с меню, карточками диалога, настройками параметров среды, многооконным интерфейсом.
Достоинства использования пакетов: декомпозиция задачи упрощает понимание каждой части в отдельности и задачи в целом, каждый пакет можно поручить отдельному разработчику за счет относительной независимости пакетов.
Все проектирование объектно-ориентированной системы должно начинаться именно с проектирования пакетов. Они позволят избежать лишних ошибок, проект станет более управляемым и обозримым.
Можно сформулировать следующие рекомендации по составлению пакетов и классов в них.
1.	Каждый пакет должен быть максимально независимым от других пакетов, все связи должны быть локализованы и сведены к минимуму, идеальный случай — связь через один класс, из которого используется один метод поведения.
2.	Структура пакетов должна отражать структуру предметной области. Это обеспечит возможность проектирования классов в четком соответствии с предметной областью и в дальнейшем позволит легко модифицировать систему для других задач в рамках данной предметной области.
3.	Каждый пакет должен содержать классы, однотипные с точки зрения предметной области.
4.	Желательно, чтобы иерархия наследования начиналась с одного базового объекта в каждом пакете, допустимо два, три, но не более.
5.	Базовый объект в каждом пакете—это следующий принципиальный момент после составления самих пакетов;
Проектирование информационных систем
он должен отражать наиболее базовые свойства той части предметной области, к которой относится пакет.
Диаграммы классов и объектов. Диаграмма классов представляет собой набор классов, типов данных, интерфейсов и отношений между ними.
Диаграмма объектов представляет собой набор экземпляров классов и типов данных; наиболее типичным ее использованием является представление примеров структур данных. Поскольку диаграмма классов может включать в свой состав объекты, то отдельного вида диаграммы объектов не существует, это фактически подмножество диаграммы классов.
Классы. Графическое представление класса — это прямоугольник, который может быть разделен на три части (рис. 6.70).
Имя класса
Атрибуты
Методы
Рис. 6.70. Пример изображения класса
Верхняя часть прямоугольника содержит имя класса, средняя — атрибуты, нижняя — методы поведения (операции). Атрибуты или методы при изображении класса могут быть скрыты, для того чтобы подчеркнуть другие аспекты диаграммы классов, например, состав классов и отношения между ними. В этом случае изображение класса принимает простейший вид прямоугольника с именем класса.
Каждый атрибут представляется в следующем виде: видимость имя : тип = начальное значение.
Перед именем может следовать знак, обозначающий видимость атрибута для других классов:
►	(+) общедоступный (public) атрибут,
лава б
Подходы к проектированию информационных систем
267
►	(#) защищенный (protected) атрибут,
►	(-) закрытый (private) атрибут.
Каждый метод представляется в следующем виде: видимость имя (список параметров) : тип возвращаемого значения.
Описатель видимости имеет те же значения, что и для атрибута.
Список параметров представляет собой перечень описателей параметров, разделенных запятой. Описатель каждого параметра имеет вид:
вид имя : тип = значение по умолчанию, вид параметра может быть следующим:
►	in — входной параметр;
►	out — выходной параметр;
►	inout — входной и выходной параметры;
Текст реализации операции может быть сопоставлен в качестве примечания для каждого метода.
Пример изображения класса представлен на рисунке 6.71.
Геометрическая фигура
+ X - координата:int
+ Y - координата : int
+ Видимость .	: bool
+ Стереть ()
+ Нарисовать ()
+ Переместить (in X: int in Y: int)
Рис. 6.71. Пример изображения класса «геометрическая фигура»
Интерфейсы. Интерфейсы предназначены для спецификации внешнего вида операций для классов.
Отношения между классами. Двуместная связь (Binary Association) — это отношение между двумя классами, вклю
268
Проектирование информационных систем
чая возможность рефлексивного отношения класса с самим собой. Изображается сплошной линией, соединяющей два класса. Линия может иметь один или несколько соединенных сегментов. Конец линии, соединенный с классом, называется ролью. Для связи может быть задано имя, которое представляет отношение в целом, оно не должно располагаться вблизи краев линии, чтобы не возникало конфликтов с наименованием ролей.
В следующем примере указано отношение между двумя классами: «линия» и «точка» (рис. 6.72). Отношение имеет имя «содержать», роли для каждого из классов называются соответственно «включает» и «входит в».
Линия	Содержать >	Точка
	Включает	Входит в	
Рис. 6.72. Пример отношения
Для каждой роли может быть определена дополнительная информация следующего вида: множественность, сортировка, квалификатор, имя роли, спецификация интерфейса, изменяемость, видимость.
Множественность роли определяет количество экземпляров классов, участвующих в отношении. Множественность определяется в виде одного или нескольких диапазонов:
►	нижняя граница ... верхняя граница;
►	в качестве нижней или верхней границы может быть задан символ *, обозначающий произвольное количество. Может использоваться перечисление диапазонов через запятую.
Пример допустимых вариантов: 1, I..*, *, 0 .
Сортировка роли определяет тип упорядочения элементов для множественности больше чем 1. Возможные значения: упорядочены, неупорядочены.
Символ агрегации — это ромб, находящийся между линией и классом. Символ агрегации обозначает, что класс,
глава б
1 Подходы к проектированию информационных систем
269
вблизи которого изображен данный знак, является накопителем для класса, находящегося на другом конце связи. Если ромб залит черным цветом, то это обозначает усиленный вариант агрегации, называемый «композиция». Символ агрегации может находиться только на одном конце связи (рис. 6.73).
Рис. 6.73. Пример агрегации
Квалификатор — это один или несколько атрибутов, значения которых обеспечивают идентификацию экземпляров класса по данной связи. Множественность, указанная для роли, при наличии квалификатора указывает на количество экземпляров класса, выбираемых одним значением квалификатора. Наиболее часто используются следующие значения для множественности:
►	0.. 1 — уникальный экземпляр может быть выбран, но не обязательно будет выбран;
►	1 — каждое значение квалификатора однозначно выбирает экземпляр класса;
►	* — одному значению квалификатора соответствует множество экземпляров.
Графически квалификатор обозначается как прямоугольник, в котором указаны имена атрибутов, являющиеся квалификаторами. Прямоугольник располагается между линией связи и классом. Ниже представлен пример, в котором классы «линия» и «точка» связаны отношением «входить в» (рис. 6.74). Квалификатором является координата точки. Множественность со стороны класса «точка» равна 0.. 1, это обозначает, что каждая точка линии должна иметь уникальные координаты. Множественность со стороны класса «линия» равна *, это обозначает, что разные линии могут иметь общие точки.
270
Проектирование информационных систем
Рис. 6.74. Пример использования квалификатора
Имя роли, произвольный идентификатор, конкретизирующий роль связи для одного из классов, указываются на линии вблизи класса (рис. 6.75).
	Роль объекта «Линия» — «Включать точки»	
Линия		Точка
		
Роль объекта «Точка» — «Входить в линию» или «Быть включенной»
Рис. 6.75. Пример обозначения роли
Класс, описывающий связь (Associaton class). Связь между классами также может обладать свойствами, присущими некоему классу (рис. 6.76). С целью определения таких свойств для связи может быть задан ассоциированный с ней класс. Связь и ассоциированный класс представляют одно целое.
Ассоциированный класс изображается обычным образом в виде прямоугольника и связывается с отношением, для которого он задан, штриховой линией. Имена связи (отношения) и описывающего его класса должны совпадать.
Рис. 6.76. Пример класса, описывающего связь
'лава 6
Подходы к проектированию информационных систем
N-местная связь (N-ry Association) — это связь между тремя и более классами. Эта связь графически обозначается ромбом, к которому подходят линии, соединяющие ромб с классами. Имя отношения указывается внутри или вблизи ромба. Класс, описывающий связь, присоединяется к ромбу с помощью штрихпунктирной линии. Пример такой связи представлен на рисунке 6.77.
Рис. 6.77. Пример многоместной связи
Для подобного вида связей не может быть применена агрегация.
Композиция, Сборка. Композиция (Composition) описывает включение классов друг в друга. Один из вариантов представления композиции определен при описании двуместной связи (с помощью закрашенных ромбов на конце линии). Альтернативная графическая форма для представления композиции — это размещение изображения включаемых классов внутри изображения включающего класса.
Композиция является усиленной формой агрегации и может быть рассмотрена только на основе двуместной связи. В случае композиции объект-владелец и его составные части не могут существовать раздельно. Компоненты, участвующие в композиции, не могут одновременно иметь нескольких
272
Проектирование информационных систем
владельцев. Все компоненты изменяются вместе с владельцем. Графически композиция может быть представлена в виде дерева, корнем которого является составной объект, а листьями — его компоненты.
Отличие сборки от композиции может быть продемонстрировано на следующем примере:
►	сборка — элементы входят в хэш-таблицу и образуют ее. Они могут существовать друг без друга. Таблица имеет собственную структуру и логику поведения. Она может не содержать ни одного элемента. В то же время элементы могут существовать изолированно от таблицы. Таким образом, элементы собираются внутри таблицы и наполняют ее;
►	композиция — здание образуется набором внутренних помещений. Но они не могут существовать друг без друга й вне друг друга.
Соответственно, такие отличия оказывают влияние на удаление объектов. Для композиции должно быть обеспечено удаление всех составных частей после удаления объемлющего объекта. Каждая часть также должна быть удалена в случае ее исключения из составного объекта.
Обобщение (Generalization) — это отношение между общим и уточняющим элементом (рис. 6.78). Обобщение показывается как сплошная линия с треугольником на конце. Треугольник располагается у общего элемента.
Рис. 6.78. Пример обобщения
глава 6
П0ДХОДЫ к проектированию информационных систем
^73
Рис. 6.79. Пример зависимости
Зависимость (Dependency) — обозначает любую зависимость между любыми элементами модели (рис. 6.79). Зависимость изображается штриховой линией с направлением. Элемент, для которого линия является выходной, зависим от элемента на другом конце линии. На линии может быть указано имя отношения.
Подобная связь никак не регламентирует вид отношений между объектами, а указывает лишь на то, что зависимый класс использует какие-то особенности реализации иного класса.
Все отношения между классами сведены в таблице 6.9.
Пример диаграммы классов представлен на рисунке 6.80.
Диаграммы использования (use case diagram) предназначены для отображения внешнего функционирования проектируемой системы и ее взаимодействия с внешним миром пользователями. Основой подхода являются так называемые блоки использования (use case), которые представляют собой некоторый набор функций системы, объединяемых в единое целое, с точки зрения пользователя. Один блок использования необязательно представляет собой одну часть системы или даже единую группу функций — он представляет собой именно понимание пользователем поведения системы.
Tib
Проектирование информационных систем
с
с«
S
S с«
ф S
к S
S ф а © S
О
•Гуурдходы к проектированию инфс|РмаЦИОННЬ1Х сметем
275
। Отображаться
Диаграммер
Область вывода
Отображение Редактирование Сохранение в файл Ввод файла
Рис. 6.80. Диаграмма класс08 для предметной области графического диаграммера
Диаграммы использования являются широко применяемыми в различных технологиях проектирования. Их главная задача — спецификация требований к системе на начальных этапах проектирования, когда решаются наиболее общие задачи предназначения разрабатываемой системы. Распространение диаграмм использования привело, в частности, и к тому, что они имеют широкое и иногда различное толкование.
Диаграмма включает в сеРя следующие элементы:
► внешние пользователи (act°rs) воздействия, которые передают или получают информацию для системы, т.е. физические объекты разной природы (от людей и механизмов до программных систем); один физический
Проектирование информационных систем
объект может описываться несколькими пользователями, если он взаимодействует с разными функциями;
►	блоки использования (use case) —.группы функций системы, которые объединяются в единое целое для внешнего пользователя;
►	связи между блоками использования и связи между блоками использования и внешними пользователями.
Выделены следующие виды связей:
►	взаимодействие (только между пользователем и блоком использования);
►	расширение — данный вид отношения от блока А к блоку В обозначает, что исполнение блока В может дополняться исполнением некоторых функций блока А;
►	использование — данный вид отношения от блока А к блоку В обозначает, что исполнение А также включает исполнение блока В.
Графически блоки использования обозначаются эллипсами с указанием имени внутри эллипса или рядом с ним. Внешние пользователи графически обозначаются как прямоугольники с табулятором «пользователь» или в виде схематичной фигурки человека с именем под ней.
Графическое обозначение для связей следующее:
►	взаимодействие — сплошная линия;
►	расширение — линия со стрелкой, помеченная словом «extends», от блока, предоставляющего расширение, к базовому блоку;
►	использование — линия со стрелкой, помеченная словом «uses», от использующего блока к используемому блоку.
Все блоки использования объединяются на рисунке в единый прямоугольник, очерчивающий рамки проектируемой системы.
Примером диаграммы может являться диаграмма, представленная на рисунке 6.81, демонстрирующая структуру системы учета клиентов Internet для Internet Service Provider (ISP).
глава 6
Подходы к проектированию информационных систем
Внешними пользователями (actor) являются:
—	«клиент» — физическое или юридическое лицо, заказывающее услуги по подключению к сети Internet;
—	«оператор» — сотрудник ISP, осуществляющий работу с клиентом и системой учета;
—	«бухгалтер» — бухгалтер ISP;
—	«системный администратор» — сотрудник ISP, обеспечивающий системное администрирование системы учета
клиентов.
Проектирование информационных систем
278
к
Основными задачами «клиента» являются:
►	заключение договора о предоставлении услуг сети Internet;
►	выбор перечня услуг для работы в сети (например, создание почтового ящика, создание web-сервера, регистрация и обслуживание домена);
►	оплата предоставленных услуг или авансовый платеж;
►	получение необходимых документов (договор, счет, счет-фактура, акт о выполненных работах);
►	получение статистических отчетов (состояние счета, сеансы работы, начисления за услуги);
►	подключение и работа в режиме on-line.
Основными задачами «бухгалтера» являются: получение отчетов о поступлении платежей.
Основными задачами «системного администратора» являются: удаление сведений о клиенте, создание нового вида услуг.
Диаграммы использования являются весьма популярными и включаются в различные методики проектирования благодаря своим достоинствам: формулировке требований, ориентированной на пользователя (т.е. система заведомо проектируется так, как ее будет видеть пользователь), простоте модели, ее ориентированности на неподготовленного пользователя, возможности описания больших проектов за счет декомпозиции на крупные блоки использования, которых в любой системе не так много, как структурных единиц самой системы.
Рекомендуемая последовательность формулирования требований к системе с помощью диаграмм использования: ► определить перечень главных пользователей (внешних входов-выходов) системы, что целесообразно сделать методом мозгового штурма с участием большого количества людей, начиная от руководителя разработки и кончая программистами;
►	определить методику участия внешних пользователей в проекте (методы привлечения их к составлению требований);
глава. 6	*?7Q
Д-Цодходы к проектированию информационных систем_
►	определить главные цели пользователей (что они хотят сделать с помощью системы) и задачи, которые нужно решить для достижения этих целей;
►	составить диаграмму использования, в которой каждой задаче каждого пользователя сопоставить блок использования; соединить блоки использования и блоки внешних пользователей, ответственных за данную задачу;
►	проверить каждый блок использования какой-либо количественной метрикой, например, можно использовать оценку времени выполнения задачи или объема ресурсов, необходимого для ее решения; на этой стадии полезно составить прототип программного средства, для оценки реализуемости проекта (но ни в коем случае не интерфейса пользователя).
Все перечисленные действия не должны приводить к слишком сложной модели и занимать слишком много времени. Далее можно перечислить рекомендации по составлению диаграмм использования: диаграммы должны быть простыми и понятными любому пользователю; автор проекта и идеи системы должен участвовать в спецификации требований; каждый участник проекта должен понимать конечную цель и предназначение разрабатываемой системы; блоки использования должны быть основаны на их целях (а не на структуре, например,); не следует использовать слишком много отношений extends и uses — они усложняют понимание диаграммы; блоки использования не должны отражать вопросов пользовательского интерфейса; необходимо вовремя остановить внешних пользователей, так как они могут хотеть от системы слишком много и она будет нереализуема.
Диаграмма последовательностей (Sequence diagram) предназначена для отображения временных зависимостей, возникающих в процессе общения между объектами. Диаграмма строится как график и имеет два измерения. По вертикали откладывается время, которое может быть схематичным или может иметь реальный масштаб. По горизонтали
280
Проектирование информационных систем
отображаются объекты. Она состоит из следующих элементов:
►	объекта — прямоугольник с записанным в нем именем объекта;
►	линии жизни объекта — штрихпунктирная линия, выходящая из объекта и расположенная вдоль оси времени (обозначает время жизни объекта);
►	активации — тонкий вертикальный прямоугольник, обозначающий период активной жизни объекта, расположен либо вдоль оси времени объекта, либо выходит из объекта;
►	вызова метода поведения объекта (сообщение) — стрелка между активациями объектов с именем действия (направление стрелки задает направление передачи данных);
►	текстовых меток (отметки времени, описание действий и т.п.).
На рисунке 6.82 рассмотрена диаграмма для установки PPP-соединения через модем между сервером и клиентом. Такая задача выполняется, например, при подключении персонального компьютера к Internet через модем. На рисунке изображены четыре объекта: «PPP-соединение», «Номеронабиратель», «Телефонная линия», «Сервер». В рамках данной задачи объекты «Номеронабиратель» и «Телефонная линия» начинают свою жизнь сразу с активации, тогда как другие объекты имеют неактивную линию жизни (см. штрих-пунктир). Активация объектов «PPP-соединение» и «Сервер» начинается только с получения соответствующего сообщения. Объект «PPP-соединение» создается только после получения соответствующего сообщения. В этом случае стрелка с сообщением соединяется не с активацией, а непосредственно с объектом. Черный крест в конце активации обозначает, что объект перестает существовать в рамках данной задачи.
Линии жизни объектов могут разветвляться для обозначения альтернативных вариантов поведения. На альтернативных линиях жизни могут располагаться различные ак-
удава б
х Подходы к проектированию информационных систем
281
Рис. 6.82. Пример диаграммы последовательностей
тивации. Альтернативная линия жизни показана для объекта «Номеронабиратель», она начинается с получения сигнала «занято» от телефонной линии.
Линии, обозначающие передачу сообщений (вызовы методов), помечаются именем выполняемого действия или передаваемым сообщением. Могут быть отображены фактические параметры, передаваемые в вызове, или результат, возвращаемый после вызова.
282
Проектирование информационных систем
Диаграмма сотрудничества (Collaboration diagram) предназначена для описания методов взаимодействия между объектами. Для пояснения смысла и назначения диаграммы необходимо ввести такое понятие, как сотрудничество.
Сотрудничество представляет собой набор объектов, которые взаимодействуют друг с другом (вызывают методы поведения друг друга) для достижения конкретной группы целей. В данном случае в процессе проектирования необходимо сосредоточиться только на тех объектах и их методах поведения, которые необходимы для достижения определенной цели или единой группы целей. Сотрудничество может быть сопоставлено операции, блоку использования (из диаграммы использования) или классу для описания его статической структуры. Важно то, что сотрудничество не предназначено для описания поведения объектов, для этого могут быть использованы диаграммы последовательностей или диаграммы действий. Поведение некоторой части проекта может быть рассмотрено в двух аспектах: статические аспекты, определяющие поведение, и динамические аспекты реализации этого поведения. Диаграмма сотрудничества описывает именно статическую структуру объектов, участвующих в реализации поведения.
Сотрудничество может быть параметрическим, и в этом случае оно представляет собой шаблон, который может использоваться в различных частях проекта. Параметрами могут являться участники сотрудничества.
Диаграмма сотрудничества включает в себя объекты и отношения между ними, заключающиеся в вызове методов друг друга. Некоторые объекты появляются только в рамках реализации сотрудничества, они помечаются специальным словом «new» (новый). Те объекты, которые уничтожаются во время реализации сотрудничества, помечаются специальным словом «destroy» (уничтожить).
На диаграмме могут быть показаны связи между объектами, представляющие параметры процедур, локальные переменные, self-ссылки (ссылки на сам объект).
Глава 6
АТТ0ДХ0ДЫ к проектированию информационных систем_____
В случае вызова метода одного объекта другим объектом рядом со связью указывается имя метода и задается направление взаимодействия (чей метод вызывается). Так как диаграммы сотрудничества очень часто используются для построения процедурных спецификаций (рис. 6.83), допускается указывать последовательности вызовов методов путем их нумерации.
Создать прямоугольник (коорд.)	п
'	«Параметр»
Рис. 6.83. Пример диаграммы сотрудничества
Диаграмма состояний (State chart diagram) представляет собой конечный автомат и показывает последовательность состояний объекта, через которые он проходит во время своего существования под воздействием внешних событий. Диаграмма представляет собой набор состояний и переходов между ними. Диаграмма состояний назначается классу или методу поведения.
Состояния. Состояния автомата соответствуют состояниям объектов, в которых объект удовлетворяет некоторому условию, выполняет некоторое действие или ожидает некоторого события. Объект может находиться в каждом состоянии в течение конечного времени. Каждому состоянию
284
Проектирование информационных систем
может соответствовать вложенный автомат. Состояние изображается как прямоугольник со скругленными краями. Каждое состояние имеет две части. В верхней части отображается имя состояния. Имя состояния может быть пустым -это так называемое анонимное состояние. Все анонимные состояния отличаются друг от друга. Нижняя часть состояния предназначена для отображения внутренних действий, выполняемых в ответ на определенные события, возникающие, когда автомат объекта находится в данном состоянии, без смены текущего состояния. Описание внутренних действий имеет следующий формат:
имя — события (список — параметров) [ условие ] / действие.
Каждое имя события должно быть уникальным в пределах одного состояния. Определены зарезервированные имена событий:
►	entry / действие — действие, выполняемое при входе в состояние;
►	exit / действие — действие, выполняемое при выходе из состояния.
Эти два предопределенных события не имеют списка параметров и условия возникновения, так как и то и другое предопределено.
Введено специальное ключевое слово «do», обозначающее вызов вложенного автомата:
do /имя — автомата (список — параметров).
Имя автомата задает конкретный автомат, которому при инициализации может быть передан список параметров, совместимый со списком параметров этого автомата. Графические обозначения различных классов состояний автомата приведены на рисунке 6.84.
События. События — это любое действие, имеющее значение с точки зрения смены состояний автомата. Определены следующие виды событий (одно событие может относиться одновременно к нескольким видам):
лава 6
Цодходы к проектированию информационных систем
285
►	условие становится истинным;
►	прием внешнего сигнала от одного объекта к другому;
►	запрос на выполнение метода объекта;
►	истечение заданного периода времени.
Сигналы определяются в следующем формате:
имя — события (список — параметров);
каждый параметр имеет формат:
имя — параметра : тип.
Сигналы могут образовывать иерархию наследования и, следовательно, изображаться с помощью диаграммы классов. Если на конечном автомате событие X приводит к переходу из состояния в состояние, то любое производное событие от X также приводит к смене этого перехода. На диаграмме классов состояния изображаются с ключевым словом «signal». Они не имеют методов поведения, могут иметь только атрибуты.
Наименование	Графическое обозначение	Смысл
Состояние	f Приостановка прав \	В верхней части — имя, в нижней — внутренние действия, выполняемые автоматом при возникновении определенных событий, когда он находится в данном состоянии
	entry/Приостановка пароля exit/Восстановление пароля ^вкл./Восстановление пароля,	
Начальное состояние	•	С него начинается выполнение автомата
Конечное состояние		На нем заканчивается выполнение автомата
Рис. 6.84. Обозначения элементов диаграммы состояний
Простые переходы между состояниями. Простой переход из состояния 1 в состояние 2 показывает, что объект, находящийся в состоянии 1, перейдет в состояние 2 и выполнит определенные действия, когда произойдет предопределенное
286
Проектирование информационных систем
для перехода событие и будут истинными специфицированные условия. Такая смена состояний называется срабатыванием перехода. Событие, помечающее переход, может иметь параметры, которые доступны внутри действий, сопоставленных переходу или тому состоянию, в который ведет переход. События, определяющие выполнение переходов, обрабатываются по одному в один момент времени. Если событие не приводит к выполнению ни одного перехода, то оно игнорируется. Переходы изображаются линией с указанием направления и дополнительной текстовой информации, представленной в следующем виде:
имя — события (параметры) [условие] / выражение Л посылка.
Условие — это логическое выражение с участием параметров события, имен состояний автомата и атрибутов объекта или класса, которым назначен данный автомат. Выражение — это процедурное выражение, которое выполняется при осуществлении перехода. Оно может включать в себя параметры события, методы поведения и атрибуты того объекта или класса, которым назначен автомат. Посылка описывает ту операцию или сигнал, который может быть послан другим объектам. Она имеет следующий формат:
назначение ... операция (параметры).
Назначение — это имя объекта, для которого выполняется операция, или посыпается сообщение или сигнал. Операция — это имя вызываемого метода, посылаемого сигнала или сообщения. Примером текста, который может рассматриваться в качестве перехода, является следующий:
►	нажата левая кнопка мыши (позиция);
►	[позиция внутри окна];
►	/ выбор - выбрать (позиция);
►	Л выбор . выделить.
Здесь «нажата левая кнопка мыши» —- это имя события, «позиция»—это параметр данного события, показывающий, в какой позиции на экране произошло нажатие. «Позиция
глава 6
Подходы х проектированию информационных систем
287
внутри окна» — это условие, которое должно быть выполнено для того, чтобы переход мог выполниться, т.е. будут обрабатываться не все нажатия кнопки мыши, а только те, которые произошли внутри заданного окна. Выражение «выбор = выбрать (позиция)» представляет собой присвоение переменной «выбор» значения функции «выбрать» с параметром «позиция». И, наконец, «выбор ... выделить» — это обращение к методу «выделить» объекта «выбор».
Составные переходы между состояниями. Составные переходы предназначены для отражения операций распараллеливания и синхронизации. Составной переход может иметь несколько входных и несколько выходных состояний. Составной переход может выполниться только тогда, когда все его входные состояния активны. После выполнения составного перехода все его выходные состояния становятся активными, а все входные перестают быть активными. Таким образом, автомат может одновременно находиться в нескольких состояниях. Составной переход изображается как прямоугольник, входные и выходные линии определяют входные и выходные состояния (рис. 6.85).
Рис. 6.85. Обозначение составного перехода
На данном рисунке изображен один составной переход, имеющий два входных состояния (А, В) и два выходных состояния (С, D).
Вложенные автоматы. Если состоянию соответствует вложенный автомат, то после выполнения действий entry для этого состояния начинает работать вложенный автомат
288
Проектирование информационных систем
(со своего начального состояния). Когда достигается одно из конечных состояний вложенного автомата, то состояние считается законченным, выполняются действия по выходу (exit), и автомат готов к смене состояния под воздействием внешних воздействий.
Одному состоянию может соответствовать либо один вложенный автомат, либо несколько конкурирующих (взаимно исключающих) вложенных автоматов. Графически это обозначается следующим образом:
►	один вложенный автомат изображается внутри прямоугольника для состояния;
►	несколько вложенных автоматов также изображаются внутри прямоугольника для состояния, но они разделяются пунктирными линиями.
Пример вложенного автомата приведен на рисунке 6.86.
Рис. 6.86. Пример изображения вложенного автомата
На данном рисунке состояние В является составным и содержит внутренний автомат, который состоит из начального, конечного состояний и состояний С и D.
Пример конкурирующих вложенных автоматов представлен на рисунке 6.87.
Состояние В декомпозируется с помощью двух конкурирующих вложенных автоматов.
На примере диаграммы состояний (рис. 6.88) рассмотрен конечный автомат, описывающий функционирование класса «диаграммер» графического редактора диаграмм.
пава б
Подходы к проектированию информационных систем
289
Рис. 6.87. Пример изображения конкурирующих вложенных автоматов
Рис. 6.88. Диаграмма состояний для класса «диаграммер»
10. Зак. 1035
^0 Проектирование информационных систем
Диаграммы действий. Диаграммы действий (activity diagrams) показывают выполнение операций. Они являются разновидностью автомата. Предназначение данной диаграммы — показать поток управления, внутренний для операции, в противоположность показу реакции на внешние события (как это делается в диаграмме состояний).
Диаграмма действий состоит из элементов, приведенных на рисунке 6.89.
Действия. Действия показывают выполнение некоторой неделимой операции. Каждое действие имеет имя, определяющее смысл этого действия. Имя может представлять собой текст на естественном языке, псевдокод операции или фрагмент текста на некотором языке программирования. Внутри описания могут использоваться атрибуты того объекта, за которым закреплена диаграмма действий.
Условия. Они предназначены для обозначения возможности условной передачи управления в соответ ствии со значением некоторого логического выражения. Условие может иметь один (или более) вход и два или более выхода. Каж-
Наименование	Графическое обозначение		Смысл
Действие	(	)		Неделимая операция
Условие	^х>0		Выбор одного из вариантов в зависимости от условия
Переход			Передача управления от одного действия к другому, с возможностью распараллеливания
Передача сигнала			Операция отправки сигнала при выполнении перехода
Прием сигнала			<	Ожидание прихода сигнала для выполнения перехода
Объект			1	Объекты, используемые при выполнении действий
Рис. 6.89. Обозначение компонентов диаграммы действий
I ’ЛЭВй 6
r Подходы к проектированию информационных систем
дый выход должен быть помечен условием, истинность которого обеспечивает переход по данной дуге.
Переходы. Переходы имеют тот же смысл, что и в автомате диаграммы состояний. Но здесь они не помечаются никаким событием и имеют условие только для специальных состояний «условие», т.е. они просто передают управление от одного действия к другому. Окончание входных действий непосредственно приводит к выполнению перехода. Возможность распараллеливания и синхронизации остается.
Полосы выполнения. Диаграмма действий может быть разделена на полосы (swim lanes), которые включают в себя определенный набор действий и переходов. Каждая полоса имеет собственное имя и тем самым позволяет группировать действия в единое целое. Ее можно сравнить с пакетом для классов. Графически каждая полоса представляет собой вертикальное разделение диаграммы действий с помощью сплошной линии. Каждое действие может находиться только в одной полосе, тогда как переходы могут пересекать полосы.
Ниже представлен пример (рис. 6.90), на котором используются практически все возможные элементы диаграммы действий. Здесь обсуждается процедура обслуживания клиента узла Internet, подающего заявку на обслуживание. Заявка может быть двух типов: заявка на регистрацию и заявка на предоставление некоторой услуги. Диаграмма содержит две полосы: «клиент» и «отдел обслуживания». После получения запроса на обслуживание клиент может подготовить платеж, а отдел обслуживания займется одновременно с этим выполнением заказа. В зависимости от типа запроса будет выполнено либо действие «создать услугу», либо действие «заполнить карточку регистрации». Далее будет выполнена подготовка документов, и после выполнения платежа он будет учтен и обслуживание закончится.
Отношения между действиями и объектами. Все действия выполняются над объектами. Целесообразно показать на диаграмме действий отношения между объектами и операциями.
10'
292
Проектирование информационных систем
Рис. 6.90. Пример диаграммы действий
Различаются два вида отношений:
►	объект отвечает за выполнение операции;
►	атрибуты объекта используются для выполнения операции.
Эти виды отношений показываются соответственно как действие, которое вызывает метод поведения объекта, и как объект, являющийся входным или выходным для действия.
Объекты на диаграмме действий показываются в виде прямоугольников с записанными внутри именами. Если объект является выходным для действия, то от действия к объекту идет штриховая линия, если же объект является входным для действия, то от объекта к действию идет штриховая линия. Вызов метода показывается сплошной линией с указанием имени и параметров операции, а также мо
глава б
ХТТОДХОДЬ1 к проектированию информационных систем
293
жет быть указано направление передачи или получения данных (см. диаграмму последовательностей).
Специальные символы. Специальные символы могут не использоваться, так как их использование необязательно, они являются дополнительным средством выражения посылки и получения сигналов. Это можно обозначить указанием имени сигналов непосредственно на переходе, а можно использовать специальные символы, которые должны соединяться с линией перехода.
«Получение сигнала» (см. рис. 6.89) — это символ, предназначенный для обозначения получения сигнала для выполнения перехода, т.е. передачи управления.
«Посылка сигнала» (см. рис. 6.89) — это символ, предназначенный для обозначения посылки сигнала в момент выполнения перехода.
Диаграммы реализации. Диаграммы реализации предназначены для отображения состава компилируемых и выполняемых модулей системы, а также связей между ними. Диаграммы реализации разделяются на два конкретных вида: диаграммы компонентов (component diagrams) и диаграммы развертывания (deployment diagrams).
Диаграммы компонентов. Диаграмма компонентов отражает зависимости составных частей программного обеспечения, в которые включаются файлы исходных текстов, двоичные файлы библиотек объектных модулей и исполняемые файлы. Она состоит из компонентов и отношений между ними. Используются отношения двух типов:
►	зависимость — это зависимость любого типа (использование, совместная компиляция);
►	композиция — это включение одних компонентов в состав других.
Компонент изображается в виде прямоугольника с двумя маленькими прямоугольниками у левого края, внутри прямоугольника записывается имя компонента.
Зависимость изображается штриховой линией от использующего компонента к используемому. Композиция (или
294 Проектирование информационных систем
включение) изображается размещением включаемого компонента внутри включающего. Компоненты могут иметь интерфейсы, через которые выражаются зависимости. Интерфейсами могут являться, например, имена вызываемых подпрограмм. Интерфейсы изображаются окружностями, соединенными с компонентом линией без направления, рядом записывается имя интерфейса.
Ниже (рис. 6.91) представлен пример диаграммы компонентов, состоящий из компонентов «графический редактор» и «оконная система». Оконная система зависит от интерфейса «нарисовать», имеющегося у компонента «графический редактор».
Оконная		Графический
система		редактор
Рис. 6.91. Пример диаграммы компонентов
Диаграммы развертывания. Диаграммы развертывания показывают конфигурацию исполняемой программной системы, включающей в себя программные компоненты, процессы, объекты. Она состоит из узлов и отношений взаимодействия между узлами и компонентами. Узлы могут включать компоненты и объекты.
Узлы представляют собой физические элементы времени выполнения, обозначающие вычислительный ресурс, обладающий как минимум запоминающим устройством и, возможно, вычислительным устройством. Узлы могут обозначать компьютеры, человеческие ресурсы или механические устройства. Внутри узлов могут содержаться компоненты и объекты, это обозначает, что данный компонент или объект существует в рамках данного узла. Узлы изображаются как проекция трехмерного куба. Узел может представлять собой тип узла или конкретный экземпляр узла. В зависимости от этого происходит именование узла. В случае узла-типа его имя выглядит так:
Глава б	204
УТодходы к проектированию информационных систем___
имя типа;
в случае узла-экземпляра имя выглядит так: имя узла : имя типа.
На диаграмме развертывания компоненты могут представлять не только типы, но и конкретные экземпляры, поэтому их имя может быть дополнено именем типа через двоеточие.
Отношение взаимодействия между узлами, компонентами или объектами обозначается штриховой линией, направленной от использующего элемента к используемому.
Ниже на рисунке 6.92 рассмотрен пример, состоящий из трех вычислительных систем, представляющих типичный случай системы доступа к базам данных на основе Internet/ Intranet-технологии, которая предполагает наличие двух компьютеров. Один из них выполняет функции web-ссрве-ра с возможностью исполнения ASP или CGI, который готовит данные для отображения на компьютере клиента. Для подготовки отображаемых данных web-сервер в лице компонента «исполнение ASP-программ» выполняет запросы к SQL-серверу, который хранит данные и обрабатывает их.
Рис. 6.92. Пример диаграммы развертывания
Проектирование информационных систем
Все это делается по запросу с клиентского компьютера, и на него же посылаются результаты запросов в подготовленном для отображения виде (HTML).
6.4.	Практическое применение методологий проектирования ИС
Описание бизнес-процессов формируется при помощи нотаций и инструментальной среды, позволяющей отразить все указанные выше аспекты. Только в этом случае модель бизнес-процессов окажется полезной для предприятия, так как ее можно будет подвергнуть анализу и реорганизации.
6.4.1.	Структурное моделирование информационных систем средствами BPwin и ERwin
Для описания БП организации (предприятия) могут быть использованы CASE-средства, одним из которых является BPwin [64]. BPwin позволяет аналитику создавать сложные модели бизнес-процессов при минимальных усилиях. BPwin поддерживает три методологии — IDEFO, IDEF3 и DFD. Каждая из них призвана решать свои специфические задачи. Так же можно строить смешанные модели.
ERwin — средство концептуального моделирования БД [65], использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД.
Возможны две точки зрения на информационную модель и соответственно два уровня модели. Логический уровень (точка зрения пользователя) означает прямое отображение фактов из реальной жизни. На физическом уровне модели рассматривается использование конкретной СУБД, опреде
глава 6
х~|~[одходы к проектированию информационных систем
297
ляются типы данных. ERwin предоставляет возможности создавать два различных уровня представления одной диаграммы и управлять этими уровнями.
6.4.1.1.	BPwin — средство функционального моделирования (IDEFO)
Основные этапы построения IDEFO-модели [66].*
1.	Определить функциональную структуру.
2.	Выделить для каждой функции входы, выходы, управление и механизмы.
3.	Построить контекстную диаграмму.
4.	Создать диаграммы декомпозиции.
5.	Получить диаграмму дерева узлов. Построить FEO-диа-грамму на основе уже построенной диаграммы IDEF0.
6.	Выделить «центры затрат».
7.	Назначить величины затрат работам на нижнем уровне детализации по каждому центру затрат и временные характеристики работ — продолжительность и частоту выполнения.
8.	Сформировать отчет по проведенному стоимостному анализу, указав соответствующие параметры генерации. Рассмотрим укрупненную модель управления компанией, представленную основными бизнес-процессами организации, такими как: стратегическое управление, организационное управление, экономическое управление, управление финансами, управление персоналом, управление маркетингом, управленческий учет, логистическое управление. Представим процессы таким образом, чтобы наглядно видеть иерархию управления и степень «важности» процессов. Цепочка будет иметь вид: 1 — стратегическое управление, 2 — организационное управление, 3 — экономическое управление, 4 — логистическое управление, 5 — управление маркетингом, 6 — управление персоналом. Описание каждого процесса приведено в таблице 6.10. Описание постановки проекта представлено на рисунке 6.93.
298 Проектирование информационных систем
Model Report Preview
Report Format: Labeled
Model Name: Управление компанией
Definition: Типовые бизнес-процессы, описывающие управление компанией
Viewpoint: ДИРЕКТОР
Scope: Общее управление бизнесом компании
Time Frame: (AS—IS)
Status: WORKING
Purpose: Моделировать текущие OS-1S бизнес-процессы ком Author Name: Федоров Максим Олегович
System Last Reuision Date: 01.04.2004 User Last Reuision Date: 01.01».2004 Creation Date: 01.04.2004
Рис. 6.93. Цель разработки проекта
Таблица 6.10
Работы диаграммы декомпозиции АО
№	Название работы (Activity Name)	Определение работы (Activity Definition)
1	2	3
1	Стратегическое управление	Анализ среды организации, определение миссии, стратегии фирмы, поведения на рынке
2	Организационное управление	Определение структуры организации
3	Экономическое управление	Экономический анализ, учет, управление финансами, издержками, себестоимостью продукции
4	Логистическое управление	Управление закупками, выпуском продукции, транспортировкой, распределением, складом
глава 6
гПодходы к проектированию информационных систем
299
Окончание табл. 6.10
1	2	3
5	Управление маркетингом	Исследования рынка, продукции, ценообразования, распределения
6	Управление персоналом	Управление человеческими ресурсами: прием сотрудников, регистрация, учет, обучение, оплата труда, организация труда
Модель АО укрупненной модели управления организацией приведена на рисунке 6.94.
Дадим пояснение к стрелкам, представленным на рисунке 6.94 (табл. 6.11).
Стрелки диаграммы АО
Таблица 6.11
Название стрелки (Arrow Name)	Название работы					
	Стратег, управл.	Организ. управл.	Эконом, управл.	Логист, управл.	Управл. маркет.	Управл. персоналом
1	2	3	4	5	6	7
Входная информация	Вход	Вход	Вход	Вход	Вход	Вход
Руководство к действию	Управление	Управление	Управление	Управление	Управление	Управление
Высший менеджмент	Механизм	-	Механизм	Механизм	Механизм	-
Аналитики	Механизм	Механизм	Механизм	Механизм	Механизм	Механизм
Аналитический аппарат	Механизм	Механизм	Механизм	Механизм	Механизм	Механизм
Менеджеры по персоналу	-	-	-	-	-	Механизм
Стратегия компании	Вход	Управление	Управление	Управление	Управление	Управление
300
Проектирование информационных систем
Рис. 6.94. Модель управления компанией
TVlELBcL б	-401
Ар|одх°ды к проектированию информационных систем____________
Окончание табл. 6.11
1	2	3	4	5	6	7
Организационные решения	—	Выход	Управление	Управление	Управление	Управление
Экономические решения	-	-	Выход	Управление	Управление	-
Логистические решения	-	-	-	Выход	Управление	-
Маркетинговые решения	—	-	-		Выход	
Решения по управлению персоналом	—	__	—	—		Выход
Декомпозируем работу «Организационное управление» (рис. 6.95), данные приведены в таблицах 6.12 и 6.13.
Таблица 6.12
Работы диаграммы декомпозиции А2
Название работы (Activity Name)	Определение работы (Activity Definition)
Организационная структуризация	Проведение описания, анализа, регламентации, совершенствования оргструктуры
Финансовая структуризация	Разработка и определение системы объединения финансового результата и распределения затрат
Управление системой качества	Разработка, внедрение, сопровождение системы качества
Управление администрированием	Разработка системы делопроизводства, исполнительской дисциплины, организация труда руководителей
Управление правовым обеспечением управления	Проведение правовой экспертизы документов, обеспечение правовой консультации и разработка локальных нормативных актов
Таблица 6.13
Стрелки диаграммы декомпозиции А2	" w
Наименование стрелки (Arrow Name)	Источник стрелки (Arrow Source)	Тип стрелки источника (Arrow Source Type)	Приемник стрелки (Arrow Dest.)	Тнп стрелки приемника (Arrow Dest. Type)	Проектирование информационных систем
1	2	3	4	5	
Входная информация	Граничная стрелка	Input	Организационная структуризация	Input	
Руководство к действию	Граничная стрелка	Control	Организационная структуризация	Control	
Аналитики	Граничная стрелка	Mechanism	Организационная структуризация	Mechanism	
Организационные решения	Все пять работ	Output	Граница диаграммы	-	
Модель организации	Организационная структуризация	Output	Финансовая структуризация	Input	
			Управление системой качества	Input	
			Управление администрированием	Input	
			Управление правовым обеспечением управления	Input	
Стратегия компании	Граничная стрелка	Control	Все пять работ	Control	
Окончание табл. 6.13
1	2	3	4	5	ава 6	,	SOS f одходы к проектированию информационных систем	ииие
Финансовые руководства	Часть граничной	Control	Финансовая структуризация	Control	
Стандарты	Часть граничной	Control	Управление системой качества	Control	
Административные нормы	Часть граничной	Control	Управление администрированием	Control	
Законы	Часть граничной	Control	Управление правовым обеспечением управления	Control	
Финансисты	Часть граничной	Mechanism	Финансовая структуризация	Mechanism	
Специалисты по качеству	Часть граничной	Mechanism	Управление системой качества	Mechanism	
Аналитический аппарат	Граничная стрелка	Mechanism	Все пять работ	Mechanism	
Юристы	Часть граничной	Mechanism	Управление правовым обеспечением управления	Mechanism	
Правовые акты	Управление правовым обеспечением управления	Output	Финансовая структуризация	Control	
			Управление системой качества		
			Управление администрированием		
			Организационная структуризация		
Администраторы	Часть граничной	Mechanism	Управление администрированием Mechanism		
304
Проектирование информационных систем
Рис. 6.95. Результат выполнения
I 'лава 6	inc
x Подходы к проектированию информационных систем______
Диаграмма дерева узлов, показывающая иерархическую зависимость работ, но не взаимосвязи между работами, представлена на рисунке 6.96.
Рис. 6.96. Диаграмма дерева узлов
BPwin поддерживает ABC-модель оценки затрат функционирования информационной системы. В таблице 6.14. представлены основные центры затрат, требуемые функционированием системы.
Центры затрат АВС
Таблица 6.14
Центр затрат	Определение
Управление	Затраты на управление, связанные с совершенствованием организационной структуры, доведением решений до подразделений, обучением персонала, внедрением и сопровождением системы качества, делопроизводством, правовой экспертизой
Человеческий ресурс	Затраты на оплату труда аналитиков, менеджеров, проводящих анализ деятельности, разрабатывающих структуру организации
Обеспечение	Затраты на обеспечение возможности проведения анализа и разработок, на обеспечение необходимой информацией
Показатели стоимости функционирования каждого процесса приведены в таблице 6.15.
Отчет по затратам приведен на рисунке 6.97.
306
Проектирование информационных
систем
Рис. 6.97. Фрагмент отчета Activity Cost Report
'лава 6
1~Годходы к проектированию информационных систем
307
Таблица 6.15
Показатели стоимости работ на диаграмме А2
Activity Name	Cost Center	Cost Center Cost, руб.	Duration, месяц	Frequency
Организационная структуризация	Управление	20 000	1,5	3
	Чел. ресурс	60 000		
	Обеспечение	34 000		
Финансовая структуризация	Управление	10 000	1	4
	Чел. ресурс	45 000		
	Обеспечение	15 000		
Управление сис-темой качества	Управление	10 000	0,5	4
	Чел. ресурс	20 000		
	Обеспечение	17 500		
Управление администрирова-нием	Управление	5 000	0,5	2
	Чел. ресурс	15 000		
	Обеспечение	20 000		
Управление пра-новым обеспечением управления	Управление	5 000	0,5	4
	Чел. ресурс	30 000		
	Обеспечение	10 000		
6.4.1.2.	BPwin — средство моделирования процессов (IDEF3)
Основные этапы построения 1DEF3-Modejiu [66].-
I.	Определить очередность запуска процессов.
2.	Выделить перекрестки для отражения слияния/разветв-лсния действий.
3.	Построить возможные графики запусков процессов.
4.	Построить контекстную диаграмму и диаграммы декомпозиции.
5.	Создать сценарии.
Декомпозируем работу «Организационная структуризация» (рис. 6.95).
308
Проектирование информационных систем
Поясним смысл диаграммы и перекрестков (рис. 6.98). Начинается организационная структуризация с процесса «Описание организационной структуры», далее следует процесс «Анализ организационной структуры». Смысл перекрестка J1 «Исключающее ИЛИ» в случае разветвления — только один следующий процесс запускается. Значит, запускается или процесс «Регламентация», или «Совершенствование оргструктуры».
После выполнения процесса «Совершенствование оргструктуры» может стоять перекресток J2 — «Исключающее ИЛИ». Здесь опять возможен выбор пути действия — запуск соответствующего процесса.
Декомпозируем процесс «Описание организационной структуры» (табл. 6.16).
Таблица 6.16
Процессы диаграммы декомпозиции
Название процесса (Activity Name)	Определение процесса (Activity Definition)
Сбор информации об организационной структуре	Анкетирование, интервьюирование, изучение документов
«Вертикальное» описание организационной структуры	Разработка классификаторов, матриц проекций
Актуализация описания организационной структуры в соответствии с изменениями в организации	Необходимо проводить коррекцию информации из-за постоянных изменений в организации
Представление проектов организационной структуры на утверждение руководству	Согласование проектов с руководством
Доведение «Положения о подразделениях» до структурных подразделений	Применение решений на низших уровнях управления
Поясним смысл диаграммы и перекрестков (рис. 6.99). Начинается описание организационной структуры с процесса «Сбор информации». Перекресток «Асинхронное И» в случае разветвления означает, что все следующие процессы
Глава 6
1 руодходы к проектированию информационных систем
309
Рис. 6.98. Диаграмма IDEF3 «Организационная структуризация»
зю
Проектирование информационных систем
Рис. 6.99. Диаграмма IDEF3 «Описание организационной структуры»
плава 6	1
1 ууодходы к проектированию информационных систем____
должны быть запущены. Перекресток «Синхронное И» в случае слияния означает, что оба процесса должны быть завершены одновременно до «Представления проекта руководству». После представления проекта возможны два пути — перекресток «Исключающее ИЛИ» — доработка или «Доведение «Положения» до подразделений». Перекресток «Асинхронное ИЛИ» в случае разветвления означает, что один из следующих процессов (или все) должен быть запущен, т.е. запускаются процессы «вертикального» описания и (или) актуализации в зависимости от решения руководства.
6.4.1.3-	BPwin — средство моделирования потоков данных (DFD)
Основные этапы построения DFD-модели [66]:
I.	Выделить процессы, внешние сущности и связывающие их потоки данных.
2.	Построить контекстную диаграмму.
3.	Выделить процессы, определить потоки данных и хранилища на соответствующем уровне декомпозиции.
4.	Построить диаграммы декомпозиции.
5.	Предложить управляющие процессы, потоки и хранилища, которые можно было бы использовать на данных диаграммах.
Рассмотрим процесс «Осуществить организационное управление» (табл. 6.17, рис. 6.100).
Таблица 6.17
Стрелки диаграммы АО
Название стрелки (Arrow Name)	Направление стрелки
Входная информация	От внешней сущности «Внешняя среда» в процесс
Структура организации	От процесса в сущность «Подразделения организации»
Миссия и стратегия организации	От сущности «Стратегическое планирование» в процесс
Проектирование информационных систем
312
в
Рис. 6.100. Контекстная диаграмма
у^лава 6	чы
х Подходы к проектированию информационных систем______
Декомпозируем процесс «Осуществить организационное управление», названия подпроцессов представлены в таблице 6.18.
Таблица 6.18
Процессы диаграммы декомпозиции АО
Название работы (Activity Name)	Определение работы (Activity Definition)
Осуществить организационную структуризацию	Провести описание, анализ, регламентацию, совершенствовать оргструктуру
Осуществить правовое обеспечение управления	Разработать и определить систему объединения финансового результата и распределения затрат
Обеспечить управление системой качества	Разработать, внедрить, обеспечить сопровождение системы качества
Осуществить управление администрированием	Разработать систему делопроизводства, исполнительской дисциплины, организация труда руководителей
Осуществить финансовую структуризацию	Провести правовую экспертизу документов, организовать обеспечение правовой консультации и разработать локальные нормативные акты
Основные хранилища информации приведены в таблице 6.19.
Таблица 6.19
Наименования хранилищ
Название хранилища (Data Store)	Вид хранилища
Организационная структура	Автоматизированное
Локальные нормативные акты	Автоматизированное
БД исполнительской дисциплины	Автоматизированное
Финансовая структура	Автоматизированное
Система качества	Автоматизированное
Существующая финансовая система	Не автоматизированное
Существующая система качества	Не автоматизированное
314
Проектирование информационных систему
Рис. 6.101. Диаграмма декомпозиции АО, стрелки которой представлены в таблице 6.20
глава 6
1 Подходы к проектированию информационных систем
315
DFD-модель процесса представлена на рисунке 6.101.
Таблица 6.20
Стрелки диаграммы АО
Название стрелки (Arrow Name)	Вход в процесс (хранилище)	Выход из процесса (хранилище)
Входная информация	Осуществить организационную структуризацию	Граничная стрелка
Организационная структура	Организационная структура	Осуществить организационную структуризацию
Миссия и стратегия организации	Осуществить организационную структуризацию	Граничная стрелка
Нормативные документы	Осуществить правовое обеспечение управления	Подразделения
Должностные инструкции	Осуществить управление администрированием	Подразделения
Административные инструкции	Часть стрелки «Структура организации»	БД исполнительской дисциплины
Структура организации	Граничная стрелка	Хранилища 1-5
6.4.1.4.	ERwin — средство информационного моделирования (IDEF1X)
Основные этапы построения IDEFlX-модели [66];
1.	Построение логической модели данных:
—	определение сущностей, определение зависимостей между сущностями;
—	задание первичных и альтернативных ключей;
—	определение атрибутов сущностей;
—	приведение модели к требуемому уровню нормальной формы;
316
Проектирование информационных систем
—	переход к физическому описанию модели: назначение соответствий имя сущности — имя таблицы, атрибут сущности — атрибут таблицу,
—	задание триггеров, процедур и ограничений;
—	генерация базы данных.
2.	Построение физической модели данных:
—	выбор целевой СУБД, выделение представления, правила валидации для колонок, а также значения, присваиваемые колонкам по умолчанию; определение индексируемых полей;
—	построение на базе логической модели физической модели;
—	генерирование БД на языке целевой СУБД с изменением, в случае необходимости, типов данных;
—	создание физической модели по схеме данных уже существующей БД на языке любой поддерживаемой ERwin СУБД.
Для построения логической модели данных в нотации EDEF1X в качестве предметной области выберем уже рассмотренную в моделях IDEFO, DFD, IDEF3 функцию управления — «Организационное управление».
Рассмотрим одну из функций «Организационного управления» — организационную структуризацию, которая, в свою очередь, декомпозируется на функции:
►	описание организационной структуры;
►	анализ организационной структуры;
►	совершенствование организационной структуры;
►	регламентация.
Для построения модели определим сущности, атрибуты сущностей и связи между сущностями. Наименования сущностей приведены в таблице 6.21.
Отношения между сущностями представлены в таблице 6.22.
Необходимо задать определения для сущностей согласно таблице 6.23, атрибуты которых представлены в таблице 6.24.
|ава 6	2-17
Подходы к проектированию информационных систем
Таблица 6.21
Сущности
Наименование сущности	Тип сущности
Функциональная структура	Основная
Организационная структура	Основная
Регламентирующие документы	Справочная
Матрицы проекций	Справочная
Классификаторы	Справочная
Решения по изменению оргструктуры	Основная
Изменения в организации	Основная
Применение решений	Основная
Таблица 6.22
Отношения между сущностями
Сущность	Отношение	Сущность
Функциональная структура	1 : М	Организационная структура
Функциональная структура	1 : М	Изменения в организации
Регламентирующие документы	1 : М	Решения по изменению оргструктуры
Регламентирующие документы	1 : М	Функциональная структура
Матрицы проекций	1 : М	Функциональная структура
Матрицы проекций	I : М	Изменения в организации
Классификаторы	1 : М	Функциональная структура
Классификаторы	1 : М	Изменения в организации
Решения по изменению оргструктуры	1 : М	Применение решений
318
Проектирование информационных систем
Определения сущностей
Таблица 6.23
Сущность	Определение
Функциональная структура	Информация о функциях, используемых классификаторах, матрицах проекций и документах, регламентирующих функции
Организационная структура	Сведения о должностях, структурных подразделениях, подчинении должностей
Регламентирующие документы	Информация о дате создания, отмены, введения, изменения документов
Матрицы проекций	Справочник имеющихся матриц проекций
Классификаторы	Справочник имеющихся классификаторов
Решения по изменению оргструктуры	Наименование решения, где применяется решение, отражает, что было до решения и что предполагается после проведения
Изменения в организации	Наименование изменения, где произошло изменение; информация о том, что было и что стало в результате изменения
Применение решений	Проверяется состояние выполнения решения и состояние обучения персонала при применении решения
Атрибуты
Таблица 6.24
Сущность	Атрибуты	Ключ	Тип
1	2	3	4
Функциональная структура	Наименование функции	РК	String (50)
	Код классификатора		Integer (20)
	Код матрицы проекций		Integer (20)
	Наименование документа		String (50)
Организационная структура	Должность	РК	String (50)
	Структурное подразделение		String (50)
	Подчинение		String (50)
глава 6
* одходы к проектированию информационных систем
319
Окончание табл. 6.24
1	2	3	4
Регламентиру-ющие документы	Наименование документа	РК	String (50)
	Дата утверждения		Date
	Дата введения		Date
	Дата внесения изменений		Date
	Дата отмены		Date
Изменения в организации	Наименование изменения	РК	String (100)
	Где произошло изменение		String (50)
	Что было		String (50)
	Что стало		String (50)
	Код классификатора		Integer (20)
	Код матрицы проекций		Integer (20)
Решения по изменению оргструктуры	Наименование решения	РК	String (100)
	Место применения		String (50)
	Что было		String (50)
	Что станет		String (50)
	Наименование документа		String (50)
Применение решений	Наименование решения	РК	String (100)
	Состояние выполнения		String (50)
	Состояние обучения персонала		String (50)
Матрицы проекций	Код матрицы проекций	РК	Integer (20)
	Наименование матрицы проекций		String (50)
Классификаторы	Код классификатора	РК	Integer (20)
	Наименование классификатора		String (20)
Согласно таблице 6.22 создаются связи, как показано на рисунке 6.102.
Полученная логическая модель данных должна быть сгенерирована в модель БД (физическую), как представлено на рисунках 6.103 и 6.104.
Типы данных атрибутов формируются для конкретной СУБД (рис. 6.105).
Результат генерации БД в среде MS Access 2000 приведен на рисунке 6.106.
11. Зак. 1035
Рис. 6.102. Создание связей
у» Ы
я
“О
о rt tv Д Д ф
д
X ё § X X £ И п 5!
Q
S-. .
322
Проектирование информационных систем
Рис. 6.105. Изменение типов данных
глава 6
* Цодходы к проектированию информационных систем
323
Рис. 6.106. Результат выполнения
6.4.2. Объектное моделирование
информационных систем средством Ration Rose
Rational Rose — мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат.
Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы. Диаграммы взаимодействия показывают, как объекты работают совместно, обеспечивая требуемые функциональные возможности. Для отображения объектов системы и их отношений используются диаграммы классов. Диаграммы компонентов иллюстрируют, как классы соотносятся с готовыми физическими компонентами системы. Наконец, диаграммы размещения применяют для визуализации проекта распределенных систем.
11*
324
Проектирование информационных систем
В качестве предметной области рассматривается магазин компьютерной техники [67]. Сотрудниками являются: несколько менеджеров, работающих с клиентами; управляющий заказами (агент по снабжению); главный (старший) менеджер; бухгалтер; специалисты сервисного центра. Главный менеджер управляет процессом функционирования, принимает управленческие решения. Управляющий заказами организовывает процесс снабжения, комплектации заказов. Менеджеры консультируют клиентов, формируют заказы. Сервисный центр рассматривает претензии клиентов. Модель функционирования системы приведена на рисунке 6.107.
Рис. 6.107. Модель функционирования системы
Диаграмма вариантов использования. Диаграммы вариантов использования описывают функциональное назначение системы или то, что система должна делать. Разработка диаграммы преследует следующие цели:
►	определить общие границы и контекст моделируемой предметной области;
'лава б
Подходы к проектированию информационных систем
325
►	сформулировать общие требования к функциональному поведению проектируемой системы;
►	разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
►	подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Диаграмма вариантов использования для информационной системы рассмотрена на рисунке 6.108.
Рис. 6.108. Диаграмма вариантов использования
Диаграмма классов. Центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими, как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.
326
Проектирование информационных систем
Рис. 6.109. Диаграмма классов для сценария «Ввести новый заказ»
4* Rational Rose - Магазин компыотерп ой
(г:; ' '
'лава 6
Подходы к проектированию информационных систем
327
Диаграмма классов представляет собой граф, вершинами которого являются элементы типа классификатор, связанные различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие, как объекты и связи.
Диаграмма классов информационной системы рассмотрена на рисунке 6.109'.
Диаграмма состояний. Каждая диаграмма состояний в IJML описывает все возможные состояния одного экземп-цяра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия.
Диаграммы состояний чаще всего используются для описания поведения отдельных объектов, но также могут быть применены для спецификации функциональности других компонентов моделей, таких, как варианты использования, актеры, подсистемы, операции и методы.
Диаграмма состояний для информационной системы рассмотрена на рисунке 6.110.
Диаграмма последовательности. При рассмотрении диаграмм состояния и деятельности было отмечено, что, хотя э ти диаграммы и используются для спецификации динамики поведения систем, время в явном виде в них не присутствует. Временной же аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Для моделирования взаимодействия объектов во времени в языке UML используются диаграммы последовательности.
Диаграмма последовательности для информационной системы рассмотрена на рисунке 6.111.
Диаграмма кооперации. Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
328
Проектирование информационных систем
V Rational Rote-Mui .пин компьнмернии )скниеж
ft He Ed: Hi1» FififiJi P»pCri T«b M>. a wdirt HMO
7 .-i  .vM:«
n tfUl X %«!«! VIOIB В В И alB«-|44 Q 4
f•" @' «Граница» Выбор заказ, a	k
♦ E? «Граним» Детали зака . ли Associations	_
- С) Сущности
$Маю
- 0 «Сущности» Заказ	ьЗ
фз Номер заказа	: #
Имя клиента
ф Лата заказа	®
* СоамльПустЗаказ	/*
♦	ЗакеказИнф е "	(1
♦	Инф
<•7 1ЬеУ|рав заказами) У £ ВтеГл менеажер(Гл к.
<7 1ЬеНомерЗаказа|Нсмт
г- Stale/Adiviy Model
% Закв’
•
CJ Выполнение заказ-;
CD Выполнен
СЗ Мнциа1ызация
О Отменен
к ЕВ «Сущности» НомерЗака
"3. Assocsations
-- D Управление
U Маю
♦ 0 «Улравлтм» Гл мене|>
Рис. 6.110. Диаграмма состояний для объекта «Заказ»
gf Во Kk Maw Rnwt'«wwe.-ftpxt Tows MHi» Whkw Heb
iOcspi! fc«j£:viB08a®ai'jB* ч^п;?Г
й Магаз» компьютерной геи
Cl Use Case View
Sg Nan
•	!* Агент по смабжеп»
>	® Еугалтерня
•	$ Клэдсащ»
-	й Менеджер пгиесоа»
-	® Покутате1ь
• » Сережи» центр
• 4 Улрав/иош»
• Актэкспертизы
> Ввести новом заказ
h
: > -3- Консуяьтаиия гю з<* t 'з Нжпадзая
।	3	Отклокмть з».аз
О Отклокмтыретеч»»
•	> Оформить заказ
•	е? Осюрмпомчсчоюе
- > Претеичч
• 2» Ситуация но рьике
1	АяОсиГогс
5 jtoiBcdView
<Мап
Ш Ввод заказа
• AsiocWiorst
* S ЙрЛорзжлза
t. S Детали заказа
=£ J9 Управ зоксмми
Е Заказ
м 0 Глм>.«а>ер
к* £3 Conpononl View fl Depfcymen Vew
. & ModeiPtepolet
]-;>и*Ю50С-8мм'[гло»ия«^и-.1;
Рис. 6.111. Диаграмма последовательности системы
329
'лава б
Цодходы к проектированию информационных систем
Прежде всего, на диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Далее, как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации ц ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи — потоки сообщений. Они представляются также в виде соединительных линий между объектами, над которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в общей последовательности инициализации сообщений.
Диаграмма кооперации для информационной системы рассмотрена на рисунке 6.112.
-- **»» •*
K# КА ViKr 'tvBd	ймрсЛ fcr* А*Им ШЬ" И*
111 Li BiS *£‘«1	Я-	.............:

DltwnfeM
*£«Ии«ьЗ» * СоФвыжЕ!
♦Ии»
Я Сеталтзжа»
• ИнфЗжаза
ВмОф м>.ам
♦ Ин»
Р Цтздае. заката*»
If / (1Ьв0фо₽мип 4 / (theKarcyfcv 4 / (ЛеМенеаа« я; / |»еМенеа«я Л / рЬеПретспэн
♦ Создатыюей
♦ Создать
^Открыть
♦ Открыть
/ |№еВвасгмтч * / ЦЬеИзммлЕ Ж / (th«6»<ra»r« • / IthaSrwnoi I / ЦвОфОмлв Я / (tbet^sramet 4 / (ЛвИакласна
/ (втеКлавоош
Рис. 6.112. Диаграмма кооперации объектов системы
""Г"* • йкжй?

ззо
Проектирование информационных систем
Диаграмма компонентов. Полный проект программной системы представляет собой совокупность моделей логического и физического уровней, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются диаграммы реализации, которые включают в себя диаграмму компонентов и диаграмму развертывания.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов информационной системы рассмотрена на рисунке 6.113.
Rational Rose-*1асазчнкомпьннбрной- -	i * Z/Л	.у
Q, Ffe Ed» fvttj». Report Ws Adkins vflndtw
о ч hi gi eiel *|ств ® в s a i ® < |чч □ si
g; Man
jfi Введ заказа Hi Введ заказа ji; Вес» заказа
-> Associations
} Component Viw
С) Границы
:<J Man
18 Выбор заказа
ВьЛор заказа
Детали заказа
Ж! Дета™ заказа
LJ Одиности
$ Man
Заказ
gj Заказ
Зй Номер заказа
Sj Номер заказа
Р) Ыправлетив
С Маш
18 Гл менеджер
£ Гл менеджер
18 Уоравпяющйи заказами gj Управляющий заказами Маю
System
St Простой заказ
87 Главный заказ
Рис. 6.113. Диаграмма компонентов системы
’лава 6
Цодходы к проектированию информационных систем
331
Диаграмма развертывания. Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Если разрабатывается программа, выполняющаяся локально на компьютере пользователя и не использующая периферийных устройств и ресурсов, то в разработке дополнительных диаграмм нет необходимости. При разработке же корпоративных приложений наличие таких диаграмм может быть крайне полезным для решения задач рационального размещения компонентов в целях эффективного использования распределенных вычислительных и коммуникационных ресурсов сети, обеспечения безопасности и других.
Для представления общей конфигурации и топологии распределенной программной системы в UML предназначены диаграммы развертывания.
Диаграмма развертывания информационной системы рассмотрена на рисунке 6.114.
ч • notional Rose- Магазин компьютерной
’ij Г de Edit Format Browse Report Tools Add-Ins Window Неф
d cs q,u * * к i & I ^Fni айава|8«-|ччпв
% йагазин компьютерной техники
♦ Г~1 Use Case View
* D Logical View
- Qj Component View
♦ D Границы
* ГД Сущности
* ГД Управление
Main
System
§7 Гласный заказ
87 Простой заказ
- ft Deployment View
0 Интернет сервер
- Д Рабочая станция №1 Й Гласный заказ
- 0 Рабочая станция №2 й Простой заказ
- 0 Рабочая станция №3 й Предварительный заказ
- 0 Сервер базыданных
Й Соединение с Б Д(Интернет)
- О Сервер приложения Й Доступ к БД й Печать бланка
0 Сетевой гринтер
Й Model Properties
Рис. 6.114. Диаграмма развертывания системы
Проектирование информационных систем
? j Контрольные вопросы
1.	В чем заключается сходство и различие понятий «проектирование ИС» и «анализ ИС»?
2.	В чем заключается проектирование архитектуры «в большом» и «в малом»?
3.	Какие методы используются при проектировании архитектур информационных систем?
4.	Какова сущность структурного подхода к проектированию информационных систем?
5.	Какие группы средств применяются при структурном анализе?
б.	Перечислить основные признаки классификации структурных методологий анализа и проектирования.
7.	Перечислить составляющие функциональной модели стандарта  IDEFO и основные правила (принципы) ее построения.
8.	Перечислить составляющие информационной модели стандарта DFD и основные правила (принципы) ее построения.
9.	Перечислить составляющие процессной модели стандарта IDEF3 и основные правила (принципы) ее построения.
10.	Каковы, по вашему мнению, цели построения моделей?
11.	Какую информацию диаграммы позволяют получить?
12.	Каково назначение логической модели в стандарте IDEF1X?
13.	Для чего предназначены спецификации управления? Перечислить основные составляющие модели.
14.	Какие параметры позволяют проводить сравнительный анализ методологий? В чем заключается их сходство и различие? Когда и при каких условиях применяются?
15.	Дать основные понятия объектно-ориентированной методологии.
16.	Какие принципы положены в основу объектно-ориентированной методологии?
17.	Перечислить основные этапы объектно-ориентированного анализа.
18.	Какие диаграммы UML используются при моделировании информационных систем? Для чего предназначены диаграммы?
ГуЛ£ГБ&
Подходы
К АВТОМАТИЗАЦИИ
ДЕЯТЕЛЬНОСТИ
ПРЕДПРИЯТИЯ
Многие предприятия в условиях рынка рассматривают информацию в качестве ценного ресурса, который следует хранить, использовать и защищать, как любой другой вид собственности. В целях получения информации, необходимой для управления производственной и хозяйственной деятельностью, предприятие создает информационную систему. Она рассматривается как инструмент управления работой предприятия.
ИС служит связующим звеном между хозяйственной деятельностью и людьми, принимающими решения. В ней осуществляется сбор, регистрация данных о хозяйственной деятельности, их обработка, хранение и передача пользователям для анализа и принятия решений. Таким образом, данные о финансово-хозяйственной деятельности являются входом в ИС, а полезная информация для лиц, принимающих решения, — выходом из нее.
Главная цель создания ИС — обеспечить руководство предприятия информацией для принятия обоснованных управленческих решений. ИС должна предоставлять полную картину финансово-хозяйственной деятельности предприятия. Прежде всего, она предоставляет количественные данные, необходимые для таких функций управления, как планирование, контроль и анализ.
7.1. Выбор стратегии автоматизации
деятельности
Определение границ (направлений) автоматизируемой деятельности является важным аспектом в процессе автоматизации. Авторами [81] Бароновым В.В., Каляновым Г.Н.,
334 Проектирование информационных систем
Поповым Ю.И. и др. предложены следующие подходы к автоматизации: хаотичная и полная автоматизация, автоматизация по участкам, автоматизация по направлениям. Ниже коротко описана сущность каждого подхода.
Хаотичная автоматизация, представляющая собой автоматизацию не связанных между собой операций, выполняемых как одним, так и несколькими сотрудниками, что приводит к наличию неавтоматизированных участков процессов. При таком подходе процесс внедрения информационных технологий определяется сиюминутными локальными задачами, а не реальными потребностями бизнеса. В результате предприятие в лучшем случае получает разрозненные прикладные системы, стоимость интеграции которых в ряде случаев может быть сравнима с общей стоимостью комплексного решения. В худшем случае создаются незаконченные фрагменты информационной инфраструктуры и прикладных систем, которые не могут применяться в практической деятельности предприятия. При этом предприятие несет дополнительные затраты на дублирование функций, которые должна была выполнять информационная система, и обслуживание созданных незаконченных прикладных систем. Хаотичная автоматизация является одним из наиболее неэффективных видов инвестирования средств в развитие предприятия.
Автоматизация по участкам. Автоматизация по участкам подразумевает процесс автоматизации отдельных производственных или управленческих подразделений предприятия, объединенных по функциональному признаку.
Подобный путь автоматизации выбирается при отсутствии инвестиций для полной автоматизации, но при требованиях технологии производства, экономической целесообразности автоматизации ИС конкретного участка.
Наиболее часто такой подход применяется для автоматизации производственных участков (средство автоматизации — специализированные АСУП). Применение принципа автоматизации предприятия по участкам для ряда пред
рлава 7
А Подходы к автоматизации деятельности предприятия
335
мва
приятий — единственно возможный способ повысить экономические показатели в условиях ограниченных инвестиционных ресурсов. Эффективность автоматизации по участкам определяется разработкой стратегического и оперативного планов автоматизации.
Автоматизация по направлениям. Автоматизация по направлениям подразумевает автоматизацию отдельных направлений деятельности предприятия. Этот подход часто применяется при использовании систем класса MRPII, ERP, когда конечной целью работ является полная автоматизация предприятия.
Отличие этого подхода от автоматизации по участкам заключается в обязательном участии всех организационных звеньев, связанных с автоматизируемым направлением, в процессе автоматизации. Обычно любое направление деятельности охватывает практически все подразделения предприятия, следовательно, этот подход нельзя рассматривать как локальный. В большинстве случаев автоматизация по направлениям связана с реинжинирингом бизнес-процессов и требует создания модели всего предприятия.
Эффективность автоматизации по направлениям определяется аналогично предыдущему подходу.
Полная автоматизация управления предприятием. Представляет собой автоматизацию всех ключевых бизнес-про-цсссов на основе произвольного набора IT решений, которые могут быть интегрированы между собой двумя способами:
► полная автоматизация с внутренней интеграцией — работа отдельных ИС на предприятии на основе единой базы данных или хранилища данных, что не требует организовывать регламентную передачу информации из одной информационной системы в другую;
► полная автоматизация с внешней интеграцией — подразумевает применение отдельных информационных систем, между которыми налаживаются процедуры регламентной передачи информации.
33^Проектирование информационных систем
АИС как система состоит из большого количества элементов различных уровней и различного назначения. К ним относятся подсистемы, модули, блоки,, задачи, процедуры, функции, операции и т.п. Интеграция предполагает такое объединение и согласование функций и процедур, чтобы в ходе процесса функционирования предприятия обеспечивалась оптимизация его поведения. Интеграция должна проявляться во всех без исключения функциональных и обеспечивающих подсистемах.
В подсистеме технического обеспечения — это локальные вычислительные сети и обеспечение связи предприятия с внешней средой через глобальные сети. В подсистеме информационного обеспечения — это ведение баз данных под управлением СУБД. Интеграция математического обеспечения проявляется, прежде всего, в согласовании входов и выходов математических моделей, комплексировании различных моделей (например, прогнозирования и планирования), целостности и непротиворечивости системы математических моделей. Интеграция программного обеспечения проявляется в том, что оно строится в виде сложного и вместе с тем гибкого программного комплекса, позволяющего выполнять программы в требуемой последовательности и в требуемых сочетаниях. Интегрированные АИС, построенные на основе одной базовой системы ERP, выводят предприятие на новый уровень интеграции организационного обеспечения.
Но главное, ради чего создаются на предприятиях автоматизированные системы, — это функциональная интеграция.
АИС строится с ориентацией на деятельность организации как целостной системы, а не на автоматизацию деятельности отдельных подразделений. При этом возможно несовпадение функционального наполнения подсистем АИС и функциональных обязанностей в подразделениях.
При проектировании и эксплуатации системы вопросам интеграции должно уделяться первостепенное внимание, так
Глава 7	ээу
 Подходы к автоматизации деятельности предприятия_
как АИС является основой формирования сложных функциональных структур, состоящих из большого количества связанных между собой функций. Разрывы интеграционных связей, выпадение необходимых функциональностей или их спабая реализация снижают эффективность деятельности предприятия.
Отметим следующие особенности комплексного подхода к автоматизации деятельности предприятия:
►	повышенная экономическая эффективность этого подхода по сравнению с другими (по участкам и направлениям);
►	чрезвычайно высокие требования к качеству управления процессом внедрения системы.
Выбор одной или нескольких комбинации из стратегий автоматизации определяется результатами анализа текущего и планируемого (ожидаемого) состояния предприятия на определенный период. Другими словами, по окончании данного этапа выбора, у менеджера появляется общее, а возможно, и более детальное понимание того, какие функции должны быть у будущего IT решения для удовлетворения по требностей предприятия.
7.2. Управление процессом автоматизации
Формирование и развитие на предприятии информационной системы, предназначенной для обеспечения постановки и поддержки принятия решения, производственных и управленческих задач в их стратегической перспективе, всегда требуют долгосрочного планирования, ориентированного на стратегические цели в области организации, развития и использования ИС, т.е. стратегического планирования ИС. Эти задачи и функции являются частью процесса управления информационной системой предприятия и требуют, в свою очередь, полной интеграции задач ИС в систему планирования предприятия в целом.
338
Проектирование информационных систем
7.2.	/. Планирование процесса автоматизации
Процесс автоматизации как любой управляемый процесс состоит из следующих этапов:
►	планирования;
►	контроля исполнения плана;
►	регулирования — анализа результатов и принятия решений.
Как правило, существуют два типа планов автоматизации предприятия [81]:
►	стратегический план;
►	оперативный план.
Стратегический план за редким исключением не содержит плана конкретных работ. В нем фиксируются принципы и условия, с соблюдением которых должно осуществляться принятие решений на каком-либо отрезке времени, и результаты, описанные в терминах бизнеса, которые должны быть достигнуты при соблюдении этих условий. Стратегический план носит условный характер, т.е. действует до наступления некоторых условий, например, образования новых подразделений, достижения объема продаж не ниже..., и т.д.
Оперативный план, как правило, содержит план конкретных работ по реализации принятых стратегических решений, описанных в технических терминах. Он включает в себя события, которые должны произойти, носит календарный характер, т.е. привязан к календарным датам (год, полгода, квартал), и сопровождается сметой расходов или графиком инвестирования средств.
Контроль исполнения планов подразумевает наличие процедур периодического сбора информации, ее обобщение и представление оперативной информации лицам, принимающим решения в форме, принятой на предприятии: например, отставание от календарных сроков, перерасход или, наоборот, недорасход средств, выделяемых на автоматизацию. В состав представляемой оперативной информации в обязательном порядке должна включаться информация о возникших по мере реализации плана проблемах.
'лава 7
Цодходы к автоматизации деятельности предприятия
339
Анализ результатов и принятие решений подразумевает наличие процедуры анализа результатов, опираясь на который производится ревизия плана или внесение изменений в ход процесса. Процедура может выполняться периодически, а может инициироваться при наступлении каких-либо событий: превышение бюджета, отставание от сроков.
Стратегический плйн (стратегия автоматизации). Понятие стратегии автоматизации включает в себя базовые принципы, используемые при автоматизации деятельности предприятия [81]. В ее состав входят следующие компоненты: ► цели: области деятельности предприятия и последователь-
ность, в которой они будут автоматизированы;
►	способ автоматизации: по участкам, направлениям, комплексная автоматизация;
►	долгосрочная техническая политика — комплекс внутренних стандартов, поддерживаемых на предприятии: типы стандартов на оборудование и ПО, перечень поставщиков и производителей базовых аппаратно-программных средств, на использование продукции которых ориентировано предприятие, перечень продуктов и линий продуктов, которые используются или которые предполагается использовать в области автоматизации;
►	ограничения: финансовые, временные и т.д.;
►	условия, при наступлении которых производится ревизия плана;
►	анализ результатов выполнения плана;
►	процедура управления изменениями плана.
Стратегия автоматизации, в первую очередь, должна соответствовать приоритетам и стратегии (задачам) бизнеса предприятия. В понятие стратегии также должны входить пути достижения этого соответствия.
Таким образом, автоматизация — это один из способов достижения стратегических бизнес-целей, во главе которого должна лежать стратегия бизнеса предприятия: миссия предприятия, направления и модель бизнеса. Таким образом, стратегия автоматизации представляет собой план,
340
Проектирование информационных систем
согласованный по срокам и целям со стратегией организации.
Важной особенностью стратегии автоматизации является степень соответствия приоритетов автоматизации и стратегии бизнеса, а именно целям, которые должны быть достигнуты.
Стратегические цели бизнеса с учетом ограничений (финансовых, временных и технологических) конвертируются в стратегический план автоматизации предприятия.
Автоматизация предприятия является инвестиционной деятельностью, следовательно, особую актуальность приобретают вопросы сохранения вложенных средств в информационные технологии. Потеря инвестиций происходит в том случае, когда информационная система перестает быть эффективной, т.е. удовлетворять потребностям бизнеса. В этом
случае система не позволяет:
►	эффективно решать поставленную задачу при требуемом уровне рентабельности эксплуатации вычислительных средств;
►	обеспечивать возможность своего развития.
Поэтому мероприятия по сохранению инвестиций должны быть направлены на обеспечение требуемой рентабельности эксплуатации информационной системы и возможности ее развития с учетом произведенных затрат. Низкая отдача от использования информационной системы при высоких затратах на ее эксплуатацию, а также неспособность фирмы изменить такое положение говорят о нецелесообразности сохранения этих инвестиций, т.е. систему лучше в дальнейшем не использовать.
К основным ограничениям, которые необходимо учитывать при выборе стратегии автоматизации, относятся следующие [81].
1.	Финансовые ограничения, они определяются величиной инвестиций, которые предприятие способно сделать в развитие автоматизации. Этот тип ограничений универсален, так как остальные три вида могут быть частично представлены как финансовые.
'лава 7
руодходы к автоматизации деятельности предприятия
341
2.	Временные ограничения, обусловленные влиянием следующих факторов:
► сменой технологий основного производства,
> ► рыночной стратегией предприятия, государственным регулированием экономики.
3.	Ограничения, связанные с влиянием человеческого фактора, к которым относятся:
►	корпоративная культура — отношение персонала к автоматизации;
►	особенности рынка труда;
►	трудовое законодательство, регулирующее процессы увольнения персонала, высвобождающегося в результате автоматизации.
4.	Технические ограничения, связанные с реальными возможностями предприятия: отсутствием помещений для размещения вычислительной техники, ограничениями по использованию определенного вида оборудования и т.п.
Типичные проблемы, которые возникают при разработке стратегии автоматизации, как правило, связаны со следующими факторами:
►	состоянием рынка информационных технологий;
►	определением эффективности инвестиций в информационные технологии;
►	необходимостью реорганизации деятельности предприятия при внедрении информационных технологий.
7.2.2. Методы и средства проектирования автоматизированной ИС предприятия (реорганизация деятельности предприятия)
Процесс изменения системы управления предприятием является многоэтапным:
►	определение миссии предприятия и его стратегических целей (стратегическое планирование). Эти задачи решаются исходя из анализа, прежде всего, внешней среды предприятия с помощью исследования рынка, анализа экономико-политических и т.п. факторов;
342 Проектирование информационных систем
►	анализ и адаптация внутренней среды предприятия с тем, чтобы его структура и принципы функционирования соответствовали миссии предприятия и были направлены на достижение поставленных стратегических целей. Этот этап называется реинжинирингом бизнес-процессов. Если же необходимо внедрение автоматизированной системы поддержки бизнеса, то данный этап можно назвать определением требований к информационной системе, т.е. на основе целевых моделей деятельности предприятия (моделей «как должно быть») выявляются объективные требования к тем задачам, исполнение которых должна обеспечивать разрабатываемая автоматизированная система;
►	формирование спецификаций, сопровождающееся выпуском проекта ИС предприятия, составной частью кото-
• рой являются модели. На этом этапе обычно принимаются во внимание ограничения, которые необходимо учитывать в моделях ИС;
► внедрение — связано с конкретной реализацией проекта ИС на предприятии.
Для большинства современных предприятий, поставивших перед собой задачу внедрения АИС, необходим, как отмечено выше, этап реорганизации, включающий наведение порядка в их деятельности, создание рациональных технологий и бизнес-процессов.
Методы проектирования автоматизированных информационных систем
Спектр существующих подходов к реорганизации предприятия варьируется от мягких, постепенных методов улучшения его деятельности, основанных в значительной степени на соображениях здравого смысла, до жестких, регламентирующих его коренную ломку и декларирующих принцип «отбрось все старое и начни заново» [81].
Одним из наиболее известных подходов к реорганизации является методика планирования бизнес-систем BSP (Business Systems Planning) фирмы IBM, разработанная в се
глава 7
*’[~[одходы к автоматизации деятельности предприятия
343
редине 70-х годов Мартином (Martin). Методика BSP определяется как «подход, помогающий предприятию определить план создания информационных систем, удовлетворяющих его ближайшие и перспективные информационные потребности». Главная идея заключается в том, что информация является одним из основных ресурсов и должна планироваться в масштабах всего предприятия, а информационная система должна проектироваться независимо от текущего состояния и структуры предприятия. Анализ и реорганизация деятельности предприятия производятся на основе ряда ма триц (данные — процессы, руководители — процессы, информационные системы — руководители, информационные системы — процессы, информационные системы — файлы данных) и с учетом выявленных при обследовании проблем, основные изменения осуществляются в целях ориентации предприятия на спроектированную информационную систему.
Подход CPI (Continuous Process Improvement) и его японский аналог TQM (Total Quality Management) успешно применялись при реорганизации предприятий еще в середине минувшего века. Этот подход продолжает активно исполь-юваться и в настоящее время, о чем свидетельствует, например, возрастающий объем применения стандартов серии ISO 9000, фактически поддерживающих CPI.
II основе подхода лежит очевидная концепция управления качеством выпускаемой продукции. Качество должно <>ыть направлено на удовлетворение текущих и будущих шпросов потребителя как самого важного звена производственной линии. Достижение соответствующего уровня качества требует постоянного совершенствования производственных процессов. Данный подход характеризуется ориентацией на требования рынка и потребителя и применим в условиях, когда существует достаточная стабильность производства и желание сохранить кадры.
Требования СММ (Capability Maturity Model) разрабо-iiiiibi институтом SEI (Software Engineering Institute) для предприятий, стремящихся к осуществлению качественного
3^4 Проектирование информационных систем
процесса разработки и сопровождения программного обеспечения, и являются примером применения подхода CPI для конкретной отрасли промышленности.
СММ описывает характеристики совершенства (качества) процессов разработки и сопровождения программного обеспечения (ПО) (ПО-процессов), а также критерии перехода от плохо управляемых к хорошо управляемым ПО-процессам в терминах уровней совершенства модели. СММ применяется:
►	для улучшения ПО-процессов, когда предприятие планирует, разрабатывает и реализует их изменения;
►	оценки ПО-процессов, когда определяются состояние текущих ПО-процессов предприятия и приоритетные процессы, а также осуществляется организационная поддержка их улучшения;
►	оценки возможностей ПО при квалификации партнеров, осуществляющих заказную разработку ПО или управляющих состоянием существующих ПО-процессов.
Фактически СММ является комплексом требований к ключевым элементам эффективного ПО-процесса и способам его эволюционного улучшения. СММ поддерживает этапы планирования, инжиниринга, управления разработкой и сопровождением ПО, что улучшает возможности предприятия в достижении целей по стоимости, функциональности и качеству производимого ПО.
В начале 90-х годов сформировался новый революционный подход к реорганизации — реинжиниринг бизнес-процессов BPR (Business Process Reengineering). Его авторы Хаммер (Hammer) и Чампи (Champy) определяют BPR как фундаментальное переосмысление и радикальное перепланирование бизнес-процессов предприятий, имеющих целью резкое улучшение показателей их деятельности, таких, как затраты, качество и скорость обслуживания [59]. Революционность данного подхода заключается в отказе от традиционных правил и предположений по ведению бизнеса, многие из которых оказываются устаревшими, ошибочными или просто не подходящими для конкретной ситуации
глава 7
* ууодходы к автоматизации деятельности предприятия
345
( гем не менее, они изначально заложены в большинство процессов), бизнес проектируется заново, с чистого листа.
BPR начинается с того, что отбрасываются все предположения и все данности. При перепроектировании сначала определяется, что должно делать предприятие, а затем — как оно должно это делать. BPR не принимает ничего как данность. Он игнорирует то, что есть, и концентрируется на гом, что должно быть.
BPR ориентируется на процессы, а не на задачи, рабочие места, персонал. Под бизнес-процессом понимается совокупность действий, получающая на входе данные различных типов и продуцирующая результат, имеющий ценность для потребителя. Современные предприятия сосредоточиваются, как правило, на отдельных задачах, составляющих бизнес-процесс, и имеют тенденцию терять из виду главную цель.
Очевидно, что по мере дальнейшего развития технологий будет происходить отказ от все большего количества правил, по которым организован бизнес. Правила, которые представляются непогрешимыми сегодня, могут устареть менее чем за год. Из этого следует, что использование возможностей изменения бизнес-процесса, заложенных в новых технологиях, — это постоянная деятельность, а не одноразовая кампания. Следование новейшим технологиям и нахождение способов их применения на предприятии должны происходить непрерывно, так же, как исследования, разработки, маркетинг. Более того, предприятия должны сделать применение новых технологий одним из своих основных занятий, если они хотят идти в ногу со временем. Те, кто лучше сможет определить и оценить возможности, скрытые и новой технологии, получат постоянно растущее преимущество над конкурентами [81].
Одним из побудительных мотивов реорганизации деятельности предприятия может служить его желание сертифицироваться по стандарту ISO 9000. Стандарт на качество проектирования, разработки, изготовления и послепродажного обслуживания ISO 9000 определяет базовый набор
346
Проектирование информационных систем
мероприятий по контролю качества и представляет собой схему функционирования бизнес-процессов предприятия, обеспечивающую высокое качество .его работы. ISO 9000 (на самом деле представляющий собой серию стандартов 9000, 9001, 9002, 9003, 9004, наиболее полным из которых является ISO 9001, специфицирующий модель обеспечения качества на всех этапах жизненного цикла товара/услуги) регламентирует два ключевых момента: наличие и документирование соответствующего бизнес-процесса, а также из-меряемость его качества.
При реорганизации деятельности предприятий важен выбор метода оценки существующего положения дел и перспективных предложений. Наибольшее распространение получили следующие методы:
►	метод динамического функционального анализа на основе сетей Петри различного вида (см. п. 8.2);
►	метод функционально-стоимостного анализа АВС (Activity Based Costing).
Каждый из этих методов (и соответствующих поддерживающих инструментальных средств) регламентирует следующие основные этапы выполнения оценок:
—	построение статической функциональной модели (с использованием SADT- или DFD-нотации);
—	расширение статической модели соответственно поведенческими или стоимостными характеристиками ее объектов;
—	сбор и ввод в модель необходимой фактической информации;
—	«исполнение» модели и получение соответствующих оценок.
С использованием динамической модели, основанной на сетях Петри, можно описать и проанализировать [72]:
►	механизмы взаимодействия процессов (последовательность, параллелизм, альтернатива);
►	временные отношения между выполняемыми процессами (одновременность, наложение, поглощение, одинаковое время запуска/завершения и т.п.);
глава 7
1 Цодходы к автоматизации деятельности предприятия
347
►	абсолютное время (длительность процесса, время запуска, зависимости от времени выполнения процесса и др.);
►	управление исключительными ситуациями, определяемое нарушениями.
Построенные динамические модели позволяют осуществлять следующие операции: статический анализ деятельности предприятия (компоненты сети, иерархия сети, соответствие типов), динамический анализ деятельности для конкретного маркирования сети, имитационное моделирование деятельности с построением соответствующих графиков.
ABC (Activity Based Costing) — метод определения себестоимости и других характеристик товаров и услуг на базе функций и ресурсов, задействованных во всех видах деятельности предприятия (производстве, маркетинге, обслуживании клиентов, оказании услуг, технической поддержке и т.п.) |69]. ABC-метод рассматривает деятельность предприятия как множество последовательно выполняемых процессов/функ-I шй, распределяя при этом накладные расходы в соответствии с детальными расчетами использования ресурсов, с подробными моделями процессов и их влиянием на себестоимость.
ABC-модель обеспечивает лишь получение важной для бнзиес-процесса информации, содержащей стоимостную картину деятельности и характеризующей ее эффективность и прибыльность товаров (услуг). Для дальнейшего ее анализа и основанного на нем управления предприятием применяется методика ABM (Activity Based Management), регламентирующая средства и способы управления в целях совершенствования бизнес-процессов и повышения прибыльности. Фактически АВМ представляет собой комплекс методов анализа ABC-модели для реорганизации бизнес-процессов и целях повышения производительности, снижения стоимости и улучшения качества.
К ключевым моментам реорганизации деятельности предприятия следует отнести убеждение руководства предприятия в необходимости изменений и привлечение мнений на свою сторону, выбор и ранжирование нуждающихся в реорганизации бизнес-процессов, реорганизация оргструктуры
348
Проектирование информационных систем

предприятия. При обсуждении необходимости реорганизации следует обсудить с руководством предприятия следующие моменты [81]:
►	основные проблемы предприятия и пути их решения, требующие изменений, а также способы управления этими изменениями;
►	недостатки традиционного функционального подхода к управлению предприятием (узкий взгляд и ограниченный интерес, конкуренция с другими функциональными подразделениями, сложные пути обмена информацией) и преодоление их при ориентации на бизнес-процессы;
►	потенциальные выгоды от проведения реорганизации;
►	этапы и сроки проведения реорганизации, требуемые для этого ресурсы;
. ► необходимость создания совместной рабочей группы, подчиняющейся непосредственно руководству предприятия, наделение ее соответствующими полномочиями. Одной из первоочередных задач созданной рабочей группы является выбор нуждающихся в реорганизации бизнес-процессов. Ранжирование и выбор процессов для реорганизации могут быть осуществлены на основании следующих критериев [81]:
—	важности процесса для осуществления общей стратегии предприятия;
—	жизнеспособности процесса;
—	ожиданий клиентов (как внешних, так и внутренних) относительно процессов;
— возможности достижения процессом желаемых результатов.
Для моделирования бизнес-процессов кроме традиционных диаграмм (нотаций), упомянутых выше, применяются и специально разработанные, а именно:
►	карты Харрингтона (Harrington), демонстрирующие лишь структуру бизнес-процесса;
►	карты процесса, базирующиеся на стандарте ANSI.
Карты Харрингтона BFD (Block Flow Diagrams) являются простейшим и наиболее распространенным типом
ж Подходы к автоматизации деятельности предприятия_
потоковых карт (схем). Они содержат два типа объектов: активности, моделирующие функции и детализируемые с помощью BFD нижнего уровня, и управляющие потоки, организующие последовательность выполнения активностей на рассматриваемом уровне. Фактически BFD позволяет формализовать лишь следующие знания о бизнес-процессах: ('остоит из, Является частью, Следует за, Предшествует.
Результаты эволюции BFD воплотились в стандарт ANSI, в соответствии с которым карта процесса определясь гея как схематичное или табличное представление последовательности всех относящихся к делу действий или собы-। ий — операций, транспортировок, инспекций, хранений, задержек и т.п., происходящих в ходе выполнения процесса или процедуры.
Средства проектирования
автоматизированных информационных систем
При выполнении работ по моделированию на каждом ИЗ представленных выше уровней могут быть использованы различные инструментальные средства.
Инструментарий, которым пользуются инженеры по управлению, аналитики и проектировщики автоматизированных систем, называется CASE-средствами. В наиболее полном варианте CASE-средства поддерживают все стадии создания и внедрения информационной системы: от постановки задач, подлежащих автоматизации, до генерации машинно-। о кода (более подробно данный вопрос изложен в главе 9). В настоящее время не существует таких систем, которые бы обеспечивали генерацию полноценных программных модулей, полностью отвечающих установленным требованиям.
Инструментальные средства, предназначенные для моделирования информационных систем, могут быть отнесены к одной из следующих категорий (PC Week/RE, № 44/98): ► локальные, поддерживающие один-два типа моделей и методов (Design/IDEF, ProCap, S-Designor, «CASE. Аналитик»);
350 Проектирование информационных систем
►	малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов — ERwin и BPwin (пример применения CASE-средств рассмотрен в п.6.4.1);
►	средние интегрированные средства моделирования, поддерживающие от 4 до 10-15 типов моделей и методов (Rational Rose (см. п.6.4.2), Paradigm Plus, Designer/2000);
►	крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset).
Система ARIS как крупное интегрированное средство моделирования имеет уникальные возможности для моделирования и анализа систем. Моделирование в ARIS может выполняться как «сверху вниз», так и «снизу вверх». Для конкретных разработок количество используемых типов моделей и методик может быть ограничено с помощью специальных фильтров. Система позволяет контролировать процесс моделирования и выполнять расширенный анализ системы: определение целей и критических факторов, оценку рисков и конкурентов и др. Система ARIS предоставляет аналитикам возможность интегрированного «управления всеми ресурсами», необходимыми для использования на всех уровнях анализа при разработке ИСУП любой сложности [84].
Методология ARIS [83] рассматривает предприятие как совокупность четырех взглядов: на организационную структуру, на структуру функций, на структуру данных, на структуру процессов. При этом каждый из этих взглядов разделяется еще на три подуровня: описание требований, описание спецификации, описание внедрения. ARIS предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-процессов предлагается использовать 85 типов моделей, каждая из которых принадлежит тому или иному аспекту. Среди большого количества возможных методов описания можно выделить следующие: ЕРС — метод описания процессов, на
глава 7
^ГТРДХОДЫ к автоматизации деятельности предприятия
351
шедший применение для описания процессов системы SAP R/3; ERM — модель сущностей-связей для описания структуры данных; UML — объектно-ориентированный язык моделирования. ARIS Toolset (ARIS Easy Design) — единая среда моделирования, которая представляет собой совокупность четырех основных компонентов — Explorer (проводник), Designer (средство для графического описания моделей), таблиц (для ввода различных параметров и атрибутов) и мастеров (Wizards). ARIS Easy Design ориентирован на сбор информации и документирование, когда ARIS Toolset позволяет еще и проводить комплексный анализ, семантические проверки информации. Кроме того, только ARIS Toolset позволяет создавать скрипты (шаблоны) для отчетов, анализа и семантических проверок. ARIS Toolset — что средство для полноправного управления проектом ARIS. Функции управления заключаются в возможностях разграничения доступа для различных групп пользователей, а также ограничения методологии. Это необходимо, чтобы избавиться от избыточности методологии при реализации конкретного проекта.
7.2.J. Подходы к созданию автоматизированных ИС Набор функций IT решения позволяет перейти к выбору способа его приобретения или, иными словами, подводит к вопросу о том, что именно из IT решений необходимо и каким образом это IT решение получить. Исходя из современных возможностей информационных технологий, предприятие располагает следующими принципиальными способами приобретения IT решения:
►	разработка (как самостоятельно, так и силами другой компании);
►	покупка готового решения, его адаптация и настройка под специфику предприятия;
►	покупка ядра информационной системы и её модификация;
352
Проектирование информационных систем
►	прототипирование;
►	аренда информационной системы у специального ASP провайдера.
Разработка ИС. При ее самостоятельной организации испытывают различного рода трудности:
—	собственная разработка достаточно часто несет вместе с собой существенно больший набор рисков, связанных со всеми ее этапами;
—	пользователи очень часто неспособны определить или сформулировать свои потребности;
—	разработчики часто не знают или не понимают специфики деятельности компании и поэтому не готовы предложить что-то действительно значимое для улучшения ИС;
-	— процесс разработки может привести к тому, что к моменту его завершения новая ИС уже нс соответствует требованиям компании, диктуемым изменениями внешней среды.
К достоинствам данного способа относятся:
►	возможность разработки АИС для конкретных локальных целей предприятия;
►	отсутствие функциональных, информационных и др. ограничений, присущих готовым АИС;
►	повышение степени совместимости АИС с уже использующимися системами на предприятии.
К недостаткам относятся:
►	большие затраты временных, трудовых и финансовых ресурсов;
►	сложность в определении пользователем своих потребностей и оценке этих потребностей разработчиками;
►	необходимость в планировании и контроле над разработкой собственными возможностями, а также адекватная оценка этих возможностей;
►	отсутствие необходимой квалификации у сотрудников в большинстве компаний.
Даже при наличии хороших готовых программ организация может решить разрабатывать свою систему, если име-
глава 7
*1~|одходы к автоматизации деятельности предприятия
353
ст специфические потребности или этого требуют ее размеры и сложность. Обычно такие разработки ведутся самими компаниями, однако возможен вариант приглашения сторонних разработчиков. В этом случае совершенно необходимо:
I.	Тщательно выбрать разработчика. Лучше, если сторонний разработчик имеет опыт работы с другими компаниями данной отрасли и понимает, как компания ведет свои дела.
2.	Подписать контракт, накладывающий взаимные обязательства, фиксирующий потребности организации, которые должны быть удовлетворены и позволяющий расторгнуть соглашение при определенных условиях.
3.	Планировать и контролировать каждый шаг. Должно быть достигнуто соглашение по всем аспектам разработки и установлены частые контрольные сроки.
4.	Поддерживать эффективное взаимодействие. Отношения между организацией и разработчиком должны быть ясными и определенными на любой момент, чему способствует частое общение.
5.	Контролировать все затраты. Все затраты должны проверяться, а денежные выплаты до завершения разработки должны быть минимизированы.
Использование услуг сторонней организации (outsourcing) — это практика найма сторонней компании для проведения части или всей деятельности организации по обработке своих данных. На практике существует две разновидности таких услуг.
В одном варианте (mainframe outsourcing agreement) подрядчик нанимает всех или часть служащих клиента, занятых обработкой данных, а затем эксплуатирует всю систему. Такие контракты заключаются на длительное время, обычно на 10 лет. Клиент вносит фиксированную годовую оплату и дополнительные выплаты в зависимости от объемов обработки данных. Благодаря специализации такое сотрудничество оказывается взаимовыгодным.
В другом варианте (client/server outsourcing agreement) организация отдает на обслуживание лишь часть своей дея
12. Зак. 1035
354
Проектирование информационных систем
тельности по обработке данных, поручает выполнять какую-то отдельную функцию. Соглашения на обслуживание заключаются на срок до пяти лет и позволяют каждому партнеру сосредоточиться на своих задачах.
Использование услуг сторонней организации — скорее организационный прием, чем решение, касающееся основ ИС. Его преимущества — лучшее использование основных фондов, получение доступа к опыту специализированных компаний и современным технологиям, понижение затрат, сокращение времени разработок, сглаживание проблем сезонности бизнеса, а также проблем роста или сокращения организации. К рискам можно отнести потерю контроля за делегированными функциями, трудность прекращения таких взаимоотношений, их негибкость, потерю исключительных свойств ИС компании.
Приобретение готового решения ИС. Немало разработчиков программного обеспечения специализируется на определенной системе. По оценкам, около 80% компаний предпочитают покупать программное обеспечение, а не разрабатывать его. Однако и в этом случае организации приходится проходить жизненный цикл разработки системы, за исключением только некоторых шагов физической разработки, связанных с программированием.
К достоинствам способа относятся:
►	минимальные задержки и затраты до внедрения ИС;
►	возможность выбора пакета (модулей), наиболее соответствующего требованиям организации;
►	наличие возможности наглядно оценить функциональные возможности готового продукта;
►	существование дополнительных услуг, заключающихся в обслуживании ИС, обучении пользователей и т.д.;
►	наличие соответствующего полного пакета документации на ИС.
В качестве недостатков можно выделить:
►	наличие вероятности того, что разработчик прекратит свое существование или обслуживание ИС;
глава 7
*ууодходы к автоматизации деятельности предприятия ЗЭЭ
►	отсутствие полного соответствия между возможностями готовых IT продуктов и потребностями организации;
►	выбор и оценка готовых решений требуют использования дополнительных ресурсов;
►	ограниченные возможности для решения возникающих проблем.
Приобретение ядра ИС и ее модификация. Наиболее гибкий подход к приобретению системы — модификация готового программного обеспечения. Он сочетает достоинства других подходов, однако сопровождается и своими рисками, обусловленными тем, что программное обеспечение при л ом как бы меняет своего разработчика.
К достоинствам относятся:
►	уменьшается использование финансовых, трудовых и временных ресурсов организации, по сравнению с самостоятельной разработкой;
►	преодолеваются функциональные ограничения, повышается степень удовлетворения потребностей организации, чем при покупке готовых решений;
►	сочетаются выгоды двух других подходов.
Недостатки способа:
►	возникают трудности при модификации, что порождает новые ошибки и проблемы контроля;
►	усложняется процесс ведения документации по внесенным изменениям;
►	возможен отказ со стороны разработчика в обслуживании модифицированных решений.
Прототипирование — это подход к разработке системы, при котором создастся ее упрощенная действующая модель, пли прототип. Такой черновой экспериментальный вариант может быть создан быстро и с небольшими затратами и предоставлен пользователям для тестирования. Эксперимен-1ы с прототипом позволяют пользователям оценить их потребности и возможности. Результаты оценки позволяют разработчикам вносить изменения в прототип. Этот итеративный процесс продолжается до тех пор, пока не будет
12*
356
Проектирование информационных систем
достигнут приемлемый уровень удовлетворения потребностей. Полученная в результате модель системы может быть либо развита в полнофункциональную систему, либо ее свойства перенесены на разрабатываемый вариант ИС.
К достоинствам прототипирования относится лучшее определение потребностей пользователей, большая вовлеченность пользователей в разработку и, как следствие, их удовлетворенность, ускорение времени разработки, обнаружение многих ошибок при экспериментах, простота внесения изменений, меньшая стоимость.
Из недостатков можно выделить: большой расход времени пользователей, стремление сделать прототип быстро модифицируемым, что приводит к недостаточно эффективному использованию компьютерных ресурсов, прототип не охватывает всех свойств разрабатываемой системы; повышенные ожидания пользователей по отношению к будущей системе и возможные разочарования.
В большинстве случаев прототипирование не заменяет жизненный цикл разработки системы. Этот подход обычно используется для небольших нестандартных систем, свойства которых можно отразить в упрощенном варианте.
7.3. Моделирование информационных систем на базе стандартов ERP
и ИСО 9001:2000
В качестве методики моделирования ИС на базе стандартов ERP и ИСО 9001:2000 рассматривается методика, предложенная Волчковым С.А. и Балахоновой И.В. [46], в которой делается акцент:
► на моделирование промежуточного этапа, заключенного между определением вектора развития предприятия (концептуальная модель) и использованием интегрированной информационной системы на предприятии (физическая модель), обеспечивающей следование принятому вектору развития; данное моделирование именуется как логическое (более абстрактное описание физической
'лава 7
Подходы к автоматизации деятельности предприятия
357
модели предприятия); оно необходимо как связка концептуальной модели с физической моделью предприятия, реализованной в ИС;
►	использование моделирования в цикле непрерывного улучшения бизнес-процессов предприятия;
►	значимость концептуальной модели;
►	сущность логического моделирования;
►	существующие проблемы моделирования и предложения по их разрешению.
Моделирование как основа BPI. Предлагается следующая классификация деятельности на предприятии [46]:
►	А — первичная деятельность: изготовление конкретных изделий (например, автомобилей) или сервис (например, гарантийное или постгарантийное обслуживание);
►	В — вторичная деятельность, направленная на улучшение основной деятельности группы А;
►	С — деятельность, направленная на совершенствование деятельности группы В.
В настоящий момент для российских предприятий критичнее всего деятельность группы А, но без наличия деятельности групп В и С в условиях конкурентного рынка невозможно обеспечить шанс получения прибыли в будущем (повышение потенциала предприятия). В рамках рассмотренных групп деятельности предприятия используются модели, представленные на рисунке 7.1.
Концептуальная модель поддерживает деятельность группы «С» Структурное моделирование (DFD, IDEFO)
Логическая модель поддерживает деятельность группы «В» Объектно-ориентированное моделирование (UML)
Физическая модель
(Информационная система/ИС, Документация Системы Менеджмента качества/СМК) поддерживает деятельность группы «А» Реляционное моделирование БД (IDEF1X)
Рис. 7.1. Модели, поддерживающие деятельность предприятия
358 Проектирование информационных систем
Деятельность группы А базируется на физической платформе, под которой понимается ИС предприятия и система документации менеджмента качества. Деятельность группы В сводится к анализу и проектированию функционирования предприятия. Деятельность группы С основывается на концепциях, включающих мировой опыт по управлению предприятием (ERP-стандарт и стандарт ИСО 9001:2000). Деятельность группы С базируется на концептуальной модели. При нацеленности предприятия на ERP-стандарт, ERP-система является гарантом его реализации. Встает вопрос о возможности предприятия внедрить у себя ERP-систему. И дело здесь не только в большой стоимости ERP-системы, но и в обеспечении предприятием четкой организации работы на базе этой системы. Помимо ERP-системы предприятие может использовать и другие ПО, главное, чтобы они были интегрированы с ERP-системой.
Вышеперечисленные группы деятельности предприятия предполагают взаимосвязанность. Таким образом, модели, используемые в рамках данных групп деятельности предприятия, также должны быть взаимосвязаны (рис. 7.2). Концептуальная модель связывается с логической моделью через использование шаблона на этапе создания логической модели. Логическая модель также имеет связи с физической моделью [47]. Rational Rose позволяет перевести классы логической модели в реляционную модель IDEF1X (ERwin). Средствами ERwin формируется описание структуры базы данных, которое закачивается в базу данных [16]. Средство моделирования Rational Rose совместно с генератором отчетов Rational SoDA позволяет формировать из логической модели отчеты по заранее описанному шаблону с соблюдением бизнес-логики предприятия. Средствами Rational Rose генерируется программный код для клиентской части ИС предприятия. Логическая модель, созданная на базе объектно-ориентированного подхода [46], отражается:
►	в компоненте представления (интерфейс ИС) через прямой или обратный инжиниринг;
глава 7
* Подходы к автоматизации деятельности предприятия
359
Рис. 7.2. Трехуровневая архитектура ИС предприятия
360
Проектирование информационных систем
►	в документации СМК предприятия в серверной части ИС (которая функционирует с использованием сервера приложений) через описание бизнес-логики;
►	в базе данных ИС через реляционную модель.
Таким образом, происходит стыковка трехуровневой архитектуры ИС с бизнес-моделированием деятельности предприятия.
При комплексной реализации трех видов деятельности предприятия (А, В и С) реализуется непрерывное повышение потенциала предприятия, или, другими словами, непрерывное улучшение бизнес-процессов/BPI (Business Process Improvement). BPI подразумевает прохождение следующих этапов, предполагающих использование логического моделирования (рис. 7.3).
1.	Отражение в шаблоне текущего состояния предприятия.
2.	Создание в шаблоне желаемой системы бизнес-процессов предприятия с привлечением передового опыта (IDEF0- и DFD-диаграмм).
3.	Обеспечение реализации на предприятии желаемой системы бизнес-процессов с помощью ERP-системы и системы менеджмента качества (основанной на стандарте ИСО 9001:2000).
4.	Накопление статистики по состоянию бизнес-процессов предприятия, которые относятся к операционному менеджменту (деятельность группы А), и ее анализ для обеспечения эффективной деятельности группы В.
5.	Определение качественных и количественных измерений и оценок бизнес-процессов предприятия для возможности определения факта достижения желаемой системы бизнес-процессов (описанной в шаблоне). Когда результаты оценок бизнес-процессов предприятия не совпадают с заложенными в шаблоне, необходимо возвратиться к этапу 4.
6.	Констатация факта достижения предприятием желаемой системы бизнес-процессов, что означает наличие в шаблоне описания уже текущей деятельности предприятия, а не желаемой. В шаблоне также сохраняется предыдущее текущее состояние предприятия, что позволяет произвести
глава 7
д Подходы к автоматизации деятельности предприятия
361
ЦИКЛ BPI
Рис. 7.3. Этапы логического моделирования
362
Проектирование информационных систем
детальный анализ по быстроте и эффективности достигнутого улучшения. В случае удачного прохождения этапа — выход на 2-й этап, а в случае неудачного прохождения — возвращение к этапам 3, 4, 5.
Прохождение вышеописанных этапов предполагает вхождение предприятия в цикл BPI, обеспечивающий непрерывное улучшение бизнес-процессов предприятия.
В рамках цикла BPI главная роль отводится логическому моделированию. Логическая модель (разработанная на базе шаблона) включает как текущую деятельность для предприятия, так и желаемую (желаемая система бизнес-процессов). Желаемая система бизнес-процессов разрабатывается и достигается с использованием концептуальной модели. Концептуальная модель базируется на передовом опыте управления предприятием (ИСО 9001:2000, ERP, CALS. GAAP, MRPII и т.д.) и создается с помощью методологий структурного анализа [15]. Концептуальная модель (DFD-и IDEFO-диаграммы) может быть разработана внешними компаниями-консультантами.
Значимость концептуальной модели (стандарты ERP и ИСО 9001:2000). Предприятие обеспечивает непрерывное улучшение за счет четкой реорганизации текущих бизнес-процессов в желаемые. IDEF0- и DFD-диаграммы описывают деятельность предприятия в соответствии с требованиями стандартов ERP и ИСО 9001:2000. Первый уровень декомпозиции деятельности предприятия рассматривается как с помощью диаграммы IDEF0, так и диаграммы DFD. IDEFO-диаграмма описывает деятельность групп А и В (на базе стандартов ИСО 9001:2000 и ERP). DFD-диаграмма описывает деятельность группы А (на базе стандарта ERP).
С помощью DFD-диаграммы проверяется полное описание потоков данных при моделировании желаемой системы бизнес-процессов предприятия. Моделирование потоков данных в рамках DFD-диаграммы позволяет увидеть на бумажном носителе взаимодействие всех процессов предприятия, охватываемых ERP-системой. DFD-диаграм
глава 7
^ууодходы к автоматизации деятельности предприятия
363
ма обеспечивает прозрачность и понимание функционирования предприятия на базе стандарта ERP.
Модель IDEF0 (стандарт ИСО 9001:2000). При моделировании желаемой системы бизнес-процессов IDEFO-ди-аграмма привлекается для проверки наличия полного набора документов системы менеджмента качества (СМК), который используется как управляющее воздействие на процессы предприятия. IDEFO-диаграмма отражает мировой опыт по управлению качеством на предприятии на базе стандарта ИСО 9001:2000.
Одним из результатов создания IDEFO-диаграммы является графический скелет документации СМК.
Преобразующие блоки в IDEFO-диаграмме находятся между собой в отношениях иерархической подчиненности: деятельность — процесс — подпроцесс — операция — действие (рис. 7.4).
В IDEFO-диаграмме преобразующие блоки соотносятся с документацией СМК [46].
1	.Деятельность — совокупность бизнес-процессов, характеризующая первый уровень IDEFO-диаграммы. Деятельность преобразует входные потоки в выходные с использованием механизмов при управляющем воздействии со стороны внешней среды (государства, общества), например, стандарта ИСО 9001:2000.
2.	Процесс — преобразующие блоки второго уровня декомпозиции IDEFO-диаграммы соответствуют элементам стандарта ИСО серии 9001:2000. Процессы протекают в соответствии с определенными целями, описанными в руководстве по качеству.
3.	Подпроцессы — преобразующие блоки второго уровня IDEFO-диаграммы соответствуют подэлементам стандарта ИСО серии 9001:2000. Исходя из цели процесса для каждого подпроцесса, входящего в него, определяется цель. Подпроцессы также протекают в соответствии с определенными целями, описанными в руководстве по качеству.
4.	Операция —совокупность последовательно или параллельно выполняемых действий.
364 Проектирование информационных систем
Операции выполняются:
а)	в соответствии с МИКами, являющимися третьим уровнем документации СМК предприятии;
б)	с потреблением ресурсов;
в)	с соблюдением ограничений со стороны других операций и внешней среды при выполнении управляющих воздействий.
Операции, относящиеся к бизнес-процессам «Управление ресурсами» и «Реализация продукции», определяются с использованием DFD-диаграммы. Таким образом, начиная с уровня операций, происходит стыковка стандартов ИСО 9001:2000 и ERP.
5.	Действие — является результатом декомпозиции операций. Действия описываются в инструкциях СМК.
Ограничительная информация
ИС, персонал
Деятельность
Стандарты ISO 9001:2000
Процесс и подпроцессы (элементы и подэлементы стандарта ________ИСО 9000:2000)_______
Руководство по качеству
Операция
______(в соответствии с ERP-стандартами)_ Методические инструкции качества (МИК) Действие
(в соответствии с ERP-стандартом и спецификой предприятия)
Рабочие и должностные инструкции
Рис. 7.4. Преобразующие блоки
IDEFO-диаграмма наглядно представляет взаимопроникновение стандартов ERP и ИСО 9001:2000. Данная диаграмма обеспечивает наглядность, а, соответственно, и лучшее их понимание.
Сущность логического моделирования. Логическое моделирование базируется на ситуационном подходе (используется бизнес-аналитиком) и объектно-ориентированном
Глава 7
Цодходы к автоматизации деятельности предприятия__
подходе (используется аналитиком ИС). Концептуальное моделирование основано на процессном подходе. Присутствие системного подхода наблюдается как в концептуальном, гак и в логическом моделировании (далее — моделирование).
Для облегчения и ускорения процесса моделирования применяется шаблон, созданный внешним консультантом. В шаблоне осуществляется моделирование текущей и планируемой (желаемая система бизнес-процессов) деятельности предприятия. Использование шаблона обеспечивает интегрированность созданной модели и ИС предприятия (ERP-система), что является гарантом слаженной работы бизнес-аналитика и аналитика ИС и получения планируемого эффекта от моделирования.
Моделирование осуществляется в рамках шаблона и сводится к описанию организационной структуры, номенклатуры (услуг), текущих и желаемых бизнес-процессов предприятия. Описания организационной структуры и номенклатуры предприятия являются редко изменяемыми, что позволяет использовать их и на этапе моделирования желаемой системы бизнес-процессов. Моделирование текущих бизнес-процессов предприятия в силу их динамичности нередко ограничивается описанием прецедентов/use case (множество последовательных событий/действий, приводящих К результату) и может не детализироваться вплоть до каждого рабочего места.
В результате процесса моделирования на базе шаблона Предприятие получает модель, описывающую следующие аспекты.
1.	Организационный аспект — топология предприятия ( территориальные площадки, местоположение, единицы оборудования, стеллажи), оргструктура; данный аспект отвечает на вопрос «Кто?» и описывается на стадии проектирования текущего состояния предприятия.
2.	Элементный аспект — номенклатура товара и услуг, спецификации продукции, техкарты изготовления, нормативы по стоимости и длительности изготовления продукции,
366 Проектирование информационных систем
требования к оборудованию и квалификации персонала, тесты для оценки качества изготовления продукции, финансовые и производственные документы и их возможные состояния. Данный аспект отвечает на вопрос «Что?» и описывается на стадии моделирования текущего состояния предприятия.
3.	Функциональный аспект описывает структуру бизнес-процессов. Бизнес-процессы предприятия отражаются в документации СМК и в бизнес-логике ИС предприятия. Данный аспект отвечает на вопрос «Как?» и описывается на стадиях моделирования как текущего состояния предприятия, так и желаемой системы бизнес-процессов предприятия.
Взаимосвязь организационного, функционального и элементного аспектов на нижнем уровне детализации отражается в диаграмме деятельности. Действия на конкретном рабочем месте описываются в рамках конкретного приёма/use case (входящего в конкретный бизнес-процесс и определяющего вариант достижения целей данного бизнес-процесса) с указанием инструкции выполнения, исполнителя, входных и выходных данных. Средство моделирования Rational Rose при описании действий, связанных с ИС, позволяет осуществлять привязку к функции ИС и присоединять описание по работе с данной функцией.
Предприятие имеет следующие выгоды от логического моделирования:
►	анализ процессов на корректность с точки зрения процессного, ситуационного и системного подходов, как следствие — улучшение «некорректных» процессов;
►	сопоставление процессов с процессами идеального предприятия (DFD- и IDEFO-диаграммы), организованное с учетом мирового опыта, как следствие — улучшение процессов на основе бенчмаркинга;
►	анализ дополнительных требований доработки ИС, удовлетворяющих конкретной специфике предприятия; в случае анализа ERP-системы, главным образом, речь идет о формировании дополнительных отчетов;
►	генерирование 2 и 3-го уровней документации системы менеджмента качества при использовании такого сред
Глава 7	з.С-1
ТТ°ДХОДЫ к автоматизации деятельности предприятия_
ства моделирования, как Rational Rose (совместно с генератором отчетов Rational SoDA).
Предложенная методика моделирования И.В. Балахонова помогает предприятию выйти на непрерывное улучшение бизнес-процессов, а также застраховывает его от стандартных проблем моделирования.
Проблемы моделирования и предложения по их решению. Моделирование для предприятия нередко заканчивается тем, что разработанные модели оказываются неактуальными и ненужными. А если учесть, что на создание модели уходит много времени и денег, то такой результат является маловыгодным для предприятия. Причинами такого результата являются:
— наличие нескольких нестыкованных между собой моделей;
—	отсутствие шаблона, что способствует увеличению срока создания модели и ее удорожанию;
—	отсутствие четко сформулированных целей моделирования;
— отсутствие информационной поддержки обеспечения внедрения и функционирования модели на предприятии.
Первая проблема снимается за счет описания в рамках одной модели как текущей, так и желаемой системы биз-нсс-процессов (основанной на объектно-ориентированном моделировании — UML).
Вторая проблема снимается за счет использования шаблона, который основывается на стандартах ИСО 9001:2000 и ERP.
Шаблон определяет типичную модель промышленного предприятия:
► описание оргструктуры стандартного промышленного предприятия: стандартные службы/отделы, олицетворяющие ответственных исполнителей данных служб, а также стандартные должности, существующие на любом промышленном предприятии. Данное описание оргструктуры будет уточнено в процессе моделирования текущего состояния предприятия;
Проектирование информационных систем
► описание бизнес-процессов стандартного промышленного предприятия (элементы и подэлементы ИСО 9001:2000) с последующей их детализацией до конкретных действий на рабочих местах (функции, заложенные в ERP-стан-дарте). Таким образом, обеспечивается легкость моделирования желаемой системы бизнес-процессов, в результате которого описание бизнес-процессов стандартного промышленного предприятия будет уточнено и преобразовано в описание конкретного промышленного предприятия.
В шаблоне не описывается номенклатура предприятия. Это описание добавляется на этапе моделирования текущей деятельности предприятия. При отражении текущего состояния бизнес-процессов необходимо определить его качественную характеристику, например, оценку качества бизнес-процесса с точки зрения потребителя (внутреннего и/или внешнего), численности персонала на данном бизнес-про-цессе, продуктивность бизнес-процесса.
Третья проблема снимается за счет использования базы для моделирования (стандарты ИСО 9001:2000 и ERP).
Четвертая проблема снимается за счет ориентации предприятия с самого начала моделирования на ERP-систему, что в дальнейшем позволяет в полной мере обеспечить контроль и оценку бизнес-процессов предприятия вплоть до конкретных действий на базе ERP-системы. Используя ERP-систему, предприятие решает сразу 3 задачи:
►	информационную поддержку внедрения, контроля и оценки желаемой системы бизнес-процессов;
►	представления организации производства и управления предприятием на базе ERP-стандарта, полностью или частично покрывающего стандарт ИСО 9001:2000 (полностью покрываются элементы «Управление ресурсами» и «Реализация продукции»);
►	интеграции процессов предприятия.
Использование предложенной в главе методики моделирования определяет мост между концептуальной и физи
r?LBa 7	ябо
 | |одходы к автоматизации деятельности предприятия__
ческой моделями предприятия, что является главным фак-к>ром в поддержании непрерывного улучшения бизнес-процессов (цикл BPI).
гя
Г | Контрольные вопросы
1.	Перечислить основные виды процессов автоматизации.
2.	Дать определение процессу интеграции. Охарактеризовать процесс интеграции для подсистем обеспечения информационной системы.
3.	Перечислить основные цели и средства функциональной интеграции.
4.	Охарактеризовать этапы планирования процесса автоматизации.
5.	Какие ограничения накладываются на каждый этап планирования?
6.	Дать определение понятию «реорганизация деятельности предприятия».
/. Перечислить и охарактеризовать основные подходы к реорганизации.
8.	Что определяет стандарт на качество проектирования, разработки, изготовления и послепродажного обслуживания ISO 9000? Какова его роль и место в проектировании информационных систем?
9.	Какие методы позволяют оценить деятельность предприятия и каковы основные этапы выполнения оценок?
10.	Охарактеризовать нотации, применяемые для моделирования бизнес-процессов организации.
11.	В чем заключается сущность проекта внедрения информационных технологий?
12.	Перечислить основные этапы логического и физического моделирования информационных систем.
13.	Какова значимость трехуровневой архитектуры ИС при моделировании деятельности предприятия?
Математические
И МЕТОДОЛОГИЧЕСКИЕ
АСПЕКТЫ ПРОЕКТИРОВАНИЯ
ИНФОРМАЦИОННЫХ СИСТЕМ
Процесс проектирования ИС требует от проектировщика принятия решения на каждом этапе создания ИС, когда встает вопрос выбора той или иной альтернативы: моделей ЖЦ ИС; типов проектирования; методологий, методов, технологий и нотаций проектирования; средств моделирования ИС и разработки АИС и т.д. Применение математических методов принятия решений позволяет осуществить выбор ‘оптимального и эффективного решения, соответствующего предъявляемым требованиям. От моделей выбора проектных решений и формирования проектных предпочтений, методик функционально-объектного анализа проекта и проектирования ИС зависят эффективность создаваемой системы, ее функциональная полнота и достаточность про-граммно-технических решений [23].
Основополагающая концепция проектирования ИС состоит в построении совокупности логических моделей предметной области при помощи соответствующих методов анализа, которые дали бы возможность пользователям, аналитикам и разработчикам получить ясную общую картину проекта, а также обеспечшш бы естественный переход к логической модели будущей ИС. Процесс проектирования ИС требует концентрации усилий на двух начальных этапах ес жизненного цикла — анализе (определение того, что должна делать система) и проектировании (определение того, как система будет делать то, что она должна делать). Проектирование — это, прежде всего, спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе. Остальные этапы разработки, тестирования и внедрения ИС обозначаются единым, объемлю-
Глава 8	а71
“Математические и методологические аспекты проектирования
щнм термином — реализация. На стадии анализа и проек-шрования осуществляется создание усовершенствованной обобщенной логической модели, отображающей реоргани-юванную предметную область или ее часть, которая под-исжит автоматизации. Модель является не просто реализацией начальных этапов работы и основанием для формирования технического задания на ее последующие этапы. Она представляет собой самостоятельный результат, имеющий большое практическое значение. Развитие логической модели предметной области, ее последовательное превращение в модель целевой ИС, позволит сформировать видение новой, реорганизованной и автоматизированной деятельности предприятия. Применение математических методов моделирования в процессе проектирования ИС, вчаст-иосги, методов моделирования на основе сетей Петри, дает возможность оценить адекватность и продуктивность создаваемых моделей, от которых зависит не только точность формируемых требований к ИС, но и сама возможность успешной реализации проекта. Это позволит избежать главной ошибки, совершаемой при проектировании ИС, когда ПС создается как бы «сама по себе» и оценивается не повышение эффективности работы организации от внедрения ИС, М эффективность работы собственно ИС.
8.1. Модели выбора проектных решений
Выбор проектного решения [23] — сложный технологический процесс, который можно определить как выбор разра-Гю । пиком обеспечивающего сервиса для удовлетворения информационных потребностей заказчика. В концептуальном плане для описания этого процесса используются классические, поведенческие и нечеткие модели принятия решений. Согласно каждой из этих моделей, разработчик не сравнивает непосредственно альтернативы: он выбирает их либо с помощью таких учитываемых в поведенческой модели факторов, как конечный эффект или желаемый уровень
3^2 Проектирование информационных систем’
поведения, либо на основе функций выигрыша, как в классическом случае. Исход, соответствующий каждой альтернативе, это результат сложного сплетения всех переменных, описывающих внешние условия со всеми переменными, характеризующими проектную альтернативу.
Однако чем более аморфна проблема, тем труднее становится правильное предсказание этих переменных и, в конечном итоге, исхода. В этих условия субъект обычно абстрагирует проблему и строит простую модель, а затем полученным из анализа модели исходом подменяет непредсказуемый исход первичной проблемы.
Любой выбор связан с процессом обработки информации об альтернативах, о критериях качества, о возможных исходах, о системах предпочтений и способах отображения множества допустимых альтернатив в множество критериальных оценок возможных исходов.
В классическом варианте теория принятия проектных решений тесно связана или с исходом желаемых уровней, или с выигрышем. Семантическая сущность этих теорий заключается в интерпретации количественных значений выигрышей. В классической модели разработчик с помощью действительно-значной функции выигрыша назначает каждой альтернативе действительное число. Для разработчика не составляет труда выбрать проектную альтернативу, когда каждой из них поставлен в соответствие только один выигрыш: выбор проектного решения в условиях определенности.
Однако, как правило, разработчик не обладает полным знанием об информационных и телекоммуникационных услугах, требующихся заказчику. Следовательно, каждой альтернативе ставится в соответствие несколько выигрышей. Выбор в таких условиях называется принятием решения или в условиях риска, или в условиях неопределенности. Решение принимается в условиях риска в случае, если разработчик знает возможные исходы состояния обеспечивающей среды проектирования и разработки и распределение их вероятностей. Если разработчик знает возможные состояния обеспечивающей среды проектирования и разработки,
Fnaea 8
1 Математические и методологические аспекты проектирования
ни „с знает распределения их вероятностей, то решение принимается в условиях неопределенности.
Различие между классической и поведенческой моделями выбора проектных решений заключается в способе упорядочения возможных альтернатив: в классической модели пиьтсрнативы упорядочиваются по отношению неравенства, в в поведенческой модели — по отношению включения.
Для исследования семантических аспектов процедур выбора проектных решений целесообразно исследовать аксиоматическую (классическую) теорию.
В семантическом плане, разработчик должен устранить расхождение между промоделированным исходом и исходом реальной проблемы. Один из проверенных временем методов для этой цели заключается в «размывании» вычисленного исхода. В этом случае классическая (четкая) ситуация представляется субъектом в нечетком, размытом виде. Образ действия, с помощью которого он «размывает» ситуацию, зависит от таких факторов, как способ моделиро-ииння проблемы и предубежденность разработчика при неполной информации.
I 1счсткое утверждение более пригодно для решения сложных проблем объектного проектирования и более адекватно о тражает семантическую сущность анализируемых разработчиком понятий и утверждений.
8.1.1. Классическая модель принятия решениг1
Среди методов классического подхода наибольшей универсальностью обладают следующие.
I.	Методы теории полезности [73]. Теория многомерной Полезности позволяет для задач в условиях риска и неопределенности получить функцию многомерной полезности, Мнксимальное значение которой соответствует наиболее Предпочтительному варианту. Многомерная функция полезности обычно получается как аддитивная или мультипликативная комбинация одномерных функций, которые строится на основании опроса экспертов и позволяют провести
Проектирование информационных систем ранжирование возможных исходов без взаимного сравнения альтернатив. При этом делается допущение о взаимной независимости критериев по полезности. Процедура построения функции полезности требует привлечения значительных объемов информации и является достаточно трудоемкой. Достоинством этого подхода является возможность оценки любого количества альтернативных вариантов с использованием полученной функции. В случае неустойчивой исходной информации применение методов теории полезности становится малоэффективным.
2.	Метод анализа иерархий [74]. Метод анализа иерархий (МАИ), предложенный Т.Л. Саати, основан на парных сравнениях альтернативных вариантов по различным критериям с использованием девятибалльной шкалы с последующим ранжированием набора альтернатив по всем критериям и целям. Взаимоотношения между критериями учитываются путем построения иерархии критериев с применением парных сравнений для выявления важности критериев и подкритериев. Метод отличается простотой и дает хорошее соответствие интуитивным представлениям. Главным недостатком этого подхода является большое количество требуемой экспертной информации, которая представляет собой множество оценок предпочтительности, полученных в процессе парного сравнения альтернатив и критериев. Метод имеет ограничение на количество одновременно сравниваемых альтернатив (не рекомендуется больше 9). Это связано с установленным психологами фактом, что обычному человеку трудно осуществлять рациональный выбор, если число объектов выбора превышает 7 ± 2. Благодаря простоте метод хорошо подходит для решения динамических ЗПР, при этом возникают новые возможности для оценки последствий принимаемых решений.
3.	Методы теории проспектов. Проспект — это игра с вероятностными исходами. В методах теории проспектов учитывается 3 поведенческих эффекта:
►	эффект определенности—тенденция придавать больший вес детерминированным исходам;
I'/hlBd 8	Ч7Ч
* Математические и методологические аспекты проектирования
►	эффект отражения — к измерению предпочтений при переходе от выигрышей к потерям;
►	эффект изоляции — тенденция к упрощению выбора путем исключения общих компонент вариантов решения. Методы теории проспектов, так же, как и предыдущие методы, имеют аксиоматические основы. Главным недостатком всех перечисленных аксиоматических теорий является непроверяемый характер аксиом, что означает на практике требование к человеку принимать на веру правила рацио-Налыюго поведения, вытекающие из той или иной теории.
4.	Эвристические методы. К эвристическим методам относят следующие методы:
► метод взвешенной суммы оценок критериев. Каждой альтернативе дается числовая (балльная) оценка по каждому из критериев. Критериям приписываются количественные веса, характеризующие их сравнительную важность. Веса умножаются на критериальные оценки, полученные числа суммируются—так определяется ценность альтернативы. Далее выбирается альтернатива с наибольшим показателем ценности;
» истод компенсации. Данный метод используется при попарном сравнении альтернатив.
Достоинством всех эвристических методов является простота и удобство, а основным недостатком то, что все они НС имеют научного обоснования.
5.	Методы теории нечетких множеств. Теория нечетких множеств позволяет представить знания о предпочтительности альтернатив по различным критериям с помощью нечетких множеств. Формирование нечетких множеств ИИляется более простой и менее трудоемкой процедурой, чем построение функций полезности. Для выявления лучших вариантов по совокупности критериев необходимо име ть в распоряжении информацию о важности критериев и । инах возможных отношений между ними. Теория нечетких множеств предоставляет различные средства для учета иааимных отношений критериев: использование весовых
Проектирование информационных систем
376 коэффициентов, нечеткие отношения предпочтения, нечеткий логический вывод на правилах определения лучшей альтернативы и т.д. [75].
8.1.2.	Модели нечеткого выбора.
Модель формирования проектных предпочтений
Процессы проектирования и разработки информационно-телекоммуникационных систем неустойчивы и сложны и поэтому характеризуются нечеткостью в исходе и выигрыше каждой альтернативы, а также в желаемом уровне обеспечения сложности проектируемой системы или уровне удовлетворенности заказчика [23]. Формулировка классической и поведенческой моделей принятия нечетких решений получается «размыванием» соответствующих классических моделей, а также определением отношений неравенства между нечеткими действительными числами и включения между нечеткими подмножествами.
Подавляющая часть моделей выбора проектных решений носит нормативный характер и представляет собой формализацию этапа выбора, когда множество альтернатив, критерии целей и ограничения, отношения предпочтения и пр. считаются заданными. Модели выбора в нечетких условиях можно разбить на достаточно независимые группы: по числу этапов или степени динамики (одноэтапные или многоэтапные), по числу лиц (ЛПР), принимающих решения (индивидуальные или коллективные), по числу используемых критериев (однокритериальные и многокритериальные).
Различные формы описания исходной информации обусловливают существование различных моделей нечеткого математического программирования [23]:
►	модели достижения нечетко поставленной цели при нечетких ограничениях, при которых нечеткое решение задачи определяется в результате слияния нечетких целей и ограничений;
►	модели при нечетком множестве допустимых альтернатив, когда нечеткая цель рассматривается как обобщен
Глава 8
^Математические и методологические аспекты проектирования
ная форма заданного критерия качества, причем ее функция принадлежности вводится на основе нормализации этого (ограниченного) критерия качества с сохранением линейного порядка;
►	нечеткий вариант стандартной модели математического программирования со «смягчением» целевой функции и/или ограничений, в котором вместо задачи оптимизации решается задача удовлетворения цели и соответствующие неравенства для целевой функции и ограничений могут нарушаться;
►	модель программирования с нечеткими коэффициентами, в которой коэффициенты моделируются с помощью нечетких чисел.
В лингвистических моделях принятия решения формализация качественной информации осуществляется за счет введения лингвистических отношений предпочтения, критериев, весов, полезностей, лотерей, кванторов и т.д. Имеющаяся у разработчика информация предоставляется с помощью лингвистических переменных.
Модель формирования проектных предпочтений
Метод построения модели формирования проектных предпочтений предложен Н.Т. Клещевым и А.А. Романовым [23].
Рассматриваемая модель предназначена для разделения объектов обеспечивающего сервиса проектирования и разработки в целях «покрытия» информационных потребнос-। ей заказчика в условиях, когда исходная информация при проектировании по своей природе неполна и процедуры формализации информационных потребностей заказчика неточны. Основным понятием для предлагаемой модели служит разделение объектных предпочтений в обеспечивающем сервисе проектирования и разработки.
В модели разделения обеспечивающего сервиса приня-। ы следующие допущения:
►	существование спроса на обеспечивающий сервис разработчика;
378
Проектирование информационных систем
►	произвольная схема клиентских потребностей;
►	существование т типовых программно-технологических подсистем Fp F2,..., Fm разработчика;
►	предлагаемые обеспечивающие услуги одного качества;
►	обеспечивающие услуги программно-технологических
подсистем, характеризующиеся р признаками;
►	степени важности признаков при выборе обеспечивающей услуги, варьируемые между программно-технологическими подсистемами;
►	предпочтительные услуги одной подсистемы по сравнению с другой, если ее признаки по своей степени важности более близки к оценке клиента.
Пусть У' = {у]', у2,у'р}— неформализованный разработчиком спрос клиента на типовые обеспечивающие услуги; X - {хр х9, ..., хп} — формализованный разработчиком спрос клиента на типовые обеспечивающие услуги; У = {ур у2, ..., ур} — множество обеспечивающих услуг типовых программно-технологических подсистем разработчика; Z = {ZpZ,, zm} — множество типовых программно-технологических подсистем разработчика.
Пусть Фр. Хх Y — [0, 1] есть функция принадлежности нечеткого бинарного отношения R. Для всех xg X и всех у G У функция Фр(х, у) — степень важности для клиента обеспечивающей услуги у по оценке разработчика в приложении реализации технологической услуги х.
Отношение R можно представить в матричной форме:
У1 Ут. ••• УР
xj	фл(хиУ1)	ф/?(Д,У2)	-	фк(хъУр)
х2	Фк(х2’У0	фк(х2,у2)	-	фк(х2,ур)
хп	Фк(хп,ух)	ФЛ(х„,у2)	-	Фк{хп,ур)
Пусть л: yxZ—>[0,1] есть функция принадлежности нечеткого бинарного отношения 5. Для всех yG У и всех zg Z
глава 8
Математические и методологические аспекты проектирования Э/у
л (у, z ) равно степени принадлежности или совместимости типовой программно-технологической подсистемы z с обеспечивающей услугой у. В матричной форме соотношение имеет вид:
Z\	Z2		zm
M^Zl) ^5(y2,Z2) - %(y2,ZOT)
• (°-А)
ns(yP^i) %(Ур,г2) ... ns(yp,zm)
У1
= У2
Уп
Теперь можно получить матрицу:
xi Ka'iUi>Zi) Ba'2CW2) -
H4'2<>2-Z2)	- VA'n(x2’Zm)
(8-3)
Ba'i(*2>Zi)
xn kxn ’ ) №a'2	’ ^2) №а'п (xn’ zin)
элементы которой определяются функцией принадлежности
~	--------•	(8-4)
ЛФ^(%’Т)
у
Сумма ^Фк(х,у) равна степени нечеткого подмноже-у
етва, указывающей число важнейших обеспечивающих услуг у, которое используется для оценки программно-технологической подсистемы z относительно проектирования технологической услуги х, а Цд'/х, zz) можно интерпретировать как взвешенную степень предпочтения программно-технологической подсистемы z для проектирования технологической услуги х. Функция предпочтения должна удовлетворять определению выпуклого нечеткого подмножества:
Проектирование информационных систем
380 mb-
zi)+(1 “ Л)(х2, z/)l-
>min[gАЧ(х}z(), H/z[X(x2>z)]],	(8-5)
для всех X] и х2, всех zze Z, всех Ле [0,1].
Поскольку все Цд'Дл), zz) выпуклые, их пересечения также выпуклые функции. Таким образом, можно построить матрицу IV:
Z|	Z2 ...	Zm
*1ГМд'1(*1>2|)л Ma-2U1,Z2) - Цл'га |(^-7„>-1)лЦл-т(^,2и)
Х2 Цлт(ад)лрЛ'2(Д2,г2) ... МА'^|(Л2.^н)лЦА'т0^)
W =	.(о.о)
_Мл'1 (хп ’ Т ) л Мл'2 (хп ’ Z2) - Мл'1л-1 (х>1 , Z,n-l У^А'т&п ’?т\
Порог разделения обеспечивающего сервиса может быть ограничен условием:
/ < nain(7 maxv min [цЛ-(х, zz), рА-(х, Zj) ].	(8.7)
Если порог I выбран, то обеспечивающий сервис Мр i=l,2, .... т описывается уровневым множеством:
Mi ~ I p^U'Rmm^max^infp^x, zz), цЛ^х, z;)] для всех хе М.	(8.8)
Рассмотрим пример, иллюстрирующий практическое использование метода разделения обеспечивающего сервиса разработчика по проектируемому технологическому сервису клиента.
♦ Пример [23]
Пусть Q = {(o1,co2,...,co12} — множество технологических услуг разработчика; Д = {б,, 32,З3,34} — множество технологических услуг, требуемых клиенту; X = {хр х2,.... х]2} — множество услуг обеспечивающего сервиса клиента; Y = {у}, у2, у3, у4} — множество услуг обеспечивающего сервиса в типовых программно-технологических подсистемах Z = {z}, z2, z3, z4} разработчика; yz — обеспечение распределенных
глава 8	,Я1
•[Математические и методологические аспекты проектирования
приложений; у2 — обеспечение протоколов TCP/IP; у3 — обеспечение текстового процессора; у4 — обеспечение графических диаграмм.
Пусть матрица R нечеткого бинарного отношения имеет вид:
У2	Уз	У4
ООО
1	О	О
О	1	о
О	0	1
1	1	1
0,4 0,5 0,9 0,3 0,4 0,8 0,8 0,8 0,2 0,5 0,5 0,5 0,7 0,8 0,5 0,1 0,1 0,1
В этой матрице элементы каждой строки выражают относительные степени важности услуг обеспечивающего сервиса разработчика для проектирования услуг обеспечивающего сервиса клиента, поддерживающего его технологический сервис. Например, для клиентских обеспечивающих услуг Хр х2, х3, х4 обеспечивающие услуги разработчика с наибольшими значениями не только важны сами по себе, ио это единственные услуги, которые учитываются при проектировании соответствующих обеспечивающих услуг клиента. С другой стороны, при проектировании обеспечивающей услуги х8 клиента наивысший приоритет имеют обеспечивающие услуги у2 и у3 разработчика, в то время как для проектирования услуги xg необходим весь обеспечивающий сервис разработчика.
Пусть элементы каждого столбца матрицы S представляют степени принадлежности или совместимости программно-
382
Проектирование информационных систем
технологической подсистемы разработчика с соответству-
ющими обеспечивающими услугами:				
	Z1	z2	Z3	z4
У1	0,9	0,1	0,5	0,7
С_У2 0 —	0,5	0,9	0,6	0,6
Уз	0,4	0,9	0,5	0,4
У4	0,8	0,1	0,5	0,6
Например, подсистема z, обеспечивает достаточно хорошее проектирование и разработку клиентских распределен-
ных приложений и графических диаграмм, но средние воз-
можности для проектирования и разработки протоколов
передачи данных и текстовых процессоров, в то время как подсистема z2 характеризуется низкими возможностями для проектирования и разработки клиентских распределенных приложений и графических диаграмм, но достаточно хорошими возможг остями в части проектирования и разработки протоколов передачи данных и текстовых процессоров.
Используя ранее полученные соотношения, формируем матрицу Т:
zi		z2	z3	z4
x\	0,9	0,1	0,5	0,7
x2	0,5	0,9	0,6	0,6
x3	0,4	0,9	0,5	0,4
x4	0,8	0,1	0,5	0,6
x5	0,65	0,5	0,525	0,575
T=x6	0,708	0,377	0,515	0,592
*2	0,717	0,355	0,514	0,595
x8	0,578	0,657	0,535	0,552
	0,65	0,5	0,525	0,575
*10	0,619	0,562	0,527	0,562
*11	0,65	0,5	0,525	0,575
Глава 8 •Математические и методологические аспекты проектировани							я_383
Наконец из матрицы			Т получаем матрицу			W:	
	0,1	0,5	0,7	0,1	0,1	0,5	
	0,5	0,5	0,5	0,6	0,6	0,6	
	0,4	0,4	0,4	0,5	0,4	0,4	
	0,1	0,5	0,6	0,1	0,1	0,5	
	0,5	0,525	0,575	0,5	0,5	0,525	
W =	0,377	0,515	0,592	0,377	0,377	0,515	-
	0,355	0,514	0,595	0,355	0,355	0,514	
	0,578	0,535	0,552	0,535	0,552	0,535	
	0,5	0,525	0,575	0,5	0,5	0,525	
	0,562	0,527	0,562	0,527	0,562	0,527	
	0,5	0,525	0,575	0,5	0,5	0,525	
Очевидно, что 0,535 — минимальная из подсчитанных величин. Теперь из матрицы Т выбираем для I наиболее возможное значение, которое было бы меньше 0,535, и покупаем, что I = 0,527. Применяя это значение в качестве порога разделения обеспечивающего сервиса разработчика, определяем, какие типовые программно-технологические подсистемы необходимы для проектирования и разработки обеспечивающего сервиса клиента:
Mj={xp х4, х5, х6, х7, xg, х9, х10, х„},
М2-{х2, х3, xs, х10},
М3={х2, xg, х10},
М4={Хр Х2, Х4, Х5, х6, Х7, xg, Х9, XW, х„}.
Вследствие особенностей программно-технологической подсистемы z„ которые отмечались ранее, ее услуги необходимы для проектирования и разработки большинства обеспечивающих услуг клиента, который придает особенно важное значение протоколам передачи данных и текстовым процессорам. Общая низкая совместимость подсистемы z3 со всеми обеспечивающими услугами разработчика
384 Проектирование информационных систем
также ограничивает ее возможности для применения в проектируемых обеспечивающих услугах клиента. Хотя подсистемы Z] и z2 весьма схожи по своим обеспечивающим услугам, высокая степень совместимости подсистемы zA с обеспечивающими услугами по проектированию и разработке распределенных приложений и графических диаграмм делает ее более привлекательной для клиента. Таким образом, за исключением обеспечивающей услуги х2 обеспечивающий сервис клиента может быть спроектирован и разработан на базе подсистемы zr Перекрытие проектируемых обеспечивающих услуг клиента появляется всякий раз, когда две типовые программно-технологические подсистемы разработчика схожи или эквивалентны по своей возможности для проектирования и разработки.
8.2.	Разработка модели системы
на основе сетей Петри
Под моделированием будем понимать исследование объекта посредством изучения его модели. Сложность моделируемого объекта зависит от целей моделирования и уровня, на котором выполняется описание. Таким образом, сложность возрастает не только при введении в рассмотрение новых качеств, но и при переходе к более детальному описанию процесса функционирования объекта моделирования, т.е. информационной системы. Модель — это представление, как правило, в математических терминах того, что считается наиболее характерным в изучаемом объекте или системе. Ожидается, что, манипулируя представлением, можно получить новые знания о моделируемом явлении, избегая необходимости манипулирования самим реальным явлением.
Метод анализа на основе сетей Петри получил достаточно широкое распространение при проектировании ИС. Интеграция получаемых при данном анализе моделей с расширенными реляционными моделями позволяет описы-
глава 8
‘Математические и методологические аспекты проектирования нать сложные процессы взаимодействия сущностей предметных областей информационных систем.
Возможны несколько путей практического применения сетей Петри при проектировании и анализе систем. В одном из подходов сети Петри рассматриваются как вспомогательный инструмент анализа. Здесь для построения системы используются общепринятые методы проектирования. Чатем построенная система моделируется сетью Петри, и модель анализируется. В этом общепринятом подходе использования сетей Петри в проектировании требуется постоянное преобразование проектируемой системы в модель в виде сети Петри. Можно предложить другой, более радикальный подход, в котором весь процесс проектирования и определения характеристик проводится в терминах сетей 11стри. Методы анализа применяются только для создания проекта сети Петри, свободного от ошибок. Здесь задача •включается в преобразовании представления сети Петри в реальную рабочую систему.
Моделирование с использованием сетей Петри осуществляется на основании статической функциональной и частично информационной моделей. Существуют инструментальные средства (например, Design/CPN для SADT и CPN-AMI, INCOME для DFD), которые осуществляют автоматическое преобразование функциональных моделей в прообразы сетей Петри.
Разработанные модели позволяют описать и проанализировать:
►	механизмы взаимодействия процессов (последовательность, параллелизм, альтернатива);
►	временные отношения между выполнениями процессов (одновременность, наложение, поглощение, одинаковое время запуска/завершения и т.п.);
►	абсолютные времена (длительность процесса, время запуска, зависимости от времени выполнения процесса и др.);
►	управление исключительными ситуациями, определяемое нарушениями.
13. Зак. 1035
386 Проектирование информационных систем
Построенные модели позволяют осуществлять следующие операции:
►	статический анализ системы (компоненты сети, иерархия сети, соответствие типов);
►	динамический анализ системы для конкретного маркирования сети;
►	имитационное моделирование системы с построением графиков движения маркеров относительно позиций сети в системном времени, определяемом моментами срабатывания переходов, и в реальном времени путем задания для переходов задержек времени, отображающих продолжительность реальных операций.
При моделировании с использованием сетей Петри в процессе проектирования информационных систем необходимо остановиться на изучении стандарта сети Петри [71], включающего: структуру и маркировку сетей, правила выполнения сетей, их особенности при моделировании ИС, методы анализа сетей.
8.2.1. Стандарт сети Петри
Сети Петри (СП) и их многочисленные модификации являются одним из классов моделей, неоспоримым достоинством которых является возможность адекватного представления не только структуры сложных организационнотехнологических систем и комплексов, но также и логиковременных особенностей процессов их функционирования. Сети Петри представляют собой математическую модель для представления структуры и анализа динамики функционирования систем в терминах «условие — событие».
Модели сетей Петри позволяют исследовать работоспособность моделируемых систем, оптимальность их структуры, эффективность процесса их функционирования, а также возможность достижения в процессе функционирования определенных состояний. Сети Петри и их обобщения являются удобным и мощным средством моделирования асин-
 лысо и
"•Математические и методологические аспекты проектирования
хронных, параллельных, распределенных и недетерминированных процессов, позволяют наглядно представить динамику функционирования систем и составляющих их элементов. Свойства иерархического вложения сетей Петри позволяют рассматривать модели различной степени детализации, обеспечивая тем самым необходимую композицию сложных систем и процессов.
Структура сети Петри. Сеть Петри С является четверкой: С = (Р, Т, I, О). Р = {рх,р2, -,Рп} — конечное множество позиций, п>0. Т - {/], /2, ..., /т} — конечное множество переходов, m > 0. Множество позиций и множество переходов не пересекаются, РПТ = 0. I :Т Р°° является входной функцией — отображением из переходов в комплекты позиций. О:Т —>Р°° есть выходная функция — отображение из переходов в комплекты позиций.
Существует следующее определение входной и выходной функций переходов: I — входная функция переходов, которая определяется как отображение I: Рх T^>N0; О — выходная функция переходов, которая определяется как отображение О : Рх P-^NQ, где NQ — множество натуральных чисел и ноль.
♦ Пример________
С = (Р, Т, I, О), Р = {pvp2, р3,р4,р5}, Т= {Zp t2, t3, t4}, = ОМ’	= (Рг’Рз’Рз}’
— {P2’ Py P^ >	~ {P5},
J(t3) = {p3},	O(t3) = {p4},
AQ = W’	Рз)-
Графическое представление сети Петри. Структура сети Петри представляет собой совокупность позиций и переходов. В соответствии с этим граф сети Петри обладает двумя кипами узлов. Кружок О является позицией, а планка | — переходом.
Ориентированные дуги (стрелки) соединяют позиции и переходы, при этом некоторые дуги направлены от позиций
13*
388
Проектирование информационных систем
к переходам, а другие — от переходов к позициям. Дуга, направленная от позиции р(. к переходу определяет позицию, которая является входом перехода. Кратные входы в переход указываются кратными дугами из входных позиций в переход. Выходная позиция указывается дугой от перехода к позиции. Кратные выходы также представлены кратными дугами.
Граф G сети Петри есть двудольный ориентированный мультиграф (рис. 8.1), G = (И, А), где И = {vp v2,..., у } — множество вершин, а А = {ар а2,аг} — комплект направленных дуг, а(. = (Vj, vk), где v., vke V. Множество V может быть разбито на два непересекающихся подмножества Р и Г, таких, что V= P\JT\ Р(]Т = 0, и для любой направленной дуги я. О А, если о,. = (у., у,), тогда либо у.е Р и у. е Т, либоу^ау^Р.	1	J
Маркировка сетей Петри. Маркировка ц есть присвоение фишек позициям сети Петри. Фишка — это примитивное понятие сетей Петри (подобно позициям и переходам). Фишки присваиваются (можно считать, что они принадлежат) позициям. Количество и положение фишек при выполнении сети Петри могут изменяться. Фишки используются для определения выполнения сети Петри.
Pi
Рз
Рис. 8.1. Граф сети Петри
Глава 8
^Математические и методологические аспекты проектирования
Маркировка р сети Петри С = (Р, Т, I, О) есть функция, отображающая множество позиций Р в множество неотрицательных целых чисел N \i:P^N . Маркировка р может быть также определена как вектор р = (Р|,р2,...,Ни), гДе п = 1Л и каждое р( е N, i = 1,п. Вектор р определяет для каждой позиции р. сети Петри количество фишек в этой позиции. Количество фишек в позициир( есть pz, i = 1,п.
Связь между определениями маркировки как функции и как вектора очевидным образом устанавливается соотношением р(р;) = р,-
Маркированная сеть Петри М =(С, р) есть совокупность структуры сети Петри С = (Р, Т, I, О) и маркировки р и может быть записана в виде М = (Р, Т, I, О, р). На графе сети Петри фишки изображаются маленькой точкой в кружке, который представляет позицию сети Петри. На рисунке 8.2 приведен пример графического представления маркированной сети Петри.
Правила выполнения сетей Петри. Сеть Петри выполняется посредством запусков переходов. Переход запускается удалением фишек из его входных позиций и образованием
390
Проектирование информационных систем
новых фишек, помещаемых в его выходные позиции. Переход может запускаться только в том случае, когда он разрешен. Переход называется разрешенным, если каждая из его входных позиций имеет число фишек, по крайней мере, равное числу дуг из позиции в переход.
Переход zy.e Тв маркированной сети Петри С = (Р, Т, I, О) с маркировкой р разрешен, если для всехр£ Р Ц (/г) > #(д? 7(Zy)).
Переход запускается удалением всех разрешающих фишек из его входных позиций и последующим помещением в каждую из его выходных позиций по одной фишке для каждой дуги. Кратные фишки создаются для кратных выходных дуг. Запуск перехода в целом заменяет маркировку р сети Петри на новую маркировку р'. Если какая-либо входная позиция перехода не обладает достаточным количеством фишек, то переход не разрешен и не может быть запущен.
Переход ^.в маркированной сети Петри с маркировкой р может быть запущен всякий раз, когда он разрешен. В результате запуска разрешенного перехода tj образуется новая маркировка р', определяемая следующим соотношением:
В (Р,) = М (Р() ~	Д(/)) +	О(/у)).
В качестве примера рассмотрим маркированную сеть Петри, изображенную на рисунке 8.3. При такой маркировке разрешены только три перехода: Zp t3 и t4. Переход t2 не разрешен, так как ни позиция ни позиция р3, являющиеся входами перехода Z2, не содержат ни одной фишки. Так как переходы t3 и Z4 разрешены, любой из них может быть запущен. Если запущен переход 14, то происходит удаление фишки из каждого входа и помещение фишки в каждый выход. При этом одна фишка удаляется изр5, одна фишка помещается в р3, а количество фишек в р4 увеличивается с двух до трех. Новая маркировка, полученная в результате запуска перехода t4, показана на рисунке 8.4.
В маркированной сети Петри, изображенной на рисунке 8.4, разрешены только переходы Z} и ty При запуске пе-
глава 8
^Математические и методологические аспекты проектирования
391
рехода осуществляется удаление фишки из рх и помещение фишек в р2, р3 и р4 (в р4 — две фишки, так как эта позиция является кратным выходом перехода tj. Эта операция образует маркировку, приведенную на рисунке 8.5.

Рис. 8.3. Маркированная сеть Петри для иллюстрации правил запуска: переходы tjr t3 и t4 разрешены
Рис. 8.4. Маркировка, полученная в результате запуска перехода t4 в сети на рисунке 8.3
Проектирование информационных систем
Рис. 8.5. Маркировка, полученная при запуске перехода в сети на рисунке 8.4
Запуски могут осуществляться до тех пор, пока существует хотя бы один разрешенный переход. Когда не останется ни одного разрешенного перехода, выполнение прекращается.
Пространство состояний сети Петри. Состояние сети Петри определяется ее маркировкой. Запуск перехода изменяет состояние сети Петри посредством изменения маркировки сети. Пространство состояний сети Петри, обладающей п позициями, есть множество всех маркировок, т.е. N”. Изменение в состоянии, вызванное запуском перехода, определяется функцией изменения 5, которую мы назовем функцией следующего состояния. Когда эта функция применяется к маркировке Ц (состоянию) и переходу tj (он должен быть разрешен), она образует новую маркировку (состояние), которая получается при запуске перехода t. в маркировке р,.
Пусть дана сеть Петри С = (Р, Т, I, О) с начальной маркировкой р°. Эта сеть может быть выполнена последовательными запусками переходов. Запуск разрешенного перехода в начальной маркировке образует новую марки
рлава 8
^Математические и методологические аспекты проектирования
ровку р1 = 8(р°, tj). В этой новой маркировке можно запустить любой другой разрешенный переход, например tk, образующий новую маркировку р2 = 8(р*,^). Этот процесс будет продолжаться до тех пор, пока в маркировке будет существовать хотя бы один разрешенный переход. Если же получена маркировка, в которой ни один переход не разрешен, то никакой переход не может быть запущен, функция следующего состояния не определена для всех переходов и выполнение сети должно быть закончено.
При выполнении сети Петри получаются две последовательности: последовательность маркировок (р°, р1, р2,...) и последовательность переходов, которые были запущены (Гд), tjV tj2, ...). Эти две последовательности связаны следующим соотношением: 8(р*,tjk) = рЛ+1 для к - 0, 1, 2, ... . Имея последовательность переходов р, легко получить последовательность маркировок сети Петри, а имея последовательность маркировок, легко получить последовательность переходов, за исключением нескольких вырожденных случаев. Таким образом, обе эти последовательности представляют описание выполнения сети Петри.
Удобно распространить функцию следующего состояния на отображение маркировки и последовательности переходов в новую маркировку. Для последовательности переходов (Z^, /2,..., t-k) и маркировки р маркировка р' = 8(р, Гу1, tj2,..., tjk ) есть результат запусков: сначала — затем —1}2 и т.д. до tjk. (Такая операция, конечно, возможна только в том случае, если каждый переход к моменту его запуска разрешен.)
8.2.2. Использование сети Петри
для моделирования
Простое представление системы сетью Петри основано на двух основополагающих понятиях: событиях и условиях. События — это действия, имеющие место в системе.
394
Проектирование информационных систем
Возникновением событий управляет состояние системы. Состояние системы может быть описано множеством условий. Условие — есть предикат или логическое описание состояния системы. Условие может принимать либо значение «истина», либо значение «ложь».
Так как события являются действиями, то они могут происходить. Для того чтобы событие произошло, необходимо выполнение соответствующих условий. Эти условия называются предусловиями события. Возникновение события может вызвать нарушение предусловий и привести к выполнению других условий, постусловий.
В качестве примера рассмотрим задачу моделирования простого автомата-продавца [71]. Автомат-продавец находится в состоянии ожидания до тех пор, пока не появится заказ, который он выполняет и посылает на доставку. Условиями для такой системы являются: а) автомат-продавец ждет; б) заказ прибыл и ждет; в) автомат-продавец выполняет заказ; г) заказ выполнен. Событиями будут: 1) заказ поступил; 2) автомат-продавец начинает выполнение заказа; 3) автомат-продавец заканчивает выполнение заказа; 4) заказ посылается на доставку. Предусловия события номер 2 (автомат-продавец начинает выполнение заказа) очевидны: а) автомат-продавец ждет; б) заказ прибыл и ждет. Постусловие для события 2: в) автомат-продавец выполняет заказ. Аналогично мы можем определить предусловия и постусловия для всех остальных событий (табл. 8.1).
Таблица 8.1
Исходные данные для задачи
События	Предусловия	Постусловия
1	Нет	б
2	а, б	В
3	В	г, а
4	г	Нет
'T’JldBd 8	7qc
дМатематические и методологические аспекты проектирования
Такое представление системы легко моделировать сетью Петри. В сети Петри условия моделируются позициями, события — переходами. При этом входы перехода являются предусловиями соответствующего события; выходы — постусловиями. Возникновение события равносильно запуску соответствующего перехода. Выполнение условия представляется фишкой в позиции, соответствующей этому условию. Запуск перехода удаляет разрешающие фишки, представляющие выполнение предусловий, и образует новые фишки, которые представляют выполнение постусловий.
Сеть Петри на рисунке 8.6 иллюстрирует модель приведенного выше автомата-продавца.
Автомат-продавец ждет
Рис. 8.6. Сеть Петри для простого автомата-продавца
Аналогичный пример можно привести для вычислительной системы, которая обрабатывает задания, поступающие с устройства ввода, и выводит результаты на устройство вывода. Задания поступают на устройство ввода. Когда процессор свободен и в устройстве ввода есть задание, процессор начинает обработку задания. Когда задание выполнено, оно посылается в устройство вывода; процессор же либо продолжает обрабатывать другое задание, если оно имеется, либо ждет прихода задания, если устройство ввода еще не получило такового. Эта система может быть промоделирована сетью Петри, показанной на рисунке 8.7.
396
Проектирование информационных систем
Одновременность и конфликт. Одной из особенностей является свойственный сетям и их моделям параллелизм, или одновременность. В модели сети Петри два разрешенных невзаимодействующих события могут происходить независимо друг от друга. Синхронизировать события, пока это не потребуется моделируемой системе, нет необходимости. Но когда синхронизация нужна, моделировать ее легко.
выводится
Рис. 8.7. Моделирование простой вычислительной системы
Т'лзва. 8	^407
Математические и методологические аспекты проектирования
Другая важная особенность сетей Петри — это их асинхронная природа. В сети Петри отсутствует измерение времени или течение времени. В реальной жизни различные события укладываются в различные интервалы времени, и это отражено в модели сети Петри независимостью от времени управления последовательностью событий. Структура сети Петри такова, что содержит в себе всю необходимую информацию для определения возможных последовательностей событий. Таким образом, на рисунке 8.7 событие «завершение выполнения задания» должно следовать за соответствующим событием «начало выполнения задания». Однако нет и не требуется никакой информации, связанной с количеством времени, необходимым на выполнение задания.
Выполнение сети Петри (или поведение моделируемой системы) рассматривается здесь как последовательность дискретных событий. Порядок появления событий является одним из возможных, допускаемых основной структурой. Если в какой-то момент времени разрешено более одного перехода, то любой из нескольких возможных переходов может стать «следующим» запускаемым. Выбор запускаемого перехода осуществляется недетерминированным образом, т.е. случайно. Эта особенность сети Петри отражает тот факт, что в реальной жизненной ситуации, где несколько действий происходит одновременно, возникающий порядок появления событий неоднозначен; скорее, может возникнуть любая из множества последовательностей событий. Однако частичный порядок появления события единственен.
Для простоты обычно вводят следующее ограничение. Запуск перехода (и соответствующего события) рассматривается как мгновенное событие, занимающее нулевое время, и возникновение двух событий одновременно невозможно. Моделируемое таким образом событие называется примитивным; примитивные события мгновенны и неодновременны. Непримитивными называются такие события, длительность которых отлична от нуля. Они не являются неодновременными и, следовательно, могут пересекаться во
398
Проектирование информационных систем
времени. Так как осуществление большинства событий в реальном мире занимает некоторое время, то они являются непримитивными событиями и поэтому не могут должным образом моделироваться переходами в сети Петри. Непримитивное событие может быть представлено в виде двух примитивных событий: «начало непримитивного события», «конец непримитивного события» и условия «непримитивное событие происходит». Эта ситуация может быть промоделирована с помощью сети, показанной на рисунке 8.8.
Начало непримитивного	Конец непримитивного
события	события
Рис. 8.8. Моделирование «непримитивного» события
Недетерминированность и неодновременность запусков переходов в моделировании параллельной системы показываются двумя способами. Один из них представлен на рисунке 8.9. В этой ситуации два разрешенных перехода в любом случае не влияют друг на друга и в число возможных последовательностей событий входит последовательность, в которой первым срабатывает один переход, и последовательность, в которой первым будет запущен другой переход. Это называется одновременностью.
Другая ситуация, в которой одновременное выполнение затруднено и которая характеризуется невозможностью одновременного возникновения событий, показана на рисунке 8.10. Здесь два разрешенных перехода находятся в конфликте. Может быть запущен только один переход, так как при запуске он удаляет фишку из общего входа и запрещает другой переход.
глава 8	лею
^Математические и методологические аспекты проектирования
Рис. 8.9. Одновременность
Эти два перехода могут быть запущены в любом порядке
Рис. 8.10. Конфликт
Переходы tj и tk находятся в конфликте, т.е. запуск одного из них удаляет фишку из и тем самым запрещает другой
Сети Петри можно использовать для моделирования систем распределения ресурсов. В этом случае некоторые фишки могут представлять собой ресурсы. Для сетей Петри такого типа важным свойством является сохранение.
Строгое сохранение—это очень сильное ограничение. Например, из него немедленно следует, что число входов в каждый переход должно равняться числу выходов, |/(/у)| = |О(/^)|.
400
n
Проектирование информационных систем
Если бы это было не так, запуск перехода изменил бы число фишек в сети.
Сеть Петри должна сохранять ресурсы, которые она моделирует. Однако взаимно однозначного соответствия между фишками и ресурсами нет. Фишка может представлять и один программный счетчик или какой-нибудь другой элемент и может представлять несколько ресурсов сразу. Во втором случае фишка позже используется для создания кратных фишек (по одной на ресурс) путем запуска перехода с большим числом выходов, чем входов. В общем следует определить взвешивание фишек. Взвешенная сумма для всех достижимых маркировок должна быть постоянной. Фишкам, не являющимся важными, можно присвоить вес 0; другим фишкам можно присвоить вес 1, 2, 3 или любое другое целое. Фишка определяется ее позицией в сети, все фишки в позиции неразличимы. Следовательно, вес связывается с каждой позицией сети. Вектор взвешивания w = (wp w2,..., wn) определяет вес wf для каждой позиции G Р.
Причиной рассмотрения сохранения в сети Петри было распределение ресурсов, другая задача, которая может возникнуть при распределении ресурсов, — тупики. Тупики служат предметом многих исследований, например, в области вычислительной техники.
Тупик в сети Петри — это переход (или множество переходов), который не может быть запущен. Переход называется активным, если он не заблокирован (нетупиковый). Это не означает, что переход разрешен, скорее, он может быть разрешенным. Следовательно, если переход активен, то всегда возможно перевести сеть Петри из ее текущей маркировки в маркировку, в которой запуск перехода станет разрешенным.
8.2.3- Методы анализа сетей
Существуют два основных метода анализа сетей Петри, которые описывают механизмы решения некоторых из уже перечисленных задач. Первый метод анализа, используемый
глава 8
^Математические и методологические аспекты проектирования
401
для сетей Петри, — это дерево достижимости, второй метод связан с матричными уравнениями.
Дерево достижимости. Дерево достижимости представляет множество достижимости сети Петри. Рассмотрим, например, маркированную сеть Петри на рисунке 8.11. Начальная маркировка ее — (1,0,0). В этой начальной маркировке разрешены два перехода: Zj и/2. Пусть корнем является вершина, соответствующая начальной маркировке, определим новые вершины в дереве достижимости для (достижимых) маркировок, получающихся в результате запуска каждого из этих двух переходов. Дуга, помеченная запускаемым переходом, приводит из начальной маркировки к каждой из новых маркировок (рис. 8.12). Это (частичное) дерево показывает все маркировки, непосредственно дости-жимые из начальной маркировки.
Рис. 8.11. Маркированная сеть Петри, для которой строится дерево достижимости
Рис. 8.12. Первый шаг построения дерево достижимости
402
Проектирование информационных систем
Теперь необходимо рассмотреть все маркировки, достижимые из новых маркировок. Из маркировки (1, 1, 0) можно снова запустить (получая (1,2, 0)) и t2 (получая (0,2, 1)); из (0, 1, 1) можно запустить t3 (получая (0, 0, 1)). Это порождает дерево, изображенное на рисунке 8.13. Начиная с трех новых маркировок необходимо повторить этот процесс, порождая новые маркировки, которые нужно ввести в. дерево, как показано на рисунке 8.14.
Рис. 8.13. Второй шаг построения дерева достижимости
Заметим, что маркировка (0, 0, 1) пассивная; никакой переход в ней не является разрешенным, поэтому никакие новые маркировки из этой пассивной маркировки в дереве порождаться не будут. Кроме того, необходимо отметить, что маркировка (0, 1,1), порождаемая запуском /3 в (0,2, 1), была уже порождена непосредственно из начальной маркировки запуском t2.
Если эту процедуру повторять снова и снова, каждая достижимая маркировка окажется порожденной. Для превращения дерева в полезный инструмент анализа необходимо найти средства ограничения его до конечного размера.
При графическом представлении множества достижимости в дереве достижимости предполагается, что равные мар-
Глава 8	4ПЧ
^Математические и методологические аспекты проектирования
Рис. 8.14. Третий шаг построения дерева достижимости
кировки, которым соответствуют различные последовательности переходов, изображаются различными вершинами на дереве. В этом случае в каждую вершину дерева будет вести единственный ориентированный путь от корневой вершины, которому соответствует единственная последовательность переходов. Если же в целях удобства и сокращения । сометрических размеров дерева достижимости равным маркировкам ставить в соответствие одну вершину, то полученный в результате граф получила название диаграммы достижимых маркировок СП или диаграммы состояний СП. В последнем случае от корневой вершины диаграммы в каждую из ее вершин может вести несколько ориентированных путей, каждому из которых будет соответствовать своя последовательность переходов.
Приведение к конечному представлению осуществляется ш счет использования пассивных маркировок (маркировки, в которых нет разрешенных переходов) и дублирующих маркировок (маркировки, ранее встречавшиеся в дереве).
404
Проектирование информационных систем
Таким образом, в дереве на рисунке 8.14 маркировка (0, 1, 1), получившаяся в результате выполнения последовательности не будет порождать какие-либо новые вершины в дереве, поскольку она ранее встречалась в результате выполнения последовательности /3 из начальной маркировки.
Для сведения дерева достижимости к конечному представлению используется еще одно средство. Рассмотрим алгоритм построения дерева достижимости. Алгоритм начинается с определения начальной маркировки с помощью корня дерева, т.е. граничной вершины. До тех пор пока имеются граничные вершины, они обрабатываются алгоритмом.
Пусть х — граничная вершина, которую необходимо обработать.
1. Если в дереве имеется другая вершина у, не являющаяся граничной, и с ней связана та же маркировка, ц[л] = ц[у ], То вершина х — дублирующая.
2. Если для маркировки ц[х] ни один из переходов не разрешен, то х — терминальная вершина.	'
Если переход tj& Т разрешен в ц[х], то необходимо со- 1 здать новую вершину z дерева достижимости.
Дуга, помеченная t., направлена от вершины х к вершине z. Вершина х переопределяется как внутренняя, вершина z становится граничной.
Когда все вершины дерева терминальные, дублирующие или внутренние, алгоритм останавливается.
На рисунке 8.15 представлено дерево достижимости для сети Петри, приведенной на рисунке 8.11.
Дерево достижимости — очень полезный инструмент анализа сетей Петри. Его можно использовать для решения некоторых задач, представленных выше.
Цветные сети Петри. Появление сетей этого класса связано с концепцией использования различных меток. Ранее все метки предполагались одинаковыми. Механизм функционирования сетей был связан только лишь с количествами меток во входных позициях переходов и определялся общими для всех меток условиями возбуждения переходов
глава 8	4ftc
^Математические и методологические аспекты проектирования
(О, (0,1)
Рис. 8.15. Дерево достижимости сети Петри, приведенной на рисунке 8.11
и правилами изменения различных позиций при выполнении сети. В цветных сетях каждая метка получает свой цвет. Условия возбуждения и правила срабатывания переходов для меток каждого цвета задаются независимо. Множество используемых при реализации цветных сетей красок выбирается конечным или бесконечным (например, счетным). При моделировании систем цветные сети чаще всего используются для построения компактных формальных и графических представлений, в составе которых имеются однотипные по структуре и характеру функционирования группы объектов.
406
Проектирование информационных систем
Контрольные вопросы
1.	В чем заключается выбор проектного решения? Какие модели могут быть использованы для выбора проектного решения?
2.	Где и когда применяются классическая и поведенческая модели принятия решений?
3.	Выделить основные преимущества использования модели нечеткого выбора перед классическими моделями принятия решения.
4.	Какие основные этапы формирования проектных предпочтений существуют?
5.	Привести примеры применения рассмотренной модели формирования проектных предпочтений.
б.	Что позволяют исследовать модели сетей Петри?
7.	Дать описание структуры сетей Петри.
’8. Сформулировать основные правила выполнения сетей Петри.
9. Для моделирования какого класса систем используются сети Петри?
10. Какие методы анализа сетей существуют?
Case-технологии —
ИНСТРУМЕНТАРИЙ
ПОДДЕРЖКИ
ЖИЗНЕННОГО ЦИКЛА
Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях экономики.
Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще (юнее усложняет разработку и сопровождение таких сис-к'м [4].
Все это способствовало появлению программно-технологических средств специального класса — CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) исполь-lycrCH в настоящее время в весьма широком смысле. Пер-поначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый
408
Проектирование информационных систем
смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС [5] (рис. 9.1).
Рис. 9.1. Схема использования CASE-cpedcme
CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств
Глава У	4.ПО
("' ASE-технологии — инструментарий поддержки жизненного цикла
Основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Большинство существующих CASE-средств основано на методологиях структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций.
Центральной частью CASE-средств является репозитарий, хранящий информацию о системе на всех этапах ее жизненного цикла и обеспечивающий согласованную работу всех участников разработки, создания и сопровождения системы. Для доступа к репозитарию и управления им используется специальное средство (навигатор по объектам репозитария), позволяющее просматривать и модифицировать объекты, хранящиеся в репозитарии, а также осуществлять административные функции.
Репозитарий включает не только объекты различных типов, но и отношения между ними, а также правила их использования и обработки. Все отчеты строятся автоматически по репозитарию. Функции управления и контроля также реализуются на основе репозитария. В частности, через репозитарии может осуществляться контроль безопасности (ограничения доступа, привилегии доступа), контроль версий, контроль изменений и др.
410
Проектирование информационных систем
Широкие возможности CASE-систем позволяют пользователям целиком сосредоточиться на собственно моделировании, не отвлекаясь на решение второстепенных вопросов, связанных с размещением элементов диаграмм, их компоновкой и т.п.
Практика разработки сложных систем подтверждает концентрацию сложности на начальных этапах разработки (анализ требований) при относительно невысокой сложности и трудоемкости последующих этапов. На этапе анализа требований приходит понимание того, что будет делать будущая система и каким образом она будет работать, чтобы удовлетворить предъявленные к ней требования. Нечеткость и неполнота системных требований, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и в конечном счете приводят к неуспеху всей работы в целом.
Построенные модели являются результатом начальных этапов разработки системы и техническим заданием на последующие этапы. Но они являются и самостоятельным (отделяемым) результатом, имеющим большое практическое значение. В частности, модель «как есть» описывает существующие технологии на предприятии. Анализ этой модели позволит выявить узкие места и предложить рекомендации по их улучшению (независимо от того, предполагается на данном этапе автоматизация предприятия или нет).
Наличие комплексной модели предприятия является основой для выполнения следующих работ: проведения анализа, оценки и внесения предложений по совершенствованию деятельности предприятия; разработки автоматизированной системы управления предприятием; разработки системного проекта и внедрения корпоративной информационной системы (КИС), поддерживающей систему управления; подготовки и проведения процедуры сертификации предприятия в соответствии с требованиями международных стандартов качества серии ИСО 9000 и т.д.
глава v	z.. -j
>(чА5Е-технологии — инструментарий поддержки жизненного цикла
Однако, несмотря на все потенциальные возможности CASE-средств, необходимо отметить следующее [5]: ► CASE-средства необязательно дают немедленный эффект;
он может быть получен только спустя какое-то время;
►	реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
►	CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.
Для успешного внедрения CASE-средств организация должна обладать следующими качествами [5].
1.	В области технологии. Понимание ограниченности существующих возможностей и способность принять новую технологию.
2.	В области культуры. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пол ьзователями.
3.	В области управления. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.
Если организация не обладает хотя бы одним из перечисленных качеств, то внедрение CASE-средств может закончиться неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.
Несмотря на все проблемы, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить следующие выгоды:
►	высокий уровень технологической поддержки процессов разработки и сопровождения ПО;
►	положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;
►	приемлемый уровень отдачи от инвестиций в CASE-средства.
412
Проектирование информационных систем
9.1. Общая характеристика
и классификация CASE-средств
Основная цель CASE состоит в том, чтобы отделить начальные этапы (анализ и проектирование) от последующих этапов разработки, а также не обременять разработчиков всеми деталями среды разработки и функционирования системы. Чем больший объем работ будет вынесен на этапы анализа и проектирования, тем лучше. В большинстве современных CASE-систем применяются методологии структурного и/или объектно-ориентированного анализа и проектирования, основанные на наглядных диаграммах техники, при этом для описания модели используются графы, диаграммы, таблицы и схемы.
При применении этого инструментария отмечается значительный рост производительности труда, составляющий (по оценкам фирм, использующих CASE) от 100 до 600% в зависимости от объема и сложности работ и опыта использования CASE. При использовании CASE изменяются все фазы ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования. В таблице 9.1 приведены оценки трудозатрат по фазам ЖЦ, в таблице 9.2 сведены основные изменения в ЖЦ при использовании CASE по сравнению с традиционной разработкой, на рисунке 9.2 представлены преимущества разработки с применением CASE-технологий.
Таблица 9.1
Преимущества применения CASE-средств
Способ разработки	Анализ, % 1		Проектирование,	Кодирование, %	Тестирование, %
Традиционная разработка	20	15	20	45
Использование структурной методологии	30	30	15	25
Использование CASE-технологий	40	40	5	15
глава 9
‘CASE-технологии — инструментарий поддержки жизненного цикла
Коэффициент уменьшения
Объем, п/программ
Рис. 9.2. Преимущества разработки с применением CASE-технологий
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации.
414
Проектирование информационных систем
Таблица 9.2
Изменения в ЖЦ ИС
Традиционная разработка	CASE
Основные усилия — на кодирование и тестирование	Основные усилия — на анализ и проектирование
«Бумажные» спецификации	Быстрое итеративное прототипирование
Ручное кодирование	Автоматическая кодогенерация
Ручное документирование	Автоматическая генерация документации
Тестирование кодов	Автоматический контроль проекта
Сопровождение кодов	Сопровождение спецификаций проектиров ания
При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее основными характерными особенностями. Это:
|-лава a	zlc
^•(^АЗЕ-технологии — инструментарий поддержки жизненного цикла
—	мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
—	интеграция отдельных компонентов CASE-средств, обеспечивающая управляемость процессом разработки ИС;
—	использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты [5]:
►	репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой - разработке, контроль метаданных на полноту и непротиворечивость;
►	графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
►	средства разработки приложений, включая языки 4GL и генераторы кодов;
►	средства конфигурационного управления;
►	средства документирования;
►	средства тестирования;
►	средства управления проектом;
►	средства реинжиниринга.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих
416
Проектирование информационных систем
большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам [5]:
—	применяемым методологиям и моделям систем и БД;
—	степени интегрированности с СУБД;
—	доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы [5]:
►	средства анализа, предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin, ARIS);
►	. средства анализа и проектирования, поддерживающие наиболее распространенные методологии проектирования, которые используются для создания проектных спецификаций (Vantage Team Builder, Designer/2000, Silverrun, PRO-IV, СА5Е.Аналитик, ARIS). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
►	средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor и DataBase Designer, ARIS Toolset;
►	средства разработки приложений. К ним относятся средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, SQL Windows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV, ARIS Easy Design;
►	средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций; средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ARIS Toolset, ERwin и S-Designor; в области анализа программных кодов наибольшее распрост-
глава у	z17
ж(7А5Е-технологии — инструментарии поддержки жизненного цикла
ранение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке C++ (Rational Rose, Object Team).
Вспомогательные типы включают:
— средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
—	средства конфигурационного управления (PVCS);
•	— средства тестирования (Quality Works);
—	средства документирования (SoDA).
На сегодняшний день российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
►	малые и средние интегрированные средства проектирования ИС: ERwin, BPwin, Rational Rose;
►	крупное интегрированное средство проектирования — ARIS.
Необходимо заметить, что к числу не менее популярных CASE-средств для разработчиков ИС можно отнести [5]: Vantage Team Builder, Designer/2000, Silverrun, S-Designor, CASE. Аналитик.
9.2. Сравнительный анализ средств инструментальной поддержки процесса проектирования ИС
9.2.1.	Основные средства проектирования ИС
Крупное интегрированное средство проектирования — ARIS [83, 9]. ARIS — архитектура бизнес-инжиниринга представляет собой модель для управления бизнес-процсс-сами. Концепция ARIS создает направляющие ориентиры для разработки, оптимизации и реализации интегрированных прикладных систем. В то же время она наглядно показывает специалистам по управлению бизнесом, как именно следует рассматривать, анализировать, документировать и внедрять информационные системы.
14. Зак. 1035
418
Проектирование информационных систем
При проектировании в среде ARIS для описания проблем в области организации процессов используются полу-концептуальные методы. Они позволяют взглянуть на ситуацию с позиции управления бизнесом, а их достаточная точность и детализация обеспечивают превосходный старт для дальнейшей обработки информационными системами.
Благодаря новым методам и инструментам модели биз-нес-процсссов все больше становятся точкой фокусировки и «калькой» при разработке и настройке информационных систем. По этой причине, в концепции ARIS уровень и полнота описания бизнеса имеют приоритет перед вопросами реализации.
Концепция ARIS позволяет зафиксировать широкий спектр описательных аспектов бизнес-процессов, подобрать способы для их рассмотрения, определить возможные наложения методов и выявить пробелы в описании. Преимущества ARIS очевидны как при решении административных и организационных вопросов бизнеса, так и при проектировании компьютеризованных информационных систем.
Функциональные возможности ARIS обеспечивают: ► инфраструктуру (архитектуру) для полного описания стандартных программных решений;
►	интеграцию в эту архитектуру наиболее подходящих методов моделирования информационных систем и разработку методов описания бизнес-процессов;
►	предоставление моделей-прототипов в качестве инструментов управления прикладным ноу-хау, моделирования и анализа системных требований, а также инструментов, помогающих получить удобную для пользователя навигацию в рамках моделей;
►	эффективно используя стандартные программные решения, ARIS-средство бизнес-инжиниринга предлагает архитектуру для управления бизнес-процессами. Благодаря использованию систем workflow, она слабо связана с программными бизнес-объектами. ARIS обеспечивает инфраструктуру для описания сборки программных ком-
глава у	z1Q
*(^А5Е-технологии — инструментарий поддержки жизненного цикла
понентов, позволяя создавать деловые информационные системы, которые идеально подходят для конфигурирования систем workflow, создания фильтров и определения параметров приложений.
В результате получаются следующие виды моделей ARIS.
1.	Функциональные модели. Процессы, преобразующие вход в выход, группируются в функциональную модель. В связи с тем, что функции тесно связаны с целями, поскольку они направлены на их достижение и подчиняются их управлению, цели также относят к функциональным моделям. В прикладных системах (ПС) описываются правила компьютерной обработки функции. Таким образом, ПС адекватно подходит под определение «функций» и также относится к функциональной модели.
2.	Организационные модели. Класс организационных моделей служит для описания иерархической структуры организации. В организационных моделях группируются субъекты ответственности и средства, выполняющие работу над одним и тем же объектом. Поэтому сущность «человеческий ресурс», а также средства «финансовые ресурсы» и «компьютерная техника» относятся к организационной модели.
3.	Модель данных. Модели данных описывают информационный контекст (среду обработки данных), а также сообщения, активизирующие функции или активизируемые ими. С именами данных можно также связать предварительные детали, касающиеся функции информационных систем как носителей данных. В моделях данных неявным образом фиксируются также объекты в виде информационных услуг. Однако в основном такие объекты описываются в моделях выходов.
4.	Модели выходов. Модели выходов содержат все физические и нефизические входы и выходы, включая потоки денежных средств.
5.	М одели управления/модели процесса. В этих моделях соответствующие классы моделируются с учетом их внутренних взаимоотношений. Представление отношений между
14*
420
м
Проектирование информационных систем
отдельными моделями, так же, как и в рамках всего бизнес-процесса, в виде управляющих моделей (или моделей процесса) позволяет постоянно отслеживать все двусторонние отношения между моделями различных типов, а также полностью описать процесс.
Концепция ARIS нацелена на создание и управление бизнес-процессами организации. Помимо связи со стратегическими установками, она перекликается со стратегическим управлением информацией.
Управление информацией предполагает планирование, регулирование и внедрение «информационного» ресурса. В модели-прототипе выделяют три аспекта: управление инфраструктурой (управление информационными технологиями), управление прикладной системой и управление внедрением информационных систем. Первая задача, связанная с инфраструктурой, охватывает уровни информационных технологий и представленные спецификации проекта. Вторая задача относится к управлению информационными системами и включает реализацию организационных требований в автоматизированных информационных системах с помощью концепции жизненного цикла ARIS, фокусируя внимание на фазах конструктивного времени. Третья задача — управление внедрением информационных систем — относится к фазе реального времени в модели жизненного цикла ARIS.
Среднее интегрированное средство проектирования ИС— Rational Rose. Rational Rose—CASE-средство фирмы Rational Software Corporation — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [19]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML) претендует на роль стандарта в области объект
•-лава у
(^АЗЕ-технологии — инструментарий поддержки жизненного цикла
но-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C+ + , Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов [19].
В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для C++, обеспечивающий реинжиниринг — восстановление модели проекта по исходным текстам программ.
Репозиторий представляет собой объектно-ориентированную базу данных. Средства просмотра обеспечивают «навигацию» по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т.д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.
В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:
►	диаграммы классов;
►	диаграммы состояний;
422
Проектирование информационных систем
►	диаграммы сценариев;
►	диаграммы модулей;
►	диаграммы процессов;
►	спецификации классов, объектов, атрибутов и операций; ► заготовки текстов программ;
►	модель разрабатываемой программной системы.
Последний из перечисленных документов является текстовым файлом, содержащим всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций).	,
Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA — для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA [5].
Rational Rose—это средство, которое может быть использовано всеми участниками проекта. Это фактически хранилище информации о контексте и проекте системы, из которого каждый участник проекта извлекает то, что ему нужно. Помимо всего вышесказанного Rational Rose позволяет генерировать «скелетный код» на большом количестве различных языков. Можно выполнять обратное проектирование кода и создавать таким образом модели уже существующих систем. Весьма выгодно иметь модели Rose для уже существующих приложений. Если сделано изменение в модели, Rose позволяет модифицировать код для его реализации. Если же был изменен код, можно автоматически обновить соответствующим образом и модель. Благодаря этому удается поддерживать соответствие между моделью и кодом, уменьшая риск «устаревания» первой.
Малые интегрированные средства проектирования ИС-— Erwin и BPwin [17]. BPwin является мощным средством моделирования и документирования бизнес-процессов. Этот продукт использует технологию моделирования IDEF0 — наиболее распространенный стандарт, который принят для моделирования бизнес-процессов. Кроме стандарта IDEF0,
глава 9
*(~'А5Е-технологии — инструментарий поддержки жизненного цикла
BPwin поддерживает также методологии моделирования DFD и IDEF3.
Функциональность BPwin заключается в создании моделей, проверке их целостности и согласованности. BPwin обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании, таких, как «зависание» связей при переходе от диаграммы к диаграмме, нарушение ассоциации связей в различных диаграммах модели и т.п. Кроме того, BPwin поддерживает пользовательские свойства, которые применяются к элементам диаграммы для описания специфических свойств, присущих данному элементу.
Одним из важнейших средств BPwin является генератор отчетов. Генератор отчетов RPTwin представляет собой автономный продукт, который поставляется с некоторыми продуктами CA/Logic Works и позволяет генерировать подробные и многогранные отчеты по модели. Вместе с BPwin устанавливается набор стандартных отчетов, которые позволяют осветить модель с различных сторон. Отчеты обычно сопровождают окончательный вариант модели бизнес-про-цсссов, созданной при помощи BPwin, и содержат информацию, размещение которой на модели сделало бы ее трудной для восприятия. Например, отчет может содержать подробное описание каждого элемента диаграммы, что помогает отчетливо представить себе назначение данного элемента без дополнительных разъяснений со стороны системного аналитика, создававшего диаграмму. Кроме того, существуют отчеты, которые предназначены для самого системного аналитика, например, отчет по целостности модели.
ERwin является наиболее мощным средством для разработки структуры данных как на логическом, так и на физическом уровне. Следует отметить, что существует несколько модификаций ERwin. Этот инструмент моделирования полностью поддерживает стандарт IDEF1X и является лидером на рынке инструментов разработки баз данных.
424
Проектирование информационных систем
Обычно разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической модели. ERwin полностью поддерживает такой процесс, он имеет два представления модели: логическое и физическое. ERwin имеет очень удобный пользовательский интерфейс, позволяющий представить базу данных в самых различных аспектах. Также ERwin имеет такие средства визуализации, как «хранимое представление» и «предметная область». Хранимые представления позволяют иметь несколько вариантов представления модели, в каждом из которых могут быть подчеркнуты определенные детали, которые вызвали бы перенасыщение модели, если бы они были помещены на одном представлении. Предметные области помогают вычленить из сложной и трудной для восприятия модели отдельные фрагменты, которые относятся лишь к определенной области, из числа тех, что охватывает информационная модель.
ERwin имеет мощные средства визуализации модели, такие, как использование различных шрифтов, цветов и отображение модели на различных уровнях, например, на уровне описания сущности, на уровне первичных ключей сущности и т.д. Эти средства ERwin значительно помогают при презентации модели в кругу разработчиков системы или сторонним лицам.
Возможность использования модели ERwin одновременно для логического и физического представления данных позволяет по окончании работы получить полностью документированную модель. ERwin, как и инструмент моделирования бизнес-процессов BPwin, интегрирован с генератором отчетов фирмы Logic Works — RPTwin. Это средство позволяет получать подробные отчеты по модели, освещая самые различные ракурсы и аспекты. Инструмент RPTwin поставляется вместе с ERwin и имеет богатый набор встроенных отчетов, позволяющих получать многогранную информацию по модели. Документирование структуры данных является очень важной частью моделирования,
глава 9
^С^АЗЕ-технологии — инструментарий поддержки жизненного цикла так как это позволяет другим разработчикам или лицам, которые будут сопровождать систему, быстрее начать ориентироваться во внутренней структуре и понимать назначение компонентов.
ERwin является не только инструментом разработки баз данных, он также поддерживает автоматическую генерацию спроектированной и определенной на физическом уровне структуры данных. ERwin поддерживает широчайший спектр серверных и настольных СУБД. В этот список входят такие продукты, как Microsoft SQL Server, Oracle, Sybase, DB2, INFORMIX, Red Brick, Teradata, PROGRESS, Microsoft Access, FoxPro, Clipper и многие другие. Средствами ERwin возможно организовать присоединение по протоколу СУБД и поддержку всех средств управления данными, присущих СУБД. Инструмент имеет богатый и гибкий макроязык, позволяющий создавать сценарии, которые будут выполняться до и после генерации определенного объекта на СУБД назначения. ERwin не поддерживает моделирования механизмов защиты базы данных, однако при помощи макроязыка можно автоматически выдать права на объект, пользуясь языком определения прав, который используется в конкретной СУБД.
ERwin может присоединиться к СУБД, получить всю информацию о структуре базы данных и отобразить ее в графическом интерфейсе, сохранив все сущности, связи, атрибуты и прочие свойства (обратная генерация). Таким образом, можно переносить существующую структуру данных с одной платформы на другую, а также исследовать структуру существующих баз данных.
ERwin тесно интегрирован с другими продуктами Logic Works. Словарь данных, созданный при анализе бизнес-процессов при помощи инструмента BPwin, может быть использован как основа для построения модели базы данных. Однако взаимосвязь между этими двумя инструментами двусторонняя, модели BPwin и ERwin можно постоянно поддерживать в согласованном состоянии. Интеграция этих
426
Проектирование информационных систем
двух продуктов очень важна с точки зрения их совместного использования при разработке программного обеспечения, так как отпадает необходимость в повторном выполнении действий и процесс создания словаря данных становится практически автоматическим.
Примеры работы с CASE-средствами Rational Rose и Erwin/BPwin рассмотрены в в. 6.4.2 и п. 6.4.1 учебного пособия, соответственно.
Описания CASE-средств более подробно изложены: Rational Rose [31, 51, 67], ERwin [17, 37, 65, 66], BPwin [17, 64, 66], ARIS [9]. С описанием остальных CASE-средств также можно ознакомиться в дополнительной литературе: Vantage Team Builder [5], Designer/2000 [5, 88], Silverrun [5, 87], S-Designor [5, 38], CASE.Аналитик [5].
3-2.2. Сравнительный анализ
основных CASE-средств
CASE-средства охватывают разнообразную деятельность, от анализа бизнес-структур и бизнес-требований до поддержки жизненного цикла разработки и сопровождения информационных систем, и являются неразрывной связью систем управления организациями и ИС. В узком смысле CASE-средства — это средства визуального моделирования, а в широком — средства, максимально автоматизирующие все процессы жизненного цикла проекта разработки и реализации (как в организационной, так и в программной инженерии). Кроме того, это средства правильного ведения работ, поддерживающие коммуникации участников проекта на разных этапах и с разных позиций (как между командами заказчика и разработчика, так и внутри рабочей группы).
Используемые в CASE-средствах модели (визуальная составляющая CASE-инструментов) — это общий язык для всех участников некоего процесса, обеспечивающий возможность задавать те или иные аспекты предметной области с
глава у	А-у-.
("'ЛЗЕ-технологии — инструментарий поддержки жизненного цикла помощью общей терминологии, общих графических изображений (нотаций).
Задачи проектирования ИС и задачи оптимизации бизнес-процессов переплетаются очень тесно. Поэтому все должно быть связано методологически, а еще лучше — технологически (это может быть единая CASE-система, может быть несколько интегрированных CASE-инструментов) [72].
Сегодня важны не только удобство и скорость работы в той или иной среде разработки. На первый план выходят аспекты обеспечения качества создаваемых программных продуктов, степень их документированности (как с точки зрения пользователей, так и ИТ-специалистов и разработчиков), легкость сопровождения и, конечно, возможность расширения их функциональности в соответствии с запросами пользователей».
Если целью работы с CASE-средствами является программный продукт, то он, как правило, создается на некотором языке программирования в определенной среде разработки. Такие возможности CASE-средств, как автоматическое создание кода и обратный процесс — построение диаграмм на основании исходного кода, методы анализа качества кода, требуют, чтобы осуществляющее их приложение «знало» соответствующий язык и среду программирования на уровне компилятора данного языка.
CASE-инструментарий призван обеспечить понимание и корректное взаимодействие представителей двух разных лагерей: аналитиков, определяющих требования бизнеса (описывающих бизнес-процессы), и разработчиков, отвечающих за структуру данных и объектно-ориентированный анализ, проектирование и программирование.
Существует более 20 технологий проектирования информационных систем и несколько сотен инструментов, предназначенных для автоматизации этого процесса. Приведем сравнительный анализ наиболее популярных средств проектирования [85, 72]: BPwin/ERwin, Rational Rose и ARIS (см. табл. 9.3).
	Таблица 9.3 Сравнительный анализ инструментальных средств				Ifc II»
	Характеристика	Rational Rose	ARIS	BPwin/ ERwin	Проектирование информационных систе
	1	2	3	4	
	Применимость ПО данного класса для различных категорий потребителей				
	Специалисты по организационному управлению (бизнес-ана-литики. бизнес-проектировщики)	0,5	1	1	
	Разработчики ИС (постановщики задач на программирование, бизнес-аналитики)	1	1	1	
	Системные архитекторы ИС	1	0,5	1	
	Программисты ИС	1	0	1	
	Менеджеры и руководители проектов	1	1	1	
	Состав и функциональность линейки продуктов (полнота по жизненному циклу)				
	Управление требованиями	1	1	0.5	
	Моделирование				
	Модели данных (ERD, логические, физические)	1	1	1	
	Модели процессов, функций, работ (ВРМ)	1	1	1	
	Модели ООП (UML и др.)	1	1	1	
	Оргструктуры, потоки и другие классы диаграмм и моделей предметной области	0	1	1	
	Проверка моделей	1	1	1	
	Анализ (динамический и стоимостной анализ процессных моделей)	1	1	1	

Продолжение табл. 9.3 -Я -------_-----------
	1	2	3	4	ава 9	_ ASE-технологии — инструментарии поддержки жизненного цикла
	Разработка технического задания	1	0,5	0.5	
	Оптимизация бизнес-процессов	1	0	0	
	Имитационное моделирование, событийно-управляемое моделирование	1	0.5	0	
	Генерация кода приложения	0	1	0,5	
	Хранение моделей деятельности предприятий	1	0,5	0,5	
	Документирование результатов моделирования, анализ моделей (печатные отчеты по моделям, их описаниям, основаниям, разработчикам, пользовательские запросы к моделям и их составляющим)	1	1	1	
	Проектирование, разработка технических аспектов ИС (архитектура, модули, экранные формы)	1	0,5	1	
	Создание ИС (формирование БД, кода, экранных форм) на основе моделей ИС	1	0	1	
	Тестирование	1	0	0.5	
	Метрики кода, аудит кода	0	0	0,5	
	Обратная связь кода с моделями ИС	1	0	1	
	Документирование ИС	1	1	0	
	Автоматизированное обучение пользователей ИС	0	1	0	
	Автоматизированный аудит внедренной ИС	0	1	1	
	Связь процедурных моделей с WorkFlow-системами	0	1	0	
	Выдача встроенных отчетов по стандарту ISO 9000	1	0	0	
*					
Проектирование информационных систем
Окончание табл. 9.3 |&
тг	с £ с с *3 с 50 С £ S. £	•—'1		т—«	W-J О	т—<		»—1
				Т—<			0,5	»—<
rq		т—<				г-*	о	г—<
т-Ч		| Многопользовательская работа с моделями, подсистемами |	Управление взаимодействием пользователей (Web-сайт, сообщения, почта, форумы, конференции)	Библиотеки (репозитарий) терминов, моделей, объектов, приложений, модулей, компонентов, функций, готовых решений и т.п.)	1 Методология ведения работ	|	Средства управления бизнес-процессами и документооборотом в рамках проекта (методология ведения проекта)	Управление проектом разработки (сетевой график работ, мониторинг состояния, распределение нагрузки на исполните- лей и т.д.)	1 Разграничение доступа пользователей к системе
- частично поддерживается, не поддерживается.
глава у
*(^А5Е-технологии — инструментарий поддержки жизненного цикла
На основании данных таблицы 9.3 можно сделать вывод о том, что ни одно из средств проектирования не удовлетворяет в полной мере требованиям комплексного проектирования ИС с целью реинжиниринга БП. Например, при проектировании ИС для небольших организаций в целях регламентации и документирования выполняемых работ, а также реинжиниринга «по направлению» может быть использовано средство BPwin. На крупных предприятиях при проведении реинжиниринга с последующим внедрением КИС будет предпочтительнее ARIS, обладающий более расширенными возможностями.
9.2.3- Вспомогательные средства поддержки жизненного цикла ПО
Средства планирования и управления проектом. Наиболее распространенным средством планирования и управления процессом проектирования ИС является Microsoft Project, информация о котором представлена в п.4.3 учебного пособия.
Средства конфигурационного управления [5]. Цель конфигурационного управления (КУ) — обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО. Для этого необходима точная и достоверная информация о состоянии ПО и его компонент в каждый момент времени, а также о всех предполагаемых и выполненных изменениях.
Для решения задач КУ применяются методы и средства, обеспечивающие идентификацию состояния компонентов, учет номенклатуры всех компонентов и модификаций системы в целом, контроль над вносимыми изменениями в компоненты, структуру системы и ее функции, а также координированное управление развитием функций и улучшением характеристик системы.
Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных
432
Проектирование информационных систем
продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.
PVCS Version Manager [39] предназначен для управления всеми компонентами проекта (совокупность файлов) и ведения планомерной многоверсионной и многоплатформенной разработки силами команды разработчиков в условиях одной или нескольких локальных сетей. Результатом работы PVCS Version Manager является созданный средствами файловой системы репозиторий, хранящий в компактной форме все рабочие версии программного продукта вместе с необходимыми комментариями и метками.
PVCS Tracker [40] — специализированная надстройка над офисной электронной почтой, предназначенная для обработки сообщений об ошибках в продукте, доставке их исполнителям и контроле за исполнением. Отчетные возможности PVCS Tracker включают множество разновидностей графиков и диаграмм, отражающих состояние проекта и процесса его отладки, срезы по различным компонентам проекта, разработчикам и тестировщикам. С их помощью можно наглядно показать текущее состояние работы над проектом и ее временные тенденции. PVCS Tracker предназначен для использования в рабочих группах, объединенных в общую сеть. Главной особенностью PVCS Tracker по сравнению с обычным приложением СУБД является его способность автоматически уведомлять пользователя о поступлении интересующей его или относящейся к его компетенции информации и гибкая система распределения полномочий внутри рабочей группы. PVCS Tracker поддерживает групповую работу в локальных сетях и взаимодействует с СУБД dBase, ORACLE, SQL Server и SYBASE посредством ODBC.
Средства документирования [5]. Для создания документации в процессе разработки ИС используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнитель
глава 9	422
*(7ASF-технологии — инструментарий поддержки жизненного цикла
ный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Automation).
Продукт SoDA предназначен для автоматизации разработки проектной документации на всех фазах ЖЦ ПО. Он позволяет автоматически извлекать разнообразную информацию, получаемую на разных стадиях разработки проекта, и включать ее в выходные документы. При этом контролируется соответствие документации проекту, взаимосвязь документов, обеспечивается их своевременное обновление. Результирующая документация автоматически формируется из множества источников, число которых не ограничено. SoDA не зависит от применяемых инструментальных средств. SoDA содержит набор шаблонов документов, определяемых стандартом на программное обеспечение DOD 2167А. На их основе можно без специального программирования создавать новые формы документов, определяемые пользователями. Разные виды документации, сопровождающие различные этапы ЖЦ, связаны между собой, и можно проследить состояние проекта от первоначальных требований до анализа, проектирования, кодирования и тестирования программного продукта.
Итоговым результатом работы системы SoDA является готовый документ (или книга).
Средства тестирования [5]. Под тестированием понимается процесс исполнения программы в целях обнаружения ошибок. Регрессионное тестирование — это тестирование, проводимое после усовершенствования функций программы или внесения в нее изменений.
Одно из наиболее развитых средств тестирования QA [41] представляет собой интегрированную многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.
QA позволяет начинать тестирование на любой фазе ЖЦ, планировать процесс тестирования и управлять им, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.
434
Проектирование информационных систем
Основными компонентами QA являются:
►	QA Partner — среда для разработки, компиляции и выполнения тестов;
►	QA Planner — модуль для разработки планов тестирования и обработки результатов; для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner;
►	Agent -— модуль, поддерживающий работу в сети.
Процесс тестирования состоит из нескольких этапов, таких как:
—	создание плана тестирования;
—	связывание плана с тестами;
—	пометка и выполнение тестов;
—	получение отчетов о тестировании и управление результатами.
9-3. Технология внедрения CASE-средств
Процесс внедрения CASE-средств состоит из следующих этапов [37]:
►	определение потребностей в CASE-средствах;
►	оценка и выбор CASE-средств;
►	выполнение пилотного проекта;
►	практическое внедрение CASE-средств.
Определение потребностей в CASE-средствах
Данный этап включает достижение понимания потребностей организации и технологии последующего процесса внедрения CASE-средств. Он должен привести к выделению тех областей деятельности организации, в которых применение CASE-средств может принести реальную пользу. Результатом данного этапа является документ, определяющий стратегию внедрения CASE-средств [5].
Анализ возможностей организации. Первым действием данного этапа является анализ возможностей организации в отношении ее технологической базы, персонала и исполь
Глава у	дЧс
^Г'АЗЕ-технологии — инструментарии поддержки жизненного цикла
зуемого ПО. Такой анализ может быть формальным или неформальным.
Формальные подходы определяются моделью оценки зрелости технологических процессов организации СММ (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами ISO 9001:1994, ISO 9003-3:1991 и ISO 9004-2:1991. В центре внимания этих подходов находится анализ различных аспектов происходящих в организации процессов.
Для получения информации относительно положения и потребностей организации могут использоваться неформальные оценки и анкетирование. Вопросы, включаемые в анкету, должны являться руководством по сбору информации, необходимой для определения степени готовности организации к внедрению СASE-технологии [5].
Оценка готовности организации к внедрению CASE-тех-нологии должна быть откровенной и тщательной, поскольку в случае отсутствия такой готовности все усилия по внедрению потерпят крах.
Определение организационных потребностей. Организационные потребности следуют непосредственно из проблем организации и целей, которых она стремится достичь. Проблемы и цели могут быть связаны с управлением, производством продукции, экономикой, персоналом или технологией. Определение потребностей должно выполняться в сочетании с обзором рынка CASE-средств, поскольку информация о технологиях, доступных на рынке в данный момент, может оказать влияние на потребности [5].
Определение потребностей организации, связанных с использованием CASE-технологии, включает анализ целей и существующих возможностей. После того как все потребности организации определены, каждой из них должен быть присвоен определенный приоритет, отражающий ее значимость для успешной деятельности организации. Если потребности, связанные с CASE-технологией, не обладают высшим приоритетом, имеет смысл отказаться от ее внедрения и сосредоточиться на потребностях с наивысшим приоритетом.
436
Проектирование информационных систем
Каждая потребность должна иметь определенный приоритет, зависящий от того, насколько критической она является для достижения успеха в организации. В конечном счете должно четко прослеживаться воздействие каждой функции или возможности приобретаемых средств на удовлетворение конкретных потребностей.
Результатом данного действия является формулировка потребностей с их приоритетами, которая используется на этапе оценки и выбора в качестве «пользовательских потребностей».
Оценка и выбор CASE-средств
Целью процесса оценки является определение функциональности и качества CASE-средств для последующего выбора. Оценка выполняется в соответствии с конкретными критериями, ее результаты включают как объективные, так и субъективные данные по каждому средству.
Процесс оценки включает следующие действия [5]:
►	формулировка задачи оценки, включая информацию о цели и масштабах оценки;
►	определение критериев оценки, вытекающее из определения задачи;
►	определение средств-кандидатов путем просмотра списка кандидатов и анализа информации о конкретных средствах;
►	оценка средств-кандидатов в контексте выбранных критериев. Необходимые для этого данные могут быть получены путем анализа самих средств и их документации, опроса пользователей, работы с демо-версиями, выполнения тестовых примеров, экспериментального применения средств и анализа результатов предшествующих оценок;
►	подготовка отчета по результатам оценки.
Процессы оценки и выбора тесно взаимосвязаны друг с другом. Когда анализируются окончательные результаты оценки и к ним применяются критерии выбора, может быть рекомендовано приобретение CASE-средства или набора CASE-средств. Альтернативой может быть отсутствие адек
Глава 9	427
•*•£"'ASE-технологии — инструментарии поддержки жизненного цикла
ватных CASE-средств, в этом случае рекомендуется разработать новое CASE-средство, модифицировать существующее или отказаться от внедрения.
Выполнение пилотного проекта
Пилотный проект представляет собой первоначальное реальное использование CASE-средства в предназначенной для этого среде и обычно подразумевает более широкий масштаб использования CASE-средства по отношению к тому, который был достигнут во время оценки. Пилотный проект должен обладать многими из характеристик реальных проектов, для которых предназначено данное средство. Он преследует следующие цели [5]:
►	подтвердить достоверность результатов оценки и выбора;
►	определить, действительно ли CASE-средство годится для использования в данной организации, и если да, то определить наиболее подходящую область его применения;
►	собрать информацию, необходимую для разработки плана практического внедрения;
►	приобрести собственный опыт использования CASE-средства.
Важной функцией пилотного проекта является принятие решения относительно приобретения или отказа от использования CASE-средства.
Практическое внедрение CASE-средств
Процесс переходё1 к практическому использованию CASE-средств начинается с разработки и последующей реализации плана перехода. Этот план может отражать поэтапный подход к переходу, начиная с тщательно выбранного пилотного проекта до проектов с существенно возросшим разнообразием характеристик. План перехода должен включать следующее [5]:
►	информацию относительно целей, критериев оценки, графика и возможных рисков, связанных с реализацией плана;
438
Проектирование информационных систем
►	информацию относительно приобретения, установки и настройки CASE-средств;
►	информацию относительно интеграции каждого средства с существующими средствами, включая как интеграцию CASE-средств друг с другом, так и их интеграцию в процессы разработки и эксплуатации ПО, существующие в организации;
►	ожидаемые потребности в обучении и ресурсы, используемые в течение и после завершения процесса перехода;
►	определение стандартных процедур использования средств.
Результатом данного этапа является внедрение CASE-средств в повседневную практику организации, при этом больше не требуется какого-либо специального планирования. Кроме того, поддержка CASE-средств включается в план текущей поддержки ПО в данной организации.
7]
• | Контрольные вопросы
1.	Каковы основные цели и возможности применения CASE-средств?
2.	Перечислить факторы, способствовавшие появлению программно-технологических средств специального класса — CASE-средств.
3.	Обосновать необходимость использования CASE-средств для моделирования процессов.
4.	Дать определение понятиям CASE-средства и CASE-технологии.
5.	По каким категориям классифицируются CASE-средства?
б.	Перечислить основные критерии оценки внедрения CASE-средств.
7.	Дать характеристику локальным и объектно-ориентированным CASE-средствам.
8.	Каково назначение вспомогательных средств поддержки жизненного цикла ИС?
10
Проектирование программных СИСТЕМ
Проектирование в теории определяется как создание низкоуровневой (весьма подробной) модели системы и выполняемых ею функций. Понятие модели включает в себя внутренние и внешние (внемодельные) связи.
Проектирование следует за анализом, но лишь условно может быть отделено от него. Часто анализ сразу же порождает и ставит на обсуждение проектные решения. Основное отличие этапа анализа от этапа проектирования состоит в том, что на первом из этих этапов идут по пути упрощения представлений при сохранении сути рассматриваемого вопроса. Для этого необходимо абстрагироваться от деталей, для того чтобы лучше определить общий взгляд на систему. При проектировании действуют наоборот: рассматривается крупная группа идей, шаблонов, прецедентов, которые тщательно анализируют, добавляя все новые технические и иные детали.
При этом проект должен сразу включать в себя возможность наращивания и частичного изменения функций, а также взаимодействие с изменяющейся внешней средой. Опыт показывает, что, как на стадии проекта, так и при реализации, требования к системе чаще всего усиливаются. Если дополнения и изменения возможны не только для создателей системы, но и для других заинтересованных групп (в том числе заказчиков), то система называется открытой.
Проект может быть конкретным, единичным, но может включать и общие утверждения (соображения), которые детализируются в его каждой конкретной реализации. Тогда мы имеем дело не с проектом, а с проектной моделью.
Существует два вида проектирования: архитектурное и детализированное. Осуществляясь, в принципе, послсдова-
440
нки
Проектирование информационных систем
тельно, эти разделы могут итеративно перемешиваться друг с другом.
Архитектурное проектирование определяется как создание общей структуры системы. Другими словами, это проектирование в терминах модулей. В теории архитектурное проектирование определяется как многоуровневая организация классов, шаблонов, прецедентов.
Более конкретно, архитектурное проектирование состоит в отнесении объектов к классам, указании основных отношений между классами (см. выше ассоциации, агрегации, обобщение, наследование и другие отношения), определении групп операций, выборе принципиальных путей их реализации и выборе основных решений по взаимодействию с окружением системы.
Детализированное проектирование определяется как конкретизация и реализация модулей, операций, отношений. На этой же стадии дорабатывается структура системы. Полностью определяются алгоритмы, функционирующие в каждом модуле.
Теоретический подход к детализированному проектированию — это многоуровневая организация объектов и их атрибутов, реализация связей и алгоритмов работы.
Архитектурное проектирование, определяя структуру, в частности, определяет программно-аппаратную платформу ИС и, тем самым, фактически накладывает ограничения на детализированное проектирование. Это — типичный для проектирования недостаток деления работы на части, который, правда, позволяет резко упростить и ускорить работу. Возвращение со стадии детализации в более общую стадию архитектурного проектирования (создания облика системы) возможно, но существенно замедляет работу. Частично выход состоит в том, что архитектурное проектирование должно предусматривать наращивание возможностей на стадии детализированного проектирования.
Глава 10	441
ТТРоектиРование программных систем____________
10.1.	Цели проектирования программных систем
Под проектированием подразумевается некий строгий подход, с помощью которого представляется возможным найти пути решения определенной проблемы, обеспечив, таким образом, переход от требований к их исполнению. В контексте инженерного программирования цель проектирования можно определить как создание программной системы, которая удовлетворяет:
►	данным функциональным требованиям в их формальной или неформальной форме;
►	явным и неявным требованиям по эксплуатационным качествам и ресурсопотреблению;
►	явным и неявным требованиям дизайна;
►	требованиям к самому процессу разработки, таким, например, как его стоимость и продолжительность.
Проектирование подразумевает учет противоречивых требований. Продуктами проектирования являются модели, позволяющие понять структуру и принципы функционирования будущей системы, сбалансировать требования и определить пути их реализации.
Программное обеспечение — это совокупность программ, процедур работы и соответствующей документации для информационной системы.
Проектирование программных систем — это такое применение естественных и математических наук, в результате которого потенциальные возможности технических средств реализуются на пользу человеку с помощью машинных программ, организационных процедур и соответствующей документации.
Современный уровень программного обеспечения информационных систем предъявляет существенные требования к проектированию:
►	повысить производительность труда при разработке программного обеспечения;
442
Проектирование информационных систем
►	повысить эффективность сопровождения программного обеспечения, так как оно составляет около половины стоимости.
Также требования к проектированию состоят в необходимости разработки и сопровождения такого программного обеспечения, которое гарантирует следующие свойства информационных систем:
—	исключительную надежность;
—	удобство в использовании;
—	естественность;
—	проверяемость;
—	труднодоступность для злоупотреблений;
—	ставку на человека, а не на машину.
Наиболее важным в проектировании программных систем является знание методов достижения, возможно, противоречащих друг другу целей и согласования разнообразных применяемых средств, каждое из которых в зависимости от ситуации в различной степени помогает или мешает достижению конкретного результата.
Эффективность проектирования основывается на осуществлении двух основных подцелей:
►	получения качественного программного изделия;
►	реализации эффективного процесса разработки и сопровождения программного обеспечения.
Каждая из этих подцелей состоит из следующих трех компонентов:
—	учета человеческих факторов;
—	управления ресурсами;
—	программотехники (технология программирования).
Эффективность проектирования программных систем представляется возможным оценить, исходя из следующих групп факторов.
1.	Качество программного изделия:
►	человеческие факторы: легкость использования, удовлетворение потребностей пользователя, реализация потенциальных способностей пользователя;
'лава 10
УТроектирование программных систем
443
►	факторы управления ресурсами: эффективность, сбалансированность, измеряемость;
►	факторы программотехники: специфицированность (полнота, непротиворечивость, безопасность, осуществимость, проверяемость), правильность, адаптируемость (структурированность, независимость, понятность).
2.	Эффективность процесса разработки программной системы:
►	человеческие факторы: планируемость, организуемость, укомплектованность штатов, руководимость, контролируемость, автоматизирусмость;
►	факторы управления ресурсами: анализируемость эффективности затрат, планируемость, оцениваемость, контролируемость, выполняемость срока и бюджета;
►	факторы программотехники: осуществимость, полнота и непротиворечивость требований, подтверждаемость, проектируемость изделия, программируемость, комплек-сируемость, внедряемость, сопровождаемость, снимаемость, управляемость конфигурацией.
Можно выделить три квалификационные категории пользователей, которые занимаются разработкой и использованием программного обеспечения.
К первому уровню относятся разработчики программного обеспечения — специалисты в области применения аппаратно-программных комплексов, способные разрабатывать базовые методы, средства и оснащение программных систем, общесистемное программное обеспечение, инструментальные и технологические средства, осуществлять генерацию и настройку программ на условия конкретного применения.
Ко второму уровню — те, кто хорошо знает тонкости построения системы и может ее модифицировать, то есть прикладные программисты, которые знают методологию проектирования, алгоритмы прикладной области и могут разрабатывать специализированное программное обеспечение, используя общесистемное.
444
Проектирование информационных систем
К третьему относятся пользователи, работающие в системе с помощью ориентированного на них языка взаимодействия. Процесс работы в этом случае сводится к заданию исходных данных, постановке задачи, проведению расчетов, анализу результатов и принятию решений.
Хорошее понимание категорий конечных пользователей может дать необходимую стартовую информацию для начала создания проекта. Необходимо постоянно изучать, что хотят конечные пользователи. Различные типы пользовательских групп имеют различные требования. Эти требования должны быть учтены при проектировании программного обеспечения.
Приложения для общего рынка. Если приложение разрабатывается для общего рынка, то возможно создать только очень грубое представление о конечном пользователе. Если создается, например, какая-либо общая программа учета, то возможно лишь предположить, что клиент имеет общее представление о компьютере и у него есть необходимость что-либо учитывать. Например, к подобным программам можно отнести часто применяемые прикладные программы пакета MS Office.
Приложения для вертикального рынка. Если создается программа поддержки офиса какой-либо организации в конкретной области деятельности, — известно, что конечные пользователи будут использовать данное приложение именно в этой области. Таким образом, возможно оптимизировать систему учета и расчетов, учитывая специфику конкретного бизнеса. Однако неизвестен ни опыт работы конечных пользователей с вычислительной техникой, ни уровень их профессионализма в собственном бизнесе. Примером приложения для вертикального рынка могут служить системы фирмы 1С.
Пользовательские приложения. Пользовательскими приложениями называются программные системы, создаваемые для конкретного пользователя, организации, фирмы. Если создается, например, офисная система для конкретного офиса
глава 10	44ч
Проектирование программных систем_____________
и существует возможность непосредственного общения с конечными пользователями и определения их уровня познания в вычислительной технике и опыта работы в собственном бизнесе, то можно заранее предусмотреть большинство конфликтных ситуаций между создаваемым приложением и конечными пользователями.
Ожидания конечных пользователей. Каждая группа конечных пользователей имеет различные требования и ожидания от создаваемой системы. Перед началом проектирования системы необходимо выяснить, на что рассчитывает конечный пользователь. Необходимо обратить внимание на следующие аспекты:
►	начальное обследование и составление технического задания или функциональные спецификации;
►	инсталляцию;
►	обучение;
►	поддержку;
►	помощь в эксплуатации.
10.2. Принципы разработки
программных систем
Общие принципы
Программное обеспечение различается по назначению, выполняемым функциям, формам реализации. В этом смысле программное обеспечение — сложная, достаточно уникальная программная система Однако можно полагать, что существуют некоторые общие принципы, которые следует использовать при разработке программ.
Частотный принцип. Основан на выделении в алгоритмах и в обрабатываемых структурах действий и данных по частоте использования. Для действий, которые часто встречаются при работе программной системы, обеспечиваются условия их быстрого выполнения. К данным, к которым происходит частое обращение, обеспечивается наиболее
446
Проектирование информационных систем
быстрый доступ. «Частые» операции стараются делать более короткими. Например, к наиболее часто используемым действиям в программных системах можно отнести процедуры работы с базой данных системы, при условии, что информация этой базы данных постоянно обновляется и используется в работе системы.
Принцип модульности. Под модулем в общем случае понимают функциональный элемент рассматриваемой системы, имеющий оформление, законченное и выполненное в пределах требований системы, и средства сопряжения с подобными элементами или элементами более высокого уровня данной или другой системы.
Способы обособления составных частей программной системы в отдельные модули могут существенно различаться. Чаще всего разделение происходит по функциональному признаку. В значительной степени разделение системы на модули определяется используемым методом проектирования программного обеспечения.
В качестве примера можно заметить, что наиболее часто в программных системах выделяют модуль, обеспечивающий взаимодействие с другими подсистемами, или модули работы с неосновными базами данных системы, т.е. базами данных, информация из которых используется только по мере надобности и недостаточно часто. (Понятие «часто» в данном случае носит относительный характер и определяется исходя из сущности информационной системы и ее программной составляющей).
Принцип функциональной избирательности. Этот принцип является логическим продолжением частотного и модульного принципов и используется при проектировании программных систем, объем которых существенно превосходит имеющийся объем функционирования. В программной системе выделяется некоторая часть важных модулей, которые постоянно должны быть в состоянии готовности для эффективной организации вычислительного процесса. Эту часть называют ядром или монитором. При формировании
глава 10
* Проектирование программных систем
447
состава монитора требуется удовлетворить двум противоречивым требованиям. В состав монитора помимо чисто управляющих модулей должны войти наиболее часто используемые модули. Количество модулей должно быть таким, чтобы рабочий объем, занимаемый монитором, был не слишком большим. Программы, входящие в состав монитора, постоянно функционируют. Остальные части программной системы загружаются только при необходимости, перекрывая друг друга.
Этот принцип чаще всего реализуется путем разбиения программной системы на исполняемые модули, между которыми осуществляется обмен информацией или организация динамически загружаемых модулей. При реализации принципа функциональной избирательности необходимо учитывать последовательность использования действий, реализованных в различных модулях, а также время, требующееся для загрузки — выгрузки модулей, и время, требуемое на обмен информацией между модулями.
Принцип генерируемости. Основное положение этого принципа определяет такой способ исходного представления программной системы, который бы позволял осуществлять настройку на конкретную конфигурацию технических средств, круг решаемых проблем, условия работы пользователя.
Одним из требований данного принципа является обеспечение адаптируемости информационной системы в ее программной реализации. Необходимо заметить, что данное требование усложняет разработку и реализацию системы, но одновременно снижает затраты на адаптацию к конкретному пользователю, что повышает эффективность разрабатываемой системы непосредственно для самих разработчиков.
Принцип функциональной избыточности. Этот принцип учитывает возможность проведения одной и той же работы различными средствами. Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи данных, из-за психологических различий в восприятии информации.
448

Проектирование информационных систем
В данном случае представляется важной реализация программной системы с учетом предыдущего принципа, предоставляющей не только различные .средства, взаимно заменяющие друг друга, но также такую конфигурацию использования этих средств, которая позволила бы настроить ее под конкретного пользователя, не снижая ее возможностей и учитывая потребности пользователя. Особое внимание здесь следует уделять вводу и представлению информации как основным моментам, при которых осуществляется непосредственное взаимодействие системы с пользователем.
Принцип «по умолчанию». Применяется для облегчения организации связей с системой как на стадии генерации, так и при работе с уже готовым программным обеспечением. Принцип основан на хранении в системе некоторых базовых описаний структур, модулей, конфигураций и данных, определяющих условия работы с программой.
Эту информацию программная система использует в качестве заданной, если пользователь забудет или сознательно не конкретизирует ее. В данном случае программа сама установит соответствующие значения.
Важным моментом является вопрос выбора этих значений «по умолчанию». Наиболее часто применяют два способа. Первый заключается в использовании по умолчанию тех значений, которые в большей мере устраивают всех пользователей. Второй чаше всего включает в себя первый и в добавление предоставляет возможность запоминания значений, определенных пользователем в качестве значений, используемых по умолчанию.
Общесистемные принципы
При создании и развитии программного обеспечения -рекомендуется применять следующие общесистемные прин- ’ ципы [78].
Принцип включения предусматривает ситуацию, когда требования к созданию, функционированию и развитию
рлава 10
* Проектирование программных систем
449
программного обеспечения определяются со стороны более сложной, включающей его в себя системы.
Это означает, что требования к программной системе выдвигаются, прежде всего, информационной системой, частью которой является программная система, и пользователем, который также включен в информационную систему, а связь между данными компонентами и программной системой является существенной и значимой для эффективности функционирования информационной системы в целом.
Принцип системного единства состоит в том, что на всех стадиях создания, функционирования и развития программного обеспечения его целостность будет обеспечиваться связями между подсистемами, а также функционированием подсистемы управления.
Таким образом, все подсистемы программной системы должны функционировать для обеспечения цели программной системы в целом и соответствующих подсистем информационной системы. И то и другое в конечном итоге выставляет принцип соответствия и направленности цели любой подсистемы программной системы целям информационной системы, а значит, и целям систем верхних уровней.
Принцип развития предусматривает в программной системе возможность ее наращивания и совершенствования компонентов и связей между ними. Данный принцип предусматривает также реализацию свойств адаптивности к изменениям как внутренним, так и внешним.
Принцип комплексности заключается в том, что программное обеспечение осуществляет связность обработки информации как для отдельных элементов, так и для всего объема данных в целом на всех стадиях обработки.
Принцип информационного единства состоит в том, что во всех подсистемах, средствах обеспечения и компонентах программного обеспечения используются единые термины, символы, условные обозначения и способы представления.
Принцип совместимости состоит в том, что язык, символы, коды и средства обеспечения программных подсистем
15. Зак. 1035
450
Проектирование информационных систем информационной системы согласованы, обеспечивают совместное функционирование всех его подсистем и сохраняют открытой структуру системы в целом.
Принцип инвариантности предопределяет, что подсистемы и компоненты программного обеспечения инвариантны к обрабатываемой информации, то есть являются универсальными или типовыми. Исключением здесь может являться избирательность программного обеспечения к физической форме и виду входных данных.
10.3. Методологии и технологии проектирования программных систем
Проблемы создания сложных технических систем с заданными характеристиками всегда принадлежали к числу самых труднорешаемых. В случае корпоративных информационных систем они усугубляются взаимозависимостью проектных решений по бизнес- и ИТ-платформам. Огромная размерность возникающих при этом задач требует многоуровневой декомпозиции ИС как объекта проектирования, в том числе декомпозиции глобальных бизнес-целей в проекции на иерархию ИТ-целей для разноплановых архитектурных компонентов этой сложной системы. Но и в этом случае остается открытым основной вопрос философии системного проектирования: как, исходя из общего описания глобальных корпоративных бизнес-целей, получить максимально ориентированную на достижение данных целей информационную систему. При этом процесс проектирования ИС должен быть организован таким образом, чтобы обеспечить получение необходимых проектных решений с заданным качеством, в установленные сроки и в пределах выделенных для данного проекта средств.
Существует несколько типовых сценариев системного проектирования ИС, в которых предприняты относительно удачные попытки решить некоторые из обозначенного комплекса проблем. Примером могут служить методоло
глава 10	х-i
*ТТРоектиРование программных систем_____________
гии, в основу которых положены хорошо известные идеи и модели Дж. Захмана, Д. Хендерсона, Р. Баркера, У. Мел-линга, А. Шеера и других.
Для обозначенных выше подходов характерно следующее: ► не предложены строгие методы декомпозиции исходной глобальной задачи проектирования сложной ИС на проектные подзадачи приемлемой размерности (отсутствует структурирование проблемы);
►	не разработаны формальные методы синтеза и преобразования системно-целевых и структурно-функциональных моделей ИС, позволяющие получить на всех иерархических уровнях проектные решения, близкие к оптимальным;
►	не предложен конкретный математический аппарат, на основе которого может быть построена подобная адекватная система моделей и который был бы применим для их анализа, а также для поиска наилучших решений в пространстве возможных альтернатив.
10.3-1- Общие требования к методологии
и технологии
Методологии, технологии и инструментальные средства проектирования составляют основу проекта любой программной подсистемы информационной системы. Методология реализуется через конкретные технологии, поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла разработки программных систем.
Технология проектирования определяется как совокупность трех составляющих:
►	пошаговой процедуры, определяющей последовательность технологических операций проектирования;
►	критериев и правил, используемых для оценки результатов выполнения технологических операций;
►	нотаций (графических и текстовых), используемых для описания проектируемой системы.
15*
ж .
Проектирование информационных систем
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям [5]:
►	технология должна поддерживать полный жизненный цикл разработки;
►	технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
►	технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей);
>	технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3—7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
►	технология должна обеспечивать минимальное время получения работоспособного программного обеспечения информационной системы. Речь идет не о сроках готовности всей информационной системы, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам;
►	технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и
глава 10	4ч,
ТТРоектиРование программных систем_______________
его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
► технология должна обеспечивать независимость выполняемых проектных решений от средств реализации программного обеспечения (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
Реальное применение любой технологии разработки программного обеспечения информационных систем в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие [5]:
—	стандарт проектирования;
—	стандарт оформления проектной документации;
—	стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
►	набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
>	правила фиксации проектных решений на диаграммах, в том числе правила наименования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т.д.;
►	требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т.д.;
►	механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т.д.
454 Проектирование информационных систем
Стандарт оформления проектной документации должен устанавливать:
►	комплектность, состав и структуру документации на каждой стадии проектирования;
►	требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.), ► правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
►	требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
►	требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
►	правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
►	правила использования клавиатуры и мыши;
►	правила оформления текстов помощи;
►	перечень стандартных сообщений;
►	правила обработки реакции пользователя.
10.3.2. Методология RAD
Одним из возможных подходов к разработке программного обеспечения в рамках итерационной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development) [5]. Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:
— небольшую команду программистов (от 2 до 10 человек); — короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
рлава 10	ass
хТТРоектиРование программных систем_______________
— повторяющийся цикл, при котором разработчики, по мере того как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании программных систем с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз [5]:
►	анализа и планирования требований;
►	проектирования;
►	построения;
►	внедрения.
На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должен быть список и приоритетность функций будущей программной системы, предварительные функциональные и информационные модели.
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования
456
Проектирование информационных систем
к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.
После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении системы на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время — порядка 60-90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатами данной фазы должны быть:
►	общая информационная модель системы;
►	функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
►	точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
►	построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений,
глава 10
АПроектирование программных систем
457
а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
►	определяется необходимость распределения данных;
►	производится анализ использования данных;
►	производится физическое проектирование базы данных; ► определяются требования к аппаратным ресурсам;
►	определяются способы увеличения производительности; ► завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза
458
Проектирование информационных систем
построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки программной системы не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
Методология RAD, как и любая другая, не может претендовать на универсальность, она хороша, в первую очередь, для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонентов, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ, операционных систем, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени), и приложения, от которых зависит безопасность, так как итеративный под
глава 10
>ТТРоектиРование программных систем
459
ход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка.
В качестве итога перечислим основные принципы методологии RAD:
►	разработка приложений итерациями;
►	необязательность полного завершения работ на каждом из этапов жизненного цикла;
►	обязательное вовлечение пользователей в процесс разработки программного обеспечения;
►	необходимое применение CASE-средств, обеспечивающих целостность проекта;
►	применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
►	необходимое использование генераторов кода;
►	использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
►	тестирование и развитие проекта, осуществляемое одновременно с разработкой;
►	ведение разработки немногочисленной хорошо управляемой командой профессионалов;
►	грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
10.3.3.	Моделирование программных систем
Моделирование является широко распространенным приемом при проектировании систем.
Каждая модель описывает определенную часть проектируемой системы. В свою очередь, существует возможность построения новых моделей на базе ранее построенных.
460
Проектирование информационных систем
Модели предоставляют возможность исследования недостатков системы в определенных условиях.
При разработке моделей (моделировании) необходимым условием успешного результата является соблюдение принципов декомпозиции, абстракции, иерархии [2].
Абстрагирование. Абстрагирование является одним из главных способов, используемым для решения сложных задач.
Абстракция — это такие существенные характеристики некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют особенности данного объекта с точки зрения дальнейшего рассмотрения и анализа.
Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от деталей их осуществления.
Существует определенный спектр абстракций по принципу выделения:
►	абстракция сущности объекта — объект представляет собой модель существенных сторон предметной области;
►	абстракция поведения — объект состоит из обобщенного множества операций, каждая из которых выполняет определенную функцию;
►	абстрагирование в виде виртуальной машины — объект объединяет группы операций, которые либо используются для управления объектом, либо соответствуют функциям нижнего уровня;
►	произвольная абстракция — объект включает в себя набор независимых по отношению друг к другу операций. Выбор достаточного множества абстракций (не больше и не меньше целесообразного количества) является основной проблемой проектирования, заключенной в установлении числа требуемого количества абстракций в зависимости от опыта проектирования и знания предметной области проектировщиком.
Глава 10	zz>1
ТТРоектиРование программных систем ____________
Декомпозиция. При проектировании программной системы необходимо составлять ее из небольших подсистем, каждую из которых представляется возможным отладить независимо от других. Правильная декомпозиция системы определяет сложность, присущую разрабатываемой программной системе, обеспечивая разделение пространства состояний системы. Процессы декомпозиции и абстрагирования неразрывно связаны и являются взаимодополняемыми при проектировании программных подсистем.
При проектировании программной системы как вида обеспечения информационных систем возможна реализация двух подходов к декомпозиции.
Первый подход можно определить как декомпозицию программной системы в соответствии со структурой информационной системы. К достоинствам данного подхода можно отнести возможность независимой разработки программного обеспечения для подсистем информационной системы, что упрощает работу по созданию программного обеспечения и позволяет ориентировать отдельные модули на решение непосредственных задач тех подсистем, в рамках которых они реализуются. Основным недостатком такого подхода к декомпозиции является дублирование ряда функций, реализуемых в рамках разных подсистем информационной системы.
Вторым подходом к декомпозиции программной системы является декомпозиция на основании выделения тесно связанных и логически единых функций информационной системы, подлежащих реализации в программной системе. При этом декомпозицию целесообразно проводить на основании следующих критериев выделения подсистем программной системы:
►	единство выделяемых функций в процессе функционирования;
►	частота использования;
►	единство используемых данных и потоков информации.

462
Проектирование информационных систем
В процессе разделения системы на модули рекомендуется придерживаться следующих правил. Первое из них состоит в следующем: поскольку модули служат в качестве элементарных и неделимых (на определенном уровне) блоков программной системы, которые могут использоваться в системе многократно, распределение функций по модулям должно создавать для этого максимальные удобства. Второе правило заключается в ограниченности размера блока вследствие ограниченных возможностей программных средств разработки и технических средств.
Иерархия. Значительное упрощение понимания сложных задач в процессе проектирования достигается за счет образования иерархической структуры из абстракций и (или) модулей.
Иерархия — это ранжированная или упорядоченная система абстракций.
Формирование иерархической структуры является необходимым для понимания взаимосвязей и подчиненности объектов и модулей программной системы. Иерархическая структура может формироваться по принципу подчиненности единой цели, единому процессу, единству используемых данных и т.п.
Процесс формирования иерархической структуры неразрывно связан с процессами абстрагирования и декомпозиции.
Процесс моделирования. Моделирование является сложным многоступенчатым итерационным процессом. Моделирование программного обеспечения информационных систем обладает рядом особенностей:
►	необходимо соблюдать логическое соответствие модели программной системы модели информационной системы;
►	необходимо наряду с процессами, протекающими непосредственно в программной системе, отражать процессы, протекающие в информационной системе;
►	необходимо учитывать цели и задачи информационной системы.
Глава 10	46ч
ТТРоектиРование программных систем_____________
Основополагающим этапом проектирования является определение целей реализации программной системы, списка автоматизируемых функций и требований к ним, а также требований к реализации программной системы в целом.
Первым этапом моделирования является построение модели «черного ящика» системы.
При этом необходимо выделить:
1	) входную информацию для программной системы из информационной системы, ее вид: либо как единичные элементы, либо как единицы массива, либо как отдельные массивы, либо как элементы или массивы какой-либо структуры; информацию необходимо классифицировать по каналам поступления (БД, каналы связи, ввод с периферийных устройств и т.п.);
2	) выходную информацию из программной системы в информационную систему, ее вид; информацию необходимо классифицировать по каналам выдачи (БД, каналы связи, вывод на периферийные устройства и т.п.);
3	) физические и логические характеристики информации и способы ее приема или выдачи, т.е. объем, частоту, периодичность, условия приема — выдачи и т.п. в зависимости от специфики проектируемой программной системы и соответствующей ей информационной системы.
Те же самые операции необходимо проделать для выделения и характеристики потоков ввиду обеспечения взаимодействия программной системы с внешней средой.
Выделение групп информационных потоков для информационной системы и внешней среды обусловлено необходимостью последующей реализации некоторых функций для информации из внешней среды и их излишней реализации для информации из информационной системы. К таким функциям можно отнести процедуры специфической криптографии, проверки целостности, достоверности и т.п.
Вторым этапом моделирования является выделение абстракций, построение модулей и иерархии объектов программной системы.
464
км
Проектирование информационных систем
Данный этап проводится на основании целевой и функциональной декомпозиции программной подсистемы информационной системы и построения иерархии функций. Переход от построенной иерархии функций к иерархии объектов программной системы происходит на основании выделения абстракции и построения модулей путем отображения уровней иерархии функций нижнего уровня на множество абстракций реализации и последующего объединение в модули на основании рассмотренных выше принципов.
На следующем этапе построения модели программной системы происходит определение взаимосвязей между выделенными модулями на соответствующих уровнях и внешней средой. На данном этапе определяются типы и виды информационных потоков внутри системы, а также формируется ряд служебных модулей, реализующих функции обмена и преобразования данных. Также формируется даталогиче-ская структура системы.
На заключительном этапе выбирается базовый уровень в иерархии системы. Выбор базового уровня необходим для последующего определения программных модулей (отдельно формируемых частей кода). На данном уровне выполняется окончательное построение модели. Каждый модуль данной модели может быть расписан как отдельная программная система.
10.3.4.	Использование формальных спецификаций
Одним из методов выполнения этапов анализа и проектирования программного обеспечения является использование формальных спецификаций, описывающих абстракции процедуры, данные и итераторы в соответствии с приведенными ниже шаблонами [76].
Процедурная абстракция. Процедуры объединяют в себе методы абстракции через параметризацию и через спецификацию, позволяя абстрагировать отдельную операцию или событие. Процедура выполняет преобразование входных
Глава 10	46=
Проектирование программных систем_____________
аргументов в выходные. Более точно, это есть отображение набора значений входных аргументов в выходной набор результатов с возможной модификацией входных значений.
Спецификация процедуры состоит из заголовка и описания функции, выполняемой процедурой. Заголовок содержит имя процедуры, номер, порядок и типы входных и выходных параметров.
Семантическая часть спецификации состоит из трех предложений — requires (требует), modifies (модифицирует) и effects (выполняет).
Эти предложения должны появляться в указанном ниже порядке, однако предложения requires и modifies обязательными не являются.
Шаблон спецификации для процедурных абстракций:
►	proc_name = proc (входные данные) returns (выходные данные);
►	requires — этот оператор задает необходимые требования;
►	modifies — этот оператор идентифицирует все модифицируемые входные данные;
►	effects — этот оператор описывает выполняемые функции.
Предложение requires задает ограничения, накладываемые на абстракцию. Предложение requires необходимо в том случае, если процедура является частной, то есть если ее поведение для некоторых входных значений недетерминировано. Если же процедура глобальна, т.е. ее поведение определено для всех входных значений, то предложение requires может быть опущено. В этом случае единственными требованиями, предъявляемыми при обращении к процедуре, являются требования, указанные в заголовке, а также требования о числе и типе аргументов.
Оператор modifies задает список имен входных параметров, модифицируемых процедурой. Если входные параметры не указаны, то это предложение может быть опущено.
Предложение effects описывает работу процедуры со значениями, не охваченными предложением requires. Оно
466
Проектирование информационных систем
определяет выходные значения и модификации, производимые над входными параметрами, перечисленными в списке modifies. Предложение effects составляется исходя из предположения, что требования предложения requires удовлетворены. Однако в том случае, когда требования в предложении requires не удовлетворены, о поведении процедуры ничего не сообщается.
Процедурная абстракция есть отображение аргументов в результаты с возможной модификацией некоторых аргументов. Аргументы принадлежат области определения процедуры, а результаты — области изменения.
Часто процедура имеет смысл только для аргументов, принадлежащих подмножеству ее области определения. Такие процедуры приводят к неустойчивым программам. Устойчивая программа — это такая программа, которая ведет себя корректно даже в случае ошибки. То есть она должна вести себя определенным, предсказуемым образом.
Метод, который гарантирует устойчивость, заключается в использовании процедур, заданных на всей области определения. Если функция не способна осуществить предназначенные ей действия для некоторых аргументов, то она должна оповестить обратившегося к ней о возникшем затруднении.
Чтобы специфицировать процедуры, которые вызывают исключительные ситуации, в спецификацию следует добавить предложение signals.
Это предложение—часть заголовка. Оно следует за предложением returns. Если исключительных ситуаций не имеется, оно может быть опущено.
Шаблон спецификации для процедурных абстракций, обрабатывающих исключительные ситуации:
►	proc_name = proc (входные данные) returns (выходные данные);
►	signals (сообщения об исключительных ситуациях);
►	requires — этот оператор задает необходимые требования;
глава 10
^Проектирование программных систем
467
►	modifies — этот оператор идентифицирует все модифицируемые входные данные;
►	effects—этот оператор описывает выполняемые функции.
Как и раньше, секция effects должна определять поведение процедуры для всех фактических аргументов, отвечающих предложению requires. Так как это поведение включает в себя исключительные ситуации, секция effects должна определять, что приводит к вызову каждой исключительной ситуации и что делает процедура в каждом таком случае. Завершение процедуры происходит оповещением об исключительной ситуации — это один из нормальных режимов работы этой процедуры.
Исключительные ситуации следует использовать для устранения большинства ограничений, перечисленных в предложениях requires.
Эти предложения следует оставлять только из соображений эффективности или если контекст использования настолько ограничен, что можно быть уверенным в удовлетворении ограничений.
Абстракции данных. Абстракции данных — наиболее важный метод в проектировании программ. Выбор правильных структур данных играет решающую роль для создания эффективной программы. При отсутствии абстракций данных, структуры данных должны быть определены до начала реализации модулей. Абстракции данных позволяют отложить окончательный выбор структур данных до момента, когда эти структуры станут вполне ясны.
Так же, как для процедур, значение типа не должно задаваться никакой его реализацией. Вместо этого должна быть определяющая его спецификация. Так как объекты типа используются только вызовом операций, основная часть спецификации посвящена описанию того, что эти операции делают. Общий вид спецификации данных состоит из заголовка, определяющего имя типа и имена его операций, и двух главных секций — секции описания и секции операций.
468
м-
Проектирование информационных систем
Шаблон спецификации для абстракции типа данных:
►	data_name = data type is {список операций}',
►	описание {описание абстракции данных}', ► операции {спецификации для всех операций}', ► end data_name.
В секции описания тип описывается как целое. Иногда там дается модель для объектов, то есть объекты описываются в терминах других объектов — таких, которые по предположению понятны тем, для кого эта спецификация предназначена. В секции описания должно также указываться, изменяемый или неизменяемый это тип.
В секции операций содержатся спецификации для всех операций. Если операция — процедура, то ее спецификация будет процедурной спецификацией. В этих спецификациях могут использоваться концепции, введенные в секции описания.
Поведение объектов данных наиболее естественно представлять в терминах набора операций, применимых к данным объектам.
Такой набор включает в себя операции по созданию объектов, получению информации от них и, возможно, их модификации. Таким образом, абстракция данных (или тип данных) состоит из набора объектов и набора операций, характеризующих поведение этих объектов. Акцент на взаимосвязях между операциями делает абстракцию данных существенно отличной от набора процедур.
Абстракции итерации. Для работы с набором данных требуется некоторый общий метод итерации, который удобен и эффективен и который сохраняет абстракцию через спецификацию. Итератор обеспечивает эти требования. Он вызывается как процедура, но вместо окончания с выдачей всех результатов имеет много результатов, которые каждый раз выдает по одному. Полученные элементы могут использоваться в других модулях, которые задают действия, выполняемые для каждого такого элемента. Использующий итератор модуль будет содержать некоторую структуру организации цикла. Каждый раз, когда итератор выдает
рлава 10
д“Проектирование программных систем
469
некоторый элемент, над этим элементом выполняется тело цикла. Затем управление возврашается в итератор, так что он может выдавать следующий элемент.
Следует отметить разделение обязанностей в такой форме взаимодействия. Итератор ответственен за получение элемента, а модуль, содержащий цикл, определяет то действие, которое будет над ним выполняться.
Итераторы являются некоторой обобщенной формой методов итерации, имеющихся в большинстве сред программирования. Как и другие абстракции, итераторы должны быть определены через спецификации. Форма спецификации итератора аналогична форме для процедуры.
Шаблон спецификации абстракции итератора:
►	iter_name - iter (входные данные) fields (выходные данные);
►	signals (сообщения об исключительных ситуациях);
►	requires — этот оператор задает необходимые требования;
►	effects—этот оператор описывает выполняемые функции.
Ключевое слово iter используется для обозначения абстракции итератора и содержит входные данные. Итератор может совсем не выдавать объектов на каждой итерации или выдать несколько объектов. Число и тип этих объектов описываются в предложении fields. Итератор может не выдавать никаких результатов, когда он заканчивается нормально. но он может заканчиваться по исключительной ситуации с именем и результатами, указанными в предложении signals.
Таким образом, решается проблема полноты типов данных, которые являются совокупностью объектов. Поскольку совокупность используется для выполнения некоторого действия над ее элементами, необходим некоторый способ доступа ко всем элементам. Этот способ должен быть эффективным в смысле времени и пространства, удобным для использования и не должен разрушать данную совокупность. Кроме того, он должен обеспечивать абстракцию через спецификацию.
470
Проектирование информационных систем
Итераторы являются механизмом, решающим эту задачу. Поскольку они выдают объекты по одному, не требуется дополнительного пространства для хранения объектов, и процедура может быть остановлена, когда нужный объект будет найден. Метод выдачи объектов зависит от знания представления этих объектов, но использующие его программы защищены от этого знания. Итераторы полезны сами по себе, однако, их основным применением являются операции над типами данных.
Современные методы проектирования деятельности пользователей программного обеспечения информационных систем сложились в рамках системотехнической концепции проектирования, в силу чего учет человеческого фактора ограничился решением проблем согласования «входов» и «выходов» человека и машины. Вместе с тем при анализе неудовлетворенности пользователей программных систем удается выявить, что она часто объясняется отсутствием единого комплексного подхода к проектированию систем взаимодействия.
Использование системного подхода позволяет принять во внимание множество факторов самого различного характера, выделить из них те, которые оказывают самое большое влияние с точки зрения имеющихся общесистемных целей и критериев, и найти пути и методы эффективного воздействия на них. Системный подход основан на применении ряда основных понятий и положений, среди которых можно выделить понятия системы, подчиненности целей и критериев подсистем общесистемным целям и критериям и т.д. Системный подход позволяет рассматривать анализ и синтез различных по своей природе и сложности объектов с единой точки зрения, выявляя при этом важнейшие черты функционирования системы и учитывая наиболее существенные для всей системы факторы. Значение системного подхода особенно велико при проектировании и эксплуатации таких систем, как информационные системы, которые по
глава 10
*у~[роектирование программных систем
471
существу являются человеко-машинными системами, где человек выполняет роль субъекта управления.
Системный подход при проектировании представляет собой комплексное, взаимосвязанное, пропорциональное рассмотрение всех факторов, путей и методов решения сложной многофакторной и многовариантной задачи проектирования интерфейса взаимодействия. В отличие от классического инженерно-технического проектирования, при использовании системного подхода учитываются все факторы проектируемой системы — функциональные, психологические, социальные и даже эстетические.
Автоматизация неизбежно влечет за собой осуществление системного подхода, так как она предполагает наличие саморегулирующейся системы, обладающей входами, выходами и механизмом управления. Уже само понятие системы взаимодействия указывает на необходимость рассмотрения окружающей среды, в которой она должна функционировать. Таким образом, система взаимодействия должна рассматриваться как часть более обширной системы — ИС реального времени.
В настоящее время можно считать доказанным, что главная задача проектирования интерфейса пользователя заключается не в том, чтобы рационально «вписать» человека в контур управления, а в том, чтобы, исходя из задач и целей системы, разработать подсистему взаимодействия двух равноправных партнеров (человек-оператор и аппаратно-программный комплекс информационной системы), рационально и эффективно функционирующих.
10.4. Архитектура информационной системы
Целью пункта является формализация представления архитектуры проектируемой информационной системы. Рассматривается схема Захмана, предназначенная для формирования взгляда на архитектуру информационной системы
472
Проектирование информационных систем
с точки зрения участников ее разработки. Предлагается аналогичная схема, в которой информационная система рассматривается в терминах различных подходов к моделированию бизнеса. Схема позволяет осознать место каждого из таких подходов в создании информационной системы, а также определить границы деятельности каждого из ее создателей [70].
10.4.1. Моделирование бизнеса и архитектура информационной системы
Методики моделирования. В этом разделе описывается та часть подхода Р. Баркера к проектированию информационных систем, которая соответствует методикам моделирования бизнеса. Подход носит название «CASE*Method» [70]. Внедрение информационной системы всегда приводит к реорганизации бизнеса. В значительной степени предмет деятельности остается без изменений, в то время как меняются способы и участники этой деятельности. Модели, используемые для определения потребностей бизнеса, должны позволять делать обоснованные изменения в организационной структуре и как можно меньше зависеть от известных информационных технологий. Необходимо сделать систему открытой в сторону введения новых процедур, например, производства, продаж, управления или учета.
Требования должны моделироваться и определяться настолько общим способом, насколько это возможно; функциональные потребности должны определять, что делается, а не как или кем. Структура данных может быть рассчитана на изменения в организационной структуре и на текущие и ожидаемые исключения и ограничения. Приведенная на рис. 10.1 диаграмма иллюстрирует несколько главных технологий моделирования, а также места их пересечения. Каждая из этих моделей реального мира должна соответствовать контексту общего направления бизнеса, которое определяется его задачами, приоритетами и критическими для успеха факторами.
Рассмотрим таблицу, иллюстрирующую использование названных методов (см. рис. 10.1) на разных стадиях развития системы (табл. 10.1).
Таблица 10.1
Таблица использования методов моделирования
Методы	Уровень бизнеса	Системный уровень	Программно-процедурный уровень
Функциональная иерархия	О	о	о
Анализ состояний	н	о	н
Диаграммы потоков данных	н	о	н
Событийное моделирование	н	о	о
Функциональная логика	о	о	н
Примечание:
о — обязательное использование;
н — необязательное, но возможное использование.
474
Проектирование информационных систем
Схема Захмана. В 1987 г. Джон Захман опубликовал полезную схему развития архитектуры информационной системы (рис. 10.2). Схема создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видят систему ее заказчик, проектировщик и разработчик, причем, в разрезе трех выбранных аспектов. Эти три аспекта — данные, функции и сетевая структура. В схеме Захмана строке соответствует точка зрения какого-либо участника проекта по созданию системы. Аспекты представлены в схеме колонками.
Архитектурное представление — это ячейка таблицы, соответствующая пересечению выбранного столбца и выбранной строки. Например, с точки зрения разработчика (технологическая модель) информационное архитектурное представление (данные) — это проект структуры данных. Взгляд какого-либо лица — это совокупность ячеек в пределах одной строки (точки зрения), то есть совокупность архитектурных представлений с выбранной точки зрения, соответствующая выбранным аспектам системы.
Захман определяет архитектуру как представление конечного продукта (в данном случае информационной системы) с точки зрения одного из заинтересованных лиц. Таким образом, существует не одна архитектура, а некое множество архитектур. В зависимости от того, кем вы являетесь и на каком аспекте фокусируете внимание, вы видите архитектуру системы по-разному. Далее приводится более развернутое описание подхода Захмана [70].
Точки зрения. Точки зрения отражают значение и области ответственности заинтересованных лиц в процессе создания системы. Заказчик видит систему с точки зрения общих стратегических и тактических аспектов. Эти аспекты могут лежать в очень широкой области (бизнес в целом или, напротив, его часть) и не всегда могут быть определены точно. Архитектурные представления, соответствующие точке зрения заказчика, находятся в двух верхних строках таблицы. Начальное планирование бизнеса и анализ обычно определяют
Глава 10
*упроектирование программных систем
475
		DATA		FUNCTION			NETWORK	
OBJECTIVES/ SCOPE	List of Things important to the Business			List of Processes the Business Performs			List of Location in Which the Business Operates	
		-						
	Entity = Class of Business Things			Processes = Class of Business Process				
MODELOF THE BUSINESS	e.g.. Entity Relationship Diagram Ent. = Business Entity Rel. = Data Rel.			e.g.. Data Flow Diagram Proc. = Bus. Process I/O = Bus. Resource (including info.)			e.g.. Logistics Network Node = Business Unit Link = Bus. Relationship (Org. Product, info.)	
MODELOF THE INFORMATION SYSTEM	e.g., Data Model Ent. - Data Entity Rel. = Data Rel.			e.g., Function Diagram Proc. = Appl. Functions 1/0 = User Views (set of Data Elements)			e.g., distributed Sys. Arch Node = I/S Function (Process, Storage, etc.) Link = Line Char.	
TECHNOLOGY MODEL	e.g., Data Design			e.g.. Structure Chart			e.g.. System Arch	
	Ent. = Segment/Row Rel. = Pointer/Key			Proc. = Computer Function I/O = Screen/Devise Formats			Node= Hardware/Sys. Software Link= Line Specs.	
DETAILED REPRESENTATION	e.g., Data Design Description			e.g., Program Description			e.g., Network Arcitecture	
		Й1 1			и			
	Ent. = Fields Rel. == Addresses			Proc. = Language Stmts. I/O = Control Blocks			Node= Link =	Addresses Protocols
FUNCTIONING SYSTEM	e.g., DATA			e.g..	FUNCTION		e.g., COMMUNICATIONS	
Рис. 10.2. Схема Захмана
476
в»
Проектирование информационных систем
первые уровни детализации для этих архитектурных представлений. Определенно установленные цели бизнеса и его требования к системе полностью детализируют каждое из представлений.
Представления проектировщика, несмотря на то, что рассматривается одна и та же система, существенно отличаются от представлений заказчика, причем не только дополнительными деталями. Представления проектировщика — это проект системы, обеспечивающей удовлетворение требований, которые, в свою очередь, описываются представлениями заказчика. Во многом представление проектировщика добавляет точность, необходимую для тех, кто будет реализовывать систему, но представления проектировщика и заказчика остаются независимыми от технологий, которые будут использоваться при реализации. Структурный анализ, информационное моделирование и некоторые виды прототипирования являются методами, которые могут быть использованы для формирования архитектурного представления проектировщика. Точке зрения проектировщика соответствует третья строка в схеме Захмана.
Проекты, связанные с созданием систем, наиболее успешны, когда компоненты каждого из технологически независимых взглядов, соответствующие данным, функциям и сетевой структуре (три верхних строки), разрабатываются одновременно командой, хорошо понимающей бизнес и имеющей опыт в разработке приложений и сетей, а также в администрировании данных. Хотя каждый участник может представлять свою точку зрения (заказчик или проектировщик) или фокусироваться на своих аспектах (данные, функции или сети), но он вносит свой набор знаний. Эти наборы знаний в совокупности дают хорошую общую картину требуемой системы. В достаточной степени проектировщики должны понимать точку зрения заказчика, и наоборот. Заказчик и проектировщик не могут развивать свои взгляды независимо. Физическое воплощение логических требований зависит от характеристик аппаратно-программной базы, выбранной для реализации системы. В отличие от же
глава 10	_
АПРоек™Рование программных систем________________
лаемых логических связей, реальные связи зависят от физических ограничений. Таким образом, необходимо знать, что мы хотим, перед тем, как делать вывод о невозможности чего-либо. Технология ограничивает решения задач, а не их условия.
Технологические соображения начинают играть роль при формировании точки зрения разработчика. Взгляды заказчика и проектировщика отражают потребности бизнеса. Взгляд разработчика отражает множество решений, ограниченных технологией, временем и стоимостью. Точки зрения разработчика соответствуют четвертой и пятой строкам в схеме. Как и ранее, это не просто следующий уровень детализации взглядов проектировщика. Они представляют сдвиг точки зрения с логического уровня (требования) на физический уровень (решения).
Существует еще одна, отдельная, точка зрения оператора системы. Деятельность оператора — это, с одной стороны, ежедневная поддержка работоспособности системы и ее мониторинг, с другой — повседневное использование системы в бизнесе. Точка зрения оператора представлена последней строкой схемы.
Важно помнить, что строки схемы представляют разные точки зрения, а не разные уровни детальности представления. Для каждой ячейки таблицы может быть сделано многоуровневое описание. Необходимо понимать, что могут быть ситуации, в которых важно понятие взгляда, то есть совокупности архитектурных представлений, находящихся в пределах одной строки. Разным строкам соответствует разное понимание предмета. Чтобы сформировать взгляд, отражающий другую точку зрения, необходим некий переход.
Аспекты. Три аспекта, рассмотренных в схеме, приводят к различным архитектурным представлениям каждой из точек зрения. Аспекты соответствуют вопросам «Что?», «Как?» и «Где?», относящимся к конечному продукту (информационной системе). Каждому аспекту соответствуют разные методы формирования представления.
478
Проектирование информационных систем
Колонка данных соответствует вопросу «Что?». В строительной промышленности, например, соответствует списку материалов и частей, используемых при строительстве здания, и взаимосвязям между этими частями. Внимание концентрируется на том, из чего строится здание, а не как и где оно строится. Для информационных систем вопрос «Что?» относится к сущностям данных и их связям.
Колонка функций соответствует вопросу «Как?». Она описывает, как работают отдельные части системы. В информационных системах функции обычно определяются входами (элементы данных), процессами (преобразования) и выходами (элементы данных). Внимание уделяется не столько отдельным частям и их связям, сколько тому, как эти части взаимодействуют при выполнении общей задачи.
Колонка сетевой структуры соответствует вопросу «Где?». Архитектурные представления в этой колонке описывают местоположение элементов системы и механизмы их взаимодействия.
Названия строк и столбцов. Схема Захмана является простым, но достаточно мощным средством. Эта мощность особенно хорошо видна при попытке ее расширения. В этом разделе приведены краткие дополнительные соображения о схеме, а также некоторые моменты, о которых следует помнить при ее использовании.
Важно понимать, что схема Захмана не является каким-либо алгоритмом действий, она лишь направляет наши соображения по нужному пути. Благодаря своей простоте, схема позволяет понять, как должна быть спроектирована и разработана информационная система не только в терминах методов проектирования и разработки, но и в терминах набора элементов системы.
При использовании схемы Захмана требуется четко представлять, что означают строки и столбцы в таблице. В каждой ячейке представлен вид конечного продукта (архитектурное представление) с точки зрения некоторой группы лиц, участвующих в разработке системы. Строки представляют их точки зрения, и, хотя процесс разработки системы явля
глава 10	/-Q
Проектирование программных систем;
ется последовательным выполнением действий, характерных для каждой из этих групп (от заказчика к проектировщику, от проектировщика к разработчику), Захман выступает против рассмотрения строк как уровней детальности представления.
Важное замечание по поводу архитектурных представлений состоит в том, что все они имеют различную природу. Это не просто набор представлений, уровень детальности которых увеличивается с прохождением каждого нового этапа. Уровень детальности — это независимая переменная, меняющаяся внутри каждого архитектурного представления.
Здесь используются следующие термины описания строк. Строка является точкой зрения. Точка зрения отражает область интереса или ответственности группы заинтересованных лиц. Все точки зрения относятся к одному и тому же продукту. Они согласуются с понятием взгляда заказчика, проектировщика и разработчика. Таким образом, точки зрения разных участников проектной группы различаются. Взгляд охватывает часть ячейки, всю ячейку или несколько ячеек в пределах одной строки. Взгляд может быть порожден любой точкой зрения (хотя он может быть шире или уже по размеру предметной области) и может быть представлен на любом подходящем уровне детальности. Взгляд отражает интересы конкретного участника проекта, ограниченные рамками выбранных аспектов.
Характеристика взгляда состоит из двух частей.
1.	Описание взгляда, включающее:
►	точку зрения (статус человека, имеющего данный взгляд); ► что показывает взгляд (аспект);
►	технику или язык, описывающий данный взгляд (например, IDEF1X для аспекта данных, IDEF0 или диаграмма потока данных для функционального аспекта);
►	уровень детальности (высокий или низкий);
►	предметную область (узкая или широкая);
►	предполагаемое использование (как будет использоваться взгляд);
►	пользователя (кто будет использовать взгляд);
480
Проектирование информационных систем
►	граничные предположения (предположения по поводу интеграции этого взгляда с другими).
2.	Управляющая информация о взгляде:
►	как был разработан взгляд;
►	с кем контактировать для управления изменениями;
►	статус (насколько взгляд полон и насколько определен); ► составные части (например, диаграммы, глоссарии, тенденции, критические для успеха факторы).
Представление предметной области подразумевает представление аспекта. В качестве аналогии рассмотрим процесс фотографирования (получения взгляда) с определенной точки зрения. Когда мы фотографируем автомобиль, пытаемся ли мы сфокусироваться на его составных частях (множестве материалов), на том, как он ездит (процесс), на его фор-мё (связи), или мы пытаемся отразить все эти аспекты на одном и том же снимке? В фотографии так же, как и в архитектуре, трудно дать детальное представление многих аспектов одновременно с помощью одного взгляда.
Аспект представляется колонкой таблицы. Мы связываем аспект данных с моделями данных, аспект функций с функциональными моделями и аспект сетей — с сетевыми моделями. Иными словами, мы связываем аспекты разных объектов с соответствующими объектными моделями.
Взгляд не может содержать архитектурные представления, находящиеся в разных строках, хотя он может быть шире или уже по количеству аспектов. Тем не менее может быть произведена трансформация одного взгляда в другой. Под этим понимается преобразование взгляда с одной точки зрения во взгляд с другой точки зрения. Преобразование — это переход от одной строки к другой.
Схема Захмана является контекстом для изучения различных взглядов на одну и ту же систему. Схема поддерживает множество взглядов, отражающих разные аспекты конечного продукта. Эти взгляды важны для разных людей и созданы с их точек зрения. Схема представляет всем участникам CASE-проекта контекст для описания информаци
глава 10
1 Проектирование программных систем
481
онной системы на понятном и приемлемом для каждого участника языке.
Дополнение схемы. Начальный вид схемы был разработан для представления архитектуры информационной системы с учетом трех ее аспектов, так что естественно рассуждать о том, что произойдет с названиями и описаниями столбцов и строк, когда количество аспектов будет увеличено.
До сих пор рассматривалась информационная система, ориентированная на полную автоматизацию, в то время как на самом деле в систему поддержки бизнеса могут входить ручные процедуры, описание и смысл которых должны отражаться в архитектурных представлениях. Поэтому естественно попытаться дополнить схему Захмана аспектами, соответствующими вопросам «Кто?», «Когда?» и «Почему?».
Наилучшим решением было бы использование для столбцов названий «Что?», «Как?», «Где?», «Кто?», «Когда?» и «Почему?», но даже такая схема не будет универсальной. Потеря универсальности может быть большей или меньшей в зависимости от того, насколько конкретный смысл мы вкладываем в каждый из аспектов.
Расширение схемы требует некоторого пересмотра названий строк. Предметная область и моделирование бизнеса остаются в первых двух строках. Если определить систему как частично автоматизированную, частично ручную, модель информационной системы трансформируется в модель системы вообще. Поскольку учитываются человеческие и другие ресурсы, технологическая модель становится моделью распределения ресурсов. Детальное представление сохраняет название.
Название нижней строки таблицы может варьироваться. Если можно определить одну или несколько точек зрения (например, точку зрения оператора системы), которые будут сильно отличаться от точек зрения проектировщика, разработчика или владельца, то название «функционирование системы» является вполне уместным.
Выбор хороших названий для столбцов и строк является более важной проблемой, чем может показаться в первом 16. Зак. 1035
482
Проектирование информационных систем
приближении. Одна из сильнейших сторон захмановской схемы состоит в том, что в ней используются аналогии, а также термины, знакомые различным категориям пользователей (заказчики, проектировщики, разработчики).
Интеграция схемы Захмана с методами моделирования бизнеса. Ранее были представлены два подхода к моделированию потребностей бизнеса, необходимому для разработки поддерживающей бизнес информационной системы. В каждом из подходов предполагается использование рассмотренных технологий моделирования. Сравним два этих подхода.
В подходе Баркера ИС развивается со временем, в процессе последовательного прохождения различных этапов жизненного цикла системы. Каждому этапу приписан набор методик, обязательных или необязательных для использования.
В подходе Захмана не делается акцент на динамике развития ИС. При переходе от одной строки таблицы к другой меняется лишь точка зрения, с которой рассматривается система, причем эта точка зрения не обязательно должна быть связана с уровнем детальности рассмотрения. В схеме Захмана отражены аспекты системы, приблизительно соответствующие некоторым методикам моделирования (информационное моделирование, диаграмма потоков данных и т.д.).
Представляет интерес составить схему, аналогичную схеме Захмана, в которой в качестве аспектов при формировании архитектурных представлений использовалась бы хотя бы часть методик, представленных на диаграмме Баркера. Три основные части диаграммы — функциональное моделирование, информационное моделирование и событийное моделирование. Их пересечения — диаграммы потоков данных, анализ состояний, информационная динамика и функциональная логика.
В таблице 10.2 перечислены известные нам инструментальные средства (программные продукты или технологические схемы), поддерживающие эти методики.
’’лава 10
Проектирование программных систем
483
Таблица 10.2
Инструментальные средства
Методики	Инструментальные средства	Комментарии
ФМ	FH Diagram, IDEF0	Иерархические функциональные модели
ИМ	ER Diagram, IDEF1X	Диаграммы сущность-связь
см	-	Четкого стандарта нет
ФМ&ИМ	DataFlow Diagram, IDEFO	Диаграммы потоков данных
ФМ&СМ	Process Modeller	Моделирование процессов
им&см	SSADM. Entity Life History	
ФМ&ИМ&СМ	Function Logic, CPN Описана в Oracle	CASE*Method Раскрашенные сети Петри
Каждая из перечисленных в табл. 10.2 методик, кроме последней, имеет программную поддержку. Семейство методологий IDEF является альтернативой использования некоторых средств Oracle CASE*Method. Прочерк в строке, соответствующей методике СМ, указывает на отсутствие методологических стандартов. Эта методика используется в различных проектах в зависимости от ситуации. Схема применения методики создается в организации, выполняющей заказ по созданию системы, на основе накопленного опыта работы. Построим теперь схему Захмана, основанную на семи перечисленных аспектах и различных точках зрения (табл. 10.3 и 10.4).
При применении модели CPN оптимальность функционирования системы определяется тем, насколько успешно модель применена на стадии разработки системы (собственно, на стадии функционирования модель уже не используется). Модель может также применяться в проектах,
16*
Таблица 10.3
Интегрированная схема архитектуры информационной системы (модели)

Точки зрения	ИМ	ФМ	СМ
Цели/ Предметная область	Список важнейших объектов бизнеса	Список процессов, выполняемых бизнесом	Список возможных событий
Бизнес-модель	Диаграмма сущность — связь (ERD)	Функциональная иерархия (FH) в терминах бизнеса	Временная схема наступления событий
Бизнес-модель	Сущность = Объект бизнеса Связь = Взаимоотношение элементов бизнеса	Процесс = Процесс бизнеса	Событие = Событие бизнеса
Модель ИС	Проект базы данных Сущность = = Сущность данных Связь = Отношение данных	FH в терминах ИС Процесс = Прикладная функция	Схема событий в ИС Событие = Событие в системе
Технологическая модель	Структура базы данных Сущность = Строка Связь = Указатель/ Ключ	Структурная диаграмма Процесс = Компьютерная функция (модуль)	Структура прерываний Событие = Запуск модуля реакции
Детальное представление	Описание структуры данных Сущность = Поле Связь =Адрес	Описание программы Процесс = Текст программы	Описание программы обработки событий Событие = Запуск программы реакции
Функционирование системы	Данные	Модули	Реакция на событие
Таблица 10.4
Интегрированная схема архитектуры информационной системы (взаимосвязь моделей)
Точки зрения	ФМ&ИМ	ФМ&СМ	им&см	ИМ&ФМ&СМ
1	2	3	4	5
Цели/ Предметная область	Описание процессов и их входов и выходов	Описание функций обработки событий	Описание динамики изменений в понятиях	Детальное описание функционирования бизнес-процессов в терминах функций, данных,событий
Бизнес-модель	Матрица Функция бизнеса/ Сущность бизнеса (объект)	Матрица Функция бизнеса/ Событие бизнеса	История изменения сущностей бизнеса	Блок-схема на уровне объектов бизнеса Блок = Функция Триггер = = Событие Переход = = Сущность бизнеса
Модель ИС	Диаграмма потоков данных Процесс = Функция; Поток = Сущность данных	Диаграмма процесса Процесс = Функция; Событие = Событие в системе	История изменения сущностей данных	Сеть Петри Место = Функция; Переход = Событие в системе; Фишка = Сущность данных
Технологическая модель	Функциональная диаграмма Функция = Транзакция; Вход/ Выход = Строка	Диаграмма процесса Процесс = Процедура реакции; Событие = Запуск процедуры	График изменения данных Сущность = = Строка; Событие = = Реакция	Блок-схема с учетом результатов моделирования Петри, Блок = Процедура;
ЧЛ
со
486
Проектирование информационных систем
	Точки зрения	1	Описание всех модулей ИС	Модуль ИС
ТГ	Точки зрения |	Описание структуры изменения информации по событиям	Изменение базы данных
	1 Точки зрения	Программа Событие = = Реакция Функция = Процедура обработки	Модуль обработки (интерфейс)
гч	Точки зрения	i	Программа Функция = Модуль транзакции; Вход /Выход = = Элемент данных	Модуль транзакции (интерфейс)
r—t	Точки зренияИ	Детальное представление	Функционирование системы
глава 10
х Проектирование программных систем
487
ограничивающихся стратегическим обследованием. Кроме того, возможности модели могут быть расширены путем использования техники сетей Петри. Применение смешанных методик не всегда обязательно. Это зависит от задач, решаемых в исследуемой организации, а также от технологических возможностей исполнителя.
Использование интегрированной схемы даст возможность применять ее на всех этапах жизненного цикла системы для формирования точек зрения всех участников CASE-проекта, причем каждый участник или группа участников проекта получат четкое представление о том, что от них требуется. Предложенная схема, так же, как и схема Захмана, не является немедленным руководством к действию. Ее назначение состоит в том, чтобы обеспечить понимание архитектуры информационной системы на разных стадиях разработки и с точки зрения разных участников проекта.
10.4.2.	Конфигурация и архитектура информационной системы
Архитектура информационной системы — концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.
Правильная и четкая организация информационных биз-нес-решений является непременным фактором успеха любой компании. Особенно важен этот фактор для предприятий среднего и малого бизнеса, которым необходима система, способная предоставить весь объем бизнес-логики для решения задач компании. В то же время такие системы для компаний со средним и малым масштабом сетей часто подпадают под критерий «цена — качество», то есть должны обладать максимальной производительностью и надежностью при доступной цене [77].
В условиях зависимости бизнеса от информационных систем разработчикам приходится сталкиваться не только с задачами реализации адекватных техническим требованиям
488
Проектирование информационных систем
функциональности и пользовательского интерфейса, но и с оптимизацией обмена данными между различными компонентами системы. Высокий уровень сложности корпоративных ИС задает повышенные требования к надежности и управляемости АИС в процессе их эксплуатации, что, в свою очередь, приводит к необходимости выделения из клиентской и серверной части системы компонентов, несущих на себе строго определенную служебную функциональность.
При декомпозиции системы на функциональные фрагменты можно выделить следующие компоненты:
—	презентационная логика (Presentation Layer — PL);
—	бизнес-логика (Business Layer — BL);
—	логика доступа к ресурсам (Access Layer — AL).
Клиент-серверная технология — это стиль работы приложений, где клиентский процесс запрашивает обслуживание у процесса сервера. Проще говоря, сервер — это программа, предоставляющая доступ к каким-либо услугам, например, к электронной почте, файлам, Web или данным (в качестве сервера баз данных). Клиент — это приложение, которое соединяется с сервером, чтобы воспользоваться предоставляемыми им услугами.
До клиент-серверной архитектуры были еще два других важных типа архитектуры:
►	локальная архитектура, при которой вся бизнес-логика, хранение данных, доступ к данным и вычисления производились на одном компьютере;
►	файл-серверная архитектура — представительская и бизнес-логика сосредоточены на локальном компьютере, а данные могут быть размещены в локальной сети на файловом сервере.
Клиент-серверная архитектура включила в себя лучшие особенности как локальной, так и файл-серверной архитектуры.
Таким образом, можно прийти к нескольким моделям клиент-серверного взаимодействия:
1.	«Толстый» клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже вне
глава 10
жТТРоектиРование программных систем
489
дренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как PL, так и BL. Серверная часть, при описанном подходе, представляет собой сервер баз данных, реализующий AL.
2.	«Тонкий» клиент. Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.
3.	Сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL.
Проникновение информационных технологий в сферу бизнеса привело к тому, что системы корпоративных масштабов требуют сочетания различных клиент-серверных моделей в зависимости от задач, решаемых на различных конкретных направлениях деятельности предприятия.
Первоначально системы базировались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture) (рис. 10.3).
Рис. 10.3. Двухуровневая клиент-серверная архитектура
490
Проектирование информационных систем
Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей — автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и другие. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена «толстым» клиентом, то есть приложением (АРМ), на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры она обладает множеством недостатков', высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за «размазанной» бизнес-логики между АРМом и сервером БД. При большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, как к самому дорогостоящему узлу в любой информационной системе.
Минусов у такой архитектуры достаточно, а решение тривиально — нужно отделить бизнес-логику от клиентской части и СУБД, выделив ее в отдельный слой. Так и поступили разработчики, и следующим шагом развития клиент-серверной архитектуры стало внедрение среднего уровня, реализующего задачи бизнес-логики и управления механизмами доступа к БД (рис. 10.4).
Достоинства трехуровневой архитектуры определяются благодаря концентрации бизнес-логики на сервере приложений, что обеспечивает возможность подключения различных БД: сервер базы данных освобождается от задач распараллеливания работы между различными пользователями, что существенно снижает его аппаратные требования; снижаются требования к клиентским машинам за счет выполнения ресурсоемких операций сервером приложений. Такую схему построения информационных систем часто называют архитектурой «тонкого» клиента.
глава 10
жууроектирование программных систем
491
«и
Рис. 10.4. Трехуровневая клиент-серверная архитектура (Three-tier architecture)
Недостатками, как и в двухуровневой клиент-серверной архитектуре, являются повышенные требования к пропускной способности сети, накладывающие жесткие ограничения на использование таких систем в сетях с неустойчивой связью и малой пропускной способностью (Internet, GPRS, мобильная связь). Самый верхний уровень (АРМы), обладающий огромной вычислительной мощностью, в действительности простаивает, занимаясь лишь выводом информации на экран пользователя.
Трехуровневая архитектура является частным случаем многоуровневой модели, объединяющей различных по «толщине» клиентов, серверы баз данных и множество специализированных серверов приложений, взаимодействующих на базе открытых объектных стандартов. Существенным облегчением в реализации многоуровневых гетерогенных систем является активная работа ряда производителей программного обеспечения, направленная на создание переходного ПО.
492
Проектирование информационных систем
Применение распределенной архитектуры (рис. 10.5) позволяет решать задачи, которые формулируются недостатками многоуровневой модели.
Рис.10.5. Распределенная архитектура системы
При таком способе построения архитектуры ИС более 95% данных могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы. Поток исправлений и дополнений, создаваемый на компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому, если хранить непрерывно используемые данные на самих компьютерах и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизится. Минимизация трафика между элементами снижает стоимость эксплуатации такой связи. Каждый АРМ независим, содержит только ту информацию, с которой должен работать, а актуальность данных во всей системе обеспечивается благодаря непрерывному обмену сообщениями с другими АРМами. Обмен сообщениями между АРМами может быть реализован различными способами,
глава 10
Проектирование программных систем_______________
от отправки данных по электронной почте до передачи данных по сетям.
Еще одним из преимуществ такой схемы эксплуатации и архитектуры системы является обеспечение возможности персональной ответственности за сохранность данных. Так как данные, доступные на конкретном рабочем месте, находятся только на этом компьютере, при использовании средств шифрования и личных аппаратных ключей исключается доступ к данным посторонних, в том числе и IT-администраторов.
Итак, рассмотренная модель построения распределенных систем вполне способна решить и реализовать функции современного программного обеспечения для предприятий среднего и малого бизнеса. Построенные на основе данной архитектуры системы будут обладать надежностью, безопасностью информации и высокой скоростью вычислений.
В качестве недостатка архитектуры необходимо отметить повышенные требования к синхронизации данных и управление ею.
? | Контрольные вопросы
1.	Каковы основные цели проектирования программных систем?
2.	Дайте определение понятию «проектирование программных систем».
3.	Какие требования предъявляются к проектированию программных систем?
4.	Дайте характеристику категориям пользователей программных систем.
5.	В чем заключаются основные принципы проектирования программных систем?
6.	Что определяют общесистемные принципы?
7.	Какие требования предъявляются к методологии и технологии проектирования программных систем?
8.	Какие стандарты используются при проектировании программных систем?
^94	Проектирование информационных систем
9.	Дайте характеристику фазам проектирования RAD-методологии. Перечислите основные принципы методологии.
10.	Какие основные принципы необходимо соблюдать при моделировании программных систем?
11.	Дайте определение понятия «формальная спецификация». Каково ее предназначение?
12.	Охарактеризуйте основные методы проектирования программных систем.
13.	Какая модель позволяет описать архитектуру информационной системы, в чем заключается ее сущность?
14.	С какими методами проектирования информационных систем возможна интеграция схемы Захмана?
15.	Раскройте физические аспекты проектирования архитектуры информационной системы.
Заключение
Информационные системы сейчас рассматриваются как неотъемлемая, более того, критически важная составляющая современного бизнеса. Невозможно представить себе устойчиво функционирующее предприятие без средств поддержки его основных бизнес-функций в виде мощного центра информационных технологий. Каждое крупное подразделение подобных предприятий также имеет в своем распоряжении соответствующую ИТ-инфраструктуру. Поэтому как нельзя более логичным решением, направленным на достижение максимального синергетического эффекта, является необходимость комплексного подхода к системному проектированию ИС и ее архитектуре. Для решения данной проблемы необходим не только пересмотр традиционных представлений о концептуальной бизнес-модели организации, об архитектуре ИС, но и глобальная переоценка места и значимости информационных технологий в структуре современных компаний.
В основу новых концептуальных представлений должны быть положены как можно более формализованные математические модели и методы анализа и синтеза проектных решений, поскольку конкурентоспособное функционирование современного предприятия возможно только при условии постоянного стратегического совершенствования его системы управления производством товаров и услуг на базе модельного представления с применением новейших информационных технологий.
Прежде всего, речь идет о базовых принципах, на которых основано создание и развитие сложных информационных систем. В них используются элементы системного, структурного и объектного анализа. Предстоит решать сложные проблемы создания библиотек системных методов, технологий и приемов проектирования, а также синтеза базовых моделей-конструктов разрабатываемых объектов,
496
Проектирование информационных систем
предназначенных для анализа проектных решений и проведения исследований в рамках заданной предметной области.
Ориентация на процессы, а не на функциональные задачи приводит в итоге к тому, что в большинстве современных методик проектирования информационных систем, в том числе корпоративных, за основу принято описание деловых, или иначе, бизнес-процессов, происходящих в той или иной компании. Бизнес-процессы являются одним из видов функциональных моделей организации. Их разработка — сложнейшая проблема, требующая знаний и опыта как в сфере бизнеса, так и в области организационного управления, а также информационных технологий. Для ее реализации, помимо детального проникновения в деловые механизмы функционирования предприятия, необходимы также соответствующие методики и инструментальные средства, так называемые CASE-среды.
Список ЛИТЕРАТУРЫ
1.	Баронов В. В. Автоматизация управления предприятием / В.В. Баронов. — М.: Инфра-М, 2000.
2.	Буч Г. Объектно-ориентированное проектирование с примерами применения / Пер. с англ. / Г.Буч.—М.: Конкорд, 1992.
3.	Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: учеб, пособие для вузов / А.М. Вендоров. — М.: Финансы и статистика, 2002.
4.	Один из подходов к выбору средств проектирования баз данных и приложений / А.М. Вендоров // СУБД. 1995. № 3.
5.	Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендоров. — М.: Финансы и статистика, 1998.
6.	Губин Н.М., Добронравов А.С., Дорохов Б. С. Экономико-математические методы и модели в планировании и управлении в отрасли связи/Н.М. Губин, А.С. Добронравов, Б.С. Дорохов. — М.: Радио и связь, 1993.
7.	Проектное управление: модели и методы принятия решений / В.С. Ефремов И Менеджмент в России и за рубежом. 1998. № 6.
8.	Зиндер Е. 3. Бизнес-реинжиниринг и технологии системного проектирования: учеб, пособие для вузов / Е.З. Зиндер. — М.: Центр Информационных Технологий, 1996,2003.
9.	Шеер А.В. Бизнес-процессы. Основные понятия. Теория. Методы / А.В. Шеер. — М.: Весть—Мета Технология, 1999.
10.	Методологический подход к реорганизации деятельности предприятий / В. Ивлев, М. Каменнова, Т. Попова//Открытые системы. 1996. № 2.
11.	Каляное Г. Н. CASE. Структурный системный анализ (автоматизация и применение) / Т.Н. Калянов. — М.: Лори, 1996.
12.	Калянов Г.Н. CASE-технологии: консалтинг при автоматизации бизнес-процессов / Г.Н. Калянов. — М.: Лори, 2000.
Проектирование информационных систем
13.	Каляное Г. Н. Теория и практика реорганизации бизнес-процессов / Г.Н. Калянов. — М.: СИНТЕГ, 2000.
14.	Кофман А. Сетевые методы планирования: применение системы ПЕРТ и ее разновидностей при управлении производственными и научно-исследовательскими проектами: пер. с франц. / А. Кофман, Г. Дебазей. — М.: Прогресс, 1968.
15.	Управление разработкой программных средств: Методы, стандарты, технология / В.В. Липаев. — М.: Финансы и статистика, 1993.
16.	Марка Д.А. Методология структурного анализа и проектирования / Д.А. Марка, К. МакГоуэн. — М.: ИНФРА, 1993.
17.	Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем / С.В. Маклаков. — М.: ДИАЛОГ-МИФИ, 2000.
18.	Использование современных методов управления проектами, маркетинга и менеджмента при создании информационных систем / А.Г. Михайлов И Информационные ресурсы России. 2000. № 6.
19.	Международные стандарты, поддерживающие жизненный цикл программных средств. — М.: МП «Экономика», 1996.
20.	Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем / Ю.В. Новоже-нов. — М.: Финансы и статистика, 1996.
21.	Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: реинжиниринг организаций и информационные технологии / Е.Г. Ойхман, Э.В. Попов. — М.: Финансы и статистика, 1997.
22.	Питерсон Дж. Т еория сетей Петри и моделирование систем / Дж. Питерсон. — М.: Мир, 1984.
2	3. Проектирование информационных систем: у чеб.пособие для вузов / под общей ред. К.И. Курбакова. — М.: Российская экономическая академия, 2000.
2	4. Фундамент корпоративного менеджмента / А. Райков И Открытые системы. 2000. № 1-2.
25. Сетевое планирование и управление / под ред. Д.И. Голенко. — М.: Экономика, 1967.
Библиографический список
499
26. Советов Б.Я., Яковлев С.А. Моделирование систем / Б.Я. Советов, С.А. Яковлев. — Изд. 3-е. — М.: Высш, шк., 2001.
2 7. Смирнова Г. Н. Проектирование экономических информационных систем: учеб, для вузов / Г.Н. Смирнова. — М.: Финансы и статистика, 2001.
28.	Черемных С. В. Моделирование и анализ систем. IDEF-тех-нологии: практикум / С.В. Черемных. — М.: Финансы и статистика, 2002.
29.	Черемных С. В. Структурный анализ систем: IDEF-техноло-гии / С.В. Черемных. — М.: Финансы и статистика, 2003.
30.	Чери С. Логическое программирование и базы данных / С. Черн, Г.Готлоб, Л. Танка. — М.: Мир, 1992.
31.	Шлеер С. Объектно-ориентированный анализ: моделирование мира в состояниях / С. Шлеер, С. Меллор. — Киев: Диалектика, 1993.
32.	Эддоус М. Методы принятия решений / М. Эддоус, Р. Стенс-филд. —М.: ЮНИТИ, 1997.
33.	Юдицкий С.А.Технология проектирования архитектуры информационно-управляющих систем / С.А. Юдицкий, А.Т. Кутанов. — М.: Институт проблем управления, 1993.
34.	Chris Gane, Trish Sarson. Structured System Analysis. Prentice-Hall, 1979.
35.	Barker R. CASE*Method. Entity-Relationship Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.
36.	Boehm B. W. A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, Aug. 1986.
3 7. Применение CASE-средства ERwin 2.0 для информационного моделирования в системах обработки данных / С.В. Горин, А.Ю. Тандоев И СУБД. 1995. № 3.
3 8. CASE-средство S-Designor 4.2 для разработки структуры базы данных / С.В. Горин, А.Ю. Тандоев И СУБД. 1996. № 1.
39.	PVCS Version Manager. User’s Guide.
500
Проектирование информационных систем
40.	PVCS Tracker. User’s Guide.
41.	QA Partner. User’s Guide.
42.	ГОСТ P ИСО / МЭК TO 10000-1-99. Информационная технология. Основы и технология функциональных стандартов. Часть 1. Основные положения и основы документирования. — М.: ИПК издательство стандартов, 1997.
43.	ГОСТ Р ИСО / МЭК 12207-99. Информационная технология. Процессы жизненного цикла программного обеспечения. — М.: ИПК издательство стандартов, 1997.
44.	Филинов Е. Н. Архитектура и структура среды распределенной обработки данных, методы и средства формального описания среды // Распределенная обработка информации. Труды VI международного семинара. Новосибирск. Сибирское отделение РАН. 1998.
45.	-Филинов Е.Н., Бойченко А. В. Проблемы и методика формирования профилей открытых информационных систем. В сб.: «Стандарты в проектах современных информационных систем», 2001.
4 6. Моделирование для непрерывного улучшения бизнес-процессов на базе стандартов ERP и ИСО 9001 / С.А. Волчков, И.В. Балахонова И Методы менеджмента качества. 2001. №2.
47.	Васкевич Д. Стратегии клиент/сервер. Руководство по выживанию для специалистов по реорганизации бизнеса: пер. с англ. / Д. Васкевич. — Киев: Диалектика, 1996.
48.	Паронджанов С.Д. Методология создания корпоративных ИС. Компания Аргуссофт. 96, http://www.citforum.ru/ database/kbd96/43.shtml.
49.	Методические указания к лабораторной работе «Моделирование систем сетевого планирования и управления» по курсу «Экономико-математические модели и методы»—Таганрог: Изд-во ТРТУ, 1999.
50.	Прозоров А. А. Проектирование КИС, http://rtlab.ru/lections/ 1ес02.
51.	Буч Г. Язык UML. Руководство пользователя: пер. с англ. / Г. Буч, Д. Рамбо, А. Джекобсон. — М: ДМК, 2000.
Библиографический список 501
5	2. Михайловский Н. Сравнение методов оценки стоимости проектов по разработке информационных систем, http:// www.ntrlab.ru/
53.	Автоматизированные Системы Стадии создания. ГОСТ 34.601-90 Комплекс стандартов на автоматизированные системы. — М.: ИПК изд-во стандартов, 1997.
54.	Моудер Дж. Метод сетевого планирования и организации работ (Перт) / Дж. Моудер, С. Филипс. — М-Л.: Энергия, 1966.
55.	Таха X. Введение в исследование операций / X. Таха. — М.: Мир, 1985.
5	6. Проектирование крупных ИС: от панацей к мастерской методов и моделей / С.А. Панащук // Директор ИС. 1998. № 20.
57.	Эдриенн Тэнненбаум (Adrienne Tannenbaum). Решения для метаданных (Meta Data Solutions. Addison Wesley, 2002).
58.	Башмаков А.И. Систематизация информационных ресурсов для сферы образования: классификация и метаданные / А.И. Башмаков, В.А. Старых. — М.: Европейский центр по качеству, 2003.
59.	Hammer М., Champy J. Reengineering the Corporation. A Manifesto for Business Revolutions. HarperBusiness, 1993.
60.	Селезнев К. IDEF3 — методология описания и моделирования процессов. «1С», http://www.documenta.spb.ru
61.	Верников Г. Г Основы IDEF3. «Корпоративный менеджмент», http.7/www.cfin.ru/vernikov/idef
62.	Сравнительный анализ структурных методологий / Г.Н. Ка-лянов, А.В. Козлинский, В.Н. Лебедев И СУБД. 1997. № 5-6.
63.	Михайлов А.Е. Объектно-ориентированная технология разработки программных систем. «Объектно-ориентированный анализ и проектирование [OOA&n/OOA&D]», http://ooad. asf.ru/standarts/Library/OORP/Listl3.aspx
64.	BPwin Methods Guide.
65.	ERwin Methods Guide.
66.	Гвоздева Т.В. Проектирование информационных систем. Ч. 1. Методы структурного анализа. Планирование и
Проектирование информационных систем
502
s-
управление проектами: лаб.практикум / ГОУВПО «Ивановский государственный энергетический университет имени В.И. Ленина». — Иваново, 2005.
67.	Гвоздева Т.В. Проектирование информационных систем. Ч. 2. Методы объектно-ориентированного моделирования: лаб.практикум / ГОУВПО «Ивановский государственный энергетический университет имени В.И. Ленина». — Иваново, 2007.
68.	Project Management Body of Knowledge (PMBOK® Guide 2000).
69.	Калянов Г. H. Консалтинг при автоматизации предприятий: подходы, методы, средства / Г.Н. Калянов. — М.: СИНТЕГ, 2000.
70.	Моделирование бизнеса и архитектура информационной системы / О. Полукеев, Д. Коваль И СУБД. 1995. № 4.
71.	Фоменков С.А. Лекции по курсу моделирование, http:// vstuhelp.narod.ru/
72.	CASE-средства: в борьбе со сложностью мира / Ю. Гареева, И. Панамарев И PC Week/RE. 2004. № 18.
73.	Кипи Р.Л. Принятие решений при многих критериях: замещения и предпочтения / Р.Л. Кипи, X. Райфа. — М.: Радио и связь, 1981.
74.	Саати Т.Л. Принятие решений. Метод анализа иерархий / Т.Л. Саати. — М.: Радио и связь, 1993.
75.	Белов А.А., Гвоздева Т.В. Основы теории нечеткости: учеб, пособие / ГОУ ВПО «Ивановский государственный энергетический университет им. В.И. Ленина». — Иваново, 2005.
76.	Лисков Б. Использование абстракций и спецификаций при разработке программ: пер. с англ. / Б. Лисков, Дж. Гатег. — М.: Мир, 1989.
77.	Крупин А. Архитектура информационных систем. ГГинфра-структура. http://www.computerra.ru/
78.	РД 50-680-88. Методические указания. Автоматизированные системы. Общие положения.
Библиографический список
503
79.	Системы автоматизированного проектирования: учеб, пособие для вузов / под ред. И.П. Норенкова. — М.: Высш, шк., 1986.
8	0. Мацяшек Л. А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML / Л.А. Мацяшек. — М.: Издательский дом «Вильямс», 2002.
81.	Баронов В.В. Автоматизация управления предприятием / В.В. Баронов. — М.: ИНФРА, 2000.
82.	Анализ требований к автоматизированным информационным системам/ Интернет-Университет Информационных Технологий. http://www.INTUIT.ru.
8	3. Камеиоеа М. Моделирование бизнеса. Методология ARIS / М.Каменова, А. Громов, М. Ферапонтов, А. Шматалюк. — М.: ООО Издательство «Серебряные нити», 2001.
84.	Моделирование бизнеса: средства и методы / В. Чеботарев // PC Week/RE. 2000. № 9.
85.	Сравнительный анализ и выбор средств инструментальной поддержки организационного проектирования и реинжиниринга бизнес-процессов. «Бизнес Инжиниринг Групп», http:// www.big.spb.ru.
86.	Одинцов И. О. Профессиональное программирование. Системный подход / И.О. Одинцов. — Изд. 2-е. — СПб.: БХВ-Петербург, 2004.
87.	Разработка информационных систем с использованием CASE-системы Silverrun / С. А. Панащук// СУБД. 1995. № 3.
8	8. Designer/2000 — новое поколение CASE-продуктов фирмы ORACLE / О.Ю. Горчинская И СУБД. 1995. № 3.
Оглавление |
ПРЕДИСЛОВИЕ......................................3
ГЛАВА 1. Введение в проектирование информационных систем............................5
1.1.	Основы создания и функционирования информационной системы.........................6
1.2.	Общая схема проектирования информационных систем (систем информационного обеспечения)....15
1.2.1.	Структура процесса проектирования ИС. 17
1.2.2.	Стадии проектирования ИС...........20
1.2.3.	Документирование процесса проектирования ИС...........................28
1.3.	Понятие консалтинга в области информационных технологий............30
1.4.	CASE-технологии — методологическая и инструментальная	база консалтинга........35
Контрольные вопросы..........................37
ГЛАВА 2. Основы методологии проектирования информационных систем...........................38
2.1.	Жизненный цикл программного обеспечения ИС................................38
2.2.	Модели жизненного цикла ПО..............40
2.3.	Содержание и организация проектирования...48
2.3.1.	Каноническое проектирование	ИС.....49
2.3.2.	Типовое проектирование ИС..........65
Контрольные вопросы..........................70
ГЛАВА 3. Организация проектирования информационных систем...........................71
3.1.	Полииерархическая структура информационной системы и типовые технологические решения.............71
3.2.	Формирование и применение профилей информационных систем.........................74
3.3.	Информационное обеспечение процесса проектирования................................83
3.4.	Подходы к организации и планированию разработки информационной системы.............86
Контрольные вопросы..........................94
Оглавление
505
двм
ГЛАВА 4. Планирование и управление информационными проектами..........................95
4.1.	Оценка стоимости информационной системы....95
4.2.	Проектное управление: модели и методы принятия решений............... 103
4.2.1.	Объект проектного управления.........105
4.2.2.	Основы проектного управления.........107
4.2.3.	Методика оптимизации загрузки сетевых моделей............................ 116
4.2.4.	Методика оптимизации сетевых моделей по критерию «время — затраты».............. 121
4.3.	Планирование и управление проектами средствами MS Project.......................... 130
Контрольные вопросы........................... 146
ГЛАВА 5. Технологии и методы проектирования информационных систем.............................147
5.1.	Методы проектирования информационных систем...........................148
5.2.	Методология создания информационных систем...........................158
5.3.	Основные составляющие методологии........ 160
5.3.1.	Итерационная спиральная модель жизненного цикла ИС.........................161
5.3.2.	Комплекс развивающихся систем согласованных моделей...................... 163
5.3.3.	Методология анализа ИС на основе бизнес-процессов................. 163
5.3.4.	Методология проектирования от данных.. 172
5.4.	Методы и средства организации метаинформации проекта системы................. 173
Контрольные вопросы........................... 181
ГЛАВА 6. Подходы к проектированию информационных систем.............................182
6.1.	Анализ и проектирование информационных систем...........................183
6.1.1.	Методы проектирования архитектур информационных систем........................ 184
6.1.2.	Подходы к ведению анализа и проектирования........................... 186
Проектирование информационных систем
6.2.	Структурный подход к проектированию ИС......189
6.2.1.	Структурный анализ в проектировании ИС......................   189
6.2.2.	Классификация структурных методологий................................ 193
6.2.3.	Методология функционального моделирования.............................. 196
6.2.4.	Методология описания и моделирования процессов...................208
6.2.5.	Моделирование потоков данных (процессов).... 227
6.2.6.	Спецификации управления..............236
6.2.7.	Моделирование данных.................241
6.2.8.	Сравнительный анализ структурных методологий.................................251
6.3.	Объектно-ориентированные методологии.......257
	6.3.1. Объектно-ориентированный анализ......259
6.3.2. Универсальный язык моделирования.....262
6.4.	Практическое применение методологий проектирования ИС...............................296
6.4.1.	Структурное моделирование информационных систем средствами BPwin и ERwin...............................296
6.4.2.	Объектное моделирование
информационных систем средством Ration Rose..323
Контрольные вопросы.............................332
ГЛАВА 7. Подходы к автоматизации деятельности предприятия...........................333
7.1.	Выбор стратегии автоматизации деятельности..333
7.2.	Управление процессом автоматизации.........337
7.2.1.	Планирование процесса автоматизации..338
7.2.2.	Методы и средства проектирования автоматизированной ИС предприятия (реорганизация деятельности предприятия).....341
7.2.3.	Подходы к созданию автоматизированных ИС.......................351
7.3.	Моделирование информационных систем на базе стандартов ERP и ИСО 9001:2000..........356
Контрольные вопросы.............................369
Оглавление	507
--------------------------------------------------ВВВВ
ГЛАВА 8. Математические и методологические
аспекты проектирования информационных систем.......370
8.1.	Модели выбора проектных решений............371
8.1.1.	Классическая модель принятия решений..373
8.1.2.	Модели нечеткого выбора.
Модель формирования проектных предпочтений...376
8.2.	Разработка модели системы на основе сетей Петри............................384
8.2.1.	Стандарт сети Петри...................386
8.2.2.	Использование сети Петри
для моделирования............................393
8.2.3.	Методы анализа сетей..................400
Контрольные вопросы.............................406
ГЛАВА 9. CASE-технологии — инструментарий поддержки жизненного цикла..........407
9.1.	Общая характеристика и классификация CASE-средств.....................................412
9.2.	Сравнительный анализ средств инструментальной поддержки процесса проектирования ИС.......................417
9.2.1.	Основные средства проектирования ИС....417
9.2.2.	Сравнительный анализ основных CASE-средств........................426
9.2.3.	Вспомогательные средства поддержки жизненного цикла ПО..........................431
9.3.	Технология внедрения CASE-средств..........434
Контрольные вопросы.............................438
ГЛАВА 10. Проектирование программных систем.......... 439
10.1.	Цели проектирования программных систем......441
10.2.	Принципы разработки программных систем......445
10.3.	Методологии и технологии проектирования программных систем................................450
10.3.1.	Общие требования к методологии и технологии.................................451
10.3.2.	Методология RAD......................454
10.3.3.	Моделирование программных	систем......459
10.3.4.	Использование формальных спецификаций.464
5И)8 Проектирование информационных систем
10.4.	Архитектура информационной системы...471
10.4.1.	Моделирование бизнеса и архитектура информационной системы.................472
10.4.2.	Конфигурация и архитектура информационной системы.................487
Контрольные вопросы.......................493
ЗАКЛЮЧЕНИЕ...................................495
СПИСОК ЛИТЕРАТУРЫ............................497
Серия
• Высшее образование •
Гвоздева Татьяна Вадимовна, Баллод Борис Анатольевич
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Ответственный редактор Технический редактор Корректор
Дизайн обложки:
А.М. Спивак Г. А. Логвинова Л. С. Акентьева М.П. Сафиуллина
Сдано в набор 20.06.2008 г. Подписано в печать 10.11.2008 г. Формат 84x108 1/32. Бумага офсетная. Гарнитура Таймс.
Тираж 3000 экз. Заказ № 1035.
ООО «Феникс» 344082, г. Ростов-на-Аону, пер. Халтуринский, 80.
Отпечатано с готовых диапозитивов в ЗАО «Книга». 344019, г. Ростов-на-Дону, ул. Советская, 57. Качество печати соответствует предоставленным диапозитивам.