Lo sviluppo del software è una disciplina di ingegneria?

Lo sviluppo del software può essere considerato ingegneria? Se no, quali sono le cose che gli mancano per essere qualificato come disciplina ingegneristica? A questo proposito è correlata questa domanda su StackTranslate.it relativa alla differenza tra un programmatore e un ingegnere del software .

C'è il Software Engineering Institute presso la Carnigie Mellon University che prescrive e mantiene gli standard CMMI. È qualcosa che trasformerà lo sviluppo in ingegneria?

L'ingegneria dello sviluppo software è? Se no, quali sono le cose che gli mancano per essere qualificati così?

Sì, l'ingegneria del software è una disciplina ingegneristica.

Wikipedia definisce l'ingegneria come "l'applicazione della matematica, nonché delle conoscenze scientifiche, economiche, sociali e pratiche al fine di inventare, innovare, progettare, costruire, mantenere, ricercare e migliorare strutture, macchine, strumenti, sistemi, componenti, materiali , processi, soluzioni e organizzazioni ". Il risultato dell'ingegneria del software è un sistema software che può migliorare la vita delle persone e può comportare una combinazione di conoscenze scientifiche, matematiche, economiche, sociali o pratiche.

In termini di visualizzazione, accademica e professionale, varia. I programmi di ingegneria del software possono essere accreditati da ABET come programmi di ingegneria. Gli ingegneri del software possono essere membri dell'IEEE. Alcune aziende considerano l'ingegneria del software come una disciplina ingegneristica, mentre altri no - è davvero un gioco da ragazzi.

Il miglior libro su questo argomento è lo sviluppo software professionale di Steve McConnell: programmi più brevi, prodotti di qualità superiore, progetti di maggior successo, carriera migliorata . Si guarda l'ingegneria del software come professione, evoluzione da un mestiere ad una professione, la scienza dello sviluppo del software, la differenza tra software di ingegneria e software di ingegneria (l'applicazione di pratiche di ingegneria del software rispetto a ingegneri che capita di software di compilazione, con un caso di studio che include my alma mater ), certificazione e licenze ed etica.

Glenn Vanderburg ha una serie di discorsi chiamati "Real Software Engineering" che ha tenuto tra il 2010 e il 2015 in una serie di conferenze, insieme a due discorsi correlati, "Craft, Engineering, and the Essence of Programming" (tenuto nel 2011 come keynote di RailsConf) e "Craft and Software Engineering" (dato nel 2011 a QCon London). Penso che questi colloqui siano un argomento piuttosto completo sul perché l'ingegneria del software sia una disciplina ingegneristica.

Un argomento, che Vanderburg solleva brevemente nei suoi discorsi, è quello sollevato da Jack W. Reeves nel 1992 (e rivisitato di nuovo nel 2005) su cosa sia la progettazione del software e su come il codice sia l'output delle attività di progettazione dell'ingegneria del software ( questo è anche discusso sul wiki C2). Una volta che ti allontani dalle vecchie scuole di pensiero in cui le specifiche e la modellizzazione sono la progettazione del software e il codice è la progettazione del software, alcune delle relazioni tra ingegneria del software e altre discipline ingegneristiche diventano più facilmente evidenti. Alcune differenze e le ragioni di tali differenze diventano ancora più evidenti dopo aver visto che l'economia dello sviluppo del software è molto diversa rispetto a molte altre discipline: la costruzione è economica (quasi gratuita, in molti casi), mentre il design è la parte costosa.

È [CMMI] qualcosa che trasformerà lo sviluppo in ingegneria?

No. CMMI è un framework di miglioramento dei processi che fornisce indicazioni alle organizzazioni su quali tipi di attività sono utili durante la creazione di software. Le discipline ingegneristiche in genere hanno un processo di ingegneria. Avere un tale processo è importante per il successo di progetti di alta qualità. Detto questo, il CMMI (o qualsiasi altro framework o metodologia di processo) è solo un singolo strumento: utilizzarlo non ti farà avanzare magicamente da uno sviluppatore a un ingegnere. Tuttavia, non seguire alcun tipo di processo è, a mio avviso, un segno di un progetto che non è un progetto di ingegneria.

