Lezione 2 Ciclo diVita e Processi Softwareunina.stidue.net/Ingegneria del Software 2... · Lezione...

Ingegneria del Software 2 – CVS e Processi Software 1

Lezione 2Ciclo di Vita e Processi Software

Riferimenti bibliografici

• I. Sommerville – Ingegneria del Software – 8a edizione – Cap.4

• R. Pressman- Principi di Ingegneria del Software- 4 edizione- Cap. 3

Obiettivi della lezione

1. Richiamare I concetti di Ciclo di Vita del Software e di Ciclo di Sviluppo Software

2. Classificare I Modelli di Processo Software fondamentali

Il Ciclo di Vita del Software (CVS)

• Standard IEEE 610.12-1990 (Glossary of Software Engineering Terms)

• Software Life Cycle: The period of time that starts whena software product is conceived and ends when the product is no longer available for use. The software life cycle typicallyincludes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkoutphase, operation and maintenance phase, and sometimes, retirement phase. Note: These phases may overlap or beperformed iteratively. Contrast with Software DevelopmentCycle.

Ciclo di Sviluppo Software

• Standard IEEE 610.12-1990

• Software Development Cycle : (1) The period of time that begins with the decision to develop a software product and ends whenthe product is delivered. This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Contrastwith Software Life Cycle.

• Notes: The phases listed above may overlap or be performediteratively, depending upon the software development approach used. (2) This term is sometimes used to mean a longer period of time, either the period that ends when the software is no longer being enhanced by the developer, or the entire software life cycle

Una architettura per la definizione di CVS

• Standard IEEE 12207.0-1996/ 2008 (Software Life-CycleProcesses)

• Software Life Cycle Processes: the Standard defines a framework containing the processes, activities,and tasks in the development, operation and maintenance of a software product, spanning the life of the system from the definition of its requirements to the termination of its use

Ciclo di Vita ed i suoi Processi (St.ISO12207-1996)

LIFE CYCLE

SUPPORTING

CONFIGURATION MANAGEMENTDOCUMENTATION

QUALITY ASSURANCE

VERIFICATIONVALIDATION

JOINT REVIEW

PROBLEM RESOLUTION

PRIMARY

DEVELOPMENT

OPERATION

MAINTENANCE

ACQUISITION

SUPPLY

ORGANIZATIONAL

MANAGEMENT

INFRASTRUCTURE

IMPROVEMENT

TRAINING

Ciclo di Vita ed i suoi Processi (St.ISO12207- 2008 nuova versione)

Processi Software: definizione

• Processo : – un insieme di attività concentrate nel tempo finalizzate alla

realizzazione di un particolare output.• Processo Software:

– Un insieme strutturato di attività necessarie per lo sviluppo diun sistema software.

– Specifica;– Progettazione (o Design);– Validazione;– Evoluzione

• Progetto Software: è un impegno (con date di inizio e fine stabilite) a produrre un prodotto o servizio, con specificate risorse e requisiti

Modelli di Processo Software

• Un processo software può essere organizzato usando i Modelli di Processo Software:– I Modelli di Processo Software (talora detti ancora

CVS) definiscono la struttura di massima di un processo software, indicando le fasi in cui si articola e i criteri di successione.

– Un Modello di processo software è unarappresentazione astratta di un processo.

– Fornisce una descrizione del processo da unaparticolare prospettiva.

Quali Modelli di Processo Software?

• Una possibile classificazione:

1. Processi basati su documentazione• Basati su linguaggi semi-formali per la specifica dei

documenti (es. UML), e richiedono trasformazioni e controlli manuali dei prodotti intermedi

2. Processi basati su Metodi Formali– Basati su linguaggi formali di specifica, con

trasformazioni e controlli automatici dei prodotti intermedi

3. Approcci AGILI– Uso ridotto di documentazione

Processi basati su Metodi Formali

