Затонский А.В. Пособие по полному жизненному циклу информационных систем

Подождите немного. Документ загружается.

151

подразделений, устраняя излишнюю интеграцию, что приводит к

повышению эффективности процесса в целом.

6. Уменьшается количество проверок и управляющих воздействий.

Проверки и управляющие воздействия непосредственно не производят

материальных ценностей, поэтому задача реинжиниринга – сократить их

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

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

воздействий превосходит стоимость заказа требуемого продукта.

Реинжиниринг предлагает более сбалансированный подход. Вместо

проверки каждого из выполняемых заданий перепроектированный

процесс часто агрегирует эти задания и осуществляет проверки и

управляющие воздействия в отложенном режиме, что заметно сокращает

время и стоимость процессов.

7. Минимизируется количество согласований. Задача реинжиниринга

состоит в минимизации согласований путем сокращения внешних точек

контакта.

8. «Уполномоченный» менеджер обеспечивает единую точку контакта.

Механизм «уполномоченного» менеджера применяется в тех случаях,

когда шаги процесса либо сложны, либо распределены таким образом,

что их не удается объединить силами небольшой команды.

«Уполномоченный» менеджер играет роль буфера между сложным

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

ответственным за весь процесс. Чтобы выполнять эту роль, менеджер

должен быть способен отвечать на вопросы заказчика и решать его

проблемы, имея для этого доступ ко всем используемым

информационным системам и ко всем исполнителям.

9. Преобладает смешанный централизованно/децентрализованный подход.

Современные технологии дают возможность компаниям действовать

полностью автономно на уровне подразделений, сохраняя при этом

возможность пользоваться централизованными данными. Важность

объединения достоинств централизации и децентрализации можно

проиллюстрировать на примере работы банков. При работе с крупными

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

независимые финансовые отношения через различные подразделения.

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

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

соответствует его профилю. Пример реальной ситуации, в которой банк

установил для одного из своих клиентов максимальный кредит в размере

20 млн. долл. Вследствие децентрализованности этого банка каждое из

его подразделений выдало этому клиенту по 20 млн., а в результате

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

что выяснилось только после банкротства клиента.

152

Что не является реинжинирингом?

Теперь укажем, что не относится к реинжинирингу бизнес-процессов. К

сожалению, из-за большой популярности BPR часто происходит путаница

реинжиниринга с другими известными подходами. Итак, что не является

реинжинирингом?

1. Несмотря на важную роль, которую информационные технологии играют

в BPR, реинжиниринг нельзя непосредственно отождествлять с

автоматизацией бизнес-процессов. БПА, используя информационные

технологии, Автоматизирует существующий процесс со всеми его

недостатками и не ставит перед собой основную задачу реинжиниринга –

проектирование нового процесса для кардинального повышения его

эффективности.

2. Некоторые пользователи путают реинжиниринг бизнеса с

реинжинирингом программного обеспечения, задача которого состоит в

переписывании на основе современных технологий устаревших ИС без

изменения самих автоматизируемых процессов.

3. Реинжиниринг не является ни реструктурированием (restructuring), ни

уменьшением размерности (downsizing). Эти термины обозначают

уменьшение возможностей компании, например снижение

производственных мощностей, для соответствия текущим более низким

требованиям. Например, на рынке падает спрос на автомобили компании

GM, и ей необходимо перестроить производство с минимальными

затратами в сторону уменьшения количества выпускаемых автомобилей.

Реинжиниринг, в отличие от реструктурирования и уменьшения

размерности, стремится сделать больше, а не меньше.

4. Реинжиниринг – это не реорганизация (reorganizing) и не «выравнивание

организации» (flattening), хотя «выравнивание» вполне может оказаться

результатом проведения реинжиниринга. В отличие от реорганизации и

выравнивания, имеющих дело с организационными структурами,

реинжиниринг имеет дело с процессами. Многие компании видят

причину своих бед в бюрократии и пытаются с ней бороться. Это

ошибочная точка зрения. При традиционной иерархической структуре

организации, где процессы разбиты на фрагменты, выполняемые в

подразделениях, без бюрократии наступит хаос. Бюрократия – это клей,

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

