Качество и улучшение процессов (Process Quality and Improvement)

   Эта тема связана с оценкой качества процессов работы с программными требованиями и улучшением этих процессов.

   Особое значение данной темы обусловлено ключевой ролью процессов работы с программными требованиями  для определения стоимостных и временных ресурсов, необходимых для реализации программного проекта, в целом. 

   Удовлетворение потребностей заказчика является целью любого программного проекта. Соответственно, обеспечение адекватности реализации требований в проекте просто невозможно без адекватных процессов работы с ними – начиная со сбора требований, заканчивая проверкой соответствия получаемого программного продукта этим требованиям на всех этапах его создания.

   Улучшение процессов и в частности процессов разработки и управления требованиями должно предваряться формулировкой проблемы.

  Нет смысла заниматься улучшением ради улучшения (есть специалисты, которые любят улучшать «из любви к искусству, что приводит, как правило к срыву сроков и увеличению стоимости конечного продукта). Нужно четко понимать какая в настоящее время есть проблема в работе с требованиями, насколько эта проблема значима, и только потом приступать к ее устранению.

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

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

Вопросы совершенствования процессов будут рассматриваться в других частях этого курса.

Данная тема тесно связана с областями знаний «Качество программного обеспечения» (Software Quality) и «Процесс программной инженерии» (Software Engineering Process). В этом контексте, основные моменты обсуждаемой темы – определение атрибутов и метрик качества, а также определение соответствующих процессов в применении к программным требованиям, которые можно свести в три группы практик:

·  Покрытие процессов работы с требованиями с точки зрения стандартов и моделей улучшения процессов, в целом.

·  Измерение и количественная оценка процессов работы с требованиями.

·  Планирование и реализация процесса улучшения, как такового.

3. Извлечение требований (Requirements Elicitation)

  Данный раздел освещает вопросы сбора требований, как с точки зрения организации процесса, так и определения источников, откуда поступают требования. Идентификация заинтересованных лиц, их взаимодействия, выполняемых ими бизнес-процессов – все это является ключевыми вопросами, без четкого и однозначного ответа на которые даже не стоит думать об успешности проекта. 

Один из ключевых принципов программной инженерии заключается в обеспечении взаимодействия между пользователями и инженерами. Прежде, чем начинается разработка программного обеспечения, именно специалисты «по требованиям» – аналитики перекидывают тот самый «мостик» между заказчиками и исполнителями, задают уровень коммуникаций и взаимопонимания между ними, который необходим для решения задач проекта.

3.1 Источники требований (Requirement Sources)

   Необходимо идентифицировать все возможные источники требований, значимые для решения задач проекта. Только после этого можно определить их влияние на проект. Необходимо понимание информированности источников требований и их значимости. Рассматриваются:

·  Цели.

·  Знание предметной области.

·  Заинтересованные лица.

·  Операционное окружение.

·  Организационная среда.

 

  Выделение приоритетов, однозначность требований, передаваемых инженерам, связь между требованиями и их взаимное влияние друг на друга – все это является следствием четкого и однозначного понимания источников требований.

3.2 Техники извлечения требований (Elicitation Techniques)

Идентифицировав источники требований, понимая кто, владеет необходимой информацией, мы далеко не застрахованы от проблем, связанных с получением требований, необходимых для дальнейшей работы.

Осуществление своей профессиональной деятельности пользователями далеко не гарантирует, к сожалению, способность ясно, четко и однозначно сформулировать то, что они делают и что именно им необходимо для решения их задач сегодня и завтра.

 Во многом, поэтому, сбор требований, зачастую, превращается в столь тяжелый и часто порождающий конфликты процесс действительно извлечения, «вытаскивания» информации, без которой невозможно переходить к дальнейшим проектным работам.

Недопонимание между аналитиком и пользователем, упущение тех или иных аспектов, на первый взгляд кажущихся второстепенными, неоднозначность или тем более некорректность интерпретации информации, полученных от пользователей – все это наиболее типичные причины «сверх - затрат» (времени, денег и т.п.), а иногда, и полного провала проектов.