• Uso di formalismo matematico per esprimere i requisiti– Es. Specifiche algebriche (es. per tipi di dato astratto)– Es. approccio basato su modelli di stato

• Uso di tecniche di model checking per provare la correttezza sul modello

• Trasformano automaticamente le specifiche in codice– La correttezza è preservata– La verifica è ottenuta implicitamente

DefinizioneRequisiti

SpecificaFormale

Trasformazioneformale

Integrazione e Testing di sistema

Processi basati su Metodi Formali

• Problemi– necessità di specifici skill (in linguaggi matematici)– Impossibilità a specificare formalmente alcune parti – Difficoltà del cliente nella convalida dei requisiti

• Applicabilità– Non adatti per sistemi di grandi dimensioni– Usati solo per parti critiche

• In questo corso approfondiremo:– (1) Processi basati su documentazione – (3) Processi basati su metodi AGILI

Modelli di Processo dalla letteratura

• Basati su documentazione:– Waterfall– Evolutivo– Basato sul Riuso (di Componenti, Linee di Prodotto…)– Incrementale– A Spirale – Rational Unified Process (UP e RUP) …

• AGILI:– XP (eXtreme Programming) – TDD (Test Driven Development)– Scrum, Lean, …

Il Waterfall model

DefinizioneRequisiti

Progettazionesoftware

Codifica e Testing di unità

Operatività eManutenzione

Integrazione eTesting di Sistema

• Fasi sequenziali ben definite• Sviluppo Guidato dalla documentazione

• Troppo rigido/ burocratizzato• Rilascia software solo a completamento di tutte le fasi• Richiede conoscenza immediata e stabilità dei requisiti

Il Waterfall model

Modello a cascata: una varianteFattibilità

validazione

Analisi e specifica deirequisiti

validazione

Progettazione

verifica

Codificaverifica

Testing

Messa in esercizio

Manutenzione

Ri-validazione

Verifica: Stabilire la verità dellacorrispondenza tra un prodotto software e la sua specificaValidazione: Stabilire l’appropriatezza di un prodotto software rispetto alla sua missioneoperativa

Validazione : Stiamo costruendo il prodottogiusto?Verifica : Stiamo costruendo giustamente ilprodotto?

Modello di Sviluppo a V (V-Model)

• Un’altra variante …

• Molto usata per sviluppo di software embedded

• Basato sull’idea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraversovarie versioni. Due modelli fondamentali:

• (A) Sviluppo Esplorativo– L’obiettivo è di lavorare col cliente per esaminare i requisiti

iniziali e farli evolvere fino al sistema finale. Dovrebbepartire da pochi requisiti ben compresi e aggiungere nuovecaratteristiche proposte dal cliente.

• (B) Prototipale (Usa e Getta)– L’obiettivo è di comprendere i requisiti del sistema. Si parte

da requisiti poco chiari e si realizzano prototipi per esplorarei requisiti e chiarirli.

Sviluppo Evolutivo

(A) Sviluppo evolutivo- Esplorativo

DescrizioneRequisitiiniziali

Specificarequisiti

ConvalidaConvalida

SviluppoSviluppo

VersioneFinale

VersioniIntermedie

Versione Iniziale

(A) Sviluppo evolutivo- Esplorativo

• Vantaggi:– Rapido feedback e possibilità di far cambiare I requisiti

• Problemi– Mancanza di visibilità del processo (è anti-economico

documentare ogni versione del sistema);– I sistemi diventano spessomal strutturati (per i continui

cambiamenti);– Richiedono particolari skills (es. Uso di linguaggi di

prototipazione rapida)• Applicabilità

– A sistemi interattivi di piccole e medie dimensioni (<500.000 LOC);

– Per sviluppare alcune parti di sistemi di grandi dimensioni (per es. l’interfaccia utente);

– Per sistemi destinati a vita breve.

• Per grandi sistemi è consigliabile un approccio misto.

(B) Sviluppo Evolutivo- Prototipale

