1

Software Development Process

CS3342 Software Design

Dr. Jacky Keung
 Agenda
• Understand software process
• Process models, their pros and cons
• Key activities of Component Based Software
Engineering (CBSE)
• Computer Aided Software Engineering (CASE) tools
What is a Process?
Sake Wine Production
Process
Software Engineering
Process
 What is Software Process?
Software • A series of predictable steps, road maps, that help us to
process
create a timely, and high-quality result.
Process Model • The road map defines tasks or activities that take place
Linear during the process.
Incremental
Evolutionary
Other Step 1: define req
Step 2: analysis …
CASE Step 3: design …
Step 4: coding …
Step 5: ….

• The process depends on the SW we are building (the nature

of the software development project)
• Web application vs. computer game vs. automobile
control system, they are using different processes
 Software Process
Software
• A process defines who is responsible for:
process
• What?
Process Model • When and how?
Linear • To reach a goal
Incremental • Process defines tasks and activities within a
Evolutionary
Other
schedule

CASE Output Deliverable

Process s:
(tasks, activities) – Program
s
Staffs – Documen
follow
ts
the Quality
process – Data
control
measures
 SW Process Model (Life cycle)
Software
Process
• A software process model
Process
Model • is an abstract representation of a process
Linear
Incremental • it describes a process
Evolutionary
• guides the software development team
Other
• with a set of key activities
CASE
 SW Process Model (Life cycle)
Software
Process
• All process models have phases
Process • (e.g: design phase, test phase) and each
Model
Linear phase has 3 components:
Incremental
– Set of activities
Evolutionary
Other – define, design, implement, test and maintain
CASE
– Set of deliverables
– What to produce
– Quality control measures
– What to use to evaluate/assess deliverables
Waterfall Model ?
 4 Types of Process Model
1. Linear 3. Evolutionary
Software
Process
• Waterfall – Prototype
Requirements
definition – Spiral
Process
Model
System and
software design – Concurrent
Linear Implementation
and unit testing
Incremental
Evolutionary Integr ation and
system testing

Other Operation and

2. Incremental maintenance

CASE
• Incremental model 4. Other
• RAD – Rapid Application Development – CBSE
– Agile
 Waterfall Model
Disadvantages
Software
Process
Advantages • Sequential, does not reflect
Easy reality
• Does not produce a prototype
Process
Model
Structured • Relies heavily on being able to
Linear
Incremental
Provide a accurately assess requirements at
the start
Evolutionary
Other
template into • Little feedback from users until it
which methods for might be too late. Therefore cannot
CASE
analysis, design, adapt to users’ needs, lack of
intelligence and adaptability
code, testing and • Problems in the specification may
maintenance can be found very late (at Coding or
be placed. integration)
• It can take a long time before the
first version is out
 Pure Waterfall
• The “god parent” of models
Software
Process • Linear sequence of phases
• “Pure” model: no phases overlap
• Risky!
Process
• Integration and testing occur at the end
Model
Linear • Too late!!
Incremental
Evolutionary
Other

CASE When to use?

• Simple Projects
• Limited amount of time
• Requirements are well understood
• Use well-understood technologies
 Waterfall Model
Software Follows a systematic, sequential approach to SW
Process development that begins at the system level and
progresses through analysis, design, code and
Process testing.
Model
Requirements
Linear definition
Incremental
Evolutionary
Other System and
software design
CASE Most commonly
Implementation used in industry.
and unit testing

Integration and
system testing

Operation and
maintenance
 Incremental Process Models
Software • Goal: provide quick basic functionality to the
Process users
• Process is not linear
Process
 Requirements are well defined
Model • Software is completed in small increments
Linear • The system “Grows” in a number of small steps
Incremental
Evolutionary
Other
2 kinds :
CASE 1. Incremental Model
2. RAD
 1. Incremental Model
Software • 1st build provides the CORE functionalities
Process
• Each increment “deliverable” adds a new
functionality.
Process • This is repeated until the product is complete
Model
Linear • It combines characteristics of the waterfall model
Incremental and the iterative nature of the prototyping model.
Evolutionary
Other

CASE

When to use?
• When the software can be
Build Then
broken into increments This first This 2nd
and each increment
represent a solution This 3rd This 4th
Complete system
 The Incremental Model
Software 1st Example:
Process increme 2nd 3rd Facebook (a social
nt networking website) with
Process parts like member registration,
Model sign in, forget password, member
Linear profile, search members, friends
Incremental list, blog, blog search, photos,
Evolutionary
photo search and messaging.
Other
1st increment:
CASE member registration,
sign in, member
profile and search
members.
2nd increment:
friends list, blog, blog
search.
3rd increment:
Same team develops all the increments photos, photo search,
messaging and
password retrieval .
 2. The Rapid Application Development (RAD) Model

