Вступ до системної інженерії

Від університету Нового Південного Уельсу можна подивитись на Coursera.

Найнудніший з тих що я проходив в інтернеті. Здається що навіть в університеті не було так нудно. Проходив я його для того щоб зрозуміти “якщо те що пишу я набагато простіше за літаки, то як взагалі ті літаки літають? Як тисячі людей домовляються про те щоб діяти разом?”

Ну, власне зрозумів. Систему розбивають на підсистеми, задають інтерфейси між ними, так на кілька рівнів, кожен працює над своєю частиною, потім їх інтегрують, тестують, і якщо не сподобалось – починають з початку.

Нудний, бо по перше, про водоспадну модель я ще в університеті дізнався (а також про Extreme programming, Dynamics System Development Method, і навіть трохи про Rational Unified Process). Що означає що кубик – таки класний і при певних зусиллях може бути в топ100 світового рейтингу, а також про те що Карнаух – одна з найкращих викладачів там, бо якби не вона, я б таких слів не знав, і це при тому що коли ми з нею познайомились я вже не дуже хотів вчитись.

А по друге, ну не треба ставити на слайди стільки списків. А якщо вже поставили – то не читати списків.

Аби краще відклалося – зробив собі конспект. Якщо хто незнайомий з тим що таке системна інженерія, і наприклад думає чи хотів би він це вчити, чи треба шукати іншу спеціальність – можете ознайомитись. Хоча, зразу попереджаю що на практиці воно дещо інакше виглядає ніж в теорії. 🙂

Зміст

• 1 Система
• 2 Життєвий цикл системи
  • 2.1 Acquisition
    • 2.1.1 Conceptual design
    • 2.1.2 Preliminary Design
    • 2.1.3 Detailed Design & Development
    • 2.1.4 Construction & Production
  • 2.2 Utilisation
• 3 Системна інженерія
  • 3.1 Аспекти
    • 3.1.1 Підхід зверху-вниз
    • 3.1.2 Інженерія вимог
    • 3.1.3 Фокус на життєвому циклі
    • 3.1.4 Інженерія дисциплін
  • 3.2 Застосування системноі інженерії
  • 3.3 Фреймворки та процеси в системній інженерії
    • 3.3.1 Менеджмент
    • 3.3.2 Інструменти
    • 3.3.3 Пов’язані дисципліни
    • 3.3.4 Процес
• 4 Requirements engineering
  • 4.1 Верифікація та валідація (V & V)
  • 4.2 Менеджмент вимог
• 5 Концептуальний дизайн
  • 5.1 C1. Визначити бізнес потреби та вимоги
  • 5.2 C2. Визначити потреби та вимоги зацікавлених осіб
  • 5.3 C3. Визначити системні потреби та вимоги
  • 5.4 C4. Провести синтез системного рівня
  • 5.5 C5. Провести System Design Review (SDR)
• 6 Preliminary design
• 7 Детальний дизайн
• 8 Виготовлення і побудова
• 9 Використання (utilisation)
• 10 Ліквідація (disposal)
• 11 Менеджмент
  • 11.1 Менеджмент тестування
  • 11.2 Керування конфігурацією (configuration management)
  • 11.3 Управління ризиками
  • 11.4 Рев’ю технічної програми
  • 11.5 Вибір підходящої методології
  • 11.6 Планування в менеджменті

Система

Перш ніж розбиратись з тим в чому полягає системна інженерія, ми розберемось що таке система. Бо системою називають багато різних понять, фізичні (нервову систему, транспортну систему, систему керування базами даних), так і логічні (банківська система, філософська система, система рівнянь).

DEF: Можна визначити систему як ціле (або множину), отриману з певного числа елементів згрупованих певним чином з певною метою.

В системній інженерії, система це множина елементів що взаємодіють між собою щоб досягти визначеної мети. В системи є:

• Елементи
• Зв’язки між ними
• Межі системи

DEF: Все що всередині меж, ми називатимемо System Of Interest (SOI).

DEF: Ціль системи називається “місією”.

• Повинна бути чікто задекларована менеджментом і зацікавленими особами (stakeholders).
• є вихідною точкою процесу проектування
• є основою кінцевого тесту придатності системи до використання

В широкому розумінні мета системи – надати вирішення бізнес-проблеми.

Звужене поняття системи в SE накладає такі умови:

• Елементи, зв’язки та межі є результатом цілеспрямованого проектування
• Система повинна бути незалежною (досягати своєї цілі без допомоги інших систем. Двигун машини – не система, він лише підсистема, бо він залежить від паливного бака, коліс і т.п.)

Види систем:

• Закриті або відкриті (такі що взаємодіють з середовищем через межі)
• Природні, штучні, або природні модифіковані людиною.
• Фізичні або концептуальні
• Нові або такі що вже створювались раніше

Системна інженерія переважно зосереджується на відкритих, штучних або продніх модифікованих фізичних системах з існуючих елементів. DEF: Система може міститись в ширшій системі – Wider System Of Interest (WSOI).

Система це майже як продукт, але часто – більше.

Стандарт ANSI/EIA-632 описує систему як

• Operational products
• Enabling products
  • Test
  • Training
  • Disposal

