Schemi sistemi software

CICLO DI VITA: 3 STADI, 6 FASI

• PRODUZIONE = SVILUPPO + MANUTENZIONE (Stadio 2)

(Stadio 1)

6 Fasi Requisiti, Specifiche, Pianificazione, Progetto, Codifica, Integrazione

. DISMISSIONE (Stadio 3)

TESTING = Attività svolta durante l'intero sviluppo

• VERIFICA = Alla fine di ogni fase e all'avvio
• VALIDAZIONE = Alla fine dello sviluppo e il prodotto che esegue

DRE (Defect Removal Efficiency) = Percentuale di difetti trovati prima dei rilasci (N^2 / T )

COSTO

SIZE = Il codice pas^2 alla size in quadrato C = As^2E' meglio fare 2 prodotti di S/2 che uno di S.

REPUBBLICHE = Costo nullo

AMPIEZZA DI MERCATO

1. A parità di ampiezza, il costo per vendere un prod. di size doppia è di molte superiore
2. A parità di costo si richiede un mercato di ampiezza 2 volte maggiore

PRODOTTO SW = Codice + documentazione

ARTEFATTO = Prodotto SW intermedio

CODICE = Prodotto SW finale

SISTEMA SW = Insieme di prodotti SW

CLIENTE = Soggetto che ordina e paga il prodotto SW

SVILUPPATORE = Fornitore che produce il software

UTENTE = Soggetto che lo usa

SW INTERNO = Cliente e sviluppatore coincidenti

SW A CONTRATTO = " " " non "

Affidabilità

Probabilità che il SW lavori correttamente in un determinato intervallo temporale.

• Difetto = Anomalia presente vuoi SW.
• Guasto = Comportamento anomalo dovuto a un difetto.
• Errore = Azione di chi introduce un difetto.

Il miglioramento dell'affidabilità dipende dalla localizzazione del difetto, cioè se appartiene al nucleo.

• Software:
  • I guasti sono conuna aperta.
  • SW sì codissnia.
  • Continuare a guastarla a qualcosa compromessa e di tutto quello che si cercatina.
  • Deg corregiloni.
• Hardware:
  • Individuali.
  • I guasti sono quasi sempre dovuti a consumi/deperussimasto dei conditimenti.

Dopo (Ripararala) la sub affebilalila non aumentare il coordinamento.

Obiettivo: Crescint dell affidabililá.

Disponibilità

è bel tempo che il SW è risultato usabile nel corso della sua vita.

Processo Software

Serie di attività necessarie alla realizzazione del prodotto SW nei tempi, con costi e con le desiderate caratteristiche di qualità.

Fasi del Processo:

• Sviluppo (I Stadio)
  • 1) Definizione → Prequisiti e specifiche.
  • 2) Produzione → Progetti codifica linellee ruiscia il cliente.
• Manutenzione (II Stadio) → Può essere di vario tipo
  • Correttivo → Per eliminare i difetti.
  • Adattiva → Per adattare il SW ad eventuali cambiamenti.
  • Perfettiva → Per aggiungere funzionalità.
  • Preventiva → Per rendere più semplice correziva.

Dimissione (III Stadio)

Modello a cascata

• Requisiti congelati dopo la speficia
• Feedback solo dopo sviluppo
• Fasi con grossa granza
• Rieseguo la costrua dell’intero prodotto
• Team con molte persone

Modello incrementale

• Requisiti facilmente modificabili
• Feedback costante
• Fasi che possono essere condotte in parallelo
• Codifica e rieseguo in ogni build
• Differenti team con piccole dimensioni

Modello a spirale

• Analisi dei rischi
• Progettare
• Comunico col cliente
• Validazione del cliente
• Sviluppo e rilascio

Si tratta di un modello incrementale, perché in ogni ciclo costruisco un build.

Versione whirloc

• Analisi rischi prototipo rapido verifica
• Analisi rischi cambiato verifica

