Методические указания и задание на контрольную работу по дисциплине Технологии разработки программных комплексов и CASE-средства

11

ISO/IEC 15288 предлагает рассматривать ЖЦ ИС в виде набора процессов. Ка-

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

щи различных видов деятельности. Всего выделено 25 процессов, объединяемых в 4

группы (рис. 3.1).

Помимо процессов, определено 123 различных результата и 208 видов деятель-

ности, нацеленных на их достижение.

4. Структура процесса проектирования программного обеспечения

Для таких объектов, как ИС или ПО вполне применимо понятие жизненного цикла изделия. Увидеть эту цикличность проще всего из так называемой спиральной модели жизненного цикла программного обеспечения (еѐ упрощенный вид показан на рис. 4.1).

Рис. 4.1

Жизненный цикл программного обеспечения (ЖЦ ПО) — непрерывный про-

цесс, который начинается с момента принятия решения о необходимости создания ПО

изаканчивается в момент его полного изъятия из эксплуатации.

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

12

ГОСТ Р ИСО/МЭК 12207-995 выделяет следующие основные этапы ЖЦ: разработка и анализ требований (завершающийся утверждением технического задания), проектирование (создание исходного кода на языках программирования), реализация, тестирование и ввод в действие (включая последующее сопровождение).

Структура ЖЦ ПО, согласно ГОСТ 12207-99, базируется на трех группах процессов:

основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение;

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

организационные процессы: создание инфраструктуры проекта, управление проектами, управление персоналом, обучение, определение, оценка и улучшение самого ЖЦ.

Существует также стандарт ISO/IEC 15504 (SPICE) Standard for Information

Technology — Software Process Assessment (оценка процессов разработки и поддержки ПО), где определены 5 категорий, включающих 35 процессов и 201 вид деятельности в ЖЦ ПО. Стандарты, разрабатываемые международными организациями в той или иной области деятельности, носят рекомендательный характер и не возведены в ранг закона.

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

Разработанная применительно к ПО, спиральная модель также может служить моделью жизненного цикла информационной системы (ЖЦ ИС) в целом. В таком слу-

чае представленные в таблицах 2.1 и 3.1 перечни работ будут описывать один типич-

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

5 ГОСТ Р ИСО/МЭК 12207-99. Процессы жизненного цикла программных средств. Соответствует меж-

дународному стандарту ISO/IEC 12207:1995 «Software Life Cycle Processes». Действующей версией этого стандарта является ISO/IEC 12207:2008.

Существует также ГОСТ Р ИСО/МЭК ТО 15271-2002. Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207.

ISO — International Organization of Standardization — Международная организация по стандартизации

(ИСО).

IEC — International Electrotechnical Commission — Международная комиссия по электротехнике (МЭК).

13

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

5. CASE – системы

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

(software engineering) и «системная инженерия» (system engineering)6. Результатом этих усилий явились так называемые CASE-системы, которые сегодня занимают такое же прочное место в практике инженерного проектирования, как и САПР.

CASE (Computer-Aided Software/System Engineering) — дословно переводится как разработка ПО/систем с помощью компьютера.

Современная CASE-система — это аналог САПР, одна из разновидностей информационных систем, среда проектирования прикладной функциональности ИС и программного обеспечения. CASE-система имеет тот же набор стандартных компонент, что и САПР7, называемых видами обеспечения, иногда дополняемый правовым обеспечением.

Принципиальное отличие среды проектирования систем (Computer-Aided System Engineering) от соответствующей среды проектирования программного обеспечения (Computer-Aided Software Engineering) заключается в результатах проектирования. В первом случае — это описания производственных процессов, процессов управления,

6Для обозначения этого направления используются также термины «системная интеграция» и «консалтинг».

7По ГОСТ обязательными компонентами САПР являются следующие виды обеспечения:

техническое;

математическое;

программное.

лингвистическое;

информационное;

методическое;

организационное.

14

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

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

Большинство CASE-систем основано на парадигме методология/метод/нота-

ция/средство.

Методология — это руководящие указания для проектирования и построения информационных систем. Она описывает серию шагов, моделей и подходов и их по-

следовательность, правила распределения и назначения используемых методов, а так-

же критерии оценки и выбора проектных решений. Цель CASE-методологии заключа-

ется в регламентации процесса проектирования ИС и обеспечении управления этим процессом с тем, чтобы повысить вероятность выполнения требований как к характе-

ристикам процесса разработки, так и к самой ИС.

Метод — это систематическая (желательно, — стандартная) процедура генера-

ции описаний компонентов проектируемой системы с использованием соответствую-

щих нотаций.

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

Средства (инструментарий) — любые программные средства, автоматизирующие ту или иную совокупность процессов проектирования ИС.

Использование всех этих элементов CASE-систем составляет то, что называется

CASE-технология.

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

15

циях, вызывает тенденцию к расширению понятия CASE-системы до средств поддержки взаимодействия бизнес — ПО — бизнес, объединения их в единое целое. Ведь программные продукты затем и нужны, чтобы помогать в управлении бизнесом. Дело в том, что задачи проектирования ИС и задачи оптимизации бизнес-процессов (или бизнеса как такового) переплетаются очень тесно. Более того, оптимизация бизнеса без внедрения ИС сейчас в принципе невозможна. Поэтому все должно быть связано методологически, а еще лучше — технологически. Это может быть единая CASEсистема, интегрирующая соответствующие CASE-инструменты.

