Differences

This shows you the differences between two versions of the page.

--- mdd:fake_rational [2016/12/25 02:25] – andreevaelena
+++ mdd:fake_rational [2026/08/29 07:59] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== 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
+==== Поиск философского камня: почему мы хотим добиться рационального процесса проектирования? ====
+Обычный процесс программного проектирования достаточно иррационален. Программисты принимают много проектных решений, не имея ясного представления желаемого поведения системы и ограничений в реализации.
+Мы никогда не найдем способ, позволяющий проектировать совершенно идеально, но мы можем подделать его. Мы можем представить нашу систему другим как если мы были бы рациональными проектировщикам, как в процессе разработки, так и в процессе сопровождения.
+==== Почему «процесс» разработки программного обеспечения всегда будет идеализацией? ====
+Мы никогда не увидим проект программного обеспечения, который был бы произведен «рациональным» путем. Перечислим некоторые причины. В большинстве случаев заказчик точно не знают, что они хотят и не могут рассказать все, что они знают. Помимо требований есть много других деталей, которые становятся известными только в процессе разработки. Даже если мы знаем все это, опыт показывает, что человек не может учесть все изобилие информации и деталей. Проекты могут меняться по внешним причинам. Ошибки будут всегда из-за человеческого фактора. Использование по разным причинам прошлых идей и наработок, разработанных для других проектов, также не является частью рационального проектирования.
+==== Почему же описание рационального идеализированного процесса тем не менее является полезным? ====
+Если мы определили идеальный процесс, но не может следовать ему полностью, мы все еще можем следовать ему настолько близко, насколько это возможно, и мы можем написать документацию, соответствующую идеальному процессу. Это то, что подразумевается под “подделкой рационального процесса проектирования”. Некоторые причины такого притворства:
+  - Проектировщики нуждаются в руководстве, которое поможет в распределении процесса.
+  - Даже если мы не можем иметь полную информацию о системе, перед началом проектирования необходимо найти как можно больше информации.
+  - Для большого количества проектов хорошо иметь стандартизованную процедуру, для передачи информации от одного проекта к другому.
+  - Оценка прогресса в проекте легче осуществляется, если иметь идеальную процесс.
+  - Регулярный обзор прогресса проекта посторонними имеет важное значение для хорошего управления. Если проект пытается следовать стандартному процессу, будет легче оценивать его.
+==== Что описание процесса разработки должно нам говорить? ====
+Наиболее полезной формой описания процесса будет описание с точки зрения рабочих продуктов. Для каждой стадии процесса рассматриваются следующие вопросы:
+  * Над каким продуктом мы должны работать дальше.
+  * Каким критериям продукт должен удовлетворять.
+  * Какого рода люди должен делать свою работу.
+  * Какую информацию они должны использовать в своей работе.
+==== Что такое рациональный процесс проектирования? ====
+Рациональный идеальный процесс проектирования программного обеспечения включает в себя следующие шаги.
+  * Создание и документирование требований.
+Идеальный документ с требованиями должен содержать все, что необходимо для написания программного обеспечения, который устроит потребителя, и ничего больше. В нем должны содержаться:
+  - Компьютерная спецификация
+  - Входные/Выходные интерфейсы
+  - Описание выходных значений
+  - Временные ограничения
+  - Ограничения по точности
+  - Возможные изменения
+  - Обработка нежелательных событий
+  * Проектирование и документирование модульной структуры
+Если над проектом работает не один человек, но работа должна быть разбита на модули. Определяются ответственности отдельных частей.
+  * Проектирование и документирование модульных интерфейсов
+Спецификация модульных интерфейсов должна быть написана для каждого модуля, содержит необходимую информацию о возможностях этого модуля и работе с ним.
+  * Проектирование и документирование иерархии использования
+  * Проектирование и документирование структуры внутренних модулей
+Возможно определение подмодулей.
+  * Написание программ
+  * Сопровождение
+Переработка дизайна и создание нового развитие системы.
+==== Какова роль документации в этом процессе? ====
+Документация играет важную роль в процессе проектирования. Но так как многие программисты воспринимают ее как бюрократическое зло, то полученная документация не является полезной, она не полна и не аккуратна. Слабая организация документации, повторения, использование множества слов вместо точной формулировки, диаграммы или формулы, отсутствие точных определений терминов, используемых при проектировании, близорукость в написании документации делают ее невозможной для эффективного использования. Чтобы избежать таких ошибок необходимо организовать процесс документации, структурировать каждый документ, составлять словарь используемых терминов и многое другое.
+==== Подделка идеального процесса ====
+Процесс подделывается путем создания документации, которая получилась бы, если бы мы проектировали идеально. Если мы находим ошибки, они должны быть исправлены и соответствующие изменения записываются в документ. Документация - наша среда проектирования и никакие проектные решения не считаются принятыми, пока их включение в документы не будет утверждено на всех уровнях. Независимо от того, как часто мы делаем ошибки на нашем пути, окончательна документация будет рациональной и точной.
+Если документация была проведена аккуратно, она будет полезна в течении долгого времени. Обратно, если документация будет широко использоваться, стоит делать её правильно.
+==== Заключение ====
+Очень сложно рационально проектировать, даже подделывать этот процесс не так легко. Но зато в результате получаем продукт, который может быть понят, может сопровождаться и повторно использоваться.