Систематическое использование метрик для количественного измерения показателей качества программного продукта и процессов ЖЦ

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

· Решению проблем поддержки количественного измерения атрибутов критического ПО с использованием метрик посвящен специальный процесс «Измерения» в категории «Процессы поддержки проекта» в опорной модели процессов жизненного цикла ПО международного стандарта ISO/IEC/IEEE 12207:2008.

Использование этого процесса при реализации практически всех процессов ЖЦ ПО является основой - обязательным нормативным требованием для того, чтобы добиться доказательности их выходных результатов. Это обуславливает включение процесса «Измерение» как объекта изучения для всех тем «Аттестационного задания». (You cannot control what you cannot measure! – руководящий принцип управления качеством)

2.3 Указанные выше специфические особенности методологии и технологий критической ПИ по существу учтены в предлагаемых для выбора темах настоящего «Методического руководства…» по (курсам) модулям учебной программы кафедры, посвящаемым углубленному изучению спецразделов ПИ, связанных с созданием и использованием критического ПО.

Перечень рекомендуемых тем «Аттестационного задания» сформирован на основе опорной модели процессов ЖЦ ПО (ISO/IEC/IEEE 12207:2008 «Системная и программная инженерия. Процессы ЖЦ ПО», а также состава информационных ресурсов, представляющих механизмы выполнения задач базовой системы менеджмента качества (СМК), реализующей стратегию TQM (всеобщего управления качеством). Функциональная IDEF0 модель СМК представлена на Рис.4 (дополнительная рекомендация: при выборе темы «Аттестационного задания» проанализируйте какие типы информационных ресурсов необходимы для выполнения работ СМК в целом и определите те из них, которые относятся к выбранной теме. Сопоставьте результаты анализа с ключевыми областями знаний дисциплины «Программная инженерия» (SWEBOK, 2004) и отразите это в Реферате (п.1 табл.1)

3 Сценарий «Аттестационного задания».

Сценарий определяет перечень, содержание и график выполнения работ «Аттестационного задания».

3.1 Исполнитель должен разработать индивидуальный план-график выполнения «Аттестационного задания». Использование стандартной техники диаграммы Ганта (см. например MS Project Manager) способствует развитию навыков планирования исследовательских работ и дисциплины самоконтроля исполнителя при индивидуальном выполнении «Аттестационного задания».

3.2 Общая концепция «Аттестационного задания» заключается в написании реферата по выбранной теме, вы результате выполнения частично-упорядоченного множества рабочих пакетов (шагов и задач), определенных в терминах «что надо сделать»-«как это сделать» (см. табл. 1), определяющих общий контекст (содержание) Сценария «Аттестационного задания».

3.3 В Табл.1 представлено нормализованное (в рамках данного «Методического руководства…») множество пошаговых инструкций, выполнение которых необходимо при наличии по любой выбранной теме «Аттестационного задания».

Каждый этап работ сценария представляет автономный функционально законченный рабочий пакет – WBS (Work Breakdown Structure), предназначенный для получения определенного выходного результата.

3.4 Базовой процедурой для выполнения любого рабочего пакета WBS является проведение экспресс-анализа и аналитических обзоров литературных источников из рекомендуемого перечня (см. электронный архив «Методического руководства…») и отобранных исполнителем самостоятельно в Internet по поисковым признакам Глоссария выбранной темы. Составление Глоссария является обязательной задачей при написании Введения Реферата (см. далее п.4.2 раздела 4).

3.5 Типовый сценарий «Аттестационного задания» в виде диаграммы Ганта представлен в Табл.2. Для конкретной темы объемы и сроки выполняемых работ детализируются и устанавливаются исполнителем индивидуально с учетом его начальной подготовки, интересов и возможностей. Рекомендуемая длительность WBS (рабочих пакетов) не более 2-3 недель. В целом типовой сценарий рассчитан на выполнение в течение одного-двух семестров (в соответствии с учебными планами выпускающей кафедры).

Таблица 1

№	Задание («что» надо сделать)	Способ решения («как» это сделать)
	Выбор темы «Аттестационного задания» и определение объекта изучения. Включает два рабочих пакета (WBS):
1.1 Определение состояния проекта ПО, к которому относится выбранная тема. Определение состава процессов ЖЦ, выполняемых в конкретном состоянии проекта ПО	а) Выбрать тему «Аттестационного задания» из перечня, рекомендуемых в разделе 5 настоящего «Методического руководства…». Объектом изучения по теме являются процессы ЖЦ критического ПО, связанные с выбранной темой «Аттестационного задания». б) Определение состава процессов ЖЦ для выбранной темы производится путем сопоставления на содержательном уровне и установления соответствия элементов Модели Переходов состояний проекта ПО (стандарт ECSS-E-ST-40), представленной на рис. 2, и Опорной модели процессов ЖЦ ПО стандарта ISO/IEC12207:08 «Системная и программная инженерия – Процессы жизненного цикла ПО», определяющей исчерпывающее множество стандартных процессов ЖЦ ПО и представленной на рис 1. Экспресс-анализ и сопоставление содержания выбранной темы и Модели Переходов Состояний проекта ПО в соответствии со стандартом ECSS-E-ST-40 (Рис 2) Определить спецификацию (состав) наиболее значимых для темы процессов жизненного цикла ПО, выполняемых в конкретном состоянии проекта ПО, как выборку (подмножество) процессов Опорной модели процессов ЖЦ ПО в соответствии со стандартом ISO/IEC/IEEE 12207:2008 (см. Рис. 1)
1.2 Детализация структуры объекта изучения выбранной темы	Руководствуясь стандартом ISO/IEC/IEEE 12207:2008, раскрыть структуру (архитектуру) спецификации процессов, выполняемых в конкретном состоянии проекта ПО в терминах: группа процессов, процессы в группе, назначение, рабочий выходной продукт, действия, задачи
	Определение и анализ предмета изучения выбранной темы. Включает три рабочих пакета (WBS):	Предметом изучения (предметной областью) выбранной темы в общем случае является методология и технология решения задач, определенных как объект изучения (см. п.1.2).
