Innovative Software Engineering Verso un nuovo paradigma di Ingegneria del SW Applicazione della metodologia «agile» alle produzioni

software ad alta affidabilità

Ing. Angelo MESSINA Brigadiere Generale Esercito

Cosa c’è da innovare?

Un nuovo modo di concepire l’ingegneria del

software

Agile e contesti ad alta affidabilità

Un nuovo modo di offrire formazione “agile”

2

Il Prodotto Software

Prodotto

dell’intelletto

destinato ad

«umani»

Molteplici

tentativi

d’ingabbiare

l’attività

assimilandola

ad un

qualunque

prodotto

dell’ingegneria

L’evoluzione

tecnologica

degli strumenti

di sviluppo ha

portato la

Software

Factory sul PC

Il Software è invasivo e pervasivo

4

Complesso o Complicato?

5

Complexity

• COMMAND & CONTROL

The processes of understanding, planning, directing coordinating and controlling forces and operations in the accomplishment of the mission

• SITUATIONAL AWARENESS

The processes that concern the knowledge and understanding of the environment that are critical to those who need to make decisions within the complex mission space

• COMMON OPERATIONAL PICTURE

Fusing fires, ISR, logistics, maneuver information across the entire battle space, into a single shared display enabling leadership decision-making processes

… the right information at the right time, disseminated and displayed in the right way, so that Commanders can do the right things at the right time in the right way …

Top “User” statement on COMMAND AND CONTROL

8

Prima difficoltà: L’approccio “agile” al requisito utente prevede l’uso di “User stories” che devono fare i conti con la complessità del requisito

User Stories

• Descrizioni in linguaggio naturale dei “Requisiti funzionali” di un sistema/prodotto Software

• Sono semplici, non definitive e frutto di un dialogo a più riprese tra chi conosce l’esigenza e chi sa come risolverla con un prodotto software

• Devono riferirsi a specifiche caratteristiche e non a enunciazioni di carattere generale.

• Possono essere raccolte attraverso workshop dedicati

9

Comunicare

Il problema della specifica del requisito non è un problema informatico

10

Il problema “linguistico” • Cosa intende veramente comunicare l’utente/stakeholder?

• Linguaggio naturale: libertà vs ambiguità il trade-off

ambiguità sintattica ,ambiguità semantica ambiguità lessicale ambiguità, nell’assegnazione delle relazioni grammaticali “Michele vide un uomo in strada con il binocolo” “Chi uccise il soldato?”

• Ontologie e Semantic networks

Ingegneria del SW approccio tradizionale: Waterfall e metodi lineari

«V» Model

Spiral Model

Metodi Lineari (“cascata”,”V”, ecc) :

• stesura requisito formale;

• analisi requisito (e contrattualizzazione);

• produzione;

• verifica;

• modifiche;

• uteriore verifica e introduzione in servizio;

• inizio ciclo lezioni apprese;

• manutenzione ed evoluzione (a titolo oneroso);

14

Esito dei METODI tradizionali DI PRODUZIONE SW

36-48 mesi (ottimistico)

6-18 mesi

variabile

5+ anni per le prime varianti dettate dalle

operazioni Quasi completamente abbandonati perchè:

– Costo non sostenibile (> 130 € a LOC/FP1);

– 70% dei programmi falliti o abbandonati

– Bassa soddisfazione del cliente

1. Linea di Codice/Punti Funzione

DoD Instruction 5000.02 (Dec 2013) heavily emphasizes tailoring program structures and acquisition processes to the program characteristics. Agile development can achieve these objectives through:

Focusing on small, frequent capability releases

Valuing working software over comprehensive documentation

Responding rapidly to changes in operations, technology, and budgets

Actively involving users throughout development to ensure high operational value

Agile practices integrate planning, design, development, and testing into an iterative lifecycle to deliver software at frequent intervals. Developers can demonstrate interim capabilities to users and stakeholders monthly…...

15

Department of Defense (US) prescrive l’utilizzazione di “Agile” per l’acquisizione di ICT

Lo sviluppo in “Agile” nell’E.I. inizia nel febbraio 2014

Rilasci frequenti di software utilizzabile sul campo + prodotto – documentazione Coinvolgimento utente finale In pratica: “usate metodi Agile”

Aziende settore Difesa transitate ad “agile”

“Agile” (commerciale) cambia le regole

Che cosa è importante nelle metodologie “agile”?

Valori Principii Pratiche Regole

17

Da ritoccare

leggermente perché si

possa applicare ai

