Archivi categoria: software engineering

System e Software Engineering – rivedere il rapporto

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. E il presente.

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

Quale metodo per l’Internet of Things?

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.

Non aspettiamoci grandi cambiamenti

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.