1 / 16

Architecture Maturity & Requirements Engineering Process Maturity Do not Explain Each Other

Architecture Maturity & Requirements Engineering Process Maturity Do not Explain Each Other. Maya Daneva. Introduction Motivation, Research Questions & Research Method Working Context Maturity Models for Architecture and Requirements Engineering Case Study Based on One Company’s Experiences

benny
Download Presentation

Architecture Maturity & Requirements Engineering Process Maturity Do not Explain Each Other

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. Architecture Maturity & Requirements Engineering Process Maturity Do not Explain Each Other Maya Daneva

  2. Introduction Motivation, Research Questions & Research Method Working Context Maturity Models for Architecture and Requirements Engineering Case Study Based on One Company’s Experiences Conclusions Contents

  3. Background • What we observe in practice? • ERP is a vehicle not only to excel but also to survive in a highly interconnected business world. • Enterprise Architecture and ERP projects feed each other / share a number of deliverables • ERP project failures are attributed to poor architecture reqmts • Research Questions: • What are the linkages between architecture maturity and to RE process maturity? • How these linkages evolve over phases of ERP evolution?

  4. Maturity Concepts • IBM • 1989, SEI, CMU: Capability Maturity Model (CMM) for software development • Late 90-ties: CMM in any IT field • Architecture Maturity Models (AMM) Goal: - to optimize architecture-related processes, - to increase organizational awareness of business and technical architecture issues.

  5. Our Approach

  6. 2 3 4 1 5 The Experience Base 13 projects, 67 instances, 1997-2002 Business initiatives vs. IS projects Fast growing (immature) IS-organization Process Instance Characteristics total time = 4 weeks risk-driven approach RE Teams Assessments: RE Good Practice Guide (Sommerville & Sawer) what worked? what did not? common points of success/failure?

  7. RE Assessment Results • 22 Defined Level processes • 29 Repeatable Level processes • 16 Initial Level Processes

  8. Architecture Assessments Review architecture usage scenarios, roles, standards, process documentation Establish mappings between assessment criteria & architecture artifacts Review architecture deliverables for small, mid-sized, & large projects

  9. Results: DoC AMM

  10. How Architecture Supports RE: Observations • Architecture facilitates use of common language • Tool for training new team members • Reuse of reference models • Architecture provided guiding principles for documenting AS-IS and TO-BE scenarios

  11. Discussion: Use of Architecture and RE Maturity Levels

  12. Discussion: Use of Architecture in Four Types of Projects

  13. Discussion: Use of Architecture in ERP Customization Requirements Definitions

  14. Related Work • We found consistencies regarding: • implicit choices between alternative starting points, namely architecture or business requirements; • both architecture and requirements help users build the system they want to use; • We found differences between levels of commitment of process owners to architecture and ERP projects • Merging enterprise architecture and RE is a bumpy road!!

  15. Conclusions:A mature architecture organization does not imply ERP RE process success.A team with high AMM maturity systematically helps ERP RE use architecture deliverables for RE purposes. This study revised our perspective to better accommodate the needs of explicit architecture practices in ERP RE.

  16. Thank you !

More Related