September 30, 2010COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser [email protected]

September 30, 2010 COMS W4156 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://bank.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



Topics covered in this lecture

• Introduce software process

• Describe several generic process models and consider advantages/disadvantages


Software Process


What is a software process?

• A structured set of activities required to develop a software product– Specification;

– Design and implementation;

– Validation;

– Evolution (operation and maintenance).


Software specification

• The process of establishing what features and services are required, as well as the constraints on the system’s operation and development.

• Requirements engineering process– Feasibility study;– Requirements elicitation and analysis;– Requirements specification;– Requirements validation.


Software design and implementation

• The process of converting the system specification into an executable system.

• Software design– Design a software structure that realizes the

specification;

• Implementation– Translate this structure into an executable

program;

• The activities of design and implementation are closely related and may be inter-leaved.


Software validation

• Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the customer(s).

• Involves checking and review processes, and acceptance or beta testing.

• Custom software: Acceptance testing involves executing the system with test cases that are derived from the real data to be processed by the system in the customer’s environment.

• Generic software: Beta testing executes the system in many customers’ environments under real use.


Software evolution

• Software is inherently flexible and can change.

• As requirements change due to changing business circumstances, the software that supports the business must also evolve and change.

• Although there has historically been a demarcation between development and evolution, this is increasingly irrelevant as fewer and fewer systems are completely new.


Process Models


Software Process

• A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.– Major Task Identification– Sequencing

In the beginning was......


Build FirstVersion

Retirement

Operations

Modify untilCustomer satisfied

Code-and-Fix


Discussion of Code-and-Fix• Really Bad• Really Common• Advantages

– No Overhead– No Expertise

• Disadvantages– No means of assessing progress– Difficult to coordinate multiple programmers

• Useful for “hacking” single-use/personal-use programs: start with empty program and debug until it works


Requirements

Validate

Retirement

Operations

Test

ImplementationVerify

Design

Waterfall


More Detailed WaterfallREQUIREMENTS

ANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE


Discussion of Waterfall• Articulated by Win Royce, ~1970• Widely used today• Advantages

– Measurable progress– Experience applying steps in past projects can be used in

estimating duration of “similar” steps in future projects– Produces software artifacts that can be re-used in other

projects• Disadvantages

– Difficulty of accommodating change after the process is underway: One phase has to be complete before moving onto the next phase.

http://bank.cs.columbia.edu/classes/cs4156/lectures/waterfall.pdf


Discussion of Waterfall• The original waterfall model (as interpreted by many)

disallowed iteration– Inflexible partitioning of the project into distinct stages

makes it difficult to respond to changing customer requirements.

– Therefore, this model is only appropriate when the requirements are very well-understood and changes will be very limited during the design process.

– But few business systems have stable requirements.• The “waterfall with feedback” model was, however,

what Royce had in mind


Requirements

Validate

Retirement

Operations

Test

ImplementationVerify

Design

Requirements Change

Waterfall*


Waterfall*REQUIREMENTS

ANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE


Evolutionary• Throw-away prototyping

– Objective is to understand the system requirements.– Should start with poorly understood requirements to clarify

what is really needed.

• Incremental development – Objective is to work with customers to evolve a final

system from an initial outline specification. – Should start with well understood requirements and stage

development and delivery.


Prototyping

Initial Concept

Complete and Release

Prototype

Refine Prototype Until Acceptance

Design and Implement

Initial Prototype


Discussion of prototyping• Mock-ups allow users to visualize an application that

hasn't yet been constructed• Used to help develop requirements specification

– Useful for rapidly changing requirements– Or when customer isn’t sure what specification should be

• Prototypes should be discarded once requirements are “known”, and another process model used for development– Prototypes should not be used as a basis for implementation,

since rapid prototyping tools do not create production quality code

– Customer (and management) may need to be “educated” about prototypes: a prototype is not 80-90% of the final product, usually not even 10%


Incremental (staged) delivery

Detailed Design, Implement, Test, Deliver Feature Set

Requirements

Validate

Retirement

Operations

Verify

Architectural Design


Discussion of incremental delivery

• Iterations are classified according to feature sets:

– e.g., features 1 and 2 will be delivered in this iteration, features 3 and 4 are next.

• Series of increasingly “complete” releases.

• Lack of process visibility - when will it be done?

• Systems are often poorly structured.


Process Iteration

• System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems.

• Iteration can be applied to any of the generic process models.

• Several approaches.


Iterative delivery

Initial Concept

Operations

Acceptance Testing

and Delivery

Requirements and Iteration

Planning

Next Iteration

Design andImplement


Discussion of iterative delivery• Rather than deliver the system as a completed product,

the development and delivery is broken down into iterations, with each iteration delivering part of the required functionality.

• User requirements are prioritized and the highest priority requirements are included in early iterations.

• Once the development of an iteration is started, the requirements are frozen - but requirements for later iterations can continue to evolve (this is the distinction compared to incremental delivery of feature sets)


Discussion of iterative development

• Customer value can be delivered with each iteration so system functionality is available earlier.

• Each iteration’s deliverable is not a prototype, but an operational system.

• However, early iterations act as a prototype to help elicit requirements for later iterations (exploratory).

• Lower risk of overall project failure.• The highest priority system services tend to receive

the most testing.


Agile (eXtreme) Programming

• Iterative, but with a lot of hype• Timeboxing:

– Set the date for delivering an iteration– Date cannot change– Only functionality (scope) can change– Short duration iterations (weeks, not

months)

http://agilemanifesto.org/


Spiral model

PLAN DEVELOP AND TEST

DETERMINE GOALS,ALTERNATIVES,CONSTRAINTS

EVALUATE ALTERNATIVESAND RISKS

Requirements,life-cycle plan

Budget1

Alternatives1

Constraints1

Risk analysis1

Risk analysis2

Risk analysis3

Risk analysis4

Constraints 2

Constraints 3

Constraints 4

Budget2

Budget3Budget4

Altern

atives 2

Altern

ative

s 3Altern

ative

s 4

Prototype 1

Proto -type2

Proto -type3

Proto -type4

Concept ofoperation

Softw

are

requ

irem

ents

Validated

requirements

Developmentplan

Integrationand test plan

Softw

are

desig

n

Validated,

verified design

Detaileddesign

Code

Unit test

SystemtestAcceptance

testImplementation

plan

start


Discussion of Spiral Model

• Proposed by Barry Boehm, ~1986

• Process is represented as a spiral rather than as a sequence of activities with backtracking.– Each loop in the spiral represents a phase in the

process. – No fixed phases such as specification or design -

loops in the spiral are chosen depending on what is required.

http://portal.acm.org.monstera.cc.columbia.edu:2048/citation.cfm?id=12944.12948&coll=ACM&dl=ACM


Discussion of Spiral Model

• Each iteration is driven by “risk management”

– Determine objectives and current status

– Identify risks and priorities

– Next iteration addresses (current) highest risk and/or highest priority items


The Basic Problem: Risk

• The spiral and agile iterative process models view “risk” as the main problem of software development– Schedule slips– Business changes– Staff turnovers– New technologies– …

Upcoming Assignments


Upcoming Assignments

• Project Concept due Tuesday 5 October, 10am• Posted on course website• Submit via CourseWorks


Team Project Planning and Progression


First Iteration Assignments

• First Iteration Plan due Tuesday 19 October.• First Iteration Progress Report due Tuesday 26

October. • First Iteration Demo Wednesday 3 November –

Thursday 11 November.• First Iteration Final Report due Friday 12

November.


COMS W4156: Advanced Software Engineering

Prof. Gail [email protected]



Documents

September 30, 2010COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser [email protected]