Тема 9. Проектирование КИС.
Жизненный цикл КИС. Модели жизненного цикла КИС: каскадная, спиральная.
Этапы проектирования КИС.
Реинжиниринг бизнес-процессов.
Моделирование бизнес-процессов.
Обзор систем автоматизированного проектирования КИС. CASE-технологии.
9.1 Жизненный цикл КИС. Модели жизненного цикла КИС: каскадная, спиральная.
Понятие жизненного цикла программного обеспечения (ЖЦ ПО) является одним из базовых в программной инженерии. Жизненный цикл программного обеспечения определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 "Information Technology -Software Life Cycle Processes" (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC – International Electrotechnical Commission — Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (или программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами. Каждый процесс разделен на набор действий, каждое действие — на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным).
В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ ПО разделены на три группы:
пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение);
восемь вспомогательных процессов, обеспечивающих выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем);
четыре организационных процесса (управление, создание инфраструктуры, усовершенствование, обучение).
Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО. Стандарт Жизненный цикл описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ любого конкретного ПО ЭИС определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Под стадией создания ПО понимается часть процесса создания ПО, ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных компонентов, документации), определяемого заданными для данной стадии требованиями. Стадии создания ПО выделяются по соображениям рационального планирования и организации работ, заканчивающихся заданными результатами. В состав жизненного цикла ПО обычно включаются следующие стадии:
1. Формирование требований к ПО.
2. Проектирование.
3. Реализация.
4. Тестирование.
5. Ввод в действие.
6. Эксплуатация и сопровождение.
7. Снятие с эксплуатации.
В однородных КИС 70-х и 80-х гг. прикладное ПО представляло собой единое целое. Для разработки такого типа ПО применялся каскадный подход (другое название — водопад (waterfall)). Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания.
При этом основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемого ПО: производительности, объема занимаемой памяти и др.
Преимущества применения каскадного способа заключаются в следующем:
• на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
• выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
В то же время этот подход обладает рядом недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. Процесс создания ПО носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимает иной вид.
Для преодоления перечисленных проблем в середине 80-х гг.была предложена спиральная модель ЖЦ.
Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а так-же целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными. Основная проблема спирального цикла — определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
9.2 Этапы проектирования КИС.
Под проектированием КИС понимается процесс разработки технической документации, связанный с организацией автоматизированной информационной технологии.
Документ, полученный в результате проектирования, носит название проект.
Цель проектирования – подбор технического и формирование информационного, математического, программного и организационно-правового обеспечения.
Этапы развития КИС:
Целью начальных этапов создания ИС, выполняемых на стадии анализа, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации. Чтобы описать процесс создания ИС, отвечающей целям и задачам организации, нужно выяснить в чем заключаются эти цели и задачи. Нужно выяснить требования заказчиков к ИС и преобразовать их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.
Проблема формирования требований к ИС остается до настоящего времени одной из наиболее трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Именно поэтому столь велика роль начальных этапов ЖЦ создания ИС, когда эти требования должны быть выявлены и формализованы, в получении конечного результата.
1. Анализ первичных требований и планирование работ.
Оценить 1) преимущества внедрения данной системы
2) временные затраты
3) обосновать стоимость
2. Проведение обследования деятельности предприятия.
Определение организационной и топологической структуры предприятия, бизнес-процессов, анализ распределения функций по подразделениям и сотрудникам, уровня автоматизации и др.
3. Построение и анализ моделей деятельности предприятия.
Строятся 2 модели на языке IDEF0 – „модель как есть“ и «модель как будет». Переход от одной модели к другой осуществляется обычно 2-мя путями:
1) совершенствованием технологии на основе оценки эффективности («мягкий» реинжениринг)
2) радикальным изменением технологии и переосмыслением бизнес-процесса («жесткий» реинжениринг).
4. Разработка системного проекта (модели требований к будущей системе) или технического задания.
Техническое задание – это документ, утвержденный в установленном порядке, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления, и содержащий предварительную оценку экономической эффективности системы.
Разделы технического задания:
Цель, задачи и назначение КИС, технические требования к системе, порядок функционирования системы, виды обеспечения КИС (организационное, информационное, техническое, математическое, программное) и требования к ним, состав и содержание работ по созданию системы, правила оценки качества построения и функционирования КИС.
5. Техническое проектирование (разработка технического проекта).
Технический проект – совокупность взаимосвязанной документации по всем трем структурным частям (общесистемной, функциональной и обеспечивающей) новой автоматизированной информационной технологии управления.
Этап разделяется на 2 стадии:
– проектирование архитектуры технологии, включающее разработку структуры и интерфейса компонент (АРМ), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;
– детальное проектирование, включающее разработку спецификации каждой компоненты, требований к компонентам, а также построение иерархии модулей и межмодульных взаимодействий, проектирование внутренней структуры моделей.
Создание рабочего проекта.
На данном этапе осуществляется:
1) разработка рабочей документации:
– пояснительной записки
– функциональной и организационной структуры
– должностных инструкций
– инструкций по заполнению входных оперативных документов
– инструкций по использованию выходных документов
– инструкции по организации и ведению нормативно-справочной документации
– инструкции по организации хранения информации в архиве
– инструкции по подготовке информации к вводу в ПК
– Расчет экономической эффективности системы
– мероприятия по подготовке объекта к внедрению
– ведомость документов.
2) разработка программных средств
разрабатывается новое ПО или производится привязка и адаптация приобретенного ПО к конкретным условиям
Все три проекта (системный, технический и рабочий) являются описанием разрабатываемой технологии, но с различной степенью детализации. Процесс создания проектов – итерационный, то есть возможен возврат к предыдущим этапам для внесения уточнений или модификаций.
7. Ввод в действие разработанной информационной технологии(опытная эксплуатация, устранения замечаний по результатам опытной эксплуатации, промышленная эксплуатация).
9.3 Реинжиниринг бизнес-процессов.
Мы имеем производство и хотим сделать его еще лучше. В каком смысле лучше? Больше продукции за меньшее количество времени? Высококачественная продукция с меньшим количеством несоответствий? Более высокая удовлетворенность потребителя? Более высокая рентабельность? Меньше стадий обработки? Больше продукции на одного рабочего? И т.д., и т.п. Все это аспекты лучшего производства. Как всего этого добиваться? Для этого надо думать о производстве в целом как о системе. Система – совокупность взаимосвязанных частей, объединенных по признаку описываемого процесса. В процессе и системном подходе заключается ключ к пониманию. В соответствии с концепцией менеджмента качества и реинжиниринга путь к улучшению производства кроется в совершенствовании процессов, а условием его улучшения являются его «прозрачность». Это объединяет менеджмент качества и реинжиниринг деловых процессов.
Различаются они тем, что менеджмент качества рассматривается как инструмент для реализации стратегических целей организации «за счет внутренних резервов», т.е. как последовательная, систематическая деятельность по планированию, обеспечению, управлению и улучшению деловых процессов.
Реинжиниринг бизнес процессов рассматривается как инструмент для реализации статегических целей организации на основе кардинального пересмотра и замены существующих деловых процессов новыми, более эффективными.
В Японии эти подходы к управлению компанией получили название «кайцен» и «кайрио» соответственно. Очевидно, что их нельзя ставить на один уровень и соответственно сравнивать, какой подход лучше. Менеджмент качества первичен по отношению к реинжинирингу бизнес процессов. Реинжиниринг эффективен только тогда, когда «внутренние резервы» исчерпаны, т.е., когда невозможно «здесь и сейчас» предложить более высокое качество за более низкую цену. Налицо циклическая схема руководства организацией, использующая оба этих подхода:
· первая фаза - системный постоянный менеджмент качества, на постоянной основе повышающий результативность и эффективность процессов и деятельности организации за счет «внутренних резервов», например, за счет самоорганизации, оптимизации,
· затем, когда К.П.Д. процессов доведен до 100%, т.е. из процессов «выжато» все, что можно, следует вторая фаза – реинжиниринг, как кардинальная перестройка делового процесса.
С учетом того, что реинжиниринг требует больших инвестиций и имеет высокий риск их невозврата, он как вид интеллектуальной деятельности представляет интерес для менеджмента качества в части используемых приемов, технологий, методов, отработанных уже на протяжении более тридцати лет.
Майкла Хаммер и Джеймс Чампи в книге «Реинжиниринг корпорации: Манифест революции в бизнесе», адресованной, прежде всего, предпринимателям и управляющим, показывают, что конкурентоспособность и экономическая жизнестойкость компаний должна быть основана на принятии новых моделей и практики управления, и промышленной организации. В качестве метода воссоздания существующих корпораций авторы предлагают реинжиниринг бизнеса, который, по их мнению, для новой революции в бизнесе означает то же, что специализация труда означала для предыдущей.
Реинжиниринг авторы определяют как фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность.
В этом определении содержатся четыре ключевых слова.
Первое ключевое слово — «фундаментальный». В центре реинжиниринга бизнеса находится идея, что необходимо идентифицировать и отказаться от устаревших правил и фундаментальных предпосылок, лежащих в основе нынешних деловых операций.
Осуществляя реинжиниринг, предприниматель должен поставить на повестку дня основополагающие вопросы, касающиеся его компании и характера ее деятельности: «Почему мы занимаемся тем, чем занимаемся? И почему мы это делаем именно так?». Задаваясь подобными фундаментальными вопросами, люди часто бывают вынуждены новыми глазами взглянуть на сложившиеся негласные правила и предположения, исходя из которых они руководят своим бизнесом.
Второе ключевое слово в определении — это «радикальный», которое является производным от латинского «radix», что значит «корень». Радикальное перепроектирование означает обращение к самым корням явлений: не проведение косметических изменений и не перетасовку уже существующих систем, а решительный отказ от всего отжившего. Радикальное перепроектирование при реинжиниринге сбрасывает со счетов все существующие структуры и методы и предполагает изобретение совершенно новых способов работы. Осуществить реинжиниринг бизнеса — это все равно что создать бизнес заново.
Третье ключевое слово — это «существенный». Реинжиниринг не имеет ничего общего с небольшими частичными или приростными улучшениями, он призван обеспечить общий мощный рост результативности. Если показатели компании лишь на 10% отстают от намеченных, если ее затраты превышаются на 10%, а качество оказывается на 10% ниже положенного, если обслуживание клиентов должно осуществляться на 10% оперативнее — такая компания вовсе не нуждается в реинжиниринге. Из этой десятипроцентной ямы компанию вполне могут «вытащить» более традиционные методы, например, призыв к подразделениям разработать программы по улучшению качества и так далее. Реинжиниринг нужен только тогда, когда ощущается потребность осуществить серьезный прорыв.
Четвертое ключевое слово в определении, данном авторами, — «процессы» — будучи наиболее важным, однако является именно тем понятием, которое представляет главную трудность для большинства руководителей корпораций. Основная часть бизнесменов вовсе не «ориентирована на процесс»: они сосредоточены на задачах, на отдельных операциях, на людях, на структурах, но никак не на процессах.
Авторы определяют бизнес-процесс как совокупность различных видов деятельности, в рамках которой «на входе» используется один или несколько видов ресурсов, и в результате этой деятельности на «выходе» создается продукт, представляющий ценность для потребителя
9.4 Моделирование бизнес-процессов.
Целью построения функциональной модели бизнес процесса является точная спецификация всех операций и действий, осуществляемых в деловом процессе, а также характера взаимосвязей между ними. Будучи построенной, такая модель способна обеспечить полное представление как о функционировании обследуемого процесса, так и о всех имеющих в нем место потоках информации и материалов.
Следует также отметить, что каждая операция в функциональной модели есть некоторый акт преобразования входных материалов или информации в продукт на выходе с использованием ресурсов в виде механизма и при выполнении условий, представленных в виде управления. Такую интерпретацию операций часто называют бизнес-правилом.
В ходе реализации программы интегрированной компьютеризации производства (ICAM), предложенной в свое время ВВС для аэрокосмической промышленности США, была выявлена потребность в разработке методов анализа взаимодействия процессов в производственных системах. Для удовлетворения этой потребности была разработана методология IDEF0 (Integrated Definition Function Modeling), которая в настоящее время принята в качестве федерального стандарта США.
Методология успешно применялась в самых различных отраслях, продемонстрировав себя как эффективное средство анализа, проектирования и представления деловых процессов. В настоящее время методология IDEF0 широко применяется не только в США, но и во всем мире.
Стандарт IDEF0 предназначен для описания бизнес-процессов на предприятии. Он помогает понять, какие объекты или информация служат «сырьем» для процессов, какие результаты влекут за собой те или иные работы, что является управляющими факторами и какие ресурсы для этого необходимы.
Основные понятия IDEF0.
В основе IDEF0 методологии лежит понятие блока, который отображает некоторую бизнес-функцию. Четыре стороны блока имеют разную роль: левая сторона имеет значение “входа”, правая - “выхода”, верхняя - “управления”, нижняя - “механизма”.
Взаимодействие между функциями в IDEF0 представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно “входным”, “выходным”, “управляющим”.
Принципы моделирования в IDEF0.
В IDEF0 реализованы три базовых принципа моделирования процессов:
– принцип функциональной декомпозиции;
– принцип ограничения сложности;
– принцип контекста.
Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций.
Принцип ограничения сложности. При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу.
Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы, на которой отображается только один блок - главная бизнес-функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная бизнес-функция не может быть сформулирована как, например, “продавать продукцию”. Главная бизнес-функция системы - это “миссия” системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии.
Одно и то же предприятие может быть описано по-разному, в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговой инспектор видят организацию совершенно по-разному. Поэтому при определении главной бизнес-функции необходимо всегда иметь ввиду цель моделирования и точку зрения на модель.
Контекстная диаграмма играет еще одну роль в функциональной модели. Она “фиксирует” границы моделируемой бизнес-системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию.
Применение IDEF0
После ознакомления с базовыми понятиями и принципами функционального моделирования деловых процессов естественным является вопрос: как это помогает повышать эффективность и качество деятельности предприятия.
Построение модели КАК ЕСТЬ. Обследование предприятия является обязательной частью любого проекта создания или развития корпоративной информационной системы. Построение функциональной модели КАК ЕСТЬ позволяет четко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций. Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов.
Бизнес- правила. Модель деловых процессов позволяет выявить и точно определить бизнес- правила, используемые в деятельности предприятия.
Очень часто бизнес- правила на предприятии не записаны в инструкции: они как бы есть, но и их как бы нет. В результате попытки изменить что-либо в деятельности предприятия или подразделения могут закончиться неудачей только лишь потому, что эти изменения противоречат сложившимся бизнес- правилам.
Информационные объекты. Функциональная модель позволяет идентифицировать все информационные объекты, которыми оперирует предприятие в своей деятельности. В отличие от информационных моделей (Data Flow Diagrams, IDEF1X) функциональная модель IDEF0 отражает, как именно используются информационные объекты в рамках деловых процессов.
Построение модели КАК БУДЕТ. Создание и внедрение корпоративной информационной системы приводит к изменению условий выполнения отдельных операций, структуры деловых процессов и предприятия в целом. Это приводит к необходимости изменения системы бизнес- правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель КАК БУДЕТ позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели КАК БУДЕТ позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям.
Распределение ресурсов. Функциональная модель позволяет четко определить распределение ресурсов между операциями делового процесса, что дает возможность оценить эффективность использования ресурсов.
Особенно эта задача актуальна при создании новых деловых процессов на предприятии. Например, компания, которая специализируется на разработке заказного программного обеспечения, приняла решение создать собственную службу сбыта. Функциональная модель делового процесса по продаже программного обеспечения позволит руководству компании четко определить, какие ресурсы необходимо выделить для того, чтобы обеспечить функционирование службы сбыта, сколько сотрудников необходимо привлечь для работы в новой службе, какие функциональные обязанности эти сотрудники должны выполнять и т.д.
9.5 Обзор систем автоматизированного проектирования КИС. CASE-технологии.
Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях экономики. Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:
сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
необходимость интеграции существующих и вновь разрабатываемых приложений;
функционирование в неоднородной среде на нескольких аппаратных платформах;
разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:
неадекватная спецификация требований;
неспособность обнаруживать ошибки в проектных решениях;
низкое качество документации, снижающее эксплуатационные качества;
затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ИС исторически всегда стояли последними в ряду тех, кто использовал компьютерные технологии для повышения качества, надежности и производительности в своей собственной работе (феномен "сапожника без сапог").
Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
Типы CASE-средств:
Средства анализа и проектирования (построение и анализ моделей деятельности): :BPwin (Platinum technology), Silverrum (Siverrum technologies), Oracle Designer (Oracle), Rational Rose (Rational Software), Power Designer(Sybase) и т.д.
Средства проектирования баз данных (моделирование данных и генерация схем баз данных для наиболее распространенных СУБД): есть в составе Silverrum, Oracle Designer, Paradigm Plus (Platinum technology), Power Designer. Наиболее известное средство – Erwin (Platinum technology).
Средства управления требованиями (обеспечивают комплексную поддержку разнородных требований к системе) – RequisitePro (Rational Software), DOORAS – динамическая объектно-ориентированная система управления требованиями.
Средства управления конфигурацией ПО – PVCS (Merant).
Средства документирования – SoDA (Rational Software).
Средства тестирования Rational Suite TestStudio (Rational Software).
Средства управления проектом – Open Plan Professional (Welkom Software).
Средства реверсного инжениринга (перенос существующего ПО в новую среду). Анализируют программные коды и схемы БД и формируют на их основе различные модели и проектные спецификации. Средства анализа схем БД входят в состав таких CASE-средств, как Silverrum, Oracle Designer, Power Designer, Erwin. Анализаторы программных кодов есть в составе Rational Rose, Paradigm Plus.
|
