Сейчас практически в каждой статье о веб 2.0 и стартапах среди рекомендаций можно увидеть совет: хватит думать об этом и предпроектной документации — занимайся проектом! И очень часто этот совет воспринимают буквально, первые строчки кода появляются еще до того, как идея окончательно сформирована.
Каков результат? Но в результате ядро системы за весь период разработки переписывалось 15 раз, не говоря уже о фронтенде.
В результате проект, задуманный на 1-2 месяца, длится полгода – год. И код превращается в кучу ошибок.
Что можно сделать, чтобы избежать этого и не планировать на полгода? Признаюсь честно, я много раз наступал на эти грабли.
Многие проекты умерли из-за недостаточного или низкое качество подготовка.
И так бы и продолжалось, если бы однажды я не познакомился с простой вещью: «Стандарты разработки программных проектов».
Те, кто работал в крупных компаниях-разработчиках программного обеспечения, наверняка слышали или использовали ту или иную методологию или стандарт. Я заранее могу представить недовольные лица некоторых людей, говорящих, что это ненужная бюрократия, никакой пользы.
К счастью, это не совсем так.
Действительно, многие стандарты достаточно обширны и описывают огромное количество вещей, ненужных в конкретном проекте.
Но на то он и стандарт, чтобы на его основе можно было построить свой.
Вам нужно выбрать только те детали, которые действительно необходимы.
Зачем использовать стандарты? Во-первых, описать, кто в команде чем занимается.
Чтобы не было ситуации, что где-то в середине проекта один из участников говорит, что не будет чем-то заниматься, потому что.
не обещал или вообще не знает, как это сделать.
Во-вторых, чтобы точно определить, что вы хотите получить в итоге.
Вам необходимо составить список требований к конечному результату.
Иначе как вы определите степень качества на выходе? В-третьих, чтобы избежать ситуации, когда оба программиста одновременно разрабатывают класс, один загружает в репозиторий его версию, а другой через некоторое время загружает свою, заменяя предыдущую, нужно определиться, как вы будете обновлять код. , установить правила.
Попробуйте хотя бы по минимуму документировать свой проект и я думаю вы сами начнете лучше понимать, что делаете.
Хватит описаний, приступим к практике.
Давайте разделим весь проект на несколько частей.
Инициализация - здесь вы обсуждаете, что примерно хотите получить, обмениваетесь мыслями.
Дизайн – это этап, который забывается.
Подробнее об этом ниже.
Кодирование - Надеюсь, здесь все понятно :) Тестирование — Но без проектирования этого этапа не бывает, если ты не знаешь, что хотел получить, как ты будешь проверять то, что получил? Интеграция — запускаем проект. Теперь поговорим подробнее о дизайне.
В случае небольшой команды я не предлагаю использовать какой-то супернавороченный софт. Давайте просто придерживаться Вики.
Я выбрал для себя «ДокуВики», вы можете использовать любую другую.
Мы будем использовать стандарты IEEE для управления проектами, хотя и не будем следовать им дословно.
Первый документ, который нам нужен, — это SPMP (План управления программным проектом), также известный как «План управления программным проектом».
Здесь мы укажем, кто за что отвечает в проекте, как будет происходить управление, какие методы вы будете использовать.
Для тех, кому нужны конкретные примеры, в конце приведу несколько ссылок.
Далее нам понадобится SRS (Спецификация требований к программному обеспечению), также известная как «Спецификация требований к программному обеспечению».
Это очень важный документ, в нем описаны все функции, которые необходимо реализовать в системе.
Требования к интерфейсу, а также варианты использования.
Нарисуйте структуру вашего сайта, создайте прототип.
Под прототипом я не имею в виду то, что действительно работает. Прототип — это эскиз пользовательского интерфейса.
Например, вы можете использовать MS Visio. Я бы рекомендовал всегда создавать прототип внешнего интерфейса, даже если все кажется простым.
Если просто, то это займет 5 минут, а что делать, если вы что-то забыли? Мы не говорим о графическом дизайне или чем-то подобном.
Просто кнопки, формы и поля ввода, а также их практическое расположение на странице сейчас не имеют определяющего значения.
Теперь перейдем к SCMP (плану управления конфигурацией программного обеспечения), также известному как план управления конфигурацией программного обеспечения.
Здесь я редко придерживаюсь стандарта, но документ все равно необходим.
В нем описывается, какое программное обеспечение вы используете во время разработки и как организованы версии.
Как проходят собрания и т.д. И, наконец, SDD (описание дизайна программного обеспечения), также известный как проектный документ. Вооружившись списком требований, описанных в СГД, мы приступаем к проектированию нашей системы.
Описываем архитектуру проекта, основные пакеты и классы.
Уровень детализации описаний определяется индивидуально.
Вот и всё, не так много, как казалось.
Из личного опыта: раздел SRS в вики можно использовать как систему управления требованиями.
Просто присвойте каждой функции свой номер, статус и приоритет. Не стоит создавать себе проблемы ненужным программным обеспечением.
Теперь пара ссылок: Документация для MOORPG с открытым исходным кодом Иреон - практический пример заполнения некоторых документов.
СПМП (англ) Здесь Оригинал При желании все стандарты можно найти в Google. Теги: #документация #проект #проектирование #стандарт #управление проектом #Чулан
-
Руководство Для Идиотов По Записи Dvd
19 Oct, 24 -
Перемещение Папок В Почте Яндекс.
19 Oct, 24 -
Кодигнитер 1.7.0
19 Oct, 24 -
На Вкус И Цвет Товарищей Нет
19 Oct, 24