CSEB233: Fundamentals of Software...

45
CSEB233: Fundamentals of Software Engineering Software Process Part 1 Process Models

Transcript of CSEB233: Fundamentals of Software...

Page 1: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

CSEB233: Fundamentals

of Software Engineering

Software Process

Part 1

Process Models

Page 2: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Lesson Objectives

● Describe the types of process flows

● Determine task set for software process activities

● Explain software process patterns

● Discuss several process assessment andimprovement frameworks

● Analyze prescriptive and specialized softwareprocess models

● Select a process model for software developmentproject

Page 3: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

A Generic Process Model

● A software process:

o a collection of work activities, actions, tasks, which

are performed when software is to be created.

● A process model or framework

o is where these activities, actions, and tasks reside,

and that defines their relationship with the process

and with one another.

o Also known as an abstract representation of a

software process.

Page 4: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

A Generic Process Model

● Shows the technical workhierarchyo activities encompassing

actions, populated by tasks

● Each action is defined by aset of task that defines:o the actual work to complete

o the work products toproduce

o the quality assurance filtersto apply, and

o the milestones that are usedto indicate the project andproduct progress

Page 5: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process ActivitiesFramework & Umbrella

● Framework activities :o generic activities that are applicable to all software

projects, regardless of their size or complexity

o Include communication; planning; modeling, construction;and deployment

● Umbrella activities:o complementary activities applied throughout a software

project and help manage and control progress, quality,change, and risk

o Include project tracking and control; risk management;software quality assurance (SQA); technical reviews;configuration management (CM); etc.

Page 6: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Models

Process Flows

Page 7: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Flow

● Describes how the framework activities and theactions and tasks that occur within each activity areorganized with respect to sequence and time

● The flows:

o Linear: execute the framework activities in sequence

o Iterative: repeats one or more of the activities beforeproceeding to the next

o Evolutionary: execute the activities in a ‘circular’ manner

o Parallel: executes one or more activities simultaneouslywith other activities

Page 8: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Flow

Page 9: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Flow

Page 10: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Flow

Page 11: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Flow

Page 12: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Models

Task Set

Page 13: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Identifying a Task Set

● A task set defines the

actual work to be done to

accomplish the

objectives of a software

engineering action

o A list of the tasks to be

accomplished

o A list of the work products

to be produced

o A list of the quality

assurance filters to be

applied

Page 14: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Identifying a Task Set Key Questions in Determining Task Set

● Different projects require different task sets

o The tasks should be selected based on problems andproject characteristics

● Q: What actions are appropriate for a frameworkactivity, given:

o the nature of the problem to be solved;

o the characteristics of the people doing the work; and

o the stakeholders of the project?

● Q: What work tasks (task set) that these actionsshould encompass?

Page 15: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Identifying a Task SetExample

● Nature of the problems and project:

o A small software project requested by one person (at aremote location) with simple, straightforward requirements.

● Actions:

o Communication action: Develop requirements

● Task set:

o Make contact with stakeholder via telephone.

o Discuss requirements and take notes.

o Organize notes into a brief written statement of requirements.

o E-mail to stakeholder for review and approval.

Page 16: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Models

Process Patterns

Page 17: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Patterns

● A process pattern

o describes a process-related problem that is encounteredduring software engineering work,

o identifies the environment in which the problem has beenencountered, and

o suggests one or more proven solutions to the problem

● In more general terms, a process pattern provides atemplate

o a consistent method for describing problem solutionswithin the context of the software process

Page 18: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Pattern Types

● Task patterns

o Pattern used to describe a problem (and solution)associated with an action within a framework activity, e.g.project estimating

● Stage patterns

o Pattern used to describe a problem (and solution)associated with a framework activity, e.g. planning

● Phase patterns

o Pattern used to describe a problem (and solution)associated with a complete process model, e.g.prototyping

Page 19: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Pattern Template

● Pattern name – meaningful, descriptive name of the pattern

● Forces – environment encountered and issues

● Type – one of the three types defined earlier

● Initial context – prerequisites for the pattern application

● Problem – the specific problem to be solved

● Solution – details description of the proposed solution andwhat happen to initial context as a result

● Resulting context – result of the application of pattern

● Related patterns – list of related pattern at any level

● Known uses and examples – instances where the pattern isapplicable

Page 20: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Models

Process Assessment &

Improvement

Page 21: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Assessment and Improvement: Approaches

● Standard CMMI Assessment Method for ProcessImprovement (SCAMPI):o Used to identify strengths, weaknesses, and ratings relative

