Дается короткий обзор методологии XP и MSF (в части планирования и проектирования решения)

1. Проектирование программных систем
методологии
1 МАИ, каф 806, ППС

2. Базовые понятия.
Экономические аспекты
• Стратегия увеличения прибыли от проекта
 Уменьшение расходов;
 Увеличение прибыли от проекта (маркетинг);
 Платить позже, получать прибыль раньше (мы платим меньше по процентам);
 Увеличение вероятности что проект останется жить (т.е. мы сможем получать прибыль
от проекта и впредь).
• Основные показатели разработки ПО и связи между ними
 Время
 Цена
 Качества
 Объем работ
2 МАИ, каф 806, ППС

3. Базовые понятия.
Экономический дизайн
 Архитектура - это баланс между:
 техническим решением;
 бизнес задачей;
 социальным аспектом (участники проекта);
 Изменения касающиеся одного направления зачастую касается другого (технические
изменения могут касаться бизнеса и т.д.)
 Все решения должны быть:
 Практичные (их можно использовать прямо сейчас);
 Легко реализуемы (сложное решение дорого реализуется);
 Базируются на принципах (понятно, какое решение какой цели добивается);
 Легко обоснуемте;
3 МАИ, каф 806, ППС

4. Базовые понятия.
Экономический дизайн
 Хорошие технически решения зачастую противоречат экономическим показателям (дорогие и
долгие)
 Базовый принцип:
80% функциональности делается 20% доработок
 Необходимо задать вопрос о степень используемости разрабатываемого дизайна (чем в
больших задача может использоваться - тем выгоднее). Степень используемости зависит от
бизнеса (Если функция не используется, то ей не обязательно быть хорошей)
 Необходимо определить атрибуты качества архитектуры. (производительность, надежность,
безопасность, отказоустойчивость).
4 МАИ, каф 806, ППС

5. Базовые понятия.
Риски при разработке ПО
 Отставание от графика проекта
небольшие циклы выпуска версий (1-4 недели). Задачи на 1-3 дня.
 Отмена проекта
заказчик определяет минимальный объем работ, для максимальной бизнес отдачи.
 Невозможность модификации системы после сдачи (высокая трудоемкость)
автоматизация тестирования позволяет поддерживать качество
 Большое число ошибок в ПО
на всех уровнях производится контроль качества (программеры на уровне кода), заказчики на уровне
функциональности
 Неправильное понимание требований бизнеса
заказчик является частью команды
 Изменение бизнеса
Небольшие циклы выпуска версий
 Не использование запрограммированой функциональности заказчиком
реализуются только задачи наивысшего приоритета
 Увольнение ключевых программистов
Программист сам планирует свою работу, стимулируется общение в команде (одиночество - главный фактор
разочарования в работе)
5 МАИ, каф 806, ППС

6. Методология как инструмент коллективной работы
6 МАИ, каф 806, ППС

7. Базовые понятия. Основные ценности XP
 Общение
большая часть проблем и ошибок всегда связана с недостатком
общения.
 Простота
Останавливайся на самом простом решении, которое позволяет
выполнить задачу
 Обратная связь
у вас всегда должна быть возможность определить, насколько
система, которую вы пишите, далека от необходимого набора
функциональности. Лучшие инструменты обратной связи – это
непосредственное общение с заказчиком и набор
автоматизированных тестов, который растет вместе с системой
 Смелость
все существующие методологии и процессы разработки
предназначены для того, чтобы обуздать и уменьшить наш страх
 Уважение
все четыре предыщущие ценности подразумевают уважение членов
команды друг к другу.
7 МАИ, каф 806, ППС

8. Базовые понятия. Основные принципы XP
 Взаимная выгода
 Сходство
 Все лучше и лучше
 Разнообразие
 Обдумывание
 Течение
 Новые возможности
 Избыточность
 Неудачи
 Качество
 Маленькими шажками
 Ответственность
8 МАИ, каф 806, ППС

9. XP
ПЛАНИРОВАНИЕ
9 МАИ, каф 806, ППС

10. Базовые понятия. Практики XP.
Анализ требований и планирование [1/2]
 «Рассказы»
функциональность приложения описывается короткими «рассказами», в которых
работа системы изложена с точки зрения заказчика. Эти «рассказы» также
являются основной движущей силой разработки приложения.
 Еженедельный цикл
вся разработка проекта происходит в виде череды еженедельных циклов. В
начале недели происходит собрание, на котором заказчик выбирает, какие
«рассказы» надо сделать за эту неделю.
 Ежеквартальный цикл
