straustrup2 (852740), страница 74
Текст из файла (страница 74)
Но по мере развития проекта требуется все больше планирования,специализации и строго определенного взаимодействия между занятыми в нем людьми. Под строгоопределенным понимается не математическая или автоматически верифицируемая запись (хотя этобезусловно хорошо там, где возможно и применимо), а скорее набор указаний по записи, именованию,документации, тестированию и т.п. Но и здесь необходимо чувство меры. Слишком жесткая структураможет мешать росту и затруднять совершенствование. Здесь подвергается проверке талант и опытменеджера. Для отдельного работника аналогичная проблема сводится к определению, где нужно286Бьерн Страуструп.Язык программирования С++проявить смекалку, а где действовать по рецептам.Можно рекомендовать планировать не на период до выдачи следующей версии системы, а на болеедолгий срок.
Строить планы только до выпуска очередной версии - значит планировать неудачу. Нужноиметь организацию и стратегию развития программного обеспечения, которые нацелены на создание иподдержание многих версий разных систем, т.е. нужно многократное планирование успеха.Цель проектирования в выработке ясной и относительно простой внутренней структуры программы,называемой иногда архитектурой, иными словами каркаса, в который укладываются отдельныепрограммные фрагменты, и который помогает написанию этих фрагментов.Проект - конечный результат процесса проектирования (если только бывает конечный продукт уитеративного процесса). Он является средоточием взаимодействий между разработчиком ипрограммистом и между программистами. Здесь необходимо соблюсти чувство меры. Если я, какотдельный программист, проектирую небольшую программу, которую собираюсь написать завтра, тоточность и полнота описания проекта может свестись к нескольким каракулям на обратной сторонеконверта.
На другом полюсе находится система, над которой работают сотни программистов иразработчиков, и здесь могут потребоваться тома тщательно составленных спецификаций проекта наформальном или полуформальном языке. Определение нужной степени точности, детализации иформальности проектирования является уже само по себе нетривиальной технической иадминистративной задачей.Далее будет предполагаться, что проект системы записывается как ряд определений классов (вкоторых частные описания опущены как лишние детали) и взаимоотношений между ними. Этоупрощение, т.к. конкретный проект может учитывать: вопросы параллельности, использованиеглобального пространства имен, использование глобальных функций и данных, построение программыдля минимизации перетрансляции, устойчивость, многомашинный режим и т.п.
Но при обсуждении наданном уровне детализации без упрощения не обойтись, а классы в контексте С++ являются ключевымпонятием проектирования. Некоторые из указанных вопросов будут обсуждаться ниже, а те, которыепрямо затрагивают проектирование библиотек С++, будут рассмотрены в главе 13. Более подробноеобсуждение и примеры определенных методов объектно-ориентированного проектированиясодержатся в [2].Мы сознательно не проводили четкого разделения анализа и проектирования, поскольку обсуждение ихразличий выходит за рамки этой книги, и оно зависит от применяемых методов проектирования.Главное в том, чтобы выбрать метод анализа, подходящий для метода проектирования, и выбратьметод проектирования, подходящий для стиля программирования и используемого языка.11.3 Процесс развитияПроцесс развития программного обеспечения - это итеративный и расширяющийся процесс. По мереразвития каждая стадия повторяется многократно, и при всяком возврате на некоторую стадиюпроцесса уточняется конечный продукт, получаемый на этой стадии.
В общем случае процесс не имеетни начала, ни конца, поскольку, проектируя и реализуя систему, вы начинаете, используя как базудругие проекты, библиотеки и прикладные системы, в конце работы после вас остается описаниепроекта и программа, которые другие могут уточнять, модифицировать, расширять и переносить.Естественно конкретный проект имеет определенное начало и конец, и важно (хотя часто удивительнотрудно) четко и строго ограничить время и область действия проекта.
Но заявление, что вы начинаете с"чистого листа", может привести к серьезным проблемам для вас, также как и позиция, что послепередачи окончательной версии - хоть потоп, вызовет серьезные проблемы для ваших последователей(или для вас в новой роли).Из этого вытекает, что следующие разделы можно читать в любом порядке, поскольку вопросыпроектирования и реализации могут в реальном проекте переплетаться почти произвольно. Именно,"проект" почти всегда подвергается перепроектированию на основе предыдущего проекта,определенного опыта реализации, ограничений, накладываемых сроками, мастерством работников,вопросами совместимости и т.п.
Здесь основная трудность для менеджера или разработчика илипрограммиста в том, чтобы создать такой порядок в этом процессе, который не препятствуетусовершенствованиям и не запрещает повторные проходы, необходимые для успешного развития.У процесса развития три стадии:287Бьерн Страуструп.Язык программирования С++-Анализ: определение области задачи.-Проектирование: создание общей структуры системы.-Реализация: программирование и тестирование.Не забудьте об итеративной природе этих процессов (неспроста стадии не были пронумерованы), изаметьте, что никакие важные аспекты процесса развития программы не выделяются в отдельныестадии, поскольку они должны допускать:-Экспериментирование.-Тестирование.-Анализ проектирования и реализации.-Документирование.-Сопровождение.Сопровождение программного обеспечения рассматривается просто как еще несколько проходов постадиям процесса развития (см.
также $$11.3.6).Очень важно, чтобы анализ, проектирование и реализация не были слишком оторваны друг от друга, ичтобы люди, принимающие в них участие, были одного уровня квалификации для налаживанияэффективных контактов.В больших проектах слишком часто бывает иначе. В идеале, в процессе развития проекта работникидолжны сами переходить с одной стадии на другую: лучший способ передачи тонкой информации - этоиспользовать голову работника. К сожалению, в организациях часто устанавливают барьеры для такихпереходов, например, у разработчика может быть более высокий статус и (или) более высокий оклад,чем у "простого" программиста.
Не принято, чтобы сотрудники ходили по отделам с целью набратьсяопыта и знаний, но пусть, по крайней мере, будут регулярными собеседования сотрудников, занятых наразных стадиях проекта. Для средних и малых проектов обычно не делают различия между анализоми проектированием - эти стадии сливаются в одну. Для малых проектов также не разделяютпроектирование и программирование. Конечно, тем самым решается проблема взаимодействия. Дляданного проекта важно найти подходящую степень формализации и выдержать нужную степеньразделения между стадиями ($$11.4.2). Нет единственно верного способа для этого.Приведенная здесь модель процесса развития программного обеспечения радикально отличается оттрадиционной модели "каскад" (waterfall). В последней процесс развития протекает линейно от стадиианализа до стадии тестирования.
Основной недостаток модели каскад тот, что в ней информациядвижется только в одном направлении. Если выявлена проблема "ниже по течению", то возникаетсильное методологическое и организационное давление, чтобы решить проблему на данном уровне, незатрагивая предыдущих стадий процесса. Отсутствие повторных проходов приводит к дефектномупроекту, а в результате локального устранения проблем получается искаженная реализация. В технеизбежных случаях, когда информация должна быть передана назад к источнику ее получения ивызвать изменения в проекте, мы получим лишь слабое "колыхание" на всех уровнях системы,стремящейся подавить внесенное изменение, а значит система плохо приспособлена к изменениям.Аргумент в пользу "никаких изменений" или "только локальные изменения" часто сводится к тому, чтоодин отдел не хочет перекладывать большую работу на другой отдел "ради их же блага".
Часто бываеттак, что ко времени, когда ошибка уже найдена, исписано столько бумаги относительно ошибочногорешения, что усилия, нужные на исправление документации, затмевают усилия для исправления самойпрограммы. Таким образом, бумажная работа может стать главной проблемой процесса созданиясистемы. Конечно, такие проблемы могут быть и возникают в процессе развития больших систем. Вконце концов, определенная работа с бумагами необходима. Но выбор линейной модели развития(каскад) многократно увеличивает вероятность, что эта проблема выйдет из-под контроля. Недостатокмодели каскад в отсутствии повторных проходов и неспособности реагировать на изменения.Опасность предлагаемой здесь итеративной модели состоит в искушении заменить размышление иреальное развитие на последовательность бесконечных изменений.
Тот и другой недостатки легчеуказать, чем устранить, и для того, кто организует работу, легко принять простую активность зареальный прогресс.Вы можете уделять пристальное внимание деталям, использовать разумные приемы управления,288Бьерн Страуструп.Язык программирования С++развитую технологию, но ничто не спасет вас, если нет ясного понимания того, что вы пытаетесьсоздать. Больше всего проектов проваливалось именно из-за отсутствия хорошо сформулированныхреалистичных целей, а не по какой-либо иной причине.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
