В 80-х и 90-х гг. индустрия создания ПО перешла в разряд инженерной дисциплины. Однако большинство проектов по созданию ПО этого периода.

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

2.1 ЭКОНОМИКА ПО.

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

1.

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

2.

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

3.

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

4.

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

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

Соотношение между рассчитываемой стоимостью и этими параметрами может быть записано следующим образом:.

Трудоемкость = (Персонал)(Среда)(Качество)(Размер

).

Для оценки стоимости ПО создано несколько параметрических моделей; все они, вообще говоря, могут быть сведены к такой форме. Один из важных аспектов экономики создания ПО (как это представляется в современных моделях определения стоимости ПО) заключается в том, что связь между работой и размерами определяет плату за большой масштаб. Плата за большой масштаб при разработке ПО является результатом того, что показатель экспоненты процесса больше единицы. В отличие от большинства производственных процессов, чем больше ПО создается, тем дороже оно обходится в пересчете на одну единицу. Например, для некоторого произвольного приложения программное решение объемом в 10 ООО строк обойдется дешевле в пересчете на одну строку, чем программное решение объемом 100 ООО строк. На сколько дешевле? Предположим, что для создания 100 000-строчной системы требуется 900 человеко-месяцев, или около 111 строк за один человеко-месяц, или 1.37 часа на одну строку. Если бы та же самая система состояла из 10 000 строк при неизменных остальных параметрах, то проект оценивался бы приблизительно в 62 человеко-месяца, или 175 строк за один человеко-месяц, или.

0.87 часа на одну строку. (На рис. В.1 в приложении В дается более подробное описание этого примера с использованием модели оценки стоимости СОСОМО.) Стоимость одной строки для меньшего приложения.

оказывается гораздо ниже таковой для большего приложения. Причина этого заключается прежде всего в сложности управления межличностными взаимодействиями по мере того, как число членов команды (и соответственно число целей, условий их достижения, технических предпочтений) возрастает. Эта плата за большой масштаб характерна для любого исследовательского проекта, продуктом которого является единственный в своем роде объект интеллектуальной собственности.

Намеченная цель: улучшение ROI

Рис. 2.1. Три поколения экономики создания ПО, ведущие к намеченной цели.

На рис. 2.1 показаны три поколения основных достижений технологии в части инструментария, компонентов и процессов. Необходимый уровень качества и персонал принимаются постоянными. По оси ординат откладывается стоимость единицы ПО (выберите, какая вам больше нравится: строка исходного кода (SLOC), функциональная точка, компонент), созданного некоей организацией. Ось абсцисс представляет жизненный цикл использования ПО в бизнесе данной организации. Три поколения процессов разработки ПО могут быть определены следующим образом:.

1.

Традиционный: 60-е — 70-е гг., кустарное производство. Организации используют кустарный инструментарий, куртарные процессы и практически все компоненты для заказчика пишутся на примитивных языках. Результат выполнения проекта был легко предсказуем в том смысле, что он практически никогда не укладывался в заранее заданные стоимость, сроки и качество.

2.

