Процессы с предварительным проектированием

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

Основным отличием от легковесного подхода является наличие двух циклов: проектировочного и цикла разработки.

На этапе проектирования участвуют:

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

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

На этапе разработки участвуют:

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

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

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

Разработка по требованиям

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

При описании бизнес-процессов, правил и ограничений, на основе пожеланий создаются бизнес-требования. Это могут быть документы BRD, описание бизнес-кейсов или бизнес-процессов. На основе бизнес-требований создаются производные системные требования, например, в формате вариантов использования, спецификаций, UML-моделей и т.п. Если на проекте формализация бизнес-требований не нужна, то на основе пожеланий сразу создаются системные требования: спецификации или отдельные варианты использования, макеты, UML-модели.

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

Согласование требований реализуется через дополнительные статусы требований. Таким образом вы можете организовать последовательный или параллельный процесс согласования документации. Для привлечения представителей закачзика к согласованию, отправьте им по почте ссылку на документ (операция "Поделиться"). Согласующие смогут оставить свои комментарии и оставить резолюцию.

Когда техническая документация подготовлена, документы можно выгрузить в подходящий формат и передать электронно или распечатать. Либо вы организуете цикл разработки на платформе Devprom ALM.


План реализации требований можно представить в виде релизов или итераций.

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

Передача требований в разработку происходит путем создания доработок (укрупненных задач на разработку). Доработку можно создать на весь документ, на все требования в документе (кнопка Реализовать) или при помощи массовой операции "Реализовать" над произвольным подмножеством требований. После того как разработка распланирована, можно приступить к проработке документации на следующий релиз. Для этого создается бейзлайн с названием очередного этапа. Изменения, которые будут вноситься в документацию не повлияют на ранее запланированные доработки.

На доске разработки расположены все доработки и ошибки, которые необходимо реализовать в плановом релизе или итерации. У доработок свой жизненный цикл, отличающийся от жизненного цикла пожеланий. Каждая доработка обычно проходит несколько стадий технологического процесса: разработку (то есть создание программного кода), тестирование и документирование. Вы можете добавить собственные стадии производства, например, проектирование. На этой стадии можно создавать модели, программные интерфейсы или макеты UI на основе ранее утвержденных требований. Более того, вы можете заменить процесс Kanban на Scrum, если в данном проекте это добавит эффективности.

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

Плюсы

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

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

Минусы

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

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

Требования

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

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

Разработка по ГОСТ

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

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

Стадия Этапы
Формирование требований

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

2. Сбор требований - собираем пользовательские требования, хотелки, формулируем цели и задачи будущей автоматизации. Пользовательские требования заводим в список пожеланий и распределяем работу над ними при помощи задач.

3. Заявка на разработку - информацию, собранную в результате обследования и сбора требований, систематизируем в заявке (документе), которая ляжет в основу будущей концепции ПО.

Разработка концепции

4. Изучение объекта - детальное изучение предметной области, выполнение исследований (НИР и Proof of Concept, PoC), снятие всех открытых вопросов, возникших на предыдущей стадии.

5. Разработка концепции - высокоуровневый документ, описывающий проблемы, решения и общую схему ПО. В англоязычной литературе используется термин "Vision" (вИдение). Задача концепции - зафиксировать области автоматизации, роли и пользователей, смежные системы, этапность разработки и ввода в эксплуатацию.

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

7. Разработка проектных решений - этап, на котором готовится основная техническая документация: варианты использования, UML-модели, макеты UI и другие виды системных и технических требований. Доработки, сформированные на предыдущей стадии проходят цикл проектирования. Распределить работу по нескольким проектировщикам можно при помощи задач. Результаты проектирования сводятся в документы с системными требованиями, например, спецификации.

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

Рабочая документация 9. Осуществляется разработка и тестирование приложений, стабилизация и исправление обнаруженных дефектов. Подготавливается и дорабатывается необходимая документация: проектная, конструкторская, эксплуатационная и т.п.
Ввод в действие 10. Производится внедрение ПО, его частей и связанных систем. Также осуществляется настройка и исправление обнаруженных дефектов, обучение персонала, разработка эксплуатационной документации.