КАРДИНАЛЬНЫЕ ИЗМЕНЕНИЯ В ПРОЦЕССАХ СОЗДАНИЯ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ Текст научной статьи по специальности «Компьютерные и информационные науки»

Ф.Ф. Иванов

КАРДИНАЛЬНЫЕ ИЗМЕНЕНИЯ В ПРОЦЕССАХ СОЗДАНИЯ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Введение в проблему

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

При всем широком многообразии классов АИС, все-таки главным признаком ее остается способность своевременно, качественно и в удобной форме предоставлять информационный ресурс для пользователя (потребителя). И чем выше скорость реакции системы на запрос пользователя, чем интеллектуальнее ее наполнение, тем сложнее и ценнее сама система, тем выше ее статус.

Небезынтересна взаимосвязь АИС и информационных технологий (ИТ). Как долгое время смешивали понятия базы данных ( БД) и банка данных (БнД)[1,2], так и по сей день в литературе, в обсуждении нередко смешиваются понятия ИТ и АИС.

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

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

Сами ИТ постоянно совершенствуются и автоматически обеспечивают возможность развития и производных от них АИС. Это совершенствование имеет два неисся-кающих источника: развитие собственных компонент ИТ (математических, алгоритмических, программных, информационных, технических, организационно-методических средств), а также растущие потребности АИС в достижении двух центральных глобальных целей информатизации (максимальной автоформализации знаний специалистов предметной области и высокой интеллектуализации взаимодействия пользователей и средств автоматизированных систем [3]). Развивая, наполняя ИТ функциональностью (решением задач предметной области), получаем полномасштабную АИС определенного типа. Нельзя не заметить, что применение конкретной ИТ (например, обработки текстовой или числовой информации ) в конкретной АИС практически всегда ограничивается ее базовыми возможностями, оставляя неиспользованной значительную долю полезных ее свойств, а в ряде случаев и подменяя (расширяя) их собственными средствами, по разумению разработчиков, более приспособленными к особенностям конкретной АИС. Эта особенность иллюстрируется на рис. 1.

Ранее, в условиях традиционных методов проектирования и разработки автоматизированных систем (АС), использовались эволюционно три типа моделей жизненного цикла этих процессов (каскадная, итерационная, спиральная) [4]. У каждой из них свои преимущества, недостатки, но все они обязательно подкреплялись достижениями в области теории математики, информатики, автоматизированных систем, информационных технологий.

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

Рис.1.

Интеграция многих ИТ в АИС

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

Готовое проектное решение или собственная разработка?

Пройдя этапы процедурного и структурного проектирования и программирования [4,5] через применение множества алгоритмических языков и технологий построения программно-технических комплексов, особенностей построения баз данных, разработчики постоянно добивались максимальной независимости от аппаратно-программной платформы, а также прозрачности и логической гибкости построенных технологий, превращения чрезвычайно трудоемкого и длительного процесса создания АИС в процесс конструирования ее в терминах и представлениях потенциальных пользователей (или хотя бы специалистов предметной области: технологов, инженеров-конструкторов, математиков, физиков, медиков и т.п.).

И это удалось с момента освоения и внедрения сначала модульного принципа, а затем объектно-ориентированного подхода (ООП) в создании и использовании АИС [4,5,6]. Потребовался новый взгляд, кардинальное представление о том, что большинство системных принципов проектирования АС (решение новых задач, непрерывность развития, типизация и стандартизация, системный подход, иерархичность, экономическая целесообразность и др.) могут достигаться с меньшими усилиями, затратами, ошибками, с большей эффективностью и при этом гарантируется значительно больший срок эксплуатации созданной системы. Существенное влияние оказало на эти процессы появление и развитие специализированных CASE-средств (технологий Computer Aided System Engineering и/или Computer Aided Software Engineering) [7,8].

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

- Бизнес-архитектура определяет основы и принципы проектирования интегрированной системы с точки зрения технологического управления. Основным компонентом этой архитектуры является модель интегрированных бизнес-процессов.

- Техническая архитектура определяет основы и принципы проектирования интегрированной системы с точки зрения информационных технологий.

- Организационная архитектура определяет структуру управления системой и компоненты, необходимые для функционирования интегрированной системы в целом и ее развития по мере появления новых требований, обусловленных задачами АИС.

