Уровни зрелости процесса управления требованиями

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

Работая над статьей о роли требований в процессе разработки программного обеспечения я обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).

Хочу поделиться с читателями habrahabr данной классификацией.

Введение


Термин «зрелость» – определяется как полное, состоявшееся развитие той или иной системы. Так как любое развитие требует затрат, в контексте бизнеса это означает, что организация принимает решение об объемах инвестиций в собственное развитие, четко понимая какие выгоды она при этом получает.

Ниже приведена шкала уровней зрелости процесса управления требованиями, построенная по аналогии с моделью CMMI. Эти модели никак не связаны между собой, но имеют некоторое пересечение. Так, достижение уровня 5 (Интеграция требований) зрелости процесса управления требованиями позволит получить как минимум уровень 3 (Процессы определены на уровне всей организации) по модели CMMI. Однако это не является прямым следствием, так как достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом.

Шкала зрелости


Уровень 0. Отсутствие требований

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

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

В результате получается продукт, который:
  • не имеет требуемой функциональности;
  • имеет излишнюю функциональность;
  • имеет низкое качество.

Зачастую на почве отсутствия требований появляются споры и непонимание между членами проектной команды, а при смене персонала часть требований может быть просто утеряна.

Уровень 1. Документирование требований

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

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

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

Уровень 2. Организация требований

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

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

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

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

Уровень 3. Структурирование требований

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

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

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

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

Уровень 4. Трассировка требований

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

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

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

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

Уровень 5. Интеграция требований

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

Целью пятого уровня зрелости как раз и является интеграция процесса управления требованиями в процессы управления изменениями, проектирования, разработки, тестирования и управления проектом в целом.

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

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

