Estratto del documento

Ingegneria del software

Matilde Simonini Ingegneria informatica anno 2022/2023

Dell’Informatica che si occupa di sistemi sw:

  • È un settore di dimensioni e complessità elevate, intese come complessità dei problemi che vengono risolti e come struttura interna dell’applicazione.
  • Realizzati da squadre.
  • Disponibili in più versioni, dove ogni versione è generalmente orientata ad una diversa categoria di utenti. Le versioni devono evolvere nel tempo.
  • Di lunga durata.
  • Destinati a sottostare a cambiamenti ↓

Implica una programmazione in grande ma ingegneria del sw ≠ programmazione → una parte dell’ingegneria dei sistemi. Consiste di molte altre attività in aggiunta alla programmazione. La programmazione è una delle basi dell’ingegneria del sw.

Fase pionieristica

Fase pionieristica, anni ’40.

I primi albori risalgono agli anni ’40 del secolo scorso, quando sono nati i primi calcolatori, che erano dedicati ad un singolo problema. Possono essere intesi come dedicati all’esecuzione di un singolo programma.

Successivamente nasce l’esigenza di programmare il calcolatore. → calcolatore = strumento per l’esecuzione di operazioni numeriche che difficilmente potrebbero essere eseguite manualmente con la precisione richiesta.

Le prime applicazioni = automazione di procedimenti di calcolo.

Curiosità: al giorno d’oggi utilizziamo ancora il termine computer perché quando ancora non esistevano i computer come li intendiamo oggi, i calcoli complessi venivano fatti da persone, denominate computer, che avevano quello specifico compito / lavoro.

I primi programmatori, erano in realtà degli scienziati, che usavano il calcolatore scrivevano in linguaggi / strumenti di basso livello, di astrazione.

Si pensi che fino alla metà degli anni ’80 si utilizzavano le schede perforate: sulla tastiera, collegata alla macchina perforatrice, veniva scritto tutto ciò che si doveva dare in ingresso al calcolatore.

Nei primi anni dopo la guerra, spesso, gli sviluppatori del sw coincidevano con utente del sw stesso.

Le applicazioni avevano vita breve.

Dal calcolo alla elaborazione dati

Dal calcolo alla elaborazione dati →

  • Avvento di applicazioni di natura gestionale: calcolatore = macchina per creare, mantenere, modificare, distribuire informazione.
  • Distinzione tra sviluppatori e utenti →
  • Esigenza di una professionalità specifica: nascono EDP, Electronic Data Processing, e sw house.
  • Dall’arte, lavoro individuale creativo, all’artigianato, lavoro di piccoli gruppi specializzati.
  • Aumento della criticità e della complessità delle applicazioni.
  • Automazione di settori non tradizionali.

Già negli anni ’50 si inizia a intuire la capacità del calcolatore che smette di essere visto come una macchina in grado di fare esclusivamente calcoli → si comprende che il calcolatore è in grado di archiviare informazioni e di trattare dei dati, non necessariamente numerici.

Data la nuova visione del calcolatore diventa indispensabile una nuova figura specifica, ossia quella dello sviluppatore di software.

Aumentano anche i settori lavorativi in cui viene richiesto l’uso di applicazioni software.

Si ha l’avvento dei linguaggi di alto livello alla fine degli anni ’50.

1 Matilde Simonini Ingegneria informatica anno 2022/2023

Fase industriale

Fase industriale, seconda metà anni ’60.

L’attività di sviluppo e manutenzione del sw coinvolge gruppi di lavoro, anche di grosse dimensioni, il cui lavoro deve essere pianificato e coordinato → nascono esigenze di natura manageriale.

L’attività di progettazione del sw deve essere sempre meno sviluppata manualmente e informalmente e deve essere sempre più supportata da strumenti automatici.

Negli anni ’60 si inizia a concepire il sw come un prodotto industriale.

Lo sviluppo deve seguire metodologie efficaci e deve aderire a standard di produzione che rendano la stessa insensibile al ricambio di personale. → Nuove applicazioni devono potere essere ottenute anche assemblando componenti standardizzati già sviluppati.

L’assemblaggio / catena di montaggio è un fattore tipico del settore industriale, per i quali si compone un prodotto nuovo mettendo insieme elementi già esistenti.

Per poter competere sul mercato sono necessari:

  • Produttività → nell’ambito della produzione del software è complicato definire la produttività.
  • Qualità, deve essere certificata.

La crisi del sw

I grandi progetti sw sono affetti da una incapacità cronica di rispettare i vincoli relativi a scadenze e budget.

Negli anni ’60 non venivano mai rispettate le scadenze perché non si era in grado di prevedere con precisione i tempi di lavorazione, e neanche i budget.

