23 August 2007

Забытая фаза проектирования

Lumber room
Сейчас почти в каждой статье про web 2.0 и стартапы среди рекомендаций можно увидеть совет: бросьте долгие раздумья и пред-проектную документацию — делайте проект! И очень часто этот совет воспринимается буквально, первые строчки кода появляются еще до того, как идея окончательно сформируется. Что в итоге? А в итоге ядро системы за весь период разработки переписывается раз по 15, не говоря уже о фронтенде. Как следствие проект который был задуман как 1-2х месячный растягивается на пол-года — год. А код превращается в сборище багов.

Что же сделать что-бы этого избежать и при этом не заниматься планированием по пол-года?

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

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

Для чего использовать стандарты? Во-первых, для того чтобы описать, кто в команде чем занимается. Для того чтобы избежать ситуации, что где-то в середине проекта один из участников говорит что чем-то он занимать не будет т.к. не обещал или вообще не умеет. Во-вторых, чтобы точно определить что вы хотите получить в итоге. Нужно составить лист требований к конечному результату. Иначе как вы будете определять степень качества на выходе? В-третьих, для того чтобы не произошла ситуация, что оба программиста одновремено разрабатывают класс, один подгружает свою версию в репозиторий, через какое-то время другой подгружает свою заменяя предыдущую, нужно определить как вы будет обновлять код, установить правила.

Попробуйте документировать свой проект хотябы по минимуму и я думаю вы сами начнете лучше понимать что вы делаете.

Хватит описаний давайте перейдем к практике. Разделим весь проект на несколько частей.

Инициализация — здесь вы обсуждаете что вы примерно хотите получить, обмениваетесь мыслями.
Проектирование — вот она стадия которую забывают. О ней подробней ниже.
Кодирование — тут всё ясно надеюсь :)
Тестирование — А вот этой стадии без проектирования не бывает, если вы не знаете что хотели получить, как вы проверите что получили?
Интеграция — запускаем проект.

Теперь подробнее о проектировании.
В случае небольшой команды, я не предлагаю использовать какое-то супер навороченное ПО. Давайте ограничимся просто Wiki. Я выбрал для себя DokuWiki, вы может использовать любую другую. Воспользуемся стандартами IEEE для проектного менеджмента, хотя следовать ему дословно не будем.
Первый документ который нам понадобится SPMP (Software project management plan) он же «План управления программным проектом». Тут укажем кто за что в проекте отвечает, как будет происходить управление, какие методы вы будете использовать. Для тех кому нужны конкретные примеры в конце приведу несколько ссылочек.
Дальше нам понадобится SRS (Software Requirements Specification) она же «Спецификация требований к ПО». Это очень важный документ, тут расписываются все функции которые должны быть реализованы в системе. Требования к интерфейсу, а так же use cases. Нарисуйте структуру вашего сайта, создайте прототип. Под прототипом я не имею ввиду что-то действительно работающее. Прототип это набросок пользовательского интерфейса. Можно воспользоваться например MS Visio. Я бы рекомендовал всегда делать прототип фронэнда, даже если кажется что всё просто. Если просто — так это займет 5 минут, а вдруг вы что-то забыли? Тут не идёт разговора о графическом дизайне или чем-то подобном. Просто кнопки, формы и поля ввода, также и их практическое расположение на странице не имеет сейчас никакого решающего значения.
Теперь перейдем к SCMP (Software configuration management plan), он же «План управления конфигурациями ПО». Тут я редко придерживаюсь стандарта, но всё же документ необходим. Здесь описывается какое ПО вы используете при разработке, как упорядочиваются версии. Как происходят сборки итд.
Ну и наконец SDD(Software Design description), он же дезигн док. Вооружившись списком требований описанных в SRS начинаем проектировать нашу систему. Описываем архитектуру проекта, основные пакеты и классы. Степень детальности описаний определяем индивидуально.

Вот собственно и всё, не так много как казалось. Из личной практики: раздел в SRS в вики можно использовать как систему управления требованиями. Просто присвойте каждой функции свой номер, статус и приоритет. Не стоит создавать себе проблем с лишним софтом.

Теперь пара ссылочек:
Документация к Open Source MOORPG Ireon — практический пример заполнения некоторых документов.
SPMP (eng) здесь

Оригинал

При желании все стандарты находятся гуглом.
Tags:документацияпроектпроектированиестандартуправление проек
Hubs: Lumber room
+15
736 49
Comments 57
Top of the last 24 hours