Для обеспечения высоких показателей важнейших характеристик АИС, таких, как срок жизни, адаптируемость, масштабируемость, широкий выбор и инвариантность прикладных решений, в основу системы в настоящее время положены следующие принципы:

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

- моделирование объекта управления, управляющей системы и их окружения;

- компонентный (модульный) подход к построению отдельных подсистем;

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

Общая функциональность системы определяется автоматизируемыми бизнес -процессами. Поскольку в различных бизнес-процессах могут использоваться одинаковые

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

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

Полученные таким образом компоненты АИС функционируют в реальной предметной области с учетом необходимой интеграции (организующего начала) по следующим основным направлениям (табл.1).

Таблица 1.

Методы и средства интеграции в АИС

Виды интеграции

Функциональная Техническая Информационная Программная

1. Согласованное управление активными объектами 1.Коллективное использование ресурсов 1.Унификация и стандартизация форм документов 1.Иерерхическое проектирование КТС

2. Координация видов деятельности по жизненному циклу 2.Вычислительная сеть 2.Системы классификации и кодирования 2.Модульное построение программных компонент

3.Многослойная функциональная иерархия 3. Система передачи данных 3. Формализация методов идентификации объектов 3. Система межуровневых и внутриуровневых интерфейсов

4. Управление конфигурацией системы 4.Многомашинный вычислительный комплекс 4.Модели информационных потоков 4.Программы сетевой обработки данных

5. Иерархическая система моделей 5.Комплексирование памяти и устройств ввода/вывода 5.Распределенная БД 5. Современные архитектуры систем

6.Развитие средств сбора и обработки данных 6.Языки описания документов, сообщений 6.Программы синхронизации различных режимов обработки данных

7. Система норм и нормативов 7. Программы управления однородными и неоднородными вычислительными сетями

В публикациях давно обсуждается идея реализации стандартов системной интеграции программных средств, поставляемых различными производителями. Прогресс системного инструментария привёл к появлению объектно-ориентированных и компонентных технологий разработки программного обеспечения (ПО), которые позволяют строить крупномасштабные системы из готовых блоков. Ведущие поставщики аппаратного и системного программного обеспечения (Intel, Microsoft, Sun, Oracle, IBM и др.), комму-

никационных средств (Cisco, Nortel, Ericsson, Motorola), прикладных решений (SAP, PeopleSoft, Siebel и др.), авторитетные государственные, международные, коммерческие и некоммерческие организации и ассоциации (ISO, IEEE, ASCII, APICS, РосСтандарт и др.) к настоящему моменту разработали и активно внедряют на практике технологии интеграции аппаратных и программных средств, позволяющие создавать открытые системы на базе стандартов и протоколов обмена данными и взаимодействия компонент в гетерогенной среде в режиме реального времени.

Усилиями ряда фирм, в том числе и отечественных, за последние 10-15 лет сложилось направление создания АИС на предприятии на основе готовых решений. На базе современных компьютерных технологий создано поколение систем управления, именуемое ERP (Enterprise Resource Planning - планирование ресурсов предприятия, то есть системы управления ресурсами).

Такие системы предоставляют возможность работать на интегрированном информационном поле множеству удаленных пользователей. Родоначальником рынка ERP-систем является немецкая компания SAP AG c продуктом R/3. К числу же наиболее значительных представителей рынка ERP можно отнести зарубежные фирмы PeopleSoft, Oracle, Baan, J.D. Edwards, отечественные фирмы 1С, корпорацию Галактика и др.

Обычно ERP строятся по принципу модульной архитектуры, и все же они не более, чем разновидность АИС. Приведем одно из определений ERP: «Набор интегрированных приложений, позволяющих создать единую среду для автоматизации планирования, учета, контроля и анализа всех основных бизнес-операций предприятия, как то: производство, финансы, снабжение, сбыт, хранение, техническое обслуживание и т. д. ».

К этому перечню можно добавить реализованные в ряде ERP-систем SSM (поддержку управления сбытом и сервисом), SCM (управление цепочками поставок), PDM (данные о продукции), а иногда и CRM (стратегии отношений с клиентами) и др.

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

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

Стандартный процесс внедрения ERP-системы состоит из следующих этапов:

1. Разработка стратегий автоматизации.

