Гузеев Конспект лекций

Основы гибкой разработки.

Гибкие методы разработки поддерживают итеративную и эволюционную разработку с адаптивным планированием и инкрементальным получением конечного ПО.

Базовые приемы:

1.Короткие и фиксированные по времени итерации

2.Эволюционное уточнение планов, требований и проектных решений.

Вкачестве гибкого процесса может рассматриваться любой итеративный метод, например унифицированный процесс. Другими примерами гибких методов являются методы управления проектами, например Scrum, XPrograming, Test Drive Development

Манифесты и основные принципы гибкого процесса:

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

1.Люди и взаимодействие, а не процессы и средства.

2.Работоспособное программное обеспечение, а не исчерпывающая документация.

3.Сотрудничество с потребителями, а не обсуждение контракта

4.Реакция на изменение, а не следование плану.

Основные принципы гибкого процесса:

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

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

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

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

5.Обеспечение простоты (чем проще используемое решение, тем меньше работы нужно сделать для его реализации и поддержки.

6.Наилучшую архитектуру и проектное решение а так же требования могут разработать только самоорганизующиеся группы разработчиков

Понятие гибкого моделирования.

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

Гибкий унифицированный процесс.

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

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

– следует избегать их создание, если нельзя получить лучшее качество.

2.В силу итеративного характера унифицированного процесса анализ требований и проектирования не завершается к моменту начала реализации. Требование и модель

проектирования адаптивно настраиваются в течении нескольких итераций на основе обратной связи.

3.Применение языка UML вместе с приемами гибкого моделирования.

4.Детальное планирование выполняется итеративно от итерации к итерации.

Котличительным особенностям унифицированного процесса можно также отнести следующие принципы:

1.Оценка рисков и ключевых моментов проекта на ранних итерациях.

2.Постоянный отклик пользователей. Обратная связь и модификация требований.

3.Построение общей базовой архитектуры на ранних итерациях.

4.Постоянный контроль качества, раннее и качественное тестирование в реальных условиях.

5.Применение прецедентов.

6.Визуализация программной модели с помощью uml.

Фазы унифицированного процесса.

Врамках унифицированного процесса работа над проектом включает 4 фазы:

1.Начало (inception) Определение начального видения проекта, прецедентов, определение сложности задачи.

2.Развитие (elaboration). Формирование более полного видения проекта, итеративная реализация базовой архитектуры. Создание наиболее критичных компонентов. Идентификация основных требований. Получение более реалистичных оценок.

3.Конструирование (construction). Итеративная реализация оставшихся менее критичных и простых компонентов, подготовка к развертыванию.

4.Передача. Бетта тестирование и развертывание. Веха (milestone) – конец итерации, где получены важные решения и оценки. Release – стабильно работающая часть ПО. Инкремент

– разница между релизом и двух последующих итераций. Finale production release – система готова для коммерческого использования.

Цикл разработки

Дисциплины унифицированного процесса.

Дисциплина – набор видов деятельности и связанных с ними артефактов в рамках одного этапа работы над проектом.

Артефакт – любой результат работы, например код, текстовые документы, диаграммы, модели…

Дисциплины:

1.Бизнес моделирование. – эта дисциплина подразумевает разработку модели предметной области (domain model), которая является визуальным представлением наиболее важных сущностей из предметной области и их взаимосвязей для разрабатываемых приложений.

2.Требование - в рамках этой дисциплины создается модель прецедентов и дополнительная спецификация, которая отражает функциональные и нефункциональные требования.

3.Проектирование – в этой модели создается модель проектирования, которая отображает программные объекты.

4.Реализация – в рамках этой дисциплины выполняется программирование и построение дисциплины, но не ее развертывание.

5.Тестирование, развёртывание, конфигурация и управление изменениями, …, окружение. Окружение предполагает установку необходимых средств и настройку процессов для данного проекта.

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

UP Disciplines

Business Modeling

Requirements

Design

Implementation

Test

Deployment

Configuration & Change

Management

Project Management

Environment

Iterations

Определение требований и начальная фаза унифицированного процесса.

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

Артефакты начальной фазы:

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

Следующие артефакты могут создаваться на начальной фазе или в начале фазы развития:

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

2.Модель прецедентов. Описываются функциональные требования, на начальной стадии (фазе) определяются имена всех прецедентов, и 10% из них описываются подробно.

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

4.Словарь терминов. Содержит ключевую терминологию по данной предметной области и словарь.

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

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

7.План итерации. Описывает что предстоит делать на первой итерации фазы развития.

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

9.Набор инструментов. Описание этапов унифицированного процесса и артефактов данного проекта.

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

Определение требований:

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

Типы и категории требований.

Существуют несколько принципов систематизации требований. Самый часто используемые это стандарт ISO 9126, и во многом аналогичный ему модель FURPS+. Хотя можно использовать любой принцип в рамка унифицированного процесса принято пользоваться моделью FURPS+.

Согласно модели FURPS+ требования делятся на следующие категории:

1.Функциональные требования. Functionality Свойства, возможности и вопросы безопасности.

2.Удобства. Usability. Человеческий фактор, справочная система и документация.

3.Надежность Reliability. Частота сбоев, возможность восстановления и предсказуемость поведения.

4.Производительность. Performance. Время отклика, точность, доступность, использования ресурсов.

5.Возможность поддержки. Supportability. Адаптивность, соответствие международным стандартам,

6.Символ “+” означает дополнительные (не определяющие) факторы:

A. реализация – требования к ресурсам, языки и средства, аппаратное обеспечение.

B.Интерфейс – ограничение, накладываемое необходимостью взаимодействия с внешними системами.

C.Операция – управление системой и ее параметрами

D.Юридически вопросы, например, авторское право.

Категории данной модели используются при формулировании требований, чтобы не упустить важные аспекты жизнедеятельности системы. Некоторые из этих требований (удобство, надежность, производительность, возможность поддержки называются атрибутами качества.) Не смотря на то, что атрибуты качества не являются функциональными требованиями они оказывают значительное влияние на архитектуру системы. Кроме того, существует более грубое деление (классификация) требований на функциональные и не функциональные. Функциональные требования относятся к поведению системы, нефункциональные это все остальные.

Вунифицированном процессе предусмотрены несколько артефактов, связанных с требованиями:

1.Модель прецедентов.

2.Дополнительная спецификация.

3.Словарь терминов.

4.Видение.

5.Бизнес правила.

Описание прецедентов в итеративном процессе моделирования.

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

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

Сценарий – специальная последовательность действий или взаимодействий, между исполнителями и системой. Это один конкретный сценарий использования системы либо один проход прецедента (успешный или нет).

Тогда, прецедент (use case) — это набор взаимосвязанных успешных и неудачных сценариев, описывающий использование системы исполнителем для решения одной из задач. Например, рассмотрим свободный формат прецедента, включающего некоторые альтернативные сценарии.

Модель прецедентов.

Как артефакт унифицированного процесса модель прецедентов состоит из диаграмм прецедентов, текстов описаний прецедентов, системных диаграмм последовательностей и описание операций.

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

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

Типы исполнителей.

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

1.Основной исполнитель (primary) – его задача выполняется с использованием системы. Этот тип используется для определения целей пользователя, на основе которых формулируются прецеденты.

2.Вспомогательный исполнитель (supporting) – обслуживает систему, например предоставляет информацию. Используется для определения внешних интерфейсов и протоколов.

3.Закулисный исполнитель (offstage) – заинтересован в реализации прецедента, но не является основным или вспомогательным исполнителем.

Форматы представления прецедентов:

1.Сжатый – аннотация в виде одного абзаца. Обычно описываю только главный успешный сценарий. Используется на стадии анализа требований для быстрого определения задач и масштабов системы.

2.Свободный. Неформальный стиль описания, занимает несколько абзацев и охватывает различные сценарии. Используется, как и первый вариант.

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

задач системы. Когда множество прецедентов уже написаны в сжатом формате. В развернутом формате представляют около 10% самых важных для приложения прецедентов.

Критерии выделения полезных прецедентов.

1.Критерии одобрения руководством.

2.Критерий EBP – элементарного бизнес процесса.

3.Критерий размера –

Определение не функциональных требований к проектируемой системы

Для определения всех требований одного описания прецедентов не достаточно.

Кчислу артефактов требований (модель прецедентов) относятся:

1.Дополнительная спецификация. Описывает требования к отчетам, документированию, поддержки, лицензированию и т.д.

2.Словарь терминов. Содержит термины и определения.

3.Документ видение. (vision) Описывает важнейшие идеи, положенные в основу разрабатываемой ИС.

4.Бизнес-правила. Устойчивые правила или политики, применяемые в предметной области.

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

Дополнительная спецификация.

Не функциональные требования, связанные с прецедентами должны быть представлены в разделе специальные требования в описании прецедентов. (обязательно). Однако допускается дублирование дополнительной спецификации (ДС).

Вдополнительную спецификацию можно включать следующие элементы:

1.Требования согласно модели FURPS+

FURPS — классификация требований к программным системам.

Образована от первых букв слов:

Functionality — Функциональные требования. Являются основными, по этим требованиям строятся диаграммы вариантов использования (Use case diagram).

Usability — Требования к удобству использования.

Reliability — Требования к надежности.

Performance — Требования к производительности.

Supportability — Требования к поддержке.

2.Отчеты.

3.Ограничения на аппаратные и программные средства.

4.Ограничения, накладываемые на процесс разработки и проектирования. Выбор или использования тех или иных средств разработки проектирования.

5.Международные ограничения.

6.Документация. (Требования или состав). (Пользовательская документация, руководство по установке, проектированию, составление справки…)

7.Соглашение о лицензировании и другие юридические соглашения.

8.Стандарты. Технически, обеспечения качества и безопасности.

9.Физические требования к окружению. Температурный режим эксплуатации, ограничения на вибрацию.

10.Операционные требования. Способ обработки ошибок, частота архивации, бекапирования. Технический режим обслуживания.

11.Информация из предметной области. Информацию, которую обязательно необходимо уточнить, но которой нет в описании прецедентов.

Документ-видение.

Шаблоном этого артефакта может является следующий пример:

1.Введение. Общая краткая характеристика информационной системы.

2.Позиционирование.

2.1.Экономические предпосылки. Насколько целесообразно начинать проект. Есть ли соответствующая ниша на рынке.

2.2.Формулировка проблемы. Список проблем, которые хочется (или надо) решить в рамках новой информационной системы.

2.3.Место системы. Для кого предназначена ИС. Ее свойства и отличия от продуктов конкурентов.

3.Заинтересованные лица.

3.1.Заинтересованные лица не являющиеся пользователями системы

3.2.Пользователи системы.

3.3.Основные задачи высокого уровня и проблемы заинтересованных лиц.

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

3.4.Задачи уровня пользователя. Список исполнителей и их задач, разработанный в процессе моделирования прецедентов.

4.Обзор системы. Сопровождается диаграммами, построенными на основе диаграмм прецедентов. То есть все они должны отображать взаимодействие внешних исполнителей с системой.

4.1.Преимущество системы. Указываются задачи, их решения и преимущества, но на более высоком уровне, чем при описании прецедентов.

5.Основные свойства системы. Описываются сжато путем перечисления основных функций. Основным назначением документа-видение заключается в обобщении модели прецедентов и дополнительной спецификацией. Используется для ввода в проект новых участников и обратной связи с заказчиком.

Системные свойства.

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

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

Границы – определяются все основные части системы.

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

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

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

Модель предметной области. (МПО)

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

Основные понятия МПО отображаются в словаре терминов.

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

1.Объекты предметной области или концептуальные классы.

2.Ассоциации между концептуальными классами

3.Атрибуты концептуальных классов.

Вмодели предметной области не используются:

1.артефакты программирования (окна, БД) (если не программное средство)

2.Обязанности, методы

Концептуальный класс

Концептуальный класс – представление идей или объекта. Его можно рассматривать в терминах символов, содержания и расширения.

1.Символы – слова или образы, представляющие концептуальный класс.

2.Содержание – определение концептуального класса.

3.Расширение – набор примеров, к которым применим этот концептуальный класс.

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

Если некоторый объект Х в реальном мире не является числом или текстом, значит это скорее концептуальный класс, чем атрибут.