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

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

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

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

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

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

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

Циркуляр министерства труда только на первый взгляд считает программистов не творческими работниками; циркуляр написан весьма неопределенно, он, очевидно, написан человеком, который не понимает, что такое вычислительная машина и что делают программисты!

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

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

Процесс проектирования даже на самом нижнем уровне, на уровне кодирования, проектирования алгоритма и структуры данных, остается творческим процессом. Если кому-то нужно написать программу в 100 команд, он должен проектировать и всю программу, и ее отдельные части.

Как организовать программу, где расположить константы, где организовывать проверки – после тела функции или перед ним, – все это принимается во внимание на нижнем уровне. Каким образом должен я разделить 3000 операторов языка высокого уровня на отдельные модули? Это и есть принятие ответственного решения.

Межуровневые механизмы и уровень тривиальности

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

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

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

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

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

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

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

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

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

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

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

В области разработки программного обеспечения деталировщиков еще мало. Огромная потребность в проектировщиках приводит к тому, что всякий, кто может хоть как-нибудь вести проектирование, быстро переводится на роль главного проектировщика в каком-либо другом проекте, часто это случается чересчур быстро, что приводит в действие принцип Питера[16]16
  О принципе Питера см. Иностранная литература, № 8, 1971 год. – Прим. перев.


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

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

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

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

Вариации уровня тривиальности и межуровневых механизмов

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

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

Структурное программирование является одним из элементов, относящихся к проектированию. Оно используется для управления связями, определения структур как больших, так и маленьких программ. Существует очень большая путаница по поводу того, что является, а что не является структурным программированием. Многие путают реализацию сверху вниз (см. с.220–221) со структурным программированием. Некоторые смешивают со структурным программированием концепции главного программиста и сквозной контроль.

X. Милс, Р. Лингер и Б. Уитт написали книгу под названием «Структурное программирование»[17]17
  Richard С. Linger, Hanan D. Mills, and Bernard I. Witt «Structured Programming: Theory and Ptactice» (Reading, Mass.: Addison – Wesley, 1979).


[Закрыть], в которой использовали такое определение:

Структуризованная программа – это программа, составленная из фиксированного базового множества первичных программ.

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

Простая программа – это программа, которая:

1) имеет один вход и один выход, и

2) для каждого узла существует путь от входа до выхода, проходящий через этот узел

Это хорошее определение, поскольку оно позволяет определить базовое множество структур в отдельности от программ. (См. рис. 5.28.) Суть дела здесь заключается в том, что если программное обеспечение строится только из первичных и простых программ, то логика и сам ход процесса ее выполнения значительно проясняются благодаря структуризации. Использование таких (готовых) структур дисциплинирует разработчика программ, что в результате приводит к появлению более понятных программ, в которых, следовательно, имеется меньшее число ошибок. К тому же структуризованные программы гораздо легче читать. Сложность программы также «структуризуется».

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

Рис. 5.28. Основные конструкции структурного программирования.

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

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

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

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

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

Введение в структурное программирование

Автоматизация хранения справочного материала (газетных вырезок) газеты «Нью-Йорк таймс» стала заметной вехой на пути развития программирования, и по праву. Выполненная Т. Бейкером из отделения федеральных систем фирмы IBM под руководством X. Милса, она изменила направление развития программирования. До сих пор она часто упоминается в литературе. Было установлено несколько рекордов производительности. Были доказаны преимущества структурного программирования. Мы настаивали на использовании методов структурного программирования, и последующее обучение им 2600 наших кадровых работников основывалось на эффектных результатах работы с «Нью-Йорк таймс».

События, происшедшие за кулисами этой работы, известны не так широко. Их стоит описать, поскольку на этом примере можно увидеть много интересного для руководителей подобными работами. Контракт с «Нью-Йорк таймс» с заранее установленной суммой достался фирме IBM в 1969 г. в результате соревнования с другими фирмами. Наши люди из Гейтсбурга были встревожены тем, что плата, запрошенная фирмой IBM, была на 800 000 долларов меньше того 1 млн., который запросили другие фирмы. В то время в Центр федеральных систем прибыл мой предшественник. Это был Генри Уайт, прекрасный, очень способный руководитель. Он организовал проверку, которая показала, что фирма не уложится в предполагаемую цену. Рассчитывали, что после исправления можно будет объединить некоторые уже существующие программы поиска с уже существующими системами, а они оказались несовместимыми! Было похоже на то, что потери составят около 800 000 долларов.