sistemi ad alta

affidabilità

“Agile” è la panacea?

Non esiste alcun proiettile d’argento!

18

L’uso di metodologie Agili non

cambia le caratteristiche

intrinseche del Software rendendo

ancora più necessarie:

Best practices

Quality first

Test driven design

Embedded Security Coding

19

Scrum (Kanban, ITA2 )potrebbe non essere cosa facile passare ad “agile”…

• Illusione di comando e controllo del processo (ci si può provare!)

• Credere nella magia (forse si!)

• “Noi siamo già Agili!” (la cosa che tutti dicono)

Tony D. Clark, © 2006 implementingscrum.com

ROI ?

Il vantaggio di efficienza tra

metodi lineare e metodi agili è comunque “strutturale”

Vale la

pena di

passare

ad

“Agile”?

Agile SCRUM (metodo di partenza per ITA2)

A un tentativo di gestire la

complessità usando il solo strumento

disponibile: La mente umana

3-5 weeks

Perchè abbiamo introdotto “Agile”

(inizialmente Scrum) nello sviluppo di software

militare

Necessità imposte da

‒ Restrizioni di budget

‒ Miglioramento della soddisfazione del Cliente

‒ Aderenza a requisiti mutevoli nel breve periodo

(volatile) requirements

Innovative Software Engineering (ITA2 case study)

Italian Army Agile è un freamework concettuale sviluppato

congiuntamente da esperti del mondo militare, accademico e

industriale utilizzato dallo Stato Maggiore Esercito per I suoi più recenti

sviluppi SW

Mission Critical Software Agile Development

Agile

Training

Innovative CASE Tools

Structured

User

Community

Governance

Custom Agile

Development

Doctrine

People (Stake Holders, Users, Developers, “Agile”

Innovators)

Occorre una nuovo CASE con funzionalità tali da:

‒ Gestire una rete di utenti/ stake-holders/ che sono una

vera community molto articolata e diversificata

‒ Prevedere il supporto di Product Ownership (scrum P.O.) multilevel boards

‒ Catturare, gestire e tracciare un set molto complesso di

requisiti multidisciplinari

‒ Supportare Team misti (utente-produttore) in modalità

interconnessa e parallela (Scrum of Scum)

Introduzione di “Agile” nell’Esercito Italiano

Occorre un nuovo concetto di Software Engineering

Software Development Control Room

iCASE

tool

Global Dash-board (ITA2) Team 1 Team 2

iCASE

tool

First Results (presentati in consessi europei e NATO)

‒ > 30 Sprints executed

‒ Customer satisfaction

over 90%

‒ Cost reduction > 50%

‒ Same quality level

Scrum is able to take care of the intrinsic non-linearity of the

“Requirement specification” phase focusing on interaction and not on

the process eliminating various level of “translation” of the user need.

S1- ADE S2-

AFRODITE

S3-ATENA S7-DEMETRA

S1 (ADE) February 17, 2014

March 21, 2014

January February March April May June July August September October November December

S2 (AFRODITE) March 24, 2014 April 15, 2014

S4 (ARES) May 28, 2014 June 16, 2014

S3 (APOLLO) April 21, 2014 May 23, 2014

S5 (ARTEMIDE) June 16, 2014 July 4, 2014

S7 (DEMETRA) August 4, 2014

August 29, 2014

S9 (EFESTO) November 10, 2014 November 28, 2014

S6 (ATENA) July 7, 2014

July 25, 2014

S8 (DIONISO) October 6, 2014

October 24, 2014

S10 (CRONO) December 2 2014

December 19, 2014

2014

Ogni Sprint consegna funzionalità significative per l’Utente

S11 (EOLO) Jan 20, 2015 Feb 9, 2015

January February March April May July August September October November December

S12 (ELIO) Feb 27, 2015 Mar 20, 2015

S14 (ERA) May 11, 2015

Jun 5, 2015

S13 (EO) Mar 30, 2015 Apr 30, 2015

December June

S15 (ERACLE) Jun 15, 2015 Jul 10, 2015

S16 (ERINNI) Jul 20, 2015 – Sep 11, 2015

2015

Ogni Sprint consegna funzionalità significative per l’Utente

Questioni Metodologiche Aperte Raccolta e gestione delle “user stories”

Il linguaggio naturale è facile per gli utenti ma può mancare di struttura per un utili avvio dello sviluppo sw

Necessita una forma di disciplina che non alteri la natura non lineare dell’interazione con l’utente.

