Чи розробка програмного забезпечення - інженерна дисципліна?

Чи можна вважати розробку програмного забезпечення інженерною? Якщо ні, то які речі йому не вистачають, щоб бути кваліфікованими як інженерна дисципліна? З цим пов'язано це питання на Stack Overflow про різницю між програмістом та програмним інженером .

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

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

Так, інженерія програмного забезпечення - це інженерна дисципліна.

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

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

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

Гленн Вандербург провів серію переговорів під назвою "Реальна програмна інженерія", яка проводила між 2010 і 2015 роками на ряді конференцій, а також дві пов'язані з цим переговори "Ремесло, інженерія та сутність програмування" (дана в 2011 році як основна інформація на RailsConf) та "Ремесло та інженерія програмного забезпечення" (дано в 2011 році в Лондоні QCon) Я думаю, що ці переговори є досить вичерпним аргументом, чому інженерія програмного забезпечення - це інженерна дисципліна.

Одним із аргументів, який Вандербург коротко викладає у своїх переговорах, є той, який висловив Джек У. Рівз у 1992 р. (І знову переглянувся у 2005 р.) Про те, що таке розробка програмного забезпечення та як код є результатом проектування програмного забезпечення ( це також обговорювались на вікі С2 ). Як тільки ви відходите від старих шкіл думки, де специфікація та моделювання - це розробка програмного забезпечення та перетворення коду на розробку програмного забезпечення, деякі взаємозв'язки між інженерією програмного забезпечення та іншими інженерними дисциплінами стають більш очевидними. Деякі відмінності та причини цих відмінностей стають ще більш очевидними після того, як ви побачите, що економіка розробки програмного забезпечення сильно відрізняється, ніж у багатьох інших дисциплінах - будівництво коштує дешево (майже безкоштовно, у багатьох випадках), а дизайн - дорога частина.

Це [CMMI] щось, що перетворить розвиток в інжиніринг?

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

Також, яка ваша думка щодо курсів / сертифікатів з програмної інженерії?

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

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

Незалежно від того, чи розробляєте ви літак або програмне забезпечення, для обох потрібно:

• робити конструкції
• визначити підсистеми та компоненти
• складають прототипи
• уточнюйте та виконуйте тести
• тощо.

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

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

Тому я вважаю розробку програмного забезпечення інженерною.

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

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

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

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

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

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

Ні, це не інженерія. Ми не такі наукові, і нам не потрібно проходити жодних державних інженерних випробувань. Насправді називати себе інженером програмного забезпечення в деяких місцях незаконно через відсутність тестування.

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

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

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

З Вікі:

Техніка:

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

Розробка програмного забезпечення

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

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

Тож вони досить схожі і можуть означати те саме.

Від Dictionary.com: en · gi · neer · ing / ˌɛndʒəˈnɪərɪŋ /

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

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

[EDIT] FWIW, я не називаю себе інженером програмного забезпечення, а розробником програмного забезпечення, тому я не маю особистої участі в цьому.

На мій погляд, інженер програмного забезпечення та розробник програмного забезпечення - це дві різні речі.

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

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

Одна цікава річ - це архітектура . Хтось, хто також бере участь у з'ясуванні того, яке апаратне / програмне забезпечення буде потрібно для життєвого циклу проекту.

Я збираюся йти з "Ні" тут. Мій брат інженер-механік, і він описує інженерію як "Мистецтво бути дешевим":

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

Як реакція, я прийшов описати розробку програмного забезпечення (а не інженерія програмного забезпечення - вони є принципово двома різними сферами) як "Мистецтво бути ефективним":

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

Різниця полягає в останній частині цих речень.

Інженерія розробки програмного забезпечення?

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

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

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

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

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

Для уточнення, у мене є лише диплом коледжу, тому не можу називати себе інженером.

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

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

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

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

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

Це також повторюваність. Візьміть набір вимог і подайте його двом командам. Коли ви зможете вивести те ж саме (без команд, що розмовляють між собою), ви досить близькі до техніки.

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

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

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

З цього я можу зробити висновок:

1. кількість потрібних мені доріг доріг (використовуючи стандартний розрахунок, визначений урядом);
2. вантажі, які мені потрібно буде підтримувати (використовуючи розрахунки, визначені урядом)
3. матеріали, які мені потрібно використовувати для підтримки цих навантажень (використовуючи або стандартні матеріали, які я можу отримати від багатьох різних постачальників, або нестандартні матеріали, які мені потім доведеться довести, матимуть правильні властивості).

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

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

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

Так, я б здогадався, що розробка - це підмножина інженерії:

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

Code Complete визначає "конструкцію" як синонім кодування та налагодження (та коментування), а також детальний дизайн заздалегідь та з тестуванням модулів та інтеграції після цього. Розділ 1, Ласкаво просимо до створення програмного забезпечення (PDF) починається з перерахування багатьох тем у загальному життєвому циклі розробки програмного забезпечення (включаючи визначення проблеми, архітектуру програмного забезпечення, корекційне обслуговування тощо), а потім каже:

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

Розробка програмного забезпечення - це інженерія.

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

Деякі кажуть, що інженери займаються розробкою "речей" для суспільного блага - чи МБР, цистерни тощо - це суспільне благо? Одні скажуть «так» (добрий проступ - хороший захист), інші - «ні». Однак я не думаю, що хтось не погодиться би з тим, що хлопець, який розробляє систему націлювання на танки нового покоління, є інженером. Громадське благо може бути суб'єктивним. У будь-якому випадку багато програмного забезпечення є загальнолюдським благам, тому справа в будь-якому випадку суперечка.

Інші кажуть, що інженери проектують, що не будують. Я бачив кілька коментарів типу "інженери-механики". Я заперечую, що інженери-механіки виробляють креслення - детальні конструкції, які реалізує щось інше. Якщо інженер-механік виробляє креслення і подає його на машину з ЧПУ, це робить їх більше не інженером-механіком - адже машина зробила реалізацію замість людини? Я можу стверджувати, що вихідний код - це детальний план, який подається на машину, яка виконує реалізацію, і я не бачу, як це відрізняється від MechE-коду подачі до машини з ЧПУ. І тепер у нас є 3D-принтери, чи це означає кінець машинобудівників? Зараз вони механічні розробники?

Ліцензування - це інша тема, яку я бачу. В даний час лише кілька юрисдикцій ліцензують інженерів програмного забезпечення. Поки що в США немає ліцензування інженерів програмного забезпечення (я думаю, що це робить тільки Техас). Деякі використали це як привід заявити, що інженерія програмного забезпечення не повинна називатися інженерією. ПЕ для інженерів програмного забезпечення. Але на більш філософському рівні лише тому, що деякі законодавці штатів обирають (чи ні) називати розробку програмного забезпечення, не впливає на реальність.