Software
Process • Builds on the Incremental model with emphases on
short development cycle.
Process
• A speed waterfall model
Model • Components are built using this model as a fully
Linear functional units in a relatively short time
Incremental
Evolutionary
• It assumes that the system can be modularized
Other • Involves multiple teams!
• RAD will fail if we don’t have strong and skillful
CASE
teams
 RAD Model
Te am # n
Software Mo d e lin g

Process
bus ine s s m ode ling
da t a m ode ling
proc e s s m ode ling

Co n s t ru c t io n
c om pone nt re us e
Te am # 2
Process Co m m u n ic at io n a ut om a t ic c ode
ge ne ra t ion
t e s t ing
Model Mo d e ling
b u sin e ss m o d e lin g
Linear d a t a m o d e lin g
p ro ce ss m o d e lin g
Incremental
Plan n in g
Evolutionary Co ns t ruc t io n De p lo ym e n t
Other Te am # 1 co m p o n e n t re u se in t e g rat io n
a u t o m a t ic co d e
g e n e ra t io n d e liv e ry
Mo d e lin g t e st in g fe e d b ack
CASE b u sin e ss mo d e lin g
d at a mo d e lin g
p ro ce ss mo d e lin g

Co n s t ru c t io n
co mp o n e n t re u se
au t o mat ic co d e
g e n e rat io n
t e st in g

6 0 - 9 0 d ays
 Evolutionary Process Models
• Specification, development and validation activities are
Software
Process carried out concurrently with rapid feedback across these
activities
• Core requirements are well understood but additional
Process requirements are evolving and changing fast
Model
• Design most prominent parts first
Linear
Incremental • Usually via a visual prototype
Evolutionar
y
• Good for situations with:
Other • Rapidly changing requirements

CASE
• Non-committal customer
• Vague problem domain 3 models:
1. Prototype
2. Spiral
3. Concurrent
 Evolutionary Process Models
Software Advantages
Process  Do not require full knowledge of the requirements
 Iterative (software gets more complex with each
Process iteration)
Model
Linear
 Divide project into builds (standalone software package
Incremental - binaries)
Evolutionar
 Allows feedback, show user something sooner
y
Other  Use to develop more complex systems
 Provide steady, visible progress to customer
CASE
Disadvantages
• Time estimation is difficult
• Project completion date may be unknown
 1. Prototyping Model
Software
Process • Start with what is known about requirements.
• Complete a quick design.
Process • Build the prototype by focusing on what will be seen
Model by the user.
Linear • Use the prototype to show the user and help refining
Incremental
requirements.
Evolutionary
• Better communication
Prototy
pe
Spiral
Concur E
Other

CASE
 Prototype Model
Software Advantages Disadvantages
Process
Prototype can serve as • Customer might think
a way for identifying that the prototype is the
Process
requirements. final product and forget
Model
the lack of quality i.e.
Linear It is developed very
Incremental PERFORMANCE,
quickly.
Evolutionary
RELIABILITY.
Prototy
pe
Spiral When to use?
Concur E
• When the customer define general objectives for the
Other
SW but does NOT identify details about INPUT,
CASE OUTPUT, or processing requirements.
• The developer is unsure of the efficiency of an
algorithm, human machine interaction, etc.
 2. Spiral Model
• Iterative (like Prototype) and controlled (like
Software waterfall)
Process
• Software is developed using evolutionary
Process
releases
Model
Linear
• Complexity increase with each release
Incremental • A spiral process rather than as a sequence of activities
with backtracking
Evolutionary
Prototype • Each loop in the spiral represents a phase in the process.
Spiral
Concur E
• No fixed phases such as req. specification or design -
Other loops in the spiral are chosen depending on what is
required—more flexible
CASE
• Emphasize risk analysis and management (Risks are
explicitly assessed and resolved throughout the process)
 • A series of Mini-projects
• Each addresses a set of “risks”
The Spiral Model – Start small, explore risks,
prototype, plan, repeat
• Number of spirals is variable
Software
Process

Process
Model
Linear
Incremental

Evolutionary
Prototype
Spiral
Concur E
Other Customer
communication

CASE

Customer
feedback
 Spiral Model
Software
Process Advantages
Can be combined with other models
Process
Model
Risk orientation provides early warning of
Linear problems
Incremental
Disadvantages
Evolutionary
Prototype • More complex
Spiral
Concur E
• Requires more management
Other

CASE
When to use?
• Very large projects, mission critical systems
• When technical skills must be evaluated at each step.
 3. Concurrent Engineering Model
