Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 7
Текст из файла (страница 7)
11о действительно ли проблемы требований влияют на итоговый код? В табл. 1.! представлены результаты исследования, проведенного в 1994 году Каперсом Джонсом (Сарсгз 1опез), и приводятся данные о всроятном количестве возможных дефектов и средней эффективности их устранения организацией-разработчиком посредством различных комбинаций тестирования, контроля и других методов.
Таблица 1.1. Краткая характеристика недоработок Источники дефектов 77% 0.23 Требования Проектирование Кодирование 1.00 1.25 55% 0.19 0.09 5055 45% 4055 35"а 3055 2555 20% 1555 10'А 555 0% Возможность Эффективность Оставшиеся дефекты возникновения устранения Глава 1. Проблема требований 87 Охоннанис амба.
1. 1 Источники дефектов Возможность Эффективность Оставшиеся дефекты возникновения устранения Документация Неправильная установка В целом О.бО 0.40 80% 0.12 70% 0.12 0.75 5.00 85% В колонке "Возможность возникновения произведена нормализация в соответствии с тем, какова доля каждой категории, если общее количество дефектов принять за 5.00. Это число выбрано произвольно и ничего не говорит об абсолютном количестве недоработок.
Колонка "Оставшиеся дефекты", относящаяся к тому, что видит в конечном итоге пользователь, нормализована аналогичным образом. Ошибки требований занимают первое место среди оставшихся недоработок и составляют примерно одну треть всех не>странепных дефектов.
Таким образом, это исследование служит доказательством того, что ошибки требований — наиболее распространенная категория ошибок при разработке систем. Высокая цена ошибок требований Если бы ошибки требований можно было быстро, просто и экономно устранять, проблема не была бы столь серьезна. Но приводимая ниже статистика пе оставляет никаких надежд. Все обстоит иначе. В проведенных в кохпшниях СТЕ, Т(сЪ', 1ВМ и 111' исследованиях была оценена стоимость ошибок, возникающих на различных стадиях жизненного цикла проекта. Дэвис (1)атЬ) в своей работе (1995) подвел итоги нескольких подобных исследований. Результаты представлепга на рис.
1.2. Хотя эти исследования проводились независимо, они имели приблизительно одинаковые результаты: если стоимость усилий, необходимых для обнаружения и устранения ошибки на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в пять — десять раз меньше. А стоимость обнаружения и устранения ошибки на стадии сопровождения — в 20 раз больше. Из рисунка видно, что при обнаружении ошибок па стадии формирования требований получаем экономию средств в соотношении 200:1 по сравнению с их обнаружением па стадии сопроволсдения жизненного цикла программы.
Хотя это может быть преувеличенисъг, легко заметить, что в данном случае проявляется эффект умножения. Причина состоит в том, что многие из этих ошибок достаточно долго остаются пс обнаруженными. Прн внимательном чтении этого раздела можно заметить, что па рис. 1.2 пс вполне корректно объединены два аспекта: относительная стоимость различных категорий ошибок и стоимость их устранения на различных стадиях жизненного цикла программного обеспечения. Например, элемент "период формирошшия требований" фштически подразумевает все ошнбкщ обнаруженные и устраненные во время, официально обозначенное как "период форапарования требованиуг".
Но поскольку маловерояпю, что техническое просктнровщпге илп программирование будут производиться па столь раппсй стадии (нсклкачая возможные действия по созданию прототипа), ошибки, которые обнаруживаются и устраняются па этой стад п и, дейпягк вильно якая ются ошибками требований. 38 Введеиие Ркс. 1.3. Отиоситеяьная стоимость устранения ошибки е)>озяичиыя фаиис яиььиенноео цикео Однако ошибки, обиаружеииые на стадии проектирования, моь>сг относиться к одной из двух категорий: (1) ошибки, возвикшис при создании технического проекта из правильного множества требований или (2) ошибки, которые следовало обнаружить ранее как овьибки требований, каким-то образом "просочившиеся" иа фазу проектирования.
Именно вторая категория ошибок особенно дорого обходится по двум причинам. 1. Ко времени обнаружения ошибки в требованиях группа разработчиков уже могла потратить время и усилия иа создание проекта по этим ошибочиым требованиям. В результате проект, вероятно, придется отбросить или пересмотреть. 2. Истинная природа ошибки может быть замаскирована; при проведении тестирования и проверок на данной стадии все думают, что имеют дело с ошибками проектирования, и значительное время и усилия могут быть потрачены впустую, пока кто-иибудь ие скажет; "Минуточку! Это вовсе ие ошибка проектирования; мы полу. чили неверные требоваиия". Для уточнения, в чем же состоит ошибка требований, необходимо общение с клиентом, который >частвовал в его разработке на саьюи первом этапе.
Но может оказаться, что в данный моььсит связаться с этим человеком невозможно или ои забыл, в чем состояла суть инструкции, которую он давал команде разработчиков, либо ие помнит, чем руководствовался при этом, или же просто переменил свою точку зрения. Аналогично может оказаться, что принимавший участие в этом этапе член команды разработчиков (часто такой человек имеет статус "бизнес-аналитика" или "системного аналитика") перешел в подразделение, занятое другим проектом, или также страдает кратковременной потерей памяти.
В рез>льтате определенная часть работы проделывается вхолостую, и это приводит к потере времеви, Проблемы, связанные с "просачиванием" недостатков из одного этапа в другой, являются вполне очевидными, сслп о них задуматься, однако подавляющее болышпютво орга- Глава 1. Проблема требований 39 ниэаций ими всерьез не занималось. Одной из организаций, й ислмнээиьно,баб)нлоэкмй пэд данным вопросом, является компания НпбЬсз А)гс~арц исследование Снайдера (Япубсг) (1992) обнаружило явление "просачивания" дефектов во многих проектах, выполненных компанией на протяжении 19 лет.
В данном исследовании говорится о том, что 74% дефектов, связанных с формированием требований, были обнаружены па этапе анализа требова. ний, когда клиенты совместно с системными аналитиками обсуждают, подвергают мозговому штурму, согласовывают и документнрукзт требования к проеиу. Это — идеальное время (и обстановка) для обнаружения таких ошибок с наименьшими затратами. Однако исследование также свидетельствует, что 4 процента дсфсктов "просачнвак~тся" на этан предварительного (высокоуровневого) проектирования, а 7 процентов — еще дальше, на этап детализированного проектирования.
Такое "просачивание" движется все дальше и дальше по жизненному циклу системы, и 4 процента ошибок требований оказываются не найденными вплоть до этапа сопровождения. когда система уже передана клиентам и считается полностью работоспособной. Таким образом, в зависимости от того, где и когда при работе над проектом разработки программного приложения был обнаружен дефект, цена его может раэпитыя в э0 — 100 раз. Причина состоит в том, что для его исправления придется затратить средства на некоторые (или все) ниже перечисленные действия. ° Повторная спецификация ° Повторное проектирование ° Повторное кодирование ° Повторное тестирование ° Замена заказа — сообщить клиентам и операторам о необходимости заменить дс.
фектную версию исправленной ° Внесение исправлений — выявить и «странить все неточности, вызванные неправильным функционированием ошибочно специфицированной системы, что может потребовать выплаты определенных сумм возмущенным ктиенталь повторного выполнения определенных вычислительных задач на ЭВМ и т.п. ° Списание той части работы (кода, части проектов и т.п.), которая выполнялась с наилучшими побуждениями, но оказалась ненужной, когда обнаружилось, что все это создавалось иа основе неверных требований ° Отозвание дефектных версий встроенного програмлшого обеспечения и соответствующих руководств.
Если принять во внимание, что программное обеспечение сегодня встраивается в различные изделия — от нар«чиых часов и микроволновых печей до автомобилей — такая замена может коснуться как этих изделий, так и встроенного в них программного обеспечения ° Выплаты по гарантийным обязательствам ° Ответственность за изделие — если клиент через суд треоует возмещения ущерба, причиненного некачественным программным продуктом ° Затраты на обслуживание — представитель компании должен посетить заказчика, чтобы установить новую версию программного обсспечепия ° Создание документации 40 Введение Заключение Итак, из приведенных данных можно сделать два вывода. 1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