Переходный: 80-е — 90-е гг., программная инженерия. Организации используют воспроизводимые процессы и готовые инструменты, а большинство создаваемых компонентов (>70%) пишется на языках высокого уровня. Некоторые компоненты (системы, системы управления базами данных, сетевое ПО и графический интерфейс пользователя. В течение 80-х гг. некоторые организации начинают достигать экономии при больших масштабах, однако с ростом сложности приложений (особенно при переходе к распределенным системам) существовавшие языки, методы и технологии оказались недостаточными для того, чтобы поддерживать требуемый уровень промышленного создания.

3.

Современная практика: начиная с 2000 г., производство ПО. Философия этой книги заключается в применении управляемых и измеряемых процессов, интегрированных сред автоматизации и по большей части (70%) готовых компонентов. Возможно, всего лишь 30% компонентов следует создавать на заказ. Используя преимущества технологии создания ПО и интегрированных сред разработки, можно очень быстро создавать системы, построенные из компонентов.

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

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

Рис. 2.2. Возврат инвестиций в различных областях применения.

Организации достигают большей экономии при больших масштабах в течение технологически успешных периодов — в рамках очень больших проектов (системы систем), продуктов долговременного использования и продуктовых линий, включающих в себя множество однотипных проектов. Рис. 2.2 дает общее представление о том, каким образом можно достичь соответствующего вида кривой возврата инвестиций (ROI, Return On Investment) при последовательных усилиях в течение всего жизненного цикла для различных областей применения.

2.2 ПРАКТИЧЕСКАЯ ОЦЕНКА СТОИМОСТИ ПО.

Одной из важных проблем при оценке стоимости ПО является отсутствие хорошо документированных практических примеров проектов, в которых применялась итерационная разработка. Хотя авторы моделей оценки стоимости и заявляют, что их инструментарий пригоден для оценки проектов, использующих итерационную разработку, лишь немногие из них основываются на эмпирических данных проектов, в которых итерационная разработка была успешной. Более того, поскольку индустрия ПО оперирует противоречивыми метриками и основными единицами измерения, то данные по конкретным проектам оказываются весьма подозрительными с точки зрения их непротиворечивости и возможности сравнения. Сбор однородных данных по проекту в рамках одной организации оказывается довольно сложным; чрезвычайно сложен сбор однородных данных по разным организациям, использующим различные процессы, языки, подходы и т.д. Например, фундаментальное понятие — единица измерения размера (строка исходного кода или функциональная точка) — вычисляется везде по-разному. Кажется удивительным, что стандарты современных языков (таких, как Ada 95 и Java) не имеют определения понятия строки исходного кода для подсчета их компилятором. То, какое именно определение (функциональной точки или строки исходного кода^ЬОС)) будет применено, не столь важно, точно так же, как конкретная длина фута или метра может быть абсолютно произвольной. Необходимо лишь, чтобы все пользовались одним и тем же определением.

Среди разработчиков и поставщиков моделей и средств для оценки стоимости ПО давно идут различные споры. Для нас практический интерес представляют три темы этих споров:.

1.

Какую модель оценки стоимости ПО следует использовать.

2.

Следует ли измерять объем ПО в строках исходного кода или в функциональных точках.

3.

Что может считаться хорошей оценкой.

В индустрии ПО между собой конкурируют около 50 поставщиков средств, данных и услуг по оценке стоимости ПО. Известны общедоступные модели и средства для оценки стоимости ПО (такие, как СОСОМО, CHECKPOINT, ESTIMACS, KnowledgePlan, Price-S, ProQMS, SEER, SLIM, SOFTCOST и SPQR/20), а также огромное количество моделей, применяемых в конкретных организациях. Поскольку мой первый опыт использования этих моделей был связан с СОСОМО и ее производными — Ada СОСОМО и СОСОМО II, именно эти модели служат основой моих аргументов и взглядов на перспективы развития экономики ПО. Кроме того, СОСОМО является одной из наиболее открытых и хорошо документированных моделей оценки стоимости. Процесс превращения СОСОМО в современную версию — СОСОМО II — описан в приложении В. Некоторые части этого приложения не могут напрямую использоваться в сегодняшних методах и технологиях, тем не менее оно дает интересную ретроспективу эволюции проблем и приоритетов экономики ПО за последние 20 лет.

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

Многие эксперты в области ПО утверждают, что SLOC — плохая единица измерения. Однако когда говорят, что сегмент программы содержит 1000 строк исходного кода, большинство людей способно представить себе ее общий размер. В случае же если программа описывается в терминах 20 функциональных точек, 6 классов, 5 вариантов использования, 4 объектных точек, 6 файлов, 2 подсистем, 1 компонента или 6000 байтов, то многие, включая экспертов ПО, начнут задавать дополнительные вопросы для того, чтобы получить представление об описываемом коде. (И многие спросят, а сколько же в ней SLOC.) Таким образом, SLOC оказывается единственной единицей измерения, которая до сих пор обладает определенной ценностью.

Десять лет тому назад я являлся ярым сторонником SLOC как единицы измерения, поскольку она хорошо работала в приложениях, которые создавались преимущественно на заказ, и поскольку измерения в SLOC было легко автоматизировать и осуществлять на практике. Сегодня же возможности современных языков и применение компонентов, автоматическая генерация исходного кода и ориентация на объекты сделали SLOC неточной единицей измерения. В приложении D в качестве характерного примера описываются тщательно проработанные подходы для подсчета SLOC с тем, чтобы они позволяли учитывать повторное использование, разработку на заказ и инструментарий для генерации кода в рамках большого проекта по созданию ПО.

