Как долго выполняются требования?

Как долго выполняются требования?

Содержание

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

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

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

Как вы можете определить необходимое количество времени и усилий, необходимых для таких действий, как сбор требований? Неудивительно, что данные различных тестов не всегда совпадают друг с другом. Также спорно, похожи ли эти «обычные» проекты на ваши собственные. Чтобы помочь вам решить эту проблему, я адаптировал некоторые идеи из моей книги «Подробнее о требованиях к программному обеспечению» в этой статье — посмотрите!

Отраслевые ориентиры

Чтобы привести пример потенциальной полезности эталонных тестов, см. Таблицу 1. Представленные данные показывают средние отраслевые значения для различных усилий по выявлению требований и созданию прототипов в отношении проектов размером 10,000 XNUMX функциональных единиц (примерно один миллион строк кода), полученных из Каперс Джонс «Оценка программного обеспечения, контрольные показатели и передовой опыт». Насколько уместны эти цифры для вашего собственного проекта?

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

Инструмент управления требованиями ALM

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

Поскольку я работал над небольшими проектами, когда работал в Kodak, наша команда часто выделяла от 15% до 18% от общего объема работы на выполнение требований. Мы обнаружили, что эти инвестиции уменьшили количество необходимых изменений после поставки. Трудно с уверенностью связать причины и следствия, но вполне вероятно, что наша низкая скорость обслуживания была в значительной степени связана с культивированием значительного участия пользователей.

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

Ваш собственный опыт

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

Система управления требованиями

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

Итеративный и инкрементный подходы

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

Базовый уровень требований

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

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

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

Выявление требований к планированию

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

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

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

Не забудьте поделиться этим постом!

Синергия между подходом к системной инженерии на основе моделей и процессом управления требованиями

Декабрь 17th, 2024

11 утра по восточному стандартному времени | 5:8 по центральноевропейскому летнему времени | XNUMX утра по тихоокеанскому стандартному времени

Фернандо Валера

Фернандо Валера

Технический директор компании Visure Solutions

Преодоление разрыва между требованиями и дизайном

Узнайте, как преодолеть разрыв между MBSE и процессом управления требованиями.