Результат:
установлены связь и понимание с органом сертификации на протяжении всего ЖЦ для содействия процессу сертификации.
сертификация ПО совершается государственным органом сертификации (ГОС) в аспекте безопасности всей системы воздушного судна по запросу организации-разработчика, которая определяет уровень ПО и предоставляет в ГОС необходимые документы по его разработке и контакты с участниками;
сертификация проводится путем изучения этих рабочих документов и опросов участников разработки экспертами ГОС;
цель сертификации состоит в выработке обоснованных ответов на вопросы о достижении в процессе разработки данного ПО целей, сформулированных в DO-178C для соответствующего уровня ПО;
для уровня А в DO-178C заданы 69 целей, для D – только 30 из них;
успешность сертификации во многом зависит от устойчивости и определенности установленного процесса разработки, сравнимого с уровнями 3 и 4 модели CMMI;
для успешной сертификации необходимы современные средства автоматизации процесса разработки – единый каркас для разработки ПО, настроенный на данную предметную область, организацию-разработчик и требования DO-178C.
Проведите инвентаризацию существующих в Вашей организации рабочих процессов и активов по разработке бортового ПО и соотнесите их с положениями DO-178C.
Составьте план пошагового приближения Вашей организации к требованиям DO-178C, включив в него регулярные самооценивания достижения целей.
Предлагаемые 6 тем для дипломных и курсовых работ связаны с проектом создания единого каркаса для управления разработкой приложений (UFADM – Unified Framework for Application Development Management) на базе свободно распространяемой операционной системы Линукс (Linux). Каркас имеет модульную структуру и включает себя компоненты, как для системного управления процессом разработки, так и для непосредственной реализации приложений.
Этот единый каркас позволяет оптимальным образом решать типовые задачи управления разработкой ПО:
постановка задачи с анализом предметной области и уточнением ее онтологии;
сбор и анализ требований с их последующей формализацией и проверкой на полноту и непротиворечивость;
составление и анализ плана разработки, а также проверку его соответствия заданным ограничениями;
анализ рисков и разработка планов ответных действий;
разработка программной архитектуры проекта и ее анализ на соответствие исходным требованиям и главным качествам будущего продукта;
отслеживание тестового покрытия исходных требований по различным заданным критериям;
регулярное отслеживание хода разработки на основе постоянно собираемых метрических данных, и т.д.
При этом широко используется постоянно пополняемый репозиторий общих и конкретных решений для тех или иных задач, обеспечивающий высокий уровень повторного использования уже существующих наработок. В зависимости от степени охвата поставленной задачи и ее уточнений, каждая работа может быть как дипломной, так и курсовой, а также как индивидуальной, так и групповой (2-4 студента).
Для каждой темы дается ее краткое описание, квалификационные требования, необходимые для ее выполнения, ожидаемый результат и оценка трудоемкости.
Тема 1. Пользовательские требования к базовому инструменту для распределенного управления программными проектами
Тема 2. Программная архитектура базового инструмента для распределенного управления программными проектами
Тема 3. Профили типовых рабочих компонентов для разработки приложений
Тема 4. Прототип метрической базы данных для управления разработкой приложений
Тема 5. Репозиторий повторно используемых компонентов
Тема 6. Сквозной пример для единого каркаса разработки приложений
Тема 1. Пользовательские требования к базовому инструменту для распределенного управления программными проектами
Задача. Определить представительный набор существующих инструментальных средств и известных подходов к подобным системам, провести их сравнительный анализ и на этой базе создать модель требований к единому каркасу.
Квалификационные требования. Знание основных этапов и моделей жизненного цикла разработки ПО, умение выявлять и анализировать неформальные требования к программному продукту, знание средств UML (Unified Modeling Language) для представления формальных моделей и систем формализации требований. Владение средствами представления результатов анализа и принятия решений.
Ожидаемый результат. Документ «Пользовательские требования к единому каркасу для управления разработкой приложений» в стандартизованном формате, содержащий отобранные требования с их обоснованием, приоритетами и оценками трудоемкости реализации, удовлетворяющие известным критериям полноты, непротиворечивости, проверяемости и т.д. Набор тестовых сценариев и тестовых наборов с таблицей тестового покрытия (Test Coverage Matrix – TCM), конструктивно проверяющих выполнение всех функциональных требований.
Трудоемкость. 6 человеко-месяцев.
Примечание. Для выполнения проекта должен быть составлен план, выбраны метрики отслеживания хода проекта, вестись еженедельная отчетность по исполнению текущих задач и ежемесячная отчетность в виде операционного обзора.
Задача. Разработать и обосновать программную архитектуру единого каркаса для управления разработкой приложений.
Квалификационные требования. Знание основных этапов и моделей жизненного цикла разработки ПО, умение выявлять и анализировать неформальные требования к программному продукту, знание основных подходов к созданию и анализу программных архитектур, средств для их представления. Владение средствами представления результатов анализа и принятия решений.
Ожидаемый результат. Документ «Программная архитектура единого каркаса для управления разработкой приложений» в стандартизованном формате, содержащий описание программной архитектуры с ее обоснованием.
Трудоемкость. 4 человеко-месяца.
Примечание. Для выполнения проекта должен быть составлен план, выбраны метрики отслеживания хода проекта, вестись еженедельная отчетность по исполнению текущих задач и ежемесячная отчетность в виде операционного обзора. В процессе работы должны быть рассмотрены, как минимум, 3 альтернативные архитектуры, удовлетворяющие поставленным требованиям, и проведено обоснование окончательного выбора.
Задача. Используя литературу и практический опыт известных производителей ПО, разработать и собрать воедино типовые профили рабочих компонентов для единого каркаса для управления разработкой приложений.
Квалификационные требования. Знание основных этапов и моделей жизненного цикла разработки ПО, умение выявлять и анализировать неформальные требования к программному продукту, знание основных подходов к созданию и анализу программных документов, средств для их представления. Владение средствами представления результатов анализа и принятия решений. Понимание процессов сертификации разработчиков по моделям CMM/CMMI и стандартам ISO 9000, а также сертификационных требований к ПО для авиационных бортовых систем и оборудования DO-178 и КТ-178.
Ожидаемый результат. Библиотека шаблонов для типовых рабочих продуктов, документ «Руководство пользователя по созданию рабочих продуктов при разработке приложений», содержащий описание этих рабочих продуктов и их шаблонов с обоснованием их выбора и структуры в зависимости от модели жизненного цикла. Уточненные наборы метрик рабочих продуктов, необходимых для объективной сертификации разработчиков и создаваемого ПО. Автоматизированная система определения этих метрик для последующего метрического анализа и сертификации.
Трудоемкость. 6 человеко-месяцев.
Примечание. Для выполнения проекта должен быть составлен план, выбраны метрики отслеживания хода проекта, вестись еженедельная отчетность по исполнению текущих задач и ежемесячная отчетность в виде операционного обзора.
Задача. Используя литературу и практический опыт известных производителей ПО, разработать схему и типовое наполнение метрической базы данных для единого каркаса для управления разработкой приложений.
Квалификационные требования. Знание основных этапов и моделей жизненного цикла разработки ПО, умение выявлять и анализировать неформальные требования к программному продукту, знание основных подходов к созданию и анализу программных документов, средств для их представления. Знание теории баз данных, практические навыки в работе с распространенными БД. Владение средствами представления результатов анализа и принятия решений.
Ожидаемый результат. Схема и типовое наполнение метрической базы данных для единого каркаса для управления разработкой приложений с обоснованием.
Трудоемкость. 4 человеко-месяца.
Примечание. Для выполнения проекта должен быть составлен план, выбраны метрики отслеживания хода проекта, вестись еженедельная отчетность по исполнению текущих задач и ежемесячная отчетность в виде операционного обзора. В процессе работы должны быть рассмотрены, как минимум, 3 альтернативные схемы, удовлетворяющие поставленным требованиям, и проведено обоснование окончательного выбора.
Задача. Используя литературу и практический опыт известных производителей ПО, разработать схему и начальное наполнение репозитория повторно используемых компонентов для разработки приложений средствами единого каркаса с возможностью автоматизированного поиска и составления статистических отчетов.
Квалификационные требования. Знание основных этапов и моделей жизненного цикла разработки ПО, умение выявлять и анализировать неформальные требования к программному продукту, знание основных подходов к созданию и анализу программных документов, средств для их представления. Знание теории баз данных, практические навыки в работе с распространенными БД. Знание средств XML (Extended Markup Language), подхода Twiki. Владение средствами представления результатов анализа и принятия решений.
Ожидаемый результат. Схема и начальное наполнение репозитория повторно используемых компонентов для единого каркаса для управления разработкой приложений с обоснованием. Автоматизированная система поиска компонентов по запросам. Система составления статистических отчетов по текущему состоянию репозитория и повторных использований его содержимого.
Трудоемкость. 6 человеко-месяцев.
Примечание. Для выполнения проекта должен быть составлен план, выбраны метрики отслеживания хода проекта, вестись еженедельная отчетность по исполнению текущих задач и ежемесячная отчетность в виде операционного обзора. В процессе работы должны быть рассмотрены, как минимум, 3 альтернативные схемы, удовлетворяющие поставленным требованиям, и проведено обоснование окончательного выбора.