2.1 Направленный скрининг (screening – просеивание, отбор) литературных источников	Поиск, экспресс-анализ, отбор по признаку соответствия выбранной теме и аналитические обзоры литературных источников по теме (из списка рекомендуемых и отобранных исполнителем в Internet)
2.2 Аналитические обзоры отобранных источников отобранных источников по группам, посвященным различным аспектам методологии и технологий разработки и использования критического ПО.	Выполнить аналитические обзоры – рефераты по группам отобранных литературных источников для выбранной темы.
2.3 Определение предметной области выбранной темы в терминах ключевых областей знаний программной инженерии и с учетом специфических особенностей предметной области курса «Инженерия критического ПО»	Выбор на основе выполненных аналитических обзоров литературы вариантов методологии (и технологии), определяемых как предмет изучения выбранной темы в терминах: абстракции, методы декомпозиции, модели, методы, методики, метрики, инструментальные средства и среды, информационные технологии
	Написание реферата по предмету изучения выбранной темы	Реферативное изложение результатов раскрытия спецификации процессов ЖЦ ПО как объекта изучения и анализа предметной области выбранной темы на основе аналитических обзоров литературы в соответствии с рекомендациями раздела 4 настоящего «Методического руководства …».
	Сформулировать обоснованные выводы по теме, характеризующие назначение, существо, специфику предметной области реферируемых процессов ЖЦ ПО и соответствие рассмотренных в реферате вариантов «лучшим мировым практикам».	На основе аналитических обзоров литературы по предметной области темы.
	Написать Заключение о достижении целей «Аттестационного Задания»	Кратко определить (и перечислить) компетенции исполнителя, приобретенные в результате выполнения «Аттестационного задания» в терминах теоретической, технологической и мировоззренческой подготовки, включающей представления о взаимосвязях и тенденциях развития критической программной инженерии в рамках процессной парадигмы.
	Написание доклада–презентации по реферату.	Подготовить слайды (Power Point), иллюстрирующие основные результаты, выводы и заключение «Аттестационного задания».
	Представление Реферата и Доклада-презентации на кафедру для рецензии и аттестационной оценки.	В соответствии с установленным порядком взаимодействия с кафедрой при дистанционной форме обучения и расписанием работы кафедры в соответствующем семестре.

