Successfully reported this slideshow.

A01BestPracticesPart3-class.ppt

449 views

Published on

  • Be the first to comment

  • Be the first to like this

A01BestPracticesPart3-class.ppt

  1. 1. Practice 5: Verify Software Quality Control Changes Develop Iteratively Use Component Architectures Manage Requirements Model Visually Quality, as used within Rational Unified Process, is defined as “The characteristic of having demonstrated the achievement of producing a product which meets or exceeds agreed upon requirements as measured by agreed upon measures and criteria And is produced by an agreed upon process . If done this way, the process can be repeated and managed In most organizations, testing accounts for 30-50% of development costs! Yet most people believe software is not adequately tested when delivered. Testing is difficult; complete testing is impossible; a good process and automated tools help! Verify Quality
  2. 2. Practice 5: Verify Software Quality Software problems are 100 to 1000 times more costly to find and repair after deployment Development Deployment Cost Test early and continuously! Test functionality, reliability; performance; Test architectural decisions early.
  3. 3. Iterative Development Permits Continuous Testing T I M E Test Test Test Iteration 1 Iteration 2 Iteration 3 T C D R T C D R T C D R Test Life Cycle Evaluate Plan Design Implement Execute Evaluate Plan Design Implement Execute Evaluate Plan Design Implement Execute
  4. 4. Iterative Development – and Continuous Testing (cont.) <ul><li>Rather than test one time, spread testing out continuously. </li></ul><ul><ul><li>Part of each iteration – BUT (see below) </li></ul></ul><ul><li>Each iteration produces an executable release ( not a product release …) </li></ul><ul><ul><li>Don’t think of an ‘executable’ as just an .exe or .dll. The executables may be part of an architecture….. </li></ul></ul><ul><li>Each iteration is tested and integrated into an evolving application. </li></ul><ul><li>Note: Each ‘phase’ has iteration(s), and each phase has milestones! (A phase may have zero or more iterations prior to arriving at the phase milestone!) </li></ul><ul><li>Be careful: The ‘ degree ’ of R, D, C, T depends on which phase the iteration is in! </li></ul><ul><ul><li>See your drawings of the RUP (There are MANY). See pg. 66 in RUP, third edition, as one of many examples…) Keep this handy! Will be referencing this many times. </li></ul></ul>
  5. 5. More…recall – talking about Verifying Quality <ul><li>Cannot ‘engineer in’ quality; Must be threaded throughout development! </li></ul><ul><li>Notice: Continuous Testing and integration! </li></ul><ul><ul><li>Distributes testing…. </li></ul></ul><ul><li>At end, entire system tested as a whole. </li></ul><ul><li>Many errors can be found early and fixed while repair costs are inexpensive </li></ul><ul><li>Architectural decisions (key decisions) tested early avoiding disastrous problems later. </li></ul><ul><li>These features greatly reduce risks and liability of delivering poor quality systems. </li></ul><ul><li>Early iterations are used to mitigate risk and address core functionalities (whether in elaboration, construction…) </li></ul>
  6. 6. Testing in an Iterative Environment Requirements Test Suite 1 Iteration 2 Iteration 3 Iteration 4 Test Suite 2 Test Suite 3 Test Suite 4 Iteration 1 Automated Tests Continuous integration!!! (one of the major problems of SDLC!) We will produce automated tests. As new requirements are added in iterations, new tests are generated and run. This means that some tests will be rerun – part of ‘Regression Testing.’
  7. 7. Automation Reduces Testing Time and Effort One Manual Test Cycle 13,000 Tests 2 Weeks 6 People 13,000 Tests 6 hours 1 Person One Manual Test Cycle 13,000 Tests 2 Weeks 6 People Test Automation Manual preparation of tests is very expensive and usually results in missed ‘opportunities.’ Run More Tests More Often
  8. 8. Dimensions of Software Quality Functionality Reliability Application Performance System Performance Does my app do what’s required? Does my app leak memory? Does my app respond acceptably? Does my system perform under production load? Test cases for each scenario implemented Analysis tools and code instrumentation Check performance for each use-case/scenario implemented Test performance of all use-cases under authentic and worst-case load Type Why? How? For each iteration, do the ‘above’ software quality checks. Remember: tests are ‘driven’ by Use Cases and Supplementary Specifications!
  9. 9. Problems Addressed by Verifying Quality Testing provides objective project status assessment Objective assessment exposes inconsistencies early ( continuous integration helps!) Testing and verification are focused on high risk areas Defects are found earlier and are less expensive to fix (because ‘testing’ is distributed… Automated testing tools provide testing for reliability, functionality, and performance Root Causes Solutions <ul><li>Insufficient requirements </li></ul><ul><li>Ambiguous communications </li></ul><ul><li>Brittle architectures </li></ul><ul><li>Overwhelming complexity </li></ul><ul><li>Subjective assessment </li></ul><ul><li>Undetected inconsistencies </li></ul><ul><li>Poor testing </li></ul><ul><li>Waterfall development </li></ul><ul><li>Uncontrolled change </li></ul><ul><li>Insufficient automation </li></ul>
  10. 10. Practice 6: Control Changes to Software Develop Iteratively Use Component Architectures Manage Requirements Model Visually Verify Quality Must recognize that we CANNOT STOP CHANGE The only ‘constant’ is ‘change!’ But, we must be able to Manage Change! Must control How and When control is introduced and who introduces the changes. This DOES NOT MEAN that we absolutely accept ALL changes, But…(Discuss!) Want a process that can respond to change…(RUP) Must synchronize Change across development teams and locations too. (What impacts do proposed changes have on our architecture!) Control Changes
  11. 11. Practice 6: Control Changes to Software <ul><li>Multiple developers </li></ul><ul><li>Multiple teams </li></ul><ul><li>Multiple sites </li></ul><ul><li>Multiple iterations </li></ul><ul><li>Multiple releases </li></ul><ul><li>Multiple projects </li></ul><ul><li>Multiple platforms </li></ul>Without explicit control, parallel development degrades to chaos!!!! May have multiple developers organized into different teams at multiple sites all working together on multiple iterations, releases, products, and platforms (mostly based on the software architecture)
  12. 12. Three Major Aspects of a CM System Controlling Change involves a Change Management System and a Configuration Management System for version control releases, etc. (this is beyond where we will go in this course…) CR = change request ( version control; evolving products…)
  13. 13. Concepts of Configuration & Change Management <ul><li> Decompose the architecture into subsystems and assign responsibility for each subsystem to a team </li></ul><ul><li>Establish secure workspaces for each developer </li></ul><ul><ul><li>Provide isolation from changes made in other workspaces </li></ul></ul><ul><ul><li>Control all software artifacts - models, code, docs, etc. </li></ul></ul><ul><li>Establish an integration workspace </li></ul><ul><li>Establish an enforceable change control mechanism </li></ul><ul><li>Know which changes appear in which releases </li></ul><ul><li>Release a tested baseline at the completion of each iteration </li></ul><ul><ul><li>Versioning; baselines; … </li></ul></ul>
  14. 14. Change Control Supports All Other Best Practices <ul><li>Develop iteratively </li></ul><ul><li>Manage requirements </li></ul><ul><li>Use component architectures </li></ul><ul><li>Model visually </li></ul><ul><li>Verify quality </li></ul><ul><li>Progress is incremental only if changes to artifacts are controlled </li></ul><ul><li>To avoid scope creep , assess the impact of all proposed changes before approval </li></ul><ul><li>Components must be reliable, i.e., the correct versions of all constituent parts found </li></ul><ul><li>To assure convergence, incrementally control models as designs stabilize </li></ul><ul><li>Tests are only meaningful if the versions of the items under test are known and the items protected from changes </li></ul>Italicized items – verbally discussed in class. Not necessarily more important than others…
  15. 15. Problems Addressed by Controlling Changes <ul><li>Requirements change workflow is defined and repeatable </li></ul><ul><li>Change requests facilitate clear communications </li></ul><ul><li>Isolated workspaces reduce interference from parallel work </li></ul><ul><li>Change rate statistics are good metrics for objectively assessing project status </li></ul><ul><li>Workspaces contain all artifacts, facilitating consistency </li></ul><ul><li>Change propagation is controlled </li></ul><ul><li>Changes maintained in a robust, customizable system </li></ul>Root Causes Solutions <ul><li>Insufficient requirements </li></ul><ul><li>Ambiguous communications </li></ul><ul><li>Brittle architectures </li></ul><ul><li>Overwhelming complexity </li></ul><ul><li>Subjective assessment </li></ul><ul><li>Undetected inconsistencies </li></ul><ul><li>Poor testing </li></ul><ul><li>Waterfall development </li></ul><ul><li>Uncontrolled change </li></ul><ul><li>Insufficient automation </li></ul>
  16. 16. Best Practices Reinforce Each Other Control Changes Use Component Architectures Model Visually Verify Quality Ensures users involved as requirements evolve Validates architectural decisions early on. Drives development, planning, change control. …. Addresses complexity of design/implementation incrementally Need tools/support environment! Measures quality early and often Continuous testing and integration Evolves baselines incrementally Architecture  teams  localizing changes; Need CMS, Conf Control… Manage Requirements Remember: these best practices yield the best results WHEN USED COLLECTIVELY! Develop Iteratively
  17. 17. Summary: Best Practices of Software Engineering <ul><li>The result is software that is </li></ul><ul><ul><li>On Time </li></ul></ul><ul><ul><li>On Budget </li></ul></ul><ul><ul><li>Meets Users Needs </li></ul></ul>Project Manager Performance Engineer Release Engineer Analyst Developer Tester Control Changes Develop Iteratively Use Component Architectures Manage Requirements Model Visually Verify Quality

×