планирование в большем масштабе происходит каждый квартал. Оно состоит из
обсуждений работы команды и темпов разработки.
 Слабина
избегайте обещаний, которые не сможете выполнить. В любой план включайте
задачи, которые вы сможете выкинуть, если не будете укладываться в срок. В
этом случае у вас будет выход даже в случае непредвиденных проблем.
10 МАИ, каф 806, ППС

11. Базовые понятия. Практики XP.
Анализ требований и планирование [2/2]
 Непосредственное вовлечение заказчика
люди, для которых вы пишете программный продукт, должны стать частью
команды и вносить свою лепту в ежеквартальное и еженедельное планирование.
 Инкрементная поставка продукта
когда вам предстоит целиком сменить существующую систему, начинайте
процесс с изменения нескольких функций, и так постепенно замените всю
систему. Избегайте подхода, который можно выразить словами «Все или ничего!»
 Контракт с оговоренным объемом работ
контракт на разработку программного обеспечения включает в себя время,
затраты и качество системы, однако точные объемы этой системы надо
оговаривать в процессе работы. Заключив с заказчиком серию небольших
контрактов, можно значительно снизить риски.
 Плата за использование
обычно заказчик платит за каждый выпуск программного продукта. Это нередко
дает повод для конфликтов между разработчиками и заказчиком, который хочет
внести как можно больше новой функциональности в наименьшее количество
выпусков продукта. Если исчислять деньгами непосредственную работу над
функциональностью, заказчик будет получать более точную и своевременную
информацию, и сможет точнее направлять разработку продукта.
11 МАИ, каф 806, ППС

12. XP
ЧЕЛОВЕЧЕСКИЙ ФАКТОР
12 МАИ, каф 806, ППС

13. Базовые понятия. Практики XP.
Команда и человеческий фактор [1/2]
 Работа в одном помещении
команда разработчиков должна сидеть в одном большом помещении – это
облегчает общение.
 Команда как одно целое
команда должна состоять из людей, обладающих всеми необходимыми для
проекта навыками и знаниями. Всех их должно объединять чувство
принадлежности общему делу, они должны всячески поддерживать друг друга.
 Информативность окружения
в рабочем помещении должны быть информативные постеры и прочие наглядные
пособия, которые показывали бы статус проекта и другую информацию о
проделанной работе.
 Энергичная работа
люди не должны быть истощены работой, им надо сохранять свежесть и
энергичность, чтобы фокусироваться на задачах и уметь эффективно их решать.
Следовательно, надо жестко ограничить сверхурочную работу, так чтобы у
каждого оставалось время и на личную жизнь. В прежней версии методологии это
называлось «приемлемый темп разработки».
13 МАИ, каф 806, ППС

14. Базовые понятия. Практики XP.
Команда и человеческий фактор [2/2]
 Парное программирование
код всегда пишут два программиста, сидящих за одним компьютером.
 Постоянство
команда разработчиков должна работать в одном и том же составе на
протяжении нескольких проектов. Те связи, которые возникают между людьми,
воистину бесценны, поэтому старайтесь перераспределять людей как можно
реже.
 «Усушка и утряска»
если команда становится все более продуктивной, не увеличивайте ее нагрузку.
Оставьте объем работ прежним, но выделите свободных членов этой команды с
тем, чтобы они создавали свои собственные новые команды.
14 МАИ, каф 806, ППС

15. XP
ПРОЕКТИРОВАНИЕ
15 МАИ, каф 806, ППС

16. Базовые понятия. Практики XP.
Проектирование [1/2]
 Инкрементное проектирование
согласно ХР, не следует заниматься подробным проектированием системы в
самом начале работ. Вместо этого команда разработчиков старается как можно
скорее начать писать программный код, чтобы получить отзывы пользователей о
системе, и улучшать ее по ходу дела. Конечно, чтобы написать хороший код,
система должна быть должным образом спроектирована. Этого ХР не отрицает.
Вопрос лишь – когда заниматься проектированием. Согласно экстремальному
программированию, проектированием должно происходить инкрементально во
время написания программного кода. Особенно полезно делать это, чтобы
убирать ненужное дублирование.
 Анализ причин и следствий
каждый раз, когда вы находите ошибку в системе, исправляйте не только ее, но и
ее причину. В противном случае эта ошибка может повториться в будущем.
16 МАИ, каф 806, ППС