DEF: Таким чином системи це не тільки створене програмне та апаратне забезпечення, а й організація, люди, правила, дані і т.п. І система це не лише продукт а й operational capability. На цьому рівні систему називають capability system.

Кожен елемент capability system має свій acquisition cycle (цикл отримання).

Приклад capability system в авіації:

• Люди: екіпаж та наземні служби
• Підтримка: паливо і мастила, механізми і запчастини
• Споруди: термінал, злітна смуга, диспетчерська…
• Організація, політики і процедури (відповідність стандартам і специфікаціям)
• Тренінги
• Дані (інструкції, документація, …)
• Головне обладнання (major equipment) – літак

Щоб не ускладнювати собі задачу ми в capability system будемо зосереджуватись на головному обладнанні.

Систему можна описати:

Логічно

ЩО система буде робити, як добре вона це робитиме, в яких умовах, як її тестувати і які інші системи з нею взаємодіятимуть.

Фізично

якими є елементи системи, як вони виглядають, ЯК їх виробляти, з’єднувати і тестувати

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

• Надто раннє фокусування на фізичному описі обмежує пошук нових рішень.
• Прив’язуючись до фізичного опису ми починаємо розв’язувати фізичні проблеми і можемо забути про якісь потрібні функції системи та додати пару непотрібних.
• Логічний опис – чудовий інтерфейс між інженерією та менеджментом

Крім того, в наш час прогресу логічний опис змінюється повільніше ніж фізичний. Логічний опис двигуна внутрішнього згорання не змінився, а от фізичні реалізації – дуже.

Таким чином існують дві пов’язані архітектури системи – фізична і логічна.

Логічна описується в requirements breakdown structure, а фізична – в work breakdown structure.

Логічна архітектура – ієрархічна – це місія системи розбита на функції, а ті в свою чергу на підфункції.

Фізична архітектура теж ієрархічна, це система розбита на підсистеми -> assemblies -> компоненти.

Приклад: Система: Літак Підсистема: Двигун Assemblies: паливні насоси і труби, турбіни, компресори, механізми… Компоненти: болти, гайки та інші деталі?

Система на відміну від підсистем незалежна. Двигун не може працювати без літака, або тестового стенду, тому він – підсистема.

DEF: Якщо наша система складається лише з елементів що самі є системами, тоді ми її називатимемо системою систем.

Відмінність системи систем в тому, що її елементи – окремі системи і були створені та оптимізовані раніше для якоїсь своєї власної мети. В звичайній системі елементи оптимізовані для цілей системи.

Робота над системою проводиться в двох областях:

• Область проблеми Problem domain (space) – переважно логічний опис системи
• Область вирішення Solution domain (space) – переважно фізичний опис

Діяльність в області проблеми – справа замовника (власника бізнесу), а діяльність в області вирішення – в організації що створює систему (розробника).

Життєвий цикл системи

DEF: Життєвий цикл – це сума файз і активностей в роботі системи протягом її життя. Широко можна розділити життєвий цикл на 4 фази:

Pre-acquisition – створення вимог. На цьому етапі проводиться дослідження і вирішується чи доцільно взагалі буде переходити до фази створення системи.

Acquisition – створення й запуск системи. Тоді система описується в термінах бізнес-вимог, вимог зацікавлених осіб та системних вимог і вони передаються контрактору. Контрактор надає реалізацію за вимогами.

Utilisation – використання і підтримка системи. Система може також змінюватись, бо:

• Змінились вимоги
• Змінилось середовище
• Треба оптимізувати продуктивність
• Оптимізувати вартість підтримки

Retirement – система працює доки:

• в ній є потреба
• вона відповідає вимогам
• її робота окупається

Якщо ці умови не виконуються, система припиняє роботу. Можливо замість неї використовуватимуть наступну.

Впродовж життєвого циклу задіяні:

• Організація клієнта
  • Enterprise management (задають напрям роботи організації)
  • Бізнес менеджмент (відповідають за активності)
  • Оператори (здійснюють операції (активності))
• Acquisition element (acquirer) (tasking activity)
  • менеджмент проекту
  • інженери
  • QA
  • Логістика
  • Підтримка

Система надається постачальником (supplier-ом), який може створити її сам, або найняти контрактора (contractor). Той хто створює називається розробником (developer). Контрактор підписує контракт. Іноді контрактор не може сам створити всю систему, тоді він звертається до підконтракторів і умови співпраці з ними описуються в підконтрактах.

Системна інженерія працює переважно в активностях acquisition та utilisation (трохи рідше), тому що чим раніше її застосовюуть, тим більший ефект вона може дати.

Acquisition

Conceptual design

Перетворення mission statement в логічний опис системи. Відбувається в три кроки:

1. Бізнес менеджмент описує Business Needs & Requirements (BNR)
2. Зацікавлені особи (stakeholders) описують Stakeholders Needs & Retirements (SNR). Це дещо розширений BNR.
3. Далі requirements engineers на основі SNR створюють System Retirements Specification (SyRS).

BNR, SNR & SyRS є елементами Functional Baseline (FBL). Це і є логічною архітектурою. Концептуальний дизайн закінчуєтсься проведенням System Design Review (SDR).

Preliminary Design

Перетворення FBL на фізичну архітектуру. На цій фазі фокус переміщується з області проблеми в область вирішення, і з клієнта на контрактора. Цей процес дає нам Allocated Baseline (ABL). Він закінчується проведенням Preliminary Design Review, який формалізує ABL.

