Moroz Team

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

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

Какие разные этапы разработки и как в них разобраться

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

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

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

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

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

  1. Начало (анализ)
  2. Развитие (проектирование)
  3. Конструирование (разработка)
  4. Внедрение

1. Начало (анализ) — делать ли нам эту систему вообще?

Этапы ГОСТ 34
1. Формирование требований к АС
2. Разработка концепции АС
3. Техническое задание

Этапы ГОСТ 19
1. Техническое задание

1.1. Каких целей и результатов хочет добиться заказчик?

Начальный этап является подготовительным. Для подготовки в первую очередь определяются цели заказчика, потребности и проблемы пользователей и возможности исполнителя.
Первый этап разработки проекта начинается с определения целей заказчика. Читайте подробнее в статье в блоге moroz.team
В результате этого должно быть принято решение о необходимости разработки (или обоснование её нецелесообразности).

1.2. Решение каких проблем пользователей позволит достичь поставленных целей и результатов?

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

«Пользователь хочет знать, когда на его заявку ответили, и получать ответ на неё в мессенджере»
Следующий этап в разработке проекта - общение с конечными пользователями и определение их проблем и потребностей. Читайте подробнее в статье в блоге moroz.team
В результате мы узнаём, что болит, где чешется и начинаем думать, как это можно исправить. Для этого исправления может понадобиться система, которую мы будем разрабатывать. Для решения каждой проблемы мы определяем облик конечной системы, который содержит основную идею. Описание облика называют видением или концепцией.
Видение обязательно должно быть принято и согласовано всеми сторонами: и заказчиком, и исполнителем. Оформить видение можно как отдельным документом, так и включить его в состав, например, технического задания — документа, который по ГОСТам включает в себя все первоначальные требования к системе.

1.3. Поясни за разработку: принятие окончательного решения о необходимости разработки

После того, как все понимают, какой должна быть система, исполнитель должен обосновать необходимость собственной разработки и проверить выгоду от её внедрения. Эту проверку называют технико-экономическим обоснованием. В результате становится понятно, выгодно ли вообще вкладываться в разработку такого решения.
Важным вопросом в процессе разработки является экономическое обоснование разработки системы. Читайте подробнее в статье в блоге moroz.team
Итоговым решением может стать:

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

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

2. Развитие (проектирование) — надо бы понять, что за система и как нам её делать

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

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

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

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

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

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

2.1. Что должна делать система? Состав функций и функциональные требования

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

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

«Система при появлении ответа на заявку должна отправлять уведомление пользователю в настроенный им в профиле мессенджер: Telegram или WhatsApp. Состав уведомления: <...>»
При разработке требований к системе важно помнить о том, что они должны учитывать потребности конечных пользователей. Читайте подробнее в статье в блоге moroz.team
Обязательно при определении функций учитывать, что нужно конечному пользователю. Если этого не сделать, то вы можете создать систему, которая не будет никому нужна, никто не будет ей пользоваться. Время и ресурсы команды разработки будут потрачены зря, а заказчик, скорее всего, будет разочарован. Не надо так!

2.2. Из чего должна состоять система? Составление общей архитектуры системы

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

Выбор подхода определяет, насколько безопасной, производительной, масштабируемой, удобной в использовании, надёжной и переносимой будет ваша система в будущем. Если система будет расти и развиваться, она не сможет это сделать хорошо без проработанной архитектуры. Также выбор архитектуры на ранних этапах упрощает тестирование, поддержку, модификацию, разработку, развёртывание и обеспечивает независимость (например, от поставщика готовых решений).
Цель проектирования общей архитектуры на этом этапе — определить общий технический подход на верхнем уровне. По завершении этой работы должно быть достаточно информации, чтобы передать архитектуру команде и продемонстрировать её жизнеспособность для клиента.
Этап проектирования очень важен при разработке ПО. Чем больше внимания и времени уделить проектированию, тем качественнее будет разработанный продукт. Читайте подробнее в статье в блоге moroz.team
Чтобы лучше погрузиться в вопросы составления архитектуры, советуем почитать книгу Роберта С. Мартина «Чистая архитектура. Искусство разработки программного обеспечения».

3. Конструирование (разработка) — ну, что ж, погнали делать

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

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

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

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

Прирост функций системы как снежный ком: зачем нужна итеративная разработка

Современные методы часто делят процесс реализации на итерации или спринты, т.е. некоторые временные промежутки. Обычно от 1 до 3 недель. По окончанию каждого такого промежутка в идеале должна получиться рабочая версия системы с приращением полезности для пользователя.
То чувство, когда наконец сделал версию системы и показываешь её заказчику. Об этом и других этапах разработки читайте подробнее в статье в блоге moroz.team
Например, в первом спринте добавили 1-2 базовые функции. Во втором спринте начали улучшать дизайн и добавили ещё 1 функцию. Третий спринт выделили на исправление ошибок, уточнение архитектуры и закрытие технического долга и т. д.
В результате каждого спринта конечные пользователи видят улучшения. Польза такого подхода в гибкости. Реалии и желания пользователя могут изменяться, уточняться. Разработка «по кусочкам» позволяет остановиться в определённый момент и изменить направление.

Этап разработки — это только написание кода? Какие ещё задачи включает этап реализации

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

Управляйте процессом разработки проще с Аванпланом

Подключайте всех специалистов и настройте работу для каждой команды. Доступно в веб-версии, в App Store и Google Play

4. Внедрение — принимай работу, начальник

Удовлетворить заказчика - это основная цель процесса разработки и каждого из его этапов. Проверить удовлетворённость заказчика позволяет этап внедрения. Об этом и о других этапах разработки читайте подробнее в статье в блоге moroz.team
Этапы ГОСТ 34
7. Ввод в действие

Этапы ГОСТ 19
5. Внедрение

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

Каким бывает внедрение и когда оно происходит

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

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

Какие ещё задачи выполняются на этапе внедрения

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

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

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

Есть ли жизнь после внедрения? Эксплуатация и сопровождение системы

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

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

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

Спасибо, что осилили эту сложную статью! Надеюсь, мемы вам понравились

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

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

Если знать нюансы, то ваш проект поможет другим не только своей инновационностью, но и своими надёжностью и качеством. Именно таких результатов мы вам и желаем!
Не хотите заморачиваться с этапами разработки? Или вам нужна помощь на каком-то из этапов? Заглядывайте к нам, в Moroz Team. Сделаем приложение для вас и поможем, чем сможем)
Ксения Мороз, часть команды Moroz Team, автор статей
Ксения Мороз, часть команды Moroz Team
16 июня 2023 г.

Узнайте больше о процессе разработки

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