Archivi categoria: software engineering

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.

Agile, con disciplina

Processi agili e CMMI possono integrarsi? Quando è opportuno farlo? Un numero monografico della rivista sul software dei militari USA discute quando, come e perché: http://www.crosstalkonline.org/storage/flipbooks/2016/201607/index.html (Crosstalk, Jul/Aug 2016).

Dall’articolo introduttivo:

“CMMI and Agile can be used together successfully. CMMI provides the ideal framework for managing and continuously improving our organization’s processes.

Agile Scrum provides a new lifecycle development model that yields a better fit for many of our projects over the traditional waterfall model, driving greater customer interaction and employee investment.

Both frameworks have provided value to the organization when we embraced them intelligently. When the best practices from both models are thought- fully applied to the right project, it is possible to do CMMI the Agile Way.”

Microservices

Introduzione ai Microservices di Martin Fowler. Questi gli spunti più interessanti:

  1. Rapporto tra microservices e SOA (Service Oriented Architecture). I microservices sono solo uno dei modi in cui la SOA può essere organizzata: senza bus centrale (Enterprise Service Bus), autonomi ed indipendenti.
  2. Organizzare lo sviluppo per microservices significa, prima di tutto, definire e attuale un modello organizzativo in cui ogni team lavora in modo indipendente. A occhio, maggiori sono le dimensioni del team di sviluppo, più questo modello organizzativo è sensato.
  3. I microservices hanno senso per fornire servizi di business completi. Avrebbe meno senso definire microservices puramente infrastrutturali.
  4. Per lavorare a microservices bisogna avere già una forte competenza sulla materia, sul dominio applicativo. Se questa manca, meglio sviluppare prima un monolite e poi, se opportuno, ristrutturarlo estrapolandone i microservizi.