Применение функциональных точек имеет много последователей, включая Каперса Джонса, который указывает на сложности, связанные с использованием SLOC для объектно-ориентированных программ [Jones, 1994]. Международный консорциум по использованию функциональных точек (the International Function Point User’s Group), образованный в 1984 г., является доминирующей ассоциацией по вопросам измерения ПО. Самым главным преимуществом применения функциональных точек является то, что этот метод не зависит от конкретной технологии и, таким образом, предоставляет элементарные единицы измерения для сравнения различных проектов и организаций. Основной его недостаток заключается в том, что определения абстрактны, а способ проведения измерений не вытекает непосредственно из входящих в него положений.

Оба способа измерения имеют свои недостатки, но я думаю, что можно пользоваться любым из них. Выполнить хоть какие-нибудь измерения лучше, чем не делать ничего. Каждому, кто пытается сравнивать разные проекты или разные организации, в качестве единиц измерения следует использовать функциональные точки. Кроме того, функциональные точки являются, вероятно, более точным способом измерения на ранних стадиях жизненного цикла проекта. На поздних же стадиях более полезной и более точной основой для различных измерений становится SLOC. В главе 16 представлена моя гипотеза о модели стоимости следующего поколения, которая могла бы позволить минимизировать или даже отказаться от необходимости проводить измерения в SLOC.

Общая точность традиционных моделей стоимости (таких, как СОСОМО) описывается как «в пределах 20% по стоимости, 70% по времени». Такой уровень непредсказуемости традиционного процесса разработки ПО отпугнет любого инвестора, особенно в свете того факта, что некоторые проекты не подтвердили своей оценки, а оказались лучше, чем ожидалось. Это интересное явление следует учитывать при планировании трудоемких работ. До тех пор пока не появляются дополнительные стимулы для опережения общего графика рАбот, проекты редко выполняются быстрее, чем планировалось. Почему? Команды и отдельные работники составляют собственные планы для выполнения своих задач. И если временные рамки оказываются не слишком жесткими, то они либо тратят свою энергию на посторонние занятия (дополнительное обучение, помощь другим или валяние дурака), либо продолжают повышать качество сверх необходимого уровня. Исполнители практически никогда не предлагают сократить сроки. Но даже если они и выступят с подобным предложением, то, вероятнее всего, наткнутся на сопротивление других сотрудников, с которыми им следует синхронизировать свою работу, Поэтому планы должны быть настолько амбициозными, насколько это возможно.

На самом деле, в большинстве случаев стоимостные модели используются «от противного» (для подтверждения объявленной стоимости), а вовсе не по прямому назначению (для определения той цены, которую следовало бы запросить). На рис. 2.3 показана обычная практика: менеджер проекта сначала определяет, какую цену следует объявить, а затем манипулирует параметрами и размерами до тех пор, пока не удается эту цену обосновать. Обоснованием объявленной цены может быть стремление выиграть тендер, выбить у заказчика финансирование, добиться финансирования внутри организации либо достигнуть каких-либо других целей.

Рис. 2.3. Обычный процесс определения стоимости.

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

Практика в этой области такова, что независимые оценки стоимости (т.е. выполненные людьми, которые никак не зависят от команды разработчиков) обычно неточны. Единственным способом, позволяющим получить заслуживающую доверия оценку, является следующий: компетентная команда — менеджер проекта вместе с менеджерами по созданию архитектуры, разработке и тестированию — выполняет несколько итераций по оценке стоимости и анализу чувствительности модели. Для того чтобы проект мог быть успешно выполнен, эта команда должна признать свое авторство произведенной оценки стоимости.

Из чего состоит хорошая оценка стоимости ПО? Этот непростой вопрос подробно обсуждается в главе 10. Если же говорить кратко, то у хорошей оценки должны быть следующие атрибуты:.

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

■ Она воспринимается всеми исполнителями как амбициозная, но выполнимая.

■ Она базируется на подробно описанной модели стоимости ПО, имеющей заслуживающее доверия основание.

■ Она основывается на данных по аналогичным проектам, которые включают в себя аналогичные процессы, аналогичные технологии, аналогичную среду, аналогичные требования к качеству и аналогичную квалификацию работников.

■ Она подробно описывается таким образом, чтобы все ключевые области риска были хорошо видны, а вероятность успеха оценивалась объективно.

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