Новые методологии программирования

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

От полного отсутствия - к монументальности, от монументальности - к гибкости
Как правило, разработка программного обеспечения представляет собой довольно хаотическую деятельность, которую нередко можно охарактеризовать фразой "code and fix" ("пишем и правим"). Единого плана не существует, а общий проект представляет собой просто смесь краткосрочных решений. Такой подход может сгодиться для создания небольшой системы, однако если система начинает расти, добавлять в нее новые свойства становится все более затруднительно. Кроме того, в ней будет появляться все больше ошибок, которые будет все труднее исправлять. Типичные признаки такой системы - долгий тестовый период уже после того, как разработка всей функциональности системы закончена. При этом нарушаются все планы выпуска программы, так как при подобном тестировании и исправлении ошибок адекватное планирование просто невозможно.
Именно так мы и работали довольно продолжительное время. Впрочем, у нас всегда была альтернатива - использовать методологию. Методология превращает создание программного продукта в упорядоченный процесс, с помощью которого можно сделать работу программиста более прогнозируемой и эффективной. Для этого создается детальное описание процесса создания системы, особое место в котором занимает планирование (аналогично другим инженерным дисциплинам).
Такие методологии существуют уже давно. Нельзя сказать, что они очень уж эффективны. С еще меньшей степенью уверенности можно говорить об их популярности. Чаще всего их обвиняют в бюрократизме - чтобы следовать такой методологии, нужно выполнять так много различных предписаний, что замедляется весь темп работ. Именно поэтому их называют тяжеловесными методологиями, или, согласно термину Джима Хайсмита ( Jim Highsmith ), - монументальными.
За последние годы в противовес этим методологиям появилась группа новых, которые раньше было принято называть облегченными (lightweight). Теперь для них используют другой термин - гибкие (agile) методологии. Привлекательность новых методологий для многих заключается в отсутствии бюрократизма, присущего монументальным методологиям. Новые методологии представляют собой попытку достичь необходимого компромисса между слишком перегруженным процессом разработки и полным его отсутствием. Иначе говоря, объема процесса в них как раз достаточно, чтобы получить разумную отдачу.
По сравнению с монументальными методологиями, в гибких смещены все основные акценты. Самое очевидное различие - меньшая ориентация на документацию, что выражается в меньшем ее объеме для каждой конкретной задачи. Правильнее в данном случае будет говорить об ориентированности на код, то есть основная предпосылка состоит в том, что ключевая часть документации - это исходный код.
Впрочем, я думаю, что не это является главным отличием гибких методологий от монументальных. Отсутствие документации - это следствие куда более существенных различий:

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

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

