- •2. Модель па
- •2.1.Бизнес - перспектива
- •2.2.Прикладная перспектива
- •2.3.Информационная перспектива
- •2.4.Технологическая перспектива
- •2.5 Основные опасности при разработке производственной архитектуры
- •2.6 Задачи модели производственной архитектуры msf
- •3. Создание производственной архитектуры
- •1. Общая характеристика модели приложения
- •1.1.Повторное использование компонентов
- •1.2.Размер приложения
- •1.3. Производительность приложения
- •1.4.Масштабируемость приложений
- •1.5.Виды архитектуры
- •2. Модель приложений
- •2.1. Бизнес-модель
- •2.2 Пользовательская модель
- •2.3 Логическая модель
- •2.4 Технологическая модель
- •2.5 Модель разработки
- •2.6 Физическая модель
- •1. Общие характеристики модели проектных групп
- •2. Обязанности членов группы
- •3. Модель проектой группы
- •3.1. Менеджер продукта
- •3.2Менеджер программы
- •3.3.Разработчик
- •3.4 Тестер
- •3.5.Инструктор
- •3.6 .Логистик
- •4.Размер групп и масштаб проекта
- •5. Создание группы
- •5.1.Поиск руководителей
- •5.2.Повышение эффективности коллективной работы
- •5.3. Координация работы с внешними группами
- •1. Модель разработки приложений
- •2.Модель процесса разработки msf
- •Основные этапы
- •Промежуточные этапы
- •Итеративность
- •3. Фазы разработки и их основные этапы.
- •3.1 Фаза Анализ
- •3.3.Фаза «Планирование»
- •3.3.Фаза «Разработка»
- •3.4. Фаза «Стабилизация»
- •4. Принципы модели процесса разработки
- •5.Роли членов группы в модели процесса разработки
- •Динамика фазы Анализ модели процесса разработки msf
- •1.Процесс исследования
- •1.1.Распределение обязанностей ролей
- •2. Модель управление рисками
- •2.1.Источники риска
- •2.2.Способы управления рисками
- •3.Этап «Одобрение концепции» и его результаты
- •3.1Концепция
- •3.2.Прототип
- •3.3. Структура проекта
- •3.4. Сводный документ оценки рисков
- •3.5. Согласование концепции
- •Динамика фазы планирования
- •1.Общая характеристика фазы планирования
- •Фаза «Планирование» и процесс проектирования
- •Распределение ролей при планировании
- •Обязанности ролей при планировании
- •12.Процесс проектирования
- •2.1. Стадии концептуального проектирования
- •2.2.Стадия логического проектирования
- •2.3.Стадия физического проектирования
- •2.1. Управление рисками на фазе планирования
- •4.Этап «Одобрение плана проекта» и его результаты
- •4.1.Функциональные спецификации
- •4.2.Основной план проекта
- •4.2.Основной график проекта
- •4.3.Пересмотренный документ оценки рисков
- •Динамика фазы разработки и ее основные результаты.
- •1. Общая характеристика фазы разработки
- •2. Основные этапы разработки
- •2.1.Распределение обязанностей на стадии разработки
- •2.3.Первый этап: анализ и рационализация
- •2.4.Второй этап: реализация
- •2.5.Третий этап: аттестация
- •2.6.Управление рисками
- •3.Этап «Завершение разработки» и его результаты
- •3.1. Код и исполняемые модули
- •3.2.Средства повышения эффективности работы пользователей и сопроводительные материалы
- •3.3. Тестовые материалы
- •Динамика фазы стабилизации
- •Распределение обязанностей в группе
- •Промежуточные этапы
- •Управление рисками на фазе Стабилизации
- •1)Организованные риски;
- •Этап «Выпуск продукта» и его результаты
3.2Менеджер программы
Задача менеджера программы — вести процесс разработки с учетом всех ограничений.
Главная обязанность менеджера программы — выполнить все стадии разработки так, чтобы нужный продукт был выпущен в нужное время. Он координирует деятельность других членов группы. И хотя иногда ему придется подгонять своих сотрудников, он не должен и помышлять о диктаторском стиле управления. Добиться баланса: характеристик, бюджета разработки, график разработки.Вести процесс разработки под соблюдением этих ограничений, координирует деятельность всех членов проектной группы
Главный менеджер программы составляет график проекта на основе информации, полученной от остальных членов группы. Он координирует этот график с руководителями всех подгрупп. Буферным временем проекта также управляет менеджер программы. Если отдельные части работы выполняются раньше графика или, наоборот, задерживаются, именно менеджер программы должен выяснить, как это скажется на проекте, и изменить график.
Для выполнения своих обязанностей менеджер программы должен отлично разбираться в деловой стороне проекта и иметь ясное представление о технологиях, необходимых для его выполнения. от руководителя отдела программного менеджмента требуется коммуникабельность и талант организатора... группа менеджмента программы управляет ресурсами, используемыми другими ролями, а также составляет и координирует расписания совещаний. Так как менеджер программы отвечает за набор функциональных возможностей приложения, одна из его обязанностей — определить их набор, необходимый для выполнения требований заказчика. Критичные для проекта требования выявляет менеджер продукта, но набор реализующих их функций определяет менеджер программы. Кроме того, менеджер программы дает заказчику рекомендации, касающиеся дальнейшего развития продукта. Отдел программного менеджмента отвечает за функциональные возможности, изложенные в спецификациях (здесь описано, что будет создано) и в главном плане проекта (определяет, как это будет сделано). Он также координирует работу над этими документами. Тем не менее каждый участник проекта вносит свой вклад в функциональные спецификации и в план проекта. Менеджер программы должен полностью положиться на опыт остальных сотрудников и только следить за соблюдением всех условий и ограничений. Менеджер программы отвечает и за бюджет проекта, объединяя требования к ресурсам всех членов группы в единый план расходов. Естественно, его задача — не только разобраться в этих требованиях, но и контролировать реальные затраты, сравнивая их с запланированными. Кроме того, менеджер программы должен регулярно сообщать о состоянии работы всем основным участникам проекта. Ведь одним из симптомов неудачного продукта является отсутствие информации о состоянии проекта.
3.3.Разработчик
Разработчики знакомят остальных членов группы с применяемыми технологиями и собственно создают продукт. В качестве консультантов они предоставляют исходные данные для проектирования, проводят оценку технологий, а также разрабатывают прототипы и тестовые системы, необходимые для проверки решений и сокращения рисков на ранних стадиях процесса разработки. Чтобы создать продукт определенного качества, разработчикам не следует замыкаться на создании кода, они должны участвовать и в решении прикладной задачи Часто, чтобы полностью разобраться в проекте, приходится создавать прототипы, а чтобы протестировать новую технологию. Этим также занимаются разработчики. Как программисты разработчики отвечают за низкоуровневое проектирование и оценку затрат на реализацию продукта. В большинстве организаций несколько основных разработчиков занимаются и архитектурой приложения. Как правило, это требуется на ранних стадиях проекта, когда уточняются детали функциональных спецификаций и описывается взаимодействие продукта с внешними системами. Разработчики сами оценивают сроки своей работы. Такая концепция MSF — создание графиков ответственными за выполнение конкретного участка членами группы — называется составлением расписания «снизу — вверх». Она позволяет выпустить нужный продукт в нужное время за счет уточнения графиков и повышения ответственности за выполнение работы в запланированные сроки. Разработчики отвечают и за техническую реализацию проекта— в основном на фазах создания логической и физической модели. На этих стадиях их задача — определить методы реализации функциональных возможностей и заданной архитектуры, а также оценить сроки выполнения этой работы. Заметим, что разработчики не выбирают функции — они только решают, как их реализовать. Кроме того, на стадии «Планирование» разработчики решают, какое влияние окажет на проект добавление или удаление некоторых функций. Разработчики не участвуют в заключительной стадии проекта — развертывании продукта, однако они должны тесно сотрудничать с логистиками на стадии установки приложения.