Технологии разработки

программного обеспечения –

MSF

Александр Гаврилов

О докладе

• Технологии разработки

• MSF Core

• MSF 4.0

• Visual Studio 2010

Немного терминологии

• Решение (solution) - скоординированная

поставка набора элементов (таких как

программно-технические средства,

документация, обучение и сопровождение),

необходимых для удовлетворения некоторой

бизнес-потребности конкретного заказчика.

• Заинтересованные стороны (stakeholders) – лица либо организации, чьи интересы затрагиваются результатами проекта • Спонсоры проекта (project sponsors) – лица либо организации, которые инициировали проект, выделяют для проекта ресурсы и утверждают его результаты.

Критерии успешности проекта • Качество • Время • Бюджет • Удобство использования, сопровождения и модификации Успешные проекты нечасты Провал Проблемы Успех 15% 51% 34% 23% 49% 28% Источник: The Standish Group International, Chaos reports, 1994- Отсутствие интегрированных средств Среднее превышение сметы:

Разделение бизнеса и технологий 45% Превышение сроков:

Плохое командное взаимодействие 63% Полученная функциональность:

Отслеживание, а не управление 67% Жесткий или незрелый процесс Standish Group Отсутствие баланса между продуктивностью и предсказуемостью Подходы к разработке • Методологии – Состав и последовательность работ – Роли участников проекта – Состав и шаблоны документов – Порядок контроля и проверки качества • Формализация – CMMI – Agile • Используются – Каскадная модель – Rational Unified Process (RUP) – Extreme Programming (XP) – Microsoft Solutions Framework (MSF) – SCRUM – … Создание ПО: методологии, подходы, принципы • Agent-oriented • Dependency injection • Kaizen • Service-oriented modeling programming • Design-driven • Kanban • Software Craftsmanship • Agile software development (D3) • KISS principle original • Software System Safety development • Design Driven Testing (Keep It Simple and • Solid (object-oriented • (DDT) Stupid), derogatory (Keep Agile Unified Process design) (AUP) It Simple, Stupid!) • • Domain-Driven Design Spiral model • • Aspect-oriented (DDD) Lean software • Structured Systems Analysis Programming development • and Design Method (SSADM) Don't repeat yourself • • • Behavior Driven (DRY) or Once and Only Literate Programming SUMMIT Ascendant (now IBM Rational SUMMIT Development (BDD) Once (OAOO), Single • Microsoft Solutions Ascendant) Point of Truth (SPoT) • Framework (MSF) Big Design Up Front • Team Software Process Кратко - MSF • Причиной появления MSF стало осознание в Microsoft проблем в собственном процессе разработки ПО • Первоначальная версия MSF увидела свет в • В 2005 г. была опубликована версия MSF v4. • В 2010 г.- новые стредства инструментальной поддержки Visual Studio • MSF является частью более широкого набора методологий от Microsoft MSF и MOF Microsoft Operations Framework Структура MSF

ДВЕ МОДЕЛИ

Группы

ТРИ ДИСЦИПЛИНЫ

Дисциплина Дисциплина Дисциплина управления управления управления Модель проектной группы Управление проектом Бизнес-приоритеты Маркетинг Представление заказчика Интернационализация Обеспечение технической Характеристики проектной группы MSF • Команда соратников (команда равных) • Наличие единого видения (shared vision) • Распределение ответственности при фиксации отчетности • Нацеленность на необходимый заказчику конечный результат • Наличие у сотрудников необходимых полномочий • Открытое общение • Установка на отсутствие дефектов • Стремление к самосовершенствованию • Гибкость и готовность к переменам • Заинтересованность и энтузиазм Внешние связи проектной группы средства эксплуатации и сопровождения Масштабирование модели проектной группы • В одном ролевом кластере может быть много людей • Один человек может взять на себя несколько ролей • Большие коллективы:

– Создаем группы направлений – Создаем функциональные группы • Малые коллективы:

– Используем таблицу совместимости ролей Таблица совместимости ролей Управл.

продуктом Управл.

проектом Арх-ра Удовл.

потр.

Управл.

выпуском Минимальный коллектив Удовлетворение Управление потребителя программой Управление Управление Тестирование Жизненный цикл ПО Каждая система на протяжении своего существования проходит определенную последовательность процессов (этапов), начиная от постановки задачи, до ее воплощения в готовую программу, эксплуатации и изъятия.

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

Исторически в эту схему работ включают:

– разработку требований или технического задания, – разработку системы или технического проекта, – программирование или рабочее проектирование, – пробную эксплуатацию, – сопровождение и улучшение, – снятие с эксплуатации.

Процессы жизненного цикла • Основные процессы;

– приобретение – разработка – эксплуатация – сопровождение • Обеспечивающие (поддерживающие) процессы;

– документирование, – управление версиями, – верификация и валидация, – просмотры, – оценивание продукта • Организационные процессы – управление проектом (менеджмент разработки), – управление качеством, – управление рисками Последовательность этапов • Модели процессов – Инкрементальная – Итерационная – Эволюционная • Участие заказчика и внесение изменений • Стоимость исправления ошибок • Разделение ролей и специализация разработчиков • Документирование Модель процессов Промежуточные вехи Контрольное тестирование завершено Стоимость исправления ошибок Чем больше проект, тем круче кривая Для малых проектов эта кривая может выродиться в почти горизонтальную почти прямую Выработка Планирование Разработка Стабилизация Внедрение Итеративный подход Минимизируем риски, разбивая большие проекты на несколько версий Функциональность Итерации • Версии • Обновляемые документы • Периодические сборки • Для каждой фазы модели процессов MSF определяет:

