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