Забытый Этап Проектирования

Сейчас практически в каждой статье о веб 2.0 и стартапах среди рекомендаций можно увидеть совет: хватит думать об этом и предпроектной документации — занимайся проектом! И очень часто этот совет воспринимают буквально, первые строчки кода появляются еще до того, как идея окончательно сформирована.

Каков результат? Но в результате ядро системы за весь период разработки переписывалось 15 раз, не говоря уже о фронтенде.

В результате проект, задуманный на 1-2 месяца, длится полгода – год. И код превращается в кучу ошибок.

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

Многие проекты умерли из-за недостаточного или низкое качество подготовка.

И так бы и продолжалось, если бы однажды я не познакомился с простой вещью: «Стандарты разработки программных проектов».

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

К счастью, это не совсем так.

Действительно, многие стандарты достаточно обширны и описывают огромное количество вещей, ненужных в конкретном проекте.

Но на то он и стандарт, чтобы на его основе можно было построить свой.

Вам нужно выбрать только те детали, которые действительно необходимы.

Зачем использовать стандарты? Во-первых, описать, кто в команде чем занимается.

Чтобы не было ситуации, что где-то в середине проекта один из участников говорит, что не будет чем-то заниматься, потому что.

не обещал или вообще не знает, как это сделать.

Во-вторых, чтобы точно определить, что вы хотите получить в итоге.

Вам необходимо составить список требований к конечному результату.

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

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

Хватит описаний, приступим к практике.

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

Инициализация - здесь вы обсуждаете, что примерно хотите получить, обмениваетесь мыслями.

Дизайн – это этап, который забывается.

Подробнее об этом ниже.

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

В случае небольшой команды я не предлагаю использовать какой-то супернавороченный софт. Давайте просто придерживаться Вики.

Я выбрал для себя «ДокуВики», вы можете использовать любую другую.

Мы будем использовать стандарты IEEE для управления проектами, хотя и не будем следовать им дословно.

Первый документ, который нам нужен, — это SPMP (План управления программным проектом), также известный как «План управления программным проектом».

Здесь мы укажем, кто за что отвечает в проекте, как будет происходить управление, какие методы вы будете использовать.

Для тех, кому нужны конкретные примеры, в конце приведу несколько ссылок.

Далее нам понадобится SRS (Спецификация требований к программному обеспечению), также известная как «Спецификация требований к программному обеспечению».

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

Требования к интерфейсу, а также варианты использования.

Нарисуйте структуру вашего сайта, создайте прототип.

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

Например, вы можете использовать MS Visio. Я бы рекомендовал всегда создавать прототип внешнего интерфейса, даже если все кажется простым.

Если просто, то это займет 5 минут, а что делать, если вы что-то забыли? Мы не говорим о графическом дизайне или чем-то подобном.

Просто кнопки, формы и поля ввода, а также их практическое расположение на странице сейчас не имеют определяющего значения.

Теперь перейдем к SCMP (плану управления конфигурацией программного обеспечения), также известному как план управления конфигурацией программного обеспечения.

Здесь я редко придерживаюсь стандарта, но документ все равно необходим.

В нем описывается, какое программное обеспечение вы используете во время разработки и как организованы версии.

Как проходят собрания и т.д. И, наконец, SDD (описание дизайна программного обеспечения), также известный как проектный документ. Вооружившись списком требований, описанных в СГД, мы приступаем к проектированию нашей системы.

Описываем архитектуру проекта, основные пакеты и классы.

Уровень детализации описаний определяется индивидуально.

Вот и всё, не так много, как казалось.

Из личного опыта: раздел SRS в вики можно использовать как систему управления требованиями.

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

Теперь пара ссылок: Документация для MOORPG с открытым исходным кодом Иреон - практический пример заполнения некоторых документов.

СПМП (англ) Здесь Оригинал При желании все стандарты можно найти в Google. Теги: #документация #проект #проектирование #стандарт #управление проектом #Чулан

Вместе с данным постом часто просматривают: