cs 551 development process n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CS 551 Development Process PowerPoint Presentation
Download Presentation
CS 551 Development Process

Loading in 2 Seconds...

play fullscreen
1 / 48

CS 551 Development Process - PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on

CS 551 Development Process. Revision 1. Organizational Structure. SYSTEM BASELINE REQUIREMENTS ALGORITHMS. FEATURE ENGINEERING. SOFTWARE DEVELOPMENT. SOFTWARE MANUFACTURING. ARCHITECTURE ENGINEERING. INTEGRATION. HUMAN FACTORS DEVELOPMENT. TO SITES. TRAFFIC ENGINEERING.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CS 551 Development Process' - maura


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
organizational structure
Organizational Structure

SYSTEM

BASELINE

REQUIREMENTS

ALGORITHMS

FEATURE

ENGINEERING

SOFTWARE

DEVELOPMENT

SOFTWARE

MANUFACTURING

ARCHITECTURE

ENGINEERING

INTEGRATION

HUMAN FACTORS

DEVELOPMENT

TO SITES

TRAFFIC

ENGINEERING

TRAFFIC

PROJECTIONS

ENGINNERING

REPORTS

SUPPORT AND OPERATIONS

- COMPUTER CENTER

- DEVELOPMENT MACHINE

- TEST MACHINE

development cycle with feedback
Development Cycle with Feedback

MANUFACTURE

& DELIVER

DEFINE

DESIGN

DEVELOP

TEST

TO SITES

OPERATE,

MAINTAIN &

EVALUATE

project trouble indicators
Project Trouble Indicators
  • No periodic project meetings
  • No Project Manager
  • No active problem list
  • No Software Architect
  • Testing Starts After Development
  • No risk Assessment
  • No independent Test Team
slide5

System Performance Resulting from Robust Requirements

Performance

Discrete Specifications

Ideal

Robust

Requirements

Dynamic Range

requirements specification spec
Requirements Specification Spec
  • Project Title, Revision Number and Author
  • Scope and Purpose of the system
  • Measurable Organization Value
  • Description
  • Feature List including ICED T and Simplified QFD analysis
  • Interfaces
  • Constraints
  • Change Log and Expected Changes
  • Responses to the unexpected
  • Measurements
  • Glossary
  • References
gantt chart see http www mne psu edu me415 resources docs gantt 20chart pdf
GANTT Chart see http://www.mne.psu.edu/me415/resources/docs/gantt%20chart.pdf
software requirements process
Software Requirements Process
  • Requirements Elicitation
  • Requirements Analysis
  • Use Cases
  • Requirements Specification
  • Prototype
  • Requirements Management
slide12

<<actor>>

Account

System

View

Status

Create &

Submit Orders

<<actor>>

Inventory

  • Develop Use Cases
    • Focus on Goals
    • Identify Actors
    • Identify Main Tasks
  • Use Case Concept
    • Complete, orthogonal, externally visible functionality
    • Initiated by an actor
    • Identifiable value to the actor

Ordering

System

role of software architect
Role of Software Architect
  • Assures that the Requirements are valid- use Prototypes in Requirements Stage
  • Assures that Requirements are quantitative
  • Defines Non Functional Requirements and Software Trustworthiness.
  • Defines 4+1 views
  • Defines Components and Interface Structures
kruchten s 4 1 model for developing software architecture

Kruchten’s “4 + 1”Model for Developing Software Architecture

View 1

View 2

Process:

System

Integrators

Logical:

End Users

View + 1

Business Scenarios:

Customers

All Stakeholders

View 4

View 3

Execution:

Programmers

Physical:

Engineers

role of project manager
Role of Project Manager
  • Defines and documents Development Process
  • Makes trade-offs among features, schedule, development cost and quality
  • Chairs Project Meetings
  • Assigns and tracks action items
  • Communicates to Project Members
waterfall model
Waterfall Model

System feasibility

