книги / Теоретические основы автоматизированного управления

В табл. 10.1 приведен обзор наиболее распространенных объект­ но-ориентированных CASE-средств, используемых при проектиро­ вании АСУ.

Сравнительный анализ CASE-систем показывает, что на сего­ дняшний день одним из наиболее приближенных к идеальному вари­ анту CASE-средств является семейство Rational Rose фирмы Rational Software Corporation. Следует отметить, что именно здесь работают авторы унифицированного языка моделирования Г. Буч, Д. Рамбо и И. Джекобсон, под руководством которых ведется разработка нового CASE-средства, поддерживающего UML.

Выделим основные критерии оценки и выбора CASE-средств:

1)функциональные характеристики:

•среда функционирования — проектная среда, программное обеспечение/технические средства, технологическая среда;

•функции, ориентированные на фазы жизненного цикла — мо­ делирование, реализация, тестирование;

•общие функции — документирование, управление конфигура­ цией, управление проектом;

2)надежность;

3)простота использования;

4)эффективность;

5)сопровождаемость;

6)переносимость;

7)общие критерии (стоимость, затраты, эффект внедрения, ха­ рактеристики поставщика).

Данные критерии подробно изложены в стандартах IEEE Std 1348-1995. IEEE recommended Practice for the Adoption of ComputerAided Software Engineering (CASE) Tools и IEEE Std 1209—1992 Recommended Practice for the Evaluation and Selection ofCASE Tools.

10.4. ОЦЕНКА КАЧЕСТВА АСУ

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

В зависимости от целей исследования и этапов жизненного цикла АСУ дефектологические свойства разделяют на дефекгогенность, дефектабельность и дефектоскопичность [55].

Дефекгогенность определяется влиянием следующих факторов:

• численностью разработчиков АСУ, их профессиональными и психофизиологическими характеристиками;

•условиями и организацией процесса разработки АСУ;

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

АСУ;

•сложностью задач, решаемых АСУ;

•степенью агрессивности внешней среды (потенциальной воз­ можностью внешней среды вносить преднамеренные дефекты, на­ пример воздействие вирусов).

Дефектабельность характеризует наличие дефектов АСУ и опре­ деляется их количеством и местонахождением. Другими факторами, влияющими на дефектабельность, являются:

•структурно-конструктивные особенности АСУ;

•интенсивность и характеристики ошибок, приводящих кдефек-

там.

Дефектоскопичность характеризует возможность проявления де­ фектов в виде отказов и сбоев в процессе отладки, испытаний или эксплуатации. На дефектоскопичность влияют:

•количество, типы и характер распределения дефектов в АСУ;

•устойчивость АСУ к проявлению дефектов;

• характеристики средств контроля и диагностики дефектов;

• квалификация обслуживающего персонала.

Оценка качества АСУ является крайне сложной задачей ввиду многообразия интересов пользователей. Поэтому невозможно пред­ ложить одну универсальную меру качества и приходится использо­ вать ряд характеристик, охватывающих весь спектр предъявляемых требований. Наиболее близки к задачам оценки качества АСУ модели качества программного обеспечения, являющегося одной из важных составных частей АСУ. В настоящее время используют несколько аб­ страктных моделей качества программного обеспечения, основан­ ных на определениях характеристики качества, показателя качества, критерия и метрики.

Критерий может быть определен как независимый атрибут АСУ или процесса ее создания. С помощью такого критерия можно изме­ рить характеристику качества АСУ на основе той или иной метрики. Совокупность нескольких критериев определяет показатель качест­ ва, формируемый исходя из требований, предъявляемых к АСУ. В на­ стоящее время наибольшее распространение получила иерархиче­ ская модель взаимосвязи компонентов качества АСУ. Вначале опре­ деляются характеристики качества, в числе которых M oiyr быть, на­ пример, общая полезность, исходная полезность, удобство эксплуата­ ции. Далее формируются показатели, к числу которых могут быть от­ несены: практичность, целостность, корректность, удобство обслу-

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

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

возможность взаимодействия — модульность, унифицируемость процедур связи, унифицируемость данных.

С помощью метрик можно дать количественную или качествен­ ную оценку качества АСУ. Различают следующие виды метрик и шкал для измерения критериев.

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

Второй тип — метрики, которым соответствует порядковая шка­ ла, позволяющая ранжировать характеристики путем сравнения с опорными значениями.

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

Рис. 10.8. Модель классификации критериев качества АСУ

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

Одним из путей обеспечения качества АСУ является сертифика­ ция. В США Радиотехническая комиссия по аэронавтике в своем ру­ ководящем документе определяет процесс сертификации как процесс официального утверждения государственным полномочным органом выполняемой функции системы путем удостоверения, что функция удовлетворяет всем требованиям заказчика, а также государственным нормативным документам. К сожалению, в настоящее время не су­ ществует стандартов, полностью удовлетворяющих оценке качества АСУ. В западноевропейских странах имеется ряд стандартов, опреде­ ляющих основы сертификации программных систем.

Стандарт Великобритании (BS750) описывает структурные по­ строения программных систем, при соблюдении которых может быть получен документ, гарантирующий качество на государственном уровне. Имеется международный аналог указанного стандарта (ИСО 9000) и аналог для стран — членов НАТО (AQAP1). Сущест­ вующая в нашей стране система нормативно-технических докумен­ тов относит программное обеспечение к «продукции производствен­

но-технического назначения», которая рассматривается как матери­ альный объект. Однако программное обеспечение является скорее абстрактной нематериальной сферой. Существующие ГОСТы (на­ пример, ГОСТ 28195—89 «Оценка качества программных средств. Общие положения») явно устарели и являются неполными.

10.5. ПРАКТИЧЕСКИЕ ПРИМЕРЫ ПРОЕКТИРОВАНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

10.5.1. Характеристика систем «Галактика» и BAAN

При создании системы «Галактика» использовали следующие по­ ложения:

1)должны быть определены цели и стратегия развития предпри­

ятия;

2)в процессе проектирования и внедрения должен участвовать первый руководитель;

3)следует учитывать «человеческий фактор» ЛПР;

4)необходимо проводить системную, а не «лоскутную» автомати­ зацию.

Система «Галактика» строится как система контуров (рис. 10.9), которые используют цикличность (повторяемость) процессов во вре­ мени и модулей (табл. 10.2).

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

Чтобы как-то уйти от неопределенности, в этой системе и ряде других, особенно отечественных разработок, модули «привязывают» к этапности ERP-стандарта (точнее к MRPII) (табл. 10.3). Контуры формируются скорее как самостоятельные блоки, которые покупа­ тель может приобрести отдельно.

Впроектировании системы «Галактики» выделены такие этапы.

1.Диагностика состояния предприятия — разработка плана реструктуризации/развития предприятия. Здесь определяют основные проблемы, цели развития, приоритетные меры, разрабатывают де­ тальный план мероприятий.

2. Реинжиниринг бизнес-процессов — проектирование автома­ тизированной системы.

Рис. 10.9. Контуры системы «Галактика»