a01bestpracticespart1-class.ppt

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

Upload: softwarecentral

Post on 07-Dec-2014

1.481 views

Category:

Documents


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 1

Best Practices of Software Engineering

Page 2: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 2

Objectives: Best Practices of Software Engineering

Explore the symptoms and root causes of software Explore the symptoms and root causes of software development problemsdevelopment problems

Explain Rational’s Explain Rational’s six best practicessix best practices for software for software developmentdevelopment

Look at how Rational’s best practices address the Look at how Rational’s best practices address the root causes of software development problemsroot causes of software development problems

Page 3: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 3

Questions:

What is software engineering? What is software engineering? Is it programming?Is it programming? What part of a development effort is programming?What part of a development effort is programming? What part of an application’s life cycle is initial programming?What part of an application’s life cycle is initial programming? What do you know about Maintenance?What do you know about Maintenance? Percentage of lifecycle costs?Percentage of lifecycle costs? What do you think ‘best practices’ mean?What do you think ‘best practices’ mean? Develop software in a Develop software in a repeatable and predictablerepeatable and predictable manner. manner. Where did they come from and are they really ‘best?’Where did they come from and are they really ‘best?’ Commercially proven approaches to software development, that, when Commercially proven approaches to software development, that, when

used in combination, strike out at the root problems of software used in combination, strike out at the root problems of software development.development.

Commonly used in industry.Commonly used in industry.

Page 4: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 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

Page 5: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 5

Comments:

$250 billion annually in US.$250 billion annually in US. Over 175,000 projects!Over 175,000 projects! Complexity, size, distribution, importance push our limits.Complexity, size, distribution, importance push our limits. Business pushes these limits:Business pushes these limits:

Great demands for rapid development and deployment We cannot keep pace with demandsWe cannot keep pace with demands 200,000 to 400,000 developer jobs open.200,000 to 400,000 developer jobs open. Develop applications Develop applications

On time Within budget Meets the users’ requirements

Page 6: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 6

Software Development is a Job for Teams

ProjectManager

PerformanceEngineer

ReleaseEngineer

Analyst

Developer

Tester

Challenges

• Larger teams

• Specialization

•Networking

•Database

•Development paradigms; process!

• Distribution

• Rapid technology change

• Integration of technologies!!!

Page 7: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 7

How Are We Doing?

ProjectManager

PerformanceEngineer

ReleaseEngineer

Analyst

Tester

• Many Successes

• Too Many Failures

Page 8: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 8

Symptoms of Software Development Problems

Inaccurate understandingInaccurate understanding of end-user needs of end-user needs Inability to deal with Inability to deal with changing requirementschanging requirements Modules that don’t fit togetherModules that don’t fit together Software that’s hard to maintain or extendSoftware that’s hard to maintain or extend Late discovery of Late discovery of serious project flawsserious project flaws Poor software qualityPoor software quality Unacceptable software performanceUnacceptable software performance Team members in each other’s way, unable to reconstruct Team members in each other’s way, unable to reconstruct

who changed what, when, where, why who changed what, when, where, why An untrustworthy build-and-release processAn untrustworthy build-and-release process

Page 9: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 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!!

Page 10: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 10

Root Causes of Software Development Problems(according to Rational Software Corporation)

Insufficient requirements management – Insufficient requirements management – leads to scope creep

Ambiguous and imprecise communicationsAmbiguous and imprecise communications Brittle architectures – Brittle architectures –

poor response to changes; little chance for reuse Overwhelming complexityOverwhelming complexity Undetected inconsistencies among requirements, designs, and Undetected inconsistencies among requirements, designs, and

implementationsimplementations Insufficient testing – 80% tested? Out the door!!!Insufficient testing – 80% tested? Out the door!!! Subjective project status assessmentSubjective project status assessment Delayed risk reduction due to waterfall development Delayed risk reduction due to waterfall development Insufficient automationInsufficient automation

Page 11: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 11

Insufficient requirementsInsufficient requirements Ambiguous communicationsAmbiguous communications Brittle architecturesBrittle architectures Overwhelming complexityOverwhelming complexity Subjective assessment Subjective assessment Undetected inconsistenciesUndetected inconsistencies Poor testingPoor testing Waterfall developmentWaterfall development Uncontrolled changeUncontrolled change Insufficient automationInsufficient automation

Develop iterativelyDevelop iteratively Manage requirementsManage requirements Use component architecturesUse component architectures Model the software visuallyModel the software visually Verify qualityVerify quality Control changesControl changes

Root CausesRoot Causes Best PracticesBest Practices

Best Practices Address Root CausesGet 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.

Page 12: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 12

Symptomsend-user needs

changing requirements

modules don’t fit

hard to maintain

late discovery

poor quality

