Herbert D. Benington pubblica Production of Large Computer Programs dove vengono descritte le tecniche per sviluppare i programmi del sistema Semi-Automatic Ground Environment (SAGE) per la sorveglianza dello spazio aereo eventuali attacchi nucleari. Nella pubblicazione descrive un’approcciuo allo sviluppo delle applicazioni complesse che prevede diverse fasi ed evidenzia l’importanza delle fasi di test.

Wiston W Royce erroneamente viene considerato da alcuni come il padre del modello waterfall per lo sviluppo del software.

Iniziò la sua carriera come Assistant Professor presso il California Institute of Technology. Nel 1961 entrò, come project manager, nella divisione aerospaziale di TRW. Il suo primo progetto riguardava la progettazione di un sistema di pianificazione delle missioni e selezione dell’orbita per le navicelle spaziali.

Negli anni successivi fu coinvolto nella ricerca e sviluppo di diversi sistemi software grandi e complessi, e iniziò a sviluppare nuove metodologie per migliorare la gestione dei progetti software.

Nel 1970 pubblicò il suo influente articolo Managing the development of large software systems, in cui presentò i concetti di gestione dei progetti software. Effettivamente l’articolo mostra una serie di esempi che descrivono le varie fasi dello sviluppo in modo sequenziale, ma non teorizza mai il concetto di waterfall. Il suo modello è rappresentato da questa figura e lo descrive in 5 passi

che illustriamo per dare un’idea, ma che possono essere approfonditi nell’articolo originale.

Step 1 – Program Design comes first
Step 2 – Document the Design
Step 3 – Do it twice
Step 4 – Plan, control and monito testing
Step 5 – Involve the customer

È interessante notare come ci faccia sorridere, al giorno d’oggi, la collocazione all’ultimo posto del coinvolgimento del cliente. Ma va contestualizzata con con il periodo.

Un’altra particolarità stridente è il voler partire con il Program design prima della raccolta dei requisiti, che viene giustificata in questo modo:

This procedure can be criticized on the basis that the program designer is forced to design in the relative vacuum of initial software requirements without any existing analysis. As a result, his preliminary design may be substantially in error as compared to his design if he were to wait until the analysis was complete. This criticism is correct but it misses the point. By this technique the program designe, assures that the software will not fail because of storage, timing, and data flux reasons. As the analysis proceeds in the succeeding phase the program designer must impose on the analyst the storage, timing, and operational constraints in such a way that he senses the consequences.

È chiaro che, per i costi della tecnologia di allora, porre dei limiti in termini di storage o tempo di utilizzo era più importante che non realizzare completamente i requisiti. Si deduce che già fossero nel bagaglio di esperienze di Wiston progetti bloccati dopo l’analisi dei requisiti perché non realizzabili con la potenza di calcolo disponibile. 

T. E. Bell e T. A. Thayer pubblicano Software Requirements: Are They Really a Problem? Dove viene preso in esame l’aspetto dei requisiti. Sono particolarmente interessanti le riflessioni iniziali:

Una scuola di pensiero sostiene che i requisiti software sorgono naturalmente e che sono corretti per definizione. In questi requisiti è sufficiente indicare un’esigenza di base (ad esempio “fare il libro paga”), quindi questo è tutto ciò che serve. D’altra parte, se i requisiti stabiliscono le caratteristiche dettagliate di ciascuna soubroutine, quelle sono le caratteristiche richieste e l’implementatore non dovrebbe metterle in discussione.

Gli aderenti a questa scuola di pensiero sono cresciuti sempre meno man mano che l’industria del software ha acquisito esperienza con questo approccio allo sviluppo del software.

Quando ogni requisito che va in dettaglio dalle dichiarazioni dei bisogni alle specifiche delle procedure è considerato allo stesso modo, i sistemi risultanti tendono ad essere gravemente carenti.

Se al personale di programmazione viene assegnato il compito di implementare un sistema con solo una dichiarazione dei bisogni, la fase critica della progettazione del software verrà probabilmente saltata con risultati disastrosi.

D’altro canto, se le specifiche dettagliate della routine vengono accettate senza che ne sia mai stata esaminata la correttezza, il software risultante probabilmente non riuscirà a completare l’esecuzione normalmente, tanto meno a produrre risultati corretti.

e le conclusioni:

I nostri dati empirici mostrano chiaramente che il presunto “problema dei requisiti” è una realtà.

Le informazioni necessarie per la progettazione e l’implementazione di sistemi sia piccoli che grandi sono spesso errate, ambigue, incoerenti o semplicemente mancanti.

I requisiti per un sistema, sufficientemente dettagliati per il suo sviluppo, non sorgono naturalmente. Devono invece essere progettati e sottoposti a revisione e revisione continue.

A Gennaio del 1986, sulla rivista Harvard Business Review, Hirotaka Takeuchi and Ikujiro Nonaka pubblicano l’articolo The New New Product Development Game dove vengono descritte delle analogie con il rugby:

 

The traditional sequential or “relay race” approach to product development—exemplified by the National Aeronautics and Space Administration’s phased program planning (PPP) system—may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.

 

---

 

Barry W.Boehm pubblica il 4-Ago-1986 A Spiral Model of Software development and enhancement dove ipotizza lo sviluppo software con un approccio incrementale che, con una serie di iterazioni, costruisce dei prototipi sempre più vicini alla soluzione finale.

Nelle quattro fasi viene posto un focus sulla valutazione dei rischi e delle alternative:

1. Determinazione degli obiettivi, delle alternative e dei vincoli
2. Identificazione delle alternative, valutare e risolvere i rischi
3. Sviluppare e verificare il nuovo prodotto del iterazione in corso
4. Pianificare la fase successiva

 

 

Nel suo libro “Rapid Application Development”, James Martin descrive il concetto di Rapid Application Development (RAD) come un approccio allo sviluppo del software che enfatizza la rapidità e la flessibilità. Le caratteristiche principali del RAD, secondo Martin, includono:

Iterazione e Prototipazione: RAD si basa sull’uso di prototipi e cicli iterativi di sviluppo. Invece di seguire un processo lineare e sequenziale, il RAD incoraggia lo sviluppo rapido di versioni prototipali del software, che vengono poi testate e perfezionate attraverso un feedback continuo con gli utenti finali.

Coinvolgimento degli Utenti: Uno degli aspetti chiave del RAD è l’intensa collaborazione con gli utenti finali. Martin sottolinea l’importanza del coinvolgimento degli utenti in ogni fase del processo di sviluppo per garantire che il prodotto finale risponda alle loro esigenze e aspettative.

Cicli di Sviluppo Brevi: Il RAD si concentra su cicli di sviluppo brevi e rapidi, consentendo alle squadre di rispondere in modo agile ai cambiamenti nei requisiti e alle esigenze degli utenti.

Riduzione della Pianificazione Formale: A differenza dei metodi tradizionali che pongono grande enfasi sulla pianificazione dettagliata e sulla documentazione, il RAD promuove una pianificazione meno formale e più adattativa.

Efficienza e Rapidità: Il libro mette in evidenza l’efficienza del RAD nel produrre software di alta qualità in tempi relativamente brevi, grazie alla sua natura iterativa e al coinvolgimento degli utenti.

Modularità: Martin discute anche l’importanza della modularità nel RAD, dove il software viene sviluppato in piccoli pezzi o moduli che possono essere rapidamente assemblati o modificati.

Flessibilità e Adattabilità: RAD è presentato come un approccio flessibile e adattabile, capace di gestire cambiamenti e aggiustamenti durante il processo di sviluppo.

In sostanza, il RAD è presentato come un’alternativa rivoluzionaria ai metodi di sviluppo del software tradizionali, sviluppati negli anni ’70 e ’80, come il Structured Systems Analysis and Design Method (SSADM). Enfatizzando l’importanza della velocità, della flessibilità e del coinvolgimento degli utenti nel processo di sviluppo.

Un problema di questi metodi era che si basavano su un modello ingegneristico tradizionale, utilizzato per progettare e costruire cose come ponti e edifici. L’immutabilià, o meno, dei requisiti era un fattore di successo o di insuccesso frequente.

Il software invece è un artefatto intrinsecamente diverso. Può cambiare radicalmente l’intero processo di progettazione, consentendo che la conoscenza acquisita dal processo di sviluppo stesso possa retroalimentare i requisiti e la progettazione della soluzione.

