Регулювання галузі програмного забезпечення [закрито]


85

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

Ця стаття IEEE останнім часом привертає деяку увагу до цієї теми.

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

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

Цитата, яка для мене викликає таке:

Іспит перевірятиме основні знання, а не оволодіння предметом

оскільки великі невдачі (наприклад, THERAC-25 ) здаються складними, тонкими питаннями, яких «базових знань» ніколи не буде достатньо для запобігання.

Ігнорування будь-яких місцевих проблем (наприклад, існуючий захист звання Інженер у деяких юрисдикціях):

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

1 Саме так, як передбачалося зробити регулювання медичної професії.


3
Я сподіваюся, що Томас Оуенс відповість на це, тому що я знаю, що він має ідеальну відповідь.
maple_shaft

3
Як би я хотів почути, що люди мають сказати на цю тему, мені це дуже схоже на дискусійне запитання, щоб воно добре підходило до формату запитів і запитів Stack Exchange.
PersonalNexus

12
Чесно кажучи, я виступаю за поправку до конституції, яка створює розмежування технології та держави, враховуючи те, наскільки урядовим виглядає Уряд, коли регулює технологію (див. Також SOPA)
JohnFx

3
Як можна регулювати галузь, коли вона змінюється щодня?
Джон Рейнор

4
Не так багато таких "досить хороших" ситуацій, які пізніше спричиняють помилки, часто є виною керівництва / маркетингу, кажучи: "ДОСТАВКА ДОСТАВКА!"
Арен

Відповіді:


105

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

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

- Мітч Торнтон, віце-голова ліцензії та реєстрації IEEE

Це звучить дуже розумно на поверхні. Зрештою, є й інші галузі, які можна вважати «успішно регульованими». Під успішним регулюванням я маю на увазі, що якщо ви дивитесь лікаря на жовті сторінки, ви можете бути впевнені, що він чи вона отримали ґрунтовну освіту в акредитованому університеті та склали ряд іспитів та пройшли резиденцію. Ось кілька «успішно регульованих» галузей (з точки зору професійних кадрів).

  • Юристи
  • Лікарі
  • Бухгалтери
  • Ядерні інженери
  • Перукарі ( не жартую )

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

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

Це неясне твердження і відкрите для ліберальної інтерпретації та застосування. Я можу зробити аргумент, що Apple Inc. або Facebook є невід'ємною частиною американської економіки - чи потрібна мені спеціальна ліцензія від уряду, щоб зараз писати для них код, оскільки якщо я збиваю сайт з моєї некомпетентності, я можу пошкодити американську економіка? На своїй останній роботі я випадково вимкнув зерновий елеватор із несправним роботою з кроном - можливо, загрожуючи постачанням продуктів харчування.

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

Ось проблема: інженерія програмного забезпечення в цей день і вік охоплює все, і ви не можете перевірити будь-яку дисципліну. Правила ведення бізнесу є надто конкретними та занадто різними від дисципліни до дисципліни. Наш гіпотетичний інженерний код написання для системи ABS на Jetta може написати щось зовсім інше для системи ABS на Elantra. Чи потрібно йому переатестуватися?

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

За словами Мітча Торнтона, віце-голови Комітету з питань ліцензії та реєстрації IEEE, іспит перевірятиме базові знання, а не оволодіння предметом.

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

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

Це те, що ви можете враховувати в розробці, але ви ніколи не можете перевірити сертифікацію .

Ось що буде, якщо ця "сертифікація" набуде чинності: кількість випадків залишиться точно такою ж. Чому? Тому що це не робить нічого, щоб усунути справжню проблему збою АБС або інсулінового насоса.


33
+1 відмінна відповідь. Мені особливо подобається: "Брак основних знань ніколи не є проблемою".
Джонатан Хенсон

