■ Демонстрации по достижении основных контрольных точек, которые заставляют оценивать результаты по значимым критериям в контексте конкретных вариантов использования.

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

■ Тестирование на протяжении всего жизненного цикла, позволяющее выявлять критичные соотношения ресурсов, критерии приемки и соответствие требованиям.

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

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

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

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

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

Несмотря на эти положительные моменты оценок, многие организации преувеличивают значение совещаний и формальных оценок, настаивая на оценках всех разработанных продуктов. Такой подход может оказаться чрезвычайно непроизводительным. Примерно лишь для 20% технических продуктов (таких, как отдельные варианты использования, проектные модели, исходный код и тестовые варианты) детальное рассмотрение оказывается предпочтительным по сравнению с другими, более полезными с точки зрения гарантии качества способами. Процесс, качество которого изначально предполагается гарантировать посредством оценок, не может быть финансово оправдан. В некоторых публикациях особо отмечается важность и высокая степень ROI таких оценок. Я подозреваю, что эти исследования публиковались профессионалами в области контроля качества, которые склонны преувеличивать важность своей дисциплины. Зачастую мой голос по данной теме остается в одиночестве, но я готов обосновать это логически.

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

■ Анализа, создания прототипов или проведения экспериментов.

■ Создания проектных моделей.

■ Перевода текущего состояния модели в выполняемый код.

■ Демонстрации сильных и слабых сторон текущего состояния разработки в контексте наиболее критичных вариантов использования и сценариев.

■ Учета уроков в моделях, вариантах использования, при реализации и планировании.

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

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

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

3а последние два десятилетия в процессе создания ПО.

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

4.1 ПРИНЦИПЫ ТРАДИЦИОННОЙ ПРОГРАММНОЙ ИНЖЕНЕРИИ.

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

обсуждаемых в остальной части книги. Выбранная мною точка отсчета — это короткая статья «Fifteen principles of software engineering» («Пятнадцать принципов программной инженерии») [Davis, 1994]. Она постепенно переросла в книгу [Davis, 1995], которая содержит в себе 201 принцип. Несмотря на свое название, данная статья описывает тридцать самых важных принципов, и она не хуже всех прочих изложений мудрости традиционного процесса в индустрии ПО. Я готов подписаться под большей частью этих принципов, но я убежден, что некоторые из них устарели. 30 принципов Дэвиса, приводимые ниже, выделяются курсивом. Для каждого принципа дается комментарий по поводу того, будет ли этот принцип поддерживаться или изменяться в данной книге. Я сделаю несколько допущений, которые будут оставлены без доказательств до следующих глав.

1.

Достигайте наивысшего качества. Качество должно иметь количественное выражение, и необходимо задействовать механизмы, стимулирующие его достижение.

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

2.

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

А Этот принцип — самый ненужный.

3.

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

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

4.

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

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

5.

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

а Этот принцип, вероятно, укоренился в «водопадном» сознании в двух видах. (1) Требования предшествуют архитектуре, вместо того чтобы рассматриваться совместно. (2) Архитектура заложена в спецификациях самих требований. В то время как современный процесс в явном виде способствует проведению анализа альтернатив при разработке, это делается параллельно с определением требований, а различные нотации и рабочие продукты, касающиеся требований и архитектуры, явным образом не связаны между собой.

6.

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

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

7.

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

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

8.

Минимизируйте семантический разрыв. Для того чтобы минимизировать семантический разрыв, структура ПО должна быть настолько близка к структуре предметной области, насколько это возможно.

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

9. Ставьте методы выше инструментов. Недисциплинированный разработчик ПО, вооруженный инструментом, становится опасным недисциплинированным разработчиком ПО.

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

10.

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

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

11.

Проверяйте код. Оценка детальной разработки и кода более хороший способ обнаружения ошибок, чем тестирование.

А Значение этого принципа переоценивается для всех, кроме самых простейших, систем ПО. Сегодняшние возможности аппаратуры, языки программирования, автоматизированные среды позволяют эффективно выполнять автоматизированный анализ и тестирование на протяжении всего жизненного цикла. Постоянное и автоматизированное тестирование в течение жизненного цикла — это необходимость для любой современной итерационной разработки. Вообще говоря, беспорядочные проверки (в противоположность проверкам, которые сосредоточиваются на известных проблемах) редко позволяют вскрыть недоработки в архитектуре или глобальные недостатки при разработке. Неверно было бы утверждать, что неэффективными являются все проверки. Когда они используются разумно и направлены на определенную проблему, то оказываются чрезвычайно эффективными для ее решения. Однако этот принцип не должен входить в число первых 15, особенно если учесть, что в индустрии ПО перепроверка является обычной практикой.

12.

