Ho da poco acquistato il libro "Designing and Developing Web-Based Application Using Microsoft .NET Framework 2.0" per la preparazione all'esame di certificazione MCPD Web (anche se devo ancora diventare MCTS, prima della laurea lo sarò !). Ho letto la prima lezione e mi è venuta voglia di riassumere in un post i concetti principali che emergono. Come sapete sono uno studente (almeno per un altro annetto) e non ho ancora una esperienza pratica sulle tecniche di progettazione e su argomenti di architettura quindi quello che scrivo scaturisce semplicemente da considerazioni fatte da altre persone che lavorano da molti anni nel mondo del software. Per questo motivo vorrei sapere il vostro parere sulla base delle vostre esperienze perchè sono convinto che si possa crescere molto in questo modo.
Analisi e verifica dei requisiti
Una nuova applicazione e in generale un nuovo progetto nasce da una cosidetta VISION. Una VISION rappresenta una idea più o meno brillante che può tradursi in un business di successo. Affinchè questo possa avvenire è necessario che gli architetti e gli sviluppatori aiutino gli analisti del business a definire esattamente gli obiettivi del progetto (goals) e quindi arrivare ad un completo insieme di requisiti.
L'analisi dei requisiti è una fase molto importante che permette di:
- raggiungere una comprensione comune e chiara (tra manager, progettisti e utenti) di ciò che si dovrà realizzare
- determinare quali sono le migliori tecnologie attualmente disponibili per risolvere i vari problemi
- permettere ai tester di confermare se l'implementazione dell'applicazione è accettabile
Alla luce di ciò è chiaro che è fondamentale definire e soprattutto documentare tutti i requisiti della nostra applicazione. Esistono tanti modi per effettuare questo passo e probabilmente non ne esiste uno migliore di un altro. Microsoft da parte sua propone un processo di sviluppo software chiamato Microsoft Solutions Framework (MSF) integrato nel prodotto Microsoft Visual Studio Team System.
Si possono individuare quattro grandi tipi di requisiti:
- Requisiti di Business (Business Requirements)
- Definiscono cosa i manager ritengono importante per il successo del progetto. Questi requisiti sono in genere ad altissimo livello e dovranno essere in seguito tradotti in requisiti più tangibili dall'architetto software.
- Requisiti Utente (User Requirements)
- Definiscono i compiti che gli utenti devono essere in grado di svolgere per raggiungere gli obiettivi del loro lavoro.
- E' senz'altro utile realizzare degli Use Case per chiarire meglio i requisiti.
- Requisiti funzionali (Function Requirements)
- I requisiti funzionali o specifiche funzionali sono le caratteristiche che gli sviluppatori devono realizzare per soddisfare gli altri requisiti. In questo caso è fondamentale scendere in grande dettaglio per permettere agli sviluppatori di capire esattamente quello che deve essere fatto. I requisiti funzionali sono tipicamente scritti da un capo tecnico o architetto.
- Requisiti di qualità del servizio o non funzionali (Quality-of-Service Requirements)
- Non rappresentano tipicamente specifici problemi utente piuttosto definiscono i requisiti riguardanti cose come performance, scalabilità e standard. Questi requisiti non devono essere sottovalutati ed è necessario definirli e considerarli fin dall'inizio nella realizzazione dell'architettura applicativa.
E' interessante individuare la differenza tra casi d'uso e requisiti. I primi sono generalmente un modello UML che descrive un insieme di passi che l'utente deve compiere per realizzare un task. I requisiti invece definiscono cosa deve essere creato per soddisfare i bisogni degli utenti.
La validazione consiste nel verificare che i requisiti creati siano:
- non ambigui
- completi
- necessari
- flessibili
Una analisi dei requisiti ben realizzata quindi semplifica il lavoro di ciascun membro del team permettendo di realizzare una buona architettura, un buon testing e soprattutto ottenere la soddisfazione dell'utente.
Mi piacerebbe sapere cosa pensate voi dell'analisi dei requisiti e in generale delle fasi e metodologie di progettazione di una applicazione come ad esempio le metodologie agili che da quanto ho capito tendono a concentrarsi quasi esclusivamente sui casi d'uso coinvolgendo quotidianamente il cliente nel processo (dicono che funzionano solo per piccoli gruppi di lavoro). Ancora non conosco esattamente le linee di separazione dei compiti tra le varie figure professionali come sviluppatore, progettista, architetto, project manager etc. Ma qui in Italia come funzionano le aziende, permettono di crescere e se si come si diventa progettista o architetto ? Se avete qualche link chiarificatore ve ne sarei grato.
Ciao a tutti