Схема проектирования разработки программного обеспечения

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

Приведем один из методов решения задачи.

1 Поймите задачу

Изучите данные.

Изучите неизвестные.

Достаточно ли данных для решения? Непротиворечивы ли они?

2 Составьте план

Чего вы должны добиваться?

Какие методы проектирования будут использоваться?

Встречалась ли вам уже такая задача?

Не знаете ли вы близкой задачи?

Можете ли вы воспользоваться ее результатом?

Можете ли вы решить более специализированную или аналогичную задачу?

Можете ли вы решить часть задачи?

3 Выполните план

Следуйте своему плану решения задачи. Проверяйте правильность каждого шага.

4 Проанализируйте решение Все ли данные вы использовали? Проверьте правильность решения. Можете ли вы воспользоваться полученным результатом или примененным методом при решении других задач?

Рассмотрим основные положения этого метода.

Поймите задачу

Худшая из ошибок, которые могут быть сделаны при решении задачи, – не вполне разобраться в ее постановке. Понять задачу – это значит понять два ее компонента: данные и неизвестное. Данные – это все элементарные факты, касающиеся задачи, и связи между фактами и неизвестным. Усвоение всех данных о сложной задаче – большая, но абсолютно неизбежная работа. При этом в первую очередь необходимо хорошо охватить «общую картину» данных без деталей, которые, однако, также запоминаются «в сторонке», чтобы их можно было легко вспомнить позже. Есть много способов добиться этого. Например, кое–кто физически разрезает спецификации на куски, которые затем расклеиваются на стене в определенном порядке. Это позволяет увидеть общую картину и при этом определить место для каждой детали.

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

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

Составьте план

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

Прежде всего, в плане нужно определить, чего вы хотите добиться. Десять человек могут иметь десять разных мнений относительно «правильного» ответа на задачу проектирования; проектировщик должен предусмотреть те конкретные аспекты решения, которые требуют наибольшего внимания. К сожалению, в большинстве проектов разработчики имеют слишком много свободы в этом отношении: каждый проектировщик принимает компромиссные решения, основываясь исключительно на собственном мнении, что приводит к несогласованности многих решений в системе. Идея целей проекта является решением этой проблемы. Суть идеи состоит в том, что на уровне всего проекта определяются общие цели, которыми следует руководствоваться во всех решениях при проектировании.

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

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

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

Выполните план

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

Проанализируйте решение

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