La domanda di sw, in questo periodo, è largamente insoddisfatta: vi sono ritardi fra il momento in cui sorge la richiesta di un’applicazione e il momento in cui la richiesta inizia a essere soddisfatta.

Le cause sono:

  • Immaturità rispetto alle altre discipline ingegneristiche. Es. ingegneria civile: metodologie assestate che consentono una descrizione precisa e rigorosa dell’artefatto da progettare, modelli a diverso livello di astrazione, produzione di disegni dettagliati in base ai quali il sistema sarà realizzato, collaudo finale allo scopo di fornire una certificazione.
  • Carenza numerica di personale specializzato.
  • Grande quantità di addetti impiegati nella manutenzione.

Gorgo del sw: carenza di personale specializzato → uso di personale impreparato/inesperto → produzione di sw di cattiva qualità → grande sforzo di manutenzione richiesto → impiego di una grande quantità di personale → carenza di personale.

Il rapporto costo sw / costo hw è crescente e le cause sono date da:

  • La produzione di sw è scarsamente automatizzabile, attività brain-intensive = richiede un largo apporto intellettuale individuale, a differenza della produzione di hw, che è largamente automatizzata, calo dei costi per hw.
  • Complessità delle applicazioni richieste.

Si parla spesso di quella che viene definita ‘crisi del sw’, che però è solo apparentemente una crisi. Si tratta invece del fatto ben noto che numerosi prodotti sw in uso, che non sono stati progettati da ingegneri qualificati, siano di qualità più o meno scadente.

Certo, questo sw è difficile da modificare ed è tecnicamente mal documentato. La dipendenza del funzionamento del sw dalla presenza di chi lo ha sviluppato è talmente grande che in molti casi lo si può considerare come il prodotto di un’attività amatoriale, certamente non come un lavoro professionale e tanto meno come esempio di tecnica e capacità ingegneristica. (W. Zuser, S. Biffl, T. Grechenig, M. Köhle, 2001).

Quando un programma sw ha successo, ovvero quando risponde alle esigenze delle persone che lo usano, si comporta senza problemi in un lungo arco di tempo, è facile da modificare e ancora più facile da utilizzare, cambia in meglio la nostra vita.

Quando il sw fallisce gli obiettivi, ovvero quando gli utenti sono insoddisfatti, quando il sw è soggetto a errori, quando è difficile da modificare e ancora più difficile da utilizzare, si verificano varie situazioni negative.

Tutti noi vogliamo realizzare del sw che cambi in meglio il mondo, evitando tutto ciò che accade quando non si riesce a ottenere un buon risultato. Per ottenere ciò è necessario introdurre disciplina nella progettazione e nella realizzazione del sw. Questo è il motivo per cui è necessario un approccio ingegneristico. (Pressman, 2004).

2 Matilde Simonini Ingegneria informatica anno 2022/2023

In realtà si è parlato di crisi del software per diversi decenni oltre gli anni ’60.

Nasce una nuova disciplina

In una conferenza NATO tenuta a Garmisch nel 1968 viene coniato il termine “Ingegneria del Software” a testimoniare l’esigenza di una disciplina ingegneristica, basata su solide basi teoriche e metodologiche che permettano la progettazione, produzione e manutenzione di applicazioni che forniscano caratteristiche di qualità prefissate mediante l’uso delle risorse previste.

L’oggetto non è la computazione e la teoria sottostante ma piuttosto l’uso dell’informatica per risolvere dei problemi, chimico vs. ing. chimico.

Programmi sw = prodotti industriali di supporto ad altri settori produttivi.

Ciclo del software = parabola vitale del sw. Tutte le fasi del ciclo vengono disciplinate grazie all’Ingegneria del sw.

IEEE Standard 610.12-1990 - Definizione di Ingegneria del Software

a) Applicazione di un approccio sistematico, disciplinato e misurabile allo sviluppo, esercizio e manutenzione del software; cioè applicazione dell’ingegneria al sw;

b) Studio di strategie di supporto al punto precedente.

Parnas 1978 - Definizione di Ingegneria del Software

Costruzione da parte di più persone di software disponibile in più versioni.

Relazione tra Software Engineering e Computer Science

Relazione tra Software Engineering e Computer Science.

Relazioni tra: Software Engineering e altre discipline.

  • Software Engineering e Computer Science.
  • Ingegneria gestionale.
  • Linguaggi di programmazione.
  • Ingegneria dei sistemi.
  • Sistemi operativi.
  • Basi di dati.
  • Intelligenza artificiale.
  • Informatica teorica.

Caratteristiche esclusive del sw

