Chi, come e quando predispone il contenuto delle specifiche?

Transcript

1 Chi, come e quando predispone il contenuto delle specifiche? Giovanna Petrone Dipartimento di Informatica Università di Torino

2 La Crisi del Software Problemi con il software: Spesso consegnato troppo tardi Non si comporta come il cliente si aspetta Raramente adattabile a circostanze modificate Molti errori scoperti dopo la consegna Communication between stakeholders!

3 Gestire la Crisi del Software Tre dimensioni da gestire : Programmatori diversi Complessità delle applicazioni Manutenzione La soluzione proposta (in quel momento): Un approccio più formale e strutturato allo sviluppo software La soluzione ha funzionato?

4 Diagramma del software lifecycle Elicitazione requisiti Analisi Design Implementazione Testing Time Manutenzione

5 Come soddisfare il cliente Scegliere prima le funzionalità importanti Fare pratica nello stimare il tempo necessario a realizzare le funzionalità richieste Il costo dei cambiamenti (tradizionalmente) requisiti progettazione testing implementazione produzione costo dei cambiamenti tempo

6 Il vecchio e il nuovo modo Vecchio: Lunga analisi dei requisiti Lungo periodo di implementazione Alla fine si può essere perso tempo in caratteristiche non importanti o già sorpassate Il modo extreme Un semplice prototipo SUBITO Sviluppo incrementale, con feedback rapido Il cliente può cambiare i requisiti

7 Extreme Programming (Wells, 2000)

8 Definizione quantitativa e qualitativa delle specifiche. Accettazione e collaudo.

9 Analisi dei requisiti, use cases, e storie dell utente

10 Analisi dei requisiti Si raggruppa sotto questo termine molte, spesso scorrelate, attività, incluse: Elicitazione dei requisiti dagli utenti Engineering dei requisiti, per determinare la miglior configurazione dei requisiti Gestione dei requisiti, per organizzare i requisiti in una struttura facile da maneggiare Analisi del sistema da costruire

11 Una rete di attività e proposte Include: Wish lists dei clienti Specifiche formali Specifiche eseguibili e programmazione logica Diagrammi E R Tecniche basate su scenario Reti di Petri

12 Cosa? Quesiti dei requisiti Esempio: Essere in grado di configurare tutte le variabili, come il nome utente, password, livello di accesso Sforzo richiesto? Esempio: 1 settimana

13 Priorità? Quesiti dei requisiti (cont.) Esempio: Configurare la password più importante del livello di accesso, del nome utente Rischio? Esempio: Gli sviluppatori sono a conoscenza delle tecnologie di encryption?

14 Principi chiave Separare il cosa dal come i requisiti non devono assumere un particolare design o implementazione Cosa: Informazione su libri ordinati deve essere memorizzata permanentemente Come: Informazione su libri ordinati deve essere memorizzata utilizzando Database A Deve essere sufficientemente chiaro per sapere che cosa costruire e verificare che sia costruito correttamente

15 Tipi di requisiti (1/2) Requisiti funzionali: Descrivere l interazione tra il sistema e il suo ambiente indipendente dall implementazione Il sistema orologio deve mostrare l ora basata sulla posizione Requisiti non funzionali: Aspetti del sistema visibili all utente non direttamente correlati con il suo comportamento funzionale Il tempo di risposta deve essere meno di un 1 secondo La precisione deve essere a meno di un secondo L orologio deve essere disponibile 24 ore al giorno eccetto che tra le 2:00am-2:01am e le 3:00am-3:01am

16 Tipi di requisiti (2/2) Vincoli ( Pseudo requisiti ): imposti dal cliente o dall ambiente nel quale il sistema opererà Il linguaggio di implementazione deve essere COBOL. L hardware deve essere un PC.

17 Che cosa non è un requisito? Struttura del sistema, tecnologia di implementazione Metodologia di sviluppo Ambiente di sviluppo Linguaggio di implementazione E desiderabile che nessuna delle scelte elencate sia vincolata dal cliente. Fight for it!

18 Criteri di validazione dei requisiti Passo critico nel processo di sviluppo: Normalmente dopo l engineering dei requisiti o l analisi dei requisiti. Anche alla consegna. Criteri di valutazione dei requisiti: Correttezza: I requisiti rappresentano il punto di vista dell utente Completezza: Sono descritti tutti i possibili scenari, inclusi i comportamenti eccezionali dell utente

19 Criteri di validazione dei requisiti (cont) Consistenza: Esistono requisiti funzionali e non che si contraddicono tra loro Chiarezza: Non ci sono ambiguità tra i requisiti Realismo: Requisiti che possono essere implementati e consegnati Tracciabilità: Ogni funzione di sistema può essere messa in corrispondenza con un insieme corrispondente di requisiti funzionali

