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

Язык программирования	Коэффициент пересчета		Язык программирования	Коэффициент пересчета
Ada	4,5		LISP	1,5
Assembler	1,0		Macro-Assembler	1,0
C	2,5		Pascal	3,5
C++	11,0		Query languages	25,0
Forth	5,0		Unix shell scripts	1,5
FORTRAN	3,0		4-th Generation Languages	16,0

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

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

Исторически первой группой метрик сложности стала сложность по Холстеду (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. Метрики сложности программы по Холстеду

Название метрики	Формула для подсчета
длина программы	N = η1 × log2 η1 + η2 × log2 η2
объем программы	V = N × log2 η
оценка длины реализации программы	L* = (2 × n2 )/ (n1 × N2)
уровень языка программирования	λ=L×V*
интеллектуальное содержание программы	I= L*×V

Цикломатическая сложность была введена Мак-Кейбом (Thomas J. McCabe) [18]; она является мерой топологической сложности схемы программы, рассматриваемой как граф передач управления в ней (control flow graph). Цикломатическое число λ(G) для графа G с n вершинами, m дугами и p компонентами связности вычисляется по формуле λ(G) = m – n + 2×p.

Число компонентов связности графа можно рассматривать как минимальное количество дуг, которые необходимо добавить для преобразования графа в сильно связный (сильно связным называется граф, любые две вершины которого взаимно достижимы). Для графов корректных программ; т.е., графов, не имеющих недостижимых от точки входа участков и "висячих" точек входа и выхода, сильно связный граф, как правило, получается путем замыкания дугой вершины, обозначающей конец программы, на вершину, обозначающую точку входа в эту программу. Таким образом, для односвязного графа управления с n вершинами и m дугами его цикломатическая сложность определяется как λ(G) =  m – n + 2.

По сути λ(G) определяет число линейно независимых контуров в сильно связном графе. Иначе говоря, цикломатическое число Мак-Кейба показывает требуемое количество проходов для покрытия всех контуров сильно связного графа или количество тестовых прогонов программы, необходимых для исчерпывающего тестирования по критерию "работает каждая ветвь". Цикломатическое число зависит только от количества предикатов в программе (т.е, условий ветвления), для которых не учитывается их сложность и уровень вложенности операторов, в котором они находятся. На практике это означает, что цикломатическая сложность равна числу разветвлений в программе (суммарному числу операторов IF, CASE и LOOP) плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом числа этих операторов (для оператора CASE берется число ветвей в нем без единицы).

К недостаткам этой метрики можно отнести ее нечувствительность к размеру программы, отсутствие корреляции со структурированностью программы, нечувствительность к вложенности циклов. Отмеченные недостатки цикломатической меры привели к появлению ряда ее модификаций, а также принципиально иных мер топологической сложности. Например, Майерс (Glenford J. Myers) предложил интервальную меру – интервал [λ₁, λ₂], где λ₁ – цикломатическая мера по Мак-Кейбу, а λ₂  – число отдельных условий (предикатов) плюс единица. При этом оператор DO считается за одно условие, а CASE c N исходами за N–1 условий. 

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

Все перечисленные метрики не связаны со сложностью алгоритма, реализуемого в программе, для которого есть точное математическое определение. В последнее время они редко используются в промышленной разработке программных продуктов; при оценке сложности программы разработчики предпочитают ориентироваться только на ее размер в KLOC или KAELOC.