Prima di ogni esame ne vengono valutati i rischi

Se il rischio di rilascio è troppo alto, nel modello a spirale sviluppo una funzionalità.

SYNCH-AND-STABILIZE

• Sviluppo e testing in parallelo
• Specifica può essere modificata
• Le priorità e i piani degli utenti possono cambiare
• Sincronizzazione molto frequente
• Rilascio con data fissata
• Continuo feedback
• Piccoli gruppi

WATERFALL

• Sviluppo e testing in sequenza
• Specifiche congelate
• Non si ricomincia a lavorare
• Una sola integrazione
• Si cerca la perfezione
• Feedback dopo il rilascio
• Gruppi grandi

MODELLO NETSCAPE

è un modello di tipo synchronize-and-stabilize con un ridotto numero di persone dello staff

con scarsa pianificazione, documentazione incompleta e risorse molto più limitate. La produttività sarà molto simile al modello Microsoft.

PROCESSO

1. Requisiti e progetto
2. Primo quadro esecutivo
3. Sviluppo
4. Quadro esecutivo intermedio (se necessario)
5. Primo rilascio interno (alpha)
6. Pubblicazione della versione beta 1
7. Beta 2 e beta 3
8. Codice completato
9. Rilascio

esempio: SW che controlla il funzionamento di un ascensore

funzioni: EB, ascensore al piano, ascensore in azione

Indicare il funzionamento della transizione:

Ts = ASC del piano terra

GBP1 = bottone che chiama ascensore 1 piano

Anche se in EB1 non c'è il token nel momento in cui vado premere si genera

Nel tempo sono state proposte altre specifiche formali.

FSM (Finite State Machine)

Esempio di linguaggio formale usato in specifica del prodotto software:

Safe Locked ---- A --- 3R ---- B ---- 2L ---- Safe Unlocked

Sono Alarm

Stato iniziale

Stato finale

Ogni rettangolo rappresenta uno possibile stato del sistema!

In questo caso si rappresenta una cassaforte.

1L = one left = a sinistra -> A

Ogni altro movimento fa suonare e allarme ed è il stato finale perché si blocca

8R = 8 destra -> B

2L = 2 a sinistra -> Cassaforte sbloccata

Si usa una notazione visual ed una tabella di passimi stati

Sono definiti con lo stato degli oggetti e il formalismo del class diagram

Viene costruito in modo iterativo e incrementale

Inizialmente si soffermiam sulle entity classes che definiscono l'oggetto applicazione

Le boundary classes rappresentano l'interfaccia utente e le control class gestiscono il flusso dei dati veicolando il risultato d'uso.

Approcci a identificare le classi

• Noun Phrase -> Frase con il sostantivo, usa nome, potenzialità di classi, molte parole vengono divise in 3 gruppi (rilevanti, non rilevanti, fuzzy)
• Common Class Patterns -> Basato sulle teorie della classi. Accteratore (concept/class), organization, people/plaudas
• Use case driven -> Quando il termine del use case è il primo e il sistema intende che si tratta di una responsabile
• CRC (Class-Responsability Collaboratores) -> Usato per una verifica dello specifica. Si usano le card. Ogni card nome della classe, responsabilità
• Approccio mixed -> Basato su elementi presenti negli altri approcci

Linee guida x identificare le entity classes

Con classe serve avere un procedimento è governo un sistema di stati delle azioni, di separazioni.

Casi di studio

1. University enrolment -> Ogni corso un class diagram, con sponsorizzati, ogni corso code oggetto dei studio, e uno stud.
2. Video store -> Un noleggio usa dei master/dischi con codice a barre x il titolo
3. Contact Management -> Mantenere le rapporti con i clienti. Schedare le attività future, varie. Redazioni delle organizze e i contatti
4. Telemarketing -> Creare e gestire le chiamate, ripetutamente più chiamante iniziati.