poor performance

colliding developers

build-and-release

Root Causesinsufficient requirements

ambiguous communications

brittle architectures

overwhelming complexity

undetected inconsistencies

poor testing

subjective assessment

waterfall development

uncontrolled change

insufficient automation

Best Practicesdevelop iteratively

manage requirements

use component architectures

model the software visually

verify quality

control changes

Addressing Root Causes Eliminates the Symptoms

Page 13: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 13

Develop IterativelyDevelop Iteratively

Control ChangesControl Changes

Use Use ComponentComponent

ArchitecturesArchitectures

Manage Manage RequirementsRequirements

Model Model VisuallyVisually

VerifyVerifyQualityQuality

Best Practices of Software Engineering

Know these!Will see this slide over and over…

Page 14: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 14

Best Practices Enable High-Performance Teams

ProjectManager

PerformanceEngineer

ReleaseEngineer

Analyst

Developer

Tester

Results

• More Successful projects

Control ChangesControl Changes

Develop IterativelyDevelop Iteratively

UseUseComponentComponent

ArchitecturesArchitecturesManageManage

RequirementsRequirementsModelModel

VisuallyVisually VerifyVerify

QualityQuality

Page 15: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 15

Practice 1: Develop Software Iteratively

Develop IterativelyDevelop Iteratively

Control Changes

Use Component

Architectures

Manage Requirements

Model Visually

VerifyQuality

Page 16: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 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 An initial design will likely be flawed with respect to its key

requirements. Requirements rarely requirements. Requirements rarely fully knownfully known up front! up front! Late-phase discovery of design defects results in costly Late-phase discovery of design defects results in costly

over-runs and/or project cancellation over-runs and/or project cancellation Oftentimes requirements change – during development!

$$$

Page 17: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 17

Additional Comments:

While large projects are more prone to cost overruns, While large projects are more prone to cost overruns, medium-size/small projects are vulnerable to cancellation. medium-size/small projects are vulnerable to cancellation.

The key reasons continue to be 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?’Where does it say ‘programmer?’

Page 18: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 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…

Page 19: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 19

RISK

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!

Page 20: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 20

Apply the Waterfall Iteratively to System Increments

Earliest iterations address greatest risksEarliest 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 systemEach iteration produces an executable release, an additional increment of the system Each iteration includes integration and testEach iteration includes integration and test

TC

DR

T I M E

Iteration 1 Iteration 2 Iteration 3

TC

DR

TC

DR

Page 21: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 21

Iterative Development Accelerates Risk Reduction

WaterfallIterative

R

I

S

K

T I M E

Iteration Iteration Iteration Iteration Iteration Iteration Iteration

Mitigate risk early; Risks mitigated during early iterations; Can kill project, if necessary. architectures; technologies; personnel;

Page 22: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 22

Iterative Development Characteristics

Critical risks are resolved before making large investmentsCritical risks are resolved before making large investments Initial iterations enable early user feedbackInitial iterations enable early user feedback

Easy to resolve problems early. Encourages user feedback in meaningful ways

Testing and integration are continuousTesting and integration are continuous – assures successful – assures successful integration (parts all fit together) integration (parts all fit together) Continuous testing.

Objective milestones provide short-term focusObjective milestones provide short-term focus Progress is measured by assessing implementationsProgress is measured by assessing implementations Partial implementations can be deployedPartial 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!No big-bang approach!

Page 23: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 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

PhasesProcess Workflows

Iterations

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration & Change Mgmt

Requirements

Elaboration TransitionInception Construction

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…

Page 24: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 24

Enables and encouragesEnables and encourages user user feedbackfeedback

Serious Serious misunderstandingsmisunderstandings evident evident early in the life cycleearly in the life cycle

Development focuses on Development focuses on critical critical issues – break it down!issues – break it down!

Objective assessment thru testing Objective assessment thru testing

Inconsistencies detected earlyInconsistencies detected early

Testing starts earlier – continuous!Testing starts earlier – continuous!

Risks identified and addressed Risks identified and addressed early - via planned iterations!early - via planned iterations!

Problems Addressed by Iterative Development

Root CausesRoot Causes SolutionsSolutions Insufficient requirementsInsufficient requirements Ambiguous Ambiguous

communicationscommunications Brittle architecturesBrittle architectures Overwhelming complexityOverwhelming complexity Subjective assessmentSubjective assessment Undetected inconsistenciesUndetected inconsistencies Poor testingPoor testing Waterfall developmentWaterfall development Uncontrolled changeUncontrolled change Insufficient automationInsufficient automation

Page 25: A01BestPracticesPart1-class.ppt

Unified Software Practices v 5.0 - DCopyright 1998 Rational Software, all rights reserved 25

Goal:

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