Создание средств параметризации методов разработки и сопровождения для управления жизненным циклом программного обеспечения тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат наук Лысов Дмитрий Вячеславович

• Лысов Дмитрий Вячеславович
• кандидат наук
• 2020

Оглавление диссертации кандидат наук Лысов Дмитрий Вячеславович

Введение

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

1.1. Проблемы преобразование программы для объединения нескольких последовательных циклов в один

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

1.3. Изменение требований к программному обеспечению

1.4. Использование искусственных нейронных сетей

1.5. Программные инженерные модели, модельные системы

1.6. Метрика и измерения в области программного обеспечения

1.7. Жизненный цикл изделия и РЬМ-системы

1.8. Цель и задачи исследования

2. Разработка средств объединения циклов, обеспечивающих темпоральную эквивалентность результата преобразования

2.1. Целевой язык

2.2. Объединение циклов

2.3. «Предположить и Допустить» для обращения цикла

2.4. Эксперименты

2.5. Выводы

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

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

3.2. Проектирование и анализ надежности программного обеспечения

3.3. Пример БИШМ

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

3.5. Предварительная оценка стоимости ИТр

3.6. Выводы

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

4.1. Управление количественным выходом улучшенных методов

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

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

4.3. Разработка модуля создания операций в системе Теашсейег

4.4. Тестирование разработанного программного модуля

4.5. Выводы

Заключение

Список литературы

Введение

Введение диссертации (часть автореферата) на тему «Создание средств параметризации методов разработки и сопровождения для управления жизненным циклом программного обеспечения»

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

совершенствования технологий исследования жизненного цикла программного обеспечения в части разработки, верификации программ и управления проектами их создания является комплекс задач, связанных с различными фазами жизненного цикла. Начиная с процесса создания кода и его оптимизации возникают проблемы управления преобразованием программы для объединения нескольких последовательных петель в одну, что полезно для процедуры верификации, потому что может упростить инварианты цикла. Предлагается использование подхода «предположи и допусти» (в дополнение к первому шагу (предположи), последние два шага могут быть выражены псевдоинструкцией «допусти», которая используется в проверке программы). По сути такой подход является первым шагом к параметризации процесса разработки и развивает работы таких исследователей, как Жданов Д., Рыбальченко А., Штейнберг О., Alberti F., Bruttomesso R., Brockschmidt M., Cohen E.

Следующий этап параметризации в рамках жизненного цикла -анализ надежности иерархической структуры программного обеспечения. Шесть этапов IEEE Standard for Developing Software Life Cycle Processes требуют создания единых механизмов формирования и исследования иерархической структуры надежности программного обеспечения, улучшающих локализацию ошибок непосредственно в соответствующем модуле. Ряд исследователей, среди которых Данилов А. Д., Мирзомудинова Р., Рыков В., Batory D., Backstrom O., Schultz D.6 Zou B. создали теоретическую базу в данном направлении, однако вопросы параметризации иерархической структуры в плане идентификации внутренней структуры программного обеспечения и генерации диаграммы потоков данных для анализа надежности однопоточного программного обеспечения остались исследованными неполностью.

Наконец, большой вклад в совершенствование средств математического и программного обеспечения распределения и прогнозирования изменений требований в жизненном цикле программного обеспечения внесли Грекул В., Зараменских Е., Boehm B., Crnkovic I., Krasner H., Zowghi D. и другие. Однако большинство полученных результатов исследований в данной области не в полной мере учитывают необходимость улучшения количественного и нормативного представления для управления проектами разработки.

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

Работа выполнена в ФГБОУ ВО «Воронежский государственный технический университет» в рамках одного из основных научных направлений «Вычислительные комплексы и проблемно-ориентированные системы управления».

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

Для достижения данной цели в диссертационной работе необходимо решить следующие задачи:

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

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

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

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

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

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

Объект исследования: методы разработки и сопровождения для управления жизненным циклом программного обеспечения.

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

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

принятия решений, методы верификации программ.

Тематика работы соответствует следующим пунктам паспорта специальности 05.13.11 «Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей»: п. 1 «Модели, методы и алгоритмы проектирования и анализа программ и программных систем, их эквивалентных преобразований, верификации и тестирования», п. 2 «Языки программирования и системы программирования, семантика программ», п. 10 «Оценка качества, стандартизация и сопровождение программных систем».

Научная новизна. В работе получены следующие результаты, отличающиеся научной новизной:

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

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

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

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

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

Положения, выносимые на защиту:

1. Операционная семантика процедуры объединения циклов, основанная на методе «предположения и допущения» для парных

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

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

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

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

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

Реализация и внедрение результатов работы. Основные положения и результаты диссертационной работы реализованы в виде специального программного модуля и нашли практическое применение в работе ПАО «Воронежское акционерное самолетостроительное Общество» для совершенствования систем управления жизненным циклом программного обеспечения. Результаты внедрены в учебный процесс Воронежского государственного технического университета в рамках дисциплин «Объектно-ориентированное программирование», «Технологии разработки программного обеспечения» профиля «Программное обеспечение автоматизированных систем» направления 09.03.01 «Информатика и вычислительная техника».

Апробация результатов диссертационного исследования. Основные положения диссертационной работы докладывались и обсуждались на следующих конференциях: V Международная НПК «Системы управления жизненным циклом изделий авиационной техники: актуальные проблемы, исследования, опыт внедрения и перспективы развития» (Ульяновск, 2016); Международная НПК «Новые технологии в научных исследованиях, проектировании, управлении, производстве» (Воронеж, 2017); XIX Международная НПК «Информатика: проблемы, методология, технологии» (Воронеж, 2019), на научных семинарах кафедры компьютерных интеллектуальных технологий проектирования ВГТУ (Воронеж, 2017-2020).

Публикации. По результатам диссертационного исследования

опубликовано 10 печатных работ, в т.ч. 3 статьи в изданиях, рекомендованных ВАК РФ, свидетельство о государственной регистрации программы, а также статья в журнале, индексируемом в международной базе цитирования Scopus. В работах, опубликованных в соавторстве и приведенных в автореферате, лично автором получены следующие результаты: [3] - операционная семантика процедуры объединения циклов, основанная на методе «предположения и допущения»; модель преобразования обращения цикла, основанная на методе «предположения и допущения»; [6, 8, 9] - эвристическая модель иерархической структуры надежности программного обеспечения, основанная на потоковой сетевой модели; [7] - алгоритм распределения и прогнозирования изменений требований в жизненном цикле программного обеспечения; [1, 5] -структурная модель взаимодействия элементов программного обеспечения в составе системы управления жизненным циклом.

