1. Поиск и обнаружение ошибки в ПО после его сдачи обходится в 100 раз дороже, чем поиск и обнаружение ошибки на ранних стадиях проектирования.
А Современные процессы, компонентные технологии разработки и архитектурные схемы явно подтверждают это соотношение. Во многих областях, в том числе при решении проблем с ПО, локальных для некоторого компонента, применение инкапсуляции обеспечивает значительное снижение влияния на ресурсы, иногда на целый порядок. Тем не менее подход с упреждающей разработкой архитектуры позволяет получить преимущество в 10 - 100 раз при.
исправлении ошибок в архитектуре. Соответственно, итерационный процесс дает огромный выигрыш в раннем понимании архитектуры и при выполнении видов деятельности, связанных с риском.
2.
Можно сократить срок разработки ПО на 25 % от номинального, но не более.
а Это правило должно оставаться справедливым для стадии жизненного цикла, связанной с разработкой, когда развивается интеллектуальное содержимое системы. Однако в случае, если стадия разработки оказалась успешной и привела к созданию согласованной базы — включая архитектуру, планы по созданию и требования, — величина сокращения стадии производства может быть более гибкой. Если некоторая промышленная организация применяет одну и ту же стадию разработки для различных проектов или если проектная организация использует одну и ту же стадию разработки в различных направлениях, в любом случае имеется больше возможностей для параллельной разработки.
3.
На каждый доллар, вложенный в разработку, приходится тратить два доллара на сопровождение.
А Это правило трудно поддается обобщению, поскольку существует большое количество различных моделей сопровождения. Сравнения, производимые в абсолютных цифрах, имеют мало смысла во всех случаях, кроме сравнения однотипных проектов. Более правильным способом измерения этого показателя является определение соотношения производительности при разработке и сопровождении (см. приложение С). Одним из интересных аспектов итерационной разработки является тот факт, что граница между разработкой и сопровождением оказывается размытой. Зрелый итерационный процесс и хорошая архитектура могут существенно уменьшить объем дефектов и доработок. Мое шестое чувство подсказывает мне, что при имеющем место общем усреднении разработки и сопровождения это правило будет меняться в сторону отношения один к одному, при котором производительность процесса разработки будет не сильно отличаться от производительности процесса сопровождения.
4.
Стоимость разработки и сопровождения ПО является прежде всего функцией числа строк исходного кода.
А Это правило гласит, что стоимость определяется прежде всего размером продукта, а фундаментальными единицами измерения размера являются строки кода. Для предыдущих поколений технологии создания ПО это было совершенно очевидно, в то время как для сегодняшних технологий, основанных на компонентах, это становится менее очевидным. Коммерческие компоненты, повторное использование и автоматические генераторы кода могут сильно исказить значение строки исходного кода. Стоимость создания по-прежнему будет определяться сложностью спецификации. Использование большего числа компонентов, типов компонентов, источников компонентов и компонентов, изготовленных на заказ, потребует большего объема работ по интеграции и приведет к повышению стоимости. Использование меньшего числа компонентов, типов, источников и большего числа промышленных инструментов приведет к снижению стоимости. К несчастью, индустрия компонентов все еще недостаточно зрелая, чтобы отвечать таким стандартам спецификации системы, которые могли бы улучшить качество оценок стоимости. Это означает, что модели стоимости следующего поколения должны быть менее чувствительными к числу исходных строк и более чувствительными к количеству различных компонентов и к легкости их интеграции.
5.
Различия между людьми приводят к огромной разнице в продуктивности при создании ПО.
А Для каждой организации, которая занимается разработкой и для которой интеллектуальная собственность является реальным продуктом, факторами, определяющими продуктивность, будут служить навыки персонала, умение работать в команде и мотивация. Современный итерационный процесс ограничивает, насколько это возможно, требование в привлечении высококвалифицированных сотрудников стадией разработки, когда команда еще относительно мала. На стадии производства, когда команды обычно становятся гораздо больше, зависимость от недостатка опыта и знаний снижается.
6.
Общее отношение стоимости ПО к стоимости аппаратуры продолжает расти. В 1955 г. оно составляло 15:85; в 1985 г. - 85:15.
а Я не могу сказать точно, как это правило выглядит сегодня. Популярность персональных компьютеров и различия в стоимости ПО, в частности, в стоимости программных инструментов для персональных компьютеров, без всякого сомнения, изменили это соотношение. Главное влияние этого правила на экономику ПО заключается в том, что аппаратура продолжает дешеветь. Циклы обработки, хранение данных и пропускная способность сетей предлагают все новые возможности для автоматизации. Соответственно, все более важную роль начинает играть среда ПО. В современном процессе среда выполняет гораздо больший объем работ по учету и анализу, чем тот, что ранее выполнялся человеком. Анализ конфигурации и соответствия качества уже в значительной степени автоматизированы, очередным рубежом является автоматизация производства и тестирования.
7.
При создании ПО всего лишь около 15% работ тратится собственно на программирование.
А За последнее десятилетие наблюдалось заметное снижение инвестиций в языки и компиляторы, за исключением языков Java и Ada 95. Инвестиции в современные технологии перекочевали в области определения зрелости процесса (например, SEI СММ), визуального моделирования (UML), автоматизированного качества ПО (автоматизация тестирования), создания компонентов (ActiveX, Java и C0RBA), управления настройками, определения параметров и других аспектов разработки ПО. Объем программирования, выполняемый в рамках проекта по разработке ПО, по-прежнему остается приблизительно на уровне 15%. Различие заключается в том, что в рамках современных проектов программирование выполняется на более высоком уровне абстракции. В 1960-х гг. на один человеко-месяц в среднем.
приходилось около 200 машинных команд, а в 1970-х и 1980-х гг. — около 1000. Производительность программирования в 1990-х гг. позволяет получать десятки тысяч машинных команд в месяц, хотя реально может быть произведено всего лишь несколько сотен написанных вручную строк исходного кода.
8. Программные системы и продукты обычно стоят в три раза дороже в пересчете на одну строку исходного кода, чем отдельные программы. Продукты, состоящие из программных систем (т.е. системы систем), дороже в девять раз.
А Современный процесс и современные технологии позволяют в значительной степени избавиться от платы за большой масштаб. При определенных условиях — например, в производстве отдельных, предназначенных для конкретного заказчика программных систем, обладающих единой архитектурой, единой средой и единым процессом, — удается достигнуть экономии при больших масштабах.
Я Сквозной контроль позволяет обнаружить 60% ошибок.
А Я уже обращал внимание на то, что это правило необходимо исключить из первой десятки. Проверка и контроль, выполняемые человеком, не позволяют обнаруживать критичные проблемы; они могут только помочь в их решении. Это правило нужно заменить следующим: «В то время как среда позволяет обнаружить большинство несоответствий и ошибок первого уровня, по-настоящему важные проблемы в архитектуре могут быть выявлены только посредством демонстраций и разрешены только посредством внимательного изучения человеком».
10. 80% работы выполняется 20% работающих.
А Это соотношение — на все времена. Оно является основополагающей философией, которую следует использовать при планировании и при осуществлении современного процесса руководства созданием ПО.