Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 1 Best Practices of Software Engineering

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 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 D Copyright  1998 Rational Software, all rights reserved 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 D Copyright  1998 Rational Software, all rights reserved 4 Software Development Situation Analysis World economies increasingly software dependent Applications expanding in size, complexity, & distribution Business demands increased productivity & quality in less time Not enough qualified people

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 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 D Copyright  1998 Rational Software, all rights reserved 6 Software Development is a Job for Teams Project Manager Performance Engineer Release Engineer AnalystDeveloper Tester Challenges Larger teams Specialization Networking Database Development paradigms; process! Distribution Rapid technology change Integration of technologies!!!

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 7 How Are We Doing? Project Manager Performance Engineer Release Engineer AnalystTester Many Successes Too Many Failures

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 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 D Copyright  1998 Rational Software, all rights reserved 9 Symptoms end-user needs changing requirements modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change insufficient automation Diagnose Treating Symptoms Does Not Solve the Problem Know these!!

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 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 D Copyright  1998 Rational Software, all rights reserved 11  Insufficient requirements  Ambiguous communications  Brittle architectures  Overwhelming complexity  Subjective assessment  Undetected inconsistencies  Poor testing  Waterfall development  Uncontrolled change  Insufficient automation  Develop iteratively  Manage requirements  Use component architectures  Model the software visually  Verify quality  Control changes Root Causes Best Practices Best Practices Address Root Causes Get to the root causes!! Eliminate symptoms to develop repeatable, predictable software; Commercially developed approaches to developing software that when used in combination strike out at the root causes of software problems.

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 12 Symptoms end-user needs changing requirements modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change insufficient automation Best Practices develop iteratively manage requirements use component architectures model the software visually verify quality control changes Addressing Root Causes Eliminates the Symptoms

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 13 Develop Iteratively Control Changes Use Component Architectures ManageRequirements ModelVisually VerifyQuality Best Practices of Software Engineering Know these! Will see this slide over and over…

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 14 Best Practices Enable High-Performance Teams Project Manager Performance Engineer Release Engineer Analyst Developer Tester Results More Successful projects Control Changes Develop Iteratively UseComponentArchitectures ManageRequirements ModelVisually VerifyQuality

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 15 Practice 1: Develop Software Iteratively Develop Iteratively Control Changes Use Component Architectures Manage Requirements Verify Quality

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 16 The time and money spent implementing a faulty design are not recoverable 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! $$$

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 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 D Copyright  1998 Rational Software, all rights reserved 18 T I M E Traditional Waterfall Development Subsystem Testing System Testing Code & Unit Testing Design Requirements Analysis 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 D Copyright  1998 Rational Software, all rights reserved 19 RISKRISK T I M E Waterfall Development Delays Reduction of Risk Subsystem Testing System Testing Code & Unit Testing Design Requirements Analysis Notice the delay in identifying, controlling, resolving RISKS! Sometimes results are catastrophic!

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 20 Apply the Waterfall Iteratively to System Increments  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 T C D R T I M E Iteration 1Iteration 2Iteration 3 T C D R T C D R

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 21 Iterative Development Accelerates Risk Reduction Waterfall Iterative RISKRISK T I M E Iteration Mitigate risk early; Risks mitigated during early iterations; Can kill project, if necessary. architectures; technologies; personnel;

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 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 D Copyright  1998 Rational Software, all rights reserved 23 Apply Best Practices Throughout the Life Cycle Project Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration & Change Mgmt Requirements ElaborationTransitionInceptionConstruction 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. Match the waterfall model  closely. Note the workflows ALL apply to each iteration. RUP tells us what to do and when; by whom…

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 24 Enables and encourages user feedback Serious misunderstandings evident early in the life cycle Development focuses on critical issues – break it down! Objective assessment thru testing Inconsistencies detected early Testing starts earlier – continuous! Risks identified and addressed early - via planned iterations! Problems Addressed by Iterative Development Root Causes Solutions  Insufficient requirements  Ambiguous communications  Brittle architectures  Overwhelming complexity  Subjective assessment  Undetected inconsistencies  Poor testing  Waterfall development  Uncontrolled change  Insufficient automation

Unified Software Practices v D Copyright  1998 Rational Software, all rights reserved 25 Goal:  Deliver top quality software on time, within budget that meets / exceeds the user requirements.