Достоверность результатов обусловлена корректным использованием теоретических методов исследования и подтверждена результатами вычислительных экспериментов и внедрения.

Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения и списка литературы. Работа изложена на 140 страницах машинописного текста, включает 53 рисунка, 23 таблицы. Список литературы включает 141 наименование.

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

1.1. Проблемы преобразование программы для объединения нескольких последовательных циклов в один

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

Формализован цикл слияния для простого императивного языка и доказано, что это сохраняет частичную корректность. Далее техника «предположи и допусти» распространена на обратное выполнение цикла, что полезно для проверки определенного типа последовательных петель. Наконец, экспериментально подтверждено, что методы преобразования действительно корректны для проверки нескольких небольших программ.

Объединение циклов [2, 10] - это преобразование программы для слияния нескольких последовательных циклов в один. Например, следующий код С

far (i = Й; i < п; i++) { sumí += i; }

for (i = Й; i < n; i + O í sum2 += i; }

преобразуется в

far (i = в; i < n; i++) { sumí += i; sun2 += i;

}

с помощью объединения циклов. Хотя объединение циклов изучалось в

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

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

void sample_ei tint n) { int sumí = 8d sum2 = 0; in t i ;

for (i = 0; i < n; i++) { sum 1 += i; } for (i = 0; i < n; i++) { sum2 += i; } assert (suml == sum2);

}

Легко видеть, что утверждение в конце всегда верно для любого аргумента n, но на самом деле статическому верификатору программ это трудно доказать. Фактически, таким современным средствам верификации моделей программного обеспечения, как CPAchecker [4] и SeaHorn [14] не удалось верифицировать эту функцию за 900 с в экспериментальной среде. Возможно это произошло потому, что инварианты цикла для доказательства утверждения включают нелинейную арифметику:

í л\\

л (i < n) л (sum2 = 0) для первого цикла и

suml = ———

è

Í w\

suml =

n(n -1) ö .. N . „ i(i - 1Y ^

л (i < n) л (sum2 = 2 ) ^я второго цикла. С другой

V ^ У

стороны, если заменить два цикла одним объединённым

void sample_01 _fusEdС int п) { int suml = 0, sum 2 = 0; int i ;

for (i = 0; i < п; i++) { suml +- i; sumí +- i;

}

assert fsuml == sum2);

}

то станет ясно, что есть более простой инвариант цикла sum1=sum2, а CPAchecker и SeaHorn успешно доказывают отсутствие ошибки утверждения в течение нескольких секунд...

Тем не менее, применимость стандартных методов для объединения циклов довольно ограничена. Например, объединение циклов в [2] требует выполнения следующих двух условий для сохранения семантики

программы:

1. Два цикла имеют одинаковые границы цикла.

2. Тело первого цикла не зависит от тела второго.

Таким образом, следующие два цикла, в которых одинаковая переменная sum обновляется, не удовлетворяют условию выше и поэтому не могут быть объединены.

for (i = 0; i < n; i++) { sum += i; } for (i = 0; i < n; i++) { sum -= i; }

На самом деле, прямое применение объединения циклов к этим циклам сохраняет семантику, и средства верификации моделей могли бы верифицировать объединённый цикл. Конечно, в целом это не так.

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

void sample_02(int п) { int s um = В■ int i;

for (i = 0; i < n; i++) £ sum += i; } for (i = 0; i < n; i++) { sum -= i; } assErt (sum == 0);

}

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

irt sum = В; int sum2 = 0; int i;

for (i = 0; i < n; i++) { sum += i; } /* (X) *f

for (i = 0; i < n; i++) { sum2 -= i; } assert(sum == 0);

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

Чтобы восстановить это соотношение между двумя циклами, вводится переменная sum_middle, чтобы представить значение sum, когда

управление доходит до строки (X).

int sum = 0; int sum2; iilt i;

for £i=0; i < n; i++) £ sum += i; } assuniE ( sum_middle == sum); sum2 = sum_nii ddle ; t* (¥) */

for (i = 0; i < n; i++) { sum2 -= i; } sum = sum2; assErtfsum = = 0);

Назовем эту программу Q. Предположим, что можно каким-то образом предсказать значение sum_middle до начала выполнения Q. Тогда безопасность Q (отсутствие отказа assert) подразумевает безопасность P, потому что:

• значения sum и sum2 в строке (Y) равны sum_middle (благодаря прогнозу);

• значение sum2 копируется в sum перед выполнением assert(sum==0).

Здесь оператор assume(sum==sum_middle) работает как холостая команда, если выполняется sum=sum_middle; он расходится, если sum=sum_middle не выполняется и поэтому выполнение не продолжается. Эта команда используется, например, в Boogie [3] для выражения допущений, используемых при верификации в качестве программы.

Последняя проблема заключается в том, как предсказать значение sum_middle в начале. Для верификации безопасности, которая является целью, оказалось, что достаточно предположения значения:

int sum_middle = havoc Q;

int sum = 0 я sun2 = sum_iniddle d i;

for (i = 0; i < n-t i++) £ sum += i; }

for (i = 0; i < n; i++) £ sum2 -- i; }

assume£sum == sum_middle);

sum = sumZ;

assert(sum == 0);

Команда havoc() недетерминированно выбирает значение и возвращает его. Опущен ниже оператор assume, который не использует sum2, поднят sum2 = sum_middle, который не использует sum. Поскольку два цикла в программе теперь удовлетворяют условиям объединения циклов, можно объединить эти циклы, чтобы получить следующую программу:

void sample_B2_fused(int n} { int sum_middle = havacQ; int sum = sum2 = sum.niddle, i; for С i = 0; i < n ; i ++) { sum += i; sum2 -= i;

}

assumefsum == sum_middle); sum = sum2; assert(sum == 0);

}

Результирующая программа сначала предполагает значение sum в строке (X) в P, выполняет программу, а затем допускает, что предположенное значение действительно является правильным предположением, используя assume, чтобы исключить выполнение, которое невозможно в P. Основным вкладом исследования является формализация объединения циклов с использованием метода «предположения и допущения», доказательство его обоснованности при верификации безопасности и эмпирическая демонстрация его полезности.