“Indipendent, Negotiable, Valuable, Estimable, Short, Testable”: la maggior parte degli attribbuti desiderati per le U.S. in Scrum sono di tipo linguistico più che informatico

Usare UML o altri formalismi è una forma di traduzione, cosa si perde?

Questioni aperte 2

Monitoring & measuring

Non invasive tools (scelta E.I.) necessary to

keep quality level and monitor criticalities

need to evolve.

Current complexity metrics borne for the old

fashion software factories do not give a

complete picture of the team based code

development cycle

What is the right amount of “control” for the

agile environment?

“Agile” Research Areas

‒ Computational linguistic approach to the User

Stories collection and validation

‒ Human based metrics to help the recruitment and

team building phases and correctly design the

continuous training

‒ New generation of non invasive CASE tools explicitly

designed for “agile” SW development

‒ New Metrics (Human Based)

H2020 R&T Key Research

Challenges

Innovative CASE (iCASE) Characteristics:

Dedicated “social” network to support the User Community

“Smart” management of the User Stories

Non invasive measurements

Innovative software complexity metrics (to include the human

factor)

34

Software Development Control Room

iCASE

tool

Global Dash-board (ITA2)Team 1 Team 2

iCASE

tool

S1 (ADE)February 17, 2014

March 21, 2014

January February March April May June July August September October November December

S2 (AFRODITE)March 24, 2014April 15, 2014

S4 (ARES)May 28, 2014June 16, 2014

S3 (APOLLO)April 21, 2014May 23, 2014

S5 (ARTEMIDE)June 16, 2014July 4, 2014

S7 (DEMETRA)August 4, 2014

August 29, 2014

S9 (EFESTO)November 10, 2014November 28, 2014

S6 (ATENA)July 7, 2014

July 25, 2014

S8 (DIONISO)October 6, 2014

October 24, 2014

S10 (CRONO)December 2 2014

December 19, 2014

2014

iCase the ideal “agile” development environment 35

Linguistic/

semantic tools

Non invasive

productivity tools

User needs ontology

Builder

Innovative

SW

metrics

Innovative Software Engineering (ITA2 case study)

Mission Critical Software Agile Development

Agile

Training

Innovative CASE

Tools

Structured

User

Community

Governance

Custom Agile

Development

Doctrine

People (Stake Holders, Users, Developers, “Agile”

Innovators)

37

Creare l’ambiente culturale per lo sviluppo di un nuovo paradigma d’ingegneria del software

Defense & Security Software Engineers Association Associazione degli Ingegneri del Software per Sicurezza e Difesa

www.dssea.eu

SOFTWARE ENGINEERING Elaborazione di un nuovo paradigma d’Ingegneria del software

Agile Enterprise Network Creazione di una rete d’imprese ispirata a criteri di agilità ed efficenza

Training Formazione innovativa Per generare figure professionali capaci di raccogliere le sfide del futuro

Ciclo conferenze SEDA www.sedaconference.eu/2016

Call for Papers (temporary content, to be completed) Software Engineering methodology, implementation, innovation & tools. (Security & Defense focus will have priority) Software Applications Security, secure coding, cyber threat evolution, cyber defense. Big data and future implications for Smart Organizations (D&S). H2020 ICT work program 2016/17 proposals. Addittive Manifacturing (3D printing) software intensive production processes of the future pose new challenges and threats to software engineering.

Risultati SEDA 2015 • La Conferenza ha visto una partecipazione di rilievo non comune e oltre

le aspettative; infatti i due giorni di presentazione sono stati seguiti da più di 200 partecipanti provenienti da oltre 20 diverse realtà industriali, altrettante PMI (Piccole Medie Imprese) italiane e 14 tra università e istituti di ricerca anche esteri, segnando un successo che nel settore nazionale si profila come il maggiore evento nel settore dello sviluppo software per applicazioni dell’ambito Difesa e Sicurezza.

• 44 articoli tecnici approvati

• Pubblicazione da parte di Springer in corso.

1° Premio DSSEA Innovative Software Engineering

• Verrà attribuito alla tesi di laurea (2015-2016) nel settore dell’informatica e discipline affini che avrà messo in luce elementi d’innovazione nel settore dello sviluppo del software e/o incorpori metodologie innovative che consentano il miglioramento dell’efficienza del processo produttivo, dell’aderenza alle necessità dell’utente, e una migliore gestione delle problematiche legate alla sicurezza del codice e alla tutela della privacy dei dati.

