На главную страницу
Форум txt.version   



Статья :: 7.2. Кадры : Гради Буч

7.2. Кадры

Распределение ресурсов

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

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

Роли разработчиков

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

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

• архитектор проекта;

• ответственные за подсистемы;

• прикладные программисты.

Архитектор проекта - его творец, человек с сильно развитым воображением; он отвечает за эволюцию и сопровождение архитектуры системы. Для малых или средних систем архитектурное проектирование обычно выполняется одной, максимум двумя светлыми личностями. Для больших проектов эта обязанность может быть распределена в большом коллективе. Архитектор проекта - не обязательно самый главный разработчик, но непременно такой, который может квалифицированно принимать стратегические решения (как правило благодаря обширному опыту в построении систем такого типа). Благодаря опыту, разработчики интуитивно знают, какие общие архитектурные шаблоны уместны в данной предметной области и какие проблемы эффективности встают в определенных архитектурных вариантах. Архитекторы - не обязательно лучшие программисты, хотя они должны уметь программировать. Точно так же, как строительные архитекторы должны разбираться в строительстве, неблагоразумно нанимать архитектора программного обеспечения, который не является приличным программистом. Архитекторы проекта должны также быть сведущи в обозначениях и организации процесса объектно-ориентированной разработки, потому что они должны в конечном счете выразить свое архитектурное видение в терминах кластеров классов и взаимодействующих объектов.

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

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

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

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

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

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

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

? Менеджер проекта   Отвечает за управление материалами проекта, заданиями, ресурсами и графиком работ. 

 ? Аналитик   Отвечает за развитие и интерпретацию требований конечных пользователей; должен быть экспертом в проблемной области, однако его не следует изолировать от остальной команды разработчиков. 

 ? Инженер по повторному использованию   Управляет хранилищем (репозитарием) материалов проекта; участвуя в просмотре и других действиях, активно ищет общее и добивается его использования; находит, разрабатывает или приспосабливает компоненты для общего использования в рамках конкретного проекта или целой организации. 

 ? Контролер качества   Измеряет результаты процесса разработки; задает общее направление (на системном уровне) тестирования всех прототипов и релизов. 

 ? Менеджер интеграции   Отвечает за сборку совместимых друг с другом версий категорий и подсистем в релизы; следит за их конфигурированием. 

 ? Ответственный за документацию   Готовит документацию по выпускаемому продукту и его архитектуре для конечного пользователя. 

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

 ? Системный администратор   Управляет физическими компьютерными ресурсами в проекте. 

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

Опыт показывает, что объектно-ориентированная разработка может обойтись меньшим числом занятых в ней людей по сравнению с традиционными методами. На самом деле, чтобы за один год произвести высококачественную программу объемом в несколько сот тысяч строк достаточно 30-40 разработчиков. Однако мы согласны с Боемом, который считает, что "лучшие результаты получаются, когда разработчиков занято меньше, а квалификация их выше" [6]. К сожалению, если при разработке проекта пытаться обойтись меньшим количеством людей, чем считается необходимым, можно встретить известное сопротивление. Как отмечалось в предыдущей главе, такое отношение, возможно, вызвано попытками некоторых менеджеров построить империю. Другие менеджеры любят скрываться за множеством служащих, потому что большее количество людей означает больше власти. Кроме того, в случае провала проекта есть на кого свалить вину. Применение самого изощренного метода проектирования или новейших инструментов не освобождает менеджера от ответственности за подбор проектировщиков, способных мыслить, и не является основанием для того, чтобы пустить проект на самотек [7].




7.2. Кадры : Гради Буч