Caratteristiche esclusive del sw: innanzi tutto, non obbedisce alle leggi della natura: è immateriale, intangibile, non pesa, non si logora con l’uso.

  • Malleabilità apparente, sembra facile modificare il sw ma non è facile operare modifiche al fine di ottenere un certo comportamento desiderato.
  • Immaterialità → solo progettazione.
  • Intangibilità, difficoltà di descrizione e valutazione.
  • Assenza del processo di assemblaggio.
  • 3 Matilde Simonini Ingegneria informatica anno 2022/2023.
  • Evoluzione tecnologica rapidissima.

Processo produttivo del sw, = ciclo di vita: dove termina lo sviluppo di una applicazione e dove inizia la sua evoluzione?

Approccio ingegneristico alla produzione del sw

Mira a garantire alti livelli di controllo sulla qualità grazie a un processo formale che descrive le varie fasi che vanno seguite nello sviluppo del sw.

Molte persone lavorano allo stesso progetto; quindi, la documentazione è importante, vedi progetti dell’ingegneria civile: “disegno” di alto livello e di dettaglio.

La fase iniziale di raccolta dei requisiti del cliente prevede che siano esibiti diagrammi, prototipi e documenti tali da garantire che ciò che si svilupperà è effettivamente ciò che vuole il cliente.

L’approccio ingegneristico è caratterizzato dalla centralità della progettazione e risulta fondamentale la componente intellettuale creativa.

Il testing del prodotto segue un processo ben formalizzato, in cui i requisiti iniziali del cliente sono riesaminati per verificarne la corretta implementazione.

L’ingegnere del sw

Alle diverse fasi corrispondono figure professionali diverse, suddivisione di competenze e ruoli; nei piccoli progetti 2 o 3 persone coprono tutti i ruoli:

  • Analista.
  • Progettista.
  • Programmatore.
  • Ingegnere del testing.
  • Istruttore, mostra agli utenti come usare il sistema.
  • Gruppo manutenzione, include analisti, progettisti, …
  • Gruppo controllo qualità.
  • Librarian, redattore di documenti usati durante la vita del sistema, ad es. specifiche dei requisiti, descrizioni di progetto, documentazione di programma, manuali di addestramento, ecc.
  • Squadra di gestione delle configurazioni, documenta le corrispondenze fra requisiti, progetto, implementazione e test, ad es. per poter dire ai manutentori quale funzione modificare se è richiesto un cambiamento nei requisiti, ecc.; inoltre coordina le diverse versioni di un sistema.

Configurazione software = insieme di documenti che descrive una versione del sistema sw e le relazioni di tracciabilità fra i file stessi. Mantenere tutte queste relazioni è fondamentale nel momento in cui si deve modificare il sw.

Nel momento in cui si effettua la modifica vengono modificate le relazioni di tracciabilità tra i file che descrivono il sw e che sono mantenuti da un tool di configurazione sw.

Ogni versione ha una configurazione e le descrizioni relative a ciascuna versione si intersecano: diverse versioni possono avere in comune molti file.

4 Matilde Simonini Ingegneria informatica anno 2022/2023

La qualità è relativa: non si può parlare in termini assoluti di qualità → dipende dall’osservatore che la giudica.

Qualità del sw: una duplice classificazione

Il nocciolo dell’ingegneria del software è l’attenzione alla qualità. (Pressman, 2004)

Primo criterio:

  • Qualità di prodotto.
  • Qualità di processo, influenza quella di prodotto.

Secondo criterio:

  • Qualità esterne: percepibili da un osservatore esterno che esamina una black-box, sono quelle di interesse per SE → prospettiva utente.
  • Qualità interne: percepibili esaminando la struttura interna di una white-box, sono quelle che permettono di realizzare le qualità esterne → prospettiva del ricercatore.

Fattori di qualità

Fattori di qualità, 16.

Di prodotto:

  • Correttezza.
  • Affidabilità.
  • Robustezza.
  • Sicurezza.
  • Innocuità.
  • Prestazioni.
  • Usabilità.
  • Portabilità.
  • Interoperabilità.

Sia di prodotto sia di processo:

  • Verificabilità.
  • Manutenibilità.
  • Riusabilità.
  • Comprensibilità.

Di processo:

  • Produttività.
  • Visibilità.
  • Tempestività.

Correttezza

Il sw è corretto se soddisfa le specifiche dei requisiti funzionali, caratteristica oggettiva. A priori, prima di iniziare lo sviluppo, devono essere stabiliti i requisiti funzionali, che non sono gli unici da rispettare.

È sufficiente anche un solo episodio in cui non vengono rispettati alcuni requisiti affinché si possa dire che l’applicazione non sia corretta.

