Progettazione di Apparati e Sistemi di TLC

1. Progettazione di Apparati e Sistemi di TLC Laboratorio Prof. Claudio Becchetti

2. Lezione 1 Progettazione: “il problema tipico”

3. Regole del corso • la maggior parte del lavoro si svolge in classe • le lezioni sono interattive • Colui che chiede una domanda può diventare uno stupido per 5 minuti, colui che non la chiede sarà uno stupido per sempre (prov. cinese) • Creare il cartellino badge • la valutazione finale non si basa sulle risposte date in classe

4. metodo di valutazione • la valutazione si basa su: • voto di gruppo, • Voto di coppia (tesina) • Esame individuale • Tesina: il vostro background ?

5. Preparazione individuale • corsi sulla progettazione del software • corsi su TLC • conoscenze Object oriented • conoscenze linguaggi di programmazione • Elettronica • bioingegneria • problem solving ?

6. Testi di riferimento • TLC • Reti di Computer,Tanenbaum A. , Prentice Hall Int. 1996 (anche in italiano) • Digital Communications, Proakis J. G., McGraw-Hill • Software • Software Engineering, Pressmann Roger S. , McGraw-Hill, (anche in italiano) • UML Distilled: Applying the Standard Object Modeling Language, Martin Fowler, Kendall Scott, Addison-Wesley (anche in italiano)

7. Altri testi • Articoli • “No silver bullets, essence and accidents of software engineering”, Brooks F. P., Computer (Apr. 1987). • “Building bug-free O-O software: An introduction to Design by Contract”, Meyer B., available in http://www.eiffel.com/ • Jézéquel J.M., Meyer B., “Design by contract: the lesson of Ariane”, IEEE Computer, 30, No. 2, pp. 129-130 (Jan. 1997) also available in http://www.eiffel.com/

8. testi opzionali • Analisi Strutturata dei Sistemi, E. Yourdon. Jackson Italia, 1990 • The C++ Programming Language, third edition, Stroustrup B., Addison-Wesley (1997). . • Speech Recognition : Theory and C++ implementation, Becchetti C., Prina L., John Wile & Sons, 1999 • Borland C++ 4.0 Object-Oriented Programming, Cantù M., Tendon S., Random House/Borland Press (1995) • Cline M. P., Lomow G. A., C++ Faqs, Addison Wesley (1995).

9. Presentazione del corso • Corso di progettazione • focus sulla progettazione in generale • focus sulla progettazione del software • focus sui sistemi di telecomunicazione (TLC) • focus su Object Oriented (OO) e C++ • Perché focus sulla progettazione ? • La progettazione è uno strumento per il problem solving • esempio paolo

10. a cosa vi serve veramente questo corso ? • Non progetterete mai ? • Non svilupperete mai il sw ? • non vi occuperete mai di TLC ? • Il C++ sarà superato • l’object oriented non serve ? • Dopo un mese dall’esame vi sarete dimenticati tutte le nozioni apprese ? • Il corso è indirizzato alla progettazione secondo le esigenze del mondo del lavoro • progettare significa risolvere i problemi (problem solving)

11. cosa vede una società da un neolaureato anche brillante • un elemento grezzo da formare • a seconda dei lavori occorrono nell’ordine dei 12 mesi perché un neolaureato sia “operativo” • nei primi 12 mesi il neolaureato non è in grado di fare quasi nulla per l’industria • per rendere operativo un neolaureato, occorre molto addestramento (“training on the job” ) • l’organizzazione cerca di insegnare il problem solving nella fase di addestramento

12. cosa vorrebbe l’industria da un neolaureato • capacità di analizzare e risolvere problemi/lavori complessi e nuovi • capacità di rispettare i vincoli del problema (tempi, costi e risorse disponibili) • capacità di rispettare i vincoli per risolvere il problema (tempi costi e risorse disponibili) • a prescindere dal settore di impiego (software, tlc, gestionale, marketing, ...) • Quindi -> problem solving: • capacità di portare a termine con profitto un lavoro in maniera autonoma

13. Problem solving e capacità di progettare: serve solo nel lavoro? Problema risolto lavoro concluso Lavoro da fare Problema da risolvere Lavoro ben fatto soluzione adeguata Vincoli tempi costi risorse

