If Given No Direction on Process

• We start where many of us are “most comfortable” - programming and low level design

• Most small establishments also focus on programming and low level design first

Low LevelDesign & Code

Testing & Integration

Requirements& Architecture

past class inputs : “many people are entering the software environment via contacts with IS/IT or other support groups; thus the support process may

also be a starting point.”

Coding

Low level Design

Code Compile Unit Test

Debugworks ? “done!”

For most of us --- this is what we are “most used to”

Software Development Process• What is a Process ?:– a set of ordered tasks aimed at achieving some end

goals

• What is a Software Development Process :– a set of ordered tasks aimed at producing software

solutions ---- the tasks include:• requirements understanding, specification, and agreement of

problem

• architecture and design of the solution

• construction and programming of the solution

• testing of the solution

• integration of the solution

• installation and deployment of the solution

• supporting, fixing, and evolving the solutionNote: Each of these tasks may itself be a Sub-Process containing ordered subtasks

Why Have a Process at all ?

• Large Software development requires a group of people - coordination of activities is key

• Process imposes a set of structure and consistency:– forms a common understanding of the ordered tasks, constraints, and

needed resources

– allows the detection of any omission and of problems in the development of solution

– clarifies the goals of the software solutions via emphasizing and modifying the process (e.g. introducing review for quality)

– allows the tailoring and improvement for development of different types of software.

• Defined process allows us to capture our experiences and then reuse, improve, and/or pass it on to others

Some Key Process Models

• Major models:– Waterfall– V-model– Prototyping– Phased Model (Incremental and Iterative)– Spiral– Agile (e.g. X-treme programming)

• Minor ones (rarely talked about in industry, now) :– Operational : (nail down the requirements and combine

with design/code - almost like prototyping)– Transformational : (“formal” evaluation of the actual

transformations from one phase to another phase)

Waterfall Process

• The most familiar and modeled after hardware and manufacturing process

• This process with each stage not starting until the previous one is completed was attractive:– easy to track for management

– deliverables are well defined

• There are some serious drawbacks:– the actual “testing” of the code comes very late in the process

– customer interaction did not happen except at the requirements phase

– “real” development stages are not that crisp in that more interaction and iteration is required because software development is not manufacturing except at the packaging and copying stage

Requirements

Design Program &Unit Test Test Integrate &

System Test Package& Release

(Spec.)

(Spec.)(Code) (Spec.&

test result) (System) (System)

V-Model

• This is similar to the Waterfall Model except the association of different testing (test case design) phases are aligned with the requirements, design, and code phases for error corrections.

Requirements

Design

Code Unit Test

Integration &Functional Test

System Test &Packaging

Test CaseDesign

Test CaseDesign

Prototyping Model

• Allows better understanding and revisions of the users’ requirements, especially UI.

• Allows better explorations of feasibility of unknown areas.

• Usually coupled with waterfall or any other processes.

Requirements

Prototype

Design Integrate System

Prototype Prototypechanges changes

Phased Development Model

• Many reasons to develop the solution in phases:1. Delivering some part fast and early

2. Getting reactions early and being able to adjust

3. Some early training and familiarization of users

4. Allows the staggering of & reuse of skills and technology

• There are 2 major approaches:– Incremental : breaking the requirements into separate

vertical application parts ; develop and deliver the parts as fully functional application subsystems.

– Iterative: break the system into separately designed horizontal cross application parts (applications with simple screens with little error recovery, enhanced error messages and context sensitive help, enhanced performance and speed, etc..); develop and deliver the various parts as complete, cross application components

Things areneververy clean

How would we develop Incrementally & Iteratively?

F1 FnF2

User Int / levels of GUI

. . . .

“Reprocess” Mechanism

Help/Error Messages

Import/Export

data sharing mechanism

“Horizontal” CommonFunction Design

“Vertical” App Component Design

installation mechanism

Spiral Model• Introduced by Barry Boehm at TRW to combine

development process with “enhanced” risk management.

• There are four major aspects :– planning

– setting goals and looking at alternatives

