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

3.2.3 Политика управления сложностью при проектировании ПО

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

Управление сложностью -- самый важный технический аспект разработки ПО.

Сложность -- не новинка в мире разработки ПО. Один из пионеров информатики Эдсгер Дейкстра обращал внимание на то, что компьютерные технологии -- единственная отрасль, заставляющая человеческий разум охватывать диапазон, простирающийся от отдельных битов до нескольких сотен мегабайт информации, что соответствует отношению 1 к 10⁹, или разнице в девять порядков. Такое гигантское отношение просто ошеломляет. Дейкстра выразил это так: “По сравнению с числом семантических уровней средняя математическая теория кажется почти плоской. Создавая потребность в глубоких концептуальных иерархиях, компьютерные технологии бросают нам абсолютно новый интеллектуальный вызов, не имеющий прецедентов в истории”. Разумеется, за прошедшее с 1989 г. время сложность ПО только выросла, и сегодня отношение Дейкстры вполне может характеризоваться 15 порядками.

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

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

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

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

· сложное решение простой проблемы;

· простое, но неверное решение сложной проблемы;

· неадекватное сложное решение сложной проблемы.

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

· стараться свести к минимуму объем существенной сложности, с которым придется работать в каждый конкретный момент времени;

· сдерживать необязательный рост несущественной сложности.

Такая политика управления сложностью при разработке обычно выражается аббревиатурами KISS & DRY, которые переводятся как “Делай короче и проще” (Keep It Short and Simple) и “Не повторяй себя” (Don't Repeat Yourself).

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

3.2.4 Политика отслеживания и исправления ошибок

· Подробное описание шагов, необходимых для воспроизведения ошибки

· Ожидаемое поведение

· Наблюдаемое (неправильное) поведение

· Кому поручено исправить

· Исправлена ошибка или нет

Политика “Zero bugs” (ноль дефектов) которая была впервые внедрена Microsoft, теперь повсеместно используется во всех успешных компаниях создающих программное обеспечение, в том числе и для веб. Согласно этой политике, в любой момент времени наиболее важным является устранение ошибок до написания нового кода. И вот почему. В общем случае, чем больше компания тянет с исправлением ошибки, тем дороже (во временном и денежном измерении) ей это обойдётся. Например, если в коде приложения есть ошибка, которая обнаруживается при первом запуске, её можно тут же исправить, так как код ещё свеж в вашей памяти. Если ошибка обнаруживается в коде, который был написан несколько дней назад, потребуется какое-то время, чтобы отследить её, но если перечитать свой код, можно всё вспомнить и исправить ошибку в разумные сроки. Но если вы обнаружили ошибку в коде, который написан несколько месяцев назад, то вы скорее всего уже многое в нём забыли, и исправить её будет гораздо сложнее. Может случиться так, что вам придётся исправлять чужой код, автор которого отдыхает на Карибских островах. В этом случае поиск ошибки -- целая наука: приходится долго, методично и тщательно искать, и неизвестно, сколько времени это займёт. А если ошибка обнаруживается в продукте, который уже продаётся, компания понесёт невероятные расходы, чтобы её исправить.

Вот это и есть главная причина, по которой лучше исправлять ошибки сразу: это занимает меньше времени.

3.2.5 Политика поддержки актуальности требований и документации

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

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

IV. Обзор подходов к планированию в рамках различных моделей и методологий разработки

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

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

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