> For the complete documentation index, see [llms.txt](https://checksound.gitbook.io/tecnologie4/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://checksound.gitbook.io/tecnologie4/master.md). # Software - Problemi e prospettive La disciplina denominata *Software Engineering* è circa i metodi, tools e tecniche utilizzati per sviluppare software. Tipi di software: * *software di sistema*; * *software applicativo*; All'interno del software applicativo, può essere utile identificare le seguenti categorie di software: * giochi; * sistemi informativi; * sistemi real-time; * sistemi embedded; * software di office automation; * software scientifico; La costruzione del software è un compito impegnativo, essenzialmente perché il software è complesso. I problemi percepiti (criticità) e gli scopi da raggiungere nello sviluppo software sono: * raggiungimento delle necessità degli utenti; * basso costo di produzione; * alte performance; * portabilità; * basso costo di mantenimento; * alta affidabilità; * rilascio nei tempi previsti; Ogni scopo è anche considerato un problema perché il software engineering ha avuto generalmente poco successo nel raggiungere questi scopi: Vedremo in seguito come questi scopi sono tra loro collegati. ### Raggiungimento delle necessità dell'utente ![](https://4279938682-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MINf3yVL3iHLmxwgC24%2F-MINiGXotFxqCceqRWGX%2F-MINmyhEXb30Uu8iZkTY%2Feffettivita_sw.PNG?alt=media\&token=4ce3f9ed-de96-47e4-98dc-ce452071ad9d) ### Costi della produzione del software ![Cambiamenti nel costo relativo dell'hardware e software](https://4279938682-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MINf3yVL3iHLmxwgC24%2F-MINiGXotFxqCceqRWGX%2F-MINncjTMa37dp8T45V6%2Fcosto_sf.PNG?alt=media\&token=98b6afd2-612a-4acd-83a9-531774a82d2e) Da cosa è dovuto il costo? E' interessante vedere quali parti dello sviluppo software di un progetto costano di più. Costi relativi delle varie fasi dello sviluppo software: ![Costi delle diverse fasi](https://4279938682-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MINf3yVL3iHLmxwgC24%2F-MINnsj6GliT-e3vEBPu%2F-MIOB-jGmCObcHyFAWlJ%2FCosti_sw_1.PNG?alt=media\&token=46e1cc4c-09af-4207-9c8e-375b62af0695) Si vede che il costo del testing è enorme, mentre il coding costituisce solo una piccola parte del software development. Se gli errori sono il problema maggiore, quando sono fatti? I numeri relativi di errori fatti durante le differenti fasi di sviluppo del software: ![](https://4279938682-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MINf3yVL3iHLmxwgC24%2F-MINnsj6GliT-e3vEBPu%2F-MIOCCynRDRlpLAQp8KY%2FCosti_sw_2.PNG?alt=media\&token=ddb92ab1-83ae-42b1-bd8d-94b22b8998ba) Tuttavia questo dato può essere fuorviante. A noi interessa il costo per correggere l'errore. E più a lungo l'errore rimane scoperto, di più costa correggerlo. Errori fatti durante le prime fasi del progetto tendono essere più costosi, a meno che non siano scoperti quasi subito. Vediamo quindi i costi relativi per correggere i differenti tipi di errore: ![](https://4279938682-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MINf3yVL3iHLmxwgC24%2F-MIOCGcd1bnK_-STD1Oj%2F-MIOCpc4PntyCDH2oDnu%2FCosti_sw_3.PNG?alt=media\&token=7b84cec4-1889-49c8-97e1-d010c105d01e) Un errore di design può non essere scoperto, ipoteticamente, fino alla fase dei test e tutto ciò comporterebbe molto lavoro per correggerlo. Viceversa un errore di sintassi nello sviluppo del codice, può essere subito rivelato dal compilatore e corretto dallo sviluppatore. ### Maintenance La *maintenance* è la parola che indica lo sforzo messo in un componente software dopo che è stato scritto e messo in produzione. E' due tipi principalmente: * *remedial maintenance*, che è il tempo speso per correggere i fault nel codice (attività di bug-fixing) * *adaptive maintenance*, che significa le modifiche fatte perché sono cambiati i requisiti del cliente *Remedial maintenance*, è conseguenza di insufficiente testing. Come vedremo un testing efficace è difficile da eseguire e richiede tempo, così è accettato come normale nel software engineering un'attività di *maintenance* è inevitabile. E' spesso difficile predirre i futuri utilizzi del software, così la *adaptive maintenance* è pratica comune. Si parla spesso del 'fardello della maintenance'. ![](https://4279938682-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MINf3yVL3iHLmxwgC24%2F-MIhHJGbRBV4gDwREF2F%2F-MIhJiQ_X4_Hxb_W7uMm%2Fmainenance.PNG?alt=media\&token=b3c9510f-556f-4d0c-822f-a0a90f277b32) ### Affidabilità Un pezzo di software è detto essere affidabile se esso funziona e continua a funzionare senza crash e senza fare qualcosa di indesiderato. Noi diciamo che il software ha un *bug* o un *fault* se non si comporta correttamente. Si presume che lo sviluppatore sappia cosa era richiesto e così il comportamento non aspettato non è intenzionale. E' comune parlare di bug nel software, ma è inoltre opportuno definire alcuni altri termini più chiaramente: * **errori** - decisioni sbagliate fatte durante lo sviluppo del software; * **fault** - un problema che può causare nel software uno scostamento rispetto al comportamento atteso; * **failure** - un evento generato (conseguenza) di quando il software si discosta dal comportamento desiderato; In questa terminologia, un *fault* è sinonimo di un bug. Le *failure* accadono mentre il sistema è testato o quando, poi, è in utilizzo. Le *failure* sono i sintomi che l'utente sperimenta, mentre i *fault* sono i problemi con cui lo sviluppatore ha a che fare. ### La crisi del software Abbiamo discusso alcuni problemi percepiti con il software: * non fa quello che l'utente si aspetta; * è costoso; * non è sempre sufficientemente veloce; * non può essere trasferito su un altra architettura facilmente; * è costoso da mantenere; * è inaffidabile; * è spesso in ritardo; * non è sempre facile da utilizzare; Di questi, soddisfare le aspettative dell'utente (validazione), la riduzione del costo del software, migliorare l'affidabilità (verification) e rilascio in tempo, sono probabilmente i quattro problemi al momento più importanti. Uno degli ostacoli per cercare di risolvere i problemi sul software e che questi ultimi molto spesso sono in conflitto tra loro. Per esempio, il prezzo basso per l'opera e l'alta affidabilità confliggono. Ancora, alte prestazioni e portabilità sono in conflitto. ![Obiettivi complementari e in conflitto in un progetto software](https://4279938682-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MINf3yVL3iHLmxwgC24%2F-MIj19zsA7bzXDM-XsDo%2F-MIj4u7k3aidUglrBYKX%2Fcomplementary_conflicting.PNG?alt=media\&token=2172aed7-fe81-4145-9e77-8aed27824b42) ### Un rimedio - l'ingegneria del software? Come abbiamo visto, è riconosciuto che c'è un grande problema nello sviluppo del software in modo da avere successo. Un certo numero di idee è stato suggerito per migliorare questa situazione. Questi metodi e tool (strumenti) sono conosciuti come software engineering (ingegneria del software). Alcune delle principali idee sono: * maggiore sforzo nel portare avanti tutte le fasi dello sviluppo in modo sistematico; * assistenza di strumenti nello sviluppo software - tools; * un'enfasi a trovare cosa esattamente l'utente del sistema realmente vuole (requirements engineering - validation - validazione); * dimostrazione al cliente di prime versioni del prodotto (prototyping - creazione di prototipi); * utilizzo di nuovi e moderni linguaggi di programmazione; * grande sforzo nel tentativo di garantire che il software è immune da errori (verification - verifica); * sviluppo incrementale, dove il progetto procede in piccoli gestibili step;