А Современные процессы создания ПО являются итерационными.

А Современные среда разработки и среда сопровождения представляют собой механизм для автоматизации процесса.

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

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

1.

Уменьшение размера или сложности того, что предстоит разрабатывать.

2.

Усовершенствование процесса разработки.

3.

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

4.

Использование лучшей среды (инструментария для автоматизации процесса).

5.

Достижение уступок и компромиссов для пороговых значений качества.

Эти параметры приведены в порядке значимости для большинства видов ПО. В таблице 3.1 перечислены некоторые усовершенствования в технологии, шаги по повышению эффективности процесса и управленческие подходы, направленные на улучшение экономики разработки и интеграции ПО.

Таблица 3.1.

Важные тенденции совершенствования экономики ПО

Большинство экспертов ПО заметят тесную взаимозависимость между этими направлениями. Например, инструментарий позволяет уменьшить размер и улучшить процесс. Уменьшение размера привносит изменения в сам процесс, а совершенствование процесса изменяет требования к инструментарию. Рассмотрим ПО пользовательского интерфейса. Лет двадцать тому назад командам, разрабатывающим пользовательский интерфейс, пришлось бы потратить много времени на анализ операций, экранных форм, динамики изменения экранного представления и на учет человеческого фактора. Все это приходилось выполнять на бумаге, поскольку перевод разработок в форму выполняемого кода, даже в виде неформальных прототипов, оказывался чрезвычайно дорогим. Таким образом, в этом процессе особое внимание уделялось тяжеловесному набору «бумажных» материалов, полученных на ранних этапах разработки, а также достижению согласия с пользователями для того, чтобы эти «требования» могли быть заморожены и чтобы можно было минимизировать высокую стоимость разработки.

Технология графического пользовательского интерфейса (GUI) является хорошим примером инструментария, обеспечивающего применение нового и измененного процесса. По мере того как технология GUI совершенствовалась, традиционный процесс взаимодействия с пользователем устаревал. Инструментарий для построения GUI позволяет командам разработчиков создавать готовый пользовательский интерфейс быстрее и с меньшей стоимостью. Теперь нет необходимости в описаниях на бумаге; фактически они являлись препятствием на пути к повышению эффективности процесса. Анализ операций и человеческого фактора по-прежнему остается важным, но теперь это можно делать в той реальной среде, в которой продукт будет использоваться, с применением уже существующих примитивов и строительных блоков. Циклы разработки и доработки, которые обычно тянулись месяцами, теперь могут выполняться за нескольких дней или недель. Старый процесс позволял лишь убедиться в том, что пользовательский интерфейс полностью проанализирован и разработан, поскольку в рамках проекта мог осуществляться только один цикл создания. Новый процесс направлен на проверку пользовательского интерфейса посредством создания нескольких реальных версий с постоянным внесением изменений, возникающих в результате обратной связи с пользователем, и на достижение устойчивого понимания требований и проблем разработки во взаимном равновесии.

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

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

3.1 УМЕНЬШЕНИЕ РАЗМЕРА ПРОГРАММНОГО ПРОДУКТА.

Наиболее действенным способом, повышающим возврат инвестиций (ROI), обычно является создание продукта, который достигает выполнения поставленных перед ним задач с помощью минимального количества исходного материала, написанного человеком. В данном случае компонентно-ориентированная разработка (component-based development) представлена как общий способ уменьшения размера программы на «исходном» языке программирования, который необходим для решения поставленных задач. Повторное использование, объектно-ориентированная технология, автоматическая генерация кода и языки программирования более высокого уровня — все это направлено на создание требуемой системы с меньшим количеством операторов исходного кода, написанных человеком. Уменьшение размера — главная движущая сила применения языков программирования более высокого уровня (таких, как C++, Ada 95, Java, Visual Basic и языков четвертого поколения), автоматических генераторов кода (CASE-средств, средств визуального моделирования, построителей GUI), повторного использования коммерческих компонентов (операционных систем, сред для работы с окнами, систем управления базами данных, промежуточного ПО, сетей) и объектно-ориентированных технологий (UML, средств визуального моделирования, архитектурных решений).

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

3.1.1 Языки.

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

полезными единицами измерения для оценки объема ПО становятся SLOC — строки исходного кода. Важные соотношения между SLOC и функциональными точками приводятся в работе [Jones, 1995]. Некоторые из этих соотношений представлены в таблице 3.2.

Таблица 3.2.

Языковая выразительность некоторых из наиболее популярных современных языков

Эти данные хорошо иллюстрируют причину заинтересованности в таких современных языках, как C++, Ada 95, Java и Visual Basic: они обладают весьма привлекательным уровнем выразительности. Однако применять эти данные следует осторожно, поскольку существует большая вероятность неправильного их употребления. Я убежден, что они отражают важные соотношения, но цифры кажутся слишком уж точными. (Без сомнения, они представляют собой среднее нескольких приблизительных значений.) Каждый язык имеет свою область применения. Visual Basic оказывается чрезвычайно выразительным и мощным при построении простых интерактивных приложений, но вряд ли будет разумным использовать его при создании бортовой программы для авиации, выполняющейся в реальном времени. Аналогично, Ada 95 может оказаться наилучшим языком для системы управления атомной электростанцией, результатом сбоя которой может стать атомная катастрофа, но вряд ли он подойдет для сильно распараллеленной, перемалывающей горы чисел научной задачи, выполняемой на суперкомпьютере. Подобные данные, имеющие отношение к индустрии ПО и распространяющиеся на различные области применения, корпорации и поколения технологий, должны интерпретироваться и использоваться с величайшей осторожностью.

