Модели жизненного цикла программных средств. Требования к ПО, страница 12

Масштабирование команды MSF. Наличие 7 ролевых кластеров не означает, что команда должна состоять из 7 человек. Один сотрудник может объединять несколько ролей, при этом некоторые роли нельзя объединять. В таблице представлены рекомендации MSF относительно совмещения ролей в рамках одним членом команды «+» - совмещение возможно, «+/-» - совмещение возможно, но не желательно, «-» - совмещение не рекомендуется

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

Когда ролевому кластеру требуется много ресурсов, формируются функциональные группы, которые потом объединяются в кластеры. Они образуются в больших проектах, когда необходимо сгруппировать работников, внутри кластера, по их областям компетенции. В команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей (разработка бизнес логики, объекты данных, интерфейсы пользователя и т.д.). Часто программистов разделяют на разработчиков библиотек и разработчиков решения. Программисты библиотек обычно используют низкоуровневые решения (Язык С) и создают повторно используемые компоненты, которые могут быть полезны всему проекту. Создатели решения обычно соединяют эти компоненты и работают с языками более высокого уровня.

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

1.  Модель процессов

Водопадная модель

2.  Спиральная модель- уточнение требований на каждом витке и активное взаимодействие с заказчиком

3.  В MSF объединяются водопадная и спиральные модели- т.е. сохраняется преимущество водопадной модели, не теряя при этом гибкости и творческой ориентации спиральной модели

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

Управление компромиссами:

Хорошо известна взаимозависимость между ресурсами проекта, его календарным графиком и реализуемыми возможностями.

Ресурсы                            Время

Возможности

После достижения равновесия в этом треугольнике изменения на любой из его сторон для поддержания баланса требуют модификации на других сторонах

CMMI