Detailed Design & Development

Далі використовується інженерія для розробки всіх підсистем, assemblies та компонентів. В результаті ми отримуємо Product Baseline (PBL), який описує продукти (системи) та медоди їх конструювання). Формалізується під час Critical Design Review (CDR). Critical – тому що це останній дизайн на папері.

Construction & Production

Компоненти створюються і інтегруються згідно з PBL. Далі проводиться Formal Qualification Review (FQR) також відомий як тест прийнятності (acceptance test).

Utilisation

На цій фазі відбувається

• Операційне використання
• Підтримка
• Зміни

Якщо всі активності виконуються послідовно – такий життєвий цикл називають водоспадною моделлю (вода переходить з етапу на етап і ніколи не повертається назад). Існують також інкрементна, спіральна та еволюційна моделі фази acquisition. Протягом цього курсу ми будемо припускати що працюємо з моделлю водоспаду, тому що вона простіша.

Системна інженерія

Аспекти

Має багато визначень, які фокусуються на різних аспектах:

Підхід зверху-вниз

Традиційно системи будують знизу вверх, тобто складають з існуючих компонентів. Але складніші системи варто створювати зверху вниз:

• Розглянути систему в цілому, її межі, інтерфейси середовище
• Розробити вимоги в цілому
• Розбити на підсистеми і розробити вимоги для них

Такий підхід задокументовано в стандарті ANSI/EIA 632. Також варто зауважити, що хоча проектування відбувається зверху вниз, інтеграція – знизу вверх.

Інженерія вимог

Чіткі вимоги важливі для успішної побудови і використання системи. Бо на них будується логічний і фізичний дизайн системи.

Погані вимоги не можна виправити гарним дизайном.

Коли вимоги сформульовано – процес фокусується на виділенні з них вимог для компонентів.

Вимоги повинні бути відслідковуваними (traceable), тобто для кожної з вимог повинно бути зрозуміло які особливості системи її виконують (forward traceability) та навпаки, кожне технічне рішення повинно бути пов’язано з якоюсь вимогою (backward traceability). Таким чином всі вимоги будуть виконані і не буде зайвих вимог. Також traceability допомагає змінювати вимоги (щоб система змінилась відповідно).

Фокус на життєвому циклі

Не можна фокусуватись лише на фазі acquisition, оптимізувати треба також ціну utilisation. Оптимізація всього називається оптимізацією ціни всього життєвого циклу (full life-cycle cost, full LCC).

Ніхто не купить дешеву машину, яку треба дорого заправляти і ремонтувати.

Комбінація оптимальних підсистем не обов’язково дає оптимальну систему. Нерозумно ставити двигун формули 1 на мопед, бо він не розрахований на такі навантаження.

Також, оптимізація повинна бути збалансована з безпекою, екологією, законами, етикою і т.п.

Інженерія дисциплін

Для створення літака потрібно багато різних професій – механіки, електрики, авіатори, програмісти, дизайнери, фінансисти, юристи, маркетологи, …

Системна інженерія визначає кожному задачі, а потім використовує менеджмент щоб інтегрувати зусилля.

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

Застосування системноі інженерії

Стандарт ANSI/EIA-632 каже що SE можна застосовувати до:

• Комерційних і некомерційних систем
• великих, малих, простих чи складних
• …

Якщо узагальнити – то до всіх

Але треба застосовувати системну інженерію продумано, щоб не збільшити складність і ціну проекту, без зменшення ризиків. Кожна активність має збільшувати цінність проекту і зменшувати ризики. SE застосовує як замовник так і контрактор.

Переваги від застосування SE:

• Економиться LLC (і чим раніше застосовано – тим більше економиться)
• Зменшуються ризики
• Збільшується якість системи (відповідність місії)

Фреймворки та процеси в системній інженерії

Бувають різні. Але в цьому курсі ми використовуватимемо фреймворк що складається з

• Процесів (Conceptual design, Preliminary design, Detailed design, Construction/Production, Utilisation …)
• Менеджменту
• Інструментів
• Пов’язаних дисциплін

На кожній фазі циклу ми більше зосереджуватимемось на меті фази, а не на деталях реалізації. А також розглянемо найкраще acquisition, бо системна інженерія на цій фазі дає найбільший ефект, хоча не оминемо й utilisation.

Менеджмент

Менеджмент – спрямовує зусилля, моніторить їх застосування, контролює та звітує.

Містить такі функції:

• Технічні рев’ю та аудити
• Тести та оцінки
• Управління ризиками
• Управління конфігурацією.
• Управління інтеграцією
• Специфікації та стандарти

Інструменти

Техніки та процеси, інформаційні системи, стандарти.

Інструменти процесів: Requirements Breakdown Structure, Functional Flowback Diagram, Work Breakdown Structure… Інструменти менеджменту: стандарти та cabability maturity models.

Пов’язані дисципліни

• Project management
• Logistics management
• QA
• Hardware engineering
• Software engineering

Процес

Цикл з трьох елементів:

1. Аналіз (Що? Вимоги)
2. Синтез (Як? Дизайн)
3. Оцінка (перевірка)

Такий цикл застосовується до систем та підсистем на всіх фазах.

