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

Можно ли считать разработку программного обеспечения разработкой? Если нет, то чего ему не хватает для квалификации в качестве инженерной дисциплины? С этим связан вопрос переполнения стека о разнице между программистом и программистом .

В Университете Карниджи-Меллона существует Институт разработки программного обеспечения, который предписывает и поддерживает стандарты CMMI. Это то, что превратит разработку в разработку?

Это разработка программного обеспечения? Если нет, то чего ему не хватает для того, чтобы быть квалифицированным таким образом?

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

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

С точки зрения того, как это рассматривается, академически и профессионально, это варьируется. Программы разработки программного обеспечения могут быть аккредитованы ABET как инженерные программы. Инженеры-программисты могут быть членами IEEE. Некоторые компании считают разработку программного обеспечения инженерной дисциплиной, в то время как другие - нет, на самом деле это непростая задача.

Лучшая книга на эту тему - «Профессиональная разработка программного обеспечения» Стива Макконнелла: более короткие сроки, более качественные продукты, более успешные проекты, улучшенная карьера . Он смотрит на программной инженерии как профессии, эволюция от ремесла к профессии, наука о разработке программного обеспечения, разница между программной инженерией и программной инженерией (применением методов разработки программного обеспечения по сравнению с инженерами , которые происходят с программным обеспечением сборки, с тематическим исследованием этого включает мою alma mater ), сертификацию и лицензирование, и этику.

Гленн Вандербург проводит серию выступлений под названием «Реальная разработка программного обеспечения», которые проводились в период между 2010 и 2015 годами на ряде конференций, а также две связанные с ними беседы «Создание, разработка и сущность программирования» (проведенные в 2011 году как выступление на RailsConf) и "Craft and Software Engineering" (дано в 2011 году на QCon London). Я думаю, что эти разговоры являются довольно всеобъемлющим аргументом, почему разработка программного обеспечения является инженерной дисциплиной.

Один из аргументов, который Вандербург кратко приводит в своих выступлениях, - это аргумент, высказанный Джеком В. Ривзом в 1992 году (и вновь пересмотренный в 2005 году) о том, что такое дизайн программного обеспечения и как код является результатом деятельности по разработке программного обеспечения ( это также обсуждается на вики С2). Как только вы уйдете из более старых научных школ, где спецификация и моделирование являются разработкой программного обеспечения, а код - разработкой программного обеспечения, некоторые из связей между разработкой программного обеспечения и другими инженерными дисциплинами становятся более очевидными. Некоторые различия и причины этих различий становятся еще более очевидными после того, как вы видите, что экономика разработки программного обеспечения значительно отличается от многих других дисциплин - конструирование является дешевым (почти во многих случаях практически бесплатным), в то время как дизайн является дорогостоящей частью.

Это [CMMI] что-то, что превратит разработку в разработку?

Нет. CMMI - это структура для улучшения процессов, которая дает рекомендации организациям о том, какие виды деятельности полезны при создании программного обеспечения. Инженерные дисциплины обычно имеют инженерный процесс. Наличие такого процесса важно для успешного завершения проектов высокого качества. Тем не менее, CMMI (или любая другая структура процесса или методология) - это всего лишь один инструмент - использование его не сделает вас волшебным путем от разработчика до инженера. Однако не следовать какому-либо процессу - это, на мой взгляд, признак проекта, который не является инженерным проектом.

Кроме того, что вы думаете о курсах / сертификатах по разработке программного обеспечения?

Это столько же, сколько другие люди вкладывают в это. Есть полезные курсы и есть бесполезные курсы. Есть ценные сертификаты и сертификаты, которые не стоят бумаги, на которой они напечатаны. Существует множество факторов: от того, кто одобряет или аккредитует курс, или кто выдает сертификат для вашей текущей отрасли занятости, до вашей текущей работы и от того, куда вы хотите пойти.

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

Независимо от того, разрабатываете ли вы самолет или программное приложение, вам необходимо:

• сделать дизайн
• определить подсистемы и компоненты
• делать прототипы
• указать и выполнить тесты
• и т.п.

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

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

Вот почему я считаю разработку программного обеспечения инженерной.

Я бы сказал, что действительно существует такая вещь, как разработка программного обеспечения.

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

Тот факт, что существует также практический подход к применению существующих планов (в данном случае разработка), просто аналогичен тому, что в других областях эти планы выполняет кто-то другой (например, рабочий-строитель).

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

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

Что касается вашего вопроса относительно CMU: применение стандарта или практики (например, CMMI) не превращает работу человека автоматически в разработку. Тем не менее, тот факт, что есть организации, которые проводят научные исследования для обеспечения новых практик, является еще одним признаком того, что существует такая вещь, как инженерия.

Нет, это не инженерия. Мы не настолько научны, и нам не нужно проходить ни одно из этих государственных инженерных испытаний. Фактически, из-за отсутствия тестирования в некоторых местах называть себя «инженером» программного обеспечения незаконно.

ИМХО термин «разработка программного обеспечения» был придуман для того, чтобы попытаться лучше описать круг вещей, которые делает разработчик, а не просто быть «программистом» (который имеет оттенок какого-то механистического процесса, не задумываясь и не творчески).

Лично я предпочитаю появившуюся аналогию разработчика как «мастера», отстаиваемого прагматичными программистами, среди прочих.

Исторически люди пытались сопоставить создание программного обеспечения с производством. Я думаю, что Джек Ривз привел довольно хороший аргумент, чтобы дискредитировать эту идею в своей статье « Что такое дизайн программного обеспечения» .

Из вики:

Инжиниринг:

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

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

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

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

Таким образом, они очень похожи и могут означать то же самое.

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

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

Я бы сказал, что создание программного обеспечения - это практическое применение математики и компьютерных наук и, возможно, любого другого числа чистых наук в зависимости от приложения.

[РЕДАКТИРОВАТЬ] FWIW, я не называю себя инженером программного обеспечения, но разработчик программного обеспечения, поэтому у меня нет личной заинтересованности в этом.

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

Я вижу инженера-программиста как того, кто занимается планированием, например, какой жизненный цикл займет разработка, выполнение требований / спецификаций и т. Д. По сути, инженер-программист имеет дело с большим количеством документации. Это может быть достигнуто разработчиком программного обеспечения и / или менеджером проекта.

Разработчик программного обеспечения будет более тесно связан с программистом, но у него будет больше навыков в других областях, таких как управление базами данных и т. Д.

Одна интересная вещь, чтобы воспитать это Архитектура . Кто-то, кто также вовлечен в выяснение того, какое оборудование / программное обеспечение будет необходимо для жизненного цикла проекта.

Я собираюсь пойти с «Нет» здесь. Мой брат - инженер-механик, и он описывает инженерию как «Искусство быть дешевым»:

«Инженеры больше заботятся о том, чтобы сделать все как можно быстрее, с наименьшими затратами, с наименьшим количеством материалов ».

В ответ я описал разработку программного обеспечения (а не разработку программного обеспечения - это на самом деле две разные области) как «Искусство быть эффективным»:

«Разработчики больше заботятся о том, чтобы все было сделано как можно быстрее, с наименьшими затратами и минимальным количеством повторений ».

Разница в последней части этих предложений.

Это разработка программного обеспечения?

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

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

Например, вы можете часто видеть инженера-строителя, который просматривает различные прочности стали и применяет физические правила для расчета требуемых материалов и того, как они должны быть реализованы. Структурное проектирование является ярким примером, потому что у вас всегда есть план (спецификация) того, что вы собираетесь построить, прежде чем строить. Это не всегда происходит с программным обеспечением.

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

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

Чтобы уточнить, у меня есть только диплом колледжа, поэтому я не могу назвать себя инженером.

Я не считаю термин «инжиниринг» наиболее подходящим для описания разработки программного обеспечения по двум основным причинам:

• Он передает много старых идей, концепций и так называемых «золотых правил», берущих начало в традиционных инженерных дисциплинах, таких как промышленное, гражданское, морское или машиностроение. Я говорю о правилах в разделении труда, производственные процессы, стандарты качества ... Они чаще всего лишь незначительно относятся к программному обеспечению.

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

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

Да, нужно уметь применять стандарты и принципы для получения достойного продукта. Что делает это трудным, так это образ мышления клиента (это просто код - не должно стоить так много изменений), чрезвычайная трудность в кодировании того, что продукт должен делать, в машинный код (разговорный / письменный язык для кода) и количественная оценка " качество". Ваше определение качества не мое.

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

У других областей разработки также есть штрафы и жесткий пересмотр и отписывание. Ответственность.

Нет. Разработка программного обеспечения - это не разработка. На мой взгляд, разница заключается в количестве креативности. В гражданском строительстве, например, творчества может быть очень мало или вообще нет. Это хорошая вещь.

Чтобы построить мост, у вас есть набор спецификаций (мне нужно получить это количество машин с этой стороны реки на другую сторону).

Из этого я могу сделать вывод:

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

Затем я должен получить одобрение и проверку проекта третьей стороной (другой компанией), чтобы убедиться, что я правильно сделал свои расчеты.

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

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

Да, я думаю, что разработка - это подмножество инженерных разработок:

• Разработка программного обеспечения включает в себя первоначальную спецификацию («какое программное обеспечение нам здесь нужно?»), Которая, возможно, предшествует разработке
• «Инжиниринг» может также включать, например, определение процесса обеспечения качества, который, безусловно, связан с разработкой, но также, возможно, выходит за рамки самой «конструкции».

Code Complete определяет «конструкцию» как синоним кодирования и отладки (и комментирования), а также подробного предварительного проектирования и последующего модульного и интеграционного тестирования. Глава 1 «Добро пожаловать в конструирование программного обеспечения» (PDF) начинается с перечисления многих тем в общем жизненном цикле разработки программного обеспечения (включая определение проблемы, архитектуру программного обеспечения, корректирующее обслуживание и т. Д.), А затем говорится:

Как видно из рисунка, конструирование в основном состоит из кодирования и отладки, но также включает в себя детальное проектирование, планирование строительства, модульное тестирование, интеграцию, интеграционное тестирование и другие действия. Если бы это была книга обо всех аспектах разработки программного обеспечения, в ней были бы хорошо сбалансированные обсуждения всех действий в процессе разработки. Поскольку это руководство по строительным технологиям, оно, однако, уделяет особое внимание строительству и касается только смежных тем. Если бы эта книга была собакой, она бы сунула руку в конструкцию, помахала хвостом при проектировании и тестировании и лаяла на другие разработки.

Разработка программного обеспечения - это разработка.

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

Некоторые говорят, что инженеры занимаются разработкой «вещей» для общественного блага - действительно ли МБР, танки и т. Д. Полезны для общества? Некоторые скажут «да» (хорошее нарушение - хорошая защита), другие скажут «нет». Однако я не думаю, что кто-то не согласится с тем, что парень, который разрабатывает систему прицеливания танков следующего поколения, - инженер. Общественное благо может быть субъективным. Во всяком случае, большое количество программного обеспечения является общественным благом, так что суть в любом случае спорная.

Другие говорят, что инженеры проектируют, а не строят. Я видел несколько комментариев типа «инженеры-механики не сваривают». Я бы сказал, что инженеры-механики создают чертежи - детальные проекты, которые реализует что- то еще. Если инженер-механик создает проект и передает его на станок с ЧПУ, это делает его уже не инженером-механиком - потому что машина выполняла реализацию вместо человека? Я бы сказал, что исходный код является подробным планом, который подается на машину, которая выполняет реализацию, и я не вижу, чем она отличается от кода подачи MechE для станка с ЧПУ. И теперь у нас есть 3D-принтеры, означает ли это конец инженеров-механиков? Они теперь механические разработчики?

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