20 Verbale Scritto Implementare i requisiti Note sulla carta, index cards, foglietti gialli, documenti formali Siti Web Prototyping Ricordate, Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned. (Hunt and Thomas, 2000)

21 Elicitazione di requisiti basati su scenario Scenario è: A narrative description of what people do and experience as they try to make use of computer systems and applications (M. Carrol, Scenario based Design, Wiley, 1995) Una descrizione concreta, focalizzata, informale di una singola caratteristica del sistema utilizzata da un singolo attore. Raccolta osservando e intervistando gli utenti

22 Diagramma Use Case Withdraw Money Bank Cus tom er Deposit Money Transfer between Accounts

23 Problemi degli Use Cases Molte definizioni in alcuni casi contraddittorie La granularità dipende dall'interpretazione dello Use Case Alcune volte legata ad un pesante, plandriven processo di sviluppo

24 Storie utente e use cases Proponiamo un interpretazione di use cases=user stories, che: Limita la dimensione di use cases Quando uno use case contiene eccezioni, cammini multipli, ecc., li scompone Lascia la possibilità di creare, un immagine comprensiva dell intero sistema

25 The XP Picture

26 Analizzare i requisiti L obiettivo di analizzare i requisiti è di esser sicuri di saperne abbastanza per procedere con il design e costruire qualcosa Così quanto è abbastanza? Attenzione alla Paralisi dell analisi!

27 Strumenti di sviluppo completi Netbeans: Eclipse:

28 Testing

29 Il ruolo del testing Definizioni Tipi di testing Black box testing Contenuto

30 Testing e Bachi Program testing can be used to show the presence of bugs, but never to show their absence! (Dijkstra, 1969) Ma l assenza di bachi non può provare nulla

31 Semplice Overview di Unit Testing Testing Test di moduli singoli Integration Testing Test di moduli che lavorano insieme System Testing Test del programma complessivo Acceptance Testing Valutazione del cliente della conformità del sistema ai requisiti

32 Divisione dei tasks (1/2) Unit Testing Fatto dal programmatore(i) Generalmente tutti white box Automazione desiderabile per la ripetibilità Integration Testing Fatto dai programmatori quando integrano il loro codice nel code base Generalmente white box, alcune volte black box Automazione desiderabile per la ripetibilità

33 Divisione dei tasks (2/2) Testing Funzionale/Sistema Si raccomanda di farlo fare (anche) a gruppi esterni Principalmente black box così che il testing non sia corrotto da troppa conoscenza Desiderabili test automatici Acceptance Testing Eseguito dal cliente/rappresentante del cliente nel suo ambiente... Sicuramente black box

34 L approccio agile Design un poco, Codifica un poco, Testare un poco Test before programming!

35 Code management e Configuration Management Systems

36 Software Configuration Management Motivazioni: perche' software configuration management? Definizione: che cosa e' il software configuration management? Attività e ruoli in software configuration management

37 Ruoli in SCM Configuration Manager Change control board member Developer Auditor

38 UNDO button Obiettivi del Configuration Management Tracciabilità delle modifiche Chi? Quale differenza tra due versioni? Which files get changed most? Identificazione delle releases Merge modifiche

39

40

41 Tools for Software Configuration Management TogetherSoft RCS CVS (Rational) ClearCase eproject

42 Free Software

43 La filosofia Open Source L'utente puo' gratuitamente: Utilizzare Copiare Distribuire Studiare Cambiare Migliorare il software

44 La filosofia Open Source Un buon prodotto sw inizia con un problema personale di uno sviluppatore I bravi programmatori sanno cosa scrivere. I migliori sanno cosa riscrivere. Quando un programma non ti interessa piu e tuo dovere passare le consegne ad un successore competente Trattare gli utenti come sviluppatori e il modo migliore per ottenere debugging efficace e miglioramenti del codice Distribuisci presto e spesso (e ascolta gli utenti).

45 Il processo Open Source Il processo e pubblico Le implementazioni sono controllate da una board che revisiona e testa il codice proposto Il codice e prodotto attraverso: Modifiche moderate Build frequenti E proprietà collettiva Non esiste il MANTENIMENTO

46 GNU e General Public License GNU: lanciato nel 1984 per sviluppare un sistema operativo tipo Unix (Linux) Licenza GPL: Si puo' distribuire e offrire il supporto a pagamento Ma il codice sorgente deve rimanere modificabile e distribuibile GRATUITAMENTE

47 When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

48 Discussione