Se tali specifiche sono formali, la correttezza può essere provata formalmente, mediante una dimostrazione di teorema, dal momento che i programmi sono oggetti formali, oppure smentita mediante controesempi, attività di testing.

A ogni forma sintattica si ha una forma semantica, ossia l’effetto.

Generalmente i requisiti vengono espressi in maniera informale.

La correttezza viene verificata attraverso l’attività di testing: si sottopone l’applicazione a prove di esecuzione.

Limiti:

È una qualità assoluta e sì/no, non esiste alcun concetto di “grado di correttezza” né di gravità dell’infrazione se le specifiche fossero sbagliate, magari a causa di requisiti inattendibili o di errori nella conoscenza di dominio.

Questa proprietà non consente di esprimere un rigoroso giudizio con un elevato grado di sicurezza.

→ Ci si chiede quanto è importante la correttezza dell’applicazione: è importante dal momento in cui i requisiti rispecchino effettivamente le richieste/aspettative/esigenze degli utenti.

Spesso i requisiti non rappresentano le vere esigenze dell’utente. Colui che si occupa di raccogliere le richieste è l’analista, il quale può fraintendere.

È fondamentale esprimere e descrivere bene i requisiti fondamentali: se tale lavoro non viene svolto correttamente si può giungere al fallimento del progetto.

Affidabilità

Informalmente significa che l’utente si può fidare del prodotto sw in questione.

Si tratta di una caratteristica valutata dagli utenti.

I risultati delle elaborazioni, le uscite, sono quelli voluti o presentano disturbi tollerabili, concetto soggettivo e variabile da sistema a sistema.

Tale giudizio dipende da chi lo esprime e dal dominio nel quale viene espresso.

5 Matilde Simonini Ingegneria informatica anno 2022/2023

Poiché si vuole oggettivare anche questo giudizio, come tutti gli altri, è stata formulato in maniera matematica.

Matematicamente è definibile come la “probabilità di assenza di malfunzionamenti nell’unità di tempo”.

Un esempio di malfunzionamento grave è la corruzione di un file.

Correttezza ⇒ affidabilità.

Il viceversa non è sempre vero.

Robustezza, sicurezza, innocuità e prestazioni

Il prodotto sw si comporta in modo ragionevole anche in circostanze non previste dai requisiti, valori d’ingresso non validi, malfunzionamenti hw, ecc.

Come si deve comportare se riceve degli ingressi che non appartengono al dominio di ingresso? A seconda del dominio è possibile affermare il comportamento desiderato in corrispondenza di certi ingressi.

Capacità del sistema sw in esecuzione di impedire l’accesso a informazioni private.

→ Assenza di pericolosità, o tollerabilità della pericolosità, dell’elaborazione.

→ Capacità di operare senza malfunzionamenti catastrofici.

Tempi di elaborazione, occupazione di memoria, traffico in rete.

Dipendono da un uso efficiente delle risorse, memoria, tempo di elaborazione, canali di comunicazione.

Influenzano l’usabilità e la “scalabilità” di un’applicazione, una soluzione che funziona su una LAN magari non funziona su una WAN.

Possono essere verificate mediante:

  • Analisi di complessità, insegnamento di “Algoritmi e Strutture Dati”.
  • Misure durante esecuzioni-campione.
  • Simulazione di un modello.
  • Analisi di un modello, es. analisi probabilistica secondo la teoria delle code.

Usabilità

Intuitività, naturalezza ed ergonomicità dell’interazione col sistema sw dal punto di vista delle diverse categorie di utenti dello stesso, espressione vecchia

Anteprima
Vedrai una selezione di 20 pagine su 96
Appunti di Ingegneria del software Pag. 1 Appunti di Ingegneria del software Pag. 2
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 6
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 11
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 16
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 21
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 26
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 31
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 36
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 41
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 46
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 51
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 56
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 61
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 66
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 71
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 76
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 81
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 86
Anteprima di 20 pagg. su 96.
Scarica il documento per vederlo tutto.
Appunti di Ingegneria del software Pag. 91
1 su 96
D/illustrazione/soddisfatti o rimborsati
Acquista con carta o PayPal
Scarica i documenti tutte le volte che vuoi
Dettagli
SSD
Ingegneria industriale e dell'informazione ING-INF/03 Telecomunicazioni

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher matilde simonini di informazioni apprese con la frequenza delle lezioni di ingegneria del software e base di dati e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Brescia o del prof Zanella Marina.
Appunti correlati Invia appunti e guadagna

Domande e risposte

Hai bisogno di aiuto?
Chiedi alla community