Библиотека Интернет Индустрии I2R.ru

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

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

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

Какие особенности характеризуют программирование как сферу деятельности? По-моему мнению, наиболее резко выделяются такие аспекты:

• Легкость порождения новых конструкций (достаточно "просто пошевелить мозгами");
• Сложность решаемых задач (например, многопроцессорные вычислительные комплексы);
• Высокие темпы развития технологий и смены стандартов (новые виды программных средств возникают, развиваются и исчезают буквально за считанные годы);
• Непредсказуемость даже ближайшего будущего (еще недавно платформа J2EE в сочетании с CORBA считалась наиболее технологичной для распределенных приложений, с появлением SOAP и .Net это уже не так очевидно);

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

Пока разработки велись в стенах университетов, военных лабораторий и инженерных центров, этот метод был приемлем, так как объем работ и сроки позволяли детальную проработку проекта. Да иначе и быть не могло, потому что программы часто решали жизненно-важные задачи. Никому ведь не придет в голову выпустить пакет заплаток (service pack) для системы пилотирования космического корабля? Разделение процесса на последовательные этапы условно называется моделью "водопада" или "каскадной" моделью и схематично выглядит так:

Рис. 0-1. Модель каскадного процесса разработки.

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

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

Рис. 0-2. Модель возвратного процесса разработки.

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

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

Эта проблема была решена в следующей модели, называемой "спиральной".

Рис. 0-3. Модель спирального процесса разработки.

Эта методология является наиболее распространенной в текущее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF (Microsoft Solution Framework). Теперь создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточняя характеристики будущего продукта. Казалось бы, теперь все хорошо: и планируем мы только то, что можем предвидеть, и разрабатываем то, что запланировано, и пользователи начинают знакомиться с продуктом заранее, имея возможность внести необходимые коррективы.

Только для этого нужны ОЧЕНЬ большие средства. Действительно, если раньше можно было создавать и распускать группы специалистов по мере необходимости, то теперь все они должны постоянно участвовать в проекте: архитекторы, программисты, тестировщики, инструкторы и т. д. Более того, усилия различных групп должны быть синхронизированы, чтобы своевременно отражать проектные решения и вносить необходимые изменения. Разработка ведется в соответствии с концепцией MDA (Model Driven Architecture - Определяемая Моделью Архитектура), одобренной консорциумом OMG и предполагает использование языка UML в качестве средства "специфицирования, создания, визуализации и документирования систем" . Естественно, проку от нарисованных на бумаге диаграмм, мало, когда речь идет о MDA. Этот подход предполагает, что код и документация являются просто разными аспектами одной сущности - модели программной системы и должны быть постоянно синхронизованы. Соответственно, мы понимаем, что без специальных средств не обойтись, но хорошие CASE (Computer Aided Software Engineering - Разработка ПО с помощью компьютера) инструменты стоят просто умопомрачительных денег, а более дешевые не приводят к автоматизации всего спектра задач. Прибавьте стоимость высококлассных специалистов, способных извлечь пользу из столь высокотехнологичных инструментов и подумайте, не становится ли все это барьером для вхождения малых и средних предприятий в отрасль?

Между тем, не стоит забывать о том, что использование даже самых продвинутых специалистов и инструментов не предполагает безоблачного продвижения проекта по виткам спирали разработки. В мире коммерческих систем в расчет нужно принимать одну весьма непредсказуемую и влиятельную силу - заказчика, как явного, так и предполагаемого покупателя. Мир бизнеса развивается по своим законам и часто требует от обслуживающей его программной индустрии не просто быстрой, а стремительной перестройки, не взирая ни на какие UML модели. Кто настолько уверен в своих способностях, чтобы утверждать, что он сможет предвидеть все необходимые нюансы разработки, даже если не понадобиться вносить радикальные изменения. Мартин Фаулер - признанный эксперт в области проектирования программных систем и использования языка UML, говорит: "Even skilled designers, such as I consider myself to be, are often surprised when we turn such a design into software" (Даже опытные дизайнеры, каким я себя считаю, часто бывают удивлены, когда преобразуют такого рода дизайн в программное обеспечение) [3].