Уайт обратился к X. Милсу. Милс только за год до этого поступил в фирму IBM после выдающейся карьеры в качестве математика и администратора. Он работал в «Дженерал электрик», в Американской радиокорпорации, в Математическом институте. Он был среди других технических работников в распоряжении Уайта. Именно ему Уайт и поручил работу по контракту с «Нью-Йорк таймс».

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

Группа работала в Гейтсбурге, очень часто наведываясь в Нью-Йорк. Они выполнили свою работу – 83 тыс. операторов на языке высокого уровня – превосходным образом за 22 месяца, затратив около 300 000 долларов. Ошибок в системе практически не было, она была готова в срок, система была создана и заработала! Вот так-то! Мы сэкономили около 700 000 долларов!

Когда я (я вступил в свою должность в декабре 1969 г.) выдавал Милсу, Бейкеру и другим крупную денежную премию, я обнаружил, что во всей фирме IBM никто не имеет никаких статистических данных по производительности труда! Сколько строк программы считается нормальным написать за один человеко-месяц? Никто этого не знал. Ни у кого даже не было точного определения «строки программы». Все были согласны с тем, что они заслужили премию, но во сколько раз они повысили производительность труда – в 5 раз (как считал я) или всего в 3? В результате мы решили внедрить в Центре федеральных систем систему измерений программ, которой постоянно пользовались в течение более чем 8 лет. Собирались статистики и данные по всем аспектам проектов; база данных содержит ныне колоссальное число данных по 100 проектам. Это единственное в своем роде собрание из всех, с которыми мне приходилось сталкиваться! Мы обратимся к нему позднее в этой же главе.

Мы постановили, что при разработке всех новых проектов надо пользоваться методами структурного программирования. К моему изумлению, реакция опытных программистов была крайне отрицательной! «Что понимает в программировании этот Милс?» «Работа для „Таймс“ это счастливая случайность!» «Все сделал Бейкер». «Милс и Бейкер – это не средние люди». С этим-то я согласен! Но мы настояли на своем, и это было правильное решение. Мы истратили уйму денег и сил на обучение более чем 2600 человек. Две недели занятий с 2600 людьми составляют 100 человеко-лет! Нет никаких сомнений в том, что это было правильное решение

Причиной того, что работа для «Нью-Йорк таймс» была выполнена с такой высокой производительностью, было то, что Милс и Бейкер еще в 1970–71 г. использовали множество самых передовых методов разработки программного обеспечения. Среди них:

структурное программирование,

метод главного программиста,

метод реализации сверху-вниз,

использование библиотекаря,

сквозной контроль,

формальные грамматики.

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

Преимущества структурного программирования

Структурное программирование внесло порядок в царство анархии. Руководителю работ и инспектору оно подарило надежность! Наглядность. Наглядность стала делать программное обеспечение более управляемым! Обозримым! Стал возможным сквозной контроль! Появились стандарты и возможности обмена программами. Были прояснены сложнейшие проблемы. Разработка программного обеспечения вступила в новую эру.

Приемлемость структурного программирования

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

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

Хорошее проектирование

Хорошее проектирование приводит к ясному проекту; в таком проекте имеется внутреннее единство. В своей книге «Мифический человеко-месяц» Брукс[18]18
  Brooks F. P. Jr., The Mythical Man-Month (Reading, Mass.; Addison-Wesley, 1975). Русский перёвод см. примечание на стр. 5.


[Закрыть] упоминает европейские соборы, строившиеся по нескольку веков. Наиболее эффектны из них те, в которых видна идея самого первого архитектора. К «плохим» относятся те соборы, в которые каждое столетие вносилось что-нибудь от очередного строителя. Многие языки программирования не прижились потому, что их создатели попытались объединить в них слишком много разноречивых свойств. В связи с этим Брукс упоминает язык PL/1.

С концепцией единства проектирования согласны и Милс, и Уитт, и Лингер, с ней согласны также Йенсен и Тонис[19]19
  Randall W. Jensen and Charles С. Tonies, Software Engineering (Englewood Cliffs, N. J.: Prentice Hall, Inc, 1979).


[Закрыть]. Мой опыт говорит, что автором проекта больших систем является обычно один человек. Этот человек определяет направление работ.

Как говорится, о вкусах спорить не приходится. Система диспетчеризации воздушных перевозок доводилась до рабочего состояния в течение 10 лет (совершенно завершена эта работа не будет никогда), за этот период времени заказчик провел немало разных ревизий. Одна ревизия, которую проводила группа независимых экспертов по программному обеспечению, констатировала, что проект управляющей (системной) программы выполнен «архаичными методами и неправильно». Несмотря на это, после завершения работ программа прекрасно работала. (Но скольким толкам дал пищу этот отзыв!)

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