to SEI CMMI appraisal reference model, which is applicableto internal process improvement and external capabilitydetermination

● CMM-Based Appraisal for Internal Process Improvement(CBA IPI):o Provides a diagnostic technique for assessing the relative

maturity of a software organization; uses the SEI CMM as thebasis for the assessment [Dun01].

o However, CMM has been retired by SEI since the introductionof CMMI group of standards

Page 22: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Assessment and Improvement: Approaches

● SPICE (ISO/IEC15504):o Standard that defines a set of requirements for software

process assessment.

o The intent of the standard is to assist organizations indeveloping an objective evaluation of the efficacy of anydefined software process [ISO08]

● ISO 9001:2000 for Software:o A generic standard that applies to any organization that

wants to improve the overall quality of the products,systems, or services that it provides.

o Therefore, the standard is directly applicable to softwareorganizations and companies [Ant06]

Page 23: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Models

Prescriptive & Specialized

Process Models

Page 24: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process Models

● Promote an orderly, structured approach to SE

● That leads to a few questions . . .

o If prescriptive process models strive for structure and

order, are they inappropriate for a software world that

thrives on change?

o Yet, if we reject traditional process models (and the

order they imply) and replace them with something

less structured, do we make it impossible to achieve

coordination and coherence in software work?

Page 25: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process Models

● Waterfall Modelo represents elements of a linear process flow

o V-model is a variation of waterfall model with quality assuranceactions depicted

● Incremental Modelo combines elements of linear and parallel process flows

● Evolutionary Modelo follows the evolutionary process flow that combines elements of

linear and iterative process flows■ Prototyping

■ Spiral

● Concurrent Modelo combines elements of iterative and parallel process flows

Page 26: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Waterfall Model

● Represents a linear process flow from communica-tion through deploymento Also known as the classic SDLC

● The original Waterfall model proposed by WinstonRoyce in 1970 made provision for feedback loopso but many organizations apply this model as if it were

strictly linear

Communicat ion Planning

Modeling

Const ruct ionDeployment

analysis

designcode

t est

project init iat ion

requirement gat hering estimating

scheduling

tracking

delivery

support

f eedback

Page 27: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsAn Analysis of Waterfall Model

Characteristics Strengths Weaknesses Applicability

• It suggests a

systematic, sequential

approach to SE,

starting from

requirements

specification through

planning, modeling,

construction, testing,

deployment and

support of the

completed system.

• Each major activity is

marked by milestones

and deliverables (i.e.

documents).

• Simple and easy to

use/explain to

customers.

• The staged

development cycle

enforces discipline:

every phase has a

defined start and end

point, and progress

can be conclusively

identified (through the

use of milestones)

• Real projects rarely follow the

linear flow that the model

proposes. Although iteration is

indirectly allowed, changes are

costly, involve significant rework

and can cause confusion to

project team.

• The model requires the customer

to state all requirements

explicitly, which is often very

difficult to achieve.

• The working software will not be

available until late in the project,

which can be disastrous for late

discovery of major defects.

• Leads to “blocking states” in

which some project team

members must wait for others to

complete dependent tasks.

• When requirements are

well understood and

unlikely to change

radically during system

development (e.g., in a

well-defined enhancement

to an existing system).

• When software

development technologies

and tools are well known.

• The work tasks in the

project are to proceed to

completion in a linear

manner.

Page 28: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe V-Model

● Variation in representing

the Waterfall model

● Illustrates how V&V

actions are associated

with earlier SE action

● There is no fundamental

difference between the

Waterfall model and the

V-model

Page 29: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Incremental Model

● Rather than deliver the software product as a singledelivery, the development and delivery is brokendown into increments with each increment deliveringpart of the required functionality.

● User requirements are prioritised and the highestpriority requirements are included in earlyincrements

● Once the development of an increment is started,the requirements are frozen but requirements forlater increments can continue to evolve

Page 30: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Incremental Model

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des ign code

t es t

increment # 1

increment # 2

delivery of

1st increment

delivery of

2nd increment

delivery of

nt h increment

increment # n

project calendar t ime

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des ign code

t es t

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des igncode

t es t

Page 31: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Evolutionary Model: Prototyping

● Using this process model, a prototype - an earlyapproximation of a final software product - is built,tested, and then reworked as necessaryo until an acceptable prototype is finally achieved from

which the complete software product is developed

● Although it can be implemented as a stand-aloneprocess model, it is more commonly used as part ofother process models

● The main purpose of the model is to help betterunderstand what it is to built when requirements arefuzzy

