Изменение ТЗ во время разработки приложения

Я думаю многие разработчики сталкивались с такой бедой как изменение технического задания при разработке сайта или программы во время разработки приложения. Такое есть и, наверное, будет всегда. Да это плохо и часто губительно, но ничего не поделаешь. Так повелось, что заказчики никогда толком и не могут определить, что же они хотят? "Вот эту фишаЧку, или вот эту!" И что делать нам разработчикам? Хочешь заработать свою копейку делай, переделывай, строй, разрабатывай. Да, за лишнюю работу цена увеличивается, но часто бывает, что и не рад увеличению этой самой платы так как работы бывает много.

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

Нужна ли спецификация для проекта?

Когда-то все свои программы я писал даже не думая о том, чтобы составить хотя бы перечень из функциональностей доступных в программе. Программы писались и даже работали =) да вот только бывало, что работа над одной программой занимала огромное количество времени. И это происходило не из-за того, что программы были огромными и многофункциональными. Нет, скорее наоборот! Они были маленькие и их функциональность была смехотворна. Тогда почему же их разработка занимала много времени? Все просто! У меня небыло и малейшего плана разработки, я не задумывался о взаимодействиях одной части программы со второй.

Это было просто ужасно, так как простейшие часики с настройками, будильником, напоминалками и календарем занял полторы тысячи строк. Подумайте 1500 строк на часы, которые ничего из себя не представляли. Но не только это было причиной таких больших сроков разработки. Порой программа выходила только через несколько версий, т.е. я начинал писать с версии 1.0, а свет увидела только 1.4 =(( И все потому, что напортачив в коде, я не разбираясь начинал писать новую версию, уже более продуманную.

И все-таки, как можно было исправить это плачевное положение? Я думаю каждый программист, который сталкивался с такими проблемами уже знает ответ на этот вопрос. А может кто-то уже и использует, то про что многие знают но мало кто использует, так как считают не нужным. А зря.

Итак, мой разговор пойдет, об одной из частей разработки программного обеспечения - написании спецификации.

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

Так, какую информацию можно изложить в спецификации? Наверное, самое главное это указать, полностью всю функциональность разрабатываемого приложения и определить как должен с каждой из них работать пользователь! Это очень важно, так как на этом шаге мы становимся на место пользователя и пытаемся разобраться как и что будет работать. Часто бывает, что разработчики создав приложение даже не думали как с ним будет работать пользователь. И для того, чтобы пользователю воспользоваться какой либо функциональность приложения ему приходится совершить чудеса эрудиции и свои превосходные знания компьютера. НО!

Не всегда, пользователь хорошо разбирается в компьютере. Часто люди только и знают как работать в некоторых программах и разобраться в чем-то сложном для них просто немыслимо сложно. Мне чуть ли не каждый день звонят люди, которые задают вопросы: "Как записать диск? Почему у меня не работает сеть? Почему у меня фильм открывается не тем проигрывателем?" Я думаю для нормального, хоть чуть-чуть знающего компьютер пользователя, эти вопросы окажутся смешными.

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

Допустим, мы написали о писали всю функциональность приложения и написали как со всем этим будет работать пользователь. Можно ли расширить и добавить в нашу спецификацию какую-нибудь информацию, которая может помочь при программировании? Конечно можем. Этот шаг мало кто делает (я сам так сделал только один раз =)) ) но польза от следующего действия огромна и позволяет сократить время программирования в 2 и более раз. Что это за шаг? Шаг разработки внутренней структуры самого приложения. Т.е. для каждой описанной нами ранее функциональности мы описываем из чего она будет состоять программно. Т.е. классы и для чего они нужны, взаимодействия между классами. После этого действия у нас все приложение будет уже описано, нам только останется создать все эти классы, а именно создать реализацию каждого конкретного класса, их методы.

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