Таблица 2 Диаграмма Ганта

4 Общие требования к структуре и содержанию Реферата «Аттестационного Задания»

Структура Реферата должна включать следующие рубрики (компоненты)

· Название выбранной темы «Аттестационного задания».

· Введение

· Определение и реферативный анализ*) объекта изучения и предметной области выбранной темы

· Выводы

· Заключение

· Список фактически использованной литературы

· Доклад-презентация.

4.1 Название темы «Аттестационного задания» выбирается из приведенного ниже «Перечня рекомендуемых тем». (п.5 настоящего «Методического руководства…»)

4.2 Введение должно определять общий контекст дисциплины «Инженерия критического ПО», в котором производится реферативный анализ конкретной выбранной темы.

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

Написание Введения производится на основе проведенных исполнителем аналитических обзоров литературы в соответствии со Сценарием «Аттестационного задания».

Основным содержанием Введения должны являться:

а) Глоссарий – перечень терминов, понятий и определений;

б) Краткие аннотированные определения ключевых областей знаний и специфических особенностей предметной области курса «Критическая программная инженерия» в целом как общего дисциплинарного контекста для выбранной темы «Аттестационного задания»

При написании Введения рекомендуется охватить (рассмотреть) с учетом выбранной темы и интересов исполнителя следующие вопросы, определяющие специфику и общий контекст курса «Инженерия критического ПО» **):

· Оценка возможностей и пригодности различных концепций и стилей программирования для разработки критического ПО:

а) «искусство» (уникальные программные модели реального или виртуального миров);

б) «ремесло» (программный продукт типа «индпошив одежды» или «строительство особняка» для Заказчика с оценкой качества в стиле agile программирования, реально без сопровождения в эксплуатации);

в) «промышленность» (индустриальный подход в рамках коллективной разработки крупномасштабных, сложных, наукоемких проектов ПО, гарантии качества и безопасности, адекватная техническая документация, сопровождение и обслуживание в эксплуатации);

г) концепция «Разработка ПО методом сборки компонент на базе библиотек программно-аппаратных алгоблоков с использованием CASE-САПР (систем автоматизированного проектирования ИУС)

д) Концепция «ИУС на компонентах FPGA: программно-аппаратная реализация алгоритмов управления»

· Требования к критическому ПО:

а) возможности (capability) - функциональность (functionality, capacity), пропускная способность (performance), точность (accuracy)

б) ограничения (constraints) – гарантоспособность, безопасность, интерфейсы, платформа, языки, показатели качества и т.п., верификация требований, управление требованиями.

· Процессо-ориентированный подход к программной реализации возможностей (функциональности) ИУС критического применения (с учетом заданных ограничений) в различных отраслях науки и техники (матмоделирование при создании сложных технических объектов и систем, космическая техника, атомная энергетика, авиация, транспорт и т.п.), модели ЖЦ ПО – «дорожные карты», определяющие сеть процессов разработки критического ПО.

· Уровень критичности ПО - определяется величиной возможного (вероятного) ущерба в диапазоне «материальные потери – ущерб окружающей среде – угроза здоровью и жизни человека» из-за скрытых дефектов критического ПО при использовании его по назначению

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