Il Manifesto Agile è stato creato da un gruppo di 17 sviluppatori software durante un incontro a Snowbird, Utah, negli Stati Uniti. Questi sviluppatori, noti come i “Firmatari del Manifesto Agile”, hanno delineato i valori e i principi fondamentali che definiscono l’approccio Agile allo sviluppo software.

Tuttavia, le pratiche che hanno portato alla creazione del Manifesto Agile erano in uso e si stavano sviluppando in varie forme da alcuni anni prima del 2001. Metodologie come Scrum, Extreme Programming (XP) e altre avevano già iniziato a prendere forma negli anni ’90, ponendo le basi per quello che sarebbe diventato il movimento Agile. Queste metodologie condividevano un comune interesse per l’iterazione, la collaborazione, la flessibilità e l’adattabilità, che sono diventati i pilastri dell’approccio Agile che si identifica in questi 12 principi:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

 

Nel rapporto del 9 Giugno 2014 dal titolo New Development Platforms Emerge For Customer-Facing Applications viene descritto il conflitto tra la rapidità con cui le aziende richiedono nuove applicazioni o modifiche a quelle esistenti ed i tempi di sviluppo del software. Secondo il rapporto i vantaggi delle nuove piattaforme sono:

1 – Una partecipazione diretta degli utenti nella progettazione

Low-code platforms  speed up development by allowing Application Development&Delivery teams to eliminate barriers to customer participation in projects, as well as handoff between phases of project.

2 – Riduzione dei tempi di sviluppo

Low-code platforms minimize hand­ coding and speed up delivery by providing visual tools for quick definition and assembly of user experiences and forms, rapid build out of multistage workflows, and easilyconfigured data models that eliminate common data integration headaches.

3 – Avere a disposizione una palestra per testare e sperimentare nuove idee

Low-code platforms allow business leaders to experiment with new product and service ideas by merging requirements, design, development, and deployment into a single platform. This sandbox approach allows one- or two-person teams to compose new apps and quickly gain feedback from customers, employees, and partners.

4 – Indirizzare tutti i canali dei clienti, inclusi i mobile

Customers using the low-code application platforms primarily focused on apps for the web channel. But these platforms support responsive design and mobile-ready functionality that makes it as easy as pushing a button to extend the app to work across other channels, including tablets and smartphones.

5 – Avere un unico punto di controllo per la configurazione, la distribuzione e la manutenzione delle app

Low­ code platforms provide a unified and centralized environment for configuration management, role-based access, authentication, and repository control of apps and configuration components. All key players in software delivery – enterprise architects, security experts, IT operations, and business experts – can add their input to the configuration and management of the platform.

 

I fornitori dellepiattaforme esaminate nel report appartegngono a tre settori dell’industria del software, e ciascuno apporta particolari punti di forza ai progetti applicativi rivolti al cliente fornendo al contemporaneamente i quattro vantaggi comuni descritti sopra.

I fornitori di piattaforme low-code si stanno evolvendo da:

Business process and dynamic case management – AgilePoint, Appian, Bizagi, Intalio, K2, MicroPact, Mobideo, Nintex, Red Hat e Software AG condividono tutti i punti di forza nella gestione dei processi aziendali (BPM), nel case management e nei workflow. Ciascuno di questi fornitori ha inoltre sviluppato o acquisito, nelle versioni recenti, strumenti di sviluppo low-code in modo così drammatico da semplificare l’adozione dei loro prodotti rispetto alle suite aziendali classiche.

Applicazioni general-purpose e cloud – Alpha Software, Alphinat, Claysys Technologies, Mendix, OutSystems e salesforce cercano di affrontare un’ampia gamma di scenari di applicazioni web e mobili con ampi set di strumenti e servizi applicativi per le transazioni, integrazioni e worjflow;
Alpha Software, Alphinat e Claysys Technologies sono forti per le applicazioni di database;
Alphinat e Claysys Technologies sono forti anche per le applicazioni basate su form;
Mendix, OutSystems e Force.com di salesforce aggiungono punti di forza nella collaborazione e nei processi aziendali

WEB content management – Acquia e Adobe rispondono alle esigenze degli sviluppatori che lavorano principalmente con HTML e CSS come linguaggi di programmazione per creare applicazioni con sofisticate esigenze di contenuti web. Questa categoria si sta trasformando lungo la stessa linea del BPM aziendale: i clienti apprezzano soluzioni agili e leggere rispetto alle soluzioni di Web Content Management aziendali.