Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/03f24.shtml

ФАКТ 24

Факт 24
       Исправление ошибок в требованиях обходится дороже всего, если они обнаружены на этапе эксплуатации, и дешевле всего, если это происходит на ранних этапах разработки.

Обсуждение
       Данный факт - это всего лишь здравый смысл. Конечно, чем дольше ошибка остается в программе (или любом другом продукте, если уж на то пошло), тем дороже обходится ее исправление (а что может быть дольше промежутка между требованиями и вводом в эксплуатацию?). Боэм и Бэсили [Boehm and Basili, 2001] говорят, что исправление ошибок во время эксплуатации обходится в 100 раз дороже, чем на самых ранних этапах разработки.
       В программировании это обстоятельство становится особенно обременительным. На ранних порах ПО представляет собой нечто аморфное, не более конкретное, чем некий вид документированной спецификации, которую нетрудно изменить. Но с течением времени программный продукт становится все более детальным (на фазе проектирования), конкретным (на фазе кодирования) и жестким (по мере приближения кода к конечному решению). То, что в самом начале могло быть исправлено почти даром, впоследствии исправить гораздо труднее.
       Данный факт вполне четко и ясно говорит, что от ошибок в программном продукте надо избавляться настолько рано, насколько это позволяет рабочий цикл. Почему же о нем так часто забывают? Дело в том, что мы, кажется, не руководствуемся этим фактом в своих действиях, хотя и не оспариваем его. Устранение ошибок в требованиях на ранних этапах требует интенсивной доводки требований, на что, видимо, не остается времени из-за безудержного стремления уложиться в сроки (часто нереальные). Какие методы применяются для доводки требований? Проверка требований на согласованность. Пересмотр требований (заказчики и пользователи анализируют и корректируют последствия недопонимания и явные ошибки). Раннее проектирование контрольных примеров для требований. Обеспечение тестируемости требований. Моделирование и создание прототипа для проверки правомерности технических требований. И, пожалуй, если вы в них верите, составление формальных спецификаций (поскольку формализм способствует формированию более строгих технических требований).
       Есть масса способов, позволяющих убедиться, что требования корректны (с наибольшей вероятностью). В среднестатистическом проекте задействуется лишь малая часть этого списка.

Полемика
       Суть данного факта не вызывает полемики. Как мы отметили ранее, это не более чем здравый смысл.
       Единственное разногласие возможно по поводу того, что следует делать. Почти каждый претендует на свое решение. Теоретики программирования настаивают на методах формальных спецификаций. Разработчики помещают на первую позицию своего списка экспертизы. Тестеры и специалисты по качеству настаивают на том, чтобы требования поддавались тестированию и чтобы контрольные примеры создавались на ранних стадиях. Системные аналитики, пожалуй, могут требовать модельных подходов. Сторонники экстремального программирования поместят представителя заказчика в команду разработчиков.
       Различные мнения различных сторон, упомянутых выше, указывают нам на один из ключей к рассматриваемой проблеме. Мнения по поводу лучшего решения задачи у всех разные. А второй ключ, причем самый важный, на который мы намекнули двумя абзацами выше, - это наш старый заклятый враг, нереалистичные сроки. Никто не хочет рисковать, опасясь впасть в "аналитический паралич" (это вполне может случиться) при попытке рассматреть все требования. Так мы и несемся сломя голову через начальные фазы жизненного цикла, укладываясь в сроки или нарушая их, пока в конце концов не садимся на мель с программным продуктом, часто неудачным, понимая что нам предстоит тестирование, которому не видно конца. Бабах! И мы опять тратим уйму времени и средств на выискивание ошибок, которые таились в продукте с самого его рождения.

Источник
       Для данного факта есть несколько источников. Здесь представлен один из них, а второй можно найти в последующем разделе "Ссылка".
       — Davis, Alan М. 1993. Software Requirements: Objects, Functions, and States, pp. 25-31. Englewood Cliffs, NJ: Prentice-Hall. Данный факт представляет собой изложение точки зрения Дэвиса, рассмотренной в этой книге.

Ссылка
       Boehm, Barry, and Victor R. Basili. 2001. "Software Defect Reduction Top 10 List". IEEE Computer, Jan. "Обнаружение и исправление ошибки в ПО после его поставки зачастую в 100 раз накладнее, чем на стадиях составления требований и проектирования".


<<< Пред. Оглавление
Glass Robert L.
Начало раздела
След. >>>



<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/03f24.shtml