Материал: DO178 Учебное пособие_в183

Изложение материала строится на основе классической модели зрелости способностей CMM/CMMI Института технологии программирования (Software Engineering Institute), описывающей процесс разработки программных продуктов. В конце каждого раздела приводятся вопросы и задания для самоконтроля за усвоением материала, предлагавшиеся студентам как контрольные задания.

Раздел 1 описывает жизненный цикл разработки в форме программного проекта для ролевой модели «Заказчик-Исполнитель», типичные деятельности, которые должны при этом исполняться в свете сложившихся в промышленности лучших практик, положенных в основу моделей CMM/CMMI зрелости способностей разработчика.

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

Раздел 3 дает краткое введение в модели зрелости способностей CMM/CMMI Института технологии программирования. Описываются 18 ключевых областей процесса разработки для CMM и 22 области процесса для CMMI и дается их сравнительный анализ.

Раздел 4 рассматривает настолько важный аспект в разработке программного продукта – анализ рисков и управление рисками в программном проекте, что в модели CMMI он даже выделен в отдельную процессную область.

Раздел 5 посвящен требованиям стандартов качества ISO 9000 применительно к разработке программного обеспечения. Рассматривается модель процессов ISO и связанные с этим методики самооценивания разработчиком степени своего соответствия этим стандартам ISO.

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

Раздел 7 рассматривает некоторые общие технологические приемы, полезные не только в программных проектах, но и других видах инженерной деятельности.

Раздел 8 посвящен специфическим для авиации требованиям к сертификации программного обеспечения и базовое для этого ПО понятие уровня безопасности компонентов ПО. Там рассматриваются те же базовые процессы (с добавлением процесса контакта с государственным органом сертификации, которого нет в моделях CMM/CMMI) с позиций сертификации ПО, как она определена в стандартах DO-178B, ED-12B и КТ-178В, и даются практические рекомендации по организации процесса создания ПО для авиационных систем и оборудования в расчете на его последующую сертификацию по требованиями упомянутых стандартов.

В разделе 9 приводятся темы для самостоятельных исследований и курсовых работ, предлагавшиеся в разное время студентам по курсу «Технология программирования».

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

Принятые сокращения

1.Жизненный цикл разработки по

1. Программные проект и его атрибуты

   1. Ролевые модели в программном проекте

Профессиональная разработка программного продукта (software product development) обычно осуществляется в рамках какого-либо программного проекта (software project), представляющего собой вид производственной экономической деятельности, в результате которой создается данный программный продукт. Известно несколько ролевых моделей, в рамках которых программные проекты выполняются.

Ролевая модель «Заказчик-исполнитель» называется так потому, что в ней явно определены роли, указанные в ее названии. Заказчик (customer) формирует основные исходные требования для программного продукта, финансирует его разработку и осуществляет приемку готового продукта, как правило, с отчуждением продукта от исполнителя и среды разработки, а исполнитель (developer) лишь выполняет разработку с достижением определенного уровня удовлетворенности ее результатом со стороны заказчика. Все права на такой программный продукт, включая все его промежуточные рабочие продукты, как правило, принадлежат заказчику, а исполнитель лишь получает оговоренную плату за выполненную работу при ее успешном завершении.

В ролевой модели «Инициативная разработка для неопределенного круга пользователей» нет явного заказчика; исходные требования к конечному продукту формирует сам исполнитель, исходя из собственного представления о будущих пользователях (users) и их потребностях в данном программном продукте. Права на такой рабочий продукт остаются у исполнителя, который может предоставлять лицензию на использование продукта желающим пользователям на определенных условиях, не обязательно включающих плату за пользование. В этой модели предполагается роль «спонсора проекта» (project sponsor); им обычно является какой-либо распорядитель бюджета, который принимает решение о финансовой поддержке проекта и его сроках, а также является последней инстанцией в разрешение конфликтных ситуаций в проекте.

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

Существуют и другие ролевые модели, включающие особенности перечисленных трех моделей в той или иной комбинации. Из всех известных моделей наиболее простой является ролевая модель «Заказчик-исполнитель», на которую и будет ориентироваться все дальнейшее изложение.

2. Размер и сложность программного проекта