При этом результирующая программа sample_02_fused не совсем семантически эквивалентна исходной программе sample_02: если предполагаемое значение sum_middle отличается от фактического значения sum в середине двух циклов исходной программы, то функция sample_02_fused расходится, тогда как sample_02 всегда завершается. Это различие, однако, не является проблематичным в этом случае, поскольку основная цель - верификация безопасности, которая является частичной корректностью, и, следовательно, для преобразования требуется только эквивалентность до момента завершения.

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

irt suml = В, sum2 = 0;

for {i = 03 i < n; i ++) { suml += i; }

for (i = 0; i < n; i++) { sum2 += n - i - 1; }

assert (suml == sum2);

Для этой программы нормальное объединение циклов менее эффективно, поскольку инвариант для объединённого цикла не очень прост. Проверено, что объединённая программа не может быть верифицирована в течение 900 с с помощью CPAchecker или SeaHorn. Однако, если изменить на обратное направление итераций второго цикла перед объединением и применить простое преобразование постобработки, то объединенная программа может быть верифицирована примерно за 20

секунд (CPAchecker) или за менее, чем секунду (SeaHorn).

Таким образом:

• Формализуется объединение циклов, применимость которого менее ограничена, чем методы, предлагавшиеся до сих пор. Преобразование основывается на новом методе «предположения и допущения». Несмотря на то, что программа, созданная в результате данного преобразования, эквивалентна исходной только до момента завершения, это преобразование во многих случаях полезно для ускорения статической верификации частичной корректности. Показана корректность преобразования.

• Предлагается преобразование обращения цикла, основанное на методе «предположения и допущения». Оно преобразовывает один цикл в другой, итерационное поведение которого является обращением исходного поведения. Показана корректность и этих преобразований.

• Реализованы предложенные два алгоритма и проведены эксперименты с использованием современных статических верификаторов программ - CPAchecker и SeaHorn. Осуществлено сравнение их производительности на программах, которые содержат последовательные циклы, корректность которых эти верификаторы не способны доказать и на программах, которые были предобработаны с использованием предложенного преобразования. Во многих случаях наблюдается улучшение производительности.

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

В программной инженерии жизненный цикл программного обеспечения (SLC) означает специфичную для проекта последовательность действий, которая создается путем сопоставления действий данного стандарта (IEEE Standard for Developing Software Life Cycle Processes) с выбранной моделью жизненного цикла программного обеспечения (SLCM) [1]. Другими словами, проектное отображение последовательностей задач (любая крупная сложная система делится на задачи или группы связанных задач) в прогрессивной эволюции от стадии концепции к стадии выхода на пенсию будет использоваться инженерами для создания программного обеспечения и выполнения их задач [2].

Стандарт IEEE [3] разделил SLC на шесть этапов:

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

б) стадия разработки, чтобы разработать систему интересов, отвечающую требованиям заинтересованных сторон, и система интересов может быть прототипом на этой стадии;

в) стадия производства, чтобы произвести интересующую систему, которая может подвергнуться усовершенствованию или перепроектированию;

d) стадия использования, чтобы эксплуатировать продукт и предоставлять устойчивые эксплуатационные услуги;

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

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

Международный стандарт ISO [4] демонстрирует, что программная система может быть иерархической и состоять из набора взаимодействующих элементов системы. Системный элемент реализуется для выполнения соответствующих заданных требований. Как сложная система, для осуществления быстрого анализа элемент системы можно рассматривать как систему.

Иерархическое моделирование используется практически во всех областях для содействия прогрессу анализа сложной системы. В работе [5] предложена функциональная модель, основанная на иерархическом подходе моделирования в программно--определяемых системах. Выделено два подхода к проектированию системы: подход сверху вниз, который называется подходом общей функции, и подход снизу вверх, который называется подходом общего оператора. Системы [5] могут состоять из 3 уровней иерархии. Уровень 1 является узлом для 3 кластеров, Уровень 2 выделяет несколько менеджеров конфигурации для каждого аппаратного компонента, а Уровень 3 означает, что каждый менеджер конфигурации отвечает за компонент обработки.

Кроме того, в области анализа надежности программного обеспечения USES-связь использования представлена в [6], чтобы продемонстрировать методику оценки надежности иерархической программной системы. USES-связь определяется по формуле USES(Mi,Mj). USES-связь устанавливается модулем Mi, вызывающим модуль Mj, а Mj определяет успех и неудачу Mi. Метод USES присваивает модулям уровни иерархии по следующим правилам:

Список литературы диссертационного исследования кандидат наук Лысов Дмитрий Вячеславович, 2020 год

/ Л

О

Subsystem level

Nodes

Relationship

Attributes

О

Unit level

Detailed Code

ir{(Uoolcaii)Cwli:^jstuiguish.h6sEachNDdcLiuio<lcli|[n]){ nodes.BraceKeyword.Add("!"):

It HmrJnodcs.NodelicadEnodc] = i" I &&{intlnodcs.Nodciiclongto|[KHici = n + I) (

I

node] kisp:itti[i] 1 iiodcpalh[nodc|:

)

else I )

Рис. 3.5. Пример уровней программного модуля автоматического моделирования в SLC

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

Code level

3.3.2. Проектирование и анализ надежности программного обеспечения

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

Как показано в табл. 3.4, согласно рис. 3.5, есть четыре субмодуля на уровне 1, и в работе рассмотрим модуль узлов как частный случай для дальнейшего проектирования и анализа. Если предположить, что каждому модулю гипотезы известны интегральные показатели надежности и отказоустойчивости, то выделенные значения надежности и времени тестирования программного обеспечения можно рассчитать по формулам (3.13)-(3.15).

Таблица 4

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

обеспечения

Уровень Гипотеза интегрированной готовности 0.999999

1 (Система) Модуль Код Ключи Узлы Интерфейс

Время 33 33 33 33

испытания

Показатели 0.2 0.2 0.2 0.3

отказов

Распределение 0.9999997488 0.9999997488 0.9999997488 0.9999999999

Общая 0.9999992463

надежность

Гипотеза интегрированной готовности 0.9999997488

2 (Узлы) Модуль Атрибуты Отношения

Время 33 33

испытания

Показатели 0.4 0.2

отказов

Распределение 0.9999999999 0.9999997488

Общая 0.9999997488

надежность

В соответствии с этапами анализа БКИБЫ, когда распределение надежности программного обеспечения соответствует заданным стандартным значениям, это распределение удовлетворяет требованиям. В

противном случае программное обеспечение должно быть перераспределено и переработано. В этом случае любой модуль серии имеет равное время тестирования. Например, в модуле кода время успешного тестирования равно 33, а метрика отказа принимается равной 0,2, таким образом, надежность этого модуля равна 0,9999997488. Надежность подуровня должна соответствовать родительскому уровню, при этом гипотеза интегральной надежности узлов уровня равна 0,9999997488.