Избавиться от бюрократии можно только с помощью реинжиниринга,

который восстанавливает целостность процессов.

5. Реинжиниринг ни в коем случае не улучшение качества (quality

improvement – QI) и не глобальное управление качеством (total quality

management – TQM). Хотя и реинжиниринг, и управление качеством

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

принципиальное отличие: управление качеством принимает имеющиеся

процессы и старается их улучшить, в то время как реинжиниринг

заменяет существующие процессы на новые.

153

Цикл современной компании начинается с реинжиниринга -

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

сопровождающейся переходом на новые принципы построения организации.

Этот вид деятельности требует выполнения специального проекта и создания

команды по реинжинирингу, включающей как сотрудников компании, так и

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

проекту завершаются и компания переходит к эволюционному периоду своего

развития, называемому усовершенствованием бизнеса: постоянные небольшие

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

возможности эволюционного развития исчерпываются, компания вновь

проводит реинжиниринг – как правило, проект охватывает уже не всю

компанию целиком, а несколько функциональных подразделений. Таким

образом, изменения организации работ в компании становятся частью ее

повседневной жизни – как реакция на постоянные изменения во внешнем

окружении: рынок, уровень технологий, потребности клиентов, конкуренция.

Методические средства информационных технологий и их

стандартизация

Для большинства технологий характерной чертой их развития является

стандартизация и унификация [43].

Стандартизация – нахождение решений для повторяющихся задач и

достижение оптимальной степени упорядоченности.

Унификация – относительное сокращение разнообразия элементов по

сравнению с разнообразием систем, в которых они используются.

Главная задача стандартизации в рассматриваемой области – создание

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

разработке, внедрению и использованию всех компонентов информационных

технологий. На сегодняшний день в области информационных технологий

наблюдается неоднородная картина уровня стандартизации. Для ряда

технологических процессов характерен высокий уровень стандартизации

(например, для транспортирования информации), для других есть большие

резервы по стандартизации.

Многообразные стандарты и подобные им методические материалы

упорядочим по следующим признакам:

1. По утверждающему органу:

• официальные международные стандарты;

• официальные национальные стандарты;

• национальные ведомственные стандарты;

• стандарты международных комитетов и объединений;

• стандарты фирм-разработчиков;

• стандарты «де-факто».

2. По предметной области стандартизации:

• функциональные стандарты (стандарты на языки программирования,

интерфейсы, протоколы, кодирование, шифрование);

154

• стандарты на фазы развития (жизненного цикла) информационных

систем (стандарты на проектирование, материализацию, эксплуатацию,

сопровождение и др.).

В зависимости от методического источника в качестве стандартов могут

выступать метод, модель, методология, подход. Следует отметить, что

указанные стандарты обладают разной степенью обязательности, конкретности,

детализации, открытости, гибкости и адаптируемости.

В качестве примера рассмотрим ряд стандартов различного уровня.

Международный стандарт ISO/OSI разработан международной

организацией по стандартизации (International Standards Organization — ISO),

предназначен для использования в области сетевого информационного обмена,

представляет эталонную семиуровневую модель, известную как модель OSI

(Open System Intercongtction — связь открытых систем). Первоначально усилия

были направлены на разработку структуры (модели) протоколов связи

цифровых устройств. Основная идея была связана с разбиением функций

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

одним более высоким и с одним более низким уровнем (за исключением самого

верхнего и самого нижнего). Идея семиуровневого открытого соединения

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

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

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

прогресс в реализации различных типов протоколов, о чем говорит успешное

функционирование многих сетей передачи данных, например, Интернета.

Международный стандарт ISO/IEC 12207:1995-08-01 – базовый стандарт

процессов жизненного цикла программного обеспечения, ориентированный на

различные его виды, а также типы информационных систем, куда программное

обеспечение входит как составная часть. Разработан в 1995 г. объединенным

техническим комитетом ISO/IEC JTC1 «Информационные технологии,

подкомитет SC7, проектирование программного обеспечения». Включает

описание основных, вспомогательных и организационных процессов.

Основные процессы программного обеспечения, предусмотренные этим

стандартом:

• процесс приобретения, определяющий действия покупателя,

приобретающего информационную систему, программный продукт или