Focus: Control

Emphasis: Documentation

Validation

Software plans &

Requirements

Validation

Product design

Verification

Detailed design

Verification

Code

Unit test

Integration

Quality assurance

Implementation

Certification

Operations &

maintenance

Operational

Reviews

figure 2 boehm s spiral model of the software process
Figure 2: Boehm’s Spiral Model of the Software Process

Cumulative Cost

Progress through steps

Determines Objectives

Alternatives, Constraints

Evaluate Alternatives:

Identify, Resolve Risks

Focus: Risk

Emphasis: Contingency Planning

Risk Analysis

Risk Analysis

Risk Analysis

Operational

Prototype

Rqts

Anal.

Proto-

Type 1

Proto-

type 3

Proto-

Type 2

Commitment

Partition

Concept of

Operation

Rqts. Plan

Life Cycle

Plan

Software

Rqts

Detailed

Design

Develop-

ment Plan

Requirements

Validation

Software

Product

Design

Unit

Test

Code

Design Validation

and Verification

Integration

and Test

Integra-

tion & Test

Acceptance

Test

Implemen-

tation

Plan Next

Phases

Develop & Verify

Next - Level Product

role of software developers
Role of Software Developers
  • Designs Software Components
  • Implements Software
  • Documents with code commentary prefaces and in-line narratives.
  • Unit Tests
  • Checks Interfaces
development plan an evolving document
Development Plan-an evolving document
  • Name of Project (issue 1 due November 23)
  • Purpose and MOV
  • Team members, their roles, management plan, QA, ease of use, coding standards
  • Gantt Chart
  • Current Estimate Table
  • QFD
  • ICED-T
making a system
Making a System

Tools

Source Library

JAVA

SOURCE

LIBRARIES

4GL

FORTRAN, ADA

C Level

Production

Computer

Development

Computer

Assembler

Binary

Application

Middleware

APPLICATION

DATA BASE

Computer

Hardware

UNIX

PRODUCT

BUILDING

BLOCKS

EXECUTABLE

LIBRARIES

….

DEVELOPERS,

PROGRAM ADMINISTRATORS

& SOFTWARE MANUFACTURERS

USERS

role of testers
Role of Testers
  • Restates Requirements quantitatively and from a test view-see PDF “In Other Words”
  • Creates test bed for developers
  • Designs and executes:
    • Scenario Tests from Use Cases
    • Integration Tests
    • Reliability Tests
    • Stress Tests
factors affecting productivity circa 1975
Factors Affecting ProductivityCirca 1975
  • Competent Management
  • Quality of people
  • Level of testing before shipping
  • Consistency of requirements
  • Sophistication of programming tools
  • Modularity of design
  • Reasonableness of commitments
development cycle circa 1970
Development Cycle Circa 1970

Design Programs,

Data Base &

User Documentation

Define

Requirements

Code and

Test Modules

Integration

Test

System

Test

Verify System

Operation

Install

Software

Target

Site

Live

Operation

slide24

Development Cycle for Multiple Sites Circa 1975-80

Site Peculiar Tests

Design Programs,

Data Base &

User Documentation

Define

Requirements

Code and

Test Modules

Integration

Test

System

Test

Verify System

Operation

Install

Software

Site 1

Live

Operation

.

.

.

.

.

.

.

.

.

Verify System

Operation

Install

Software

Live

Operation

Site N

slide25

Development Cycle with Software

Manufacturing Circa 1980-90

Site Peculiar Tests

Design Programs,

Data Base &

User

Documentation

Software

Manufacture

Controls &

Builds

Define

Requirements

Code and

Test

Modules

Integration

Test

System

Test

Verify System

Operation

Install

Software

Live

Operation

Site 1

.

.

.

.

.

.

.

.

.

Software

Manufacture

Builds and

Ships

Verify System

Operation

Install

Software

Live

Operation

Site N

slide26

Development Cycle with

