|
Categorie
Winzipedia Uso dell'wiki |
AnalisiESpecificaDeiRequisitiIngegneriaDelSoftware.AnalisiESpecificaDeiRequisiti VersioniMostra le modifiche minori - Mostra le modifiche Modificata la linea 13: da:
dei requisiti a:
dei requisiti un processo complicato ed ostico in quanto alla realizzazione Modificate le linee 24-25: da:
#'''Avvio''': la prima fase durante la quale si da origine . Scopo di questa fase #'''Deduzione''': In questa fase vengono identificati una serie di problemi che aiutano a comprendere la deduzione dei requisiti a:
#'''Avvio''': la prima fase durante la quale si da origine . Scopo di questa fase quello di definire una solida conoscenza del problema, delle persone che desiderano una soluzione, della natura della soluzione desiderata e delle comunicazioni e collaborazioni preliminari fra il cliente e lo sviluppatore. #'''Deduzione''': In questa fase vengono identificati una serie di problemi che aiutano a comprendere la deduzione dei requisiti difficile da realizzare per: Modificate le linee 30-31: da:
#'''Negoziazione dei requisiti''': Molto spesso i clienti richiedono di quanto possa essere ottenuto, in base alle risorse disponibili. Inoltre a:
#'''Negoziazione dei requisiti''': Molto spesso i clienti richiedono di quanto possa essere ottenuto, in base alle risorse disponibili. Inoltre relativamente comune che i clienti propongano requisiti in conflitto con altri. Scopo quello di riconciliare questi conflitti tramite un processo di negoziazione. I clienti valuteranno i requisiti e ne discuteranno le . Dovranno poi essere analizzati i rischi associati a ciascun requisito. Modificata la linea 33: da:
* non esiste una spiegazione del sono state prese determinate scelte, questo portare ad avere un software di ottima ma non a:
* non esiste una spiegazione del sono state prese determinate scelte, questo portare ad avere un software di ottima ma non quello che serve Modificata la linea 43: da:
* Requisiti obbligatori, a:
* Requisiti obbligatori, irrinunciabili per il cliente. Modificata la linea 71: da:
dei requisiti a:
dei requisiti basata su processi di comunicazione tra progettisti, Modificata la linea 74: da:
rigorosi e leggibili da utenti di diversa formazione. a:
rigorosi e leggibili da utenti di diversa formazione. un documento Modificata la linea 87: da:
il sistema preesistente, se a:
il sistema preesistente, se . buona regola anche effettuare degli Modificata la linea 103: da:
Presenta un elenco di caratteristiche, ognuna delle quali a:
Presenta un elenco di caratteristiche, ognuna delle quali dotata di un codice Modificate le linee 116-117: da:
funzionamento del sistema. Un attore sistema o il prodotto e che a:
funzionamento del sistema. Un attore un elemento che comunica con il sistema o il prodotto e che esterno al sistema stesso. Quindi un attore e un Modificata la linea 121: da:
a:
dei requisiti evolutiva, nella prima iterazione Modificata la linea 125: da:
Uno scenario di utilizzo a:
Uno scenario di utilizzo un insieme di informazioni che descrivono, dal Modificate le linee 134-136: da:
La definizione di scenari e casi modello che simula la . Inoltre a volte lo scenario non ad esempio quando il prodotto a:
La definizione di scenari e casi utile quando difficile creare un modello che simula la . Inoltre a volte lo scenario non ben definito, ad esempio quando il prodotto destinato al mercato. Questo implica una Modificata la linea 139: da:
Il modello per analizzare un problema a:
Il modello per analizzare un problema quello che fornisce una maggiore Modificata la linea 153: da:
Sviluppando un prodotto non a:
Sviluppando un prodotto non possibile scegliere una forma linguistica Modificata la linea 158: da:
Non a:
Non possibile inoltre definire linguaggi formali migliori di quelli informali Modificata la linea 165: da:
dei requisiti un documento, la specifica, che a:
dei requisiti un documento, la specifica, che un oggetto Modificata la linea 187: da:
Il problema del riuso della conoscenza consiste nel fatto in cui una volta che un prodotto a:
Il problema del riuso della conoscenza consiste nel fatto in cui una volta che un prodotto stato creato, magari partendo da zero, inevitabilmente Modificata la linea 196: da:
non solo ) a:
non solo ) quello dei pattern. Modificate le linee 198-199: da:
Il pattern Non a:
Il pattern uno schema che segue per risolvere un problema. Non uno schema particolare relativo ad un certo problema, ma Modificata la linea 230: da:
, a:
, integrare e far interagire in maniera corretta i requisiti Modificata la linea 272: da:
* Aspetti cognitivi ( documento requisiti a:
* Aspetti cognitivi ( documento requisiti un modello di una parte della ) Modificata la linea 276: da:
* Aspetto sociale (documento dei requisiti a:
* Aspetto sociale (documento dei requisiti espressione di un sistema sociale) Modificate le linee 279-280: da:
della specifica che si In ogni caso a:
della specifica che si realizzata, assicurandosi di che il prodotto finale in grado di svolgere. In ogni caso necessario gestire requisiti che contengono inconsistenze ed evolvono nel tempo Modificata la linea 290: da:
a:
esso stesso motore del cambiamento, gestire il cambiamento una Modificata la linea 295: da:
* Adattarsi ai cambiamenti aziendale, delle tecnologie e degli obiettivi per cui il prodotto a:
* Adattarsi ai cambiamenti aziendale, delle tecnologie e degli obiettivi per cui il prodotto stato creato. Modificate le linee 297-298: da:
* Basare la progettazione su che La progettazione a:
* Basare la progettazione su che stabile per garantire una certa efficienza. La progettazione il cuore del mestiere. Non esiste una vera tecnica che Aggiunte le linee 1-300:
! Analisi e specifica dei requisiti '''Autori:''' [[Profiles.Alberto|Alberto Taiocchi]]\\ ->'''Sommario''' !! Significato, motivazioni, processi concorrono diverse parti interessate (responsabili, utilizzatori, progettisti, ricopre un ambito non solo tecnico, ma anche sociologico, di comunicazione viene scomposta in diverse fasi. ** Problemi di ampiezza, limiti del sistema mal definiti oppure il cliente specifica dettagli tecnici futili che possono confondere gli obiettivi del sistema * le specifiche possono essere incomplete, vaghe e contradditorie * incertezza generale rigurdante i requisiti Si deve essere comunque pronti a gestire requisiti contenenti inconsistenze. Tali requisiti verranno ulteriormente dettagliati nelle fasi successive. Durante la fase di negoziazione vengono distinti tre classi di requisiti: * Requisiti desiderabili, non necessari ma utili. * Requisiti opzionali, relativamente utili oppure contrattabili in seguito. !!!! Specifiche Terminata la fase di negoziazione si otteranno una serie di documenti contenenti un elenco di funzioni e caratteristiche che il prodotto deve possedere. Esistono due tipi di specifiche, le ''specifiche funzionali'' indicanti il motivo per cui viene realizzato il prodotto (che cosa deve fare il prodotto software) e le ''specifiche non funzionali'' descritte nella normativa 9126. * Efficienza, indica il tempo di esecuzione, in relazione ai vincoli di tempo, dovuta ad una sincronizzazione di tutto il sistema. !!!! Convalida Esamina le specifiche per garantirsi che tutti i requisiti software siano stati affermati in modo non ambiguo, che siano state rilevate e corrette tutte le incoerenze, le omissioni e gli errori e che i prodotti finali siano conformi agli standard definiti per il processo, il progetto e il prodotto. !!!! Gestione dei requisiti !!! Modellazione e analisi esistono vari approcci alla modellazione. Ad esempio si possono usare modelli basati sui dati (E-R), oppure modelli che studiano il comportamento dinamico di un sistema. In base al tipo di modellazione decisa si adotteranno diversi linguaggi (linguaggi naturali, naturali-strutturati, semiformali, formali). responsabili, utenti e esperti. Per poter permettere una comunicazione fluente si necessita di documentazione, linguaggi di specifica che siano espressivi, uno standard di documentazione e seguire la vita dei requisiti (e i loro !! Tecniche e linguaggi !!! Tecniche di estrazione dei requisiti I requisiti non sempre sono deducibili da documenti, che spiegano o cercano di spiegare il problema, creati dal cliente. Bisogna assolutamente far luce sugli aspetti in ombra. Ci sono diverse tecniche per farlo, come interviste al cliente (strutturate o meno per argomenti, in modo da pilotare il cliente a questionari scritti mirati, osservando possibili utenti futuri del sistema e studiando incontri periodici tra clienti e sviluppatori per fare il punto della situazione e rilevare eventuali percorsi errati intrapresi dal progetto. Il risultato di tutto ordine di completezza: * elenco strutturato dei requisiti Questi tre punti affrontano il problema con approcci diversi, ma hanno delle caratteristiche comuni: * presenza di schemi * identificazione di ogni requisito * distinzione tra requisiti funzionali e non funzionali !!! Elenco strutturato dei requisiti univoco che la identifica, un titolo ed una descrizione della funzione svolta varie persone (o dispositivi) che utilizzeranno il sistema o il prodotto nel contesto della funzione e il comportamento che deve essere descritto. Gli attori rappresentano i ruoli che le persone o i dispositivi giocano durante il iterazione tutti gli attori principali e identificare gli attori secondari a mano a mano che aumenta la conoscenza del sistema. che uno scenario sia un racconto in cui un utente o un commerciale vengono utilizzate per uno scopo definito e decorano il racconto con informazioni aggiuntive utili dal punto di vista del mercato come ad esempio viene descritto in italiano, diagrammi di flusso dati, reti di Petri. . . completezza. Si possono utilizzare diversi tipi di modelli: * Concettuali, non richiedono competenze informatiche e di solito sono utilizzati in modelli di business, realizzati da persone con grande conoscenza del dominio applicativo. !!! Forme linguistiche * Stili di specifica (formalismo) ** Informali, linguaggio libero, come se fosse un libro. ** Semi formali, linguaggio con sintassi definita solo in modo parziale. ** Formali, linguaggio con sintassi e semantica predefinite. ** Operazionali, descrivono il comportamento desiderato di un prodotto. particolari situazioni (Esempio: Schema E-R per strutturare dei dati, non una macchina a stati finiti). Il documento dei requisiti cosi prodotto, la e viceversa. Bisogna essere coscenti del fatto che ci sono diverse persone coinvolte nel lavoro, con diversi punti di vista e dalle diverse competenze tecniche. Bisogna mirare al formalismo delle tecniche linguistiche garantendo coinvolte. !!! Documentazione materiale, per esempio un documento di word, un file. Tutte le informazione disordinato, ma seguendo uno schema preciso, comprensibile, facile da leggere, anche una serie di attributi ausiliari utili per gestire revisioni future del documento. Un documento per questi scopi normalmente ha un indice di questo tipo: # Storia delle revisioni # Introduzione # Scopo # Definizioni, abbreviazioni, sigle # Riferimenti # Contesto di riferimento # Situazione attuale # Limiti della situazione attuale # Obiettivi # Requisiti funzionali # Requisiti non funzionali # Profili utenti # Allegati !! Modellazione e riuso della conoscenza !!! Il problema maturata negli sviluppatori lascia un segno nel loro bagaglio tecnico. Questa conoscenza va riutilizzata per affrontare nuovi progetti, che potranno Un prodotto software risulta quindi essere un insieme di conoscenze relative ad un dominio applicativo, ad un processo, un businnes, ecc. che in qualche modo va riutilizzato. Ci sono diverse tecniche moderne per riutilizzare prodotti software, sviluppo di prodotti per integrazione con legacy e cots, ecc. Un esempio efficace, utilizzato nella pratica ormai da tempo (e !!! Pattern problemi, per quanto abbiano domini applicativi diversi, hanno forme ricorrenti di base uguali e quindi possono essere affrontati tutti utilizzando una logica comune. Il cuore del concetto di riuso non risiede nello sfruttare la tecnologia precedente, ma nel capire il mercato e i processi dei clienti, in modo da scoprire la forma ricorrente su cui si basa il funzionamento. !!! Analisi del dominio applicativo Per capire quale sia la forma ricorrente dietro un processo bisogna capirne il dominio applicativo. Per farlo, si deve raccogliere una serie di dati dello specifico settore. Dobbiamo identificare le caratteristiche, i requisiti ,le architetture comuni. Raccogliere una collezione di modelli che descrivono i processi di business dello specifico settore di interesse: * Modelli del contesto * Modelli di flusso di dati * Modelli di dati * Modelli ad oggetti * Scenari * Dizionario dei termini * Caratterizzazione del dominio delle caratteristiche !! Relazioni con le altre fasi !!! Requisiti di sistema e requisiti software I requisiti di sistema e i requisiti software rappresentano la descrizione delle caratteristiche che un software e i componenti del sistema devono avere per poter interagire tra di loro, formando un sistema completo e funzionante. altrettanto diversa, che devono interagire tra di loro. Bisogna definire allora del sistema con tale organizzazione. !!! Relazioni con la progettazione si segue uno schema che prevede la progettazione architetturale del sistema, vita alla progettazione di dettaglio. Questo passo viene fatto per diversi motivi. Serve per stimare la dimensione di un progetto e poter cos`ı stabile punti ** Valutare le scelte, costi, rischi e benefici * Identificazione dei requisiti ** Obiettivi ** Specifiche generali * Scelte e alternative architetturali ** Architettura di sistema ** Make or buy * Servizi ** Avvio ** Formazione ** Manutenzione * Pianificazione di massima e tempi ** Rischi ** Costi ** Benefici ** Competitors ** Eventuale realizzazione di componenti critici o prototipali !!! Validazione La fase di validazione ha lo scopo principale di accertarsi che il lavoro svolto fino ad ora sia corretto. Validare un documento significa provare che si comporti come dovrebbe. Questo implica che ci sia un oggetto con la relativa per motivi quali: ** Teorie scientifiche non possono essere provate corrette attraverso le osservazioni, esse possono essere solo falsificate (Popper) ** Le osservazioni non sono neutre (libere da valori) ma si muovono lungo punti di vista dominanti (Kuhn) Ci sono diversi metodi per accrescere la fiducia nei confronti di un prodotto: * Creare corrispondenza tra i desideri delle parti interessate, analizzando il tutto con utenti, clienti, sviluppatori ed esperti del dominio applicativo. * Simulare il prodotto finale (anche con dei prototipi) per valutare con mano. * Negoziare contrasti interni di viste a proposito di qualsiasi aspetto che produce incongruenze tra i modi diversi di vedere il prodotto finale o alcune delle sue caratteristiche. !!! Evoluzione quelli che hanno saputo adattarsi hai cambiamenti. Un software di successo pensare al cambiamento. Per cambiamenti si intende una serie di aspetti fondamentali: * Garantire una specializzazione sufficiente, evitando di generalizzare troppo, cosi come specializzare troppo. viene applicata, ma esistono una serie di strumenti messi a disposizione |