Измерения в конструировании

 

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

Измерения при разработке ПО необходимы для того, чтобы:

- определить или показать качество продукции;

- оценить производительность труда персонала;

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

- сформировать основу (базовую линию) для последующих оценок;

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

Измерения бывают

a) прямые и

b) косвенные.

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

Измерения тесно связаны с понятием метрики.

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

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

1) Трудоемкость и емкостная сложность (асимптотическая оценка),

2) Количество строк кода (LOC - lines-of-code),

3) Цикломатическая сложность,

4) Анализ функциональных точек,

5) Количество ошибок на 1000 строк кода,

6) Степень покрытия кода тестированием,

7) Покрытие требований,

8) Количество классов и интерфейсов,

9) Связность.

Методы оценки трудоемкости и емкостной сложности были рассмотрены в рамках предмета «Алгоритмы и структуры данных». LOC –оценки изучались в «Управлении проектами». Цикломатическая сложность программы это - мера, основанная на методах статического анализа кода. Она кратко рассмотрена на одной из предыдущих лекций.

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

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

Связность и сцепление — характеристики внутренней взаимосвязи между модулями. Они были рассмотрены раньше.

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

По назначению и областям применения метрики принято делить на 3 группы:

1) метрики производительности,

2) метрики качества продукции и

3) технические характеристики продукта.

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

Вторая классификация метрик - по их ориентации, - также выделяет три класса:

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

2) функционально-ориентированные метрики, которые являются косвенными мерами, характеризующими функциональное назначение продукта и особенности его входных и выходных данных;

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

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

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

- общие затраты (в человеко-месяцах - чел.-мес);

- объем программного изделия (в тысячах строк исходного кода -KLOC);

- стоимость разработки (в тыс. рублей или в долларах $);

- объем документации (в страницах документов - СД);

- ошибки, обнаруженные в течение первого года эксплуатации (число ошибок - ЧО);

- число людей, работавших над изделием (человек);

- срок разработки (в календарных месяцах).

На основе перечисленных показателей вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта):

Достоинства размерно-ориентированных метрик:

1) широкое распространение;

2) простота и легкость вычисления.

Недостатки размерно-ориентированных метрик:

1) зависимость от языка программирования;

2) исходные данные для них трудно получить на начальной стадии проекта;

3) не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. При этом рассматривается не размер, а функциональность или полезность продукта. Используется 5 информационных характеристик.

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

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

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

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

5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

Достоинства функционально-ориентированных метрик:

1. Не зависят от языка программирования.

2. Легко вычисляются на любой стадии проекта.

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

FP-оценки легко пересчитать в LOC-оценки. Результаты пересчета зависят от языка программирования, используемого для реализации ПО.

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

1) локализацию,

2) инкапсуляцию,

3) информационную закрытость,

4) наследование и

5) способы абстрагирования объектов.

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

Инкапсуляция — упаковка (связывание) совокупности элементов. В объектно-ориентированных системах инкапсулируются обязанности класса, представляемые его свойствами, операциями и состояниями. Метрики, учитывающие инкапсуляции, позволяют оценить группу свойств обрабатывающих модулей. Кроме того, измерения переходят на более высокий уровень абстракции (например — метрика «количество операций на класс»).

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

Наследование — механизм, обеспечивающий тиражирование обязанностей одного класса в другие классы. Оно распространяется через все уровни иерархии классов. При этом наследование характеризуется разными объектно-ориентированными метриками (количество детей — потомков класса, количество родителей, высота класса в иерархии наследования).

Абстракция — это механизм, который позволяет проектировщику выделять главное в программном компоненте (как свойства, так и операции) без учета второстепенных деталей. Класс — это абстракция, которая может быть представлена на различных уровнях детализации и различными способами (например, как список операций, последовательность состояний, последовательности взаимодействий). Поэтому объектно-ориентированные метрики должны представлять абстракции в терминах измерений класса. Примеры: количество экземпляров класса в приложении, количество родовых классов на приложение, отношение количества родовых к количеству неродовых классов.

Наиболее распространенными метриками для объектно-ориентированных программных систем являются:

1) Взвешенные методы на класс (в простейшем случае – количество методов в классе);

2) Размер класса (общее количество операций и свойств класса);

3) Высота дерева наследования;

4) Количество детей (подклассов);

5) Сцепление между объектами классов и др.

3. Практические соображения
3.1 Проектирование в конструировании

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

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

