SlideShare a Scribd company logo
1 of 18
MSF (Microsoft Solutions Framework)
• Каркас решений Microsoft или Фреймворк для создания
решений от Microsoft (МСФ, MSF).
• МСФ представляет собой каркас процессов, основанных
на принципах и использующих опробованные практики.
MSF (Microsoft Solutions Framework)
• Microsoft Solutions Framework является также
продуктом, предоставляемым Microsoft. В этом качестве
он представляет собой базу знаний в виде пакета
руководств, разделённого на несколько белых книг –
документов, каждый из которых охватывает определённую
модель или дисциплину. Он входит в набор
инструментальных средств Microsoft Visual Studio Team
System для поддержки МСФ.
MSF (Microsoft Solutions Framework)
МСФ основан на наборе из 9 основополагающих
принципов, формирующих общую суть моделей
и дисциплин:
1. Работа в рамках единого видения;
2. Проявление живости, ожидание изменений;
3. Сотрудничество с заказчиками;
4. Поощрение свободного общения;
5. Обучение на любом опыте;
6. Вкладывание [денег] в качество;
7. Поставка инкрементного результата;
8. Установление ясной подотчётности;
9. Наделение полномочиями членов команды.
MSF (Microsoft Solutions Framework)
МСФ предлагает набор из ключевых
концепций:
1. Фокусировка на конечном результате;
2. Поддержка своей клиентуры;
3. Чувство гордости за мастерство;
4. Просмотр всей картины;
5. Непрерывное обучение;
6. Усвоение качества обслуживания.
MSF (Microsoft Solutions Framework)
Модель руководства МСФ обладает
следующими тремя особенностями:
1. Итеративный подход;
2. Подход, основанный на фазах и вехах;
3. Целостный подход к созданию
и внедрению решений.
6
MSF (Microsoft Solutions Framework)
Модель процесса MSF
Водопадная модель – фазы работ и вехи
Спиральная модель – постоянное уточнение
требований, активное взаимодействие с заказчиком.
В MSF объединяются водопадная и спиральная модели:
сохраняются преимущества упорядоченности
водопадной модели, не теряя при этом гибкости и
творческой ориентации спиральной модели.
Модель ЖЦ для подхода MSF
Содержание
завершено
Готовность
выпуска
утверждена
Концепция
утверждена
Планы проекта
утверждены
Разработка
С
т
а
б
и
л
и
з
а
ц
и
я
П
л
а
н
и
р
о
в
а
н
и
е
Представление
Развёртывание
Развёртывание завершено
Модель ЖЦ для подхода MSF
Модель ЖЦ для МСФ отражает один цикл
разработки
• В МСФ выделено всего 5 фаз:
1. Представление;
• 2. Планирование;
• 3. Разработка;
• 4. Стабилизация;
• 5. Развёртывание.
Все фазы разграничены главными вехами. Для
повышенного управления проектом внутри фаз
выделяют ряд промежуточных вех,
показывающих достижение результата
в некоторой деятельности.
• На фазе 1 выполняется создание и сплочение команды
на основе выработки единого видения. Основными задачами
являются создание ядра команды и подготовка документа
с описанием концепции проекта, включающего видение
и содержание проекта. Главная веха 1 считается достигнутой,
если команда и заказчик пришли к соглашению об общих
задачах и сроках проекта, включаемой и не включаемой
в решение функциональности. Результатами являются:
Описание видения и содержания, Документ оценки рисков,
Описание структуры проекта.
• На фазе 2 производится основная работа по составлению
планов проекта. Она включает в себя подготовку командой
функциональной спецификации, разработку дизайнов,
подготовку рабочих планов, оценку проектных затрат и сроков
разработки различных составляющих проекта. Главная веха 2
считается достигнутой, если заказчик и команда пришли
к соглашению о составе решения и сроках поставок.
Утверждённые спецификации, планы и календарные графики
образуют базовый план проекта. Результатами являются:
Функциональная спецификация, План управления рисками,
Сводный план и сводный календарный график проекта.
• На фазе 3 команда фокусируется на создании компонентов
решения. Некоторая часть этой работы может продолжаться
на следующей фазе, если такая необходимость выявлена при
тестировании. Эта фаза также включает в себя разработку
инфраструктуры. Главная веха 3 считается достигнутой, если
создание всех компонентов решения завершено и решение
готово к тестированию и стабилизации. Результатами являются:
Исходный и исполнимый код приложений, Скрипты установки
и конфигурирования, Окончательная функциональная
спецификация, Материалы поддержки решения, Спецификации
и сценарии тестов.
• На фазе 4 производится тестирование разработанного решения.
При этом внимание фокусируется на его эксплуатации
в реалистичной модели производственной среды. Главная
веха 4 считается достигнутой, если команда завершила
разрешение всех существенных проблем и производится
выпуск или внедрение решения. Результатами являются:
«Золотой» выпуск, Документация выпуска, Материалы
поддержки решения, Результаты и инструментарий
тестирования, Исходный и исполнимый код приложений,
Проектная документация, Обзор вехи.
• На фазе 5 команда внедряет технологии и компоненты решения,
стабилизирует внедрённое решение, передаёт работу персоналу поддержки
и сопровождения и получает со стороны заказчика окончательное одобрение
результатов проекта. По завершении внедрения команда производит анализ
работы и удовлетворённости заказчика. Главная веха 5 считается
достигнутой, если решение начало давать заказчику результат, а команда
может свернуть свою деятельность. Результатами являются:
Информационные системы эксплуатации и поддержки, Процедуры
и процессы, Базы знаний, отчёты, журналы протоколов, Версии проектных
документов, массивы нагрузки и код, разработанные во время проекта,
Отчёт о завершении проекта, Окончательные версии всех проектных
документов, Показатели удовлетворённости заказчика и пользователей,
Описание последующих шагов.
• Следует сделать следующие замечания по этой модели ЖЦ.
Длительность фаз не одинакова. Деятельность может
выходить за рамки одной фазы. Наличие / отсутствие
некоторых фаз определяется выполняемым проектом.
• Таким образом, МСФ предлагает модель ЖЦ, основанную
на распределении работ в команде проекта по фазам,
а не на выделении процессов.
15
15
Agile
(гибкая методология разработки ПО)
В отрасли разработки программного обеспечения термин
Agile Development Method появился в начале 2000-х
годов, когда в штате Юта был издан «Манифест гибкой
разработки ПО».
С тех пор под «Agile» понимают набор подходов по
“гибкой” разработке программного обеспечения.
16
16
Agile
Mанифест «живой» разработки
Основные принципы «живой» разработки ПО
зафиксированы в манифесте «живой» разработки:
 Люди их общение более важны, чем процессы и
