Як уникнути проблем із програмним забезпеченням

У цю цифрову епоху ви, напевно, чули про гігантів соціальних мереж, таких як Facebook і Twitter, і платформи електронної комерції, такі як Alibaba і Amazon. Ці онлайн-сайти використовують різні пакети програмного забезпечення для своєї роботи. Ці програми досить відверто змінили те, як ми працюємо, думаємо і живемо.

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

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

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

1. Вимкнення служби 911 у кількох штатах США

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

Таким чином, було дуже лихом, коли 9 квітня 2014 р. Помилка маршрутизації виклику 911 у семи штатах США, включаючи Каліфорнію, Флориду, Міннесоту, Північну Кароліну, Пенсільванію, Південну Кароліну та Вашингтон.

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

2. Приземлення флоту United Airlines

У липні 2015 року United Airlines була змушена зупинити весь свій флот літаків через програмний збій. Це вплинуло на понад 4900 рейсів по всьому світу, і багато пасажирів залишилися в аеропортах і, очевидно, були розчаровані.

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

3. Несправність педалі акселератора Toyota Camry

У вересні 2007 року Джин Букаут їхала по міжштатному шосе 69 в Оклахомі з пасажиркою Барбарою Шварц, коли зіткнулася з труднощами. керуючи своєю Toyota Camry.

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

На жаль, це призвело до того, що автомобіль з’їхав на набережну. В результаті Шварц помер, а Bookout був госпіталізований на п’ять місяців через тяжкі травми.

Було припущено, що аварія сталася через декілька невідповідностей кодування, які призвели до збою завдання в CPU Camry. Цей процесор міг би керувати надзвичайно величезною кількістю функцій, включаючи запалювання, контроль дросельної заслінки та круїз-контроль.

Код Toyota став заплутаним безладом після кількох років нагромадження нових кодів на старі. Зазвичай це називають «кодом спагетті».

Однак нещасний випадок з Bookout висвітлив цю проблему і висвітлив недоліки Toyota в їхньому програмному забезпеченні. Було навіть виявлено, що існує понад 10 мільйонів способів для потенційне небажане прискорення, заснований на тому, як був структурований код Toyota.

Несправність термостата Nest

Nest — компанія, що належить Alphabet, що робить розумні термостати. Ці термостати досить витончені і дозволяють користувачам контролювати температуру в своїх будинках зі своїх смартфонів.

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

Короткий аналіз проблем із програмним забезпеченням

Такі підходи, як проектування на основі моделі та TLA+, дозволяють розробникам отримати більш широке уявлення про те, як працює їхнє програмне забезпечення.

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

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

Однак надія є. Такі підходи, як дизайн на основі моделі та TLA+ дозволяють розробникам отримати більш широке уявлення про те, як працює їхнє програмне забезпечення.

Дизайн на основі моделі, як випливає з назви, дозволяє розробляти програмне забезпечення за допомогою візуальних моделей. TLA+, що скорочується від Temporal Logic of Actions, — це мова, призначена для написання специфікацій комп’ютерної програми. Що чудово в TLA+, так це те, що він дозволяє вичерпне тестування та перевірку програмного забезпечення до того, як воно стане оприлюдненим.

Як дизайн на основі моделі, так і TLA+ вже довели свою перевагу. Технології Esterel, фірма з розробки програмного забезпечення, використовує дизайн на основі моделі для створення критичного для безпеки програмного забезпечення, тоді як TLA+ використовується такими, як Microsoft виправить можливу катастрофічну помилку Xbox, а Європейське космічне агентство перепише коди для зонда, який приземлився на комета.

Процес написання коду високо цінується програмістами. Багато з них просто заінтриговані процесом написання кодів. Таким чином, змусити деяких програмістів прийняти такі підходи, як проектування на основі моделі та TLA+, є викликом. Ці підходи часто сприймаються як суто академічні без реальної життєздатності. Однак зміна погляду повинна відбутися якомога раніше.

Останні думки

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

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

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

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

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