В прошлой статье мы разобрались с тем, что такое нотации, для чего они нужны и что важно учесть при их выборе.
Но реальность такова, что на предприятии нотация либо есть, либо нет. Выбирать ее под каждую конкретную задачу никто не будет. Поэтому описание задачи подгоняют под имеющиеся нотации.
И какой бы совершенной ни была методология, если разработчик не сформулировал четкие требования к системе (ПО), результатом может стать разочарование. Дорогостоящее разочарование.
В ответ можно услышать оправдания: «Данная методология не позволяет... не умеет… не предназначена…».
Формулировка требований – вот с чего необходимо начинать разработку
Ошибки, допущенные на начальных этапах разработки, в итоге обходятся дороже остальных. А для их устранения иногда приходится перекраивать всю программу. Именно поэтому так важно внимательно отнестись к формулировке требований.
Пример: После беседы с руководителем одного из отделов была поставлена задача – разработать систему контроля затрат по определенному виду деятельности.
Беседа с каждым работником отдела не была проведена, т.к. решили сократить время и получить единую информацию от руководителя.
Разработали. Внедрили. Все отлично и прозрачно, руководитель доволен. А вот специалист, работающий с программой, был возмущен. Система не проводила подсчет затрат, только контроль. Т.е. все суммы специалист должен был ввести руками :).
Почему? А не просили!
И смешно, и грустно… Но для исправления ошибки пришлось писать новую программу.
Классическая ошибка при разработке – недостаточно уделили времени на беседу со всеми участниками процесса. Часто избегают бесед с большим количеством людей по причине «100 человек и у каждого свое требование».
Да! И это важно учесть!
и не перепутать - "детям мороженое, бабе цветы"
Ошибки, допущенные на стадии сбора требований, составляют от 40 до 60% всех дефектов проекта.
Davis, 1993; Leffingwell, 1997
Таким образом, требования – это фундамент здания, которое вы проектируете. И чем мощнее здание (система), тем надежнее должен быть фундамент.
Надеюсь, я убедила вас, что четкая формулировка требований важна :)
Идем дальше.
С чего начать? С беседы со всеми участниками, конечно!
Провести беседы, зафиксировать требования, пожелания, проблемы.
Но если вам кажется, что собрать информацию от всех участников бизнес-процесса легко, то вам действительно кажется…
Этап определения требований – это этап, на 95% состоящий из взаимодействия разработчика и участников процесса. А взаимодействие людей – это психология. И возникающие проблемы на этом этапе – на 95% проблемы психологические.
Начнем с самого слова «требования».
Разработчики и пользователи системы (ПО) вкладывают в него разный смысл.
Для разработчика – это функционал ПО. То, что должна делать программа.
Для пользователя – это его «хотелки». И если он сообщил их разработчику, но не увидел в программе, он точно останется недоволен.
Из практики: в 99% случаев участник процесса, рассказывая о своей работе, чувствует себя специалистом, который знает, как надо. И убедить человека в том, что его рабочий процесс организован неверно, бывает крайне сложно или невозможно вообще. Многие воспринимают это как сомнение в их компетентности и отказываются от дальнейшего общения.
Об этой и множестве других проблем при разработке ПО, а также о путях их преодоления мы и поговорим в следующих постах рубрики…
Посты этой рубрики:
Разработка ПО часть 3 - Нотации
Разработка ПО часть 2 – Методы описания
Разработка ПО часть 1