– Что (какие артефакты) является результатом – Над чем работает каждый из ролевых кластеров Дисциплина управления рисками • Итеративный процесс • Осуществляется на протяжении • Базируется на посылке о присутствии • Нацелена на проведение профилактических мероприятий Мы не боремся с рисками – мы ими управляем Процесс управления рисками База знаний о рисках Дисциплина управления проектами • Проект (project) – ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги • Управление проектами (project management) – это область знаний, навыков, инструментария и приемов, используемых для достижения целей проектов в рамках согласованных параметров качества, бюджета, сроков и прочих ограничений Управление изменениями • Мы не можем избежать изменений • Но мы можем заранее Ресурсы договориться о приоритетах, руководствоваться при реагировании на Возможности изменения • Для этого используется матрица компромиссов Дисциплина управления способности эффективность Microsoft Solutions Framework 4. • Развитие MSF Core • 2 философии – Быстрые процессы – Формальные процессы • Поддержка в инструментах – Visual Studio Team System Скорость или предсказуемость?

условий конкуренции устойчивых условий • Опора на людей • Опора на процессы • Планируй по мере • Планируй заранее продвижения Разработчики предпочитают Agile MSF Agile Scrum – ключевые принципы Ориентация на нужды заказчика и его клиентов Обязательность исполнения Уважение труда всех членов команды Качественный и удобный обмен информацией Высокий КПД, видимые результаты Характеристики Самоорганизующиеся команды Процесс смешанный: инкрементальный и итеративный Прогресс разработки виден с каждой итерацией - “спринтом” Требования в виде user stories собраны в специальном списке “product backlog” Нет четко прописанных правил, каждая команда выбирает свой путь Product Backlog Содержит все требования (работу по проекту) Записи выполнены в виде пользовательских историй:

работая с программой в роли [кого], я хочу иметь возможность [делать что], чтобы [достигнуть каких результатов] Каждая история должна быть дополнена или планом тестирования, либо сценарием демонстрации заявленной функциональности и приоритезирована владельцем продукта Команда Идеальный размер - 5-9 человек Команда - кросс-функциональна Команда ответственна за принятие обязательств Самоуправляема Роли Максимальная вовлеченность:

ScrumMaster (управление проектом) Владелец продукта (управление продуктом) Команда (архитектура, разработка, тестирование,…) Средняя или низкая вовлеченность:

Пользователь Заказчик Эксперты Масштабирование Команды 5-9 человек Увеличение количества с помощью команды команд Факторы роста:

приложение, размер команды, ее распределение, длительность проекта Scrum использовался и в командах более чем в 500 человек Модель процессов 1. Подготовка и инициация а. Планирование продукта б. Product Backlog 2. Спринты (итерации) 1,2,3,n-раз а. Планирование б. Спринт 3. Конечный результат Спринт Команда работает в течении фиксированного периода - спринта Длительность - от 1 до 4 недель Длительность оговаривается заранее Рекомендуется спринты делать равными по времени Между спринтами нет перерыва MSF Formal • Строгий, документированный процесс • Соответствие CMMI level • Главное – процесс • Большие команды, длительный процесс разработки • MSF Formal расширяет MSF Agile – Больше верификации – Больше планирования – Процедуры утверждения – Отслеживание потраченных ресурсов Идеальный процесс 1. Создание команды 2. Создание плана проекта 3. Создание сайта проекта и библиотеки документов 4. Установка политик изменения кода, сборка 5. Создание логической структуры решения 6. Создание структуры развертывания решения 7. Создание диаграммы классов 8. Создание тестовых сценариев для блочного тестирования 9. Статический анализ кода и профилирование 10.Управление ручным тестированием 11.Нагрузочное тестирование 12.Отчеты по проекту Процесс в виде графика Создание проекта / выбор методологии тестирование классов Инструментальная поддержка:

Visual Studio Team System Программные компоненты Общие:

Visual Studio Team System (VS Team Suite, Team Foundation Server, TFS Build, SharePoint, SQL Server Reporting Services) Дополнительные:

Expression Studio (Blend, Design, Web) Office Applications (Project, Visio, Word, Excel, Outlook) Первые шаги...

Создание командного проекта и портала Треки Бэклог Рабочая книга итерации Актуализация задач Роли Менеджер проекта Бизнес-аналитик Архитектор Разработчик Тестировщик Менеджер проекта Должен поставить в срок решение, удовлетворяющее заказчика Планирует и отслеживает итерации и выполнение работ по ним Следит за статусом проекта Выявляет и минимизирует риски Бизнес-аналитик Работает и с командой, и с заказчиком Создает основополагающий документ видение проекта Выявляет желания и цели заказчиков, трасформируя их в соответствующие рабочие элементы и документы Управляет ожиданиями от продукта Архитектор Создает фундамент - архитектуру разрабатываемой системы и следит за ее корректностью Упрощает систему разбивая ее на модули Создает основные документы по архитектуре Разработчик Основная задача: создание программного обеспечения в срок Оценка времени и трудозатрат Спецификации Профилировка Анализ кода Тестировщик Основная задача: выявление ошибок в системе путем ее тестирования Создание плана тестирования и его поддержка Оценка влияния ошибок на систему Минимизация влияния ошибок Определение стандартов качества Разработчик пользовательского интерфейса Сбор требований Создание концепта Проработка взаимосвязей Создание пользовательского и визуального интерфейсов Тестирование Разработчик баз данных Основная задача: создание программного обеспечения в срок Оценка времени и трудозатрат Спецификации Помощь во взаимодействии с БД Анализ Управляющий выпуском Основная цель: обеспечение и контроль за выпуском продукта Создание плана по выпуску Выбор версий-кандидатов на выпуск или развертывание Скачать полную версию можно www.ms-library.ru А.В.Гаврилов «Технология разработки программных систем»

Александр Гаврилов [email protected]