2. Анализ деятельности предприятия.

3. Реорганизация деятельности.

4. Выбор системы.

5. Внедрение системы.

6. Использование (эксплуатация + сопровождение).

Понятие «стратегия автоматизации» состоит из базовых принципов, которые используются при автоматизации предприятия:

- цели (выявление областей деятельности предприятия и последующая их автоматизация);

- способ автоматизации (по отделам, направлениям или комплексная автоматизация);

- долгосрочная ИТ-политика (внедрение комплекса внутренних стандартов);

- ограничения (финансовые, временные, кадровые и т. д.);

- процедура управления изменениями в планировании.

По сути, стратегия автоматизации представляет собой процесс, четко согласованный по срокам и целям со стратегией компании. В противном случае успешная интеграция будет попросту невозможна. Рассмотрение этапов 1-3 не входит в рамки данной статьи и поэтому ниже в разных ракурсах описываются только особенности выполнения этапа выбора системы.

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

На практике встречаются следующие основные варианты создания АИС[11]:

1. Создание и внедрение осуществить полностью собственными силами.

2. Реализовать проект "под ключ" силами внешней компании-консультанта.

3. Привлечь руководителя проекта от внешней компании-консультанта.

4. Привлечь экспертов по продукту от внешней компании-консультанта.

Основными вариантами являются, конечно, 1 и 2. Варианты 3 и 4 являются

"промежуточными". В табл.2 ниже приведено сравнение этих вариантов.

Таблица 2.

Сравнительная таблица вариантов создания АИС

Вариант Преимущества Недостатки

1. Внедрение полностью собственными силами 1. Меньшие финансовые затраты 2. Знание бизнес-процессов 3. Независимость на этапе эксплуатации 1. Требуются специалисты с хорошим знанием программного продукта 2. Требуются программисты 3. Требуется разработка методологии управления проектом и четкое следование ей

2. Реализация проекта (или его этапов) "под ключ" силами внешней компании-консультанта 1. Опыт управления проектами 2. Разработанная и "обкатанная" методология внедрения 3. Опыт внедрения системы на нескольких предприятиях 4. "Новый взгляд" на задачи предприятия 5. Знание программного продукта 6. Штат опытных программистов 1. Бoльшие финансовые затраты 2. Сторонние консультанты не знают особенностей конкретного предприятия, и им требуется время на их изучение 3. Проблема поддержания системы на этапе эксплуатации

Вариант Преимущества Недостатки

3. Привлечение руководителя проекта от внешней компании-консультанта 1. Меньшие финансовые затраты 2. Опыт управления проектами 3. Опыт внедрения системы на нескольких предприятиях 4. Владение современными методами построения систем управления 5. Независимость на этапе эксплуатации 1. Требуется разработка методологии управления проектом и четкое следование ей 2. Необходимость решения вопроса занятости сотрудников, выделенных (или нанятых) для реализации проекта 3. Требуются программисты

4. Привлечение экспертов по продукту от внешней компании-консультанта 1. Меньшие финансовые затраты 2. Знание программного продукта 1. Требуется разработка методологии управления проектом и четкое следование ей 2. Необходимость решения вопроса занятости сотрудников, выделенных (или нанятых) для реализации проекта

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

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

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

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

Основные аргументы против собственного изготовления системы таковы: на написание стандартных промышленных систем, таких как SAP, Oracle Applications, People Soft необходимы большие ресурсы. Причем это касается не только написания, но и последующей отладки ERP-системы. Так, на разработку последней интернет-ориентированной ERP-системы компания PeopleSoft потратила $500 млн. и два года работы 2 тыс. разработчиков;

- промышленные системы опробованы и работают на тысячах предприятий всего мира: например, у того же SAP R/3 более 15 тыс. клиентов;

- как правило, стандартные системы сопровождаются выверенными методологиями внедрения;

- в случае с «самописной» системой человек, ее написавший, может при увольнении забрать все свои наработки, что невозможно при использовании стандартных систем.

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

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

Ниже приведен перечень фирм, специализирующихся на разработке и внедрении ЕКР-систем (табл.3.)[7].

Таблица 3

Перечень отечественных и зарубежных фирм, разработчиков ЕКР-систем

Корпоративная АИС (фирма) Сфера применения Срок внедрения Стоимость внедрения

