2 Introduzione all'Ingegnera del So.txt

2 Introduzione all'Ingegnera del Software (Lezione del 30/09/2021) 2.1 Cos'e un software? Sono programmi per computer che hanno documentazione associata (ad es. requisiti, modelli di progettazione e manuali utente). Un software puo essere: generico: sviluppato per essere venduto a una gamma...

2 Introduzione all'Ingegnera del Software (Lezione del 30/09/2021) 2.1 Cos'e un software? Sono programmi per computer che hanno documentazione associata (ad es. requisiti, modelli di progettazione e manuali utente). Un software puo essere: generico: sviluppato per essere venduto a una gamma di clienti diversi, ad es. Software per PC come Excel o Word; specico (personalizzato): sviluppato per un singolo cliente secondo le sue speciche. Un nuovo software puo essere creato dallo sviluppo di nuovi programmi, dalla congurazione di software generici e dal riutilizzo di software esistenti. 2.2 Cos'e l'Ingegneria del Software? E una disciplina ingegneristica che si occupa di tutti gli aspetti della produzione di software. Gli ingegneri del Software dovrebbero adottare un approccio sistematico e organizzato al loro lavoro e utilizzare strumenti e tecniche appropriate a seconda del problema da risolvere, dei vincoli di sviluppo e delle risorse disponibili. 2.3 Qual e la di erenza tra Ingegneria del Software e Informatica? L'informatica si occupa di teoria e fondamenti mentre l'Ingegneria del Software si occupa degli aspetti pratici dello sviluppo e della fornitura di software utili ed economici. 2.4 Qual e la di erenza tra Ingegneria del Software e Ingegneria dei Sistemi? L'Ingegneria dei Sistemi si occupa di tutti gli aspetti dello sviluppo di sistemi basati su computer: hardware, software e ingegneria di processo. L'Ingegneria del Software fa parte di questo processo per quanto riguarda l'infrastruttura software, il controllo, le applicazioni e i database nel sistema. Gli ingegneri di sistema sono coinvolti nelle speciche del sistema, nella progettazione architet- tonica, nell'integrazione e nella distribuzione. 2.5 Cos'e lo processo software? E un insieme di attivita il cui obiettivo e lo sviluppo o l'evoluzione del software. Le attivita generiche in tutti i processi software sono: speciche: cosa dovrebbe fare il sistema e i suoi vincoli di sviluppo; sviluppo: produzione del sistema software; convalida: verica che il software sia cio che il cliente desidera; evoluzione: cambiare il software in risposta alle mutevoli esigenze. 2.6 Che cos'e un modello del processo software? E una rappresentazione semplicata di un processo software, presentata da una prospettiva speci-ca. Esempi di prospettive di processo sono: Prospettiva del usso di lavoro, sequenza di attivita; Prospettiva del usso di dati, usso di informazioni; Prospettiva di ruolo/azione, chi fa cosa. Esistono alcuni modelli di processo generici come il modello a cascata, lo sviluppo iterativo e l'ingegneria del software basata su componenti. 2.7 Quali sono i costi dell'Ingegneria del Software? All'incirca il 60% per i costi di sviluppo, 40% per i costi di test. Per i software personalizzati, i costi di evoluzione spesso superano i costi di sviluppo. I costi variano in base al il tipo di sistema che si sta sviluppando e alle prestazioni e adabilita del sistema. La distribuzione dei costi dipende dal modello di sviluppo utilizzato. 2.8 Quali sono i metodi dell'Ingegneria del Software? Sono approcci strutturati allo sviluppo del software come per esempio: descrizioni e notazioni dei modelli, descrizioni dei modelli graci che dovrebbero essere prodotti; regole, vincoli applicati ai modelli di sistema; raccomandazioni, consigli sulle buone pratiche di progettazione; guida al processo, quali attivita seguire. 2.9 Che cos'e CASE (Computer-Aided Software Engineering) Sono sistemi software destinati a fornire supporto automatizzato per le attivita dei processi soft- ware. I sistemi CASE sono spesso utilizzati per il supporto del metodo come per esempio: Upper-CASE, strumenti a supporto delle prime attivita di processo dei requisiti e della progettazione; Lower-CASE, strumenti per supportare attivita successive come programmazione, debug e test. 2.10 Quali sono le caratteristiche di un buon software? Il software deve fornire all'utente le funzionalita e le prestazioni richieste e deve essere manutenibile, adabile e accettabile: manutenibilita: il software deve evolversi per soddisfare le mutevoli esigenze; adabilita: il software deve essere adabile; ecienza: il software non dovrebbe fare un uso dispendioso delle risorse di sistema; accettabilita: il software deve essere accettato dagli utenti per i quali e stato progettato. Cio signica che deve essere comprensibile, utilizzabile e compatibile con altri sistemi. 2.11 Quali sono le principali sde che l'Ingegneria del Software deve a rontare? eterogeneita: sviluppo di tecniche per la creazione di software in grado di far fronte a piattaforme e ambienti di esecuzione eterogenei; consegna: sviluppo di tecniche che portano a una consegna piu rapida del software; ducia: sviluppo di tecniche che dimostrino che il software puo essere considerato adabile dai suoi utenti. 2.12 Responsabilita professionale ed etica L'ingegneria del software e piu che l'applicazione di competenze tecniche. Gli ingegneri devono comportarsi in modo onesto ed eticamente responsabile. Il comportamento etico e piu che sem- plicemente rispettare la legge. Abbiamo vari problemi legati alla responsabilita professionale come: riservatezza: gli ingegneri dovrebbero normalmente rispettare la riservatezza dei loro datori di lavoro o clienti, indipendentemente dal fatto che sia stato rmato o meno un accordo formale di riservatezza. competenza: gli ingegneri non dovrebbero travisare il loro livello di competenza. Non dovrebbero accettare consapevolmente un lavoro che e al di fuori delle loro competenze. diritti di proprieta intellettuale: essere a conoscenza delle leggi locali sulla proprieta intellettuale come brevetti, copyright, ecc. e fare attenzione a garantire che la proprieta intellettuale di datori di lavoro e clienti sia protetta; uso improprio del computer: l'Ingegnere non dovrebbe utilizzare le proprie competenze tecniche per abusare dei computer di altre persone. 2.13 Codice Etico ACM/IEEE Le societa professionali negli Stati Uniti hanno collaborato per produrre un codice di pratica etica. Questo codice contiene otto principi relativi al comportamento e alle decisioni e riguarda professionisti, educatori, manager, supervisori e responsabili politici, nonche tirocinanti e studenti della professione. 2.14 Dilemmi etici Alcuni esempi di dilemmi etici: disaccordo in linea di principio con le politiche dell'alta dirigenza; il tuo datore di lavoro agisce in modo non etico e rilascia un sistema critico per la sicurezza senza aver terminato il test del sistema; partecipazione allo sviluppo di sistemi d'arma militari o sistemi nucleari. 3 Processi software (Lezione del 30/09/2021) E un insieme strutturato di attivita necessarie per sviluppare un sistema software che riguardano speciche, design, validazione ed evoluzione. Un modello di processo software e una rappresentazione astratta di un processo. Presenta una descrizione di un processo da una prospettiva particolare. 3.1 Modelli di processo software generici Modello a cascata: fasi separate e distinte di specica e sviluppo; Sviluppo evolutivo: le speciche, lo sviluppo e la convalida sono intercalati; Ingegneria del Software basata sui componenti: il sistema e assemblato da componenti esistenti. Esistono molte varianti di questi modelli, ad es. sviluppo formale in cui viene utilizzato un processo a cascata ma la specica e una specica formale che viene ranata attraverso diverse fasi no a un design implementabile. 3.1.1 Modello a cascata Le fasi del modello a cascata sono: analisi e denizione dei requisiti; progettazione di sistemi e software; implementazione e test di unita; integrazione e test del sistema; funzionamento e manutenzione. Il principale svantaggio e la dicolta di accogliere il cambiamento dopo che il processo e in corso: una fase deve essere completata prima di passare alla fase successiva. I problemi di questo modello: la suddivisione in essibile del progetto in fasi distinte rende dicile rispondere alle mutevoli esigenze dei clienti; e appropriato solo quando i requisiti sono ben compresi e le modiche saranno abbastanza limitate durante il processo di progettazione. pochi sistemi aziendali hanno requisiti stabili; il modello a cascata viene utilizzato principalmente per grandi progetti di ingegneria dei sistemi in cui un sistema viene sviluppato in diversi siti. 3.1.2 Sviluppo evolutivo Sviluppo esplorativo: l'obiettivo e lavorare con i clienti e sviluppare un sistema nale partendo da una specica iniziale. Inizia con requisiti ben compresi e aggiungi nuove fun- zionalita come proposto dal cliente; Prototipazione usa e getta: l'obiettivo e comprendere i requisiti di sistema. Dovrebbe iniziare con requisiti poco compresi per chiarire cosa e veramente necessario. I principali problemi di questo modello sono: mancanza di visibilita del processo; i sistemi sono spesso poco strutturati; potrebbero essere richieste competenze speciali (ad esempio nelle lingue per la prototipazione rapida). Viene applicato per: per sistemi interattivi di piccole o medie dimensioni; per parti di sistemi di grandi dimensioni (es. l'interfaccia utente); per sistemi di breve durata. 3.1.3 Ingegneria del Software basata sui componenti Basato sul riutilizzo sistematico in cui i sistemi sono integrati da componenti esistenti o sistemi COTS (Commercial-o -the-shelf). Le fasi del processo sono: analisi dei componenti; modica dei requisiti; progettazione del sistema con riutilizzo; sviluppo e integrazione. Questo approccio sta diventando sempre piu utilizzato man mano che sono emersi gli standard dei componenti. 3.2 Iterazione del processo I requisiti di sistema si evolvono SEMPRE nel corso di un progetto. L'iterazione puo essere applicata a qualsiasi modello di processo generico. Due approcci (correlati): consegna incrementale e sviluppo a spirale. 3.3 Sviluppo a spirale Il processo e rappresentato come una spirale piuttosto che come una sequenza di attivita con backtracking. Ciascun ciclo della spirale rappresenta una fase del processo. Nessuna fase ssa come specica o progettazione: i loop nella spirale vengono scelti in base a cio che e richiesto. I rischi sono esplicitamente valutati e risolti durante tutto il processo. 3.4 Sviluppo incrementale Lo sviluppo e la consegna sono suddivisi in incrementi: ogni incremento fornisce parte della fun- zionalita richiesta. I requisiti degli utenti hanno la priorita e i requisiti con priorita piu alta sono inclusi nei primi incrementi. Una volta avviato lo sviluppo di un incremento, i requisiti vengono congelati anche se i requisiti per gli incrementi successivi possono continuare a evolversi. I vantaggi di questo modello sono: il valore del cliente puo essere fornito con ogni incremento in modo che la funzionalita del sistema sia disponibile prima; i primi incrementi fungono da prototipo per aiutare a sollecitare i requisiti per gli incrementi successivi; minor rischio di fallimento complessivo del progetto; i servizi di sistema con la priorita piu alta tendono a ricevere il maggior numero di test. 3.5 Attivita di processo 3.5.1 Speciche del software E il processo per stabilire quali servizi sono richiesti dei vincoli al funzionamento e allo sviluppo del sistema. Il processo di ingegneria dei requisiti e composto da: studio di fattibilita; elicitazione e analisi dei requisiti; specica dei requisiti; convalida dei requisiti. 3.5.2 Progettazione e implementazione del software E il processo di conversione delle speciche di sistema in un sistema eseguibile. Con questo processo, si deve progettare una struttura software che realizzi la specica e tradurre questa struttura in un programma eseguibile. Le attivita di progettazione e realizzazione sono strettamente correlate e possono essere inter- connesse. Le attivita del processo di progettazione: progettazione architettonica; specica astratta; progettazione dell'interfaccia; progettazione dei componenti; progettazione della struttura dei dati; progettazione di algoritmi; 3.5.3 Convalida del software La verica e la convalida hanno lo scopo di dimostrare che un sistema e conforme alle sue speciche e soddisfa i requisiti del cliente del sistema. Implica il controllo e la revisione dei processi e dei test di sistema. Il test del sistema implica l'esecuzione del sistema con casi di test derivati dalla specica dei dati reali che devono essere elaborati dal sistema. 3.5.4 Evoluzione del software Il software e intrinsecamente essibile e puo cambiare. I requisiti cambiano e il software deve evolversi e cambiare. Sebbene vi sia stata una demarcazione tra sviluppo ed evoluzione (manutenzione), cio e sempre piu irrilevante poiche sempre meno sistemi sono completamente nuovi. 3.6 Metodi strutturati Sono approcci sistematici allo sviluppo di un software design. Il progetto e solitamente documen- tato come un insieme di modelli graci. I modelli possibili sono: modello a oggetti; modello di sequenza; modello di transizione di stato; modello strutturale; modello a usso di dati. 3.7 Fasi di test Test di componenti o unita: i singoli componenti vengono testati in modo indipendente oppure possono essere funzioni o oggetti o raggruppamenti coerenti di queste entita; Test del sistema: test del sistema nel suo complesso. La verica delle proprieta emergenti e particolarmente importante; Test di accettazione: test con i dati del cliente per vericare che il sistema soddis le esigenze del cliente. 3.8 Computer-aided software engineering (CASE) CASE e un software per supportare i processi di sviluppo e di evoluzione del software. Si occupa dell'automazione delle attivita come: editor graci per lo sviluppo di modelli di sistema; dizionario dati per la gestione delle entita progettuali; generatore di interfaccia utente graca per la costruzione dell'interfaccia utente; debugger per supportare la ricerca dei guasti del programma; traduttori automatici per generare nuove versioni di un programma. 3.9 Integrazioni CASE Tools: supporta le singole attivita di processo come il controllo della coerenza del design, la modica del testo, ecc; Workbenches: supporta una fase di processo come la specica o la progettazione, normal- mente include una serie di strumenti integrati; Ambienti: supporta tutto o una parte sostanziale di un intero processo software. Normal- mente includono diversi banchi di lavoro integrati.