- •1. Введение в методологию msf и историческая справка
- •2. Что такое методология?
- •3. Основные концепции методологии msf
- •4. Основные положения msf
- •5. Формирование команды. Модель проектной группы
- •14. Управление выпуском
- •15. Удовлетворение потребителя
- •13. Тестирование
- •6. Основные принципы построения команды
- •16. Управление продуктом
- •12. Разработка
- •10. Управление программой
- •7. Ролевые группы и роли
- •11. Архитектура продукта
- •24. Принципы модели процессов
- •8. Зоны ответственности ролевых групп
- •9. Задачи ролевых групп и взаимодействие с заинтересованными лицами
- •17. Рекомендации по возможному объединению ролей
- •18. Основные сведения о рисках
- •19. Планирование управления рисками
- •20. Процесс управления рисками
- •21. Управление рисками как составная часть жизненного цикла проекта
- •22. Учебный пример. Выделение рисков
- •23. Модель процессов msf
- •25. Взаимодействуйте с “заказчиками”
- •26. Поощряйте свободный обмен информацией в проекте
- •27. Создавайте “единое видение проекта”
- •28. Следите за качеством продукта
- •29. Проявляйте гибкость - будьте готовы к изменениям
- •31. Будьте готовы к внедрению сегодня
- •30. Ставьте "вехи"
- •32. Управление компромиссами
- •33. Треугольник компромиссов
- •34. Матрица компромиссов проекта
- •35. Схема процесса разработки
- •36. Структурные единицы схемы
- •37. Цикличность процесса разработки
- •38. Фазы и вехи процесса разработки
- •39. Фаза выработки концепции
- •40 . Основные задачи фазы
- •41. Задачи ролевых групп на фазе выработки концепции
- •44. Выработка концепции
- •43. Результаты фазы выработки концепции
- •42. Вехи фазы выработки концепции
- •45. Видение проекта
- •46. Концепция решения
- •47. Цели и Задачи
- •48. Предположения и Ограничения
- •49. Пользователи
- •50. Сценарии использования
- •51. Рамки
- •52. Функциональность решения
- •53. За рамками решения
- •54. Планирование проекта. Фаза планирования
- •55. Основные задачи фазы
- •56. Задачи ролевых групп на фазе планирования
- •57. Вехи фазы планирования
- •62. Вехи фазы разработки
- •63. Результаты фазы разработки
- •64. Стабилизация решения. Фаза стабилизации
- •65. Основные задачи фазы
- •67. Вехи фазы стабилизации
- •68. Результаты фазы стабилизации
- •66. Задачи ролевых групп на фазе стабилизации
- •69. Внедрение решения. Фаза внедрения
- •70. Основные задачи фазы
- •71. Задачи ролевых групп на фазе внедрения
- •72. Вехи фазы внедрения
- •73. Результаты фазы внедрения
- •74. Компоненты
- •75. Имя компонента
- •80. Узел
- •76. Виды компонент
- •77. Интерфейсы
- •78. Зависимости
- •79. Рекомендации по построению диаграммы компонентов
- •81. Соединения
- •82. Рекомендации по построению диаграммы развертывания
- •83. Кооперация
- •84. Диаграмма кооперации уровня спецификации
- •85. Объекты
- •86. Мультиобъект
- •87. Активный объект
- •88. Составной объект
- •89. Связи
- •90. Стереотипы связей
- •91. Сообщения
- •92. Формат записи сообщений
- •93. Заключительные рекомендации по построению диаграмм кооперации
- •1. Введение в методологию msf и историческая справка
- •2. Что такое методология?
- •3. Основные концепции методологии msf
72. Вехи фазы внедрения
Главная веха фазы: “Внедрение завершено”. Данная веха – кульминация фазы
внедрения .
В течение фазы MSF рекомендует выделить промежуточные вехи:
-
Ключевые компоненты развернуты.
Большинство инфраструктурных решений включают в себя ряд компонент,
образующих основу всего решения. Кроме того:
-
Компоненты могут обеспечивать функционирование ключевых технологий внедряемого решения. Например: контроллеры доменов, маршрутизаторы, почтовые серверы.
-
Для предотвращения задержек, ключевые компоненты могут быть рассмотрены и утверждены к внедрению еще до того, как другие части решения стабилизированы
-
Внедрение на местах завершено.
К моменту прохождения этой вехи все целевые потребители получают доступ к решению. Лица, ответственные за участки внедрения, подписывают акты о пуске решения в эксплуатацию. На этом этапе проектная группа концентрируется на завершении мероприятий по внедрению и на сворачивании проекта.
-
Внедренное решение стабилизировано
К моменту этой вехи заказчик и проектная группа приходят к соглашению о том, что решение функционирует правильно. На этой стадии члены проектной группы и внешние заинтересованные лица начнут выходить из проекта.
73. Результаты фазы внедрения
Результаты фазы внедрения включают в себя:
-
Информационные системы эксплуатации и поддержки.
-
Процедуры и процессы.
-
Базы знаний, отчеты, журналы протоколов.
-
Версии проектных документов, массивы данных и программный код, разработанные во время проекта.
-
Отчет о завершении проекта.
-
Окончательные версии всех проектных документов.
-
Показатели удовлетворенности заказчика и потребителей.
-
Описание последующих шагов.
74. Компоненты
Для представления физических сущностей в языке UML применяется специальный термин - компонент. Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Для графического представления компонента может использоваться специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками:
Внутри большого прямоугольника записывается имя компонента и, возможно, некоторая дополнительная информация.
В UML компонент является потомком классификатора. Он предоставляет организацию в рамках физического пакета ассоциированным с ним элементам модели. Как классификатор, компонент может иметь также свои собственные свойства, такие как атрибуты и операции.
75. Имя компонента
Имя компонента подчиняется общим правилам именования элементов модели в языке UML и может состоять из любого числа букв, цифр и некоторых знаков препинания. Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Хотя его графическое изображение в обоих случаях одинаковое, правила записи имени компонента несколько отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы.
Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается
<имя компонента>:<имя типа>, При этом вся строка имени подчеркивается.
В качестве простых имен принято использовать имена исполняемых файлов, динамических библиотек, Web-страниц, текстовых файлов, файлов БД или файлов с исходными текстами программ.
Поскольку конкретная реализация логического представления модели системы зависит от используемого программного инструментария, то и имена компонентов будут определяться особенностями синтаксиса соответствующего языка программирования.