In Software Engineering Radio un’intervista a Karl Wiegers. Si parla di requisiti, casi d’uso, testing e project management. Diversi spunti interessanti.
Come in tutti gli episodi di Software Engineering Radio si può ascoltare, oppure sileggere la trascrizione.
https://se-radio.net/episode-518-karl-wiegers-on-software-engineering-lessons
Nei sistemi attuali l’interazione tra progettazione degli aspetti hardware e software è sempre più importante.
Il rapporto tradizionale tra le due discipline, il system engineering e il software engineering, deve essere riconsiderato alla luce del peso sempre maggiore che il software sta assumendo.
Il direttore del Software Engineering Institute, Paul Nielsen, aveva scritto un articolo sulla necessità di una maggiore integrazione qualche mese fa: “Systems Engineering and Software Engineering: Collaborating for the Smart Systems of the Future“
Ha poi ripreso e sviluppato l’idea in questo video:
Il futuro del software, ma già anche il presente, nell’interazione tra esseri umani e intelligenza artificiale.
“Humans and AI are trustworthy collaborators that rapidly evolve systems based on programmer intent”.
Una pubblicazione gratuita del Software Engineering Institute, consiglio di dare un’occhiata almeno all’executive summary:
https://sei.cmu.edu/news-events/news/article.cfm?assetId=741319
Il COBOL resiste.
Per decenni è stato il linguaggio di programmazione più usato dagli sviluppatori software. Ora non lo è più ma continua a reggere il peso di innumerevoli transazioni, in particolare nei sistemi informatici delle banche.
Una breve storia del COmmon Business-Oriented Language, in pista dal 1959, con dati sulla sua diffusione e spiegazione del perché viene ancora usato.
Quale metodo per l’Internet of Things (IoT)? Come condurre i progetti?
In un articolo in Communications of the ACM, novembre 2017,
Is There a Single Method for the Internet of Things? , Ivar Jacobson e colleghi si pongono la domanda e individuano due metodi: Ignite e IoT Methodology.
Ma servono davvero metodi nuovi? Secondo gli autori, anche i metodi per lo sviluppo di soluzioni IoT devono integrarsi nel framework Essence da loro definito (l’evoluzione di Semat, fatta propria dall’Object Management Group).
In questo modo lo sviluppo di soluzioni IoT può essere confrontato con quello di altre tipologie di sistemi e sfruttare le pratiche che si sono dimostrate utili in altri settori, evitando di ripartire da zero (e dover reinventare la ruota).
Lo scopo di Essence-Semat, come affermano gli autori, è infatti quello di definire un terreno comune con cui poter mettere a confronto metodi diversi, per enuclearne le pratiche che possono adattarsi nel modo migliore alle esigenze di ogni specifico ambito.
Numero monografico di Crosstalk dedicato all’approccio e alle pratiche agili, 15 anni dopo l’enunciazione del manifesto originario.
Interessanti l’articolo sui problemi negli Stand-Up meeting di Scrum, e un resoconto sull’adozione di pratiche agili nel contesto militare italiano.
Per l’integrazione continua non bastano gli strumenti. Ecco cosa serve: ContinuousIntegrationCertification, di Martin Fowler e Jez Humble.
Astrazioni per l’ignoto, Abstracting the Unknown, presentazione keynote di Grady Booch a SATURN 2016: su architetture software, agile, domain modeling, UML, outsourcing.
Quanto, quando, cosa e come è importante nella definizione delle architetture software.
SATURN è la conferenza annuale sulle tematiche architetturali del Software Engineering Institute.
Robert C. Martin: il futuro della programmazione.
Cos’è cambiato, dal 1945 in poi: la potenza e il costo dell’hardware, la crescita enorme del numero degli sviluppatori software.
Cosa non è cambiato: la criticità intrinseca dello sviluppo, che richiede disciplina e professionalità.
Quale sarà la prossima ricetta per migliorare lo sviluppo software? Quali nuovi approcci e tecnologie risolveranno tutti i problemi irrisolti?
Abbandonate le speranze, afferma Bob Martin, il tempo dei grandi cambiamenti è trascorso, la nostra disciplina è maturata. Possiamo aspettarci qualche ulteriore miglioramento, ma non più le rivoluzioni del passato.
Progress in software has followed a logarithmic growth curve. In the early years, progress was stark and dramatic. In later years the progress became much more incremental. Now, progress is virtually non-existent.
Look: Assembler was massively better than Binary. Fortran was much better than Assembler. C was a lot better than Fortran. C++ was probably better than C. Java was an improvement over C++. Ruby is probably a bit better than Java.
Waterfall was a whole lot better than nothing. Agile was better than waterfall. Lean was a little better than Agile. Kanban may have been something of an improvement.
Every year. though we apply massive effort, we make less progress than the year before; because every year we get closer and closer to the asymptote.
Ora, aggiunge, è semplicemente ora di mettere in pratica quello che si è imparato. E soprattutto di farlo in modo professionale.
We need to realize that we have hit the asymptote. It’s time to stop the wasteful churning over languages, and frameworks, and paradigms, and processes.
It’s time to simply get down to work.
We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam profession.
The Churn, di Robert C. Martin.