Читать интересную книгу Программное обеспечение и его разработка - Фокс Джозеф М.

При разном руководстве создаются условия для возникновения ошибок. Стрелки А на рис. 4.10 направлены в обе стороны, поскольку пользователи должны иметь возможность передавать свои требования разработчикам. Часто они лишены такой возможности.

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

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

Смысл стрелки В вполне понятен и ясен, но она обычно игнорируется до тех пор, пока не случится какой-нибудь казус!

Патологические жизненные циклы программного обеспечения

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

Рис. 4.11. Патологический жизненный цикл программного обеспечения, пример 1 (вверху). Рис. 4.12. Патологический жизненный цикл программного обеспечения, пример 2 (внизу).

Первая схема (рис. 4.11) иллюстрирует разрыв между разработкой и продолженной позднее разработкой. Во многих случаях за эти этапы отвечают совершенно разные организации. Заключившая контракт группа в Новой Англии разрабатывает, а где-то на юге другая группа ведет сопровождение. Пунктирная линия между разработкой и продолжающейся разработкой показывает, что этот переход не гладкий и не простой. В действительности во многих случаях мы можем нарисовать такую схему, как на рис. 4.12.

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

Эти схемы соответствуют одноразовым разработкам, которые встречаются в случае программных обеспечений типов I и II.

Неразрывная связь разработки и продолжающейся разработки

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

Рис. 4.13. Жизненный цикл программного обеспечения, в котором разработчик сам сопровождает свои программы.

Это в особенности относится к программам типа V, которые разрабатываются постепенно и имеют несколько версий, каждая из которых вступает в действие в свой срок.

Имеются ли различия в задачах разработки и продолжающейся разработки? Безусловно, но они не имеют ничего общего с тем, как их многие себе представляют. Мой коллега Энди Ферентино (который привлек мое внимание к рис. 4.13) был свидетелем выступления кандидата на соискание докторской степени по программированию, темой диссертации которого было различие между разработкой и «продолжающейся разработкой» (в терминологии автора «maintenance»). Энди указал на то, что окружение, в котором создается программное обеспечение, должно быть абсолютно одинаковым на обеих фазах. Эти два рода деятельности лишь очень немногим отличаются один от другого. Давайте проследим шаг за шагом.

Разработка программного обеспечения, продлевающая все фазы жизненного цикла

Если составить диаграмму, отражающую сравнительные усилия в ходе разработки программного обеспечения, мы увидим, что затраты на определение требований и проектирование превышают затраты на использование, а затраты на сопровождение редко бывают значительными.

Таблица 4.1. Различия между разработкой и продолжающейся разработкой

Разработка Продолжающаяся разработка 1. Определение требований для системы типа V крайне затруднено, так как до этого таких систем еще не было С системами типа V работать легче, так как пользователь к этой фазе уже лучше знает, что ему нужно (Для систем типов I и II работа по определению требований практически одинакова) 2. Проектирование. Большие возможности. Выбираются лучшие варианты. Начинают сверху Проще, поскольку система существует, многое из того, что спроектировано на верхних уровнях, сделано, и в большей мере определяет то, что надо делать на более низких уровнях. Труднее, если документация плохая. Напоминает археологические раскопки 3. Программирование Такое же Такое же 4. Компоновка Такая же Такая же 5. Тестирование Такое же Такое же 6. Документирование Такое же Такое же

Это проиллюстрировано на рис. 4.14, где размер букв пропорционален затратам на соответствующие фонды.

Рис. 4.14. Затраты на разработку, распределение по фазам жизненного цикла.

Такое распределение затрат абсолютно неверно. Оно, однако, повсеместно распространено, потому что разработчики программного обеспечения постоянно убеждают сами себя в том, что обеспечение должно создаваться по методу «большого взрыва», единым усилием. Это заблуждение имеет свои причины, мы еще будем в этом разбираться.

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

Фаза использования

Хотя фаза использования следует в жизни программы после фазы разработки, именно она является, или по крайней мере должна являться, определяющей. Ее характеристики в большой степени определяют две другие фазы. Для начала перечислим некоторые из характеристик использования, которые могут уточнить стратегию разработки.

Периодичность использования. Я могу разработать программу, которая выполняется каждый день, или раз в неделю, или раз в месяц, или раз в год. Я также могу разработать программу, которая будет работать постоянно, все время. Я могу разработать программу, которая будет исполнена только один раз, а затем выброшена. Эффективность использования аппаратуры (например, памяти) крайне важна, если программа работает постоянно, и совершенно не имеет никакого значения для программы, запускаемой однократно или только один раз в год.

Количество пользователей. Я могу разработать программу, которая будет использоваться только моей фирмой и нигде больше. Я также могу разработать программу для использования на 500 предприятиях моей отрасли. Я могу разработать программу для тысячи различных небольших фирм, каждая из которых может, а возможно, и будет использовать ее немного по-своему. И снова особенности и характеристики, на которых я настаиваю в моей программе, сильно различаются при этих различных видах использования. Пять сотен разных пользователей влияют на программу совершенно иначе, чем 500 «одинаковых» пользователей (все пользователи из моего учреждения используют систему одинаково).