14. Problem solving: dove ? • creare un sistema tlc • organizzare una vacanza • Aprire un ristorante • produrre un software • creare un nuovo prodotto • organizzare una festa • organizzare una vacanza • lasciare la ragazza? • Il problem solving serve ovunque si presenti un problema/ lavoro: • 1) importante • 2) di complessità non banale

15. Problem solving e progettazione • Ogni volta che dobbiamo risolvere un problema o fare un lavoro importante occorre: • progettare il lavoro/ la soluzione • Progettare significa stabilire: • cosa bisogna fare • Come implementarlo • In che tempi • Con che risorse • Come verificare cosa si è implementato • la capacità di problem solving si acquisisce imparando a progettare

16. La progettazione e il corso • lo scopo del corso è di insegnare a progettare • vi verranno insegnate nel corso le tecniche di progettazione che dovrete applicare a casi concreti • le tecniche di progettazione servono solo nel mondo del lavoro ? • le tecniche di progettazione servono solo nel campo del software TLC ?

17. Fine task ? 100 % % Funzionamento compreso 0 % Tempo Praticone o Progettista ? • Esempio: • Le istruzioni della cinepresa nuova: Leggete le istruzioni o usate subito la cinepresa ?

18. In tempo ? taskda fare Concluso ? Bene ? Problema da risolvere Rispetta i vincoli (costi)? • Tempi rispettati • costi rispettati • funzioni coperte con adeguata qualità taskda fare Concluso !! Problema da risolvere Tecniche di progettazione Task problemi e progettazione

19. Esempio: • Esempio del viaggio • la mia organizzazione della settimana bianca • e io intanto prenoto (esempio rosanna) • “Usa la testa non le gambe”

20. Schema di un problema controlla Cliente fornisce affida Input Output Task vincoli Progetta , pianifica, esegue Le definizioni ? esecutore

21. Definizioni • Task • tutto le operazioni che devo compiere per ottenere l’output • Input • tutto ciò che posso o devo prendere dall’ambiente esterno per portare a termine il task, • informazioni (dati, scadenze, costi, tempi) • risorse (mezzi fisici, persone, soldi) • Vincoli • possono impedire la soluzione del task (vincoli incrociati)

22. Definizioni (output e test) • Output • il risultato del mio lavoro: • informazioni , servizi, mezzi trasformati , documenti, progetti, software ... • Test • metodi implementati da me o dal mondo esterno per verificare che l’output sia adeguato • Cliente • chi mi chiede di: • risolvere un problema • definire delle soluzioni • portare a termine una attività

23. identificazione di input output e task e test • Esercitazione • creare una tabella a 5 colonne : nome del task come di seguito, input , vincoli, descrizione task, output, test) • creazione video gioco software • lavoro di gruppo • progettazione di un telefonino • produzione di un telefonino • organizzazione di un concerto • organizzazione di una vacanza con un gruppo di amici • quale è la differenza fra input e vincolo ?

24. L’Invariante di Input e vincoli • tutti i problemi implicano • tempi di realizzazione (cioè pianificazione controllo) • costi (budget a disposizione) • risorse (umane, materiali) • per affrontare un problema/ progettazione occorre definire sempre chiaramente i tre aspetti

25. Esempio SENIOR PROJECTMANAGER:DescrizioneE' responsabile della stesura, sviluppo e gestione di progetti informatici incentrati sulle applicazioni di Rete per l'interazione Internet, Intranet ed Extranet. In particolare il suo ruolo prevede: • la definizione, con il cliente, del piano di lavoro e delle modalità di collaborazione nell'ambito di system integration; • l'analisi e la valutazione delle diverse componenti del progetto (costi, tempi e risorse); • la gestione del team interno di lavoro e degli eventuali partner; • la verifica dei risultati raggiunti.

26. I dati di input sono esaustivi ? • Se il problema non è banale, i dati di input non sono mai sufficienti per avere un task univoco e una soluzione univoca. • Questo è la causa più frequente di incapacità di portare a termine un task soprattutto in problemi mai affrontati • altra causa di paralisi nel portare a termine un task sono i vincoli incrociati • Come si procede ? Le assunzioni !!

27. Assunzioni • L’assunzione deve essere: • plausibile nel contesto del task • esplicitata (deve essere menzionata da qualche parte) • Le assunzioni sono spesso collegate ai soldi e sono fondamentali per la buona riuscita di un progetto (ref. il registro delle assunzioni) • Le assunzioni servono a • Ridurre il numero di possibilità di design • Semplificare • Limitare e vincolare il task (l’oggetto non farà questo) • Definire delle preferenze (p.es. linguaggio usato) • eliminare i vincoli

