Принципы работы с требованиями к ПО. Леффингуэлл (2002) (Принципы работы с требованиями к ПО. Леффингуэлл (2002).djvu), страница 91

Но поскольку многие организации по разныл~ причинам приняли 13О 9000 (то лн потому, что считали его >дачным, то ли потому, что это было необходимым условием веденин бизнеса в Европе и др>тих частях мира), интересно рассмотреть, какое внимание уделяется в нем нринцэшам > правления требованиями. Так, 13О 9000 подчеркивает Приложение Г. Принципы управления требованиями в стандартах... 425 необходимость взаимной катерацкк закаэчика и разработчика систем программного обеспечения; в частности, он требует выполнения следующего. ° Назначить представителей обеих групп, ответственных за задание требований ° Определить методы и процедуры согласования и принятия изменений требований ° Предпринять усилия по предотвращению неправильного понимания трсбовшшй ° Определить процедуры записи и пересмотра результатов обсуждений требований Хотя кажется, что зто очевидные и всем известные действия, которыми можно пренебречь, стоит вспомнить, что происходит прн оценке, необходимой для прохождения сертификации.

В организацию приходит инспектор и спрашивает: "Где ваши методы и процедуры принятия измснсний требованийу Предъявите мне их в письменном виде. Я хотел бы провести внеплановые проверки отдельных команд разработчиков и убедиться, что данные процедуры действительно выполняются". 15О 9000 также требует, чтобы исходная информация для фазы разработки нроекта— фазы жизненного цикла, когда обычно выполняется техническое проектирование и программирование — была определена и докумептирована. Этой исходной информацией, очевидно, являются требования, и 15О 9000 требует, чтобы они были сформулированы таким образом, чтобы их выполнение можно было проверить.

Стандарт РВО 9000 также предписывает использовать процессы систематического разрешения проблем неполноты, неоднозначности и конфликта требования. Одним нз важных следствий такого внимательного отношения к требованиям с самого начала разработки является то, что прн организованном проведении технического проектирования и разработки можно рассчн. тывать, что в результате работы появится система, которая действительно соответствует спецификации (т.е. набору требований), а пе полагаться на то, что качество работы системы будет обеспечено в результате проведения чрезмерного количества испытаний в конце жизненного цикла разработки. Как и 5Е1-СММ, 15О 9000 ничего нс говорит о том, хак осуществлять управление требованиями.

Факт существования официального процесса, который прсдписываст выбрать "официальных" представителей иэ числа польэоватслсй н разработчиков для обсуждения требований к системе, очевидно, не гарантирует, что эти два нндивндтэыа бу. дуг в состоянии выявить и документировать правильные требовапив. 11о вооружившись описш[ными в данной книге процед)рами и методами, мы сможем создать всеобъемлющий подход к управлению требованиями, который удовлетворит самых придирчивых инспекторов!5О 9000 и СММ.

Приложение Д Принципы управления требованиями в Кабопа1 Ю'ПЮей Ргосеы Совместно с Филипном Крачтеном (РЫ11рре КхисЫеп) и Лесли Пробаско (Ееа1ее РтоЬаасо) В данной книге предлагается обзор лучших практических наработок в управлении требованиями. Описанные в книге профессиональные приемы н предложенный в главе 35 рецепт управления требованиями помогуг команде пойти по правильному нуги при разработке следующего проекта.

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

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

Кайопа1 ()п)бед Рюсем (процесс разработки программного обеспечения, который был разработан и преврэщен в коммерческий продукт корпорацией Кайопа1 боймаге Согрогжюп (1999)), вобрал в себя лучшие практические приемы в отрасли разработки программного обеспечения. Процесс основан на прсцсдснтах и использует итеративный подход к разработ. ке програзопгого обеспечения. Оп включает в себя обьсктноорисптпроаанные методы, и многие виды деятельности в пел~ направлены на разработку маделей, описанных посредством УМ( КНР является развитием методологий ОЬ)сего~у (Джейкобсон ()асоЬзоп), Кристсрсон (СЬпмсгзоп), Джонсон ()опззоп), 1992) и Кайопа1 ЛрргоасЬ. В нсго внесли свой вклад многие эксперты отрасли, среди которых авторы данной книпь команды разработчиков из компаний Ке9пвйс, 1псл 8ОЛ, 1псл и ~ноги~ др) гис. Как продукт, КНР представляет собой доступное посрсдствол~ ЪсЬ руководство, которое попадает непосредственно на рабочий стол разработчика программного обсспсчепия.

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