его сервис;

• процесс поставки, регламентирующий действия поставщика,

снабжающего указанными выше компонентами;

• процесс разработки, определяющий действия разработчика принципов

построения программного изделия;

• процесс функционирования, определяющий действия оператора,

обслуживающего информационную систему в интересах пользователей и

включающий помимо требований инструкции по эксплуатации

консультирование пользователей и организацию обратной связи с ними;

155

• процесс сопровождения, регламентирующий действия персонала по

модификации программного продукта, поддержке его текущего

состояния и функциональной работоспособности.

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

управление конфигурацией, обеспечение качества, верификацию, аттестацию,

совместную оценку, аудит.

Рассмотрим краткую характеристику каждого этапа.

1. Формирование требований к ИС:

• обследование объекта и обоснование необходимости создания ИС;

• формирование требований пользователя к ИС;

• оформление отчета о выполненной работе и заявки на разработку ИС

(тактико-технического задания);

2. Разработка концепции ИС:

• изучение объекта;

• проведение необходимых научно-исследовательских работ;

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

пользователя;

• оформление отчета о выполненной работе;

3. Техническое задание:

• разработка и утверждение технического задания.

4. Эскизный проект:

• разработка предварительных проектных решений по системе и ее частям;

• разработка документации на ИС и ее части.

5. Технический проект:

• разработка проектных решений по системе и ее частям;

• разработка документации на ИС и ее части;

• разработка и оформление документации на поставку изделий для

комплектования ИС и/или технических требований (технических

заданий) на их разработку;

• разработка заданий на проектирование в смежных частях проекта объекта

автоматизации.

6. Рабочая документация:

• разработка рабочей документации на систему и ее части;

• разработка или адаптация программ.

7. Ввод в действие:

• подготовка объекта автоматизации к вводу ИС в действие;

• подготовка персонала;

• комплектация ИС поставляемыми изделиями (программными,

техническими и информационными средствами);

• строительно-монтажные работы;

• пуско-наладочные работы;

• предварительные испытания;

• опытная эксплуатация;

156

• приемочные испытания.

8. Сопровождение ИС:

• выполнение работ в соответствии с гарантийными обязательствами;

• послегарантийное обслуживание.

В связи с широким использованием в настоящее время объектной

технологии большой интерес представляет CORBA (Common Object Request

Broker Architecture) – стандарт в виде набора спецификаций для

промежуточного программного обеспечения объектного типа. OMG разработал

семантический стандарт, включающий 4 основных типа:

• объекты, моделирующие мир (студент, преподаватель, экзамен);

• операции, относящиеся к объекту и характеризующие его свойства (дата

рождения студента, пол и др.);

• типы, описывающие конкретные значения операций;

• подтипы, уточняющие типы.

Естественно затраты на стандартизацию могут сделать проектные работы

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

затраты с лихвой окупаются в процессе эксплуатации и развития системы,

например при замене оборудования или программной среды.

Таким образом, стандартизация является единственной возможностью

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

По аналогии с современным строительством, программные приложения

реализуются из компонентов. Под компонентом в данном случае понимают

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

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

взаимодействие с другими компонентами с помощью открытых интерфейсов.

Такая технология направлена на сокращение сроков разработки программных

приложений и обеспечение гибкости внедрения. В плане реализации подобной

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

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

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

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

информационных технологии имеют мало общего. Однако внедрение

информационных технологий всегда приводит к реорганизации бизнеса.

Потому методики моделирования бизнеса имеют много общего с

проектированием информационных систем. Здесь может быть выстроена

следующая цепочка: предметная область → бизнес-модель → модель

информационной системы → технологическая модель → детальное

представление → функционирование системы.

Среди стандартов проектирования бизнес-процессов можно отметить

следующие:

• семейство стандартов IDEF (Integration Definition for Function);

• RUP (компании Rational Software);

• catalysis (компании Computer Associates);

• семейство стандартов компании Oracle.

157

Каждый из этих стандартов базируется на исходных понятиях. Например,

в стандарте IDEF0 (Integration Definition for Function Modeling) такими

понятиями являются:

• «Работа» (Activity) – для обозначения действия;