28. Esercizio: • identificare le assunzioni dei precedenti casi • creazione video gioco software • progettazione di un telefonino • produzione di un telefonino • organizzazione di un concerto • organizzazione di una vacanza con un gruppo di amici • nel corso vi sono volutamente (come nella realtà) case study con dati di input incompleti o vincoli incrociati • E’ fondamentale che voi identifichiate e tracciate le assunzioni per evitare input incompleti o vincoli incrociati • E’ compito del committente accettare le assunzioni

29. Schema del corso • parte 1 ; le fasi della progettazione • parte 2 : la progettazione strutturata • parte 3: la progettazione a oggetti e classi • parte 4: la progettazione object oriented

30. le fasi della progettazione • Progettare “X” significa stabilire: • 1: Mission (cosa è “X” e purché faccio “X” ) • 2: Analisi (cosa fa “X” ) • 3: Design (come realizzo “X” ) • 4: Implementazione (“X” realizzato) • 5: Test (“X realizzato funziona ? È adeguato ?” : • Rispetta design (è come lo volevo implementare) • Rispetta analisi (fa ciò che avevo progettato di fargli fare) • Rispetta la mission (soddisfa il motivo per cui lo avevo fatto)

31. Capacità acquisite nella prima lezione • dato un problema qualsiasi: • identificare • input • vincoli • output • task • cliente • test • individuare input incompleti/vincoli incrociati • definire assunzioni plausibili individuare i rischi

32. Lezione 2 le fasi della progettazione: la mission, l’analisi

33. In tempo ? taskda fare Concluso ? Bene ? Problema da risolvere Rispetta i vincoli? Lavoro ben fatto soluzione adeguata Concluso !! taskda fare Problema da risolvere Tecniche di progettazione Task problemi e progettazione

34. Perché progettare ? • Progettare è frustrante • All’inizio si raggiungono risultati più lentamente • È una attività impegnativa perché richiede forte uso di attività concettuale invece si tende a prediligere attività celebrale “manuale” • Stanca più velocemente • progettare è vincente • Garantisce il risultato giusto in tempi certi • Il tempo impiegato è molto inferiore rispetto all’approccio da “code and fix”. • “Usa la testa e non le gambe”

35. Perché imparare a progettare • Secondo la letteratura scientifica, un personale ben addestrato può lavorare fino a 25 volte di più rispetto ad un personale non sufficientemente adeguato nell'ambito del software. (Negli altri settori il differenziale di produttività si limita ad un fattore 4 ). • La differenza di prestazioni fra due operatori del software è spesso dovuta ad una differente capacità di progettazione • Riduzione del ciclo di vita del software: come è ripartito fra le varie fasi ?

36. Non progettare nel software e nelle TLC • Non progettare significa: • I tempi per concludere un task possono dilatarsi all’infinito (comune nella codifica del software) • Non si sa mai quando si finisce (per fare il 5% del lavoro occorre il 95 % del tempo ?) • La qualità del prodotto è bassa, richiede normalmente rilavorazioni per correggere errori • Il prodotto può essere gestito solo da chi lo ha creato

37. Fine task ? 100 % % Funzionamento compreso 0 % Tempo Praticone o Progettista ? • Esempio: • Le istruzioni della cinepresa nuova: Leggete le istruzioni o usate subito la cinepresa ?

38. Parte prima: le fasi della progettazione • Progettare “X” significa stabilire: • 1: Mission (cosa è “X” e purché faccio “X” ) • 2: Analisi (cosa fa “X” ) • 3: Design (come realizzo “X” ) • 4: Implementazione (“X” realizzato) • 5: Test (“X realizzato funziona ? È adeguato ?” : • Rispetta design (è come lo volevo implementare) • Rispetta analisi (fa ciò che avevo progettato di fargli fare) • Rispetta la mission (soddisfa il motivo per cui lo avevo fatto) • Case study: la penna

39. Le fasi della progettazione Mission Analisi Design Implement. Test

40. 1: Mission • Indica la meta, la direzione e lo scopo del task che si vuole compiere • È espresso in forma concisa (max 3 righe) • Serve a eliminare i problemi di framework • Esempio di framework (es. la Russia in sede) • E’ un “contratto” con il cliente: • Va concordato con il cliente • È focalizzato sui bisogni del cliente è difficile da individuare è difficile da seguire

41. Lost the mission-> Fired ! • Perdere la mission può far licenziare (esempio) • la mission deve essere sintetica: le mission nelle aziende • IBM At IBM, we strive to lead in the creation, development and manufacture of the industry's most advanced information technologies, including computer systems, software, networking systems, storage devices and microelectronics. And our worldwide network of IBM solutions and services professionals translates these advanced technologies into business value for our customers • Coca cola • The Coca-Cola Company exists to benefit and refresh everyone who is touched by our business. • Esercizio: • trovare alcune mission la Fiat, Xerox, IBM, HP, un teatro

42. Esempi di mission • Il cliente chiede: progettami una penna • Mission: progettare un oggetto in grado di scrivere indelebilmente sulla carta • Quali assunzioni ? • Esercizio definire la mission per • la progettazione di un centralino telefonico per piccole aziende, • la progettazione di gioco per play station, • la progettazione di un video telefono mobile. • Quali assunzioni ?

43. 2: Analisi • Specifica che cosa deve fare il prodotto/servizio indicato nella mission • Deve discendere ed essere coerente con la mission • Esempio di incoerenza fra mission e analisi (la coppia faffi) • E’ una lista di requisiti secondo il punto di vista del cliente utilizzatore • se non si è capaci di fare analisi non si è capaci di codificare il software

44. I requisiti • I requisiti sono un qualcosa desiderato dal cliente espresso in forma di frase testuale • I requisiti dovrebbero essere numerati • I requisiti dovrebbero essere testabili • I requisiti dovrebbero essere univoci,non sovrapponibili, non ambigui • I requisiti dovrebbero coprire completamente i desiderata del cliente • i requisiti sono definiti dall’analista in base alle richieste del cliente, o sono direttamente forniti dal cliente

45. Esempio di requisiti • Le penna: • Mission: progettare una penna per scrivere sulla carta • Requisiti: • La penna dovrà scrivere per almeno un chilometro di carta • La penna dovrà avere un costo di produzione inferiore a 1 € • La penna dovrà avere una impugnatura giudicata comoda per almeno il 70% degli utilizzatori • La penna dovrà scrivere in inchiostro blu o rosso • La penna dovrà funzionare fra 0° e i 40°

46. Validazione dei requisiti • Il cliente dà spesso requisiti ambigui/incompleti • l’analista li trasforma in modo che i requisiti siano: • numerati • testabili • Definire un test per i precedenti requisiti • Non sovrapposti • Coprano completamente i desiderata del cliente

47. Esempio di requisiti non corretti • Dash lava più bianco !: come si testa ? • Requisiti: • La penna dovrà scrivere a lungo • La penna dovrà scrivere per almeno un chilometro di carta • La penna dovrà costare poco • La penna dovrà avere un costo di produzione inferiore a 1 € • La penna dovrà avere una impugnatura adeguata • La penna dovrà scrivere bene

48. Criteri aggiuntivi di validazione dei requisiti • Fattibilità • Siamo in grado di farlo ? • Abbiamo il tempo i soldi le capacità le persone giuste (il caso ATC USA) • Accettabilità • Ci conviene farlo ? • Otteniamo qualcosa di soddisfacente come performance • Vulnerabilità • qualsiasi cosa che può andare male andrà male (Murphy) • Quali sono i rischi / conseguenze delle nostre scelte ? • Essendo pessimisti cosa può andar male e se va male quali sono le conseguenze

49. Gli errori dell’analista • Esempio di errore • esempio della penna e del software () • Errore tipico e grave: • inserire nell’analisi di X come va fatto X (=design) • quali sono le implicazioni di questo errore ? • L’errore ha impatto su costi tempi e risorse ?

50. Gli errori dell’analista 2 • esempio: una società di consulenza invia un ingegnere neolaureato ad un corso approfondito di analisi UML • l’ingegnere fa grande esperienza di analisi • la società di consulenza deve effettuare un lavoro di informatizzazione presso una azienda e decide di inviare l’ingegnere per il lavoro di analisi • quali sono i problemi che incontrerà l’ingegnere ? • 1:esempio • 2:esempio