Для того чтобы соответствовать конкретным требованиям, программное обеспечение должно быть протестировано более 33 раз, то есть каждый модуль должен быть протестирован более 33 раз на уровне 1. Пользователи могут корректировать время тестирования и показатели отказов в соответствии с вероятностью распределения. Как только вероятность распределения определена, результат оценки надежности программного обеспечения должен соответствовать этому значению, чтобы гарантировать надежность этого программного обеспечения.

3.3.3. Доверительный интервал надежности программного обеспечения

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

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

X • К(т,а2) (3.16)

где ц - среднее значение показателей сбоя программного обеспечения, известная величина; а - дисперсия показателей сбоя программного обеспечения. Следовательно, статистика такова:

Т = • 1(п -1) (3.17)

где Б - выборочная дисперсия, подчиняющаяся распределению 1

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

т - "Г1 а/2(п - 1),т '1 а/2(п - 1)

•ч/п \!п

(3.18)

Как показано в табл. 3.5, существует 20 выборок, приведенных 20 экспертами, и предположим, что уровень значимости а=0,05. Показатели сбоя программного обеспечения и доверительный интервал могут быть рассчитаны:

показатель отказов т=0,46

доверительный уровень: [0.362629, 0.557371]

20 решений, предоставленных 20 экспертами

Таблица 3.5

Номер m Номер m

1 0.8 11 0.4

2 0.2 12 0.6

3 0.5 13 0.6

4 0.2 14 0.7

5 0.3 15 0.2

6 0.5 16 0.5

7 0.7 17 0.3

8 0.7 18 0.6

9 0.2 19 0.3

10 0.7 20 0.2

Предположим, что только при рассмотрении одного сценария входной области связь между метриками сбоя программного обеспечения и вероятностью сбоя программного обеспечения показана на рис. 6. Значение верхнего доверительного предела составляет 0,557371, значение нижнего доверительного предела - 0,362629. Вероятность сбоя программного обеспечения уменьшается по мере увеличения числа тестов и имеет тенденцию к стабильному значению.

0.5

(failure)

—Upper Confidence Limits —Average Lower Confidence Limits

test times (h)

0 1 2 4 6 8 10 12 14 16 18 20 Рис. 3.6. Доверительный интервал на уровне 95%

22 24

Доверие программного обеспечения вероятности отказа тренда между верхней и нижней границы доверительного интервала доверительный интервал составляет 95%. Следовательно, если вероятность отказа верхних доверительных пределов соответствует требованиям надежности (например, вероятность отказа должна быть ниже 10-6), то существует 97,5%-я вероятность того, что эта тенденция верна. При достаточном количестве тестов показатель коэффициента отказоустойчивости не может повлиять на конечные результаты

надежности программного обеспечения.

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

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

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

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

Вообще говоря, ЯБ - это метод реализации анализа требований. Анализ требований относится к преобразованию не сформулированных заявлений о требованиях в подробное определение требований, даже превращая их в спецификацию требований. Разработка программного обеспечения - это динамичный процесс. Это часто приводит к изменению требований к программному обеспечению в процессе разработки. Хотя существует множество эффективных и применимых методов, инструментов и методов, используемых для сбора и управления

требованиями [51-53], требования к программному обеспечению неизбежно меняются в процессе разработки и обслуживания системы. Эти изменения обусловлены несколькими факторами, включая сложность системы, методы, требования рынка и государственное регулирование [54]. Изменение требований делает настолько трудным оценку графика и стоимости проекта, что качество продукта не поддается контролю, и ставит перед проектом большие проблемы [55-57]. Как следствие, необходимо определить лучший подход к управлению воздействиями постоянно меняющихся требований. Достаточные измерения и точный прогноз являются наиболее важными шагами на пути к лучшему и эффективному управлению изменениями требований.

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

3.4.1. Прогнозирование изменений требований

Факторы изменения требований

Побуждения ИТр различны, которые включают ряд факторов, таких как технология, управление, рабочая среда и психология науки. Анализ факторов, вызывающих изменение требований, является эффективной мерой для предотвращения изменений, особенно хороших для прогнозирования частоты и распределения ИТр. Так называемая частота ИТр - это отношение количества ИТр к общему количеству требований. Есть много исследований, связанных с причинно-следственной связью. Один стиль использует статистический анализ из запроса на изменение (СЯ) [71] систем на практике [56]. Другой получает основные факторы в результате разговора или опроса разработчиков или руководителей проектов [60]. Главная задача - учесть те факторы, которые приводят к изменению частоты ИТр, но причины изменения распределения ИТр имеют отношение к причинно-следственной связи ИТр. Основываясь на выводах [54,56,58,59,60,64,72], определим особенности, связанные с изменением частоты и распределения ИТр, по отношению к четырем основным факторам:

• характер проекта,

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

• состояние пользователей,

• управление проектом.

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

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

Характер проекта

Основной особенностью исследуемого программного проекта является его максимальный размер. Он часто характеризуется количеством строк кода, размером исходных файлов и так далее. Будем использовать прогнозируемое количество подсистем (также называемых модулями) для измерения проекта. Результат прогноза является очень надежным, потому что изменение количества основных функциональных модулей редко случается после завершения анализа требований. В целом коэффициент сложности увеличивается с увеличением количества модулей. Следующей особенностью является количество сотрудников. Обычно в одной подсистеме может участвовать около трех человек, но степень детализации можно регулировать в соответствии с практической ситуацией. Если количество участников в модуле больше или меньше среднего, коэффициент сложности будет увеличиваться. Предположим, что общее число людей, вовлеченных в проект, равно Р, а число прогнозируемых подсистем - М, тогда можно использовать формулу |Р/М-3|, чтобы рассчитать сложность. Объем доступного бюджета (особенно на этапе анализа требований) также является одним из факторов, влияющих на проект. Чем более обеспечена достаточная стоимость, тем ниже коэффициент сложности. Кроме того, методы, применяемые в проекте, и методы риска также влияют на ИТр, а также на накопление технологий в прошлом. Если система имеет предпочтительные ресурсы для повторного использования (например, исходные коды, проектные документы, опыт разработки и т.д.), это снизит риск ИТр.

Таблица 3.6.

Способ оценки характера проекта_

Параметр Коэфф. сложности Вес

<10 0.2

