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

Ошибки в определении требований являются наиболее распространенными. 2. Стоимость > странепия таких ошибок, как правило, одна из самых высоких. Ошибки в определении требований приводят к затратам, составляющим 25 — 40% бюджета проекта разработки в целом. Учитывая частоту возникновения ошибок в определении требований и эффект умн<ь жения стоимостей устранения, легко предсказать, что эти ошибки обусловят оольшую часть — часто 70% или более — затрат на повторную работу.

А поскольку па переделки, как правило, расходуется 30-50% бюджета проекта (Бом (ВоеЬш )и Папаччо (Рарассю), 1988,Ь), ца устранение ошибок в определении требований может быть истрачено 25— 40% всего бюджета проекта! Наш опыт подтверждает эти данные, и это послужило основным побудительным мс» тивом лля написания данной книги. Если, затратив относительно небольшие средства на несколько ключевых приемов, сдастся продвинуться в данной области. это позволит сберечь значительные средства, повысить производительность, сэкономить время, не выоптьск из графика и. в конце концов, предложить заказчику результаты более высокого качества, нс говоря уже о сохранении сил и нервов команды разработчиков.

Глава 2 Введение в управление требованиями Основные положения ° Требование — это возможность, которую должна обеспс ьнвать система. И Управление требованиями — это процесс систематического выявления, организации и документп)ювания требований к сложной системе. И Наша задача состоит в том, чтобы понимать проблемы заказчиков в их предметной области и па вх языке и создавать системы, удовлетворяющие их потребности.

И Функция — это предоставляемое системой обслуживание для удовлетворс" иия одной илп нескольких потребностей клиентов. И Ирецсдецт (вариант использования, изс сазе) описывает последовательность выполняемых системой действий, дюощих клиенту некий полезный результат. Обратившись к приведенным в главе 1 данным, нетрудно понять, цочсму столь большое внимание уделяется управлению требованиями. Но прежде чем налагать различные методы и стратегии, необходимо привести несколько определений и примеров. Начнем с определения того, что понимается под трсоованисм. Определения 'Что такое требование Хотя за долгие годы уже появилось множество определений требований к программному обсспечсгшю, вполне приемлемым является слсдуюьцес определение, предложенное специалистами в области разработки требований Дорфианом ())огГтап) и Тэйером (ТЛаусг) (1990).

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

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

° Любой, кому довелось хотя бы однажды иметь дело со сложными программными систелзами — в качестве пользователя или разработчика — знает, насколько важнылг является умение выявить суть требований из общения с пользователями и прочими участниками процесса. ° Учитывая, что системе будут предъявлены сотни, если не тысячи, требований, очень важно о)зганизовать их. ° Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обеспечить дохулнппли~лоеаниетребоваиий. Требования следует записать так, чтобы они были доступны для ознакомления; зто может быть документ, модель, база данных или листок на доске объявлений.

Но как быть с управлением требованиями? Основными факторами в данном случае являются размер проекта и его сложиостзе никто не будет вспокзинать об "управлении" требованиями, если в проекте участвуют два человека и необходимо обеспечить выполнение десяти требований. Однако при проверке 1000 требований (как в неболыпом коммерческом программном продукте) или 300 000 требований (как в системе управления самолетом Боинг 777) пам, очевидно, придется столкнуться с задачами организации, определения приоритетов, управления доступом, а также обеспечения ресурсов для выполнения всех этих различных требований. ° Кто из участников команды проектировщиков отвечает за требование, касающееся скорости ветра (№278), и кому из них разрешено вносить в него изменения или вообще удалить его? ° Если в требование №278 вносятся изменения, на какие другие требования зто пс» влияет? ° Как удостовериться в том, что в системе программного обеспечения уже написан код для выполнения требования №278, и какие тестовые примеры из общего набора тестов предназначены для проверки того, что данное требование действительно выполнено? Именно эпю, а также многое другое подразумевается под управлениекс требованиями.

Глава 2. Введеиие в управлеиие требоваииями Это ис есть чт<»то совер|пеппо новое, что мы сами придумали. Это — одпп из осиоваипых па здравом смысле видов деятсльиости, которые в той или ипой форме реализуются болыпииством организаций-разраоотчиков. Однако, как правило, эта деятельность пс является формальной, и ск| занимаются от случая к случа|о.

В результате пекоторыс важнейшие виды деятельиости ь<о<уг пропускаться или производиться иа скору|о руку под давлением обстоятельств или связанных с разработкой политических моментов. Такцм образом, под управлением требовапиями следует попимать паоор оргапизовапиых, стаидартиэоваппых и систематических процессов и л|етодов работы с требованиями в значительном и сложном проекте. Коне шо, мы — пе первые, кто предложил идею оргаииэовапцых, <(юрмализованных пр<» цсссов; хорошо известны модель повышения уровня зрелое'и| процессов разработки пр<» граммиого обеспечения Института программирования (ВЕ(.СММ вЂ” Зо!<и<в е Епаэпееппк 1пэй<ше'э СараЬНиу Ма<оп|у Моде!), а также набор сти<даргов управления качеством БО 9000. Мы коротко изложим подходы, принятые в БВ!.СММ и 1$О 9000, в Приложении Г.

Применение методов управления требованиями Типы программных приложений Раисе мы предложили разоить программные приложения па следующие категории. ° Ипформациоппыс систе<п | и другие приложения, разработанные для использования внутри компании (такис, как система обра<ютки платежных ведомостей, используемая для расчета выдаваемых на руки сумм). Эта категория является основой индустрии ||пформациоииьш систем<<пи<(юрэ<ациоииых техполоп|й, илп 15/ГГ. ° Программиое обеспечспие (ПО), разрабатываемое и продаваемое как коммерческий продукт (иапример, текстовый процессор, которым мы пользовались при написании данной книги).

Разрабатывающие такое ПО компаппи обычно называют независимыми поставщиками программного обеспечения (!п<(среп<!еп«ойиаге тепЙогэ), или !э<<. ° Программное обсспсчсипс компьютеров, встраиваемых в дргпю приборы, машины или сложные системы (такие, как находящиеся в самолете, о котором мы уже писали, мобильном телефоне, которым только что пользовались, автом<юиле, в котором по. едем к месту следующей встречи). Программиое обеспечение этого типа паювем приложеииями для встроенных систем илп встроспиыми приложениями. Эти три типа приложений сущсствеипо отличаются по своей природе.

Приложения для болывих универсальных ЭВМ могут состоять иэ 5 000 000 строк па языке СО ВО1. и создаваться па протяжении десяти и более лет командой из 50-100 сотрудников, 11рпложепия ЖеЬ. кап сита а<о<ус состоять пз 10 000 строк про грамлп юго кода па языке ) а< а. и пх может создать эа год команда из одиог<»двух человек. !!аконец, программпое прыложеиие для системы учета теле<!юпиых разговоров в рсалыюм зрел|сии может состояты<э ! 000 000 строк, пап|ивиных па языке С с целью лшксимзльпо сократить время выполнения. Мы позаботимся о том, чтобы методы ушравлшпи трсбовшшямп, представленные в даю ной ишгш можно было применять к любому пз этих типов. Многие методы пс зависят от типа приложепив; для других может потребоваться дополпитсльпая (<чптывшощая тип приложс- 44 Введение ния) настройка перед их применением.