Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 6
Текст из файла (страница 6)
Если вы думэстс, что только ваша организация испытывает подобцьзе проблемы, вас успокоит вытекающий нз приведенной в главе 1 статистики факт, что практически все организации страдают от нцх. Знание того, лачаку возникают эти проблемы и где онн наиболее острыс н дорогостоящие, — первый важнейший шаг на пути совершенствования. В главе 2 вводятся используемые в управлении требованиями понятия, которые будут обсуждаться ца протяжении всей книги. Даже если вам кажется, что вы знаете, что такое Введение 31 "требования" — и действительно, кто нс знаем этого? — мы рекомендуем прочитать этот материал, так как в нем содержатся некоторые определения и общие предположения, которые используются в дальнейшем. Наконец, глава 5 посвящена организации команды создателей программного обеспечения. Успешное управление требованиями может осуществляться только хороню организованной командой создателей программного обеспечения.
Однако данная книга не о командах, и рассмотрение гаких важных тем, как формирс» ванне высокопроизводительных команд, их мотивация и управление ими в процессе разработки программного обеспечения, не входит в нашу задачу. Книга посвящена управлению требованиями к программному обеспечению, а для успешного осуществления этой задачи необходима поддержка всей команды создателей программного обеспечения. Дело в том, что, возможно, управление требованиями в большей степени, чем любая другая деятельность в рал~ках разработки программного обеспечения, затрагивает каждого члена как основной, так и расширенной команды, в которую входят пользователи и другие заинтересованные лица.
Мы исходим из того, что во всех проектах, за исключением самьпс тривиальных, успешное унроэление тфебоеанклми мозсет осущесэмляэпся тааько хорошо ореаивзоэоикой командой сидаяилей программного ойсягченил. Более того, чтобы добиться успеха, каждый член команды должен тем или иным образом участвовать в процессе управления требованиями и знать о своей роли в нем. Глава 1 Проблема требований Основные положении ° Цель разработки программного обеспечения состоит в том, чтобы, уложив<вись в отведенное время п бюджет, разработать качественное программное обеспечение, удовлетворяющее реальные потребности пользователей.
щ Успех проекта зависит от хоров<о организованного управления трсбова. пнями. ° Ошибки в требованиях — наиболее часто встречающийся тпп ошибок при рзэработкс систем, а их устранение является наиболее дорогостоящим. ° Использование нескольких ключевых прись<оп может значительно снизить вероятность ошибок в требованиях и, следовательно, повысить качество программного обеспечения.
Цель В настоящее время тысячи команд разработчиков программного обеспечения занять< раз. работкой самых разнообразных программных приложений в различных отраслях. Но, рабе- тая в разных отраслях и говоря на разных язь<ках, вес оии работают с олними и теми же из- вестнымн технологиями, чнтыот одни н те жс журналы, учились в одних и тех же н>колах и, к счастью, ичеют одну жную цель: розрабопюп<ь удпвлппмпрлпппее реальные поп<раб><огп>п алпеппю копеспмп< пап проз)к<а<иное пбсг> ичение, улплпппиись и опмедпоше прсчл и бюдлгепь Клиепть< могут быть достаточно разными, ° Для некоторых из нас клиент является некой внсншсй сущностью, источником эакаюв, и сто нужно убедить отклонить предложения нывих конкурентов и приобрести па>а г<г товый программный продухт, поскольку ои проще в использовании, имеет болыпс функциональных возможностей и, в конечном счете, лу'пвс по всем параметрам.
° Для хруп<к клиентом является напавшая нх для разработки своего програлпшого обеспечения компания, которая ожидает, что програл<лн<ос обеспечение оудет наивысшего качества (во<>з<ожиого при сопрел<синоп< состоянии Лел) и слопает компанию более конкурентоспособной н более прибыльной. ° /гля большинства жс клнспт работает вместе с нами, спл>п лалывс по к<>рнлору, этажом ниже плп где-то в другом месте и с ш тер<нншсм ожняаст полог<> при»оа«- пия, п<>зволя<ощсго более эффективно обрабатывать заказы пли пгн<>лш<>вать срсгютяа алсктр<ншой комл<ерцип Лля продажи товаров и услуг, чтооы комп,ишп, и 34 Введение которой мы вместе работаем, стала более прибыльной, а наша работа лучше опла чивалась и приносила большее удовлетворение.
Таким образом, хотя клиенты и различны, цель у всех одна. Немного статистики Необходимо признать, что при разработке нетривиальных программных систем кар. тина получается достаточно пестрой. Безусловно, некоторые системы работают достаточно хорошо, и непрофессионалы, равно как и ветераны, поражаются тому, что удалось сделать: 1п»егпе», интерфейсы пользователя, карманные вычислительные устройства, интеллектуальные приборы, управление процессами в реальноь» времени, интерактивное ведение счетов клиентов брокерских фирм и т.д. Также верно и то, что многие работающие системы весьма несовершенны.
Например, текстовый процессор и операционная система персонального компьютера, которые авторы использовали при написании данной книги, вместе вызывали примерно два системных сбоя в день при создании этой главы, а также демонстрировали множество других неприятных сюрпризов и досадных мелких неточностей. Конечно же, их нельзя считать примерами соверв»енного прс» граммного обеспечения, однако они были "достаточно хороши", чтобы с их помощью написать данную главу.
Но зачастую ситуация более серьезна. Исследования группы Стендиша (Б»апдЬ)» Сгоир) (1994) свидетельствуют о следующеь». В США ежегодно трапштсл йиее 250 миллиардов дсиларов на разработку нрило. жений информационных технологий в рамкак»фимерно 175000 провитав. Средняя спюимость проекта для кру»»»ий компании сосптаеяет 32322000, дея средней— $1331000, а длямелкой — $434000... Ииледования гру»»»»ы Стендита показаеи, что 31%»»роекпнм»удип пу»ехра»цен до ювертения.
За»»»рапса на 52, 7% проектов сос»»швяп» 189% оп» пьу»воначальной оценки... Исходя из этого, г)эу»»па Спмндита оцениваепь что.,американские кампании и нраеипмэъственные учреждения потравит В1 миллиард долларов на программные »»роек»»»ы, которые ток и не будут заверше»»ы. Эп»и же организации заплатят дотмнипмль»»о 59 миллиардов даэларов за ирограм. ные проекты, которые хотя и запер н»апкя, незначительно»»рееысят первоначально отведенное на них время.» В целом к таким данным принято относиться с некоторой долей скепсиса, но каждый из работаияинх в дан»»ой отрасли может легко привести примеры подобного рода У каждого из нас есть любимый проект, который так и не вышел на рынок, или информационная система, своего рода "смоляная яма", которую ь»ы создали и до сих пор страдаем от этого.
Таким образом, если есть очевидные эмпирические доказательства того, что проблема существует, и эти доказательства нолтвер;кдаются нашим собственным опытом, лу ш»ее, что можно сделать,— прнзпать ее существование и попытаться ее решить. Не так ли? Используется с разрешения. Глава 1. Проблема требований 35 Основные причины успеха и провала проекта Первым шагол~ на пугн решения любой проблемы является осоз»а»яе ос»ов»ых»ркчк» ее воз»ихновеныл. К счастью, в своем обзоре группа Стснлигла не ограничилась цифрами и предложила своим респондентам указать наиболее значительные факторы, повлиявшие на "успешные", "проблемные" (с которыми возникла задержка или пс оправдавшие ожиданий) и "потерпевшие неудачу (прекращенные) проекты. И тогда оказалось, что не случайно в данной кингс такое пристальное в»ил~ание уде.
ляется вопросу требований; многие наиболее часто встречающиеся серьезные проблсл~ы при разработке программного обеспечения связаны имснно с требованиями. В оюгетс группы Стецдиша (1994) указано три наиболее часто встречающихся ключевых фактора, создающих "проблемы" в проектах.
° Недостаток исходной информации от клиента: 13% всех проектов ° Неполные требования и спецификации: 12% проектов ° Изменение требований и спецификаций: 12% всех проектов В остальном данные сильно расходятся. Конечно, проект может потерпеть не)дачу из-за нереалистического подхода к составлению графика или выделению времени (эта причина указана для 4% проектов), неправильного подбора персонала и выделения ресурсов (6%), несоответствия технологических навыков (7%) и по другим причинам. Но если считать, что приведенные группой Стендиша цифры представляют реальное положение дел в отрасли, то, по крайней л~ере, третья часть проектов испытывает проблемы из-за причин, непосредственно связаннгях со сбором и документированиел~ требований, а также с управлением ими.
Хотя большинство проектов действительно превышают отведенное время и бюджет, если их вообще удается закончить, группа Стендиша обнаружила, что около 9% проектов крупных компаний были завершены вовремя и в пределах бюджета; аналогичного успсха удалось достигнуть в 16% проектов мелких компаний. Возникает очевидный вопрос: Ка. козы ал»внмг "факто(гм усшхл" в ятях»рогктах) Согласно проведенному исследованию тремя наиболее важными факгорачн были следующие. ° Подключение к разработке пользователя: 16% всех успс»шых проектов ° Поддержка со стороны исполнительного руководства: 14% всех успешных проектов ° Ясная постановка требований: 12% всех успешных просктов Другие источники приводят даже более впечатляющие результаты.
Например, организация Е5Р!Т! (Епгореап 5о(п»аге Ргосем 1шргоеегпепг Тга!»1»8 1пй(айте — Европейская инициатива по обучению совершенствованию процесса п рограм ми рован»я) провела в 1996 году опрос с целью определить относительную важность рата»чиых типов су" щсствующих в отрасли проблем. Результаты этого широкого опроса, в котором приняли ) врастив 3800 респондентов, отражены на рис. 1.1. Двумя самыми главными проб»елками, упоминавшимися почти в половине ответов, оказались следующие. 1. Спецификации требований 2.
Управление требованиями клиента Зб Введение В подтверждение результатов опроса группы Стендиша, вопросы собственно написа. ния кода вновь оказались относительно "нспроблемными", Из сказанного следует, что требования являются одной из основных причин возникновения проблем прн разработке програымпого обеспечения. !'ассыотрим экономические факторы, связанныс с этой конкретной причиной. Рис. 1.1. Опювиые типы праблем, аазиииающик яри разрабатие при ераммиаею абтпечеиил частота возникновения ошибок; связанных с требованиями В исследованиях как группы Стендиша, так и Е5Р1Т1 содержатся качественные данные: респонденты считают, что проблемы требований, судя по всему, превосходят остальные в плане риска неполадок, которые онн вызывают цри разработке приложений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
