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

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

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

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

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

Разберём следующие источники информации об этапах разработки:

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

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

Этапы ГОСТ 34

1. Формирование требований к АС

2. Разработка концепции АС

3. Техническое задание

Этапы ГОСТ 19

1. Техническое задание

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

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

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

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

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

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

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

Этапы ГОСТ 34

4. Эскизный проект

5. Технический проект

Этапы ГОСТ 19

2. Эскизный проект

3. Технический проект

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

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

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

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

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

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

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

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

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

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

Этапы ГОСТ 34

6. Рабочая документация

Этапы ГОСТ 19

4. Рабочий проект

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

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

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

Например, в первом спринте добавили 1-2 базовые функции. Во втором спринте начали улучшать дизайн и добавили ещё 1 функцию. Третий спринт выделили на исправление ошибок, уточнение архитектуры и закрытие технического долга и т. д.

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

Конечно, на этом этапе не только пишут код. Разработчики — это не весь процесс реализации системы. К процессу разработки системы относятся разноплановые специалисты:

Подробнее о нашем сервисе рассказали в предыдущих статьях:

— Лебедь, рак и щука: как руководителю контролировать работу команд, использующих разные инструменты

— Как получить ответ на вопрос «Когда будет готово?» быстро и бесплатно

Этапы ГОСТ 34

7. Ввод в действие

Этапы ГОСТ 19

5. Внедрение

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

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

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

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

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

Этапы ГОСТ 34

8. Сопровождение АС

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

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

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

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

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

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

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

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

А если хотите узнать больше о жизни и работе в айтишечке, следите за анонсами новых статей в нашем Telegram-канале и читайте другие статьи:

— Операция «Ы»: просто о процессе разработки ПО на примере строительства

— Важен ли размер? Маленькие студии разработки против крупных IT-гигантов

— Лебедь, рак и щука: как руководителю контролировать работу команд, использующих разные инструменты