Число подсистем (модулей) 10~20 0.4

20~30 0.6 0.2

30~40 0.8

>40 1.0

Количество разработчиков 0.2, 0.4, 0.6, 0.8, 1.0 0.1

Бюджет проекта 0, 0.5, 1.0 0.05

Сложность и рискованность технологий 0, 0.5, 1.0 0.15

Возобновляемые ресурсы 0, 0.5, 1.0 0.2

Достаточность анализа требований 0.2, 0.4, 0.6, 0.8, 1.0 0.3

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

Учет особенностей разработчиков

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

1. Опыт разработчиков, т.е. возраст. Разработчики с большим опытом принимают на себя меньший риск ИТр.

2. Условие освоения подходов и инструментов развития. Если разработчики знакомы с подходами и инструментами, это поможет им более полно рассмотреть требования проекта.

3. Знание бизнеса.

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

5. Степень общения между разработчиками и пользователями. Это можно оценить с точки зрения времени проведения интервью и возможности взаимодействия. Плохое общение ведет к серьезным испытаниям для ИТр.

6. Внутренняя связь и сотрудничество в команде разработчиков.

Таблица 3.7

Рекомендации по оценке разработчиков__

Параметр Коэфф. сложности Вес

Опыт разработчиков 0.2, 0.4, 0.6, 0.8, 1.0 0.15

Знакомство с подходами и инструментами 0, 0.5, 1.0 0.1

Знание бизнеса 0.2, 0.4, 0.6, 0.8, 1.0 0.2

Тренинг по разработке проектов 0, 0.5, 1.0 0.1

Коммуникабельность 0.2, 0.4, 0.6, 0.8, 1.0 0.3

Внутренняя связь и сотрудничество 0.2, 0.4, 0.6, 0.8, 1.0 0.15

Учет особенностей пользователей

Влияние на распространение ИТр, вызванное пользователями, может быть классифицировано следующим образом:

1. Диапазон профессий и опыта работы. Достаточное понимание бизнеса выгодно для разработки программного обеспечения.

2. Четкость требований пользователей. Чем более явная цель имеется, тем более достаточен ранний анализ требований.

3. Внутреннее взаимодействие и согласованность требований. Когда будет достигнуто достаточное внутреннее взаимодействие и

согласованность требований, мы определяем коэффициент сложности как 0. В противном случае коэффициент равен 0,5 или 1,0.

4. Энтузиазм участников. Если пользователи против проекта, коэффициент сложности будет определен как 1,0.

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

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

Таблица 3.8.

Рекомендации по оценке пользователей

Параметр Коэфф. сложности Вес

Опыт работы 0.2, 0.4, 0.6, 0.8, 1.0 0.1

Четкость требований 0.2, 0.4, 0.6, 0.8, 1.0 0.25

Внутреннее взаимодействие и 0, 0.5, 1.0 0.2

согласованность требований

Энтузиазм участников 0, 0.5, 1.0 0.1

Степень владения компьютерными 0, 0.5, 1.0 0.05

технологиями

Удовлетворение первоначальными спецификациями 0.2, 0.4, 0.6, 0.8, 1.0 0.3

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

Таблица 3.9.

_Рекомендации по оценке управления проектами_

Параметр Коэфф. сложности Вес

Достаточность проверки потребностей 0.2, 0.4, 0.6, 0.8, 1.0 0.4

Настройка инструментов потребностей 0.2, 0.4, 0.6, 0.8, 1.0 0.2

Формализация документов потребностей 0.2, 0.4, 0.6, 0.8, 1.0 0.2

Управление конфигурацией для ИТр 0, 0.5, 1.0 0.1

Рациональность организации и управления 0.2, 0.4, 0.6, 0.8, 1.0 0.1

Табл. 3.9 предоставляет количественную основу для оценки факторов, которые будут влиять на частоту и распределение ИТр. Факторы и их подпункты могут быть скорректированы с учетом фактического положения организаций, занимающихся разработкой программного обеспечения. Эта структура представляет собой комбинацию существующих результатов исследований и нашего накопленного опыта в процессе разработки информационных систем. Более детальная структура оценки может быть построена с помощью корреляционного анализа, который представлен в [61]. Кроме того, метод корреляционного анализа

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

3.4.2. Метод прогнозирования изменений требований

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

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

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

• все анализируемые проекты не нащупывают, потому что проекты такого типа слишком неопределенны, чтобы делать рациональный прогноз.

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

Прогнозирование распределения ИТр на основе управления статистическим процессом

Исследование [62] показало, что:

1. Для организации программного обеспечения частота ИТр является относительно устойчивой величиной, когда его способность к процессу разработки программного обеспечения является зрелой.

2. Распределение ИТр имеет относительно устойчивое статистическое правило. Основываясь на исследованиях, можно принять метод прогнозирования ИТр следующим образом: во-первых, рассчитывается среднее значение цр частоты ИТр предыдущих проектов и устанавливается количество исходных потребностей как Nor, поэтому вероятное количество ИТр составляет Nmp=^PNor. Во-вторых, становятся известны распределенные пропорции ИТр на каждом этапе процессов разработки, т. е. проектирования, кодирования, тестирования и

обслуживания.

Как следствие, можно получить количество вероятных ИТр на каждом этапе. Этот подход прост в эксплуатации. Но возможности программных организаций постоянно обновляются, и раннее распространение не может хорошо отражать текущее состояние, т.е. этот подход относится к статическому прогнозированию. Улучшение заключается в использовании большинства последних данных для проведения статистического анализа. Будет представлен динамический и самоадаптирующийся подход к прогнозированию в следующем подразделе.

Прогнозирование ИТр на основе ИНС

Как показано ранее, четыре фактора играют решающую роль в распределении ИТр. Следовательно, необходимо представить количественную оценку этих факторов. В работе применяем метод ранжирования экспертов для их количественной оценки. Предположим, что значения риска, вытекающие из характера проекта (PC), состояния разработчика (DC), условия пользователя (UC) и управления проектом (PM), равны Vpc, Vdc, Vuc, Vpm соответственно. Процесс количественной оценки выглядит следующим образом: возьмем PC и предположим, что PC имеет n подпунктов, а вес каждого подпункта равен Wi (1<i<n). Мы выбираем из числа опытных разработчиков и администраторов проекта «главного эксперта». Матрица оценки R, соответствующая этому коэффициенту, может быть получена путем ранжирования каждого подпункта при ссылке на структуру оценки.

R =

41

а21

42

22

1m

2m

