1-software_engineering_requirements (1133541), страница 5

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

Текст из файла (страница 5)

Недопонимание между аналитиком и пользователем, упущение тех или иных аспектов, напервый взгляд кажущихся второстепенными, неоднозначность или тем более некорректностьинтерпретации информации, полученных от пользователей – все это наиболее типичные причины“сверх-затрат” (времени, денег и т.п.), а иногда, и полного провала проектов.Существует множество практик и подходов, позволяющих добиться действительно стройнойсистемы требований, отвечающих реальным потребностям и приоритетам заказчиков. Среди нихможно выделить следующие:Интервьюрирование – традиционный подход извлечения требований; не стоит забывать, чтополучение информации от пользователя “не равно” получению требований; информациядолжна быть проанализирована и трансформирована в требования, таким образом,информация от пользователя является “входом” в процессы сбора требований, а самитребования – “выходом” этих процессов;Сценарии – контекст для сбора пользовательских требований, определяющий ответы навопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемыхпользователями;Прототипы – отличный инструмент для уточнения и/или детализации требований;существуют разные подходы к прототипированию – от “бумажных” моделей до пилотныхподсистем, реализуемых как самостоятельные (в терминах управления ресурсами) проектыили бета-версии продуктов; часто прототипы постепенно трансформируются в результатыпроекта и используются для проверки и утверждения требований;“Разъясняющие встречи” - в оригинале звучит как “facilitated meetings”; достаточно емкий посмыслу термин, пришедший из общей практики менеджмента и базирующийся на идеяхсотрудничества заинтересованных лиц для совместного анализа путей решения проблем,определения и предупреждения рисков и т.п.

В отличие от “обычного”, с позволения сказать,“мозгового штурма”, как исключительной формы обсуждения тех или иных задач (часто вкритические моменты работ над проектом), “запланированный мозговой штурм” – особаяформа встреч участников проекта и заинтересованных лиц со стороны заказчика,посвященная обсуждению тех вопросов, ответы на которые не могут быть определены вCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru11Основы программной инженерии (по SWEBOK)Программная инженерия.

Программные требования.результате обычных интервью и которые требуют вовлечения большего количества лиц, чемпросто пары “пользователь-аналитик”; я позволили себе сконструировать на русском языкеэтот термин еще и как “запланированный мозговой штурм”, так как такого рода встречидействительно обычно планируются с заданной периодичностью для обеспеченияоднозначности интерпретации информации, значимой для проекта и, что очень важно –проведения таких встреч до того, как связанные с данными вопросами риски непревратились в реальные проблемы, требующие решения “вчера”, а, следовательно, идополнительных (изначально незапланированных) ресурсов времени, денег и т.д.;Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков иинженеров рядом с пользователем в процессе выполнения последним его работ пообеспечению функционирования бизнес-процессов: в определенной степени можно провестианалогию с практикой присутствия представителя заказчика в проектной группе исполнителя( типовая практика в eXtreme Programming “on-site customer” – “присутствующий заказчик”);данная техника является достаточно затратной, но, в то же время, очень эффективной, аиногда – просто незаменимой, особенно, если речь идет о достаточно сложных ивзаимосвязанных бизнес-процессах;Существуют и другие, достаточно эффективные практики, описание которых можно найти влитературе и которые вы, наверняка, сами используете в своей работе (например, RequirementsWorkshop, Role Playing, Storyobarding и т.п.).

Некоторые из них будут также упоминаться в контекстеконкретных методологий.4. Анализ требований (Requirements Analysis)Эта секция посвящена процессам анализа требований, то есть трансформации информации,полученной от пользователей (и других заинтересованных лиц) в четко и однозначно определенныетребования, передаваемые инженерам для реализации в программном коде.Анализ требований включает: Обнаружение и разрешение конфликтов между требованиями; Определение границ задачи, решаемой создаваемым программным обеспечением; в общемслучае - определение “scope” (или “bounds”), границ и содержания программного проекта; Детализация системных требований для установления программных требований;Практически всегда, хотя это явно и не отмечено в описании анализа требований как секцииSWEBOK, на практике выделяется и детализация бизнес-требований для установленияпрограммных требований.