17. Базовые понятия. Практики XP.
Проектирование [2/2]
 Сначала тесты
перед тем, как редактировать старый код или писать новый, нужно написать
тесты, которые будут его проверять. Это поможет решить четыре проблемы:
 «Программирование по-ковбойски»: во время написания кода так легко
увлечься и начать писать код для всех задач подряд, которые приходят на
ум. Если же сначала написать тесты, которые затем будут проверять код,
нам волей-неволей придется сосредоточиться на задаче, которую мы
пытаемся решить, а также проверить, насколько правильно мы
спроектировали данную часть системы.
 Слаженность и единство: если написать тест трудно, значит, у вас проблемы
с дизайном системы, а не с тестированием или программированием. Когда
программный код разбит на функционально связанные модули с
минимальным количеством двусторонних зависимостей между ними,
тестировать его не составит большого труда.
 Доверие: если вы пишете код, который работает, и документируете его с
помощью автоматизированных тестов, ваши коллеги будут доверять вам.
 Ритм: во время программирования можно легко увлечься и блуждать в коде в
течение нескольких часов. Если вы приучите себя к ритму «тест, код,
рефакторинг, тест, код, рефакторинг», этого никогда не случится.
17 МАИ, каф 806, ППС

18. XP
ПРОГРАММИРОВАНИЕ
18 МАИ, каф 806, ППС

19. Базовые понятия. Практики XP.
Программирование и выпуск продукта
 Десятиминутная сборка
систему должно быть можно собрать (с учетом прогона всех тестов) за десять минут. Это
позволит часто повторять операцию и получать отзывы о разрабатываемом продукте.
 Постоянная интеграция
разработчики должны выкладывать в репозиторий результаты своей работы каждые два
часа, чтобы избежать проблем с интеграцией нового кода.
 Код и тесты
только программный код и тесты являются постоянными артефактами системы, которые надо
сохранять. Все остальное может быть получено из программного кода и тестов.
 Общий код
любой член команды может в любой момент изменить любую часть системы. Эта практика
называлась в прежней версии ХР «коллективное владение кодом».
 Единая база программного кода
существует только одна официальная версия разрабатываемой системы. Если вам
понадобилось создать для чего-то ее ветку, оставляйте ее лишь на несколько часов.
 Ежедневная поставка системы
каждую ночь надо собирать новую версию системы и вводить ее в действие. Чем больше
разрыв между официальной версией системы и той, что находится у вас в
компьютере, тем это рискованнее и дороже для проекта.
19 МАИ, каф 806, ППС

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

21. Модель процессов MSF
 Симбиоз водопадной и спиральной модели
 Модель процессов MSF состоит из пяти четко
определенных этапов:
 создания общей картины приложения;
 планирования;
 разработки;
 стабилизации;
 развертывания.
 Каждый этап завершается контрольной точкой.
 Мы рассмотрим только основные моменты
первых двух этапов.
21 МАИ, каф 806, ППС

22. Роли в модели команд MSF
 Менеджер решения (product management)
отвечает за управление связями с клиентом. На этапе проектирования на эту роль
возлагается сбор клиентских требований и контроль за тем, чтобы они соответствовали и
удовлетворяли все потребности бизнеса. Менеджер решения также работает над планом
связей с клиентом в процессе создания и реализации проекта.
 Менеджер программы (program management)
несет ответственность за разработку и поставку решения заказчику в полном соответствии с
ограничениями проекта.
 Разработчик (development)
обеспечивает разработку технологического решения в соответствии со спецификациями,
предоставленными менеджерами решения.
 Тестировщик (testing)
отвечает за выявление и устранение всех неполадок и проблем с качеством продукта и дает
окончательное ≪добро≫ на выпуск и поставку решения.
 Менеджер по выпуску (release management)
отвечает за развертывание и работу продукта. Он проверяет корректность инфраструктуры и
определяет возможность развертывания и поддержки продукта.
 Специалист по удобству использования (user experience)
анализирует потребности и проблемы, возникающие у пользователей, и оценивает продукт на
предмет соответствия таким потребностям.
22 МАИ, каф 806, ППС

23. MSF . Управление компромиссами
 Иногда в проектах возможны нарушение графиков или перерасход бюджета.Главная причина
подобных проблем — нечетко описанная область действия проекта. Область действия
(scope) определяет, какие задачи решает продукт, а какие не относятся к его компетенции.
 Матрица компромиссов проекта — инструмент, который команда и заказчик используют при