Software Plan
Process

Process Divide Parallel development

Model
Linear
Incremental
Work on Work on Work on
Evolutionary Component or Component or ... Component or
Prototype Layer A Layer B Layer X
Spiral
Concur
E
Other Integrate
CASE
• It explicitly use the divide and conquer principle.
• Each team works on its own component, typically following a spiral
or evolutionary approach.
• There has to be some initial planning, and periodic integration.
 Other Process Model: Component based
software engineering (CBSE)
Software Pre-fabricated
Process
• When reuse is a development Components

Process
objective
Model • Based on systematic reuse where
Linear
Incremental
systems are integrated from
Evolutionary existing components or COTS
Other
CBSE
(Commercial-off-the-shelf)
systems. (E.g., data conversion, encryption,
CASE device drivers, data mining modules)

• The main difference is that CBSE A new system

emphases on composing solutions
from prepackaged software
components or classes
 CBSE: The Key Questions
Software
Process
When faced with the possibility of reuse, the
software team asks:
Process • Are commercial off-the-shelf (COTS)
Model
Linear components available to implement the
Incremental requirement?
Evolutionary
Other • Are internally-developed reusable components
CBSE
available to implement the requirement?
CASE • Are the interfaces for available components
compatible within the architecture of the
system to be built?

First rule of CBSE: never build what you can buy!

Because: it becomes solution oriented, built based on
features available in the components, not from customer
requirements (problem-oriented).
 CBSE and design principles
Software
Process
CBSE is based on sound software engineering
Process
design principles:
Model • Components are independent so do not
Linear
Incremental
interfere with each other;
Evolutionary
Other • Component implementations are hidden;
CBSE
• Communication is through well-defined
CASE interfaces; (method calls)
• Component platforms are shared and
reduce development efforts / costs.
 What is a Component?
Software
Process • Components provide a service without regard to
where the component is executing or its
Process programming language
Model
Linear • The component interface is published and all interactions
Incremental
are through the published interface;
Evolutionary
Other • An independent, executable entity.
CBSE
• The services offered by a component are made available
CASE
through an interface API.
Component-based
Engineering
Example: Bar Code
Component
• If you are building a POS application…
• Use a bar code generator component, do not write your
own.
Example
• You are developing a software application for online Food ordering for CityU
Canteen. Once the order is completed, the user needs to print the generated
QR-Code to the counter for payment and then collect their food.

• But you are not an expert is QR-Code technology, what should you do?
• Solution:
• You can use QR-Code Components which can be purchased from vendors.
• For example: http://www.keepautomation.com/products/java_barcode/barcodes/qrcode.html

• You need to follow the component’s API for method calls.

• You then need to integrate the output with your own application.
• Anyone got a QR code reader on their iPhone / Android Phone? 
 Component characteristics
Software Standardised Component standardisation means that a component that
Process is used in a CBSE process has to conform to some
standardised component model. This model may define
component interfaces, component meta-data,
documentation, composition and deployment.
Process
Independent A component should be independent – it should be possible
Model
to compose and deploy it without having to use other
Linear specific components. In situations where the component
Incremental needs externally provided services, these should be
Evolutionary explicitly set out in a ‘requires’ interface specification.
Other
Composable For a component to be composable, all external
CBSE interactions must take place through publicly defined
interfaces. In addition, it must provide external access to
CASE information about itself such as its methods and attributes.
Deployable To be deployable, a component has to be self-contained and
must be able to operate as a stand-alone entity on some
component platform that implements the component model.
This usually means that the component is a binary
component that does not have to be compiled before it is
deployed.
Documented Components have to be fully documented so that potential
users of the component can decide whether or not they
meet their needs. The syntax and, ideally, the semantics of
all component interfaces have to be specified.
 The CBSE Process - considerations
Domain Engineering
Step (1)
Domain Software Reusable
Build up a Analysis Architecture
Development
Artifact
Development
component
library Repository
Domain Structural Reusable
model Model Artifacts/
Components

Software Engineering
Step (2)
System Specification
& Construction
Analysis
Develop a User Design
Requirements
new system
based on System
Analysis
Application
& Design
components Spec Models
Software
Homework 

• Have a look at the QR-Component BlueJ project

• Modify the code to generate other types of barcodes,
such as Code128
• API available in folder:
QR_Component_BlueJ/KA.Barcode.for.Java/java-barcode-api/index.html

• Note: Need to import the component first

• In BlueJ -> Preferences -> Libraries -> Add
• In Folder: QR_Component_BlueJ/com.keepautomation.barcode.jar

• Good Luck and Have a good week!