4
Чудова відповідь, але вона враховує інженерію програмного забезпечення лише з точки зору програмістів. Справжня інженерія програмного забезпечення насправді - це командне зусилля, що включає багато наборів та дисциплін, бізнес-аналітиків, забезпечення якості, управління проектами тощо ... Інциденти настільки ж ймовірні внаслідок поганого програмування, оскільки вони пропущені вимоги, неправильно зрозумілі вимоги, погано керовані проекти і неправильне тестування. Чи згадується тест ОП про щось таке? Звичайно, не тому, що це для програмістів.
maple_shaft

3
Я хотів би додати, що я думаю, що вся ідея IEEE - це сміття для початку. Все, що уряд повинен зробити, - це його робота, щоб виправити проблему. Нести відповідальність за будь-які збитки, завдані комусь. Це одне піклується про проблему
Джонатан Хенсон

16
Не погоджуючись із "Відсутністю базових знань - це ніколи не проблема". Насправді це часто є проблемою. Як часто нові програмісти (або старіші) нехтують санітарною обробкою? Перевірка кутового корпусу? Для фізичних систем я можу прочитати датчик. Це може бути увімкнено або вимкнено. А що з зламаним? Як моє програмне забезпечення може сказати? Тоді що я з цим робити? Припустимо, він увімкнено чи вимкнено? Такі типи "основних" речей, як правило, є спірними.
sdg

3
@JonathanHenson Знову ж таки, я вважаю, що більшість випадків ін'єкції SQL є саме таким - не вистачає базових знань ... але загалом, хороший пост. +1.
Джефф Ферланд

72

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

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


10
+1 для "Інженери програмного забезпечення вже вкрай регламентовані як члени відповідних галузей, що є найважливішими для безпеки, і поза цими галузями мало потреби"
Тревор Бойд Сміт

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

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

2
@larsmans Я погоджуюся з Карлом, якщо уряд має справу з ракетою або чимось там, де він вважає, що високі стандарти повинні бути дозволені, нехай наймають власних програмістів та інженерів відповідно до будь-якого стандарту, який вони оберуть. Приватний сектор не повинен заробляти гроші на державному ризику - це фашизм. Приватній галузі не слід дозволяти загрожувати громадськості для початку. Люди, які знають, що їм найкраще потрібно, - це люди, які ризикують. Нехай вони самі займаються своїми справами. І так, я знаю, що це роблять маточники тощо. Їх не можна пускати.
Джонатан Хенсон

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

32

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

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

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

Крім того, проблеми, які цей захід намагається запобігти, ймовірно, не виявляться тестом. У будь-якому разі, я також хотів би бачити @ThomasOwens відповідь на це.

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

Оновлення

Я думав про це ще дещо минулої ночі над пивом чи десятьма.

Все, що регулювало сферу медицини, - це винищення всіх парадигм, окрім однієї. Якщо їх метою було відлучити лікарів-гомеопатів та натуропатів, яких оперативно називали «кваквами», то таке регулювання було успішним. Однак я не погоджуюся з тим, що таке вигідно для всіх, крім людей, які пишуть законодавство. Подумайте, що це зробило. Це підняло витрати на медичну допомогу до нестабільних рівнів, значно збільшило рівень відповідальності за медичні послуги та вилучило всю споживчу силу з вибору та самовизначення з ринку. У медичній спільноті більше немає ринку ідей, і нові методи лікування та способи мислення про медицину зараз придушені. Крім того, бар'єр для виходу на поле є надзвичайно високим, і, як наслідок, у нас є дефіцит хорошого МД с. Крім того, регулюючі органи мають повноваження контролювати постачання лікарів, щоб вони в свою чергу контролювали ціну, яку лікарі платять.

Дійсно є певні вигоди, які ми отримали від медичного регулювання, але витрати є надто високими.

