A Rational Unified Process (RUP) Plug-in To Support Requirements Quality Assurance

1. A Rational Unified Process (RUP) Plug-inTo Support Requirements Quality Assurance Andreas Altmannsberger Frank Bühler Mike Rowe U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

2. Agenda • Introduction to the Rational Unified Process (RUP) • Mechanisms for modifying RUP • Where software processes have problems • Requirements Quality Assurance • In Theory and in Practice – not always the same • Conclusion U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

3. IBM / Rational’s Unified Process RUP • Rational’s Unified Process (RUP) is one of the more formal and all encompassing software engineering process frameworks. • Many software engineering processes are based upon RUP U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

4. RUP is a Process Framework • The framework is composed of • Roles – that individuals perform in the performance of Activities to produce Artifacts • Activities – transform input Artifacts into output Artifacts • Artifacts – the end products of activities. The most important of which is generally the running software. • Workflows – provide sequences of Activities which make up a process. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

5. RUP from www.rational.com U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

6. RUP Customization/Tailoring • Customization of RUP involves: • deleting, • adding, and • modifying the Roles, Activities, Artifacts and Workflows. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

7. RUP Rational Process Workbench • Rational Process Workbench (RPW) contains two tools that facilitate building new plug-ins. • The RUP Modeler supports developing and managing new process content. It is an extension of Rose XDE. • The RUP Organizer takes the outputs of the Modeler and compiles these into a Plug-in that can be applied to the RUP. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

8. RUP Builder • RUP Builder (bundled with RUP) is a tool that applies plug-ins to the RUP. • In addition to making your own plug-ins via the Rational Process Workbench, many plug-ins are available through both open source and commercial channels (see • http://www-128.ibm.com/developerworks/rational/library/5823.html) • RUP Plug-In for COTS Package Delivery V1.0 • RUP Plug-In for WebSphere Business Integrator Modeler V1.0 • RUP for Extreme Programming Plug-Ins-- a very interesting concept (removes everything then adds in XP) • And many, many more U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

9. So lets do a RUP Plug-in • What should we do? • The Plan: • Look at where software development runs into problems. • Analyze how the RUP handles this aspect of the process. • Design a plug-in to improve the process • Finally, implement the plug-in U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

10. Software Development has Problems • Standish Group’s CHAOS report (1994) • 31.1 % of projects canceled before completion • 52.7 % of projects completed but significantly over budget, over time estimates and offered with fewer features. • Only 16.2 % of projects delivered on time, on budget and with original feature set. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

11. Nature of Development Problems • Reasons for canceled projects • Lack of User Involvement 15.9% • Unclear Statement of Requirements 13.0 % • Reason for over budget/schedule/ fewer featured projects • Lack of User Input 12.8% • Incomplete Requirements & Specifications 12.3 % • Changing Requirements & Specifications 11.8% U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

12. Nature of Development Problems • Leffingwell and Widrig (2003) surveyed 3800 software professions: • 50 % indicated two largest software engineering problem were related to: • Requirement specification and • Management of requirements • Requirements errors consume an estimated 25 to 40% of total project budget. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

13. Nature of Development Problems • Common theme in development problems relates to requirements (and user input). • How does RUP address Requirement Quality Assurance? • Only one activity is related to Requirements, that is Review Requirements, which is part of the Requirements Discipline Workflow. • Review Requirements only deals with the management of changing requirements – there is no significant V and V involved. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

14. RUP Requirements Quality Assurance Plug-in Needed • RUP is deficient with respect to Requirements Quality Assurance (RQA) • Solution – design a RUP RQA Plug-in • Add Role, Requirements Quality Controller • Add Five Activities • Add Six Artifacts • Add Requirements Quality Assurance Workflow U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

15. Requirements Quality Assurance Plug-in Activities • Specify Quality Criteria – establish catalog of quality criteria for use cases and requirements • Simulate Requirements – simulate requirements using formal language and methods • Inspect Requirements – formal review of use cases and requirements • Measure Requirements Quality – quantitatively measure quality of use cases and requirements • Execute Use Cases – execute use cases using Petri net analysis U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

16. Requirements Quality Assurance Plug-in Artifacts • The new activities produce six new artifacts: • Requirements Quality Criteria Specification – the set of criteria that must be met by requirements • Requirements Quality Report – describes approach and results of quality assurance activity • Requirements Defect List – deficiencies discovered in requirements • Formal Requirements Specification – translation of natural language based requirements to formal requirements specification language • Measurement Statistics – lists the quantitative assessment of requirements • Petri Net – Petri net used to execute use cases U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

17. Requirements Quality Assurance Plug-in Workflow Detail Verify Requirements U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

18. Integration into Requirements Workflow U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

19. Problem with Tailoring RUP • “In theory there is no difference between theory and practice, but in practice there is!” [Jan L. A. van de Snepscheut] • RUP contains 32 process components • The process components of RUP are highly coupled. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

20. RUP Component Coupling (dependency diagram) U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

21. RUP Coupling • One third of the 32 components are highly coupled. • 21 components have coupling of less than 25 % (low to moderate coupling) • 8 components have coupling of more than 25 % (high coupling) • 3 components have coupling of more than 40 % (very high) This would generally NOT be considered good OO Design! U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

22. Consequences of Coupling • High coupling makes it hard to tailor RUP – particularly if modifying or deleting components • The output of one activity will be a set of artifacts. • These artifacts will be the inputs to other activities. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

23. Changing Activities • If an activity is changed or deleted, • Then • Its artifacts may not be created and / or • Its artifacts may be altered. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

24. Consequence of Changed Activities • Artifacts are the output of activities. • Artifacts are also the input of activities. • If an artifact is not available or significantly changed, then • They will not be available as input for subsequent activities and / or • The subsequent activities will need to be changed to react to changed input artifacts. • In highly coupled systems, one change can result in/require cascading changes. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville

25. Conclusion and Future Work • Rational promotes RUP as a highly customizable framework. • RUP is customizable, but with serious limitation in the case where some of the components are deleted or modified due to high coupling. • Our RQA plug-in was independent, thus it was not hampered by RUP coupling. • This work was done with RUP v6. Recently, RUP v7 has been deployed. We have yet to investigate this new version. U. of Applied Sciences, Darmstadt, DE and U. of Wisconsin - Platteville