Упорядоченность по важности и стабильности
Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика. Разработчик, отталкиваясь от приоритетности требований, управляет процессом реализации информационной системы.
Стабильность требования характеризует прогнозную оценку неизменности требований во времени.
Наличие количественной метрики
Количественные метрики играют важную роль в верификации и аттестации информационных систем. В первую очередь это относится к нефункциональным требованиям, которые, как правило, должны иметь под собой количественную основу (запрос должен отрабатываться не более, чем ___ секунд; средняя наработка на отказ должна составлять не менее, чем ___ часов). Функциональные требования также могут расширяться количественными мерами при помощи так называемых аспектов применимости (см. материал "Расширенный анализ требований. Иллюстрированные сценарии и прототипы" ).
Каких требований не должно быть
Согласно [3.5], спецификация требований не должна содержать деталей проектирования или реализации (кроме известных ограничений). Иными словами, требования должны отвечать на вопрос: "что должна делать система", абстрагируясь от вопроса "как она это должна делать". Стремление принимать детальные проектные решения на этапе анализа требований - одна из типичных "ловушек", типичных для неопытных команд разработчиков. Вариантов реализации всегда больше, чем один, а для принятия взвешенного решения нужна максимально более полная информация. Поэтому этапы работы с требованиями, проектирования и реализации планируются поочередно, хотя и могут быть частично запараллелены в рамках итерационного подхода к созданию программных систем (см. "Требования в управлении проектом").
|
|
|
Рабочий поток анализа требований
Анализ требований - один из основных рабочих потоков (Workflow) программной инженерии, наряду, допустим, с такими, как проектирование интерфейса пользователя, либо программирование.
Для его обозначения в англоязычной литературе, как правило, используется понятие "Requirement Process". В отечественной практике, наряду с обобщающим термином "анализ требований", принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как "поток работ", "требования", "работа с требованиями", "определение требований" и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK, и введем терминологию, которой будем придерживаться на протяжении лекционного курса.
|
|
|
SWEBOK SoftWare Engineering Body Of Knowledge – свод знаний о программной инженерии (гиперссылка http://www.computer.org). Представляет собой международный стандарт, подготовленный координационным комитетом программной инженерии (Software Engineering Coordinating Committee) под эгидой АСМ и IEEE. Цель документа – определить необходимый набор знаний и рекомендуемые практики, которыми должны владеть специалисты в области программной инженерии. В настоящее время существует версия 3.0, подготовленная в 2014 году, в которой содержатся 15 областей знаний. Каждая область знаний представляет собой иерархически упорядоченный текст стандартизованного типа, включая понятийный аппарат, методы и средства, инструменты поддержки инженерной деятельности и др. Ранняя версия документа (SWEBOK 2004) доступна в переводе С. Орлика (http://swebok.sorlik.ru/).
SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:
· Requirements Elicitation (Извлечение требований),
· Requirements Analysis (Анализ требований в узком смысле),
· Requirements Specification (Специфицирование требований),
· Requirements Validation (Проверка требований).
В качестве примера альтернативной декомпозиции потока работ можно рассмотреть взгляд, предложенный в RUP [4.1]. RUP предлагает выделить в основном потоке анализа требований такие компоненты, как:
|
|
|
· Analyze the Problem (Анализ проблемы),
· Understand Stakeholder Needs (Понимание потребностей совладельцев),
· Define the System (Определение системы),
· Manage the Scope of the System (Управление контекстом системы),
· Refine the System Definition (Уточнение определения системы).
RUP (Rational Unified Process – "рациональный унифицированный процесс") – методология разработки программного обеспечения от IBM. RUP развивался десятилетиями и отражает коллективный опыт множества людей и компаний. Методология оформлена в виде базы знаний, которая в настоящее время доступна в рамках продукта IBM Rational Method Composer http://www-03.ibm.com/software/products/ru/rmc. RUP - формализованный, итеративный, инкрементный, настраиваемый процесс разработки, направляемый требованиями, базирующийся на метриках и визуальном моделировании на основе UML. Процесс поддерживает команды любого размера.
Stakeholder - "Совладелец", заинтересованное лицо. Согласно PMBOK - лицо или организация (например, потребитель, спонсор, исполняющая организация или общественность), которые активно вовлечены в проект, - на чьи интересы могут позитивно или негативно повлиять исполнение или завершение проекта. Заинтересованная сторона также может оказывать влияние на проект и его результаты. (конец цитаты). Поиск заинтересованных лиц и отслеживание их интересов на всем протяжении проекта – одна из ключевых стратегий в большинстве современных методологий разработки программного обеспечения. Следование этой стратегии позволяет существенно смягчить риски и обеспечить "мягкое" внедрение разработанного ПО.
|
|
|
Обобщая указанные выше декомпозиции, а также подходы, описанные в [4.4,4.5-4.7], далее будем придерживаться следующей, более удобной в методическом плане схемой декомпозиции потока работ "Работа с требованиями":
· "Формирование видения" ;
· "Выявление требований" ;
· "Классификация и специфицирование требований" ;
· Расширенный анализ требований ( "Расширенный анализ требований. Моделирование" и "Расширенный анализ требований. Иллюстрированные сценарии и прототипы" );
· "Документирование требований" ;
· "Проверка требований" ;
· "Введение в управление требованиями" ;
· "Совершенствование процессов работы с требованиями" .
Первые 6 работ в лекционном курсе рассматриваются, как компоненты процесса анализа требований.
Для того, чтобы успешно создать автоматизированную информационную систему (или шире, программную систему), необходимо, во-первых, определить компоненты потока работ, которые будут использоваться командой разработчиков и, во-вторых, правильно их организовать. В вопросы организации входит упорядочение работ во времени, интерфейсы между ними, параллелизм, работа с рисками и многое другое.
Найти ответ на первый вопрос может помочь общая классификация задач, работ и операций программной инженерии, представленная в ГОСТ Р ИСО/МЭК 12207-99. Другая, более поздняя по времени классификация, присутствует в SWEBOK. Однако нужно отметить, что данные руководящие документы рассматривают общий случай, а в частном проекте может быть задействован далеко не весь арсенал работ.
Сложнее - с решением второго вопроса. На сегодня существуют и имеют примеры успешного применения десятки и сотни различных методологий (процессов), среди наиболее известных - MSF, RUP, Oracle PJM, XP, FDD, SCRUM, PSP, Crystal, DSDM. Методологии подразделяются на 3 "волны": каскадные (исторически первые), прогнозирующие (например, RUP) и "гибкие" (agile), вошедшие в широкую практику на рубеже тысячелетий [4.3].
Agile - серия гибких (облегченных) подходов к разработке программного обеспечения, в противовес так называемым "тяжеловесным" подходам. Базируются на Agile-манифесте http://agilemanifesto.org/principles.html.
Основные его идеи – смещение акцентов от всесторонней документации – к работающему коду, от контрактов – к сотрудничеству, от планов – к быстрой реакции на изменяющиеся требования, от формализации – к поддержке индивидуальностей и взаимодействия. Наиболее известные типопредставители – Scrum и XP.
Описания методологий существенно разнятся объемом (от десятков до тысяч страниц текста), наборами базовых работ и рабочих квалификаций, акцентами (работа с моделями, управление рисками, построение команды и пр.). Но авторы их описаний обычно сходятся в одном: лучшая из методологий, которой нужно следовать, чтобы добиться успеха - именно та, которую предлагает (описывает, рекламирует) конкретный автор. Редким исключением являются работы А. Коберна, автора группы методологий Crystal (см., в частности, [4.3]), где он предлагает брать за основу не "самый лучший" из процессов, а тот, который, во-первых, наилучшим образом соответствует проектной задаче, а во-вторых - команде, которая будет его реализовывать. В [4.3] вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.
Дата добавления: 2021-03-18; просмотров: 183; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!