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