OSS / Системноинженерное мышление в управлении жизненным циклом(2014)

TechInvestLab, 14 июня 2014

151

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

●темпоральная (temporal) модальность, связанная со временем. Например, "длина была 16 три года назад".

●Доксическая (doxastic) модальность, связанная с верой. "Я верю, что длина дана как 16". Доксическая модальность важна для квалификации (удостоверения того, что требования выполнены -- вера в то, что система соответствует её определению).

Требования довольно трудно формализовать именно потому, что нужно разбираться с их модальностями. Сложность вопроса можно оценить по базовой статье, только не в попсовой википедии, а в серьезной философской энциклопедии: http://plato.stanford.edu/entries/logic-modal/

Инженерные обоснования

Требования связаны с инженерными обоснованиями: они переформулируются как "декларации" (claim) разработчиков о соответствии -- т.е. "я верю, что длина равна 16", а затем это высказывание доказывается по логическим правилам рациональной аргументации (помним, что логика -- это дисциплина, занимающаяся правильностью рассуждений). Эти доказательства проводятся "как в суде" -- и для этого даже заводится "дело" (assurance case, как раз от "судебного дела" -- с вариантами dependability case, safety case, security case, requirement case, architectural quality case).

Обзор по инженерным обоснованиям приведён тут: http://ailev.livejournal.com/811715.html

Рабочие продукты требований

Рабочие продукты требований могут быть самые разные -- и чаще всего они не называются "требования". Так, требования можно обнаружить в:

●Разделе "технические требования" технических заданий (хотя "техническое задание" чаще всего подробно перечисляет работы -- "задание на работы", а не требования, но всё-таки какое-то описание целевой системы как "чёрного ящика" это описание содержит)

●Документе "Опросный лист" (который посылается, чтобы опросить потенциальных поставщиков инженерных решений и содержит как раз основные требования к поставляемой системе) и посылаемом в ответ на "Опросный лист" документе "Технико-коммерческие предложения"

●Различных стандартах (некоторые из которых называются "технические условия", т.е. даже в названиях они не содержат слова "стандарт" или "требования")

Важно понимать, что требования системной инженерии -- это какие-то

TechInvestLab, 14 июня 2014

152

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

Требования совсем необязательно являются бумажными документами-текстами. Они вполне могут храниться в какой-то базе данных (часто эта база данных ведётся в рамках какой-то "информационной системы управления требованиями" - - DOORS, IRqA и т.д.) в виде отдельных пронумерованных текстовых описаний. Или требования могут быть представлены в виде какой-то компьютерной модели, численной или логической.

Требования стейкхолдеров

Требования стейкхолдеров -- это требования (описания "черного ящика"), которые создаются для отдельных стейкхолдеров. Конечно, требования разных стейкхолдеров будут противоречить друг другу. Обычно от инженера по требованиям требуется документировать (в тексте или какой-то модели) требования стейкхолдеров, а затем завизировать эти требования у них -- чтобы подтвердить правильность понимания. К требованиям стейкхолдерам главное -- их понятность самим стейкхолдерам.

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

Требования и ограничения

Конечно, каждый клиент мнит себя инженером (а иногда не мнит, а действительно является инженером, а иногда ещё и инженером, более знающим, чем инженеры команды проекта). Такой клиент не только будет формулировать требования стейкхолдера, а также требования к системе, но обязательно попытается сформулировать конкретные инженерные решения "прозрачного ящика" (например, из каких частей должна составлять система, какое в ней должно быть использовано оборудование). Формально высказывания о "прозрачном ящике" не называются требованиями, поэтому некоторые авторы предлагают называть их "ограничениями" (свободы творчества инженерной команды).

Неплохо бы понимать в каждом проекте, что является требованиями, а что является ограничениями. Прежде всего вы должны удовлетворить требованиям. И если придуманное вами инженерное решение для "прозрачного ящика" лучше того, которое требует клиент в своих ограничениях, нужно попытаться убедить клиента снять эти ограничения.

TechInvestLab, 14 июня 2014

153

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

Требования к системе

