Requirements Engineering - Corso Aziendale
| Descrizione Dettagli Programma Peculiarità Contatti |
| Per molti sviluppatori, il termine requisiti evoca l'immagine di documenti polverosi, resi rapidamente obsoleti dall'evoluzione del progetto. Burocrazia, insomma, un inutile retaggio del passato in un mondo agile e competitivo. Il motivo e' semplice. Troppo spesso si finisce per documentare l'ovvio, senza aggiungere valore. Si crede che l'analisi debba generare molta carta, mentre l'obiettivo dell'analisi e' capire il problema, definirne i contorni e di conseguenza il confine di automazione del sistema, che rappresenta esattamente il prodotto che andremo a creare. Non e' un compito semplice. Pensare di ridurlo ad una mera compilazione di un template, magari scrivendo Use Case dopo una rapida intervista ad un potenziale utente, significa affrontare una dura battaglia disarmati. Saltarla a pie' pari, iniziando a scrivere codice dopo una rapida chiacchierata, porta spesso a realizzare un sistema che fa quello che ha chiesto l'utente, ma non quello che serve all'utente. Ammesso, ovviamente, che sia possibile identificare con tanta semplicita' il mitico "utente". Ogni attivita' complessa richiede un set di strumenti ampio. Strumenti concettuali ancora prima che strumenti pratici, perche' dobbiamo imparare ad affrontare situazioni diverse con tecniche diverse. Con metodo, ma anche con creativita', perche' i veri requisiti non sono quasi mai a portata di mano. Spesso, la differenza tra un prodotto di successo ed uno che ottiene una tiepida accoglienza sta proprio nell'aver compreso a fondo il problema, ed aver poi trovato un approccio che faccia realmente lavorare il computer, non l'utente. Infine, e' anche necessario comunicare quanto abbiamo appreso. Comunicarlo agli utenti, all'azienda, ai progettisti, ai programmatori. In modo economico, ove possibile, senza creare volumi che nessuno leggera' mai con attenzione. Insegnare a fare tutto cio' e' l'obiettivo del corso. Troverete quindi un buon trattamento delle tecniche piu' note ed utilizzate (come gli Use Case), ma anche una grande enfasi sullo studio del problema, sulla valutazione di idee alternative e la gestione dei conflitti tra le richieste, sulla concezione di approcci innovativi, che non portino all'ennesimo caso di "computer inutile". Si passa poi ad altri strumenti, importanti per specificare in modo preciso ma compatto regole e comportamenti. Qui ritroverete l'uso di UML come linguaggio principe per comunicare con programmatori e progettisti, in modo efficace ed efficiente. Non mancano ovviamente gli esercizi, e spesso viene scelto un problema aziendale come candidato all'applicazione delle diverse tecniche esposte. |
|
Durata: 3 giorni, con possibilita' di ulteriori attivita' di mentoring su problematiche aziendali. Il corso puo' essere esteso a coprire anche altri temi, come i Thinking Hats ed il Lateral Thinking di De Bono, la gap analysis, la SWOT analysis, le tecniche di analisi dei profili utente (Personas) di Cooper, ecc. Il programma ideale dipende dal tipo di problemi che vengono abitualmente affrontati, dalla struttura e dalla cultura aziendale. In genere, il corso viene sempre personalizzato. Partecipanti: Massimo 15 Prerequisiti: Familiarita' con i sistemi software, preferibilmente esperienza da progettisti o analisti (non strettamente necessaria, mentre e' utile una mentalita' logico-analitica). Indicato per: Aziende che sviluppano prodotti software con una forte componente di interazione con l'utente (applicazioni consumer, di produttivita' individuale, banking, entertainment, gestionali, applicativi "da ufficio", ecc). Non e' consigliato per chi sviluppa sistemi embedded-real/time con scarsa interazione con l'utente. Corsi correlati: |
Concetti Generali
|
| E' sin troppo semplice mettere insieme un corso sui requisiti, raccogliendo informazioni dai vari standard, proponendo template piu' o meno rigidi, e chiudendo il cerchio con l'equazione requisiti = use case. Questo corso percorre una strada differente, e pure quando arriva a coprire gli stessi argomenti, lo fa da una diversa prospettiva. Riconosce che gli utenti non sempre riescono a distinguere problemi e soluzioni, e propone un insieme di tecniche ampio per arrivare a capire, integrare, creare i veri requisiti. Questo passo importante, di cui ho avuto modo di parlare gia' molti anni fa (ad es. nel mio saggio When Past Solutions Cause Future Problems, IEEE Software, September/October 1997), e' anche parzialmente ripreso nelle appendici del mio UML 2 Manuale di Stile, il cui draft e' liberamente scaricabile. La parte creativa va comunque integrata con approcci sistematici (e dove occorre formali) per la specifica dei requisiti. Anche qui, ho cercato di evitare gli errori piu' frequenti (pagine e pagine di use case dove e' semplice trascurare dettagli importanti) e mostrare come le dinamiche complesse si catturino meglio con un activity diagram, come l'uso di un diagramma delle classi in luogo di un obsoleto "dizionario dei termini" possa semplificare il passaggio alle successive attivita' di design e codifica, creando un ubiquitous language, un linguaggio condiviso tra tutte le figure coinvolte nello sviluppo del software, e cosi' via. Come sempre, a questo si unisce una conoscenza approfondita dei temi trattati, la pratica costante nei piu' svariati settori applicativi, e non ultima una lunga esperienza di insegnamento (ho iniziato l'attivita' di formatore intorno al 1993). Chi si rivolge a me cerca, di norma, il corso migliore sul mercato. |
|
Per ogni approfondimento sul corso, per ricevere un'offerta, pianificare una data,
discutere eventuali personalizzazioni degli argomenti o degli esercizi, ecc, contattatemi
via email all'indirizzo corsi@eptacom.net
o telefonicamente al numero 019-9246391. Nota: il corso viene svolto unicamente presso le aziende. Al momento, non e' prevista l'iscrizione come singoli partecipanti. |