Inoltre, qual è la tua opinione sui corsi / certificati di ingegneria del software?

Ha solo lo stesso valore di altre persone. Ci sono corsi utili e ci sono corsi inutili. Esistono certificati preziosi e certificati che non valgono la carta su cui sono stampati. Ci sono molti fattori, da chi approva o accredita il corso o da chi rilascia il certificato al proprio attuale settore di lavoro fino al proprio posto di lavoro e dove si desidera andare.

Proveniente da un tipico background ingegneristico, ma facendo carriera nello sviluppo di software, vedo grandi somiglianze tra i due mondi. A parte forse l'esatta definizione di ingegneria, vedo in pratica che lo sviluppo di software non è così diverso dallo sviluppo di un prodotto fisico. Almeno penso che non dovrebbe essere molto diverso.

Sia che si progetta un aeromobile o un'applicazione software, per entrambi è necessario:

• fare disegni
• definire sottosistemi e componenti
• realizzare prototipi
• specificare ed eseguire i test
• eccetera.

Ho letto da qualche parte in un'altra risposta che la progettazione di software è diversa perché non si progetta tutto prima di iniziare a programmare. Bene, in realtà in misura minore, ciò vale anche quando si progetta un prodotto fisico. La progettazione, la prototipazione e il collaudo sono un processo iterativo.

Inoltre, quando i progetti software aumentano di dimensioni, diventa più importante definire sottosistemi, componenti e interfacce chiari, che è anche simile alla progettazione di prodotti complessi come un aereo.

Ecco perché considero lo sviluppo di software come ingegneria.

Direi che esiste davvero qualcosa come l'ingegneria del software.

L'ingegneria comporta l'applicazione sistematica delle conoscenze scientifiche alla soluzione dei problemi. La complessità dei problemi che vengono affrontati oggi non è così diversa da quelli affrontati da un ingegnere elettrico nella creazione di un circuito o un ingegnere chimico nella progettazione di un processo di produzione o un ingegnere meccanico nella creazione di un dispositivo.

Il fatto che esista anche un approccio pratico per l'applicazione di piani esistenti (sviluppo in questo caso) è semplicemente simile al fatto che in altri campi qualcun altro esegue tali piani (ad esempio, il muratore).

È vero che la maggior parte degli sviluppatori svolge anche compiti di ingegneria del software e che la nostra formazione spesso non è nella programmazione ma piuttosto nell'ingegneria del software. Quindi ci sporchiamo le mani mentre un ingegnere civile no.

Tuttavia, la capacità di applicare un linguaggio di programmazione e un programma non ne trasforma uno in un ingegnere: ho incontrato la mia parte di sviluppatori che non hanno una vera comprensione delle complessità e dei problemi al di fuori del loro attuale codice.

Per quanto riguarda la tua domanda sulla CMU: l'applicazione di uno standard o di una pratica (ad es. CMMI) non trasforma automaticamente il lavoro di una persona in ingegneria. Tuttavia, il fatto che ci siano organizzazioni che svolgono ricerche scientifiche per fornire nuove pratiche è di nuovo un segno che esiste qualcosa come l'ingegneria.

No, non è ingegneria. Non siamo così scientifici e non dobbiamo superare nessuno di questi test di ingegneria statali. In effetti, è illegale definirsi un "ingegnere" del software in alcuni luoghi a causa della mancanza di test.

IMHO il termine "ingegneria del software" è stato coniato per cercare di descrivere meglio la gamma di cose che uno sviluppatore fa, piuttosto che essere semplicemente un "programmatore" (che ha sfumature di alcuni processi meccanicistici con poca riflessione o creatività).

Personalmente preferisco l'analogia emergente di uno sviluppatore come un "artigiano", sostenuto tra l'altro dai programmatori pragmatici.