Требования стейкхолдеров могут быть противоречивы, разрознены и неполны. Требования, достаточные для разработки системы, называются системными требованиями (требованиями к системе, system requirement). Их разрабатывает инженер по требованиям в ходе так называемой "аналитической" работы (хотя в этой работе кроме анализа требований стейкхолдер и присутствует синтез системных требований).

К требованиям к системе предъявляют множество самых разных требований: непротиворечивости, полноты, проверяемости и т.д. Разработать хорошие требования к системе очень и очень непросто.

Главная ошибка, из-за которой терпят провал многие проекты -- это необнаружение какого-то важного требования какого-то из стейкхолдеров.

Инженерия требований

Разработкой требований занимается поддисциплина системной инженерии "инженерия требований". Главная часть инженерии требований -- это реинжиниринг использующей (над)системы (using system) для того, чтобы получить описания "чёрного ящика". Инженеры по требованиям (это вид системных инженеров) выявляют стейкхолдеров, узнают их потребности (нужды, needs), разрабатывают требования стейкхолдеров, проводят переговоры между стейкхолдерами в тех случаях, когда их требования противоречивы, или когда команда проекта оказывается не в состоянии их выполнить и требования нуждаются в коррекции, согласуют требования стейкхолдеров между собой, готовят требования к системе.

Неправильно называть инженерию требований "управлением требованиями". Управление требованиями -- это дисциплина инженерного менеджмента (логистическая, "инженерного документооборота"), она заключается в том, чтобы предоставить средства хранения требований и сообщения о них всем тем, кто в них нуждается. Для того, чтобы управлять требованиями, нужно их сначала иметь: а для этого нужно проводить инженерную работу (прежде всего делать реинжиниринг использующей системы, чтобы понять, что в ней должна делать целевая система). Обычно управление требованиями включают в состав инженерии требований как поддисциплину, но только одну из многих. Обзор стандартов представления требований в целях управления требованиями

(хранения и пересылки) можно найти тут: http://ailev.livejournal.com/900086.html --

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

TechInvestLab, 14 июня 2014

154

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

Какие бывают виды требований

Самые распространённые практики инженерии требований -- это выявление функций (поведения) системы из каких-то сценариев взаимодействия (user stories, use cases: там множество вариантов). Иногда про такие требования, выведенные из сценариев использования, говорят "функциональные требования", противопоставляя их "нефункциональным" (например, требованиям надёжности, ремонтопригодности, доступности, безопасности и т.д., так называемые "-ости",

по-английски это будут "ilities" -- reliability, repairability, availability, safety, etc.). Но есть замечание Donald Firesmith, что "не бывает нефункциональных требований" -- ибо все эти "требования качества" (как их иногда тоже называют) это абсолютно функциональные требования, характеризующие функции системы с точки зрения каких-то стейкхолдеров, обычно не рассматривающихся в сценариях "пользования".

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

TechInvestLab, 14 июня 2014

155

Подробнее про требования защитоспособности (выделенные на рисунке выше) можно посмотреть в презентации Дональда Файерсмита -- http://www.vniiaes.ru/files/RuSEC%202010.rar (и там же можно посмотреть на презентацию по целеориентированной инженерии требований Яна Александера).

Кто должен делать требования

Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: "вы предоставьте нам подробные требования, иначе мы и пальцем не пошевелим". Должен разочаровать: это неверная позиция. Заказчик может представить только свои нужды, а не требования к системе. Если у заказчика есть инженеры (или заказ на разработку системы делает инженерная фирма), то есть шанс получить "требования стейкхолдера". Но это ещё не требования к системе. Разрабатывает требования обычно команда проекта, они не приходят извне проекта. Другое дело, что без активного участия стейкхолдеров (в том числе представителей организации заказчика) требования не подготовишь. Но в любом случае, ответственность за требования лежит на команде проекта, а не на заказчике.

Заказчик же может, например, завизировать разработанные командой проекта

TechInvestLab, 14 июня 2014

156

требования -- но и в этом случае, изготовленная система, которая не удовлетворит его нуждам (needs) по причине того, что требования были сформулированы командой проекта неправильно, может встретить серьёзные проблемы при приёмке/validation (хотя блестяще пройдёт проверку/verification -- инженеры подтвердят сами себе, что изготовили ровно то, что планировали, хотя это не то, в чём нуждался клиент).

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