• Realizzazione di una prima implementazione (prototipo), più o meno incompleta da considerare come una ‘prova’, con lo scopo di:– accertare la Fattibilità del prodotto– validare i Requisiti

• Dopo la fase di utilizzo del prototipo si passa alla produzione della versione definitiva del Sistema Sw mediante un modello che, in generale, è di tipo waterfall.

Modello con Prototipo (Usa e Getta)

REQUISITI PROGETTAZIONEVELOCE

SVILUPPOPROTOTIPO

VALUTAZIONE ERAFFINAMENTO

REQUISITI

SVILUPPO PRODOTTO

CVSCLASSICO

IS basata sul Riuso

• Sviluppo basato sul riuso sistematico, integrandoComponenti esistenti o interi sistemi COTS (Commercial-off-the-shelf)

• Fasi del Processo (CBSE)– Specifica dei requisiti;– Analisi dei componenti;– Modifica dei Requisiti (specificando i componenti disponibili);

– Progettazione con riuso;– Sviluppo e Integrazione.

• Necessita di appositi standard per la specifica dicomponenti.

Sviluppo basato sul Riuso

SpecificaRequisiti

Analisi Dei componenti

Modifica deirequisiti

Convalida delSistema

Sviluppo E Integrazione

Progetto del Sistema con riuso

Processi di sviluppo Iterativi

• In un ambiente globale di rapidi cambiamenti, è essenziale per la competitività delle aziende che il software di cui necessitanosia sviluppato e consegnato in tempi rapidi!

• La mutevolezza ed instabilità dei requisiti impongono diadottare processi di sviluppo ciclici, in cui il software vieneconsegnato in una serie di incrementi, prodotti in vari cicli diprocesso (iterazioni) in cui si ritorna sulle fasi già condotte

• I cicli di processo possono essere applicati ad ogni genericomodello di processo.

• Due possibili approcci:– (A) Sviluppo e Consegna Incrementale;– (B) Sviluppo a Spirale.

(A) Sviluppo e Consegna Incrementale

• Piuttosto che consegnare il sistema tutto in una volta, lo sviluppo e la consegna sono eseguiti per incrementi,dove ogni incremento rilascia parte dellefunzionalità richieste .

– Ai requisiti Utente vengono associati livelli di priorità e quelli a priorità maggiore vengono rilasciati con I primiincrementi.

– Una volta partito lo sviluppo di un incremento, I relativirequisiti devono essere congelati, mentre I requisiti coinvoltiin incrementi successivi possono continuare ad evolvere.

– I servizi comuni possono essere implementati all’inizio del processo, o quando una funzione è richiesta da un datoincremento.

(A) Sviluppo e Consegna Incrementale

IndividuazionePreliminare requisiti

Assegnazione requisitiagli incrementi

Progettoarchitetturale

Integrazionedell’incremento

Integrazionedell’incremento ConvalidaConvalidaConvalida

dell’incremento

Convalidadell’incremento

Sviluppodell’incremento

Sistema Incompleto

SistemaCompleto

Esempio di processo incrementale

Requisiti: R1, R2, R3Architettura: M1, M2, M3, M4Pianificazione: 3 iterations

Iteration1R1, requires M1, M2Develop and integrate M1, M2Deliver R1

Iteration2R2, requires M1, M3Develop M3, integrate M1, M2, M3Deliver R1 + R2

Iteration3R3, requires M3, M4Develop M4, integrate M1, M2, M3, M4Deliver R1 + R2 + R3

Vantaggi dello sviluppo incrementale

– I clienti non devono aspettare il sistema completoper la consegna, ma possono disporre al più presto dei requisiti più critici, attraverso I primi incrementi.

– I primi incrementi possono essere usati come prototipo per aiutare a definire I requisiti degliincrementi successivi.

– Si riduce il rischio di un fallimento totale del progetto.– I servizi a più alta priorità saranno anche testati più