инструменты
 Работающая программа более важна, чем
исчерпывающая документация
 Сотрудничество с заказчиком более важно, чем
обсуждение деталей контракта
 Отработка изменений более важна, чем следование
планам
17
17
Agile
Mанифест «живой» разработки
Для заказчика манифест можно коротко сформулировать
так:
 разработка ведется короткими циклами (итерациями),
продолжительностью 1-4 недели;
 в конце каждой итерации заказчик получает ценное для
него приложение (или его часть), которое можно
использовать в бизнесе;
 команда разработки сотрудничает с Заказчиком в ходе
всего проекта;
 изменения в проекте приветствуются и быстро
включаются в работу.
18
18
Agile
методологии гибкой разработки ПО
Наиболее известные методологии гибкой разработки ПО:
 Scrum;
 Lean;
 Feature Driving Development;
 Extreme Programming (XP).

More Related Content

Similar to Проектирование_и_архитектура_ПС_2022_L03s.ppt

Бастион Интегратор: Bastion Signal для MS Project Server - контроль и согласо...
Бастион Интегратор: Bastion Signal для MS Project Server - контроль и согласо...Бастион Интегратор: Bastion Signal для MS Project Server - контроль и согласо...
Бастион Интегратор: Bastion Signal для MS Project Server - контроль и согласо...Alexey Yavkin
 