Архитектура

Системная архитектура -- эта альфа, пожалуй, важнейшая среди подальф определения системы. Она была сформулирована по мотивам строительной архитектуры относительно недавно (лет эдак двадцать назад) и имеет множество определений:

●Из ISO 42010: Архитектура (системы) – основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития (Architecture (of a system) – fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution).

●Из книжки Garlan et al.: Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений (The architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both).

●Набор из более чем 150 других определений архитектуры, которые предлагались профессионалами системной и программной инженерии: http://www.sei.cmu.edu/architecture/start/glossary/community.cfm

После одной из затяжных интернет-дискуссий по архитектуре в программной инженерии Ralf Johnson выдал альтернативное определение: "Архитектура -- это обо всём важном. Что бы это ни было". А что можно считать важным в инженерной системе? Если представить архитектуру как набор инженерных решений, принимаемых для определения структуры системы, то "важные решения" -- это при изменении которых приходится в существенной мере изменять множество других решений, в существенной мере перепроектировать систему. Если вместо двигателя внутреннего сгорания на автомобиль поставить электромоторы, то автомобиль придётся перепроектировать практически заново (хотя что-то из неархитектурных решений может и остаться: оплётка руля, стекло

TechInvestLab, 14 июня 2014

157

на дверцах, фары). Следовательно, выбор между двигателем внутреннего сгорания и электродвигателем в ходе создания автомобиля -- это архитектурное решение.

Книжка Garlan et al. "Documenting Software Architectures" упоминается в литературе к стандарту архитектурных описаний ISO 42010. Она предлагает метафору для понимания того, что такое архитектурное описание и почему его так трудно сделать: как документировать крыло птицы для того, кто не знает, что это такое? Там ведь огромное количество разноуровневых структур, повторения с вариациями, критические для полёта качества элементов и свойства крыла, невыводимые из свойств отдельных его частей. Как записать все эти структуры, в которых каждое перо неповторяемо в его даже самых маленьких деталях, есть множество особенностей костей и мышц, но все они в совокупности дают функцию полёта?

TechInvestLab, 14 июня 2014

158

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

Итого: важно, какие типы структур системы документируются (например -- структуры компонент/принципиальные схемы, модули и их интерфейсы, размещения и т.д.), какие принципы проектирования/конструирования и развития документируются.

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

TechInvestLab, 14 июня 2014

159

инженерии системной архитектуры? Прежде всего -- для рассуждения о системе для команды проекта. Архитектурные описания для инженеров как шахматная доска для игроков в шахматы -- это гроссмейстеры могут играть "в уме", а простые люди предпочитают вести сложные рассуждения не в кортексе (коре головного мозга), а с использованием экзокортекса. Команда поможет также убрать ошибки: эти ошибки трудно заметить, если архитектурные решения не задокументированы.

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

Архитектурные инженерные решения ясно выражают ограничения для для проектантов/конструкторов (команды проекта), поэтому они стабилизируют разработку.

Архитектурные описания также помогают разъяснять принимаемые по поводу целевой системы инженерные решения для внешних по отношению к команде стейкхолдеров («шахматная доска для зрителей и судей»).

Архитектурную работу можно делать плохо, а можно хорошо (но делается она в любом случае). Чтобы её делать хорошо, нужно её обсуждать специально, знать лучшие архитектурные практики!

Инженерия системной архитектуры

Практика создания системной архитектуры получила название "инженерия системной архитектуры". Конечно, у этой практики есть и множество других названий: architecturing (архитектурирование -- но так по-русски говорят редко), эскизное проектирование (conceptual design). Инженерия системной архитектуры представляет собой часть в архитектурном проектировании (architecturing design), хотя в это проектирование входит создание всего проекта (design), в том числе и неархитектурной его части.

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

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

Более того, раньше при наличии требований и существовании этого "народного эпоса" часто переходили непосредственно к проектированию и конструированию,

TechInvestLab, 14 июня 2014

160

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

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

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

Практики архитектурного проектирования