принятии решений о компромиссах. Подобные решения следует принимать на ранних
стадиях проекта.
 Учитывая, что зафиксировано _______ , мы определим ________ и в случае необходимости
скорректируем.
 Например, «Учитывая, что зафиксированы ресурсы, мы определим график и в случае
необходимости скорректируем функциональность»
23 МАИ, каф 806, ППС

24. MSF . Порядок применения итераций в проектах
 Создание плана выпуска множественных версий. При планировании реализации всех
функций в нескольких версиях команде проще принимать решения о том, какие функции
реализовать в текущей версии и что можно отложить до следующей. Это позволяет более
эффективно использовать имеющиеся ресурсы и время. Кроме того, удается предотвратить
нежелательное расширение области действия проекта, создав четкий график развития
функциональности продукта.
 Ускорение итераций. Важное преимущество метода версий в том, что клиент быстро
получает работоспособный продукт, набор функций которого со временем расширяется.
Четко определяйте область действия проекта, чтобы итерации укладывались в разумные
временные рамки.
 Поставка в первой версии только базовых функций. Предоставление базового, но
надежного и пригодного к использованию решения намного эффективнее, чем разработка
продукта, который клиент сможет использовать только через недели или месяцы.
Предоставив клиенту основные функции на первых этапах реализации решения,
разработчики активно подключают клиента к участию в корректировке и совершенствовании
продукта на последующих итерациях.
 Создание в первую очередь рискованных функций. В процессе оценки риска команда
определяет самые рискованные функции. Именно их следует реализовать в первую очередь
при создании варианта продукта, разрабатываемого для проверки верности концепции. В
случае проблем, требующих коренных изменений архитектуры, вы сможете внести изменения
на ранних стадиях проекта, что сэкономит значительные бюджетные средства.
24 МАИ, каф 806, ППС

25. MSF .Управление рисками
 Определение рисков
позволяет выявлять их, благодаря чему команда получает информацию о возможных
проблемах.
 Анализ рисков
преобразование оценок и информации о конкретных проектных рисках, обнаруженных на
предыдущей стадии, в форму, пригодную для принятия решения об их важности.
 Планирование рисков
использование результатов предыдущей стадии для формулировки стратегий, планов и
мероприятий.
 Мониторинг рисков
наблюдение за конкретными рисками и документирование планов мероприятий по
управлению ими или устранению.
 Управление рисками
процесс исполнения планов мероприятий по управлению и устранению рисков и отчетность о
состоянии дел в этой сфере.
 Извлечение уроков
формализация приобретенного опыта и соответствующих проектных документов и
инструментальных средств и сохранение приобретенных знаний в форме, доступной для их
повторного использования в командах и во всей компании.
25 МАИ, каф 806, ППС

26. MSF . Создание общей картины решения
подробнее будет рассмотрено в отдельной теме
 На этой стадии команда, заказчик и спонсоры проекта определяют высокоуровневые бизнес-
требования и общие цели проекта. Главная задача — согласовать то, как видят проект
разные его участники, и выработать у членов команды единое мнение о полезности проекта
для компании и его реализуемости.
 Результаты
 документ общей картины и области действия решения — описывает цели и
ограничения проекта. В нем перечислены параметры разрабатываемого продукта,
требования, которым он должен удовлетворять, его функции и предварительный
календарный график работ; Основные характеристики: конкретность, измеримость,
реалистичность, насущность, точный расчет времени.
 документ структуры проекта — описывает организационную структуру проекта и
процесс руководства проектом и определяет роли и обязанности каждого члена
команды;
 документ оценки риска — содержит начальное определение и анализ рисков,
связанных с проектом, а также планы мероприятий по обеспечению непрерывности
бизнеса
26 МАИ, каф 806, ППС

27. MSF . Сбор и анализ бизнес-требований
подробнее будет рассмотрено в отдельной теме
 Сбор и анализ бизнес-требований:
 анализ текущего состояния предприятия и анализ бизнес-требований решения;
 Сбор и анализ пользовательских требований
 определение вариантов использования системы;
 определение требований по поддержке других языков и локализации;
 определение требований по поддержке специальных возможностей
 Сбор и анализ системных требований:
 определение требований по сопровождению и поддержке;
 определение требований по масштабированию, доступности, надежности
развертыванию, безопасности;
 Сбор и анализ требований к оборудованию, ПО и сетевой инфраструктуре:
 определение требований по интеграции;
 анализ ИТ-среды, в том числе существующих и будущих приложений, а также текущего и
