1 / 19

Continuing Best Practices

Continuing Best Practices. Slide information taken in large part from former Rational Corporation slides considerably modified and supplemented for classroom use. Verify Quality. Practice 5: Verify Software Quality. Develop Iteratively. Use Component Architectures. Manage Requirements.

marianne
Download Presentation

Continuing Best Practices

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. Continuing Best Practices • Slide information taken in large part from former Rational Corporation slides considerably modified and supplemented for classroom use.

  2. Verify Quality Practice 5: Verify Software Quality Develop Iteratively Use ComponentArchitectures Manage Requirements Model Visually Control Changes 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!

  3. Practice 5: Verify Software Quality Software problems are 100 to 1000 times more costly to find and repair after deployment Cost Development Deployment One of the ways to improve quality: Test early and continuously! Test functionality, reliability; performance; Test architectural decisions early.

  4. R R R D D D C C C T T T Plan Plan Plan Design Design Design Test Life Cycle Implement Implement Implement Execute Execute Execute Assess! Assess Assess! Iterative Development Permits ContinuousTesting – ensuring higher Quality Iteration 1 Iteration 2 Iteration 3 Test Test Test T I M E

  5. Iterative Development – and Continuous Testing (cont.) • Rather than test one time, spread testing out continuously. • Part of each iteration – BUT (see below) • Each iteration produces an executable release (not a product release…) • Don’t think of an ‘executable’ as just an .exe or .dll. The executables may be part of an architecture…… • Each iteration is tested and integrated into an evolving application. • 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!) • Be careful: The ‘extent (how much)’ of R, D, C, T depends on which phase the iteration is in! (See your drawings of the RUP)

  6. More…recall – talking about Verifying Quality • Cannot ‘engineer in’ quality; Must be threaded throughout development! • Notice: Continuous Testing and integration! • Distributes testing….ensures higher quality • At end, entire system tested as a whole. • Many errors can be found early and fixed while repair costs are inexpensive • Architectural decisions (key decisions) tested early avoiding disastrous problems later. (What do we mean by architectural decisions? What might these be??) • These features greatly reduce risks and liability of delivering poor quality systems.

  7. Testing in an Iterative Environment Iteration 1 Iteration 2 Iteration 3 Iteration 4 Requirements 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.’ Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 Automated Tests

  8. Quality – What is it? • It is an elusive term • Means different things to different people Next few slides from OOSE text slides; modified

  9. Software Quality... • Usability - Users can learn it fast and get their job done easily • Efficiency - It doesn’t waste resources like CPU time and memory • Reliability - It does what it is required to do without failing (MTBF, MTTR…) • Maintainability - It can be easily changed • Reusability - Its parts can be used in other projects, so reprogramming is not needed

  10. QUALITY SOFTWARE Software Quality...again, means different things to differentstakeholders Customer: User: solves problems at easy to learn; an acceptable cost in efficient to use; terms of money paid and helps get work done resources used Development manager: Developer: sells more and easy to design; pleases customers easy to maintain; while costing less easy to reuse its parts to develop and maintain

  11. Software Quality • The different qualities can conflict. • Increasing efficiency can reduce maintainability or reusability • Increasing usability can reduce efficiency • Setting objectives for quality is a key engineering activity • Then design to meet these objectives • Avoids ‘over-engineering’ which wastes money • Obtain the highest possible reliability using a fixed budget

  12. Short Term Vs. Long Term Quality • Short term: • Does the software meet the customer’s immediate needs? • Is it sufficiently efficient for the volume of data we have today? • Long term: • Maintainability • Customer’s future needs • Scalability

  13. Dimensions of Software Quality Type Why? How? 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 For each iteration, do the ‘above’ software quality checks. Remember: tests are ‘driven’ by Use Cases and Supplementary Specifications! Back to Rational…

  14. Problems Addressed by Verifying Quality Root Causes Solutions • Insufficient requirements • Ambiguous communications • Brittle architectures • Overwhelming complexity • Subjective assessment • Undetected inconsistencies • Poor testing • Waterfall development • Uncontrolled change • Insufficient automation 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

  15. Control Changes Practice 6: Control Changes to Software Develop Iteratively Use ComponentArchitectures Verify Quality Manage Requirements Model Visually 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!)

  16. Practice 6: Control Changes to Software • Consider: we often have: • Multiple developers • Multiple teams • Multiple sites • Multiple iterations • Multiple releases • Multiple projects • Multiple platforms 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) Without explicit control, parallel development degrades to chaos!!!!

  17. Requirements change workflow is defined and repeatable Change requests facilitate clear communications Isolated workspaces reduce interference from parallel work Change rate statistics are good metrics for objectively assessing project status Workspaces contain all artifacts, facilitating consistency Change propagation is controlled Changes maintained in a robust, customizable system Problems Addressed by Controlling Changes Root Causes Solutions • Insufficient requirements • Ambiguous communications • Brittle architectures • Overwhelming complexity • Subjective assessment • Undetected inconsistencies • Poor testing • Waterfall development • Uncontrolled change • Insufficient automation

  18. Develop Iteratively Best Practices Reinforce Each Other Ensures users involved as requirements evolve Manage Requirements What does iterative development do?? Use ComponentArchitectures Validates architectural decisions early on. Drives development, planning, change control. …. Addresses complexity of design/implementation incrementally. Need tools/support environment! Model Visually Measures quality early and often. Continuous testing and integration Verify Quality Evolves baselines incrementally Architecture  teams  localizing changes; Need CMS, Conf Control… Control Changes Remember: these best practices yield the best results WHEN USED COLLECTIVELY!

  19. Performance Engineer Develop Iteratively Analyst Use ComponentArchitectures Model Visually Verify Quality Manage Requirements Project Manager Developer Control Changes Tester Release Engineer Summary: Best Practices of Software Engineering The result is software that is • On Time • On Budget • Meets Users Needs

More Related