SAP R/3 Оборонные предприятия, компании нефтегазового комплекса, металлургия, энергетика телекоммуникации, банковский сектор. 1-5 лет и более Лицензия на 50 рабочих мест стоит около $350 тыс. Стоимость внедрения может в несколько раз превышать стоимость решения.

Oracle Applications Тяжелая промышленность (преимущественно металлургия), телекоммуникационные компании, финансовый сектор, химическая промышленность. 1-5 лет и более Стоимость решения на одно рабочее место составляет около $5 тыс. Полная стоимость существенно зависит от требуемой функциональности и сложности внедрения.

IFS Application Предприятия машиностроительного комплекса, энергетика, пищевая промышленность, фармацевтика, кабельная промышленность. 0,8-3 года и более Полная стоимость внедрения может достигать $250 тыс. и более. Также существенно зависит от требуемой функциональности.

Baan ERP Автомобилестроение, химическая промышленность, фармацевтика, пищевая промышленность. 6 мес-1,5 года и более Стоимость одного рабочего места -$3 тыс. Соотношение цены решения и расходов на внедрение 1:11:3.

iRenaissance Пищевая промышленность, химические компании, металлургическая промышленность нефтеперерабатывающие, целлюлозно-бумажные, фармацевтические предприятия. 4 мес. - 1,3 года и более Стоимость внедрения в среднем $200 тыс.

Корпоративная АИС (фирма) Сфера применения Срок внедрения Стоимость внедрения

MBS Axapta, Navision Предприятия нефтяной отрасли, пищевой промышленности, торговые компании, металлургия, дистрибуция, телекоммуникационная отрасль. 6 мес. - 2 года и более В среднем стоимость решения на одно рабочее место - $3,5 тыс. Стоимость внедрения составляет 100-250% стоимости решения.

iScala Машиностроение, телекоммуникационная отрасль, пищевая промышленность. 3 мес. - 1,5 года и более Средняя стоимость iScala 2.1 составляет $2-5 тыс. за одно рабочее место.

MF G/PRO Автомобильная, авиационная, электронная, электротехническая, химическая, фармацевтическая и пищевая промышленность. 3 мес. - 1,5 года и более Стоимость лицензии на одно рабочее место $2-5 тыс. в зависимости от конфигурации. Внедрение обходится в 100-200% этой суммы.

J.D.Edwards OneWorld Горнодобывающая промышленность, строительные организации, торговые компании, нефтегазовый сектор. 7 мес. - 1,5 года и более Стоимость рабочего места One-World варьируется от $400 до $4000.

SyteLine ERP Производители измерительного и электрооборудования, деревообработка, полиграфия, машиностроение. 6 - 9 месяцев и более Стоимость лицензии на одно рабочее место $2-4 тыс. Примерно во столько же обойдется внедрение.

"Галактика" Нефтегазовая отрасль, машиностроение, химия, энергетика, металлургия и др. 4 мес. - 1,5 года и более Лицензия $350-1200 на одно рабочее место. Стоимость внедрения составляет 50-100% этой суммы.

"Парус" Машиностроение, нефтегазовые компании, предприятия энергетической отрасли 4 мес. - 1 год и более Стоимость лицензии на одно рабочее место $1-2 тыс. Стоимость внедрения 100-200% цены решения.

"1С: Предприятие 8.0. Управление производственным предприятием" Машиностроение, пищевая промышленность и др. 3-9 мес. и более Лицензия на одно рабочее место $150-600. Стоимость внедрения на одно рабочее место $200-1000

Корпоративная АИС (фирма) Сфера применения Срок внедрения Стоимость внедрения

КИС "АС+" Энергетика, телеком, химическая, пищевая промышленность и др. 6-12 мес. и более Лицензия на один функциональный модуль (без учета рабочих мест) от $15 тыс. до $100 тыс. Стоимость внедрения 100%-200% стоимости лицензий.

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

Объектно-ориентированный анализ, проектирование и программирование