intensamente degli altri.

Problemi dello sviluppo Incrementale

• Problemi– Gli incrementi devono essere relativamente piccoli

(<=20.000 LOC) ma può essere difficile predisporre i requisiti in incrementi della dimensione giusta.

– Le funzionalità comuni (richieste da più requisiti) potrebbero non essere identificate abbastanza presto, giacchè bisogna prima attendere che gli incrementi siano completati per avere ben chiari tutti i requisiti.

Un esempio: Extreme programming

• Extreme Programming– Un esempio di approccio allo sviluppo basato su

sviluppo e consegna di piccolissimi incrementi difunzionalità.

– Si basa su un continuo miglioramento del codice, sulcoinvolgimento dell’utente nel processo di sviluppo, e sulla programmazione a coppie.

(B) Sviluppo a Spirale (di Boehm)

• Il processo è rappresentato come una spirale, piuttosto che una sequenza di attività con retro-azioni.

• Ogni giro nella spirale rappresenta una fase del processo.

• Non prevede fasi prefissate a priori (come la specifica o il design) ma i cicli sono definiti in base al caso specifico.

• C’è una esplicita gestione dei rischi che vengonovalutati e risolti durante tutto il processo.

• Metamodello perché comporta la selezione di un modello di CVS da adottare nello sviluppo.

Modello di sviluppo a spirale

Riskanalysis

Riskanal ysis

Riskanal ysis Pr oto-

type 1

Pr ototype 2

Pr ototype 3Oper a-tionalpr oto ype

Concept ofOper ation

Simula tions , models , benchmar ks

S/Wrequir ements

Requir ementv alidation

DesignV&V

Productdesign Detailed

design

Unit test

Integ ra tiontest

AcceptancetestService De velop , verify

ne xt-level pr oduct

Evalua te alterna tives,identify, resolv e risks

Deter mine objecti ves,alterna tives and

constr aints

Plan ne xt phase

Integ rationand test plan

De velopmentplan

Requir ements planLife-cycle plan

REVIEW

1. Determinazione di obiettivi, alternative e

vincoli

3. Sviluppo e Verifica del prodotto4. Pianificazione

della fase successiva

2. Valutazione di alternative,

identificazione e risoluzione dei

rischi

Settori del modello a spirale

• Determinazione degli obiettivi– Definizione di obiettivi , vincoli e piano di gestione della

• Valutazione e riduzione del rischio– Si analizzano I rischi della fase e si scelgono le attività

necessarie a gestire I rischi.• Sviluppo e Convalida

– Si sceglie un modello di sviluppo per il sistema tra I modelli generici.

• Pianificazione– Il progetto viene revisionato e si decide se continuare con

un nuovo giro della spirale. Si pianifica tale giro.

• Il RUP (Rational Unified Process)– Un esempio di modello di processo “ibrido”

Unified Process (UP) Booch, Rumbaugh, Jacobson (autori sia di UML che UP)

UML (Unified ModelingLanguage)

• Linguaggio per la modellazione e costruzione di sistemi software.

• È Standard OMG (ObjectManagement Group) dal 1997

UP (Unified Process)

• È il processo definito dai tre autori per lo sviluppo con utilizzo di UML

• Non è uno standard

• La versione commerciale è nota come RUP (RationalUnified Process) creata da IBM

Rational Unified Process (RUP)

• Un moderno modello di processo software derivato da UML e dal relativo processo.

• Include tutte le caratteristiche dei modelli generici(sviluppo iterativo ed incrementale)

• Individua 3 prospettive sul processo: – Una prospettiva dinamica che mostra le fasi del

modello al fluire del tempo;– Una prospettiva statica che mostra le attività

(workflow) coinvolte;– Una prospettiva pratica che suggerisce le buone

regole da seguire.

Prospettiva dinamica: Le fasi del RUP

Phase iteration

Inception Elaboration Construction TransitionAvvio Elaborazione Costruzione Transizione

