лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки

• Название: Курс лекций для специальности спо базовой подготовки
• Анкор: лекция
• Дата: 02.09.2022
• Размер: 4.41 Mb.
• Имя файла: Сборник лекций по МДК _Технология разработки программного обеспе.docx
• Тип: Курс лекций; #660044
• страница: 11 из 62

Рабочий поток анализа требований

Анализ требований - один из основных рабочих потоков (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 (Извлечение требований),
  
• 
  RequirementsAnalysis (Анализ требований в узком смысле),
  
• 
  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] вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.