Третий и четвертый этап развития ИТ (1975-2000 гг.) стали революционными для создания и внедрения АИС. Для них характерно не только появление и промышленное внедрение персональных ЭВМ, не только стандартизация в области сетей и распределенной обработки, не только зарождение и упрочение всемирной паутины, но и обобщение опыта специалистов многочисленных фирм по проектированию, разработке и внедрению АСУ, возникновение особых АИС (систем поддержки принятия решений (СППР), экспертных систем (ЭС), автоматизированных систем научных исследований (АСНИ), пакетов прикладных программ (ППП) и типовых проектных решений (ТПР)), типизация и стандартизация в области АС в виде все еще действующих стандартов [12], которые были незначительно видоизменены в последние годы (2005г.), а также их согласование с новыми стандартами в этой сфере за рубежом (семейство стандартов ИСО).

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

Каждый год в этот период вступали в действие сотни тысяч разнообразных АСУ в различных отраслях, активно развивалась теория, и все же возрастало среди заказчиков и разработчиков недовольство трудоемкостью создания систем, неудовлетворительными характеристиками мобильности и адаптивности и слишком коротким периодом эксплуатации (быстрым моральным старением).

Изменение структуры программно-технологических комплексов от монолитной (один EXE-модуль содержит все для решения задачи) и оверлейной (весь комплекс состоит из нескольких EXE-модулей (один - головной, остальные - поддеревья всей системы к динамической). Появление динамических загружаемых библиотек модулей-DLL (DYNAMIC LINK LIBRARY, а впоследствии и переход к объектно-ориентированной идеологии существенно улучшили ситуацию на этапах проектирования и одновременно усложнили процессы отладки (событийное управление!), и, кажется, вновь, как на ранних этапах развития АИС «привязали» оператора (пользователя) к рабочему месту (креслу!). Но за все надо платить, ведь, несмотря на стремительный рост возможностей вычислительной техники и средств связи, опережающий рост размеров приложений и

необходимость сокращения сроков появления новых версий все-таки требовали новых подходов.

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

Традиционно во всех стандартных моделях выделяют следующие основные этапы жизненного цикла: стратегическое планирование; анализ требований; проектирование (предварительное и детальное); кодирование (программирование); тестирование и отладка; эксплуатация и сопровождение.

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

Сначала появилось объектно-ориентированное программирование и только затем -объектно-ориентированное проектирование. Ранние этапы описания предметной области и разработки архитектуры системы не поддерживались. Первые варианты применения объектно-ориентированной методологии в большой степени являлись чистым повторением принципов объектно-ориентированного программирования. Такие вопросы как декомпозиция предметной области, спецификация требования, интерфейс с пользователем не рассматривались. Но успехи объектно-ориентированного программирования заставили распространить новую технологию на весь жизненный цикл.

Рис.2.

Модель жизненного цикла иМЬ

Фирма Rational Software, разработавшая язык UML [13,14], предложила так же и свою модель жизненного цикла, которая называется Rational Objectory Process. Можно перечислить следующие основные свойства данной технологии:

- процесс итеративный, т.е. происходит последовательное уточнение результатов;

- действия процесса направлены на создание моделей, а не других элементов проекта, например, текстовых документов;

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

Жизненный цикл разбит на внутренние циклы, результатом каждого из которых является собственная версия программной системы. Каждый цикл состоит из четырех фаз (рис.2.): 1) начало (Inception ); 2) совершенствование ( Elaboration ); 3) построение ( Construction ); 4)переход ( Transition ).

В настоящее время объектно-ориентированный подход является одним из быстро развивающихся направлений в проектировании систем. Примером могут являться объектно-ориентированный анализ - методология разработки систем, предложенная Йорде-ном; объектно-ориентированное проектирование, объектно-ориентированное программирование, реализованное в многочисленных компиляторах C++, Object Pascal, Borland Pascal, Smalltalk.

Как уже отмечалось, объектно-ориентированное программирование возникло раньше объектно-ориентированного анализа и проектирования, поэтому на сегодняшний день существует достаточно большое количество языков, поддерживающих данную технологию. Первым из них, по дате возникновения, считается язык Smalltalk, хотя многие элементы объектно-ориентированного подхода были использованы еще в языке Simula в 1967г. Наиболее мощным инструментом создания объектно-ориентированных программ на сегодня является язык C++, созданный на базе языка структурного программирования C. Успешно развивается язык Java, который изначально разрабатывался как объектно-ориентированный.

