A rational design process: How and why to fake it

Оригинал: Parnas D.L., Clements P.C. (1985) A rational design process: How and why to fake it. In: Ehrig H., Floyd C., Nivat M., Thatcher J. (eds) Formal Methods and Software Development. TAPSOFT 1985. Lecture Notes in Computer Science, vol 186. Springer, Berlin, Heidelberg

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

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

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

1. Проектировщики нуждаются в руководстве, которое поможет в распределении процесса.
2. Даже если мы не можем иметь полную информацию о системе, перед началом проектирования необходимо найти как можно больше информации.
3. Для большого количества проектов хорошо иметь стандартизованную процедуру, для передачи информации от одного проекта к другому.
4. Оценка прогресса в проекте легче осуществляется, если иметь идеальную процесс.
5. Регулярный обзор прогресса проекта посторонними имеет важное значение для хорошего управления. Если проект пытается следовать стандартному процессу, будет легче оценивать его.

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

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

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

• Создание и документирование требований.

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

1. Компьютерная спецификация
2. Входные/Выходные интерфейсы
3. Описание выходных значений
4. Временные ограничения
5. Ограничения по точности
6. Возможные изменения
7. Обработка нежелательных событий

• Проектирование и документирование модульной структуры

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

• Проектирование и документирование модульных интерфейсов

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

• Проектирование и документирование иерархии использования
• Проектирование и документирование структуры внутренних модулей

Возможно определение подмодулей.

• Написание программ
• Сопровождение

Переработка дизайна и создание нового развитие системы.

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

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

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