планируемого оборудования,
 системного ПО и сетевой инфраструктуры;
 анализ влияния решения на ИТ-среду
27 МАИ, каф 806, ППС

28. MSF . Планирование
 Кульминация этапа планирования— контрольная точка ≪утверждение плана проекта≫
 Функциональные спецификации (базовые) описывают, что именно будет представлять
из себя продукт. Это итог усилий всей команды.
 Генеральный план проекта (базовый) — это набор планов для каждой из шести ролей
команды, они ориентированы на обеспечение максимального соответствия функций решения
и функциональных спецификаций. Здесь описываются методы, которые команды
предполагают применять для выполнения своих задач.
 Генеральный календарный график проекта (базовый) определяет временные рамки
генерального плана проекта и синхронизирует календарные графики, разработанные
разными командами. В нем указывается предполагаемое время выполнения работы
отдельными командами. Объединяя отдельные календарные графики, проектная команда
создает единый календарный график проекта. Это первый шаг на пути к определению
конечной даты выпуска продукта.
 Обновленный генеральный документ по оценке риска уже создан на этапе построения
общей картины решения и регулярно пересматривается и обновляется, особенно при
прохождении контрольных точек. Здесь описываются различные виды риска, связанного с
разработкой решения. Обычно все риски сортируются для выявления самых опасных из них и
их оценки суммируются для получения обшей оценки риска.
28 МАИ, каф 806, ППС

29. MSF . Разработка спецификаций
 Создание технических спецификаций на основе функциональных требований. Учет таких
параметров проекта, как производительность, возможность поддержки и сопровождения,
расширяемость, масштабируемость, доступность, удобство развертывания и безопасность:
 выбор стратегии разработки;
 выбор стратегии развертывания;
 выбор стратегии обеспечения безопасности;
 выбор стратегии поддержки и сопровождения;
 создание плана тестирования;
 создание плана обучения пользователей
Тип дизайна Представление Цель
Концептуальный Представление проблемы с точки Описание проблемы и решения
зрения пользователя и бизнеса в терминах сценариев
использования системы
Логический Представление решения с точки Описание решения как логического
зрения команды проекта набора взаимодействующих сервисов
Физический Представление решения с точки Описание сервисов и технологий
зрения разработчиков решения
29 МАИ, каф 806, ППС

30. MSF
Концептуальный дизайн
 На стадии анализа выполняются следующие задачи:
 уточнение диаграмм ВИС;
 выбор подходящей прикладной архитектуры решения;
 создание концептуальной модели решения.
 Требования бизнеса делятся не следующие категории: пользовательские, системные,
процедурные,бизнес-требования.
 Чтобы создать концептуальный дизайн решения, определяют сервисы и архитектуру
решения.
 Существует несколько видов сервисов, предоставляемых решением: пользовательские
сервисы, сервисы данных и системные сервисы.
Сервис Пример
Пользовательский Сервис отображения заказа
Системный Сервис размещения заказа
Данных Сервис информации о заказе
30 МАИ, каф 806, ППС

31. MSF
Логический дизайн
 Логический дизайн — это процесс описания продукта в терминах организации, структуры,
синтаксиса и взаимодействия его частей с точки зрения проектной команды.
 Этап логического дизайна состоит из двух перекрывающихся стадий:
 стадии анализа, во время которой определяются бизнес-объекты, сервисы, атрибуты и
отношения между объектами;
 стадии оптимизации, во время которой команда уточняет список бизнес-объектов и на
основании их определяет новые объекты и сценарии.
 Результаты логического дизайна таковы:
 логическая модель компонент— набор компонент и соответствующих им операций,
атрибутов и отношений;
 высокоуровневый дизайн пользовательского интерфейса;
 логическая модель данных.
31 МАИ, каф 806, ППС

32. MSF
Физический дизайн
 Физический дизайн — это процесс описания компонентов, сервисов и технологий решения
сточки зрения разработчиков (программистов).
 Цели физического дизайна:
 превратить логический дизайн в спецификации набора компонентов;
 определить технологии, оптимальные для программирования;
 создать структурное представление решения с точки зрения группы разработчиков.
 Физический дизайн дает новые результаты, в том числе:
 диаграммы классов;
 диаграммы последовательностей;
 базовую модель развертывания;
 модель программирования (тактики);
 спецификации компонентов.
 К базовым результатам стадии исследования относятся:
 существующая топология сети;
 существующая топология данных;
 существующая топология компонентов;
32 МАИ, каф 806, ППС