страницы в данном разделе 
Объектно-ориентированный анализ и проектирование с примерами приложений на С++ : Гради Буч Предисловие : Гради Буч
ЧАСТЬ ПЕРВАЯ Концепции : Гради Буч 1.1. Сложность, присущая программному обеспечению : Гради Буч
1.2. Структура сложных систем : Гради Буч 1.3. Внесение порядка в хаос : Гради Буч
1.4. О проектировании сложных систем : Гради Буч Дополнительная литература : Гради Буч
Глава 2 Объектная модель : Гради Буч 2.1. Эволюция объектной модели : Гради Буч
2.2. Составные части объектного подхода : Гради Буч 2.3. Применение объектной модели : Гради Буч
Выводы : Гради Буч Дополнительная литература : Гради Буч
Глава 3 Классы и объекты : Гради Буч 3.1. Природа объекта : Гради Буч
3.2. Отношения между объектами : Гради Буч 3.3. Природа классов : Гради Буч
3.4. Отношения между классами : Гради Буч 3.5. Взаимосвязь классов и объектов. : Гради Буч
3.6. Качество классов и объектов : Гради Буч Дополнительная литература : Гради Буч
Глава 4 Классификация : Гради Буч 4.1. Важность правильной классификации : Гради Буч
4.2. Идентификация классов и объектов : Гради Буч 4.3. Ключевые абстракции и механизмы : Гради Буч
Дополнительная литература : Гради Буч 1.1. Сложность, присущая программному обеспечению : Гради Буч
1.2. Структура сложных систем : Гради Буч 1.3. Внесение порядка в хаос : Гради Буч
1.4. О проектировании сложных систем : Гради Буч Дополнительная литература : Гради Буч
1.1. Сложность, присущая программному обеспечению : Гради Буч 1.2. Структура сложных систем : Гради Буч
1.3. Внесение порядка в хаос : Гради Буч 1.4. О проектировании сложных систем : Гради Буч
Дополнительная литература : Гради Буч 2.1. Эволюция объектной модели : Гради Буч
2.2. Составные части объектного подхода : Гради Буч 2.3. Применение объектной модели : Гради Буч
Выводы : Гради Буч Дополнительная литература : Гради Буч
2.1. Эволюция объектной модели : Гради Буч 2.2. Составные части объектного подхода : Гради Буч
2.3. Применение объектной модели : Гради Буч Выводы : Гради Буч
Дополнительная литература : Гради Буч 3.1. Природа объекта : Гради Буч
3.2. Отношения между объектами : Гради Буч 3.3. Природа классов : Гради Буч
3.4. Отношения между классами : Гради Буч 3.5. Взаимосвязь классов и объектов. : Гради Буч
3.6. Качество классов и объектов : Гради Буч Дополнительная литература : Гради Буч
3.1. Природа объекта : Гради Буч 3.2. Отношения между объектами : Гради Буч
3.3. Природа классов : Гради Буч 3.4. Отношения между классами : Гради Буч
3.5. Взаимосвязь классов и объектов. : Гради Буч 3.6. Качество классов и объектов : Гради Буч
Дополнительная литература : Гради Буч 4.1. Важность правильной классификации : Гради Буч
4.2. Идентификация классов и объектов : Гради Буч 4.3. Ключевые абстракции и механизмы : Гради Буч
Дополнительная литература : Гради Буч 4.1. Важность правильной классификации : Гради Буч
4.2. Идентификация классов и объектов : Гради Буч 4.3. Ключевые абстракции и механизмы : Гради Буч
Дополнительная литература : Гради Буч ЧАСТЬ ВТОРАЯ Метод : Гради Буч
продолжение 70 : Гради Буч 5.1. Элементы обозначений : Гради Буч
5.2. Диаграммы классов : Гради Буч 5.3. Диаграммы состояний и переходов : Гради Буч
5.4. Диаграммы объектов : Гради Буч   5.5. Диаграммы взаимодействия : Гради Буч
5.6. Диаграммы модулей : Гради Буч 5.7. Диаграммы процессов. : Гради Буч
5.8. Применение системы обозначений : Гради Буч Глава 6 Процесс : Гради Буч
6.1. Основные принципы : Гради Буч 6.2. Микропроцесс проектирования : Гради Буч
6.3. Макропроцесс проектирования : Гради Буч Выводы : Гради Буч
Дополнительная литература : Гради Буч Глава 7 Практические вопросы : Гради Буч
7.1. Управление и планирование : Гради Буч 7.2. Кадры : Гради Буч
7.3. Управление релизами : Гради Буч 7.4. Повторное использование : Гради Буч
7.5. Качество и измерения : Гради Буч 7.6. Документация : Гради Буч
7.7. Инструменты : Гради Буч 7.8. Специальные вопросы : Гради Буч
7.9. Выгоды и опасности объектно-ориентированной разработки : Гради Буч Глава 5 Обозначения : Гради Буч
5.1. Элементы обозначений : Гради Буч 5.2. Диаграммы классов : Гради Буч
5.3. Диаграммы состояний и переходов : Гради Буч 5.4. Диаграммы объектов : Гради Буч
  5.5. Диаграммы взаимодействия : Гради Буч 5.6. Диаграммы модулей : Гради Буч