Хотя в нем используется несколько иная терминология, чем в данной книге, И.1Р обеспечивает реализацию предложенных в книге основных принципов управления требованиями в такой форме, что они могут непосредственно применяться командой разработчиков программного обеспечения. Структура КАР! Процесс описывает, кено, чию, как и когда делает. Ка!!опа1 13гййед Ргосем описывается с помощью четырех ключевых элементов моделирования. ° Сотрудники (тгог)сегз), "кто" ° Деятельности (ас!!т!!!ез), "как" ° Артефакты (агт!таста), "что" ° Рабочие процессы (ног)т()отнз), "когда" 1'ассмотрим рнс.

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

Деятельности Сотруд Реализация яра цедента Рнс. Д.1. Соитруднньтг, дтмтел знаеми в аритефантим т Этот раздел взят из работы Фттлнппа Крачтена (Р!ттйрре Кгос!ттеп), Т!те Кз!!она! оп!ттед Ргосем — Ап!нггоднсцоп (Кеагйпб, МА: Ада!зон-Иез!су Еообтпзп, 1999) стр. 89 — 48, н воспроизводится с согласия издателя. Приложение Д. Принципы управления требованиями в Кайона!... 429 Рабочие гг)гоцессы позволяют группировать деятельности а осмысленные поспелова. тельпости, которые обеспечивают некий результат для организации-разработчика, и показывают, как взаимолействуют различные сотрудники. В дополнение к этим четырем основным понятиям, К1)Р предлагает мепюднческне указания по осуществлению соотвст.

ствующих деятельностей, гааблоны основных артефактов, а также руковадспгва по применению автоматических средств разработки программного обеспечения. Принципы управления требованиями в КАУР 11риемы управления требованиями организованы в К1)Р в Раттгггг нРоцесс угазугабогггкгг пфебовагтй, один из девяти основных рабочих процессов. В ходе данного процесса производятся и обновляются следующие артефакты (рис. Д.2). ° Заггросы заинтиересовапных лиц; т.с, коллекция различных запросов, в том числе формальные запросы изменений, потребности или другие пожелания заинтерссо.

ванных лиц на протяжении жизненного цикла проекта, которые могут повлиять натребования к продукту. ° Документ-концеггцил 11гмгол иосггпгеггг), который кратко характеризует копнсш1ию рассматриваемой системы: основные характеристики. функции, потребности за. интересованных лиц, а также основные предоставляемые уел)ти. ° Модель ггРецедпгаов, которая представляет собой организованный набор прецедентов, составляющих основную массу требований. ° ззогкглнипильные спецификлцгггг., фиксирующие все требования, которые невозможно непосредственно связать с конкретными прецедентами; в частности, многие нефункциональные требования и ограничения проектирования. Два последних артефакта вместе образуют единую форму, которую мы в данной книге назвали пакетом Модегп ЗКЯ 1гас)сабе.

В результате данного рабочего процесса разрабатываются также другие артефакты, которые перечислены ниже. ° АпгРггбуты пг)Уебоваггийг информационный архив, содержащий связанную с требованиями информацию, которая используется для отслеживания статуса требований и обеспечения их трассировки к другим элементам проекта. ° Раскад~овкгь ггРецедентов, система пгчески производимые для основных прсг1слеггтов с участием актаров-людей, чтобы моделировать интерфейс пользователя и исследовать некоторые требования практичности.