Життєвий цикл розробки пристрою. Частина 1

На рисунку показаний цикл розробки пристрою. Перед тим як продукт буде готовий він проходить через кілька стадій :  “Аналіз проблеми” – “Проектування” – “Розробка” – “Тестування” – “Виробництво”. Для простих систем може бути достатньо одного циклу.
На стадії “Аналіз проблеми” розглядаються вимоги та обмеження.

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

product development process

Часто покращення одного параметру може бути досягнуто тільки за рахунок зниження якості іншого: збільшення автономної роботи пристрою, може збільшити розмір пристрою за рахунок більшого розміру батареї. На подібні компороміси часто доводиться йти інженеру при проектуванні пристрою. Система може бути обмежена такими факторами як вартість, безпека, сумісність з іншими продуктами, використанням конктретних електронних та механічних частин, а також часом розробки. Наступні критерії часто розглядаються на етапі “Аналіз проблеми”:

Безпечність: ризики для людей та оточуючого середовища;
Похибка:
різниця між очікуваними параметрами та реальними;
Час реакції:
час між виявленням події та реакцією на неї;
Потужність:
кількість енергії яка потрібна для роботи пристрою;
Розмір і маса:
фізичні вимоги до системи;
Вартість одиниці товару:
вартість виробництва для 1 одиниці продукту;
Час розробки: час потрібний для проектування, розробки та тестування;
Людський фактор:
оцінка наскільки зручною в користуванні буде система;
Сумісність: наскільки пристрій сумісний з існуючими стандартами;

Роглянемо шаблон документа для тенхічних вимог:  IEEE STD 830-1998.  В таких документах описується що система буде робити, однак не взазується жодних деталей як саме. Основна мена цього документу служити посередником між інженерами та замовником. Цей документ може бути юридично – зобов’язучим  договором. Він повинний бути написаний так щоб бути зрозумілим як замовнику так і розробникам. 

Документ складається з 3 основних частин:

  1. Загальні положення
    1.1. Цілі: Чому ми робимо цей проект? Яка мета?
    1.2. Процес: Як розвиватиметься проект?
    1.3. Ролі та обов’язки: хто що робитиме? Хто клієнти?
    1.4. Взаємодія з існуючими системами: Яким  чимном система буде сумісна?
    1.5. Термінологія: Визначити терміни, що використовуються в документі.
    1.6. Безпека: Як буде захищатись інтелектуальна власність?
  2. Функціональний опис
    2.1. Функціональність: Що саме буде система робити ?
    2.2. Обсяг: Перерахуйте фази і що буде зроблено в кожній фазі.
    2.3. Прототипи: Як можна буде продемонструвати проміжний прогрес?
    2.4. Продуктивність: Визначити заходи і описати, як вони будуть визначатися.
    2.5. Зручність: Опишіть інтерфейси. Кількісно , якщо це можливо.
    2.6. Безпека: Поясніть вимоги безпеки і як вони будуть оцінюватися.
  3. Кінцевий продукт
    3.1. Звіти: Як буде система описується?
    3.2. Аудит: Як клієнти будуть оцінювати прогрес? 
    3.3. Результати: Які очікувані? Звідки ми знаємо, коли це буде зроблено?

Більш детально з процесом розробки можна ознайомитись в цьому відео:

Корисні лінки:

Курс, матеріал якого взятий за основу:  UT.6.01x Embedded Systems – Shape the World
Шаблон Requirements Document:  IEEE STD 830-1998.