• No results found

Best Practices of Software Engineering

N/A
N/A
Protected

Academic year: 2021

Share "Best Practices of Software Engineering"

Copied!
25
0
0

Loading.... (view fulltext now)

Full text

(1)

Best Practices of Software

Engineering

(2)

Unified Software Practices v 5.0 - D

2

Objectives: Best Practices of Software Engineering

 Explore the symptoms and root Explore the symptoms and root causes of software development causes of software development

problems problems

 Explain Rational’s Explain Rational’s six best practices six best practices for software development

for software development

 Look at how Rational’s best practices Look at how Rational’s best practices address the root causes of software address the root causes of software

development problems

development problems

(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 What part of an application’s life cycle is initial programming?

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 predictable repeatable 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 Commercially proven approaches to software

development, that, when used in combination, strike out development, that, when used in combination, strike out

at the root problems of software development.

at the root problems of software development.

 Commonly used in industry. Commonly used in industry.

(4)

Unified Software Practices v 5.0 - D

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. $250 billion annually in US.

 Over 175,000 projects! Over 175,000 projects!

 Complexity, size, distribution, importance push Complexity, size, distribution, importance push our limits.

our limits.

 Business pushes these limits: Business pushes these limits:

 Great demands for rapid development and deployment

 We cannot keep pace with demands We 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

(6)

Unified Software Practices v 5.0 - D

6

Software Development is a Job for Teams

Project Manager

Performance Engineer

Release Engineer

Analyst

Developer Tester

Challenges

• Larger teams

• Specialization

•Networking

•Database

•Development

paradigms; process!

• Distribution

• Rapid technology change

• Integration of

technologies!!!

(7)

How Are We Doing?

Project Manager

Performance Engineer

Release Engineer

Analyst

Tester

• Many Successes

• Too Many Failures

(8)

Unified Software Practices v 5.0 - D

8

Symptoms of Software Development Problems

 Inaccurate understanding Inaccurate understanding of end-user needs of end-user needs

 Inability to deal with Inability to deal with changing requirements changing requirements

 Modules that don’t fit together Modules that don’t fit together

 Software that’s hard to maintain or extend Software that’s hard to maintain or extend

 Late discovery of Late discovery of serious project flaws serious project flaws

 Poor software quality Poor software quality

 Unacceptable software performance Unacceptable software performance

 Team members in each other’s way, unable to Team members in each other’s way, unable to reconstruct who changed what, when, where, reconstruct who changed what, when, where, why why

 An untrustworthy build-and-release process An untrustworthy build-and-release process

(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!!

(10)

Unified Software Practices v 5.0 - D

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 communications Ambiguous and imprecise communications

 Brittle architectures – Brittle architectures –

 poor response to changes; little chance for reuse

 Overwhelming complexity Overwhelming complexity

 Undetected inconsistencies among requirements, Undetected inconsistencies among requirements, designs, and implementations

designs, and implementations

 Insufficient testing – 80% tested? Out the door!!! Insufficient testing – 80% tested? Out the door!!!

 Subjective project status assessment Subjective project status assessment

 Delayed risk reduction due to waterfall development Delayed risk reduction due to waterfall development

 Insufficient automation Insufficient automation

(11)

 Insufficient requirementsInsufficient requirements

 Ambiguous Ambiguous

communications communications

 Brittle architecturesBrittle architectures

 Overwhelming Overwhelming complexity

complexity

 Subjective assessment Subjective assessment

 Undetected Undetected inconsistencies inconsistencies

 Poor testingPoor testing

 Waterfall developmentWaterfall development

 Uncontrolled changeUncontrolled change

 Insufficient automation

 Develop iteratively Develop iteratively

 Manage requirements Manage requirements

 Use component Use component architectures

architectures

 Model the software Model the software visually

visually

 Verify quality Verify quality

 Control changes Control changes

Root Causes

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

(12)

Unified Software Practices v 5.0 - D

Copyright  1998 Rational Software, all rights reserved 12

Symptom s

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

(13)

Develop Iteratively Develop Iteratively

Control Changes Control Changes Use Use

Component Component Architectures Architectures Manage

Manage Requirements Requirements

Model Model Visually

Visually VerifyVerify Quality Quality

Best Practices of Software Engineering

Know these!

(14)

Unified Software Practices v 5.0 - D

14

Best Practices Enable High- Performance Teams

Project Manager

Performance Engineer

Release Engineer

Analyst

Developer Tester

Results

• More Successful projects

Control Changes Control Changes Develop Iteratively Develop Iteratively

UseUse Component Component Architectures Architectures Manage

Manage Requirements

Requirements ModelModel

Visually Visually

Verify Verify Quality Quality

(15)

Practice 1: Develop Software Iteratively

Develop Iteratively Develop Iteratively

Control Changes Use

Component Architectures Manage

Requirements

Model

Visually Verify Quality

(16)

Unified Software Practices v 5.0 - D

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 An initial design will likely be flawed with respect to its key requirements.

respect to its key requirements.

Requirements rarely

Requirements rarely fully known fully known up front! up front!

 Late-phase discovery of design defects Late-phase discovery of design defects results in costly over-runs and/or project results in costly over-runs and/or project

cancellation cancellation

 Oftentimes requirements change – during

development! $$$

(17)

Additional Comments:

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

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

(18)

Unified Software Practices v 5.0 - D

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…

(19)

RI S K

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!

(20)

Unified Software Practices v 5.0 - D

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

T C

D R

T I M E

Iteration 1 Iteration 2 Iteration 3

T C

D R

T C

D R

(21)

Iterative Development Accelerates Risk Reduction

Waterfall Iterative

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.

(22)

Unified Software Practices v 5.0 - D

22

Iterative Development Characteristics

Critical risks are resolved before making large Critical risks are resolved before making large investments

investments

Initial iterations enable early user feedback Initial iterations enable early user feedback

 Easy to resolve problems early.

 Encourages user feedback in meaningful ways

Testing and integration are continuous Testing and integration are continuous – assures – assures successful integration (parts all fit together)

successful integration (parts all fit together)

 Continuous testing.

 Objective milestones provide short-term focus Objective milestones provide short-term focus

 Progress is measured by assessing implementations Progress is measured by assessing implementations

Partial implementations can be deployed 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! No big-bang approach!

(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

Supporting Workflows

Iter.

#2 Iter.

#n Iter.

#n+1 Iter.

#n+2 Iter.

#m Iter.

#m+1

Deployment Configuration & Change Mgmt

Requirements

Elaboration Transition

Inception 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

(24)

Unified Software Practices v 5.0 - D

24

Enables and encourages

Enables and encourages user user feedback

feedback Serious

Serious misunderstandingsmisunderstandings evident early in the life cycle evident early in the life cycle Development focuses on

Development focuses on

critical issues – break it down!

critical issues – break it down!

Objective assessment thru Objective assessment thru testing

testing

Inconsistencies detected early Inconsistencies detected early Testing starts earlier –

Testing starts earlier – continuous!

continuous!

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

early - via planned iterations!

Problems Addressed by Iterative Development

Root Causes

Root Causes Solutions Solutions

Insufficient requirementsInsufficient requirements

Ambiguous Ambiguous

communications communications

Brittle architecturesBrittle architectures

Overwhelming Overwhelming complexity

complexity

Subjective assessmentSubjective assessment

Undetected Undetected inconsistencies inconsistencies

Poor testingPoor testing

Waterfall developmentWaterfall development

Uncontrolled changeUncontrolled change

Insufficient automationInsufficient automation

(25)

Goal:

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

budget that meets / exceeds the user requirements.

requirements.

References

Related documents

This publication presents the main outcomes of a partnership working towards “Harmonising Approaches to Professional Higher Education in Europe” (HAPHE) in 2012–2014,

Endurance and on auto assure peters mo address to send us recycle them a number of that work environment lots of options shown, you need some branches are available.. Environment

In contrast to the findings about affective commitment, teachers' continuance and normative commitment are negatively related to management by exceptions (passive)

Teachers in all content areas need to be able to teach students how to read complex informational texts related to their content areas and motivate students to be able to read

The researcher in this study went one step further and examined how organizations communicate on Facebook when a crisis or emergency occurs and how their

We developed a mercury emissions inventory for Malaysia by measuring the actual emissions levels in two solid waste incineration facilities (SWIF-a and SWIF-b) and a coal-fired

Laser Thermo keratoplasty LTK Conductive keratoplasty CK +1.50 – +2.50D Hyperopic PRK +1.50 - + 4.00D Hyperopic LASIK Also consider. Clear lens extraction >50 years

Gwent Specialist Substance Misuse Service (GSSMS) 139 Lower Dock Street Newport NP20 1EE Tel: 01633 216777 Operating Hours?. Monday - Friday: 9am