Традиционное управление разработкой ПО

Традиционное управление разработкой ПО

самым лучшим качеством.
ПО является его гибкость: запрограммировать можно практически все что угодно. Худшим качеством ПО также является его гибкость. Это самое «практически все что угодно» сильно затрудняет планирование, мониторинг и управление разработкой ПО.
Ключевые моменты.
Традиционный подход к управлению созданием ПО кажется хорошим только в теории; на практике же он основывается на устаревших технологии и методах.
Традиционная экономика ПО позволяет получить точку отсчета для традиционных принципов управления созданием ПО.
Непредсказуемость — первопричина того, что в последние 30 лет называли «кризисом ПО».
В середине 90-х гг. были предприняты по крайней мере три важные попытки анализа состояния индустрии разработки ПО. Результаты были представлены в Patterns of Software Systems Failure and Success (Образцы успехов и неудач систем ПО) [Jones, 1996], в «Chaos» («Хаос») [Standish Group, 1995] и в Report of the Defense Science Board Task Force on Acquiring Defense Software Commercially (доклад научного совета по обороне, касающийся задачи увеличения количества ПО для оборонных целей, получаемого на коммерческой основе) [Defense Science Board, 1994], В приложении А приведены некоторые результаты, имеющие отношение к этому вопросу.
Эти три аналитических исследования привели к одному и тому же выводу: процент успешных проектов по созданию ПО чрезвычайно низок. По некоторым моментам имелись разногласия, но основные посылки хорошо согласовывались и дополняли друг друга. Выводы заключались в следующем:.
1.
Разработка ПО по-прежнему абсолютно непредсказуема. Только около 10% проектов по созданию ПО оказываются успешными, укладываясь в первоначальные бюджетные и временные рамки.
2.
Управление определяет успех или неудачу в большей степени, чем технологические преимущества.
3.
Количество «выброшенного на свалку» и переделанного ПО является показателем незрелости процесса.
Эти три работы ясно продемонстрировали сложность проблемы и современные нормативные показатели эффективности традиционного управления разработкой ПО. Здесь есть что совершенствовать.
В завершение главы дается обобщение процесса управления созданием ПО, который использовался в большинстве традиционных проектов. Поскольку у этого подхода, известного как водопадная (waterfall) модель, существует много производных, он является основополагающим для большинства проектов, опыт по которым накоплен к настоящему моменту. Обобщать всегда опасно, поэтому методы усовершенствования процесса, обсуждаемые на протяжении книги, должны рассматриваться в подходящем контексте.
1.1 ВОДОПАДНАЯ МОДЕЛЬ.
Большинство трудов по программной инженерии представляет водопадную модель как основу «традиционного» процесса создания ПО. Я же склонен рассматривать ее как показатель уровня этого процесса. Сначала мы изучим и подвергнем критике теорию водопадной модели, а затем посмотрим, как традиционный процесс создания ПО используется в промышленных целях. В действительности при промышленном подходе большинство теорий игнорируется, однако водопадной модели удается служить основой для многих удачных примеров (и многих неудачных), особенно при совместном применении с современными технологиями.
1.1.1 В теории.
В 1970 г. мой отец, Уинстон Ройс, опубликовал в IEEE WESCON статью «Managing the Development of Large Scale Software Systems» («Управление разработкой широкомасштабных систем ПО») [Royce, Winston, 1970]. Эта статья, основанная на уроках, извлеченных им в процессе руководства большими проектами по разработке ПО, и по сей день остается наиболее цитируемым источником по водопадной модели. В статье представлено глубокое и краткое изложение философии традиционного управления разработкой ПО того времени, и многие из рекомендаций тридцатилетней давности выдержали проверку временем, несмотря на большие изменения в технологии.
В статье были приведены три основополагающих момента. (Цитаты и перефразированные утверждения выделены курсивом.).
1.
Разработка компьютерных программ состоит из двух основных этапов: анализ и кодирование.
2.
Для того чтобы иметь возможность управлять и контролировать всю ту интеллектуальную свободу, которая присуща процессу разработки ПО, необходимо ввести несколько «сверхнормативных» этапов, включающих в себя определение системных требований, определение требований к программному обеспечению, разработку программы и тестирование. Эти этапы дополняют этапы анализа и кодирования. На рис. 1.1 показаны структура проекта и основные этапы разработки крупномасштабной программы.
,.
3.
Основной подход, описываемый водопадной моделью, является весьма рискованным и допускает неудачное завершение. Стадия тестирования, находящаяся в конце цикла разработки, - первый момент, где можно определить реальное время выполнения, объем занимаемой памяти, скорость ввода/вывода и т. д., чтобы сравнить их со значениями, установленными при анализе. Изменения, внесенные в программу, могут оказаться настолько разрушительными, что требования к ПО, на которых основывалась разработка программы, окажутся невыполненными. В таком случае придется либо пересмотреть требования, либо внести существенные изменения в структуру программы.
Пункт 1, кажущийся по началу тривиальным, ниже будет развернут в одну из моих основных тем, касающихся управления: отделение стадии разработки от стадии производства.
Семь из девяти страниц статьи посвящены описанию пяти условий, которые необходимы для усовершенствования основного водопадного процесса и могли бы исключить многие риски при разработке, указанные в пункте 3. Обсудим подробнее эти пять пунктов. (Цитаты и перефразированные утверждения выделены курсивом, за ними следуют комментарии автора в контексте сегодняшней технологии и терминологии.).
1. Проектные решения первичны. Прежде всего необходимо включить стадию предварительного проектирования программы между стадией формирования требований к ПО и стадией анализа. Таким способом разработчик программы может убедиться в том, что она не окажется непригодной из-за изменения объема занимаемой памяти, времени выполнения и данных. При переходе к стадии анализа разработчик программы должен передать аналитику налагаемые ограничения по времени, памяти и операциям таким способом, чтобы тот смог оценить последствия. Если суммарные требуемые ресурсы окажутся неприемлемыми либо если в проект изначально вкрались ошибки, это будет установлено на ранней стадии, и итерация с определением требований и предварительным проектированием может быть повторена до начала основного проектирования, кодирования и тестирования. Каким же образом реализуется эта процедура разработки программы ? Необходимо предпринять следующее:.
Водопадная модель, часть 3:.
Пять условий, необходимых для работы этого подхода
Водопадная модель, часть 1: Два основных этапа построения программы
1.
Завершайте проектирование программы до начала анализа и кодирования.
2.
Ведите документацию полно и своевременно.
3.
Выполняйте работу дважды, если это возможно.
4.
Планируйте, контролируйте и наблюдайте за тестированием.
5.
Привлекайте к работе заказчика.
Рис. 1.1. Водопадная модель.
Начинайте процесс проектирования с разработчиками программ, а не с аналитиками или программистами.
Продумайте, опишите и распределите режимы обработки данных, обращая внимание на риск появления возможных ошибок. Распределите функции обработки, создайте базу данных, установите время.
выполнения, определите интерфейсы и режимы взаимодействия с операционной системой, опишите режимы ввода/вывода и предварительно определите эксплуатационные процедуры.
Составьте обзорный документ - понятный, информативный и соответствующий текущему положению вещей - с тем, чтобы каждый работающий над проектом мог получить из него детальное представление о системе.
А Существо схемы процесса, представленной в последующих главах, — упреждающая разработка архитектуры (architecture-first development). Хотя некоторые термины могут меняться (например, вместо термина «проект программы» используется термин «архитектура»), существо современного процесса соответствует приведенным здесь объяснениям. Как будет описано ниже, архитектура первична, она определяется и разрабатывается параллельно с планированием и формированием требований, являясь одной из составляющих частей стадии разработки проекта.
2.
Документируйте проект. Объем документации, необходимой для компьютерных программ, довольно велик; он намного больше того объема, который готовы создать программисты, аналитики или разработчики программ, если оставить их наедине со своими компьютерами. Зачем же требуется так много документации ? (1) Каждый разработчик должен обмениваться информацией с разработчиками интерфейсов, менеджерами и, возможно, заказчиками. (2) На ранних стадиях документация - это и есть проект. (3) Истинная ценность документации заключается в том, что она позволяет поддерживать на более поздних этапах изменения, выполняемые отдельной группой тестирования, отдельной группой сопровождения и группой эксплуатации, которые не знают ПО.
А Если не обращать внимания на технологические несоответствия того времени, когда была написана статья, то существо посылки «документируйте проект» остается в силе. Понятное изложение основных моментов, доступное всем исполнителям и группам, по-прежнему остается существенным. Однако по причине больших изменений, произошедших с системами обозначений, языками, браузерами, инструментами и методами, необходимость во многих документах отпала. В последующих главах я отстаиваю ту точку зрения, что сосредоточивать свое внимание на документации ошибочно и непродуктивно. Это является следствием того, что сегодняшние технологии поддерживают скрупулезные и самодокументируемые системы обозначений для описания требований, структур и реализаций.
3.
Выполняйте работу дважды. Если компьютерная программа разрабатывается впервые, добейтесь того, чтобы версия, которая в конце концов попадет к заказчику для реального использования, была бы на самом деле второй, хотя бы для наиболее критичных проектных/эксплуатационных решений. Заметьте, что это всего лишь миниатюрная копия полного процесса, требующая соответственно малых затрат времени.
Работающая над первой версией команда должна быть особенно компетентна, что позволит быстро обнаружить проблемные точки в проекте, смоделировать их и альтернативные им решения, не обращая внимания на очевидные аспекты разработки, которые несущественны на ранних стадиях, и в результате получить программу, свободную от ошибок.
а Это — краткое и упрощенное описание упреждающей разработки архитектуры. Ответственность за начальную разработку возлагается на «архитектурную группу». Обобщение такой практики приводит к появлению подхода «выполняйте работу N раз», на котором основывается современная итерационная разработка (см. ниже).
Без этого первого прохода менеджер проекта вынужден полагаться на мнение разработчиков. С «моделированием» же первого прохода у него появляется возможность экспериментальной проверки некоторых ключевых гипотез. Но во всем остальном ему придется полагаться на человеческую оценку, которая в области разработки компьютерных программ (так же, как и при определении максимально допустимого взлетного веса, стоимости проекта или победителя на скачках) неизменно и существенно оптимистична.
а Это замечательное описание духа итерационной разработки и присущих ей преимуществ в управлении рисками.
4. Планируйте, контролируйте и следите за тестированием. Без всякого сомнения, самым главным потребителем ресурсов, выделенных на проект (человеко-дней, машинного времени и/или управленческого анализа), является стадия тестирования. Эта стадия наиболее рискованна с точки зрения стоимости выполнения и соблюдения графика работ. Она обычно является завершающим этапом, когда вернуться назад и пойти по другому пути вряд ли возможно (или вообще невозможно). Три предыдущие рекомендации имели целью поиск и исправление ошибок до начала стадии тестирования. Однако даже при соблюдении этих рекомендаций все равно приходится переходить к стадии тестирования и все равно остаются некоторые важные вещи, которые необходимо выполнить, а именно: (1) задействовать группу специалистов для проведения тестирования, которые не несут никакой ответственности за исходную разработку; (2) выполнить визуальные проверки для обнаружения очевидных ошибок, таких как отсутствие знаков «минус», пропуск множителей двойки, переход по неверному адресу (не следует использовать компьютер для выявления подобного рода ошибок, это слишком накладно); (3) протестировать все логические ветви программы; (4) произвести окончательную проверку на том компьютере, на котором будет применяться программа.
а Среди этих советов есть несколько хороших и несколько устаревших. Пункты 1 и 4 по-прежнему важны. Пункт 2 на сегодняшний день является распространенным способом проверки качества (применение инспекций ПО), но его цель в том виде, в котором она изложена здесь, устарела.
Подобный подход мог быть хорошим и эффективным по стоимости при использовании технологии 1970 г., но не современных подходов. Компьютеры, компиляторы, анализаторы и прочие инструменты являются более эффективными механизмами поиска очевидных ошибок. Что касается пункта 3, то тестирование всех логических ветвей программы и в 1970 г. было уже довольно непростой задачей даже без учета тех сложностей, которые привнесли распределенные повторно используемые компоненты и другие усложняющие факторы. И конечно же, это абсолютно неосуществимо для большинства современных систем. Особенно это касается распределенных вычислений, для которых время является дополнительным измерением, а число логических ветвей практически бесконечно. В современном процессе тестирование происходит на протяжении всего жизненного цикла, что, при правильном его выполнении, требует намного меньше суммарных ресурсов и позволяет находить ошибки на более ранних стадиях жизненного цикла, когда еще существует возможность использования альтернативных решений.
5. Привлекайте к работе заказчика. По ряду причин проектные решения являются предметом, допускающим широкую интерпретацию даже после достижения предварительного соглашения. Важно привлечь клиента к работе формальным путем с тем, чтобы он был вовлечен в разработку на ранних ее стадиях и до окончательной сдачи проекта. Существуют три стадии, следующие за определением требований, на которых введение в курс дела, оценки и участие заказчика могут способствовать успеху разработки. Это «предварительный обзор ПО», следующий за этапом предварительной разработки программы, серия «критических обзоров структуры ПО» в процессе разработки программы и «окончательный обзор принимаемого ПО», который идет за тестированием.
А Введение в курс дела использовалось в течение многих лет, и везде результаты оказывались положительными. Привлечение заказчика к предварительным демонстрациям и к оценке альфа/бета-версий является проверенной и ценной практикой.
Я всегда восхищался тем, насколько проницательной оказалась эта статья. В то время как многие тратили всю свою энергию, пытаясь опровергнуть подход, предлагаемый водопадной моделью, мне удалось найти минимальное количество изъянов в этой теории, даже с учетом применения ее в контексте современной технологии. Критике следовало бы подвергнуть практику использования этого подхода, которая включает в себя некоторые необоснованные и неработающие элементы. Я подозреваю, что большинство критиков никогда по-настоящему не понимали этой теории; они знакомы лишь с обычной практикой.
На протяжении всей книги я буду ссылаться на практику применения в прошлом и в настоящем того подхода, который предлагается водопадной моделью и который далее при обсуждении называется «традиционным» подходом к управлению процессом создания ПО. Я готов поспорить, что этот процесс не является хорошим подходом для современных разработок и технологий, и я буду использовать его в качестве отправной точки при рационализации процесса с целью его усовершенствования, что позволит избавиться от некоторых его врожденных пороков.
1.1.2 На практике.
Несмотря на рекомендации многих экспертов и теорий, более поздних по отношению к водопадной модели, в целом ряде проектов по-прежнему используется традиционный подход к управлению созданием ПО. Поскольку в настоящее время его применение сокращается, я буду говорить о нем в прошедшем времени.
Сформулируем краткие характеристики традиционного процесса в том виде, в котором он обычно использовался, что, вообще говоря, может и не совпадать с тем, как он должен был использоваться на самом деле. Проекты, в которых приходилось сталкиваться с/трудностями, зачастую имели следующие проблемы:.
■ Затянувшаяся интеграция и позднее обнаружение ошибок, допущенных при разработке.
■ Позднее разрешение рисков.
■ Функциональная декомпозиция, определяемая требованиями.
■ Противостояние между участниками проекта.
■ Чрезмерное внимание, уделяемое документации и совещаниям для обмена мнениями.
Затянувшаяся интеграция и позднее обнаружение ошибок, допущенных при разработке.
На рис. 1.2 показан ход разработки в зависимости от времени в случае традиционного проекта, использующего водопадную модель управления. Прогресс определяется как процент написанного кода, т.е. того, что можно доказательно признать готовым. (Написанный код может быть транслирован и выполнен, при этом он необязательно является полным, совместимым или соответствующим спецификациям.) В таких случаях обычным является следующее:.
■ Раннее завершение этапа «бумажного» проектирования и подробная (зачастую излишне) постановка задач.
■ Переход к кодированию на поздних этапах жизненного цикла.
■ Кошмарные трудности при интеграции, возникающие из-за непредвиденных проблем при реализации и из-за неточностей в интерфейсах.
■ Жестко регламентированные бюджет и время сдачи системы.
■ «Втискивание» неоптимальных решений в тот момент, когда уже не остается времени на перепроектирование.
■ Трудно сопровождаемый сырой продукт, передаваемый заказчику с опозданием.
При тех несовершенных языках и технологиях, которые использовались в традиционном подходе, особое внимание уделялось прежде
Формат
Специальный.
текст
Блок-схемы
Исходный код
Базовые.
конфигурации
Деятельность
Анализ.
требований
Разработка.
программы
Кодирование и тестирование модулей
Затянувшаяся интеграций и тестирование
Продукт
Документация
Документация
Кодированные.
модули
Временные.
настройки
Рис. 1.2. Ход разработки в традиционном проекте.
всего тщательной «разработке ПО», и только после этого начиналось создание ПО на языке программирования, когда понимание и внесение изменений становится затруднительным. Подобная практика предполагала применение множества различных форматов (требования — на естественном языке, предварительная разработка — в виде блок-схем, детальная разработка — на языках разработки программ, а окончадельная реализация — на языках программирования, таких как FORTRAN, COBOL и С) и чреватых ошибками, трудоемких переводов из одного формата в другой.
Традиционные методы, применявшиеся в процессе разработки при использовании водопадной модели, неминуемо приводили к запоздалой интеграции и к устойчивым системным ошибкам в работе программы. В традиционной модели вся система создавалась сначала на бумаге, затем целиком реализовывалась, затем интегрировалась. И только по окончании этого процесса становилось возможным тестирование системы, позволяющее убедиться в том, что основная архитектура (интерфейсы и структура) разработана правильно. Одной из распространенных особенностей проектов, для реализации которых применяется традиционный подход, является то, что на проведение тестирования тратится 40% или более от всех ресурсов. В таблице 1.1 представлено типичное распределение затрат по всему спектру действий, выполняемых при создании ПО.
Таблица 1.1.
Затраты на различные виды деятельности в традиционном проекте
Деятельность
Затраты
Менеджмент
5%
Определение требований
5%
Проектирование
10%
Кодирование и тестирование модулей
30%
Интеграция и тегтироьлве
40%
Ввод в действие
5%
Создание среды разработки
5%
Всего
100%
Позднее разрешение рисков.
Одной из серьезных проблем, связанных с водопадной моделью, являлась невозможность раннего разрешения рисков. Это было не столько результатом жизненного цикла водопадной модели в целом, сколько результатом повышенного внимания на ранних стадиях к «бумажным» продуктам, в которых реальные риски разработки, реализации и интеграции оставались относительно малыми. На рис. 1.3 представлена типичная кривая распределения рисков для проектов, использующих водопадную модель. Она разбивается на четыре отдельных периода подверженности рискам, для каждого из которых риск определяется как вероятность
Рис. 1.3. График риска в традиционном проекте в течение его жизненного цикла.
невыполнения поставленной задачи по смете, срокам, функциональным возможностям или качеству. В самом начале жизненного цикла по мере определения требований реальный уровень риска практически непредсказуем. После того как понимание требований концепции разработки становится устоявшимся, даже если эта концепция существует только на бумаге, уровень риска стабилизируется. Однако стабилизируется он обычно на относительно высоком уровне, поскольку на этот момент времени существует весьма незначительное количество реальных фактов, которые могли бы позволить менеджеру получить объективную оценку. По мере написания кода некоторые риски для отдельных компонентов оказываются разрешенными. После этого осуществляется интеграция, и основную роль начинают играть качество и риски, присущие системе в целом. Обычно именно в течение этого периода удается решить многие проблемы и достичь большинства компромиссов. Однако решение проблем на столь позднем этапе жизненного цикла, когда существует огромная инерция, тормозящая внесение изменений в продукт, оказывается чрезвычайно накладным. Соответственно, проекты имеют тенденцию к затягиванию стадии интеграции (см. рис. 1.2) до тех пор, пока не будут реализованы основные изменения в проекте (перепроектирование). Этот процесс позволяет исключить наиболее важные риски, однако приходится жертвовать качеством конечного продукта, особенно удобством его сопровождения. Употребление термина «перепроектирование» весьма произвольно. Большинство подобных действий можно описать скорее как «втискивание» изменений и латание дыр в уже существующей реализации с целью минимизации суммарных усилий, требующихся для решения проблемы. Внесение такого рода изменений не способствует сохранению общей целостности разработки и соответствующего удобства сопровождения.
Функциональная декомпозиция, определяемая требованиями.
Традиционно важнейшее значение для процесса разработки ПО имеют требования: сначала пытаются точно определить требования, а затем стремятся точно реализовать их. Такой подход зависит от того, насколько полно и недвусмысленно удается определить требования до начала выполнения других видов деятельности по разработке ПО. При этом все требования наивно рассматриваются как одинаково важные и неизменные на протяжении всего жизненного цикла разработки ПО. В действительности все эти условия редко оказываются выполненными. Определение требований является сложной и важной составляющей процесса разработки ПО. Фактически каждая большая программа сталкивается с серьезными трудностями при определении требований (см. приложение А). Более того, отношение ко всем требованиям как к одинаково важным отнимает время от разработки действительно значимых требований и заставляет выполнять лишнюю бумажную работу, связанную с отладкой, тестированием, поддержкой и т.д., — бумажную работу, которая неминуемо будет выброшена в корзину позже, по мере эволюции основных требований и соответствующего понимания проекта.
В качестве примера рассмотрим крупномасштабный проект, такой как CCPDS-R {см. приложение D), в котором требования к ПО включают в себя 2000 пунктов. (Пункт — это отдельное требование, например: «система должна выдерживать одиночные сбои аппаратуры без потери критичных возможностей».) Адекватная работа с определяющими проектными требованиями в таких системах (обычно всего от 20 до 50 пунктов) становится весьма затруднительной, если контракт налагает обязательства, чтобы все 2000 пунктов были определены и учитывались по достижении каждой основной контрольной точки разработки. Объем трудозатрат, которые могли бы быть направлены на решение действительно важных проектных проблем, распыляется на излишний багаж р 1950 пунктов, который приходится тащить за собой, и на работы, связанные с отладкой, тестированием, документацией и т.д.
Еще одним свойством традиционного подхода является то, что требования обычно специфицируются как функциональные. Процесс создания ПО по водопадной модели исходит из основополагающего допущения о том, что ПО само по себе декомпозируется на отдельные функции; требования в этом случае предъявляются к получившимся компонентам. Такая декомпозиция зачастую весьма далека от объектно-ориентированной декомпозиции и от использования уже существующих компонентов. Функциональная декомпозиция нередко закрепляется в контрактах, контрактах субподряда и в декомпозиции работ, что в значительной мере препятствует подходу, в котором ведущую роль играет архитектура. На рис. 1.4 показан результат применения подхода, в котором основную роль играют требования: здесь структура ПО организована в соответствии с определенной структурой требований.
Противостояние между участниками проекта.
Для традиционного процесса характерна тенденция к возникновению противоречивых отношений между заинтересованными сторонами, что связано во многом со сложностями определения требований и с обменом информацией исключительно в виде бумажных документов, содержащих проектные данные в специальных форматах. Отсутствие жестко заданной системы записи приводит к созданию субъективных отчетов и к произвольному порядку обмена информацией.
Следующая последовательность действий являлась типичной при заключении большинства контрактов на создание ПО:.
1.
Исполнитель готовил черновой вариант контракта, содержавший промежуточные материалы, и отправлял его заказчику.
2.
Заказчик должен был дать свои замечания (обычно в течение 15 - 30 дней).
3.
Исполнитель включал эти замечания в контракт и представлял (обычно в течение 15 — 30 дней) окончательную версию на утверждение.
Рис. 1.4. Неоптимальная организация программных компонентов, получающаяся при подходе, в котором ведущую роль играют требования.
Подобный процесс с одноразовым рассмотрением предполагал способность к быстрому реагированию как со стороны заказчиков, так и со стороны исполнителей. Издержки в процессе обмена бумагами оказывались недопустимыми. Подобный подход приводил даже к тому, что отношения между заказчиком и исполнителем вырождались до взаимного недоверия, что затрудняло достижение баланса между требованиями, сроками и затратами.
Чрезмерное внимание, уделяемое документации и совещаниям для обмена мнениями.
При традиционном процессе важное место занимало изготовление различной документации, в которой описывался программный продукт, при этом внесению существенных изменений в сам продукт уделялось недостаточно внимания. Основные контрольные точки обычно представляли собой церемониальные совещания, которые собирались исключительно для обсуждения конкретных документов. Подрядчики были вынуждены производить буквально тонны бумаг для демонстрации прогресса заинтересованным лицам, вместо того чтобы направлять свою энергию на решение задач, которые могли бы позволить снизить риск и получить.
качественное ПО. Зачастую выступающие и аудитория рассматривали простые вещи, которые им и без того были понятны, вместо действительно сложных и важных проблем. Вследствие этого большинство совещаний имело низкую ценность для разработчиков и высокую стоимость в терминах усилий и времени, затраченных на их подготовку и проведение. Они лишь создавали видимость прогресса. Результаты типичного совещания, посвященного разработке, сведены в таблицу 1.2.
Таблица 1.2.
Результаты рассмотрения разработки в традиционной модели проекта
Видимые результаты
Реальные результаты
1
Много выступлений перед широкой аудиторией
Только небольшой процент аудитории разбирается в ПО.
В выступлениях и документах представлены лишь некоторые важные моменты и риски из тех, что присущи сложным программным системам.
Представление проекта как соответствующего требованиям
Не существует никаких веских свидетельств соответствия, Соответствие неоднозначным требованиям малоценно.
Охват требований (обычно сотни)
Очень немногие требования (десятки) непосредственно влияют на ход проекта.
Работа со всеми требованиями не позволяет сосредоточиться на действительно важных требованиях.
Проект считается «непорочным, пока не доказано обратное»
Проект всегда имеет пороки.
Недостатки проекта проявятся на более поздних этапах жизненного цикла,
Диагностика пяти симптомов (см. выше) проектов, предрасположенных к появлению проблем, может оказаться весьма сложной, особенно на ранних стадиях жизненного цикла, когда проблемы, связанные с традиционным подходом, могли бы быть решены наиболее просто. Соответственно, современные проекты по созданию ПО должны использовать механизмы, которые дают возможность оценить состояние здоровья проекта на ранних стадиях его жизненного цикла и которые позволяют периодически проводить объективные проверки.
1.2 Эффективность традиционного управления проектами.
Одностраничная статья Барри Боэма «Industrial Software Metrics Top 10 List» («Список 10 главных правил промышленного создания ПО») [Boehm, 1987] дает объективную характеристику положению дел с разработкой ПО. (Существует мало свидетельств того, чтобы за последнее.
десятилетие произошли какие-либо значительные изменения.) Хотя многие из этих правил являются довольно общими, они точно описывают некоторые фундаментальные экономические отношения, сложившиеся при использовании традиционного процесса создания ПО за последние 30 лет.
Ниже курсивом выделяются правила Боэма и обычным шрифтом даются мои комментарии.
1.
Поиск и обнаружение ошибки в ПО после его сдачи обходится в 100 раз дороже, чем поиск и обнаружение ошибки на ранних стадиях разработки.
А Эта оценка является главным обоснованием для изменения процесса практически любого направления. Она не является уникальной для разработки ПО. Если, например, некая крупная автомобильная компания исправляет дефект, обнаруженный после продажи, стоимость ремонта может быть на много порядков выше, чем стоимость выявления дефекта на стадии разработки или производства.
2.
Можно сократить срок разработки ПО на 25 % от номинального, но не более.
А Одной из причин такого положения вещей является то, что для сокращения времени разработки на N% требуется увеличить количество персонала на М% (в предположении, что другие параметры остаются неизменными). Любой рост числа работников требует увеличения затрат на управление. Вообще говоря, допустимые отклонения для этих затрат с учетом графика выполнения параллельных работ, замораживания последующих работ и других ресурсных ограничений составляют около 25%. Оптимальным для работы, требующей 100 человеко-месяцев, может быть выполнение ее за 10 месяцев 10-ю работниками. Смогут ли такую работу выполнить 100 человек за один месяц? 50 человек за два месяца? А может быть, 20 человек за 5 месяцев? Понятно, что это все нереальные варианты. Правило 25%-ного сокращения гласит, что в этом случае допустимое предельное значение — 7.5 месяцев (хотя существует вероятность того, что потребуются дополнительные человеко-месяцы, возможно, около 20). Любое дальнейшее сокращение сроков работ обречено на неудачу. С другой стороны, оптимальный график работ может растягиваться почти произвольно и в зависимости от сотрудников может выполняться за существенно большее время при меньшем штате. Например, если отводится 25 месяцев на выполнение работ, то вполне можно уложиться в 75 человеко-месяцев при использовании трех человек.
3.
На каждый доллар, вложенный в разработку, приходится тратить два доллара на сопровождение.
А Боэм называет это правило «железным законом разработки ПО». Независимо от того, создается ли продукт долговременного использования, у которого выходят по две коммерческие версии в год, или единственное в своем роде ПО для конкретного заказчика, количество денег, затрачиваемых на весь цикл сопровождения, будет с некоторой вероятностью в два раза больше суммы, истраченной за весь цикл разработки. На первый взгляд трудно.
понять, хорошее это соотношение или плохое. Для сектора коммерческих продуктов оно определяется прежде всего коммерческим успехом на рынке. Успешные программные продукты (такие, как Orade, приложения Microsoft, Rational Rose и операционная система UNIX) существуют в течение очень долгого времени, что может приводить к более высокому значению отношения стоимости сопровождения к стоимости разработки. С другой стороны, менеджеры проектов по созданию «одноразового» ПО редко планируют большие затраты на его сопровождение. В любом случае каждому, кто был занят в индустрии ПО в течение последних 10 - 20 лет, известно, что ПО всегда трудно сопровождать.
4.
Стоимость разработки и сопровождения ПО явЛяется прежде всего функцией числа строк шходного кода.
а Это правило является следствием преобладания разработки ПО на заказ, отсутствия коммерчески используемых компонентов и отсутствия повторного применения, что было присуще эре традиционного процесса.
5.
Различил в уровне разработчиков приводят к огромной разнице в продуктивности при создании ПО.
А Это самая главная мудрость традиционного процесса: нанимайте хороших работников. Данному правилу зачастую придается как недостаточное, так и чрезмерное значение. Когда отсутствуют объективные сведения относительно причин успеха или неудачи, очевидным козлом отпущения становится квалификация персонала. Это суждение субъективно, и его трудно оспаривать.
6.
Общее отногиение стоимости ПО к стоимости аппаратуры продолжает расти. В 1955 г. оно составляло 15:85; в 1985 г. - 85:15.
А Тот факт, что на ПО приходится 85% стоимости большинства систем, является не столько следствием продуктивности создания ПО (которое к тому же оказывается не столь хорошим, как хотелось бы), сколько следствием того уровня функциональных задач, выполнение которых возлагается на ПО при принятии решений о системе в целом. Нужда в программном обеспечении, широта его использования и его сложность продолжают безгранично расти.
7.
При создании ПО всего лишь около 15% усилий затрачивается собственно на программирование.
А Это весьма важный показатель необходимого равновесия. Для успешного осуществления проекта приходится помимо кодирования выполнять много других задач. Управление требованиями, проектирование, тестирование, планирование, контроль за ходом проекта, управление изменениями и подготовка инструментария — одинаково важные задачи, на которые тратится приблизительно 85% ресурсов.
8.
Программные системы и продукты обычно стоят в три раза дороже в пересчете на одну строку исходного кода, чем отдельные программы. Продукты, состоящие из программных систем (т.е. системы систем), дороже в девять раз.
а. Эта экспоненциальная зависимость лежит в основе того, что называют платой за масштаб (diseconomy of scale). В отличие от других товаров, чем больше объем создаваемого ПО, тем дороже оно обходится в пересчете на строку исходного кода.
9. Сквозной контроль позволяет обнаружить 60% ошибок.
А Возможно, это и так. Однако с учетом правила 1 сквозной контроль не позволяет обнаруживать значимые ошибки, особенно на ранних стадиях жизненного цикла. Дефект дефекту рознь. Вообще говоря, сквозной контроль и другие формы контроля, производимого человеком, хороши для обнаружения ошибок, лежащих на поверхности, и проблем, касающихся стиля. При использовании для разработки специальной системы записи просмотр человеком может служить первичным механизмом гарантии качества, но он не позволяет обнаруживать проблемы второго, третьего, N-oro порядка, такие как конфликты ресурсов, узкие места, связанные с производительностью, конфликты управления и т.п. Более того, очень немногие люди способны находить даже семантические ошибки первого порядка в тексте программы. Скольким программистам удается компилировать свою собственную программу с первого раза?.
10. 80% работы выполняют 20% работающих.
а Это основополагающее утверждение остается верным практически для любых дисциплин, связанных с разработкой (или для любой профессиональной дисциплины, если уж на то пошло). Я расширил это правило. Следующие фундаментальные постулаты лежат в основе объяснения современного подхода к процессу управления созданием ПО:.
80% разработки выполняется для удовлетворения 20% требований.
80% процентов стоимости ПО приходится на 20% компонентов.
80% ошибок возникают по вине 20% компонентов.
80% ПО выбрасывается и заново переделывается из-за 20% ошибок.
80% ресурсов расходуются на 20% компонентов.
80% разработок выполняются с помощью 20% инструментария.
80% успеха обеспечивают 20% людей.
Эти соотношения дают хорошую точку отсчета для поиска способов усовершенствования процесса и технологии. Они представляют приблизительные практические правила, которые объективно характеризуют ход традиционного процесса управления созданием ПО и традиционные технологии. В последующих главах я буду возвращаться к этим соотношениям для того, чтобы обосновать новый подход, защитить старый подход и определить количественные характеристики процесса или усовершенствований технологии.