Комментарии 38

    +2
    Из описания CMMI-0 в каком-то фициальном документе мне понравилось «Производственный процесс подобен хаосу, результат достигается за счет героического усилия отдельных лиц»
      +4
      Вот если бы автор изложил предложенную шкалу с характеристиками отдельных этапов своими словами, исходя из собственного опыта — было бы гораздо интереснее. Сейчас же первое, что приходит в голову при ознакомлении с предложенной классификацией — «поверхностная», «формальная», «местами подменяющая понятия». Впрочем, это могут быть и проблемы перевода. Примеры ниже.

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

      Пример 1.
      «Первый шаг перехода от полного отсутствия требований к их появлению — это выявление и документирование требований.»

      Первый ли? Вот, например, отечественные ГОСТы 19 и 34 серии. Они позволяют документировать требования в ряде простых и непритязательных документов, которые отвечают всем перечисленным в пункте критериям.
      А кроме того, они в своем составе предполагают много чего разного, включая инструменты трассировки, характерные лишь для 4-го уровня предложенной классификации.

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

      «Для продолжения рода нужно совсем другое» (с) «Тот самый Мюнхгаузен»

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

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

      Можно подумать, на других «уровнях зрелости» об этих активностях никто и не помышляет. Например, двумя уровнями ранее, без всяких специальных инструментов запросто происходит и планирование управления, и само управление, и группировка требований.
        0
        Leonid76, я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий. А встречал, когда наоборот — документы по указанным стандартам готовились постфактум и носили формальный характер. Если же требования и готовились перед началам проекта, то исключительно для того, чтобы потешить самолюбие заказчика, повторяющего магическое заклинание: «Техническое задание». После чего про документ забывали и начинали просто «кодить».

        По поводу косноязычия согласен, но уверен, что не один я сталкивался с «трудностями перевода» при чтении документа, написанного литературным языком, но сплошным текстом.

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

          0
          я еще ни разу не встречал

          А я встречаю регулярно. В основном — по 34 серии. Когда и ТЗ, и технорабочий проект — не формальность, а насущная потребность. И в отношениях с заказчиком, и в организации разработки (особенно когда работает несколько команд от разных юрлиц, да еще и раскиданных по разным городам).
          Разумеется, количество таких проектов на нашем ИТ-рынке сильно меньше, чем «сделайте мне магазин, быстро и дешево».

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

          Разве?

          Уровень 3. Структурирование требований
          На данном уровне зрелости возникает необходимость применения специализированных инструментальных средств, предназначенных для работы с требованиями.

          если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме

          Либо о недостатках классификации.

          Поймите правильно — я не стараюсь забросать статью экскрементами. Просто становится не по себе, когда неплохие, в общем, мысли продвигаются в жизнь в такой вот наивной оболочке. Это чревато вполне измеримыми потерями и снижением КПД нашего «производства».

          Кроме всего прочего, такое вот разделение на «уровни взросления» между строк говорит, что 1 — это детский лепет, а 5 — это круто и солидно. Но в реалиях, 5й уровень — это высочайшей цены компромисс между управляемостью и производительностью рабочих команд в масштабах крупных организаций. И у него масса отрицательных эффектов. Один из них — то, что фокус профессионального мастерства «постановщика требований» смещается от содержания к форме (от самих требований к инструментам управления ими). То есть, специалист считается крутым не потому, что он круто обращается с требованиями, а потому, что у него 5-й дан по какому-нибудь энтерпрайз-архитектору.
            0
            разделение на «уровни взросления» между строк говорит, что 1 — это детский лепет, а 5 — это круто и солидно

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

            и еще
            достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом

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

            Что же касается категоричности, то я смягчил формулировку в статье.

            Leonid76, спасибо за обратную связь!
              0
              В свое повествование я вкладывал несколько иной смысл:

              Это неотъемлемый атрибут моделей взросления. Мол, «взрослеть надо, чада неразумные».

              Пришлось бы приложить очень большие усилия, чтобы его нивелировать. Гораздо больше процитированных. А самое главное, делать это особо незачем. Иначе суть подхода теряется.

              принятие решения о достижении того или иного уровня зрелости

              Сейчас звучит примерно как «всё, я решил, что мне теперь есть 18!»
              Наверное, можно принять решение о приведении процессов в соответствие с требованиями того или иного уровня зрелости. Но решить, что «мы теперь зрелые вот на столько» — это вряд ли.

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

              Гм… Скорее, крупная компания не может себе позволить не жертвовать. Иначе у нее будет беда. Исключение — крупные компании, состоящие из относительно маленьких полуавтономных «ячеек».

              спасибо за обратную связь!

              Рад стараться!
            0
            «я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий.»

            ГОСТ 34 — не на программы, а не информационные системы, если вы последними не занимались, немудрено, что вы не встречали :)

            А ГОСТ 19 достаточно простой по сути, там значимых разделов — раз-два и обчёлся, поэтому сейчас распространены более современные стандарты на структуру требований типа IEEE 838: school.system-analysis.ru/standards/
              0
              Что за мещанская склонность к искажению смысла цитируемого текста и желание интерпретировать его в удобном для себя контектсте? А контекст тут простой — самопиар, ведь цитирующий руководит и преподает в указанной Школе.

              Моя фраза полность звучит так:
              Я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий. А встречал, когда наоборот — документы, по указанным стандартам, готовились постфактум и носили формальный характер.

              Кроме того, в ГОСТ'е нет понятия «информационная система», а есть термин «автоматизированная система» (см. ГОСТ 34.003-90). Именно это, а не выдернутая из контекста фраза, иллюстрирует кто с чем не знаком. :)
                0
                зря вы перешли на личности и оскорбления.
                  0
                  Я не считаю это оскорблением, а лишь интерпретацией контекста Вашего комментария.

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

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

              0
              Вы с чем именно не согласны?

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

              В такой ситуации требования должны максимально быстро перемещаться из области идей в задачу разработчику.
                0
                Не согласен с тем, что Вы заведомо усложняете. Разве где-то сказано, что для проверки гипотезы нужно потратить большое количество времени на разработку спецификации по стандарту IEEE 830, например? Скорее наоборот.
                  0
                  Но тогда я не очень понимаю: если для проверки гипотезы нужно что-то запрограммировать, требования на данном этапе будут или нет?
                    0
                    Конечно будут, только их представление может быть разным. Например, в вашем случае это может быть стикер на доске, задача в трекере, документ на одну страницу — все, по чему разработчик сможет понять задачу, а тестировщик разработать сценарий тестирования.
                      0
                      Ок, в классификации из статьи это соответствует первому уровню, верно?
                        0
                        Верно!
            0
            И еще, управление требованиями подразумевает многоэтапное и многоуровневое их согласование. Что, без должного вмешательства, очень сильно растягивает разработку. Поэтому, управляя требованиями, нельзя забывать об эффективности согласовательного процесса между участниками.
              0
              Нет, не подразумевает. Оно вполне может быть, но не обязано.
                0
                Ок, возможно, бывают ситуации когда Заказчик (или Product Owner) написали спеку со своим видением, а разработке остается только взять под козырёк и делать. Но я такого никогда не видел.
                Обычно спеку согласуют как минимум с экспертом по разработке, который должен сказать реализуемо ли это, в какой сррок и какими ресурсами. Если проект большой — таких экспертов несколько. А результат экспертизы может запросто привести к пересмотру требований, т.к. оценочные качество-сроки-ресурсы не устроят заказчика.
                  +1
                  В реальности почти всегда обязательно, т.к. в любом серьезном проекте у лиц, уполномоченных утверждать окончательный вариант требований, нет ни компетенций, ни времени (это просто не их задача) писать требования самим. А раз автор и утверждающий — разные лица, то процесс согласования неизбежен. Продуктовая разработка имеет свою специфику, но там мороки с огласованиями (правда уже внутри компании-вендора) не меньше
                    0
                    Процесс согласования неизбежен. Избежны такие вещи, как многоуровневость и многоэтапность.

                    Пример многоуровневости (как это могло бы быть прописано в Регламенте управления требованиями):

                    Порядок согласования требований.
                    Сформулированное требование согласуется в следующей последовательности:
                    1. С руководителем группы разработки.
                    2. С руководителем проекта ООО «Василек».
                    3. С ответственным за раз/дорабатываемый продукт ООО «Василек»
                    4. С функциональным заказчиком.
                    5. С руководителем проекта от Заказчика.
                    6. С генеральным директором ООО «Василек».
                    7. С генеральным директором Заказчика.


                    Там же, уже про этапы:

                    Этапы согласования требований
                    Для согласования с руководителем группы разработки (РГР) устанавливаются следующие этапы:
                    1. Предоставление требований на ознакомление — не менее, чем за 10 дней до плановой даты их согласования.
                    2. Отработка замечаний и предложений руководителя группы разработки — не позднее, чем за 3 дня до плановой даты их согласования.
                    3. Устранение финальных замечаний — не позднее дня плановой даты согласования требований.

                    Для согласования с руководителем проекта устанавливаются следующие этапы:
                    1. Предоставление требований на ознакомление — не менее, чем за 15 дней до плановой даты их согласования.

                    и т.д.


                    А по факту, аналитик пришел к программисту, спросил «я тут такую хрень придумал, закодить сможешь?». По получении утвердительного ответа пошел к заказчику и сказал: «мы для тебя разработали уникальное, не имеющее аналогов по эффективности решение!...» а дальше — рассказал про то, как замечательно свежепридуманная хрень порешает задачи заказчика до полного восторга у последнего. Менеджер продукта? Нет такого. Архитектор? А ему пофиг. Директор? Да он потом на всем техпроекте оптом распишется.
                      0
                      аналитик пришел к программисту, спросил «я тут такую хрень придумал, закодить сможешь?». По получении утвердительного ответа пошел к заказчику и сказал: «мы для тебя разработали уникальное, не имеющее аналогов по эффективности решение!...»

                      Только потом окажется что программист закодил не то и не через 2 дня а через две недели. И ответит, что о сроках его не спрашивали, а задание он со слов аналитика понял именно так, как сделал. А клиент посмотрев на решение, отказался покупать. И с кого спрашивать, если нет официального согласования?

                      И, главное, где тут формализованные структурированные требования? В словах аналитика?
                        0
                        Только потом окажется что программист закодил не то и не через 2 дня а через две недели.

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

                        А клиент посмотрев на решение, отказался покупать.

                        Он ведь был в восторге и согласился, когда аналитик ему это презентовал?

                        И с кого спрашивать, если нет официального согласования?

                        А если есть? Если же нет — то это или нарушение процесса (в котором заказчик должен поставить согласующие подписи) или риски того же процесса (если «верим на слово»). Может быть и так, и так. И последствия будут разными.

                        И, главное, где тут формализованные структурированные требования? В словах аналитика?

                        Нет их тут. Пример — про важный участок работ под названием «согласование». Давайте считать, что после восторгов заказчика все требования были внесены «куда следует», протрассированы и включены в планы релизов.
                          0
                          Это уже реализация, а не согласование.
                          Так согласование и нужно, чтобы реализация соответствовала требованию, не так ли? Поэтому требование должно быть максимально подробным. И программист, лишь один раз получивший «на орехи» за неверную интерпретацию требований, в следующий раз будет занудно и педантично выяснять все детали, и требовать их письменной спецификации, прежде чем приступит к работе. Это мое наблюдение из практики.
                          Он ведь был в восторге и согласился, когда аналитик ему это презентовал?
                          Так ведь закодили не то что презентовали :)
                          Давайте считать, что после восторгов заказчика все требования были внесены «куда следует», протрассированы и включены в планы релизов.
                          Так это и потребует уйму времени.
                            0
                            Так согласование и нужно, чтобы реализация соответствовала требованию, не так ли?

                            В частном случае — так.
                            Еще раз хочу обратить внимание: эта ветка идет от Вашего поста с утверждением «управление требованиями подразумевает многоэтапное и многоуровневое их согласование». Мои посты в ней — на тему этого утверждения.

                            До согласования и после него с требованиями может происходить много интересного и в разной степени полезного. Здесь я этого вопроса не касался. Только «утверждение», только хардкор.

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

                            В зависимости от того, кто на него смотрит, и от преследуемой цели (согласование — это одно, разработка — другое, тестирование — третье и т.д.), требование может выглядеть очень по-разному (не меняя своей сути). К заказчику мы идем с концепцией требования, программисту отдаем детализацию, с тестировщиком обсуждаем кейсы по требованию.
                +1
                Статья очень спорное впечатление производит. Оказывается, управление изменениями требований уже не ключевая и жизненно необходимая для любого современного проекта активность, а нечто nice to have, что появляется только в идеале — на последнем уровне зрелости. А базовые вещи у нас, оказывается, не забывать картинки в доках нумеровать
                  0
                  Своеобразная интерпретация прочитанного, но Вы имеете на нее право…
                  0
                  Не поверхностно. За это спасибо!

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

                  Я хотел раздавать ссылку на эту статью! Благо есть кому и зачем давать. Пока не допишете — сделать этого не могу.

                  Вопросы, если есть, пишите в ЛС (хотя гугль тоже может подсказать почти все, можно просто брать и копировать заинтересовавшие фразы).
                    0
                    Опять под управлением требованиями понимается разработка требований и управление требованиями.

                    Сходите что-ли сам CMMI почитайте, если уж:
                    www.software-quality-assurance.org/cmmi-requirements-management.html
                    www.software-quality-assurance.org/cmmi-requirements-development.html

                    Это всё равно, что разработку автомобиля называть управлением автомобиля.
                      0
                      Денис, отличные ссылки. :)

                      Во первых строках читаем:

                      Disclaimer: The opinions expressed here are the authors
                      and do not express a position on the subject from the
                      Software Engineering Institute (SEI) or any organization
                      or SEI Partner affiliated with the SEI.
                        0
                        Ну так они же на CMMI основываются, а не на земельном кодексе Зимбабве. Имхо это лучше, чем никаких ссылок на первоисточники, как в статье.
                          0
                          Так и статья автора тоже не на земельном кодексе. И даже ссылка есть:

                          обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).

                          (А даже если была бы на земельном кодексе — какая разница? Гораздо интереснее, что получилось в результате.)

                          Я о том, что собственное мнение авторов по тем двум ссылкам настолько же авторитетно, сколь и собственное мнение нашего автора (в хорошем смысле).

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

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

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

                            Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.

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

                              Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.

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

                              Ну а в автоматизаторской жизни под «управлением» каким-то объектами чаще всего подразумевается активность а-ля CRUD («управление договорами», «управление учебными группами», «управление анкетами» и т.п.). То же худо-бедное управление персоналом — и то начитается с разработки образа будущего сотрудника (а не худо-бедное — с «сот» под образы в виде оргштатки).

                              Про то, как совмещать эти деятельности на практике — отдельный разговор

                              Если применение теории на практике требует большого напильника, то может, с ней что-то не так? Классик утверждал, что теория без практики мертва.
                              Я не призываю отказаться от этих теорий. Они милы и по-своему полезны. Я призываю не применять их как нечто, имеющее абсолютный авторитет. А уж тем более, как прокрустово ложе.
                      0
                      Пара ссылок на ту же тему, на которые почему-то постеснялся сослаться автор:
                      grigorash.ru/archives/905
                      www.ibm.com/developerworks/ru/library/r-requirements/

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

                    Самое читаемое