Управление программным проектом (УПП) – 2
| 1. Руководитель проекта в RUP
|
| 2. Краткий обзор действий УПП RUP
|
| 3. Изложение деловых обстоятельств
|
| 4. Идентификация рисков
|
| 5. Разработка плана проекта
|
| 6. Формирование проектной группы
|
| 7. Соотношение работника и персоны (индивидуума)
|
| 8. Управление рисками ЭТО ПРОЦЕСС: • СИСТЕМАТИЧЕСКОГО ВЫЯВЛЕНИЯ ПОТЕНЦИАЛЬНЫХ РИСКОВЫХ СОБЫТИЙ • ОЦЕНКИ УРОВНЯ ИХ ВЛИЯНИЯ, • РАЗРАБОТКИ РЕШЕНИЙ ПО УПРАВЛЕНИЮ, ПРИМЕНЯЕМЫХ В СТРАТЕГИЧЕСКОМ И ОПЕРАТИВНОМ УПРАВЛЕНИИ ДЛЯ ОБЕСПЕЧЕНИЯ УВЕРЕННОСТИ В ДОСТИЖЕНИИ ЦЕЛЕЙ. |
| 9. Понятие о риске Подверженность потере или ущербу Фактор, вещь, элемент или направление движения, заключающий вероятную опасность |
| 10. Понятие успеха проекта Достижение всех требований и ограничений, ожидаемых от проекта |
| 11. Прямой и косвенный риски Прямой риск – риск, который в существенной степени может контролироваться проектом Косвенный риск – риск, мало или вообще никак не управляемый проектом |
| 12. Классификация рисков М.Фаулера
|
| 13. Стратегии работы с рисками
|
| 14. Двухуровневое планирование
|
| 15. Артефакт "План проекта"
|
| 16. Артефакт "План итерации" |

SWEBOK. Область знаний «Проектирование ПО»
| 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 (Констатайн-Локвуд) Модель ролей Модель задач Модель содержимого Операционная модель Модель реализации. |
Дата добавления: 2018-02-15; просмотров: 1107; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!