Подход к разработке [Stfalcon.com]
Подход к разработке [Stfalcon.com]Подход к разработке [Stfalcon.com]
Подход к разработке [Stfalcon.com]Stfalcon
 
презентация эуп 12-13
презентация эуп 12-13презентация эуп 12-13
презентация эуп 12-13student_kai
 
Общие темы. Тема 03.
Общие темы. Тема 03. Общие темы. Тема 03.
Общие темы. Тема 03. Igor Shkulipa
 
Методология ведения проектов
Методология ведения проектовМетодология ведения проектов
Методология ведения проектовAlexanderAvva
 
метод Oracle (45)
метод Oracle (45)метод Oracle (45)
метод Oracle (45)romachka_pole
 
Жизненный цикл проекта
Жизненный цикл проектаЖизненный цикл проекта
Жизненный цикл проектаOlya Kollen, PhD
 
Mva stf module 1 - rus
Mva stf module 1 - rusMva stf module 1 - rus
Mva stf module 1 - rusMaxim Shaptala
 
Модуль 7 Проектное управление (учебно-наглядное пособие).
Модуль 7 Проектное управление (учебно-наглядное пособие).Модуль 7 Проектное управление (учебно-наглядное пособие).
Модуль 7 Проектное управление (учебно-наглядное пособие).dontourism
 
современные модели качества программного обеспечения
современные модели качества программного обеспечениясовременные модели качества программного обеспечения
современные модели качества программного обеспеченияcezium
 
Как совместить лучшее из водопадных и аджайл подходов в ИТ проектах
Как совместить лучшее из водопадных и аджайл подходов в ИТ проектахКак совместить лучшее из водопадных и аджайл подходов в ИТ проектах
Как совместить лучшее из водопадных и аджайл подходов в ИТ проектахDanil Dintsis, Ph. D., PgMP
 
10 лет с Docsvision - опыт внедрения, эксплуатации и развития
10 лет с Docsvision - опыт внедрения, эксплуатации и развития10 лет с Docsvision - опыт внедрения, эксплуатации и развития
10 лет с Docsvision - опыт внедрения, эксплуатации и развитияDocsvision
 
Модуль 3. Лекция 15-16. Устав проекта
Модуль 3. Лекция 15-16. Устав проектаМодуль 3. Лекция 15-16. Устав проекта
Модуль 3. Лекция 15-16. Устав проектаYana Brodetski
 
Mva stf module 3 - rus
Mva stf module 3 - rusMva stf module 3 - rus
Mva stf module 3 - rusMaxim Shaptala
 
Управление проектом: планирование, выполнение, контроль
Управление проектом: планирование, выполнение, контрольУправление проектом: планирование, выполнение, контроль
Управление проектом: планирование, выполнение, контрольNatalia Zhelnova
 

Similar to Проектирование_и_архитектура_ПС_2022_L03s.ppt (20)

Бастион Интегратор: Bastion Signal для MS Project Server - контроль и согласо...
Бастион Интегратор: Bastion Signal для MS Project Server - контроль и согласо...Бастион Интегратор: Bastion Signal для MS Project Server - контроль и согласо...
Бастион Интегратор: Bastion Signal для MS Project Server - контроль и согласо...
 
Подход к разработке [Stfalcon.com]
Подход к разработке [Stfalcon.com]Подход к разработке [Stfalcon.com]
Подход к разработке [Stfalcon.com]
 
Inform tech
Inform techInform tech
Inform tech
 
презентация эуп 12-13
презентация эуп 12-13презентация эуп 12-13
презентация эуп 12-13
 
Общие темы. Тема 03.
Общие темы. Тема 03. Общие темы. Тема 03.
Общие темы. Тема 03.
 