Requirements engineering

Інженерія вимог має на меті розробити набір вимог.

Потреби (needs) – це здатності системи описані на мові бізнес менеджменту та зацікавлених осіб на рівні бізнес-операцій.

Вимоги (requirements) – формальні структуровані твердження, які можна перевірити. Кожній потребі відповідає одна чи більше вимог.

Вимоги утворюються з потреб в процесі, який називають аналіз вимог, або бізнес-аналіз, або аналіз місії. Потреби та вимоги існують на різних рівнях: Enterprise, Business management & business operations – з області проблеми і на рівнях системи та підсистем – з області вирішення.

Нагадаємо що в області проблеми оперують логічним описом системи, а в області вирішення – фізичним.

На enterprise рівні задаютьс стратегії, лідерські наміри, візії, мета та цілі. І створюється concept of operations, куди все те входить.

На рівні Business management – створюють OpsCon (Operations Concept) який описує що система робитиме, як добре, і чому (з точки зору користувача).

Оформляється як Preliminary Life-Cycle Concepts Documents (PLCD), який складається з концептів різних фаз: Acquisition, Deployment, Support, Retirement.

Acquisition concept описує те як система буде отримана (acquired). Deployment conecpt – як вона буде перевірена і запущена. Support concept – яку інфраструктуру та персонал вона потребує після запуску. Retirement concept – описує як система буде знята з експлутації, включно із знешкодженням будь-яких небезпечних матеріалів.

Потреби описані в цих документах формалізуються як вимоги в Business Requirements Specifications (BRS) або Business Requirements Document (BRD), процесом який називається Mission analysis або business analysis.

Коли бізнес-менеджмент задоволений своїми потребами і вимогами вони передають їх на рівень business operations. Ті формують свої потреби в Life-Cycle concepts documents (LCD) і формалізують їх в Stakeholders Requirements Specification (StRS), під час процесу який називається аналізом вимог.

З StRS формують System Requirements Specification (SyRS), на рівні системи.
На рівні системи також існують потреби, в формі System Life-Cycle concepts і на всіх рівнях включно з Business Operations та нижче, процес перетворення потреб на вимоги називається аналізом вимог (requirements analysis). На рівні Enterprise & Business management цей процес називається аналізом місії та бізнес-аналізом.

DEF: Сутність (entity) – щось чого стосується потреба або вимога: підприємство, business unit, система, елемент системи (процес, людина чи організація).

DEF: Потреба (need) – погоджене очікування від сутності виконувати певну функцію або володіти певною властивістю.

DEF: Вимога (requirement) – результат формального перетворення однієї чи кількох вимог в узгоджене зобов’язання для елемента виконувати деяку функцію або володіти певною властивістю (у заданих межах).

DEF: Функціональна вимога – щось що система повинна робити або надавати.

DEF: Нефункціональна вимога – певна властивість, якість чи атрибут, якою повинна володіти система, умова якій та повинна відповідати або обмеження згідно з яким система працюватиме чи розроблятиметься.

Обмеження іноді розглядають окремо від нефункціональних вимог.

Кожна вимога повинна підтримуватись наступними твердженнями:

• Твердженнями щодо продуктивності, верифікації та обґрунтуванням.
• Визначення інших систем з якими система повинна інтегруватись та з якими повинна мати інтерфейс.
• Інформація щодо області застосування в якій працюватиме система

BRS та StRS не такі формальні як SyRS, але мають таку саму структуру, і підкоряються таким самим правилам.

Вимоги продуктивності – як добре система буде виконувати кожну з своїх функціональних вимог. Гарною дисципліною є мати хоча б одне твердження щодо продуктивності для кожної функціональної вимоги. Більшість функцій мають очевидній параметри продуктивності, такі як швидкість, витривалість, прискорення…

Вимоги верифікації – твердження що пояснюють як дізнатись чи система відповідає функціональним, та вимогам продуктивності. Немає сенсу описувати вимогу не знаючи як перевірити систему на її відповідність. І при наявності таких вимог набагато легше складати план тестування.

Обґрунтування (rationale) – причина через яку існує вимога. Записує рішення проектування, які привели до такої вимоги, і логіку яка стоїть за вибором певних чисел. Вимоги не повинні прийматись, якщо для них не існує зрозумілої та необхідної причини.

В теорії, вимоги описують ЩО, а не ЯК, але на практиці

• система може бути змушеною працювати певним чином
  • для сумісності з існуючими системами
  • чи відповідності певному стандарту
• конкретний приклад більш зрозумілий ніж абстрактна вимога
• Ті хто пишуть специфікацію самі можуть бути експертами в своїй області, тому вони знають ЯК.

Додаткові причини через які нам потрібні вимоги:

• Щоб визначити рамки (scope) проекту
• Щоб впевненись що кожен задіяний мав можливість висловити свою точку зору, і її врахували
• Щоб обґрунтувати витрати ресурсів
• Щоб звітувати про прогрес
• Щоб визначити коли роботу буде закінчено

DEF: Користувач (user) – хтось хто користується системою після її створення. Вони є частиною системи як і матеріали, ПЗ, обладнання, дані… В користувача може бути роль.

DEF: Клієнт (customer) – той хто платить за розробку