Предсказуемый или адаптивный?
Проектирование и конструирование
Традиционным образцом для методологий программирования являются инженерные дисциплины, такие, например, как гражданское строительство и машиностроение, где особое внимание уделяется планированию, которое предшествует непосредственному строительству. Инженеры разрабатывают целый ряд чертежей, в которых точно указывается, что именно должно быть построено, и как соединить все составляющие в единое целое. Во время работы над этими чертежами принимается много различных проектных решений - например, как распределять груз на мосту и т.п. После этого чертежи передаются другой группе людей, чаще всего, вообще в другую компанию, которая будет заниматься собственно строительством. Принято считать, что строители в точности воспроизводят все, что было обозначено на чертежах. В действительности, строители сталкиваются при этом с некоторыми проблемами, однако, как правило, они несущественны.
Чертежи, где представлены отдельные элементы строительства, ложатся в основу подробного чертежа, который позволяет определить конкретные задачи и зависимости между ними. А это, в свою очередь, дает возможность рассчитать стоимость и временные рамки строительства. Кроме того, здесь же подробно описывается, каким образом строители должны делать свою работу. Благодаря этому работа строителей становится еще менее интеллектуальной, хотя, разумеется, нередко требует очень хороших навыков ручного труда.
Итак, в данном случае перед нами два совершенно разных вида деятельности. С одной стороны, проектирование , которое является трудно прогнозируемым процессом, и для которого требуются дорогостоящие творческие специалисты, с другой - конструирование , которое прогнозировать гораздо легче. Как только проект готов, можно планировать конструирование. Как только готов план, конструирование становится вполне предсказуемым процессом. В гражданском строительстве фаза конструирования гораздо масштабнее, нежели проектирование и планирование - как с точки зрения бюджета, так и по времени.
Подобным образом выглядит и подход к разработке программного обеспечения, принятый во многих методологиях: считается, что необходимо иметь предварительный план работ, по которому могут работать люди более низкой квалификации. Для этого проектирование должно быть отделено от конструирования. Следовательно, нужно спроектировать процесс создания программного продукта таким образом, чтобы работа по непосредственному конструированию (при наличии плана) стала несложной.
Итак, какую же форму должен иметь такой план? Многие считают, что роль плана должна играть нотация, созданная, например, при помощи языка UML. Если с помощью UML можно отобразить все существенные проектные решения, значит, можно создать нужный план и передать его затем кодировщикам, которые выполнят задачу по конструированию.
Однако здесь возникает важный вопрос: можно ли создать такой план, который превратит кодирование в относительно несложную работу? И, если да, то является ли кодирование настолько дорогим и долговременным процессом, чтобы подобный подход оправдывал себя?
Все это заставляет задуматься еще над несколькими вопросами. Во-первых, насколько сложно довести проект, выполненный на языке UML, до такого состояния, когда его можно передавать программистам. Проблема состоит в том, что нотация на языке UML может выглядеть очень хорошо на бумаге и при этом содержать в себе серьезные дефекты, которые проявятся только тогда, когда начнется работа по непосредственному программированию. В гражданском строительстве создатели моделей опираются на многолетний опыт, зафиксированный в целой системе правил. Кроме того, базовые положения модели (например, проектирование взаимодействия различных сил) поддаются математическому анализу. В отличие от таких моделей, UML и подобные им диаграммы можно проверить только одним образом - с помощью экспертной оценки. Конечно, такая проверка приносит свои плоды, однако при этом кое-какие ошибки могут остаться, и вы узнаете о них только в процессе кодирования или тестирования. Даже опытные проектировщики (каковым я считаю, к примеру, себя) нередко испытывают удивление, видя как их план воплощается в программном продукте.
Теперь относительно сравнительной стоимости. При строительстве моста на работы по проектированию уходит около 10% от всей стоимости работ. Остальное - затраты на конструирование. В программных разработках время, которое тратится на кодирование намного меньше (Макконнелл (McConnell) предположил, что в большом проекте на кодирование и написание тестового кода приходится всего 15%, то есть цифра, с точностью до наоборот повторяющая соотношение планирования и конструирования при постройке моста. Даже если считать тестирование частью конструирования, то все равно проектирование займет не менее 50% работ.) Отсюда вопрос о сущности проектирования при разработке программных продуктов и его отличиях от проектирования в других областях инженерной деятельности.
Наличие подобных вопросов заставило Джека Ривза (Jack Reeves) предположить, что на самом деле проектным документом является исходный код, а вся фаза конструирования сводится к использованию компилятора и компоновщика. И в самом деле, все, что можно отнести к конструированию, может и должно быть автоматизировано.
Размышляя обо всем этом, можно прийти к следующим выводам:

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

