SENG 209 Software engineering Software Development Process Timothy Korson [email protected].

SENG 209 Software engineering

Software Development Process

Timothy Korson

[email protected]

2

Software development

A software development process is the set of activities needed to transform a user’s requirements into a software system

User’s Requirements Software DevelopmentProcess

Software DevelopmentProcess

Software system

3

Basic Goals of a Software Development Process

Correct, Robust, High Quality Software that is easy to use and meets real business needs

Modifiable Software Extensible Software Portable, Integrable Software Rapid Development Capability Maximize Productivity Minimize Costs

4

Modern Software Processes Promise to:

Support RAD through reuse of components, design patterns, architectural frameworks, and domain models

Improve product quality Facilitate business process reengineering Solve problems of greater complexity Improve maintainability and extensibility Improve communication with customers Improve communication between developers

5

Potential Benefits An optimal use of object-oriented technology requires a

new development process Any promised benefits from the use of OT are only

potential benefits. They do not magically happen. They require specific management practices to make them happen

Rarely however, do corporate policies and practices encourage managers to follow good, modern software engineering techniques

6

In Fact: Most corporate policies and practices actively discourage

managers from following good, modern software engineering techniques

Can you think of examples from your own experience?

7

Mind-Set

Traditional Mind-set Modern Mind-set

What does the system do? What are the fundamental business concepts in the domain?

How do I design a system to provide these functions?

How can I model the problem and distribute responsibilities to achieve the system's functionality?

Focus on version 1 of this system

Focus on extensibility and families of systems

8

Use Case Driven

9

Good Software Engineering is NOT Use Case Driven

10

History OOPSLA 1993 - Which Method is Best?

11

Unified ProcessUnified Process

Architect-Centric Use-Case Driven Component Based

12

Good Software Engineering is...

Domain Analysis Based Architecture-Centric Use-Case Configured Component Biased Quality Engineered

13

Domain Analysis Based First major activity in

software development is the identification of the fundamental business concepts and relationships

Design of the application server code is based on the classes and relationships in the domain model

14

Architecture-Centric Architecture definition and refinement is viewed as a

core development activity an appropriate percentage of the project schedule is

devoted to architecture Architecture is not ad hoc, but is based on industry

standards, patterns, commercial frameworks and components

All detail design and coding is done within a well defined architectural framework, often according to a specific pattern

Architecture team plays a key role throughout the

entire product lifecycle

15

From Domain Analysis to Architecture

The architecture for each separate domain describes the way the classes within the domain interact and is based on domain relationships

The architecture for the application describes the way the different domains interact

Grading Domain Model

Application Model

(Major Domain)

RegistrationSpreadsheet

DomainDomain

GradingReportingDomain

16

Use-Case Configured

Architecture

Application

Use Cases

Domain Relationships

Business Goals &Technical SystemRequirements

CommercialStandards &Frameworks

17

Uses cases STOP at the system interface boundary

18

Do not directly derive your design from your use cases

Use cases DO describe sequences of actions that actors follow in using the system

Use cases must NEVER specify what steps the system takes internally in responding to the stimulus from an actor

SystemInterface

19

Example Architectural Drivers

Finance Extensibility

Telecommunications 24X7 hot switchover

Aerospace COTS and GOTS contract mandate

20

Watch out for ShortcutsWatch out for Shortcuts RAD tools that tie screens directly to databases give you RAD

development, but not RAD modifiability Screens should be tied to the business model.

The business model should not directly embed SQL, or any other implementation technology, in it’s methods

ReportGUI

Business Model

Relational Database

Technology Interface

Writer

What are the trade-offs?

21

Component Biased The development process is biased towards using:

Robust libraries of domain-specific and domain-independent components

Frameworks that supply substantial portions of an application

Packaging techniques that requires loose coupling and well specified interfaces between modules

Supporting management techniques that enable us to integrate these components

22

Quality Engineered Formal QA process Testing across the life-cycle Iterative, incremental development

process Prototype supported process Continuous education for software

engineers Adherence to best current standards and

practice Adaptability over rigidity

23

A Software Development Process Meta-ModelA Software Development Process Meta-Model

1. EmphasisDomain Analysis Based

Architecture-Centric

Reuse-oriented

