Software Engineering (CoSc 3061)

Chapter 02

Software Process

0
 Topics Covered
◼ Software Process

◼ Characteristics of a software process

◼ Software Development Process

◼ Software life cycle and process model

◼ Process Assessment Model

◼ Software Process Metrics

1
 Software Process………….?
◼ The software process defines the way in which
software development is organized, managed,
measured, supported and improved (independently
of the type of support technology exploited in the
development).

◼ A structured set of activities required to develop a

software system.

◼ Organizing a structured set of activities to develop

software systems. 2
Cont…

◼ Development team's activities that leads to final

development of their software program is software process.

◼ Each of these activities relates to the other in some way,

forming a linear path the team follows from initial
planning to final deliverables.

3
 Conti…
◼ Many different software processes involve the following activities:
◼ Specification – The team defining what the system should do
and constraints of the project(SRS).
◼ Design and implementation – Defining the organization of

the system and implementing the system(SDD+Code).

◼ Verification /validation: The team verifies that, it does what

the customer wants/not and presents prototype to the customer

for review.
◼ Evolution – The team listens to customer feedback and

changing the system in response to changing customer needs for

better functionality. 4
SDLC
◼ Main phases of software development process are:
◼ Requirements Analysis (answers “WHAT?”)
• Specifying what the software must do.
◼ Design (answers “HOW?”)
• Specifying different parts of the s/w, and how they will fit together.
◼ Implementation (a.k.a. “CODING”)
• Writing the code
◼ Testing
• Validating the product against requirements.
◼ Maintenance (Fixing or Enhancing)
» Fixing the defects and adding new capabilities
5
 Software Process Model

◼ A process model (also called software life cycle model ) is a

descriptive and diagrammatic representation of the software life
cycle.
◼ It is an abstract representation of a process. It presents a
description of a process from some particular perspective.
◼ A process model maps the different activities performed on a
software product from its beginning to ending.
◼ In any process model, the basic activities are included in the

life cycle but the activities may be carried out in different orders.

6
 Need for Software Process Model
◼ Development team must have a clear understanding about when and
what to do/outline your development process.
◼ Provide a visual representation of development process for both the
team and the customer to review.
◼ Without using of a particular process model:-
◼ the development of a software product would not be in a systematic

and disciplined manner.

◼ It becomes difficult for project managers to monitor the progress of

the project.
◼ A software process model defines entry and exit criteria for every
phase.
◼ A phase can start only if its phase-entry criteria have been satisfied. 7
 How to Choose Software Process models
➢ The development team must identify suitable process model for
the particular project and then adhere to it.

➢ A process model chosen based on the:

◼ Nature of project and application

◼ Methods and Tools to be used

◼ Controls and deliverables that are required.

◼ Nature of requirements

8
 Different Software Process models
◼ Many software process models have been proposed so far. Each of
them has some advantages as well as some disadvantages.
◼ A few important and commonly used are:
1. Waterfall Model
2. V-Shaped Model
3. Structured Evolutionary Prototyping Model
4. RAD
5. Incremental Model
6. Spiral Model
7. The (Rational) Unified Process
8. Agile Model
9
Waterfall Model

❑ Also called the classic life cycle or the linear sequential model.

❑ It suggests a systematic, sequential approach to software development

that begins at the system level and progresses through analysis,
design, coding, testing, and support.

❑ It is known as waterfall because it flows gradually downwards to

implementation phases. Once the phase is completed you can’t repeat it.

❑ There is no backtracking, Because the model does not support going back
to previously completed phases.
10
Cont…

11
 Phases in Waterfall Model
Requirements analysis and definition.
❑ The system’s services, constraints, and goal are established
and defined(SRS) in a manner which is understandable by
users and development team.
Software design.
❑ In this system design process the requirements transform in to

one or more executable form and establishes an overall

system architecture.
12
 Phases in Waterfall Model
Implementation and unit testing.
❑ During implementation phase, the software design is realized
as a set of program units and perform unit testing.
Integration and system testing.
❑ Individual units are integrated and tested to ensure that

software requirements have been met/ not including system

testing.
Maintenance
❑ Maintenance phase involves correcting error, improving the
system units and enhancing the system’s services.
13
 Pro’s and Con’s of Waterfall Model
Advantages:
❑ Simple to implement and manage.

❑ Often well when the projects have a defined set of requirements.

Drawbacks:
❑ Unable to accommodate changes at later stages

❑ A working version of the software is not available during development

❑ Unable to accommodate iteration.

❑ Deadlock can occur due to delay of any step.

❑ Because of its rigid structure, does not work well for complex projects
where there is a chance of a change in requirements .
14
 When to Use Waterfall Model
◼ Requirements are very well known

◼ Product definition is stable

◼ Technology is understood

◼ New version of an existing product

◼ Porting an existing product to a new platform.

15
 V-Shaped Model
▪ V model is known as Verification and Validation model.

