Лекция 3. Стандартный процесс.
advertisement
Тема 3 Стандартный процесс. Основные этапы внедрения СММ. Структура стандартного процесса разработки ПИ. Конкретный процесс. Совершенствование процесса. Распределение ответственности в коллективе разработчиков. Виды организационных структур. 1 Основные этапы освоения методологии СММ Для получения положительного результата задача разработки и внедрения стандартного процесса (СП) должна быть разбита на несколько этапов Этап 1 Перед предприятием должны быть поставлены реальные цели по достижению в хронологическом порядке уровней зрелости модели СММ и составлен долгосрочный план внедрения СП Этап 2 Необходимо определить компоненты СП предприятия (выбрать из множества требований в каждой ключевой области модели СММ наиболее подходящее подмножество для конкретных условий работы предприятия) 2 Основные этапы освоения методологии СММ (продолжение) Этап 3 Осуществить разработку, внедрение, сопровождение и последующее постоянное совершенствование стандартного процесса, определенного на этапе 2 Для любого предприятия необходимо иметь свой собственный уникальный стандартный процесс 3 Определение стандартного процесса Множество требований 5-го уровня Множество требований 3-го уровня Множество требований 4-го уровня Множество требований СП Множество требований 2-го уровня 4 Определение проектного процесса Конкретный проектный процесс получается из стандартного путем его подгонки под конкретный проект разработки ПИ Множество требований специального проектного процесса Множество требований 5-го уровня Множество требований 3-го уровня Множество требований 4-го уровня Множество требований СП Множество требований 2-го уровня 5 Структура стандартного процесса, с точки зрения разработчика ПИ Основные процессы 88-90% Поддерживающие процессы 10-12% Деятельность при выполнении проекта ПИ 100% 6 Распределение ответственности в коллективе разработчиков ПИ Требования модели СММ Модель СММ не накладывает конкретных рамок на организационную структуру предприятия, выпускающего ПИ Моделью устанавливается лишь совокупность правил распределения ответственности предприятия и отношения подчиненности В модели определены роли руководителей различных уровней 7 Роли руководителей Старший руководитель (Генеральный директор) Главным предметом внимания старшего руководителя является стратегические технические и деловые цели предприятия, долгосрочные и краткосрочные интересы, заключение контрактов и соглашений Старший руководитель несет ответственность за всё Старший руководитель определяет, создает и поддерживает все виды ресурсов для перспективного развития предприятия 8 Руководитель проекта (ответственный исполнитель проекта) Руководитель проекта несет деловую ответственность за ход выполнения проекта ПИ в целом и поставляемые продукты Заказчику 9 Руководитель разработки (архитектор, научный руководитель) Руководитель разработки несет полную ответственность за принятие всех технических решений по разработке ПИ в проекте в целом С руководителем разработки руководитель проекта решает такие вопросы, как стратегия разработки ПИ, выбор аппаратных и программных средств, технологий разработки, тестирования и т.д. 10 Руководители среднего звена (начальники отделов) Руководители среднего звена по разработке ПИ несут прямую организационную ответственность за младших руководителей разработки, включая также ответственность за планирование продвижения по службе и роста зарплаты, комплектование кадров Руководители среднего звена отчитываются непосредственно или косвенно руководителю проекта 11 Младший руководитель (менеджер проекта) Младший руководитель несет прямую ответственность за небольшую команду разработчиков ПИ в проектной группе и несет ответственность за результаты ее деятельности, включая также ответственность за планирование продвижения по службе, роста зарплаты, комплектование кадров 12 Ведущий специалист (системный программист) Ведущий специалист по задачам программирования руководит небольшим коллективом программистов в команде разработчиков, выполняющих конкретные задачи по разработке ПИ, и отвечает за формирование правильной технической направленности работ персонала (включая себя), занятого решением конкретной задачи. Ведущий специалист обычно отчитывается тому же младшему руководителю, что и остальные участники решения задачи 13 Персонал разработчиков ПИ Персонал разработчиков ПИ - это исполнители конкретных работ (аналитики, программисты, инженеры), которые не управляют разработкой, а непосредственно выполняют работы по созданию и сопровождению ПИ. Ведущие специалисты по задачам программирования также относятся к персоналу разработчиков программных средств 14 Описание групп – исполнителей проекта • Группа разработки ПИ (проектная группа) Выполняет разработку ПИ по какому-либо проекту. Руководитель группы несет ответственность за результаты разработки • Группа технологии разработки программ Включает специалистов, координирующих работы по формированию и развитию используемой на предприятии технологии разработки ПИ Может быть самостоятельной, организационно оформленной группой, или рассредоточена по другим группам 15 Описание групп – исполнителей проекта (продолжение) • Группа системных инженеров Составляет спецификации требований для использования или приобретения аппаратных и программных средств для разработки ПИ, осуществляет контроль за приобретением этих средств, проверку их соответствия спецификациям и ввод их в эксплуатацию • Группа тестирования Выполняет независимое тестирование ПИ с целью выяснения его соответствия требованиям Заказчика, работоспособности и надежности функционирования Руководитель группы несет ответственность за составление плана и корректность организации процесса тестирования 16 Описание групп – исполнителей проекта (продолжение) • Группа проверки качества Планирует и осуществляет действия по проверке качества всех продуктов проекта с целью подтверждения того, что выдерживаются технологические этапы разработки ПИ, стандарты и установленный на предприятии уровень качества • Группа управления конфигурацией Отвечает за планирование, координацию и реализацию деятельности по управлению конфигурацией создаваемых в проекте ПИ • Группа обучения Несет ответственность за координацию технического сотрудников предприятия планирование и обучения всех 17 Перераспределение ролей участников проекта Формулировки ролей участников проекта могут изменяться Каждая роль может выполняться одним или несколькими сотрудниками Отдельный сотрудник может играть несколько ролей (например, в проекте среднего размера один и тот же сотрудник может быть младшим руководителем по системному проектированию, руководителем системного проектирования по данному проекту и руководителем проекта в целом) В больших проектах предпочтительно заполнять каждую из ролей различными сотрудниками 18 Перераспределение ролей участников проекта (продолжение) Состав групп может варьироваться от одного исполнителя до нескольких исполнителей из различных подразделений (Например, для небольших проектов группа управления конфигурацией может включать одного инженера-программиста, занимающегося этим видом деятельности только часть рабочего дня) Если сотрудник выполняет несколько ролей, необходимо, чтобы ключевые приемы процесса, требующие независимого исполнения, действительно исполнялись независимо 19 Перераспределение ролей участников проекта (продолжение) Ключевые приемы, требующие независимого исполнения: 1. Варианты системного тестового набора данных и тестовые процедуры должны готовиться группой, независимой от группы, разрабатывающей программы 2. Группа проверки качества должна быть независима от сотрудников, занимающихся разработкой ПИ и от руководителя проекта 20 Виды организационных структур Бюрократические организационные структуры - линейная Органические (адаптивные) организационные структуры - матричная - дивизиональная - функциональная 21 Линейная структура 22 Дивизиональная структура 23 Функциональная структура 24 Слабая матричная структура 25 Сбалансированная матричная структура 26 Сильная матричная структура 27 Проектная организационная структура 28 Сравнение функционально-матричных структур 29 Организационная структура проектной команды Основные понятия Организационные структуры проекта – временная организационная структура, включающая всех его участников Функция — это вид деятельности, выполняемой в ходе проекта, требует определенной специфической квалификации и способностей Роль – это временное назначение сотруднику набора функций в рамках конкретного проекта Должность – это сертифицированная способность играть определенные роли и выполнять определенные функции Иерархическая модель Или «дерево субординации» Офицер Сержант Солдат Солдат Сержант Солдат Солдат Сержант Солдат Солдат Модель «Бригада главного программиста» Секретарь Главный программист Второй пилот Контролер Редактор Архивариус Технолог Администратор Модель «Бригада главного программиста»: модификация «сдвоенный центр» Главный программист Главный программист Контролер Редактор Архивариус Технолог Секретарь Администратор Модель «Команда равных» Управление продуктом Управление программой Обучение пользователей Сопровождение (логистика) Разработка Тестирование