Storicamente, le persone hanno cercato di analogizzare la creazione di software con la produzione. Penso che Jack Reeves abbia argomentato abbastanza bene per screditare questa idea nel suo articolo What Is Software Design .

Da Wiki:

Ingegneria:

L'ingegneria del software è l'applicazione di un approccio sistematico, disciplinato e quantificabile allo sviluppo, al funzionamento e alla manutenzione del software e allo studio di questi approcci; cioè, l'applicazione dell'ingegneria al software.

Sviluppo software

Lo sviluppo del software è l' insieme di attività che si traducono in prodotti software. Lo sviluppo del software può includere ricerca, nuovo sviluppo, modifica, riutilizzo, reingegnerizzazione, manutenzione o qualsiasi altra attività che porti a prodotti software. [1]

Soprattutto la prima fase del processo di sviluppo del software può coinvolgere molti dipartimenti, tra cui marketing, ingegneria, ricerca e sviluppo e gestione generale.

Quindi sono abbastanza simili e possono anche significare la stessa cosa.

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

–Noun 1. l'arte o la scienza di applicare concretamente la conoscenza delle scienze pure, come fisica o chimica, come nella costruzione di motori, ponti, edifici, miniere, navi e impianti chimici.

Direi che la creazione di software è l'applicazione pratica della matematica e dell'informatica, e potenzialmente di qualsiasi altro numero di scienze pure a seconda dell'applicazione.

[EDIT] FWIW, non mi definisco un ingegnere del software, ma uno sviluppatore di software, quindi non ho un interesse personale in questo.

A mio avviso, un ingegnere del software e uno sviluppatore del software sono due cose diverse.

Vedo un ingegnere del software come uno che pianifica, come ad esempio quale ciclo di vita prenderà lo sviluppo, facendo requisiti / specifiche, ecc ... Fondamentalmente, un ingegnere del software si occupa di molta documentazione. Ciò può essere realizzato da uno sviluppatore di software e / o da un project manager.

Uno sviluppatore di software sarebbe più strettamente correlato a un programmatore ma con maggiori competenze in altre aree come la gestione del database, ecc.

Una cosa interessante da sollevare è l' architettura . Qualcuno che è anche coinvolto nel capire quale hardware / software sarà necessario per il ciclo di vita del progetto.

Vado con "No" qui. Mio fratello è un ingegnere meccanico e descrive l'ingegneria come "The Art of Being Cheap":

"Gli ingegneri sono più preoccupati di fare le cose il più velocemente possibile, al minor costo possibile, con il minor numero di materiali possibile " .