Да, если разрабатываются системы поддержки жизненного цикла больного или управления космическим кораблем, мы просто не можем обойтись без подробной и формализованной проектной документации. Но большинство задач не из этой области. Мы каждый день наблюдаем сообщения программ об ошибках, часто теряются некоторые данные, обычно не хватает каких-то операций и все это порой раздражает. Ну и что? Опыт и многочисленные исследования в этой области показывают, что пользователи ГОТОВЫ мириться с выходками программы, ПОКА она выполняет свои ГЛАВНЫЕ обязанности. По их мнению, это разумная плата за возможность приступить к использованию системы раньше, а не тогда, когда она станет безупречно свободна от ошибок и, как правило, уже никому не нужна. Естественно, все недостатки должны устраняться при их обнаружении и как можно скорее.

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

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

"Брожение" в умах передовых мыслителей информационной индустрии не пропали даром и привели к взаимному сотрудничеству в целях укрепления и развития общего дела. 11-13 февраля 2001 года произошла неофициальная встреча 17 наиболее активных исследователей нового направления. В результате столь неординарной по мнению многих участников встречи появилось новое образование, существующее пока только в виртуальном мире - Активный Альянс (www.AgileAlliance.org). В принятом меморандуме участники альянса выразили общее мнение по тем аспектам методологии, которые они считают наиболее значимыми:

• Взаимодействие людей превыше процессов и инструментов
• Работающее ПО превыше всеобъемлющей документации
• Понимание заказчика превыше подписания соглашений
• Реакция на изменения превыше следования плану

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

XP

Из всех новых методологий eXtreme Programming находится в самом центре всеобщего внимания. Именно благодаря XP активные методологии вызвали такой ажиотаж и всевозможные слухи.

Поначалу XP относили в лучшем случае к хакерству в худшем смысле слова. Многие до сих пор считают эту методологию чем-то вроде культа Вуду, несмотря на то, что ее основателем и главным идеологом является Кент Бек (Kent Beck) - всемирно известный эксперт по языку Smalltalk и разработке объектно-ориентированных систем. Другим видным пропагандистом XP является Мартин Фаулер (Martin Fowler) - тоже всемирно признанный ученый-исследователь и автор многочисленных публикаций на темы ОО систем, паттернов, UML и реструктуризации программ.

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

Чтобы понять XP, нужно забыть о том, что разработка ПО - это инженерная дисциплина. Ведь ни один инженерный проект не сталкивается в процессе реализации с такими проблемами, как изменение характеристик изделия в ходе разработки. Разве возможно, чтобы, например, при строительстве дома, позвонил заказчик и сказал: "Сделайте мне пятый этаж чуть пониже, шестой немного расширьте влево, а вместо лестницы установите американскую горку"? В программных проектах требования очень часто изменяются в ходе работ, не зависимо от первоначальной модели и архитектуры системы. Так что же тогда за процесс - программирование? В свете XP разработка напоминает написание книги группой авторов.

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

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

Все эти принципы применимы и при создании программной системы. Хотя Кент Бек и говорит, что они давно известны в практике программирования, только с появлением XP они действительно образовали эффективную методологию.

Простейшее работоспособное решение (Simplest thing that could possibly work)

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

Проникновение задачей (Personal involvement)

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

Постоянное общение

По мнению самого Бека и других специалистов, команда XP разработчиков не должна превышать 10-15 человек и они обязательно должны находиться в одном помещении, чтобы сократить до минимума издержки взаимодействия. При большем количестве участников проекта или отсутствия подходящего помещения, по крайней мере, постоянно контактирующие разработчики должны иметь возможность общаться без необходимости договариваться об этом предварительно. Известны успешные проекты и больших коллективов, вплоть до 40 человек.

Наместник заказчика (On site customer)

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

Парное программирование (Pair programming)

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

Общий стандартизованный код

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

Тесты вперед (Test first)

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

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

Таким образом, "тесты вперед" подход, хотя и не гарантирует 100% работоспособности, все-таки предоставляет очень высокие гарантии качества и позволяет и программистам и заказчику чувствовать себя более уверенно на пути к окончательному выпуску продукта.

Ежедневная сборка (Daily builds)

