Отцом-идеологом экстремального программирования считают Кента Бека (Kent Beck, born 1961). XP является достаточно молодой методологией, оценки которой весьма противоречивы – от восторженных до резко негативных.

Факторы ускорения разработки.

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

Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2-3 недели и не более 1 месяца. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать посредством активного включения в процесс разработки заказчика как полноправного члена команды и за счет наличия постоянного контакта с заказчиком.

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

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

Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации.

Тесное взаимодействие с заказчиком (feed-back, on-site customer). Заказчик должен быть членом XP-команды (on-site customer). Заказчик должен быть экспертом в автоматизируемой предметной области. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).

Метафора системы (system metaphor). Хорошая метафора системы означает простоту именования классов и переменных; команда должна иметь единые правила именования.

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

Стандарты кодирования (coding conventions). Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга.

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

Парное программирование (pair programming) – одна из самых известных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит.

40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы (overtime) – это четкий индикатор проблемы на данном конкретном направлении разработки; к тому же заказчик не платит за сверхурочную работу в XP. Поиск причин сверхурочной работы и их скорейшее устранение – одно из основных правил.

Коллективное владение кодом (collective code ownership). Каждый программист в коллективе XP должен иметь доступ к коду любой части системы и вносить изменения в любой код. Обязательное правило: если программист внес изменения, и система после этого работает некорректно, то именно этот программист должен исправить ошибки. В противном случае работа системы уподобится тотальному хаосу.

Частая смена версий (small releases). Минимальная итерация – один день, максимальная – месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю плюс обратная связь (feedback). На основании этого определяется следующая итерация: каким будет новый релиз.

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

Тестирование (testing). В отличие от большинства остальных методологий тестирование в XP — одно из важнейших составляющих. Экстремальный подход заключается в том, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test — тест данного модуля; таким образом, в XP осуществляется regression testing (возвратное тестирование, «неухудшение качества» при добавлении функциональности).

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

ГЛАВА 6. СТАНДАРТЫ В ОБЛАСТИ программной инженерии

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

Слово стандарт происходит от английского standard - норма, образец, мерило. Это:

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

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

Например: ГОСТ ЕСПД – единая система программной документации – документы, описывающие состав и структуру документации на разработку программ для ЭВМ (общее описание, техническое задание, эскизный проект, технический проект, описание применения).

Типовые образцы, например, – эталоны мер и весов (эталон метра, хранящийся в Париже в палате мер и весов).

Стандарт может быть разработан на:

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

· нормы, правила, требования организационно-методического и общетехнического характера.

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

В нашем курсе мы кратко рассмотрим три вида стандартов:

· Федеральный государственный образовательный стандарт высшего образования по направлению 09.03.04 Программная инженерия,

· Профессиональные стандарты из группы 06 Связь, информационные и коммуникационные технологии, соответствующие деятельности выпускника бакалавриата по направлению 09.03.04 Программная инженерия,

· Стандарты по системной и программной инженерии.

6.1 Образовательный стандарт по направлению подготовки

09.03.04 Программная инженерия

Федеральный государственный образовательный стандарт высшего образования (далее - ФГОС ВО) представляет собой совокупность обязательных требований при реализации профессиональных образовательных программы высшего образования – программы бакалавриата по направлению подготовки 09.03.04 Программная инженерия.

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

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

Таблица 1