Джозеф Фокс - Программное обеспечение и его разработка

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

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

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

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

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

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

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

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

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

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

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

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

Как и всякая новая человеческая деятельность, новые методы проектирования оказываются тоже очень трудными для введения. Изменениям сопротивляются; правила раздражают; строгости кажутся бесполезными. Но это бывает только в начале. Как и многие другие полезные новые методы, эти методы в конце концов признаются «единственно возможными», а на все старые при этом начинают смотреть с изумлением и весьма критически.

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