Quanto è lontano il processo di i-fi cazione dell'ingegneria del SW negli ultimi 10 anni?

"l'ingegneria del software dovrebbe essere come costruire una casa"

Solo quando l'intera casa è già stata costruita in precedenza. Abili falegnami e artigiani eseguono le stesse abilità in diversi luoghi fisici quando costruiscono case. Non costruiscono nuovi tipi di edifici. Non inventano nuove tecniche o materiali di costruzione.

Perché costruire lo stesso software due volte? Perché ricostruire di nuovo la stessa casa? Perché non clonare semplicemente il software e riutilizzarlo?

La metafora è totalmente infranta.

Il software di costruzione deve coinvolgere qualcosa di nuovo o unico. Se non coinvolge qualcosa di nuovo o unico, allora è già stato fatto e può essere copiato. Problema risolto.

Le nuove e uniche funzionalità del software sono nuove tecnologie o nuovi casi d'uso (o entrambi).

Se è una nuova tecnologia, l'architetto non crea solo progetti. È nuova tecnologia. In primo luogo, deve essere inventato. Quindi applicato al dominio del problema. Ciò richiede esperienza, esperimenti falliti e lezioni apprese.

Se si tratta di un nuovo caso d'uso, l'architetto non crea solo progetti. È nuovo uso. Gli utenti devono essere intervistati. I potenziali casi d'uso hanno provato a vedere se funzionano o non funzionano. Correzioni e adeguamenti devono essere fatti.

Anche. Il software è interamente progettato. Anche ciò che chiamavamo "costruzione" era una progettazione molto dettagliata e una serie dettagliata di esperimenti in un'area strettamente focalizzata. Un linguaggio di programmazione è davvero uno strumento di progettazione - fornisce una pratica astrazione in modo che possiamo separare il nostro design dal circuito del chip su cui verrà infine eseguito.

La metafora era completamente infranta. È sempre stato totalmente rotto. Il software non è come costruire una casa.

I read a UML book a long time ago (15 or so years ago) by the inventors which said something like "software engineering should be like building a house". Meaning architects produce blue prints, and specialized workers utilize various views of them to produce their part of the end result.

Questa è una visione idealizzata dei lavori di costruzione reali. Gli architetti producono progetti, che sono in errore e mancano aspetti. L'ingegnere civile lo timbra dopo averlo controllato per l'integrità architettonica, e di tanto in tanto sbaglia. Falegnami, idraulici, et al , correggono i vari errori dell'architetto e degli ingegneri e collaborano con il cliente per creare un edificio piacevole.

Hai mai sentito di una casa i cui progetti hanno specificato un muro in cui non potrebbe adattarsi? Io ho. Sembra molto simile al software, no?

Le persone tirano fuori "reali" campi ingegneristici ma mancano ciò che accade lì quando vengono progettate nuove cose. I razzi avevano un gran numero di progetti negli anni '50 e '60. Tonnellate di razzi esplosero e compirono altri malfunzionamenti. Alcuni ancora fai . Negli anni '50 negli Stati Uniti i piloti dei jet test stavano morendo al ritmo di uno alla settimana. Il design Tacoma Narrows Bridge ha avuto un insetto critico. Il MIT aveva un'architettura unica in uno dei suoi edifici e dopo alcuni anni, era che perdeva e non funzionava bene ... probabilmente letteralmente bacato. =) Continua a stimolare la creatività e troverai difetti.

Ogni programma che hai intenzione di scrivere sta risolvendo un problema unico per il tuo spazio, tempo e enigma. La ricerca è ciò che stai facendo quando non sai cosa stai facendo.

La creazione di software come i guru di processo desiderano che sia impossibile dalla natura dell'attività. La creazione del software è stata automatizzata, in realtà. Chiamiamo quegli strumenti compilatori .

Questo punto di vista è caduto in disgrazia per la maggior parte. Il breve motivo per cui è che quando hai un progetto software hai finito. I "lavoratori specializzati" che mappano all'edificio una metafora della casa sarebbero la sceneggiatura. Lo sviluppo del software è più simile a un gigantesco progetto, ma anche quella metafora non è eccezionale.

