Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 62
Текст из файла (страница 62)
Речтин (Rechtin) [H 1992] предложилпрагматическое руководство для системного архитектора, который долженуправлять процессом развития.Интересная ссылка по вопросу о "созревании" программного продукта- это работа Хэмфри (Hamphrey) [H 1989]. Классическая ссылка на то, каксимитировать этот процесс, - статья Парнаса (Parnas) [H 1986].Глава 7Практические вопросыРазработка программ пока остается чрезвычайно трудоемким делом, в значительнойстепени она по-прежнему больше напоминает строительство коттеджей, чемпромышленное возведение зданий [1]. Доклад Кишиды и др.
свидетельствует, что дажев Японии на начальной стадии проектов "все еще по большей части полагаются нанеформальный подход - карандаш и бумагу" [2].Ситуация усугубляется тем обстоятельством, что проектирование - никак не точнаянаука. Возьмем проектирование баз данных, одну из технологий, предшествовавшихобъектно-ориентированному проектированию.
Как замечает Хаврис-кевич: "Хотя всевыглядит просто и ясно, неизбежно примешивается изрядная доля личногопредставления о важности различных объектов на предприятии. В результате процесспроектирования не воспроизводим: разные проектировщики могут создать разныемодели одного и того же предприятия" [З].Из этого можно сделать вывод, что при любом самом изощренном и теоретическиобоснованномметодепроектированиянельзяигнорироватьпрактическиесоображения.
Значит, мы должны принять во внимание управленческий опыт в такихобластях, как подбор кадров, управление релизами и контроль качества. Для технологаэто в высшей степени скучная материя, но для разработчика это реалии жизни, скоторыми надо справляться, чтобы создавать сложные программные системы. Итак, вэтой главе мы займемся практическими вопросами объектно-ориентированнойразработки и влиянием объектной модели на управление.7.1.Управление и планированиеЕсли мы при проектировании опираемся на метод итеративногоразвития, то важнее всего иметь сильное руководство, способное управлятьходом проекта и направлять его. Слишком много проектов сбились с пути изза неспособности сосредоточиться на главном, и только сильная командаменеджеров может что-то с этим поделать.Управление рискомВ конечном счете, главная обязанность менеджера программногопродукта - управление как техническим, так и нетехническим риском.Технический риск для объектно-ориентированной системы содержится врешении таких проблем, как выбор структуры наследования классов,обеспечивающий наилучший компромисс между удобством и гибкостьюпрограммного продукта.
Серьезное решение приходится также принимать привыборе механизмов упрощения архитектуры и улучшения эффективности.Нетехнический риск содержит в себе такие вопросы, как контрольсвоевременности поставки программных продуктов от третьих фирм илирегулирование отношений заказчика и разработчиков, что необходимо длявыяснения реальных требований к системе на стадии анализа.Как было описано в предыдущей главе, микропроцесс объектноориентированной разработки нестабилен по своей природе и требуетактивного управления, концентрации усилий.
К счастью, существуетмакропроцесс разработки, который выдвигает ряд конкретных требований ихарактеристик. Менеджер проекта, изучая соответствие требований ифактических результатов, может оценить состояние разработки и, принеобходимости, перенаправить ресурсы команды. Эволюционная сутьмакропроцесса разработки означает, что можно распознать проблемы в началежизненного цикла и продуманно учесть связанный с ними риск прежде, чемпроект окажется в опасности.Многие виды деятельности по управлению разработкой программногообеспечения, например, планирование задач и просмотры, предусмотрены нетолько в объектно-ориентированной технологии.
Однако при управленииобъектно-ориентированным проектом намечаемые задачи и рассматриваемыерезультаты не совсем такие, как в других системах.Планирование задачНезависимо от размера проекта, которым вы заняты, полезно раз внеделю проводить встречу всех разработчиков для обсуждения выполненнойработы и действий на следующую неделю. Некоторая минимальная частотавстреч необходима, чтобы способствовать общению между членамиколлектива.
С другой стороны, слишком частые встречи снижаютпродуктивность и обычно являются признаком потери курса. Объектноориентированная разработка требует, чтобы разработчики имели достаточноевремя для размышлений, введения новшеств и неформального общения сколлегами. Менеджеры команды должны учитывать в плане и это неструктурированное время.Проводимые встречи дают простую, но эффективную возможностьгладкой подстройки планов в микропроцессе и распознания показавшихся нагоризонте опасных ситуаций. Результатом такой встречи может бытьнебольшая корректировка в распределении работ, обеспечивающаяустойчивость процесса: никакой проект не может позволить хотя бы одномуиз разработчиков сидеть сложа руки, ожидая, пока другие члены командыприведут в порядок свою часть архитектуры.
Это особенно верно дляобъектно-ориентированных систем, в которых архитектура представляетсянабором классов и механизмов. Проект может заглохнуть, если разработчикамникак не удается разобраться с одним из ключевых классов.Планирование задач связано с построением графика представлениярезультатов макропроцесса. В промежутках между очередными релизамименеджеры команды должны оценить трудности, угрожающие проекту,1сконцентрировать ресурсы, чтобы разрешить возникшие проблемы, и далеезаниматься новой итерацией микропроцесса, в результате которой нужнополучить стабильную систему, удовлетворяющую сценариям,запланированным для нового релиза.
Планирование задач на этом уровнеочень часто оказывается неудачным из-за чрезмерно оптимистическихграфиков [4]. Разработка, которая рассматривалась как "просто вопроспрограммирования", растягивается на многие дни работы; графикивыбрасываются в корзину, когда разработчик, занимаясь частью системы,предполагает определенные протоколы для других частей системы, а потомполучает неполно или неправильно изготовленные классы. Смертельнуюопасность могут представлять внезапно обнаружившиеся ошибки вкомпиляторе или то, что программа не укладывается в заданное времяисполнения. И то и другое часто приходится преодолевать, жертвуяпринятыми ранее тактическими решениями.Ключ к тому, чтобы не поддаваться чрезмерно оптимистическомупланированию, - "калибровка" команды и ее инструментов разработки.Типичное планирование задач протекает следующим образом.
Вначалеменеджер направляет энергию разработчика на специфические части системы,например на проектирование классов для интерфейса с реляционной базойданных. Разработчик анализирует необходимые усилия и оценивает времяисполнения, которое менеджер учитывает при планировании других его1Глиб замечает: "если вы не идете в атаку на трудности, трудности идут ватаку на вас" [5].действий. Проблема в том, что эти оценки не всегда реальны: они обычноделаются в расчете на самый благоприятный случай. Один разработчик можетсогласиться на решение задачи за неделю, а другой на эту же задачу попроситмесяц.
Когда работа будет реально выполнена, может оказаться, что онаотняла три недели рабочего времени у обоих разработчиков: первыйразработчик недооценил усилия (общая проблема многих программистов), авторой разработчик оценил реальные усилия более точно (например потому,что он понимал разницу между действительным рабочим временем икалендарным, которое часто заполнено множеством нефункциональныхдействий). Таким образом, чтобы разработать графики, к которым коллективможет иметь доверие, менеджерам необходимо ввести своего рода"калибровочные коэффициенты" для пересчета оценок времени, заявленныхразработчиками. Это не признак того, что менеджеры не доверяютразработчикам, но просто признание того факта, что большинствопрограммистов сосредоточены на технических проблемах, а не на задачахпланирования.
Менеджер должен помогать разработчикам учитьсяпланировать, - но это тот навык, который может быть приобретен толькоопытом.Объектно-ориентированный процесс разработки помогает выявитьявные принципы калибровки. Метод итеративного развития позволяет вначале проекта найти множество промежуточных пунктов, которыеменеджеры команды использовали бы для накопления данных о достиженияхкаждого разработчика, определения графиков работы и планирования встреч.При эволюционной разработке руководители коллектива со временем будутлучше понимать реальную продуктивность каждого своего разработчика, аразработчики смогут научиться более точно оценивать объем предстоящейработы. Те же выводы приложимы и к инструментам: архитектурные релизыуже на ранней стадии проекта стимулируют использование инструментовразработки, которые помогают своевременно проверить структурныеограничения.ПросмотрПросмотр (walkthroughs) - общепринятая практика, которую нужноиспользовать каждой команде разработчиков.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
