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

Для решения этой проблемы воспользуемся методом экспертного оце­нивания [7]. При этом группе, состоящей из m экспертов, предлагается проранжировать по степени важности п характеристик (свойств, показате­лей) сопоставляемых технологий (вариантов выбора). Каждый эксперт, действуя независимо от других, должен приписать ранг 1 наиболее важно­му свойству, ранг 2 - следующему и т. д. Допускается приписывание двум или более свойствам одного и того же ранга (совпадающие ранги).

По результатам экспертного опроса построена табл. 1.3, где через хij обозначен ранг (целое число от 1 до п), присвоенный i-м экспертом j-му свойству.

Таблица 1.3.

Результаты экспертного опроса

Дальнейшая обработка результатов опроса с целью получения оценок коэффициентов важности свойств включает в себя:

приведение ранжировок экспертов к нормализованному виду (в случае совпадающих рангов). При этом свойствам, имеющим в ранжировке какого-либо эксперта одинаковые ранги, приписывается ранг, равный среднему значению номеров мест, занимаемых этими свойствами в ранжировке. Например, ранжировка: 2; 1; 2; 3; 4 (n=5) преобразуется в 2,5; 1; 2,5; 4; 5. Отметим, что сумма рангов после нормализации ран­жировки

S приобретает наибольшее значение, когда ранжировки всех экспертов одинаковы, и значение, близкое к нулю, когда одинаковы суммарные ран­ги свойств (т. е. эксперты ставят ранги случайно). Знаменатель выраже­ния (4.21) — это максимальное значение S, имеющее место при совпаде­нии ранжировок. Таким образом коэффициент k0 принимает значение от 0 до 1.

В знаменателе выражения (4.21) вычитаемое - это поправка к макси­мальному значению S, введение которой необходимо при наличии совпа­дающих рангов:

где tmi — число повторений μ-го ранга ранжировки i-ro эксперта;

проверку значимости коэффициента конкордации, т. е. гипотезы о том, что эксперты проставляют свои ранги случайным образом и, следователь­но, нет никакой согласованности в их мнениях. Идея проверки состоит в том, что при случайном присвоении рангов коэффициент конкордации принимает случайные значения, причем закон распределения k0 (S или ка­кой-либо иной, связанной с этими величинами статистики) может быть найден при всяких п и т в результате перебора всех возможных и равнове­роятных результатов ранжирования (если не допускать совпадения рангов в ранжировках каждого эксперта, то число равновероятных вариантов результатов опроса составит (n!)m).

При различных сочетаниях от m и n предложены способы проверки зна­чимости согласия [7]. В частности, при больших п и т (п >20 и m≥13) статистика X

имеет распределение близкое к χ2 с числом степеней свободы v=n-1.

Для проверки значимости коэффициента конкордации необходи­мо:

q  рассчитать значение статистики X;

q  задаться уровнем значимости α;

q  в таблице χ2 — распределения найти квантиль порядка 1-α при
v=n-1 степенях свободы;

q  сопоставить полученное значение статистики X и : если X >, то гипотеза о случайной простановке рангов отклоняется и коэффициент конкордации считается значимым.

Если коэффициент конкордации оказывается незначимым, то сле­дует вернуться к организации опроса экспертов: изменить их состав, использовать процедуру с заочным обменом мнений (метод ДЕЛЬФЫ) и т. д. [7].

Вычисления коэффициентов важности свойств можно осуществить различными способами [7]. Наиболее простые из них основаны на том, что о важности свойств содержится информация в суммарных рангах хj: Чем выше важность свойства, тем большее число экспертов будут ста­вить его на первые места в ранжировках, влияя тем самым на суммарный ранг.

Коэффициент важности р. при этом

где j=1,2,...,n; xj — суммарный ранг j-ого свойства (см. формулу 4.20); знаменатель - сумма суммарных рангов (сумма всех элементов таблицы ранжировок).

Коэффициент βj меняется от 0 до 1, большие значения свидетельствуют о большей важности свойства.

1.6.4. Пример оценки важности свойств аппаратуры1)

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

Для определения коэффициентов важности перечисленных шести свойств (n=6) экспертам было предложено проранжировать свойства по их важности при выборе типа аппаратуры считывания. Ранжировки экспер­тов т=13 приведены в таблице 1.4.

Рассмотрим этапы вычисления согласно разделу 1.6.3.

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

Суммарные ранги [формула (4.20)] приведены в таблице 1.4.

На основании данных табл. 1.4 рассчитываем .

Коэффициент конкордации (все Ti =0 в виду отсутствия совпадающих рангов):

Значимость коэффициента конкордации проверим приближенно, пользуясь статистикой Х [см. выражение (4.24)]:

Примем α=0,05. Из табл. χ2 - распределения [9] находим при v=n-1=5

Так как X=23,4 > χ2=11,07, то коэффициент конкордации следует считать значимым.

Таблица 1.4.

Таблица ранжировок примера (см. п. 1.6.4)

Коэффициенты важности найдем по формуле (4.25):

1.6.5. Оценка вариантов решения по каждой характеристике (свойству)

Эта задача может быть решена таким же способом, как и оценка важности свойств (см. п. 1.6.3.) с применением ранжирования вариан­тов решения по каждой характеристике, обработки ранжировок экспертов, вычисления коэффициентов важности вариантов. При этом коэффициенты важности находятся по каждой характеристике, т. е. процедура осуществляется столько раз, сколько свойств выбрано для при­нятия решения.