rii е [0,1], 1 < i < n, 1 < j < m

Ап1 ап2 пт

Затем, используя вес каждого подпункта, количественно РС можно представить следующим образом:

V

pc

1 n

=11

m ы

W

m j=1

(3.19)

Очевидно, что значение Урс находится между 0 и 1. Например, вероятный риск ИТр, вызванный фактором РС в проекте, описывается следующим образом:

R=

0.4 0.4 0.6 0.4 0.4

0.6 0.2 0.4 0.4 0.2

0 0 0 0.5 0

0.5 0.5 1.0 0.5 0.5

0.5 0.5 0.5 0 0.5

0.4 0.2 0.4 0.4 0.2

Тогда УрС=(0.2*2.2+0.1 *1.8+0.15*3+0.2*2+0.3*1.6)/5=0.395. Значения Уас, Уис и Урт также можно рассчитать по формуле (1). Большие значения представляют большую вероятность появления ИТр. Деятельность по оценке должна быть синхронной с разработкой проекта, т.е. требуется провести детальную оценку после заполнения документов спецификации требований. Когда проект завершен, можно скорректировать часть подпунктов, чтобы подготовить прогноз для следующего проекта.

Указанные значения оценки и Ког представлены в качестве входных данных ИНС, т.е.

Х=(Урс,Уас,Уис,УртЛоГ).

Выходные данные ИНС состоят из значений распределения ИТр на четырех этапах (проектирование, кодирование, тестирование и обслуживание). Обозначается следующим образом:

У^ад^т).

Выбрана сигмоидная функция в качестве отображения входного слоя на скрытый слой:

ед = 1/(1+е-х).

Линейная функция используется для отображения скрытого слоя на выходной слой. Прогнозирование распределения ИТр может быть выполнено в два этапа:

Шаг 1, этап обучения. Собираются соответствующие данные предыдущих проектов в качестве входных и выходных векторов соответственно, а затем обучается сеть.

Шаг 2, фаза прогнозирования. Когда ошибка сети сходится, данные текущего проекта (Урс,Уас,Уис,Урт^ог) помещаются в сеть, чтобы вычислить количество возможных ИТр на каждом этапе после анализа требований.

Весь процесс прогнозирования ИТр показан на рис. 3.8. Как видно из формулы (3.19), определение веса подпунктов очень важно. Различие весов подпунктов просто качественное, поэтому эвристическое назначение, как правило, неточно. Но можно использовать метод иерархий, который был использован для определения веса характеристик качества программного обеспечения в [73], чтобы взвешивать подпункты. Этот метод содержит проверку непротиворечивости, поэтому ошибка принятия решения находится на приемлемом уровне.

Существенным преимуществом подхода, основанного на ИНС, является способность к динамическому адаптивному обучению. Этот подход не только эффективно использует статистические правила распределения ИТр в архивных проектах, но также отражает повышение зрелости организации программного обеспечения. На рис. 3.8 показано, что это зависит от оценки разработчиков четырех факторов при разработке программного обеспечения. Как следствие, реализация этого подхода может ускорить количественное и нормативное представление для

управления проектами, что соответствует требованию уровня 4 [74].

Рис. 3.8. Структура прогнозирования с использованием ИНС для распределения ИТр

3.5. Предварительная оценка стоимости ИТр

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

3.5.1. Таксономия изменений требований

Существует несколько способов классификации ИТр [66], например, по причине ИТр, по происхождению изменения и т.д. В работе в основном исследуются типы изменений ИТр. Таксономия для классификации запросов на изменение заключается в следующем:

• добавление требования: добавление требования, чтобы восполнить упущение или удовлетворить требования клиентов;

• удаление требования: удаление или удаление существующих требований из стратегии бизнеса или избыточности требований;

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

Недостаточно предсказать стоимость ИТр только по распределению ИТр на каждом этапе. Также необходимо знать номер каждого типа ИТр. Способность ИНС прогнозировать зависит от обучения на исторических данных, поэтому важно получить номер ИТр трех типов, упомянутых выше на каждом этапе. С этим можно справиться при следующих двух условиях:

1. Если организация программного обеспечения внедряет хорошее управление ИТр на практике, число может быть получено из структуры анализа данных, упомянутой в [56].

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

Для этапа, следующего за анализом требований, такого как проектирование, кодирование, тестирование и т.д., Мы должны построить еще один ИНС для прогнозирования количества каждого типа ИТр. Входные данные такие же, как и в сети в разделе 3.2, в то время как выходные данные модифицируются в пропорции трех типов ИТр, то есть У=0аДаДт), где !а, и !т представляют скорость требования добавления, удаления и модификации соответственно, и !а+!а+1:т=1. Процесс прогнозирования также делится на два этапа, как указано выше. Число каждого типа может быть рассчитано путем ссылки на пропорции и общее число ИТр на этом этапе.

3.5.2. Модель предварительной оценки стоимости ИТр

В настоящее время существует множество моделей оценки стоимости программного обеспечения. Среди них широко распространены модели СОСОМО-11 [75] и ООМ/СООМ [76,77]. К сожалению, все они игнорируют стоимость, вызванную ИТр. В соответствии с классификацией ИТр применяем ИНС для прогнозирования количества каждого типа ИТр на каждом этапе соответственно, а затем предварительно оцениваем стоимость ИТр во всем жизненном цикле программного обеспечения. Общая стоимость ИТр (С) состоит из дополнительных затрат, вызванных ИТр на этапах проектирования (Са), кодирования (Сс), тестирования (С!) и

обслуживания (Cm), то есть C=Cd+Cc+Ct+Cm.

1. Cd: на этапе детального проектирования документы спецификации требований анализируются и классифицируются для составления детального плана реализации. Усилия по добавлению, удалению и изменению требований почти эквивалентны, поэтому нет необходимости различать их. В этом случае обозначаем дополнительную стоимость ИТр как а, поэтому стоимость ИТр на этапе проектирования

Cd=aNd (3.20)

2. Cc: в отличие от стадии проектирования, стоимость реализации добавления, удаления и модификации требований различна на этапе кодирования. Как правило, дополнительная стоимость модификации требования является самой большой, обозначаемой как pm. Стоимость добавления (pa) занимает второе место, наименьшей является стоимость удаления (pd), т.е. a<pd<pa<pm. Таким образом, стоимость ИТр на этапе кодирования может быть рассчитана по следующей формуле.

Cc = PataNc+PdtdNc+PmtmNc=(Pata+Pdtd+Pmtm)Nc (3.21)

