Определяне на минималните системни изисквания за спестяване на пари и време при проектиране на хардуер
Как да започнете разработването на изцяло нов продукт? Ако интегрирате IoT, изкуствен интелект, тенденции от Industry 4.0 или автоматизация в проекта си, ще се сблъскате с повтарящи се проблеми при събирането на спецификации в процеса на проектиране. Тъй като разработването на нови технологични продукти може да отнеме средно между 2 и 5 години, методологиите за проектиране трябва да се използват като основа за определяне на системните изисквания по отношение на хардуера, за да се спестят ресурси и пари.
Ако прочетете нашите предишен блог Относно разликата между минимални и твърди системни изисквания, вече знаете, че първите исторически се занимават с правно покритие за компаниите за разработка на софтуер за решаване на оплаквания, когато софтуерът им не работи правилно на определени хардуерни платформи. За разлика от тях, твърдите системни изисквания се отнасят до спецификациите, без които софтуерът няма да работи.
Освен това, когато се разработва нов продукт, ще се сблъскате с някои повтарящи се проблеми по време на процеса на проектиране, които могат да бъдат скъпи. Ако по време на началните фази, преди създаването на прототип, не дефинирате точно системните изисквания, в крайна сметка ще похарчите много пари за оборудване за тестови цели. Чрез използването на методология за проектиране във всяка нова разработка можете да избегнете грешки в тази скъпа част от процеса. Нека разгледаме някои подробности.
Първата стъпка към спестяване на пари
Във всяка методология на проектиране, първата стъпка за спестяване на пари е прецизното събиране на спецификациите за системата. За вградените системи, например, можете да работите върху дефинирането на архитектурата. Това е методология, която позволява на интердисциплинарен екип да работи заедно, за да картографира връзките между хардуер и софтуер, като същевременно се грижи за нуждите на крайния потребител, използвайки общ език. Можете прочетете повече в тази публикация. Най-важният аспект на тази първа стъпка е комуникацията между различните страни (технически и нетехнически), за да се гарантира, че крайните резултати са получени точно от софтуерна и хардуерна гледна точка.
Дефиниране на твърди системни изисквания
След като съберете първоначалните изисквания, трябва да ги превърнете в твърди системни изисквания. Някои категории, които трябва да определите, са ограничения на техническата архитектура, имплицитни хардуерни изисквания, контекстуални хардуерни изисквания и минимални поддържани хардуерни изисквания. Можете да прочетете повече за тези изисквания в тази публикация.
Как това се свързва с минималните системни изисквания? Ако следвате солидна методология за проектиране, вашите минимални и твърди изисквания трябва да са еднакви. Освен това, трябва да определите целевата и желаната хардуерна платформа, производителност и надеждност.
Чрез дефиниране на скала между вашите твърди и желани параметри, можете да създадете рентабилна, повтаряща се тестова среда на различни хардуерни платформи. Само тогава ще можете да определите кои системи работят най-добре с вашия софтуер. Следователно, вашите минимални системни изисквания ще се основават на реални данни за производителността.
Готова ли е индустрията?
Въпреки това, индустрията все още няма стандартна процедура или методология за тестване на системи, за да се определят минималните системни изисквания. В повечето случаи компаниите разработват свои собствени и ги използват лично или, в най-лошите случаи, просто гадаят какви могат да бъдат тези минимални изисквания. За съжаление, някои компании използват хардуерната платформа за разработване на софтуер като ориентир за определяне на минималните системни изисквания. Проблемът е, че платформата, която обикновено се използва за разработка, има прекалено големи компоненти, което увеличава цената на крайната система.
В резултат на това ще водите трудна битка срещу нарастващите разходи през целия жизнен цикъл на продукта, особено при настоящите пазарни условия и проблеми с веригата за доставки. Преоразмеряването на компонентите и придържането към един набор от спецификации с една опция за всеки компонент е просто лукс, който вече не можете да си позволите.
Вярно е, че методологията на проектиране и дефинирането на твърди системни изисквания ще отнемат повече време, отколкото вероятно сте свикнали в началото на процеса, но това ще намали времето за пускане на вашия продукт на пазара, ще ви спести много пари по време на фазите на създаване на прототипи и ще ви даде гъвкавост по време на етапа на масово производство. И накрая, методологията на проектиране ще удължи жизнения цикъл на продукта и ще ви даде възможност да го изведете от производство при ваши условия.
Как мога да разработя собствена тестова среда?
Въз основа на твърдите изисквания, трябва да изберете няколко хардуерни платформи, освен системата, използвана за разработване на софтуер, и да стартирате решението в няколко различни сценария и потребители. Уверете се, че сте включили едни и същи задачи във всички системи и сте стартирали софтуера както за първи път, така и като потребител, който интензивно се възползва от него. Уверете се, че можете да изпълнявате всички задачи, които крайните ви потребители ще използват с вашето оборудване. И накрая, систематично запазвайте данните, за да ги анализирате и да вземате решения. Тъй като няма текущ индустриален стандарт, партнирайте си с производител на хардуер, който може да ви води през този процес и който може да бъде истински бизнес партньор, като същевременно разработва надеждна и повтаряема методология за събиране на минимални и твърди системни изисквания.
Ако искате да продължите да четете за вградените системи, можете да прегледате тази страница.
