====== 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
====	Поиск философского камня: почему мы хотим добиться рационального процесса проектирования?====
Обычный процесс программного проектирования достаточно иррационален. Программисты принимают много проектных решений, не имея ясного представления желаемого поведения системы и ограничений в реализации.
Мы никогда не найдем способ, позволяющий проектировать совершенно идеально, но мы можем подделать его. Мы можем представить нашу систему другим как если мы были бы рациональными проектировщикам, как в процессе разработки, так и в процессе сопровождения. 
====	Почему «процесс» разработки программного обеспечения всегда будет идеализацией?====
Мы никогда не увидим проект программного обеспечения, который был бы произведен «рациональным» путем. Перечислим некоторые причины. В большинстве случаев заказчик точно не знают, что они хотят и не могут рассказать все, что они знают. Помимо требований есть много других деталей, которые становятся известными только в процессе разработки. Даже если мы знаем все это, опыт показывает, что человек не может учесть все изобилие информации и деталей. Проекты могут меняться по внешним причинам. Ошибки будут всегда из-за человеческого фактора. Использование по разным причинам прошлых идей и наработок, разработанных для других проектов, также не является частью рационального проектирования. 
====	Почему же описание рационального идеализированного процесса тем не менее является полезным?====
Если мы определили идеальный процесс, но не может следовать ему полностью, мы все еще можем следовать ему настолько близко, насколько это возможно, и мы можем написать документацию, соответствующую идеальному процессу. Это то, что подразумевается под "подделкой рационального процесса проектирования". Некоторые причины такого притворства:
  - Проектировщики нуждаются в руководстве, которое поможет в распределении процесса.
  - Даже если мы не можем иметь полную информацию о системе, перед началом проектирования необходимо найти как можно больше информации.
  - Для большого количества проектов хорошо иметь стандартизованную процедуру, для передачи информации от одного проекта к другому.
  - Оценка прогресса в проекте легче осуществляется, если иметь идеальную процесс.
  - Регулярный обзор прогресса проекта посторонними имеет важное значение для хорошего управления. Если проект пытается следовать стандартному процессу, будет легче оценивать его.
====	Что описание процесса разработки должно нам говорить?====
Наиболее полезной формой описания процесса будет описание с точки зрения рабочих продуктов. Для каждой стадии процесса рассматриваются следующие вопросы:
  * Над каким продуктом мы должны работать дальше.
  * Каким критериям продукт должен удовлетворять.
  * Какого рода люди должен делать свою работу.
  * Какую информацию они должны использовать в своей работе.
==== Что такое рациональный процесс проектирования?====
Рациональный идеальный процесс проектирования программного обеспечения включает в себя следующие шаги.
  * Создание и документирование требований.
Идеальный документ с требованиями должен содержать все, что необходимо для написания программного обеспечения, который устроит потребителя, и ничего больше. В нем должны содержаться:
  - Компьютерная спецификация
  - Входные/Выходные интерфейсы
  - Описание выходных значений 
  - Временные ограничения
  - Ограничения по точности
  - Возможные изменения
  - Обработка нежелательных событий
  * Проектирование и документирование модульной структуры
Если над проектом работает не один человек, но работа должна быть разбита на модули. Определяются ответственности отдельных частей.
  * Проектирование и документирование модульных интерфейсов
Спецификация модульных интерфейсов должна быть написана для каждого модуля, содержит необходимую информацию о возможностях этого модуля и работе с ним.
  * Проектирование и документирование иерархии использования
  * Проектирование и документирование структуры внутренних модулей
Возможно определение подмодулей. 
  * Написание программ
  * Сопровождение
Переработка дизайна и создание нового развитие системы.

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