Сибирский федеральный университет (г. Красноярск)
Опубликован: 18.06.2007 | Доступ: свободный | Студентов: 9336 / 2477 | Оценка: 4.36 / 3.79 | Длительность: 15:50:00
ISBN: 978-5-94774-865-9
Лекция 4:

Процесс анализа требований

< Лекция 3 || Лекция 4: 12 || Лекция 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] вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.

Почему нужно анализировать требования?

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

Со всей очевидностью можно утверждать: да, АТ, как этап разработки ИС, невозможно пропустить: этот этап закладывает фундамент всего процесса проектирования и реализации системы. Степень проработки АТ может быть различной: от совершенно неформальной записки, представленной на одной странице, до развернутой системы документов, моделей и прототипов, построенной в соответствии с принципами одной из прогнозирующих методологий, например, RUP. Она зависит от следующих основных факторов: размеров проекта, величины имеющихся ресурсов и степени рисков. Невысокая глубина проработки приемлема для небольших проектов, характеризующихся небольшим ресурсом и невысокими рисками. Хорошо проработанные требования позволяют:

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

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

Один из ключевых вопросов, позволяющих оценить результативность процесса - что является выходом (результатом) процесса. В чем результат АТ? Результатом рабочего потока "анализ требований" является набор артефактов. Это могут быть текстовые документы, модели UML, либо других языков моделирования, прототипы программного обеспечения.

Другой важный вопрос - какие цели преследует процесс.

RUP предлагает следующие цели для потока работ АТ:

  • добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система;
  • дать разработчикам наилучшее понимание требований к системе;
  • определить границы системы;
  • определить интерфейс пользователя и системы.
< Лекция 3 || Лекция 4: 12 || Лекция 5 >
Александр Медов
Александр Медов

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

Александр Медов
Александр Медов

Здравствуйте, прошел весь курс,хотел заказать версию для печати но она не кликается,когда исправяте данную опцию?

Артем Зайцев
Артем Зайцев
Россия, Санкт-Петербург