Основная идея этой статьи состоит в следующем: методологи разрабатывают сложные системы, у которых есть весьма изменчивые и нелинейные компоненты - люди. При этом им как-то удается вообще не замечать эти компоненты и то воздействие, которое они оказывают на проектируемую систему. После некоторого размышления такое положение дел кажется абсурдным, однако, в нашей отрасли совсем не много исследователей, уделяющих время серьезному изучению влияния человеческого фактора на разработку программного обеспечения.
Наиболее заметными исключениями из этого правила являются Джеральд Вайнберг (Gerald Weinberg [Wei]) и Том Демарко (Tom DeMarco [Dm]), чьи книги публикуются сейчас в юбилейных (!) изданиях. Их работы так популярны в нашей отрасли, что, казалось бы, они должны были только повысить интерес к этому предмету и вызвать активизацию исследований в этой области. Сейчас все большее количество консультантов начинает относиться к людям как к главному фактору в разработке ПО [B99] [Hi], однако, в целом, сообщество разработчиков программного обеспечения продолжает игнорировать тот факт, что именно человек должен быть центральной темой исследований. Это представляется мне серьезным упущением - все равно, что не принимать во внимание металлические перекрытия в стенах и жаловаться на плохую работу радиоприемника.
Раньше и я рассматривал людей, участвующих в проектах, как какой-то второстепенный фактор. Это продолжалось до тех пор, пока после нескольких лет работы исследователем и методологом, я не заметил, что мои рекомендации как методолога не соответствуют моему же собственному опыту в разработке ПО. Проблема была не в том, что делали мои разработчики (они справлялись с работой весьма успешно). Проблема была в другом: то, что я писал, не соответствовало тому, что мы делали.
В течение последних пяти лет я мучительно пытался определить (мне трудно это сделать даже сейчас) "что же находится у меня перед глазами". Постепенно мне стало ясно, что в моем (да и любом другом) методологическом уравнении не хватает одной переменной - влияния на методологию такого понятия как "человек".
Теперь, когда я начал учитывать этот параметр, мои методологические прогнозы и выводы стали соответствовать тому, что я вижу в реальной жизни. Теперь я считаю, что люди - это главный , первоочередной двигатель проекта.
Чем же это отличается от того, что писали в "Peopleware" Демарко и Листер (Lister)? Они высказали мнение, что люди представляют собой важный фактор, и указали на некоторую специфику вопроса. Меня же интересует то, как групповые и индивидуальные особенности человека влияют на проектирование способов разработки ПО (иными словами, на методологии), в применении к различным группам, работающим над разными видами задач.
Мои идеи весьма сходны с теми, которые излагал Вайнберг в главе "Teaming" ("Работа в команде") своей книги "The Psychology of Computer Programming" ("Психология программирования"). Особенно все то, что касается противопоставления двух стилей руководства - управления задачами (task management) и управления поддержкой (maintenance management). Это весьма близко к тому, что пытаюсь получить я - некие характеристики и рекомендации, которые из них следуют. Вайнберг основывается на тех проектах, которые он исследовал в 60-е годы. Однако его выводы остаются справедливыми и полезными и сейчас, 30 лет спустя, что еще раз подтверждает стабильность и важность человеческого фактора в разработке ПО. Мне кажется, уже наступило время тщательно изучить подобные факторы, и начать относиться к следующим из них рекомендациям как к основам разработки ПО, а не открывать их для себя каждые 30 лет.
В этой статье я расскажу о той работе, которую проделал, чтобы понять, что именно люди являются главным залогом успеха проекта. В настоящее время для прогнозирования я использую именно человеческий фактор. Я пишу эту статью от первого лица, потому что формальный, академический стиль не очень подходит для описания поисков чего-то совершенно очевидного и при этом не совсем понятного. Лучше всего подать это в виде рассказа от первого лица.
Все проекты и команды отличаются друг от друга, поэтому не существует одной методологии, которая подходила бы всем без исключения. Люди тоже отличаются друг от друга, к тому же им свойственно непостоянство, однако большинство любит общаться, может ориентироваться в нестандартной ситуации и проявлять инициативу.
Можно ли строить удобные и эффективные методологии, базируясь на этих двух утверждениях? В этой статье я расскажу, как можно динамически конструировать гибкие методологии, с одной стороны, основываясь на положительных сторонах человеческой натуры, а с другой, учитывая ее слабости. Такое конструирование помогает не только наладить общение по техническим вопросам, но и отслеживать зависимости в рамках проекта. При этом первоочередное внимание уделяется моральному духу команды и тесному взаимодействию разработчиков. Вспомогательные рабочие продукты доводятся лишь до той степени завершенности, которая позволит сообразительным коллегам понять, куда двигаться дальше. В каждом конкретном случае процесс разработки динамически "настраивается" на максимальное соответствие нуждам самого проекта и команды, которая над ним работает.

