В программной инженерии

(ПРИНЦИПЫ «БЫСТРОЙ РАЗРАБОТКИ ПО»)

В начале 2001 г. ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и др.) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки ПО» (Agile Alliance's Manifesto) и заключающихся в следующем[3]:

· индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;

· работающее ПО ценится выше всеобъемлющей документации;

· сотрудничество с заказчиками ценится выше формальных договоров;

· реагирование на изменения ценится выше строгого следования плану.

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

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

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

· когда она позволяет людям легче выразить свои мысли. Языки высокого уровня дают возможность более сжато выражать идеи. Некоторые языки высокого уровня позволяют человеку мыслить в технологическом пространстве, приближенном к проблемному пространству, позволяя почти не отвлекаться на мысли об ограничениях реализации;

· когда она выполняет задачи, невыполнимые вручную. Инструменты измерения и анализа собирают данные, которые иначе собрать было бы невозможно. Программисты говорят о них, как об основных инструментах;

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

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

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

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

· G — дефекты вызывают потерю удобства;

· D - дефекты вызывают потерю возместимых средств (материальных или финансовых);

· Е — дефекты вызывают потерю невозместимых средств;

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

· от 1 до 6 человек — малый масштаб;

· от 6 до 20 человек - средний масштаб;

· свыше 20 человек — большой масштаб.

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

· интерактивное общение лицом к лицу — это самый дешевый и быстрый способ обмена информацией;

· избыточная «тяжесть» технологии стоит дорого;

· более многочисленные команды требуют более «тяжелых» и формальных технологий;

· большая формальность подходит для проектов с большей критичностью;

· возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;

· дисциплина, умение и понимание противостоят процессу, формальности и документированию;

· потеря эффективности в некритических видах деятельности вполне допустима.

Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является «Экстремальное программирование» (Extreme Programming — ХР[4]). Далее приве­дено краткое изложение этого метода.

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

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

3. Единицей собираемых требований к ПО является «пользовательская история» (user story), описывающая с точки зрения пользователя функциональность, которая может быть разработана за одну итерацию. Заказчики записывают истории на простых индексных карточках. Заказчики и программисты договариваются о планах на следующую итерацию таким образом:

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

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

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

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

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

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

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

8. Один человек в команде назначается «наставником». Вместе с участниками команды он оценивает использование ими основных приемов: парного программирования и тестирования, ротации пар, поддержания простоты проектных решений, коммуникации и т.д.

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

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

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

В своем определении ХР включает набор приемов и методик, которые команде нужно освоить: игру планирования, ежедневное оперативное совещание, реорганизацию и опережающую разработку тестов.

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

! Следует запомнить

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

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

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

4. Неотъемлемыми свойствами ПО являются сложность, согласованность, изменяемость и незримость.

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