copyright 2003-2009, dennis j. frailey software engineering best practices dennis j. frailey...

Copyright 2003-2009, Dennis J. Frailey

Software Engineering Best Practices

Dennis J. [email protected]

Things that make a big difference for real software development

projects

2 Copyright 2003-2009, Dennis J. Frailey 2

Objective

To present some basic techniques used in professional software development projects– Some of these are not widely covered in

undergraduate programs


Would You Buy This Car?

The price is 50% more than what you agreed to pay

Delivered to the dealer 3 months late Not the right color Some of the options you selected aren’t

there (“we’ll install them later”) The speakers and the CD player are

incompatible, so you can only use the CD player through headphones

Although “new”, it has 5,000 miles on it from the extensive testing that was done

Despite that testing, it still won’t start if it’s below freezing and it has a number of other problems


Frequent Problems on Real Software Projects

Nobody knows what work must be done– Do we need to provide an installation guide?– Is there a warranty on this software and what

do we do about it if there is?– In what format should we deliver the code?

Vague understanding of the big picture– How does the software fit into the overall

customer environment? Are the networks and computers suitable for the software?

– Will the customer understand how to use it?– Do the software developers know how it will

be used?


Frequent Problems on Real Software Projects (continued)

Unclear understanding of how much has been accomplished and how much is left to do– “How much longer will it take?”– “How much more money is required?”

Ignorance about risks– Do we have any idea what the real risks are?– Is there something we can do to mitigate

them? (Make them less likely or lower their potential impact)

– Do we know what to do if they happen?


Frequent Problems on Real Software Projects (continued)

Confusion about different versions of software– Which version of the data base goes with the

latest version of the user interface?– How come it does one thing in the customer’s

site but something else in our testing lab?– Does the design match the code? If not, which

one is right?

Haphazard approaches to quality– “We didn’t have time to test it thoroughly”– “We tested it for weeks but it still had lots of

bugs”


Best Practices for Managing These Problems

The Work Breakdown Structure– Documenting and organizing the work to be

done Estimating and Tracking

– So you know where you are Systems Engineering

– Designing the big system before designing the software

Risk Management Configuration Management Quality Assurance


The Work Breakdown Structure

Definition: A work breakdown structure is a hierarchical list of the work activities required to complete a project.

This includes tasks for: - Software development - Management of software development - Support of software development - Any other activities required to meet

customer requirements, such as creation of documents, training programs, tool development or acquisition, travel, etc.

ParserCode

GeneratorFile

SystemRun TimeSystem

UserInterface

ManageSoftware

Development

Build “C”Compiler

Build TestSuite

WriteDocumentation

WriteInstallationSoftware

Software for“C” Compiler


Sample Work Breakdown Structure for Taking a Course

1. Take a Course on Programming in Java1.1 Do Assignment 1 – Simple Program1.2 Do Assignment 2 – Program with Arrays1.3 Take Midterm Exam1.4 Do Assignment 3 – Program with Pointers1.5 Do Assignment 4 – Program with I/O1.6 Take Final Exam

These are the tasks you must complete in order to finish the course


Sample Work Breakdown Structure Hierarchy Allows Additional Detail

1. Take a Course on Programming in Java1.1 Do Assignment 1 – Simple Program 1.1.1 Study Chapters 1 and 2 of textbook 1.1.2 Write a Simple Java Program 1.2 Do Assignment 2 – Program with Arrays 1.2.1 Study Chapters 3 and 4 1.2.2 Review Graded Assignment 1 1.2.3 Write Java Program with Arrays1.3 Take Midterm Exam 1.3.1 Study Chapters 1-5 1.3.2 Meet with study group to review 1.3.3 Go to exam room at designated time


Sample WBS for a Software Project (top levels only)

1.0 Software for Payroll system 1.1 Build the Payroll software 1.1.1 Build a User Interface 1.1.2 Build a File System 1.1.3 Build a Data Base 1.1.4 Build a Table of Rules 1.1.5 Build a Check Printing System 1.2 Build the Test Suite for the Software 1.2.1 (detailed steps for building test suite) 1.3 Write Documentation 1.4 Write Installation Software 1.5 Manage the Above


