Progettazione dei sistemi informatici

Transcript

1 Progettazione dei sistemi informatici Gestione dei progetti CARLO BELLETTINI

2 Agile! Bertrand Meyer In realtà non è solo un libro su Agile analizza in maniera critica molti concetti metodologici su come si fa a parlare di un processo

3 Meta considerazioni sulla presentazione dei modelli Natura descrittiva cerco di rappresentare ciò che vedo Natura prescrittiva cerco di fornire un template a cui bisogna attenersi

4 Falsi 1 Proof by anecdote, which we have seen at work in this example. An anecdote, or ten, are not a proof. 2 Slander by association: lumping together an idea that an author wants to criticize with one that everyone loathes. Non-agile ideas get that treatment. 3 Intimidation: labeling anyone who does not buy the agile gospel, chapter and verse, as a reactionary control freak. 4 Catastrophism: pretending that software development as currently practiced is a disaster (so that only your agile method can save it). 5 All-or-nothing. promoting an extremist method, not practicable in its entirety, so that project successes can be ascribed to agile techniques and failures to their incomplete application. 6 Cover-your-behind: advocating radical prescriptions; then as a footnote stating that they may not after all be always applicable; but never saying precisely when they should be used and when not. 7 Unverifiable claims. The Scrum literature in particular routinely touts enormous productivity improvements. Who would not want to multiply project effectiveness by an order of magnitude? In the absence of rigorous independent verification, you should take such assertions (depending on your benevolence on that particular day) as either a sign of charming youthful enthusiasm or irrelevant hype to be discarded.

5 Modello a spirale (Boehm 1988)

6 Pinball Life-Cycle (Ambler, 1994)

7 Unified Process

8 Best practices Sviluppare iterativamente Gestire i requisiti Usare architetture basate sui componenti Creare modelli visivi del software Verificare la qualità del software Controllare le modifiche al software

9 Alcune leggi in ordine sparso... Davis Law (L4): The value of models depends on the view taken, but none is best for all purposes Constantine Law (L7): A structure is stable if cohesion is strong and coupling low Bauer-Zemanek s Hypotesis (H3): Formal methods significantly reduce design errors, or eliminate them early Parnas Law (L8): Only what is hidden can be changed without risk Humphrey s Law (L35) Mature processes and personal discipline enhance planning, increase productivity and reduce errors.

10 Volatilità dei requirements

11 Requirements e stakeholders

12 Lean Software Nasce da Lean Manufactoring della Toyota Reduce waste

13 Kanbam Minimize Work In Progress

14 Scrum Freeze Requirements during short Iterations

15 Crystal Osmotic Communication

16 extreme Programming Increment then simplify

17 extreme programming: Le variabili in gioco portata la quantità di funzionalità che si vogliono implementare delicata perché mutevole tempo il tempo che si può dedicare al progetto qualità la qualità del progetto che si deve ottenere costo le risorse finanziarie che si possono impegnare

18 extreme programming: i principi feedback rapido presumere la semplicità non pianificare per il futuro, per il riuso

19 Design for change si o no? Boehm (1976) basandosi sullo studio di casi reali ipotizza una curva di tipo esponenziale per il costo di modifiche Extreme programming sostiene Costo di modifiche Costo di modifiche Avanzamento del progetto Avanzamento del progetto

20 Leprechauns... Cap 10

21 extreme programming: i principi feedback rapido presumere la semplicità non pianificare per il futuro, per il riuso accettare il cambiamento tra soluzioni equivalenti (anche come complessità) scegliere comunque quella che lascia più strade aperte modifica incrementale le modifiche vanno effettuate per piccoli stadi si applica al progetto, al piano di lavoro, al team lavoro di qualità visto dal punto di vista psicologico: se si vuole che il programmatore rimanga, e sviluppi bene deve essere soddisfatto di ciò che fa

22 Figure in gioco e responsabilità Manager (e/o cliente) ha la responsabilità di decidere la portata del progetto cosa fare prima del rilascio le priorità tra le funzionalità date dei rilasci Tecnico ha la responsabilità di decidere stime dei tempi per implementare le singole funzionalità conseguenze di scelte tecnologiche processo pianificazione dettagliata

23 Diritti Diritti dei Manager and Customer sapere che cosa può essere fatto, con quali tempi e a quali costi vedere progressi nel sistema, provati dal superamento di test da lui definiti cambiare idea, sostituire funzionalità e cambiare priorità Diritti degli sviluppatori sapere cosa è necessario attraverso dei requisiti chiari (storie di uso) con una chiara dichiarazione delle priorità dire quanto tempo serve per implementare una specifica storia e di cambiare queste stime in base all esperienza identificare e indicare le funzionalità pericolose (portatrici di rischi) in modo da potergli assegnare alte priorità e sperimentarle produrre software di qualità in pace, con divertimento. Insomma ad un lavoro divertente ma produttivo.

24 extreme Programming: L approccio 1) Planning game 2) Brevi cicli di rilascio 3) Uso di una metafora 4) Semplicità di progetto 5) Testing 6) Refactoring 7) Programmazione a coppie 8) Proprietà collettiva 9) Integrazione continua 10) Settimana di 40 ore 11) Cliente sul posto 12) Standard di codifica

25 Planning game & user stories 43

26 extreme Programming: L approccio 1) Planning game 2) Brevi cicli di rilascio 3) Uso di una metafora 4) Semplicità di progetto 5) Testing 6) Refactoring 7) Programmazione a coppie 8) Proprietà collettiva 9) Integrazione continua 10) Settimana di 40 ore 11) Cliente sul posto 12) Standard di codifica Vengono determinate le funzionalità del prossimo rilascio, combinando priorità commerciali e valutazioni tecniche. Basato su storie scritte dall utente: una versione semplificata ed informale degli Use Cases di UML 3 FASI CICLICHE: Esplorazione: scoprire cose nuove che potrebbe fare il sistema Impegno: si decide quale sottoinsieme di tutti i possibili requisiti realizzare nella prossima fase (contribuiscono sia gli utenti che i programmatori) Gestione: direzione dello sviluppo con correzioni dall andamento reale