Martin Fowler (vedere la sezione Separazione di progettazione e costruzione ) ha scritto a riguardo per un po 'ora, per esempio.

Meaning architects produce blue prints, and specialized workers utilize various views of them to produce their part of the end result.

Direi che siamo giunti a quel punto decenni fa: produciamo progetti (il codice sorgente) e "lavoratori" specializzati (generatori di codice, compilatori, software di installazione, ma anche persone come traduttori, progettisti, scrittori di documentazione) producono la loro parte del risultato finale (il software finale, in esecuzione sul computer degli utenti).

Penso che come concetto "l'ingegneria del software dovrebbe essere come costruire una casa" è in gran parte frainteso. Come metafora letterale, accetto un po 'la risposta di S. Lott che la metafora sembra essere infranta. Come concetto, comunque, penso che l'idea che il software debba essere "ingegnerizzato" proprio come i costrutti fisici sono "ingegnerizzati" è solido, ma richiede una piccola prospettiva. La creazione di software è come costruire una casa? No, e non lo sarà mai, ma dal momento che i processi creativi sono migliorati e sviluppati nel tempo, penso che l'ingegneria del suono sia cresciuta per essere così integrata con ciò che facciamo, che a malapena lo riconosciamo per quello che è veramente.

Dimenticatevi di come i 3 Amigos hanno promosso UML e di come costruire case basandosi su una metodologia cascata e su tutto quel materiale. Invece di guardare le differenze, guarda le somiglianze concettuali. Un architetto specifica un'approssimazione di cosa sarà una casa. Egli specifica un framework, ma afferma solo quanto basta per garantire che, indipendentemente da come vengono implementati i progetti, che il progetto sarà strutturalmente valido. Questo vale anche per un buon architetto di software.

Anche se sono d'accordo sul fatto che i processi di sviluppo del software debbano essere altamente iterativi, sono in disaccordo con le persone che credono di poter creare un progetto software sonoro semplicemente desiderandolo nell'esistenza dopo aver iniziato la codifica. Anche gli Agile Warriors più abili là fuori avranno almeno l'esperienza di avere in mente un progetto generale approssimativo prima di mettere qualcosa in prova o in codice. Il vantaggio per l'ingegnere del software, tuttavia, è che i difetti di progettazione possono diventare rapidamente evidenti e che con i test in corso, il refactoring è più semplice e un'architettura scarsamente fattorizzata può diventare "migliore" organicamente, con il passare del tempo.

Quindi, nel cuore della domanda dell'OP, sono stati compiuti progressi nello sviluppo di software utilizzando le pratiche di ingegneria del suono? La mia risposta è un sonoro sì, ma dipende in gran parte dal tuo punto di vista. Dalle mie esperienze / prospettive, ho visto l'ascesa e la "caduta" di UML come un'indicazione che il concetto di ingegneria del software ha superato la necessità di processi di progettazione pesantemente irreggimentati in termini di documentazione, ma che UML mantiene un posto nel processo come mezzo per aiutare gli sviluppatori a elaborare diagrammi concettuali in modo schematico. Ciò aiuta gli sviluppatori a spiegare cosa stanno facendo agli altri, in particolare ai laici. Le linee guida e le metodologie procedurali sono nate in molte forme diverse, ed è proprio queste le vere indicazioni su come il software è progettato oggi. Prendi qualsiasi processo agile, e ci si concentra sul testing, e nella maggior parte dei casi un approccio test-first. Dal punto di vista del design, i test sono parte integrante del processo di progettazione, poiché i test convalidano il design. Le specifiche sotto forma di brevi dichiarazioni "story" / "feature" fanno anche parte dei processi di ingegneria e, con l'avvento dell'integrazione continua e dei processi di compilazione automatizzati che sono così comuni oggi, il ruolo dello sviluppatore di software medio si è appoggiato più verso la fine della progettazione dello spettro, e ha lasciato i compiti più banali e spesso ripetitivi da affrontare con un sistema dedicato "robot".