3. Ct: аналогично этапу кодирования. Дополнительные затраты на каждое добавление, удаление и модификацию требований отмечаются как Ya, Yd и ym (Yd<Ya<Ym) соответственно, причем

Pa<Ya, Pd<Yd, Pm<Ym.

Следовательно,

Ct = (Y ata + Y dtd +gmtm)Nt (3.22)

4. Cm: техническое обслуживание является более сложным, чем три вышеуказанных этапа. В целом, только часть разработчиков проектов являются разработчиками, или даже они не являются разработчиками.

Когда происходят ИТр, важно понять, в каких частях требуются изменения. Используем подход, предложенный в [78], для количественной оценки степени понимания изменений. Это происходит в двух аспектах: «Понимание программного обеспечения» (SU) и «Незнакомость программиста» (UNFM). SU определяется по результатам самооценки сопровождающих документов и исходного кода. Каждый аспект делится на пять рангов (значение варьируется от 0,1 до 0,5). Чем выше значение, тем хуже понимание, и наоборот. Последнее значение SU является средним значением их оценок по обоим аспектам. Значение UNFM количественно выражено в табл. 3.10.

Разница между Cm и Ct - это просто прирост, порожденный SU и UNFM, потому что все модификации на этих двух этапах сделаны для законченной системы.

Cm = (Y ata + Y dt d + Y mtm )(1 + SU • UNFM)Nm (3.23)

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

Таблица 3.10.

UNFM Уровень компетентности

0.0 Полностью знаком

0.2 В основном знаком

0.4 Более-менее знаком

0.6 Мало знакомый

0.8 Практически незнакомый

1.0 Совершенно незнаком

3.5.3. Тематическое исследование

Чтобы проверить методы прогнозирования распределения и стоимости ИТр, было проведено тематическое исследование с данными проектов на объединении ВАСО за последние два года. Обзор шести выбранных проектов показан в табл. 3.11.

Таблица 3.11.

Характеристики проектов _

Проект Описание Средства разработки

ССЗ Система сетевой зарядки VC, PB, SQL Server

СУОРС Система управления образованием и работой студентов PB, JSP, EAServer, SQL

СУИТ Система управления инструментами и технологиями Server PB, .NET, SQL Server

С1111Р-О11 Система поддержки принятия решений в основном производстве .NET, PB, Oracle, Arcinfo

СУН Система управления недвижимостью Delphi, .NET, SQL Server

С1ШР-В11 Система поддержки принятия решений во вспомогательных производствах .NET, PB, Oracle, Arcinfo

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

При проверке метода прогнозирования распределения ИТр, данные из пяти предыдущих проектов были собраны для обучения сети ВР. Хотя сеть была стабильной, использовали ее для прогнозирования распределения ИТр проекта СУН. Эксперимент проводился в среде МаНаЬ

7.0 с сетью 5^35x4, параметры конфигурации которого были следующими: эпохи = 2x104, цель = 0,005, шт_§гаё = 1,0х10-10, ши_шах = 1,0x108. Поскольку начальное значение веса сети назначается случайным образом с помощью набора инструментов нейронной сети МаНаЬ, оно не может обеспечить сходимость ошибок при каждом обучении. Необходимо было убедиться, что ошибка принятой сети сходится. Следовательно, прогнозирующий результат: N^=11, N/=7, N^=9, N^=5. В отличие от табл. 3.12, очевидно, что распределение ИТр, предсказанное ИНС, является гораздо более точным.

Таблица 3.12.

Факторы ИТр и их распределение в проектах_

Проект Уре Уае Уис Урш ^ N0 ^ ^

ССЗ 0.402 0.470 0.255 0.550 45 2 3 2 1

СУОРС 0.775 0.652 0.780 0.412 372 34 22 28 21

СУИТ 0.560 0.640 0.725 0.605 295 20 13 29 24

С1111Р-О11 0.285 0.305 0.232 0.260 264 6 5 4 2

СУН 0.325 0.402 0.265 0.300 67 3 2 1 1

С1111Р-В11 0.395 0.255 0.385 0.300 281 12 9 8 4

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

3.6. Выводы

1. Предложен подход к моделированию иерархической структуры надежности программного обеспечения (БИБ^М) для проектирования и анализа надежности программного обеспечения в БЬС. С помощью этого метода проектировщик и разработчик программного обеспечения могут четко определить программную основу и осуществить быстрый анализ систем разработки программного обеспечения на любом этапе.

2. Метод БИБ^М основан на FNM, при этом анализ и оценка надежности программного обеспечения соответствуют FNM. Для оценки программной надежности программной системы был использован оригинал метода FNM. Пример использован для обоснования БИБ^М, включая анализ моделирования программного обеспечения, проектирование и анализ надежности программного обеспечения, а также расчет доверительного интервала надежности программного обеспечения.

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

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

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

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

6. Представлен метод ИНС, используемый для прогнозирования распределения ИТр. После прогнозирующего распределения, предлагается модель для оценки стоимости ИТр.

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

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

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

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

Изучение количественного выхода в жизненном цикле программного обеспечения при внедрении новых (улучшенных) методов разработки программного обеспечения является сложной проблемой, которую необходимо решать системно [79]. Соответствующие метрики и модели должны быть выбраны, и их взаимосвязи должны быть выражены формально, чтобы обнаружить возможные несоответствия или незавершенности. Определена модельная система, связанная с конкретным жизненным циклом программного продукта в виде совокупности моделей и взаимосвязей между ними. Шэтому модельная система будет содержать все взаимосвязи и ограничения между моделями и модельными элементами, содержащимися в разных моделях. Эта концепция использована в [79] для анализа нескольких аспектов разработки программного обеспечения, а также для выработки основы принятия решений для обоснования и принятия решений на основе стоимости в процессе разработки программного обеспечения [80].

Используем концепцию модельной системы для решения проблемы количественной оценки выходов новых (улучшенных) методов разработки программного обеспечения и предлагаем основанную на стоимости инфраструктуру (УР). УР влечет за собой применение взаимосвязанных

метрик и моделей из [81-85] для оценки соответствующих затрат, преимуществ, переведенных в управление и улучшение качества программного обеспечения, а также результирующих связанных с ценностями метрик, оцененных в течение жизненного цикла системы программного обеспечения. Эта структура применима на высоком уровне абстракции и предлагает полезные результаты с практической точки зрения, как показывает наш пример.

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

4.1.1. Конкретные показатели качества

Ориентируемся на следующие соответствующие метрики:

Плотность дефектов, (DD), измеряется количеством дефектов ND относительно размера программного обеспечения S, [дефекты / SLOC]:

DD = ND (4.1)

S

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

Эффективность устранения дефектов, (DRE) в [%] определяется как: DR

DRE =-*100,[%] (4.2)

DE + DI

где DR - количество удаленных дефектов;

DE - количество дефектов, унаследованных (существующих);

DI - количество введенных дефектов.

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

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

Модель устранения дефектов - DRM, [дефекты], определяется как:

DRM = DE + DI - DR (4.3)

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

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

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

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

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

Структура создается для формального метода проверки программного обеспечения (SIM) как один из наиболее часто используемых методов разработки программного обеспечения. SIM состоит из совещаний особого типа, которые проводятся для объективного

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

Формально SIM состоит из шести этапов:

1) Планирование (график, анонс, координата)

2) Обзор (общаться, обучать, учиться)

3) Подготовка (изучение, анализ, изучение)

4) Встреча (облегчить, определить, записать)

5) Переработка (поиск, ремонт, доработка)

6) Последующие действия (проверить, измерить, сообщить).

Конечным результатом применения этих формальных этапов

является переход от первоначального чернового варианта с предварительно заданным уровнем и продуктом с высоким уровнем дефектов к конечному базовому продукту с низким уровнем дефектов. Шесть этапов предназначены для: добавления стоимости, структуры, повторяемости, измеримости; оптимизировать количество выявленных дефектов, тем самым оптимизируя качество программного обеспечения.

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

Количественные модели для оценки затрат

Компоненты стоимости

CSIM = CD + CM + CI + CTR (4.4)

где:

• CSIM - полная стоимость при применении SIM

• CD - стоимость разработки программного обеспечения

• CM - стоимость обслуживания программного обеспечения

• CT - стоимость тестирования программного обеспечения

• CI - стоимость внедрения SIM

• CTR - стоимость обучения

Общая стоимость жизненного цикла

TLCSIM = (S*K -Tj *99-TTa *9)*c (4.5)

где:

• TLCSIM - общая стоимость жизненного цикла программного обеспечения, которая включает в себя затраты на разработку и обслуживание программного обеспечения и отражает влияние применения

моделей для оценки: плотность дефектов,

• S - расчетный размер программного обеспечения, [SLOC]

• K - среднее усилие по разработке и обслуживанию программного обеспечения в соответствии с SLOC [PH / SLOC], без использования формальных проверок или тестирования

• T - расчетное (плановое) время для проверок, [ч]

• TT,a - рассчитанное общее время для испытаний после применения инспекций, [H]

• c - стоимость труда в час [м.ч. / час], м.д. = денежные единицы

TLC основан на модели, предложенной в [85], и использует

экономику SIM, тестирование программного обеспечения и обслуживание программного обеспечения. Консервативные предположения заключаются в том, что дефект может быть исправлен в течение: 1 часа с использованием SIM-карты, 10 часов с использованием тестирования программного обеспечения и 100 часов с использованием обслуживания программного обеспечения. В [85] предлагается, чтобы K = 10,51 для современных программных систем среднего и среднего масштаба, но уравнение (4.5) может быть откалибровано в зависимости от: усилий по разработке и обслуживанию, эффективности устранения дефектов, а также эффективности инспекций и испытаний.

Сначала оценим компоненты общей стоимости из (4.4).

Стоимость обучения:

Ctr = Ctr*N (4.6)

где:

• Ctr - стоимость обучения на человека [м.у. / п]

• N - размер команды для развития, чел. [P]

Стоимость внедрения SIM:

Ci = (nM*tSIM_run)*c (4.7)

где:

• nM - количество встреч для внедрения SIM

• tSIM-run - время на прогон SIM-карты (определяется действиями, включенными в прогон SIM-карты: планирование, обзоры, подготовка, встречи, доработка и контроль)

Количество встреч для реализации SIM: S

nM = - (4.8)

ir

где: • ir - средний уровень проверки [SLOC / встреча]

Расчетное (запланированное) время для проверок может быть оценено с использованием двух альтернативных методов, и обозначим результаты как TI(1) и TI(2):

T(1) = n *t (4 9)

-4 M LSIM-run

T(2) _ 1I _

У —

è ы Ц*-0

*

(N*4 +1) (4.10)

где:

• psi - размер рабочего продукта на фазу (количество требований, количество диаграмм, количество SLOC или количество тестовых случаев)

• щ - скорость просмотра в час и фаза (req / H, diagr / H, SLOC / H или tc / H)

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

т(1)

nD,i _ (4.11)

tD,I

где:

• TI(1) - расчетное (плановое) время проверки

• tD,I - среднее время нахождения дефекта при осмотре.

Если предположим, что nD,S - это число дефектов в программном обеспечении до проверок (относительно предполагаемого размера программного обеспечения), то оставшиеся дефекты после применения инспекции являются:

nD,R _ nD,S - nD,I (412)

где:

• nD,R - количество оставшихся дефектов после применения SIM

• nDI - количество дефектов, обнаруженных SIM-картой.

Теперь предположим, что применяем тестирование программного обеспечения для устранения оставшихся дефектов и что эффективность процесса тестирования оценивается параметром eT. Тогда количество дефектов, которые обнаруживает тестирование программного обеспечения, определяется как:

nD,T,a _ eT*(nD,S - nD,I) (4.13)

где: • eT - эффективность тестирования программного обеспечения

Предполагая, что можно оценить среднее время нахождения дефекта путем тестирования tDT, стоимость тестирования для оставшихся дефектов определяется по формуле:

Ct _ (nD,T,a*tD,t)*C (4.14)

где:

• CT - стоимость тестирования на оставшиеся дефекты

• tD,T - среднее время нахождения дефекта при тестировании

Если tDT - предполагаемое время обнаружения дефекта при тестировании, то общее время тестирования программного обеспечения после проверки составляет:

Тт,а = nDXa*tD,t (4.15)

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

Cm = TLCSIM - (CD + CI + CT) (4.16)

Оценили все компоненты затрат Cd, Cm, Ct, Ci, Ctr при использовании усовершенствованного метода разработки программного обеспечения для разработки программной системы:

• CD оценивается с использованием моделей оценки стоимости программного обеспечения и методов усреднения [81-83]

• CM оценивается по формулам (4.5), (4.7), (4.14), (4.16)

• CT оценивается по формуле (4.14)

• CI оценивается по формуле (4.7)