Use Case Configured

Quality Engineered

2. Activities (Workflows)Domain Analysis

Application Analysis

Application Design

Class Design / Development

Incremental Integration and System Testing

3. Notation UML

4. Scope Comprehensive

5. Process ModelIterative/Incremental Process

Phased Development

inception

elaboration

construction

transition

Prototype-supported

24

Incremental Model Build a system in increments that represent

increasing levels of functionality:

Analyze a little… Design a little… Code a little… Test a little… Learn a lot…

This is different from waterfall until implementation, then incremental development

25

Prototyping ModelPrototyping Model Some advocate a process with little formal analysis and design, evolving the

prototype into the product.

This is good for small, short lived, in-house projects that will forever be supported by the same person(s).

Today’s systems need a well documented solid architecture that is matched to the business needs of the product.

It is a temptation to skip Domain Analysis and Architecture when using a powerful IDE such as JBuilder from Borland

Note: We will use the term prototype to designate a disposable product.

26

Good Software Engineers Create Lots of Disposable Protypes:

Analysis Prototypes Answer questions about requirements

Design Prototypes Answer questions about the architecture. Design

prototyping is facilitated by simulation tools

Implementation prototypes Answer questions about feasibility, performance,

memory requirements, etc.

27

Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Test

Preliminary iteration(s)

Itr. #1

Itr. #2

Itr. #n

Itr. #n+1

Itr. #n+2

Itr. #m

Itr. #m+1

Core Workflows Phases

Iterations

*Figure 11.2 page 296 “The United Software Development Process, Jacobson, Booch, Rumbaugh

RUP Effort Distribution

28

Vocabulary Phase Workflow Iteration Increment Cycle Build Release

29

An OO Development ProcessAn OO Development Process

Basic process is incremental Iterate within increments, with prototype support as necessary. Often this

will involve reworking one piece of the system several times before an increment is finished. Previous increments are only revisited to fix errors or serious flaws.

How does one incrementally build an architecture?

Do enough analysis and design to form a context, then concentrate on driving an increment through to completion (running, tested code).

30

Building Complex Systems is Fundamentally an Incremental Process

“A complex system that works is invariably found to have evolved from a simpler system that worked ... . A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”

Ramamoorthy, C., and Sheu, IEEE Expert, Vol. 3 (3), p. 14

31

Basic Development Process

light activity

heavy activity

In

Activity Increment

In+1 In+2 In+3

Domain Analysis

Application Assembly

Application Design

Class Development

Application Analysis

Integrated cradle to grave teams work best

32

Getting Started

light activity

heavy activity

I 0a

Activity Increment

I 0b I0c I01

Domain Analysis

Application Assembly

Application Design

Class Development

Application Analysis

Establishing a basic context

33

Stepping through the process Getting Started

DA

AA

Workflow

AD

CD

IT

34

Stepping through the process Increment 1

DA

AA

Workflow

AD

CD

IT

I1

35

Stepping through the process Increment 2

DA

AA

Workflow

AD

CD

IT

I1 I2

When performing the Ith increment, bring the entire analysis and design up to date.

36

Choosing Increments - “Use Case” versus Architectural

A use-case driven (external) increment implements some subset of the user requirements (e.g. traffic controller works for non-rush hour straight traffic. No turn traffic, pedestrians or emergency vehicles are yet considered).

An architecturally based (internal) increment implements some subset of system functionality (e.g. database access mechanism, inter-process communication).

How does one balance scheduling external increments with internal increments?

37

Testing Architectural Increments

Architectural increments imply architectural test cases

The specification of an architecture should include a set of “architectural use cases”

38

Design ReviewsDesign Reviews

Architecture review

Cluster design review

Detail design review

There should be at least three

types.

Why?

39

Incremental Process Implies Incremental Documentation

Other important documents, such as the user manual and test plan, are also developed, and verified incrementally.

RequirementsSpecifications

Analyze Analyze

Design Design

Implement

DomainModel

DesignDocument

Implement

40

Summary Need to plan on throwing away the

“right” amount of code Need to do enough architectural design

before first increment so that you have a roadmap

Plan on building some use case increments before all of the architectural mechanisms are in place

Use components, patterns, and frameworks to realize your architectures