Иногда для оценки вариантов технологий по каждой характеристике используется следующая шкала оценок: отлично, очень хорошо, хорошо, приемлемо, слабо, неприемлемо. Наименованиям этой шкалы для исполь­зования в процедуре выбора необходимо ставить в соответствие некото­рые значения, например оценке «отлично» может соответствовать 1, «очень хорошо» — 0,75, «хорошо» — 0,625, «приемлемо» — 0,5, «слабо» — 0,25, «неприемлемо» — 0.

1.6.6. Оценка коэффициентов предпочтительности (важности) вариантов решения

Пусть имеется п свойств (характеристик) вариантов и значения βj, j=1,2,...,n коэффициентов важности свойств.

Выбор осуществляется из N вариантов, для каждого μ-го из которых имеется оценка γjμ степени обладания j-м свойством (важности μ-го вари­анта по j-му свойству). Тогда можно рассчитать коэффициент предпочти­тельности γμ (важности) μ-го варианта по формуле

Наиболее предпочтителен вариант с наибольшим значением γμ. Рассмотрим пример выбора СУБД при создании информационной системы по совокупности 14-ти характеристик, приведенных в табл. 1.5, в которой указаны коэффициенты важности характеристик βj, j=1,2,...,14 и оценки трех (N=3) СУБД по каждой характеристике (от­лично — 1, очень хорошо — 0,75, хорошо — 0,625, приемлемо — 0,5, слабо — 0,25).

Проводя расчеты γμ, μ=1 ,2,3, по формуле (4.26), получим

γ1 = 0,08Ч0,625+0,08Ч0,625+0,03Ч0,025+0,14Ч1+0,11Ч0,625+0,08Ч0,75+

+0,08Ч0,5+0,05Ч0,625+0,06Ч0,75+0,06Ч0,75+0,05Ч0,625+0,05Ч0,5+

+0,05Ч0,5+0,08Ч0,625 = 0,6688

γ2 = 0,08Ч0,625+0,08Ч0,5+0,03Ч0,625+0,14Ч0,75+0,11Ч0,75+0,08Ч0,625+

+0,08Ч0,625+0,05Ч0,5+0,06Ч0,5+0,06Ч0,625+0,05Ч0,75+0,05Ч0,625+

+0,05Ч0,625+0,08Ч0,75 = 0,6448

γ3 = 0,08Ч1+0,08Ч0,5+0,03Ч1+0,14Ч1+0,11Ч0,75+0,08Ч1+0,08Ч0,75+

+0,05Ч1+0,06Ч0,25+0,06Ч0,5+0,05Ч0,5+0,05Ч0,625+0,05Ч0,625+

+0,08Ч0,75 = 0,755

Таблица 1.5

Выбор типа СУБД

Таким образом, лучший вариант в данном случае — СУБД под номе­ром 3.

1.7. CASE-технологии проектирования программного обеспечения информационных систем

1.7.1. Назначение CASE-технологий

Аббревиатуре CASE (Computer-aided Software Engineering) может быть поставлен в соответствие следующий перевод — автоматизированная разработка программного обеспечения.

CASE - технология — это совокупность методов анализа, проектирова­ния, разработки и сопровождения сложных систем программного обеспе­чения, поддерживаемых комплексом взаимосвязанных средств автомати­зации [18].

Для реализации CASE-технологий создаются CASE-средства — инст­рументарий для разработчиков и программистов, позволяющий автомати­зировать процесс проектирования и разработки программного обеспече­ния.

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

При описании CASE-технологий используется понятие жизненный цикл (ЖЦ) программного обеспечения, который состоит из последовательнос­тей состояний ПО, начиная от момента возникновения необходимости в данном программном продукте до момента его полного выхода из упот­ребления. Обычно выделяют следующие этапы ЖЦ ПО [18]: анализ тре­бований, проектирование, программирование (разработка), тестирова­ние и отладка, эксплуатация и сопровождение.

Анализ требований выделяется в отдельный этап, т. е. этой проблеме придается важное значение при создании программных продуктов. Считается, что именно здесь лежит ключ к успеху разработки [18]. На этом этапе дается ответ на вопрос, что должна делать создаваемая система, т. е. каковы ее функции, условия их выполнения, особенности взаимодействия с пользователями и другими системами. Безусловно, что этот этап основан на творческой работе разработчика (системного аналитика). CASE - технология должна помочь ему четко представить все особенности создаваемой системы и также четко и однозначно выразить требования к ней.

Наибольшее распространение получили следующие две модели ЖЦ [19]:

каскадная модель;

спиральная модель.

В случае каскадной модели переход к следующему этапу ЖЦ происхо­дит только после того, как будет полностью завершена работа на предыду­щем.

Положительные стороны каскадного подхода заключаются в том, что [19]:

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

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

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

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

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

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

В жизненном цикле ПО этапы проектирования и программирования разделены (в п. 1.2 программирование являлось одной из стадий проекти­рования). Такое разделение связано с тем, что при четком изложении того, что и как должна делать система, процесс написания программы (кодиро­вания) может быть автоматизирован (частично или полностью). Поэтому особое значение приобретает именно этап проектирования, где требуется творческое участие разработчика.

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4