▪ An extension of the Waterfall Model, the V-Model also functions

as a sequential flow.

▪ But , instead of only moving linearly downward, the lifecycle

bends upwards after coding (for each of testing phases), to form the
typical V shape.

▪ The model demonstrates relationships between each phase of life cycle and
its associated phase of testing.
▪ That means , testing of product is planned in parallel with a corresponding
phase of development. 16
V-Shaped SDLC Model

17
 V-Shaped Model Steps
◼ Project and Requirements Planning
◼ Production, operation and maintenance
◼ allocate resources
◼ Provide enhancement or corrections
◼ Product Requirements and Specification
◼ System and acceptance testing – check the
Analysis – complete specification of the
entire system in its environment.
software system(SRS).
◼ Integration and Testing – check that modules
◼ Architecture or High-Level Design –
a r e interconnect correctly.
defines how software functions fulfill the
◼ Unit testing – check that each module acts as
design
expected/not.
◼ Detailed Design – develop algorithms for
◼ Coding – transform algorithms into software
each architectural component.
18
 V-Shaped Model Strengths

◼ There is planning for verification and validation of product in

early stages of product development.

◼ Test design are executed in the starting including planning.

◼ Each deliverable must be testable.

◼ Calculation of errors is done at the starting of the project

hence, less chances of error occurred at final phase of testing.

◼ Easy to use. 19
V-Shaped Weaknesses
⚫ Does not easily handle concurrent events

⚫ Does not handle iterations or phases

⚫ Does not easily handle dynamic changes in requirements, if it is not

constant.

⚫ Does not contain risk analysis activities

⚫ Not suitable for large and composite projects

20
When to use the V-Shaped Model
⚫ Excellent choice for systems requiring high reliability – hospital patient
control applications
⚫ All requirements are known up-front.

⚫Solution and technology are known

21
 Structured Evolutionary Prototyping Model
⚫ Developers build a prototype during requirements phase.
⚫It involves creating a working system quickly for the customer to ensure
the team is meeting the customer's parameters/not.

⚫This prototype is working model of limited functionality, and provides

customer with a visual of what the final product might look like.

⚫The prototype is evaluated by end users , then give corrective feedback.

⚫ Based on feedback the developers further refine the prototype.

⚫ When the user is satisfied, continue to full development.

22
Cont…

23
Structured Evolutionary Prototyping Steps
⚫ A preliminary project plan is developed
⚫The model is source for a partial requirements specification
⚫ A prototype is built with basic and critical attributes
⚫ The designer builds
⚫ the database

⚫ user interface

⚫ algorithmic functions

⚫ The designer demonstrates the prototype, the user evaluates for

problems and suggests improvements.
⚫This loop continues until the user is satisfied. 24
Structured Evolutionary Prototyping Strengths
⚫ Customers can “see” the system requirements.
⚫ Developers learn from customers.
⚫A more accurate end product.
⚫Unexpected requirements accommodated
⚫Allows for flexible design and development
⚫Users are actively involved development process.
⚫Earlier error detection takes place in this model.
⚫It gives quick user feedback for better solutions.
⚫It identifies the missing functionality easily.
⚫Reduce maintenance cost.
25
Structured Evolutionary Prototyping Weaknesses
▪ The client involvement is more and it is not always
considered by the developer.
▪ It is a slow process because it takes more time for
development.
▪ Many changes can disturb time of development.
▪ Require extensive customer collaboration ,so needs
committed customer.
▪ Process may continue forever (scope creep).
▪ Special tools & techniques are required to build a prototype.

26
When to use Structured Evolutionary Prototyping
⚫ Requirements are unstable or good where requirements are
changing.

⚫Short-lived demonstrations

⚫ New, original development

27
Incremental Development
⚫It combines the elements of waterfall model and they are
applied in an iterative fashion.
⚫The team develops in increments, developing one part of
software and submitting it to user testing, to obtain user
feedback (Modular design).
⚫Each increment builds give the product and submits it to the
customer for suggesting any modifications.
⚫And each subsequent release of the system adds function to
previous release until all designed functionally has been
implemented.
28
Cont…
▪ This process is repeated until the product is completed.

29
Cont…
⚫ So, rather than deliver system as a single delivery, the development
and the delivery is broken down into increments with each
increment delivering part of the required functionality.

⚫ User requirements are prioritized, so the highest priority

requirements are included in early (first )increments.

⚫ Once the development of increment is started, the

requirements are unchanged though requirements for later
increments can continue to evolve.
30
Incremental Development –Advantages/ Strengths
•Deliver working software early: Each release delivers an
operational product(first ++).
•Parallel development. Multiple modules can be worked by
different teams.
•Modules can be completed at different times.
•Separation of concerns. Each module is a self-contained chunk
of the product.
•Adaptable to changes in scope. Modules can be added to or
dropped from the product.
•Risks can be identified and addressed per module.
31
Incremental Model Strengths……..
⚫Customer can respond to each build.