Iterazione delle fasi

Le fasi del RUP

• Avvio– Stabilire gli obiettivi di business (e relativi limiti, fattibilità e

giustificazioni economiche) per il sistema.

• Elaborazione– Ottenere una comprensione del dominio del problema (e

specificare i requisiti), stabilire una struttura architetturaleed il piano di progetto.

• Costruzione– Progettare, programmare e testare il sistema

incrementalmente.

• Transizione– Trasferire il sistema nel suo ambiente operativo.

Fasi, Iterazioni ed Incrementi

Avvio Elaborazione Costruzione Transizione

Release ReleaseReleaseReleaseReleaseReleaseRelease

It. Avvio It. Elab. It. Costr . It. Trans.

• Ogni fase può essere eseguita in modo ciclico (più iterazioni) , con risultati sviluppati in modo incrementale.

• Anche l’intero sistema delle fasi può essere ripetuto ciclicamente.

Prospettiva Statica: I Workflow

• Il RUP prevede vari workflow (6 attività principali e 3 di supporto):– Modellazione Processi di business– Requisiti– Analisi e Progettazione– Implementazione

– Test– Rilascio– Gestione della configurazione e delle modifiche– Gestione del Progetto– Ambiente

Workflow e Fasi

• Il RUP non vincola l’esecuzione delle attività a specifiche fasi

• Tutti i workflow del RUP possono essere eseguiti in qualunque iterazione del processo.

• Ovviamente nelle prime iterazioni gli sforzi si concentreranno sui workflow di modellazione e dei requisiti, nelle successive sulla implementazione e sul test.

Distribuzione dei workflow per fasi

Incept ion Elabor at ion Const ruct ion Tr ansition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Iterations #1 #2 #n-1 #n

Support

Le sei pratiche fondamentali del RUP

• Sviluppare il software iterativamente:– Pianificare gli incrementi in base alle priorità del cliente

• Gestire i requisiti:– Documentare esplicitamente I requisiti ed I cambiamenti

effettuati• Usare architetture basate su componenti:

– Strutturare l’architettura con un approccio a componenti• Creare modelli visuali del software:

– Usare modelli grafici UML per rappresentare viste statiche e dinamiche del sistema

• Verificare la qualità del software:– Verificare l’aderenza a standard di qualità aziendali

• Controllare le modifiche al software:– Gestire I cambiamenti e le configurazioni del software

Configurazione del RUP

• Il RUP è un processo generico di sviluppo software:

– deve essere istanziato per ciascuna organizzazione e per ciascun progetto specifico, aggiungendo: standard, modelli di documento standard, strumenti, …

• Punti di forza:– Separazione di fasi e workflow– Le fasi sono dinamiche e vanno pianificate, i workflow sono

statici e sono attività tecniche condotte nelle varie fasi– Comprende un vasto insieme di linee guida e template per

operare con approccio OO e basato su componenti

– Definisce in modo accurato: Ruoli, Attività, Input Output delle varie attività

Costi del RUP

• Impatto organizzativo– Può portare ad una riorganizzazione completa del lavoro

• Impatto culturale– Può comportare una ridefinizione del modo di lavorare

• Costi tecnologici– L’utilizzo del processo é agevolato dall’uso di strumenti (tool)

specifici (come quelli della suite Rational)• Costi di avvio

– Adattamento del processo– Divulgazione– Inquadramento dei processi esistenti

• Spesso si rinuncia ad adottare il RUP proprio perchè essocomporta un drastico cambiamento nel modo di lavorare dellepersone, che potrebbero reagire (sul breve termine) diminuendo la loro produttività

Scelta di un Modello di Processo: alcuni aspetti da valutare

• tolleranza del modello ai rischi che si potranno incontrare• facilità di comunicazione tra sviluppatori e utilizzatori• stabilità dei requisiti noti; probabilità di esistenza di requisiti (ancora) non

