Программное обеспечение и его разработка
Шрифт:
Если составить диаграмму, отражающую сравнительные усилия в ходе разработки программного обеспечения, мы увидим, что затраты на определение требований и проектирование превышают затраты на использование, а затраты на сопровождение редко бывают значительными.
Таблица 4.1. Различия между разработкой и продолжающейся разработкой
| Разработка | Продолжающаяся разработка |
|---|---|
| 1. Определение требований для системы типа V крайне затруднено, так как до этого таких
| С системами типа V работать легче, так как пользователь к этой фазе уже лучше знает, что ему нужно |
| (Для систем типов I и II работа по определению требований практически одинакова) | |
| 2. Проектирование. Большие возможности. Выбираются лучшие варианты. Начинают сверху | Проще, поскольку система существует, многое из того, что спроектировано на верхних уровнях, сделано, и в большей мере определяет то, что надо делать на более низких уровнях. Труднее, если документация плохая. Напоминает археологические раскопки |
| 3. Программирование Такое же | Такое же |
| 4. Компоновка Такая же | Такая же |
| 5. Тестирование Такое же | Такое же |
| 6. Документирование Такое же | Такое же |
Это проиллюстрировано на рис. 4.14, где размер букв пропорционален затратам на соответствующие фонды.
Такое распределение затрат абсолютно неверно. Оно, однако, повсеместно распространено, потому что разработчики программного обеспечения постоянно убеждают сами себя в том, что обеспечение должно создаваться по методу «большого взрыва», единым усилием. Это заблуждение имеет свои причины, мы еще будем в этом разбираться.
В большинстве проектов обычно получается так, что если реализуется от половины до трех четвертей обещанных функций, то проект объявляется успешно завершенным. Продукция отправлена потребителю, спутник запущен. Все упущения будут восполняться позднее, под маркой сопровождения. Для повышения технологичности сопровождения и облегчения продолжающейся разработки делается очень мало или совсем ничего. Никаких усилий не прилагается к тому, чтобы сделать систему более подходящей для пользователя.
Хотя фаза использования следует в жизни программы после фазы разработки, именно она является, или по крайней мере должна являться, определяющей. Ее характеристики в большой степени определяют две другие фазы. Для начала перечислим некоторые из характеристик использования, которые могут уточнить стратегию разработки.
Периодичность использования. Я могу разработать программу, которая выполняется каждый день, или раз в неделю, или раз в месяц, или раз в год. Я также могу разработать программу, которая будет работать постоянно, все время. Я могу разработать программу, которая будет исполнена только один раз, а затем выброшена. Эффективность использования аппаратуры (например, памяти) крайне важна, если программа работает постоянно, и совершенно не имеет никакого значения для программы, запускаемой однократно или только один раз в год.
Количество пользователей. Я могу разработать программу, которая будет использоваться только моей фирмой и нигде больше. Я
Тип использования. Существуют диалоговые и автономные системы использования вычислительных машин. Попробуем провести различия между «пользователем» и «заказчиком». Пользователь — это человек, который сидит у терминала и ведет диалог с вычислительной машиной. Пользователь управляет ею, он «приводит» ее в действие. Служащий трансагентства, занимающийся резервированием авиационных билетов, является пользователем. Заказчик же — это главный бухгалтер фирмы. Ему не нужно вести никакого диалога с вычислительной системой, когда она производит расчет зарплаты для сотрудников фирмы.
Если мы готовимся к диалоговому использованию системы, мы должны так писать программное обеспечение, чтобы пользователю было легко взаимодействовать с машиной. Это гораздо больше, чем просто справочная система; такая система должна быть настолько удобной для работы, чтобы человек, работающий с машиной, охотно ею пользовался и работал с полной отдачей сил. Программы должны быть написаны так, чтобы система подсказывала пользователю, что сделать, если полученные ею инструкции не очень ясны.
Последствия отказов при разных типах использования.
В некоторых системах многочасовой отказ вычислительной машины хотя и неприятен, но все же приемлем. В других же отказ вычислительной машины всего лишь на несколько минут чреват катастрофой. В последнем случае нам приходится ставить дополнительную аппаратуру. Но дополнительная аппаратура это еще полбеды. Нам приходится еще писать программы для сохранения критических данных и передачи их с одного процессора на другой. Часто это должно делаться не за минуты, а всего лишь за секунды. Это весьма сложное программное обеспечение. Программа, управляющая переключением светофоров в городе, не представляет собой ничего сложного; однако если эта программа должна всегда работать правильно, то сложность программного обеспечения возрастает по крайней мере втрое.
Диапазон сложного программного обеспечения простирается от научного центра (годовой) стоимостью 50 млн. долларов, обеспечивающий диалоговую работу 460 ученых, где 90 % всех программ выполняется один-единственный раз, до управляющей системы, в которой программное обеспечение работает по 365 дней в году, по 24 ч. в сутки, не имеет права на малейший отказ и изменяется крайне редко — один раз в год.
Фаза разработки, входящая в жизненный цикл программного обеспечения, может быть разбита на шесть отдельных этапов:
— Определение требований
— Проектирование
— Написание команд
— Компоновка
— Тестирование или верификация
— Документирование
Поскольку разработка на обозримое будущее представляет собой основную проблему в области программного обеспечения, оставшаяся часть книги в основном будет посвящена рассмотрению этих шести этапов.
Как мы уже видели, эту фазу часто называют обслуживанием. Это наиболее часто игнорируемый элемент жизненного цикла, оставляемый на попечение какой-нибудь новой, часто неизвестной заранее группы. Наша ключевая идея состоит в том, что эта часть цикла должна приниматься во внимание с самого начала работ по разработке.