0% found this document useful (0 votes)
14 views25 pages

A01BestPracticesPart1 Class

Uploaded by

Mahi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views25 pages

A01BestPracticesPart1 Class

Uploaded by

Mahi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 25

Best Practices of Software

Engineering

Unified Software Practices v 5.0 - D


Copyright  1998 Rational Software, all rights reserved 1
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
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
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
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
Software Development is a Job for Teams
Challenges
• Larger teams
• Specialization
Performance
Engineer
•Networking
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
How Are We Doing?

Performance

• Many Successes Analyst


Engineer

• Too Many Failures


Project
Manager

Tester

Release
Engineer

Unified Software Practices v 5.0 - D


Copyright  1998 Rational Software, all rights reserved 7
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
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
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


Copyright  1998 Rational Software, all rights reserved 10
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
Addressing Root Causes Eliminates the Symptoms

Symptoms Root Causes Best Practices


end-user needs insufficient requirements develop iteratively
changing requirements ambiguous manage requirements
communications
modules don’t fit use component
brittle architectures architectures
hard to maintain
overwhelming complexity model the software
late discovery
undetected inconsistencies visually
poor quality
poor testing verify quality
poor performance
subjective assessment control changes
colliding developers
build-and-release waterfall development
uncontrolled change
insufficient automation

Unified Software Practices v 5.0 - D


Copyright  1998 Rational Software, all rights reserved 12
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
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
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
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
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
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
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
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
Iterative Development Accelerates Risk Reduction

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

You might also like