noti• importanza di rilasci ‘early’ di (parziali) funzionalità• Intrinseca complessità del problema e delle probabili soluzioni• (anticipata) conoscenza di frequenza e dimensione di richieste di

cambiamento• maturità dell’applicazione (o del dominio applicativo)• disponibilità e priorità di fondi• flessibilità dello scheduling e budget (scadenze per il ricevimento e spesa

dei fondi; possibilità di modificare gli incrementi per ottimizzare costi e minimizzare rischi)

• criticità del rispetto di scheduling e budget• adeguatezza del processo ‘istituzionale’ e tool di sviluppo dello

sviluppatore• corrispondenza tra organizzazione del management e il modello da adottare

Ulteriori Riferimenti bibliografici

• Booch, Rumbaugh, Jacobson, Unified Software DevelopmentProcess, Addison Wesley 1999

• Kroll, Kruchten, Booch, The Rational Unified Process MadeEasy: a Practitioner’s Guide to RUP, Addison Wesley, 2003

• J.Arlow, I. Neustadt, UML2 e Unified Process- Analisi e progettazione Object-Oriented, 2 ed., McGraw Hill 2006

Lezione 2 Ciclo diVita e Processi Softwareunina.stidue.net/Ingegneria del Software 2... · Lezione...

Documents

Transcript of Lezione 2 Ciclo diVita e Processi Softwareunina.stidue.net/Ingegneria del Software 2... · Lezione...

Fondamenti d Informatica 1tanwts.altervista.org/FoI1516/01_IntroInternet.pdf · • Modello TCP/IP – Per le comunicazioni tra processi software/ hardware – Per le comunicazioni

DiVita Magazine - N° 5

diVITA Magazine DESPAR - Il Momento è ORA! Buona Sana Vita.

Magazine DiVita n.9

Città di Biella processi-ponderazione PTPCT 2018/2020 ...comune.biella.it/sito/file/biellaonline/amministrazione-trasparent... · Sviluppo software: Acquisizione servizio di manutenzione

Software libero nei processi di ricerca archeologica: l ...steko/slides/2010/foggia_redslipware.pdf · Domande La distribuzione geografica dipende da fattori ambientali, politici,

I PROCESSI DI SVILUPPO SOFTWARE: LA STORIA › doc › D06_StoriaSviluppoSoftware.pdf · I PROCESSI DI SVILUPPO SOFTWARE: LA STORIA Collana “I quaderni” ... Alcuni IDE, rivolti

PECULIARITÀ DEI PROCESSI COGNITIVI QUALE SOFTWARE? BANCHE DATI DEI SOFTWARE SITI SITI UTILI PER LA RICERCA DEI SOFTWARE DIDATTICI In classe ho un bambinobambino.

Ingegneria del Software 2. Ciclo di vitapages.di.unipi.it/.../lezioniIS/02.IngegneriaSoftware.pdfISO/IEC 12207:2008 • Processi del ciclo di vita del software • Il modello più

Pianificazione, valutazione e conduzione dei progetti per ... progetti Software - Analisi costi...Tecnologie dellÕInformazione applicate ai processi aziendali. Pagina 7 Analisi Costi

Lezioni diVita nostraLezioni diVita nostra · 2020. 4. 16. · Frutti di bene, di attenzione alle persone, di lavoro, di preghiera, di carità. Caro donGia ti salutiamo e siamo certi

DiVita Magazine - LUGLIO 2012 - N°12 - Anno 4

Magazine diVITA di Luglio 2015

Divita Magazine n.10

DiVita Magazine - N° 4

DiVita Magazine - OTTOBRE 2012 - N°14 - Anno 5

diVITA Magazine DESPAR - Speciale Natale

IL SOFTWARE PER LA GESTIONE DEI PROCESSI DI …

Magazine DiVita n.8 Ipasud

DiVita Magazine - marzo 2011 - N°8 - Anno 3