Opzioni di rappresentazione |
Il Proof of concept strutturale può assumere diverse forme, ad esempio:
-
un elenco di tecnologie conosciute (framework, modelli, architetture eseguibili) che sembrano appropriate alla
soluzione
-
una bozza di modello concettuale di una soluzione che utilizza una annotazione come UML
-
una simulazione di una soluzione
-
un prototipo eseguibile
La decisione se è obbligatorio o meno un proof of concept strutturale e quale forma dovrebbe assumere dipende da:
-
quanto bene si conosce il dominio - se non si è familiari con il dominio, il proof of concept strutturale potrebbe
non solo esplorare soluzioni possibili, ma potrebbe anche aiutare il cliente e le organizzazioni di sviluppo a
comprendere e chiarificare i requisiti
-
la novità del sistema - se le organizzazioni di sviluppo hanno costruito molti sistemi precedentemente, allora
potrebbe non essere necessario creare un proof-of-concept - dovrebbe essere possibile basare una determinazione di
fattibilità sulle architetture e le tecnologie di riferimento esistenti
-
anche se il dominio è conosciuto e il sistema ha precedenti, tutti i requisiti cono giudicati particolarmente
onerosi; ad esempio, sono richiesti livelli altissimi di transazione ed estrema affidabilità
Maggiore è il rischio e maggiore è l'impegno necessario in questa attività di sintesi strutturale nella fase di inizio
(con la previsione di risultati più realistici dai modelli prodotti e valutati), in modo che tutti gli stakeholder
possono essere convinti che la base per inoltrare i fondi e continuare nell'elaborazione è credibile. Tuttavia, deve
essere riconosciuto che tutti i rischi non possono essere eliminati in questa fase. La fase di Inizio non dovrebbe
essere distorta in una fase di Elaborazione de facto.
|