Що потрібно змінити, щоб програмне забезпечення стало офіційною професією?

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

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

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

Що потрібно змінити, щоб це сталося, і чи це навіть було б добре?

(Якщо хтось знає про формальне дослідження цієї теми, я дуже вдячний посиланням)

Оновлення

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

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

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

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

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

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

З статті Вікіпедії про професію :

Існує значна згода щодо визначення характерних рис професії. Вони мають "професійну асоціацію, когнітивну базу, інституціоналізовану підготовку, ліцензування, автономію роботи, контроль колег ... (і) етичний кодекс" [18], до якого потім додає і Ларсон, "високі стандарти професійної та інтелектуальної майстерності", "(Ларсон, с. 221), що" професії - це професії, що мають особливу владу і престиж "(Ларсон, пх), і що вони складають" ексклюзивну елітну групу "(Ларсон, стор. 20) у всіх суспільствах.

Це цитує Магалі Сарфатті Ларсона «Повстання професіоналізму: Соціологічний аналіз» . Пошук "характеристик професії", як правило, призводить до подібних результатів.

Як інженерія програмного забезпечення співпадає з цими характеристиками?

• Професійна асоціація Існує чимало професійних асоціацій для інженерів програмного забезпечення. IEEE і більш конкретно Computer Society IEEE служать фахівців , що працюють в області машинобудування по всьому світу, з IEEE Computer Society з особливим акцентом на комп'ютерних і програмних інженерів. ACM є інший професійною організацією , для фахівців , що працюють в обчислювальної, як правило , в Північній і Південній Америці. Є також Британське комп'ютерне товариство , яке займається різними аспектами професій інформаційно-комунікаційних технологій, як правило, у Великобританії.

• Когнітивна база Проект програмного забезпечення знань спонсорується IEEE, Boeing, Національною науковою радою Канади, Raytheon, Construx Software, Канадською радою професійних інженерів, корпорацією MITER, NIST, Rational, SAP (для версії 2004 року). Це було розпочато спеціально як крок до "зробити інженерію програмного забезпечення законною інженерною дисципліною та визнаною професією" .

• Інституціоналізоване навчання У США програми ABB можуть бути акредитовані з інформаційних технологій, інформатики та програмної інженерії . У Канаді програми інформатики та інженерії програмного забезпечення акредитовані CIPS . Ці організації визначають мінімальні стандарти та очікувані результати для студентів, які закінчують акредитовану програму, щоб вони могли функціонувати у професійному середовищі. IEEE пропонує також два іспити на базі знань із програмного забезпечення інженерії програмного забезпечення - іспит сертифікованого спеціаліста з розробки програмного забезпечення для студентів (або нещодавно закінчених магістрантів) та сертифікований іспит з розробки програмного забезпечення для професіоналів середньої кар'єри.

• Ліцензування Станом на квітень 2013 року, NCEES пропонує екзамен з професійної інженерії з програмної інженерії . Він пропонується на державній основі в США. Однак іспит на ПЗ з програмного забезпечення на даний момент не пропонується кожним штатом, і ще менше вимагає ліцензії. Ця стаття, опублікована у випуску програмного забезпечення IEEE за листопад / грудень 1999 року, обговорює ліцензійні вимоги в штаті Техас та коротке обговорення ліцензування в Онтаріо та Британській Колумбії, Канаді та Великобританії. У Техасі ліцензія потрібна лише для роботи над проектуванням, випробуванням або впровадженням вбудованих систем або в режимі реального часу, які "вимагають детального розуміння інженерних електричних або механічних компонентів", а також для програмних систем для "механічних пристроїв, електричних пристроїв" , та енергосистеми »- відносно невеликий обсяг роботи з розробки програмного забезпечення. У державах, які пропонують ліцензування, найгірший сценарій - це дисциплінарне стягнення, санкції або втрата вашої ліцензії, якщо клієнт або роботодавець подає скаргу. Однак єдиний реальний шкоду приносить державам, які вимагають ліцензії - якщо ліцензія не потрібна для виконання роботи, втрата її не означає нічого.

• Етичний кодекс ACM та IEEE Computer Society створили Кодекс етики та професійної практики інженерного програмного забезпечення . У Сполучених Штатах випускники акредитованих інженерних програм ABET, включаючи програми програмної інженерії, також можуть приєднатися до Ордена інженера , який дотримується етичного кодексу, який, як правило, застосовується до професійних інженерів.

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

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

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

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

Нічого не потрібно міняти.

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

Я думаю, що ваше питання стосується ліцензування.

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

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

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

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

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

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

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

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

Я розробляю програмне забезпечення більше 20 років. Я не стверджую, що це робить мене чудовим розробником, але я думаю, що я досить хороший розробник. Проблема в тому, що мені доводиться постійно демонструвати, чому я кращий розробник, ніж кожен хлопець, який навчився програмуванню у вільний час і хоче таку ж роботу, як і я. Не кажучи вже про легіони "офшорних" розробників, які обіцяють виконати ту саму роботу за частину грошей. Зараз для цього потрібно багато зусиль. Я маю надати зразки роботи, довідки, здавати тести, робити інтерв'ю. Я міг легко провести поганий день, помилитися на тесті та отримати дискваліфікацію. Я вважаю за краще сказати: "так, я сертифікований розробник, і ось мій сертифікат". Мені все-таки доведеться робити інтерв'ю, але принаймні я змагаюся лише з іншими сертифікованими розробниками.

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

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

Програмне забезпечення - це не професія, і ніколи не буде такою.

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

Цей опис зовсім не відповідає програмному забезпеченню.

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

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

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

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

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

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

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