Некоторые из популярных сегодня моделей оценки стоимости ПО не совсем подходят для итерационного процесса создания ПО, в котором главное внимание уделяется упреждающей разработке архитектуры. Несмотря на успехи отдельных поставщиков инструментов для оценки стоимости ПО в распространении своих экспериментальных данных, многие по-прежнему используют экспериментальную базу традиционного процесса для выполнения оценок современного проекта. Этот раздел посвящен тому, какую структуру, с моей точки зрения, следует придать модели стоимости ПО для того, чтобы она лучше всего соответствовала оценке современного процесса создания ПО. В индустрии ПО существуют модели стоимости и способы оценки, поддерживающие отдельные части данного подхода. Моя модель стоимости ПО является исключительно теоретической; у меня нет никаких эмпирических свидетельств того, что этот подход является более точным, чем современные модели стоимости. Сегодня доступен целый ряд методов и технологий, необходимых для современного процесса управления, однако не существует соответствующих завершенных проектов, которые могли бы стать объективным обоснованием моих суждений.
В модели стоимости ПО следующего поколения разработка архитектуры должна быть явно отделена от производства приложения так же, как в процессе с упреждающей разработкой архитектуры. Стоимость разработки, производства, тестирования и сопровождения базовой архитектуры является функцией масштаба, качества, технологии, процесса и опыта команды. В модели стоимости архитектуры по-прежнему будет наличествовать некоторая плата за большой масштаб (показатель степени больше единицы), поскольку ей присуща ведущая роль в таких областях, как.
исследование и ориентация на разработку. После того как организации удается получить стабильную архитектуру, затраты на производство определяются экспоненциальной функцией размера, качества и сложности с более стабильными амплитудой процесса и влиянием персонала. Модель стоимости стадии производства должна отражать экономию при больших масштабах (показатель степени меньше единицы), аналогично традиционным экономическим моделям для массового производства товаров народного потребления. Гипотетическая модель стоимости для процесса с упреждающей разработкой архитектуры приведена на рис. 16.1.
С помощью моделей стоимости ПО следующего поколения нужно оценивать крупномасштабные архитектуры с экономией при больших объемах. Это предполагает, что показатель экспоненты процесса будет меньше единицы. Я объясняю это тем, что чем больше система, тем больше возможностей для применения автоматизации и для многократного использования процессов, компонентов и архитектур.
В случае традиционного процесса минимальный уровень автоматизации, поддерживающий вспомогательные виды деятельности по планированию, контролю над проектом и управлению изменениями, приводит к тому, что многие рабочие процессы становятся трудозатратными, в результате приходится платить за большой масштаб. Отсутствие автоматизации управления было характерно как для организаций, разрабатывающих множество проектов, так и для отдельных проектов. Различные виды среды и инфраструктуры следующего поколения движутся в сторону автоматизации и стандартизации многих видов управленческой деятельности, по мере роста масштаба расходуя все меньший процент от общего объема работ на вспомогательные виды деятельности.
Повторное использование общих процессов на протяжении нескольких итераций в рамках одного проекта, нескольких версий в рамках одного продукта или нескольких проектов в рамках одной организации также позволяет избавиться от платы за большой масштаб. Основных источников дефектов и доработок удается избежать за счет применения предшествующего опыта и зрелых процессов. Разработка достоверных планов на базе заслуживающих доверия норм выполнения проекта и надежных компонентов позволяет исключить другие источники дефектов и доработок. В то время как повторное использование компонентов снижает объем производственных работ, повторное использование процессов, инструментов и опыта оказывает непосредственное влияние на экономию при больших масштабах.
Другое важное отличие этой модели стоимости заключается в том, что архитектура и приложения имеют различные единицы массы (масштаб против размера) и являются представлениями области решения. Масштаб может измеряться в терминах архитектурно значимых элементов (классы, компоненты, процессы, узлы), а размер может измеряться в SLOC или в мегабайтах выполняемого кода. Эти единицы измерения отличаются от единиц измерения в проблемной области, таких как отдельные требования или варианты использования. Описание проблемной области влечет за собой определение области решений.
Рис. 16.1. Модели стоимости следующего поколения.
Однако, как показано на рис. 16.2, для каждой конкретной проблемы существует множество решений, каждое из которых обладает определенной предполагаемой ценой. Ключевым аспектом при выборе из потенциальных решений является его стоимость. Из конкретных решений проблем можно получить более аккуратные и точные оценки стоимости. Из этого следует, что модель для оценки стоимости должна руководствоваться основными параметрами предполагаемого решения. Если ни одно из решений не является приемлемым по предполагаемой цене, то необходимо искать другие возможные решения либо изменять формулировку проблемы.
Рис. 16.2. Дифференциация возможных решений по оценке их стоимости.
Споры между апологетами функциональных точек и апологетами строк исходного кода — хороший показатель необходимости измерения как масштаба, так и размера. Мне думается, что функциональные точки являются более точными для количественного выражения масштаба архитектуры, в то время как SLOC точнее отражают размер компонентов, из которых состоит общая реализация. Красота применения SLOC заключается в том, что сбор информации может быть легко автоматизирован, и достигнуть точности тоже не представляет труда. Однако точность SLOC как единицы измерения объема сомнительна, что может приводить к неправильной интерпретации при использовании SLOC для абсолютных сравнений между различными проектами и организациями. В частности, это справедливо для ранних фаз проекта, если SLOC применяются для измерения масштаба. Во многих проектах SLOC успешно использовались в качестве меры общего объема на поздних стадиях жизненного цикла, когда наиболее важными оказываются измерения относительного объема изменений от месяца к месяцу по мере создания выпускаемых версий.
Ценность функциональных точек заключается в том, что они лучше приспособлены для отображения общего масштаба решения, независимо от реального размера и языка программирования, выбранного для окончательной реализации. Однако функциональные точки непросто извлекать из строгих форматов представления, поэтому автоматизация и отслеживание внесенных изменений оказываются трудными или неоднозначными.
Строгая нотация для рабочих продуктов проектирования является необходимой предпосылкой каких-либо улучшений качества оценки масштаба разработки. В будущем я ожидаю появления новых возможностей для автоматизации измерения масштаба непосредственно из рабочих продуктов проектирования, представленных в виде моделей UML.
Я ожидаю двух основных улучшений в моделях оценки стоимости ПО следующего поколения:.
1.
Отделение стадии разработки от стадии производства приведет к необходимости отличать масштаб архитектуры от размера реализации. Это позволит получить большую аккуратность и более «честную» точность при оценках на протяжении всего жизненного цикла.
2.
Строгие нотации, такие как UML, предоставят более стандартизованные единицы измерения масштаба, что предполагает возможность автоматизации и отслеживания. Такие измерения будет проще соотносить со стоимостью продукции.
Количественное выражение масштаба архитектуры ПО на стадии разработки — это область для проведения исследований. В течение следующего десятилетия в процессе создания ПО окажутся возможными два прорыва, каждый из которых будет осуществляться за счет технологических преимуществ в среде сопровождения. Первый прорыв — появление интегрированных инструментов, которые обеспечат автоматизацию преобразования информации между различными элементами требований, проекта, реализации и внедрения. Такой инструментарий приведет к более объемлющей «круговой» разработке. Основным содержанием второго прорыва будет уменьшение сегодняшних четырех комплектов фундаментальных технических рабочих продуктов до трех за счет автоматизации видов деятельности, связанных с написанием программного кода вручную, что избавит от необходимости иметь отдельный комплект реализации. Такая технологическая возможность (см. рис. 16.3) позволит получать выполняемые программы непосредственно из UML-представлений без вмешательства человека. Инструментарий визуального моделирования уже способен создавать фрагменты кода из UML-моделей, однако получение завершенных фрагментов является делом будущего.
Если первый прорыв будет рискованным, но простым, то второй станет изменением всей парадигмы. Когда команда разработчиков сможет производить рабочие продукты реализации и внедрения в рамках свободной от ошибок автоматизированной среды, процесс разработки ПО изменится разительно, примерно так же, как изменилось производство чипов при переходе к процессу «печатания».