С другой стороны, находятся такие руководители, которые уже закончили проект и теперь хотят, чтобы были написаны программы размером в 400 000 строк или около того. А после того как программы будут написаны, их надо будет отправить пользователям и заняться их сопровождением. Этим руководителям не нужна ни привлекательность, ни изобретательская деятельность. Им требуется надежность, ясность, воспроизводимость. Им нужны простые, незатейливые программы.

Проектирование это…

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

Итеративность

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

Компромиссы

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

Проектирование больших программ типа V – это многогранная деятельность

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

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

Рис. 5.29. Специальные знания, необходимые при проектировании.

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

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

Деталировка – это примитивное проектирование

У нас был один проект, который принес нам убытков на 3 млн. долларов. Это была система редактирования данных в реальном времени, которую мы делали по заказу Национального управления по аэронавтике и космическим исследованиям, причем цена была заранее установлена. X. Милс постоянно говорил мне, что проект системы отсутствует; исполнители же говорили, что работают по проекту.

Я назначил на один из дней проверку, и исполнители работ докладывали в течение 10 ч.! У них было огромное количество графиков, расчетов, бумаг и данных.

Через 10 ч. ответ был ясен! У них был проект, метод, казавшийся вполне осуществимым. Все это было сосредоточено в двухметровой куче графиков и в головах двух ведущих сотрудников. Для нас, слушателей, проект оставался недоступным. Некоторые проблески его мелькали перед нами в течение этих 10 ч. Мы убедились, что проект существует, но увидеть его мы не могли, никто из нас не мог его отчетливо сформулировать.

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

Устойчивые программы, или программы, дружественные пользователю

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

В тот момент, когда мы подключили людей к диалогу с вычислительной машиной (типы III, IV и V), задачи, стоявшие перед нами, значительно возросли. Мы должны писать теперь программы, которые могут давать людям возможность взаимодействовать – вести диалог с системой.

Я однажды работал с небольшой группой программистов – всего 7 человек, – занимавшейся созданием диалоговой программы по анализу многозначных решений. Программы писались на языке APL; их размер составлял 10 тыс. операторов языка APL – из них 9 тыс. операторов было написано для управления интерфейсом с человеком. Девять из десяти. Нам необходимо было сделать так, чтобы надежды пользователей оправдались, иначе нашей системой не стали бы пользоваться.

Если необходимо было ввести букву О, а пользователь набирал цифру 0 либо наоборот – мы не ограничивались тем, что сообщали «неверные данные на входе». Мы давали подсказки, чтобы помочь поддержать процесс активным. «Вы хотели ввести символ нуль или О?» – выдавали мы на экран.

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

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

Если отсутствует документация, доступная для всех, имеющая несколько уровней детализации, проекту грозит беда. Под несколькими уровнями детализации я подразумеваю то, что проект может быть описан за 30 мин, за 2 ч, за 8 ч, или за 16 ч. Если имеется только 30-мин. обзор или 16-ч. версия и ничего между ними, остерегайтесь. Почему?

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

Наша группа по разработке системы выпуска газет США имела два уровня проекта – 30-мин. и 16-ч. Я знал и руководителя работ, и проектировщика – соответственно Б. Уитта и Т. Бейкера. Они не знали неудач и в прошлом уже выполнили просто фантастические работы. И я доверял им! Но что случилось бы, если бы кто-нибудь из них заболел или уволился? На карту была поставлена судьба целого проекта – миллионы долларов.

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

Спецификация – это проектирование и одновременно выработка требований

Проект отвечает на вопрос КАК; требования отвечают на вопрос ЧТО.

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

Рис. 5.30. Спецификация – это требование и проект.

С одной точки зрения некоторая вещь кажется проектом; с другой – она же кажется требованием, (см. рис. 5.30.)

Если уж слово «автомобиль» может быть и требованием, и проектом, то и подавно документ в 100 страниц может быть и проектом и требованием.

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

Новые методы проектирования

В нашем распоряжении имеется чересчур много новых методов проектирования. Многие из этих методов являются в сущности методами записи, а не ведения процесса. Они достаточно ценны, поскольку любая помощь при проектировании только приветствуется. У них множество имен: метод Вернера – Орра и Джексона, метод HIPO, SADT (технология структурного анализа и проектирования), IA (информационный анализ), структурное проектирование – все они лучше, чем отсутствие какого-либо формализма при проектировании. Все они большей частью связаны с документированием и демонстрацией проекта, чем с его созданием, причем в значительной степени это относится к последним двум стадиям – структуризации и представлению, чем к первой – созданию.

Данные и процесс

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

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

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

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

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