|
|
Процесс развития программного обеспечения - это итеративный и
расширяющийся процесс. По мере развития каждая стадия повторяется
многократно, и при всяком возврате на некоторую стадию процесса уточняется
конечный продукт, получаемый на этой стадии. В общем случае процесс
не имеет ни начала, ни конца, поскольку, проектируя и реализуя систему,
вы начинаете, используя как базу другие проекты, библиотеки и прикладные
системы, в конце работы после вас остается описание проекта и программа,
которые другие могут уточнять, модифицировать, расширять и переносить.
Естественно конкретный проект имеет определенное начало и конец, и
важно (хотя часто удивительно трудно) четко и строго ограничить время
и область действия проекта. Но заявление, что вы начинаете с "чистого
листа", может привести к серьезным проблемам для вас, также как и позиция,
что после передачи окончательной версии - хоть потоп, вызовет
серьезные проблемы для ваших последователей (или для вас в новой
роли).
Из этого вытекает, что следующие разделы можно читать в любом
порядке, поскольку вопросы проектирования и реализации могут в
реальном проекте переплетаться почти произвольно. Именно, "проект"
почти всегда подвергается перепроектированию на основе предыдущего
проекта, определенного опыта реализации, ограничений, накладываемых
сроками, мастерством работников, вопросами совместимости и т.п.
Здесь основная трудность для менеджера или разработчика или
программиста в том, чтобы создать такой порядок в этом процессе,
который не препятствует усовершенствованиям и не запрещает повторные
проходы, необходимые для успешного развития.
У процесса развития три стадии:
Не забудьте об итеративной природе этих процессов (неспроста стадии не были пронумерованы), и заметьте, что никакие важные аспекты процесса развития программы не выделяются в отдельные стадии, поскольку они должны допускать:
Сопровождение программного обеспечения рассматривается просто как
еще несколько проходов по стадиям процесса развития (см. также
$$11.3.6).
Очень важно, чтобы анализ, проектирование и реализация не были
слишком оторваны друг от друга, и чтобы люди, принимающие в них
участие, были одного уровня квалификации для налаживания эффективных
контактов.
В больших проектах слишком часто бывает иначе. В идеале, в процессе
развития проекта работники должны сами переходить с одной стадии на
другую: лучший способ передачи тонкой информации - это использовать
голову работника. К сожалению, в организациях часто устанавливают
барьеры для таких переходов, например, у разработчика может быть
более высокий статус и (или) более высокий оклад, чем у "простого"
программиста. Не принято, чтобы сотрудники ходили по отделам с целью
набраться опыта и знаний, но пусть, по крайней мере, будут
регулярными собеседования сотрудников, занятых на разных стадиях проекта.
Для средних и малых проектов обычно не делают различия между
анализом и проектированием - эти стадии сливаются в одну. Для малых
проектов также не разделяют проектирование и программирование.
Конечно, тем самым решается проблема взаимодействия. Для данного
проекта важно найти подходящую степень формализации и выдержать
нужную степень разделения между стадиями ($$11.4.2). Нет единственно
верного способа для этого.
Приведенная здесь модель процесса развития программного обеспечения
радикально отличается от традиционной модели "каскад" (waterfall).
В последней процесс развития протекает линейно от стадии анализа до
стадии тестирования. Основной недостаток модели каскад тот, что в ней
информация движется только в одном направлении. Если выявлена
проблема "ниже по течению", то возникает сильное методологическое
и организационное давление, чтобы решить проблему на данном уровне,
не затрагивая предыдущих стадий процесса. Отсутствие повторных
проходов приводит к дефектному проекту, а в результате локального
устранения проблем получается искаженная реализация. В тех
неизбежных случаях, когда информация должна быть передана назад к
источнику ее получения и вызвать изменения в проекте, мы получим
лишь слабое "колыхание" на всех уровнях системы, стремящейся подавить
внесенное изменение, а значит система плохо приспособлена к
изменениям. Аргумент в пользу "никаких изменений" или "только локальные
изменения" часто сводится к тому, что один отдел не хочет
перекладывать большую работу на другой отдел "ради их же блага".
Часто бывает так, что ко времени, когда ошибка уже найдена, исписано
столько бумаги относительно ошибочного решения, что усилия,
нужные на исправление документации, затмевают усилия для исправления
самой программы. Таким образом, бумажная работа может стать главной
проблемой процесса создания системы. Конечно, такие проблемы могут быть
и возникают в процессе развития больших систем. В конце концов,
определенная работа с бумагами необходима. Но выбор линейной модели
развития (каскад) многократно увеличивает вероятность, что эта
проблема выйдет из-под контроля.
Недостаток модели каскад в отсутствии повторных проходов и
неспособности реагировать на изменения. Опасность предлагаемой здесь
итеративной модели состоит в искушении заменить размышление и
реальное развитие на последовательность бесконечных изменений.
Тот и другой недостатки легче указать, чем устранить, и для того,
кто организует работу, легко принять простую активность за реальный
прогресс.
Вы можете уделять пристальное внимание деталям, использовать
разумные приемы управления, развитую технологию, но ничто не спасет
вас, если нет ясного понимания того, что вы пытаетесь создать. Больше
всего проектов проваливалось именно из-за отсутствия хорошо
сформулированных реалистичных целей, а не по какой-либо иной причине.
Что бы вы не делали и чем бы не занимались, надо ясно представлять
имеющиеся у вас средства, ставить достижимые цели и ориентиры и не
искать технических решений социологических проблем. С другой стороны,
надо применять только адекватную технологию, даже если она потребует
затрат,- люди работают лучше, имея адекватные средства и приемлемую
среду. Не заблуждайтесь, думая, что легко выполнить эти рекомендации.
| |
|