CCPM DBR Vebinar 28 01 2010
CCPM DBR Vebinar 28 01 2010CCPM DBR Vebinar 28 01 2010
CCPM DBR Vebinar 28 01 2010
 
Short guide to PMBOK 5
Short guide to PMBOK 5Short guide to PMBOK 5
Short guide to PMBOK 5
 
MS ALM 2013 Review
MS ALM 2013 ReviewMS ALM 2013 Review
MS ALM 2013 Review
 
Методология ведения проектов
Методология ведения проектовМетодология ведения проектов
Методология ведения проектов
 
метод Oracle (45)
метод Oracle (45)метод Oracle (45)
метод Oracle (45)
 
Жизненный цикл проекта
Жизненный цикл проектаЖизненный цикл проекта
Жизненный цикл проекта
 
Mva stf module 1 - rus
Mva stf module 1 - rusMva stf module 1 - rus
Mva stf module 1 - rus
 
Модуль 7 Проектное управление (учебно-наглядное пособие).
Модуль 7 Проектное управление (учебно-наглядное пособие).Модуль 7 Проектное управление (учебно-наглядное пособие).
Модуль 7 Проектное управление (учебно-наглядное пособие).
 
современные модели качества программного обеспечения
современные модели качества программного обеспечениясовременные модели качества программного обеспечения
современные модели качества программного обеспечения
 
Как совместить лучшее из водопадных и аджайл подходов в ИТ проектах
Как совместить лучшее из водопадных и аджайл подходов в ИТ проектахКак совместить лучшее из водопадных и аджайл подходов в ИТ проектах
Как совместить лучшее из водопадных и аджайл подходов в ИТ проектах
 
Projekts Lean
Projekts LeanProjekts Lean
Projekts Lean
 
10 лет с Docsvision - опыт внедрения, эксплуатации и развития
10 лет с Docsvision - опыт внедрения, эксплуатации и развития10 лет с Docsvision - опыт внедрения, эксплуатации и развития
10 лет с Docsvision - опыт внедрения, эксплуатации и развития
 
Модуль 3. Лекция 15-16. Устав проекта
Модуль 3. Лекция 15-16. Устав проектаМодуль 3. Лекция 15-16. Устав проекта
Модуль 3. Лекция 15-16. Устав проекта
 
Mva stf module 3 - rus
Mva stf module 3 - rusMva stf module 3 - rus
Mva stf module 3 - rus
 
Управление проектом: планирование, выполнение, контроль
Управление проектом: планирование, выполнение, контрольУправление проектом: планирование, выполнение, контроль
Управление проектом: планирование, выполнение, контроль
 

More from dinarium2016

НуП_Лекция 8. Работа с файлами на Ассемблере.ppt
НуП_Лекция 8. Работа с файлами на Ассемблере.pptНуП_Лекция 8. Работа с файлами на Ассемблере.ppt
НуП_Лекция 8. Работа с файлами на Ассемблере.pptdinarium2016
 
НуП_Лекция 7. Работа с каталогами диска.ppt
НуП_Лекция 7. Работа с каталогами диска.pptНуП_Лекция 7. Работа с каталогами диска.ppt
НуП_Лекция 7. Работа с каталогами диска.pptdinarium2016
 
НуП_Лекция 5. Управление видеосистемой.ppt
НуП_Лекция 5. Управление видеосистемой.pptНуП_Лекция 5. Управление видеосистемой.ppt
НуП_Лекция 5. Управление видеосистемой.pptdinarium2016
 
НуП_Лекция 2. Управление программами.ppt
НуП_Лекция 2. Управление программами.pptНуП_Лекция 2. Управление программами.ppt
НуП_Лекция 2. Управление программами.pptdinarium2016
 
Проектирование_и_архитектура_ПС_2022_L09s.ppt
Проектирование_и_архитектура_ПС_2022_L09s.pptПроектирование_и_архитектура_ПС_2022_L09s.ppt
Проектирование_и_архитектура_ПС_2022_L09s.pptdinarium2016
 