DEF: Acquirer (отримувач) – той хто отримує систему. Зазвичай організація клієнта має отримувачів окремо від користувачів, бо користувачі вже зайняті своїми поточними операціями.

DEF: Розробник (developer) – той хто створює продукт.

DEF: Контрактор – організація в якій відбувається розробка, пов’язана з клієнтом контрактом.

DEF: Stakeholder (зацікавлена особа) – будь-хто на кого впливає система, і хто має право впливати на вимоги. Користувачі постійно є зацікавленими особами, але також сюди може входити менеджмент, уряд та інші…

DEF: Requirements engineering – формальний процес що рухається від стратегії бізнесу до SyRS.

Причини використоувати інженерію вимог:

• Щоб могти отримати повні, недвозначні, несуперечливі вимоги.
• Щоб могти торгуватись між функціональністю та ціною
• Щоб могти керувати змінами в вимогах

Характеристики гарних вимог (бажано щоб були присутні в кожній вимозі):

• Обов’язкова (це очевидно, але варто окремо впевнитись, що без неї ми отримуємо не ту систему яку хочемо)
• Одна (single) (не бути комбінацією двох окремих)
• Коректна
• Недвозначна (всі хто її читають повинні розуміти одне й те ж)
• Здійсненна (feasible) (чи можна її дотриматись при існуючих технологіях та ресурсах?)
• Відповідна рівню (бізнес менеджери не повинні писати SysRS)
• Повна (подальших запитань не повинно виникати)
• Конформна (conforming) (повинна відповідати певній стандартній структурі)
• Верифіковна (verifiable) (як перевірити що система відповідає вимозі?)

Вимоги мають наступні атрибути

• Унікальний ідентифікатор
• Короткий заголовок (щоб на вимогу можна було посилатись простіше ніж через ID)
• Пріоритет (щоб був певний простір для маневру в дизайні)
• Ризики (наскільки ця вимога додає до загального ризику)
• Джерело (людина, організація чи документ)
• Обґрунтування (причина існування)
• Історія змін (зазвичай записується якимось програмним забезпеченням)
• Зв’язки з іншими вимогами.
• Інша інформація (дата створення, статус (прийнята, відкинута, виконана…), тип, тег…)

Також, вимоги описують емерджентні (emergent) властивості:

• ті які виникають лише після того коли окремі елементи були інтегровані в систему
• не проявляються в елементах системи поокремо
• залежать від взаємодії елементів системи і середовища
• описуються лише зверху вниз, бо не можуть бути описані у вимогах до підсистем.

Емерджентні властивості можуть бути неочікуваними (в тому числі й небажаними)

Вимоги записуються в Requirements Breakdown Structure – ієрархії, яку створюють за допомогою

• Elicitation (витягування, випитування). Ці вимоги отримуються через інтерв’ю, чи нараду, і записуються з джерелом.
• Elaboration (розвиток, уточнення)
  • Декомпозиція (Decomposition) – розбиття високорівневих вимог на низькорівневі.
  • Висновування (Derivaiton) – коли деякі вимоги необхідні щоб задовольнити інші вимоги.

Elicitaion та особливо Elaboration – заняття не для новачків, і інженер з вимог або бізнес-аналітик повинні розуміти бізнес, предметну область, конкретну проблему, потреби та обмеження системи для зацікавлених осіб, фазу отримання (acquisition) та керування проектами, інженерію вимог та системну інженерію, технології задіяні при інженерії системи. Такий набір навиків не трапляється випадково, і його потрібно цілеспрямовано розвивати.

Приклад місії системи:

Медичний центр МЦ, надаватиме обраний діапазон медичних сервісів, в безпечному і комфортному середовищі, для того щоб отримувати заданий прибуток.

Вимоги які ми отримуємо розбиттям:

• Надавати діапазон медичних сервісів
• Надавати безпечне середовище
• Надавати комфортне середовище
• Отримувати заданий рівень прибутку

Вимоги які можна вивести:

• Надавати інфраструктуру медичного центру
• Підримувати медичні сервіси
• Керувати медичним центром та його сервісами

Підходи до отримання (Elicitation) вимог:

• Структуровані воркшопи (з порядком денним)
• Мозкові штурми (менш структуровані)
• Інтерв’ю (воркшопи 1 на 1)
• опитування, анкети
• прецеденти (use cases) та операційні сценарії (історії користувача (user stories))
• симуляції, моделі та прототипи
• спостереження за процесом роботи
• участь в активностях роботи
• огляд технічної документації
• аналіз ринку
• аналіз конкурентих систем
• зворотня інженерія
• вимірювання продуктивності (benchmarking)

Верифікація та валідація (V & V)

DEF: Верифікація (Verification) – перевірка що система на кожній стадії відповідає специфікації яку для неї створили (SyRS)

DEF: Валідація (Validation) – перевірка що система відповідає початковим потребам та вимогам (BRS & StRS).

V&V здійснюється за допомогою тестування та оцінки (Test & Evaluation T&E)

Development T&E (DT&E) – здійснюється під час фази acquisition щоб підтримати розробку. Та під час utilisation щоб перевірити зміни.

Acceptance T&E (AT&E) – здійснюється клієнтом щоб дізнатись чи вони можуть прийняти систему від розробника. Виконується при переході від acquisition до utilisation.