• «Вход» (Input), Выход» (Output), «Управление» (Control), «Механизм»

(Mechanism) — для обозначения интерфейсов.

Использование стандартов проектирования бизнес-процессов позволяет

унифицировать процесс абстрагирования и формализации представления

предметной области. Мощным методологическим средством в этой области

является концепция CALS (Continuous Acquisition and Life cycle Support).

Русскоязычный термин, отражающий специфику CALS – компьютерное

сопровождение процессов жизненного цикла изделий (КСПИ). Выделяют

следующие основные аспекты данной концепции:

• компьютеризация основных процессов создания информации;

• интеграция информационных процессов, направленная на совместное и

многократное использование одних и тех же данных;

• переход к безбумажной технологии организации бизнес-процессов.

В методологии CALS (КСПИ) существуют две составные части:

компьютеризированное интегрированное производство (КИП) и

интегрированная логистическая поддержка (ИЛП).

В состав КИП входят:

• системы автоматизированного проектирования конструкторской и

технологической документации (САПР-К, САПР-Т, CAD/CAM);

• системы автоматизированной разработки эксплуатационной

документации (ETPD – Electronic Technical Develoment);

• системы управления проектами и программами (РМ – Project

Management);

• системы управления данными об изделиях (PDM – Project Data

Managent);

• интегрированные системы управления (MRP/ERP/SCM).

Система интегрированной логистической поддержки (ИЛП)

предназначена для информативного сопровождения бизнес-процессов на

послепроизводственных стадиях жизненного цикла изделий от разработки до

утилизации. Целью внедрения ИЛП является сокращение затрат на хранение и

владение изделием. В состав ИЛП входят:

• система логистического анализа на стадии проектирования (Logistics

Suuport Analysis);

• система планирования материально-технического обеспечения (Order

Administration, Invoicing);

• электронная эксплуатационная документация и электронные каталоги;

• система поддержки эксплуатации и др.

Важной составляющей (КСПИ) является электронная подпись (ЭЦП).

Современный электронный технический документ состоит из двух частей:

содержательной и реквизитной. Первая содержит необходимую информацию, а

158

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

числе из обязательных атрибутов — одну или несколько электронных

подписей.

Развитие CALS (КСПИ) связано с созданием виртуального предприятия,

которое создается посредством объединения на контрактной основе

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

связанных общими бизнес-процессами. Информационное взаимодействие

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

объединенных через общую корпоративную или глобальную сеть.

Значительный прогресс достигнут в области стандартизации

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

следующие классы и подклассы:

• символьный (подкласс – командный);

• графический (подклассы – простой, двухмерный, трехмерный);

• речевой;

• биометрический (мимический);

• семантический (общественный).

Выделяют два аспекта пользовательского интерфейса: функциональный и

эргономический, каждый из которых регулируется своими стандартами.

Подробнее вопросы разработки пользовательского интерфейса ИС будут

рассмотрены в соответствующем разделе учебника.

Критерии качества существующего или создаваемого

программного средства

Функциональность − это способность программного средства (ПС)

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

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

внешнем описании ПС.

Надежность (reliability) ПС − это его способность безотказно выполнять

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

времени с достаточно большой вероятностью. При этом под отказом в ПС

понимают проявление в нем ошибки. Таким образом, надежное ПС не

исключает наличия в нем ошибок − важно лишь, чтобы эти ошибки при

практическом применении этого ПС в заданных условиях проявлялись

достаточно редко. Убедиться, что ПС обладает таким свойством можно при его

испытании путем тестирования, а также при практическом применении. Таким

образом, фактически мы можем разрабатывать лишь надежные, а не

правильные ПС.

Легкость применения − это характеристики ПС, которые позволяют

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

применению ПС и оценке полученных результатов, а также вызывать

положительные эмоции определенного или подразумеваемого пользователя.

Эффективность

− это отношение уровня услуг, предоставляемых ПС

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

159

Сопровождаемость − это характеристики ПС, которые позволяют

минимизировать усилия по внесению изменений для устранения в нем ошибок

и по его модификации в соответствии с изменяющимися потребностями

пользователей.

Мобильность − это способность ПС быть перенесенным из одной среды

(окружения) в другую, в частности, с одного компьютера на другой.

