Страница 17 из 28
Но гораздо чаще стратегические находки приходят в результате изменения способа представления данных или таблиц. Именно здесь лежит сердце программы. Покажите мне ваши блок-схемы, но спрячьте таблицы, и я останусь в неведении. Покажите мне ваши таблицы, и мне уже не надо смотреть блок-схемы, они и так очевидны.
Легко продолжить примеры могущества представлений. Я вспоминаю молодого человека, занимавшегося созданием сложного пультового интерпретатора для IBM 650. Он смог поместить его в неправдоподобно малый объем памяти, сделав интерпретатор для интерпретатора, поскольку контакты с человеком медленны и редки, а память была дорогой. Элегантный маленький транслятор с фортрана, созданный фирмой Digitek, использует очень сжатое специальное представление Для самой программы транслятора, так что внешняя память оказывается ненужной. Время, потерянное на интерпретацию этого представления, окупается в десятикратном размере благодаря исключению ввода/вывода.
(Целый ряд таких примеров можно найти в упражнениях к шестой главе книги Брукса и Айверсона "Автоматическая обработка данных')", а также в упражнениях, предлагаемых Кнутом2).)
Лучшее, что может зачастую сделать программист, оказавшийся в затруднительном положении из-за нехватки памяти,- это отвлечься от своей программы, а потом вернуться назад и пересмотреть свои данные. Представление данных - это сущность программирования
X. ДОКУМЕНТАЦИОННАЯ ГИПОТЕЗА
Гипотеза: "В ворохе бумаги лишь небольшое количество документов становится критическими осями, вокруг которых вращается руководство каждым проектом. Они-то и являются личным инструментом руководителя".
Три фактора - технология, внешняя обстановка и традиции ремесла определяют содержание документов, которые должны появиться в проекте. Новому руководителю, не привыкшему еще к своей роли, эти документы представляются абсолютной бессмыслицей, ненужной помехой, девятым валом, грозящим его захлестнуть. И действительно, большая часть их именно такова.
Однако мало-помалу он начинает осознавать, что некоторая небольшая часть этих документов воплощает в себе существенную часть его работы как руководителя. Подготовка каждого документа позволяет сосредоточить все мысли и выкристаллизовать основные идеи из обсуждений, которые в противном случае длились бы бесконечно. Их ведение становится для руководителя механизмом контроля и предупреждения. Сам по себе документ служит перечнем точек проверки, показателем положения дел и базой данных для отчетности.
Для того чтобы ознакомиться с ролью документов в проектах программного обеспечения, рассмотрим сначала конкретные документы, используемые в других областях, и выясним, возможно ли обобщение этого опыта.
Документы для разработки ЭВМ
Допустим, что создается вычислительная машина. Каковы самые важные документы?
Цели работы. Здесь определяются требования к новой машине, цели ее создания, устанавливаются ограничения и приоритеты.
Спецификации. Это система команд машины плюс спецификации производительности, С этого документа начинается новый продукт, хотя в законченном виде он появляется последний!.
График работ.
Бюджет. Один из самых полезных для руководителя документов, его функции далеко не исчерпываются установлением ограничений. Существование бюджета стимулирует технические решения, которые в противном случае могли быть и не приняты, и, что еще важнее, способствует решению вопросов общей политики.
Схема организации.
Размещение рабочих мест.
Предсказание, оценка, цены. Они находятся в циклической взаимосвязи, которая определяет успех или неудачу проекта (рис. 10.1). Чтобы сделать предсказание относп-1ельно рынка, необходимы спецификации производительности и установленные цены. Для того чтобы установить оценку производ ственных затрат, предсказания объединяются с расчетом компонент проекта и определяют долю труда па создание каждой единицы, а также фиксированные затраты. Эти затраты, в свою очередь, определяют цены.
Если эти цены ниже установленных, начинает раскручиваться спираль успеха. Предсказания растут, затраты на единицу продукции падают, а цены падают еще ниже.
Если же цены оказываются выше установленных, то раскручивается спираль неудачи, и чтобы разорвать ее, нужно приложить немало сил. Нужно повысить производительность, разработать новые приложения, соответствующие более широким предсказаниям. Затраты следует уменьшить, чтобы дать более низкие оценки. Напряженность этого цикла создает своего рода дисциплину, зачастую вызывающую улучшение работы представителя рынка и инженера.
Это может быть также причиной смешного непостоянства. Я помню машину, в которой счетчик команд то появлялся в памяти, то исчезал, и так каждые шесть месяцев в течение трехлетнего цикла ее разработки. На одном этапе необходима была чуть более высокая производительность, тогда счетчик команд реализовывался на транзисторах. На следующем этапе вставала задача уменьшения стоимости, и этот счетчик реализовывался как ячейка памяти. .В другом проекте лучший технический руководитель из всех, которых я когда-либо встречал, очень часто выступал в роли гигантского маховика: его инерция ослабляла колебания, идущие и от рынка и от руководства.
Документы для факультета университета
Несмотря на громадные различия в целях и роде деятельности, приблизительно то же число тех же документов входит в критический набор декана факультета университета. Почти каждое решение декана, ученого совета или заведующего кафедрой выражается в составлении или изменении следующих документов.
Цели работы.
Программы курсов.
Квалификационные требования.
Предложения по НИР, переходящие в планы при получении фондов.
Расписание занятий и штатное расписание.
Бюджет.
Рабочие места.
Загрузка профессорско-преподавательского состава и ассистентов.
Отметим, что вышеперечисленные пункты очень похожи на те, что уже рассматривались в проекте разработки вычислительной машины: спецификации продукта, распределение времени, распределение средств, распределение места и распределение людей. Отсутствуют только документы относительно стоимости. Такое сходство не случайно - любая задача административного руководства состоит из вопросов: что, когда, сколько, где и кто?
Документы для проекта программного обеспечения
Во многих проектах программного обеспечения люди начинают с проведения встреч для обсуждения его структуры, а затем приступают к написанию программ. Независимо от того, каковы размеры проекта, руководитель должен немедленно начинать формализацию даже мини-документов, чтобы они могли служить ему базой данных. В конце концов оказывается, что ему нужны те? же документы, что и другим руководителям.
Что: цели работы. Здесь определяются требования к новой машине, цели ее создания, устанавливаются ограничения и приоритеты.
Что: спецификации продукта. Они начинаются как предложения, а в конце уже выступают как руководство и внутренняя документация. Их важнейшей частью являются спецификации быстродействия и объема памяти.
Когда: график работ.
Сколько: бюджет.
Где: рабочие места.
Кто: схема организации. Это переплетается со спецификацией сопряжении, как предсказывает закон Конвея: "Организации, разрабатывающие системы, стремятся к созданию систем, которые являются копией структур связи в самих организациях." Конвей ') придерживается точки зрения, что схема организации первоначально будет отражать первый проект системы, который почти наверняка будет плохим. Если проект системы открыт для изменений, то организация тоже должна быть к ним готова,
Зачем нужны формальные документы?
Во-первых, очень важно записывать решения. При записи выявляются всевозможные огрехи и несоответствия. Процесс записи требует принятия сотен мини-решений, а ведь именно их наличие и отличает ясную, четкую политику от смутной и неопределенной.
Во-вторых, с помощью документов решения будут сообщаться другим. Руководителя будет постоянно удивлять, что установки, предлагаемые им для общего сведения, тем не менее неизвестны некоторым членам его группы. Поскольку его основная работа сводится к тому, чтобы сохранять направление движения, его главная повседневная задача заключается не в принятии решений, а в установлении связей, и документы будут огромной поддержкой в этой работе.