Эти данные позволяют сделать два интересных наблюдения, касающихся отличий и связей между Ada 83 и Ada 95, с одной стороны, и между С и C++, с другой. Интерес Министерства обороны США к развитию языка Ada 83 частично объяснялся желанием повысить его выразительность. (Среди других причин были надежность, поддержка программирования задач в реальном времени, простота сопровождения и.

гарантированный ROI за счет стандартизации языка.) Серьезной экономической мотивацией была возможность создавать программу, содержащую существенно меньшее число строк кода, чем требовалось при использовании в качестве альтернативы традиционных языков программирования — FORTRAN, COBOL, С и ассемблера. В язык Ada было включено огромное количество технологических возможностей для разработки ПО, среди которых управление конфигурацией на уровне языка, отделение интерфейса от реализации, примитивы управления архитектурой, инкапсуляция, поддержка параллелизма и многое другое. Ada 95 представляет собой хорошо спланированное расширение языка, направленное на приведение его в соответствие с новыми технологиями и на учет уроков, извлеченных из приложений в разных областях. Различие в выразительности между Ada 83 и Ada 95 заключается в основном в тех особенностях, которые были введены в язык с целью поддержки объектно-ориентированного программирования. Таким образом, в первом приближении ценность использования объектно-ориентированного программирования заключается в том, что оно позволяет писать программы, содержащие на 30% меньше строк исходного кода.

Еще более глубокое различие существует между языками С и C++. C++ включает в себя некоторые (хотя и не все) из преимуществ языка Ada, например поддержку объектно-ориентированного программирования. С другой стороны, язык C++ разрабатывался так, чтобы поддерживать язык С как собственное подмножество. Такой подход имеет свои «за» и «против». Совместимость с языком С позволила программистам, работающим на С, легко перейти на язык C++. Но обратной стороной оказывается известное в индустрии ПО явление: существует значительное количество программистов, использующих компилятор C++, но при этом программирующих на С-подмножестве, что не позволяет им достигать выразительности объектно-ориентированного языка C++. Развитие языка Java позволило решить многие проблемы C++ (в частности, исторически сложившуюся поддержку языка С, которая вдохновляла на определенные опасные программистские трюки), сохранив при этом объектно-ориентированные возможности и добавив переносимость и распределенность.

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

1 ООО ООО строк на ассемблере.

400 ООО строк на языке С.

220 ООО строк на языке Ada 83.

175 ООО строк на языке Ada 95 или C++.

Эти значения показывают относительную выразительность различных языков. Коммерческие компоненты и автоматические генераторы кода (такие, как CASE-средства и построители GUI) способны обеспечить.

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

75 ООО строк на языке Ada 95 или C++ при использовании.

нескольких коммерческих компонентов.

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

3.1.2 Объектно-ориентированные методы и визуальное моделирование.

Как известно, в 90-е гг. имело место широкое движение за использование объектно-ориентированной технологии. Я уделяю этой теме мало внимания, поскольку данная технология не имеет отношения к обсуждаемым здесь темам, касающимся управления созданием ПО, и по объектно-ориентированной технологии издано множество книг. В результате некоторых исследований можно прийти к выводу, что объектно-ориентированные языки программирования позволили получить выигрыш как в производительности при создании ПО, так и в качестве ПО [Jones, 1994], хотя экономический выигрыш еще требуется доказать, поскольку стоимость обучения объектно-ориентированным методам разработки, таким как UML, непомерно высока.

Предоставляя более формализованные нотации для отображения и визуализации абстракций ПО, объектно-ориентированная технология оказывает фундаментальное влияние, которое заключается в уменьшении общего размера того, что требуется разработать. Буч описал три другие причины, которые привели к успешному завершению конкретных объектно-ориентированных проектов [Booch, 1996]. Это интересные примеры взаимозависимости между различными направлениями совершенствования экономики ПО. (Цитаты выделены курсивом.).

1.

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

А. Это пример того, как объектно-ориентированная технология позволяет вносить соответствующие улучшения в работу команды и в межличностные взаимоотношения.

2.

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

!.

а Этот аспект объектно-ориентированной технологии предоставляет возможность использовать процесс упреждающей разработки архитектуры, при котором интеграция является ранней и растянутой во времени процедурой жизненного цикла.

3.

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

А Эта особенность объектно-ориентированной технологии критична по отношению к используемым для реализации объектно-ориентированной архитектуры языкам и среде.

Буч также сформулировал пять характеристик успешного объектно-ориентированного проекта:.

1.

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

2.

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

3.

Эффективное использование объектно-ориентированного моделирования.

4.

Наличие четких представлений об архитектуре.

5.

Применение грамотно управляемого итерационного и пошагового жизненного цикла разработки.

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

3.1.3 Повторное использование.

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

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

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

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

■ У них имеется экономическая мотивация продолжительной поддержки.

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

■ У них достаточно широкая клиентская база для того, чтобы получать прибыль.

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

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

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

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

3.1.4 Коммерческие компоненты.

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

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

Таблица 3.3.

Достоинства и недостатки коммерческих компонентов по сравнению с ПО, создаваемым на заказ