1 / 39

I l Processo di Sviluppo

I l Processo di Sviluppo. Agenda. Rational ed il contesto IBM Software Group Razionali per l’adozione di un processo Descrizione di un Development Case Piano di Implementazione Le soluzioni IBM Rational. Agenda. Rational ed il contesto IBM Software Group

eljah
Download Presentation

I l Processo di Sviluppo

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Il Processo di Sviluppo

  2. Agenda • Rational ed il contesto IBM Software Group • Razionali per l’adozione di un processo • Descrizione di un Development Case • Piano di Implementazione • Le soluzioni IBM Rational

  3. Agenda • Rational ed il contesto IBM Software Group • Razionali per l’adozione di un processo • Descrizione di un Development Case • Piano di Implementazione • Le soluzioni IBM Rational Agenda slide

  4. . . . Distri-bution Manufac-turing Gov't. Finance Telecom Retail Customer /PartnerApplications ValueChain Management Product Lifecycle Management Customer Relationship Management Enterprise Resource Management Application Integration Layer - Transaction Management WebSphere MiddlewareIntegrationPlatform - Data Management DB2 - Collaboration Lotus - Systems Management Tivoli Rational - Software Development Multi-Platform Systems Integration Layer IBM eServers Non-IBM Servers IBM software: Enabling the on demand enterprise • Scalable • Modular • Flexible • Standards based • Reliable

  5. Rational WebSphere DB2 Lotus Tivoli Manage Build Run Software Development Transaction Management Data Management Collaboration Systems Management IBM: A Foundation for the On Demand Era Requirements& Analysis Visual Modeling& Development AutomatedTesting Project Management Software Configuration Management

  6. Processi di business Guidano Applicazioni Applications Sviluppo di nuovi sistemi INTEGRATI INTEGRATI Sistemi Legacy Pacchetti applicativi INTEGRATI Acquisire valore dalle applicazioni di business Automatizzano& Integrano

  7. Estendere • Esporre • Aggiornare Sviluppo di nuovi sistemi • Progettare • Sviluppare • Test • Rilasciare INTEGRATI INTEGRATI INTEGRATI • Personalizzare • Esporre • Test • Rilasciare Sistemi Legacy Pacchetti Applicativi Applicazioni?Sfruttarle, acquisirle o realizzarle

  8. Agenda • Rational ed il contesto IBM Software Group • Razionali per l’adozione di un processo • Descrizione di un Development Case • Piano di Implementazione • Le soluzioni IBM Rational Agenda slide

  9. Obiettivi per l’adozione di un processo: • Analizzare le esigenze di progetto: • Driver Di Business • Fattori Critici di Successo • Problemi/Implicazioni • Configurare una soluzione alle esigenze in termini di: • Processo • Interventi e priorità • Strumenti • Attività • Definire un Piano di Implementazione con risultati: • Incrementali • Misurabili • Fasati sulle priorità

  10. Mappa di una possibile soluzione… • Il successo è determinato dal raggiungimento di una serie di:“OBIETTIVI DI BUSINESS” • Questi sono determinati da alcuni:“FATTORI CRITICI DI SUCCESSO” • …per i quali esistono alcuni:“OSTACOLI AL SUCCESSO”

  11. ...Mappa di una possibile soluzione Una soluzione efficace è studiata per: • Abbattere gli OSTACOLI AL SUCCESSO, • Agevolare i FATTORI CRITICI • Garantire gli OBIETTIVI DI BUSINESS.

  12. Quali obiettivi di business? • Uniformare e centralizzare la gestione delle agenzie? • Migliorare l’automazione dei processi di Business dei vari utilizzatori? • Garantire una precisa e corretta fatturazione all’utenza? • Normalizzare l’Interfaccia con i diversi sistemi esterni (campo, gestione agenzie, etc...)? • Fornire un accesso diversificato alle diverse tipologie di utenti (C/S, Web, etc...)? • Ridurre i costi di manutenzione? • Aumentare la scalabilità del sistema? • …….

  13. …Attenzione ai Fattori Critici di Successo… (Business): • Definizione di una architettura modulare, basata su Servizi e Interfacce stabili • Corretta comprensione dei requisiti e dei processi di business da automatizzare • Definizione delle priorità dei requisiti e gestione del rischio • Gestione del Cambiamento (Gestione di progetto): • Produttività e Qualità delle Risorse (Interne) • Gestione Forniture (esterne) • Evidenza risultati (Elaborati) • Standard e metodi

  14. …ed i Principali Ostacoli da evitare… • Insufficiente definizione dei requisiti • Mancata gestione del rischio • Gestione del cambiamento disomogenea o insufficiente • Obiettivi tutti alla stessa priorità • Ritardata identificazione di problemi significativi • Inadeguato livello di qualità • Interdipendenze che rendono difficoltoso il lavoro in parallelo • Incapacità di tracciare il cambiamento alle evoluzioni • Standard e metodi inadeguati o rallentanti • Linguaggi di comunicazione disomogenei • Insufficiente scambio di informazione

  15. …Raccomandazioni Principali… • Adottare un processo formale di gestione dei requisiti • Gestire un ‘Elenco dei Rischi’ di Progetto e pianificare lo sviluppo di conseguenza • Gestire il Cambiamento in tutte le sue forme • Sviluppare in modo Iterativo e con ‘Piani di Iterazione’ • Pianificare Iterazioni in funzione di priorità e rischio • Pianificare ed eseguire test a tutti i livelli ad ogni iterazione • Definire spazi di lavoro distinti per sviluppo e integrazione • Sviluppare per Componenti (CBD) • Adottare un Processo ‘Activity Driven’ • Realizzare un ‘Development Case’ • Adottare la Modellazione Visuale con UML a tutti i livelli • Automatizzare il processo

  16. …Mappa Ostacoli-Raccomandazioni • Adottare un processo formale gestione dei requisiti • Creare e mantenere un ‘Elenco dei Rischi’ di Progetto • Gestire il Cambiamento in tutte le sue forme • Sviluppare in modo Iterativo e con ‘Piani di Iterazione’ • Pianificare Iterazioni in funzione di priorità e rischio • Eseguire test a tutti i livelli e ad ogni iterazione • Definire spazi di lavoro distinti per sviluppo e integrazione • Sviluppare per Componenti (CBD) • Adottare un Processo ‘Activity Driven’ • Realizzare un ‘Development Case’ • Adottare la Modellazione Visuale con UML a tutti i livelli • Automatizzare il processo Insufficiente definizione dei requisiti Mancata gestione del rischio Gestione del cambiamento disomogenea o insufficiente Obiettivi tutti alla stessa priorità Ritardata identificazione di problemi significativi Inadeguato livello di qualità Interdipendenze rendono difficoltoso il lavoro in parallelo Incapacità di tracciare il cambiamento alle evoluzioni Standard e metodi inadeguati o rallentanti Linguaggi di comunicazione disomogenei Insufficiente scambio di informazione

  17. Quali Pratiche adottare? Raccomandazioni: Best Practices: …Formale gestione dei requisiti… …Gestire ‘Elenco dei Rischi’… …Gestire il Cambiamento… …Sviluppare ‘Piani di Iterazione’… …Pianificare in funzione di rischio… …Test ad ogni iterazione… …Definire spazi di lavoro distinti… …Sviluppare per Componenti… …Processo ‘Activity Driven’… …Realizzare un ‘Development Case’… …UML a tutti i livelli… …Automatizzare il processo… Sviluppare Iterativamente Gestire i Requisiti Modellare Visualmente Sviluppare per Componenti Verificare continuamentela Qualità Gestire il Cambiamento

  18. Riduzione Rischio Sviluppare Iterativamente... Iterativo Waterfall • Il processo iterativo abbatte il rischio Risk Rischio può essere: Un requisito che non si conosce Un requisito poco chiaro Un requisito difficile da implementare o verificare Time

  19. ...Sviluppare Iterativamente Non documentando un ‘rischio’ non lo si elimina! Gestendo il rischio lo si può ‘mitigare’ o ‘eliminare’! Come? • Sviluppando Iterativamente (early prototyping, early testing) • Stilando una ‘Risk List’ da subito (living document) • Pianificando la verifica dei rischi più elevati nelle prime iterazioni • Discutendola regolarmente con Stakeholders/steering comitees • Sviluppando piani di ‘mitigazione’ del rischio • …

  20. Gestire i Requisiti... • Raccogliere • Organizzare • Documentare • Tracciare • Gestire il cambiamento di diverse tipologie di requisiti Es.: • Casi d’Uso • Features • Requisiti non-funzionali • Etc.

  21. Modellare Visualmente... • Per rappresentare il sistema prima che esista • Per ridurre il rischio prima dell’implementazione • Per documentare le scelte e i meccanismi architetturali • Per visualizzare i diversi aspetti del SW • Per migliorare la comunicazione Quali Modelli? Modello dei Casi d’Uso Modello di Analisi (Top Level) Modello di Disegno (Detailed) Modello Dati

  22. Application Modeling Requirements Modeling Web Modeling Data Modeling UML: un unico linguaggio per tutti ...Modellare Visualmente Business Modeling Business Modeling

  23. Specializzare, Generalizzare, Stratificare, Pacchettizare, … Application- specific Business- specific Middleware System- software Sviluppare per Componenti (CBD) Obiettivi: • Isolare il cambiamento • Riuso • Manutenilibità • Pianificazione di risorse e rilasci • … LAYER:

  24. Verificare la Qualità... …A tutti i livelli: • UNIT(metodo/classe/componente) • INTEGRATION(componente/interfacce/servizio) • SYSTEM(servizi) …Su tutte le dimensioni: • FUNZIONALITA’(Use Case) • PRESTAZIONI(requisiti Non-Funzionali) • AFFIDABILITA’(memoria, tempi, copertura, etc.)

  25. Iterazione1 Iterazione2 Iterazione3 Iterazione4 Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 ...Verificare la Qualità • Iterativamente… Modelli/Codice Tests

  26. Gestire il Cambiamento... • Adottando un processo “Pilotato dal Cambiamento”. • Il cambiamento non è qualcosa da evitare ma il meccanismo principe di ogni lavorazione/rilavorazione SW • 2 le principali tipologie di cambiamento: • Richiesta di Miglioramento (Enhancement Request) • Richiesta di Correzione (Defect) • Al cambiamento vanno associate le modifiche che questo ha scaturito (change history) • Il cambiamento ‘vive’ all’interno di un workflow che va definito (es. sottomisione, assegnazione, apertura, risoluzione, chiusura). …

  27. Sede Centrale ReqPro Test CQ CQ CQ CQ CQ CC CC CC CC Fornitore Esterno ...Gestire il Cambiamento Sviluppo Distribuito Geograficamente Torino Milano Firenze

  28. Agenda • Rational ed il contesto IBM Software Group • Razionali per l’adozione di un processo • Descrizione di un Development Case • Piano di Implementazione • Le soluzioni IBM Rational Agenda slide

  29. Realizzare un ‘Development Case’ • Non esiste UN Processo valido per TUTTI. RUP va personalizzato! • Un ‘Development Case’ è una istanza specifica di RUP • Contiene CIO’ CHE SERVE e può subire correzioni • Descrive gli elaborati di ogni disciplina fondamentale • Può essere realizzato in qualsiasi formato • Documenta un ‘Caso’ reale di Sviluppo e quindi è soggetto a cambiamenti…

  30. Il ‘Development Case’: un esempio... • Business Modeling: • Modelli/Elaborati: • BOM (Business Object Model) [Rose/XDE] • BUC (Business Use Case Model) [Rose/XDE] • Gestione Requisiti: • Modelli/Elaborati: • Modello dei Casi d’Uso [Rose/XDE] • Modello di Analisi [Rose/XDE] • Documenti: • Piano di Gestione dei Requisiti [RequisitePro-MSWord] • Documento di Visione (o White Paper di Progetto) [RequisitePro-MSWord] • Specifiche dei Casi d’Uso (principali) [RequisitePro-MSWord] • Specifica Supplementare [RequisitePro-MSWord] • Glossario di Progetto [RequisitePro-MSWord] • Database Requisiti [RequisitePro-Access/MSSQLServer/Oracle]

  31. ...Il ‘Development Case’: un esempio... • Analisi e Disegno: • Modelli/Elaborati: • Modello di Disegno [Rose/XDE] • ( Modello/i di Contenuti - es. Design Patterns Java ) [Rose/XDE] • Modello Dati [Rose/XDE] • Documenti: • SAD (Software Architecture Document) [SoDA-MSWord-Rose/XDE] • Implementazione: • Modelli/Elaborati: • Modello di Disegno [sincronizzato in XDE/ WSAD/ WSED] • Codice [RRD/ WSAD/ WSED] • Documenti: • Linee guida di Disegno [MSWord-RUP] • Linee guida di Programmazione [MSWord-RUP] • Linee Guida di Stile e GUI Design [MSWord-RUP]

  32. ...Il ‘Development Case’: un esempio... • Gestione Cambiamento: • Modelli/Elaborati: • Definizione workflow gestione richieste di modifica [ClearQuest] • Repository di Progetto - Workspaces di Sviluppo e Integrazione [ClearCase] • Documenti: • Piano di Gestione della Configurazione [MSWord-RUP] • Test: • Documenti: • SW Test Plan Funzionale [TeamTest/SoDA] • SW Test Plan Non-FunzionaleSW [TeamTest/SoDA] • SW Test Report(s) [TeamTest-SoDA] • Elaborati: • Test Procedures/Scripts [TeamTest]

  33. ...Il ‘Development Case’: un esempio • Project management: • Documenti: • Master SDP (Software Development Plan) [MSProject-RUP] • Piano di Iterazione [MSProject-RUP] • Risk List [MSWord-RUP] • Elaborati: • Database Richieste di Modifica [ClearQuest] • Database Richieste di Modifica di Progetto [ClearQuest]

  34. Agenda • Rational ed il contesto IBM Software Group • Razionali per l’adozione di un processo • Descrizione di un Development Case • Piano di Implementazione • Le soluzioni IBM Rational Agenda slide

  35. Piano di Implementazione... • Raccomandazioni indicative basate su esperienze precedenti IBM Rational su progetti della medesima tipologia. • Fornitura di un piano dettagliato di implementazione in cui verranno specificati: • Obiettivi • Attività previste • Elaborati da produrre • Stima e qualifica risorse • Strumenti e licenze necessarie • Criteri di completamento delle attività

  36. ...Piano di Implementazione • Automazione del Processo • Adozione di Strumenti a supporto: • delle attività previste dal Development Case • BM=Business Modeling • RM=Requirements Management • AD=Analysis & Design • I=Implementation • T=Test • CM=ChangeManagement • PM=ProjectManagement • Dei vari ruoli di progetto: • A=Analisti,DataModeler, • D=Designer,Sviluppatori, • T=Tester, • PM=Proj.M.

  37. Agenda • Rational ed il contesto IBM Software Group • Razionali per l’adozione di un processo • Descrizione di un Development Case • Piano di Implementazione • La soluzione IBM Rational Agenda slide

  38. Best Practices di un Processo Pratico Sviluppo Iterativo Gestione Requisiti Architetture a Componenti Modellazione Visuale (UML) Verifica continua della Qualità Gestione del Cambiamento Soluzione: Rational Unified Process (RUP)Un Processo reso pratico Configurabile per le tue esigenze di … • Ambiente Tecnologico (J2EE, WinDNA, .NET, RealTime) • Strumenti utilizzati (IBM, BEA, HP, etc.) • Necessità di Team (Requisiti, Modellazione, Sviluppo, Test, etc...)

  39. RequisitePro, XDE, Rose XDE, Rose + IDE, Rapid Developer Rose /RQA, Test RT, Purify+ XDE, Rose XDE, Rose BusinessModel Requirements & Use Cases Unit Tests Code Model TestManager Robot, Test RT TestManager TestManager TestManager ClearQuest System Tests TestResults Test Cases Test Plan Defects – Rational Unified Process, Rational Developer Network Common Process and Guidance – SoDA, ProjectConsole Progress Metrics and Reporting – ClearCase, ClearQuest Software Configuration Management Workflow del ciclo di sviluppo

More Related