Software Manufacturing Circa 1990-2000

Agile

‘Test then Code’

Approach

Daily Software

Builds

Quality

Assurance

Define

Requirements

Verify System

Operation

Install

Software

Live

Operation

Site 1

Software

Manufacture

Builds and

Loads Server

.

.

.

.

.

.

.

.

.

Verify System

Operation

Install

Software

Live

Operation

Site N

agile software development
Agile Software Development
  • Agile methods
  • Extreme programming
  • Agile application development
  • Software prototyping

Focus: Time-to-Market

Emphasis: Minimum Appropriate Process, a Humanistic Approach

technologies used in agile development
Technologies used in agile development
  • .NET and J2EE
  • Web Design
  • Visual Basic
  • Databases
an iterative development process

Define system

deliverables

Define system

deliverables

Specify system

increment

Build system

increment

Validate

increment

No

Validate

system

Integrate

increment

Yes

Deliver system

Done?

An iterative development process
advantages of incremental development
Advantages of incremental development
  • Accelerated delivery of customer services. Each increment delivers the highest priority functionality to the customer.
  • User engagement with the system. Users have to be involved in the development which means the system is more likely to meet their requirements and the users are more committed to the system.
agile methods
Agile methods
  • Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods:
    • Focus on the code rather than the design;
    • Are based on an iterative approach to software development;
    • Are intended to deliver working software quickly and evolve this quickly to meet changing requirements.
  • Agile methods are probably best suited to small/medium-sized business systems or PC products.
principles of agile methods

Principle

Description

Customer involvement

The customer should be closely involved throughout the

development process. Their role is provide and priorities new

system requirements and to evaluate the iterations of the system.

Incremental delivery

The so

ftware is developed in increments with the customer

specifying the requirements to be included in each increment.

People not process

The skills of the development team should be recognized and

exploited. The team should be left to develop their own ways o

f

working without prescriptive processes.

Embrace change

Expect the system requirements to change and design the system

so that it can accommodate these changes.

Maintain simplicity

Focus on simplicity in both the software being developed and in

the deve

lopment process used. Wherever possible, actively work

to eliminate complexity from the system.

Principles of agile methods
problems with agile methods
Problems with agile methods
  • It can be difficult to keep the interest of customers who are involved in the process.
  • Team members may be unsuited to the intense involvement that characterises agile methods.
  • Prioritising changes can be difficult where there are multiple stakeholders.
  • Maintaining simplicity requires extra work.
  • Contracts may be a problem as with other approaches to iterative development.
extreme programming
Extreme programming
  • Perhaps the best-known and most widely used agile method.
  • Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
    • New versions may be built several times per day;
    • Increments are delivered to customers every 2 weeks;
    • All tests must be run for every build and the build is only accepted if tests run successfully.
the xp release cycle
The XP release cycle

Select user

Break down

stories for this

Plan release

stories to tasks

release

Evaluate

Release

Develop/integrate

system

software

test software

extreme programming practices
Extreme programming practices

I

incr

em

en

t

a

l

p

l

ann

i

ng

R

e

qui

r

e

m

en

ts

a

r

e

r

e

cord

e

d

on

S

t

o

r

y

C

a

r

ds

and

t

he

St

or

i

e

s

t

o

be

i

nc

l

uded

i

n a

r

e

l

e

as

e

a

r

e

de

t

er

mi

ned

by

t

h

e

tim

e

a

va

il

ab

l

e

a

nd

t

he

ir

r

e

l

a

ti

ve

pr

i

o

rit

y.

The

deve

l

ope

r

s

br

e

ak

t

he

s

e s

t

o

ri

es

i

n

t

o

deve

l

op

m

en

t

tasks

.

Sm

a

ll

R

e

l

eas

e

s

T

he

mi

n

im

a

l

u

s

e

f

u

l

s

e

t

o

f

f

unc

ti

ona

lit

y

t

ha

t

prov

i

de

s

bu

si

nes

s

va

l

ue

i

s

deve

l

oped

f

ir

s

t.

R

el

eas

e

s of

t

he

s

ys

t

e

m

a

r

e

fr

equen

t

and

i

nc

r

e

m

en

t

a

ll

y

a

dd

f

unc

ti

ona

lit

y

t

o

t

h

e

fi

r

st r

e

l

ea

s

e.

Sim

pl

e

De

si

gn

E

nough de

si

gn

i

s

ca

rri

ed ou

t

to

m

ee

t t

he cu

rr

en

t

r

equ

ir

e

m

en

t

s

and

no

m

o

r

e.

T

es

t

f

ir

s

t

deve

l

op

m

en

t

An

au

t

o

m

a

t

ed un

it t

es

t

f

r

a

m

ewo

r

k

is

u

s

ed

t

o

w

r

i

te t

e

s

t

s f

o

r

a

new

p

i

ece

o

f

f

unc

ti

ona

lit

y be

f

o

r

e

t

ha

t

fun

ct

ion

a

l

it

y

it

se

lf

is

im

p

l

e

m

en

t

ed

.

R

e

fa

c

to

ri

ng

A

ll

d

e

ve

l

ope

r

s

a

r

e

expe

c

t

e

d

t

o

re

f

ac

t

o

r

t

h

e

code con

ti

nuous

l

y

as

soon

a

s

po

s

s

i

b

l

e

code

im

p

r

ove

m

en

t

s

a

r

e

f

ound

.

T

h

i

s

keeps

t

he

code

s

im

p

l

e

and

m

a

i

n

t

a

i

n

a

bl

e

.

extreme programming practices1
Extreme programming practices

P

a

ir

Pr

ogra

mmi

ng

Deve

l

op

e

r

s

wo

r

k

i

n

pa

ir

s

,

che

c

king ea

c

h

o

t

he

r

Õ

s w

ork and

p

r

ov

i

ding

t

he

suppo

rt

t

o

a

l

w

ays do

a

good

j

ob

.

Co

ll

e

c

t

i

ve

Owne

rs

hip

T

he pa

ir

s

o

f

deve

l

op

e

r

s

wo

r

k on

a

ll

a

re

a

s of

t

he

s

ys

t

e

m,

s

o

t

ha

t

no

i

sl

ands

o

f

expe

rti

s

e

deve

l

op

and

al

l

t

he

deve

l

ope

r

s

own a

ll t

he

code

.

Anyon

e

c

a

n

chang

e

any

t

h

i

ng

.

Con

ti

nuou

s

I

n

t

egr

at

ion

A

s

s

oon

a

s

wo

r

k on

a

t

ask

i

s

co

m

pl

et

e

it

i

s i

n

t

eg

r

a

t

ed

i

n

t

o

t

he

who

l

e

sy

st

e

m

.

Af

t

e

r

any

s

uch

i

n

t

eg

r

a

ti

on

,

a

ll

t

h

e

un

it

t

e

st

s

i

n

t

he

sy

st

e

m

m

u

st

pa

s

s

.

S

us

t

a

i

nab

le

pac

e

L

arg

e

a

m

oun

ts

o

f

ove

r-t

i

me

a

r

e

not

con

s

id

e

r

e

d

ac

c

ep

t

ab

l

e

a

s

t

he

ne

t

ef

f

ec

t i

s

of

t

en

t

o

r

educ

e

code qua

lit

y

a

nd

m

ed

i

u

m

t

e

rm

p

r

oduc

ti

v

i

ty

On

-

s

it

e

Cu

s

to

m

e

r

A

rep

r

e

s

en

t

a

ti

ve

of

t

he end

-

u

s

er o

f

t

he

sy

s

t

em (t

he

C

us

t

o

m

e

r

)

shou

l

d

be

ava

il

ab

l

e

f

u

ll

tim

e

fo

r

th

e

u

s

e

o

f

t

h

e

X

P

te

a

m

.

In

an

ex

tr

e

m

e

prog

r

a

mmi

ng p

r

oce

s

s

,

t

he

cus

t

o

m

e

r

is

a

m

e

m

be

r

o

f

th

e

deve

l

op

m

en

t t

ea

m

a

nd

i

s

r

espon

si

b

l

e

f

or

b

ri

nging

sy

st

e

m

r

equ

i

r

e

m

e

n

t

s

to

t

he

te

a

m

f

or

im

p

l

e

m

en

t

a

ti

on.

xp and agile principles
XP and agile principles
  • Incremental development is supported through small, frequent system releases.
  • Customer involvement means full-time customer engagement with the team.
  • People not process through pair programming, collective ownership and a process that avoids long working hours.
  • Change supported through regular system releases.
  • Maintaining simplicity through constant refactoring of code.
testing in xp
Testing in XP
  • Test-first development.
  • Incremental test development from scenarios.
  • User involvement in test development and validation.
  • Automated test harnesses are used to run all component tests each time that a new release is built.
pair programming
Pair programming
  • In XP, programmers work in pairs, sitting together to develop code.
  • This helps develop common ownership of code and spreads knowledge across the team.
  • It serves as an informal review process as each line of code is looked at by more than 1 person.
  • It encourages refactoring as the whole team can benefit from this.
  • Measurements suggest that development productivity with pair programming is similar to that of two people working independently.
agile practices for distributed teams
Agile Practices for Distributed Teams
  • Cohesive components with interface structures
  • XP for small development teams
  • Scrum as management structure
  • Frequent builds
  • Inter-team trust and work hour overlap
  • Experienced staff
  • Leverage collaborative tools – wikis, PM,…

Ref: SD Times 15Oct07 pg 41

cots reuse
COTS reuse
  • An effective approach to rapid development is to configure and link existing off the shelf systems.
  • For example, a requirements management system could be built by using:
    • A database to store requirements;
    • A word processor to capture requirements and format reports;
    • A spreadsheet for traceability management;
back to back testing
Back-to-back testing

Test data

T

System

Application

prototype

system

Results

comparator

Difference

report

software factory

- CODE

- DOCUMENT

- FIX BUGS

Release

Archives

Base

Libraries

Software Factory

DESIGNERS

CONTROL PROGRAMS

& PROCEDURES

Reports

Support

Programs

Change

Management

Tracking

System

Source

Control

Modification

Requests

Doc.

Library

Source

Lib.

Change

Requests

Released

Product

To Test

Team

Build System

Shipping

Utilities

Released

Product

Application

Files

Middleware, Tools and Operating System

To Sites

source code management
Source Code Management
  • Store, update and retrieve all versions
  • Manage code ownership
  • Control updating privileges
  • Identify accurate version of retrieved source
  • Track changes
  • Maintain build database, tools and machine
release flow
Release Flow

DEVELOPMENT ENVIRONMENT

EXECUTION ENVIRONMENT

DEVELOPMENT

SHOPS

COMPONENT

TEST

MODULE A

MODULE B

MODULE C

MODULE D

  • CODE
  • PROCEDURES
  • DOCUMENTATION

SYSTEM INTEG.

TEST

SOFTWARE

MANUFACTURING

RELEASE

PACKAGES

SOFTWARE

MANUFACTURING

SITES

COOPERATIVE

TESTING

N - 1

N

MODIFICATION

REQUEST

(MR)

purpose of release documents
Purpose of Release Documents
  • Describe features
  • Describe corrections to troubles
  • Cross reference software dependencies
  • Specify limitations or deficiencies
  • Provide special installation instructions and
  • provide data conversion instructions
  • Specify training
  • Identify new, changed or deleted documents
  • Provide software source code
  • Maintain product lists
software change
Software Change

Cultural

Technical

Innovation

&

Investment

Business