Це ж відбудеться з інженерами програмного забезпечення, якщо таке регулювання буде прийнято. Я бачу це зараз, регулюючі органи будуть приймати рішення про те, що об'єктно-орієнтоване програмування є єдиним стандартом дизайну, а функціональним та процедурним програмістам не буде дозволено практикувати. Тоді вони почнуть нам говорити, що нам не дозволяється керувати власною пам’яттю, оскільки це не безпечно. Тоді вони будуть стискати JAVA та C # всі наші горла та кажуть нам, що ми повинні ним користуватися, поки Oracle та Microsoft стають жирними та щасливішими. Інновації будуть задушені, а творчість буде поза законом. Microsoft та Google пишуть законодавство, тож правила ринку будуть спрямовані на власну прибутковість та проти соціального добробуту.

Крім того, дозвольте нагадати всім, що комп’ютери почалися як захоплення та академічне починання. Крім війн Unix 80-х - початку 90-х у нас були безкоштовні операційні системи, безкоштовні компілятори, безкоштовні програми тощо ... Це швидко закінчиться. Світ, який заповідали нам Річард Сталлман, Лінус Торвальдс і Денніс Річті, поступово згасне від існування.

Підсумовуючи, чи не втомлюється я конкурувати з "Я буду створювати вам CMS-сайт Wordpress за 25 доларів на годину" або "будь-який додаток для iPhone за 500 доларів"? Не дуже, чому? Тому що я чортів добре в тому, що я роблю, і клієнти, яких я хочу, готові платити за досконалість. Коли я беру проект самостійно або за місцем своєї роботи, я ризикую отримати свої власні зусилля і репутацію. Це піде за мною, куди б я не поїхав. Також більшість людей знають, що отримують те, за що платять. Клієнт, який готовий заплатити мені лише ціну, яку вони платять своєму хлопцеві на газоні, буде кошмаром, з яким завгодно боротися. Якби уряд зафіксував правову структуру, щоб змусити постачальників послуг відшкодувати свої збитки, тоді б дуже мало поганих програмістів, які все ще мали роботу в цій галузі.

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


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

4
@ Джонатан Хенсон: Загалом, звичайно, це не так. Багато тестів набрали нуль на тесті Джоеля. ( joelonsoftware.com/articles/fog0000000043.html ) Щодо того, чи не повинні , це ділове рішення, а не моральне рішення. Всі ці речі коштують грошей: багато-багато грошей. Якщо ви будуєте систему управління повітряними суднами, з часом вигідно взяти на себе ці витрати; якщо ви будуєте гру у фейсбуці, можливо, ні.
Ерік Ліпперт

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

1
@Andy, я думаю, ми повинні попросити обмін стеками змінити назву цього сайту на softwareengineers.stackexchange.com :)
Джонатан Хенсон

1
@JonathanHenson Offend? Ні в якому разі, не хвилюйтеся! :) Я мав би зробити це трохи зрозумілішим, що я розмістив посилання лише тому, що це було дивно збігом з вашим коментарем.
янніс

23

Новини Силіконової долини - 31 червня 2015 року

Жах: Несертифікований програміст зробив програму перервати

"Я більше ніколи не зможу бігти", - виводить жертва. Поліція проводить розслідування.

Злочин: Ліцензія доктора Х. Акер-молодшого відкликана за неправильне використання вказівника та спроби читання з системного файлу

Адвокат каже, що буде апеляція до Верховного суду.

Анонси: Програмісти Cobol, сертифіковані в 1975 році, повинні бути переоформлені не пізніше 2025 року

IEEE підтверджена сертифікація не змінилася з того часу

Оголошення: Сертифікація гарантована Magic Knowledge Stuffers, Inc

Навчіть себе програмуванню за 21 день.


Я намагаюся вирішити, чи це настійний повний відповідь чи жартівливий коментар. (Можливо, обидва?)
Ліндон Уайт

@Oxinabox 31 червня дата жартівлива
гнат

"Навчіть себе програмуванню за 10 днів!" hehe
BЈоviћ

20

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