Краткий обзор дискуссии
Эта статья - логическое продолжение предыдущих работ: "Characterizing people as first-order, non-linear components of software development" [Co1] (в русском переводе: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения") и "A methodology per project" [Co2] (в русском переводе: "Каждому проекту своя методология"), где обсуждалась возможность создания гибкой "человекоцентричной" методологии для отдельно взятой команды, причем непосредственно в процессе работы над проектом.
Суть изложенного в этих статьях материала сводится к следующему: Нет двух одинаковых проектов или команд, но у любой организации есть некие общие характерные черты, слабые и сильные стороны. В процессе предварительного опроса можно определить эти основные характеристики и уже на их основе начинать делать первые методологические рекомендации. Можно, конечно, начинать давать рекомендации, основываясь только на принципах конструирования методологии (даже притом, что относительно самих этих принципов до сих пор нет единого мнения). Впрочем, один из них гласит, что в любом проекте человеческий фактор может легко возобладать над процессом (см. [Co1], [Wei]). Легкие методологии, основанные на межличностных коммуникациях, представляют собой довольно прочные структуры (см. [Co2]). Их оптимальный "вес" может разниться от проекта к проекту, в зависимости от количества занятых в работе людей и близости их физического размещения, а также ущерба от возможного сбоя системы (см. [Co2]). Главное достоинство легких методологий состоит в том, что они предписывают обрабатывать большие объемы информации, относящиеся к проекту, в процессе неформального, непосредственного, личного общения, а не с помощью документации. Для этого команда использует сильные стороны человеческого характера: способность людей "ориентироваться в обстановке, задавать вопросы и обсуждать их", отслеживать внутрипроектные зависимости, элементы требований и дизайна. Подобная коммуникация делает методологию не только легче и экономичнее, но и "приятнее", удобнее и комфортнее. Подобные механизмы часто используют опытные руководители. Сейчас можно назвать целый ряд родственных методологий, которые строятся на сходных принципах, и которые можно "настроить" под конкретный размер команды (или культуру). Все эти "легкие" методологии я очень кратко перечислю в конце статьи.
Данная работа состоит из следующих частей:

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

"Каждому проекту своя методология" и свойства человеческой натуры
Первая из двух статей, на основе которых я написал эту, называется "Characterizing people as first-order, non-linear components of software development" [Co1] (в русском переводе: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения"). Заканчивается она следующим образом:

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

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

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

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

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

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

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

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

Второй статьей была "A methodology per project" [Co2] (в русском переводе: "Каждому проекту своя методология"). Она заканчивается такими словами:

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

Объединив и то, и другое, получаем:

  1. Каждый проект заслуживает своих собственных процесса и методологии, созданных специально для него.
  2. "Легкость" и непосредственное общение являются весьма желательными их атрибутами.
  3. Наиболее эффективно люди общаются непосредственным образом - лицом к лицу.
  4. Непостоянство, непоследовательность и лень представляют собой самые заурядные человеческие слабости, которые всегда нужно учитывать при конструировании методологии (ключевая фраза: "процессы, требующие высокой дисциплины, обречены на хрупкость").
  5. Процесс разработки должен строиться на положительных качествах человеческой натуры: чувстве гражданской ответственности, способности ориентироваться в обстановке, общаться друг с другом и проявлять инициативу.

Источники
Эта статья основывается на результатах работы над реальными проектами, а также исследованиях и опросах, проведенных мною в период с 1991 по 1999 гг. Большая часть собранных материалов так или иначе представлена в работах [Co1], [Co2] и [Co3].
Все эти идеи подтвердились после опроса тех организаций, которые сумели добиться таких же успехов, разрабатывая аналогичные методологические подходы. В Великобритании IBM Object Technology Practice уже несколько лет проводит семинар по так называемой "настройке методологии" в начале каждого проекта. Что-то подобное делает в Мюнхене Siemens. А один из военных субподрядчиков во Флориде рассказал, как его сертифицированная по ISO-9000 группа разработчиков создает особый легкий процесс для каждого вида работ (при помощи контрольных таблиц для процесса).
Я также использовал работу Керта (Kerth), [Ke], где рассматривается техника ретроспективного анализа работ (обычно их называют "разбором полетов", но этот автор использует понятие "послеродовый осмотр").
С процессом осуществления изменений в структуре и в принципах работы команды в конце каждого инкремента я впервые познакомился во время работы над проектом "Ingrid", [Co3] в 1992. Тогда без этого было просто не обойтись. С тех пор я внес в метод некоторые дополнения, а именно объединил его с правилом "настраивать" методологию еще и в середине инкремента. После я открыто использовал этот принцип в работе над проектом "Winifred" [Co3], и когда работал в Центральном Банке Норвегии [Co2]. Кроме того, мой коллега использовал принцип "настройки" методологии в конце каждого инкремента, работая над проектом "Insman" в Германии [Co2]. Все три проекта окончились успешно, причем применение такой методологии явно повлияло на качество результата.
В течение многих лет при разработке ПО использовались самые разнообразные методологии (как в случае уже упомянутых IBM и Siemens, а также описанные в работах [MO] и [Gr]). Однако, насколько мне известно, первой методологией, которая рекомендует динамически менять процесс во время проекта, является Crystal.
Идея заменить письменную документацию непосредственным личным общением была высказана давным-давно. Ее отстаивал в конце 60-х Вайнберг (Weinberg [Wei]), а в конце 70-х - Демарко (и снова он, но уже в 90-х [De1], [De2]). С тех пор многие использовали эти идеи как "секретное оружие", а недавно вышли из подполья - независимо и сразу в нескольких местах:

  • в методологии под названием eXtreme Programming ([Be] (в русском переводе "Экстремальное программирование", "Питер", СПб, 2002)
  • в семействе легких методологий Crystal [Co4]
  • в методологии Adaptive Software Development ([Hi])

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

Действие первое - предыстория
Айвар Якобсон (его фамилия так и произносится: "Я-коб-сон") начал писать о сценариях использования программных продуктов году эдак в 1967, когда работал над системой AXE для компании Eriksson. Те первые сценарии были написаны в свободной форме и весьма неформальным языком. Писал он их для того, чтобы показать, как люди будут использовать эти самые системы AXE. Тогда варианты использования еще не напоминали те сложные формальные структуры, которые зачастую используются сейчас при их описании (к чему и автор, вынужден признаться, приложил руку...). В середине 80-х Якобсон уже тратил немало времени и сил на описание тех решений, которые он смог найти в этой области в течение прошедших 20 лет. Именно тогда он придумал шведский термин "anvendningfall", что в приблизительном переводе означает "ситуация использования" или, по-английски, "usage case". Работая над английским переводом своей статьи, он решил, что "usage case" звучит как-то не по-английски, и переделал его в "use case". Если вам чем-то не нравится термин use case ("вариант использования"), скажите спасибо, что вам не приходится каждый раз выговаривать anvendningfall. Идея неформальности и свободы изложения была заложена в понятие варианта использования изначально. Дело в том, что людям не нравилось - да и сейчас не нравится - излагать сценарии формальным образом. Когда я однажды спросил Якобсона, нет ли у него модели для формального изложения вариантов использования, он ответил: "Ох, ну конечно же, я сделал такую модель. Есть только одна проблема - никто не хочет ею пользоваться". Впрочем, если считать варианты использования неформальными документами, возникнет другая проблема. Люди начнут спрашивать: "Да что же это такое, эти ваши "варианты использования"? Как мне узнать, что я пишу их правильно? А как связать между собой много вариантов использования?"
В 1992 я натолкнулся на первую, программную статью Якобсона о вариантах использования, которую он написал в 1987 году. В то время я работал над созданием объектно-ориентированной методологии для IBM Consulting Group . Как и многие до меня, я сразу понял, что эти описания поведения системы естественным образом дополняют внутренние описания компонентов системы, которые создаются во время ОО-проектирования. Поэтому я, как и многие другие, начал искать ответ на вопрос: а что же такое эти варианты использования? И, как и многие другие, я попадал то в одну, то в другую ловушку - писал их слишком формально или слишком свободно. Нужно было накопить некоторый опыт, чтобы понять, что лучше всего выбрать средний вариант. Якобсон, тем временем, продолжал издавать книги и статьи, посвященные вариантам использования, однако почему-то вопросы при этом никуда не исчезали.

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

  • Что такое вариант использования - строгое изложение требования к системе или просто описание (story)?
  • Может быть, "сценарий" - это еще одно название для варианта использования?
  • Насколько формальной или неформальной должна быть структура варианта использования?
  • Образуют ли варианты использования некую взаимосвязанную структуру, или же просто сваливаются в кучу?

Для некоторых вариант использования был просто еще одним определением понятия "сценарий" (краткого описания некоторого взаимодействия пользователя с системой). Мартин Фаулер (Martin Fowler) часто язвительно замечал, что "вариант использования", скорее всего, и значит "сценарий", только по-шведски. Последователи этой школы считают, что у варианта использования нет никакой внутренней структуры. Если их становится много, то их просто сваливают в кучу, и все. Те, кто пишет варианты использования таким образом, вполне довольны результатами, поэтому до сих пор многие рекомендуют описывать варианты использования именно так. Прочие же, особенно исследователи и разработчики CASE (Computer Aided Software Engineering) средств, посчитали, что неформальные артефакты будут слишком неполными, и что им нужен математический базис и поддержка в CASE средствах. Они разработали специальные языки, нотации и программы, с помощью которых варианты использования превратились в строгие и скрупулезные описания. Этот подход снискал куда меньше последователей. Людям был нужен простой способ выражения своих соображений относительно будущей системы. Они не хотели использовать формальные программные средства. Более того, им казалось, что дополнительная работа по формализации вариантов использования не дает ощутимых результатов. Кроме того, формалисты столкнулись с еще одной проблемой: как учесть все варианты поведения, с которыми может столкнуться система? Как-то меня спросили: "Если я разрабатываю автомат для продажи конфет, как мне специфицировать, какие монетки засунет туда покупатель? Он может положить три монетки по 25 центов, а может и 15 пятицентовиков. Или сначала положит 25 центов, а потом десять пятицентовиков? Или в обратном порядке? Или еще как-нибудь?" Я ответил: "Нужно написать: человек кладет в автомат деньги". После того, как я на своем опыте убедился в том, что слишком много формализма так же плохо сказывается на результатах работы над вариантами использования, как и его отсутствие, я остановился на неком среднем варианте: полуформальный текст, который находится в полуформальной структуре. В этом случае мы можем:

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

Может быть, это покажется неожиданным, но вторая цель гораздо важнее первой. Ниже я изложу структуру, которую я считаю оптимальной, и которая позволяет одновременно учитывать обе приведенные выше конфликтующие между собой цели. Несложно понять, что вариант использования представляет собой текстовое описание шагов, которые выполняет действующее лицо (actor). "Что же объединяет все эти шаги? Что в них общего?" В начале 90-х никто не мог однозначно ответить на этот вопрос. Внимательно слушая объяснения Айвара Якобсона и размышляя над примерами, которые он приводил, я обнаружил две подсказки. Первая, самая важная, заключалась в том, что вариант использования описывает то, как действующее лицо пытается достичь некой цели, используя систему. Таким образом, если мы назовем одно из действующих лиц основным, то все действия можно будет рассматривать в контексте тех целей, которые он (или она) пытаются достичь.
При описании вариантов использования очень важно связать их с целями, которые ставят перед собой действующие лица системы. Это не даст свести варианты использования к описанию функциональности системы, о которой в первую очередь пекутся программисты. Нет, подходить надо с другой стороны: что именно хочет от системы пользователь? Это и есть причина, по которой он взаимодействует с программой. Если программа дает пользователю возможность достичь поставленной цели, то она тем самым приносит ему максимальную пользу. А вот вторая подсказка, которую я нашел у Якобсона: иногда цель оказывается недостижимой. Любое желание, будь то получить выгодный контракт, вставить карточку в банкомат, заполнить еще одно поле в онлайновой форме и т.д., может по тем или иным причинам оказаться невыполнимым. Если задуматься о подобных ситуациях заранее и описать, как система должна вести себя в таких случаях, можно сэкономить массу времени и денег. Получается, что вариант использования должен представлять собой структуру из двух частей: описание последовательности действий, когда все идет, как надо, и небольшие описания того, как ведет себя система, когда происходит какой-то сбой.
Однако тут перед нами встает еще одна проблема - цели могут иметь различные масштабы. Например, я могу считать своей основной целью желание получить хороший контракт. Более близкая цель (временной промежуток сужается) - пригласить клиента вместе пообедать. Еще более близкая цель (временной промежуток еще уже) - раздобыть наличность, чтобы заплатить за обед. Эта цель подводит меня к необходимости снять деньги с карточки в ближайшем банкомате. В это же время моей самой насущной и самой краткой по времени целью является засунуть карточку в банкомат и начать транзакцию. Все эти цели сосуществуют одновременно. Достижение или недостижение каждой из них можно описать при помощи вариантов использования. Главное - понимать, что если мы не будем указывать, насколько масштабную цель описывает вариант использования, у читателя возникнет искаженная картина происходящего. Варианты использования пишет множество различных людей. Если каждый из них будет прямо в тексте обозначать, каков масштаб цели, которую он описывает, то читатель сразу поймет, что имелось в виду, и избежит всевозможных недоразумений и недопонимания. При всем уважении к банкоматам, нельзя не отметить, что в нашем примере самой важной и высокоуровневой является цель получить контракт на работу. Получить деньги из банкомата - это так сказать, цель среднего уровня. А вот вставить карточку в банкомат - это очень низкоуровневая цель, фактически, деталь поведения. При этом каждая цель является совершенно полноценной и заслуживает отдельного варианта использования. Если в начале варианта использования сразу указать, какого уровня цель он описывает, то у читателя сразу же сложится правильное представление о поведении системы и пользователя. В описании варианта использования мы совмещаем идею о многоуровневости целей и понятие успешности/неуспешности их достижения. Каждый шаг сценария представляет собой цель меньшего масштаба, которую уже удалось достичь. Мы пишем: "Клиент вставляет карточку в банкомат", имея в виду самую низкоуровневую цель и подразумевая, что клиент ее выполнит. Продолжая описание этого варианта использования в разделе "Альтернативные варианты" или "Дополнения", мы должны будем написать, что случится, если эта низкоуровневая цель все же не будет достигнута: "Карточка застревает в банкомате; банкомат автоматически выключается и ставит в известность ремонтную службу".

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

И в течение продолжительного времени достаточно было ответить: "А что вы хотите - это же документирование требований к системе! Если не записать все, то требования будут не полными". Приходилось удовлетворяться таким ответом, хотя его было явно недостаточно.

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

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

Вот простой пример. Джим подходит к автомату, продающему конфеты. На самом деле, он не хочет тратить деньги - он хочет конфету. Он бы был рад, если бы конфеты выдавались бесплатно. У владелицы автомата совсем другие интересы. Ей, вообще-то, совсем не хочется отдавать конфеты. Она была бы рада, если бы люди просто клали в ее автомат деньги. Автомат по продаже конфет действует на основе простейшего контракта: Джим кладет в автомат деньги, а владелец автомата должен гарантировать, что Джиму выдадут конфету.

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

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

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

Итак, к этому моменту (1997 год) стало казаться, что в теории создания вариантов использования уже не осталось "белых пятен".

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

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

Авторы Экстремального Программирования (ХР3) остались верны идее неформальных сценариев, у которых нет никакой заданной структуры. Кент Бек (Kent Beck) создал термин "рассказ пользователя" (user story). Именно им и стали называть такие неформальные требования к системе. Рассказ пользователя состоит из нескольких фраз, записанных на маленькой бумажной карточке. В них пользователь объясняет, что именно он хочет от системы. В ХР рассказ пользователя представляет собой не требование к системе, а некое напоминание о будущем обсуждении этой функциональности с заказчиком. Таким образом, на карточке достаточно записать ровно столько информации, чтобы и заказчики, и программисты поняли, что именно им нужно будет обсудить в дальнейшем.

Ларри Константайн (Larry Constantine) рассматривает описание сценариев с точки зрения проектирования пользовательского интерфейса. Он обнаружил, что для этого ему совершенно не нужно описывать внутреннее поведение системы или ее взаимодействие с второстепенными действующими лицами. Для проектирования интерфейсов вполне достаточно текста, записанного в две колонки. В первой пишут то, что пользователь пытается сделать, во второй - как реагирует на его действия система. Такая простейшая структура позволяет создать интерфейс, отвечающий задачам пользователя. Чтобы избежать путаницы, Константайн переименовал "вариант использования" (use case) в "вариант задачи" (task case), так как варианты использования традиционно представляют собой спецификацию системы.

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

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

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

В своей книге "Writing Effective Use Cases"4, я выделяю три уровня детализации в описании вариантов использования: краткий, обычный и полный.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исходя из этого, в ближайшем будущем с вариантами использования может произойти следующее:

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

Что же можно сделать, чтобы варианты использования были действительно полезной техникой? Прежде всего, надо научиться:

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

А потом расслабьтесь и анализируйте доводы за и против.

Книги

  • Armour, F., Miller, G., Advanced Use Case Modeling: Software Systems, Addison Wesley, 2000.
  • Cockburn, A., Writing Effective Use Cases, Addison-Wesley, Boston, MA, 2000.4
  • Constantine, L., Lockwood, L., Design for Use, Addison Wesley, 1999.2
  • Jacobson, I., The Object Advantage : Business Process Reengineering With Object Technology, Addison Wesley, 1995.
  • Kulak, D., Guiney, E., Use Cases: Requirements in Context, Addison Wesley, 2000.

Статьи

 

Страница сайта http://silicontaiga.ru
Оригинал находится по адресу http://silicontaiga.ru/home.asp?artId=5561