Чтобы еще сильнее повысить качество, XP предписывает делать промежуточные выпуски системы как можно чаще, даже до одного раза в неделю. Сборку системы или отдельных подсистем рекомендуется производить как минимум ежедневно, чтобы можно было после рабочего дня в автоматическом режиме проверять с помощью функциональных тестов ее работоспособность, а в случае неполадок быстро исправить ошибки, которые при таком подходе могли быть сделаны только накануне. При регулярных выпусках системы пользователи имеют возможность своевременно сообщать о недоработках, что улучшает продукт по ходу разработки. Как говорит Кент Бек: "Оптимизм - болезнь разработчиков, мнение заказчика - лекарство".

Рассказы пользователей (User stories)

Как же можно разрабатывать систему, если нет ни утвержденных спецификаций, ни плана разработки, ни архитектуры, да еще постоянно вносятся изменения? Вот это - то самое чудо, которое стало возможным благодаря XP. Ответ прост как все гениальное: мы начинаем разработку как только понимаем, чего хочет заказчик В ДАННЫЙ МОМЕНТ. В последующем, мы перестраиваем программы так, чтобы отражать вносимые изменения. При этом мы планируем только то, что можем предвидеть, а разрабатываем только то, что востребовано.

Для проведения этого простого принципа в жизнь, в XP предназначена специальная процедура, называемая "Рассказы пользователей", которая означает то же, что и прецеденты использования (use cases) в UML, но не имеют никакого формального выражения. Просто потребности пользователей должны быть осознаны всеми участниками проекта. Основную роль в этом играют неформальные встречи и дискуссии, а также "наместник" заказчика в группе разработки. Каждая "история" описывает какую-либо функциональную сторону системы и должна быть оценена по двум шкалам: "бизнес-ценность" и "величина риска". Затем эти "User Stories", ставшие уже полноценными требованиями, сортируются и на самом верху оказываются те, чьи бизнес или риск значение максимальны. Вот ими то и следует заняться в первую очередь. Риск не может быть устранен полностью, но заказчик должен о нем знать, а разработчики должны провести исследования и/или разработать прототипы, позволяющие обнаружить способы решения ожидаемых проблем.

Рефакторинг (Refactoring)

Как же писать программы в такой динамичной и постоянно меняющейся обстановке? Это объясняет другая, также нашумевшая техника XP, подразумевающая реструктуризацию и заключающаяся в осознанном подходе к вопросам модификации кода без потери его функциональности. Книга М. Фаулера подробно описывает этот процесс и включает большое количество примеров. На сайте www.retactoring.com поддерживается on-line версия каталога приемов реструктуризации и полезные ссылки. Конечно, программы модифицировали всегда, но только с появлением XP это стало не второстепенным занятием исправления просчетов, а полноценной техникой разработки, позволяющей вносить изменения таким образом, чтобы улучшать внутреннее устройство системы, а не приводить к ее деградации.

Разумное проектирование

Очень многие считают, что XP - это новый вид RAD (Rapid Application Development - Быстрая Разработка Приложений) технологии, которая зарекомендовала себя как недальновидная. На самом деле, XP не только поощряет проектирование, но и включает его в методологию. Как обычно, система требует тщательного планирования, но только уже без излишнего "пророчества" и требований к инструментарию. Для разработки общей архитектуры достаточно настенной доски для рисования. Если потребуется, дизайн можно сфотографировать и включить в документацию проекта. Как всегда, следует выделить те компоненты, которые, скорее всего, потребуют модернизации и постараться создать для этого соответствующие условия. Большим уважением пользуются паттерны проектирования и различного рода эвристики. Как и любая деятельность в XP, планирование компонента должно начинаться только тогда, когда оно безусловно необходимо. Особенно рекомендуется откладывать на возможно более долгий срок определение пользовательского интерфейса, как наиболее часто изменяющуюся часть системы и наиболее сильно отражающуюся на пользователях.

"Экстремальная" символизация

XP является флагманом новых методологий и в наибольшей мере символизирует их ценности:

• Взаимодействие личностей
• Работающие программы
• Сотрудничество с заказчиком
• Реакция на изменения

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