6. CASE-методология

Поскольку объектам проектирования, к которым применяется CASE-методоло-

гия, являются системы (информационные, программные), то естественно, что в основе этой методологии лежат принципы системного подхода, разработанные в основном в ходе становления таких научных дисциплин, как «Кибернетика» и «Системный ана-

лиз». Эти принципы являются обобщением опыта работы человека со сложными сис-

темами и в данном случае направлены на то, чтобы вновь создаваемые системы дейст-

вительно обладали системными свойствами.

Основу методологии системного анализа составляют рациональные процедуры,

методы и приемы изучения проблем, используемые для обоснования и принятия ре-

шений.

Проблема — это отклонение того, что имеет место в действительности, от же-

лаемого. Системным анализом предложена определенная логическая последователь-

ность этапов и процедур, направленных на разрешение проблемной ситуации. Эта по-

следовательность состоит, в самом общем виде, из трех этапов: подготовка решения;

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

вается проектом.

Нетрудно увидеть, что структура проектов ИС по ГОСТ 34.601-90 или ISO/IEC 15288 отражает содержание этих трех этапов решения проблемы. Создание проекта

16

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

В основе CASE-методологии проектирования ИС, как и в системном анализе,

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

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

лью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требо-

ванию — быть адекватной этой области.

Для системной инженерии важнейшее значение имеет такой принцип системно-

го подхода, как принцип структуризации — необходимость анализа элементов сис-

темы и их взаимосвязей в рамках конкретной структуры и понимание того, что про-

цесс функционирования системы обусловлен не только свойствами ее отдельных эле-

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

ницу, если мы не будем четко различать системы, которые подлежат структуризации,

объекты, для которых мы должны иметь описания, те или иные модели.

Допустим, мы хотим заняться проектированием ИС для предприятия. О каких объектах структуризации может идти речь?

Об одном из объектов структуризации мы уже говорили — это процесс проек-

тирования ИС. Здесь CASE-методология говорит нам, что если структуру этого про-

цесса мы выстроим в соответствии со стандартами ГОСТ 34.601-90, ГОСТ 12207-99

или ISO/IEC 15288, то это должно помочь нам решить проблему создания ИС.

Но зачем нам нужна ИС, которая, судя по перечню видов работ по ее созданию,

содержащегося в стандартах, никак не может быть дешевой?

Является ли создание или модернизация ИС актуальной проблемой? Вполне возможно, поскольку, создавая такую систему, которая играет для организации при-

17

мерно такую же роль, как нервная система для человека, мы направляем все информа-

ционные процессы организационной системы в русло самых современных информа-

ционных технологий. Но эта цель не самодостаточна. Никто не будет нести расходы,

внедряя ИТ ради них самих.

И здесь мы сталкиваемся с еще одним принципом системного подхода — прин-

ципом иерархичности. Совершенно очевидно, что решение о проектировании (реин-

жиниринге) ИС принимается не на уровне самой ИС, а в системе более высокого по-

рядка — руководством организационной системы, в которую ИС входит в качестве одной из подсистем. Такое решение будет принято только в том случае, если есть на-

дежда, что ИС будет способствовать решению проблем с более очевидной актуально-

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

Что это за системы?

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

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

яснить структуру существующей ИС, структуру ее проблем, а затем, если это будет признано целесообразным, синтезировать структуру новой ИС, которая устранит имеющиеся проблемы.

Итак, мы видим, по меньшей мере, еще два типа объектов структуризации — ИС и еѐ проблемы.

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

Во-вторых, — это организационная система (фирма), в которую ИС входит как одна из подсистем. Это еще один тип объектов структуризации. Организационная сис-

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

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

18

мационными процессами. Поэтому в проекте ИС все эти структуры должны быть опи-

саны, проанализированы, а для проблем предложены решения.

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

например, системы под названием «экономика».

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

действий с внешним миром.

Мы видим, что нам приходится иметь дело с большим разнообразием объектов и их моделей. Это не случайно, именно так в проектировании ИС проявляется еще один из принципов системного подхода — принцип множественности, который указывает на необходимость использования множества моделей для описания отдель-

ных элементов и системы в целом.

Как же справиться с этим разнообразием? Как разобраться в этом наслоении структур? Как из всего этого вычленить проблемы, решаемые с помощью ИС? Как именно ИТ и ИС могут способствовать их устранению? В получении ответов на по-

добные вопросы нам должны помочь знания, сконцентрированные в виде CASE-

методологии, реализованные в виде CASE-технологии, то есть весь арсенал проверен-

ных практикой CASE-методов и программных CASE-средств.

Наиболее распространенные CASE–методы перечислены в табл. 6.1.

Таблица 6.1

Отметим, что для автоматизации работы с большинством из перечисленных в

табл. 6.1 методов разработаны программные CASE-средства (см. раздел 9).