– evaluate the alternatives and the risks

– develop and test (perform the task)

• Each of development phases such as requirements, design, etc. goes through the four aspects.

Plan

Setting goal &alternatives

Prototype alternatives& analyze risks

Develop &Test (perform the task)

Design

Agile Processes

• There are several “agile” processes:– Extreme Programming –XP– Crystal– SCRUM– Adaptive Software Development

• Some commonalities among the Agile processes:1. Develop in small increments 2. Frequent “delivery” of the increments3. Small teams of people4. Focus on customer collaboration, rather than legal contracts5. Value human and human interaction more than documentation

and process/tools 6. Accommodate changes, rather than excessive front end planning

and follow the plan rigidly --- believe in “changes”

A lot like the earlier “phased incremental & iterative process”

Extreme Programming (XP)• A Programming practice or set of principles

originated by Kent Beck in the mid-90’s.• Based on the concept of quick and constant “Feedback

Mechanism” involving:• Planning Game (Small Units of Requirements)

• Onsite Customer (Immediate and better feedback)

• Metaphor (Use one set of metaphor for design/architecture)

• Simple Design (Just enough to cover what’s needed)

• Collective Code Ownership (Peer pressure to improve code)

• Pair Programming (Feedback and shared improvements)

• Coding Standard (Facilitates better communication)

• Refactoring (Continuous examination for code improvement)

• Continuous Functional and Unit Testing (100% completion of test)

• Continuous Integration (integrating small functional “releases”)

• 40 hour work (high morale and energy level)

somerecognitionof “human”aspects

Extreme Programming “Process”

Simple Design

System Metaphors

Coding standards

PlanningGame(requirements)

Refactoring

Pair Programming Functional &Unit Test

Collective CodeOwnership

Continuous Integration

SmallReleases

LargerRelease

Onsite Customers

Adhere to 40 hour work week as much as possible !

A Note for Your Project Assignment

• Reminder: 2nd part of your semester project WILL be a “team project”

– So ---- think about agreeing on a process modeled after one of these “macro-processes” --- see earlier slide #4 on why process is needed.

Do you need to think about process this early in the game?

---- What do you say?

Process Plays an Important Role in Software Engineering

• Process Modeling and Studying– building static models to depict understand the

process model

– building dynamic models to run and predict outcomes of process model

• Process improvements and enforcement– ISO 9000

– CMM and CMMI

Process “modeling,” although a good idea, is very difficult due tothe great variability in human behavior ---- so far it has not beendone very successful.

Studying Process or Sub-Process

Process orSub-processDescription

Pre-conditions

Inputs

Post-conditions

Outputs

Measurements of Success:- schedule reduction- cost reduction- improved quality- etc.

Difficult toshow

How Do We Describe the Process

• Pre and Post conditions : how much do we specify (people skills, tools readiness, previous process completion status, etc.)

• Input : all the inputs and to what degree• Outputs : all the outputs and to what degree • Process Description : how detailed ; how should it

be represented (graphical, textual, etc.)• Should all these descriptions be static descriptions

or dynamic and possibly “executable ?” (Leon Osterweil’s proposal in late 1980’s)

• Don’t Worry about the Lai notation (Static model) & other process modeling discussions towards the end of Chapter 2

Some “Desirable Properties” of Process Descriptions

1. Facilitates the communication of and the understanding of the process. (check your book and my lecture notes --- communicated “deep” enough?)– Allows reuse of all or parts of the process– allows improvements and adjustments

2. Allows the management of process– provides metrics and measurements on the process

3. Provides more than just description– give some guidance on how to execute the process– deep enough to automate parts of or all of the process

Top 2 Industry Process “standards”

• ISO 9000– Very Document Oriented

– Popular in Europe and among Manufacturing industry

– Popular in the early 90’s

• CMM/CMMI– CMM Has 5 levels of maturity, each level addresses

a set of “Key” processes - except for level 1

– For continuous improvements

– Start to gain popularity among service companies

Agile’s --- SCRUM is the currently “popular” process