Например, пресловутый режим работы 24x7, сформулированный в видебизнес-требования, накладывает достаточно жесткие рамки на выбор технологической платформы иархитектурных решений как технических требований к разрабатываемой программной системе..SWEBOK отмечает, что традиционный взгляд на анализ требований часто сфокусирован илиуменьшен до вопросов концептуального моделирования с использованием соответствующиханалитических методов, одним из которых является SADT – Structured Analysis and Design Technique(методология структурного анализа и техники проектирования), знакомый многим по нотациям IDEF0(функциональное моделирование – стандарт IEEE 1320.1), IDEF1X (информационноемоделирование – стандарт IEEE 1320.2, известный также как IDEFObject), часто применяемым какдля моделирования бизнес-процессов, так и структур данных, в частности – реляционных базданных.Так или иначе, вне зависимости от выразительных средств, которые являются лишь инструментоманализа и фиксирования результатов, результатом анализа требований должны быть однозначноинтерпретируемые требований, реализация которых проверяема, а стоимость и ресурсы –предсказуемы.4.1 Классификация требований (Requirements Classification)Требования могут классифицироваться по целому ряду параметров, например: Функциональные и нефункциональные требования Внутренние (с другими требованиями) или внешние зависимости Требования к процессу или продуктуCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru12Основы программной инженерии (по SWEBOK)Программная инженерия.

Программные требования.Приоритет требованийСодержание требований в отношении конкретных подсистем создаваемого программногообеспеченияИзменяемость/стабильность требованийДругие варианты классификации могут, и часто базируются, на принятых в организации подходах,применяемых методологиях, методах и практиках, а, зачастую, и специфике проектов и дажетребованиях заказчиков к процессу разработки и, в частности, определения требований и формепредставления результатов их анализа.4.2 Концептуальное моделирование (Conceptual Modeling)Разработка модели проблемы реального мира – ключевой элемент анализа требований.

Цельмоделирования – понимание проблемы, задачи и методов их решения до того, как начнется решениепроблемы.Часто приходится слышать, что прагматичность подхода в отношении программных проектовзаключается в “пропуске” этапа (или стадии, фазы) моделирования. В свою очередь, часто ставятзнак равенства между моделированием и “этими красивыми квадратиками со стрелочками”. Ни то, нидругое утверждение неверны. Например, в XP и в других гибких (Agile) практиках существуют иистории пользователей, и карточки задач, и процедуры анализа (в частности, связанных с ними“мозговых штурмов”, как запланированных, так и, к сожалению, не очень) , в результате которого мысформулировали задачи, высокоуровневые возможности - “фичи” продукта (feature - особенность), атакже необходимые модели (см.

[Амблер, 2002]). Объем моделей, их детализация и средствапредставления могут быть различны. Их выбор базируется и/или диктуется конкретным культурнымконтекстом организаций, вовлеченных в проект, и практик, применяемых проектной группой. Именноне форма, но сама идея моделирования как попытка упростить и однозначно интерпретировать наконцептуальном уровне проблематику деятельности в реальном мире – обязательная составляющаякак управления требованиями, так и программной инженерии, в целом.Среди факторов, которые влияют на выбор модели, метода и детализации ее представления,степени связанности с программным кодом и другими вопросами: Природа проблемы (проблемной области) Экспертиза и опыт инженеров Требования заказчика к процессу Доступность методов и инструментов Внутрикорпоративные стандарты и регламенты Культура разработкиВ любом случае, моделирование рассматривается в программном контексте, а не только с точкизрения бизнес-задач как таковых, Это обусловлено необходимостью понимания операционного исистемного контекста, то есть окружения, в котором программная система будет реальноиспользоваться и которое накладывает свои, иногда достаточно жесткие ограничения.Вопросы моделирования тесно связаны с применяемыми методами и подходами.

Характеристики

Список файлов книги