Best Practices of Software Engineering

1. Best Practices of Software Engineering

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

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.

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

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

6. Performance Engineer Analyst Project Manager Developer Tester Release Engineer Software Development is a Job for Teams • Challenges • Larger teams • Specialization • Networking • Database • Development paradigms; process! • Distribution • Rapid technology change • Integration of technologies!!!

7. Performance Engineer Analyst Project Manager Tester Release Engineer How Are We Doing? • Many Successes • Too Many Failures

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

9. Treating Symptoms Does Not Solve the Problem Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change insufficient automation Symptoms end-user needs changing requirements modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release Diagnose Know these!!

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

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 Best Practices Address Root Causes Get to the root causes!! Eliminate symptoms to develop repeatable, predictable software; Root Causes Best Practices Commercially developed approaches to developing software that when used in combination strike out at the root causes of software problems.

12. Addressing Root Causes Eliminates the Symptoms 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

13. Best Practices of Software Engineering Develop Iteratively Use ComponentArchitectures Verify Quality Manage Requirements Model Visually Control Changes Know these! Will see this slide over and over…

14. Performance Engineer Analyst Project Manager Developer Tester Release Engineer Best Practices Enable High-Performance Teams • Results • More Successful projects Develop Iteratively Use Component Architectures Manage Requirements Verify Quality Model Visually Control Changes

15. Develop Iteratively Practice 1: Develop Software Iteratively Use ComponentArchitectures Verify Quality Manage Requirements Model Visually Control Changes

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

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?’

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…

19. Waterfall Development Delays Reduction of Risk Requirements Analysis R I S K Design Code & Unit Testing Subsystem Testing System Testing T I M E Notice the delay in identifying, controlling, resolving RISKS! Sometimes results are catastrophic!

20. Iteration 1 Iteration 2 Iteration 3 R R R D D D C C C T T T T I M E 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

21. R I S K Iterative Waterfall Iteration Iteration Iteration Iteration Iteration Iteration Iteration T I M E Iterative Development Accelerates Risk Reduction Mitigate risk early; Risks mitigated during early iterations; Can kill project, if necessary. architectures; technologies; personnel;

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!

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 waterfall model  closely. Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration & Change Mgmt Project Management Environment Note the workflows ALL apply to each iteration. RUP tells us what to do and when; by whom… Preliminary Iteration(s) Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#m Iter.#m+1 Iterations

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

25. Goal: • Deliver top quality software on time, within budget that meets / exceeds the user requirements.