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