Функциональность и надежность являются обязательными критериями

качества ПС, причем обеспечение надежности будет красной нитью проходить

по всем этапам и процессам разработки ПС.

Можно считать, что продуктом программирования является ПС,

содержащее программы, выполняющие требуемые функции. Здесь под

«программой» часто понимают правильную программу, т.е. программу, не

содержащую ошибок. Однако понятие ошибки в программе трактуется в среде

программистов неоднозначно. Будем считать, что в программе имеется ошибка,

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

«Разумное ожидание» пользователя формируется на основании документации

по применению этой программы. Следовательно, понятие ошибки в программе

является существенно не формальным. В ПС программы и документация

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

говорить об ошибке не в программе, а в ПС в целом: будем считать, что в ПС

имеется ошибка (software error), если оно не выполняет того, что разумно

ожидать от него пользователю. В частности, разновидностью ошибки в ПС

является несогласованность между программами ПС и документацией по их

применению.

Так как задание на ПС обычно формулируется неформально, а также из-

за того, что понятия ошибки в ПС не формализовано, то нельзя доказать

формальными методами (математически) правильность ПС. Нельзя показать

правильность ПС и тестированием: как указал Дейкстра, тестирование может

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

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

ПС мы не сможем убедиться, что достигли цели.

Альтернативой правильного ПС является надежное ПС.

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

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

времени. Другие критерии можно оценить только качественно, то есть по

бесцифровым шкалам: «хорошо» – «плохо», «высокая» – «низкая» и т.п.

Измерение значения критерия позволяет обнаружить проблему, решение

которой существенно важно для повышения качества ПС.

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

сколько полезность создаваемого ПС, являются его актуальность, практическая

значимость и научная новизна принимаемых решений.

Актуальный – важный, существенный для настоящего момента. Под

актуальностью работы следует понимать оправданность и действительную

необходимость её выполнения. Необходим также анализ предшествующих

исследований. Актуальность работы это необходимое и достаточное

160

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

поставленных проблем, качество анализа этой значимости, новизна работы.

Понятие практическая значимость работы включает оценку полученных

результатов с точки зрения полезности и научно-практическую ценность

вытекающих из работы выводов, а также рекомендации и факт внедрения.

Практическая значимость работы характеризует общественную, научную,

природоохранную или другую ценность полученных материалов и

подтверждается фактами доведения их до сведения государственных органов,

научной общественности, граждан, фактами внедрения, практической

реализацией природоохранных мероприятий и т.п.

Определение требований к ИС

Производится в последовательности:

1. Цель, стоящая перед создаваемой ИС.

2. Задачи, которые надо решить для достижения цели.

При разработке и использовании ПС мы многократно имеем дело с

преобразованием (переводом) информации из одной формы в другую.

Заказчик формулирует свои потребности в ПС в виде некоторых требований.

Исходя из этих требований, разработчик создает внешнее описание ПС,

используя при этом спецификацию (описание) заданной аппаратуры и,

возможно, спецификацию базового программного обеспечения. На основании

внешнего описания и спецификации языка программирования создаются

тексты программ ПС на этом языке. По внешнему описанию ПС

разрабатывается также и пользовательская документация. Текст каждой

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

частности, при исправлении в ней ошибки. Пользователь на основании

документации выполняет ряд действий для применения ПС и осуществляет

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

процессах разработки ПС, имеет место указанный перевод информации (рис.

21).

Определение требований к ИС − задание, отражающее в абстрактной

форме потребности пользователя. В общих чертах определяет замысел ИС,

характеризует условия использования ИС. Неправильное понимание

потребностей пользователя трансформируется в ошибки внешнего описания.

Поэтому разработка ПС начинается с создания документа, достаточно полно

характеризующего потребности пользователя и позволяющего разработчику

адекватно воспринимать эти потребности.

Определение требований представляет собой смесь фрагментов на

естественном языке, различных таблиц и диаграмм. Такая смесь, должна быть

понятной пользователю, не ориентирующемуся в специальных

программистских понятиях. Обычно в определении требований не содержится

формализованных фрагментов, кроме случаев достаточно для этого

подготовленных пользователей (например, математически)

− формализация