Проектирование_и_архитектура_ПС_2022_L08s.ppt
Проектирование_и_архитектура_ПС_2022_L08s.pptПроектирование_и_архитектура_ПС_2022_L08s.ppt
Проектирование_и_архитектура_ПС_2022_L08s.pptdinarium2016
 
Проектирование_и_архитектура_ПС_2022_L07s.ppt
Проектирование_и_архитектура_ПС_2022_L07s.pptПроектирование_и_архитектура_ПС_2022_L07s.ppt
Проектирование_и_архитектура_ПС_2022_L07s.pptdinarium2016
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptdinarium2016
 
Проектирование_и_архитектура_ПС_2022_L05s.ppt
Проектирование_и_архитектура_ПС_2022_L05s.pptПроектирование_и_архитектура_ПС_2022_L05s.ppt
Проектирование_и_архитектура_ПС_2022_L05s.pptdinarium2016
 
Проектирование_и_архитектура_ПС_2022_L04s.ppt
Проектирование_и_архитектура_ПС_2022_L04s.pptПроектирование_и_архитектура_ПС_2022_L04s.ppt
Проектирование_и_архитектура_ПС_2022_L04s.pptdinarium2016
 
Проектирование_и_архитектура_ПС_2022_L02s.ppt
Проектирование_и_архитектура_ПС_2022_L02s.pptПроектирование_и_архитектура_ПС_2022_L02s.ppt
Проектирование_и_архитектура_ПС_2022_L02s.pptdinarium2016
 
Проектирование_и_архитектура_ПС_2022_L01.ppt
Проектирование_и_архитектура_ПС_2022_L01.pptПроектирование_и_архитектура_ПС_2022_L01.ppt
Проектирование_и_архитектура_ПС_2022_L01.pptdinarium2016
 

More from dinarium2016 (12)

НуП_Лекция 8. Работа с файлами на Ассемблере.ppt
НуП_Лекция 8. Работа с файлами на Ассемблере.pptНуП_Лекция 8. Работа с файлами на Ассемблере.ppt
НуП_Лекция 8. Работа с файлами на Ассемблере.ppt
 
НуП_Лекция 7. Работа с каталогами диска.ppt
НуП_Лекция 7. Работа с каталогами диска.pptНуП_Лекция 7. Работа с каталогами диска.ppt
НуП_Лекция 7. Работа с каталогами диска.ppt
 
НуП_Лекция 5. Управление видеосистемой.ppt
НуП_Лекция 5. Управление видеосистемой.pptНуП_Лекция 5. Управление видеосистемой.ppt
НуП_Лекция 5. Управление видеосистемой.ppt
 
НуП_Лекция 2. Управление программами.ppt
НуП_Лекция 2. Управление программами.pptНуП_Лекция 2. Управление программами.ppt
НуП_Лекция 2. Управление программами.ppt
 
Проектирование_и_архитектура_ПС_2022_L09s.ppt
Проектирование_и_архитектура_ПС_2022_L09s.pptПроектирование_и_архитектура_ПС_2022_L09s.ppt
Проектирование_и_архитектура_ПС_2022_L09s.ppt
 
Проектирование_и_архитектура_ПС_2022_L08s.ppt
Проектирование_и_архитектура_ПС_2022_L08s.pptПроектирование_и_архитектура_ПС_2022_L08s.ppt
Проектирование_и_архитектура_ПС_2022_L08s.ppt
 
Проектирование_и_архитектура_ПС_2022_L07s.ppt
Проектирование_и_архитектура_ПС_2022_L07s.pptПроектирование_и_архитектура_ПС_2022_L07s.ppt
Проектирование_и_архитектура_ПС_2022_L07s.ppt
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.ppt
 
