Общий процесс разработки требований

Общий процесс разработки требований

Если вы не можете описать в виде процесса то, что вы делаете, значит, вы не знаете, что вы делаете.
Вильям Эдвардс Деминг (W.E.Deming), консультант по управлению, 1900-93.
2.1 Введение.
Эта глава знакомит читателя с концепцией процесса разработки систем.
Она начинается с рассмотрения различных возможных способов разработки. Это помогает выделить общие черты, характерные для многих проектов по разработке, и описать шаблон разработки систем, который может использоваться в дальнейшем в различных ситуациях. В данной главе этот шаблон описывается в виде общего процесса разработки систем лишь с некоторыми подробностями. Последующие разделы показывают то, как общий процесс разработки систем может быть применим в конкретных ситуациях.
Здесь же рассматривается связь между моделями процессов и информационными моделями, а так же выводиться информационная модель для общего процесса разработки.
2.2 Разработка систем.
Прежде чем приступать к разработке любой системы необходимо сначала определить для чего эта система нужна. Если же цель создания системы не определена, то совершенно непонятно какой система должна быть и невозможно даже предположить устроит ли разработанная система ее пользователей.
Форест Гамп прекрасно выразил эту идею, когда сказал:.
Если вы не знаете куда идете, то вы вряд ли туда дойдете.
Точность и ясность, с которой формулируются первоначальные потребности, зависит от конкретного человека, который их выражает, и от его позиции в организации.
Изначально потребности могут быть выражены весьма смутно. Например, «мне нужна система, которая бы увеличила эффективность работы моего отдела». Понятно, что такая «характеристика» не является достаточной для того, чтобы выйти с ней на рынок и купить систему. Однако с такой характеристики можно начинать изучение того, что же все-таки человеку нужно. Необходимо исследовать - что в отделе выполняется неэффективно; определить - что именно должно быть улучшено, и выяснить - какими свойствами должна обладать система, чтобы улучшить работу отдела.
Действия, в результате которых из нечеткой первоначальной характеристики потребностей получаются требования, которые могут служить в последствии основой для приобретения или создания системы, и формируют процесс разработки пользовательских требований (stakeholder requirements).
Как уже говорилось выше, к заинтересованным сторонам (stakeholders) могут относиться не только те лица, которые будут непосредственно взаимодействовать с системой, но и те люди и организации, которые так или иначе заинтересованы в существовании системы. Подробно разработка пользовательских требований освещается в Главе 5.
Рис. 2.1 иллюстрирует процесс разработки.
Рис 2.1 Процесс разработки системы.
На приведенной диаграмме для моделей процессов используются следующие графические элементы: с помощью круга (овала) обозначаются процессы, а с помощью прямоугольника обозначаются данные. Стрелки указывают на суть операции с данными данные читаются или записываются. Так на рис 2.1 показано, что процесс разработки пользовательских требований читает (получает) формулировки потребности пользователей и записывает (производит) пользовательские требования.
Помимо этого процесс разработки пользовательских требований производит и читает (использует) модель использования.
Думать о потенциальном решении проблемы можно лишь только после того, как разработан полный набор пользовательских требований, поскольку это означает, что уже определено именно то, что пользователь сможет получить от предполагаемой системы. Далее хорошая практика заключается еще и в том, что вместо того, чтобы сразу переходить к созданию детальных спецификаций системы, нужно сначала определить какие именно характеристики должна иметь система, не вдаваясь в детали реализации.
В этом, как раз, и состоит процесс разработки системных требований. На этом этапе рекомендуется разработать абстрактную модель системы. Несмотря на абстрактность, такая модель очень полезна при обсуждениях внутри команды, разрабатывающей систему, поскольку помогает достичь взаимопонимания и общего (единого) видения будущей системы.
Модель также полезна для объяснения концепций решения тем пользователям и другим заинтересованным сторонам, которые хотят убедиться, что проект движется в правильном направлении. Модель также помогает представить структуру требований в виде документа. Каждый элемент модели может формировать раздел документа. Таким образом, каждое требование попадает в соответствующий контекст, что очень помогает рецензировать готовый набор требований с точки зрения его полноты и завершенности.
Системные требования допускают рассмотрение несколько альтернативных вариантов архитектуры системы. Архитектура определяет набор компонентов, которые, взаимодействуя, порождают требуемые характеристики системы. Эти характеристики являются системными свойствами (emergent properties), которые должны в точности соответствовать требуемым характеристикам системы, описанным в системных требованиях. Модель архитектуры определяет, что каждый компонент системы должен делать и как компоненты системы должны взаимодействовать между собой, чтобы система удовлетворяла заданным системным требованиям. Иными словами, архитектурная модель определяет требования для каждого системного компонента (см. рис. 2.1) с точки зрения функций, которые выполняются компонентом, и обязательств его взаимодействия с другими компонентами. Архитектурная модель системы, а, следовательно, и системные требования для компонентов должны также обуславливать и другие свойства системы, такие как физические размеры, производительность, надежность, и удобство эксплуатации (maintainability).
Для большинства систем (за исключением совсем уж маленьких) компоненты архитектурной модели могут быть достаточно сложными для того, чтобы реализовывать их как единое целое. В этом случае компоненты зачастую называют «подсистемами», поскольку их сложность позволяет рассматривать их как самостоятельные системы со своими собственными правами. Но это лишь вопрос терминологии, поскольку даже в этом случае эти подсистемы все равно являются лишь составной частью (компонентом) для системы более высокого уровня.
Процесс разработки архитектурных моделей для каждой подсистемы и последующего получения требований для каждого компонента подсистемы выглядит так же, как и описанный выше процесс разработки архитектурной модели для самой системы. В конечном итоге все сводится к тому, что необходимо разработать архитектурные модели для каждой подсистемы и для всех входящих в них компонентов, как это показано на рис. 2.1.
Описанный процесс разработки также показывает, что разработка системы происходит на разных уровнях, и что на каждом из них выполняются различные действия. Так рис. 2.1 демонстрирует, что процесс разработки на каждом уровне поддерживается моделями (модель использования, абстрактная модель, архитектурные модели), но природа моделей на каждом из уровней существенно отличается. Это пример распространенного подхода на каждом уровне разработки используется своя модель. Последующие разделы данной главы описывают другие общие идеи, на которых базируется общий процесс разработки требований.
При этом весьма важно понимать, что на каждом уровне существуют собственные требования:.
• формулировка потребностей (необходимости);.
• пользовательские требования;.
• системные требования;.
• требования для компонентов системы;.
• требования для компонентов подсистем.
Следовательно, разработка требований это не что-то такое, что можно сделать один раз и потом забыть. Работа над требованиями происходит на каждом отдельном уровне и часто происходит на разных уровнях одновременно.
Так, начиная с уровня требований к системным компонентам, происходит множественная и одновременная работа над требованиями на каждом нижнем уровне (на рис. 2.1 это выделено серым фоном).
2.3 Контекст общего процесса.
На рис. 2.2. представлен иной взгляд на процесс разработки требований.
Диаграмма демонстрирует, что один и тот же процесс - процесс разработки требований применяется на каждом уровне, хотя ранее были описаны различия в работе на разных уровнях процесса разработки системы. Такой странный, на первый взгляд, подход описания процесса разработки всего лишь говорит о том факте, что существует много общего в работе, выполняемой на разных уровнях.
И хоть целью данной главы является описание таких вот общих аспектов и представление общего подхода к процессу разработки требований, тем не менее, описание процессов будет включать и различия в них, что даст более широкие возможности использования полученных знаний.
Важно отметить тот факт, что при многоуровневой разработке, каждый уровень требует соответствующих знаний и опыта (экспертизы).
На верхнем уровне очень важно знание предметной области, которая соответствует области проблем. На системном уровне важно получить общее представление о системе, чтобы избежать слишком узкого (чересчур детализированного) понимания пользовательских требований. На этом уровне неизбежно появляется уклон в сторону определенного решения. На этой стадии целесообразно и необходимо привлекать людей (организации), которые до этого имели опыт успешной реализации аналогичных систем. Аналогичным образом, разработчики подсистем должны привносить свои знания и опыт, ранее полученные при разработке похожих подсистем.
Следовательно, вряд ли одни и те же люди будут участвовать в разработке на каждом из уровней. Даже если представители одной организации работают на всех уровнях, скорее всего, это будут разные люди, часто из разных отделов, или подразделений.
Поэтому очень полезно придерживаться той идеи, что на любом из уровней работа ведется с единственной целью - удовлетворить условного «заказчика» с более высокого уровня, для чего необходимо привлекать к работе «поставщиков», находящихся уровнем ниже.
Рис. 2.2 Различные уровни разработки требований.
2.3.1 Входящие и производные требования.
Рис. 2.3 является альтернативным представлением рис. 2.2.
Рис.2.3 Определение входящих и производных требований для основного процесса.
На рис. 2.3 каждый индивидуальный процесс детализирован, что подчеркивает тот факт, что требования, получаемые из одного процесса, становятся входящими для другого процесса.
Это естественным образом подводит нас к идее, что процесс разработки требований - это процесс преобразования входящих (с более высокого уровня) требований в производные требования, которые, в свою очередь, являются входящими для следующего уровня.
2.3.2 Стратегия проверки и критерии приемки.
Прежде чем объяснять нюансы процесса разработки требований, необходимо обратить внимание на то, что существует другой тип информации, который также является входящим и производным для процесса разработки требований.
Это информация, связанная с проверкой реализации требований.
Для того чтобы полностью осознать всю важность работы с требованиями, и для того, чтобы требования стали хорошей базой для разработки системы, необходимо задуматься над тем, как будущая система (или ее компонент) сможет продемонстрировать, что она удовлетворяет заданным требованиям. Частично это достигается путем формулирования для каждого из требований такого проверочного критерия, который будет впоследствии использован для того, чтобы ответить на простой вопрос - удовлетворяет ли разработанная система требованиям заказчика.
При этом также необходимо определить условия, в которых будет производиться проверка соответствия системы критериям приемки. В первой главе мы знакомились с планами тестирования для каждого уровня разработки требований. Как уже говорилось, тестирование - это только один из типов проверки, но существуют и другие - опытные и стендовые испытания, инспекции и рецензирование. Применяемые типы проверки во многом зависят от характера системы. Например, система, которая связана с угрозой жизни и здоровью, должна проверяться намного более тщательно, нежели та, которая связана с управленческой отчетностью.
Как обобщение вышесказанного на рис. 2.4 показан полный контекст процесса разработки требований.
Часто бывает так, что стратегия создаваемой проверки сама полностью формирует требования для тестового оборудования или добавляет новые требования к уже используемым тестовым установкам, или требует включения в систему дополнительных диагностических функций или контрольных точек. Зачастую это даже преобразуется в отдельный проект для разработки тестового оборудования и других необходимых приспособлений. Например, для авиационного электронного оборудования необходимо выполнить как можно больше тестов до того, как оборудование будет установлено на самолет (по причинам безопасности и себестоимости). И все равно, - даже после установки оборудования на самолет, - необходимо выполнить симуляцию функционирования таких (всех) устройств на земле до начала испытательных полетов. До выполнения первого полета, летчик-испытатель должен быть уверен, что оборудование надежно и работает в соответствии с принятыми нормами и стандартами.
На нижних уровнях, стратегия проверки может определять, должен ли поставщик проверять каждую поставляемую деталь (компонент). Возможные стратегии предусматривают проверку каждого элемента до поставки, проверку групп элементов, или случайную выборочную проверку элементов потребителем.
Рис. 2.4 Значение стратегии проверки.
2.4 Введение в основной процесс разработки требований.
Установив контекст процесса разработки требований, мы может теперь заглянуть и внутрь процесса.
Сначала мы опишем процесс разработки требований для идеального мира, в котором никогда и ничего не меняется, а затем подкорректируем этот процесс, памятуя, что мы живем в постоянно изменяющемся мире.
2.4.1 Идеальный мир.
На рис. 2.5 показан процесс разработки требований для идеального мира.
Процесс начинается с необходимости согласования входящей информации (требований) с заказчиками, находящимися на уровень выше.
На втором этапе необходимо провести анализ входящей информации и понять, как из нее получить требуемую выходную (производную) информацию. Этот этап обычно проходит параллельно с первым и подразумевает создание моделей и аналитических отчетов, которые являются основой для разработки производных требований и стратегии проверки требований следующего (нижнего) уровня.
Как только производные требования становятся в достаточной степени сформированными необходимо начать их согласование с исполнителями, работающими на следующем уровне.
На рис. 2.5 показано, что при таком подходе возможна разработка нескольких пакетов производных требований. При этом каждый из этих пакетов должен быть согласован с соответствующим исполнителем, что отнюдь не исключает того, что один исполнитель может отвечать за реализацию несколько пакетов требований.
Рис. 2.5 Процесс разработки требований для идеального мира.
2.4.2 Разработка требований в контексте изменений.
К сожалению или к счастью, но жизнь никогда не стоит на месте. Это особенно сильно заметно в области разработки систем. Создается такое впечатление, что все только и делают, что постоянно меняют свое мнение, утверждая, что-то, что было согласовано ранее, теперь просто категорически неприемлемо.
А раз так, то, следовательно, и процесс разработки требований необходимо адаптировать к изменениям, так как показано на рис. 2.6.
Степень формальности отношения к изменениям зависит от характера проекта и от стадии, на которой он находится.
На ранних стадиях проекта, чтобы проект быстрее двигался вперед, изменения должны предлагаться чаще и приниматься легче.
После того, как требования формально согласованы, обычно рекомендуется уже более строго (формализовано) подходить к принятию и внесению изменений, для того чтобы изменения не вносились по прихоти, например, какого-либо одного из участников проекта. Для этого используется формальная процедура, когда изменения вначале предлагаются (но не вносятся), а затем рассматриваются в контексте их возможного влияния, которые они могут оказать на весь проект в целом.
Рис. 2.6 Процесс разработки требований в контексте изменений.
Процесс оформления решения по поводу принятия внесения или отклонения конкретного изменения обычно требует участия руководителя проекта иили группы по контролю изменений. Как уже говорилось, степень формальности, с которой эти люди должны рассматривать конкретное изменение, зависит от характера проекта.
Тема контроля изменений, как часть процесса управления проектом, будет рассмотрена более подробно в Главе 8.
Как следует из рис. 2.6, практически любое действие в рамках процесса разработки требований может привести к изменениям, и эти изменения обычно распространяются вверх. Это не означает, что заказчик никогда ничего не меняет, что все проблемы находятся на нижних уровнях, и «вытекают» из того, что разработка ведется «сверху вниз». Просто движение сверху вниз уже учтено в рамках основного процесса и теперь необходимо также учесть и обратную связь.
Одна из возможных ситуаций, когда может возникнуть необходимость внесения изменения, это, например, обнаруженные ограничения модели или проблемы, аналитически выявленные при или попытке получения производных требований, или даже при разработке стратегии проверки для производных требований.
Запрос на изменение (или предложение изменения) (change request) может предусматривать не только изменение модели-ей, но иили проведение дополнительного анализа для более полного исследования проблемы. Также на этапе анализа и моделирования могут быть найдены проблемы, связанные с входящими требованиями, и поэтому создан запрос на внесение изменения в процесс согласования требований.

Популярные статьи

Свежие статьи