Что такое стадия разработки

Что такое стадия разработки

Какие основные шаги в создании программного обеспечения и какие специалисты в этом задействованы? В этой статье, Сергей Зыков, Product Manager в EPAM Latvia, описал жизненный цикл разработки ПО по Agile-методологии и поделился своим опытом в этой области.

Жизненный цикл разработки ПО по Agile-методологии (Agile SDLC) – это процесс разработки ПО, учитывающий изменения требований, рыночные условия и потребности клиентов. Он основывается на сотрудничестве, командной работе и постоянном совершенствовании.

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

Этап планирования

Планирование является начальной стадией жизненного цикла разработки ПО. Проектная команда работает со стейкхолдерами, чтобы определить жизнеспособность и ценность продукта, а также возможность его реализации. Наилучшим результатом будет сформированная стратегия по продукту, которая определяет видение, цели, объемы и минимально жизнеспособный продукт (MVP – minimum viable product), а также содержит задокументированные требования и бэклог продукта (перечень функций, которые тот должен иметь). Ключевыми людьми здесь являются менеджеры/владельцы продукта и бизнес-аналитики. Затем команда решает, какие технологии и ресурсы использовать для создания продукта. За это отвечают деливери-менеджер и архитектор решений.

Этап проектирования

На этом этапе, проектная команда начинает работать над архитектурой и UI/UX продукта. Дизайнеры создают первые каркасы, макеты и прототипы, чтобы помочь стейкхолдерам визуализировать финальный продукт и проверить пользовательский опыт. Крайне важно предложить что-то материальное как можно быстрее, чтобы ускорить обратную связь от стейкхолдеров, а в идеальном мире еще и конечных пользователей.

Этап разработки

Проектирование завершено. Что дальше? Начинается стадия разработки. Команда начинает строить продукт, применяя итеративный и инкрементальный подход, или иначе – спринты. Они делят бэклог продукта на меньшие, осуществимые задачи, которые называются историями пользователей, а затем определяют их приоритетность, оценивают и работают над ними в последовательности, установленной бэклогом продукта. Как правило, команда состоит из владельцев продукта, разработчиков, бизнес-аналитиков и QA-инженеров.

Этап тестирования

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

Этап развертывания

Следующий этап в этом процессе – развертывание. Чтобы убедиться, что продукт работает правильно, команда разворачивает его в производственной среде и проводит последний раунд тестирования и проверки. DevOps-инженер настраивает среды и конвейеры и управляет процессом развертывания.

Этап обслуживания

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

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

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

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

Мы, Moroz Team, в предыдущих статьях обозначили основные проблемы бизнеса в разработке ПО и наметили пути решения проблем с компетенцией команды. Пришло время разобраться с процессом.

Строительство и разработка ПО очень сильно похожи между собой. У каждого из них есть цель по созданию некоторого результата. Есть ограничения по срокам и бюджету. И в каждом случае для достижения результата применяется некоторый подход.

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

И в разработке, и в строительстве присутствуют следующие части-кирпичики процесса:

• стадии (крупные этапы)
• направления деятельности (или умным словом дисциплины)
• роли исполнителей, специалистов
• задачи, которые выполняют исполнители
• результаты деятельности (или ещё одним умным словом артефакты)

Смешаем все кирпичи в кучу, чтобы понять, как они работают вместе.

Наша цель — создать продукт, который работает. В заданном объёме, в заданный срок и выделенный бюджет. Чтобы это сделать, нам нужно:

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

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

Стадиями или фазами являются значительные периоды проекта. Каждый период заканчивается контрольной точкой для принятия важных решений. Расскажу о стадиях жизненного цикла проекта на примере методологии UP (Unified Process).

1. Начальная стадия (Inception)

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

Т.е. заказчик и исполнитель должны определить, для кого они делают дом, каким он должен быть, и каким способом будут его строить. Например, будут ли его строить с нуля или распечатают готовые блоки на 3D-принтере. Если договорились — проект запущен.

2. Развитие (Elaboration)

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

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

3. Конструирование (Construction)

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

Здесь начинается непосредственное строительство: от фундамента до отделочных работ. В итоге должен получиться готовый дом.

4. Внедрение (Transition)

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

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

Основные направления в разработке ПО:

• Бизнес-моделирование
• Требования
• Проектирование
• Реализация
• Тестирование
• Развёртывание
• Управление проектом
• Окружение
• Маркетинг и сопровождение

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

В строительстве существуют не только строители. Также и в разработке есть не только разработчики. Вот некоторые из основных ролей, которые есть в процессе разработки:

• Аналитик
• Архитектор
• Владелец продукта (product manager или product owner)
• Дизайнер пользовательского интерфейса (UI) или пользовательского опыта (UX)
• Инженер DevOps
• Маркетолог
• Методист процесса (например, scrum-мастер)
• Разработчик
• Руководитель проекта (project manager)
• Сотрудник поддержки
• Тестировщик (QA-инженер)
• Технический писатель

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

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

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