Хорошее управление более важно, чем хорошая технология. Лучшая технология не сможет компенсировать слабое управление, а хорошее управление позволяет получить великолепные результаты даже при наличии недостаточных ресурсов. Хорошее управление заставляет полностью выкладываться, хотя и не существует универсальных «правильных» стилей руководства.

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

13.

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

А Этот принцип расположен в списке слишком далеко от его начала.

14.

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

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

15.

Принимайте на себя ответственность. Когда рушится мост, мы спрашиваем: «Что инженеры сделали неправильноЬ> Если же выходит из строя ПО, мы редко задаемся подобным вопросом. Факты, однако, таковы, что в любой прикладной дисциплине самые лучшие методы могут быть использованы для создания ужасных решений, а самые устаревшие методы - для получения элегантных результатов.

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

16.

Выясните приоритеты заказчика. Возможно, заказчика устроит задержка с реализацией 90% функциональных возможностей, если 10% из них он получит вовремя.

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

17.

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

А Это верно, но предполагает, что вы никогда ничего не захотите показывать пользователю. Следовало бы сказать так: «Чем больше пользователи видят, тем больше они начинают понимать». Не все заказчики на 100% руководствуются жадностью. Они знают, что ресурсы их некоторым образом лимитированы, а у разработчиков существуют свои ограничения. Демонстрация промежуточных результатов — это наглядная деятельность, которая необходима для приведения в соответствие ожиданий заказчика. Если распространять данный принцип на современный процесс, это будет означать, что менеджер проекта по созданию ПО должен обладать объективной информацией, которой он сможет оперировать, оспаривая неизбежные просьбы о внесении изменений и поддерживая баланс между допустимостью, функциональными возможностями и риском.

18.

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

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

19.

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

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

20.

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

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

21.

Используйте инструментарий, но оставайтесь реалистами. Инструментарий для разработки ПО позволяет тому, кто его применяет, работать более эффективно.

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

22.

Избегайте рисков. Многие программисты любят создавать программы с различными трюками - конструкциями, которые работают правильно, но непонятно как. Покажите всему миру, насколько вы ловки, избежав трюков в своей программе.

▲ Мне кажется, трудно поверить в то, что это является одним из главных принципов. Сложно провести границу между «трюком» и новаторским решением. Я знаю, к чему стремится Дэвис, но мне бы не хотелось вводить в действие принцип, который в качестве побочного эффекта зажимал бы новаторство. Запутанных способов кодирования следует избегать до тех пор, пока не появятся непреодолимые причины их использования. К несчастью, такие причины весьма обычны для нетривиальных проектов.

23.

Пользуйтесь инкапсуляцией. Сокрытие информации является простым, проверенным средством, позволяющим получить ПО, которое проще тестировать и сопровождать.

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

24.

Используйте связность (coupling) и сцепление (cohesion). Связность и сцепление - лучшие средства измерения присущих ПО сопровождаемости и адаптируемости.

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

25.

Используйте меру сложности Маккейба (McCabe). Существует много известных способов для определения сложности, присущей ПО, но ни один из них не является настолько интуитивно понятным и легким в применении, как способ Тома Маккейба.

А Способы измерения сложности важны для определения некоторых критичных компонентов, которым требуется повышенное внимание. Однако в моей практике сложность на самом деле была очевидна; редко приходится сталкиваться с тем, чтобы измерения сложности использовались в практических приложениях для управления проектом или принятия решений. Такие измерения могут быть интересны с академической точки зрения (изучение метапроектов и стратегическое принятие решений), а также могут оказаться полезными при управлении проектом (если оно автоматизировано), но вряд ли они относятся к наиважнейшим принципам.

26.

Не тестируйте свое собственное ПО. Разработчики никогда не должны становиться главными тестирующими своего ПО.

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

27.

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

а При поверхностном взгляде кажется, что это хороший принцип, особенно на стадии конструирования (construction), когда высока вероятность повторения ошибок. Однако в результате анализа ошибок в сложных программных системах оказалось, что одним из критичных источников ошибок являются излишний анализ и излишнее проектирование, выполняемые на бумаге на ранних стадиях проекта. В некоторой степени излишняя работа была направлена на предотвращение ошибок. Это приводило к уменьшению отдачи от вложенных ресурсов по сравнению с тем, что могло бы быть получено при переходе к созданию прототипов и построению системы, при котором ошибки оказываются более очевидными и осязаемыми. Таким образом, я бы разбил данное утверждение на два принципа: (1) не бойтесь делать ошибки на стадии разработки, (2) анализируйте причины ошибок на этапе производства.

28.

Знайте, что энтропия ПО возрастает. Сложность любой программной системы, претерпевающей множественные изменения, возрастает, и она становится все менее и менее организованной.

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

29.

Люди и время не взаимозаменяемы. Измерение проекта только в человеко-месяцах имеет мало смысла.

А Это вечный принцип.

30.

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

А Этот принцип применим ко всем дисциплинам, а не только к управлению созданием ПО.

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