Your SlideShare is downloading. ×
A01BestPracticesPart1-class.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

A01BestPracticesPart1-class.ppt

1,163
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,163
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Best Practices of Software Engineering Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 1
  • 2. Objectives: Best Practices of Software Engineering  Explore the symptoms and root causes of software development problems  Explain Rational’s six best practices for software development  Look at how Rational’s best practices address the root causes of software development problems Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 2
  • 3. Questions:  What is software engineering?  Is it programming?  What part of a development effort is programming?  What part of an application’s life cycle is initial programming?  What do you know about Maintenance?  Percentage of lifecycle costs?  What do you think ‘best practices’ mean?  Develop software in a repeatable and predictable manner.  Where did they come from and are they really ‘best?’  Commercially proven approaches to software development, that, when used in combination, strike out at the root problems of software development.  Commonly used in industry. Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 3
  • 4. Software Development Situation Analysis World economies Applications expanding increasingly software in size, complexity, & dependent distribution Business demands Not enough qualified increased productivity & people quality in less time Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 4
  • 5. Comments:  $250 billion annually in US.  Over 175,000 projects!  Complexity, size, distribution, importance push our limits.  Business pushes these limits:  Great demands for rapid development and deployment  We cannot keep pace with demands  200,000 to 400,000 developer jobs open.  Develop applications  On time  Within budget  Meets the users’ requirements Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 5
  • 6. Software Development is a Job for Teams Challenges • Larger teams • Specialization Performance •Networking Engineer Analyst •Database •Development Project paradigms; process! Manager Developer • Distribution Tester • Rapid technology change Release Engineer • Integration of technologies!!! Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 6
  • 7. How Are We Doing? Performance • Many Successes Engineer Analyst • Too Many Failures Project Manager Tester Release Engineer Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 7
  • 8. Symptoms of Software Development Problems  Inaccurate understanding of end-user needs  Inability to deal with changing requirements  Modules that don’t fit together  Software that’s hard to maintain or extend  Late discovery of serious project flaws  Poor software quality  Unacceptable software performance  Team members in each other’s way, unable to reconstruct who changed what, when, where, why  An untrustworthy build-and-release process Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 8
  • 9. Treating Symptoms Does Not Solve the Problem Root Causes Symptoms insufficient requirements end-user needs ambiguous changing communications requirements brittle architectures modules don’t fit overwhelming hard to maintain complexity late discovery undetected poor quality inconsistencies poor poor testing performance subjective colliding assessment developers waterfall build-and-release development Diagnose uncontrolled change insufficient automation Know these!! Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 9
  • 10. Root Causes of Software Development Problems (according to Rational Software Corporation)  Insufficient requirements management –  leads to scope creep  Ambiguous and imprecise communications  Brittle architectures –  poor response to changes; little chance for reuse  Overwhelming complexity  Undetected inconsistencies among requirements, designs, and implementations  Insufficient testing – 80% tested? Out the door!!!  Subjective project status assessment  Delayed risk reduction due to waterfall development  Insufficient automation Unified Software Practices v 5.0 - D 10 Copyright 1998 Rational Software, all rights reserved
  • 11. Best Practices Address Root Causes Get to the root causes!! Eliminate symptoms to develop repeatable, predictable software; Root Causes Best Practices  Insufficient requirements  Develop iteratively  Ambiguous communications  Manage requirements  Brittle architectures  Use component architectures  Overwhelming complexity  Model the software visually  Subjective assessment  Verify quality  Undetected inconsistencies  Control changes  Poor testing Commercially developed approaches to  Waterfall development developing software that when used in combination strike out at the root causes  Uncontrolled change of software problems.  Insufficient automation Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 11
  • 12. Addressing Root Causes Eliminates the Symptoms Symptoms Root Causes Best Practices end-user needs insufficient requirements develop iteratively changing ambiguous manage requirements requirements communications use component modules don’t fit brittle architectures architectures hard to maintain overwhelming complexity model the software late discovery undetected visually poor quality inconsistencies verify quality poor performance poor testing control changes colliding developers subjective assessment build-and-release waterfall development uncontrolled change insufficient automation Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 12
  • 13. Best Practices of Software Engineering Develop Iteratively Use Manage Model Verify Component Visually Requirements Architectures Quality Control Changes Know these! Will see this slide over and over… Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 13
  • 14. Best Practices Enable High-Performance Teams Results Performance • More Successful Engineer projects Analyst Project Manager Developer Develop Iteratively Tester Use Manage Component Model Verify Requirements Architectures Visually Quality Release Engineer Control Changes Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 14
  • 15. Practice 1: Develop Software Iteratively Develop Iteratively Use Manage Model Verify Component Visually Requirements Architectures Quality Control Changes Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 15
  • 16. Practice 1: Develop Software Iteratively  An initial design will likely be flawed with respect to its key requirements. Requirements rarely fully known up front!  Late-phase discovery of design defects results in costly over-runs and/or project cancellation  Oftentimes requirements change – during development! $$$ The time and money spent implementing a faulty design are not recoverable Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 16
  • 17. Additional Comments:  While large projects are more prone to cost overruns, medium-size/small projects are vulnerable to cancellation.  The key reasons continue to be  poor project planning and management,  shortage of technical and project management expertise,  lack of technology infrastructure,  disinterested senior management, and  inappropriate project teams.”  Where does it say ‘programmer?’ Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 17
  • 18. Traditional Waterfall Development Requirements Analysis Design Code & Unit Testing Subsystem Testing System Testing T I M E Been in use for over 30 years. Phases in lock-step. Assumption: when Design starts, Requirements are firm; When Code and Testing starts, Design is firm and complete; etc. All FALSE in practice! True only in well-understood application domains; prior experiences, etc. Leads to missed deliveries, cost overruns, poor quality of delivered software and more… Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 18
  • 19. Waterfall Development Delays Reduction of Risk Requirements R Analysis I Design S K Code & Unit Testing Subsystem Testing System Testing T I M E Notice the delay in identifying, controlling, resolving RISKS! Sometimes results are catastrophic! Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 19
  • 20. Apply the Waterfall Iteratively to System Increments Iteration 1 Iteration 2 Iteration 3 R R R D D D C C C T T T T I M E  Earliest iterations address greatest risks  (executable, architectural prototype?)  Highest priorities first; mitigate risk early; key functionality first.  Each iteration produces an executable release, an additional increment of the system  Each iteration includes integration and test Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 20
  • 21. Iterative Development Accelerates Risk Reduction R I S Iterative Waterfall K Iteration Iteration Iteration Iteration Iteration Iteration Iteration T I M E Mitigate risk early; Risks mitigated during early iterations; Can kill project, if necessary. architectures; technologies; personnel; Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 21
  • 22. Iterative Development Characteristics  Critical risks are resolved before making large investments  Initial iterations enable early user feedback  Easy to resolve problems early.  Encourages user feedback in meaningful ways  Testing and integration are continuous – assures successful integration (parts all fit together)  Continuous testing.  Objective milestones provide short-term focus  Progress is measured by assessing implementations  Partial implementations can be deployed  Waterfall method – no delivery  Incremental development? May be some great values in delivering key parts of application. Critical components delivered first?  No big-bang approach! Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 22
  • 23. Apply Best Practices Throughout the Life Cycle We will use the Rational Unified Process (RUP) as our ‘process’ together with the Unified Modeling Language (UML) and Rational Rose Enterprise Edition modeling tool. Phases Process Workflows Inception Elaboration Construction Transition Match the Business Modeling waterfall Requirements model  closely. Analysis & Design Implementation Test Deployment Supporting Workflows Configuration & Change Mgmt Project Management Environment Note the workflows ALL apply Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 to each iteration. RUP tells us what to do and when;v 5.0 - D whom… by Unified Software Practices Copyright 1998 Rational Software, all rights reserved 23 Iterations
  • 24. Problems Addressed by Iterative Development Root Causes Solutions  Insufficient requirements Enables and encourages user feedback  Ambiguous communications Serious misunderstandings evident early in the life cycle  Brittle architectures  Overwhelming complexity Development focuses on critical issues – break it down!  Subjective assessment  Undetected Objective assessment thru testing inconsistencies Inconsistencies detected early  Poor testing  Waterfall development Testing starts earlier – continuous!  Uncontrolled change Risks identified and addressed  Insufficient automation early - via planned iterations! Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 24
  • 25. Goal:  Deliver top quality software on time, within budget that meets / exceeds the user requirements. Unified Software Practices v 5.0 - D Copyright 1998 Rational Software, all rights reserved 25