Содержание к диссертации
Введение
Глава 1. Методы управления качеством процесса разработки программного обеспечения 10
1.1 Анализ этапов и направлений развития теории управления качеством процесса разработки программного обеспечения 10
1.2 Классификация моделей, методик, стандартов и методологий управления качеством процесса разработки ПО 14
1.3 Взаимосвязь качества процесса разработки ПО и качества ПО 16
1.4 Значимость повышения качества процесса разработки ПО для современной авионики 18
1.5 Оценка трудоемкости разработки и анализ ценообразования ПО 24
1.6 Анализ моделей, методологий и стандартов, применяемых для управления
качеством процесса разработки ПО 26
1.7 Управление рисками при разработке ПО 64
1.8 Выводы по главе 1 71
Глава 2. Разработка математической модели оценки качества процесса разработки программного обеспечения. обоснование метода выбора приоритетных процессов. 74
2.1 Разработка математической модели оценки качества процесса разработки ПО 74
2.2 Разработка критериальной базы приоритетных процессов при повышении качества процесса разработки программного обеспечения 87
2.3 Сопоставительный анализ методов многокритериального выбора 89
2.4 Обоснование метода выбора приоритетных процессов организации производства програ ммных продуктов 95
2.5 Разработка процедуры оценки интегрального показателя качества процесса разработки программного обеспечения 100
2.6 Выводы по главе 2 106
Глава 3. Разработка алгоритма повышения качества процесса разработки программного обеспечения. управление рисками 108
3.1 Управление рисками 108
3.2 Разработка алгоритма повышения качества процесса разработки программного обеспечения 116
3.3 Апробация разработанного алгоритма 119
3.4 Выводы по главе 3 135
Заключение 137
Библиографический список 139
ПРИЛОЖЕНИЕ А 150
ПРИЛОЖЕНИЕ Б 154
ПРИЛОЖЕНИЕ В 157
ПРИЛОЖЕНИЕ Г 159
ПРИЛОЖЕНИЕ Д 162
- Классификация моделей, методик, стандартов и методологий управления качеством процесса разработки ПО
- Значимость повышения качества процесса разработки ПО для современной авионики
- Разработка критериальной базы приоритетных процессов при повышении качества процесса разработки программного обеспечения
- Разработка алгоритма повышения качества процесса разработки программного обеспечения
Введение к работе
I. Актуальность темы.
Критический уровень зависимости деятельности современных организаций от информационных технологий и программных продуктов определяет значимость программного обеспечения (ПО) для экономики страны, промышленности и общества. Высокая конкуренция в области разработки ПО диктует жесткие требования к качеству производимых продуктов.
Проблемы повышения качества производственных процессов и управления качеством применительно к продуктам, услугам и процессам разрабатывались во многих научных исследованиях по квалиметрии и управлению качеством. В решение задач, связанных с этой проблемой, внесли существенный научный вклад А.Г. Варжапетян, Е.Г. Семенова, Ю.П. Адлер, Н.Н. Рожков, О.П. Глудкин, Г.Г. Азгальдов, Л.В. Черненькая. Необходимо отметить ставшие классическими в управлении качеством работы таких ученых, как Э. Деминг, А.У. Шухарт, К. Ишикава, Д. Джуран и другие. Проблеме оценки качества и управления качеством программных продуктов посвящены фундаментальные работы М. Холстеда, А. Альбрехта, Б. Боэма.
С развитием и усложнением программных продуктов и информационных систем, а особенно с развитием объектно-ориентированного программирования, метрики и процедуры оценки кода программного продукта стали трудно применимыми. На первый план вышел процесс разработки ПО. Проблемам управления процессом разработки ПО и управления ИТ-услугами посвящены исследования Ф. Брукса, У. Хэмфри, Ф. Кратчена, М. Полка, М. Мюллера, Т. Фелманна, С. Кана. Среди работ авторов из России и стран СНГ можно выделить В.А. Липатникова, В.Ш. Сулаберидзе, М.А. Годлевского, В.А. Шехов-цова, Е.М.Корнышову и др. Огромный вклад в развитие данной проблематики внесли такие организации, как ISO, SEI, Microsoft, Oracle, CETIC, Eurostat.
Ряд позиций из Перечня критических технологий Российской Федерации связан с разработкой ПО: «Технологии информационных, управляющих, навигационных систем», «Технологии и программное обеспечение распределенных и высокопроизводительных вычислительных систем».
Важнейшим потребителем ПО являются организации, разрабатывающие комплексы бортового оборудования (КБО). В России и за рубежом разработка ПО является неотъемлемой частью процесса создания комплексов бортового оборудования. Современная авионика нуждается в разработке нового и модернизации существующего ПО. Надежность работы КБО во многом зависит от надежности ПО, а специфика решаемых КБО задач диктует повышенные требования к качеству и надежности установленного ПО. В свою очередь, качество и надежность самого ПО определяется технологиями, в соответствии с которыми осуществляется процесс разработки ПО. Требования к качеству процесса разработки ПО с одной стороны, и недостатки современных подходов к управлению качеством, не предлагающих квалиметрических моделей и средств управления качеством процесса разработки ПО, с другой стороны, обосновывают актуальность разработки моделей, алгоритмов и процедур оценки и повышения качества процесса разработки ПО.
Цель работы
Целью диссертационного исследования является повышение качества процесса разработки ПО на основе создания квалиметрических моделей, алгоритмов и процедур.
Для достижения поставленной цели поставлены и решены следующие задачи:
создание математической модели оценки качества процесса разработки программного обеспечения,
разработка метода выбора приоритетных процессов организации разработки ПО,
разработка алгоритма повышения качества процесса разработки ПО,
разработка формализованной процедуры определения интегрального показателя качества процесса разработки ПО.
Объект исследования.
Объектом исследования является процесс разработки программного обеспечения.
Предмет исследования.
Предметом исследования является управление качеством процесса разработки программного обеспечения.
Методы исследования
Для решения задач использованы положения математической статистики и теории вероятностей, метод анализа иерархий, математические методы поддержки принятия решения, аппарат факторного и кластерного анализа, методы бережливого производства, методы построения структурированной функции качества. Основные теоретические результаты подтверждены при внедрении результатов диссертационной работы.
Тематика работы соответствует областям исследования: 1. «Методы анализа, синтеза и оптимизации, математические и информационные модели состояния и динамики качества объектов», 3. «Методы стандартизации и менеджмента (контроль, управление, обеспечение, повышение, планирование) качества объектов и услуг на различных стадиях жизненного цикла продукции», 4. «Квалиметрические методы оценки качества объектов, стандартизации и процессов управления качеством» паспорта специальности 05.02.23.
На защиту выносятся следующие основные результаты и положения:
метод выбора приоритетных процессов организации разработки ПО
математическая модель оценки качества процесса разработки ПО
процедура определения интегрального показателя качества процесса разработки ПО
алгоритм повышения качества процесса разработки ПО
Научная новизна
Научной новизной обладают следующие результаты исследования:
математическая модель оценки качества процесса разработки ПО,
отличающаяся наличием механизма количественной оценки рейтингов
атрибутов процессов и позволившая формализовать задачу повышения уровня возможностей процесса метод выбора приоритетных процессов организации разработки ПО, отличающийся многокритериальностью и учетом текущих и перспективных целей организации;
процедура определения интегрального показателя качества процесса разработки ПО, отличающаяся возможностью снижения размерности показателей, исходя из требований потребителя;
алгоритм повышения качества процесса разработки ПО, основанный на предложенном методе, построенной модели и разработанной процедуре.
Практическая значимость
Практическая значимость результатов диссертационной работы заключается в повышении качества процесса разработки ПО за счет применения предложенных квалиметрических методов и средств.
Результаты использования основных положений, выводов и рекомендаций, сформулированных в диссертации, обеспечили сокращение времени разработки ПО при выполнении требований по надежности и безопасности, корректности для верификации ПО, снижение материальных, финансовых и трудовых затрат, что подтверждено актами внедрения.
Практический интерес представляет также использование полученных результатов в процессе обучения студентов дисциплинам, связанным с технологией разработки программного обеспечения.
Публикации
Основные положения диссертации изложены в 13 печатных работах, в том числе 4 работах, опубликованных в ведущих рецензируемых научных изданиях. Девять публикаций подготовлены без соавторов.
Апробация работы
Основные положения и результаты исследования докладывались и обсуждались на XXXIX международной конференции «Гагаринские чтения» (Москва, 2013), 65-й, 66-й, 67-й международной студенческой научно-технической конференции ГУАП (Санкт-Петербург, 2012-2014), Тринадцатой Международной научно-практической конференции «Управление качеством» (Москва, 2014), Международной научно-практической конференции «Проблемы и направления развития систем качества» (Ульяновск, 2014), XV международном форуме «Формирование современного информационного общества – проблемы, перспективы, инновационные продукты» (Санкт-Петербург, 2014), научно-технической конференции ОАО «НПП «Радар ммс» (Санкт-Петербург, 2014).
Структура и объем диссертации
Диссертация состоит из введения, трех глав, заключения, списка литературы и приложений. Она содержит 149 страниц основного текста, 15 рисунков, 28 таблиц и приложения. Список библиографических источников насчитывает 110 наименований.
Классификация моделей, методик, стандартов и методологий управления качеством процесса разработки ПО
Разнообразие созданных методик, стандартов и методологий обуславливает необходимость создания классификации средств управления качеством процесса разработки ПО. Классификация может быть произведена по нескольким показателям.
По характеру обоснования моделей: концептуальные и эмпирические, то есть полученные рациональными методами или выведенные из опыта. В основе концептуальных моделей лежат принципы процессного подхода, управления проектами, управление качеством. Примерами концептуальных моделей являются модели CMMI, RUP. Эмпирические модели разработаны на основе обобщения опыта ГТ-проектов (например: Agile, OWPL).
В зависимости от предлагаемого подхода: модели зрелости, процессные модели, проектные методологии и групповые практики. Модели зрелости предназначены для управления компанией или подразделением. В основе таких моделей лежит понятие уровней зрелости организации - определенных этапов, которые должна пройти компания при улучшении организационных процессов. Модели зрелости предлагают поэтапное улучшение, а не требования к конечной системе качества, и результатом применения таких моделей является не только повышение качества процесса разработки ПО, но и повышение производительности организационных процессов в целом. Примерами таких моделей может послужить модель зрелости CMMI или стандарт ГОСТ Р 9004 -2009, концепция моделей зрелости также используется во многих других стандартах, таких как ГОСТ Р ИСО/МЭК 15504, СоЫТ. Процессные модели также предназначены для управления компанией или подразделением и основаны на оценке организационных процессов с использованием процессного подхода [18]. Одним из наиболее известных примеров является стандарт ISO 9001 - 2011. Также известным и распространенным является стандарт ГОСТ Р ИСО/МЭК 15504, сочетающий в себе признаки процессной модели и модели зрелости. Проектные методологии используются при управлении IT-проектами и сосредоточены на процессах управления проектами. Примерами таких методологий являются свод знаний по управлению проектами PMBOK, Microsoft Solution Framework (MSF). Групповые практики служат для оценки качества и эффективности работы команд разработчиков. Примером таких практик может послужить индивидуальный процесс разработки Personal Software Process (PSP).
В зависимости от характера реализации: прогнозируемые и адаптивные. Прогнозируемые – основываются на предпосылке о возможности и целесообразности детального планирования будущего. При использовании прогнозируемой модели составляется список требований, план мероприятий, определяется потребность ресурсов, а затем производятся мероприятия согласно плану [19]. Адаптивные – нацелены на преодоление предполагаемой неполноты требований, а также их постоянного изменения и адаптации к изменяющимся условиям деятельности компании. Наиболее характерным примером является методология быстрой адаптивной разработки Agile [11].
Универсальные концепции управления аккумулируют опыт и лучшие управленческие практики, которые стали основой методологий совершенствования деятельности компаний-разработчиков, таких как модели зрелости (CMM/CMMI), стандарты оценки и улучшения процессов (SPICE) и TickIT. Эти модели и стандарты регламентируют организационно-управленческую и технологическую среду, в условиях которой применяются проектные методологии. Схематично, классификация стандартов, моделей и методологий представлена на рисунке 1.1. Рисунок 1.1 Методологии, модели стандарты, применяемые в области управления процессом разработки программного обеспечения
С развитием современных языков программирования, а также объектно-ориентированного программирования, основное внимание стало уделяться управлению процессом разработки ПО, а не оценке самих программных продуктов. В свою очередь, повышение качества процесса разработки обеспечивает повышение качества программного продукта, а также рациональное использование материальных, трудовых и временных ресурсов [20; 21].
Процесс – совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы [22].
Процессы существуют как шаблоны последовательности действий (классы). В ходе выполнения проекта осуществляется реализация процесса – появляется
экземпляр процесса – объект (process instance) . Модель процессов – иерархически упорядоченный список процессов [18]. Проблема формализации процессов организации производства актуальна для всех компаний и организаций. Формальное описание процессов необходимо для обеспечения повторяемости процесса, однозначного понимания процессов всеми сотрудниками, возможности измерения характеристик процессов.
В управлении разработкой ПО концепция управления процессами организации производства находит свое отражение в моделях зрелости (CMM/ CMMI) и стандартах улучшения процессов (ГОСТ Р ИСО/МЭК 15504) [23]. Управление процессами приводит к улучшению функционирования организации, повышению эффективности отдельных процессов и организации в целом.
Стандарты серии ISO 9000 и методологии управления процессами, проектами и совершенствования деятельности компании (CMMI, SPICE и другие) основываются на предпосылке о наличии прямой связи между организацией процесса разработки и качеством ПО. Исходя из этих предпосылок система, организация и процессы определяют уровень качества. Также доказано, что повышения уровня зрелости процессов в организации сокращает трудозатраты на разработку программных продуктов [21].
Значимость повышения качества процесса разработки ПО для современной авионики
Современный этап развития отечественной и зарубежной авиации характеризуется двумя основными направлениями [25-27]: - создание новых перспективных самолетов и вертолетов; - модернизация эксплуатируемого авиационного парка. При этом, в современной отечественной и зарубежной авиации особое внимание уделяется автоматизации управления самолетом. Повышение автоматизации управления самолетом на всех этапах полета с учетом расширения информационной поддержки в процессе выполнения полетного задания и развития навигационного обеспечения позволяет существенно повысить как эффективность полетов самолетов гражданской авиации, так и выживаемость самолета [26; 28]. Задача автоматизации управления самолетом возлагается на комплексы бортового оборудования (КБО).
Современная обработка информации в бортовой авионике представляет собой сложную многослойную иерархическую автоматизированную система принятия решений, в которой общая задача управления полетом и целевые задачи разбиваются на семейство последовательно расположенных более простых задач принятия решений. Авионика составляет значительную часть бортового оборудования современных летательных аппаратов (ЛА) [29]. На рисунке 1.2 показана структурная схема пилотажно-навигационного комплекса (ПНК). Рисунок 1.2 - Контур управления ЛА с оборудованием ПНК
Современные пилотажно-навигационные комплексы представляют собой интеллектуальные системы управления, главным признаком которых является адаптация и обучение, дающие знания о неизвестных характеристиках объекта управления и окружающей среды. Такой подход к созданию перспективных комплексов бортового оборудования позволяет использовать единые технические решения как при создании комплексов для новых самолетов, так и при модернизации бортового оборудования эксплуатируемого авиапарка. Основу КБО составляет управляющая вычислительная система, назначение которой заключается в: - решении навигационных задач на всех этапах полета с выдачей сигналов в САУ самолета и на директорные приборы; - планирование и редактирование маршрутов полета на основе аэронавигационных баз данных в ручном и автоматическом режимах; -управление самолетом в горизонтальной плоскости (горизонтальный профиль полета) на основе ряда промежуточных пунктов маршрута из аэронавигационной базы данных; -управление самолетом в вертикальной плоскости (вертикальный профиль полета) с учетом характеристик машины, метеообстановки, заправки, загрузки и центровки.
В зависимости от назначения самолета и решаемых им задач состав бортового оборудования может меняться. При этом может также меняться программное обеспечение. Некоторые возможности, разработанные для военного сектора, имеют очевидное применение в соответствующих гражданских секторах. Современная военная и гражданская авиация нуждается в постоянной модернизации и модификации существующего, а также разработке нового ПО для бортовой авионики. Ряд авторов выделяет несколько важнейших требований к КБО, имеющих зависимость от разрабатываемого ПО, а, следовательно, и от процесса разработки: - высокую надежность - удобство в эксплуатации и обслуживании - высокий уровень унификации аппаратной части и ПО - простоту модернизации и наращивания решаемых задач [30-32]. Из этого следует вывод о значимости управления качеством процесса разработки ПО для создания современных КБО. В РФ и за рубежом разработка ПО является составной частью процесса разработки комплексов бортового оборудования. В лучших зарубежных практика качество и надежность ПО обеспечивается прежде всего за счет строгой формализации всех процессов проектирования [33]. Процесс разработки ПО для КБО базируется на известной концепции жизненного цикла ПО и включает те же процессы, что и разработка ПО в любой другой отрасли. На рисунке 1.4 представлен пример типового процесса разработки ПО для КБО. На схеме процесс разработки ПО рассматривается как итеративный, каждый цикл итерации которого состоит из следующих основных этапов: этап системного анализа требований к КБО; этап системного проектирования КБО; этап системного анализа требований к ПО; этап системного проектирования ПО; этап программирования программных модулей; этап сборки и интеграции ПО; - этап интеграции ПО и оборудования; - этап квалификации ПО и оборудования. В области разработки КБО ПО используется для самых разнообразных задач: - обработка радиолокационной информации, - решение навигационных задач, - работа стендов полунатурного моделирования (СПНМ) При этом надежность работы КБО во многом зависит от надежности ПО. В свою очередь надежность самого ПО определяется теми технологиями, в соответствии с которыми разрабатывается ПО [34]. Вместе с тем, при разработке ПО многие предприятия продолжают в качестве основных руководящих документам использовать стандарты серии ЕСПД [35]. Эти стандарты были созданы в 70-х годах прошлого века, и в настоящее время руководствоваться ими для создания сложного и надежного ПО недостаточно. Анализ системных требований к КБО Ж Системное проектирование КБО ж Анализ системных требований к ПО ж Системное проектирование ПО ж Реализация программных модулей Ж Реализация программных модулей ж Сборка и интеграция ПО ж Интеграция ПО с оборудованием Ж Квалификация ПО Рисунок 1.4 Типовой процесс разработки ПО для КБО Среди специфических средств разработки и языков программирования, применяемых в разработке ПО для современной авионики, наибольшую известность получили продукты Wind River VxWorks и ForthLogic [36; 37]. Среди широко распространенных языков программирования наибольшую популярность в разработке авионики получили Assembler и языки на его основе, а также C/C++. В частности, среда разработки VxWorks предлагает разработку и компиляцию приложений на языках C/C++, Ada, Java. Существенным требованием к ПО КБО является соответствие стандартам по безопасности и/или наличие сертификатов по этим стандартам. Наиболее значимые стандарты и их назначения представлены в таблице 1.1 Таблица 1.1 Стандарты надежности и безопасности ПО для КБО ЛА Стандарт Назначение POSIX Спецификации стандарта POSIX определяют стандартный механизм взаимодействия прикладного ПО и операционной системы (ОС). DO-178B(C) Данный стандарт основывается на методе оценки опасности, которую может вызвать неправильная работы системы в первую очередь для пассажиров и экипажа воздушного судна. Стандартом предусмотрено пять уровней описания степени серьезности отказа, и для каждого из данных уровней определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня отказа. Является часто применяемым стандартом по безопасности при разработке КБО ARINC-653 Данный стандарт определяет универсальный программный интерфейс APEX (Application/Executive) между ОС бортового авиационного комлпекса и прикладным ПО. В 2007 году было выпущено очередное дополнение стандарта. Оно касается организации холодного и горячего старта модулей авионики, стандартов обработки ошибок приложениями.
Переформулировать определение можно следующим образом: «функциональная точка – это минимальная единица продукции, производимой разработчиком информационной системы, имеющая содержательный смысл с точки зрения конечного пользователя». Таким образом существенным преимуществом функциональных точек является то, что произвести измерение ИТ-проекта можно уже на ранней стадии, взяв за основу только документацию по проект. Модель функциональных точек преобразуется в количество строк кода. Существует сводная таблица количества строк кода, необходимого для реализации одной функциональной точки в различных распространенных языках программирования. Фрагмент этой таблицы представлен в таблице 1.2
Разработка критериальной базы приоритетных процессов при повышении качества процесса разработки программного обеспечения
Описанную в предыдущем параграфе модель достаточно трудоемко применять ко всем процессам, описанным в ИСО 15504. Также повышение качества некоторых процессов является более приоритетным для организации, а некоторые процессы не требуются или не используются в течение рассматриваемого периода управления. Для определения процессов, повышение качества которых необходимо в первую очередь, требуется решить задачу выбора приоритетных процессов (Рисунок 2.1).
При разработке подхода к определению приоритетных процессов организации требуется учитывать два основных аспекта: во-первых, оценка процессов может осуществляться по многим критериями и, во-вторых, требуется выбрать подходящий многокритериальный метод (МКМ). Управление процессом разработки программного обеспечения, основанное на модели зрелости процессов ИСО 15504 имеет следующие особенности: - рассматривается большое количество процессов - 7 процессных областей включающих в себя более 30 процессов; - качество процессов проблематично оценить количественными показателями; - для оценки важности процессов необходимо рассмотреть большое количество критериев в силу того, что стандарт рассматривает большое количество процессов, выполняющих самые разнообразные задачи. Для сравнения МКМ принятия решений выбраны следующие аспекты: - возможность выбора, - возможность ранжирования, - сортировка альтернатив, - способ оценки, - способ агрегирования частных оценок, - способ оценки критериев, - одновременный учет разных шкал и показателей, - уровень сложности метода, - формализация метода, - возможные типы показателей, - количество сравниваемых объектов.
Сравнительный анализ на основе предложенных аспектов представлен в таблице 1. Рассматриваются теория полезности (Multi-Attribute Utility Theory -MAUT) [85], метод анализа иерархий (МАИ, Analytical Hierarchy Process - AHP) [77], методы «превосходства» (метод ELECTRE) [86], методы «взвешивания» [87]. 2.3 Сопоставительный анализ методов многокритериального выбора 1. Многокритериальная теория полезности Теория полезности, изложенная в работе "Теория игр и экономическое поведение", носит аксиометрический характер [88]. Авторы показали, что, если предпочтения людей по отношению к определенным играм (лотереям) удовлетворяют ряду аксиом, то их поведение может рассматриваться как максимизация ожидаемой полезности. Аксиоматические методы подходят к измерению ценности, полезности альтернатив как последовательности определенных шагов, подтверждающих справедливость выбора некоторых аксиом, на основании которых обосновывается возможность использования функции полезности определенного вида. Аксиоматические методы подразделяются на две группы: - принятие решений при определенности (оценки альтернатив считаются известными); - принятие решений при риске (заданы функции распределения вероятностей оценок альтернатив). Обе группы методов используют близкую систему аксиом (три группы): Аксиомы "слабого порядка" и транзитивности. В условиях определенности. Пусть u,v,w U - полезности альтернатив. Тогда: а) для любых u,v имеет место одно из следующих соотношений: б) из следует В условиях риска: Пусть R - множество распределений вероятностей на множестве альтернатив. Каждое распределение P в R можно представить в виде лотереи , где pb Р2,-, Рг - вероятности осуществления альтернатив aі, аг,..., ar. ) (2.27) Каждому распределению P или Q в R можно приписать определенное числовое значение ожидаемой полезности U(P) или U(Q) такое, что P Q, тогда и только тогда, когда U(P) U(Q). Тогда для распределений P,Q,W: а) имеет место одно из соотношений: (2.28) б) если Аксиомы, исключающие ненормальности в предпочтениях. а) Возможности использования любых частей полезности 2-х альтернатив для выражения эквивалентной полезности третьей (аксиома растворимости): Для детерминированного случая: из следует, что существует такое a, , что: (2.29) Для условий риска: если , то существует такое a, , что: (2.30) б) Запрещение использования альтернатив, неизмеримо превосходящих другие (Архимедова аксиома): Для детерминированного случая: если , то существует такое a, , что: (2.31) Для условий риска: если , то существуют такие p,q, , , что: . (2.32) . (2.33) Аксиомы независимости. Эти аксиомы выражают требования, чтобы предпочтения между альтернативами не зависели от некоторых преобразований этих альтернатив. Чаще всего используются: Для детерминированного случая: а) Слабая условная независимость по полезности: предпочтения для двух альтернатив, отличающихся лишь оценками по шкале одного критерия, не зависят от оценок этих альтернатив по шкалам других критериев б) Совместная независимость: предпочтения между альтернативами, отличающимися оценками по определенному подмножеству критериев, не зависят от одинаковых оценок по критериям оставшегося подмножества Для условий риска: в) Аксиома эквивалента определенности: предпочтения между лотереями не должны зависеть от одинаковых составляющих исходов лотерей г) Аксиома строгой условной независимости по полезности: предпочтения среди многокритериальных альтернатив, для которых часть оценок по критериям задана распределением вероятностей, а другая часть имеет постоянные значения, не зависят от этих постоянных значений д) Аксиома маргинальности: многокритериальные альтернативы сравнимы между собой только на основе рассмотрения распределений вероятностей оценок по отдельным критериям Рассмотренные выше аксиомы обычно используются для доказательства существования функции полезности определенного вида. При справедливости аксиом групп 1 и 2 (слабого порядка и транзитивности, исключения ненормальностей в предпочтениях), а также условной независимости и совместной независимости функция полезности может быть выражена в виде: (2.34) где xi – оценка альтернативы по i-му критерию, fi – частная функция полезности по i-му критерию. При выполнении аксиом определенного эквивалента, строгой условной независимости, маргинальности полезности для случая риска полезность альтернативы имеет вид: (2.35) где pj – вероятность осуществления j-й альтернативы, xj - вектор многокритериальных оценок j-й альтернативы. Достаточно часто формулируются другие аксиомы независимости с целью доказать существование функции полезности определенного конкретного вида. 2. Метод анализа иерархий (МАИ) Метод анализа иерархий базируется на парных сравнениях между собой альтернатив и критериев (таблица 2.6). Таблица 2.6 – Значения элементов матрицы сравнения Значение aij Определение 1 Равная важность критериев 3 Один критерий немного важнее другого 5 Один критерий существенно важнее 7 Очень высокая важность одного из критериев 9 Крайне высокая важности 2,4,6,8 Промежуточные значения При использовании МАИ сравнивается вес, соответствующий каждому критерию с весом каждого из остальных критериев. В результате формируется матрица вида: ( ) ( ) (2.36) Здесь wi и wj показывают важность (вес) i-го и j-го критериев соответственно. Матрица, представленная в формуле (2.36) называется матрицей сравнения, и может быть выражена также формулой (2.37). ( ) ( ) (2.37) Элементы (i,j), лежащие под правой диагональю являются обратными элементам, лежащим над ней: (2.38) , Элементы, лежащие на главной диагонали матрицы равны 1. При j i, элементы aij определяются согласно таблице 2.6. Для n критериев необходимо сделать n(n-1)/2 сравнений, чтобы получить матрицу А. Если матрица сравнений согласованна (или идеальна), то есть для любых i,j,k, то справедливо: (2.39) где n – число практик управления, а – вектор относительных весов. Термин относительных в данном случае означает, что сумма весов равна 1. При этом при проведении оценки обычно нельзя получить совершенную матрицу сравнения. При наличии несогласованности в матрице А, вектор W может быть определен как:
(2.40) где - наибольшее собственное значение матрицы А. Установлено, что [89]. Чем ближе к n, тем ближе матрица сравнения к идеальной. Из этого утверждения был выведен коэффициент согласованности: (2.41) Этот индекс показывает отклонение от идеальной матрицы сравнения. Степень согласованности матрицы А измеряется уровнем согласованности: (2.42) где RI – стохастический коэффициент согласованности, определяемый эмпирическим путем как среднее значение коэффициента CI для случайно сгенерированных по таблице 3 матриц сравнения. Если матрица А согласованна, то CI и CR равны 0, так как . Если , оценка весов приемлема [77]. В противном случае необходимы дополнительные вычисления для приведения оценки весов в соответствие требованию. В этом случае матрица сравнения вычисляется заново, затем снова проверяется, и операция повторяется до тех пор, пока условие не будет выполнено.
Разработка алгоритма повышения качества процесса разработки программного обеспечения
Предложенные в данной работе методы, процедуры и модели позволяют разработать на их алгоритм повышения качества процесса разработки программного обеспечения. В основе алгоритма лежит цикл DMAIC (Define-Measure-Analyze-Improve-Control), известный из методологии «Шесть Сигм». Данный цикл предназначен для проектов, осуществляемых по методологии «Шесть сигм», но также может быть использован в качестве фреймворка для других проектов по повышению качества. Цикл включает в себя пять основных этапов: определение, изменение, анализ, улучшение, контроль [108]. Все эти этапы обязательны и их требуется осуществлять в строго определенном порядке. Применительно к разрабатываемому алгоритму повышения качества процесса разработки ПО, эти этапы обозначены следующим образом [109]. Define Цель данного этапа состоит в четком определении бизнес целей, проблем, потенциальных ресурсов. Составляется план, который постоянно обновляется. На этом этапе необходимы следующие действия: - изложение проблемы, - определение целей улучшения, - определение рисков, связанных с процессами, - определение набора показателей качества процесса разработки. Measure На этой стадии производится сбор информации. Главная задача - понять, какую роль каждый процесс играет в жизни компании. Также выявляются неэффективные процессы, больше других нуждающиеся в повышении качества. - определение приоритетных для улучшения процессов с использованием разработанного метода выбора, - измерение текущего значения интегрального показателя качества, - измерение уровней рисков, - оценка рейтингов атрибутов возможностей процессов, связанных с поставленными целями. Analyze
На данном этапе, на основе проведенных измерений выявляются основные «проблемные точки» процесса разработки, определяется целевое состояние проблемных процессов, и планируются мероприятия по улучшению. Этап можно разделить на следующие шаги: - составление текущих профилей возможностей, - определение целевых профилей возможностей, - определение необходимых мероприятий (внедрение новых практик, улучшение существующих) для достижения целевого профиля возможностей. Improve Основной целью данного этапа является проведение необходимых мероприятий для достижения целевых профилей процессов и повышения качества процесса разработки. На основе результатов предыдущих этапов принимается решение и разрабатывается план действий по улучшению наиболее важных процессов. На этом этапе внедряются необходимые практики для достижения целевого профиля возможностей процессов. Control На последнем этапе DMAIC осуществляется контроль над процессом, чтобы убедиться в правильности выбранного решения. - измерение конечного значения интегрального показателя качества после улучшения, - сопоставление конечного и начального значений, - вывод об успешности мероприятий, - при необходимости - корректировка целей и возврат к предыдущим шагам.
Предприятие Назначение ПО Используемыеязыки программирования и СУБД ОАО «НПП Радар ммс» ПО для обработки радиолокационной информацииПО для решения навигационных задачПО для стендов полунатурного моделирования Borland C++,Microsoft VisualC++ ООО«ЕвроЛюкс» обеспечение работы многофункциональных терминаловпоисковые системывеб-сайты различной сложности и назначения Java, PHP,Python, Flash,Javascript, ГБУ«Информационно-методический центр» система мониторинга и нормирования цен публичныхофертсистема размещения и контроля целевыхгосударственных программсистема технической поддержки (helpdesk) дляпользователей автоматизированной информационнойсистемы госзаказа Java, PHP,Javascript, Ruby,MySQL,PostgreSQL,Oracle, MongoDB Применение разработанного алгоритма представлено на примере одной из организаций - компании ООО «ЕвроЛюкс». Оценка производилась по 20 проектам разработки программного обеспечения, выполненным в период с 2011 по 2014 годы. Основными проблемами, с которыми сталкивалась организация в ходе выполнения проектов, руководство компании называло следующие: - проекты не укладываются в запланированные сроки; - высокие затраты на разработку, проекты не укладываются в бюджет; - много времени затрачивается на переговоры из-за некорректно составленного ТЗ и списка требований; - большое количество доработок после сдачи проекта, вызванных несоответствием проекта требованию заказчика и, как следствие, возникновение дополнительных затрат на доработку; - большое количество обращений в техническую поддержку после сдачи проекта и, как следствие, высокие затраты на поддержку.
Исходя из этих проблем, установлены основные цели компании, связанные с повышением качества процесса разработки ПО. Сводная таблица целей представлена в таблице 3.5, а отсортированная по группам целей ССП - в таблице 3.6. Наиболее важными целями являются – снижение затрат на разработку и выполнение сроков сдачи проектов. Также важной целью является увеличение производительности команды разработчиков. Далее каждый процесс оценивался исходя из его вклада в достижение целей организации. Оценка производилась совместно с руководством и руководителями отделов разработки. Оценка важности процессов представлена в таблице 3.8. Знаком ( ) обозначаются процессы, которые не рассматривались в силу особенностей деятельности компании, а также процессы, выполнение которых подразумевается при внедрении механизма повышения качества.
В качестве средств и инструментов для планирования проекта использовалась система постановки задач Redmine. Она же обеспечивала управление ресурсами и графиком выполнения проекта. Документирование процессов осуществлялась системой Redmine, а также оформленными по единому образцу постановками задач, размещенными в Redmine и на внутренних сетевых ресурсах компании. В системе постановки задач четко отмечались и отслеживались сроки выполнения задач, а также исполнители, которым были поставлены данные задачи, что обеспечивало распределение ресурсов и обязанностей. Для разработки общего плана проекта, перед распределением задач, собирались специальные совещания с участием руководства компании, руководителей проектов и руководителей отделов. На совещании составлялся утверждаемый руководством список необходимых средств разработки, обозначались ориентировочные сроки и график выполнения проекта, производилась первичная декомпозиция плана работ.