• Il premio consiste nella somma di 1000 euro, tesseramento gratuito alla DSSEA e pubblicazione del lavoro negli atti ufficiali di SEDA 2016.

• Dettagli sul sito DSSEA

Innovative Software Engineering Course • Il “Corso in Innovative Software Engineering” è l’elemento di base del

ciclo didattico di preparazione per figure destinate ad operare nel processo di produzione del software per applicazioni ad alta affidabilità con la versione della metodologia "AGILE" sperimentata e utilizzata dall’Esercito Italiano.

• L’attività si attua con il patrocinio di sotto l'egida del Comitato Formazione e Standard della DSSEA che ne cura la rispondenza ad obiettivi didattici, attualità e la qualità dei docenti.

• Le figure professionali formate attraverso il corso riempiono il vuoto esistente fra le pratiche così dette “agile” sviluppate in ambito commerciale e le necessità imposte dagli ambienti di sviluppo software formali.

Innovative Software Engineering Course • A differenza di quanto fino ad oggi disponibile sul mercato, il corso

“Innovative Software Engineering” è articolato su una prima fase di approfondimento sulle metodologie “Agile” e la loro comparazione con i metodi di sviluppo tradizionali tenuta da illustri professori provenienti da università italiane e straniere, autori di numerose pubblicazioni scientifiche in materia di ingegneria del software e in particolare di metodi “agile”.

• Una seconda fase applicativa, sulla implementazione effettiva di un ciclo produttivo agile reale tenuto da ingegneri del software militari con effettiva esperienza di realizzazione di prodotti software “mission critical”

Corso Innovative SW Engineering fase applicativa

Effort Planning

Simulando un utente/stakeholder condurre una

breve intervista che consenta di stilare e almeno

5 user stories (INVEST) per ogni (3) ruolo. (12’)

1

In qualità di sorvegliante

Devo poter Al fine di priorità

In qualità di supervisore

In qualità di manager

15’

Tocca a voi (intero Team)Game rules:

1

•Esecuzione simulata e stilizzata di uno Sprint di 3 settimane pari a 120ore lavorative / operatore

•8 elementi per Team

•PO = Product Owner Stakeholder

•SM = Scrum Master (forte)

•AP = Analista Programmatore – P se usato come Pair Programmer

•S = software Security Expert

•T = software Testing Expert (in aggiunta al testing effettuato da AP)

Effort Planning Diamo per effettuato il Team Building

1. Definire i ruoli nel team (3’) : P.O.-SM-AP-SecEx-Tester = 8 elementi

(serviranno a definire l’impiego delle risorse nei task)

1

Occorre definire il

bilanciamento tra il

numero di Analisti

Programmatori e quello

di esperti di sicurezza e

testing (tot. 6 elementi)

Users Stories & Use Cases

Esercitazione

1

Scopo:

Simulando uno sprint “semplificato” approfondire alcuni elementi critici della metodologia agile.

•Ruolo dell’utente finale

•Raccolta delle User stories

•Pianificazione delle risorse e sprint planning

•Gioco dei ruoli•Rapidità di reazione

•Capacità di agire in Team

Sprint planning (esempio def. Task Verifica/allocazione delle risorse totali (es.per n. 4 AP-1SecEx-1Test spec.)

1

US #1Supervisore flussi video minimi/ottimali

Funzione sw Risorse A/P (h) Risorse testing Risorse Sicurezza Pairprogramming

Task1 Acquisizione stream video 8 1 0 0

Task2 Restituzione lato client sala operativa

8 1 1 si

US #nSupervisore flussi video minimi/ottimali

Funzione sw Risorse A/P (h) Risorse testing Risorse Sicurezza Pairprogramming

Task1 aaaaaaaaaaaaaaaa 8 2 1 si

Task2 bbbbbbbbbbbbbbbb 8 1 0 si

Totali (50/60) 10 task riprogrammati per il prossimo sprint

400 120 120 80

Ultima occasione per ridefinire la squadra

Simulazione realizzazione MMI 1

07:21:32 Op1: tutto bene lungo perimetro ovest07:22:01 SO: OK

Sensori perimetraliSensori IRRadar 1Locks

Sprint planning (limitato a 1 settimana) esempio con 4 task paralleli al giorno

1

Simulazione 1° Sprint

Condurre uno stand-up meeting

abbreviato (5’)

Disegnare (a matita) una MMI

simulata con le funzioni realizzate.

Abilitare SOLO le funzioni

pianificate

Applicare I risultati del “gioco”

Definire il risultato ottenuto

1

20’

•Domande?