Мені подобається думати про це як про те, що я починаю з програми інженерії програмного забезпечення (SWEBOK) та Кодексу етики та професійної практики інженерної програми . Хоча загальне їх прийняття все ще досить обмежене, я вважаю, що вони слугують гарною базою для визначення типів речей, про які хтось, ідентифікуючи себе як інженер-програмник, повинен знати і як така людина повинна діяти в професійній якості. Це не означає, що це жорсткі правила, але, скоріше, ці документи керуються професійними інженерами програмного забезпечення щодо того, що зазвичай стосується роботи, яку вони можуть просити виконати. SWEBOK час від часу переглядається, щоб гарантувати, що він залишається актуальним.

Наступна характеристика - акредитація освітніх програм. У США акредитацією програм інженерних програм проводиться ABET . Вони також акредитують інформатику, інформаційні технології, обчислювальну техніку та інші професії, що стосуються обчислень. ABET розміщує свої вимоги до акредитованих програм на своєму веб-сайті - інженерія програмного забезпечення вважається інженерною програмою. Мета акредитації - забезпечити послідовність випускників різних інженерних програм, принаймні з точки зору предмета, який викладається на уроці. Про якість освіти це нічого не говорить.

Після закінчення навчання сертифікація та ліцензування використовуються для оцінювання знань, отриманих на уроці (а в деяких випадках і на роботі), проти стандартних тіл знань. Хоча в акредитованих школах є визначений масив матеріалу, який слід викладати, не існує міри того, наскільки добре цей матеріал викладається та скільки учнів навчаються після завершення програми. Сертифікація та ліцензування пропонують методи для цього - всі складають однакові іспити та демонструють знання в різних галузях знань, в яких походить ця професія. У галузі програмної інженерії IEEE пропонує сертифікати, коріння яких є SWEBOK - сертифікована розробка програмного забезпечення Асоційований для старших та недавніх випускників та сертифікований фахівець з розробки програмного забезпеченнядля тих, хто має галузевий досвід. Щоб вони додали цінності, потрібно визнати SWEBOK як хороше визначення того, що таке інженерія програмного забезпечення.

Нарешті, професійні товариства підтримують керівні документи для професії, сприяють проведенню конференцій та публікацій для обміну знаннями та ідеями, подолання прогалин між науковими колами та промисловістю тощо. Два провідні товариства - це комп'ютерне товариство IEEE та ACM , але є й інші товариства по всьому світу. Вони загортають все в приємний пакет і допомагають доставляти інформацію потрібним людям.

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

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

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

Однак є одна яскрава проблема сертифікації - це тест на книгу. Деякі люди добре читають, навчаються, запам'ятовують і здають тест. Однак це не означає, що вони хороші інженери. Люди весь час прослизають через щілини. Сертифікація або ліцензія - це лише один крок. Навчання на роботі та наставництво з боку інших досвідчених інженерів обов'язково підходить для хорошого практикуючого. Крім того, можливість запобігти практиці людей у ​​критичних умовах також може допомогти зменшити ризики для суспільства та бізнесу.

Хороша книга з досить глибоким обговоренням цього питання - це Професійна розробка програмного забезпечення Стіва МакКоннелла : скорочення графіків, продукти вищої якості, більш успішні проекти та покращена кар’єра .


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

"двоє з трьох заслуговують на увагу кваліфікованого інженера" ​​ви маєте рацію, космічні кораблі не все так складно зробити
zzzzBov

+1 спасибі за те, що ви додали свій внесок до цього питання. Сподіваюся, ви почуваєте себе краще.
Джонатан Хенсон

12

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

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

Люди роблять помилки, і жодна норма регулювання не запобіжить виникненню катастроф. Розглянемо NASA, яка на сьогодні має найсуворіші вимоги до розробки програмного забезпечення, відомі людині. У них все ще є програмні помилки? (Так, так, і багато разів, так!)

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


