Помоги проекту - поделись книгой:
Появление больших систем программного обеспечения обусловлено снижением стоимости аппаратуры вместе с одновременным увеличением его мощности. Список систем не ограничивается приведенными в таблице, этот список все пополняется. Я знаю множество программ для министерства обороны, в которых затраты на программистскую часть превысили 50 млн. долларов. Этого уровня достигает и промышленность. В этот диапазон попадают большие системы связи фирм ATT, RCA, W.U., Satellite Business Systems. Операционные системы, сделанные для крупнейших промышленников, имеют даже большие размеры и стоят дороже.
Как мы уже видели, на авиатранспорте применяются столь же большие программы. Системы подобных размеров начинают заводить себе банки, особенно иностранные.
Одной из программ, стоившей гораздо больше 100 млн. долларов, была система наземного контроля космических кораблей типа Аполлон, созданная хьюстонским Центром пилотируемых полетов. Я был в Хьюстоне в 1970 г. сразу же после вступления на пост главного управляющего федеральным системным центром с целью проинспектировать работу 700 человек, подчинявшихся лично мне.
Они показали мне, как они управляют ходом разработки программы в миллион строк. Я был просто потрясен! «Это сущая бюрократия», — думал я, когда мне показывали планы, руководства, формы, тесты и еще множество всевозможных документов.
Вскоре после этого я посетил еще некоторые подчиненные системы. Там не было такой большой системы управления разработками — и разработки были неуправляемыми. Самым правильным был подход, применявшийся в Хьюстоне, — для управления разработкой действительно большой системы более 50 % средств нужно направлять на планирование, проверку, составление графиков, руководство и управление. Это и есть та инфраструктура, которую мы видим в других отраслях. Позже мне показали график, изображенный на рис. 4.19. Он и сейчас соответствует действительности.
Наверное, самый понятный пример эффекта, проистекающего от возрастающего масштаба работ, был мною обнаружен при изучении одного интересного и удивительного факта, когда в 1968 г. я прибыл в отделение федеральных систем для того, чтобы стать помощником его президента Боба Эванса. Около десяти человек из Хьюстонской космической группы были направлены в Лондон, в один из банков. Для чего это было нужно? Специалисты по космосу помогали Лондонскому банку налаживать обработку данных?
Или, может быть, некоторые из членов Хьюстонской группы были специалистами по банковскому делу? Вовсе нет. Причиной их командировки в Лондон был тот факт, что самыми крупными заморскими партнерами фирмы IBM являются банки. А европейские, японские и другие иностранные банки в противоположность банкам США не столь сильно скованы рамками всевозможных законов и границами государств. Для связи с тысячами своих отделений они пользуются системами, стоящими более 100 млн. долларов.
Банкам понравились люди из Хьюстона. Несмотря на то что они ровным счетом ничего не понимали в банковском деле, они имели большой опыт по реализации систем
Одним из позднейших фундаментальных открытий математики было открытие числа нуль. Оно появилось поздно, поскольку вначале его необходимость не была очевидна.
Так же обстоит дело и с понятием сложности. Сложность легко себе представить, но трудно описать. Еще мало разработано приемов для работы с понятием сложности. У нас нет метрики для измерения того, что одна работа вдвое сложнее другой. Нет прилагательных для определения степени сложности. Мы вынуждены говорить, что это «более сложное» или «очень сложное». Это, быть может, и верно, но не очень полезно, когда нам надо создать нечто «более сложное», чем что-то еще. Ведь стоимость наших работ достигает миллионов долларов, а их результаты имеют очень значительные последствия. Мы, однако, можем четко различать два «вида» сложности:
1) техническая сложность конкретного приложения.
2) логическая сложность приложения и/или системы программного обеспечения.
Техническая сложность. У меня в распоряжении две программы, по 50 тысяч команд каждая. Одна «делает» платежную ведомость, а другая «делает» вычисления, связанные с безопасностью летящей ракеты. Ракетная программа будет более сложной; в ней требуется решить некоторые сложные уравнения.
Предсказание погоды, уравнения ядерной физики, орбитальные расчеты, гравитационные эффекты, баллистика — все это требует специального математического аппарата, инженерного искусства, а также высокой научной квалификации и знаний. Эти знания нужно использовать во всех фазах разработки программного обеспечения. Получение таких знаний само по себе достаточно трудный процесс, использование же их трудно вдвойне.
Логическая сложность. Существует и другой вид сложности — логическая сложность, причем управляться с логической сложностью даже труднее, чем с математической или технической. Эта сложность проявляется в многообразии различных вариантов, выбор среди которых надо производить на каждом шаге решения. Каким образом можно проследить все возможные или подходящие нам пути, по которым проходит управление при выполнении больших программ? В программах может быть лишь несколько условных переходов, в других же программах их может оказаться огромное множество! Попробуем разобраться, почему же бывает трудно справиться с программой с большим количеством условных переходов.
Сколькими различными способами можно соединить с контактами пять проводков из семижильного жгута? Таких способов 2520.
Сколько различных порядков при ударе можно выстроить для 12 — всего лишь 12 — ребят, игроков бейсбольной команды младшей лиги? Подсчитали? 79 миллионов 833 тысячи 600! Только для 12 ребят!
Одной из самых логически сложных программ является программа диспетчеризации воздушного транспорта, применяемая в США и Великобритании. Она стоила более 100 млн. долларов и используется в 20 диспетчерских центрах США, а также в Лондоне. К настоящему времени мы имеем уже пятилетний опыт ее эксплуатации, система работает вполне удовлетворительно. Великобритания, приобретая систему, выплатила за нее и вычислительную машину IBM 9020, на которой система работает, 10 млн. долларов наперекор жесточайшей политике «Покупать только британское» (Тот факт, что иностранная держава выбрала и использует американскую систему, привел к тому, что Федеральное агентство Соединенных Штатов по авиации отказалось от своих многочисленных нападок на систему и обвинений в ее бесполезности, несовременности и т. д.).
Во время переговоров при заключении контракта на изготовление диспетчерской системы мы специально изучали 600 тысяч строк программы, подготовленной для работы на центральном вычислительном комплексе, и обнаружили в ней большое число условных переходов. Мы насчитали 39 203 таких перехода, т. е. в среднем по одному на каждые 15.3 строк текста В этой программе очень много внимания уделяется принятию различных решений, что связано с запутанной логической структурой управления, предсказания возможных конфликтных ситуаций, а также множества различных вариантов, возникающих при работе с 97 устройствами для ввода данных и запросов к системе, форматной выдаче данных на дисплеи. Сколько же вариантов возникает при выполнении этой программы? Это число равно 39 203! Это просто астрономическое число, оно примерно равно 1011 801, или десятке, за которой следует 11 800 нулей! Если бы мы могли проверять один вариант программы за одну секунду, то на тестирование всей программы в целом нам пришлось бы затратить несколько тысяч лет. Мы не можем создать специальную тестирующую систему, которая могла бы проверить нам все варианты, возникающие в окружающем нас мире.
Если кто-то начинает говорить о том, что он создал программу, в которой нет ни одной ошибки, значит, либо он говорит об
Большие системы программного обеспечения логически очень сложны. Они содержат огромное число ветвлений. В своей книге «Мифический человеко-месяц» Брукс[8] утверждает, что системное программное обеспечение в девять раз труднее разрабатывать, чем прикладное обеспечение. Основной причиной этого является логическая сложность.
Если отдельно рассмотреть прикладные программы, они окажутся не такими уж сложными. Однако при первой же попытке объединить некоторое количество прикладных программ в цельную однородную систему мы сразу же столкнемся со сложными проблемами. Рис. 4.20 взят из книги Джеймса Мартина «Организация баз данных».
К сожалению, в настоящее время вопросу изучения логической сложности уделяется недостаточное внимание. По мере внедрения вычислительной техники в различные прикладные области, связанные с проведением большого числа сложных операций и управления процессами, мы лучше сможем представить себе эту важную отрасль.
Проблемы, связанные со сложностью. Сложность всегда доставляла и до сих пор доставляет людям множество неприятностей. И никого не должно удивлять то, что она мучает нас при разработке больших программных систем, — однако это удивляет. Ведь мы склонны всегда забывать, сколько мучений мы претерпели из-за сложности, где бы она ни проявлялась.
Очень долго у людей были сложности с мостами. За одно только десятилетие с 1870 по 1880 г. только в одних Соединенных Штатах разрушалось в среднем до 40 мостов
Как сильно все сказанное о том времени напоминает ситуацию, возникшую в программировании сегодня! А ведь семидесятые годы прошлого столетия не были первыми годами бедствий. Веками мосты разрушались из-за воздействия гармонических колебаний. Чего стоили только проходы через мосты солдат, марширующих
Проблемы возникали не только с подвесными мостами. В 1944 г. двухфермовый мост через Миссисипи в Честере, шт. Иллинойс, был сброшен ветром со своих ненадежных опор. В 1905 г., когда был разрушен мост на кронштейнах через реку Св. Лаврентия в канадской провинции Квебек, было убито 87 рабочих. Физическая природа таких строений была тогда недостаточно понятна людям.
Новые явления приносят нам новые сложности. Моторы компании «Локхид Электра» (Lockheed Electra) разрушаются из-за дефектов проектирования. Самолеты DC-10 не летают!
Во второй половине семидесятых годов в здании Джона Хэнкока в Бостоне уже не было стеклянных окон. Были заменены 10 тыс. 400-фунтовых стекол.
Люди до сих пор не справились со сложностями, возникшими вместе с открытием ядерной энергии. Убытки от катастрофы, происшедшей на Острове третьей мили, продолжают расти и уже достигли 4 млрд. долларов!
После того как программа уже создана и работает, ее ясность зависит только от ее разработки и реализации. На стадии разработки нам часто доставляет неприятности неясность поставленных перед нами целей. Что должна делать программа? В каком-то смысле пять различных типов использования программ отражают атрибут ясности.
Работа вычислительной машины по типу I (коммерческие расчеты) совершенно ясна. Задачи по обработке данных в большинстве случаев уже полностью решены. Все, что нам надо сделать, это разобраться в используемых процедурах и запрограммировать их. На противоположной стороне шкалы находятся задачи по управлению процессами типа V.
Чаще всего при их программировании нам приходится сталкиваться с выполнявшими до сих пор все работы «старыми мастерами», т. е. какими-то умными, искусными, все понимающими людьми, которые способны держать в голове все параметры, варианты, возможные ловушки, несовместимости, несоответствия и разрывы. Эти люди «видят», как развиваются события, могут почувствовать, когда что-то не ладится, и «знают», что надо делать в этом случае.
Попробуйте записать все правила, алгоритмы, попробуйте повторить то, что эти люди могут проделать в своем уме, и вы столкнетесь с необходимостью уметь здраво рассуждать, распознавать сложные образы, обладать изрядной долей интуиции и «чувствовать». Все это с трудом поддается определению, и получить полезную систему можно только после нескольких неудач, напрасных разработок, после потери значительных денежных сумм.
При попытке автоматизировать нефтеочистительные заводы фирмы Exxon, расположенные в Эдмонтоне, Канада, и в Антверпене, Бельгия, фирма IBM потеряла более 10 млн. долларов. Выполняли работу две сотни моих хьюстонских сотрудников. Как-то один из разработчиков спросил инженера компании Exxon, каким образом он узнает, когда надо нажать на рычаг. «Очень просто, — ответил тот. — Я опускаю палец в струю и
При построении больших систем управления процессами, взаимодействующих со многими пользователями, реальное использование вычислительной машины можно осознать только
Прочитав это, мой читатель может возразить, что это скорее проблемы системы, а не программного обеспечения. И читатель будет прав.
Программное обеспечение наследует проблемы системы.
При разработке большой системы типа V по мере стабилизации других частей комплекса последнее, что может быть еще модифицировано, — это именно программное обеспечение. Что мы подразумеваем под «стабилизацией»? В больших системах типа V разрабатывается сразу множество различных элементов. Коммуникационные связи/ дисплей/ радиолокатор/ сонар/ телеметрия/ ракета/ спутник/ двигатели/ управление/ еще что-нибудь — что-то из этого списка будет самым новым, самым передовым в мире, может разрабатываться также какой-нибудь необычный способ объединения этих объектов. Эта новинка может преподнести вначале своей эксплуатации любой сюрприз, и нам придется приспосабливаться к реальному положению.
Основная тяжесть адаптации падает на две части нашей системы — на программное обеспечение и обслуживающий персонал. Максимум возможного мы стремимся сделать за счет программ, оставляя нагрузку на людей минимальной. Программное обеспечение действительно будет «гибким»[10],
Долгосрочное планирование и правильное использование фондов в дальнейшем могут сэкономить немалые суммы денег. Мост Джорджа Вашингтона из Нью-Йорка в Нью-Джерси был построен в 1931 г. с одним путепроводом, но все расчеты напряжений были сделаны так, что через 30 лет оказалось возможным добавить еще один уровень с шестирядной дорогой. И действительно, в 1962 г. этот уровень был достроен (см. рис. 4.21).
Первоначально второй уровень предназначался для железной дороги. Железная дорога построена не была, но структура моста без каких-либо изменений подошла для автомобильного путепровода.
В противоположность предыдущему примеру со строительством второго уровня рассмотрим пример строительства моста-близнеца рядом со старым мостом! Посмотрите, какой мост построен через залив Чезапик. (См. рис. 4.22.)
Хотя значительное число программ и не требует никакого развития,
При разработке больших программ, предназначенных для использования в течение 20 лет и более, подавляющая часть всех капиталовложений пришлась на этап продолжающейся разработки.
При разработке больших систем типа V единственной по-настоящему важной проблемой является отсутствие ясных требований. Руководитель проекта не может понять, что ему делать.
Таблица 4.11 Какие требования могут меняться
| Продукция | Структура рынка |
| Размах производства | Разделение труда |
| Заводы, их расположение | Заказчики |
| Организация | Налоговое законодательство |
| Ведущие специалисты | Законы охраны собственности |
| Число заводов | Обмен продукцией между заводами |
| Сети | Аппаратура |
| Процедуры | Следовательно, прикладные программы |
| Необходимые данные | Следовательно, база данных |
Самым первым требованием к большой программной системе должно быть обеспечение легкости внесения изменений.
Первой заботой руководителя разработки программного обеспечения должно быть резервирование средств на выпуск нескольких версий системы.
Масштаб, сложность и ясность нужно принимать во внимание и планировать с самого начала работ. Построение системы в миллион команд — это такой же триумф, как и постройка моста, часто стоимости этих объектов тоже сравнимы. Однако программное обеспечение невидимо. Никто не видит его; только некоторые посвященные могут его оценить. В некотором смысле такое положение не очень-то радует. Когда создается что-нибудь достаточно сложное, хотелось бы, чтобы плоды труда были видны. Даже сама работа программы это как бы «верхняя часть айсберга». Нет никакого способа показать огромную сложность и достигнутые результаты. Только в процессе изучения и создания можно оценить сложность и масштаб подобных работ.
Очень полезно различать
| 1. Пакеты программного обеспечения | Программное обеспечение, которое может использоваться на любой вычислительной машине, например транслятор с Кобола |
| 2. Системы с программным обеспечением различных компонент | Получающиеся в результате системы, например системы обработки слов отличаются друг от друга именно своим программным обеспечением |
| 3. Аппаратные комплексы с минимальными программными включениями | Продукция с минимумом программного обеспечения, например копировальная установка, использующая ЭВМ для управления операциями |
В разработке обеспечения как продукции есть два пункта (см. также табл. 4.12), отличающих ее от разработки программного обеспечения проектов:
1) процесс определения требований;
2) широта усилий в смысле разнообразия разрабатываемых функций.
Таблица 4.12. Различия между программным обеспечением проекта и продукцией
| Продукция | Проект | |
|---|---|---|
| Число пользователей | Сотни | Один или несколько |
| Конкуренция | После начала использования | Только за право вести разработку |
| Продолжающаяся разработка | Критична | Не так критична |
| Контроль при использовании | Очень Незначительный | Весьма важен |
Если мы заставим людей, имеющих опыт разработки программного обеспечения проектов, заняться работой по реализации программ на свободную продажу, это вряд ли приведет к успеху. Неудача нас может ожидать и в обратном случае, при привлечении к работе над проектом тех, кто раньше занимался разработкой товарных программ.
Программная продукция — это программа, которую стремятся продать на широком рынке тысячам или по крайней мере сотням пользователей. Программные проекты имеют значительно более ограниченный круг пользователей. Стандартная программа составления платежных ведомостей, стандартное обеспечение графических дисплеев, транслятор с Кобола, стандартное обеспечение бухгалтерских расчетов, пакеты генератора отчетов — все это примеры товарных программ. Примером программного проекта может служить набор программ, написанных для управления искусственным спутником Земли.
Товарное программное обеспечение разрабатывается со специальной целью удовлетворить требованиям максимально большего числа пользователей. Это оказывает влияние на весь жизненный цикл программ, но в наибольшей степени на начальный этап разработки, на определение требований к системе.
Проще всего убедиться в полезности введения такой классификации, рассмотрев крайние случаи тех и других программ, не вдаваясь в сближающие их детали. У системы «Аполлон», т. е. проекта космических исследований и полета на Луну, был всего один пользователь, при этом этот пользователь жил и работал бок о бок с разработчиком. Между ними был установлен и поддерживался тесный и эффективный канал связи. В противоположность этому обобщенный пакет составления платежных ведомостей предназначен сразу сотням пользователей, большинство из которых никогда не разговаривали и не виделись с разработчиками. Кроме того, разработчики других подобных пакетов предлагают этим потенциальным пользователям свою продукцию. Главным вопросом здесь, следовательно, является не вопрос пригодности нашей программы, а вопрос ее конкурентоспособности. Это различие является определяющим, от него зависят и удачи, и неуспех.
В табл. 4.13 представлены некоторые примеры из сферы программного обеспечения. Там есть и товарные программы, и программные проекты, там же можно найти сведения о продукции, в которой программное обеспечение является только частью общей системы. Внимательное изучение схемы не раз приводило к удивительным результатам: разработчики считали, что они заняты созданием какой-нибудь системы, а потом оказывалось, что они неправильно оценивали, точнее, неправильно понимали, какие усилия нужны будут для завершения их работ.
Таблица 4.13 Характеристики программного обеспечения проектов и программного обеспечения как продукции
| Проекты — - - — - - — - - —> | <- - — - -Продукция | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Расчет налоговых отчислений | Хьюстон | Инструментальные программы мин. обороны | Контроль авиаперевозок FAA | Бортовые навигационные системы на кораблях | «Wizard of Avis» | Сопровождение ракет | Телевизоры | Компилятор с Кобола для IBM 370 | Обработка текстов | |
| Число пользователей | 1 | 1 | 1 | десятки | сотни | сотни | тысячи | тысячи | тысячи | тысячи |
| Число разраб. организаций | 1 | 1 | 1 | 1 | неск. | 1 | 1 | 1 | 1 | 1 |
| Посредники между пользователем и разработчиком | Нет | Нет | Да | Да | Да | Да | Да | Да | Да | Да |
| Параллельная разработка | Нет | Да | Да | Да | Да | Нет | Да | Да | Нет | Да, затем Heт |
| Требования пользователя или рынка | Пользователь | Пользователь | Пользователь | Пользователь | Пользователь | Пользователь | Пользователь | Рынок | Рынок | Рынок |
| Конкуренция после построения программного обеспечения | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да | Да |
| Финансовый риск | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Нет | Да | Да |
| Сопровождение программного обеспечения | В | В | В | В | В | Н | Н Апп. — инт Аппар. прод. с прогр. обесп. | В Прогр. — инт. Товарное прогр. обесп. | В Прогр. — Инт. | |
Требования к проектам и продукции. Выработать требования к системе «Аполлон» гораздо легче, чем к системе управления процессом обработки слов. Дело заключается в том, что ошибки при определении требований исправлять в первом случае значительно легче. Руководство программой Аполлон имело тесный контакт со всеми, кто будет пользоваться программным обеспечением, и вполне способно управлять ими.
Такая тесная связь позволяла легче справляться с некоторыми не очень грубыми ошибками. Если бы о каждой незначительной ошибке или изменении приходилось сообщать сотне или более пользователям, очевидно, что работа по их извещению отняла бы много сил.
Для выработки хорошо составленных требований к разрабатываемому программному обеспечению, предназначенному для продажи многим пользователям, необходимо проводить исчерпывающее исследование их нужд и пожеланий, а затем еще выяснять конъюнктуру рынка. Нам нужно не просто удовлетворить требованиям большого числа пользователей, нам нужно выиграть соревнование с другими системами.
В случае проектов конкурентная борьба разворачивается только в момент выбора группы разработчиков. Определение требований к товарному программному обеспечению — это сложный процесс, которым длительное время вынуждены заниматься большие коллективы людей.
Размах работ при разработке проектов и товарных программ.
В большинстве проектов для построения высоконадежных или высокоскоростных систем приходится разрабатывать уникальные программы. Для многих проектов необходимо создавать специальные средства для их разработки. С другой стороны, условия создания товарных программ носят более ограниченный характер. Продукция обычно более четко очерчена, все интерфейсы, используемые для связи с другими частями программного обеспечения, детально проработаны. Если, например, мне нужно разрабатывать транслятор с Кобола или программу печати платежных ведомостей, то совершенно необязательно начинать с разработки новой операционной системы. Писать команды, образующие интерфейс с операционной системой, безусловно, необходимо, но разрабатывать саму систему нет нужды. Напротив, шансы на разработку операционной системы резко увеличиваются, если поступает задание разработать программу для штурманского дела. (См. рис. 4.23.)
Существует много процессов, позволяющих некоторую часть программного обеспечения, работающую всего в одном месте, превратить в «стандартное» программное обеспечение, годное к продаже в сотни организаций. Такой процесс иногда называется доведением программы до товарного уровня. Создание продукции на основе обычной программы походит на процесс инженерного сопровождения, имеющий место при разработке аппаратуры.
Часто рассказываемая с иронией апокрифическая история о группе из трех гениев, за один вечер работы где-то в гараже написавших программу, за разработку которой некая компания обещала потом около 300 тыс. долларов, однако весьма поверхностна. Конечный результат этих двух процессов просто невозможно сравнивать. Чтобы по-настоящему понять эту разницу, давайте предположим, что некто обращается к нам — большой компании — с работающей программой и предлагает продавать эту программу тысячам пользователей и поддерживать ее. Предположим, мы действительно верим, что на этом можно что-то заработать. Составим список того, что нам необходимо будет проделать с этой программой. Список этот, далеко не исчерпывающий, приведен ниже.
— Пересмотреть существующую документацию, если она действительно существует.
Нам необходимо пересмотреть не только конечную документацию, относящуюся к рабочей программе, но и начальную — что делает эта программа, что она не делает, ограничения, инструкции пользователям.
— Создать документацию на продукцию.
Создать рекламную литературу, кратко описывающею нашу продукцию.
—
— Пример граничных условий
| Входное значение | Предел | |
|---|---|---|
| Платежная ведомость | Недельный заработок | 9999.99 — нуль, отрицательных нет |
| Радиолокатор | Дальность | от 1000 футов до 99 432 футов |
—
Поделиться книгой: