Текст книги "Программное обеспечение и его разработка"

Автор книги: Джозеф Фокс

сообщить о нарушении

Текущая страница: 15 (всего у книги 21 страниц)

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

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

Медленно развивающиеся процессы следует тестировать с помощью длительных прогонов (24 ч.).

Документирование

Люди не очень-то любят составлять документацию на созданную ими продукцию. В то же время документация – это самое важное из того, что они должны сделать! Некий превосходный программист спроектировал и написал программу определения орбитальных характеристик спутника. Он первым закончил программирование, все работало правильно, память попусту не тратилась. Программа была написана на Фортране и занимала около 4 страниц плотного фортрановского текста. Он знал свою программу вдоль и поперек. Через 3 мес. его попросили добавить к своей программе несколько функций. Он достал документацию и принялся ее изучать. Три или четыре дня он пытался понять, что же происходит в его программе! А ведь он ее сам написал! Сколько бы сил он потратил, если бы это была чужая программа! А теперь представьте, что документации не было.

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

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

Документация нам нужна для того, чтобы:

1) напомнить тем, кто создал эту программу, о том, как она устроена;

2) показать тем, кто придет после нас, как устроена программа, каков ее алгоритм.

Самодокументирование

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

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

1) хорошо прокомментированный текст программы;

2) схемы, иллюстрирующие проект, и словесное их описание;

3) структурированные словесные описания или схемы процессов, причем первое более предпочтительно;

4) описания данных.

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

Структурированное словесное описание

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

PROCEDURE: PWARN $ display warning message

INPUTS:

LOTMP – time to retry after overtemp condition

LEMI – time to retry after EMI condition

LACT – printer queue overflow flag

OUTPUTS:

none

IF LACT set THEN

IF NOR less than TQR (space unavailable) THEN

clear LACT

set LCODE to 134

call procedure POPMG to display operator message

ENDIF

ENDIF

DO-WHILE LACTX is 0 thru 1

IF EMI is set and CSRTC is greater than or equal to LEMI(LACTX) THEN

set LCODE to 321

call procedure POPMG to display warning message

store the new retry time in LEMI

increment retry counter LRCTR

IF LRCTR greater than or equal 3 THEN

clear the FM! flan

ENDIF

ENDIF

IF OVRTMP is set and CSRTC greater than or equal LOTMP(LACTX) THEN

set LCODE to 320

call procedure POPMG to display warning message

store new retry time in LOTMP

increment retry counter LRCTR

IF LRCTR greater than or equal to 3 THEN

clear OVRTMP flag

ENDIF

ENDIF

END-WHILE

END PROCEDURE-OUTPUT INTERRUPT

Рис. 5.52. Структурированное описание на языке проектирования программ.

На рис. 5.52 приведено структурированное словесное описание, для которого использован язык проектирования программ PDL. Это описание эквивалентно нескольким блок-схемам, которые изображены на рис. 5.53. Словесное описание лучше блок-схем по следующим причинам:

1) оно располагается на одной странице, и его общая структура легко обозрима;

2) оно содержит больше информации, чем блок-схемы.

На рис. 5.54 приведено другое описание с гораздо большим числом комментариев.

Рис. 5.53. Блок-схемы.

PROC SESSION MANAGEMENT * THIS PROCEDURE MANAGES THE

TERMINAL INTERACTION WITH THE USER. LEGAL USER

COMMANDS ARE MOVE AND DELETE *

USE SESSION DATA

DO * PROCESS USER COMMANDS *

GET INPUT (COMMAND) * NEXT USER INPUT *

RUN INPUTCHECK (COMMAND, ERROR)

IF

ERROR = TRUE

THEN

PUT OUTPUT (ERROR)

ELSE * NO ERROR – PROCEED WITH PROCESSING *

IF * DETERMINE TYPE COMMAND *

COMMAND = MOVE

THEN * PROCESS MOVE COMMAND *

INCLUDE MOVE PROCESSING

ELSE * PROCESS DELETE COMMAND *

INCLUDE DELETE PROCESSING

Fl

Fl GET INPUT (SESSION ~ ON)

WHILE * KEEP PROCESSING INPUT COMMANDS AS LONG

AS SESSION ON INDICATOR IS ON (TRUE) *

SESSION ON = TRUE

OD

CORP

DATA SESSION DATA

*ABSTRACT DATA TYPES & COMMENTS *

ATAD

Рис. 5.54. Структурированное описание.

Служебные слова CORP, OD, FI и ATAD представляют собой «закрывающие скобки» для слов PROC, DO, IF и DATA. Если правила ясны, то документы такого типа читаются очень легко.

Строки типа «IF * ОПРЕДЕЛЕНИЕ ТИПА ПРИКАЗА *» необходимо еще будет переводить на язык, с которого можно осуществлять трансляцию, но уже на этом уровне совершенно ясно, что нужно делать. В совокупности с хорошим общим описанием проекта такого рода документация должна быть вполне достаточна для продолжающейся разработки. Документы этого уровня можно обрабатывать с помощью машин, но транслировать их в рабочую программу еще невозможно.

Документация для других целей

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

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

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

– Руководителям пользователей необходима документация нескольких разных уровней. Что система делает? Чего она не умеет делать? Что возможно? Легко? Трудно?

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

– Руководство пользователей должно иметь возможность знакомиться и изучать планы реализации или ввода в эксплуатацию.

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

Отслеживание связей

Если взглянуть на заднюю панель любой очень большой вычислительной машины, станет очевидно, что нам совершенно необходима схема или хотя бы список, содержащий сведения о каждом проводке из точки XYZ в точку QLR. Это же относится и к программному обеспечению. Рассматривая каждый модуль как отдельную схему, можно сообразить, что нам потребуется отслеживать, кто, что и для кого делает. Но визуально представить себе программу труднее чем электронное устройство. Что такое модуль? В лучшем случае это наименьшая отдельно транслируемая часть программы, но такое толкование крайне изменчиво и в большой степени зависит от авторов. Один модуль может выполнять несколько функций. Для управления нашей большой программной системой нам нужно иметь таблицу привязки функций к модулям, и наоборот. Часто оказывается полезной схема вроде представленной в табл. 5.5 (см. также рис. 5.55)

Изучим теперь каждый столбец в табл. 5.5 и посмотрим, о чем же они нам рассказывают:

Столбец 1. Описание функции. Насколько это возможно, оно должно говорить само за себя.

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

Столбец 3. Автор программы.

Таблица 5.5.

	848А	Дэниэлс	848А	437 849 Печати	849 ОС Планировщик
	852	Шварц	849	Нет	Возврат	831
	857	Трэверс	839	858	858	852
	1612	Уард	442 857	894 1631	1614	1610
	1614	Уард	1612	Нет	Возврат	1612

Столбец 4. Какие модули или устройства формируют данные, используемые в данном модуле; имеются в виду непосредственные источники, а не вся их совокупность.

Столбец 5. Какие модули или устройства получают данные от данного модуля.

Столбец 6. Каким модулям может передаваться управление из данного модуля.

Столбец 7. Каким модулем вызывается данный.

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

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

Избыток документации

Документация должна в точности соответствовать тем целям, для которых создавалось программное обеспечение. Если программы будут работать на 500 машинах, на борту каждого корабля ВМФ США, их надо документировать более тщательно, чем программы, используемые лишь однажды и затем выбрасываемые. Документацию для этих последних программ можно составлять на оборотной стороне конверта.

Если пользователей у программы нет, составлять пользовательскую документацию не следует. Звучит это довольна глупо, но почему-то часто все-таки случается. В «Стандартах» отмечена необходимость пользовательской документации, т. е. документов, в которых говорится о том-то и том-то, поэтому руководство требует, чтобы эти документы составлялись. И вот создается двухметровая кипа документов, ни один из которых ни разу не будет использован.

Исключение блок-схем

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

История проекта

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

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

«Как» – это «что». Требование – это проект – уровни детализации

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

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

Рис. 5.56. Уровни документации, применяемые в системе Министерства обороны США.

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

Такие иерархии документов существуют во всех технических отраслях. Министерство обороны установило весьма формализованные правила на составления спецификаций. В общих чертах схема таких спецификаций представлена на рис. 5.56.

По мере продвижения дел в нашем проекте наступает момент, когда мы получаем возможность написать спецификацию системы. Уровень детализации, с которым надо создавать эту спецификацию, весьма проблематичен. Какую же степень подробности нужно считать достаточной?

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

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

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

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

Реальная ситуация

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

Глава 6
Руководство разработкой программного обеспечения

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

Давайте поднимемся на несколько ступеней по служебной лестнице и предположим, что на нас возложена обязанность по управлению разработкой большого проекта. Мы определим очертания всех наших подсистем и для каждой подсистемы назначим своего компетентного руководителя. Конечно же, мы захотим следить и за ходом разработки нашего программного обеспечения. Мы слишком обеспокоены работами в других подсистемах, чтобы подробно заниматься управлением разработкой программного обеспечения; это входит в обязанности человека, которого мы самым тщательным образом выбрали в качестве руководителя разработкой программного обеспечения. В этой и следующих главах мы концентрируем свое внимание на вопросах, служащих для высшего руководства индикаторами «состояния здоровья» проекта. Мы посмотрим, как надо организовать группу программистов; как выбрать руководителя разработкой программного обеспечения; каким образом определить, разрабатывать ли обеспечение самим или заказывать его на стороне; каким образом подобрать подрядчика. Мы внимательно изучим некоторые места, в которых проекты спотыкались в прошлом, а также места, которые представляют грозную опасность и сейчас.

На что надо обращать особое внимание? На что направлены наши поиски? Что вызывает наши споры? Какие моменты наиболее показательны?

Системы, подсистемы и программное обеспечение

«Закон Мьюира: Как только мы захотим отделить какой-нибудь объект от других, мы обнаружим, что он связан со всем на свете».[33]33
  Block A. Murphy's Law Book Two (Los Angeles, Calif.: Price/Stern/ Sloan. Publishers, Inc., 1980).


[Закрыть]

Общесистемная незамкнутость

Существует только одна система – Вселенная. Все другие системы можно называть так только с натяжкой: они не замкнуты.

Какую систему мы имеем в виду, говоря о системе здравоохранения Соединенных Штатов? О системе, очерченной на рис. 6.1 сплошной линией? Или пунктирной линией?

Рис. 6.1. Определение системы.

А может быть, эта система имеет очертания, ограниченные линией с точками? Задумываемся ли мы о том, что наш собеседник может представлять себе систему, о которой мы с ним разговариваем, совершенно иначе, чем мы?

Взгляд сверху вниз

Если бы я руководил более или менее крупной компанией, я стремился бы к тому, чтобы платежные ведомости печатались в срок, а при резервировании билетов на самолеты не возникало никаких ошибок. Предположим, что ведомость подготавливается недостаточно эффективно или ее подготовка затягивается. Придется мне самому исследовать возникшую проблему. Я буду изучать дела уровень за уровнем. Начну я с человека, отвечающего за ведомости, и попрошу его описать мне систему сверху вниз. Он может разбить систему на пять компонент: 1) процедуры; 2) люди; 3) вычислительные машины/системы; 4) входные данные и 5) распределение. На этой стадии у меня возникает возможность более глубоко ознакомиться с любой из этих пяти компонент. Поскольку нас интересует вычислительная сторона дела, я попрошу описать мне следующий уровень разбиения именно области вычислений. Это разбиение приведено на рис 6.2.

Рис 6.2 Деление системы на подсистемы.

Можно заметить, что отдельные элементы второго уровня сложнейшим образом переплетаются между собой. Выбор покупаемых нами дисплеев (аппаратура) и то, что мы собираемся на них высвечивать, очень сильно влияет на 1) процедуры и 2) людей, а возможно, и на 4) входные данные и 5) распределение. Помните, существует только одна система – Вселенная, все остальные системы имеют прорехи! Теперь перейдем к третьему уровню (рис. 6.3). Пока мы отбросим подсистемы 1, 2, 4 и 5, в реальной же ситуации этого сделать нельзя (описывать эти подсистемы нам не позволяет размер книги). Все нами сказанное остается верным и при переходе на уровень 4 (см. также рис. 6.3).

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

Рис. 6.3. Следующие уровни подсистем

Рис. 6.4. Подсистема программного обеспечения

Рис. 6.5. Авторы программ

Нам нужно выяснить, почему платежные чеки оказываются неправильными, для этого нужно изучить программы, работающие в фазе использования. Два оставшихся раздела программного обеспечения будут нами исследоваться только в том случае, если проблемы фазы использования приведут нас назад к одному, а то и к обоим этим разделам. Перейдем к уровню 6 (рис. 6.5). Здесь мы показываем обе ветви, указывая в скобках авторов программ.

Ограниченный объем книги опять не позволяет нам привести полный список всех выполняемых отдельных программ. Мы могли бы и должны были бы продолжить составление диаграммы уровня 7, на которой надо показать модули всех программ, но опять-таки на это не хватает места. Матричная диаграмма в табл. 6.1 показывает, какого рода подробности нам необходимы. Теперь, если выяснится, что все проблемы относятся к области «чистой выплаты», мы начнем изучать и тестировать модули, влияющие на чистую выплату.

Таблица 6.1. Программы, выполняемые для печати платежных ведомостей

Программа выписки чеков	8402 Стп[34]34   СТП – строки текста программы на исходном языке. [Закрыть]	Джонсон А. Д., отдел 4
Печать квитанций	462 Стп	Шварц М. Д., отдел 5
Программа	892 Стп	Дэниэлс Р. М., отдел 11
Удержания из заработной платы	44 °Стп	Абадан Д. Р., отдел 442
Расчет даты	414 Стп	Уитерс М. Р., уволился
Отчет по налогам штата	317 Стп	Джонсон А. Д., отдел 4
Расчет профсоюзных взносов	219 Стп	Трэверс Д., отдел 41
Печать профсоюзных взносов	44 Стп	Трэверс Д., отдел 41

Мы достигли достаточно точного и подробного видения проблемы. Ограничимся рассмотрением уровня 6, поскольку он более удобен для записи и чтения, хотя на практике лучше работать с более подробным уровнем 7. Мы хотим отметить все, что выполняется во время использования. Нам нужно для этого перечислить все программы, их размеры и их авторов. Результаты сведены в табл. 6.1.

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

Мы не ждем, что А. Д. Джонсон, автор программы выписки чеков, будет понимать, каким образом СУБД выполняет возложенные на нее обязанности. Мы можем лишь требовать от него, чтобы он знал, что может делать СУБД, как обратиться к ней с требованием выполнить работу, как проверить, что работа выполнена.

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

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

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

Различные подсистемы обработки данных в одной системе

Система состоит из множества подсистем – одна из них обычно есть вычислительная система, например система наземного контроля. Но и во всех других подсистемах тоже могут быть и вычислительные машины, и программное обеспечение! (См. рис. 6.6.) Вычислительные машины и программное обеспечение могут входить в состав любой подсистемы как ее часть. Спутниковая подсистема может иметь в своем составе сразу несколько вычислительных машин, на каждой из которых имеется свой комплект программного обеспечения (см. рис. 6.7).

Один простой вопрос может сбить с толку всю организацию: «Кто должен отвечать за программное обеспечение?». Разумеется, для программного обеспечения наземного контроля необходим компетентный, очень квалифицированный руководитель разработки программного обеспечения проекта. Должен ли он отвечать и за то обеспечение, которое работает на самом спутнике? Возможно. А возможно, и нет.

Рис. 6.6. Спутниковая система связи

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

Отделение программного обеспечения от аппаратуры

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

Рис. 6.7. Спутниковая подсистема

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

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

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

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

В некоторых системах может быть сразу несколько узких мест в разных подсистемах. Эти узкие места могут различаться тем, что одни из них связаны с аппаратными ограничениями, а другие возникли из-за чисто программных причин. «Балансировка системы» состоит в том, чтобы избегать ситуаций, когда одна подсистема оказывается намного слабее остальных. Мы уже говорили, что хорошее программное обеспечение может заставить хорошо работать плохую аппаратуру; верно и обратное утверждение. На с.168 приведен пример обработки запросов, которая может проводиться аппаратурой несколькими разными способами. При этом внешние характеристики системы определяются программным обеспечением.

Перегрузка аппаратной подсистемы, которую можно принять за неполадку с программным обеспечением

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

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

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

Стоимость и график разработки предсказать невозможно

Термин «разработка» используется настолько широко, мы так часто ею заняты, что иногда вводим себя в заблуждение и начинаем думать, что полностью владеем этим процессом. Всякий сразу согласится с тем, что затраты и результаты исследований предвидеть нельзя. И каждый сразу же согласится с тем, что производство даже очень сложной продукции можно и контролировать и предсказывать. Ну а что же такое разработка? В словаре говорится, что разработка это 1) «постепенное развертывание» и 2) «воплощение в жизнь». Разработка не относится к изученным и просчитанным видам человеческой деятельности – будь то в программировании или в других областях. Ни в одной отрасли техники невозможно предсказать время и суммы, необходимые для разработки новых вещей. Мы можем предсказывать производство, но производство имеет циклический характер по самому своему определению, в производстве есть процесс обучения, и, если следовать ему, как мы знаем, можно добиться того, что последний экземпляр окажется дешевле первого. Создавая объемистую книгу, посвященную изучению живых организмов и организаций, Дж. Г. Милер в «Живых системах»[35]35
  James Grier Miller, «Living Systems» (New York: Me Graw-Hill Book Co., 1978).


[Закрыть] цитировал исследования Джоан Вудворд, проводившиеся в Англии, и сразу комментировал их.