Per quanto riguarda gli architetti del software in circolazione? Che cosa fanno veramente? Ancora una volta ritengo che questo sia un ruolo poco compreso perché la gente pensa che gli architetti debbano progettare tutto in anticipo. Questo può essere vero per la progettazione hardware, ma per quanto riguarda il software, gli architetti dovrebbero essere comunicatori e facilitatori e dovrebbero essere le persone che determinano in che modo i vincoli aziendali influenzeranno la progettazione generale di un prodotto. Se questo significa specificare un progetto scheletrico in anticipo, allora questo è un aspetto positivo, ma l'architetto deve quindi garantire che il resto del prodotto possa crescere e crescere all'interno di tale framework e che vengano utilizzati processi di ingegneria del software appropriati per implementare effettivamente il prodotto all'interno delle linee guida specificate.

Lo sviluppo del software è come costruire una casa in cui i nuovi proprietari di case arrivano all'ispezione finale e chiedere che l'impianto idraulico venga spostato dall'altra parte della struttura e che l'ordine dei piani venga mischiato.

Per essere chiari: la giusta metodologia dipende dal dominio del problema (non si utilizza lo stesso processo per i siti web avionici e art gallery). Detto questo, la stragrande maggioranza dei progetti software là fuori ha davvero beneficiato della crescente adozione di metodologie agili. C'è qualcosa nella natura del software che rende impossibile per le persone capire quello che vogliono o ciò che è meglio fino a quando vedono il sistema funzionare. Sì, la visione architettonica è essenziale, ma le moderne architetture software sono molto più aperte e flessibili di quanto non fosse nei giorni in cui UML è stato concepito.

Una cosa che non dovrebbe essere trascurata è che la tecnologia di base con cui lavoriamo si è evoluta enormemente e in modo eccellente negli ultimi 15 anni. I progetti della prima metà degli anni '90 non avevano per lo più il vantaggio della memoria raccolta rifiuti, del controllo automatico dei limiti di array e di altre sottigliezze che diamo per scontate. C, C ++ o persino l'assemblatore erano spesso necessari nelle applicazioni mainstream per ottenere prestazioni da hardware che considereremmo primitive ed estremamente limitate. Quindi la tendenza a perseguire una strategia di project management a cascata o "costruire una casa" è stata una risposta naturale agli strumenti e agli ambienti di sviluppo che erano molto meno flessibili di cui oggi godiamo.

Grazie a Dio si sbagliavano o oggi il nostro lavoro sarebbe etichettato come un semplice operaio.

Ho assistito a così tante società di servizi IT che tentano di industrializzare il processo di sviluppo del software, ridurre le dimensioni e ridurre i costi, e alla fine essere in grado di trasferire in mare aperto tutti gli sviluppi. La maggior parte di loro ha fallito di fronte a tale approccio.

Siamo più simili agli artigiani. E quindi può essere molto orgoglioso delle nostre realizzazioni.

Penso che i fondatori di UML fossero visionari ma 15 anni fa la tecnologia e l'hardware non erano pronti. La tecnologia di modellazione software è cambiata. Eclipse e dotnet stanno migliorando. Esistono oggi due diverse visioni su UML. Per IBM UML è una visione astratta del sistema che utilizza un approccio MDA / MDD mentre per Omondo dovrebbe essere il mondo reale basato su un singolo modello live mappato a MOF e il codice utilizzato come componente di una fabbrica di software. Entrambi gli approcci stanno fornendo un grande valore per proiettare se usati come dovrebbero.

L'hardware è ora molto potente. Per esempio i miei laptop personali possono fare più oggi di 10 mainframe 15 anni fa, quindi i livelli di modellazione grafica oggi possono essere perfetti mentre prima era impossibile.

Se sei stato deluso da UML direi proviamo ancora oggi usando gli strumenti e le tecnologie più recenti.