8
Фантастичним доповненням до цієї відповіді був би перелік існуючих програмних компаній, які, мабуть, не були б розпочаті, якби ці норми діяли. Майкрософт та Facebook - це гарний початок, оскільки сертифікація, ймовірно, потребує ступеня (майже кожна професія, яка починається з тестування, додає ступінь вимоги, якщо вони не починаються з однієї).
пн

1
@maple_shaft, ІМО, порівнюючи лікарів / юристів з інженерною програмою, не є дійсним. Поля занадто різні для порівняння (див. Відповідь Джаррода Крапиви, щоб дізнатися, чому ви не можете порівняти інженерію програмного забезпечення з лікарями / юристами).
Тревор Бойд Сміт

1
@maple_shaft - Ви маєте на увазі, що сертифікація поліпшить якість техніки. Я досить скептично став би результатом. Я думаю, що час, витрачений на вивчення більшості тестів, - це не витрачений час на вивчення кращої техніки.
psr

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

1
@maple_shaft, що повністю залежить від характеру відмови - Facebook не реагує не є критичним (крім впливу на кишені інвесторів). Далі - додатки / ігри, які містять дані кредитної картки (наприклад, у Facebook), випадково вивівши дані кредитної картки, матимуть серйозні наслідки.
HorusKol

11

У 1999 році ОСБ видав заяву про ліцензування, коли вона значною мірою вийшла з роботи IEEE SWEBOK. Переглянувши загальнодоступні документи SWEBOK та заяву ОСБ, я підтримую думку ОСББ.

Поглянувши на статтю, хтось із 4-6-річним досвідом вимагає скласти іспит, який перевіряє базові знання. Це поза смішним, і слід сміятися з дверей.


10

Програмні компоненти пристрою - це деталь реалізації. Наприклад, в індустрії систем управління всі пристрої безпеки, які використовувались, були захищені, і люди не довіряли програмному забезпеченню. Однак зараз ми бачимо захищені на основі програмного забезпечення пристрої, такі як реле безпеки та ПЛК безпеки. Вони допустимі, оскільки вони все ще повинні відповідати галузевим нормам щодо пристроїв безпеки (залежно від категорії безпеки). Тому в деяких випадках пристрої потребують надлишкових процесорів та зайвого коду, написаних двома різними командами тощо.

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

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

Це дійсно не має нічого спільного з "програмуванням" і все, що стосується "інженерії".

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


5
+1 ІМХО, на що ви насправді натякаєте, це те, що регулятор повинен відповідати продукту, а не інженерам. Наприклад, положення (затвердження), необхідні для систем пожежної та вторгнення сигналізації, забезпечують роботу програмного забезпечення, а не можливості інженерів, які його написали. (Багато регламентів виглядають приблизно так само, як коли системи були повністю виготовлені з електронних схем.)
jwernerny

8

Програмне забезпечення вже жорстко регулюється в авіабудуванні. Див. DO-178B .

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

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


4

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

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

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


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

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

3

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

І FDA, і FTA вимагають аналізу ризиків та на основі цієї стратегії пом'якшення наслідків. Пізніше це звичайно стратегія швейцарського сиру, коли можна визнати, що будь-яке пом'якшення є помилковим, тому застосовується багаторазове пом'якшення за один і той же ризик (одне пом'якшення також може бути застосоване до кількох ризиків), кожне пом'якшення - це шматочок швейцарського сиру, який ви можете переглянути одну, можливо, дві скибочки, зібрані разом, але складіть достатньо скибочок разом, і це вже неможливо. Навіть коли пом'якшення виконуються ідеально, це не призводить до 100% безпечного обладнання. Якщо аналіз ризику невірний, існують ризики, про які ніхто не думав (Y2K).

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

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


1
+1 - Для: "Найбільш важливими помилками безпеки є помилки інтеграції." Насправді, при всьому процесі, який ми проходимо, майже ніколи не виникає помилка кодування. 99,98% часу це проблема розуміння між різними модулями та пристроями щодо того, як вони повинні працювати.
Данк