Часто программный проект характеризуют размером создаваемого в нем продукта (большой, средний, небольшой) и его сложностью (проект высокой, средней или низкой сложности). Проект считается большим, если в нем нужно разработать более 50 тысяч строк кода (KLOC – K Lines Of Code, причем пустые строки или строки, содержащие только комментарии, не учитываются) и(или) более различных 50 интерфейсов с пользователем и(или) другими системами, если для него нужны разработчики со стажем работы не менее 5 лет, или если требуется применить какие-либо инновационные технологии или новое ПО. Для небольшого проекта все эти требования противоположны, а проект среднего размера занимает некоторое промежуточное положение. Существует ряд инструментов, подсчитывающих размер проекта, а многие трансляторы с языков программирования имеют эту функциональность как встроенную.

Если разные компоненты программного продукта создаются на разных языках программирования, то размер этого продукта определяется в KAELOC – K Assembler Equivalent Lines Of Code, а для пересчета KLOC в KAELOC используются переходные коэффициенты, эмпирически установленные для разных языков программирования (Табл. 1). С помощью этих же коэффициентов можно сравнивать программные продукты, написанные на разных языках.

Табл. 1. Пересчет KLOC в KAELOC

На сложность проекта могут быть индивидуальные точки зрения, но обычно заказчик и исполнитель быстро приходят к единому мнению по поводу этой его характеристики. Среди факторов, повышающих сложность проекта, обычно называют наложение фаз разработки, наличие субподрядчиков, географическую разобщенность исполнителей, включая их взаимодействие из разных стран, разработку встроенного ПО и совместную разработку аппаратуры и ПО.

Известными формальными критериями сложности программного продукта (программы) являются статические словарные и топологические группы метрик, а так же их комбинации и производные от них.

Исторически первой группой метрик сложности стала сложность по Холстеду (Maurice Halstead) [17], основанная на подсчете числа вхождений в текст программы двух видов программных единиц: операторов и операндов, по которым определяются следующие четыре базовых метрики:

η₁ – размер словаря операторов – число различных операторов языка программирования, включая символы-разделители, имена процедур и знаки операций, встречающихся в тексте программы;

η₂ – размер словаря операндов – число различных операндов, включая имена переменных и обозначения констант, встречающихся в тексте программы;

N₁ – общее число всех операторов в программе;

N₂ – общее число всех операндов в программ,

по которым определяются размер словаря данной программы: η = η₁ + η₂ и длина данной ее реализации: N = N₁ + N₂.

Холстед установил связь между размером словаря и длиной реализации:

N ≈ Ñ =

причем на представительной выборке текстов программ коэффициент корреляции реальной длины N с указанной оценкой Ñ составил 98%.

Другой важной и содержательной метрикой, введенной в рассмотрение Холстедом, был объем программы в битах: V = N log₂ η, поскольку log₂ η – это минимальное число бит, необходимое для различимого представления всех ее программных единиц. Введено также понятие потенциального объема программы V* для выражения данной программы в максимально сжатой форме в «идеальном языке», где все необходимые операторы уже имеются или определены в виде процедуры или подпрограммы. Для такой формы представления программы требуется знать только имена операндов для аргументов и результатов таких операторов. Отметив соответствующие базовые метрики в таком представлении звездочками, получаем, что

Поскольку в минимальном «идеальном языке» всего 2 типа операторов (вызов функции или процедуры и оператор присваивания) и ни операторы, ни операнды не требуют повторений , то и указанное уравнение сводится к:

где представляет собой число различных входных и выходных параметров программы. Таким образом, V* не зависит от языка, на котором написана программа и является разумной мерой ее «содержательности».

Используя введенные понятия, можно определить «уровень» конкретной реализации программы, зависящий от языка программирования:

L^*=

который равен 1 только для максимально «сжатых» реализаций; при увеличении объема программы уровень уменьшается и наоборот.

Холстед также вводит «интеллектуальное содержание» программы: I= L^*×V , которое может быть оценено непосредственно, исходя из базовых метрик программы:

и который приблизительно равен ее потенциальному объему V* и, таким образом, не зависит от языка программирования.

Поскольку с увеличение потенциального объема V* уровень программы L уменьшается в том же отношении, то их произведение λ=L×V* остается неизменным для всех программ на данном языке программирования, и поэтому его принято называть уровнем данного языка программирования.

Табл. 2. Метрики сложности программы по Холстеду