Программное обеспечение и его разработка
Шрифт:
С другой стороны, что нам необходимо для утверждения спецификаций верхнего уровня? Нам может потребоваться большое число разных сведений по различным пунктам, не входящим в данный документ, но собранным в различных местах проекта. Нам могут понадобиться черновики будущих документов или детальные эскизы и описания, содержащиеся в рабочих документах, которые, конечно же, сосредоточены на более низких уровнях.
Еще раз повторяясь, можно сказать, что после достижения некоторого уровня детализации делаются попытки перенести его на документы более высокого уровня. В этом и есть ошибка. Документация высокого уровня должна быть свободна от этих подробностей. Для сопровождения спецификаций высокого уровня можно привлекать
Требования должны содержать сведения о том, что является необходимым, а спецификация проекта должна описывать, как нужно этого достигнуть. Всегда нужно помнить, однако, что каждая спецификация есть одновременно и «как», и «что» — все зависит от того, с какой стороны вы на них смотрите.
Необходимость документации совершено понятна. Столь же понятно и то, что часто не существует никакой документации — абсолютно никакой. Плохая документация — это одно, отсутствие документации — это совершенно иное. Существует столько программ без документации, что проблема кажется глобальной. Документация на программное обеспечение является более необходимой, чем документация на аппаратуру, ведь программы неосязаемы и абстрактны. Программа без документации похожа на невзорвавшуюся бомбу. В один прекрасный день она может взорваться.
Глава 6
Руководство разработкой программного обеспечения
Эта глава посвящена описанию тесно связанных между собой вопросов, возникающих на протяжении различных стадий процесса разработки. Описание построено так, что каждая проблема рассматривается в момент своего наиболее вероятного возникновения. Все эти проблемы непременно возникают, если пренебрегать некоторыми предупреждениями. Некоторые из них появляются на ранних стадиях разработки проекта, некоторые позднее. Понимание этих проблем досталось мне на многолетнем опыте, иногда весьма тяжелом. После разъяснения многие из них могут показаться очень простыми, но, однако, часто их упускают из вида.
Давайте поднимемся на несколько ступеней по служебной лестнице и предположим, что на нас возложена обязанность по управлению разработкой большого проекта. Мы определим очертания всех наших подсистем и для каждой подсистемы назначим своего компетентного руководителя. Конечно же, мы захотим следить и за ходом разработки нашего программного обеспечения. Мы слишком обеспокоены работами в других подсистемах, чтобы подробно заниматься управлением разработкой программного обеспечения; это входит в обязанности человека, которого мы самым тщательным образом выбрали в качестве руководителя разработкой программного обеспечения. В этой и следующих главах мы концентрируем свое внимание на вопросах, служащих для высшего руководства индикаторами «состояния здоровья» проекта. Мы посмотрим, как надо организовать группу программистов; как выбрать руководителя разработкой программного обеспечения; каким образом определить, разрабатывать ли обеспечение самим или заказывать его на стороне; каким образом подобрать подрядчика. Мы внимательно изучим некоторые места, в которых проекты спотыкались в прошлом, а также места, которые представляют грозную опасность и сейчас.
На что надо обращать особое внимание? На что направлены наши поиски? Что вызывает наши споры? Какие моменты наиболее показательны?
«Закон Мьюира: Как только мы захотим отделить какой-нибудь объект от других, мы обнаружим, что он связан со всем на свете». [33]
Существует только одна система — Вселенная. Все другие системы можно называть так только с натяжкой: они не замкнуты.
33
Block A. Murphy's Law Book Two (Los Angeles, Calif.: Price/Stern/ Sloan. Publishers, Inc., 1980).
Какую систему мы имеем в виду, говоря о системе здравоохранения Соединенных Штатов? О системе, очерченной на рис. 6.1
А может быть, эта система имеет очертания, ограниченные линией с точками? Задумываемся ли мы о том, что наш собеседник может представлять себе систему, о которой мы с ним разговариваем, совершенно иначе, чем мы?
Если бы я руководил более или менее крупной компанией, я стремился бы к тому, чтобы платежные ведомости печатались в срок, а при резервировании билетов на самолеты не возникало никаких ошибок. Предположим, что ведомость подготавливается недостаточно эффективно или ее подготовка затягивается. Придется мне самому исследовать возникшую проблему. Я буду изучать дела уровень за уровнем. Начну я с человека, отвечающего за ведомости, и попрошу его описать мне систему сверху вниз. Он может разбить систему на пять компонент: 1) процедуры; 2) люди; 3) вычислительные машины/системы; 4) входные данные и 5) распределение. На этой стадии у меня возникает возможность более глубоко ознакомиться с любой из этих пяти компонент. Поскольку нас интересует вычислительная сторона дела, я попрошу описать мне следующий уровень разбиения именно области вычислений. Это разбиение приведено на рис 6.2.
Можно заметить, что отдельные элементы второго уровня сложнейшим образом переплетаются между собой. Выбор покупаемых нами дисплеев (аппаратура) и то, что мы собираемся на них высвечивать, очень сильно влияет на 1) процедуры и 2) людей, а возможно, и на 4) входные данные и 5) распределение. Помните, существует только одна система — Вселенная, все остальные системы имеют прорехи! Теперь перейдем к третьему уровню (рис. 6.3). Пока мы отбросим подсистемы 1, 2, 4 и 5, в реальной же ситуации этого сделать нельзя (описывать эти подсистемы нам не позволяет размер книги). Все нами сказанное остается верным и при переходе на уровень 4 (см. также рис. 6.3).
На четвертом уровне, как и на всех других, мы можем произвольно выбирать дальнейшее разбиение системы. На этом уровне мы можем составить дополнительные системы классификации, для примера мы остановимся на схеме уровня 5 (рис. 6.4).
Нам нужно выяснить, почему платежные чеки оказываются неправильными, для этого нужно изучить программы, работающие в фазе использования. Два оставшихся раздела программного обеспечения будут нами исследоваться только в том случае, если проблемы фазы использования приведут нас назад к одному, а то и к обоим этим разделам. Перейдем к уровню 6 (рис. 6.5). Здесь мы показываем обе ветви, указывая в скобках авторов программ.
Ограниченный объем книги опять не позволяет нам привести полный список всех выполняемых отдельных программ. Мы могли бы и должны были бы продолжить составление диаграммы уровня 7, на которой надо показать модули всех программ, но опять-таки на это не хватает места. Матричная диаграмма в табл. 6.1 показывает, какого рода подробности нам необходимы. Теперь, если выяснится, что все проблемы относятся к области «чистой выплаты», мы начнем изучать и тестировать модули, влияющие на чистую выплату.