Page 32: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Evolutionary Model: Prototyping

Communicat ion

Quick plan

Const ruct ion of

prototype

Mode ling

Quick de sign

Delivery

& Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

Page 33: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Evolutionary Model: Spiral

● A process model that combines the iterative nature

of prototyping with the systematic aspects of

waterfall model

● The spiral model can be thought of as a repeating

waterfall model that emphasizes risk assessment

and that is executed in an incremental fashion

● Each loop/pass through the spiral model consists of

risk assessment and other framework activities from

communication through deployment

Page 34: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Evolutionary Model: Spiral

communication

planning

modeling

constructiondeployment

delivery

feedback

start

analysis

design

code

test

estimation

scheduling

risk analysis

Page 35: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Concurrent Model

● A process model that combines the iterative and

parallel elements of any of the prescriptive

process models

● In this model, all SE activities (framework or

umbrella) exist concurrently but reside in

different states

Page 36: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Prescriptive Process ModelsThe Concurrent Model

Under review

Baselined

Done

Under

revision

Await ing

changes

Under

development

none

Modeling act ivit y

represents the state

of a software engineering

activity or task

Page 37: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Specialized Process Models

● Component based software development (CBSD)o the process to apply when reuse is a development objective

● Formal methodso emphasizes the mathematical specification of requirements,

which can demonstrate software correctness but are notwidely used.

● Aspect-oriented software development (AOSD)o provides a process and methodological approach for defining,

specifying, designing, and constructing aspects

● Unified Processo a “use-case driven, architecture-centric, iterative and

incremental” software process closely aligned with the UnifiedModeling Language (UML)

Page 38: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Specialized Process Models

● Agile Processo An iterative approach to requirements specification, construction

and deployment, which support rapid changes to requirements

● Personal Process Modelo Emphasizes the need to record and analyze errors each individual

practitioner made, so that he/she can develop a strategy toeliminate them

● Team Process Modelo Build self-directed teams that plan and track their work, establish

goals, and own their processes and plans. These can be puresoftware teams or integrated product teams (IPT) of three to about20 engineers

o Show managers how to coach and motivate their teams and how tohelp them sustain peak performance

Page 39: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Models

Selecting a Process Model

Page 40: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Selecting a Process ModelFactors to Consider

● The characteristics of the problems to be solvedo Such as complexity of the problem, etc.

o e.g. simple with clear, stable requirements, or complex withchanging, unstable requirements, etc.

● The characteristics of the projecto Such as the customers who have requested the product and the

people who will do the work, etc.

o e.g. Uncertain requirements, breakthrough technology

● The characteristics of the producto Such as quality attributes or metric of the product, product domain,

etc.

● The project environment in which the software team workso Such as political, cultural, language, etc.

Page 41: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Process Management Tools

● Also known as process modeling tools or processtechnology

● Allows a team to define and manage the elements of aprocess model (activities, actions, task, work products,milestones, and QA points/filters)

● Such tools also provide detailed guidance on the contentof each process element

● The tools may also provide standard project managementtasks such as estimating, scheduling, tracking and control.

● Example:

o Igrafx Process Tools (www.micrografx.com)

Page 42: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Selecting a Process ModelAn Exercise

● The Project:o Assume that you are in charge of a project to create a portal

for the Shah Alam district of Selangor.

o This portal would include a homepage with links to a widerange of discounted travel packages to major destinations inSelangor, links to certain featured places like golf courses,shopping complexes and places to eat, links to the detailedmap of Selangor, and links to news and events listing

o It also includes a bulletin board and chat room feature wheretourists (international and local tourists) can exchangeinformation.

o The portal should also provide Automated Teller Machine(ATM) locator, time zone converter, and currency converter.

Page 43: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Selecting a Process ModelAn Exercise

● Select a software process model that you would

recommend to be implemented in the above

mentioned project

● Why is the software process model selected?

Page 44: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

Summary

● There are four types of process flows – linear, iterative,evolutionary, and parallel.

● Software process patterns may suggest one or moreproven solutions to the problem from other projects, whichcan be reused in another project

● There are several process assessment and improvementsframeworks that can be exercised by practitioners

● The analyses of prescriptive and specialized softwareprocess models would help select the most appropriateprocess model for a software development project, whichcan be proceeded with the identification of task set for theproject

Page 45: CSEB233: Fundamentals of Software Engineeringmetalab.uniten.edu.my/~hazleen/CSEB233/CSEB233ProcessModel.pdf · CSEB233: Fundamentals of Software Engineering Software Process Part

THE END