Что такое findslide.org?

FindSlide.org - это сайт презентаций, докладов, шаблонов в формате PowerPoint.


Для правообладателей

Обратная связь

Email: Нажмите что бы посмотреть 

Яндекс.Метрика

Презентация на тему Цикл разработки программного обеспечения

Содержание

Павловская Т.А. (СПбГУ ИТМО)ПроектОдним из ключевых понятий технологии разработки программного обеспечения, как и многих других областей деятельности, является понятие проекта. Проект есть уникальное временное предприятие, направленное на создание определенного, уникального продукта и услуги. Технология управления проектом
Цикл разработки ПО и роль тестера на каждом этапе Павловская Т.А. (СПбГУ ИТМО)ПроектОдним из ключевых понятий технологии разработки программного обеспечения, как Павловская Т.А. (СПбГУ ИТМО)Четыре «П» разработки ПОПерсонал(кто это делает)Процесс(способ, которым это делается)Проект(выполнение необходимых действий)Продукт(артефакты) Павловская Т.А. (СПбГУ ИТМО)ПродуктАртефакт – любой вид информации, создаваемый, изменяемый и используемый Павловская Т.А. (СПбГУ ИТМО)ПроектСовокупность действий, необходимых для создания артефакта:контакт с заказчикомнаписание документациипроектированиепрограммированиетестирование… Павловская Т.А. (СПбГУ ИТМО)ПроцессПроцесс создания ПО – определение полного набора видов деятельности, Павловская Т.А. (СПбГУ ИТМО)Семейства процессов разработки ПОтяжеловесные (heavyweight)применяются при фиксированных требованиях и Павловская Т.А. (СПбГУ ИТМО)Стратегии создания ПО Павловская Т.А. (СПбГУ ИТМО)Технологии программирования Технология программирования (технология разработки ПО) — способ Павловская Т.А. (СПбГУ ИТМО)Источники сложности проектаНаличие высококвалифицированных специалистов на рынке труда. Стабильность Павловская Т.А. (СПбГУ ИТМО)Проблемы управления проектамиМногие процессы разработки неуправляемы. Их исходные данные Павловская Т.А. (СПбГУ ИТМО)Водопадная модель жизненного цикла ПО:Синонимы: классический ЖЦ, каскадная модель Павловская Т.А. (СПбГУ ИТМО)Модель с промежуточным контролем: Павловская Т.А. (СПбГУ ИТМО)Макетирование (прототипирование)Построение/уточнение макетаОценка макета заказчиком12  Проектирование продукта Павловская Т.А. (СПбГУ ИТМО)Инкрементная модельАнализПроектированиеКодиро-ваниеТестиро-ваниеПоставка 1-гоинкремента1-й инкрементАнализПроектированиеКодиро-ваниеТестиро-вание2-й инкрементАнализПроектированиеКодиро-ваниеТестиро-вание3-й инкрементПоставка 2-гоинкрементаПоставка 3-гоинкремента Павловская Т.А. (СПбГУ ИТМО)Технология RAD Rapid Application Development — Быстрая разработка приложений. Ориентирована Павловская Т.А. (СПбГУ ИТМО)Этапы RADБизнес-моделирование (моделируются информационные потоки между бизнес-функциями)Моделирование данных (набор Павловская Т.А. (СПбГУ ИТМО)Спиральная модель разработки ПОПрограммное обеспечение создается итерационно с использованием Павловская Т.А. (СПбГУ ИТМО)Особенности спиральной моделиОсновным достоинством спиральной схемы является то, что, Павловская Т.А. (СПбГУ ИТМО)Гибкие технологии разработки ПОМинимизируют риски благодаря разделению процесса разработки Павловская Т.А. (СПбГУ ИТМО)Основные идеи agile• Личности и их взаимодействие важнее, чем Павловская Т.А. (СПбГУ ИТМО)Основы манифеста гибких технологий• Главное – удовлетворение требований заказчика Павловская Т.А. (СПбГУ ИТМО)Проектирование в гибких технологияхОтказ от длительного проектирования перед началом Павловская Т.А. (СПбГУ ИТМО)Разработчики получают задачу, берут соответствующий фрагмент разрабатываемого кода, выполняют Павловская Т.А. (СПбГУ ИТМО)Экстремальное программированиеОсновная идея экстремального программирования (ХР) — устранить высокую Павловская Т.А. (СПбГУ ИТМО)Основные принципы ХРПланирование Частая смена версий Метафора Простой проект ТестыПереработка системы Программирование в паре Непрерывная  интеграция Коллективное владение Заказчик с постоянным участием 40-часовая неделя Открытое рабочее  Тестирование в ХРТестирование модулей (unit testing):позволяет разработчикам убедиться, что код работает корректно, Павловская Т.А. (СПбГУ ИТМО)ScrumОсновой Scrum является итеративная разработка. Scrum определяет итеративные правила Павловская Т.А. (СПбГУ ИТМО)Общие положения3 роли: владелец продукта (Product Owner) - отвечает Павловская Т.А. (СПбГУ ИТМО)Реализация проекта в ScrumФаза реализации разбита на последовательность итераций Павловская Т.А. (СПбГУ ИТМО)Документация в Scrum Всего 3 документа: журнал продукта (Product Павловская Т.А. (СПбГУ ИТМО)Унифицированный процесс (RUP)Разработчики: Г. Буч, А. Якобсон, Д. Рамбо Павловская Т.А. (СПбГУ ИТМО)Характеристики УПуправляемый вариантами использованияархитектурно-ориентированныйитеративный и инкрементныйиспользует UMLоснован на компонентном Павловская Т.А. (СПбГУ ИТМО)Преимущества управляемого УПОграничивает финансовые риски затратами на одну итерациюСнижает Павловская Т.А. (СПбГУ ИТМО)Жизненный цикл УПКаждый цикл состоит из 4х фаз, каждая Павловская Т.А. (СПбГУ ИТМО)Назначение вехПо ним руководитель принимает решения перед тем, как Павловская Т.А. (СПбГУ ИТМО)Цикл разработки Павловская Т.А. (СПбГУ ИТМО)Содержание фазАнализ и планирование требований:идея превращается в концепцию готового Павловская Т.А. (СПбГУ ИТМО)Построениеуточнение базового уровня архитектурыреализация всех вариантов использованияВнедрениебета-версиятренинги сотрудников заказчиковисправление дефектов Павловская Т.А. (СПбГУ ИТМО)Модели УПМодели – наиболее важный тип артефактов. Каждая модель Павловская Т.А. (СПбГУ ИТМО)UMLЯзык для специфицирования, визуализации, конструирования и документирования программных продуктов.Также Павловская Т.А. (СПбГУ ИТМО)Диаграммы вариантов использования  (Use case diagrams) Павловская Т.А. (СПбГУ ИТМО)Диаграммы деятельности  (Activity diagrams) Павловская Т.А. (СПбГУ ИТМО)Диаграммы последовательностей действий (Sequence diagrams) Павловская Т.А. (СПбГУ ИТМО)Диаграммы компонент (Component diagrams) Павловская Т.А. (СПбГУ ИТМО)Пример реального процесса разработки ПО Павловская Т.А. (СПбГУ ИТМО)Обзор идеиВыдвигается идея нового продукта Назначается менеджер по продукту Павловская Т.А. (СПбГУ ИТМО)Обзор проектаPjM назначает системного архитектора (SWA) и старшего тестера Павловская Т.А. (СПбГУ ИТМО)Подготовка проектаPjM уточняет план проекта, назначает команду разработчиков, организует Павловская Т.А. (СПбГУ ИТМО)Разработка продукта (Development) - 1SWA разрабатывает на утверждение SG Павловская Т.А. (СПбГУ ИТМО)Разработка продукта (Development) - 2Выполняется итеративно: анализ, дизайн, программирование, Павловская Т.А. (СПбГУ ИТМО)Альфа-тестированиеИтеративное тестирование продукта тестерами под руководством CQA. Как только Павловская Т.А. (СПбГУ ИТМО)Бета-тестированиеПродукт отсылается на ознакомление и тестирование ограниченному набору пользователей Павловская Т.А. (СПбГУ ИТМО)Подготовка к выпуску и выпускPdM и HPdM проверяют, что Павловская Т.А. (СПбГУ ИТМО)все! Павловская Т.А. (СПбГУ ИТМО)CASE-технологии Computer Aided Software/System Engineering – автоматизированная разработка ПО/системСуществуют Павловская Т.А. (СПбГУ ИТМО)Компонентный подход и САSЕ-технологии Компонентный подход предполагает построение программного Павловская Т.А. (СПбГУ ИТМО)Технология СОМ определяет общий принцип взаимодействия программ любых типов: Павловская Т.А. (СПбГУ ИТМО)На базе технологии COM были разработаны компонентные технологии, решающие Павловская Т.А. (СПбГУ ИТМО)MTS (Microsoft Transaction Server — сервер управления транзакциями) — Павловская Т.А. (СПбГУ ИТМО)Технология СОRВАТехнология СОRВА, разработанная группой компаний ОМG, реализует подход,
Слайды презентации

Слайд 2 Павловская Т.А. (СПбГУ ИТМО)
Проект
Одним из ключевых понятий технологии

Павловская Т.А. (СПбГУ ИТМО)ПроектОдним из ключевых понятий технологии разработки программного обеспечения,

разработки программного обеспечения, как и многих других областей деятельности,

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

Слайд 3 Павловская Т.А. (СПбГУ ИТМО)
Четыре «П» разработки ПО
Персонал
(кто это

Павловская Т.А. (СПбГУ ИТМО)Четыре «П» разработки ПОПерсонал(кто это делает)Процесс(способ, которым это делается)Проект(выполнение необходимых действий)Продукт(артефакты)

делает)
Процесс
(способ, которым это делается)
Проект
(выполнение необходимых действий)
Продукт
(артефакты)


Слайд 4 Павловская Т.А. (СПбГУ ИТМО)
Продукт
Артефакт – любой вид информации,

Павловская Т.А. (СПбГУ ИТМО)ПродуктАртефакт – любой вид информации, создаваемый, изменяемый и

создаваемый, изменяемый и используемый сотрудниками при создании системы
Артефакты:
Само приложение
Спецификация

требований
Проектная модель
Исходный и объектный код
Тестовые процедуры


Слайд 5 Павловская Т.А. (СПбГУ ИТМО)
Проект
Совокупность действий, необходимых для создания

Павловская Т.А. (СПбГУ ИТМО)ПроектСовокупность действий, необходимых для создания артефакта:контакт с заказчикомнаписание документациипроектированиепрограммированиетестирование…

артефакта:
контакт с заказчиком
написание документации
проектирование
программирование
тестирование


Слайд 6 Павловская Т.А. (СПбГУ ИТМО)
Процесс
Процесс создания ПО – определение

Павловская Т.А. (СПбГУ ИТМО)ПроцессПроцесс создания ПО – определение полного набора видов

полного набора видов деятельности, необходимых для преобразования требований пользователя

в продукт.
Процесс служит шаблоном для создания проекта.
Процесс определяет:
кто делает
что делает
когда делает
как достичь цели

Процессы делятся на тяжеловесные и легковесные (гибкие)



Слайд 7 Павловская Т.А. (СПбГУ ИТМО)
Семейства процессов разработки ПО
тяжеловесные (heavyweight)
применяются

Павловская Т.А. (СПбГУ ИТМО)Семейства процессов разработки ПОтяжеловесные (heavyweight)применяются при фиксированных требованиях

при фиксированных требованиях и многочисленной группе разработчиков разной квалификации
облегченные

(lightweight, agile)
применяются при малочисленной группе квалифицированных разработчиков и грамотном заказчике, который имеет возможность участвовать в процессе

Начнем с гибких технологий - наиболее актуальных.

Слайд 8 Павловская Т.А. (СПбГУ ИТМО)
Стратегии создания ПО

Павловская Т.А. (СПбГУ ИТМО)Стратегии создания ПО

Слайд 9 Павловская Т.А. (СПбГУ ИТМО)
Технологии программирования
Технология программирования (технология

Павловская Т.А. (СПбГУ ИТМО)Технологии программирования Технология программирования (технология разработки ПО) —

разработки ПО) — способ организации процесса создания программы, совокупность

приемов и способов выполнения определенных видов деятельности.
На разных уровнях и по разным критериям выделяют пересекающиеся модели:
Водопадная (каскадная) модель, нисходящее (структурное) программирование
Макетирование
Спиральная (итерационная) модель разработки ПО
Объектно-ориентированное программирование
Гибкие (agile) технологии: экстремальное программирование (XP), Scrum, TDD, FDD…
RUP
Компонентный подход (COM, CORBA)
САSЕ-технологии
RAD

— Почему вы пилите тупой пилой, ведь это очень долго и трудно?
— Некогда точить, пилить надо!!!


Слайд 10 Павловская Т.А. (СПбГУ ИТМО)
Источники сложности проекта
Наличие высококвалифицированных специалистов

Павловская Т.А. (СПбГУ ИТМО)Источники сложности проектаНаличие высококвалифицированных специалистов на рынке труда.

на рынке труда.
Стабильность используемой технологической платформы, стабильность и

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

Слайд 11 Павловская Т.А. (СПбГУ ИТМО)
Проблемы управления проектами
Многие процессы разработки

Павловская Т.А. (СПбГУ ИТМО)Проблемы управления проектамиМногие процессы разработки неуправляемы. Их исходные

неуправляемы. Их исходные данные и желаемый результат неизвестны или

определены очень нечетко.
Процесс достижения желаемого результата не поддается формализации (например, разработка архитектуры и исчерпывающее тестирование продукта).
Идентифицированные процессы разработки сопровождаются неизвестным количеством неидентифицированных.
Требования к продукту часто меняются в течение жизненного цикла проекта, что требует сложной процедуры изменения и согласования требований.
Попытки предложить формальную, детализованную методологию разработки ПО оказываются безуспешны, потому что сам процесс разработки не поддается детализации и формализации.
Слепое следование методологиям, предполагающим управляемость и предсказуемость процессов разработки, приводит к непредсказуемым результатам проекта.

Слайд 12 Павловская Т.А. (СПбГУ ИТМО)
Водопадная модель жизненного цикла ПО:
Синонимы:

Павловская Т.А. (СПбГУ ИТМО)Водопадная модель жизненного цикла ПО:Синонимы: классический ЖЦ, каскадная модель

классический ЖЦ, каскадная модель


Слайд 13 Павловская Т.А. (СПбГУ ИТМО)
Модель с промежуточным контролем:

Павловская Т.А. (СПбГУ ИТМО)Модель с промежуточным контролем:

Слайд 14 Павловская Т.А. (СПбГУ ИТМО)
Макетирование (прототипирование)
Построение/уточнение макета
Оценка макета заказчиком
1
2

Павловская Т.А. (СПбГУ ИТМО)Макетирование (прототипирование)Построение/уточнение макетаОценка макета заказчиком12 Проектирование продукта

Проектирование продукта


Слайд 15 Павловская Т.А. (СПбГУ ИТМО)
Инкрементная модель
Анализ
Проектирование
Кодиро-вание
Тестиро-вание
Поставка 1-го
инкремента
1-й инкремент
Анализ
Проектирование
Кодиро-вание
Тестиро-вание
2-й инкремент
Анализ
Проектирование
Кодиро-вание
Тестиро-вание
3-й

Павловская Т.А. (СПбГУ ИТМО)Инкрементная модельАнализПроектированиеКодиро-ваниеТестиро-ваниеПоставка 1-гоинкремента1-й инкрементАнализПроектированиеКодиро-ваниеТестиро-вание2-й инкрементАнализПроектированиеКодиро-ваниеТестиро-вание3-й инкрементПоставка 2-гоинкрементаПоставка 3-гоинкремента

инкремент
Поставка 2-го
инкремента
Поставка 3-го
инкремента


Слайд 16 Павловская Т.А. (СПбГУ ИТМО)
Технология RAD
Rapid Application Development —

Павловская Т.А. (СПбГУ ИТМО)Технология RAD Rapid Application Development — Быстрая разработка приложений.

Быстрая разработка приложений. Ориентирована на максимально быстрое получение первых

версий разрабатываемого ПО. Она предусматривает:
ведение разработки небольшими группами (3-7 человек), каждая из которых проектирует и реализует отдельные подсистемы, позволяет улучшить управляемость проекта;
использование готовых компонентов способствует уменьшению времени получения работоспособного прототипа;
наличие четко проработанного графика цикла, рассчитанного не более чем на три месяца, существенно увеличивает эффективность работы.
Технология RAD хорошо зарекомендовала себя для относительно небольших стандартных проектов, разрабатываемых для конкретного заказчика.

Слайд 17 Павловская Т.А. (СПбГУ ИТМО)
Этапы RAD
Бизнес-моделирование (моделируются информационные потоки

Павловская Т.А. (СПбГУ ИТМО)Этапы RADБизнес-моделирование (моделируются информационные потоки между бизнес-функциями)Моделирование данных

между бизнес-функциями)
Моделирование данных (набор объектов, которые требуются для поддержки

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

Слайд 18 Павловская Т.А. (СПбГУ ИТМО)
Спиральная модель разработки ПО
Программное обеспечение

Павловская Т.А. (СПбГУ ИТМО)Спиральная модель разработки ПОПрограммное обеспечение создается итерационно с

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

программный продукт, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения.

На 1-й итерации может использоваться макет, который оценивается заказчиком.


Слайд 19 Павловская Т.А. (СПбГУ ИТМО)
Особенности спиральной модели
Основным достоинством спиральной

Павловская Т.А. (СПбГУ ИТМО)Особенности спиральной моделиОсновным достоинством спиральной схемы является то,

схемы является то, что, начиная с некоторой итерации, продукт

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

Основной проблемой использования спиральной схемы является определение моментов перехода на следующие стадии. Для ее решения обычно ограничивают сроки прохождения каждой стадии, основываясь на экспертных оценках.
Спиральную модель применяют для программ, основанных как на процедурной, так и на объектно-ориентированной парадигме.


Слайд 20 Павловская Т.А. (СПбГУ ИТМО)
Гибкие технологии разработки ПО

Минимизируют риски

Павловская Т.А. (СПбГУ ИТМО)Гибкие технологии разработки ПОМинимизируют риски благодаря разделению процесса

благодаря разделению процесса разработки на маленькие промежутки времени (итерации),

обычно 1-4 недели.
Каждая итерация может рассматриваться как полноценный проект (может включать в себя планирование, анализ требований, проектирование, реализацию, тестирование и документирование).
Обычно результатом итерации не является продукт, готовый к выходу на рынок. Но целью каждой итерации является получение стабильной версии продукта.
В конце каждой итерации происходит переоценка приоритетов проекта, что значительно сокращает риски.
Все гибкие методологии имеют общие характеристики:
• итеративная разработка;
• фокус на взаимодействии и коммуникации;
•полный или частичный отказ от создания дорогостоящих промежуточных артефактов проекта.

Слайд 21 Павловская Т.А. (СПбГУ ИТМО)
Основные идеи agile
• Личности и

Павловская Т.А. (СПбГУ ИТМО)Основные идеи agile• Личности и их взаимодействие важнее,

их взаимодействие важнее, чем процессы и инструменты.
• Работающее программное

обеспечение важнее, чем полная документация.
• Сотрудничество с заказчиком важнее, чем переговоры по контракту.
• Реакция на изменения важнее, чем следование плану.

Краеугольным камнем гибких технологий программирования является разработка через тестирование:
автоматические тесты пишутся для любой части реализации, которая гипотетически «может сломаться»;
тесты пишутся непосредственно перед написанием соответствующего кода;
существующий код никогда не меняется без написания соответствующих тестов;
выполняется регулярный запуск всех автоматических тестов.



Слайд 22 Павловская Т.А. (СПбГУ ИТМО)
Основы манифеста гибких технологий
• Главное

Павловская Т.А. (СПбГУ ИТМО)Основы манифеста гибких технологий• Главное – удовлетворение требований

– удовлетворение требований заказчика путем скорой и непрерывной поставки

ценного и работоспособного ПО.
• Приветствуются изменяющиеся требования: их используют для повышения конкурентоспособности продукта.
• Работоспособное ПО поставляется как можно чаще, периодами от пары недель до пары месяцев.
• Бизнесмены и разработчики ежедневно работают сообща.
• Проекты строятся вокруг мотивированных личностей, которым оказывается доверие и создаются все условия для работы.
• Наиболее эффективным способом передачи информации (как внутри команды разработчиков, так и вовне) является личный разговор.
• Основной мерой прогресса является работоспособное ПО.
• Устанавливается удобный режим ведения разработки.
• Непрерывное внимание к техническому совершенству и хорошему дизайну повышает гибкость.
• Простота — искусство НЕ делать лишней работы.
• Лучшие архитектурные решения, наборы требований и дизайны создаются самоорганизующимися командами.
• Команда регулярно рассматривает и внедряет любые методы повышения своей эффективности.


Слайд 23 Павловская Т.А. (СПбГУ ИТМО)
Проектирование в гибких технологиях
Отказ от

Павловская Т.А. (СПбГУ ИТМО)Проектирование в гибких технологияхОтказ от длительного проектирования перед

длительного проектирования перед началом работы и выполнение проектирования на

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

Слайд 24 Павловская Т.А. (СПбГУ ИТМО)
Разработчики получают задачу, берут соответствующий

Павловская Т.А. (СПбГУ ИТМО)Разработчики получают задачу, берут соответствующий фрагмент разрабатываемого кода,

фрагмент разрабатываемого кода, выполняют рефакторинг, необходимый для упрощения написанного

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


Слайд 25 Павловская Т.А. (СПбГУ ИТМО)
Экстремальное программирование
Основная идея экстремального программирования

Павловская Т.А. (СПбГУ ИТМО)Экстремальное программированиеОсновная идея экстремального программирования (ХР) — устранить

(ХР) — устранить высокую стоимость изменений, вносимых в ПО

в процессе как разработки, так и эксплуатации.
Цикл разработки в ХР состоит из очень коротких итераций. Четырьмя базовыми действиями в цикле являются:
выслушивание заказчика
проектирование
кодирование
тестирование.
Заказчик постоянно присутствует в группе разработчиков.
При принятии решений всегда стремятся выбрать самое простое, тесты пишутся еще до написания кода.
Сборка системы выполняется ежедневно.
Идеолог ХР - Кент Бек

Слайд 26 Павловская Т.А. (СПбГУ ИТМО)
Основные принципы ХР
Планирование 
Частая смена версий 
Метафора 
Простой проект 
Тесты
Переработка системы 
Программирование в паре

Павловская Т.А. (СПбГУ ИТМО)Основные принципы ХРПланирование Частая смена версий Метафора Простой проект ТестыПереработка системы Программирование в паре Непрерывная  интеграция Коллективное владение Заказчик с постоянным участием 40-часовая неделя


Непрерывная  интеграция 

Коллективное владение 
Заказчик с постоянным участием 
40-часовая неделя
Открытое рабочее  пространство 
Стандарты кодирования
Не более чем правила
Область применимости ХР: небольшие

и средние проекты.

Слайд 27 Тестирование в ХР
Тестирование модулей (unit testing):
позволяет разработчикам убедиться,

Тестирование в ХРТестирование модулей (unit testing):позволяет разработчикам убедиться, что код работает

что код работает корректно, и без опасений выполнять рефакторинг

(refactoring).
помогает не авторам кода понять, зачем нужен тот или иной фрагмент кода и как он функционирует
Приемочное тестирование (acceptance testing):
позволяет убедиться в том, что система действительно обладает заявленными возможностями и функционирует корректно.
TDD (Test Driven Development):
пишется тест (не проходит)
пишется код, чтобы тест прошел
выполняется рефакторинг кода.

Павловская Т.А. (СПбГУ ИТМО)


Слайд 28 Павловская Т.А. (СПбГУ ИТМО)
Scrum
Основой Scrum является итеративная разработка.

Павловская Т.А. (СПбГУ ИТМО)ScrumОсновой Scrum является итеративная разработка. Scrum определяет итеративные

Scrum определяет итеративные правила управления проектом, которые призваны обеспечивать

достижение максимального эффекта от реализованной функциональности.
В Scrum определяются основные правила взаимодействия участников команды, которые призваны обеспечивать максимально быструю реакцию на существующую ситуацию.
Каждая итерация в Scrum может быть описана так: планируем – фиксируем – реализуем – анализируем.
За счет фиксирования требований на время одной итерации и изменения длины итерации методология Scrum позволяет управлять балансом между гибкостью и предсказуемостью разработки.

Слайд 29 Павловская Т.А. (СПбГУ ИТМО)
Общие положения
3 роли:
владелец продукта

Павловская Т.А. (СПбГУ ИТМО)Общие положения3 роли: владелец продукта (Product Owner) -

(Product Owner) - отвечает за определение требований к продукту
команда

(Team) - группа самостоятельных и инициативных разработчиков, ответственных за реализацию проекта
скрам-мастер (ScrumMaster) отвечает за решение всех организационных проблем и соблюдение методологии Scrum.
3 фазы проекта:
Подготовка (Pregame): общий план проекта, список основных требований к продукту, высокоуровневая архитектура продукта.
Реализация (Game): итеративное развитие продукта.
Завершение (Postgame): действия, необходимые для подготовки продукта к выходу на рынок.

Слайд 30 Павловская Т.А. (СПбГУ ИТМО)
Реализация проекта в Scrum
Фаза реализации

Павловская Т.А. (СПбГУ ИТМО)Реализация проекта в ScrumФаза реализации разбита на последовательность

разбита на последовательность итераций - спринтов (Sprint).
В результате

каждого спринта в продукте реализуется новый, заметный для владельца продукта, объем функциональности.
В конце каждого спринта продукт остается в работоспособном состоянии.
Спринт начинается с сессии планирования (Sprint Planning Meeting) - определяется объем функциональности, которая будет реализована в течение спринта.
Ежедневно проводится собрание участников проекта - скрам-сессия (Daily Scrum Meeting).
По завершению спринта проводится демонстрационная сессия (Sprint Review Meeting).

Слайд 31 Павловская Т.А. (СПбГУ ИТМО)
Документация в Scrum
Всего 3

Павловская Т.А. (СПбГУ ИТМО)Документация в Scrum Всего 3 документа: журнал продукта

документа:
журнал продукта (Product Backlog)
высокоуровневый список функциональных и технических

требований, необходимых для реализации продукта
журнал спринта (Sprint Backlog)
детализированный список функциональных и технических требований, необходимых для успешного завершения итерации
график спринта (Burndown Chart).
показывает ежедневное изменение общего объема работ, оставшегося до завершения итерации.


Слайд 32 Павловская Т.А. (СПбГУ ИТМО)
Унифицированный процесс (RUP)
Разработчики: Г. Буч,

Павловская Т.А. (СПбГУ ИТМО)Унифицированный процесс (RUP)Разработчики: Г. Буч, А. Якобсон, Д.

А. Якобсон, Д. Рамбо (Rational, 1998)
Обобщенный каркас процесса разработки

ПО
Компонентно-ориентирован
УП управляет действиями всех его участников:
разработчиков
руководства
пользователей
заказчиков
Процесс должен постоянно адаптироваться к реальному положению дел, которое определяется:
доступными технологиями
утилитами
персоналом
организационными шаблонами.

Слайд 33 Павловская Т.А. (СПбГУ ИТМО)
Характеристики УП
управляемый вариантами использования
архитектурно-ориентированный
итеративный и

Павловская Т.А. (СПбГУ ИТМО)Характеристики УПуправляемый вариантами использованияархитектурно-ориентированныйитеративный и инкрементныйиспользует UMLоснован на

инкрементный
использует UML
основан на компонентном подходе, использует стандарт визуального моделирования
Архитектура

- представление всего проекта с выделением важных характеристик. Архитектура описывается различными представлениями и охватывает наиболее важные статические и динамические аспекты системы.

Разработка делится на мини-проекты (итерации), в ходе которых реализуется группа вариантов использования. Итерации не обязательно аддитивны.


Слайд 34 Павловская Т.А. (СПбГУ ИТМО)
Преимущества управляемого УП
Ограничивает финансовые риски

Павловская Т.А. (СПбГУ ИТМО)Преимущества управляемого УПОграничивает финансовые риски затратами на одну

затратами на одну итерацию
Снижает риск непоставки продукта
Ускоряет темпы процесса

разработки в целом
Облегчает адаптацию к неизбежным изменениям требований

Слайд 35 Павловская Т.А. (СПбГУ ИТМО)
Жизненный цикл УП
Каждый цикл состоит

Павловская Т.А. (СПбГУ ИТМО)Жизненный цикл УПКаждый цикл состоит из 4х фаз,

из 4х фаз, каждая фаза разделяется на итерации
Результатом каждого

цикла является новый выпуск системы
Каждая фаза заканчивается вехой
Веха определяется по наличию определенного набора артефактов
Артефакт – любой вид информации, создаваемый, изменяемый и используемый сотрудниками при создании системы

Слайд 36 Павловская Т.А. (СПбГУ ИТМО)
Назначение вех
По ним руководитель принимает

Павловская Т.А. (СПбГУ ИТМО)Назначение вехПо ним руководитель принимает решения перед тем,

решения перед тем, как перейти на следующую фазу
Возможность отслеживать

процесс
Возможность прогнозирования оценок в других процессах

Слайд 37 Павловская Т.А. (СПбГУ ИТМО)
Цикл разработки

Павловская Т.А. (СПбГУ ИТМО)Цикл разработки

Слайд 38 Павловская Т.А. (СПбГУ ИТМО)
Содержание фаз
Анализ и планирование требований:
идея

Павловская Т.А. (СПбГУ ИТМО)Содержание фазАнализ и планирование требований:идея превращается в концепцию

превращается в концепцию готового продукта
создается бизнес-план разработки
упрощенная модель вариантов

использования
пробный вариант архитектуры
выявление рисков и расстановка приоритетов
грубая оценка проекта

Проектирование:
детальное описание вариантов использования
архитектура в виде представлений всех моделей
план действий и оценка ресурсов


Слайд 39 Павловская Т.А. (СПбГУ ИТМО)
Построение
уточнение базового уровня архитектуры
реализация всех

Павловская Т.А. (СПбГУ ИТМО)Построениеуточнение базового уровня архитектурыреализация всех вариантов использованияВнедрениебета-версиятренинги сотрудников заказчиковисправление дефектов

вариантов использования
Внедрение
бета-версия
тренинги сотрудников заказчиков
исправление дефектов


Слайд 40 Павловская Т.А. (СПбГУ ИТМО)
Модели УП
Модели – наиболее важный

Павловская Т.А. (СПбГУ ИТМО)Модели УПМодели – наиболее важный тип артефактов. Каждая

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

зрения на определенном уровне абстракции.
Вариантов использования
Анализа
Проектирования
Развертывания
Реализации
Тестирования

Все модели связаны, они полностью описывают систему.
Набор моделей дает варианты обозрения системы для всех сотрудников.

Слайд 41 Павловская Т.А. (СПбГУ ИТМО)
UML
Язык для специфицирования, визуализации, конструирования

Павловская Т.А. (СПбГУ ИТМО)UMLЯзык для специфицирования, визуализации, конструирования и документирования программных

и документирования программных продуктов.
Также используется в бизнес-моделировании и моделировании

любых иных (не программных) систем.
UML позволяет задавать следующие аспекты:
Диаграммы вариантов использования (use case diagrams)
Диаграммы классов (class diagrams)
Диаграммы поведения
Диаграммы состояний (statechart diagrams)
Диаграммы действий (activity diagrams)
Диаграммы взаимодействия (interaction diagrams)
Диаграммы последовательностей(sequence diagrams)
Диаграммы взаимодействий(collaboration diagrams)
Диаграммы реализации (implementation diagrams)
Диаграммы компонент (component diagram)
Диаграммы развертывания (deployment diagram)


Слайд 42 Павловская Т.А. (СПбГУ ИТМО)
Диаграммы вариантов использования (Use case

Павловская Т.А. (СПбГУ ИТМО)Диаграммы вариантов использования (Use case diagrams)

diagrams)


Слайд 43 Павловская Т.А. (СПбГУ ИТМО)
Диаграммы деятельности (Activity diagrams)

Павловская Т.А. (СПбГУ ИТМО)Диаграммы деятельности (Activity diagrams)

Слайд 44 Павловская Т.А. (СПбГУ ИТМО)
Диаграммы последовательностей действий (Sequence diagrams)

Павловская Т.А. (СПбГУ ИТМО)Диаграммы последовательностей действий (Sequence diagrams)

Слайд 45 Павловская Т.А. (СПбГУ ИТМО)
Диаграммы компонент (Component diagrams)

Павловская Т.А. (СПбГУ ИТМО)Диаграммы компонент (Component diagrams)

Слайд 46 Павловская Т.А. (СПбГУ ИТМО)
Пример реального процесса разработки ПО

Павловская Т.А. (СПбГУ ИТМО)Пример реального процесса разработки ПО

Слайд 47 Павловская Т.А. (СПбГУ ИТМО)
Обзор идеи

Выдвигается идея нового продукта

Павловская Т.А. (СПбГУ ИТМО)Обзор идеиВыдвигается идея нового продукта Назначается менеджер по


Назначается менеджер по продукту (PdM). Он оценивает идею и

составляет ее краткий обзор, который направляет на утверждение HBU и HPdM.
Назначается PjM
Milestone S3: HBU или HPdM принимают решение о дальнейшем анализе бизнес-идеи


Слайд 48 Павловская Т.А. (СПбГУ ИТМО)
Обзор проекта
PjM назначает системного архитектора

Павловская Т.А. (СПбГУ ИТМО)Обзор проектаPjM назначает системного архитектора (SWA) и старшего

(SWA) и старшего тестера (CQA).
PdM, PjM, представитель спонсора, SWA,

CQA формируют руководящую группу (Steering Group), принимающую решения по проекту.
SWA анализирует техническую возможность реализации.
PjM составляет обзор по своему проекту.
PjM составляет черновик плана проекта (Project Plan)
PdM подготавливает отчет об анализе бизнес-идеи продукта.
Milestone S2: HBU или HPdM дают добро на начало разработки проекта.

Слайд 49 Павловская Т.А. (СПбГУ ИТМО)
Подготовка проекта
PjM уточняет план проекта,

Павловская Т.А. (СПбГУ ИТМО)Подготовка проектаPjM уточняет план проекта, назначает команду разработчиков,

назначает команду разработчиков, организует взаимодействие с другими отделами (документация,

локализация, поддержка пользователей, технические тренинги и т.д.)
PdM и SWA составляют список требований к программному продукту (Stakeholder Requirements):
Функциональность (Functionality), Удобство использования (Usability), Надежность (Reliability), Быстродействие (Performance), Безопасность (security), Обеспеченность поддержкой (Supportability)
требования могут градуироваться по приоритетам: обязательно (must), желательно (should), возможно (may).
SWA с SWE возможно создают прототип продукта
StakeHolder Requirements – основной продукт по завершению фазы.
Milestone S1: Product Council разрешает начать разработку продукта.

Слайд 50 Павловская Т.А. (СПбГУ ИТМО)
Разработка продукта (Development) - 1
SWA

Павловская Т.А. (СПбГУ ИТМО)Разработка продукта (Development) - 1SWA разрабатывает на утверждение

разрабатывает на утверждение SG дизайн продукта (Design Description) и

спецификацию по Интерфейсу пользователя (UI description), проводит декомпозицию на модули, описывает все в удобном для разработки виде (напр. UML),
PjM планирует сроки и расстановку сил по разработке каждого модуля
CQA начинает подготовку Test Plan и Test Specification
Тестовая спецификация строится с учетом требований. Она описывает методы тестирования, Test Cases, их важность и критерии проверки.
Milestone DA: дизайн утверждается SG (Руководящей группой).


Слайд 51 Павловская Т.А. (СПбГУ ИТМО)
Разработка продукта (Development) - 2

Выполняется

Павловская Т.А. (СПбГУ ИТМО)Разработка продукта (Development) - 2Выполняется итеративно: анализ, дизайн,

итеративно: анализ, дизайн, программирование, тестирование.
Milestones Dn – D1: завершение

билда N, …, 1.
Milestone D1:
Фиксация - Code & feature freeze (alpha version)
Нет серьезных дефектов - No any urgent bugs
CQA подготовил тестовую спецификацию
Первая версия. TWriter подготовил черновик руководства пользователя
Продукт готов к системному тестированию.


Слайд 52 Павловская Т.А. (СПбГУ ИТМО)
Альфа-тестирование
Итеративное тестирование продукта тестерами под

Павловская Т.А. (СПбГУ ИТМО)Альфа-тестированиеИтеративное тестирование продукта тестерами под руководством CQA. Как

руководством CQA. Как только серьезных проблем больше не обнаруживается,

продукт переходит в статус beta version.
Milestone V3: product beta-version & draft of User Guide, нет серьезных проблем и отклонений от требований


Слайд 53 Павловская Т.А. (СПбГУ ИТМО)
Бета-тестирование
Продукт отсылается на ознакомление и

Павловская Т.А. (СПбГУ ИТМО)Бета-тестированиеПродукт отсылается на ознакомление и тестирование ограниченному набору

тестирование ограниченному набору пользователей (User Support team, beta testers,

sales engineers, external partners).
Milestone V2: готов Release Candidate, no any unresolved problems found.
Тестирование окончательной версии:
Release candidate version отсылается избранным заказчикам.
Milestone V1: Руководящая группа принимает решение о том, что продукт готов к выходу.


Слайд 54 Павловская Т.А. (СПбГУ ИТМО)
Подготовка к выпуску и выпуск
PdM

Павловская Т.А. (СПбГУ ИТМО)Подготовка к выпуску и выпускPdM и HPdM проверяют,

и HPdM проверяют, что продукт готов к выходу на

рынок (все собрано, документация подготовлена, отделы поддержки и тренинга готовы, реклама дана, произведена Интернет-подготовка, завод готов отштамповать диски, отдел доставки готов их доставить, определены цены, согласовано с продавцами, и т.п.).
Milestone R2: все подготовлено и согласовано, назначена точная дата выхода.
Выпуск (R2)
Продукт заливается на болванки, доставляется в магазины. Дается контрольная отмашка о выходе продукта в свет.


Слайд 55 Павловская Т.А. (СПбГУ ИТМО)
все!

Павловская Т.А. (СПбГУ ИТМО)все!

Слайд 56 Павловская Т.А. (СПбГУ ИТМО)
CASE-технологии
Computer Aided Software/System Engineering

Павловская Т.А. (СПбГУ ИТМО)CASE-технологии Computer Aided Software/System Engineering – автоматизированная разработка

– автоматизированная разработка ПО/систем
Существуют САSЕ-технологии, поддерживающие как структурный, так

и объектный (в т. ч. компонентный) подход
САSЕ-средства повышают производительность труда программистов и улучшают качество программного обеспечения. Они:
обеспечивают автоматизированный контроль совместимости спецификаций проекта;
уменьшают время создания прототипа системы;
ускоряют процесс проектирования и разработки;
автоматизируют формирование проектной документации для всех этапов жизненного цикла;
частично генерируют коды программ для различных платформ разработки;
поддерживают технологии повторного использования компонентов системы;
обеспечивают возможность восстановления проектной документации по имеющимся исходным кодам.

Слайд 57 Павловская Т.А. (СПбГУ ИТМО)
Компонентный подход и САSЕ-технологии
Компонентный

Павловская Т.А. (СПбГУ ИТМО)Компонентный подход и САSЕ-технологии Компонентный подход предполагает построение

подход предполагает построение программного обеспечения из отдельных компонентов —

физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы.
В отличие от обычных объектов, объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию.
Компонентный подход лежит в основе технологий, разработанных на базе СОМ и СОRВА.

Слайд 58 Павловская Т.А. (СПбГУ ИТМО)
Технология СОМ определяет общий принцип

Павловская Т.А. (СПбГУ ИТМО)Технология СОМ определяет общий принцип взаимодействия программ любых

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

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

Технологии СОМ


Слайд 59 Павловская Т.А. (СПбГУ ИТМО)
На базе технологии COM были

Павловская Т.А. (СПбГУ ИТМО)На базе технологии COM были разработаны компонентные технологии,

разработаны компонентные технологии, решающие различные задачи разработки программного обеспечения.


OLE-automation — технология создания приложений, обеспечивающая доступ к их внутренним службам. Например, ее поддерживает Microsoft Ехсеl, предоставляя другим приложениям свои службы.
ActiveX — технология, построенная на базе OLE-automation, предназначена для создания как распределенного в сети, так и сосредоточенного на одном компьютере программного обеспечения. Предполагает использование визуального программирования для создания компонентов — элементов управления ActiveX. Полученные таким образом элементы управления можно устанавливать на компьютер дистанционно с удаленного сервера, причем устанавливаемый код зависит от используемой операционной системы.

Технологии СОМ


Слайд 60 Павловская Т.А. (СПбГУ ИТМО)
MTS (Microsoft Transaction Server —

Павловская Т.А. (СПбГУ ИТМО)MTS (Microsoft Transaction Server — сервер управления транзакциями)

сервер управления транзакциями) — технология, обеспечивающая безопасность и стабильную

работу распределенных приложений при больших объемах передаваемых данных.
MIDAS (Multilier Distributed Application Server — сервер многозвенных распределенных приложений) — технология, организующая доступ к данным разных компьютеров с учетом балансировки нагрузки сети.
Все указанные технологии реализуют компонентный подход, заложенный в СОМ.

Технологии СОМ


  • Имя файла: tsikl-razrabotki-programmnogo-obespecheniya.pptx
  • Количество просмотров: 100
  • Количество скачиваний: 0