Transition from process to product-level perspective for business software

440 views

Published on

Nuno Ferreira, Nuno Santos, Pedro Soares, Ricardo Machado, Dragan Gasevic, Transition from Process- to Product-Level Perspective for Business Software

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
440
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transition from process to product-level perspective for business software

  1. 1. TRANSITION FROM PROCESS- TO PRODUCT-LEVEL PERSPECTIVE FOR BUSINESS SOFTWARE 20/09/2012 Nuno Ferreira, Nuno Santos, Pedro Soares, Ricardo J. Machado, Dragan Gašević Presenter: Nuno Santos (nuno.santos@ccg.pt ) © 2010-2013 ISOFIN
  2. 2. PROJECT PRESENTATIONISOFIN CLOUD - INTEROPERABILITY IN FINANCIAL SOFTWARE (Leader) 2 © 2010-2013 ISOFIN
  3. 3. THE V+V PROCESS CPD CPI OCs Issues Mashed UCs Issues A-type Sequence B-type Sequence A-type Sequence B-type Sequence Use Cases Logical Architecture Use Cases Logical Architecture Refinement Integration Refinement Integration and and and and Specification 4SRS Validation Specification 4SRS Validation Process-Level Perspective Product-Level Perspective Analysis Design CPD CPI Implementation Process-Level 4SRS Product-Level 4SRS 4SRS 4SRS 3 © 2010-2013 ISOFIN
  4. 4. THE MODELS USED (PROCESS-LEVEL)OCs and A- and B-type sequence diagramsOCs CPD activity type #x interaction #a activity type #y Role #i of Entity #1 Role #j of Entity #2 A-Type Sequence B-Type Sequence interaction #b Organizational Configuration BlackBox A-Type Sequence Diagrams B-Type Sequence Diagrams Use case #a Use case #b Use case #c AE #d AE #e AE#f Actor #y Actor #x A- and B-type sequence diagrams 4 © 2010-2013 ISOFIN
  5. 5. THE MODELS USED (PROCESS-LEVEL)Use Case Models A-Type Sequence Use Cases Logical Architecture BlackBox {U2.1.} Perform Requirements Analysis: … {U2.3.} Design IBS: ... {U2.4.} Process ISOFIN Platform Subscriptions: ... {U2.6.} Implement IBS: … {U2.7.} Publish IBS Description: … 5 © 2010-2013 ISOFIN
  6. 6. THE MODELS USED (PROCESS-LEVEL)the Four-Step-Rule-Set (4SRS) method Step 4 - architectural Step 2 - architectural element elimination element association 2v - architectural 2iii - architectural 2iv - architectural element naming Associations Associations classification element specification architectural architectural 2i - use case Step 3 - description elimination elimination 2vi - global renaming 4i - Direct Step 1 -architectural 2ii - local element element element 4ii - UC packaging & represented 2viii - 2vii - element creation represent aggregation by{U2.1.} cd Allows browsing the Browse the IBS and SBS available catalogs in the Catalogs searching ISOFIN Platform (ISOFIN already existing IBS and Application, IBS, and {AE2.3.1.i} {AE1.11.i} SBS information with the SBS). The user (Business {AE2.3.2.i} IBS Analysis {AE2.2.c} Access {P2.2} IBS {AE1.11.d1} Generated intent of analyzing if the User or the IBS Business {AE2.10.i}{AE2.1.c} T Pre-Start {AE2.1.c} {AE2.5.c} T Remote Analysis {AE1.11.d2} AE current business need Analyst) is allowed to {AE2.11.i} Decision {AE2.5.i} Catalogs Decisions {AE2.1.d} isnt already fullfilled and if search for information {AE3.3.i} the ISOFIN Platform regarding the desired {AE3.7.1.i} infrastructure supports the artifact and to select new implementation. … artifacts to use on his purposes. ... Set of functional and non- functional requirements ISOFIN needed to fulfill identified ISOFIN Generated Functionalities business needs, intended Functionalities {P2.1} IBS{AE2.1.d} T {AE2.1.d} T {AE2.1.c} AE Requirements system functionalities and Requirements Requirements List all the constraints that List may restrict design and implementation.{AE2.1.i} F 6 © 2010-2013 ISOFIN
  7. 7. THE MODELS USED (PROCESS-LEVEL)Logical architecture of the intended system* {P6} ISOFIN Platform Subscriptions Management <<data>> {AE2.4.2.d} ISOFIN <<data>> Customer Request <<data>> {AE3.3.d} SBS Supplier Decisions {AE1.5.d} Consumer Subscription Subscription <<interface>> Requirements Requirements {AE3.3.i} Request Platform Subscription <<data>> <<interface>> {AE2.4.1.d} ISOFIN {AE2.4.2.i} Subscription Supplier Request Request Analysis Decisions {P4} Audit <<data>> <<data>> <<control>> {AE2.4.4.d} ISOFIN {AE2.4.3.d} ISOFIN {AE1.9.c2} Validate Platform Customer Policy Platform Supplier Policy Platform Access <<control>> {AE4.3.c} Execute Service <<control>> Testing {AE1.9.c1} Validate Platform Subscription <<interface>> <<data>> <<interface>> {AE4.6.i} Rate Audit <<control>> {AE4.7.d} Audit Results {AE2.4.4.i} Communicate Goals {AE2.4.4.c} Grant Access Subscription Request to ISOFIN Platform Status <<data>> {AE1.11.d1} Business Needs Requirements <<data>> {AE4.5.d} Process <<interface>> Monitoring Decisions {AE4.3.i} Service Audits <<data>> {AE4.4.d} Delivery and Support Decisions <<data>> {AE4.1.d} Audit Requirements Analysis {P3} ISOFIN Application <<data>> Development {AE4.2.d} Audit Preparation <<control>> {AE2.4.2.c} Execute {P3.1} ISOFIN Conformance Tests Application Requirements {P1.} SBS {P2} IBS Development Development <<control>> {P1.1} SBS {P2.1} IBS {AE2.8.1.c1} Generic Requirements Requirements Interface Design Rules <<data>> <<data>> <<control>> <<data>> {AE2.1.d} ISOFIN {AE1.11.d2} {AE3.2.c} Define {AE3.1.d} Business Functionalities Business Needs {P3.2} ISOFIN NBS Specs Subset Requirements List Requirements List Fulfillment Request Application Analysis Decisions {P1.2} SBS {P2.2} IBS Analysis Analysis Decisions Decisions <<control>> {AE2.8.1.c2} ISOFIN <<control>> {AE2.3.2.c} ISOFIN <<data>> Application Interface {P5} System Maintenance <<data>> <<control>> Decisions Application Specification {AE3.5.d} NBS <<control>> {AE3.4.d} SBS {AE2.3.1.c} IBS Implementation {AE2.1.c} Access Design Decisions Internal Structure Decisions Remote Catalogs Specification <<data>> <<interface>> {AE5.1.d} Infrastructure <<control>> {AE5.1.i} Manage Management Decisions <<control>> Infrastructure {AE3.1.c} Access {AE2.6.1.c} IBS Local Catalogs Code Organization Decisions {P3.3} ISOFIN Application Generator <<control>> {AE5.1.c} Install Patches <<data>> {P1.3} SBS {AE5.5.d} Future Generator <<interface>> Maintenance Tasks List {P2.3} IBS {AE2.8.2.i} ISOFIN <<interface>> <<data>> Generator <<interface>> Application Deployment {AE2.8.1.i} Interface {AE3.6.d} SBS Process {AE3.7.2.i} Local Generation Implementation <<interface>> <<interface>> SBS Publishing <<data>> <<data>> <<data>> Decisions {AE2.7.i} Execute {AE2.11.i} Execute Interface {AE5.3.d} Service-level {AE5.4.d} Infrastructure- {AE5.2.d} Infrastructure IBS Publication in Publishing Info Agreements related Risks Decisions Requirements List Catalog Integration <<interface>> <<data>> {AE2.10.i} Execute ISOFIN {AE2.8.2.d} ISOFIN <<interface>> <<control>> <<control>> Application Publication in Application Deployment <<interface>> {AE2.11.c} Global Catalog Decisions {AE3.7.1.i} Remote {AE2.7.c} IBS {AE3.6.i} Generate Publishing SBS Publishing Publication SBS Code Integration Decisions Interface Decisions <<interface>> «generates» <<interface>> «generates» {AE2.6.2.i} IBS {AE2.6.1.i} Deployment Generate IBS Code {P3.4} ISOFIN Application {P1.4} SBS Process <<data>> <<data>> <<data>> {AE2.6.2.d} IBS <<control>> {AE3.7.2.c} Local {AE3.7.1.c} Remote {AE2.10.c} ISOFIN SBS Publishing SBS Publishing Deployment Application Publication Information Information Decisions <<data>> Decisions <<data>> {AE2.9.d} ISOFIN {AE1.4.d} ISOFIN Application Configuration Application Decisions Configurations <<interface>> {AE1.2.i} Receive <<interface>> Information from ISOFIN {AE2.9.i} Configure pre- Application runtime ISOFIN Application «generates» <<interface>> {AE1.1.i} Send Commands to ISOFIN Application {P2.4} IBS <<interface>> {AE1.10.i} Receive Information from IBS <<interface>> <<interface>> {AE1.8.i} Interfaces {AE1.6.i} Configure pre- Configuration Commands runtime IBS <<data>> {AE1.8.d} IBS Configurations <<data>> {AE1.6.d} IBS Configuration Decisions 7(*) not intended for reading <<control>> {AE1.7.c} Alert Configurations <<interface>> {AE1.7.i} Create Alert <<interface>> {AE1.9.i} Send Commands to IBS © 2010-2013 ISOFIN
  8. 8. THE MODELS USED (PROCESS-LEVEL)Detail of the architecture 8 © 2010-2013 ISOFIN
  9. 9. THE MODELS USED (PRODUCT-LEVEL)Mashed UC’sMashedUC’s CPI {U2.3.1.c} Define A-Type Sequence B-Type Sequence {U3.7.1.i} Publish {U2.1.c} Access IBS Internal SBS Information Remote Catalogs Structure SBS Developer {U2.11.i} Integrate Publishing BlackBox Information IBS Business Analyst {U2.11.c} Define {U3.7.1.c} Define {U2.6.2.d} Define Global Publishing SBS Information IBS Deployment Integration SBS Publisher {U2.7.c} Define IBS {U2.7.i} Publish IBS {U2.6.1.i} {U2.6.2.i} Deploy Information Information Generate IBS Code IBS IBS Developer 9 © 2010-2013 ISOFIN
  10. 10. V+V PROCESS ASSESSMENT Transition Rules Project Charter Mashed UCsOCs Materials Materials CPD CPIA-type Sequence B-type Sequence A-type Sequence B-type Sequence Issues IssuesUse Cases Logical Architecture Use Cases Logical Architecture 4SRS 4SRS Assessment of the V+V execution using Active Reviews for Intermediate Designs (ARID) 10 © 2010-2013 ISOFIN
  11. 11. CONCLUSIONS & OUTLOOK11
  12. 12. CONCLUSIONS The approach assures that validation tasks are performed continuously along the modeling process. It allows for validating:  the final software solution according to the initial expressed requirements;  the B-Type sequence diagrams according to A-Type sequence diagrams;  the logical diagram by traversing it with B-Type sequence diagrams. The presented approach compels the designers and developers to provide a set of models that allow the requirements to be sustainably specified; 12 © 2010-2013 ISOFIN
  13. 13. CONCLUSIONS Each created model in the V+V process takes knowledge from the previously created model as input. Since they are created in succession, the time required to derive a given model is smaller than the previous one. The V+V process is able to conduct reviews regarding architectural decisions; Traceability between the models is integrated in our V+V process thus, any change made to those domain-specific needs is reflected in the logical architectural model . 13 © 2010-2013 ISOFIN
  14. 14. FUTURE WORK (TO BE PRESENTED) Problem Domain Solution Domain Project Charter Organizational Configurations (OCs) #C Requirements #D Context for Project Reviewer System User Product System Course Developer Aplications Admin Design (CPD) OCs Materials CPD A-type Sequence Diagrams B-type Sequence DiagramsRefinement {U2.1.} {U2.2.} {U2.3.} {AE2.1.i} {AE2.2.c} {AE2.3.i} Integration and IBS Business IBS Business and Analyst AnalystSpecification Validation A-type Sequence B-type Sequence Issues Use Cases Diagrams Logical Archictecture Diagram {U2.1.} {U2.2.} AE2.1i AE2.2c AE2.1c {U2.3.} IBS Business AE2.3i AE2.2d AE2.1d Analyst Use Cases Logical Architecture 4SRS U2.1 AE2.1i 4SRS AE2.1d U2.2 AE2.2d AE2.2c To be presented at Software Quality Days Conference - SWQD2013 (http://www.software-quality-days.com/en/) 14 © 2010-2013 ISOFIN
  15. 15. FUTURE WORK (TO BE PRESENTED) 15 © 2010-2013 ISOFIN
  16. 16. WRAP-UP! Thanks for your attention! Obrigado pela atenção! Gracias por su atención! nuno.ferreira@i2s.pt rmac@dsi.uminho.pt nuno.santos@ccg.pt dgasevic@acm.org 16 psoares@ccg.pt © 2010-2013 ISOFIN

×