Цель
|
Определить количество, тип (навыки, специальность), квалификацию и уровень персонала, необходимого для
проекта
|
На основе оценки трудозатрат для проекта, желательного расписания, выбранной организационной структуры и отображения
ролей руководитель проекта определяет профайл персонала (необходимое количество сотрудников в разные периоды и их
навыки) для проекта. Оценка трудозатрат для проекта, конечно, не зависит от количества сотрудников, их опыта и
квалификации; в то же время, при оценке трудозатрат руководитель почти наверняка будет исходить из неявных
предположений о возможностях персонала. В параграфе Модель оценивания COCOMO (см. раздел Задача: этапы и итерации проекта) возможности и опыт персонала
являются основными драйверами трудозатрат. Таким образом, выбор приемлемых общих трудозатрат (путем варьирования
драйверов трудозатрат COCOMO) и осуществимого расписания будет определяющим при составлении профайла персонала.
В некоторых случаях руководителю проекта заранее известно о количестве будущих сотрудников и уровне их квалификации.
В таких случаях, при заданном штате и уровне квалификации, переменной величиной является только расписание, в
предположении, что рамки проекта остаются неизменными.
Руководитель проекта также должен учитывать, что слишком быстрое повышение уровней персонала может привести к срыву
проекта, а также, что попытка резко сократить расписание за счет увеличения штата может привести к серьезному снижению
производительности.
На начальном этапе основной упор делается на определение рамок проекта и разработку экономического обоснования проекта.
Следовательно, коллектив будет невелик: руководитель проекта, архитектор программного обеспечения, а также, возможно,
один-два разработчика, особенно в случае, когда необходим прототип доказательства концепции для прояснения требований
или поддержки компоновки продукта.
На этапе уточнения основное внимание уделяется архитектуре и прототипу архитектуры. Следовательно, задачи
проектирования на начальной стадии уточнения концентрируются на архитектурных аспектах; подробностям описания классов и
их атрибутов уделяется гораздо меньше внимания, поскольку они, хотя и определены, не имеют значения для архитектуры. Во
время этих итераций большая часть трудозатрат приходится на коллектив архитекторов и назначенный коллектив, отвечающий
за прототипы. В последний обычно входят более опытные программисты. На этот момент вы располагаете еще очень небольшим
коллективом разработчиков, который пока занимается общими механизмами и технологиями. Группа тестирования займется
компоновкой среды тестирования и проверкой первых вариантов использования.
Выбирать будущих архитекторов следует очень тщательно: они должны не только быть высококвалифицированными специалистами
по анализу и проектированию, но и обладать лидерскими качествами. Для того чтобы члены более крупного коллектива могли
ознакомиться с архитектурой на этапе построения, рекомендуется распределить архитекторов среди коллективов, отвечающих
за построение. Архитекторы должны также быть специалистами во многих областях, связанных с разработкой программного
обеспечения: проектировании и реализации программного обеспечения, настройке производительности, управлении базами
данных, сетью и конфигурацией.
На этапе построения обеспечивается архитектурная целостность системы в условиях добавления в систему все новых и новых
функций. Для этого необходимы архитектурное уточнение (создание "контрольных версий", а не "замораживание" архитектуры
после этапа уточнения) и коллектив архитекторов, который следит за работой проектировщиков.
Архитекторы, как правило, внедряются в коллективы разработчиков, играя роль технических руководителей и координируя с
другими техническими руководителями взаимодействие между коллективами. Коллективы строителей должны быть
многофункциональными, обладающими навыками как проектирования, так и разработки, поскольку они отвечают и за
проектирование, и за реализацию назначенных им функциональных возможностей. Обычно коллектив строителей отвечает за
разработку одной или нескольких подсистем с определенными интерфейсами; изменения в этих интерфейсах или добавление
новых подсистем вызывают соответствующую модификацию архитектуры и должны рассматриваться со всей тщательностью. В
пределах подсистемы коллектив сравнительно свободен в проектировании и реализации того, что считает необходимым, однако
во избежание параллельной разработки одних и тех же механизмов реализации требуется обмен информацией между
коллективами.
Как правило, коллективы строителей организованы в виде горизонтальной структуры - по уровням. Один коллектив отвечает
за интерфейсы баз данных или инфраструктуру связи, в то время как другие занимаются непосредственно функциональными
возможностями приложений. Вследствие этого, коллективы "верхнего" уровня должны лучше разбираться в проблемной области,
проектировании пользовательских интерфейсов и создании интерфейсов для внешних систем. Коллективы более "низких"
уровней имеют дело непосредственно с технологией реализации. При составлении этих коллективов необходимо учитывать
различия в требованиях к их навыкам.
Первый вопрос при тестировании: насколько обширным оно должно быть по формальным правилам? Второй вопрос: какую часть
требуемого вы можете выполнить, чтобы, с одной стороны, обеспечить требуемое качество, с другой - не потратить слишком
много денег и времени? Как правило, бюджета проекта не хватает на проведение всех тестов. По этой причине, при работе
над проектом необходимо выбрать приемлемый уровень тестирования. Помните, что все спецификации тестирования необходимо
проверить и осуществить. Если вы запланируете множество спецификаций тестирования, но не успеете воплотить эти планы в
жизнь из-за нехватки времени, то это произведет крайне отрицательное впечатление на сотрудников коллектива, работающих
над проектом.
Создайте специальный коллектив для проведения тестирования. По крайней мере один сотрудник в этом коллективе должен
быть из коллектива, отвечающего за прием требований. Коллектив для проведения тестирования отвечает за следующее:
-
Тестирование в режиме "черного ящика". Тестирование вариантов использования извне системы на основе потока
событий варианта использования (см. раздел Рабочий
продукт: вариант использования).
-
Тестирование в режиме "белого ящика". Тестирование фактической отправки сообщений в варианте использования
на основе последовательных панелей для сценариев.
-
Тест системы. Тестирование системы на отказоустойчивость для выяснения ее истинной природы.
Помните, что тестирование - это не только проведение тестов, но и подготовка среды тестирования, а также написание и
проверка спецификаций тестирования.
Тестирование вариантов использования и всей системы должна провести независимая группа. Члены группы должны выполнить
тесты и написать отчеты о тестировании. Работа по тестированию вариантов использования должна быть организована таким
образом, чтобы за тестирование каждого варианта использования отвечал отдельный сотрудник.
Если провести тестирование вариантов использования силами независимой группы, как в небольшом проекте, невозможно, то,
по крайней мере, проследите за тем, чтобы сотрудник, отвечающий за вариант использования в проектировании, не
тестировал этот вариант.
В средних и больших проектах следует применять автоматизированное регрессионное тестирование. Для этого коллективу,
проводящему тестирование, потребуются несколько программистов. Это еще более важно во время итерационной разработки,
когда вы не хотите тратить время и силы на повторное выполнение одних и тех же комплектов тестов.
На этапе внедрения разработка уже завершена. Проводится бета-тестирование и подготавливается окончательный выпуск. Если
на этапе построения все было сделано правильно, то коллектив можно начинать уменьшать, сокращая число разработчиков и
проводящих тестирование. В коллективе возрастет доля инструкторов и экспертов по логистике инфраструктуры, отвечающих
за развертывание проекта в среде пользователей.
Архитектор программного обеспечения, или коллектив архитекторов, работает в "режиме проверки исполнения": он помогает
рассортировать отчеты о проблемах и расставить предложения и заказы на внесение изменений по приоритету, следя за тем,
чтобы проблемы не устранялись в ущерб архитектуре ради сиюминутных выгод. На этапе внедрения задачи проектирования
отходят на задний план и ограничиваются исправлением ошибок и внесением мелких поправок.
|