Этапы разработки проекта по мемам и ГОСТам: приятное с полезным

Мы, Moroz Team, в предыдущей статье «Операция «Ы»: просто о процессе разработки ПО на примере строительства» рассказывали, из чего состоит процесс разработки. И упомянули основные фазы — крупные этапы разработки проекты. В этой статье раскроем подробнее каждый из них.

Этапы, стадии, фазы, процессы и ещё куча вариаций терминов. Назовём их единым словом «шаг», чтобы уж точно не запутаться.

На вопрос о шагах разработки разные источники из сферы IT дают разные ответы. В одном источнике есть 4 шага, а в другом их уже 8. И каждый по сути своей прав. Чтобы никого не обидеть, мы просто посмотрим, как эти шаги ложатся друг на друга. И постараемся убедиться, что все они говорят нам об одном и том же.

Разберём следующие источники информации об этапах разработки:
— ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» (далее буду называть просто «ГОСТ 34»)
— ГОСТ 19.102-77 «Стадии разработки» (далее — просто «ГОСТ 19»)
— Унифицированный процесс (Unified Process, UP) и его более известный вариант RUP (Rational Unified Process)

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

За основу для единого набора возьмём последовательность фаз (этапов) унифицированного процесса. Просто потому что их меньше и все они имеют понятные названия

В результате этого должно быть принято решение о необходимости разработки (или обоснование её нецелесообразности).

С конечными пользователями, чьи проблемы нужно решить, нужно познакомиться, узнать, как они выполняют свои задачи, с какими препятствиями сталкиваются и как мы можем им помочь. Эти исследования могут выполняться разными способами: от наблюдения за процессом до интервью с пользователями. Этот этап называют обследованием или изучением предметной области. В результате мы можем получить список из пунктов вроде:

«Пользователь хочет знать, когда на его заявку ответили, и получать ответ на неё в мессенджере»

Видение обязательно должно быть принято и согласовано всеми сторонами: и заказчиком, и исполнителем. Оформить видение можно как отдельным документом, так и включить его в состав, например, технического задания — документа, который по ГОСТам включает в себя все первоначальные требования к системе.

Итоговым решением может стать:

— закупка готового решения, которое уже есть на рынке;
— или доработка текущих инструментов;
— или разработка нового решения с нуля.

Решили дорабатывать или разрабатывать? Провели первоначальное планирование, определили примерные сроки получения результатов, согласовали ТЗ (если есть необходимость) и погнали!

Этапы ГОСТ 34
4. Эскизный проект
5. Технический проект

Этапы ГОСТ 19
2. Эскизный проект
3. Технический проект

В ГОСТах тут всё совпадает: эскизный и технический проект. Часто их объединяют в один, как сделаем и мы. Рассмотрим их в рамках этапа развития.

Перед началом непосредственно программирования, необходимо подготовить «каркас» системы. А затем уже только сам каркас нанизывать кодом. В составе этого каркаса обязательны:

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

Помимо этих важных элементов на этапе развития может уже и разрабатываться некоторая архитектурная основа системы. Раннее программирование на этом этапе приветствуется, но не является обязательным. Немного расскажем про основные составляющие этапа.

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

Возьмём пример предыдущего пожелания пользователя: «Пользователь хочет знать, когда на его заявку ответили, и получать ответ на неё в мессенджере». И переформулируем его в функцию:

«Система при появлении ответа на заявку должна отправлять уведомление пользователю в настроенный им в профиле мессенджер: Telegram или WhatsApp. Состав уведомления: <...>»

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

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

Чтобы лучше погрузиться в вопросы составления архитектуры, советуем почитать книгу Роберта С. Мартина «Чистая архитектура. Искусство разработки программного обеспечения».

Этапы ГОСТ 34
6. Рабочая документация

Этапы ГОСТ 19
4. Рабочий проект

Наконец, настал тот час! Можно приступать к выполнению требований и превращению всех хотелок в реальность — к разработке. На этом этапе наконец-то пользователь сможет увидеть и пощупать готовую систему. А чтобы делать это не через годы работы, а как можно чаще, поможет итеративный подход к разработке.

Итеративный подход может применяться и на предыдущих этапах. Но здесь он всегда более ярко выражен из-за более ощутимых результатов. Поэтому расскажем о нём здесь подробнее.

Современные методы часто делят процесс реализации на итерации или спринты, т.е. некоторые временные промежутки. Обычно от 1 до 3 недель. По окончанию каждого такого промежутка в идеале должна получиться рабочая версия системы с приращением полезности для пользователя.

В результате каждого спринта конечные пользователи видят улучшения. Польза такого подхода в гибкости. Реалии и желания пользователя могут изменяться, уточняться. Разработка «по кусочкам» позволяет остановиться в определённый момент и изменить направление.

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

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

Этап внедрения чаще выполняется параллельно с этапом разработки. Внедрение выполняется не 1 раз для всей системы, а по итогам каждой итерации (спринта). Например, пока разработчик приступает к реализации новых функций, DevOPS-инженеры устанавливают версию системы, полученную в результате предыдущей итерации (спринта).

Помимо установки самой системы, внедрение может включать и другие задачи:

• проверки и приёмочные испытания;
• создание руководств для пользователей и другой документации;
• передача информации о новой функциональности службе поддержки;
• сообщение о новой версии (может быть связано с маркетинговыми активностями).

На этапе внедрения заказчик может посчитать, что разработка системы завершена. В таком случае возврат на этап конструирования (разработки) не произойдёт.

ГОСТ 34
8. Сопровождение АС

Эксплуатация — это непосредственное использование системы пользователями по назначению. Сопровождение или поддержка — это помощь пользователям в работе с системой.

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

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

Не всегда порядок этапов может и должен соблюдаться именно таким образом. Вы можете их комбинировать и переставлять, использовать разные модели жизненного цикла.

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

Если знать нюансы, то ваш проект поможет другим не только своей инновационностью, но и своими надёжностью и качеством. Именно таких результатов мы вам и желаем!

Не хотите заморачиваться с этапами разработки? Или вам нужна помощь на каком-то из этапов? Заглядывайте к нам, в Moroz Team. Сделаем приложение для вас и поможем, чем сможем)