In reazione, sono arrivato a descrivere lo sviluppo del software (non l'ingegneria del software - sono fondamentalmente due campi distinti) come "L'arte di essere efficienti":

"Gli sviluppatori sono più preoccupati di fare le cose il più velocemente possibile, al minor costo possibile, con il minor numero di ripetizioni possibili " .

La differenza è nell'ultima parte di quelle frasi.

L'ingegneria dello sviluppo software è?

No. Essere un ingegnere significa che il tuo progetto segue una linea temporale di causa ed effetto - segui i codici di costruzione, quindi il tuo edificio non cade (o almeno non puoi essere incolpato se lo fa). Scrivendo software, puoi seguire tutte le linee guida (e ce ne sono così tante tra cui scegliere!) E potrebbe ancora bloccarsi / arrestarsi / dare risposte sbagliate (a meno che tu non sia coinvolto nel campo straordinariamente piccolo di scrivere programmi dimostrabili a lato linguaggi funzionali senza effetto).

Vedo un ingegnere (meccanico, strutturale, software) come qualcuno che progetta il prodotto in anticipo sulla base delle esigenze comprese e una comprensione di cosa e come applicare i materiali per soddisfare tale esigenza.

Ad esempio, potresti spesso vedere un ingegnere strutturale che cerca diversi punti di forza dell'acciaio e applica le regole della fisica per calcolare i materiali richiesti e come dovrebbero essere implementati. L'ingegneria strutturale è un ottimo esempio perché finisci sempre con un progetto (specifica) di ciò che costruirai prima di costruire. Questo non succede sempre con il software.

Per me la differenza tra un ingegnere informatico e un programmatore è che l'ingegnere è in grado di costruire le specifiche per ciò che verrà prodotto prima di scrivere qualsiasi codice, in cui un programmatore o semplicemente scrive il codice sulla base delle specifiche di qualcun altro, o è uno di quelli programmatori del selvaggio west che scrivono codice senza specifiche. Inoltre, l'ingegnere ha la sua laurea.

Ho paragonato la differenza tra un operaio edile e un ingegnere strutturale alla differenza tra un programmatore e un ingegnere del software.

Per chiarire, ho solo un diploma universitario, quindi non posso definirmi un ingegnere.

Non considererei il termine "ingegneria" come il più appropriato per descrivere lo sviluppo del software, per 2 motivi principali:

• Trasmette molte vecchie idee, concetti e le cosiddette "regole d'oro" che hanno origine nelle discipline ingegneristiche tradizionali come l'ingegneria industriale, civile, navale o meccanica. Sto parlando di regole in materia di divisione del lavoro, processi di produzione, standard di qualità ... Questi spesso si applicano solo marginalmente al software.

• Non riesce a descrivere in modo soddisfacente ciò che la programmazione ha più di altre discipline (e credo che abbia molto di più e molto diverso) e quali nuove sfide gli sviluppatori debbano affrontare giorno per giorno rispetto alle loro controparti tradizionali domini di ingegneria. La natura virtuale e immateriale del software gioca un ruolo enorme in questo.

Lo sviluppo del software è stato a lungo visto come "solo un'altra disciplina ingegneristica". Considerando i tassi di fallimento dei progetti software che conosciamo da quando sono stati misurati, è giunto il momento di riconoscere lo sviluppo come un animale completamente nuovo, il codice come materiale davvero speciale e il ciclo di vita delle applicazioni come un tipo completamente diverso di ciclo di produzione e smettere disperatamente di provare applicare vecchie ricette a loro.

Sì, si dovrebbe essere in grado di applicare standard e principi per arrivare a un prodotto decente. Ciò che rende difficile la mentalità del cliente (è solo il codice - non dovrebbe costare molto da cambiare), l'estrema difficoltà nel codificare ciò che il prodotto dovrebbe fare nel codice della macchina (dalla lingua parlata / scritta al codice) e nel quantificare " qualità". La tua definizione di qualità non è la mia.

È anche ripetibilità. Prendi una serie di requisiti e consegnala a due squadre. Quando riesci a ottenere la stessa cosa (senza che i team parlino tra loro) sei abbastanza vicino all'ingegneria.

Altre aree dell'ingegneria hanno anche sanzioni e una rigida revisione e firma. Responsabilità.

No. L'ingegneria del software non è ingegneria. Secondo me, la differenza sta nella quantità di creatività coinvolta. Nell'ingegneria civile, ad esempio, può esserci poca o nessuna creatività. Questa è una buona cosa.

Per costruire un ponte, hai una serie di specifiche (ho bisogno di portare questo numero di macchine da questo lato del fiume all'altro lato).

Da ciò, posso dedurre:

1. il numero di corsie stradali di cui ho bisogno (utilizzando un calcolo standard definito dal governo);
2. i carichi che dovrò sostenere (usando i calcoli definiti dal governo)
3. i materiali che devo usare per supportare quei carichi (usando materiali standard, che posso ottenere da un numero di fornitori diversi, o materiali non standard, che poi devo dimostrare avranno le proprietà corrette).

Quindi, devo ottenere il progetto approvato e verificato da una terza parte (un'altra società) per assicurarmi di aver eseguito correttamente i miei calcoli.

Quindi, quando il ponte sarà effettivamente costruito, il lavoro verrà svolto da persone qualificate in modo standard. Faranno un lavoro che hanno fatto centinaia, forse migliaia di volte prima.

Non fraintendetemi, ogni progetto di ingegneria civile è diverso, ma sembra che ogni volta che sviluppo una nuova applicazione / sito Web, le cose vanno diversamente.

Sì, immagino che lo sviluppo sia un sottoinsieme dell'ingegneria:

• L'ingegneria del software include la specifica iniziale ("di che tipo di software abbiamo bisogno qui?"), Che probabilmente precede lo sviluppo
• L '"ingegneria" potrebbe anche includere, ad esempio, la definizione del processo di garanzia della qualità, che è certamente correlato allo sviluppo, ma probabilmente anche al di fuori dell'ambito della "costruzione" stessa.

Code Complete definisce "costruzione" sinonimo di codifica e debug (e commenti), anche con una progettazione dettagliata e test di unità e integrazione in seguito. Il capitolo 1, Benvenuti in Software Construction (PDF) inizia elencando molti argomenti nel ciclo di vita generale dello sviluppo del software (tra cui Definizione del problema, Architettura del software, Manutenzione correttiva, ecc.), Quindi dice:

Come indica la figura, la costruzione consiste principalmente nella codifica e nel debug, ma implica anche progettazione dettagliata, pianificazione della costruzione, unit test, integrazione, test di integrazione e altre attività. Se questo fosse un libro su tutti gli aspetti dello sviluppo del software, conterrebbe discussioni ben bilanciate di tutte le attività nel processo di sviluppo. Poiché si tratta di un manuale di tecniche di costruzione, tuttavia, pone un'enfasi sbilanciata sulla costruzione e tocca solo argomenti correlati. Se questo libro fosse un cane, si appesantirebbe fino alla costruzione, scuotendo la coda in fase di progettazione e test e abbaiando alle altre attività di sviluppo.

Lo sviluppo del software è ingegneria.

Alcuni argomenti fatti da altri sul perché l'ingegneria del software non soddisfa lo standard dell'ingegnere:

Alcuni dicono che gli ingegneri si occupano di progettare "cose" per il bene pubblico - gli ICBM, i carri armati, ecc. Sono nel bene pubblico? Alcuni direbbero di sì (una buona offesa è una buona difesa) altri direbbero di no. Tuttavia, non penso che nessuno sarebbe in disaccordo sul fatto che il ragazzo che progetta il sistema di targeting per carri armati della prossima generazione sia un ingegnere. Il bene pubblico può essere soggettivo. Ad ogni modo un sacco di software è nel bene pubblico, quindi il punto è discutibile in entrambi i casi.

Altri dicono che gli ingegneri progettano che non costruiscono. Ho visto diversi commenti di tipo "ingegneri meccanici non saldano". Direi che gli ingegneri meccanici producono progetti - disegni dettagliati che qualcosa altro implementa. Se un ingegnere meccanico produce un progetto e lo trasmette a una macchina CNC, ciò non li rende più un ingegnere meccanico, perché una macchina ha fatto l'implementazione anziché una persona? Direi che il codice sorgente è un progetto dettagliato che viene inviato a una macchina che esegue l'implementazione e non riesco a vedere come sia diverso da un codice di alimentazione MechE a una macchina CNC. E ora abbiamo stampanti 3d, questo significa la fine degli ingegneri meccanici? Ora sono sviluppatori meccanici?

La licenza è l'altro argomento che vedo emergere. Attualmente solo alcune giurisdizioni dispongono di software di licenza. Non esiste (finora) nessuna licenza statunitense per ingegneri del software (penso che solo il Texas lo faccia). Alcuni hanno usato questo come motivo per affermare che l'ingegneria del software non dovrebbe essere chiamata ingegneria. Il PE per gli ingegneri del software sta arrivando. Ma a un livello più filosofico solo perché alcuni legislatori statali scelgono (o no) di chiamare l'ingegneria dello sviluppo del software non ha alcun effetto sulla realtà.