Управление программным проектом (УПП) – 2

1. Руководитель проекта в RUP

2. Краткий обзор действий УПП RUP

3. Изложение деловых обстоятельств

4. Идентификация рисков

5. Разработка плана проекта

6. Формирование проектной группы

7. Соотношение работника и персоны (индивидуума)

8. Управление рисками

ЭТО ПРОЦЕСС:

•   СИСТЕМАТИЧЕСКОГО ВЫЯВЛЕНИЯ ПОТЕНЦИАЛЬНЫХ РИСКОВЫХ СОБЫТИЙ

• ОЦЕНКИ УРОВНЯ ИХ ВЛИЯНИЯ,

• РАЗРАБОТКИ РЕШЕНИЙ ПО УПРАВЛЕНИЮ, ПРИМЕНЯЕМЫХ В СТРАТЕГИЧЕСКОМ И ОПЕРАТИВНОМ УПРАВЛЕНИИ ДЛЯ ОБЕСПЕЧЕНИЯ УВЕРЕННОСТИ В ДОСТИЖЕНИИ ЦЕЛЕЙ.

9. Понятие о риске

Подверженность потере или ущербу

Фактор, вещь, элемент или направление движения, заключающий вероятную опасность

10. Понятие успеха проекта

Достижение всех требований и ограничений, ожидаемых от проекта

11. Прямой и косвенный риски

Прямой риск – риск, который в существенной степени может контролироваться проектом

Косвенный риск – риск, мало или вообще никак не управляемый проектом

12. Классификация рисков М.Фаулера

13. Стратегии работы с рисками

14. Двухуровневое планирование

15. Артефакт "План проекта"

16. Артефакт "План итерации"

1. Структура SWEBOK

-Software requirements – Требования к ПО

-Software design – Проектирование

-Softwareconstruction – конструирование ПО

-Software testing – тестирование

-Softwaremaintenance – эксплуатация (поддержка) ПО

-Software configurationmanagement – конфигурационноеуправление

-Software engineering management – управлениевпрограммнойинженерии

-Software engineeringprocess – процессыпрограммнойинженерии

-Software engineering tools and methods – инструменты и методы

-Softwarequality – качество программного обеспечения

2. Цели проектирования

Получить глубокое понимание моментов, относящихся к нефункциональным требованиям и ограничениям.

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

Определить основные интерфейсы между подсистемами.

3. Процесс проектирования

4. Связность и связанность

Связность, соединение (Cohesion) модуля – это мера зависимости его частей.

Чем выше связность модуля, тем лучше результат проектирования (тем «чернее» его ящик (Орлов))

Связанность, сцепление (Coupling) – определяет силу связи (часто, взаимного влияния) между модулями.

Связанность — внешняя характеристика модуля, которую желательно уменьшать.

5. Достаточность, полнота и простота

Этот подход подразумевает, что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией (моделью), но не более того.

То есть не включают функциональность, отсутствующую в модели.

Данный принципyнаиблоее ярко представлен в гибких (agile) подходах к разработке ПО через метафору YAGNI

“YouAren’ t GoingtoNeedIt”, то есть “не делай этого, пока не понадобится”.

6. Usage-centered design (Констатайн-Локвуд)

Модель ролей

Модель задач

Модель содержимого

Операционная модель

Модель реализации.

Мы поможем в написании ваших работ!