Национальный аэрокосмический университет им. Н.Е. Жуковского (ХАИ)
Учебное пособие
Методическое руководство
по выполнению Аттестационного задания
по курсу «Инженерия критического ПО»
(магистратура, дистанционная форма обучения, повышенная сложность)
Базовая версия
Дата редакции:
2013
«Методическое руководство по выполнению Аттестационного задания по курсу «Инженерия критического ПО» разработано авторской группой в составе:
кафедра «Инженерия ПО» НАКУ им. Н.Е. Жуковского «ХАИ»:
Конорев Б.М. – д.т.н., профессор кафедры «Инженерия ПО» НАКУ им. Н.Е. Жуковского «ХАИ»
Туркин И.Б. – д.т.н., профессор, заведующий кафедрой «Инженерия ПО» НАКУ им. Н.Е. Жуковского «ХАИ»
Соколова Е.В. – к.т.н., доцент кафедры «Инженерия ПО» НАКУ им. Н.Е. Жуковского «ХАИ»
Сергиенко В.В. – к.т.н., руководитель испытательной лаборатории ХХП «Сертификационный центр АСУ» ГП «Госцентркачества»
кафедра «Компьютерные системы и сети» НАКУ им. Н.Е. Жуковского «ХАИ»:
Харченко В.С. – д.т.н., профессор, заведующий кафедрой «Компьютерные системы и сети» НАКУ им. Н.Е. Жуковского «ХАИ»
Тарасюк О.М. – к.т.н., доцент кафедры «Компьютерные системы и сети» НАКУ им. Н.Е. Жуковского «ХАИ»
кафедра «Теоретическая и прикладная информатика» ХНУ им. В.Н. Каразина:
Жолткевич Т.Н. – д.т.н., профессор, заведующий кафедрой «Теоретическая и прикладная информатика» ХНУ им. В.Н. Каразина
Зарецкая И.Т. – к.т.н., доцент кафедры «Теоретическая и прикладная информатика» ХНУ им. В.Н. Каразина
Владимирова М.В. – к.т.н., доцент кафедры «Теоретическая и прикладная информатика» ХНУ им. В.Н. Каразина
кафедра «Моделирование систем и технологий» ХНУ им. В.Н. Каразина:
Мищенко В.О. – д.т.н., профессор кафедры «Моделирование систем и технологий» ХНУ им. В.Н. Каразина
Содержание
1 Назначение. Общие положения. 6
1.1 Методическое руководство по выполнению Аттестационного задания по курсу «Инженерия критического ПО» (далее – «Методическое руководство…») определяет технологию выполнения индивидуального «Аттестационного задания» при углубленном изучении специальных разделов системной и программной инженерии, посвященных проблематике создания и использования критического ПО. 6
1.2 «Аттестационное задание» по существу заключается в написании Реферата и Доклада-презентации по выбранной теме. Основанием для написания реферата должны служить проведенные исполнителем исследования литературных источников из рекомендуемого перечня и самостоятельно отобранных в Internet по признаку принадлежности к объекту и предмету (предметной области) изучения по выбранной теме. 6
1.3 Содержание Реферата «Аттестационного задания» должно доказательно отражать достижение исполнителем (студентом) уровня компетентности, адекватного требованиям современных международных (SWEBOK, PMBOK) и национальных (Нормативы МОН Украины) образовательных стандартов, а так же передовым мировым достижениям – «лучшим практикам» в области создания и использования критического ПО в различных прикладных областях. 6
1.4 Целью «Аттестационного задания» является формирование элементов теоретической, технологической и мировоззренческой подготовки современного специалиста, развитие умения и навыков исследований в сфере критической программной инженерии, обеспечение готовности специалиста к работе в сфере создания критических программных приложений, как в условиях жесткого нормативного регулирования, так и в условиях использования agile-технологий. 6
1.5 «Методическое руководство…» рассчитано на студентов старших курсов университета, проходящих обучение по программам подготовки специалистов и магистров при очной, заочной и дистанционной формах обучения. 6
Предполагается наличие соответствующей подготовки студента в области компьютинга (информатики, компьютерных наук, информационных технологий, программной инженерии и т.д.) в объемах соответствующих учебных программ университета. 6
1.6 В процессе выполнения «Аттестационного задания» предусматривается необходимый объем индивидуального дистанционного взаимодействия исполнителя с кафедрой (преподавателем), включающий консультации по выбору темы, отбору и аналитическим обзорам литературы, написанию реферата, выводов, заключения и презентационного доклада по теме, получение рецензии кафедры и аттестационной оценки по изучаемому модулю. 6
2 Общая характеристика предметной области курса «Инженерия критического ПО» 7
(Раздел носит иноформационно-справочный характер). 7
2.1 Предметная область дисциплины «Инженерия критического ПО» является существенной частью предметной области в целом дисциплины «Программная инженерия», представленной ее «Ключевыми областями знаний» (SWEBOK, PMBOK 2004). В силу этого она в той или иной мере пересекается с предметными областями других дисциплин Компьютинга (компьютерные науки, информатика, информационные технологии т.д.), имея в то же время четко выраженную специфику [10, 11, 24-29]. 7
2.2 Специфика дисциплины «Инженерия критического ПО» определяется концентрацией ее интересов (проблематики) вокруг следующих специальных проблем системной и программной инженерии [6, 7, 18-21, 15, 13]: 7
2.2.1 Методология проектирования критического ПО 7
2.2.2 Квалификационные испытания критического ПО [1, 2, 3, 6, 3, 15]: 12
2.2.3 Управление качеством критического ПО 13
2.2.4 Базовая модель менеджмента в сфере «Программная инженерия». 13
14
2.2.5 Уровень критичности. Риски. Безопасность (функциональная и информационная). Оценка и регулирование величины рисков, связанных со скрытыми дефектами критического ПО. 17
2.2.6 Отчуждаемость критического ПО. 17
2.2.7 Систематическое использование метрик для количественного измерения показателей качества программного продукта и процессов ЖЦ. 18
2.3 Указанные выше специфические особенности методологии и технологий критической ПИ по существу учтены в предлагаемых для выбора темах настоящего «Методического руководства…» по (курсам) модулям учебной программы кафедры, посвящаемым углубленному изучению спецразделов ПИ, связанных с созданием и использованием критического ПО. 19
3 Сценарий «Аттестационного задания». 20
3.1 Исполнитель должен разработать индивидуальный план-график выполнения «Аттестационного задания». Использование стандартной техники диаграммы Ганта (см. например MS Project Manager) способствует развитию навыков планирования исследовательских работ и дисциплины самоконтроля исполнителя при индивидуальном выполнении «Аттестационного задания». 20
3.2 Общая концепция «Аттестационного задания» заключается в написании реферата по выбранной теме, вы результате выполнения частично-упорядоченного множества рабочих пакетов (шагов и задач), определенных в терминах «что надо сделать»-«как это сделать» (см. табл. 1), определяющих общий контекст (содержание) Сценария «Аттестационного задания». 20
3.3 В Табл.1 представлено нормализованное (в рамках данного «Методического руководства…») множество пошаговых инструкций, выполнение которых необходимо при наличии по любой выбранной теме «Аттестационного задания». 20
3.4 Базовой процедурой для выполнения любого рабочего пакета WBS является проведение экспресс-анализа и аналитических обзоров литературных источников из рекомендуемого перечня (см. электронный архив «Методического руководства…») и отобранных исполнителем самостоятельно в Internet по поисковым признакам Глоссария выбранной темы. Составление Глоссария является обязательной задачей при написании Введения Реферата (см. далее п.4.2 раздела 4). 20
3.5 Типовый сценарий «Аттестационного задания» в виде диаграммы Ганта представлен в Табл.2. Для конкретной темы объемы и сроки выполняемых работ детализируются и устанавливаются исполнителем индивидуально с учетом его начальной подготовки, интересов и возможностей. Рекомендуемая длительность WBS (рабочих пакетов) не более 2-3 недель. В целом типовой сценарий рассчитан на выполнение в течение одного-двух семестров (в соответствии с учебными планами выпускающей кафедры). 20
4 Общие требования к структуре и содержанию Реферата «Аттестационного Задания» 25
4.1 Название темы «Аттестационного задания» выбирается из приведенного ниже «Перечня рекомендуемых тем». (п.5 настоящего «Методического руководства…») 25
4.2 Введение должно определять общий контекст дисциплины «Инженерия критического ПО», в котором производится реферативный анализ конкретной выбранной темы. 25
4.3 Собственно Реферат должен быть написан в соответствии с рекомендациями раздела 3 «Сценарий Аттестационного Задания» и представлять реферативный (ссылочный) анализ объекта изучения и предметной области выбранной темы. 27
4.4 Выводы 28
4.5 Заключение 28
4.6 Список фактически использованной литературы. 28
4.7 Доклад-презентация по теме должен быть представлен в виде 5-7 слайдов Power Point и рассчитан на приблизительно семиминутный доклад, охватывающий выбор и определение объекта изучения, общую характеристику проведенных аналитических обзоров литературы, представление предметной области изучаемой темы, соответствие «передовым мировым практикам», выводы и заключение. 28
5 Перечень рекомендуемых тем «Аттестационного задания». 29
5.1 Процессная парадигма инженерии критического ПО.) 30
5.2 Качество критического ПО 32
5.3 Управление разработкой программных средств. 33
5.4 Квалификационные испытания критического ПО. 35
5.5 Методология разработки критического ПО. 36
5.6 Модели качества процессов ЖЦ ПО SPICE. 37
5.7 Модели качества программного продукта SQuaRE 38
5.8 Полимодельная инварианто – ориентированная Model-checking верификация. 39
5.9 Динамическая спецификация критического ПО 40
5.10 Статический анализ в инженерии критического ПО. 41
5.11 Нормативная база инженерии критического ПО 42
5.12 Управление конфигурациями ПО. Повторное использование ПО. 44
6 Рекомендуемая литература. Электронный архив 45
1Назначение. Общие положения.
1.1Методическое руководство по выполнению Аттестационного задания по курсу «Инженерия критического ПО» (далее – «Методическое руководство…») определяет технологию выполнения индивидуального «Аттестационного задания» при углубленном изучении специальных разделов системной и программной инженерии, посвященных проблематике создания и использования критического ПО.
1.2«Аттестационное задание» по существу заключается в написании Реферата и Доклада-презентации по выбранной теме. Основанием для написания реферата должны служить проведенные исполнителем исследования литературных источников из рекомендуемого перечня и самостоятельно отобранных в Internet по признаку принадлежности к объекту и предмету (предметной области) изучения по выбранной теме.
1.3Содержание Реферата «Аттестационного задания» должно доказательно отражать достижение исполнителем (студентом) уровня компетентности, адекватного требованиям современных международных (SWEBOK, PMBOK) и национальных (Нормативы МОН Украины) образовательных стандартов, а так же передовым мировым достижениям – «лучшим практикам» в области создания и использования критического ПО в различных прикладных областях.
1.4Целью «Аттестационного задания» является формирование элементов теоретической, технологической и мировоззренческой подготовки современного специалиста, развитие умения и навыков исследований в сфере критической программной инженерии, обеспечение готовности специалиста к работе в сфере создания критических программных приложений, как в условиях жесткого нормативного регулирования, так и в условиях использования agile-технологий.
1.5«Методическое руководство…» рассчитано на студентов старших курсов университета, проходящих обучение по программам подготовки специалистов и магистров при очной, заочной и дистанционной формах обучения.
Предполагается наличие соответствующей подготовки студента в области компьютинга (информатики, компьютерных наук, информационных технологий, программной инженерии и т.д.) в объемах соответствующих учебных программ университета.
1.6В процессе выполнения «Аттестационного задания» предусматривается необходимый объем индивидуального дистанционного взаимодействия исполнителя с кафедрой (преподавателем), включающий консультации по выбору темы, отбору и аналитическим обзорам литературы, написанию реферата, выводов, заключения и презентационного доклада по теме, получение рецензии кафедры и аттестационной оценки по изучаемому модулю.
2Общая характеристика предметной области курса «Инженерия критического ПО»
(Раздел носит иноформационно-справочный характер).
2.1Предметная область дисциплины «Инженерия критического ПО» является существенной частью предметной области в целом дисциплины «Программная инженерия», представленной ее «Ключевыми областями знаний» (SWEBOK, PMBOK 2004). В силу этого она в той или иной мере пересекается с предметными областями других дисциплин Компьютинга (компьютерные науки, информатика, информационные технологии т.д.), имея в то же время четко выраженную специфику [10, 11, 24-29].
2.2Специфика дисциплины «Инженерия критического ПО» определяется концентрацией ее интересов (проблематики) вокруг следующих специальных проблем системной и программной инженерии [6, 7, 18-21, 15, 13]:
2.2.1Методология проектирования критического ПО
В контексте настоящего «Методического руководства…» методология проектирования критического ПО представляется согласованным набором соответствующих моделей, методов, методик и метрик, общего руководства (концепции) по их совместному использованию на различных этапах ЖЦ ПО для достижения демонстрируемого требуемого уровня качества проекта критического ПО.
Методология в общем случае определяется выбором иерархии абстракций и используемыми методами декомпозиции ПО как объекта разработки при реализации принципа «разделяй и властвуй». К числу широко используемых относятся объектно-ориентированный, компонентно-ориентированный, функционально-ориентированный и др. подходы и их разновидности [1, 24-29].
Разница между методологией и технологией заключается в том, что технология является производным понятием от методологии, определяя на процедурном уровне методики, метрики и инструментальное оснащение выполняемых работ при реализации выбранной методологии.
Методы программной реализации функциональности ИУС критического использования должны учитывать следующие специфические факторы:
Обеспечение корректности представления темпоральной логики в спецификациях и реализации критического ПО,
реальное время – глобальный параметр критического ПО (явно или по умолчанию),
взаимодействие ПО с физическим оборудованием,
существование рисков ущерба (потерь), связанных с недостаточным качеством – скрытыми дефектами критического ПО при реализация необратимых операций.
В соответствии с концепцией международных стандартов качества серии ISO 9000 ПО представляет одну из четырех базовых категорий продукции (наряду с оборудованием, услугами и сырьем-материалами), производимых и используемых в различных сферах деятельности человечества.
ПО как продукт программной инженерии является результатом реализации сети производственных процессов. Международным стандартом ISO/IEC/IEEE 12207:2008 «Системная и программная инженерия – Процессы жизненного цикла ПО» определена Опорная (ссылочная) модель процессов ЖЦ ПО (Process Reference Model) [1] (рис.1). Модель включает семь категорий процессов системной и программной инженерии, обеспечивающих исчерпывающее стандартное (унифицированное) представление всех типов процессов, выполняемых при использовании различных моделей ЖЦ программных продуктов (приложений).
Рис.1. Опорная модель процессов ЖЦ ПО системной и программной инженери
Согласование системного и программного контекстов процессов ЖЦ ПО («наблюдение» за состоянием реализации специальных процессов ПО в общем контексте системной инженерии) осуществляется с использованием модели переходов состояний проекта в соответствии со стандартом ECSS-ST-E-40 «Программное обеспечение», представленной на рис.2 [6.13]. Механизм переходов реализуется с использованием стандартных процессов Review и Audit опорной модели ISO/IEC/IEEE 12207:2008 «Системная и программная инженерия – Процессы жизненного цикла ПО».
Выбор абстракций. Декомпозиция (реализация принципа «разделяй и властвуй» - “divide et impera”). Нотации (графические языки, проектные зарисовки – adornment, аксиоматика, синтаксис) [6.14].
Реализация «4+1» парадигмы представления архитектуры критического ПО (рис. 3), определяющей сбалансированную совокупность форм представления проектных решений архитектурного проекта: «1» - функции, «2» - компоненты, «3» - динамические спецификации, «4» - размещение на платформе, «4+1» - множество вариантов использования.
Языки описания архитектуры (Architecture framework and architecture description languages – ADL) на основе стандарта ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия – описание архитектуры» [3].
Управление требованиями и обоснование объемов имитационного моделирования (при верификации), обеспечивающих требуемую полноту тестового покрытия и минимизацию скрытых дефектов критического ПО в условиях действия факторов:
Заказчик критического ПО часто узнает, что ему надо и может сформулировать полные требования к ПО после получения варианта разработанного ПО;
Объективно действует тенденция “creep requirement” (ползучесть, изменчивость требований) при создании сложных систем (а тем более систем беспрецедентной сложности) и необходимость, как следствие, реализация технологии создания ряда функциональных прототипов разрабатываемого критического ПО.
Такие технологии позволяют управлять полнотой и достоверностью исходных данных и требований к разработке критического ПО при использовании спиральной модели ЖЦ ПО в рамках как классических, так и agile-технологий.
Анализ, метрики и оценка композиционной, многокомпонентной характеристики качества критического ПО «Гарантоспособность» (Dependability), включающей субхарактеристики Надежность, Готовность, Обслуживаемость, Безопасность (в ряде случаев).