Разработка крупных программных систем в современных условиях невозможна без использования средств автоматизации разработки программного обеспечения (CASE средств). CASE, поддерживающих объектно-ориентированный подход не так много. Наиболее известное средство в этом направлении система Rational Rose, которая поддерживает, в том числе, этапы объектно-ориентированного анализа и проектирования.

Разработчик Rational Rose - фирма Rational Software Corp., известная своими наработками в области объектно-ориентированных технологий, главной из которых является язык UML.

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

Rational Rose состоит из следующих основных компонент: репозиторий, графический интерфейс пользователя, средства инспекции проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов и также расширения для поддержки различных языков программирования.

Из основных возможностей можно перечислить следующие:

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

дологию;

- удобная навигация между элементами модели при помощи "инспектора проекта";

- хранение результатов проектирования в виде единой модели;

- поддержка работы над проектом группы разработчиков;

- мощная система подготовки отчетов и документации о проекте;

- возможности синтеза программ практически на всех современных объектно-ориентированных языках, в том числе и на межплатформенном языке Java;

- поддержка компонентных технологий построения программных систем;

- широкие возможности по проектированию ПО различной архитектуры, от простых программ до крупных "клиент-серверных" систем и Интернет-приложений;

- возможность реинжиниринга модели на основе исходных текстов программы. Этим обеспечивается поддержание единства проектной информации и реализации;

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

Объектно-ориентированный подход не гарантирует создания правильных программ. Следовательно, тестирование так же необходимо для объектно-ориентированных программ, как и для структурных. Преимущества этого подхода, выражающиеся в возможности повторного использования, приводят к необходимости более тщательного тестирования. Классы обычно создаются заранее с возможностью использования в различных задачах, а, следовательно, одна задача не может полностью обеспечить тестирования взаимодействия методов поведения классов. Основные свойства объектов (инкапсуляция, наследование, полиморфизм) добавляют новые аспекты тестирования. Заключение

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

Примечания

1. Диго, С.М. Базы данных: проектирование и использование : учебник для студ. вузов. - М. : Финансы и статистика, 2005. - 590 с.

2. Коннолли, Т., Бегг, К. Базы данных: проектирование, реализация и сопровождение: теория и практика - М.: Вильямс, 2003. - 1439 с.

3. Советов, Б. Я. Информационная технология : Учеб. для ВУЗов по спец.

«Автоматизир. системы обработки информ. и упр.» — М. : Высш.шк., 1994. — 368 с.

4. Жаков, В.И., Путилов, В.А., Фильчаков, В.В., Янкелевич, А.А., Объектно-ориентированная технология разработки программных систем. - Апатиты: КФ ПетрГУ, 1998. [Электронный ресурс]: Режим доступа: http://guap.ru/dept04/caf46/textbooks/oop/ _Toc436898582

5. Непейвода, Н.Н. Стили и методы программирования. Интернет-университет информ. технологий - ИНТУИТ.ру, 2005. [Электронный ресурс] : Режим доступа: http:// www.intuit.ru/department/se/progstyles/1/

6. Буч, Г., Объектно-ориентированное проектирование с примерами применения. -М.: Конкорд, 1992.

7. Советов, Б. Я. Цехановский, В. В.; Чертовской, В. Д. Теоретические основы автоматизированного управления: учеб. для студ. вузов. - М.: Высшая школа, 2006. - 461с.

8. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). - М.: Лори, 1996.

9. Автоматизированная система технологического управления Единой национальной электрической сетью (ЕНЭС) ОАО «ФСК ЕЭС» [Электронный ресурс]: Режим доступа: http://www.fsk-ees.ru/evolution_technology_development_astu.html

10. Гнатуш А. Журнал IT Manager, №2, 2005г. [Электронный ресурс]: Режим доступа: http://itm.finestreet.ru/

11. Консультационная группа АТК [Электронный ресурс]: Режим доступа: http:// www.atkcg.ru/

12. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы: Сб.ГОСТ 34.201-89,ГОСТ 34.602-89,РД 50-682-89. -М.: Изд-во стандартов, 1989. - 34с.

13. Трофимов С.А. CASE-технологии: Практическая работа в Rational Rose. Изд. 2.

- М.: Бином-Пресс, 2002 г. - 288 с.

14. Буч Г., Рамбо Д., Якобсон И. Язык UML: Руководство пользователя. - М.: ДМК

- пресс, 2007. - 496 с.