Каждая

новая функция или возможность работы с более сложными данными или условиями

органически вырастают на того, что уже имеется.

Органически усложняются и вырастают из того, что имеется. Фильм секрет. Едешь по дороге, фары освещают на 50 метров. Проезжаешь 50 метров – видишь следующие 50 метров. Логически следует то, что просчитать невозможно было изначально

Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих пор

помню испытанный в 1958 году удар, когда впервые услышал, как мой друг говорил

о строительстве (building) программ в противоположность написанию (writing). В

мгновение он расширил все мое представление о процессе программирования.

Применение метафоры было сильным и точным. Сегодня мы понимаем, что сходство

существует между созданием программы и другими строительными процессами, и

свободно используем другие элементы метафоры, такие как спецификации

(specifications), сборка компонентов (assembly of components), леса (scaffolding).

Метафора строительства пережила свое время. Пора снова вносить изменения. Если,

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

чтобы их можно было точно специфицировать заранее, и слишком сложны, чтобы

строить без ошибок, тогда нужен радикально иной подход.

Обратимся к природе и рассмотрим сложность живых созданий, а не безжизненных

творений человека. Там мы обнаруживаем конструкции, сложность которых вселяет

в нас ужас. Один только мозг настолько сложен, что невозможно составить его

схему. Его мощь невозможно повторить, он богат своеобразием, способен к

самосохранению и самообновлению. Секрет в том, что мозг растет, а не строится.

Так же должны создаваться наши программные системы. Несколько лет назад

Харлан Миллз предложил наращивать программные системы путем пошаговой

разработки.11 Это значит, что сначала систему надо заставить выполняться, даже

если при этом она не делает ничего полезного, кроме вызова некоторого числа

фиктивных подпрограмм. Затем она понемногу обрастает мясом, причем

подпрограммы, в свою очередь, разрабатываются сначала как вызовы пустых

фиктивных подпрограмм, находящихся на уровень ниже.

Настаивая на применении этой технологии разработчиками проектов на моих

лабораторных занятиях по программной инженерии, я стал свидетелем

поразительных результатов. За последнее десятилетие ничто другое не оказало

столь сильного влияния на мою собственную работу и ее эффективность. Этот

подход предполагает нисходящее проектирование, поскольку это — нисходящее

наращивание программы. Он позволяет легко отслеживать работу в обратном

направлении. Он предоставляет возможность раннего создания макетов. Каждая

новая функция или возможность работы с более сложными данными или условиями

органически вырастают на того, что уже имеется.

Воздействие на моральный дух ошеломительное. Когда есть хотя бы простая

работающая система, возрастает энтузиазм. Энергия удваивается, когда на экране

появляется картинка из новой графической программной системы, даже если это

всего лишь прямоугольник. И на каждой стадии процесса разработки существует

112

работающая система. Я считаю, что за одинаковые сроки команда может нарастить

значительно более сложный объект, чем построить.

В больших проектах можно ощутить такие же выгоды, как и в моих маленьких.12

Фредерик брукс

К 1955 году уже создавались программы для бизнеса объемом от 50 до 100

человеко-лет.

Миллион рублей тысяча тысяч рублей или тысяча дней. Что составляет 2.7 человеко-лет

32 человека за месяц закрывают миллион рублей

Миллион долларов заработает 700  человек за год.

Частоты. Для любого программного продукта каждая характеристика пользователя

представляет собой распределение со множеством возможных значений и

соответствующими частотами. Как архитектору получить эти частоты? Изучение этой

слабо очерченной популяции представляется сомнительным и дорогостоящим

занятием.3 С годами я пришел к убеждению, что архитектор должен угадать или,

если вам больше нравится, постулировать полный набор признаков и значений

вместе с частотами для создания полного, явного и общего для всех описания

группы пользователей.

Такая непривлекательная процедура имеет ряд полезных последствий. Во-первых,

при стремлении точно угадать частоты архитектор вынужден очень тщательно

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

возникает обсуждение, полезное для всех участников и выявляющее различия в

образах пользователя, имеющихся у разных проектировщиков. В-третьих, явное

присвоение частот содействуют пониманию того, какие решения какими свойствами

группы пользователей обусловлены. Даже такой неформальный анализ

чувствительности приносит пользу. Когда обнаруживается, что очень важные

решения зависят от некоторых специфических предположений, оказывается

уместным получить более точные численные оценки. (Разработанная Джеффом

Конклином (Jeff Conklin) система позволяет формально и точно прослеживать

принятие проектных решений и документировать их основания.4 Мне не приходилось

ею пользоваться, но думаю, что она должна быть очень полезна.)

Подводя итоги: установите предположительные признаки группы пользователей.

Гораздо лучше ошибаться, но выражаться ясно, чем выражаться туманно.