Проектирование_и_архитектура_ПС_2022_L05s.ppt
Проектирование_и_архитектура_ПС_2022_L05s.pptПроектирование_и_архитектура_ПС_2022_L05s.ppt
Проектирование_и_архитектура_ПС_2022_L05s.ppt
 
Проектирование_и_архитектура_ПС_2022_L04s.ppt
Проектирование_и_архитектура_ПС_2022_L04s.pptПроектирование_и_архитектура_ПС_2022_L04s.ppt
Проектирование_и_архитектура_ПС_2022_L04s.ppt
 
Проектирование_и_архитектура_ПС_2022_L02s.ppt
Проектирование_и_архитектура_ПС_2022_L02s.pptПроектирование_и_архитектура_ПС_2022_L02s.ppt
Проектирование_и_архитектура_ПС_2022_L02s.ppt
 
Проектирование_и_архитектура_ПС_2022_L01.ppt
Проектирование_и_архитектура_ПС_2022_L01.pptПроектирование_и_архитектура_ПС_2022_L01.ppt
Проектирование_и_архитектура_ПС_2022_L01.ppt
 

Проектирование_и_архитектура_ПС_2022_L03s.ppt

  • 1. MSF (Microsoft Solutions Framework) • Каркас решений Microsoft или Фреймворк для создания решений от Microsoft (МСФ, MSF). • МСФ представляет собой каркас процессов, основанных на принципах и использующих опробованные практики.
  • 2. MSF (Microsoft Solutions Framework) • Microsoft Solutions Framework является также продуктом, предоставляемым Microsoft. В этом качестве он представляет собой базу знаний в виде пакета руководств, разделённого на несколько белых книг – документов, каждый из которых охватывает определённую модель или дисциплину. Он входит в набор инструментальных средств Microsoft Visual Studio Team System для поддержки МСФ.
  • 3. MSF (Microsoft Solutions Framework) МСФ основан на наборе из 9 основополагающих принципов, формирующих общую суть моделей и дисциплин: 1. Работа в рамках единого видения; 2. Проявление живости, ожидание изменений; 3. Сотрудничество с заказчиками; 4. Поощрение свободного общения; 5. Обучение на любом опыте; 6. Вкладывание [денег] в качество; 7. Поставка инкрементного результата; 8. Установление ясной подотчётности; 9. Наделение полномочиями членов команды.
  • 4. MSF (Microsoft Solutions Framework) МСФ предлагает набор из ключевых концепций: 1. Фокусировка на конечном результате; 2. Поддержка своей клиентуры; 3. Чувство гордости за мастерство; 4. Просмотр всей картины; 5. Непрерывное обучение; 6. Усвоение качества обслуживания.
  • 5. MSF (Microsoft Solutions Framework) Модель руководства МСФ обладает следующими тремя особенностями: 1. Итеративный подход; 2. Подход, основанный на фазах и вехах; 3. Целостный подход к созданию и внедрению решений.
  • 6. 6 MSF (Microsoft Solutions Framework) Модель процесса MSF Водопадная модель – фазы работ и вехи Спиральная модель – постоянное уточнение требований, активное взаимодействие с заказчиком. В MSF объединяются водопадная и спиральная модели: сохраняются преимущества упорядоченности водопадной модели, не теряя при этом гибкости и творческой ориентации спиральной модели.
  • 7. Модель ЖЦ для подхода MSF Содержание завершено Готовность выпуска утверждена Концепция утверждена Планы проекта утверждены Разработка С т а б и л и з а ц и я П л а н и р о в а н и е Представление Развёртывание Развёртывание завершено
  • 8. Модель ЖЦ для подхода MSF Модель ЖЦ для МСФ отражает один цикл разработки • В МСФ выделено всего 5 фаз: 1. Представление; • 2. Планирование; • 3. Разработка; • 4. Стабилизация; • 5. Развёртывание. Все фазы разграничены главными вехами. Для повышенного управления проектом внутри фаз выделяют ряд промежуточных вех, показывающих достижение результата в некоторой деятельности.
  • 9. • На фазе 1 выполняется создание и сплочение команды на основе выработки единого видения. Основными задачами являются создание ядра команды и подготовка документа с описанием концепции проекта, включающего видение и содержание проекта. Главная веха 1 считается достигнутой, если команда и заказчик пришли к соглашению об общих задачах и сроках проекта, включаемой и не включаемой в решение функциональности. Результатами являются: Описание видения и содержания, Документ оценки рисков, Описание структуры проекта.
  • 10. • На фазе 2 производится основная работа по составлению планов проекта. Она включает в себя подготовку командой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта. Главная веха 2 считается достигнутой, если заказчик и команда пришли к соглашению о составе решения и сроках поставок. Утверждённые спецификации, планы и календарные графики образуют базовый план проекта. Результатами являются: Функциональная спецификация, План управления рисками, Сводный план и сводный календарный график проекта.
  • 11. • На фазе 3 команда фокусируется на создании компонентов решения. Некоторая часть этой работы может продолжаться на следующей фазе, если такая необходимость выявлена при тестировании. Эта фаза также включает в себя разработку инфраструктуры. Главная веха 3 считается достигнутой, если создание всех компонентов решения завершено и решение готово к тестированию и стабилизации. Результатами являются: Исходный и исполнимый код приложений, Скрипты установки и конфигурирования, Окончательная функциональная спецификация, Материалы поддержки решения, Спецификации и сценарии тестов.
  • 12. • На фазе 4 производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Главная веха 4 считается достигнутой, если команда завершила разрешение всех существенных проблем и производится выпуск или внедрение решения. Результатами являются: «Золотой» выпуск, Документация выпуска, Материалы поддержки решения, Результаты и инструментарий тестирования, Исходный и исполнимый код приложений, Проектная документация, Обзор вехи.
  • 13. • На фазе 5 команда внедряет технологии и компоненты решения, стабилизирует внедрённое решение, передаёт работу персоналу поддержки и сопровождения и получает со стороны заказчика окончательное одобрение результатов проекта. По завершении внедрения команда производит анализ работы и удовлетворённости заказчика. Главная веха 5 считается достигнутой, если решение начало давать заказчику результат, а команда может свернуть свою деятельность. Результатами являются: Информационные системы эксплуатации и поддержки, Процедуры и процессы, Базы знаний, отчёты, журналы протоколов, Версии проектных документов, массивы нагрузки и код, разработанные во время проекта, Отчёт о завершении проекта, Окончательные версии всех проектных документов, Показатели удовлетворённости заказчика и пользователей, Описание последующих шагов.
  • 14. • Следует сделать следующие замечания по этой модели ЖЦ. Длительность фаз не одинакова. Деятельность может выходить за рамки одной фазы. Наличие / отсутствие некоторых фаз определяется выполняемым проектом. • Таким образом, МСФ предлагает модель ЖЦ, основанную на распределении работ в команде проекта по фазам, а не на выделении процессов.
  • 15. 15 15 Agile (гибкая методология разработки ПО) В отрасли разработки программного обеспечения термин Agile Development Method появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «Agile» понимают набор подходов по “гибкой” разработке программного обеспечения.
  • 16. 16 16 Agile Mанифест «живой» разработки Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки:  Люди их общение более важны, чем процессы и инструменты  Работающая программа более важна, чем исчерпывающая документация  Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта  Отработка изменений более важна, чем следование планам
  • 17. 17 17 Agile Mанифест «живой» разработки Для заказчика манифест можно коротко сформулировать так:  разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;  в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;  команда разработки сотрудничает с Заказчиком в ходе всего проекта;  изменения в проекте приветствуются и быстро включаются в работу.
  • 18. 18 18 Agile методологии гибкой разработки ПО Наиболее известные методологии гибкой разработки ПО:  Scrum;  Lean;  Feature Driving Development;  Extreme Programming (XP).