Соответствие процессу: большая часть этой главы посвящена дисциплине требований рационального унифицированного процесса (RUP).
В данной главе мы попытаемся обосновать необходимость анализа и проектирования программного обеспечения и покажем, как к этому приступить.
Подходящие примеры мы решили выбрать из практического исследования, описываемого в главе 16. В этой главе изучается разработка электронной банковской системы. Более подробные сведения о примерах можно найти в разделе "Требования к HomeDirect" главы 16.
Зачем нужны анализ и проектирование
Сначала попробуем ответить на простой вопрос: зачем вообще нужно говорить об анализе и проектировании? Ведь анализ, кажется, совсем исключен из списка приоритетов некоторых продвинутых разработчиков и даже был назван приводящим ни более, ни менее как к "аналитическому параличу".
Всегда существует вероятность, что какие-то группы могут завязнуть на стадии анализа. Однако полное пренебрежение анализом и проектированием и переход сразу к реализации вряд ли выглядит лучшей альтернативой.
Предположим, что вы хотите попасть из точки А в точку В. Если это близко и вы хорошо знакомы с местностью, вполне можно сразу же отправляться в путь, не тратя времени на то, чтобы взглянуть на карту и составить какой-то предварительный план.
Напротив, если А и В отстоят на большое расстояние и находятся на незнакомой территории, шансы на успех очень повышаются, если заранее уделить время планированию.
В разработке программ нет ничего принципиально иного. В небольших программных проектах с использованием известной технологии и в хорошо знакомой предметной области вполне можно обойтись без анализа и проектирования. Но эта стадия будет существенно необходимой в больших проектах неисследованного направления, если разработчик хочет избежать ловушек и опасностей, жертвой которых становится огромное большинство проектов .
Анализ проблемы
Требования могут быть всех видов и форм и исходить из самых разных источников. Они могут быть представлены конечным, пользователем в форме письменных документов, составлены при встречах с визионерами в компании или выдвинуты при личной беседе с заказчиком.
Часто проекты терпят неудачу из-за того, что требования не были точно поняты. Это не слишком удивительно в свете того, что естественный язык, в письменной или устной форме, неточен по своему характеру и допускает различные интерпретации. Поэтому в первую очередь необходимо удостовериться, что требования правильно поняты, т.е. продвинуться дальшетого, что очевидно и зафиксировано в документе. Только таким способом можно реально определить, какие модели и шаблоны понадобятся при разработке программной системы.
Именно здесь в дело вступают прецеденты. Можно с помощью моделирования прецедентов создать точную модель того, что требуется в системе, а затем на базе прецедентов исследовать другие аспекты разработки. Прецеденты заполняют разрыв между конечным пользователем и требованиями к системе. Они также позволяют наметить путь от функциональных требований к реализации.
Лучше всего, чтобы анализом занималась группа. Благодаря этому можно сравнивать мнения разных людей, оценивающих одни и те же требования со своей точки зрения. Также полезно, чтобы в обсуждении принимал участие специалист по проблемной области. Не помешает и участие заказчика, или автора требований, чтобы можно было узнать о смысле требований из первых рук. Такое обсуждение может сэкономить массу работы на последующих этапах. На этой стадии, чтобы добраться до сути проблемы, можно применять такие методы, как мозговой штурм или диаграммы причинно-следственных связей.
В ходе этой стадии полезно попробовать исключить повторяющиеся требования и уменьшить их общее количество. Не поддайтесь искушению одновременно со сбором требований пытаться разрабатывать проект. Также следует избегать "ползучего" добавления требований (наподобие "ползучего добавления функций", когда функции постоянно продолжают накапливаться, выходя за заранее намеченный объем), предпринимая решительные усилия сохранить связь с потребностями заказчика.
Более подробно об этих работах можно узнать в следующих книгах: Grady Booch, Object-Oriented Analysis and Design with Applications, Addison-Wesley, 1994, и Daryl Kulak et.al., Use Cases-Requirements in Context, Addison-Wesley, 2000.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
