Совет по ПО для авиации обладал «необходимой структурой, в которую входили самые удачливые менеджеры крупномасштабных проектов, признанные авторы, выдающиеся консультанты и администраторы, ответственные за разработку ПО в основных компаниях». Одним из продуктов Совета стал набор из девяти лучших практических приемов. Советом была предпринята попытка сфокусировать внимание на приемах, которые могли бы оказать самый сильный эффект на совершенствование дисциплины управления ПО для крупномасштабных проектов и на контроль за сложностью в рамках таких проектов.
Эти девять лучших практических приемов приводятся ниже. Я комментирую их с точки зрения того, как они соотносятся со схемой проекта, управленческими дисциплинами и 10-ю главными принципами, рекомендованными мною. (Заимствования выделены курсивом.).
1.
Формальное управление рисками.
а Использование итерационного процесса, который явно рассматривает риск, более или менее соответствует тому, о чем здесь говорится.
2.
Соглашение по интерфейсам.
а Хотя мы можем пользоваться разными словами, здесь преследуется та же самая цель, что и в моем принципе упреждающей разработки архитектуры. Формирование основ архитектуры движет проект к достижению соглашения по различным внешним интерфейсам и самым важным внутренним интерфейсам, поскольку все они являются неотъемлемой частью архитектуры.
3.
Формальные проверки.
А Процесс оценки на протяжении всего жизненного цикла, выполняемый параллельно с другими процессами, должен взвешенно использовать несколько различных стратегий по исправлению дефектов. Наименее важной стратегией, с точки зрения широты охвата, являются формальные проверки по причине высоких затрат человеческих ресурсов и низкого уровня обнаружения дефектов в отношении к архитектурно значимым дефектам, которые распределены по нескольким компонентам и разбросаны во времени.
4.
Планирование и управление на основе метрик.
А Этот важный принцип непосредственно связан с моими принципами нотации, основанной на моделях, и объективного контроля за качеством.
В отсутствие строгой нотации для рабочих продуктов измерение прогресса и качества вырождается до уровня приблизительных субъективных оценок.
5.
Двойной контроль качества на уровне «дюймовой гальки».
А Этот прием иногда интерпретируется неправильно. Слишком многие проекты использовали точно такой подход на ранних стадиях жизненного цикла и разрабатывали чрезвычайно подробный план за очень высокую цену. Три месяца спустя, когда изменялись некоторые требования или архитектура, большую часть детально разработанного плана приходилось переделывать заново. Лучшим является подход, позволяющий поддерживать качество плана на уровне, соответствующем уровню понимания требований и архитектуры. Вместо «дюймовой гальки» я бы рекомендовал расставить контрольные точки на стадии разработки, а «дюймовую гальку» оставить для стадии производства. Это основная мысль моего принципа изменяющегося уровня детализации.
6.
Сравнение прогресса всей программы с планом.
а Этот прием, т.е. открытость взаимодействия между членами команды, работающей над проектом, конечно же, необходим. Ни один из моих принципов не соответствует ему напрямую. Он кажется настолько очевидным, что я оставляю его без комментариев.
7.
Отслеживание дефектов в сравнении с целевым качеством.
А Этот важный принцип непосредственно связан с моими принципами упреждающей разработки архитектуры и объективного контроля качества. Критичные дефекты и целевое качество определяются архитектурой. Получение рычага воздействия на эти аспекты и отслеживание тенденций их изменения являются необходимыми требованиями для достижения успеха.
8.
Управление конфигурацией.
А Совет по ПО для авиации выделил управление конфигурацией как ключевое для управления сложностью и для отслеживания изменений, вносимых во все рабочие продукты. Он также признает, что автоматизация является важной из-за объема и динамики современных крупномасштабных проектов, где применение ручных методов требует высоких затрат и чревато ошибками. Такое же обоснование имеет мой принцип управления изменениями.
9.
Ответственность управления за информированность людей.
А Это еще один принцип управления, который кажется очевидным, и я оставляю его без комментариев.
Нетрудно заметить совпадение и общность духа между моими главными принципами и лучшими приемами Совета по ПО для авиации. Однако мне кажется, что Совет пропустил такие важные принципы, как конфигурируемость и разработка, основанная на компонентах, моделях и демонстрациях. Это кажется удивительным. Моим объяснением причин включения принципов, гласящих, что разработка должна основываться на компонентах и на моделях, является снижение сложности работ. Это та самая цель, которую провозгласил Совет по ПО для авиации. Принцип, по которому разработка должна основываться на демонстрациях, попал в число первых 10-ти прежде всего для стимуляции процесса постоянной интеграции на протяжении всего жизненного цикла и для установления более тесных связей между заинтересованными сторонами посредством более осмысленных средств взаимодействия. Поскольку Совет по ПО для авиации сосредоточился только на одной частной области — на крупномасштабных, имеющих национальное значение системах — конфигурируемость оказалась не столь существенной.
Два из приемов Совета по ПО для авиации, которые я бы не стал включать, это проверки и двойной контроль качества на уровне «дюймовой гальки». Они полезны, но на практике им уделяется чересчур много внимания, кроме того, существуют другие важные принципы, которые следовало бы учесть.