Розробка мікропрограми складається з п’яти етапів

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

Освоєння створення надійної архітектури мікропрограми та одночасна реархітектура застарілого програмного забезпечення може бути складним і тривалим процесом.

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

Крок 1: Визначте необхідні специфікації.

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

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

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

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

Повний набір вимог складається з письмових заяв, які починаються ключовою фразою «[товар] повинен...».

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

Крок 2: розрізняйте архітектуру та дизайн

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

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

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

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

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

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

Крок 3: Управління часом

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

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

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

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

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

Крок 4: Тест-орієнтований дизайн

Тестування має вирішальне значення для кожної вбудованої системи. Проведення багаторівневого тестування є обов’язковим і дуже важливим. Основні рівні тестування включають:

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

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

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

Модульні тести оцінюють загальнодоступний API (інтерфейс прикладного програмування), який компонент представляє іншим елементам. В ідеалі розробники повинні створювати модульні тести для власного коду, щоб максимізувати їхню ефективність.

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

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

Крок 5: Підготуйтеся до змін

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

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

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