Operational T&E – здійснюється певний час на початку фази utilisation, можна назвати це пробним періодом.

Менеджмент вимог

Вимоги змінюються бо:

• вони розробляються
• зацікавлені особи змінюють потреби
• бізнес змінюється
• середовище змінюється
• закони і регуляції змінюються

Часто більше половини системних вимог змінюється перед тим як система почне використовуватись. Зазвичай щоб забезпечити відслідковуваність (traceability) застосовується інструменти для менеджменту вимог.

Інструменти для менеджменту вимог:

• Підтримують Elicitation
• Дозволяють навігувати по вимогах та вибирати їх на основі критерію.
• Підтримують пряму і зворотню відслідковуваність
• Підтримують створення гарних вимог (шаблони, глоссарій)
• Дозволяють імпорт та експорт в різні формати (електронні таблиці та документи)
• Не нав’язують конкретний процес інженерії вимог.

Інструменти інженерії вимог:

• контекстні діаграми
• functional flow block diagram (FFBD)
• requirements breakdown structure (RBS)
• N2 diagram
• structured analysis
• data flow diagram (DFD)
• control flow diagram (CFD)
• IDEF diagram
• action diagram
• state transition diagram (STD)
• unified modelling language (UML)

RBS (фунціональна ієрархія) розробляється за допомогою переходу вимог від місії системи до її цілей, і підцілей. Додавання системи нумерації дозволяє кожному рівню пов’язуватись з попереднім.

RBS:

• Зображається ієрархічно
• Назви елементів мають базуватись на дієсловах
• Ключові фрази повинні бути короткими (три чотири слова)
• КОжна ключова фраза повинна бути унікальною
• Елементи повинні нумеруватись ієрархічно.

RBS може підтримуватись FFBD

• FFBD теж є ієрархічними (блоки можуть містити інші блоки рівнем нижче)
• Іменування та нумерація в FFBD повинна бути консистентною з RBS
• Повинна показуватись послідовність виконання функцій.

Наприклад:

Сигналізація активується -> Авторизований вхід -> Сигналізація деактивується

                   \
                     ->   Неавторизований вхід -> Сигналізація спрацьовує

Концептуальний дизайн

Успішні організації думають стратегічно та операційно. Операційне мислення стосується проведення щоденних операцій без заминок. Стратегічне мислення стосується більш довготермінових цілей. Іноді воно розкриває прогалини в операційній здатності (gap in operational capability).

Деякі з цих прогалин

• можуть завадити організації досягати стратегічних цілей
• не дають використовувати шанси
• можуть відкривати організацію для загроз.

Приклади: нестача персоналу, нестача інструментів… Прикордонна служба в Україні має прогалину в операційній здатності моніторити російський кордон.

Прогалини створюють потребу в рішеннях. Керівники бізнесу повинні пріоритизувати багато прогалин. Потреби пов’язані з критичними прогалинами започатковують початок циклу системної інженерії, і початок фази концептуального дизайну.

C1. Визначити бізнес потреби та вимоги

Коли у нас є критична прогалина здатності, ми визначаємо які основні зацікавлені особи пов’язані з прогалиною. Основні зацікавлені особи ідентифікують обмеження, бізнес вимоги, межі системи й інтерфейси, створють вимоги з потреб та узгоджують і фіналізують вимоги.

Приклади зацікавлених осіб:

• Менеджмент
• Інженери
• Підтримка
• Логістика
• Користувачі
• Клієнти

Приклади обмежень:

• Обмеження бізнесу: існуючі контракти, політики, стандарти і процедури.
• Обмеження проекту: бюджет і розклад.
• Зовнішні обмеження: закони та регуляції.
• Обмеження проектування: доступність технології, можливості виробництва.

Зібрати бізнес вимоги:

• Визначити місію системи, розширити її до цілей, а від них до функцій.
• Розробити сценарії що описують як система працюватиме.
• Розробити критерії валідації.
• Визначити концепти життєвого циклу
  • Як система буде працювати (операційний концепт)
  • Як розроблятиметься (acquisition concept)
  • Як переходитиме від розробки до використання
  • Як підтримуватиметься під час використання
  • Як буде ліквідовуватись

Рамки системи визначаються:

• Контекстом
• Межами
• Інтерфейсами

Це зображається на контекстній діаграмі, схожій на діаграму Вена.

Коли ми витягуємо бізнес вимоги з потреб, ми дивимось на обмеження та обираємо лише здійсненні (feasible) рішення.

Коли всі зацікавлені особи узгодять вимоги, вони створять Business Needs & Requirements, що складаються з:

• Preliminary Life-Cycle concept documents (PLCD)
• BRS

C2. Визначити потреби та вимоги зацікавлених осіб

Далі ми обираємо більше зацікавлених осіб (не тільки основних), і вони беруть Business Needs & Requirements, та розширюють і вдосконалюють їх.

Історії користувача розширюються до віньєток (vignettes) Критерії валідації розширюються до розширених критеріїв валідації PLCD розширюються до LCD (Life-Cycle concept documents) BRS розширюються до StRS

І це все в купі дає Stakeholders Needs & Requirements

C3. Визначити системні потреби та вимоги

На цьому етапі за домомогою аналізу вимог ми отримуємо SyRS. Це завдання для більш ніж однієї кваліфікованої людини. Ми зберігаємо відслідковуваність до StRS, і записуємо вимоги у фреймворк RBS.