5.7. Диаграммы процессов. : Гради Буч 5.8. Применение системы обозначений : Гради Буч
продолжение 104 5.1. Элементы обозначений : Гради Буч
5.2. Диаграммы классов : Гради Буч 5.3. Диаграммы состояний и переходов : Гради Буч
5.4. Диаграммы объектов : Гради Буч   5.5. Диаграммы взаимодействия : Гради Буч
5.6. Диаграммы модулей : Гради Буч 5.7. Диаграммы процессов. : Гради Буч
5.8. Применение системы обозначений : Гради Буч 6.1. Основные принципы : Гради Буч
6.2. Микропроцесс проектирования : Гради Буч 6.3. Макропроцесс проектирования : Гради Буч
Выводы : Гради Буч Дополнительная литература : Гради Буч
6.1. Основные принципы : Гради Буч 6.2. Микропроцесс проектирования : Гради Буч
6.3. Макропроцесс проектирования : Гради Буч Выводы : Гради Буч
Дополнительная литература : Гради Буч 7.1. Управление и планирование : Гради Буч
7.2. Кадры : Гради Буч 7.3. Управление релизами : Гради Буч
7.4. Повторное использование : Гради Буч 7.5. Качество и измерения : Гради Буч
7.6. Документация : Гради Буч 7.7. Инструменты : Гради Буч
7.8. Специальные вопросы : Гради Буч 7.9. Выгоды и опасности объектно-ориентированной разработки : Гради Буч
7.1. Управление и планирование : Гради Буч 7.2. Кадры : Гради Буч
7.3. Управление релизами : Гради Буч 7.4. Повторное использование : Гради Буч
7.5. Качество и измерения : Гради Буч 7.6. Документация : Гради Буч
7.7. Инструменты : Гради Буч 7.8. Специальные вопросы : Гради Буч
7.9. Выгоды и опасности объектно-ориентированной разработки : Гради Буч ЧАСТЬ ТРЕТЬЯ Примеры приложений : Гради Буч
продолжение 142 : Гради Буч   8.1. Анализ : Гради Буч
8.2. Проектирование : Гради Буч 8.3. Эволюция : Гради Буч
8.4. Сопровождение : Гради Буч Глава 9 Среда разработки: библиотека базовых классов : Гради Буч
продолжение 148 : Гради Буч 9.1. Анализ : Гради Буч
9.2. Проектирование : Гради Буч 9.3. Эволюция : Гради Буч
9.4. Сопровождение : Гради Буч Глава 10 Архитектура клиент-сервер: складской учет : Гради Буч
продолжение 154 : Гради Буч 10.1. Анализ : Гради Буч
10.2. Проектирование : Гради Буч 10.3. Эволюция : Гради Буч
Глава 11 Искусственный интеллект: криптоанализ : Гради Буч продолжение 159 : Гради Буч
11.1. Анализ : Гради Буч 11.2. Проектирование : Гради Буч
11.3. Эволюция : Гради Буч 11.4. Сопровождение : Гради Буч
Глава 12 Управление: контроль за движением поездов : Гради Буч продолжение 165 : Гради Буч
12.1. Анализ : Гради Буч 12.2. Проектирование : Гради Буч
12.3. Эволюция : Гради Буч 12.4. Сопровождение : Гради Буч
Глава 8 Система сбора данных: метеорологическая станция : Гради Буч   8.1. Анализ : Гради Буч
8.2. Проектирование : Гради Буч 8.3. Эволюция : Гради Буч
8.4. Сопровождение : Гради Буч продолжение 175
  8.1. Анализ : Гради Буч 8.2. Проектирование : Гради Буч
8.3. Эволюция : Гради Буч 8.4. Сопровождение : Гради Буч
Глава 9 Среда разработки: библиотека базовых классов : Гради Буч 9.1. Анализ : Гради Буч
9.2. Проектирование : Гради Буч 9.3. Эволюция : Гради Буч
9.4. Сопровождение : Гради Буч продолжение 185
9.1. Анализ : Гради Буч 9.2. Проектирование : Гради Буч
9.3. Эволюция : Гради Буч 9.4. Сопровождение : Гради Буч
Глава 10 Архитектура клиент-сервер: складской учет : Гради Буч 10.1. Анализ : Гради Буч
10.2. Проектирование : Гради Буч 10.3. Эволюция : Гради Буч
продолжение 194 10.1. Анализ : Гради Буч
10.2. Проектирование : Гради Буч 10.3. Эволюция : Гради Буч
Глава 11 Искусственный интеллект: криптоанализ : Гради Буч 11.1. Анализ : Гради Буч
11.2. Проектирование : Гради Буч 11.3. Эволюция : Гради Буч
11.4. Сопровождение : Гради Буч продолжение 203
11.1. Анализ : Гради Буч 11.2. Проектирование : Гради Буч
11.3. Эволюция : Гради Буч 11.4. Сопровождение : Гради Буч
Глава 12 Управление: контроль за движением поездов : Гради Буч 12.1. Анализ : Гради Буч
12.2. Проектирование : Гради Буч 12.3. Эволюция : Гради Буч
12.4. Сопровождение : Гради Буч продолжение 213
12.1. Анализ : Гради Буч 12.2. Проектирование : Гради Буч
12.3. Эволюция : Гради Буч 12.4. Сопровождение : Гради Буч
А.1. Концепции : Гради Буч А.2. Smalltalk : Гради Буч
А.3. Object Pascal : Гради Буч А.4. C++ : Гради Буч
А.5. Common Lisp Object System (CLOS) : Гради Буч А.6. Ada : Гради Буч
A.7. Eiffel : Гради Буч А.1. Концепции : Гради Буч
А.2. Smalltalk : Гради Буч А.3. Object Pascal : Гради Буч
А.4. C++ : Гради Буч А.5. Common Lisp Object System (CLOS) : Гради Буч
А.6. Ada : Гради Буч A.7. Eiffel : Гради Буч
Словарь терминов : Гради Буч Литературные ссылки : Гради Буч

Разделы
Околокомпьютерная литература (375)
Программирование (102)
Программы (75)
ОС и Сети (49)
Интернет (29)
Аппаратное обеспечение (16)
Базы данных (6)
Flutter
React Native
Xamarin