@Dunk дякую, що це насправді цитата з Левісона. Факт, який я мав намір включити до тексту, але, здавалося б, забув :)
Rune FS

2

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

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

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

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


4
Зазвичай такі нормативні акти також закінчуються юридичними вимогами. Напр., Цивільне будівництво, яке потребує ПП
Пол Натан

@PaulNathan Добре, тому природний прогрес до загальновизнаної дисципліни починається з саморегуляції (наприклад, MPAA) і врешті-решт призводить до регулювання законом (Державні комітети, FCC тощо)
maple_shaft

7
Я не вірю, що розробка програмного забезпечення готова до саморегуляції чи навіть близької до неї. Відверто кажучи, думка про те, що "справжні інженери" мають "справжню якість", для мене - це жарт. Космічні човники вибухнули, ракети загорілися, мости впали, будівлі обвалилися і т. Д. Було б непогано спробувати нав’язати якість зверху, але, ха-ха.
Пол Натан

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

1
@maple_shaft - основна проблема полягає в тому, що ви не можете використовувати Linux / BSD / grep / vi / Firefox тощо, оскільки вони не написані офіційною SE. У той час як хтось із MSCE cert у VB буде добре.
Мартін Бекетт

1

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

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

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

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

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

Демонстрація навичок - це більше, ніж просто тестування або отримання «почесного значка». Тест - це лише перевірка. Реальне підтвердження - це школа, стажування, учень, наставництво під старшими, практикуючи, все це є частиною цього.

Я бачу, чого намагається досягти IEEE, але на даний момент це безрезультатна вправа. Індустрія швидко змінюється, занадто великий попит на виштовхування продукту за двері, "хакерський" спосіб мислення та ін. Регулювання повинно виходити зсередини, якщо взагалі.


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

Чи не слід оцінювати навички в процесі найму. О, зачекайте, HR наймає людей на основі паперових даних (які не демонструють застосовних знань у розробці програмного забезпечення), а люди з персоналу абсолютно нічого не знають про потреби / вимоги до розробки програмного забезпечення. Подвійний провал ...
Еван Плейс

0

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

  1. Галузь в цілому охоплює широкий спектр областей, деякі з яких є життєво важливими (наприклад, контролюючи дозування випромінювання в медичному пристрої), а деякі - ні (додаток у Facebook "Який маточок ви?" Я не бачу жодного аргументу регулювання для додатків, де кількість низьких.

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

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

  4. Все, що сказано, все ще залишаються сфери, в яких бізнес має сенс завдати шкоди (часто це негативні зовнішні явища , іноді вони є результатом ринкової сили для деяких установ). Наприклад, в районі може бути одна місцева лікарня; у цьому випадку якість програмного забезпечення може мати величезну зміну щодо рівня догляду, який отримує пацієнт, але не має великої різниці в тому, яку лікарню вибере пацієнт. Тоді у лікарні не обов’язково мати багато ділових справ для інвестування у розробників вищої якості. У цьому випадку може бути випадок охорони здоров’я для регулювання забудовників, яким лікарню дозволяють приймати на роботу.

ІМХО.


0

Я повинен відповісти на це ...

Починаючи з того, що сказав @JonathanHenson, і вступу @gnat, те, що я кажу, нормально, люди, які мають гроші, можуть платити за сертифіковані речі, люди або країни, у яких немає грошей, не можуть платити за ліцензії (стільки за сертифіковані речі ), тож все ще будуть ренегати, якщо це втілиться в життя. Навіть якщо традиційні (і не настільки традиційні) способи доставки закриті, люди все одно знайдуть способи доставки програмного забезпечення зацікавленим користувачам. Навіть якщо це означає розробити інший протокол HTTP або навіть альтернативний цілий стек мережі, орієнтований лише на те, щоб зробити з'єднання невизначимими (див. Останній абзац, для того, хто може це зробити).

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.