The WBS Is ...

A “table of contents” for the project.


Top Level Role of WBS

SourceDocuments

(Statement of Work,

Requirements,contract,

test criteria, etc,)

HistoricalRecords(at end

of project)

WBS

CostEstimate

(proposal &/project start)

CostTracking(during

execution)


Using the WBS to Estimate

WBS #

Task Estimated Hours

Estimated Completion

1.1 Do Assignment 1 15 9/22

1.1.1 Read Chapters 1, 2 3 9/15

1.1.2 Write Simple Java Pgm 12 9/22


1.2.1 Read Chapters 3, 4 4 9/23

1.2.2 Review Graded Assign. 1 1 9/23

1.2.3 Write Java Pgm with Arrays 16 9/30


Using the WBS to Track

WBS #

Task Estimated Hours

Actual Hours

Estimated Completion

Actual

1.1 Do Assignment 1 15 12 9/22 9/25

1.1.1 Read Chapters 1, 2

3 2 9/15 9/22

1.1.2 Write Simple Java Pgm

12 10 9/22 9/25


1.2.1 Read Chapters 3, 4

4 9/23

1.2.2 Review Graded Assign. 1

1 9/23

1.2.3 Write Java Pgm with Arrays

16 9/30


Graph to Show Progress

I M Exhausted, CSE 7315, Fall 2004BCWS/ACWP/BCWP Line Chart

0

20

40

60

80

100

120

140

160

180

Wk 1 Wk 2 Wk 3 Wk 4 Wk 5 Wk 6 Wk 7 Wk 8 Wk 9 Wk 10 Wk 11 Wk 12 Wk 13 Wk 14 Wk 15

Week Number

Hou

rs

BCWS

ACWP

BCWP


Using the WBS for Historical Records

Previous WBS

New WBS

Facts about New

Project

Previous WBS

Previous WBS

Previous WBS

Old Projects


Systems EngineeringA Sample System

Display PrinterKeyboard

Processorand

Memory

SystemSoftware

PowerSupply

Computer

SystemUnit


Systems Engineering - Step 1 - Analyze the Requirements of the Overall System

Determine what the customer really wants– >> Analysis of the problem and the need

Produce testable specifications (may be in the form of simulations of expected behavior, use cases, specification documents, system requirements models, or other things)

Confirm the specifications are right by conferring with the customer


Systems Engineering - Step 2 - Design the System

Select the architecture of the system – >> Synthesis, not analysis– Done by Systems engineer and/or chief

architect Determine the major parts (functional

decomposition into sub-systems) Determine the interfaces between the

subsystems Allocate the requirements to the various

parts


Example of Requirements Allocation

Requirements:

- Sense Status

- A/D conversion

- Display

Temperature Sensor

AnalogDevice

A/DConverter Software


Typical Requirements Flowdown

Transmission

System Analysis& Design

Allocated Requirements

Automobile

Drive Train ChassisEngine

100 pounds

torque ...

50 pounds 2000 pounds

500 pounds250 hp

...

Original Requirements

3000 pounds

0-60mph in 9 sec


Risk Management

Risks are:– things that can go wrong

If it has already happened, or is certain to happen, it is an issue, not a risk!– You should be discussing your action plan

for managing the problem

Copyright 2003-2009, Dennis J. Frailey

Risk Management Phases

1) Risk Assessment – The things you do before you start the

project to identify– What can go wrong– How it can hurt you– Why it may happen– How you can mitigate (reduce) the risk

2) Risk Control– The things you do during the project

– Preventing the unexpected– Responding when you cannot prevent


Risk Assessment ChartRisk Evidence How

LikelyImpact Priority Mitigation

Late project due to employee turnover

Unplanned turnover rate has been running high

7 7 49 Employee bonuses if they stay to end of project

Bottleneck at testing due to changing require-ments

Past experience with this customer

8 6 48 Iterative development Customer workshops

