- Анализ: определение области задачи.

- Проектирование: создание общей структуры системы.

- Реализация: программирование и тестирование.

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

- Экспериментирование.

- Тестирование.

- Анализ проектирования и реализации.

- Документирование.

- Сопровождение.

Сопровождение программного обеспечения рассматривается просто как еще несколько проходов по стадиям процесса развития (см. также $$11 .3.6).

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

В больших проектах слишком часто бывает иначе. В идеале, в процессе развития проекта работники должны сами переходить с одной стадии на другую: лучший способ передачи тонкой информации - это использовать голову работника. К сожалению, в организациях часто устанавливают барьеры для таких переходов, например, у разработчика может быть более высокий статус и (или) более высокий оклад, чем у простого программиста. Не принято, чтобы сотрудники ходили по отделам с целью набраться опыта и знаний, но пусть, по крайней мере, будут регулярными собеседования сотрудников, занятых на разных стадиях проекта. Для средних и малых проектов обычно не делают различия между анализом и проектированием - эти стадии сливаются в одну. Для малых проектов также не разделяют проектирование и программирование. Конечно, тем самым решается проблема взаимодействия. Для данного проекта важно найти подходящую степень формализации и выдержать нужную степень разделения между стадиями ($$11 .4.2). Нет единственно верного способа для этого.

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

Вы можете уделять пристальное внимание деталям, использовать разумные приемы управления,

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

11.3.1 Цикл развития

Процесс развития системы - это итеративная деятельность. Основной цикл сводится к повторяемым в следующей последовательности шагам:

[1] Создать общее описание проекта.

[2] Выделить стандартные компоненты.

[a] Подогнать компоненты под данный проект.

[3] Создать новые стандартные компоненты.

[a] Подогнать компоненты под данный проект.

[4] Составить уточненное описание проекта.

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

Итак, допустим необходимо создать машину среднего размера с четырьмя дверцами и достаточно мощным мотором. Очевидно, что на первом этапе проекта не следует начинать проектирование машины (и всех ее компонентов) с нуля. Хотя программист или разработчик программного обеспечения в подобных обстоятельствах поступит именно так.

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

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

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

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

Мы не пытаемся утверждать, что все разработчики машин действуют столь разумно, как в приведенном примере, а разработчики программ совершают все указанные ошибки. Утверждается, что указанная методика разработки машин применима и для программного обеспечения. Так, в этой и следующей главах даны приемы использования ее для С++. Тем не менее можно сказать, что сама природа программирования способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5). В разделе 11.4.3 опровергается профессиональное предубеждение против использования описанной здесь модели проектирования. Заметим, что модель развития программного обеспечения хорошо применима только в расчете на большие сроки. Если ваш горизонт сужается до времени выдачи очередной версии, нет смысла создавать и поддерживать функционирование стандартных компонентов. Это просто приведет к излишним накладным расходам. Наша модель рассчитана на организации со временем жизни, за которое проходит несколько проектов, и с размерами, которые позволяют нести дополнительные расходы и на средства проектирования, программирования, и на сопровождение проектов, и на повышение квалификации разработчиков, программистов и менеджеров. Фактически это эскиз некоторой фабрики по производству программ. Как ни удивительно, она только масштабом отличается от действий лучших программистов, которые для повышения своей производительности в течении лет накапливали запас приемов и методов проектирования, создавали инструменты и библиотеки. Похоже, что большинство организаций просто не умеет воспользоваться достижениями лучших сотрудников, как из-за отсутствия предвидения, так и по неспособности применить эти достижения в достаточно широком объеме.

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

11.3.2 Цели проектирования

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

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

- гибкости,

- расширяемости и

- переносимости

Лучшее решение - выделить части системы, которые вероятнее всего будут меняться, в