— анализ предметной области

— сбор и формирование требований

— документирование требований (ведение базы знаний)

Владелец продукта:

— разработка видения продукта

— управление бэклогом продукта

— планирование итераций (спринтов)

Разработчик:

— проектирование программных решений

— их реализация и отладка (преобразование в программный код)

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

Результатом каждой задачи является некоторый артефакт. Вот несколько примеров артефактов, которые создают и за которые отвечают уже привычные нам роли:

— модель предметной области

— спецификация требований (например, в виде технического задания)

Владелец продукта:

— план итерации (спринта)

Разработчик:

— программное решение (как результат проектирования)

— текст программы (программный код)

— версия системы (сборка)

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

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

Вот несколько примеров, когда отсутствие процесса ни к чему хорошему не приводит:

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

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

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

Чтобы понять, насколько вы способны изобретать велосипед и делать свой процесс, обратимся к понятию «сю-ха-ри».

Занимаясь айкидо, мы постигаем понятие сюхари (Shu Ha Ri) — это одновременно и концепция боевых искусств, и показатель уровня мастерства.

Состояние Сю («соблюдать») — первая ступень, когда вы тренируетесь многие годы, повторяя за учителем все приемы и движения; вы исполняете их словно танцевальные фигуры, и ваше тело их впитывает. Вы не вносите никаких изменений, так как не имеете права отклоняться от правил.

Состояние Ха («прорываться») — вторая ступень, когда вы, овладев всеми приемами и правилами, можете освободиться от них и начать импровизировать. Посвингуйте, исполняя мелодию танго.

Состояние Ри («отделяться») — третья ступень, когда вы настолько овладели мастерством, что освобождаетесь от приемов и движений; теперь вы выше всех правил и способны беспрепятственно созидать. Айкидо или танго стали вашей сутью, и в каждом вашем шаге заложен их смысл.

Если вы находитесь на стадии «Сю» в разработке и пока не знаете нюансов, стоит пока повторять за профессионалами. Благо, существует уже почти вековая история развития индустрии.

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

На стадии «Ри» вы уже можете делать процесс по своим правилам и обучать ему других.

Важно не перескакивать эти стадии. Совершенствоваться постепенно и осознанно. И не останавливаться.

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

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

Не старайтесь сразу же сделать ваш процесс идеальным. Начните с малого и постоянно совершенствуйтесь. Следуйте по ступенькам СЮ-ХА-РИ. Адаптируйте процесс под себя и создавайте новые правила, которым станут подражать другие.

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

Если вам не терпится опробовать внедрение или устранение узких мест в вашем процессе разработки на практике, приходите к нам в Moroz Team. Поможем, чем сможем)

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

За анонсами новых статей можете следить в нашем Telegram-канале.

Хороший разбор, спасибо

Состояние СЮХАРИ на самом деле должно постоянное мелькать в голове и оно позволяет не забывать о том ,что нужно выходить на новый уровень

Роли есть, задачи есть, хотелки есть, многа букав. Блупринта нет. А дом строят по блупринту. Просто берут и довольно тупо строят, без танцев с бубном и "смешиванием кирпичиков".

We can even compare a software development blueprint to something similar to constructing a building. Raising a building from scratch requires having a plan. Architects refer to such a plan as a blueprint. It is an intricate plan of the building that is going to be constructed and is enriched with minute details including measurements, materials used, etc.

In software parlance, a blueprint is the high-level plan or outline depending on which the end product, that is the software, is going to build. It specifies the technical specifications, and the resources necessary for creating the software or even act as a template depending on which more software products will develop. Further, the end product created using the blueprint would also work and perform as per user requirements and expectations.

Читая такие статьи не могу избавится от ощущения (субъективного) что авторы играются в разработку frontend, красиво обрамляя себя в околоайтишный смузихлебско-инфоцыганский контекст ).

36. Стадии и этапы разработки программного обеспечения

Пре-альфа. Начальная стадия разработки — Период времени со старта разработки до выхода стадии Альфа (или до любой другой, если стадии Альфа нет).

Альфа. Внутреннее тестирование — Стадия начала тестирования программы в целом специалистами-тестерами, обычно не разработчиками программного продукта, но, как правило, внутри организации или сообществе разрабатывающих продукт.

Бета. Публичное тестирование — Стадия активного бета-тестирования и отладки программы, прошедшей альфа-тестирование (если таковое было). Программы этого уровня могут быть использованы другими разработчиками программного обеспечения для испытания совместимости.

Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия-кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексноетестирование, благодаря чему были исправлены все найденные критические ошибки.

Релиз или RTM (англ. release to manufacturing промышленное издание) — издание продукта, готового к тиражированию. Это стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки, но существует вероятность появления новых, ранее не замеченных, ошибок.