Etc. Etc. Etc. Etc. Etc. Etc.


Risk Control

A) Risk Monitoring

- Watching to see if risks happen

– Metrics to warn you of problems

– Periodic reviews

B) Risk Abatement

- Counteracting risks

- Taking contingency actions as needed


Risk Control ChartRisk Monitoring Counteracting /

Contingency Ongoing

Mitigation

Late project due to employee turnover

Measure turnover rate and project schedule

Get management help in identifying alternate employees

Periodic employee mini-bonuses

Bottleneck at QA due to changing require-ments

Track requirements changes and QA backlog

Requirements freeze; Multiple releases

Feature prioritization

Etc. Etc. Etc. Etc.


Risk Management is Ongoing

Risk Management (planning, analysis)

Product Development

Actions to identify and monitor risks

Actions to mitigate or abate risks


Requirements Stability Monitoring

Requirements Stability

0

20

40

60

80

100

120

140

160

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

TotalTBDChanges

CDRPDR


Risk Monitoring Thresholds Establish thresholds so you know when

to act– Beware of the “frog in the water” problem

– Historical experience is a good basis to judge when things are getting out of hand


What Is Software Configuration Management?

Definition:

Software Configuration Management is the process

of identifying, organizing and managing modifications to

software

Software Configuration Management is the process

of identifying, organizing and managing modifications to

software


Purpose ofConfiguration Management

The purpose of configuration management is to maintain integrity of the product by controlling change to the

product

The purpose of configuration management is to maintain integrity of the product by controlling change to the

product


All components that make up or relate to a version of a product– The proper version of each:

What Is The Configuration?

� document� compiler used to develop� development tool� data set used for

simulating� special equipment� operating system

� test code� test data� library� procedur

e� hardware� etc.

� module� component� data file� macro� simulator� specification

If any of the above is wrong, the product lacks integrity and may not work

If any of the above is wrong, the product lacks integrity and may not work


What is Integrity?

Having the right parts that all fit together to form a correct product.

ListingUser’s Guide

Main, rel 2.3Sub1, rel 1.7Sub2, rel 3.1...

Object code


Why is SW Configuration Management Needed?

Because software is flexible, changeable, and intangible

It is too easy to lose integrity of software because of these factors

Unmanaged change is very possibly the largest single cause of failure to deliver

systems on time and within budget.NASA SCM Guidebook, August, 1995

Unmanaged change is very possibly the largest single cause of failure to deliver

systems on time and within budget.NASA SCM Guidebook, August, 1995


Examples of Loss of Integrity

Performance 2 years ago cannot be duplicated with the current release

Source code will not compile without errors

Compiled code will not execute with the same results as the released code

It worked in the factory but not in the field

All records of a particular feature are gone, and the programmer/designer left the company


More Examples of Loss of Integrity

Compiled code has different object code or code size from released code

A bug that we fixed once before has reappeared

Code does not match the design specification

A feature that we added and fully tested has suddenly stopped working

We cannot figure out which version of each module is needed to reproduce a problem we found in the field


Configuration Management Has Five Major Functions

1) Configuration Identification– Which parts are combined in what way to

make a given release/version2) Configuration Control

– The rules for making changes to software3) Change Management

– Deciding who is allowed to make changes and when?

4) Status accounting– Where is each component?

5) Configuration Authentication– Verifying that everything is right


Software Quality Assurance

Purposes:

– To prevent defective products from being shipped to the customer

– To arbitrate disputes when there are debates about whether the product is “good enough”

– To provide management and developers with visibility into the process being followed and the products being built So they can manage the outcome


Quality Assurance Looks at the Entire Process

Requirements

Development QC InspectionPass

Fail

Standards ofQuality

Process and Design Standards


Software Quality Assurance

Typical Practices:

– Inspections

– Reviews

– Audits

– Communication

– Measurements

– Independent confirmation of compliance Standards, requirements, procedures


Professional Software Engineering Is ...

Building Software Systems that People can Rely On

“The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software.”

IEEE Standard Glossary of Software Engineering Terminology


Questions?