• Визначити функціональні та нефункціональні вимоги і вимоги продуктивності
• Визначити якими повинні бути бажані емерджентні властивості
• Визначити вимоги верифікації і валідації
  • Верифікація: Чи збудували ми систему правильно?
  • Валідація: Чи збудували ми правильну систему?
• Присвоїти їм обґрунтування (rationale)
• Розмістити в RBS (вимога може приєднуватись до кількох місць в RBS, але без дублікації, лише за допомогою посилання. Дублікація вимог – це дуже погано).

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

Спіраль System Requirements Review (в зошиті).

C4. Провести синтез системного рівня

Чорновик SyRS розглядається потенційним контрактором і вони пропонують свої рішення. А також в більшості випадків – зміни до SyRS. Також вони інформують про ціну та терміни проекту. Отримувач розглядає різних контракторів і вибирає того який найкраще підходить перед тим як підписати контракт. Перед тим як узгодити SyRS проводяться переговори.

C5. Провести System Design Review (SDR)

На цьому етапі

• проводять огляд SyRS та запропонованого рішення
• відслідковують вимоги до StRS
• переглядають планування щоб виконати й керувати технічною програмою

Preliminary design

На цьому етапі у нас є контракт (чи щось на нього подібне, якщо контрактор знаходиться всередині організації замовника). Всередині контракту є SyRS та запропоноване рішення.

Підготовче проектування (preliminary design) – це розбиття системи на підсистеми і опис вимог для них. Утворюєтья ієрархія вимог від систем до підсистем, в якій теж не варто забувати про відслідковуваність. Зворотня відслідковуваність допомагає уникнути сповзання рамок (requirements creep), а пряма (forward traceability) – прибрати вимоги підсистем якщо зникне вимога до системи.

Також, на стадії підготовчого проектування ми ідентифікуємо інтерфейси підсистем (на додачу до зовнішніх, які ми визначили на етапі conceptual design).

Далі ми з’ясовуємо як краще створити підсистеми:

• Купити (Off the Shelf, OTS, Commertial of the shelf COTS).
• Модифікувати існуючу (Modified Off The Shelf, MOTS)
• Створити свою (Developmental)

Переваги та недоліки OTS:

• + відомі функції і продуктивність
• + доступні зразу
• + відома ціна
• – потрібна гарна документація щоб інтегрувати
• – може залежати від стабільності технології та розміру ринку

MOTS – майже так само як і в OTS, а також:

• – гарантія
• – підтримка
• – Недооцінка складності модифікації

Своя розробка:

• – Проблеми з життєвим циклом (треба запускати окремий процес системної інженерії)
• – Треба підтримувати також і підсистему
• + Ідеально оптимізована для місії системи (хоча в кінці розробки може виявитись і гірше ніж OTS)

При проектуванні потрібно давати певний простір для рішень. Наприклад якщо ми маємо вимогу зробити машину легшою за 1230 кг, і виділяємо на двигун 200 кг, а на систему охолодження 25, то якщо система охолодження вкладеться в 20 кг, ми можемо виділити на двигун 205кг.

Не варто розробляти машину яка перевершує деякі свої вимоги, але не дотримується інших.

Підготовче проектування закінчується коли є вимоги для всіх підсистем, разом з простором для проектування. Після цього роблять Preliminary Design Review (PDR). На ньому задають питання на зразок “Коли ви розглядали цю опцію, які опції ще ви розглядали?”, “Ви врахували проблеми всього життєвого циклу?” і т.п.

Детальний дизайн

Цю стадію проходять підсистеми що ми розробляємо самостійно, а також MOTS підсистеми. І процес інтеграції OTS підсистем. Метою детального проектування є створити готовий до виробництва чи будівництва план.

Протягом цієї фази ми:

• Впевнюємось що всі елементи можливо створити
  • Деталі, матеріали, процеси та навики доступні
• Проектуємо елементи відповідно до специфікації
  • Ітеративно (тому що з першого разу гарний дизайн рідко виходить)
  • Прототипуємо, моделюємо
  • Користуємось CAD
  • Перевикористовуємо дизайн існуюючих систем
• Впевнюємось що всі елементи можна буде інтегрувати рівнем вище.

В кінці цього дизайну роблять Critical Design Review. Питання задають ті самі що й в PDR, але на іншому рівні.

Виготовлення і побудова

Ми використовуємо документацію з попередньої фази (дизайн, списки деталей, специфікації матеріалів, описи процесів…). Паралельно над дизайном працювали спеціалісти з виробництва та Integrated Logistics Support Specialists, для того щоб бути певними що план можливо здійснити.

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

Робити зміни на цій фазі – дуже дорого. Також, на цій фазі постійно проводяться перевірки того що система працює як задумано:

• Інспекції (прийти і побачити що кімната відповідає плану)
• Аналіз (Перевірити документацію COTS підсистем)
• Тести (перевірити що вода в трубах тече)
• Демо (показати що світло вмикається)
• Фізичний аудит (збудована система відповідає кресленням)
• Логічний аудит (функціонування системи відповідає документації)

Щоб перейти до фази використання створюють всю інфраструктуру, набирають персонал і проводять його навчання.