⚫ Uses “divide and conquer” breakdown of tasks.

⚫Initial product delivery is faster.

⚫ Customers get important functionality early.

⚫Early increments act as a prototype to help elicit requirements for later
increments.
⚫ Risk of changing requirements is reduced.

32
When to use the Incremental Model
▪ A project has a lengthy development schedule.
▪ When software team are not very well skilled or trained.
▪ Most of the requirements are known up-front, but are
expected to evolve over time and when the requirements are
superior/ larger.

▪ When the customer a needs to get basic functionality to

the market early.
33
 Rapid Application Model (RAD) Home work…
⚫It combines rapid prototyping with incremental development. Or
⚫It is a modification of the Incremental Model.

⚫When implementing this model, several components are developed

simultaneously as if they were smaller, individual projects.
⚫The different components are then assembled into working
prototypes.
⚫This helps to provide better feedback as well as the customer
oversees the live development of the system and is able to more
quickly identify new parameters or potential errors with original
expectations for the project. 34
 RAD Phase
⚫Requirements planning phase (a workshop utilizing structured
discussion of business problems).

⚫User description phase – automated tools capture information from

users.

⚫Construction phase – productivity tools, such as code generators,

screen generators, etc. inside a time-box. (“Do until done”)

⚫Cutover phase -- installation of the system, user acceptance testing

and user training.
35
RAD Strengths
⚫ Reduce development time
⚫ Time-box approach mitigates cost and schedule risk

⚫ Customer involved throughout the complete cycle, so minimizes risk of

not achieving customer satisfaction and business needs.
⚫Uses modeling concepts to capture information about business, data,
and processes.

36
RAD Weaknesses
▪ It requires highly expansive developers
⚫ Risk of never achieving closure.

⚫ Hard to use with legacy systems.

⚫ Requires a system that can be modularized.

⚫ Developers and customers must be committed to rapid-fire

activities in an abbreviated time frame.

37
When to use RAD
⚫ When the requirements are well-known.
⚫ User involved throughout the life cycle.
⚫When the project easily modularized into several increments.
⚫ High performance not required.
⚫ Low technical risks
⚫When there's a necessity to make a system, which modularized
in 2-3 months of period.
⚫It should be used only if the budget allows the use of
automatic code generating tools.
38
Reading Assignment!!!
⚫ Spiral Model (Boehm 87)
⚫The (Rational) Unified Process
⚫Iterative Development Model
⚫Agile Model

39
Software Process Assessment
▪ Determine state of organization’s software process
▪ Assessment team uses CMM to guide, identifying &
prioritizing findings.
▪ CMM is a business model that companies can use to helps to
improve their software development capabilities.
▪ Findings & KPA guidance used to plan, improvement
strategy for organization.
▪ Key process areas (KPA) refers to an individual employee's
overall scope of activities that he's expected to perform.
40
Software Capability Evaluations
- Identify risks associated with a project or contract to build high
quality on schedule & budget
- During acquisition process, capability evaluation may be
performed on collectors
- Findings of an evaluation may be used to identify risk with using a
contractor.
- Performed on existing contracts to monitor process
performance.
41
Software Process Assessment & Capability Evaluation Steps:
SW Process Assessment …
• Common Steps:
- Team Selection
➢ Select team trained in CMM
➢ Knowledgeable in SE & mgmt
- Maturity Questionnaire
➢ Site reps complete questionnaire
- Response Analysis
➢ Analyze results of questionnaire
➢ Investigation areas = KPAs

43 43
Conti…
- On-site Visit
- Using results analysis, conduct on-site visit to view process
areas
- Using KPAs as guide, question, listen, review & synthesize info
- Apply professional judgment
- Document rationale for situations where KPAs not met

44
Why Measure Software?
⚫ To determine the quality of the current product or process
⚫ To predict qualities of a product/process
⚫ In order to improve the quality of a product/process

➢ Metric - quantitative measure of degree to which a system, component or

process possesses a given attribute. E.g.
❖ Number of errors found per person

❖ Developer experience’s

❖ LOC, no class,….. 45
Motivation for Metrics
⚫Estimate the cost & schedule of future projects
⚫Evaluate the productivity impacts of new tools and techniques
⚫Improve software quality.
⚫Forecast future staffing needs.
⚫Anticipate and reduce future maintenance needs

46
Metrics in the Process Domain
⚫ Process metrics are collected across all projects and over long periods of time
⚫ They are used for making strategic decisions.
⚫ The intent is to provide a set of process indicators that lead to long- term software
process improvement.
⚫ The only way to know how/where to improve any process is to:-
⚫ Measure specific attributes of the process
⚫ Develop a set of meaningful metrics based on these attributes
⚫ Use the metrics to provide indicators that will lead to a strategy for
improvement.

47
END
Q?

48