a) базовые концепции проектирования,

b) ключевые вопросы проектирования ПО,

c)структура и архитектура ПО,

d) анализ и оценка качества проектирования ПО,

e)нотации проектирования ПО,

f) стратегия и методы проектирования ПО.

Базовая концепция проектирования ПО - это методология проектирования архитектуры с помощью

a) методов (объектного, компонентного и др.),

b) процессов жизненного цикла (стандарт ISO/IEC 12207) и

c) техник - декомпозиции, абстракции, инкапсуляции и др.

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

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

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

Архитектура проекта - высокоуровневое представление структуры системы и спецификация ее компонентов. Она определяет:

a) логику отдельных компонентов системы настолько детально, насколько это необходимо для написания кода,

b) связи между компонентами.

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

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

a) структурным, включающим типовые композиции структур из объектов и классов, связей и др.;

b) поведенческим, определяющим схемы взаимодействия классов объектов и их поведение диаграммами активностей, взаимодействия, потоков управления и др.;

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

Анализ и оценка качества проектирования программного обеспечения включает в себя мероприятия по:

a) анализу сформулированных в требованиях атрибутов качества,

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

c) проведения качественного анализа результатов проектирования путем статического анализа, моделирования и прототипирования.

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

a) структурные,

b) поведенческие.

Структурные нотации - это структурное, схемное или текстовое представление структуры ПО из объектов, компонентов, их интерфейсов и связей. К этим нотациям относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity-Relation Diagrams), IDL (Interface Description Language), Use Case Driven и др. Нотации включают в себя:

1) языки описания архитектуры и интерфейса,

2) диаграммы классов и объектов,

3) диаграммы сущность-связь,

4) конфигурации компонентов,

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

Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. Им соответствуют диаграммы потоков данных (Data Flow), таблиц принятия решений (Decision Tables), деятельности (Activity), кооперации (Colloboration), последовательности (Sequence), пред- и постусловия (Pre-Post Conditions), формальные языки спецификации (Z, VDM, RAISE), языки проектирования PDL и др.

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

1) Литературная;

2) Сельскохозяйственная;

3) Жемчужины;

4) Строительная.

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

 

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

 

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

 

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

 

К стратегиям проектирования программного обеспечения относятся: проектирование снизу-вверх, сверху-вниз, абстрагирование, использование паттернов и др. Методы могут быть функционально-ориентированные и структурные. Первые ориентированы на идентификацию функций и их уточнение сверху-вниз. После этого уточняются диаграммы потоков данных и проводится описание процессов. Структурные методы базируются на структурном анализе, структурных картах, диаграммах потоков данных (Dataflow) и др.

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

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

При проектировании программных систем предлагается использовать до 5 уровней детализации (см. рис. 22):

Рис. 22. Уровни проектирования программных систем

Уровень1. Программная система в целом. Это – начальный уровень проектирования.

Уровень 2. Разделение системы на подсистемы или пакеты. Результатом будут эти подсистемы и связи между ними. Причем, связей должно быть немного, и они должны быть упорядочены. Наиболее часто используемые подсистемы:

a) Бизнес-правила (законы и директивы, реализуемые в системе);

b) Пользовательский интерфейс;

c) Доступ к базе данных.

Уровень 3. Разделение подсистем на классы. Определение основных сущностей, с которыми будет работать программа, и интерфейсов классов.

Уровень 4. Разделение классов на методы. Определение основных методов обработки информации.

Уровень 5. Проектирование методов. Выполняется отдельными программистами. Сводится к выбору конкретных алгоритмов, реализующих обработку данных.

Конструирование охватывает два последних уровня.

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

1) Быстрая разработка (RAD);

2) Унифицированная разработка (RUP);

3) Экстремальное программирование;

4) Технология Scrum.

Процессы разработки программных систем делятся на два класса:

1) Тяжеловесные и

2) Облегченные.

В первых прогнозируется весь объем работ. Они строго документируются и выполняются в заданном порядке и в заданные сроки. При этом изменение требований к программному продукту недопустимо.

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

Области применения рассмотренных процессов:

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

2) Адаптивный процесс используют при частом изменении требований, малочисленной группе разработчиков и грамотном заказчике, который активно участвует в разработке.

Быстрая разработка (Rapid Application Development) применяет инкрементную стратегию конструирования. Она обеспечивает очень короткий цикл разработки за счет компонентно-ориентированного конструирования. RAD-модель эффективна, если требования к системе полностью определены, а проектная область ограничена. При этом время разработки может быть от 60 до 90 дней.