· Качество – глобальная характеристика критического ПО как степень соответствия требованиям, включая требования к Гарантоспособности и Безопасности, Качество, как результат и показатель (мера, метрика) эффективности реализованного менеджмента в целом. Дуализм качества критического ПО, стратегия TQM, концепция (политика) непрерывного усовершенствования качества, процессная композиционная система менеджмента качества, реализующая стратегию TQM, - цели, задачи, критерии – кумулятивность, точность прогноза и рентабельность качества критического ПО.

· Управление (менеджмент) разработкой критического ПО – базовая модель менеджмента в процессной парадигме ПИ, управляемость, технологическая зрелость процессов ЖЦ.

· Верификация, Валидация, квалификационные испытания, сертификация критического ПО. Цели. Задачи. Методы. Проблема «комбинаторного взрыва» в пространстве состояний критического ПО. Полнота и достоверность тестирования при верификации, классификация методов (тестирование, имитационное моделирование, статический анализ текстов исходного ПО, формальный анализ ПО, Model-checking верификация с использованием темпоральной логики и инварианто-ориентированных моделей критического ПО).

· Динамическая спецификация критического ПО – ПО верхнего уровня или «сборочный чертеж» ПО как дискретная функция двух переменных (Т, х), , где Т- дискретное время, х – условие коммутации (вкл., выкл.) решаемых задач, циклические и разовые задачи, требования к операционным системам реального времени преодоление противоречия между параллельным развитием процессов внешней среды и последовательным характером обработки данных компьютером систем реального времени, статическое и динамическое планирование заявок на решение задач, приоритетное обслуживание заявок с вытеснением.

· Техническая документация проекта критического ПО, назначение, файл проектных определений и файл проектных обоснований (PDF project definition fail и PJF project justification fail поECSS-EST-40), управление информацией и управление конфигурациями, разрешение проблем и поддержка принятия решений в ЖЦ ПО (ISO/IEC/IEEE 12207:2008). Особенности agile-технологий и возможность (условия) их использования для критических приложений

· Нормативная база критического ПО. Стандарты предприятия – нормативная база (НБ) системы менеджмента качества, таксономия НБ (процессы, методики и метрики, производственные инструкции организации). Организация и направления разработки международных стандартов (ISO, IEC, ECSS, IAEA, EV, IEEE…). Адаптация к условиям конкретной организации, цели, технология, критерии, тематические бренды международных стандартов, определяющих требования к критической программной инженерии. Примеры (ISO/IEC 25000, ISO/IEC 15504, ISO/IEC/IEEE 12207, ECSS, IAEI…). Тенденции развития.

Скрининг – технологии формирования нормативных профилей проектов критического ПО на основе рекомендуемых для использования международных и национальных стандартов. Гармонизация требований (дизъюнктов) нормативных профилей проекта критического ПО.

4.3 Собственно Реферат должен быть написан в соответствии с рекомендациями раздела 3 «Сценарий Аттестационного Задания» и представлять реферативный (ссылочный) анализ объекта изучения и предметной области выбранной темы.

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

Особое внимание следует обратить на обеспечение отсутствия в Реферате признаков плагиата – заимствования текста без ссылок на первоисточник.

В тексте Реферате обязательно (shall!) должны быть ссылки в квадратных скобках
на фактически использованные литературные источники.

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

Выводы

В выводах рекомендуется представить:

а) Констатацию общего объема и особенностей проведенной аналитической работы по подбору, экспресс-анализу и аналитическим обзорам литературный источников по выбранной теме «Аттестационного Задания».

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

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

Заключение

Рекомендуется констатировать достижение цели и определить общий результат выполнения «Аттестационного задания» в терминах достигнутой компетентности (знаний, умений, представлений) исполнителя, определяющих его теоретическую, технологическую и мировоззренческую подготовку и готовность работать как в условиях строгого нормативного регулирования в сферах создания и использования критического ПО в различных отраслях науки и техники, так и в сферах использования agile-технологий программирования.