Використання (utilisation)

Далі систему використовують щоб закрити прогалину в операційній здатності.

Також потрібно здійснювати підтримку системи:

• Операційну (наприклад прибирання, заміна лампочок)
• Ремонт (Maintenance) (латання даху, чистка дренажу)
• Інженерну (+ зміни) (стає можливою завдяки коректній документації)

Модифікації на цій фазі можуть бути потрібні щоб:

• Реагувати на зміни
  • Вимог
  • Середовища
• Покращувати підтримуваність

Ліквідація (disposal)

Коли зникає початкова потреба або система більше не є життєздатною.

Варіанти:

• Продаж іншій організації
• Переробка на матеріали
• Використання в іншій ролі

Менеджмент

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

Менеджмент тестування

Ми проводимо тестування

• Під час розробки (DT&E)
• Перед використанням (AT&E)
• Під час використання (Може приводити до модифікацій системи)

Система вважається валідною коли зацікавлені особи задоволені, і така система включає в себе окрім верифікованої основної системи (відповідної специфікаціям), верифіковані інтерфейси з зовнішніими системами, підтримку, навчання та персонал.

Тестування повинне бути запланованим, інакше для нього доведеться або роздувати бюджет та розклад проекту, або створювати нетестовану систему.

Керування конфігурацією (configuration management)

Мета керування конфігурацією – контролювати версії всього що є у нашій системі:

• Документації
• ПЗ
• Апаратного забезпечення
• Інтерфейсів для інтеграції системи

Якщо у будинку архітектор і майстер будуть мати різні креслення вікон – буде проблема. Тому варто впевнитись що всі працюють з однією версією всього.

Керування конфігурацією полягає в:

• Ідентифікації всього що буде контролюватись
• Повідомленні про поточний актуальний стан цих елементів всім кого це стосується (status accounting)
• Розгляд пропозицій щодо змін в цих елементах (і проведення дискусії між всіма зацікавленими особами) (change management)
• Періодичний аудит для того щоб впевнитись що всі використовують актуальну конфігурацію.

Управління ризиками

Ризик – це шанс що станеться щось що вплине на досягнення нашої цілі.

• Cost risk – вихід за бюджет
• Schedule risk – перевищення термінів
• Technical risk (головний фокус в SE)
  • Невідповідність вимогам
  • Ненадійна система
  • Важко виробляти в потрібних об’ємах

Ми розглядаємо ризики в двох аспектах:

• Ймовірність що він трапиться
• Рівень впливу на результат, якщо таки трапився

За цими двома параметрами ризики розташовують в діапазоні від незначних (insignificant) до екстремальних (extreme risks).

Найбільш значних ризиків ми:

• Уникаємо
• Зменшуємо
  • ймовірність (наприклад додатковий генератор і акумулятори, проектуємо з надлишковою міцністю)
  • вплив (наприклад шолом чи паски безпеки)
• Передаємо організації яка краще на них спеціалізується (швидкій допомозі, пожежникам, страховій фірмі)
• Іноді приймаємо ризики (наприклад при використанні нової технології)

Рев’ю технічної програми

Проводиться на всіх стадіях. БО чим раніше ми виявимо проблему, тим дешевше і легше її буде виправити.

• System Design Review
• Preliminary Design Review
• Critical Design Review

Рев’ю – це технічні наради, формально проведені (з порядком денним, модератором…)

Наради не варто проводити доки не буде готовим артефакт який обговорюватимуть. Якщо специфікація не готова, варто відкласти нараду, а не проводити її згідно розкладом, сподіваючись наздогнати і зробити потрібні зміни пізніше.

“Погані новини не схожі на вино, вони не стають кращими з часом.”

Проекти що містять більше ризиків, потребують більше рев’ю ніж проекти з незначними ризиками.

Вибір підходящої методології

В цьому курсі ми розглядали водоспадну модель, тому що вона найпростіша. Її можна застосовувати коли є:

• Чітке розуміння проблеми і бажаного вирішення
• Чітикий запис цього розуміння в системні вимоги
• Вимоги змінюються нечасто
• Технологія доступна і стабільна
• Часу і грошей достатньо щоб розв’язати проблему за один раз.

І хоча таке нечасто зустрічається, але зустрічається. Проте застосовувати waterfall в інших випадках може бути шкідливо.

Наприклад, якщо у нас не вистачає бюджету щоб збудувати всю систему, ми лише проектуємо її повністю, а тоді будуємо лише частину. І коли додатковий бюджет з’являється – добудовуємо згідно плану. Такий підхід називається інкрементним (incremental approach).

Якщо не всі вимоги зрозумілі, ми будуємо систему для виконання зрозумілих вимог, а тоді при появі потреби – вносимо зміни. Це – еволюційний підхід (evolutionary approach).

Не варто вважати що якщо методологія спрацювала в одному випадку, то працюватиме і в іншому.

Планування в менеджменті

• Яку методологію ми використовуємо?
• Хто що робить?
• Коли відбуваються рев’ю?
• Які ресурси потрібні?
• Яким ризикам ми піддаємось?
• Як ми підходимо до T&E, керування конфігурацією та інженерії вимог?

Ви результаті планування ми отримуємо System Engineering Management Plan (SEMP).

Цей план зазвичай не залишається статичним на типовому проекті