Серия
• Высшее образование •
Т.В. Гвоздева, Б.А. Баллод
ПРОЕКТИРОВАНИЕ
ИНФОРМАЦИОННЫХ
СИСТЕМ
Рекомендовано Учебно-методическим объединением вузов Российской Федерации по образованию в области прикладной информатики в качестве учебного пособия для студентов высших учебных заведений, обучающихся по специальности «Прикладная информатика»
БИБЛИОТЕК *
Волгодонский институт сервис' ЮРГУЭС
Ростов-на-Дону «Феникс» 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 ориентируется на процессы, а не на задачи, рабочие места, персонал. Под бизнес-процессом понимается совокупность действий, получающая на входе данные различн