RAD-подход ориентирован на разработку информационных систем и включает в себя следующие этапы:

a) Бизнес-моделирование, при котором система представляется на уровне бизнес-функций и потоков информации между ними;

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

c) Моделирование обработки, которое обеспечивает реализацию бизнес-функций;

d) Генерация приложения, которое максимально использует существующие компоненты, а вновь разрабатываемые компоненты предназначены для повторного применения; кроме того конструирование осуществляется с помощью утилит автоматизации;

e) Тестирование и объединение компонентов; этот этап требует мало времени, так как повторно используемые компоненты уже протестированы.

При RAD каждая главная функция приложения поручается отдельной группе разработчиков. Затем эти функции объединяются в систему.

RAD имеет следующие недостатки:

1) Для больших проектов требуются большие людские ресурсы;

2) Приложения должны декомпозироваться на отдельные модули;

3) Невозможность применения в условиях высоких рисков (если не определены все требования или используются новые технологии).

Унифицированная разработка (Rational Unified Process - RUP) – один из самых известных процессов, использующих итеративную модель разработки. Он был разработан компанией Rational Software и стал основной методологией компании IBM. RUP описывает некоторый абстрактный процесс, на основе которого организация или проектная команда создает специализированный процесс для конкретной системы. Основные характеристики абстрактного процесса:

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

b) Итеративная разработка с продолжительностью отдельной итерации от 2 до 6 недель. Перед началом итерации выбираются прецеденты, которые она должна реализовать.

RUP ориентирована на архитектуру. Реализация и тестирование архитектуры должны начинаться на самых ранних стадиях проекта. На первых итерациях выбираются наиболее важные прецеденты, которые требуются в большинстве компонентов. Это позволяет оценить принятые решения и избежать ошибок на ранних стадиях. Рекомендуется использовать модели на UML (которые можно строить с помощью пакета Rational Rose).

Жизненный цикл проекта RUP состоит из 4 фаз:

1) Начало обычно состоит из одной итерации, в ходе которой необходимо:

a) Определить видение и границы проекта;

b) Создать экономической обоснование;

c) Идентифицировать большую часть прецедентов использования и описать ключевые прецеденты;

d) Найти возможное архитектурное решение;

e) Оценить бюджет, график и риски проекта. Если оказывается, что выполнение проекта нецелесообразно, то на этой фазе все завершается.

2) Проектирование может занимать 2 – 3 итерации или быть пропущенным (если используется уже существующая архитектура). На нем создается архитектура системы. Результатом является 20 – 30 % реализованных прецедентов использования. Цель фазы:

a) Детальной описание большей части прецедентов использования;

b) Создание оттестированной базовой архитектуры;

c) Снижение основных рисков и уточнение бюджета и графика проекта.

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

4) Внедрение занимает от 1 до 3 итераций. На этой стадии проводится тестирование системы, тренинги пользователей и развертывание системы на рабочей площадке. Исполнители анализируют систему на предмет возможности улучшения и повторного использования ее модулей.

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

1) Бизнес-моделирование – описание бизнес-процессов заказчика и поиск их улучшений;

2) Управление требованиями – определение границ проекта, разработка и согласование с заказчиком функционального дизайна системы;

3) Анализ и проектирование архитектуры системы, ее развитие;

4) Реализация – разработка, юнит-тестирование, интеграция компонентов;

5) Тестирование – поиск дефектов, проверка реализации требований;

6) Развертывание – создание дистрибутива, установка системы, обучение пользователей;

7) Управление конфигурациями и изменениями – управление версиями и документирование;

8) Управление проектом – создание команды, планирование фаз и итераций, управление бюджетом и рисками;

9) Среда – создание инфраструктуры для выполнения проекта.

Объем работ, выполняемых в рамках перечисленных дисциплин, на разных фазах проекта меняется, как показано на рис. 24. Например, в начале больше усилий требуют анализ и дизайн, а в конце – реализация и тестирование системы.

Рис. 24. Распределение работ при выполнении проекта

 

Для полноценного создания RUP необходимо в начале обучить сотрудников.

Экстремальное программирование (eXtreme Programming, XP) – это облегченный процесс, ориентированный на группы малого и среднего размера (до 10 человек), которые разрабатывают системы в условиях неопределенных или быстро меняющихся требований. XP-процесс – высокодинамичный, состоящий из очень коротких итераций. Основными действиями в XP-цикле являются:

1) Кодирование,

2) Тестирование,

3) Выслушивание заказчика,

4) Проектирование.

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

a) Непрерывной связи с заказчиком и в пределах группы;

b) Простоты (выбора минимального решения);

c) Быстрой обратной связи (с помощью модульного и функционального тестирования);

d) Смелости в проведении профилактики возможных проблем.

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

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

2. Частая смена версий – быстрый запуск в производство простой системы. Новая версия реализуется в очень коротком (двухнедельном) цикле.

3. Метафора – вся разработка проводится на основе простой истории о том, как работает вся система.

4. Простое проектирование – проектирование с максимальной простотой.

5. Тестирование – непрерывное написание тестов для модулей (тестируй, а затем кодируй).

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

7. Парное программирование – весь код пишется двумя программистами, работающими на одном компьютере.

8. Коллективное владение кодом – любой разработчик может в любое время улучшать любой код.

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

10. 40 - часовая неделя – нельзя увеличивать производительность за счет сверхурочных работ.

11. Локальный заказчик – в группе постоянно должен находиться представитель заказчика, готовый отвечать на все вопросы.

12. Стандарты кодирования – соблюдение правил одинакового представления кода во всех частях программной системы.

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

«Метафора» обеспечивает глобальное видение проекта. Она не содержит детальную проектную документацию. Реструктуризация этого не требует. Проектная документация сохраняется, если заказчик перестает придумывать новые истории. Тогда работу приостанавливают (систему помещают в «нафталин») и пишут руководство страниц на 5 -10 по готовому варианту системы. Реорганизация на каждом шаге позволяет получить простейшее решение, а изменения приводят к отказу от решений «в общем».

Парное программирование обеспечивает повышение качества системы и уменьшение времени цикла. Доказано, что оно увеличивает затраты примерно на 15 %, а время цикла сокращает на 40 – 50 %. Этот стиль обеспечивает обмен опытом, более оперативное нахождение ошибок в коде и т.д.

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

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

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

a) Исследование – поиск новых требований (историй), которые должна реализовать система;

b) Блокировка – выбор для реализации конкретного подмножества из всех историй;

c) Регулирование – собственно разработка (реализация плана).

В соответствии с общими требованиями XP первая реализация (самая большая) должна иметь длительность 2 – 6 месяцев. Продолжительность остальных реализаций – около 2 месяцев. Каждая итерация длится примерно 2 недели. Численность группы разработчиков – не больше 10 человек.

XP-процесс для проекта с 7 реализациями, осуществляемый за 15 месяцев, показан на рис. 23. Процесс инициируется начальной исследовательской фазой. Эта фаза имеет клапан «пропуска». На ней принимается решение о целесообразности дальнейшей работы.

На рисунке предполагается, что длительность первой реализации равна 3 месяцам, а со второй по седьмую – 2 месяца. Реализации, начиная со второй, характеризуют природу XP-проекта. Каждая итерация длится 2 недели, за исключением тех, которые относятся к поздней стадии – пуску в производство (в это время темп ускоряется). Наиболее сложной является первая реализация. Она предполагает поставку заказчику первого варианта системы, причем, процесс начинается с нуля.

 

Рис. 23. Идеальный XP-процесс

 

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

1. Scrum Мастер (Scrum Master)– самая важная роль. Он отвечает за успех проекта. Эту роль играет менеджер (лидер). Он не раздает задачи. Команда является самоорганизующейся и самоуправляемой. Обязанности мастера:

a) Создание атмосферы доверия;

b) Устранение препятствий;

c) Уяснение и разъяснение проблем;

d) Соблюдение соглашений и корпоративных стандартов.

2. Владелец продукта (Product Owner) – представитель заказчика, отвечающий за разработку и принимающий все решения (обязательно один человек).

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

Процесс работы над программным продуктом по технологии Scrum иллюстрирует рис. 25.

В основе работы лежат короткие ежедневные и циклические 30-дневные встречи, которые называются спринтом. Отбор задач на спринт выполняется с учетом их важности, как показано на рис. 26. Во время спринта выполняются все работы по дизайну, кодированию и тестированию продукта. Результатом спринта является продукт, который можно передавать заказчику. Цель спринта должна быть фиксированной. Это означает, что только команда может изменить требования во время спринта.

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

Рис. 25. Выполнение проекта по технологии Scrum