Существует множество практик и подходов, позволяющих добиться действительно стройной системы требований, отвечающих реальным потребностям и приоритетам заказчиков. Среди них можно выделить:

 Интервьюирование – традиционный подход извлечения требований. Понятно, что получение информации от пользователя «не равно» получению требований. Информация должна быть проанализирована и трансформирована в требования, таким образом, что информация от пользователя является «входом» в процессы сбора требований, а сами требования – «выходом» этих процессов.

 Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы «что если» и «как это делается» в отношении бизнес-процессов, реализуемых пользователями.

 Прототипы – отличный инструмент для уточнения и детализации требований. Существуют разные подходы. Прототипирование – от «бумажных» моделей до пилотных         подсистем, реализуемых как самостоятельные проекты или бета-версии продуктов. Часто прототипы постепенно трансформируются в результаты проекта и используются для проверки и утверждения требований.

 «Разъясняющие встречи», «Дополнительные встречи» - в оригинале звучит как «facilitated meetings». Подход базирующийся на сотрудничестве заинтересованных лиц для совместного анализа путей решения проблем, предупреждения рисков и т.п.

   Эти встречи обычно планируются с заданной периодичностью для обеспечения однозначности интерпретации информации, значимой для проекта. Очень важно встречаться до того, как связанные с данными вопросами риски не превратились в реальные проблемы, требующие решения «вчера», а, следовательно, и   дополнительных (изначально незапланированных) ресурсов времени, денег и т.д.

 Наблюдение – подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов. Данная техника является достаточно затратной, но, в то же время, очень эффективной, а     иногда – просто незаменимой, особенно, если речь идет о сложных и взаимосвязанных бизнес-процессах.

 

4. Анализ требований (Requirements Analysis).

   Под анализом требований понимается преобразование  информации, полученной от пользователей (и других заинтересованных лиц) в четко и однозначно определенные требования, передаваемые инженерам для реализации в программном коде.

  Анализ требований включает:

· Обнаружение и разрешение конфликтов между требованиями.

· Определение границ задачи, решаемой создаваемым ПО.

  В общем случае - определение границ и содержания  

  программного проекта.

· Детализация системных требований для установления  

  программных требований.

 

Практически всегда, на практике выделяется и детализация бизнес - требований для установления программных требований. Например, режим работы 24 x 7, сформулированный в виде бизнес - требования, накладывает достаточно жесткие рамки на выбор технологической платформы и архитектуры, как технических требований к разрабатываемой программной системе.

Так или иначе, вне зависимости от выразительных средств, которые являются лишь инструментом анализа и фиксирования результатов, результатом анализа требований должны быть однозначно интерпретируемые требования, реализация которых проверяема, а стоимость и ресурсы – предсказуемы.

4.1 Классификация требований (Requirements Classification)

Требования могут классифицироваться по целому ряду параметров, например:

·  Функциональные и нефункциональные требования.

·  Внутренние или внешние зависимости.

·  Требования к процессу или продукту.

·  Приоритет требований.

·  Содержание требований в отношении конкретных подсистем   

   создаваемого программного обеспечения.

·  Изменяемость/стабильность требований.

 

 

     Другие варианты классификации могут базироваться, на принятых в организации подходах, применяемых методах и практиках, специфике проектов и даже требованиях заказчиков к процессу разработки. Например, к форме определения требований и представления результатов их анализа.

4.2 Концептуальное моделирование (Conceptual Modeling).

Разработка модели проблемы реального мира – ключевой элемент анализа требований. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы. 

Часто приходится слышать, что прагматичность подхода в отношении программных проектов заключается в «пропуске» этапа моделирования. Это утверждение в корне неверно.

Например, в XP(Экстремальное программирование, Extreme Programming, XP) существуют и истории пользователей, и карточки задач, и процедуры анализа (в частности «мозговых штурмов»), в результате чего формулируются высокоуровневые модели.

Экстремальное программирование                         (Extreme   Programming, XP) - одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Двенадцать основных приёмов экстремального программирования могут быть объединены в четыре группы:

· Короткий цикл обратной связи (связь «накоротке»):

· Разработка через тестирование.

· Игра в планирование.

· Заказчик всегда рядом.

· Парное программирование.

· Непрерывный, а не пакетный процесс:

· Непрерывная интеграция.

· Рефакторинг.

· Частые небольшие релизы.

· Понимание, разделяемое всеми:

· Простота дизайна.

