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
Requirements
& Architecture
Low Level
Design & Code
Testing &
Integration
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
Debug
Unit Test
works ?
For most of us --- this is what we are “most used to”
“done!”
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 solution
Note: 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
(Spec.)
(Spec.)
Program &
Unit Test
(Code)
Test
(Spec.&
test result)
Integrate &
System Test
(System)
Package
& Release
(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.
Test Case
Design
Requirements
System Test &
Packaging
Test Case Integration &
Design Functional Test
Design
Code
Unit Test
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
changes
Integrate System
changes
Prototype
Prototype
Phased Development Model
•
Many reasons to develop the solution in phases:
1.
2.
3.
4.
•
There are 2 major approaches:
–
Things
are
never
very
clean
Delivering some part fast and early
Getting reactions early and being able to adjust
Some early training and familiarization of users
Allows the staggering of & reuse of skills and technology
–
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
How would we develop Incrementally & Iteratively?
“Vertical” App Component Design
F1
F2
....
Fn
User Int / levels of GUI
“Horizontal”
Common
Function
Design
Help/Error Messages
“Reprocess” Mechanism
Import/Export
data sharing mechanism
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.
Setting goal &
alternatives
Plan
Design
Prototype alternatives
& analyze risks
Develop &
Test (perform the task)
Agile Processes
• There are several “agile” processes:
–
–
–
–
Extreme Programming –XP
Crystal
SCRUM
Adaptive Software Development
• Some commonalities among the Agile processes:
1.
2.
3.
4.
5.
6.
Develop in small increments
Frequent “delivery” of the increments
Small teams of people
Focus on customer collaboration, rather than legal contracts
Value human and human interaction more than documentation
and process/tools
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:
some
recognition
of
“human”
aspects
•
•
•
•
•
•
•
•
•
•
•
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)
Extreme Programming “Process”
Onsite Customers
System Metaphors
Coding standards
Simple Design
Planning
Pair Programming
Game
(requirements)
Refactoring
Functional &Unit Test
Collective Code
Ownership
Continuous Integration
Larger
Release
Adhere to 40 hour work week as much as possible !
Small
Releases
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 to
the great variability in human behavior ---- so far it has not been
done very successful.
Studying Process or Sub-Process
Preconditions
Postconditions
Process or
Sub-process
Description
Outputs
Inputs
Measurements of Success:
- schedule reduction
- cost reduction
- improved quality
- etc.
Difficult to
show
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?)
–
–
2.
Allows reuse of all or parts of the process
allows improvements and adjustments
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