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

Тип работы:
Реферат
Предмет:
Экономические науки


Узнать стоимость

Детальная информация о работе

Выдержка из работы

----------------? ?-------------------
У роботі розглянуто реалізацію моделей та алгоритмів, які використовуються при розробці плану програми удосконалення процесу розробки програмного забезпечення. Описано інформаційну технологію, наведено діаграму розміщення для системи підтримки прийняття рішень, а також результати досліджень
Ключові слова: моделі, алгоритми, процес розробки програмного забезпечення, інформаційна технологія, результати досліджень
?---------------------------------?
В работе рассмотрена реализация моделей и алгоритмов, используемых при разработке плана программы усовершенствования процесса разработки программного обеспечения. Описана информационная технология, приведена диаграмма размещения для системы поддержки принятия решений, а также результаты исследований
Ключевые слова: модели, алгоритмы, процесс разработки программного обеспечения, технология, результаты исследований ----------------? ?-------------------
УДК 004.4. 075
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ УПРАВЛЕНИЯ КАЧЕСТВОМ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
М. Д. Годлевский
Доктор технических наук, профессор, заведующий кафедрой Кафедра автоматизированных систем управления Национальный технический университет «Харьковский политехнический институт» ул. Фрунзе, 21, г. Харьков, Украина, 61 002 E-mail: god_asu@kpi. kharkov. ua И. Л. Брагинский Президент компании Компания НИКС Солюшенс пр. Гагарина, 181, г. Харьков, Украина, 61 105 E-mail: garry@nixsolutions. com
1. Введение
В рыночной экономике проблема качества является важнейшим фактором повышения уровня жизни, экономической, социальной и политической безопасности. Качество — комплексное понятие, характеризующее эффективность всех сторон деятельности социально-экономической системы: разработка стратегии, организация производства и предоставления услуг, маркетинг и т. д. Важнейшей составляющей всей системы качества является качество продукции и предоставляемых услуг. С течением времени понятие качества претерпело определенную эволюцию. Первый этап соответствовал начальным задачам системного подхода к управлению качеством (система Тейлора, 1905 г.). Это была система управления качеством отдельно взятого изделия (услуги). Второй этап соответствовал управлению процессами. Акцент с инспекции и выявления дефектов был перенесен на их предупреждение путем определения причин дефектов и их устранения на основе изучения процессов и управления ими. На третьем этапе в 50-е годы была выдвинута концепция тотального контроля качества — TQC (Total Quality Control) на различных этапах проектирования и изготовления продукции и предоставления услуг. Четвертый этап. В 80-е годы начался переход от тотального контроля качества к тотальному менеджменту качеством — TQM (Total Quality Management). В это время появилась серия новых международных стандартов на системы качества — стандарты ISO 9000 (1987 г.). Если TQC — это управление качеством с целью выполнения установленных требований, то TQM — еще и управле-
ние целями и самими требованиями. На пятом этапе, в 90-е годы, устанавливаются требования к системам менеджмента с точки зрения защиты окружающей среды и безопасности продукции.
Учитывая универсальный характер стандартов серииО 9000, они были применены в области программной инженерии для решения задач повышения качества разработки программных систем (ПС).
2. Постановка задачи
Основная задача повышения качества ПС состоит во внедрении в повседневную практику организаций — разработчиков поддерживающих процессов жизненного цикла (ЖЦ) ПС: «гарантирование качества», «управление качеством», «верификация и валидация». Термин «гарантирование качества» соответствует используемому за рубежом термину «Software Quality Assurance» (SQA), а «верификация и валидация» — «Verification and Validation» (V& amp-V). SQA связан с двумя видами деятельности: внедрение стандартов качества и соответствующих процедур в разработку ПС- оценка приверженности этим стандартам и процедурам. С 1995 г. эта деятельность регламентируется международным стандартом ISO/IEC 12 207. Объектом исследования SQA являются, в основном, процессы ЖЦ ПС, а не программные продукты. Для контроля качества программных продуктов предназначен процесс V& amp-V [1]. Начиная с 1998 года в состав процессов, которые поддерживают термин «качество», был включен организационный процесс «управление качеством». Это
. уз
© М. Д. Годлевский, И. Л. Брагинский, 2013
стандарты ^0/1ЕС 12 207 (1998−2001 гг.) и ^0/1ЕС ТЯ 15 504 (1998−2002 гг.). Для обеспечения целенаправленного подхода к решению задачи гарантии качества ПС и совершенствования процессов ЖЦ ПС ЗЦА интегрируется с процессом управления качеством.
Усовершенствование действующих в организации процессов — одна из основных задач инженерии качества ПС. Согласно стандарту ДСТУ ^0/1ЕС ТЯ 15 504−7 первыми шагами усовершенствования процессов ЖЦ является оценивание мощности процессов и на этой основе разработка плана программы усовершенствования в условиях ограниченных ресурсов. Термин «мощность» рассматривается как синоним таких понятий как: зрелость, совершенство, потенциал. Зрелость процесса разработки (ПР) ПС [2−5] можно охарактеризовать как степень четкости: определения, управления, измерения, контроля и выполнения ПР ПС в организации. Известные модели зрелости [6, 7] позволяют оценить мощность отдельных процессов ЖЦ или зрелость всей организации, но задача заключается в формировании программы улучшения качества разработки ПС, которая позволит руководителю организации выстроить стратегию продвижения фирмы к более высокому уровню зрелости в условиях ограниченных ресурсов. В настоящее время в научной литературе в области программной инженерии этот вопрос практически не изучен. Поэтому актуальной является приведенная ниже технология формирования программ улучшения качества ПР ПС на основе модели зрелости в условиях ограниченных ресурсов.
Программное обеспечение (ПО) является одной из составляющих ПС. Так как понятие «процесс разработки» будет в большей степени касаться ПО, то в дальнейшем в работе будем использовать термин ПР ПО.
3. Технология управления качеством ПР ПО
В настоящее время существует множество подходов к оценке качества ПР ПО. Основными из них, наиболее хорошо зарекомендовавшими себя на практике, являются: стандарт ISO/IEC 15 504 TR — Software Process Improvement and Capability Determination (SPICE) — модель CMMI -Capability Maturity Model Integration.
Модель CMMI разработана Институтом программной инженерии (Software Engineering Institute, SEI) и была создана в 1998 году на базе более ранней модели CMM (Capability Maturity Model). Обе модели базируются на концепции зрелости организации — разработчика ПО. Знание степени зрелости помогает предсказать возможности каждого проекта в достижении поставленных перед ним целей. Модель CMMI реализует два подхода к оценке зрелости: дискретное представление (как в СММ) на основе пяти уровней зрелости- непрерывное представление (как в SPICE) на основе четырех уровней возможности. В основе первого подхода лежит концепция зрелости базового ПР ПО в масштабе всей организации, а в основе непрерывного — концепция мощности (качества) отдельной процессной области. Каждый уровень зрелости состоит из нескольких процессных (фокусных) областей. Процессная область (Key Process Area, KPA) определяет действия, обеспечивающие достижение множества целей, важных с точки зрения увеличения зрелости ПР ПО. Используются два вида
целей: частные и общие. Частные цели принадлежат к определенной процессной области и описывают, что должно быть выполнено для реализации процессной области. Общая цель может появляться в нескольких процессных областях. Каждая KPA состоит из множества практик (Key Practice, KP). Практики описывают инфраструктуру и действия, необходимые для успешной реализации процессной области. Они разделены на частные и общие, и обеспечивают достижение соответствующих им частных и общих целей.
В рассматриваемой работе при разработке технологии управления качеством ПР ПО в качестве базовой использовалась модель CMMI. При этом без потери общности в модели рассматривались только частные цели и соответствующие им практики.
Процессу разработки информационной технологии системы поддержки принятия решений в любой области деятельности всегда предшествует тщательно проработанная технология определения последовательности проведения отдельных бизнес-процессов для ее реализации. В данной работе для решения этой проблемы использован стандарт IDEFO (рис. 1), реализация которого осуществлялась на основе программного средства Ramus.
Согласно технологии решения задачи первым укрупненным бизнес-процессом А1 является определение текущего состояния ПР ПО. В качестве входной информации является исходное состояние ПР ПО исследуемой организации — разработчика ПО. Как было сказано выше, ПР ПО оценивается с точки зрения модели CMMI. При этом оценка ведется на уровне исходного состояния отдельных практик фокусных областей, которые определяются таким понятием как «уровень возможности» [8] в пределах от нуля до трех.
Базовой официальной методикой для получения оценки текущего состояния ПР ПО на основе модели CMMI является метод SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Данный метод имеет три класса оценки: A, B, C. Оценку класса, А проводит SEI — уполномоченный эксперт. Результатом оценки являются:
1) уровень зрелости ПР ПО от первого до пятого-
2) выводы, которые описывают сильные и слабые стороны процесса организации по отношению к CMMI-
3) консенсус по ключевым вопросам организации процесса-
4) оценка базы данных, которую организация может продолжать использовать для мониторинга прогресса в процессе совершенствования и поддержки будущих оценок.
Класс оценки В помогает организации понять, с относительно высокой степенью уверенности, статус ее программного обеспечения и систем инженерного процесса по отношению к CMMI. Класс В часто выполняется, когда организации необходимо точно оценить ее прогресс на пути погашения целевого уровня CMMI. Класс С короче и более гибкий, чем, А и В, и проводится для решения целого ряда особых потребностей от быстрого анализа пробелов до определения готовности организации к проведению оценки согласно классу А.
Недостатком SCAMPI является то, что данная технология позволяет сделать только качественные оценки ПР ПО и нет рекомендаций по переводу этих качественных оценок в уровни возможности отдельных практик
э
Рис. 1. Технология управления качеством ПР ПО
фокусных областей. SCAMPI распространяется только как методический материал, доступный для практического применения только после прохождения обучения в SEI.
Учитывая все выше сказанное, в работе для оценки текущего (исходного) состояния ПР ПО и проверки работоспособности разработанной технологии были использованы эксперты исследуемой организации — разработчика ПО, которые давали оценку уровня возможности практик отдельных фокусных областей. Обработка этой информации проводилась аналитиками — лицами формирующими решение (ЛФР) на основе методологии коллективного экспертного оценивания (МКЭО) [9].
Результатом бизнес-процесса А1 является текущее состояние ПР ПО.
Бизнес-процесс А2 предназначен для формирования целевого профайла, определяющего цели организации по усовершенствованию ПР ПО, которые ставятся лицом принимающим решение (ЛПР) на основе ограничения на финансовые ресурсы, а также экспертных оценок необходимых ресурсов для достижения поставленных целей отдельно по каждой практике рассматриваемых фокусных областей.
Для формирования оптимального плана усовершенствования ПР ПО (бизнес-процессы А3-А5) используются разработанные авторами динамическая модель и алгоритм управления качеством процесса разработки ПО на основе модели зрелости CMMI [10]. В качестве входной информации используется: исходное состояние ПР ПО- целевой профайл- необходимые финансовые ресурсы по каждой практике, принадлежащей целевому профайлу- ограничения на финансовые ресурсы, которые могут быть использованы на рассматриваемом плановом периоде. Кратко рассмотрим каждый из бизнес-процессов А3-А5.
Бизнес-процесс А3 предназначен для формирования множеств допустимых вариантов состояния ПР ПО на каждом рассматриваемом плановом подпериоде с уче-
том ограничения на финансовые ресурсы, которые выделяются на каждом подпериоде планирования и могут быть перенесены на последующий t+t-ый подпериод, если они не израсходованы нам подпериоде.
Бизнес-процессы А4, А5 реализуют непосредственно динамическую модель задачи, которая представляет собой аддитивную целевую функцию с ограничениями на финансовые ресурсы и переменные, определяющие уровень возможности отдельных практик, входящих в целевой профайл. Для формирования оптимального плана программы усовершенствования ПР ПО используется алгоритм последовательного анализа вариантов [10], на каждом шаге которого отметаются неконкурентоспособные варианты развития ПР ПО. В итоге на выходе технологии управления качеством ПР ПО (рис. 1) формируется оптимальная траектория развития ПР ПО.
4. Диаграмма размещения ПС
Диаграмма размещения ПС (рис. 2) отражает физические взаимосвязи между программными и аппаратными компонентами системы. В данной работе была выбрана архитектура клиент-сервер с «толстым» клиентом. Сервер в этом случае является лишь хранилищем данных, а вся работа по обработке и представлению данных перенесена на машину клиента. Для реализации ПС был выбран язык C#, а для хранения и обработки данных — СУБД MySQL, основные преимущества которой — достаточное быстродействие и устойчивость к ошибкам. Кроме этого, СУБД MySQL справляется с обработкой довольно больших массивов данных. Для реализации взаимодействия C# и MySQL использована утилита MySQL Connector, которая представляет собой полнофункциональный ADO. NET драйвер для MySQL. ПС была разработана в Visual Studio 2010.
Кратко рассмотрим основные компоненты диаграммы размещения ПС (рис. 2).
Е
Рис. 2. Диаграмма размещения ПС
ConnectDB — данный компонент представляет собой блок, в котором описаны настройки конфигурации подключения к базе данных (имя пользователя, пароль, название БД и т. д.). СММ1. МаЛ — компонент, содержащий в себе основное математическое и алгоритмическое обеспечение программной системы (например, функции вычисления оптимальной траектории и т. д.). CMMI. DataAccessLayer — данный компонент представляет собой «слой» работы с поступающими данными. Он использует компонент CMMI. DataAccessLayer. Mode!, который реализует модель задачи. В нем осуществляется отбор состояний, учитывающих ограничения на финансовые ресурсы, расчет степеней принадлежности и т. д. CMMI. ServiceLayer — собственно компонент генерации состояний. Содержит реализацию алгоритмов и функций генерации всевозможных состояний ПР ПО. Часть логики реализуется в компоненте СММ1. ServiceLayer. Generated.
Необходимо отметить, что CMMI. ServiceLayer является связующим компонентом с CMMI. DataA-ccessLayer.
5. Апробация ПС
Для проверки работоспособности разработанной ПС был выбран фрагмент целевого профайла, который представлен в табл. 1.
Целевой
Исходное и планируемое состояние практик измеряются в шкале «уровень возможности» в пределах от нуля до трех. В нашем случае на основе экспертных оценок специалистов определены: исходное состояние практик фокусных областей для второго уровня зрелости и планируемое на конец планового периода. В графе «необходимые финансовые ресурсы» приведен объем финансов, необходимый для перехода с первого на второй уровень возможности. Решение динамической задачи формирования плана программы усовершенствования ПР ПО рассматривается на плановом периоде, состоящем из трех подпериодов. Ресурсы, выделяемые и расходуемые на каждом подпериоде, приведены на рис. 3. Как видно из рис. 3, принадлежность к уровню зрелости 2 в течение планового периода меняется от 0,5 до 1, так как учитывались только фокусные области и соответствующие им практики целевого профайла (табл. 1).
Целью дальнейших исследований является:
1) просчет полноразмерных тестовых примеров с возможностью перехода на третий уровень зрелости-
2) учет влияния уровня зрелости на стоимость ПО-
3) исследование вида функции принадлежности к некоторому уровню зрелости-
4) сравнение результатов исследования ПР ПО на основе модели CMMI с моделью SPICE.
Таблица 1
профайл
Уровень зрелости 2
Категория Управление проектами Поддержка
Фокусные области (ФО) REQM — управление требованиями CM — управление конфигурацией
Цели REQM1 CM1 CM3
Практики (П) 4 5 1 6 7
Исходное состояние 1 1 1 1 1
Планируемое состояние 2 2 2 2 2
Необходимые финансовые ресурсы, у.е. 4300 4300 3000 3000 3000
Весовые коэффициенты для ФО 0,6 0,4
Весовые коэффициенты для П 0,8 0,2 0,5 0,3 0,2
Рис. 3. Апробация ПС
Литература
1. Андон, Ф. И. Основы инженерии качества программных систем [Текст] / Ф. И. Андон, Г. И. Коваль, Т. М. Коротун, Е. М. Лаврищева, В. Ю. Суслов.- К.: Академпериодика, 2007.- 672 с.
2. Goodman, F.A. Defining and deploying software processes [Text] / F.A. Goodman. — Auerbach Publications, 2006. — 221 p.
3. Madachy, R.J. Software process dynamics [Text] / R.J. Madachy. — Hoboken, NJ: IEEE Press-Wiley Interscience, 2008. -601 p.
4. Li, T. An Approach to Modelling Software Evolution Processes [Text] / T. Li. — Berlin-Heidelberg: Springer, 2008. — 213 p.
5. Abrahamsson, P. Agile Processes in Software Engineering and Extreme Programming [Text] / P. Abrahamsson, R. Baskerville, K. Conboy, et al. (eds.). — Berlin-Heidelberg: Springer, 2008. — 258 p.
6. Chrissis, M.B. CMMI: Guidelines for Process Integration and Product Improvement [Text] / M.B. Chrissis, M. Konrad. — Add-ison-Wesley, 2003. — 688 p.
7. Ahern, D.M. CMMI Distilled: A Practical Introduction to Integrated Process Improvement [Text] / D.M. Ahern, A. Clouse, R. Turner. — Addison-Wesley, 2008. — 288 p.
8. Годлевский, М. Д. Принципы моделирования оценки и управления качеством процесса разработки программного обеспечения [Текст] / М. Д. Годлевский, В. А. Шеховцов, И. Л. Брагинский // Східно-Європейський журнал передових технологій. — Харків. -2012. — № 5/3 (59). — С. 45−49.
9. Крючковский, В. В. Интроспективный анализ. Методы и средства экспертного оценивания [Текст] / В. В. Крючковский, Э. Г. Петров, Н. А. Соколова, В. Е. Ходаков. — Херсон: Гринь Д. С., 2011. — 168 с.
10. Годлевский, М. Д. Динамическая модель и алгоритм управления качеством процесса разработки программных систем на основе модели зрелости [Текст] / М. Д. Годлевский, И. Л. Брагинский // Проблемы информационных технологий. — Херсон: ОЛДИ — Плюс, 2012. — С. 6−13.
Е

ПоказатьСвернуть
Заполнить форму текущей работой