· Метафора системы.

· Коллективное владение кодом и

      выбранными шаблонами проектирования.

· Стандарт кодирования.

· Социальная защищенность программиста:

· 40-часовая рабочая неделя, стабильность

      рабочего статуса.

 

                Отдельно поясним, что такое рефакторинг.

Рефакторинг - процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости.

   Именно идея моделирования, как попытка упростить и однозначно интерпретировать на концептуальном уровне проблематику деятельности в реальном мире – обязательная составляющая, как управления требованиями, так и программной инженерии, в целом.

   Факторы, которые влияют на выбор модели и степень связанности с программным кодом следующие:

·  Природа проблемы (проблемной области).

·  Экспертиза и опыт инженеров.

·  Требования заказчика к процессу.

·  Доступность методов и инструментов.

·  Внутрикорпоративные стандарты и регламенты.

·  Культура разработки.

   В любом случае, моделирование рассматривается в программном контексте, а не только с точки зрения бизнес - задач как таковых. Это обусловлено необходимостью понимания операционного и системного контекста, то есть окружения, в котором программная система будет реально использоваться и которое накладывает свои, иногда достаточно жесткие ограничения.

  Вопросы моделирования тесно связаны с применяемыми методами и подходами. Однако, частные методы или нотации, так или иначе, соответствуют принятым в индустрии практикам и тяготеют к тем формам, с которыми связаны накопленный опыт и подтвержденные общепринятой практикой знания.

Могут быть разработаны различные виды моделей, включающие потоки работ и данных, модели состояний, трассировки событий, взаимодействия пользователей, объектные модели, модели структур данных, и т.п.   

Примером служит UML (унифицированный язык моделирования - Unified Modeling Language, разработанный и продвигаемый консорциумом OMG).

Он часто воспринимается, по факту, в качестве общепринятого стандарта в моделировании и включает целый комплекс моделей.

В UML 2.0 включено 14 моделей, представленные в двух группах – статические модели и поведенческие, связанные и объединенные общей архитектурой, на основе концепции метамоделей.

 В то же время, UML не единственный. Создан, активно развивается и уже поддержан индустрией стандарт BPMN – Business Process Management Notation.       Далее, по мере необходимости, мы будем обращаться к этим инструментам.

  4.3 Архитектурное проектирование и распределение требований (Architectural Design and Requirements Allocation).

   Общепризнано, что создание архитектуры программных решений является обязательным элементом успешных проектов. Архитектурное проектирование «пересекается» с программным и системным проектированием и иллюстрирует насколько сложно провести четкую грань между различными аспектами проектирования.

  Во многих случаях, инженеры действуют как архитекторы, потому, что процессы анализа и выработки требований зависят от программных компонентов.

  Программные компоненты создаются для решения задач, поставленных заданными требованиями и призваны, в конечном счете, добиться реализации поставленных перед проектом целей.

  Архитектурное проектирование очень близко к концептуальному моделированию. Непосредственное отображение бизнес - сущностей реального мира на программные компоненты не является обязательным. Во многом, поэтому и существует такое разделение между моделированием и проектированием.

  В принципе, можно говорить о том, что деятельность по моделированию в большей степени касается того, «что» надо сделать, а архитектура – «как» это будет реализовано.

  Существует ряд стандартов и общепринятых практик, связанных с архитектурным проектированием: 

·  Стандарт IEEE 1471-2000 «Recommended Practice for

   Architectural Description of Software Intensive Systems».

·  Модель Захмана.

·  TOGAF – The Open Group Architecture Framework.

Отметим, что не надо путать архитектурные рекомендации с практиками и стандартами архитектурного проектирования. Одни дают рекомендации по конкретным архитектурно - технологическим решениям.

Другие концентрируются именно на том, чему стоит уделить внимание при создании архитектуры, как ее описать с позиций методологии.

5. Спецификация требований (Requirements Specification).

На инженерном жаргоне устоялся термин «software requirements specification» (SRS) – спецификация программных требований.

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

Эти документы систематически анализируются, в них вносятся изменения, они пересматриваются и утверждаются.

  Чаще всего, для описания комплексных проектов (в части требований) используется три основных документа (спецификации):

·  Определение системы.

·  Системные требования.

·  Программные требования.