37. Жизненный цикл программного продукта

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

38. Техническое задание, как этап разработки программного обеспечения

— исходный документ для разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).

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

ТЗ разрабатывается заказчиком для разработчика

39. Требования, предъявляемые к разработке технического задания

Требования к автоматизированным функциям

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

Требования к информационному обеспечению.

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

Требования к эргономике и технической эстетики

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

Требования к Программному обеспечению.

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

Требования к лингвистическому обеспечению.

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

Требования к надежности.

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

Особенности и основные этапы разработки ПО – специфика и принципы работы

Сегодня в мире тысячи программ и приложений, имеющих разное назначение. Главная задача любого ПО – решение потребности конкретной целевой группы. Однако разработка софта – сложная работа. Для ее выполнения требуется квалификация, опыт, знания со стороны разработчиков. При этом речь не только в сложности кода конкретного языка программирования. Любое веб-приложение или прикладная программа должна быть удобной, практичной, функциональной и интуитивно понятной.

Любая программа должна иметь преимущества, быть реализованной в короткие, оговоренные сроки. Это важно, чтобы конкуренты не смогли перехватить инициативу. Ведь если процесс разработки и тестирования затягивается, момент благоприятного выхода на рынок может быть упущен. Особый момент – функционал. Ведь ПО должно решать проблему целевой аудитории. В таком случае софт будет востребован, станет популярным среди активных пользователей.

Главные этапы разработки ПО и особенности их прохождения

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

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

Пять этапов разработки ПО

Для начала рассмотрим жизненные этапы разработки ПО, которые обозначаются аббревиатурой SDLC (Software development lifecycle). Это определенный цикл, состоящий из 5ти этапов, через которые проходит любая программа при разработке.

1. Сбор требований и их анализ

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

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

Чаще всего для этого разрабатывается SRS (Software Requirement Specification) – документ, в котором содержатся основные требования, которые предъявляются к программному продукту. Разработчикам важно точно выявить желание клиента, определить сроки разработки проекта. Здесь главная проблема — многостраничный список требований. Для их решения необходимо тесное взаимодействие с заказчиком, акцент на высокоуровневых требованиях.

2. Разработка дизайна для программного продукта.

Создаваемый софт должен быть не только функциональным, но также удобным, понятным для пользователя. Для этого требуется правильно разработать архитектуру, способ представления программы, его пользовательский интерфейс, графическое решение. Особое внимание нужно уделить дизайну, где ориентируются на Software Requirement Specification (сокр. SRS).

SRS – документ, в котором закрепляется перечень требований и свойств, которые предъявляются к правильной, корректной работе программы. Разработчиком и дизайнером нужно понять, в какой форме должен быть представлен продукт. Сделать это непросто. Сам заказчик зачастую не знает этого, полагаясь на опыт, квалификацию программистов.

Для этого обычно каждый из разработчиков предлагает свой подход. После все документируется в DDS (Design Document Specification). Далее информация анализируется, выявляются требования и связи архитектурного модуля продукта с внешними модулями. Чтобы добиться успеха, важно иметь в команде грамотных лидов, способных предложить оптимальную архитектуру на основе опыта выполнения аналогичных проектов.

3. Непосредственная разработка программного обеспечения

После того, как разобрались с архитектурой, согласовали функционал, дизайн и концепцию, приступают к разработке софта. Пишут программный код, выполняют сборку, последовательно создают необходимые модули и фичи согласно утвержденному DDS. Практика доказывает, что чем более четкими являются требования в Design Document Specification, тем лучше происходит имплементация.

Рассмотрим трудности, с которыми сталкиваются разработчики на данном этапе.

4. Тестирование продукта

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

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

5. Внедрение и поддержка продукта

После устранения всех багов, ПО выходит в релиз. Начинается поэтапное внедрение программы согласно выбранной бизнес-стратегии. Изначально софт может быть выпущен в ограниченном сегменте, протестирован в конкретной бизнес-среде. Для этого выполняют UAT-тестирование (User Acceptance Testing). В его основе — получение реальных отзывов со стороны.

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

Иногда заказчик предпочитает устанавливать сервера приложений в своей внутренней сети, а не в Google, Azure или AWS. Менеджер должен заранее проинформировать клиента о том, что команда разработчиков не сможет таком случае гарантировать стабильную работу ПО.

Данные этапы разработки ПО выполняются в рамках каскадной («водопад») модели. Она является распространенной, востребованной. Существуют и другие — итерационная, спиральная, гибкая (Agile Model), быстрая (RAD Model), прочие.

Выбор конкретной модели жизненного цикла остается за командой разработчиков. Заказчику важно получить результат. Механизм разработки и внедрения продукта его обычно интересует мало.

Что будет, если не соблюдать этапы разработки ПО

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